[DGD] LWO
Blain
blain20 at gmail.com
Thu Aug 13 23:19:59 CEST 2015
So what you're saying is, I can finally simulate JavaScript and make
jquery-like nodes. :)
On Aug 13, 2015 4:07 AM, <bart at wotf.org> wrote:
> I use them first of all for creating things
> like bigmap and bigarray implementations
> (ie, mappings and arrays which scale beyond
> 16384 elements) and for example to create a
> kind of interface/session objects.
>
> You may have seen some comments from me
> regarding a rdbm and sql implementation.
> Besides sql, this also has a native lpc
> interface that uses LWOs.
>
> Maybe you are familiar with perl and the way
> you can bind a mapping to a bdb or gnudb.
> What my code does with help of LWOs is allow
> lpc code to access databases is if they are
> mappings or as objects, depending on what
> you want to do and on preference.
>
> For example, there is a database logdb with
> a table logcfg. Logcfg has a column 'keep'
> which tells how long a certain message
> should be kept in the lig.
>
> Modifying the 'keep' for a log can be done
> in a few ways:
>
> run_sql( "use logdb; update syslog set (
> keep = 3600 ) where log = logname;" );
>
> Or:
>
> open_database("logdb")->set_value("syslog",
> "keep", 3600 );
>
> Or:
>
> open_database("logdb")["syslog"]["keep"]
> ["logname"] = 3600;
>
> The 3rd variation uses LWOs with operator
> overloading
>
> Bart
> On Wed, 12 Aug 2015 19:08:59 -0500, Blain
> wrote
> > Bart: What are some practical
> applications for operator overloading?
> > On Aug 9, 2015 8:00 AM, <bart at wotf.org>
> wrote:
> >
> > > I noticed 2 bugs in the code I posted
> (not handling ranges properly when
> > > beginning or end not specified, and not
> handling the difference between 0
> > > and
> > > nil in the | operator), both fixed.
> > >
> > > As to open-sourced libraries for DGD,
> Iirc Shentino is maintaining an
> > > open-sourced lib (or 2 actually?), and
> there is klib of course (also
> > > maintained by Shentino nowadays if I'm
> not mistaken), and Felix maintains a
> > > lib called cloudlib, which is very
> interesting codewise, but seems rather
> > > incomplete for as far as building a mud
> goes.
> > >
> > > Every so often, when people ask about
> things, I'll post some examples (if
> > > possible as public domain, so they can
> be used by everyone without
> > > licensing
> > > concerns).
> > >
> > > Beyond the things mentioned above, I
> don't think there is anything
> > > open-sourced that runs on modern
> versions of DGD and can take advantage of
> > > at
> > > least some of the features that make DGD
> special.
> > >
> > > In general, you'll have to make some
> choices. Current Gurbalib seems to
> > > aim at
> > > simplifying the codebase to provide
> something that is relatively easy to
> > > understand and use, but at the expense
> of some of the complexity,
> > > infrastructure and restrictions needed
> to run DGD as a persistent server
> > > and
> > > for example support for a verb based
> user interface.
> > >
> > > This doesn't have to be an issue if you
> want to use it for a classic lpmud
> > > style lib for example, but may be
> limiting if you aim for a 'new'
> > > persistent
> > > mud with a persistent world and managed
> in-game economy.
> > >
> > > Picking between those 2 styles or
> consciously deciding on a mix (and on
> > > solutions to the various conflicts this
> causes) is very important, doing so
> > > much later on will involve lots and lots
> and lots of extra work, and
> > > depending
> > > on the size of your codebase, may not
> even be a feasable option (trust me
> > > on
> > > this one, I went this way with Way of
> the Force, and it took about half a
> > > decade to find and address the more
> prominent issues).
> > >
> > > At any rate, Gurbalib is your best
> starting point when wanting to run
> > > something lpmud alike, and has an active
> maintainer and a small but active
> > > community, but its not a very good
> starting point if you aim at something
> > > that
> > > isn't very lpmud like.
> > >
> > > Bart.
> > >
> > > On Sat, 08 Aug 2015 19:38:53 -0400,
> Littlefield, Tyler wrote
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > This is cool, thanks. I got what I was
> trying for working today.
> > > > Are there many different systems open-
> sourced in LPC? I'd like to see
> > > > how things are done, most especially
> with DGD.
> > > >
> > > > Thanks,
> > > > On 8/8/2015 10:19 AM, bart at wotf.org
> wrote:
> > > > > An example LWO can be found at:
> > > > >
> > > > >
> http://wotf.org/downloads/lpc/kvset.c
> > > > >
> > > > > It should work on gurbalib directly
> (and with little or no
> > > > > modification on about every other
> lib).
> > > > >
> > > > > It implements a variation on the
> mapping type that adds support for
> > > > > &, | and - operators.
> > > > >
> > > > > Bart
> > > > >
> > > > > On Sat, 8 Aug 2015 12:05:05 +0200,
> bart wrote
> > > > >> Creating an LWO is easy:
> > > > >>
> > > > >> object src; object lwo;
> > > > >>
> > > > >> src = find_object(
> "/path/to/some/object" ); lwo = new_object(
> > > > >> src );
> > > > >>
> > > > >> lwo will be the lightweight object,
> src is a blueprint object
> > > > >> used as a template for the lwo.
> > > > >>
> > > > >> Note that an object does not have
> to do anything special to be
> > > > >> usable as lwo, but there are some
> differences between a clone of
> > > > >> a blueprint object and an lwo:
> > > > >>
> > > > >> Very important: lightweight objects
> do not get destructed
> > > > >> explicitly, they simply are
> forgotten when nothing references
> > > > >> them anymore. This means (very
> important if you are trying to do
> > > > >> any kind of object management or
> data storage on destruct) there
> > > > >> will be NO calls to the lwo
> informing it that it is going to be
> > > > >> destructed. This is a simple fact
> and not something that you can
> > > > >> code your way around, it is a
> consequence of the nature of LWOs.
> > > > >>
> > > > >> LWOs can *NOT* have call_outs.
> Again, this is a consequence of
> > > > >> the nature of LWOs. Do not use LWOs
> for code that must use
> > > > >> call_outs or move the call_outs to
> some other bit of code not in
> > > > >> an LWO.
> > > > >>
> > > > >> LWOs are kept in the storage space
> of the object that created
> > > > >> them (did the call to
> new_object()). ALL the things that apply to
> > > > >> arrays and mappings that are passed
> by reference from one object
> > > > >> to another also apply to LWOs. This
> means they will only be
> > > > >> shared until the end of the
> execution round, after which a copy
> > > > >> will be made and both objects
> involved will end up having their
> > > > >> own copy of the LWO. For example,
> you might want to keep track
> > > > >> of some centralized counter for
> something. You decide to stick
> > > > >> this in some object, and let
> everything that needs this counter
> > > > >> call the object. So far so good,
> and this works with blueprints
> > > > >> (as you can simply use find_obect()
> and are guaranteed to end up
> > > > >> at that blueprint) or clones (you
> have to pass the object
> > > > >> reference to code that needs it).
> Doing this with an LWO however
> > > > >> may or may not work depending on
> exactly how you implement this:
> > > > >> - pass lwo reference to other
> object, which uses it to reference
> > > > >> the counter and then forgets it,
> all in the same execution round:
> > > > >> this works - pass lwo reference to
> another object which stores it
> > > > >> and then later on (as the result of
> a call_out or other user
> > > > >> action) tries to use it: this will
> not work as expected as the
> > > > >> LWO is no longer the one that was
> stored originally, it is a copy
> > > > >> of it.
> > > > >>
> > > > >> Also important, LWOs support
> features that regular clones do not,
> > > > >> especially operator overloading
> (see the git commit log for dgd,
> > > > >> look for the keyword operator).
> > > > >>
> > > > >> Anyway, there are things for which
> LWOs are an absolutely
> > > > >> brilliant solution, things like
> building advanced data types (for
> > > > >> example mappings that can contain a
> lot more then 16384 key/value
> > > > >> pairs), but also things for which
> they are a very cumbersome
> > > > >> solution that is best be avoided.
> > > > >>
> > > > >> So.. creating them is easy, making
> good use of them however
> > > > >> requires some more careful thought
> really, they are not 'just an
> > > > >> alternative for clones', rather,
> they are something totally
> > > > >> different then clones, and
> generally things that need clones
> > > > >> cannot easily be done with LWOs and
> the other way around.
> > > > >>
> > > > >> Bart.
> > > > >>
> > > > >> On Sat, 08 Aug 2015 03:33:39 -0400,
> Littlefield, Tyler wrote
> > > > > Hello all: I've been looking for
> examples. Is there a syntax for
> > > > > creating an LWO? Any help
> appreciated. Thanks, - -- Take care, Ty
> > > > > twitter: @sorressean
> web:http://tysdomain.com pubkey:
> > > > >
> http://tysdomain.com/files/pubkey.asc
> > > >
> > > > >>>
> ____________________________________________
> > > > >>>
> 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
> > > > >
> > > > >
> > > > > --
> http://www.flickr.com/photos/mrobjective/
> http://www.om-d.org/
> > > > >
> > > > >
> ____________________________________________
> > > > >
> https://mail.dworkin.nl/mailman/listinfo/dgd
> > > > >
> > > >
> > > > - --
> > > > Take care,
> > > > Ty
> > > > twitter: @sorressean
> > > > web:http://tysdomain.com
> > > > pubkey:
> http://tysdomain.com/files/pubkey.asc
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG v2
> > > >
> > > >
> iQEcBAEBAgAGBQJVxpMNAAoJEAdP60+BYxejo5wH/iat
> nZXyhqU2+p0WbZBnXJWI
> > > >
> QxOTC35kNHGfQJjd1B/+DZ+WGTeG3lrgJadDHwOu/kPs
> 3fEGZsHvioT0jDxQomnB
> > > >
> F5aNw3/QT0XCIt0xQ4gjRFbBQ18Q9Ffd22RFriIh9y3E
> XBSKXwaazx5YD172CRgH
> > > >
> /jhyxfVIgtjRzs6bgtpkdyUAkivwU7dH3Xkf9AcPf71z
> HwD36vmJyvQEDhvt+zjU
> > > >
> 7W+KG5KaO03/pPEqk+YXf4M+etMXcnMVlpZqgYkcqQNm
> KW2KWa8T5AFkKG/A5Bzj
> > > >
> abUmxPOT0PV7EIA5HmTEmC8m/okqFkAz4jm6VzVPchOy
> 5a0ZX9SL/ynbyIipsCc=
> > > > =iaK9
> > > > -----END PGP SIGNATURE-----
> > > >
> ____________________________________________
> > > >
> 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
More information about the DGD
mailing list