[DGD] FLS

[Blain]

I'd love to see examples of mimicking this behavior with existing
capability.

A stack held in the TLS won't step back with the call stack when a given
frame is deleted.  Old data would persist and become confusing.

Not every frame is invoked with call-other.  Even if they were, using
call_other would require a variable be manually added to every function in
the library.

This idea is not only useful to a this_user/body style stack.  It could be
used in other non-gamr implementations as well.  It's simply frame-based
volatile data dump.  Temporary redirections of output, i.e. piping, might
be done here, for example.

How much overhead would something like this add? If a given implementation
did not utilize it, what kind of unnecessary burden would it impose?  Could
a compile-time toggle flag be useful here?

I think if it did exist already, many people would already be using it.

On Oct 10, 2017 14:18, <bart at wotf.org> wrote:

> On Tue, 10 Oct 2017 11:47:12 -0700, Raymond Jennings wrote
> > I said that already :P
>
> I must have missed that in the longish thread.
>
> >
> > Two geeks agreeing on the idea though is probably a good sign :)
>
> No no, the sky must be falling!
>
> Bart
>
> >
> > On Tue, Oct 10, 2017 at 11:48 AM,  <bart at wotf.org> wrote:
> > > You probably could achieve that from lpc by overriding call_other().
> > >
> > > Bart
> > >
> > > On Wed, 4 Oct 2017 17:45:38 -0500, Blain wrote
> > >> I implemented the this_user idea in the kernellib's TLS
> > >> implementation, but there was no easy way to tell if the setting
> > >> corresponding to a given frame is expired.  So thus the FLS idea was
> > >> born.
> > >>
> > >> If DGD could supply a null element before the first arg, all else
> > >> could be handled by the lib.  The current klib's implementation of
> > >> TLS could also be made to use this instead of having to create
> > >> wrappers for entry-level functions in driver.c to basically do the
> > >> same thing (except with only frame 0).
> > >>
> > >> On Oct 4, 2017 17:01, "Blain" <blain20 at gmail.com> wrote:
> > >>
> > >> > I envisioned looping backward to find the latest setting for
> implementing
> > >> > something like this_player(). Obviously not all uses of something
> like this
> > >> > would need to do that, though.  Another possible use is to let a
> frame
> > >> > store unique data that later frames can query, such as stack-based
> security.
> > >> >
> > >> > On Oct 4, 2017 16:10, "Felix A. Croes" <felix at dworkin.nl> wrote:
> > >> >
> > >> >> Blain <blain20 at gmail.com> wrote:
> > >> >>
> > >> >> > I'm talking about one for each frame so that it goes away
> automatically
> > >> >> > when that frame goes away.  An example use is a variable for the
> current
> > >> >> > user/player/body in a given frame that is automatically rolled
> back when
> > >> >> > the frame ends and focus goes back to a previous frame, who's
> current
> > >> >> > user/player/body variable will then be on top.
> > >> >>
> > >> >> This is more than what you called FLS, since it also involves
> setting a
> > >> >> new value for each frame, or else falling back to a value provided
> by a
> > >> >> previous frame.  I would describe that as stack-based, rather than
> > >> >> frame-based.
> > >> >>
> > >> >> If you're looking for a this_player() equivalent, there is an
> example
> > >> >> implementation in the LP 2.4.5 mudlib simulation.  It doesn't use,
> but
> > >> >> could be done with, thread-local storage.
> > >> >>
> > >> >> Regards,
> > >> >> Felix Croes
> > >> >> ____________________________________________
> > >> >> 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/
> > >
> > > ____________________________________________
> > > 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/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd