On Fri, 4 Jul 2014 07:32:19 -0500
Kent Tenney <kten...@gmail.com> wrote:
> the problem with UNLs is they don't allow choices which involve
> changing the headline. If I change the name of a method, I don't
> want to lose the choices for the implementation of that method.
>
> Thanks for doing the work re: gnx setting. The code you provided
> works a champ.
As long as you don't go from
Node A ('ktenney', '20110117134522', 7)
Node B ('ktenney', '20140807232334', 7)
to
Node A ('ktenney', 'init_vars', 7)
Node B ('ktenney', 'init_vars', 7)
or something like that.
Also changing gnxs might break pointers to nodes from other places.
You could just
p.v.u.setdefault('space_vers', {})['id'] = uuid.uuid4()
or more readable
if 'space_vers' not in p.v.u:
p.v.u['space_vers'] = {}
p.v.u['space_vers']['id'] = uuid.uuid4()
using the space_vers `namespace` assuming you'll want to store more
than one thing on the node. Like the index of the version you're
currently viewing, I guess.
Oh, doh, but that's not helping at all with the @auto stuff.
> The idea would be a table in the companion db which, on closing
> the Leo file would generate key/value pairs @auto tree UNL / gnx
> on opening the Leo file and after parsing the @auto file, the
> @auto tree gnx's would be reverted to the previous ones, simulating
> the persistence of regular nodes. No collision issues.
And doh again, really should have read the whole email before I started
replying :-}
Sounds like you're on a reasonable path.
@shadow has persistent uas and gnxs.
Cheers -Terry
> Come to think of it, the table in the companion db could also
> trivially save the ua of the @auto tree nodes, ... at which point the
> @auto tree nodes are as rich a data store as a regular node.
>
> If the file had been edited outside Leo since Leo saw it last, the
> nodes in the db could be tagged as obsolete, or new records created
> accordingly.
>
> If the db were updated on changes instead of on closing, less would be
> lost in a crash.
>
> I'll ruminate this approach until the reason it won't work rears it's
> ugly.
>
> [-:
>
> On Thu, Jul 3, 2014 at 8:50 PM, 'Terry Brown' via leo-editor
> <leo-editor@googlegroups.com> wrote:
> > On Thu, 3 Jul 2014 18:30:32 -0500
> > Kent Tenney <kten...@gmail.com> wrote:
> >
> >> p.gnx is not currently writable, would it be a big
> >> deal to make it writeable? If not globally, for
> >> @auto tree nodes?
> >
> > So wow, p.v.gnx is a property which only supports get, which is why
> > you can't write to it, which wasn't a surprise. What is a surprise
> > to me, it's not just returning a hidden variable, it's calling
> > g.app.nodeIndices.toString(v.fileIndex), where v.fileIndex
> > is a tuple like ('tbrown', '20140703203404', 26811)
> > i.e. username, start of session timestamp, count of gnxs created in
> > session.
> >
> > So it looks like making it writeable would be a big deal. Although
> > g.app.nodeIndices.toString() shouldn't take long to execute, I do
> > wonder how much total CPU time it takes, given how often it must be
> > called. Well, having said that, maybe it's not called that much.
> > Other than serialization, you're usually dealing with in memory
> > objects directly.
> >
> > Still, interesting I'd never looked at such a fundamental piece of
> > Leo.
> >
> > Kent - you could write to it like this:
> >
> > p.v.fileIndex = (p.v.fileIndex[0], my_info, p.v.fileIndex[2])
> > my_info = p.v.fileIndex[1]
> >
> > although that trashes the timestamp and jeopardizes the uniqueness.
> >
> > I think you should aim to use UNLs instead, seeing they can easily
> > persist in @auto etc.
> >
> > Cheers -Terry
> >
> >
> >> Thanks,
> >> Kent
> >>
> >> On Thu, Jul 3, 2014 at 7:46 AM, Edward K. Ream
> >> <edream...@gmail.com> wrote:
> >> > On Thu, Jul 3, 2014 at 6:40 AM, Kent Tenney <kten...@gmail.com>
> >> > wrote:
> >> >> The version I'm developing on is using a back end with a bunch
> >> >> of dependencies, but I'll see about simplifying it, Sqlalchemy +
> >> >> sqlite should be sufficient. (someone with sql chops could
> >> >> eliminate sqlalchemy)
> >> >>
> >> >> Dang, I've been testing choices development with regular nodes,
> >> >> but day to day I'm always working in <@auto somefile.py> trees,
> >> >> and gnx is ephemeral. Maybe a hash of UNL would work for primary
> >> >> key instead of gnx
> >> > ...
> >> >
> >> > Interesting coincidence of several recent trains of thought:
> >> >
> >> > 1. Recently I removed almost all clones from leoProjects.txt and
> >> > leoNotes.txt. You could call it a matter of housekeeping, but
> >> > I'm moving towards a workflow in which clones exist only until a
> >> > project is done. So they are becoming more ephemeral.
> >> >
> >> > 2. ArmageDOOM mentioned this link on #leo:
> >> > https://news.ycombinator.com/item?id=7511979
> >> >
> >> > One of the comments was that Leo's file format "hadn't taken
> >> > off". Without gnx's, Leo's external files would be identical (or
> >> > nearly so) with org mode. No, this doesn't really make @auto
> >> > processing any easier, because even org mode sentinels will be
> >> > unacceptable to most non-Leonine users.
> >> >
> >> > 3. I recently realized that clones are a bit of a nuisance for
> >> > find/change. The more clones I have, the more duplicates there
> >> > are when using F3 (find-next)
> >> >
> >> > For all these reasons, I am beginning to wonder whether clones
> >> > can somehow be put a little more behind the scenes.
> >> >
> >> > To be sure, clones (vnodes) are likely always to exist as a basic
> >> > capability, but if clones can be made just slightly more
> >> > "ephemeral" then gnx's might not be needed in external files.
> >> > For example, I wonder whether my work flow could be based on a
> >> > combination of Terry's bookmarks and (perhaps) automatically
> >> > generated (and thus more ephemeral) clones.
> >> >
> >> > In this context, your comments about hashing the UNL fits right
> >> > into the zeitgeist. Bookmarks are, iirc, just unl's...
> >> >
> >> > In short, this could be an important new direction for Leo. No,
> >> > we aren't going to get rid of clones. No, we aren't going to
> >> > get rid of sentinels. But there might be important benefits if
> >> > we can convert sentinels to org-mode format, and if we can make
> >> > clones more of the plumbing than the porcelain (to use git
> >> > terminology).
> >> >
> >> > In short, it looks like you are leading the way again, Kent.
> >> >
> >> > Edward
> >> >
> >> > --
> >> > You received this message because you are subscribed to the
> >> > Google Groups "leo-editor" group. To unsubscribe from this group
> >> > and stop receiving emails from it, send an email to
> >> > leo-editor+unsubscr...@googlegroups.com. To post to this group,
> >> > send email to leo-editor@googlegroups.com. Visit this group at
> >> > http://groups.google.com/group/leo-editor. For more options,
> >> > visit https://groups.google.com/d/optout.
> >>
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "leo-editor" group. To unsubscribe from this group and stop
> > receiving emails from it, send an email to
> > leo-editor+unsubscr...@googlegroups.com. To post to this group,
> > send email to leo-editor@googlegroups.com. Visit this group at
> > http://groups.google.com/group/leo-editor. For more options, visit
> > https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
