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.
