You are not logged in.
going to probe some of you for some information:
I'm looking for some code snippets to load, into a c program, another language module, and execute a function by name...
any language will do, I'm just looking for a point of reference...
if possible, and you know how, I'd like to know how to convert a simple native type in the language, to a C struct...
i'll make up a language to demonstrate what I'm looking for:
# !/usr/bin/env phrak
#phrak-script
string hello_whirled()
{
string s = "hello";
return s + " whirled";
}
#include <phrak-script.h>
...
phrakscript_init();
phrakscript* s = phrak_script_load("test.phrak");
phrakscript_obj* o = s->get_symbol("hello_whirled");
if(o->is_callable())
std::cout << o->call().to_string();
phrakscript_free_obj(o);
phrakscript_free(s);
...
Offline
You're writing a freaking scripting language now? what happened to the window manager????
http://docs.python.org/api/intro.html
Have a look at that yet?
I can tell you exactly how to embed groovy into java.... :-D
Dusty
Offline
no, the scripting language was a demo... I'm not writing one...
Right now I'm going to work on an indepth module framework... the core of the WM is pretty easy, if I have it conceptualized correctly... it's not hard to make a C/C++ only module framework, but I'd like to understand how one accesses external languages so I can design it properly...
right now, I'm torn between the following styles of "linking" modules to the core:
apache style: precisely named C structures which contain function pointers
xchat style: precisely named functions, loaded individually
misc ideas: one single "switch" type function which calls the appropriate module function (??)
basically, before I finalize the "glue", I'd like to know if that glue is extensible...
Offline
It depends on the design of the wm which style is best. If you have a lot functions, then apache style is best. If you only have a few, you can as wel use dlsym(). The misc idea is of a different kind than the other two, as it only tells something about the function and nothing about how the functions are found. It's a way to get in a big mess if you don't look out, so watch out with it.
Server client style:
The X way: through local sockets.
Some other IPC like message queues or whatever.
Fork + exec and pipes.
Anyway, I wouldn't add support for other languages directly, but let a language specific wrapper plugin handle it (though if you use the last of the above styles then the core doesn't care about the client format, as long as it runs).
Offline
yeah, I debated using IPC mechanisms for a while but decided it added a layer I didn't really want... however, the more I think about incorporating in other languages, the more ipc tends to appeal (for instance, using some basic IPC, I can even create modules in bash)
Pros and cons of going with formatted fifo ipc? not really sure atm.
Using a messaging mechanism wouldn't work in the way that I would like it to....
I believe I'm close to something which will allow for loadable python modules... and perhaps perl could work too, given enough research...
Offline