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?
> 
> Jesse

Sorry for the no subject... I hope this is better

Jesse