Re: [Help-smalltalk] Using Smalltalk as a scripting language

[Paolo Bonzini]

> > > If not what is the preferred way to handle
> > > errors? hijacking #doesNotUnderstand in the Object class ( including
> > > #halt and company )?
> >
> > Hijacking SystemExceptions.UnhandledException>>#defaultAction sounds
> > better.
> >
> > Even better would be to define #debuggerClass in the superclasses that
> > your scripts are supposed to subclass.  The #debuggerClass will be
> > sent the class method #open:.
>
> What kind of class is #debuggerClass supposed to return? Of course I
> could simply make a class with only #open but I'd like to use the proper
> superclass for this situation to avoid breaking potential future gst
> versions.

Yes, any class with #open: will do.

> How is this class registered. Meaning how does gst know about the new
> class? It's written there that you define a class in smalltalk as in the
> example. But where is the gluing made between the c struct and the
> appropriate smalltalk class?

You load a file containing the Smalltalk class before the user's files 
(or you create an image after loading that file, which is the same).

> How do I register a method in a class which
> is a c function?

On the C side you use defineCFunc, on the Smalltalk side (in the same 
file as above) you use <cCall: 'foo' ...> as described in the manual.

Each binding has two sides, a C side and a Smalltalk side.  A simple one 
is the MD5/SHA1 binding in packages/digest.

Regarding your other message:

> Something seems wrong. I tried this out and it fails. I have the following:
>
>     pClsGame = gst_perform_with( orderedSubclasses, gst_symbol_to_oop(
> "at" ), gst_int_to_oop( 1 ) );
>     printf( "[ST] cg=%p nil=%p\n", pClsGame, gst_interpreter_proxy.nilOOP );
>     if( pClsGame == gst_interpreter_proxy.nilOOP ) ...
>
> I made a type and wrote "at" instead of "at:" which triggered the
> problem. The return value is when I gst_perform "printNl" on it "nil".

This is wrong indeed, you found a bug in GNU Smalltalk. :-(

I suggest that you base your application on the master branch of the GNU 
Smalltalk git repository, where I have fixed the bug.  The next release 
will be out soon, so it is stable and has new features, some of them 
useful for bindings.  If you prefer, I can backport to 3.0 or 3.1 though.

Paolo