[Vala] Fwd: Vala - generates code at runtime

[Fredderic Unpenstein <magentus gmail com>]

On 10 February 2010 09:29, jideel <jideel free fr> wrote:
> Thanks for your response.
> You're probably right, perhaps it's not the right tool.

Sounds to me like you might be able to get away with just a few key
functions in a scripting language, and keep the rest static.

A vala object that wraps a TCL interpreter for example, should be
pretty simple. Then leave all the heavy lifting to Vala, a database or
two, etc.

Python I think will let you save the bytecompiled code, not sure about
Perl or Ruby or what-not.  But they can also get a little hairy around
the embedding API, Python especially if I recall correctly...

But something simple like TCL, used to implement just a few specific
method of an otherwise generic object, might be all you need.  Cache
the objects after they've been used, to try and re-use the byte
compiled function definitions, and should be pretty sweet.


If you DO want to go compiled code for speed, you could try sticking
to straight C.  That compiles pretty darned fast, especially when it's
not needing to pull in loads of libraries and what-not, and again,
wrap it in a generic Vala object that provides the main functionality.
 The web interface can give the impression of object orientated
programming by providing a template into which you plug your function
definitions.  Doesn't mean they have to actually end up as compiled
objects.

I used to play a text-based MUD back in the old days, where every
room, item, monster, etc., were all small C programs using a core
library.  The owner of an object could submit updated code, which was
put through an automated sanitiser, and if it passed, compiled and
stored in an object storage directory. Next time anything requested
that object the system would execute it, with the core library acting
as a remote procedure call mechanism over the standard IO.  When the
last active instance of the object vanished (no one in any room it's
in, or not being carried by anyone presently active in the game), the
executable was told to exit, and all that was left was the binary file
in the object store.  (The source code was kept in a separate public
library...)


> From what I remember of GModule, there's two main problems.  1) the
GType system doesn't like unloading stuff; once a type is defined, it
tends to stay defined.  Various strings and things get added to a
static storage space and can't be free'd, and stuff like that.  So
unloadable modules need to be wrapped, taking care that none of the
unloadable parts will ever find their way into persistant corners of
the object system.  2) I'm not entirely sure that module unloading is
even entirely portable to begin with, in which case they've provided
the mechanism to support it, but no implementation since there isn't a
generally reliable one available.

But again, all that becomes mute when you're only defining a few
methods and wrapping them in a generic object.  Only the generic parts
will find their way into persistant storage spaces, and and once the
instance of the object is free'd, the library implementing its
specialised methods can be unloaded fairly easily.


Fredderic