Embedding a C interpreter

[JRowe]

Well, basically, I've been struggling with getting a neural net package running in AutoIt. I started with DllCall, and ran into issues when creating the struct for input. I ran into issues in laying out a plugin based solution, and the same issues apply for both the SOAP and the COM solutions.

I can't pass arrays from AutoIt to a Dll without taking a performance hit, and the variability of the inputs/outputs structure means each implementation has to be unique... e.g. any given neural net may have anywhere from 10 inputs and 2 outputs, or 400k inputs and 1000 outputs. This, of course, would be a pain in the ass to write in AutoIt, not to mention a potentially massive performance hit.

One solution I thought of would be to have c templates that are modifiable via a plugin and executed on the fly. This would give me a clean throughput back and forth from AutoIt and the neural net software.

I discovered this software which is a method of embedding c/c++ in an application.

The freeware version of Ch is what I'm going to be working with to start with, since I can use AutoIt to modify the c scripts on the fly, and automate their execution, but I was thinking that there might be a more elegant solution, and was wondering if any of the developers had looked into this.

My plan is to set be able to modify the plugin code on the fly and use the interpreter as a kind of dynamic, modifiable dll.

The bonus, of course, would be using almost any c programs in AutoIt, with a light plugin wrapper for data interchange.

Does anyone know of a free or open source Embeddable C/C++ package? Ch standard will almost certainly be enough, but I'd like to know if anything else is out there, and if this type of thing has been done before.

[JRowe]

Well, I did a little more research, and while there are a few interpreters out there, I can't find any reference of AutoIt being used with an interpreter. Plenty of LUA, Python, C# and Java integration, though.

CINT is another option, and might be best, as it's written at a university level, by a bona fide nerd, and not some random corporate hacks, whose software is "just work."

It's an arbitrary thing, with me, but I feel better about using software that I can distribute freely, with no restrictive licensing.

Anyway, the hunt continues.

*edit* Lots of good stuff at the CINT homepage. I'll try some of the plugin stuff and see where I get, then report back here.

For reference: I believe strings have been broken somehow, as passing strings to basic plugins returns gobbledeegook characters on successful function calls.

Edited February 19, 2009 by JRowe

[SmOke_N]

All of this sounds rather rediculous.

If you know "C", and you're having an issue, rather than looking for an interpreter, just write a wrapper for the C library that is provided for you, compile it to a dll, and use it via your AutoIt app..

If it's something more than that, then you need to be MUCH more specific.

[JRowe]

Why ridiculous? I was just asking if anyone has used a c/c++ interpreter in AutoIt before. The answer appears to be no, since there's little reference on the forums to anything like that happening...

Since I ran into troubles with the neural net stuff, I started looking for other solutions. One of those ideas was an embedded interpreter, and I wanted to see what was out there. CINT appears to be robust, and is very well documented.

My idea, then, was that by using the plugin code in conjunction with an interpreter, you can modify plugin related stuff on the fly, essentially using c/c++ inside your script, which in turn opens up all sorts of c/c++ software to a seemingly simple interface with AutoIt. The benefit would be runtime modification of plugin related code, so that data manipulation (arrays and the like) could be written in C code and passed directly to the plugin.

It would be naive/blind automation, except where you had specific interfaces defined between AutoIt and the plugin code, but essentially, you would bypass the whole issue of the AutoIt variant and c datatype incompatibility.

Since CINT can also use compiled objects, you can conceivably call existing C code from within AutoIt that uses compiled code, bypassing the whole freaking mess of dllCalls and dllStruct manipulation that make it so hard for novices and intermediate level folks like myself to do neat stuff with AutoIt.

That's why I'm excited

Edited February 19, 2009 by JRowe

[James]

I think this would be a good idea. I have looked at Ch before and it is very good.

[SmOke_N]

Why ridiculous? I was just asking if anyone has used a c/c++ interpreter in AutoIt before. The answer appears to be no, since there's little reference on the forums to anything like that happening...

Since I ran into troubles with the neural net stuff, I started looking for other solutions. One of those ideas was an embedded interpreter, and I wanted to see what was out there. CINT appears to be robust, and is very well documented.

My idea, then, was that by using the plugin code in conjunction with an interpreter, you can modify plugin related stuff on the fly, essentially using c/c++ inside your script, which in turn opens up all sorts of c/c++ software to a seemingly simple interface with AutoIt. The benefit would be runtime modification of plugin related code, so that data manipulation (arrays and the like) could be written in C code and passed directly to the plugin.

It would be naive/blind automation, except where you had specific interfaces defined between AutoIt and the plugin code, but essentially, you would bypass the whole issue of the AutoIt variant and c datatype incompatibility.

Since CINT can also use compiled objects, you can conceivably call existing C code from within AutoIt that uses compiled code, bypassing the whole freaking mess of dllCalls and dllStruct manipulation that make it so hard for novices and intermediate level folks like myself to do neat stuff with AutoIt.

That's why I'm excited

Ha@

bypassing the whole freaking mess of dllCalls and dllStruct manipulation that make it so hard for novices and intermediate level folks like myself to do neat stuff with AutoIt.

It's always something small (large to them) that suits a specific users needs that makes something exciting.

My suggestion simply being, write a wrapper on some other core language that does all the struct work for you ... then you can make "simple" dll calls for your needs.

Edited February 19, 2009 by SmOke_N

[jvanegmond]

JRowe, sometimes you have to look at a languages strong points and weak points. In your case, you say AutoIt is not powerful enough for what you want. Maybe you can use another language and use AutoItX to call anything Autoit specific.

[Valik]

I would be really surprised if embedding a language inside a program didn't involve explicitly integrating support into the language by compiling in the stubs or wrappers required. In short, it's unlikely you can embed another language in AutoIt unless you can do so entirely through DllCall(). But then, that wouldn't really be an embedded language since embedded implies it is "inside" the host.

[James]

I would be really surprised if embedding a language inside a program didn't involve explicitly integrating support into the language by compiling in the stubs or wrappers required. In short, it's unlikely you can embed another language in AutoIt unless you can do so entirely through DllCall(). But then, that wouldn't really be an embedded language since embedded implies it is "inside" the host.

That sounds fair and valid to me. It's just stupid to go back now.