ball-parking 10 times a day, gives me 24 hours of dev time
{-;
On Fri, Jul 4, 2014 at 4:03 PM, 'Terry Brown' via leo-editor
<[email protected]> wrote:
> On Fri, 4 Jul 2014 15:36:47 -0500
> Kent Tenney <[email protected]> wrote:
>
>> as simple as that routine is, it's too complex for me to
>> remember and apply consistently. I would rather spend
>> many many hours coming up with a way to avoid those
>> 5 seconds of effort.
>
> http://xkcd.com/1205/
>
> :-) Cheers -Terry
>
>> On Fri, Jul 4, 2014 at 2:38 PM, 'Terry Brown' via leo-editor
>> <[email protected]> wrote:
>> > On Fri, 4 Jul 2014 11:03:08 -0500
>> > Kent Tenney <[email protected]> wrote:
>> >
>> >> >@shadow has persistent uas and gnxs.
>> >>
>> >> and done in an interesting way: the @shadow <file>
>> >> organizer node ua contains the gnx of the file.
>> >>
>> >> @shadow doesn't parse .py, so it doesn't meet my needs
>> >
>> > Hmm, I often load files in Leo using the leoserver script to load
>> > them from the command line, which pulls them in as @edit nodes.
>> > The if it was a python file and I want it parsed, I just change
>> > 'edit' to 'auto' and use "refresh from disk". There are some
>> > issues with refresh from disk but it works in this context.
>> > Longwinded way of saying you could use @auto to load and parse the
>> > file and the switch it to @shadow.
>> >
>> > But if there isn't one already, we should have a command that
>> > performs "@auto" parsing on the selected node. It could also be
>> > used if you write a bunch of little stub function definitions in
>> > one node and then want them parsed into separate nodes for easy
>> > navigation.
>> >
>> > Cheers -Terry
>> >
>> >> Could the @auto <file> organizer ua be convinced to persist the
>> >> gnx's of the last parsed file?
>> >>
>> >> ... and, thanks for the reminder, I'll see if c.db will be
>> >> sufficient
>> >>
>> >>
>> >>
>> >> On Fri, Jul 4, 2014 at 10:00 AM, 'Terry Brown' via leo-editor
>> >> <[email protected]> wrote:
>> >> > On Fri, 4 Jul 2014 07:32:19 -0500
>> >> > Kent Tenney <[email protected]> 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
>> >> >> <[email protected]> wrote:
>> >> >> > On Thu, 3 Jul 2014 18:30:32 -0500
>> >> >> > Kent Tenney <[email protected]> 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
>> >> >> >> <[email protected]> wrote:
>> >> >> >> > On Thu, Jul 3, 2014 at 6:40 AM, Kent Tenney
>> >> >> >> > <[email protected]> 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 @shadow
>> >> >> >> > doesn't parse .py, so it doesn't meet my needs
>> >
>> > Could the @auto <file> organizer ua be convinced to persist the
>> > gnx's of the last parsed file?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
>> >> >> >> > [email protected]. To post to this
>> >> >> >> > group, send email to [email protected]. 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
>> >> >> > [email protected]. To post to this
>> >> >> > group, send email to [email protected]. 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
>> >> > [email protected]. To post to this group,
>> >> > send email to [email protected]. 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
>> > [email protected]. To post to this group,
>> > send email to [email protected]. 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 [email protected].
> To post to this group, send email to [email protected].
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
