Re: Leo's run levels

2017-07-16 Thread Xavier G. Domingo
I'm wondering if it would be a useful thought experiment to list a series of "run levels" (https://en.wikipedia.org/wiki/Runlevel) or levels of initialization for Leo - just a textual list where we do our best to be aware of dependencies for each level. It will be interesting to look at

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread Xavier G. Domingo
El 16/07/2017 a las 15:52, Edward K. Ream escribió: On Sun, Jul 16, 2017 at 12:29 PM, vitalije > wrote: Having said that, my earlier recommendation than one should avoid switching branches in same folder is not valid any more.

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread vitalije
> > The recovered nodes are *not* a sign of problems (any more). They could > be called a courtesy--a note that code is different in the new branch from > the previous branch. > > The acid test is to save all files (write-at-file-nodes) after switching > branches. Any changed file is a

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread Terry Brown
On Sun, 16 Jul 2017 13:47:40 -0500 "Edward K. Ream" wrote: > On Sun, Jul 16, 2017 at 10:49 AM, Terry Brown > wrote: > > As long as Leo's refresh from disk code works reasonably and as long > as you **always say yes to all** when Leo prompts for

New backend for Leo Cacher

2017-07-16 Thread vitalije
Commit 0e98b2073 contains new backend for leoCache.Cacher. New code is disabled by default by `SQLITE=False` switch in leo/core/leoCache.py To try it set `SQLITE=True`. On next launch Leo will have to read and parse all external files, like it does after cleaning cache. But following launches

Re: Leo's run levels

2017-07-16 Thread Edward K. Ream
On Sun, Jul 16, 2017 at 11:00 AM, Terry Brown wrote: :-) I think there's an intuitive sense that there might be some > potential for simplification, which would be very valuable. ​I agree, but startup code is the ruin of all intuition... ​ > it doesn't seem like > ​ ​

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread Edward K. Ream
On Sun, Jul 16, 2017 at 1:18 PM, Terry Brown wrote: > While I will leave it to Edward to agree or disagree, I'd just point out > that the c.db and g.db API must remain unchanged for all the non - cache > uses they have, including in personal code we can't mass edit. > ​I

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread Edward K. Ream
On Sun, Jul 16, 2017 at 12:29 PM, vitalije wrote: > > > Having said that, my earlier recommendation than one should avoid > switching branches in same folder is not valid any more. > ​That's great news.​ I still don't know if leoCache was responsible for all those

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread Edward K. Ream
On Sun, Jul 16, 2017 at 10:49 AM, Terry Brown wrote: > > As long as Leo's refresh from disk code works reasonably and as long as > you **always say yes to all** when Leo prompts for reload on external > changes, it doesn't seem like there should be a problem. > ​I agree.

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread vitalije
On Sunday, July 16, 2017 at 8:21:40 PM UTC+2, Terry Brown wrote: > > P.S meant to say that apart from preserving the API I see no issues with > switching the cache backend, unless some one was using pickleshare directly > to access it outside Leo, seems unlikely. > > Yes, that is what I

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread Terry Brown
P.S meant to say that apart from preserving the API I see no issues with switching the cache backend, unless some one was using pickleshare directly to access it outside Leo, seems unlikely. On July 16, 2017 12:29:56 PM CDT, vitalije wrote: >What I found is that there

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread Terry Brown
While I will leave it to Edward to agree or disagree, I'd just point out that the c.db and g.db API must remain unchanged for all the non - cache uses they have, including in personal code we can't mass edit. Cheers - Terry On July 16, 2017 12:29:56 PM CDT, vitalije

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread vitalije
What I found is that there was a bug in sqlite-leo code which prevented refresh-from-disk to work quite reliably. Happily, I have found and fixed it. In sqlite-leo branch as from cbb8f876854b looking for a file in Leo cache is fully avoided. That brought small speed up in starting Leo. Master

Re: Leo's run levels

2017-07-16 Thread Terry Brown
On Sun, 16 Jul 2017 07:58:06 -0700 (PDT) "Edward K. Ream" wrote: > On Sunday, July 9, 2017 at 2:15:06 AM UTC-5, Edward K. Ream wrote: > > > >> On Wed, Jul 5, 2017 at 3:51 PM, Terry Brown > >> wrote: > >> > >>> I'm wondering if it would be a useful

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread Terry Brown
On Sun, 16 Jul 2017 06:21:05 -0700 (PDT) vitalije wrote: > As I wrote in this comment > , > I had a serious trouble with this branch pollution thing. > My advice is never to develop two separate

Re: How does instant update work in Pharo?

2017-07-16 Thread Edward K. Ream
On Saturday, July 15, 2017 at 4:50:32 PM UTC-5, Edward K. Ream wrote: > developing with @button or @test *already simulates instant reload pretty well*. Let me clarify this statement. Here is the lede for a new post: Today, right now, Leo devs and script writers can develop python code *more

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread Edward K. Ream
On Sun, Jul 16, 2017 at 8:21 AM, vitalije wrote: > As I wrote in this comment > , > I had a serious trouble with this branch pollution thing. > ​This is troubling. I have not had any real problems

Re: Leo's run levels

2017-07-16 Thread Edward K. Ream
On Sunday, July 9, 2017 at 2:15:06 AM UTC-5, Edward K. Ream wrote: > > >> On Wed, Jul 5, 2017 at 3:51 PM, Terry Brown >> wrote: >> >>> I'm wondering if it would be a useful thought experiment to list a >>> series of "run levels" (https://en.wikipedia.org/wiki/Runlevel) or

Re: Menu clarity - Open Leo File

2017-07-16 Thread Edward K. Ream
On Sun, Jul 16, 2017 at 9:28 AM, Edward K. Ream wrote: ​> leoSettings.leo should document @menu and @item...This is a big miss.​ See #529 addresses. It also recommends a new help-for-settings command. Edward -- You

Re: Menu clarity - Open Leo File

2017-07-16 Thread Edward K. Ream
On Sun, Jul 16, 2017 at 7:45 AM, Edward K. Ream wrote: This is a discussion about menus, not commands. > ​But see below...​ Further, a better learning opportunity for newbies would be a >> 'Help-for-Menus' entry to show the menu coding. HTH with that if you like :) >> >

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread Edward K. Ream
On Sun, Jul 16, 2017 at 8:21 AM, vitalije wrote: ​> ​ As I wrote in this comment , I had a serious trouble with this branch pollution thing. ​ Many thanks for this detailed comment. In the past,

Re: A road to branch pollution: git stash goes back in time

2017-07-16 Thread vitalije
As I wrote in this comment , I had a serious trouble with this branch pollution thing. My advice is never to develop two separate branches in the same folder. Every branch deserves its own folder. At least this is true

Re: Menu clarity - Open Leo File

2017-07-16 Thread Edward K. Ream
On Sun, Jul 16, 2017 at 2:14 AM, lewis wrote: Yes, technically they are commands and in your example you use the keyboard > directly, not the menu. > ​This is a discussion about menus, not commands. ​ > In the context of a menu they appear as a File Open menu

Re: Menu clarity - Open Leo File

2017-07-16 Thread lewis
Yes, technically they are commands and in your example you use the keyboard directly, not the menu. In the context of a menu they appear as a File Open menu operation. They seem duplicated and out of position. Under a Cmds heading the display should be the actual commands: open-cheat-sheet-leo