Using Smalltalk as a scripting language
Locked
12
12
Using Smalltalk as a scripting language
 
|
( new to this list, so hello )
I would like to provide a Smalltalk scripting module for my game engine just because I can ( and smalltalk is awesome :P ). Now I tried looking at the docs to figure out how to get smalltalk into my app. So far what I managed is the following: gst_set_var( GST_VERBOSITY, 1 ); //gst_smalltalk_args (argc - 1, argv + 1); // we have none //gst_set_executable_path( dataDir ); // undefined in gstpub.h ?! if( gst_initialize( NULL, NULL, GST_NO_TTY ) != 0 ){ printf( "[ST] gst_initialize failed.\n" ); return false; } So far this seems to work. I get 0 as a result so I assume the VM is up and running. Why the gst_set_executable_path does not exist in gstpub.h I don't know. Now in the manual ( http://www.gnu.org/software/smalltalk/manual/html_node/Using-Smalltalk.html#Using-Smalltalk ) it is written to omit |gst_process_file. Now what I want is two fold. First I want to expose engine classes ( c++ classes ) to smalltalk. As far as I get from the docs this should be possible although I'm not fully getting it yet. Second is that I want to load various script files containing smalltalk code and classes into the VM. How am I supposed to do this? ||gst_process_file seems to be a blocking call if afterwards in the manual the exit code is called. In general my init looks like this ( pseudo-code ): load engine scripts load game scripts call initGame and store return value as game object from that time on I operate on the game object sending all kinds of messages. What goes for calling the initGame method I think I figured out from the docs how this is supposed to be done but what goes for loading the script files and parsing them I'm still at a loss. Side question: Is there somewhere an API documentation? I'm not so fond of messing with function calls if I don't know what I can feed them as input ( docs seem rather scarce to me ). Thanks in advance. |||-- 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 ) _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
signature.asc (269 bytes)
Re: Using Smalltalk as a scripting language
|
|
Re: Using Smalltalk as a scripting language
|
|
On 10/26/2009 08:10 PM, Roland Plüss wrote:
>> Why the gst_set_executable_path does not exist in gstpub.h >> I don't know. > > Just an old version of GST. It's 3.0.5 , that should not be too old shouldn't it? >> Now in the manual ( >> http://www.gnu.org/software/smalltalk/manual/html_node/Using-Smalltalk.html#Using-Smalltalk >> >> ) it is written to omit |gst_process_file. Now what I want is two fold. >> First I want to expose engine classes ( c++ classes ) to smalltalk. As >> far as I get from the docs this should be possible although I'm not >> fully getting it yet. > > This is the same as creating bindings for a library such as SQLite or > GTK+ or NCurses. There are several examples of varying complexity in > the GNU Smalltalk distribution. >> from that time on I operate on the game object sending all kinds of >> messages. What goes for calling the initGame method I think I figured >> out from the docs how this is supposed to be done but what goes for >> loading the script files and parsing them I'm still at a loss. > > _gst_process_file works. If the file is just a bunch of class and > method definition, it won't block. > > If the main program is written in Smalltalk, you actually want to make > it blocking though. game loop run inside the game engine (c++) which then occasionally sends messages to the game object ( which in turn is an instance of some game base class provided to the developer ). So if I get you correctly then I can simply call _gst_process_file for any single script file without getting a block. Is there a way to prevent this function call from ever blocking? Like for example the developer messes up and produces code which would block, can I prevent this from happening so he doesn't kill himself? >> Side question: Is there somewhere an API documentation? I'm not so fond >> of messing with function calls if I don't know what I can feed them as >> input ( docs seem rather scarce to me ). > > You can feed everything you want, you may get a #doesNotUnderstand: if > you screw up. I guess I posed the wrong question. I talk about the c functions in the gstpub.h file like for example _gst_process_file and company. I didn't find a man page or anything in the docs which outlines how to use these c functions or which kind of parameter values they know/accept. -- 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 ) _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: Using Smalltalk as a scripting language
|
|
Re: Using Smalltalk as a scripting language
|
|
>> Is there a way to prevent this function call from ever >> blocking? > > No, that's not possible. You could run _gst_process_file in a > separate thread though. When _gst_process_file finishes, the thread > would tell the main thread that it can execute Smalltalk code. Until > _gst_process_file finishes, the main thread could keep executing, but > would not be able to execute Smalltalk code. I tried using that function but even for an empty file it returns a failure code according to the example. I'm a bit stumped on that one without any informations on why the call fails. >> I guess I posed the wrong question. I talk about the c functions in the >> gstpub.h file like for example _gst_process_file and company. I didn't >> find a man page or anything in the docs which outlines how to use these >> c functions or which kind of parameter values they know/accept. > > The functions beginning with _gst_ are not public, only those > beginning with gst_ are (each gst_ function has a private counterpart; > they're exactly the same and are separated just for optimization > purposes). > > Most of these are documented in the info manual. gst_process_file is > an exception (it is documented by an example, but not in the function > reference). not really usable for me since in my engine files can be anything from disk files to memory files or even URL files. Hence I've got a file reader class which feeds the data to the scripts. Is there a way to feed script data to smalltalk using a memory pointer instead of a file? Or do I have to hack this together myself? -- 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 ) _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: Using Smalltalk as a scripting language
|
|
Re: Using Smalltalk as a scripting language
|
|
Re: Using Smalltalk as a scripting language
|
|
>> 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:. superclass for this situation to avoid breaking potential future gst versions. > You can test "x == gst_interpreter_proxy.nilOOP". You can of course > define your own IS_NIL macro. However gst_class_name_to_oop returns > NULL (not nil) if the class is not found; I'll update the docs. That would be nice. In fact would it be possible to use doxygen style documentation? They are very helpful to developers as they contain what is important: function signatures and possible values. I forgot one question. From looking through the docs I get it that to map a c++ class to gst I have to create a struct which is then mapped to smalltalk. Now I'm still trying to wrap my head around how exactly this is supposed to work. I'm assuming http://www.gnu.org/software/smalltalk/manual/html_node/Object-representation.html#Object-representation is the way to handle this. There it is described how to structure this struct and how to get it from an OOP. Now what I don't get are a couple of things. 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? How do I register a method in a class which is a c function? In the docs it is mentioned that you have to use a register function but it seems as far as I get it that it works only for adding a function to the system class ( in an example this is written vmProxy->defineCFunc("Tcl_Eval", Tcl_Eval) which does not seem to define a class OOP in any way ). Is there another function for adding a c function as a smalltalk method to a class or is this the same function with a different signature? ( I'm missing the function signature so I'm a bit at a loss on how it is actually called ). If I can wrap my head around these two things I think I know all it takes to get the show running. -- 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 ) _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: Using Smalltalk as a scripting language
|
|
Re: Using Smalltalk as a scripting language
|
|
>>>> 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. run-time problem? > 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. Not a problem. Fixed it right now by using OOP pObjNil = gst_eval_expr( "nil" ) This should be the same as the interpreter nil. Works with that so far. -- 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 ) _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: Using Smalltalk as a scripting language
|
|
Re: Using Smalltalk as a scripting language
|
|
> 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!) 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 ) _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: Using Smalltalk as a scripting language
|
|
Re: Using Smalltalk as a scripting language
|
|
In reply to this post by Paolo Bonzini-2
>> 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: > want to provide a wrapper to smalltalk for this. To begin with I make it simple and want to make a class DEEngine which only exposes a method #quit which shuts down the engine. This would be a class side method since it's a singleton class. Now I have to register a c function using gst_define_cfunc( "stClassEngine.ccQuit", ccQuit ) where ccQuit is defined as static void ccQuit( OOP self ) inside the stClassEngine class. I put OOP self there since did not see any way for the c function to know otherwise which object received the message. Now how to I attach personal data to a smalltalk object? So if I define the class DEEngine in smalltalk script and this script is parsed the VM is going to create an instance of this class. But this class has no knowledge about the pointer to the game engine but calling ccQuit requires the engine pointer to be present. I had a similar problem when I messed with Python and there I had to make a singleton keeping all the pointers so I can access it. That's not really object oriented programming at all. Is there a way in smalltalk to defined sort of private memory space inside an object so I can put custom data into it or do I have to make the same mess as in Python? To my understanding I can access smalltalk code using the trick written on http://www.gnu.org/software/smalltalk/manual/html_node/Object-representation.html#Object-representation .That though only allows access to object data the way smalltalk allocates it. If there would be a way to attach some sort of unused data after the smalltalk internal data I could force my stuff into a smalltalk object. Any way to pull that off? -- 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 ) _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: Using Smalltalk as a scripting language
|
|
Re: Using Smalltalk as a scripting language
|
|
>> Now how to I attach personal data to a smalltalk object? > > You derive your class from CObject, or alternatively you embed a > CObject in one of the instance variables. A CObject can point to > arbitrary malloced data. Read about CObject in the docs. As far as I get you can mess with the pointer from smalltalk code. But that's not what I want. I use memory not as pointer but as live objects ( for example casting the memory to a vector or matrix class ). So can I fully hide the allocated data from smalltalk? I just want it to be accessible only through cCall functions. By the way, thanks for the help. I'm nearly at the point where it works. I just need to crack the user allocated data and error handling problem and them I'm ready to rock ^.=.^ -- 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 ) _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: Using Smalltalk as a scripting language
|
|
Re: Using Smalltalk as a scripting language
|
|
>> As far as I get you can mess with the >> pointer from smalltalk code. > > Then do the same that CObject does, but manually. Make your class > <shape: #byte> and create it with sizeof(void *) indexed instance > variables (with gst_object_alloc). At the end of the struct you can > place a "void *opaque" data and set it after the call to > gst_object_alloc. When I get this correctly then this would be in fact gst_object_alloc( oopClass, numberOfCOnlyBytes ); where numberOfCOnlyBytes is the number of bytes I append to the struct which is not accessible to smalltalk. So far so right? So I assume if I want to use this approach I have to provide a cCall for #new which creates the object using the prior mentioned gst_object_alloc bypassing the smalltalk creation call. Sounds like quite the hack but it looks like it could work out. -- 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 ) _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: Using Smalltalk as a scripting language
|
|
Re: Using Smalltalk as a scripting language
|
|
>> When I get this correctly then this would be in fact gst_object_alloc( >> oopClass, numberOfCOnlyBytes ); where numberOfCOnlyBytes is the number >> of bytes I append to the struct which is not accessible to smalltalk. So >> far so right? > > Yes, right. numberOfCOnlyBytes can actually be just sizeof (void *) > with the C data stored "on the side". You choose (remember that if > you place data in the Smalltalk object you have to deal with the GC > moving the objects). What exactly you mean with "moving"? I'm not referencing to data inside the custom data area using pointers. Most of the time I simply store there a pointer to the wrapped engine object. Sometimes it's two pointers ( required if a non-ref-counted object is stored which is located inside a ref-counted object so I store two pointers one with ref-counting to guard the second non-ref-counted one ). So as long as the data is just copied nothing bad should happen. >> So I assume if I want to use this approach I have to >> provide a cCall for #new which creates the object using the prior >> mentioned gst_object_alloc bypassing the smalltalk creation call. Sounds >> like quite the hack but it looks like it could work out. > > Doesn't seem to bad. Most likely you'd have a cCall for #initialize > anyway. Having one for #new instead does not change much. > To my understanding ( from past smalltalk lectures at university where we worked with Squeak ) #new is responsible for allocating an object while #initialize or #init is responsible for setting up default values for the newly created instance. Therefore I proposed #new. Unless that is in GST this rule is slightly different. -- 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 ) _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
| Free forum by Nabble | Edit this page |