Re: Documentation on new data model for Leo outlines

[vitalije]

Thanks for all your comments and suggestions. I agree that using integers 
to access the elements of attrs list is not very readable. There will be 
time to discuss it further when whole model is settled down a bit. It is 
still evolving, so I haven't seen much point in polishing it yet.

Today, I haven't progress very much because I had lots of interruptions. I 
have made small gui example. But before I show it I wish to make few more 
outline commands like promote/demote children, move up,left,right,down. I 
hope tomorrow I would be able to finish this prototype and publish it so 
that everyone can test it.

About script compatibility and rewriting Position class, I was thinking 
that it would be simplest thing to just let them be as they are now. 
Instead of changing Position and VNode, we can change execute-script 
command. Before executing script, we can rebuild the whole tree with legacy 
VNodes and Positions which should not take very long (less than 100ms I 
expect). Legacy scripts will run in the legacy environment and after they 
finish we can synchronize data in the new model which is also very fast 
operation. That way there will be no need for major changes in the legacy 
code, and we can start to port piece by piece functionality to the new 
model. Both models can easily coexist. We can advice all users to write 
their scripts using new patterns and strategies to take the advantage of 
new model. But they can keep old scripts if they like.

Anyway, I am still exploring what else may be improved in the new model.

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

ebba40fdb adds explicit keypad bindings to leoSettings.leo

[Edward K. Ream]

The alternative would be to add code to Leo's core which would default to 
the non-keypad bindings.  However, I prefer the present approach: it more 
explicitly shows the bindings, and invites users to bind keypad bindings to 
other commands.

The previous rev also makes Numpad and Num_pad synonyms for Keypad. As 
always, Leo ignores the case of modifiers, so you can also use numpad and 
num_pad.

I've been more methodical about the new bindings, so perhaps this will be 
the end of the matter. Regardless of the bindings in leoSettings.leo, you 
are free to override them in your myLeoSettings.leo file.

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation on new data model for Leo outlines

[Edward K. Ream]

On Tuesday, May 15, 2018 at 6:36:15 AM UTC-5, Edward K. Ream wrote:

all existing Position methods and generators must have exactly the same 
> *effect* as before.  Many (All?) Position methods and generators will 
> need to be rewritten.  That's fine. The new code will be simpler than the 
> old code.
>

Rewriting the Position methods will be straightforward, as I'll now 
explain. 

>From Vitalije's Theory of Operation 
: "Suppose that model keeps 
a list of all nodes in outline order. Positions would be represented by 
indexes in this list."

This makes p.moveToThreadNext() and p.moveToThreadBack() trivial.  Either 
increment or decrement the index, with appropriate bounds checks.

p.threadNext() is just self.copy().moveToThreadNext(). It (and all other 
"copy" methods) will not have to change.

Methods like p.moveToVisNext() is conceptually harder, but it may be 
possible to use the existing p.moveToVisNext as is. We shall see...

*Summary*

The representation of an index as an index will probably simplify all 
Position methods. In any event, there is no doubt whatever that all 
Position methods can be rewritten to preserve existing meaning exactly.

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Mindmap-like calculations in outline

[Edward K. Ream]

On Tue, May 15, 2018 at 11:52 AM, Luka  wrote:

> Is it possible to perform tree-based calculations like in freeplane,
> mindjet mindmanager etc?
>

​The answer to all such questions must be "yes", because Leo's scripting
capabilities are completely general.​


Assume every node has named atrributes (like in valuespace, or some v.u
> dictionary). Like task duration for project management.
>
> I want parent to accumulate sum of all children attributes values:
>


> parent node: sumvalue=sum(all_children(value))
> child node: value=1
> child node: value=3
>

> After evaluation, I want to get sumvalue=4. For example, it could be sum
> of all tasks durations which equals to the whole project duration.
>

​If you care only about children, this will work: ​

​sum([p.v.u.get('value', 0) for p in p.children()])​


I checked valuespace plugin, it seems that it performes calculations in
> outline order as provided by all_unique_positions(). In my case children
> are required to be evaluated first. In genral, it is required that deepest
> level descendants are evaluted first in outline order, then their parents,
> and so on until top level nodes are evaluted last.
>

​Leo's generators work in a depth-first manner, but that is not required.
You can use recursive calls to get exactly the traversal you want (tested
code):

def add_descendants(p):
return (
p.v.u.get('value', 0) +
sum([add_descendants(child) for child in p.children()])
)

print(add_descendants(p))

​In this case, it doesn't matter whether the traversal is depth-first or
breadth-first, because addition is commutative.

HTH.  Please feel free​ ask more questions.

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation on new data model for Leo outlines

[Edward K. Ream]

On Tue, May 15, 2018 at 8:53 AM, Terry Brown  wrote:

>
> We've discussed this before I think, but returning tuples can be a real
> pain for extensibility.


​I agree. I think Vitalije is aware of the trade-offs.  For now, I'm happy
to let him choose whatever style he likes.

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Mindmap-like calculations in outline

[Luka]

Is it possible to perform tree-based calculations like in freeplane, 
mindjet mindmanager etc? 

Assume every node has named atrributes (like in valuespace, or some v.u 
dictionary). Like task duration for project management.

I want parent to accumulate sum of all children attributes values:
parent node: sumvalue=sum(all_children(value))
child node: value=1
child node: value=3

After evaluation, I want to get sumvalue=4. For example, it could be sum of 
all tasks durations which equals to the whole project duration.

I checked valuespace plugin, it seems that it performes calculations in 
outline order as provided by all_unique_positions(). In my case children 
are required to be evaluated first. In genral, it is required that deepest 
level descendants are evaluted first in outline order, then their parents, 
and so on until top level nodes are evaluted last.

I also tried to find appropriate generator (like all_unique_positions()) to 
make simple scripts based on v.u myself, but I could not find appropriate 
one.

Does any solution already exist? 

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation on new data model for Leo outlines

[Terry Brown]

On Tue, 15 May 2018 08:04:21 -0500
"Edward K. Ream"  wrote:

> On Tue, May 15, 2018 at 6:55 AM, Terry Brown 
> wrote:
> 
> > What about a namedtuple?
>  
> ​That or a bunch.  Just to be clear, ​the code itself may change to
> make this moot.

Realized after I posted that may have some memory impact, possibly not
an issue / very minor.

> Another possibility, which I often favor, is to unpack the tuple in
> place:
> 
> item1, item2, ... itemN = aTuple
> <>
> 
> This pattern appears already in other places in Vitalije's code.
> 
> Edward

We've discussed this before I think, but returning tuples can be a real
pain for extensibility.  Changing

  return foo, bar

to

  return foo, bar, etc

breaks all clients, whereas changing

  return {'foo': x, 'bar': y}

to

  return {'foo': x, 'bar': y, 'etc': z}

is very unlikely to break anything.

but if dicts are a performance issue a named tuple might be a good
balance.

Veering off topic I wish there was a more general solution for dot
access to dict members, I understand all the arguments against, but
often writing mathematical expressions...

col = (pos['x'] - grid['minx']) / (grid['maxx'] - grid['minx']) * grid['cols']

vs.

col = (pos.x - grid.minx) / (grid.maxx - grid.minx) * grid.cols

Cheers -Terry

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: @data abbreviation documentation

[Rob]

Hmm, I still see the old comments.

Leo 5.7.3 devel, build 20180509115144, Wed May  9 11:51:44 UTC 2018
Git repo info: branch = devel, commit = 110174b3f8a8

Rob...

On Wednesday, May 9, 2018 at 7:15:49 AM UTC-4, Edward K. Ream wrote:
>
>
>
> ​Thanks for this.  Now in LeoSettings.leo at rev 383fcc472.
>
> 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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation on new data model for Leo outlines

[Edward K. Ream]

On Tue, May 15, 2018 at 6:55 AM, Terry Brown  wrote:

What about a namedtuple?
>

​That or a bunch.  Just to be clear, ​the code itself may change to make
this moot.

Another possibility, which I often favor, is to unpack the tuple in place:

item1, item2, ... itemN = aTuple
<>

This pattern appears already in other places in Vitalije's 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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Global and local @outline-data tree-abbreviations

[Rob]

That's a good idea, Terry. I didn't realize this might impact (and improve) 
other @data types. I will post the feature request this morning.

Rob...

On Monday, May 14, 2018 at 5:45:57 PM UTC-4, Terry Brown wrote:
>
>
>
> Something you could include in the request... 
>
> There are a few cases where we have 
>
> @data global-foo-settings 
> @data local-foo-settings 
>
> or maybe even 
>
> @data global-foo-settings 
> @data local-foo-settings 
> @data user-foo-settings 
>
> Being wary of Vitalije's dreaded FNMW (flexibility no matter what ;-) 
> let's consider the possibility of syntax like 
>
> @data foo @append 
>
> or something that extends @data settings rather than replacing them. 
> Then we don't have to invent names for all the needed levels of config., 
> users can just create what they need with the existing lyered config. 
> loading. 
>
> Cheers -Terry 
>
>
>
>

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation on new data model for Leo outlines

[Terry Brown]

On Tue, 15 May 2018 04:36:15 -0700 (PDT)
"Edward K. Ream"  wrote:

> *Readability will not affect performance*
> 
> attrs[gnx] is a tuple [h, b, ps, chn, sz[0]]. The components should
> be accessed via a bunch, or an enum, say,
> 
> e_h = 0
> e_b = 1
> e_ps = 2

What about a namedtuple?

Cheers -Terry

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation on new data model for Leo outlines

[Edward K. Ream]

On Monday, May 14, 2018 at 9:44:11 AM UTC-5, Edward K. Ream wrote:
>
>
> On Mon, May 14, 2018 at 8:02 AM, vitalije  wrote:
>
>> I have just published first two articles about what I have done so far in 
>> this mini-project. Here are the links:
>>
>>1. Leo tree model - new approach 
>>
>>2. Leo tree model - loading from a file 
>>
>>
>> ​This is superb work.  I never dreamed the code could be improved so much.
>

Still true, after more reflection. Some comments:


*Strategy*
I have confidence that this project will be a success.  Sitting in the 
bathtub yesterday, I realized that code details don't matter much.  The 
only things that matter are:

1. Existing Leo scripts must not be impacted in *any* way.

In particular, all existing Position methods and generators must have 
exactly the same *effect* as before.  Many (All?) Position methods and 
generators will need to be rewritten.  That's fine. The new code will be 
simpler than the old code.

2. All existing unit tests must pass.

Naturally, unit tests of low-level details of VNodes and Positions can 
change as necessary.


*Summary of code*
I've studied the code more thoroughly.  My high-level summary of the read 
process:

Part 1: Create tuples.

Use xml.etree.ElementTree when reading .leo files.  Use regexs when reading 
external files.

Part 2: Use the tuples to create vnodes.

This is non-trivial, because @others and section references alter the tree 
structure.

I think that's all that most devs will need to know.

*Readability will not affect performance*

attrs[gnx] is a tuple [h, b, ps, chn, sz[0]]. The components should be 
accessed via a bunch, or an enum, say,

e_h = 0
e_b = 1
e_ps = 2
...

To prove that this has no effect on performance, I added a global count, 
gCount of the number of times a[n] was accessed in leoDataModel.py during 
the tests run in test_leo_data_model.py.  Here is the instrumented run, 
with the new count last:

tree size 8137 read in 488.24ms files:164
ok 471 471
Average: 24.82ms
checking write
ok
tree correct 5327576
pickle avg: 20.38ms
upickle avg: 14.93ms
profiling write_all
ok 695.47ms
gCount: 50723

And here is the timeit script showing the time penalty of using an enum 
constant, e_gnx, instead of hard constants in the a array.

number = 5
setup1 = 'a = [0]'
stmt1 = 'b = a[0]'
n1 = timeit.timeit(stmt=stmt1, setup=setup1, number=number)
n1 = float(n1)

setup2 = 'e_gnx = 0; a = [0]'
stmt2 = 'b = a[e_gnx]'
n2 = timeit.timeit(stmt=stmt2, setup=setup2, number=number)
n2 = float(n2)

print('n1:%8.6f' % n1)
print('n2:%8.6f' % n2)
print('n2-n2: %8.6f' % (n2-n1))

And here is the output on my machine:

n1:0.001246
n2:0.001259
n2-n2: 0.13

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: I love Leo, but... Scrivener and Org-Mode

[Edward K. Ream]

On Mon, May 14, 2018 at 5:05 PM, Israel Hands  wrote:

>
> I got greedy though and added the line below
>
>
> ​​
> g.execute_shell_commands('"C:\Program Files (x86)\SumatraPDF\SumatraPDF.exe"
>  latex_test.pdf')
>
> which works but hangs Leo
>

​Use a list of arguments, not a single string:

​
g.execute_shell_commands([
'"C:\Program Files (x86)\SumatraPDF\SumatraPDF.exe",
'latex_test.pdf'
])

HTH.

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.