Re: A new tree drawing approach

[Brian Theado]

Vitalije,

This looks interesting. Thanks for sharing. I'm not familiar with how the
existing tree drawing approach works. Could you share (in broad strokes)
what the current drawing does and how it is different from your new scheme?

Is it that the existing code recreates all the QT items from scratch every
time there is a redraw? And your code can add/remove a much smaller subset
of QT items because of your set operations?

I didn't quite follow your example about expanding a node. When a node is
expanded, then the children or descendants must appear in the display. How
does that relate to the "set of links" you are using to represent the
outline structure?

Thanks,
Brian

On Tue, Apr 7, 2020 at 9:02 AM vitalije  wrote:

> For several days now, I've been working on a new drawing approach. The
> preliminary results of this work can be seen in the new branch
> tree-refresh .
> There are still some things missing (like hoisting and chapters) but they
> won't be hard to add if Edward accepts this idea.
>
> I had an Aha moment: The outline structure can be represented as a set of
> links, where each link is just a tuple (parent_id, index, child_id). In
> other words, all the information about the structure (or shape) of the Leo
> outline including the information about clones, can be represented by the
> set of elements (parent.gnx, index, child.gnx). And what is more important
> is that obtaining this set from the Leo is not too expensive operation.
>
> import timeit
> def makeset():
> def it(v):
> for i, ch in enumerate(v.children):
> yield v.fileIndex, i, ch.fileIndex
> yield from it(ch)
> return set(it(c.hiddenRootNode))
> g.es(timeit.timeit(makeset, number=100)/100*1000, 'ms')
>
> On my fastest computer this gives 6.14ms for LeoPy.leo. On older computers
> it might be about 12ms.
>
> The idea is to keep track of this set each time we redraw the tree. On the
> next redraw we can simply use the set arithmetic to find what is changed in
> the tree. We calculate new set (let's call it a current_links) and then use
> (current_links - last_links) to get all the inserts and (last_links -
> current_links) to get all deletes.
> Both of these operations are very fast and then we just need to add
> several new links or delete some of the previously existstent links to draw
> new version of tree.
>
> This techinque can eliminate a lot of unnecessary redraws. For example if
> the node is expanded nothing is changed and the only thing necessary is to
> set certain tree item to expanded state.
>
> It isn't only about the speed. There are more benefits of using this
> approach to draw tree. After redrawing the tree, for every position in the
> Leo there exists a single item. This fact alone can make a lot of other
> parts of Leo much simpler. A lot of checks that position exists and is
> still valid may be skipped if the position comes from the tree. Keeping
> track of expanded/collapsed state for each position can be delegated to the
> tree items, because for each valid position there exists a single item.
>
> The code in tree-refresh branch is a prototype that shows this approach as
> possible. It doesn't do hoisting and chapters yet, and the code is not
> cleaned. A lot of qt_tree code is not used and can be deleted. There is one
> more status field in the status line which shows how much time took the
> last redraw. All of the unit tests pass.
>
> There is a room for improvements of diff-calcualtion. In the current
> version bare set difference is used which is not producing the smallest
> possible diff. For example if a parent node has 10 children and we delete
> first one, the difference will contain not just one delete operation as it
> would ideally but 10 deletes followed by 9 inserts, because every child has
> now the different index. Perhaps we can process these differences a bit
> before applying them. But for now it works just fine. Deleting 9 items and
> creating new 9 items is still much less work than deleting the whole
> outline and recreating it from scratch.
>
> 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/945d9bd3-7653-47ba-9617-8359587ae8b5%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 

Re: Reproducible computational science

[Thomas Passin]

I think that Leo does have potential in this area, as long as it can export 
usable notebooks in Jupyter format.  That's not necessarily out of the 
question.  In fact, there is already an exporter (and an importer) for 
notebooks.  They don't seem to be able to bring in execution results and 
images so far.  But that could be fixed.

The export capability is needed so that Leo users would be able to share 
their work with the much larger number of people who use Jupyter notebooks.

We have found that the VR3 plugin (still in beta but nearly there) can be 
used to embed graphical output from calculations, even interactive output 
(e.g., from Bokeh) without much difficulty.  Right now it can only execute 
python code, but there doesn't seem to be any reason that couldn't change.

What we need is an approach to converting a Leo tree of nodes that uses VR3 
to/from a Jupyter notebook.  Since Jupyter notebooks for the most part 
either point to image files or embed output as data: urls, that should be 
very doable.  Even if it can't do everything that Jupyter can do, it would 
be able to do a useful subset.  Then we could have the benefits of working 
in Leo combined with the benefits of sharing Jupyter notebooks.

On Wednesday, April 8, 2020 at 3:46:23 PM UTC-4, Brad wrote:
>
> I use Jupyter notebooks for a lot of my analyses.
> Though I realize a lot more is possible, my personal preference is not to 
> use this platform beyond exploratory analyses where one can embed 
> relatively short snippets of code into the notebook.
>
> I know that one could zip a directory with Jupyter notebooks and data to 
> satisfy some of my requirements, but it seemed to me that with Leo's very 
> versatile structure, and the capability to naturally incorporate meta data 
> in a structured manner, might offer some advantages.
>
> Per Marcel's perceptive comments, I understand that  Leo has only a 
> fraction of the users of Jupyter notebooks. However, that doesn't mean that 
> Jupyter notebooks are more capable for this task. 
>
> This a hard problem and I was just suggesting that an 'out of the box' 
> solution using something like Leo might be worth considering.
>
> Kind regards,
> Brad
>  
>
>
> On Tuesday, April 7, 2020 at 6:14:14 PM UTC-6, Thomas Passin wrote:
>>
>> It's interesting to me, anyway.  Could you talk about why you haven't 
>> found Jupyter notebooks to be satisfactory?  On other threads we have been 
>> discussing whether Leo, with the Viewrendered3 plugin, might be able to do 
>> much of what Jupyter does, and have some advantages besides.  Your question 
>> seems to fit right in.
>>
>> On Tuesday, April 7, 2020 at 3:57:27 PM UTC-4, Brad wrote:
>>>
>>> Hello All,
>>>
>>> As I see it, one of the more important trends in computational sciences 
>>> is reproducibility. I have tried out a number of platforms that attempt to 
>>> enable reproducibility and capture the provenance necessary to faithfully 
>>> recapitulate computational analyses; however, I found them burdensome in 
>>> terms of the imposed workflows.
>>>
>>> I wonder if Leo could be a compelling platform for this use case. 
>>>
>>> Is anyone else interested in this use case?
>>>
>>>
>>>

-- 
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/416052e1-1d74-4194-b9de-573ad0b65346%40googlegroups.com.

Re: Reproducible computational science

[Brad]

I use Jupyter notebooks for a lot of my analyses.
Though I realize a lot more is possible, my personal preference is not to 
use this platform beyond exploratory analyses where one can embed 
relatively short snippets of code into the notebook.

I know that one could zip a directory with Jupyter notebooks and data to 
satisfy some of my requirements, but it seemed to me that with Leo's very 
versatile structure, and the capability to naturally incorporate meta data 
in a structured manner, might offer some advantages.

Per Marcel's perceptive comments, I understand that  Leo has only a 
fraction of the users of Jupyter notebooks. However, that doesn't mean that 
Jupyter notebooks are more capable for this task. 

This a hard problem and I was just suggesting that an 'out of the box' 
solution using something like Leo might be worth considering.

Kind regards,
Brad
 


On Tuesday, April 7, 2020 at 6:14:14 PM UTC-6, Thomas Passin wrote:
>
> It's interesting to me, anyway.  Could you talk about why you haven't 
> found Jupyter notebooks to be satisfactory?  On other threads we have been 
> discussing whether Leo, with the Viewrendered3 plugin, might be able to do 
> much of what Jupyter does, and have some advantages besides.  Your question 
> seems to fit right in.
>
> On Tuesday, April 7, 2020 at 3:57:27 PM UTC-4, Brad wrote:
>>
>> Hello All,
>>
>> As I see it, one of the more important trends in computational sciences 
>> is reproducibility. I have tried out a number of platforms that attempt to 
>> enable reproducibility and capture the provenance necessary to faithfully 
>> recapitulate computational analyses; however, I found them burdensome in 
>> terms of the imposed workflows.
>>
>> I wonder if Leo could be a compelling platform for this use case. 
>>
>> Is anyone else interested in this use case?
>>
>>
>>

-- 
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/73dc42a5-f61d-4a44-81b9-b51861f3d876%40googlegroups.com.

Re: No vim or pyzo bridges for Leo

[Edward K. Ream]

On Wed, Apr 8, 2020 at 10:58 AM gar  wrote:

Well strange to hear it from you.
> Actually Leo panes are vim's buffers. And all of them can be directly
> mapped one to another. Like some IDE plugins for vim do.
>

Yes, I understand that. Let me try to explain what I *think *the problem is.

Suppose we had a bridge between neovim and Leo. That bridge would be a
neovim plugin, presumably written in python. Actually, the details don't
matter.

Well, what would the bridge do? My guess is that Leo would intercept
keystrokes (in Leo's body) and send them across the link to neovim, which
would then update vim's buffer and send (somehow) the results back to Leo,
which would then update Leo's body pane.

That's a *lot* of work to do on each key stroke!

Furthermore, Leo's environment is a lot more complex than neovim's. So some
keystrokes can't be sent to neovim, because they mean something to Leo.

> So I do continue to use Leo GUI which is hard to configure, slow and need
> to be restarted for every little tweak.
>

I suspect that the bridge scheme described above will be slower.

I have to use very outdated syntax highlight schemes for most languages I
> use! pygments are claimed to be supported but works with python only.
>

Updating Leo's syntax coloring probably is a separate issue.

> Also there are many vim enthusiasts which like to make plugins for 3rd
> party goodies. But for leo it's not possible for now since it is too closed.
>

The "Won'tDo" label means that *I* won't do it. Any Leo user is welcome to
create their own plugin.

> The same with emacs I believe.
>

Leo already supports the pymacs bridge
.
Any emacs guru is welcome to create another kind of emacs bridge. Again, *I*
am not going to do that, but I would welcome contributions.

> I could write more arguments but stop here cause english is not my
> native language and I am tired :-) But hope I told enough to be my voice taken
> into account.
>

You have explained yourself very well. If you have ideas for a vim bridge I
would be glad to study them.

The main point I am trying to make is that all bridges between Leo and
another editor should be done by those who actually use the other
environment. If you would like to create a bridge between Leo and neovim I
would be happy to help in any way I can.

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/CAMF8tS18dRY5DANzfsyUPgHSWAB9%2BN--fcaM7hvmOM4NRZwJKA%40mail.gmail.com.

Re: No vim or pyzo bridges for Leo

[Thomas Passin]

Hi, Gar,

On Wednesday, April 8, 2020 at 11:58:27 AM UTC-4, gar wrote:
>
>
> I have to use very outdated syntax highlight schemes for most languages I 
> use! pygments are claimed to be supported
> but works with python only.
>

Colorizing works with other languages if you mark them with an @language 
directive, like this:

@language java
import javax.servlet.*;

public class Experiment extends javax.servlet.http.HttpServlet {
static Logger logger = Logger.getLogger("org.exp.Codes");
boolean _DEBUG = false;
String _FORMAT = "atom";
String _MIMETYPE = "application/xml";
String _TEXTTYPE = "text/plain";
String _JSONTYPE = "application/json";

Paste the snippet into a Leo code.  It should be colorized.  It is on my 
system.

I realize that colorizing is just a small part of your post; I'm not 
addressing anything else here.

-- 
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/16a8c530-5638-4102-bb97-a60f52d66d7d%40googlegroups.com.

Re: Pyzo as a live Leo explorer

[Thomas Passin]

On Wednesday, April 8, 2020 at 11:37:18 AM UTC-4, Matt Wilkie wrote:
>
> Thanks for the extra detail Thomas. 
>
> Something like this function in runLeo.py 
>  
> to add command line argument might be used to invoke no-docks:
>
> def run_console(*args, **keywords): 
>"""Initialize and run Leo in console mode gui""" 
>import sys 
>sys.argv.append('--gui=console') 
>run(*args, **keywords)
>

I wouldn't be using --gui=console to use docks, but this worked like a 
charm (no def: needed) -

import leo 

import sys

sys.argv.append('--use-docks')

leo.run()


Then CTRL-ENTER in Pyzo.


Thanks for the idea!

-- 
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/7dfda76c-feba-4915-8a5e-d712ac321173%40googlegroups.com.

Re: No vim or pyzo bridges for Leo

[gar]

Well strange to hear it from you.
Actually Leo panes are vim's buffers. And all of them can be directly
mapped one to another. Like some IDE plugins for vim do.
For the most of programming jobs now done with Leo I do not need Leo GUI
and actually would like to avoid it if I could.
I can setup vim buffers as I need, I can run vim via ssh in tmux, I can, I
can But I cannot cause I fall in love with leo's approach.
So I do continue to use Leo GUI which is hard to configure, slow and need
to be restarted for every little tweak.
I have to use very outdated syntax highlight schemes for most languages I
use! pygments are claimed to be supported
but works with python only.
I will never have plenty of those sexy editing plugins and would always use
ms word editing style with alot of mouse.
With Leo GUI I even cannot run leo on 32bit linux cause PyQt does not
support it. And what if Qt change license more drastically?

Also there are many vim enthusiasts which like to make plugins for 3rd
party goodies. But for leo it's not possible for now since it is too closed.
The same with emacs I believe.

I could write more arguments but stop here cause english is not my
native language and I am tired :-) But hope I told enough to be my voice
taken into account.

вт, 7 апр. 2020 г. в 13:16, Edward K. Ream :

> I have closed the following issues and marked them "Won'tDo":
>
> #1235  (neovim)
> #1384  (pyzo)
>
> Imo, bridges between vim or pyzo make no sense.
>
> Consider a simple thought experiment. Let's imagine that we *did* have a
> bridge between Leo and either vim or pyzo. Then what? Neither vim nor pyzo
> could be made to understand Leo, and Leo would in no way benefit from the
> bridge.
>
> Instead, I encourage users to use vim and pyzo *in addition to* Leo.
>
> 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/72fe6818-76d2-4242-b97f-e87417b54696%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/CAC%2B8SVxpnL0Jvw4JhWutUY7Gi5TWiHUUc_C2jgUcouhtMEFnvA%40mail.gmail.com.

Re: Pyzo as a live Leo explorer

[Matt Wilkie]

Thanks for the extra detail Thomas. 

Something like this function in runLeo.py 
 to 
add command line argument might be used to invoke no-docks:

def run_console(*args, **keywords): 
   """Initialize and run Leo in console mode gui""" 
   import sys 
   sys.argv.append('--gui=console') 
   run(*args, **keywords)


It is called like this:


import leo.core.runLeo
leo.core.runLeo.run_console()


I tried simply changing it to `leo.core.runLeo.run_console('--no-dock')` 
instead but that failed, so more would be needed. A path perhaps though.


Leo 6.3-devel, devel branch, build 8051ecd172
2020-04-05 05:55:36 -0500

trace: createMenuFromConfigList NO PARENT Edit Settings doHandlersForTag,
callTagHandler,onCreate,build_menu

Redirection is not supported.

The kernel process exited. (1) 


-matt



-- 
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/3100d93f-84d9-4d2b-8a5b-c223d9e2089d%40googlegroups.com.

Re: What's next, part 3

[Matt Wilkie]

Witth astonishing regularity the very moment I identify and proclaim "this 
is the state of (my) world" is when it begins to markedly change. Maybe 
true here too, discovering and opening the void is when nature rushes to 
fill it. Or not. ;-)

-matt

-- 
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/58a5bb70-2e70-45e1-b328-760c7b3cc0ec%40googlegroups.com.

Re: Reproducible computational science

['Marcel Franke' via leo-editor]

Am Dienstag, 7. April 2020 21:57:27 UTC+2 schrieb Brad:
>
>
> I wonder if Leo could be a compelling platform for this use case. 
>
>
Why do you think that?
What is leo offering that other solutions miss?

The idea would be to have a sharable Leo file of a given format that would 
> include enough information (exact code, data, specifics of the platform and 
> libraries, etc.) such that the 'sharee' could exactly re-create the results 
> of the 'sharer'.
>
>
 Out of the box, that't barely possible even for regular apps. Binary data 
would be a problem, big data would be a significant problem and libraries 
would be somewhat tricky.

Also, if you aim for real reproducibility, you would need a bunch of more 
stuff, like a plaintext-readme with instructions, because leo-files are not 
well readable without leo. You would also need to preserve the used 
leo-version, which means deliveriung a dedicated folderstructure would be 
better anyway.

It seems that Leo is a rich enough platform that a 'schema' could be 
> created to facilitate this kind of sharing.
>
>
 It entirely depends on what your aim is. Would it be used as an internal 
tool in a small group with low amount of data for day to day-usage? 
Yes, some work is neccessary, but would be doable.

As a public tool, competing with something like Jupyter, for serious 
scientific work and data with potential thousands and tenthousands of 
unexperienced users? No way. Leo is just not a good fit for this. Leo is 
just a small petproject where people explorer interessting ideas while 
ignoring quality and stability, not a dedicated vision maintainend by 
hundreds of dedicated experts. For serious reproducibility you must plan in 
matters of decades, and leo is not able to deliver that. To be fair, 
something like Jupyter is hardly delivering this too, but it's a big well 
maintained and documented project with a well prospering community going 
into this direction, so it will at some point likely reach it.

-- 
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/4f98e66b-d639-482b-9036-dc524d457d19%40googlegroups.com.