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.
