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

[Roland Plüss]

> On 10/28/2009 09:20 PM, Roland Plüss wrote:
>> What exactly does #open do? Assuming I use a c function as #open in the
>> base class do I then get this function called whenever there is a
>> run-time problem?
>
> It is #open: actually.  The function will be passed an error message
> and it can print it + invoke gst_show_backtrace.  However, the
> function should also terminate the active process, so it's better if
> you write it in Smalltalk.
>
> A better choice is that you write in C a "print"-like function, and
> then do
>
>     TextCollector extend [
>         primWrite: aString [
>             <cCall: 'roland_write_string' returning: #void args:
>                    #(#string)>
>         ]
>     ]
>
>     Eval [
>         Transcript message: Transcript -> #primWrite:
>     ]
>
> to connect the transcript to your function.
>
> Then you do not need a #debuggerClass at all, because you can use the
> default implementation of UnhandledException.  You also get more
> flexibility, for example backtraces will include file names and line
> numbers instead of bytecode indices (much better!)
This sounds tricky. The problem is that in my engine scripting is done
as a module and crash recovery too. Hence if the scripting messes up
something it has to throw an engine exception ( a c++ class ) which is
then handled by the crash recovery module which in turn decides if it
can recover and continue or bail out gracefully. This especially means
that the scripting module has to write debugging information to an
exception trace object ( again a c++ class ). A console is not always
available ( see *cough*crap-windows*cough* ). That's making things a bit
difficult.

Now it might work out if I could write a backtrace directly to the
exception trace object. This means though that I have to handle the
error itself not the text that is print out. How safe is it by the way
to throw a c++ exception from a ccall? Is this going to mess GST up?
They way I use the scripts the engine always sends event messages to the
game scripts which are handled in a short time. Hence these are various
calls to gst_nvmsg_send. Would it be not better to catch the error at
this point so a c++ exception can be safely thrown? What I have in mind
is using a message which could be called from the error handling method
which populates the exception trace with informations and sets a flag
that an error happened. This way after gst_nvmsg_send returns I can
thrown an exception safely. Would this be better from the point of view
of GST than trying to thrown an exception from a ccall?

-- 
Yours sincerely
Plüss Roland

Leader and Head Programmer
- Game: Epsylon ( http://epsylon.rptd.ch/ ,
http://www.moddb.com/games/4057/epsylon )
- Game Engine: Drag(en)gine ( http://dragengine.rptd.ch ,
http://www.moddb.com/engines/9/dragengine )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php )

signature.asc
Description: OpenPGP digital signature