Re: Traveling to Florida

[Edward K. Ream]

On Friday, December 9, 2016 at 11:33:15 AM UTC-5, Terry Brown wrote:
>
> Have a great trip, heading for daytime highs in the 20s C / 70s F, leaving 
> behind highs of -10 C / 10 F, can't imagine why you do it :-)
>

Rebecca and I are settling into life in Naples.  I hope to be fixing 
significant bugs soon.

EKR

>

-- 
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: binary installer

[Edward K. Ream]

On Tue, Dec 13, 2016 at 2:24 AM, Sr U  wrote:

Did you get past your installation problems?  I wish I had kept careful
> notes on what I tried before I finally got my Win7 install to work...it
> took hours and several install-delete-install cycles.
>

​I have been following this conversation with interest.

I understand your desire to have things "just work", but this may be an
illusion.  Instead, installing the latest version of Leo using git will
likely be much simpler, especially after installing Anaconda
 first.

In the time you have spent futzing with installers, you could have
installed Anaconda and git, and even learned the rudiments of git.
Thereafter, you can get the latest code by doing git pull.

This is, by far, the best way.  Please try it unless your boss absolutely
forbids it ;-)  And if so, you might try convincing him/her...

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 Project Variables - like simple settings nodes, but available to all nodes

[Edward K. Ream]

​​
On Mon, Dec 12, 2016 at 2:11 PM, Richard Twyning <
service.management.addr...@gmail.com> wrote:

> ​
> I'm very new to Leo and I think I'm trying to do something similar to what
> was asked in this post.
>

​I've just re-read this thread.  It doesn't seem to come to any firm
conclusions.  I'll try to do better here...​

I'm trying to use Leo to create batch files.  The release number has to
> repeat throughout the file.  How can I store it in a header node and
> reference it from a sub node?
>

​Suppose you have lots of files, each of which has a version number that
should be updated in sync.  Here are your options, as I see it.

1. The simplest way, if it works, would be to define a section node
containing the version.  Each file would reference this node using
cross-file clones. I'm not sure why this wouldn't work.  Have you tried
it?  Feel free to ask questions if this precis isn't clear to you.

2. Next, I would consider writing a script.  It would traverse your
outline, looking for a (regex) pattern.  If found, it would substitute the
version directly into each file, while retaining the original pattern for
future use.  Clear?

3.The valuespace plugin might work.  I don't know.

4. Don't bother requesting ​changes to Leo's code to support this.  It
won't happen.

All comments and further questions are welcome.

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: leo stalling for long periods

[Edward K. Ream]

On Fri, Dec 16, 2016 at 2:06 PM, 'Terry Brown' via leo-editor <
leo-editor@googlegroups.com> wrote:

> Sounds like a challenge, cross platform wise etc.​
>

​Thanks for this comment.

Rev 2a0eca16 uses the following default:

@bool check_for_changed_external_files = false

The node now contains a warning that references #262
, now named "@bool
check_for_changed_external_files may hang on network files".

Given the severity of #262, I don't see any real alternative.

EKR

-- 
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: Exception running Markdown_Importer

[Edward K. Ream]

On Tue, Dec 13, 2016 at 7:25 AM, Edward K. Ream  wrote:

​> ​
The problem is likely the following regex:
​ ​
[snip]​

Fixed, I think, at rev bd90f4d.​

​As noted in the checkin log, ​actual @auto-md files import @@section names
correctly, but some dashed problem with the unit testing logic is requiring
a kludge.  Maybe no big deal...

Please test the new code and report any problems.  Thanks.

EKR

-- 
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: leo stalling for long periods

['Terry Brown' via leo-editor]

Sounds like a challenge, cross platform wise etc.
A unix command like `df -l` (disk free local) seems to know. But there are so 
many ways non-local files can be mounted, sshfs, Windows shares, etc.
Cheers -Terry
 
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Friday, December 16, 2016 12:23 PM
 Subject: Re: leo stalling for long periods
   
On Fri, Dec 16, 2016 at 11:11 AM, john lunzer  wrote:


Here is the issue in question. 
​
Thanks.  I've reopened it, and labeled it a Bug to denote its new status re 
network drives.

I am dithering about whether to make file check the default or not.  It may 
depend on whether it's possible to check whether a drive is a network drive or 
not. Does anyone know whether a check is possible?

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


   
 

-- 
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: Theme Problems

[Edward K. Ream]

On Thu, Dec 15, 2016 at 6:20 PM, Edward K. Ream  wrote:

>
>
> On Tue, Dec 13, 2016 at 8:25 PM, 'Terry Brown' via leo-editor <
> leo-editor@googlegroups.com> wrote:
>
>> You're right, themes seem to have been  completely nerfed.
>> ekr_dark_theme has a @data node, but it doesn't seem to work.
>>
>
​Please file an official bug report, so we can all track this.

Thanks.

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: leo stalling for long periods

[Edward K. Ream]

On Fri, Dec 16, 2016 at 11:11 AM, john lunzer  wrote:

Here is the issue in question
> .
>
​
Thanks.  I've reopened it, and labeled it a Bug to denote its new status re
network drives.

I am dithering about whether to make file check the default or not.  It may
depend on whether it's possible to check whether a drive is a network drive
or not. Does anyone know whether a check is possible?

EKR

-- 
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: Theme Problems

[Edward K. Ream]

On Fri, Dec 16, 2016 at 9:57 AM, john lunzer  wrote:

> have you recently done a fresh checkout of Leo and followed the theme
> instructions? I believe that is what both Terry and I did and how we
> concluded that themes are non-operational.
>

​No, I haven't.  I won't be able to do that on my Linux box until I get
home. I'll try to use a theme on my laptop to see what happens.

EKR

-- 
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: leo stalling for long periods

[john lunzer]

Yes, this was me because I almost exclusively access files over a slow vpn 
on network drives.

Here is the issue in question 
. I actually never 
tested this change. I'll try to turn it on at some point soon. On the other 
hand, the date Curtis gave for his build (Dec 8th) indicates that your 
previous changes should be included so perhaps the changes you made didn't 
have the desired effect.

On Thursday, December 15, 2016 at 6:13:33 PM UTC-5, Edward K. Ream wrote:
>
>
>
> On Thu, Dec 15, 2016 at 3:54 PM, Curtis Carlsen  > wrote:
>
>> I was mistaken, most of my external files are local, but some may be on 
>>> network drives.
>>>
>>
>> That said, your setting change seems to have fixed the problem!
>>
>> Perhaps even local files have similar problems on some platforms?
>>
>
> ​Thanks to all the participants in this discussion.  ​Clearly, the present 
> situations isn't good enough.  John, was it you who reported the 
> performance problems with network drives?  Do you remember the issue 
> number? I'm having trouble finding it.  It probably should be reopened.
>
> 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: Bad bugs *are* possible in python & Leo

[john lunzer]

I've heard the claim that interpreted languages simply have a whole 
different set of bugs than compiled languages. 

I think about 95% of the bugs I encounter in Python at runtime are due to 
incompatible types due to an "inappropriate" type/value being passed to a 
function. Sometimes it's simply the wrong variable and sometimes the right 
variable has been passed but needs to be converted to str/int/etc or exist 
inside a list. I find this class of bugs is usually not detectable with 
static file checkers like pylint/pyflakes/flake8. I'm annoyed by them but 
they are almost always obvious from the stack trace. 

I've also heard the claim that static type checking eliminates this class 
of bugs. I would agree that static type checking can *limit* this class of 
bugs but I also find that it presents a false sense of security about 
passing appropriate values and lulls me into writing weaker tests. Type 
checking *can* be a *part* of a robust test but should rarely be the only 
test.

I infinitely prefer this class of bugs over memory management issues. That 
said, if one is following best practices and robust tests are being written 
then this class of bugs nearly disappears, which explains why I encounter 
them so often ;)

On Friday, December 16, 2016 at 4:49:04 AM UTC-5, Edward K. Ream wrote:
>
> A recent tweet misquoted me.  In the "Why I Like Python 
> " Chapter I discussed why 
> python is fundamentally safer than C. It's not (usually) possible to make 
> memory allocation errors in python, whereas in C one must be constantly on 
> guard.
>
> Alas, this does *not* mean that it is impossible to make serious errors 
> in python!  In Leo, the most serious errors would cause users to lose data 
> *silently* when they saved a file.  Yes, people can delete data from a 
> .leo by accident, but that's not what I mean.  The worst bugs would delete 
> data without the user's knowledge.
>
> This has happened in the past. We don't want it ever to happen in future.
>
> The rest of this post discusses where the danger areas are in Leo.  It 
> will be of interest primarily to Leo's maintainers.  Feel free to ignore.  
> But please, I have *never* said that bad bugs are impossible in python.  
> Only one class of bad bugs is impossible in python.
>
> *LeoTree.select*
>
> The easiest way to destroy Leo would be to mess up the node-switching 
> logic in LeoTree.select and helpers.  This logic handles the surprisingly 
> complex and dangerous process of switching from one node to another.  I 
> won't go into details, but any errors can cause data in the body pane to 
> revert to their previous contents, which horrendous consequences.
>
> Afaik, there is no way to simplify this logic. Among other things, it must 
> switch what c.p means at *precisely* the correct moment so that redraws 
> happen properly.  c.endEditing is part of this logic, and is much trickier 
> than one might assume. LeoBody.onBodyChanged is also critical and tricky 
> code.
>
> *Leo's Qt event handling*
>
> It took months to get Leo's Qt tree-handling code to be rock solid.  
> Mistakes caused Leo to hard crash within PyQt, which is a thin wrapper 
> around C code.  Pass a bad C reference to Qt--die hard.
>
> There is a serious, unavoidable, additional complication.  Unlike most 
> outliners, Leo scripts can cause changes to the outline.  This means there 
> are two, fundamentally different, paths through the tree handling code. The 
> first arises from user mouse clicks in the outline.  The second arises from 
> user scripts, including built-in scripts.  This second path can cause Qt 
> events that *must be suppressed*. Failure to do so will cause unbounded 
> recursions or other catastrophic failures.
>
> And one more thing about the Qt code.  Ending editing of a headline 
> destroys the underlying QLineEdit widget.  Leo's code must take great pains 
> to handle this fact.  Failures result in references to unallocated C 
> memory.  Again, Leo dies hard.
>
> *Summary*
>
> The worst bugs in Leo's history caused people to lose data when switching 
> nodes.
>
> Developing a new gui for Leo will always be challenging because scripts 
> can cause unwanted outline events that must be suppressed. The curses gui 
> may be an exception, or not.
>
> Memory allocation bugs are not (usually) possible with python, but they 
> can arise by passing bad references to C libraries.
>
> Yes, python is fundamentally safer than C, but arbitrarily bad bugs *are* 
> possible. 
> Happily, bad bugs can arise only in a few critical areas in 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 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, 

Re: Theme Problems

[john lunzer]

It's possible the tests need to be updated. Rather than run the tests, have 
you recently done a fresh checkout of Leo and followed the theme 
instructions? I believe that is what both Terry and I did and how we 
concluded that themes are non-operational.

On Thursday, December 15, 2016 at 6:20:19 PM UTC-5, Edward K. Ream wrote:
>
>
>
> On Tue, Dec 13, 2016 at 8:25 PM, 'Terry Brown' via leo-editor <
> leo-e...@googlegroups.com > wrote:
>
>> You're right, themes seem to have been  completely nerfed.
>> ekr_dark_theme has a @data node, but it doesn't seem to work.
>>
>
> ​Hmm.  I don't have access to a Linux box right now, but just before I 
> left for Florida I ran all unit tests in Leo.  That surely used a dark 
> theme, so afaik themes do work on Linux.
>
> EKR
>

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

Bad bugs *are* possible in python & Leo

[Edward K. Ream]

A recent tweet misquoted me.  In the "Why I Like Python 
" Chapter I discussed why 
python is fundamentally safer than C. It's not (usually) possible to make 
memory allocation errors in python, whereas in C one must be constantly on 
guard.

Alas, this does *not* mean that it is impossible to make serious errors in 
python!  In Leo, the most serious errors would cause users to lose data 
*silently* when they saved a file.  Yes, people can delete data from a .leo 
by accident, but that's not what I mean.  The worst bugs would delete data 
without the user's knowledge.

This has happened in the past. We don't want it ever to happen in future.

The rest of this post discusses where the danger areas are in Leo.  It will 
be of interest primarily to Leo's maintainers.  Feel free to ignore.  But 
please, I have *never* said that bad bugs are impossible in python.  Only 
one class of bad bugs is impossible in python.

*LeoTree.select*

The easiest way to destroy Leo would be to mess up the node-switching logic 
in LeoTree.select and helpers.  This logic handles the surprisingly complex 
and dangerous process of switching from one node to another.  I won't go 
into details, but any errors can cause data in the body pane to revert to 
their previous contents, which horrendous consequences.

Afaik, there is no way to simplify this logic. Among other things, it must 
switch what c.p means at *precisely* the correct moment so that redraws 
happen properly.  c.endEditing is part of this logic, and is much trickier 
than one might assume. LeoBody.onBodyChanged is also critical and tricky 
code.

*Leo's Qt event handling*

It took months to get Leo's Qt tree-handling code to be rock solid.  
Mistakes caused Leo to hard crash within PyQt, which is a thin wrapper 
around C code.  Pass a bad C reference to Qt--die hard.

There is a serious, unavoidable, additional complication.  Unlike most 
outliners, Leo scripts can cause changes to the outline.  This means there 
are two, fundamentally different, paths through the tree handling code. The 
first arises from user mouse clicks in the outline.  The second arises from 
user scripts, including built-in scripts.  This second path can cause Qt 
events that *must be suppressed*. Failure to do so will cause unbounded 
recursions or other catastrophic failures.

And one more thing about the Qt code.  Ending editing of a headline 
destroys the underlying QLineEdit widget.  Leo's code must take great pains 
to handle this fact.  Failures result in references to unallocated C 
memory.  Again, Leo dies hard.

*Summary*

The worst bugs in Leo's history caused people to lose data when switching 
nodes.

Developing a new gui for Leo will always be challenging because scripts can 
cause unwanted outline events that must be suppressed. The curses gui may 
be an exception, or not.

Memory allocation bugs are not (usually) possible with python, but they can 
arise by passing bad references to C libraries.

Yes, python is fundamentally safer than C, but arbitrarily bad bugs *are* 
possible. Happily, bad bugs can arise only in a few critical areas in 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 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: Notes on Leo learning

[Edward K. Ream]

On Fri, Dec 16, 2016 at 2:29 AM, Satish Goda  wrote:

> Hello folks.
>
> I have started taking notes for myself as I dig deeper into integrating
> Leo into my daily workflows. The GitHub link to my repo is below.
>
> https://github.com/satishgoda/leo-editor-tutorial
>
> My intention is to create a set of tutorials that will elucidate the core
> aspects of Leo (I am writing an introductory one on Python & Leo today!!).
>
> Just wanted to share it with you all and I am open to ideas and thoughts.
>

​Excellent.  I see​

​that your sandbox contains some @button scripts for creating your chapters.

It took me awhile to realize that several of your references are to Jake
Peck's a -> ab  site.​ I didn't know
that any of that existed.  Jake, did you announce your blog?  I sure missed
it.

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.