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.
