Ok, I have now written the first cut of the decoders.
There's more to do but here's a taste.
The type of a decoder function is:
size_t decoder (void *target, char const *source, size_t offset)
This function decodes data from the array source starting at offset,
and puts it into target. It then returns the new offset for the next thing
to decode.
For a pod, the decoder called just does a memcpy.
For a string, we first memcpy sizeof(size_t) bytes into a size_t variable,
and use that value to grab more bytes which we convert to a string
at the target:
new (p) string (source + sizeof(size_t)+offset, n)
At level 1, you can encode a set of types, provided none of them have pointers
to any of the set (self included), stick the strings in a list, pass it to
another function, which then reconstructs the objects. This should work very
soon.
The list is statically a list of strings. But actually its a heterogenous list,
containing arbitrary objects -- and so -- we have dynamic typing.
Note a full object encode (not done yet) will glue the shape object
to the front of the encoded string. The decoder will grab this
and create new store, using the shape object to figure out the length
and associating the store with the shape (and also, the maximum and
used number of slots if it's an array). Then the decoder is called on
the array to initialise the store (typically with memcpy).
At level 2 we can handle pointers as well.
Now: functions. Here's the problem. Most function refer to the
"thread frame" object which contains the "global variables".
In particular, stdin etc, program arguments, and the garbage collector.
So a full pointer closure over a function is going to drag in the
thread frame and everything it points at as well.
We cannot allow the thread frame to be "re-initialised".
So instead, I propose that we just remap the thread frame pointer
in functions to the current thread frame. There's an issue with
system objects (fibres, files, channels etc) as well.
In effect if you want to save functions, they need to have a specially
designed set of state objects, so that they're NOT dependent on
global data being invariant across load/save. Exactly how such functions
will get rescheduled as fibres with channels I do not know at this time.
Probably the game programmer is going to have to write some
code to restart the game.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
