I'm working on a small scripting support for a C application I wrote.
The idea is to let users execute script functions they define and
register. To control things in the main application there are two
classes defined with some methods (all in C). Actually it works, I scan
the scripts directory for scripts, load them into ruby with rb_require
and call register_functions for that file. The register_functions will
call a global defined function register_function (which is defined in C)
to register a method.
Now having done this, when the user wants to execute a certain script
function I rb_require the appropriate script file and call the function.
This works for now, but there are things I'm doing wrong.
For instance. Its not nessescary for ruby to stay alive after a script
is executed. I'm willing to create a Ruby 'world' every time a script
has to run because scripts are just add-on, small and non time
consuming. Now I call ruby_init every time a script needs to be executed
and ruby_finalize after it executes. Problem is that ruby doesn't get
cleaned. All code stays and I rather would not have this. I could try to
fork the process and call ruby from within the child but I don't know
what will happen with the callback functions for the two classes I
created in C. Am I thinking in the wrong direction here or should there
be something like ruby_clear?
The second problem is that it works now. It actually does, but I guess
it isn't the best way to do things. Well thats not the problem, the
problem is that whenever I call puts or print to write something to
stdout my application crashes (SEGVT) on rb_func_undef_alloc (or
something like that). Could this be caused by using threads?
On Wed, 2004-07-14 at 14:33, Jesse van den Kieboom wrote:
Hi,
I'm working on a small scripting support for a C application I wrote.
The idea is to let users execute script functions they define and
register. To control things in the main application there are two
classes defined with some methods (all in C). Actually it works, I scan
the scripts directory for scripts, load them into ruby with rb_require
and call register_functions for that file. The register_functions will
call a global defined function register_function (which is defined in C)
to register a method.
Now having done this, when the user wants to execute a certain script
function I rb_require the appropriate script file and call the function.
This works for now, but there are things I'm doing wrong.
For instance. Its not nessescary for ruby to stay alive after a script
is executed. I'm willing to create a Ruby 'world' every time a script
has to run because scripts are just add-on, small and non time
consuming. Now I call ruby_init every time a script needs to be executed
and ruby_finalize after it executes. Problem is that ruby doesn't get
cleaned. All code stays and I rather would not have this. I could try to
fork the process and call ruby from within the child but I don't know
what will happen with the callback functions for the two classes I
created in C. Am I thinking in the wrong direction here or should there
be something like ruby_clear?
The second problem is that it works now. It actually does, but I guess
it isn't the best way to do things. Well thats not the problem, the
problem is that whenever I call puts or print to write something to
stdout my application crashes (SEGVT) on rb_func_undef_alloc (or
something like that). Could this be caused by using threads?
and ruby_finalize after it executes. Problem is that ruby doesn't get
cleaned. All code stays and I rather would not have this. I could try to
fork the process and call ruby from within the child but I don't know
what will happen with the callback functions for the two classes I
created in C. Am I thinking in the wrong direction here or should there
be something like ruby_clear?
Why you don't load the script in an anonymous module ?
The second problem is that it works now. It actually does, but I guess
it isn't the best way to do things. Well thats not the problem, the
problem is that whenever I call puts or print to write something to
stdout my application crashes (SEGVT) on rb_func_undef_alloc (or
something like that). Could this be caused by using threads?
> and ruby_finalize after it executes. Problem is that ruby doesn't get
> cleaned. All code stays and I rather would not have this. I could try to
> fork the process and call ruby from within the child but I don't know
> what will happen with the callback functions for the two classes I
> created in C. Am I thinking in the wrong direction here or should there
> be something like ruby_clear?
Why you don't load the script in an anonymous module ?
Hmm, I don't even know what an anonymous module is
> The second problem is that it works now. It actually does, but I guess
> it isn't the best way to do things. Well thats not the problem, the
> problem is that whenever I call puts or print to write something to
> stdout my application crashes (SEGVT) on rb_func_undef_alloc (or
> something like that). Could this be caused by using threads?
Do you ruby threads or system threads ?
System threads. I don't use threading myself but GTK+ (or pango, I'm not
sure) seems to thread.
System threads. I don't use threading myself but GTK+ (or pango, I'm not
sure) seems to thread.
GTK+ and Pango may be compiled with native thread *support*, but they
(and most Glib-based toolkits) are single-threaded event-driven APIs.
If you're having reentrancy problems, you could try recompiling GTK+
(and its dependencies, Glib, ATK, and Pango) with thread support
disabled.
Lennon
···
On Wed, 14 Jul 2004 21:56:22 +0900, Jesse van den Kieboom <troplosti@orcaweb.cjb.net> wrote:
Okay, I understand the idea now. Problem is that I register two global
objects (from within C) in the Ruby environment. The scripts can use
these objects to do things in the main application and if I execute the
scripts in an anonymous module these objects wouldn't be know to the
script right? But maybe I can just load the file instead of requiring
it. The problem then is that when I load a script file it just executes
and I'm not able to just call a function in the script.
> System threads. I don't use threading myself but GTK+ (or pango, I'm not
> sure) seems to thread.
ruby don't really like system threads : try to avoid it if you can
Well, I'll try to get them out then, but I'm not sure this can be done.
I don't think this is an option as I'm developing this for debian and it
uses the debian packages. I looked a bit further and maybe its nog GTK+
or Pango. My guess is it has to do with Gnome (or bonobo). But it seems
to work for now. Maybe I'll look into it later.
Jesse
···
On Wed, 2004-07-14 at 18:45, Lennon Day-Reynolds wrote:
On Wed, 14 Jul 2004 21:56:22 +0900, Jesse van den Kieboom > <troplosti@orcaweb.cjb.net> wrote:
[...]
> > Do you ruby threads or system threads ?
> >
>
> System threads. I don't use threading myself but GTK+ (or pango, I'm not
> sure) seems to thread.
GTK+ and Pango may be compiled with native thread *support*, but they
(and most Glib-based toolkits) are single-threaded event-driven APIs.
If you're having reentrancy problems, you could try recompiling GTK+
(and its dependencies, Glib, ATK, and Pango) with thread support
disabled.
> System threads. I don't use threading myself but GTK+ (or pango, I'm not
> sure) seems to thread.
ruby don't really like system threads : try to avoid it if you can
I'm beginning development of an embedded ruby application,
where I want to run ruby in a separate system thread
(not the main thread), and run an OpenGL renderer (C/C++)
in the main thread.
However I plan to never have the main thread call the ruby
interpreter directly, or vice-versa. The ruby thread and
the renderer thread will communicate via a command queue
data structure, with appropriate access synchronization.
And data owned by the ruby garbage collector will never
be seen by other threads.
What I'm wondering is, does this sound like a fairly trouble-
free approach? Or am I still stepping into dangerous
territory here? I'm hoping that by keeping the ruby thread
completely separate from the other thread(s) (except for
communication through the queueing mechanism) that I should
be safe from thread-related issues with the ruby interpreter.
However, if what I'm attempting is already known to be
fraught with problems, I'd definitely like to know!
script right? But maybe I can just load the file instead of requiring
it. The problem then is that when I load a script file it just executes
and I'm not able to just call a function in the script.
The problem is not that you _can_ load the file, you *must* load it
because ruby lost all definitions after the load
Isolating the Ruby runtime in a single thread should protect most of
the runtime's internal data structures from synchronization problems,
but I don't think that the core is implemented with an eye towards
cooperating with other threads on things like signals.
If you're only allowing access to the Ruby runtime from a single
thread anyway, you might be better off just forking a child process
that handles the Ruby scripting, and having the two communicate via
some sort of RPC.
The problem is not that you _can_ load the file, you *must* load it
because ruby lost all definitions after the load
Okay, I might get it know. So if I'm understanding this all well then
after each load all previous memory, definitions, classes, all of it is
lost and I can begin clean? This is indeed just what I need.
The problem I have know is that I used to call this from C to let the
script register its functions:
This worked okay when I rb_required the file. But now that I'm using
rb_load_file this fails. I suppose the register_functions from the
loaded file is not sitting in the rb_mKernel module than?:
[15:43:15] # script_register_functions: registering functions in
/home/jesse/.gnome2/gnoemoe/scripts/run.rb
[15:43:15] # script_error: Error while executing Ruby code: undefined
method `register_functions' for Kernel:Module
[15:43:15] # script_error: Ruby backtrace:
[15:43:15] # script_error: from
/home/jesse/.gnome2/gnoemoe/scripts/run.rb:39
What should I specify for 'module' in the rb_funcall?
I like Paul's follow up: "Give ruby a try, but don't expect it to
solve all your problems. It will not make breakfast for you in bed or
greet you with a kiss."
···
On Wed, 14 Jul 2004 22:30:07 +0900, CT <demerzel@gmail.com> wrote:
This worked okay when I rb_required the file. But now that I'm using
rb_load_file this fails. I suppose the register_functions from the
loaded file is not sitting in the rb_mKernel module than?:
The loaded file need to call the register_functions, i.e. rather than
define a register_function the file must call any method that it want
What should I specify for 'module' in the rb_funcall?
You can't specify a module : the module don't exist after the load this is
why ruby lost the definitions.
I like Paul's follow up: "Give ruby a try, but don't expect it to
solve all your problems. It will not make breakfast for you in bed or
greet you with a kiss."
The loaded file need to call the register_functions, i.e. rather than
define a register_function the file must call any method that it want
Now I'm really confused. I can't call any functions that sit in the
loaded file. I can't define functions from within C that the ruby script
I load can call. What CAN I do then. I need to let my C application know
what methods there are. Every method registered is a little script. And
I need to execute these methods from my C application.
You can't specify a module : the module don't exist after the load this is
why ruby lost the definitions.
And this is exactly the kind of thing that makes non-coders think
we're all in love with our computers...which many of us may be, but
it's probably best to keep the evidence out of the wrong hands, (i.e.,
wives, girlfriends, etc.) though.
