[DGD] Minor issue

[bart at wotf.org]

I'd argue that in cases like this, modifying the kernel library is a better
approach then modifying DGD. In fact, being able to modify such behavior in
LPC is imo one of the strengths of DGD.

Bart.

On Fri, 3 Feb 2017 22:24:27 -0600, Blain wrote
> The end goal would be to allow this without using the TLS at all:
> 
> some object:   auto->clone_object(file/obj, owner, args...)
> auto:   DGD->::clone_object(obj, args...)
> DGD:   auto->_F_create(args...)
> auto:   clone->call_other(clone, CREATOR, args...)
> 
> (and ditto for new_object)
> 
> In destruct_object, I call DESTRUCTOR with args..., but DGD doesn't 
> need to get involved with that part.
> 
> On Fri, Feb 3, 2017 at 10:18 PM, Blain <blain20 at gmail.com> wrote:
> 
> > Then maybe DGD could be made to accept additional args to clone_object()
> > and new_object()?  I've solved it for now by changing TLSVAR(0)
> > [effectively -1] to be an array of arrays, pushing and popping in
> > clone_object/new_object and _F_create, respectively.  But, like I said, I
> > hate modifying the kernel.  It's one of my goals to create a mudlib which
> > doesn't require kernel modification.  So far I've had to make a number of
> > minor changes, but I think this is one of the larger ones to date.
> >
> > I had to modify the TLSVAR(0) read/write calls in auto.c in clone_object,
> > new_object, destruct_object, _F_create (I added code to read the array and
> > push it to the constructor.  I'm having to take a leap of faith that var 0
> > isn't modified between clone_object/new_object and _F_create.  For
> > destruct_object I don't have to worry as I'm using it within the same
> > function.
> >
> > On Feb 3, 2017 6:38 PM, "Raymond Jennings" <shentino at gmail.com> wrote:
> >
> >> Also, just so you know
> >>
> >> DGD itself does not support TLS, only access via call_trace() to writable
> >> arrays that the kernel library just happens to have set up properly so
> >> that
> >> it can create the TLS api itself.
> >>
> >> On Fri, Feb 3, 2017 at 4:28 PM, Raymond Jennings <shentino at gmail.com>
> >> wrote:
> >>
> >> > At what exact abstraction/api level are you trying to access the TLS
> >> api?
> >> >
> >> > The baseline version is stored on the call stack, but the version
> >> > presented by the klib itself is different
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, Feb 3, 2017 at 3:08 PM, Blain <blain20 at gmail.com> wrote:
> >> >
> >> >> I'm having a minor issue with passing extra args to a newly-cloned
> >> object
> >> >> if another object is cloned during the process.  I'm using LWO's for
> >> >> object
> >> >> tracking, and the call to new_object() is overwriting TLSVAR(0) which
> >> >> clone_object() set.  I am trying but to modify the kernel too much, but
> >> >> will have to to fix this.  I was wondering if maybe DGD could be
> >> changed
> >> >> grab the args from TLS (or Auto could pass them along with
> >> >> ::clone_object()) and then pass them to _F_create().
> >> >>
> >> >> -Blain
> >> >> ____________________________________________
> >> >> https://mail.dworkin.nl/mailman/listinfo/dgd
> >> >
> >> >
> >> >
> >> ____________________________________________
> >> https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/