2011/2/11 Christophe Raffalli <christophe.raffa...@univ-savoie.fr>
> Le 11/02/2011 10:06, Emmanuel Onzon a écrit :
> > 2011/2/2 john skaller <skal...@users.sourceforge.net <mailto:
> skal...@users.sourceforge.net>>
> >
> >
> > On 03/02/2011, at 12:45 AM, Emmanuel Onzon wrote:
> >
> > > Hello,
> > > here are the changes:
> > >
> >
> >
> > 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?
>
> All action for a given non-terminal have the same type ?
>
>
All actions, regardless of the non terminal, have the same type. They are
stored in an array and a liste of couples (rule, action).
Each rule of the grammar is identified by an integer.
The index of the array storing the user action is the integer identifying
the corresponding grammar rule.
> So you can replace the action by a number and create a table per non
> terminal storing all actions.
> If the assertion about type is false, the Obj module is needed ...
>
>
I tried to use the module Obj of the standard library to avoid having all
the constructors of the type obj of dypgen library but I gave up because it
was too difficult to debug. So I prefer to avoid the magic of Obj.
> I think this is also comptabible with the creation of new non terminal.
>
> This would solve automatically the problem. May be this could be an option
> of dypgen, because it may
> slow down parsing for very simple action code.
>
> The only thing is to make sure that action are always numbered in the same
> way, so it impose a few
> more constraints that just "same binary" imposed for marchaling, but it
> should be easy to cope with?
>
>
There is a hashtable that returns the integer identifying each grammar rule.
Therefore if the user gives a list of couple (rule, action) then dypgen can
find where to store each action in the array.
> But a big advantage is that if action uses references or other muatable
> (which is a bad idea, but is
> possible), then these mutable are not marshaled.
>
> Hope this helps,
> Christophe
>
> >
> > Emmanuel
>
> --
> Christophe Raffalli
> Universite de Savoie
> Batiment Le Chablais, bureau 21
> 73376 Le Bourget-du-Lac Cedex
>
> tel: (33) 4 79 75 81 03
> fax: (33) 4 79 75 87 42
> mail: christophe.raffa...@univ-savoie.fr
> www: http://www.lama.univ-savoie.fr/~RAFFALLI
> ---------------------------------------------
> IMPORTANT: this mail is signed using PGP/MIME
> At least Enigmail/Mozilla, mutt or evolution
> can check this signature. The public key is
> stored on www.keyserver.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
