On 11/02/2011, at 8:06 PM, Emmanuel Onzon wrote:
> BTW: using StackOverflow the reason for Marshal failure of Felix automaton
> now seems to be that OCS Scheme contains un-Marshalable WeakArray... ;(
>
> Ok,
> I'm guessing a version of the parsing_device that doesn't contain any user
> action would be marshalable. One can imagine marshaling the parsing_device
> without the user actions. After loading it, it would be necessary to attach
> the user actions to it. For instance Felix could resubmit all the couples
> (rule, user action), then dypgen wouldn't have to build the automaton but
> would use the couples to attach the user actions to the parsing device.
> To do this you would need dypgen to return the current parsing_device without
> the user actions and a function that would attach the user actions to the
> parsing_device.
> What do you think about this?
Something like that may be necessary, however it isn't clear it should be done
by Dypgen.
Consider that the user action is rewritten something like this:
{ (Hashtbl.find myhash index) () }
Then the user action is again Marhsal'able, and the onus is on the application
to
load and save the table of action functions.
My problem remains: how to save compiled Scheme code. Possible the answer is:
save it uncompiled and compile (once) on loading.
Since my user actions are machine generated, generating a unique index etc
isn't a problem.
in fact, all the Scheme actions are already saved "uncompiled", as part of the
grammar, its just that loading them not only compiles them, it also builds
the automaton.
So my *guess* at the moment is that you shouldn't have to modify Dypgen
to support this, and even if you did, it wouldn't save much. In fact, it might
actually get in the way. For example with the Hashtable there is no
ordering constraint: I could load the automaton THEN compiler the scheme,
or, I could compile the scheme, THEN load the automaton.
Whereas if Dypgen tries to maintain the map, it might force the order,
if for example you chose to use a Map or a functional data structure
rather than an imperative one.
My big problem is that there's a fair amount of work to implement this,
and it may not save any time :)
Unfortunately .. this is a "suck it and see" experiment, both on finding out
how hard it is to do, if there are any problems which suggest Dypgen HAS
to do it, and finally if it was worth the effort.
Bottom line: I think you shouldn't do it at this stage, unless someone else
also needs it.
The really big plus would be if the save could be done without
any closures, because that would make the saved data portable
between many tools that happens to all analyse the same language.
--
john skaller
skal...@users.sourceforge.net
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
