>@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 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 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.
