[DGD] happycode in DGD

[Raymond Jennings]

So basically, happycode objects are like parsers and user objects, marked
as special.  They have handles both to the object they are tied to and the
master object providing their code.




On Fri, Sep 6, 2013 at 5:34 PM, Raymond Jennings <shentino at gmail.com> wrote:

> 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
>>
>
>