Re: Leo and fossil merged with Rust

[Edward K. Ream]

On Mon, Jul 29, 2019 at 2:11 PM vitalije  wrote:

It has been a very long time since I've got this idea of combining Leo with
> fossil. For all these years I felt that there was a great potential in this
> mixture, but I haven't got the time to do anything about it until recently.
>
Many thanks for this excellent work. Clearly, you've demonstrated that
potential.


> Using two scale widgets user can choose any recorded version of the
> outline shape, and history of the selected node.
>

You have convinced me that outline and node diffs could be useful.

Sending snapshots from Leo is done by the plugin which keeps track of the
> time passed since the last Leo command has been executed. When 5s pass
> since the last executed command, Leo calculates the snapshot and if it is
> different than the previous one it sends it in separate thread to the
> server. The whole process is almost unnoticeable by the user. The server
> stores the deltas in the database file (one database per Leo outline) which
> is located in the same folder as the Leo document, and has the '.history'
> appended to its name. For example: outline test.leo will have it's history
> stored in the database test.leo.history in the same folder.
>

Looks good to me.

Below is the link to the video demonstration (if you have read everything
> above you can skip to the 3:00). There are some issues with the sound which
> I couldn't fix, but there are captions in English.
>

Excellent. This kind of demo, with minimal/no captions seems to be
popular.  For example, see the emacs demos here
.
They let the code do the explaining :-)  I am thinking that I should
replace of of Leo's ponderous videos with this kind of thing.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2i%3DDCSeLWGVabQSuCZhTAUjJuKyUaB2RbWxO4sBzagyQ%40mail.gmail.com.

Re: Leo and fossil merged with Rust

[vitalije]

On Monday, July 29, 2019 at 9:31:49 PM UTC+2, Terry Brown wrote:
>
> That is very cool.  I hope Kent sees it, he's talked about such things 
> more than once.
>
 
Yes I just tried to find the exact date when this idea appeared on this 
list. I haven't found my message that I am rather sure I had written about 
some experimental code - a Leo script to disassemble Leo outline in small 
files (one per node) + outline as a separate file and execute fossil 
command in a separate process to commit those files. And the other script 
used to execute fossil checkout and then reassemble parts to Leo outline. 
Most probably it was in 2012 or before.
 
Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/7e9273d3-1ed2-4f36-8ffd-32e59e9fead2%40googlegroups.com.

Re: Leo and fossil merged with Rust

[Terry Brown]

That is very cool.  I hope Kent sees it, he's talked about such things more
than once.

Cheers -Terry

On Mon, Jul 29, 2019 at 2:11 PM vitalije  wrote:

> It has been a very long time since I've got this idea of combining Leo
> with fossil. For all these years I felt that there was a great potential in
> this mixture, but I haven't got the time to do anything about it until
> recently.
>
> Fossil uses an extremely good algorithm to calculate the difference
> between two texts. And the deltas produced by this algorithm are very
> compact and nice to work with. If the input texts are texts, than the delta
> is also a plain text. I have ported this algorithm from C in which fossil
> is originally written, to Rust programming language. The ported code is
> published on crates.io as fossil-delta
> . Using this library, I wrote a
> small web server which accepts snapshots sent from Leo periodically at idle
> time and calculates the delta between the previous one and the current one,
> and stores those deltas in the sqlite database. The server also serves
> small web application that allows user to browse history of any recorded
> Leo outline. Using two scale widgets user can choose any recorded version
> of the outline shape, and history of the selected node.
>
> Sending snapshots from Leo is done by the plugin which keeps track of the
> time passed since the last Leo command has been executed. When 5s pass
> since the last executed command, Leo calculates the snapshot and if it is
> different than the previous one it sends it in separate thread to the
> server. The whole process is almost unnoticeable by the user. The server
> stores the deltas in the database file (one database per Leo outline) which
> is located in the same folder as the Leo document, and has the '.history'
> appended to its name. For example: outline test.leo will have it's history
> stored in the database test.leo.history in the same folder.
>
> Below is the link to the video demonstration (if you have read everything
> above you can skip to the 3:00). There are some issues with the sound which
> I couldn't fix, but there are captions in English.
>
> The demo 
>
> Vitalije
>
> PS: the outline is about 210Kb, and database with about 625 recorded
> versions is about 450Kb. Those 625 versions were recorded during the 30
> hours time span.
>
> --
> 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 leo-editor+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/897a3b7a-554b-4db6-8501-ebafc1746214%40googlegroups.com
> 
> .
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46QO%2B_nGcyPs-OV1V8aUbr1JZAooF0CT98NK63XhGTUuCQ%40mail.gmail.com.

Leo and fossil merged with Rust

[vitalije]

It has been a very long time since I've got this idea of combining Leo with 
fossil. For all these years I felt that there was a great potential in this 
mixture, but I haven't got the time to do anything about it until recently. 

Fossil uses an extremely good algorithm to calculate the difference between 
two texts. And the deltas produced by this algorithm are very compact and 
nice to work with. If the input texts are texts, than the delta is also a 
plain text. I have ported this algorithm from C in which fossil is 
originally written, to Rust programming language. The ported code is 
published on crates.io as fossil-delta 
. Using this library, I wrote a 
small web server which accepts snapshots sent from Leo periodically at idle 
time and calculates the delta between the previous one and the current one, 
and stores those deltas in the sqlite database. The server also serves 
small web application that allows user to browse history of any recorded 
Leo outline. Using two scale widgets user can choose any recorded version 
of the outline shape, and history of the selected node.

Sending snapshots from Leo is done by the plugin which keeps track of the 
time passed since the last Leo command has been executed. When 5s pass 
since the last executed command, Leo calculates the snapshot and if it is 
different than the previous one it sends it in separate thread to the 
server. The whole process is almost unnoticeable by the user. The server 
stores the deltas in the database file (one database per Leo outline) which 
is located in the same folder as the Leo document, and has the '.history' 
appended to its name. For example: outline test.leo will have it's history 
stored in the database test.leo.history in the same folder.

Below is the link to the video demonstration (if you have read everything 
above you can skip to the 3:00). There are some issues with the sound which 
I couldn't fix, but there are captions in English.

The demo 

Vitalije

PS: the outline is about 210Kb, and database with about 625 recorded 
versions is about 450Kb. Those 625 versions were recorded during the 30 
hours time span.

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/897a3b7a-554b-4db6-8501-ebafc1746214%40googlegroups.com.

Re: Leo and black

[Edward K. Ream]

On Mon, Jul 29, 2019 at 9:04 AM Terry Brown  wrote:

rabbitMQ - high performance cross language / cross machine (cloud) message
queue system..it seems like the missing link in easy decoupling /
connecting of software.

Thanks for this.  I've bookmarked https://www.rabbitmq.com/

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0Q9F847Ss94KqJdpXC6F-1o%2BTwKskbL_TFZo1mgK4_NQ%40mail.gmail.com.

Re: Leo and black

[Edward K. Ream]

On Mon, Jul 29, 2019 at 9:33 AM vitalije  wrote:

> I didn't want to say that this command should be used rarely. I was just
pointing out that unless you have changed the code in a node, there is no
point in executing this command.

The node selection logic already compares the old and new versions of p.b
and p.h.  It must do this in order to set the dirty "bit" and the
corresponding icon.  So yes, Leo should blacken a node only if it's body
text changes.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2y4gho8-2USDyUDMjHu6qXHi7MxDTcuHS8aB%3DPLyjWnA%40mail.gmail.com.

Re: Leo and black

[Edward K. Ream]

On Mon, Jul 29, 2019 at 8:06 AM vitalije  wrote:

That would be rather invasive and most of the time unnecessary spending CPU
> time. Selecting nodes is already too complicated and not very fast (to say
> the least). Please don't add any more burden to it.
>

Blackening nodes automatically would be a user option, off by default.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2xzcivfUrE2cg2fGnSUU0c25ifiKEY7Pi5ioyFtG%2ByCg%40mail.gmail.com.

Re: Leo and black

[vitalije]

On Monday, July 29, 2019 at 4:04:57 PM UTC+2, Terry Brown wrote:
>
> I disagree with Vitalije's assessment of how often you'd execute it,
>

I didn't want to say that this command should be used rarely. I was just 
pointing out that unless you have changed the code in a node, there is no 
point in executing this command. While reading code  you presumably select 
nodes more often than you write code that needs beautifying. And perhaps 
while you write code, you wish to see it beautified right away and not just 
after you had selected some other node and then come back to the original 
node to see the beautified code.

I am mostly concerned with the present complexity of the tree 
selection/deselection code. I feel like it has already too much staff 
there, and perhaps something needs to be removed, reduced, simplified. 
Adding more code to it worries me.

Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/07ade57d-4849-4471-96ac-63a19035518a%40googlegroups.com.

Re: Leo and black

[Terry Brown]

Now that I think about it I started using Black before I stopped using
Leo.  I disagree with Vitalije's assessment of how often you'd execute it,
I found I quite often wanted a node tidied up.  But I would agree with
Vitalije on taking a minimalist light weight approach to using Black in
Leo.  I just set up a button to run it on the current node - thinking at
the time how cool it is that Leo makes doing that so easy.

Totally unrelated PSA: rabbitMQ - high performance cross language / cross
machine (cloud) message queue system - I'm probably just late to the party,
but it seems like the missing link in easy decoupling / connecting of
software.  Not saying it has some immediate relevance to Leo, just that
it's good to know about such things in general.

Cheers -Terry

On Mon, Jul 29, 2019 at 8:07 AM vitalije  wrote:

>
>
> On Monday, July 29, 2019 at 2:44:10 PM UTC+2, Edward K. Ream wrote:
>>
>> So it looks like Leo could optionally run blacken-node whenever selecting
>> and/or unselecting a node for which @language python is in effect.
>>
>>
> That would be rather invasive and most of the time unnecessary spending
> CPU time. Selecting nodes is already too complicated and not very fast (to
> say the least). Please don't add any more burden to it. Instead let the
> user decide when to execute this command. If one wishes to perform it on
> every node selection, then it would be trivial to add it as a plugin so
> that the Leo's core dealing with selecting nodes, remains free of this
> feature.
>
> The benefit of having this command executed is a rather rare thing. One
> must:
>
>1. write Python code
>2. write a lengthy line of code that could be split by this command
>
> How many times one can have these conditions met? Against how many node
> selections where these conditions are not fulfilled? I believe the ratio is
> negligibly small.
>
> Vitalije
>
>
> --
> 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 leo-editor+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/ec0a3148-9636-4977-b134-aa75ca421913%40googlegroups.com
> 
> .
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46TcSzopm6M3PurA8XeM%2BA%3DGuw-%3DB7rC%2BJ%2B-ekOgeNqa-w%40mail.gmail.com.

Re: Leo and black

[vitalije]

On Monday, July 29, 2019 at 2:44:10 PM UTC+2, Edward K. Ream wrote:
>
> So it looks like Leo could optionally run blacken-node whenever selecting 
> and/or unselecting a node for which @language python is in effect.
>
>
That would be rather invasive and most of the time unnecessary spending CPU 
time. Selecting nodes is already too complicated and not very fast (to say 
the least). Please don't add any more burden to it. Instead let the user 
decide when to execute this command. If one wishes to perform it on every 
node selection, then it would be trivial to add it as a plugin so that the 
Leo's core dealing with selecting nodes, remains free of this feature.

The benefit of having this command executed is a rather rare thing. One 
must:

   1. write Python code
   2. write a lengthy line of code that could be split by this command

How many times one can have these conditions met? Against how many node 
selections where these conditions are not fulfilled? I believe the ratio is 
negligibly small.

Vitalije


-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ec0a3148-9636-4977-b134-aa75ca421913%40googlegroups.com.

Re: Leo and black

[Edward K. Ream]

On Sunday, July 28, 2019 at 4:03:37 PM UTC-5, Edward K. Ream wrote:

> black looks considerably slower than Leo's beautify commands.

On second thought, it looks like Leo *can* use black with very little extra 
work.

*Black looks fast enough*

The blacken-node command (in the "black" branch) takes about 0.01 sec for 
typically sized nodes. At present, this code doesn't actually change p.b.  
It only reports diffs.  So it looks like Leo could optionally run 
blacken-node whenever selecting and/or unselecting a node for which 
@language python is in effect.

*Leonine constructs are not gotchas*

black.make_chunks adapts black to Leo. It calls black only for sequences of 
lines *not *containing Leonine constructs.  At present, it doesn't 
recognize @language so as to call black only for sequences of python lines.

Black's (mis-) handling of Leo's sentinel lines doesn't matter because 
sentinel lines never appear in p.b.

We might add an @no-black directive, or maybe even retire the @no-beautify 
directive.

*Summary*

Leo could (optionally) run the blacken-node command when selecting nodes 
containing python source code.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9eaa4734-daeb-420a-9663-4b991e4d1dee%40googlegroups.com.

Re: Leo and black

[Edward K. Ream]

On Sunday, July 28, 2019 at 4:03:37 PM UTC-5, Edward K. Ream wrote:

[improving] Leo's existing beautify commands so they follow black's 
> line-breaking strategy [should] be relatively straightforward.  This would 
> be a major departure for Leo's beautify commands. 
>

A quick prototype of Leo's token-based beautify code reveals no gotchas:

- The code will need a new token type, say 'optional-line-end', in addition 
to the existing 'line-end' token.  'optional-line-end' represents a newline 
within one or more open (unmatched) parens or square/curly brackets.  
'line-end' tokens represent newlines outside such unmatched parens or 
brackets.

- The new code might even avoid some nasty logic involving backslash 
newlines. Black generally deletes backslash newlines.

- The prototype code scans back through the output_tokens list looking for 
the previous 'line-end' or 'file-start' token. Instead, the revised code 
will likely remember the position of the previous 'line-end' or 
'file-start' token.

- Calculating the length of one or more lines is easy:

len(''.join([z.to_string() for z in self.code_list[i:]]))

where i is the start of the lines.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3bf54932-6cca-497e-84c2-ea81d760ea5c%40googlegroups.com.

Re: Leo and black

[Edward K. Ream]

On Sun, Jul 28, 2019 at 5:15 PM Terry Brown  wrote:

> I've been using black for quite a while.  I agree it's probably not
> fast enough to continuously reformat a file as you type, but that would
> probably be annoying.


Thanks for these comments.  The prototype code in the "black" branch could
be adapted to the work flow you suggest.  That code understands
Leo-specific constructs, and works on nodes, not files, and there would be
blacken-tree and blacken-node commands, just as with the beautify commands.

However, Leo's existing beautify commands appear to be three times faster
than the blacken commands. Furthermore, Leo's beautify commands depend only
on Python standard library for tokenizing.  So my plan is to see if I can
use black's line-breaking ideas in Leo's beautify commands.  That should
take just a few hours.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0LABJbDqLUFsa%2BTKT6sL_4uwSBq_qWNxC%2B_oPVS_6yYA%40mail.gmail.com.