[DGD] happycode in DGD

[Raymond Jennings]

On Fri, Sep 6, 2013 at 5:12 PM, <bart at wotf.org> wrote:

> 2 comments at first glance:
>
> On Fri, 6 Sep 2013 16:55:49 -0700, Raymond Jennings wrote
> > thanks to an enlightening chitchat with aidil, I think I have a basic
> > gameplan for implmeenting happycode in DGD
> >
> > First off, each happycode snippet is compiled on the spot along with
> > the rest of the source code it is with.
> >
> > Second, happycode snippets are split off into their own heavyweight
> objects
> > after being morphed into bytecode for the vm.
> >
> > Third, code in the defining object that emits function pointers is tagged
> > with a reference to the happycode object in question.
> >
> > Fourth, function pointers use that tag to know which happycode
> > object to execute when they are referenced.
> >
> > Fifth, happycode objects are garbage collected similiarly to kfuns, and
> > automatically nuked when they are proven to be orphaned.
> >
> > Sixth, destructing a  source object also nils out any happycode objects
> > built from it.
> >
> > Seventh, it is an error to recompile an object in such a way that
> happycode
> > objects refering to it lose track of variables.  So if you have happycode
> > refering to object scope variables, you can't remove those vars in
> > the new program.
>
> How do you intend to enforce this beyond saying "don't do that" ?
>

A control block with outstanding happycode objects will require checking
against every associated happycode object before a variable removal is
permitted.  I'll probably be checking the varmap.  It's a similiar process
to upgrading clones after a master is recompile din place.

If I detect any variables vanishing that a happycode blob depends on, the
compilation is aborted.

> Eighth, new happycode objects are generated as needed each time a source
> > object is recompiled.  I decided to avoid the entire conhjflict between
> > closures and recompiling by "freezing" the bytecode inside the happycode
> > object when it's compiled.  So happycode never recompiles.  I tjust
> floats
> > until it becomes unreferenced.
>
> How to provide access to inherited code, and ensure the sniplet does get
> recompiled (based on the same lpc code it had when it was initially
> compiled)
> when those inherits get recompiled? Not doing so will result in old
> versions
> of this inherited code staying around until all objects referencing it
> will be
> gone.
>

Similiarly, by checking the new control block and making sure that no
functions disappear that are needed by the happycode objects.  Local
function calls remain, and continue to point to whatever functions replace
the ones that they referred to.  Kinda like undefined function resolution
during runtime.  In fact, if I treat it as a call to an undefined function,
I might not even need to check this during recompile.  It might be a good
debug tool though.

Also, happycode snippets are NEVER recompiled, ever.  When I recompile a
master object, I generate brand new happycode objects, and leave the old
ones behind for outstanding fp's to point to.

Of course, everything would be much simpler if happycode blocked recompiles
outright, but then where's the advantage in porting to dgd?

Bart.
>
> --
> http://www.flickr.com/photos/mrobjective/
> http://www.om-d.org/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>