Re: Hex File Snooper

[David Szent-Györgyi]

 styles, ideas, arid 
approachs. 

Further thoughts or. writing good FORTH are to be found in Leo Brodie's 
*Starting 
FORTH*. 

On Thursday, June 13, 2024 at 6:19:31 PM UTC-4 tbp1...@gmail.com wrote:

>  It was remarkable how much faster a 2 MHz Z80 was than an early PC with 
> the 8088 at nearly 5 MHz.  I was able to make a direct comparison because I 
> had a FORTH program I used all the time on a 64k Z80 machine.  When I got a 
> PC I was able to find a 8088 FORTH system.  FORTH was written with a small 
> core of assembler and then all the other FORTH instructions were written 
> using that fast core.  So FORTH for the two machines was as nearly 
> comparable as you were going to get.
>
> The PC version running our FORTH code on a 8088 machine was wretchedly 
> slow compared to the Z80 version.  The PC version only caught up when the 
> AT came out with an 8MHz processor.
>
> On Thursday, June 13, 2024 at 5:08:29 PM UTC-4 jkn wrote:
>
>> I never used TECO on a PDP (PDP/11 in my case), but I did use PMATE 
>> ('Michael Aaronson's Text Editor, IIRC) on an early S-100 Z80 computer, and 
>> that was heavily 'inspired' by TECO, I believe. working with the 'command 
>> syntax' was great fun, as was customising the editor to work with your 
>> graphics card driver.
>>
>>
>> On Thursday, June 13, 2024 at 8:45:01 PM UTC+1 tbp1...@gmail.com wrote:
>>
>>> After reading the link, I see I never got near anything like TECO.
>>>
>>> On Thursday, June 13, 2024 at 3:17:49 PM UTC-4 David Szent-Györgyi wrote:
>>>
>>>> TECO for the PDP/8 was available under OS/8. The Wikipedia article on 
>>>> TECO <https://en.wikipedia.org/wiki/TECO_(text_editor)> is a nice 
>>>> summary. There you can find links to Web pages on TECO, including one by 
>>>> the originatoer of TECO and the GitHub repository for TECOC, a 
>>>> reimplementation in C for Windows, macOS, and LInux. 
>>>>
>>>>

-- 
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/088d4f3c-f696-499f-a0e4-87f48377d36cn%40googlegroups.com.

Re: Hex File Snooper

[David Szent-Györgyi]

The original IBM PC was a quick-and-dirty design; performance was not a 
goal. 

FORTH is an opposite: Simplicity and flexibility are at the heart of its 
design, with carefully considered access to assembly language where 
required for performance or access to bare metal. The design requires 
trading conventional convenience for that. More conventional schemes for 
access to bare metal involve complex, fragile, non-portable and expensive 
platform development tools. Given engineering talent able to use FORTH, 
FORTH makes sense. The wide-open architecture of FORTH requires discipline, 
documentation, and careful management to write code that not only runs but 
can be read and maintained. 

I haven't made a career of embedded systems work, but I have done a few 
small projects of that sort, and I think that FORTH holds its own in the 
right hands. 

-- 
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/45bc7b8a-db98-4143-8fc0-fc932272306en%40googlegroups.com.

Re: Hex File Snooper

[David Szent-Györgyi]

TECO for the PDP/8 was available under OS/8. The Wikipedia article on TECO 
 is a nice summary. There 
you can find links to Web pages on TECO, including one by the originatoer 
of TECO and the GitHub repository for TECOC, a reimplementation in C for 
Windows, macOS, and LInux. 

-- 
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/8b7fbdde-6e13-4f65-8de9-cded0a576a44n%40googlegroups.com.

Re: Hex File Snooper

[David Szent-Györgyi]

The TECO text editor was designed to edit files that were too large to fit 
in memory. I used TECO on a PDP8/e minicomputer; the 8/e used 12-bit words; 
memory was addressed in 128-word pages and 4096-word fields. 

The original implementation of Emacs was a set of "editor macros" written 
in TECO. Maybe this means that the old joke that every program accrues 
features to become more like Emacs has it wrong; every program grows to 
become more like TECO. *grin*

-- 
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/3e6211f8-b0ee-4539-af3f-a5f5ea3e0c1bn%40googlegroups.com.

Re: I just had successful eye surgury

[David Szent-Györgyi]

Heal, heal!

On Thursday, March 28, 2024 at 4:03:52 PM UTC-4 Edward K. Ream wrote:

> A vitrectomy 
> of
>  
> the rt eye. I'll be limited in what I can do for about a week.
>
> 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/a5fe3bb2-bef0-4f2d-998f-32f5a9be429fn%40googlegroups.com.

Some humor

[David Szent-Györgyi]

A message that applies to Leo and to other tools for literate programming: 

*"I don't want self-documenting code. I want self-coding documentation." *

I found it after yet another occasional stroll through the catalog of 
calligraphic buttons of Nancy Lebovitz . She 
makes custom buttons to order. She says that custom orders give her new 
buttons to sell. Decades into this small business, the catalog is extensive.

-- 
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/d71da2a0-ed95-4c06-b89b-3be3ba31c3b4n%40googlegroups.com.

Re: Quick steps on how I got Leo working on Windows 11

[David Szent-Györgyi]

On Saturday, October 14, 2023 at 10:01:44 AM UTC-4 tbp1...@gmail.com wrote:

I'd say this is how to get it installed using Anaconda, which apparently is 
not the same as using Python from python.org.  For one thing, using 
python.org you don't have to install build tools to build pyqt5 (and note 
that Leo will also work with pyqt6) - pip installs a pre-built package. 


The Anaconda distribution of Python  is aimed 
science-related computing - data science, including life science and 
bioinformatics - in which Python sees much use. It addresses the headaches 
of packaging Python code and applications, and comes with a much-expanded 
set of Batteries Included. 

-- 
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/c50ccb35-2ee5-40f1-8f0a-636fba06b3dcn%40googlegroups.com.

Re: ENB: Ahas re paste-retaining-clones

[David Szent-Györgyi]

On Sunday, August 13, 2023 at 5:31:16 AM UTC-4 Edward K. Ream wrote:

Today is my 74th birthday. This Engineering Notebook post is my birthday 
present to myself.


Have the happiest of  birthdays. Thank you for working on your birthday and 
giving a gift to us all. 

-- 
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/510e2cf7-cf7c-482e-acfb-42af7196b0b4n%40googlegroups.com.

Re: ChatGPT Helpful In Translating Tables

[David Szent-Györgyi]

On Thursday, June 22, 2023 at 11:22:20 AM UTC-4 tbp1...@gmail.com wrote:

Even copying selected text out of a pdf file can be unpleasant.  Often 
there will be no newlines, so words may run together when they were 
visually separated by a line break.


Yes, indeed. Part of my day job involves serving as acquisitions editor for 
content for my employer's Web site, and I must pull content from PDFs from 
all over the world, some of them produced by companies whose workers' 
native language is not in Roman letters. Fishing data out of PDFs is more 
of a toothache than a headache! 

-- 
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/3a809cb9-01b7-49d2-aa81-480e030339e4n%40googlegroups.com.

Re: ChatGPT Helpful In Translating Tables

[David Szent-Györgyi]

On Sunday, June 18, 2023 at 11:06:30 PM UTC-4 tbp1...@gmail.com wrote:

Very thoughtful piece by Jon Udell - Why LLM-assisted table transformation 
is a big deal 

.

 
In my day job, I have to pull useful items out of PDFs  - pictures, text, 
tables. PDFs often make this difficult - because of password-protected 
access, and because the information that renders as neatly organized text 
and tables when printed or displayed in a viewer is not neatly organized - 
the data in the PDF requires rearrangement. Jon Udell's article mentions 
this without discussing the specifics of the articles he processes. 

It is true that tools like ChatGPT are trained on text and as such most 
likely to work on text, but they do not reason about non-text. I would 
argue that a PDF is non-text, and as such, recreating neatly organized text 
and tables is error-prone; if we really value the facts in a technical 
publication, we need to start with suitable source, which probably needs 
carefully done markup created by experts in the subject matter of the 
publication. 

I would not trust a complex table produced by ChatGPT, since it is not only 
not a subject matter expert, it cannot reason as a human being can when 
making sense of such a document. 

I don't know what to say about the extraordinary domain of software that 
produces those PDFs. How many of those software applications incorporate 
features meant to allow exploration of the structure of a document? This 
sounds to me like the sort of job for which Leo is well-equipped! 

-- 
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/78528da2-3174-4437-af37-2d763dc28bcfn%40googlegroups.com.

Re: Pyspread - a spreadsheet where each cell can be a Python expression

[David Szent-Györgyi]

On Tuesday, May 2, 2023 at 1:04:27 PM UTC-4 jkn wrote:

There was a much older 'python in a spreadsheet' program, created by 
Resolver Systems. I followed it with interest, they tried to create a 
commercial product out of it but failed.


That product used IronPython - an alternate implementation of Python 
implemented on the Dynamic Language Runtime for .NET 
. Resolver Systems is long gone, but IronPython is 
still out there, though development by its tiny team is slow - the current 
release added Python3 features, and was released early in 2023; it is 
closest to CPython 3.4. 

Unlike CPython, IronPython has no Global Interpreter Lock ("GIL"), and it 
used unicode for strings long before that was sorted out in CPython. 
Differences between IronPython and CPython make IronPython a dialect, but  
one well-suited to multi-threaded projects. It is an excellent "glue 
language" as it is an interpreter with a JIT compiler; it has full access 
to .NET  as well as to Win32; it also has access to libraries accessible 
through CTypes. In my day job, I write complex macros in IronPython for an 
application that controls exotic hardware; I prefer the IronPython 
read-eval-print-loop to compiling code through a heavyweight IDE and 
compiler that Get In My Way. 

Michael Foord and Christian Muirhead, who were with Resolver Systems, wrote an 
excellent book on IronPython 
. While its content has 
not been updated to address the current release, its exploration of .NET 
specifics makes it worth reading for the newcomer to IronPython. 

-- 
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/68157a41-abfa-4983-bda5-1ddd0edc8b6dn%40googlegroups.com.

Re: Leo 6.7.3 coming soon

[David Szent-Györgyi]

On Monday, April 10, 2023 at 8:04:23 AM UTC-4 Edward K. Ream wrote:

The fix appears to be straightforward, but it points out the folly of 
rushing to release major changes.


If it is difficult for you, who know know Leo's code base so well,  to keep 
in mind the complex interactions of that code base with the wide range of 
inputs generated by Leo's users, would the capabilities of Hypothesis 
 be of help to you? Would 
they be of help to others who lack understanding of those interactions? 

In case it is useful: some time ago, I posted about property-based testing, 
Hypothesis, and Pydantic 
. I 
cannot speak from experience as to effectiveness, the degree of clutter it 
would add to the code base, or the effort required to retro-fit Leo's code 
base, documentation, and sample outlines, but its benefits seem really 
attractive at first reading. 

-- 
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/643b403d-2bb4-4364-b16a-e9587dbb5ff9n%40googlegroups.com.

Re: Eye surgery tommorrow

[David Szent-Györgyi]

The surgery appears to have gone well. The eye is blurry, but apparently 
that's normal. I'll see my eye doc later today.


Best wishes! 

-- 
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/1c36595a-7f00-4af7-a39c-147684f17ac2n%40googlegroups.com.

Re: Pydantic - Type Hints For Validating Data

[David Szent-Györgyi]

It does sound interesting. It even supports "custom" (user-defined) types. 

A plug-in for Pydantic supports Hypothesis 
, «a Python library for 
creating unit tests which are simpler to write and more powerful when run, 
finding edge cases in your code you wouldn’t have thought to look for. It 
is stable, powerful and easy to add to any existing test suite. It works by 
letting you write tests that assert that something should be true for every 
case, not just the ones you happen to think of.»

-- 
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/252da855-1da7-4a7a-b7c2-24e3fe4f5ed1n%40googlegroups.com.

Re: New Leo "Package" File Format?

[David Szent-Györgyi]

Now this is interesting!  I wasn't considering huge image files, most just 
"ordinary" ones like photos, screenshots, or graphs that would be common 
images to want to include with, for example, a markdown document.  I'll 
read up on your links.  Thanks!


A consideration that didn't occur to me initially: the archive file format 
might have a limit on file size. The archive file library might also have a 
limit on that. The original ZIP file format limited archive size to 4 GB; I 
read that the ZIP64 format extension 
 raises that limit 
to 16 exabytes(!), and that Windows Vista and its successors build support 
for ZIP64-sized archives into Windows Explorer/File Explorer, and that 
macOS Sierra's built-in Archive Utility does not support ZIP64. 

Limits imposed by the file system can also be a problem. NTFS has no 
issues, but FAT32 limits file size to 4GB 
; I 
reformat FAT32 thumb drives drives to exFAT format, which lifts that to 
2^64-1 bytes (!). 

I don't want to think about cross-platform issues handling metadata such as 
NTFS attributes. 

I find that Windows 7 Windows Explorer and Windows 10 File Explorer clutter 
the Windows file cache when I ask them to process Zip archives of many 
hundreds of files or multiple gigabyte Zip files; basic operations slow to 
a crawl as a result, leading me to reboot Windows to recover the 
performance lost. I don't see such performance losses when I use 7-Zip 
instead. 

-- 
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/d691f7df-ad28-47df-82dd-ec43ba61b292n%40googlegroups.com.

Re: New Leo "Package" File Format?

[David Szent-Györgyi]

On Sunday, April 2, 2023 at 3:55:31 PM UTC-4 tbp1...@gmail.com wrote:

It seems to me that the main challenge would be for Leo to know just what 
to have in the package.  External files would be easy, but for example 
image files - how to know about them could be a real challenge.  I'm 
thinking that an outline could contain an @resources node, where the user 
could add anything that Leo didn't know about.  Not ideal, but perhaps 
necessary.

 
If you limit the scope of your work to compression and decompression of 
files, you might consider the libraries available for 7-Zip 
 - support for operating ystems other 
than Windows requires one of the variants described there. If you care 
about handling individual images or metadata from them, your task is much 
greater and a great challenge. 

I know something of that challenge, since I earn my living supporting 
software for life science microscopy. The number of formats used in that 
field is enormous, the requirements that must be during acquisition are 
distinct from those required thereafter for retrieval and analysis. 
Acquisition can involve a great number of individual images, enough that 
efficient writing to disk and reading back from disk can require a number 
of individual files, with a separate file that describes the entire 
dataset. 

Not that you would necessarily wish to use the formats designed for life 
science microscopy of the open source software available for reading and 
writing them, but here are links that might be of interest. 

OME-TIFF and OME-Big-TIFF: these support individual files with a great 
number of images; the OME-Big-TIFF variant supports files larger than four 
gigabytes. These, among others, are described under "OME Model and File 
Formats ". Information 
specific to OME-TIFF 
 is 
available; documentation for the OME-TIFF file structure 
 
is available also. 

Bio-Formats  is a standalone 
Java library for reading and writing life sciences image file formats. It 
is capable of parsing both pixels and metadata for a large number of 
formats, as well as writing to several formats. C++ code is available; I 
cannot speak to its condition and compliance with the current standard for 
the format. 

-- 
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/2df6065c-b24a-4400-af40-7b21f2b45c09n%40googlegroups.com.

Re: New Leo "Package" File Format?

[David Szent-Györgyi]

On Saturday, April 1, 2023 at 10:06:06 PM UTC-4 mys...@gmail.com wrote:

Having a zip file of all file assets would work as well with some 
implementation of a VFS by the program utilizing it I presume.


Given use of the appropriate codec, Zip files are easily packed or 
unpacked. 

The zlib codec  provides for superior compression, and is 
open source; it can be built for operating systems that do not bundle 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/e620c1a7-9c36-4b97-925c-2d2790397990n%40googlegroups.com.

Re: New Leo "Package" File Format?

[David Szent-Györgyi]

I have seen this function referred to as "Pack and Go" in other software 
that is widely used - SolidWorks, AutoCAD for starters. 

On Wednesday, March 29, 2023 at 1:48:09 PM UTC-4 tbp1...@gmail.com wrote:

> There is a perennial problem when one wants to give a  Leo outline to 
> someone else.  It happens when an outline contains external files, or 
> images to display, or any other data files that might be needed.  For 
> example, an article written with the Viewrendered3 plugin in mind, or for a 
> Sphinx document, must have its resources available or it cannot work.
>
> If the outline contains @file trees and these external files aren't 
> included in, e.g., a zip file, those files will be blank when the recipient 
> open the outline.  Yes, one can change the @files to @clean and re-save 
> them all.  But that is awkward, and negates the reason for having them be 
> @files in the first place.  
>
> Otherwise, one is forced to create a package file - usually a zip file - 
> that contains the outline and any required external files and 
> subdirectories.
>
> Current software, such as LibreOffice or Word, handle this by saving their 
> files as archives that contain all the external resources a document 
> needs.  I suggest that Leo needs a similar capability.  This would not 
> replace the existing Leo file format nor the existing outline save 
> commands.  It would add new *Save/Open Archive* commands.
>
> How might this work?  For a save, Leo would check each external file and 
> each @rst tree to get their paths, and then compress the external resources 
> and at-files into the archive.  For other resources, such as images in, 
> say, an *images* directory, An outline could have a new kind of node, 
> perhaps with an *@resources* headline, that specifies what subdirectories 
> and files to include.  Perhaps there could be more than one *@resources* 
> node in the document.
>
> To open an archive, Leo would expand the archive, which would create all 
> the directories and files. Then it would load the .leo outline contained in 
> the archive.
>

-- 
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/a30f5050-562b-43f1-8bba-88077223d8acn%40googlegroups.com.

Re: Programming By Contract for Python

[David Szent-Györgyi]

Down the rabbit hole we go: Hypothesis 
looks worth a look.


I know that some time back, I posted a message with links on Hypothesis and 
Pydantic. I haven't had time to explore them. In case the links are of use 
in the current dive down the rabbit hole: 
Tools of Interest: Hypothesis and Pydantic for Property-based Testing 
 

-- 
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/16fbea49-1d7c-44b1-b038-4e3485bd62b0n%40googlegroups.com.

Leo package as published on test.pypi.org

[David Szent-Györgyi]

I was looking for a pypy package of other software whose next release that 
has been in stuck in Alpha for a long time, and I ended up searching 
test.pypy.org , which is a repository for testing 
the publishing of Python packages. I found Leo there, but the Leo package 
there  is stale - it is Leo 6.4b2! 

If it makes no sense to maintain the package on test.pypy.org, shouldn't it 
be deleted?

Would it be a misuse of test.pypy.org to publish packages of development 
versions of Leo?

-- 
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/27084f2d-99b2-4116-b437-57900dd88bc0n%40googlegroups.com.

Re: OT? Beware of ChatGPT

[David Szent-Györgyi]

Thanks for your comments.

Imo, we have every right to consider the need to address manipulation by 
machines employing AI.  Period :-)

Yes, but I am academically-minded, and I expect to argue my case - because 
I do not expect to be believed unless I present a sound argument. 

-- 
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/533c99b2-0a91-412d-913c-caf2aa213e1cn%40googlegroups.com.

Re: OT? Beware of ChatGPT

[David Szent-Györgyi]

Bear with me. What follows is Not Brief. 

Understanding and deployment of the current wave of AI require 
understanding of two works of The Twentieth Century. One is Kurt Gödel's 
Incompleteness Theorems. The other is Alfred Korzybski's General Semantics, 
as explained by S. I. Hayakawa. 

Gödel's Incompleteness Theorems are a follow-on to the work of Alfred North 
Whitehead and Bertrand Russell, who in the the second decade of the 
Twentieth Century published *Principia Mathematica. *The Wikipedia article 
on that work  provides 
a useful summary: 

«*PM*, according to its introduction, had three aims: (1) to analyze to the 
greatest possible extent the ideas and methods of mathematical logic and to 
minimize the number of primitive notions, axioms, and inference rules; (2) 
to precisely express mathematical propositions in symbolic logic using the 
most convenient notation that precise expression allows; (3) to solve the 
paradoxes that plagued logic and set theory at the turn of the 20th century 
. . .»

That article continues: 

«There is no doubt that *PM* is of great importance in the history of 
mathematics and philosophy: as Irvine has noted, it sparked interest in 
symbolic logic and advanced the subject by popularizing it; it showcased 
the powers and capacities of symbolic logic; and it showed how advances in 
philosophy of mathematics and symbolic logic could go hand-in-hand with 
tremendous fruitfulness. Indeed, *PM* was in part brought about by an 
interest in logicism, the view on which all mathematical truths are logical 
truths. It was in part thanks to the advances made in *PM* that, despite 
its defects, numerous advances in meta-logic were made, including Gödel's 
incompleteness theorems.»

Gödel made public his Incompleteness Theorems in 1930. From the Wikipedia 
article on him : 

«These theorems ended a half-century of attempts, beginning with the work 
of Gottlob Frege and culminating in *Principia Mathematica* and Hilbert's 
Program, to find a non-relatively consistent axiomatization sufficient for 
number theory (that was to serve as the foundation for other fields of 
mathematics).
In hindsight, the basic idea at the heart of the incompleteness theorem is 
rather simple. Gödel essentially constructed a formula that claims that it 
is unprovable in a given formal system. If it were provable, it would be 
false. Thus there will always be at least one true but unprovable 
statement. That is, for any computably enumerable set of axioms for 
arithmetic (that is, a set that can in principle be printed out by an 
idealized computer with unlimited resources), there is a formula that is 
true of arithmetic, but which is not provable in that system.»

The Incompleteness Theorems prove that any system of logic has one of two 
flaws: if it is internally consistent, there is a truth that cannot be 
derived within it; if it is universal ("always provable"), it must 
mishandle at least one proof, producing an incorrect result. 

*This applies to digital computer programs, which implement machines; such 
machines are by definition abstracted constructs of statements that fall 
within a system of logic. *What sense we are to make of such machines needs 
to be discussed, since those machines' workings are complex and beyond the 
examination of human beings. 

Hayakawa's book *Language in Thought and Action *was published in 1949, and 
intended to provide a toolkit for defense against manipulation via forms of 
communication that include propaganda, advertisement,  and popular 
entertainment. Hayakawa reformulates findings of Alfred Korzybski's General 
Semantics: he calls upon the reader to distinguish between their internal 
model of the world and the world itself, with the admonition that "the map 
is not the territory".  He presents the idea of a "ladder of abstraction" 
in which a rung is more abstract than the one below it. He argues that 
manipulative communications - in propaganda, in advertisement, in popular 
culture - are more easily applied at higher levels of abstraction. He 
advises the reader to beware such manipulation, and to promote more honest 
and productive communication by pitching discussion at lower rungs when 
possible. 

The founders of General Semantics were beings of their time and place, 
describing their work as a theoretical and a practical system whose 
adoption can reliably alter human behavior in the direction of greater 
sanity. Looking back on that from 2023, one can see arrogance in their a 
position. One can wonder whether they were aware of the implications of 
Gödel's Incompleteness Theorems for their own system of logic. 

That said, it is worth recalling Hayakawa's teachings in the present 
discussion. Hayakawa wrote about human constructs. ChatGPT is a machine, an 
abstraction with assumptions and logic that are not open to inspection, one 
that 

Re: PyScript - Real Python In The Browser

[David Szent-Györgyi]

An article on change coming with an upcoming update to the Dart language 
 mentions 
that there is as yet no standard for garbage collection for WebAssembly. A 
group working on that has been chartered 
.  
>From the article:

"Following the release of Dart 3, the next significant milestone for the 
language is likely to be support for compiling Dart code into WebAssembly 
(Wasm), which will allow Flutter Web apps to run as native code in 
browsers. That effort requires cooperation from the W3C and browser vendors 
to add support for garbage collected languages (like Dart) to Wasm by way 
of the WasmGC extension 
."

>

-- 
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/17b72d48-2f7d-4170-890c-5b2422177fcbn%40googlegroups.com.

Re: Leo deployment on Windows - past story, current story

[David Szent-Györgyi]

*On creating a shortcut to the .leo configuration directory. *This applies 
to Windows 10; I have yet to test it on Windows 11. 

To create a shortcut to the hidden "configuration directory" in one's home 
folder, configure File Explorer to show hidden files, right-click on the 
*.leo* folder in one's home folder, choose "Create Shortcut" from the 
context menu, then place the shortcut as needed, then configure File 
Explorer to not show hidden files. 

I am accustomed to creating shortcuts for backing up installed 
applications, including the folder that contains the application, the 
folder for housekeeping information that is shared by all users, and the 
folder for user-specific housekeeping information. For that, I typically 
create shortcuts to each of these folders, using Windows 10's File 
Explorer's context menu entry "New->Shortcut". That approach fails when 
creating shortcuts to a folder that (a) is in one's home folder and (b) has 
a name that begins with a dot, thereby calling for special treatment. For 
such a folder, "New->Shortcut" creates a shortcut that does not work. 

I make the shortcut to the *.leo* folder apply to every user by editing the 
shortcut's properties, and replacing the *C:\username* in the *Target* 
field with *%HOMEPATH% *. %HOMEPATH% is a Windows environment variable that 
is evaluated when the shortcut is used rather than at the time of its 
creation. 
On Saturday, May 22, 2021 at 11:18:23 PM UTC-4 David Szent-Györgyi wrote:

> I've written 
> <https://groups.google.com/g/leo-editor/c/U5u76-Zbi10/m/XhY4_Al1AQAJ>of 
> the need to discuss the deployment stories on Windows, macOS, various Unix 
> distributions, various Linux distributions. Before this discussion begins, 
> one must consider that there are multiple implementations of Python. For 
> the moment, I'm limiting my comments to CPython running native on Windows. 
>
> *Context: *The last time I worked on an installer for Leo or any other 
> package, Leo 4.3 was the current release, and came with a single-file 
> installer built using NSIS. That installer was for Windows only. NSIS as it 
> stood then was flexible as it saw use in many projects, but its use was 
> somewhat arcane. My work was aimed at supporting per-user installations of 
> CPython as well as shared installations, and installing per-user and 
> system-wide installations of Leo on top of system-wide installations of 
> CPython; my hope was that the two flavors of per-user support would ease 
> the work of side-by-side testing of multiple CPython releases and multiple 
> Leo releases. By the time I had something to share with Edward, Windows 
> Vista had brought the headaches of UAC dialog boxes that were the user 
> interface for tightened security, and I had not touched those. Edward was 
> already burdened by maintenance of the Windows XP-savvy installer script 
> that NSIS compiles. It's possible that my work only promised more 
> installer-related work for him, but it's Edward's right to comment on that 
> if he wishes to. 
>
> Contrast that with the current requirements under Windows:
>
>- 
>
>CPython;
>- 
>
>Qt, whose publisher has restricted access to the LTS releases to 
>paying customers, which forces non-commercial users to track development 
>versions that are released every six months; 
>- 
>
>Git, or another source code management tool that speaks enough Git to 
>pull from GitHub; 
>- 
>
>Leo's devel branch on GitHub, which mingles Leo's core with Leo's 
>plugins, some of which are clearly essential to leo as it stands.
>
> What are the installer stories for each of these? 
>
>- 
>
>CPython comes with an installer,  one that supports setups for the 
>individual user and for all users. 
>- 
>
>The changes to Qt distribution are no gift to a project like Leo, if 
>my guess about the limits to Edward's ability to scale are as accurate as 
>my knowledge of my own. 
>- 
>
>Git, I can't speak to. It has arrived since I had spare time to 
>develop software, even limiting development to my narrow requirements.  
>- 
>
>Following Leo's devel branch on GitHub seems to require following 
>discussions among its developers here on Leo-editor. The supportive 
>responses of the people here are a major plus. 
>
> What are the usage stories for each of these? 
>
> *Cpython.* The current release of CPython is 3.9.5. Its installer 
> supports installation for the current and for all users. It supports access 
> to the pip <https://pip.pypa.io/en/stable/> manager for packages on the 
> Python 
> Package Index <https://pypi.org/> ("

Re: Repairing Windows System Files

[David Szent-Györgyi]

On Sunday, June 12, 2022 at 3:35:17 PM UTC-4 tbp1...@gmail.com wrote:

> You cannot get help on, e.g., "/cleanup-image", or even learn that it 
> exists, unless you prefix the help command with the "/online" .  It seems 
> that dism can do so many things that the help system had to become 
> complicated, too.
>

You mean that one has to enter the command *dism /?*

then 
*dism /online /?*
then 

*dism /online /cleanup-image /?*The same is true of PowerShell's built-in 
help: one has to drill down, one argument at a time. One must know which 
argument to give at each step. That would be easier if Microsoft chose more 
wisely when coining names!

-- 
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/304c92a8-5793-45cb-8af8-375b19c215d2n%40googlegroups.com.

Re: Repairing Windows System Files

[David Szent-Györgyi]

On Sunday, June 12, 2022 at 9:26:35 AM UTC-4 David Szent-Györgyi wrote:

Links of interest: 
> Repair a Windows Image 
> <https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/repair-a-windows-image>;
>  
> includes dism usage for checking whether an image is repairable, for 
> detecting corruption as well as for making repairs
> Windows Imaging Format 
> <https://en.wikipedia.org/wiki/Windows_Imaging_Format>, on Wikipedia 
> VHD (file format) <https://en.wikipedia.org/wiki/VHD_(file_format)>, on 
> Wikipedia, covering VHDX as well
> DISM Overview 
> <https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/what-is-dism>,
>  
> Microsoft's documentation, not written for the general reader
>

I add another link, which should come first in the list: 

Use the System File Checker tool to repair missing or corrupted system files 
<https://support.microsoft.com/en-us/topic/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system-files-79aa86cb-ca52-166a-92a3-966e85d4094e>,
 
which covers Windows Vista through Windows 10. This is a task-centered 
procedure that explains just enough of the purpose of each command that one 
enters. The article makes no mention of Windows 11, alas.  

-- 
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/c9b31d84-8002-4e10-beb3-18a4fa243e61n%40googlegroups.com.

Re: Repairing Windows System Files

[David Szent-Györgyi]

On Sunday, June 12, 2022 at 10:03:54 AM UTC-4 tbp1...@gmail.com wrote:

> The help text for dism is mostly unintelligible to ordinary computer 
> users.  You would have to know a lot of Microsoft-specific OS details to 
> make sense of most of it.  The only help command likely to be helpful for 
> most of us is
>
> dism /online /cleanup-image /?
>

I am not in front a WIndows computer, so I cannot see the response to that 
command. Am I correct that the response is display of the options for 
performing cleanup or recovery operations on the operating system as 
installed on the computer that is providing the command line?

-- 
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/f764db0c-8c59-48df-9446-3594e96ccbden%40googlegroups.com.

Re: Please upvote Thomas's gf4 project

[David Szent-Györgyi]

>
> Youngsters have no idea what programming life was like in the "horse and 
> buggy" days 40 or 50 years ago:
>
> - Feeble hardware.
> - Feeble programming tools: We worked in assembler or C.
>   No git, python, numpy, matplotlib and leo.
> - No internet! No google, github and online communities!
> QQQ
>
> 40 or 50 years ago the challenges were way different, but we had the same 
> kind of engineering fun seeing what was possible.
>

In 1980 I was briefly involved in a project aimed at writing software to 
help in learning or reviewing trigonometry. The software was to run on the 
Atari 800 microcomputer, which offered sophisticated graphics for video 
displays, supporting mixing of text and graphics and offering hardware 
support for overlay of sprites along with hardware for detection of 
collisions between sprites and the rest of the displayed field. All that 
relied on custom chips built to run alongside the computer's 6502 
microprocessor; controlling it required careful programming. The machine 
featured a maximum of 48 KB of RAM and a floppy disk drive. 

The project's software was written in Forth, which provided a programming 
language, use of assembly language when needed, and a development 
environment that could fit on so small a machine. Forth had for many years 
an important niche in industrial control and embedded computing. 

Links of interest: 
Forth (programming language) 
, 
on Wikipedia. 
Gforth, GNU Project's implementation 
Win32Forth 
Documentation and books
Gforth user manual 

Starting Forth , by Leo Brodie, 
updated in 2003 by FORTH, Inc. 
Thinking Forth: A Language and Philosophy for Solving Problems 
, 
by Leo Brodie 

-- 
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/499730d0-403f-440b-94f5-3144177f80d7n%40googlegroups.com.

Re: Repairing Windows System Files

[David Szent-Györgyi]

The terminology used with Microsoft's *dism* gives specific new meanings to 
terms widely used in broader contexts. Keep in mind these specific 
meanings: 

WIM file a "Windows image" file, used for deployment of Windows Vista and 
more recent versions of Windows; extension .wim
VHD and VHDX files "Virtual hard disk", other types of file containing disk 
images; extensions .vhd and .vhdx
/Online targets the installation of Windows that is in use
/Image targets a specified WIM file , VHD, or VHDX file. 
store from British usage, a place in which items are routinely kept; 
distinct from the North American usage for a shop)

Links of interest: 
Repair a Windows Image 
;
 
includes dism usage for checking whether an image is repairable, for 
detecting corruption as well as for making repairs
Windows Imaging Format 
, on Wikipedia 
VHD (file format) , on 
Wikipedia, covering VHDX as well
DISM Overview 
,
 
Microsoft's documentation, not written for the general reader

-- 
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/b40a7658-0a29-4448-8b2c-41db489fb24fn%40googlegroups.com.

Re: Repairing Windows System Files

[David Szent-Györgyi]

On Saturday, June 4, 2022 at 5:57:21 PM UTC-4 tbp1...@gmail.com wrote:

> I don't know when to prefer one over another.  I run sfc first, perhaps 
> because it's easier to remember the command line.  If problems are found 
> and claimed to be fixed, it's probably good to repeat the scan.
>
> I mention these utilities even though they are not Leo-specific, because 
> it's hard to discover them online and I have found them helpful.
>

If my reading of the explanation below is correct, it is best to use *dism* 
before using *sfc*. The following is an excerpt from Using the Deployment 
Image Servicing and Management Tool (DISM) to repair the Windows System 
Store 

.

*The System File Checker tool can be used to repair corrupted system files. 
For more information on how to use the tool, refer to the following 
Microsoft article: Use the System File Checker tool to repair missing or 
corrupted system files . The 
System File Checker tool compares those files against the .wim store that 
is saved on the system (not to be confused with the Windows Software Store 
app where you can purchase software for Windows). If this store is 
corrupted, the repairs may not resolve the problems that the system is 
having. The DISM tool has some modifiers that can scan and repair the .wim 
store based on parent copies stored on Microsoft’s update servers, making 
it useful to run in conjunction with a system file check.*

-- 
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/25dc0b8d-08db-4ac1-8d63-3f45bfc7bdb3n%40googlegroups.com.

Re: Why specs matter (On The Two Types Of Developers)

[David Szent-Györgyi]

Rereading that "Dive into Mark" posting again after many years, with my US 
State's primary election coming tomorrow, my thoughts go in another 
direction: I think of parallels with respect to the law. 

For "a**holes" read "lawyers". For "morons" read "legislators". 

Reading Tom's distinction between "requirements" and "specifications", I 
think that those who believe the US Constitution to be a living document 
focus on requirements, while the Originalists focus on specifications. 

*sigh*

>

-- 
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/db9c68eb-ca42-4317-bdbc-00cff812e796n%40googlegroups.com.

Re: Managing Python 2.7 Code In Leo

[David Szent-Györgyi]

On Monday, January 17, 2022 at 12:57:12 PM UTC-5 David Szent-Györgyi wrote:

> For more straightforward scripting engine uses, there's always Lua, though 
> the 
>> fork of Lua done to implement a JIT <http://luajit.org> trails the main 
>> implementation <https://www.lua.org>. There is an interesting offshoot 
>> of the language that is aimed at systems programming <https://nelua.io>. 
>>
>
On Monday, January 31, 2022 at 12:04:25 PM UTC-5 tbp1...@gmail.com wrote:

> Ah, Lua!  I think I last tried it back before I had even encountered  
> Python, but back then I didn't really have a need for it. Maybe I should 
> revisit it.  I would want at least some equivalent for numpy and a gui 
> system like Qt.  I gather that wxWindows is a possibility among others.
>

>From a Web search for the words "Lua" and "Numpy":

Lua Equivalent for NumPy and SciPy? - Stack Overflow 
<https://stackoverflow.com/questions/7786070/lua-equivalent-for-numpy-and-scipy>

Convert Torch Lua into Numpy Python - Stack Overflow 
<https://stackoverflow.com/questions/37141841/convert-torch-lua-into-numpy-python>

That spurs a search for the words "Torch" and "Lua", which is fruitful, if 
frustrating in the end. From the Wikipedia article on Torch 
<https://en.wikipedia.org/wiki/Torch_(machine_learning)>: 
Torch is an open-source machine learning library, a scientific computing 
framework, and a script language based on the Lua programming language. It 
provides a wide range of algorithms for deep learning, and uses the 
scripting language LuaJIT <https://en.wikipedia.org/wiki/LuaJIT>, and an 
underlying C implementation. It was created at IDIAP at EPFL. As of 2018, 
Torch is no longer in active development. However PyTorch 
<https://en.wikipedia.org/wiki/PyTorch>, which is based on the Torch 
library, is actively developed as of June 2021.

PyTorch has language bindings for Python and for C++. I read that there is 
information available on calling C++ functions from Lua, but I don't know 
how easy that is, given the reliance of C++ on mangling names. 

There's also SciLua <https://scilua.org>, which I read is most easily 
installed with the ULua distribution of LuaJIT <https://ulua.io>. I'm not 
sure that falling back on a specific distribution of a minority 
implementation of Lua promises greater ease than pursuing a minority 
implementation of Python, alas. 

More on Torch below. 

>From Torch | Scientific computing for LuaJIT. <http://torch.ch/>:
Torch is a scientific computing framework with wide support for machine 
learning algorithms that puts GPUs first. It is easy to use and efficient, 
thanks to an easy and fast scripting language, LuaJIT, and an underlying 
C/CUDA implementation.

A summary of core features:

   - a powerful N-dimensional array
   - lots of routines for indexing, slicing, transposing, …
   - amazing interface to C, via LuaJIT
   - linear algebra routines
   - neural network, and energy-based models
   - numeric optimization routines
   - Fast and efficient GPU support
   - Embeddable, with ports to iOS and Android backends


>From Lua and Torch - Artificial Inteligence - GitBook 
<https://leonardoaraujosantos.gitbook.io/artificial-inteligence/appendix/lua>
:
Torch is a scientific computing framework based on Lua with CPU and GPU 
backends. You can imagine like a Numpy but with CPU and GPU implementation. 
Some nice features:

   - Efficient linear algebra functions with GPU support
   - Neural Network package, with automatic differentiation (No need to 
   backpropagate manually)
   - Multi-GPU support
   
Lua Torch :: Anaconda.org <https://anaconda.org/alexbw/lua-torch>

Get Lua running with Torch on Windows 10 with limited Admin rights - Stack 
Overflow 
<https://stackoverflow.com/questions/48277220/get-lua-running-with-torch-on-windows-10-with-limited-admin-rights>

Lua & Torch Tutorial - luckylwk.github.io 
<http://luckylwk.github.io/2015/05/23/lua-torch/>

-- 
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/050eb94c-e11b-4ee1-8ca1-7380dd9b97f7n%40googlegroups.com.

Re: Managing Python 2.7 Code In Leo

[David Szent-Györgyi]

On Monday, January 17, 2022 at 5:18:15 PM UTC-5 tbp1...@gmail.com wrote:

> On Monday, January 17, 2022 at 12:57:12 PM UTC-5 David Szent-Györgyi wrote:
>
>> Jython support for Python3 is planned 
>> <https://www.jython.org/jython-3-mvp> and roadmapped 
>> <https://www.jython.org/jython-3-roadmap>. 
>>
>
> Yes, and have you noticed the huge amount of work those plans will 
> entail?  I don't see it getting competed in the near future, I'm sorry to 
> say. 
>

Like you, I thought those plans call for a lot of work, and completion 
might be some time off. Part of that might be the ever-growing complexity 
of Python3, which is accruing features that cannot be implemented simply, 
thereby complicating maintenance of minority implementations such as Jython 
and IronPython. 

I greatly admire the tasteful engineering that I see in the choices that 
Guido van Rossum made in earlier releases. For example, an operating system 
that supports multi-tasking well relieves the need for multi-threading. 

For more straightforward scripting engine uses, there's always Lua, though the 
fork of Lua done to implement a JIT <http://luajit.org> trails the main 
implementation <https://www.lua.org>. There is an interesting offshoot of 
the language that is aimed at systems programming <https://nelua.io>. 

Yeah, yeah, I know, I'm wandering far afield, sorry for trespassing. I'll 
come quietly, officer! 

-- 
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/ba0874f3-3b2c-4231-bff6-53cf59345717n%40googlegroups.com.

Re: Managing Python 2.7 Code In Leo

[David Szent-Györgyi]

On Monday, January 17, 2022 at 6:01:43 AM UTC-5 Edward K. Ream wrote:

> On Sun, Jan 16, 2022 at 3:08 PM tbp1...@gmail.com  
> wrote:
>
>> The project is a Tomcat web application that uses mixed java and Jython.  
>
>
> VSCode probably allows you to use python 2 for some projects. I am not 
> going to support python 2 in Leo, but a plugin could do so.
>

Jython  is one of the languages in which macros 
are written for the ImageJ  image processing and 
analysis software, and important as such. Jython support for Python3 is 
planned  and roadmapped 
. 

Another significant implementation of Python for which Python3 compliance 
is a work in progress is IronPython , which runs 
native on the Dynamic Language Runtime for .NET. The implementation is open 
source, source code for IronPython2, IronPython3, and the Dynamic Language 
Runtime is on GitHub . The current forum 
for for developers and users a Gitter discussion group 
. 

I work on ImageJ macros, using Jython when I can. I work with .NET-based 
applications for which IronPython is the macro language.  Those macros are 
short enough that they don't need an outliner, and the host applications 
provide the IDE. 

-- 
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/2126192c-0c21-4d86-8129-d98f52e7836dn%40googlegroups.com.

Re: Personal take-aways from a rust video

[David Szent-Györgyi]

The earlier edition that I saw doesn't give descriptions of the algorithms. 
Its descriptions of the data structures might be of interest. 

On Thursday, November 4, 2021 at 9:39:39 AM UTC-4 Edward K. Ream wrote:

> On Wed, Nov 3, 2021 at 10:40 AM David Szent-Györgyi  
> wrote:
>
>>
>>
>> On Sunday, October 31, 2021 at 9:22:11 AM UTC-4 tbp1...@gmail.com wrote:
>>
>>> Very large collections are best thought of a graphs, IMO, because there 
>>> are usually many types of connections between them - depending of course on 
>>> the type and intended use of the entries.  However, treelike *views* into 
>>> the data are very often much better for a human to work with.  With large 
>>> collections, it can take a long time to create a view from scratch, so it 
>>> is helpful to create the most important ones in advance.  In the database 
>>> world, these creation of such views are helped by indexes, temporary 
>>> tables, and database views.  In Python (and other languages that have 
>>> native map structures), dictionaries can play that role.
>>>
>>> With increasing size, finding something becomes harder.  It may well be 
>>> that for Leo, once it can work with very large numbers of nodes, that we 
>>> will need new and faster ways to find items and peruse them.
>>>
>>> Another issue of size is the amount of data that a single node can 
>>> hold.  I recently crashed Leo by trying to read some 80 megabytes of text 
>>> into the body of a node.  I was curious how fast it could do a search and 
>>> replace on that much data, but I didn't find out because of the crash.  Of 
>>> course, we are currently limited by Qt's capabilities, and Leo may never 
>>> need to do such a thing, so it may not matter.
>>>
>>
>> Decades ago, Project Xanadu 
>> <https://en.wikipedia.org/wiki/Project_Xanadu> was founded to create a 
>> scalable datastore suitable for hosting published information linkable in 
>> forms developed by end users, with separation of the back-end mechanisms of 
>> storage, publication, and collection of micropayments from the front end of 
>> presentation. While the project did not come to fruition as desired by 
>> founder and computer industry gadfly Ted Nelson, the Project's work was 
>> influential. Nelson was the first person to conceive of the idea of 
>> hypertext - the term is his. 
>>
>
>  
>
>> The mathematics underlying the back-end storage might be of interest; 
>> those are described in Literary Machines 
>> <https://en.wikipedia.org/wiki/Literary_Machines>; a reprint is 
>> available from Nelson <https://xanadu.com.au/general/faq.html#6>; more 
>> on them might be found through Xanadu Australia - see link below. 
>>
>
> Thanks for this. The book appears to be back in print, but out of stock. 
> I'll get a copy asap.
>
> 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/7d5ac624-688e-4aae-a419-381a1276911dn%40googlegroups.com.

Re: Personal take-aways from a rust video

[David Szent-Györgyi]

On Sunday, October 31, 2021 at 9:22:11 AM UTC-4 tbp1...@gmail.com wrote:

> Very large collections are best thought of a graphs, IMO, because there 
> are usually many types of connections between them - depending of course on 
> the type and intended use of the entries.  However, treelike *views* into 
> the data are very often much better for a human to work with.  With large 
> collections, it can take a long time to create a view from scratch, so it 
> is helpful to create the most important ones in advance.  In the database 
> world, these creation of such views are helped by indexes, temporary 
> tables, and database views.  In Python (and other languages that have 
> native map structures), dictionaries can play that role.
>
> With increasing size, finding something becomes harder.  It may well be 
> that for Leo, once it can work with very large numbers of nodes, that we 
> will need new and faster ways to find items and peruse them.
>
> Another issue of size is the amount of data that a single node can hold.  
> I recently crashed Leo by trying to read some 80 megabytes of text into the 
> body of a node.  I was curious how fast it could do a search and replace on 
> that much data, but I didn't find out because of the crash.  Of course, we 
> are currently limited by Qt's capabilities, and Leo may never need to do 
> such a thing, so it may not matter.
>

Decades ago, Project Xanadu  
was founded to create a scalable datastore suitable for hosting published 
information linkable in forms developed by end users, with separation of 
the back-end mechanisms of storage, publication, and collection of 
micropayments from the front end of presentation. While the project did not 
come to fruition as desired by founder and computer industry gadfly Ted 
Nelson, the Project's work was influential. Nelson was the first person to 
conceive of the idea of hypertext - the term is his. The mathematics 
underlying the back-end storage might be of interest; those are described 
in Literary Machines ; a 
reprint is available from Nelson ; 
more on them might be found through Xanadu Australia - see link below. 

Web site of the original Project 
Web site *Xanadu Australia* *,* more recently 
updated and detailed than the original Project's Web site

-- 
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/0b427a15-944c-48e7-b73a-24a9916ef988n%40googlegroups.com.

Re: Wow: AlphaFold .ipynb and Google Colab

[David Szent-Györgyi]

On Wednesday, September 15, 2021 at 7:44:42 AM UTC-4 Edward K. Ream wrote:

> Namely the Nobelist Albert Szent-Györgyi. 
> 
>

The National Library of Medicine of the National Institutes of Health has a 
section of its Web site devoted to him 
. 

While I did not know Albert adult-to-adult, I grew up well aware of his 
work and the regard in which other scientists held him. My mother and 
father started their careers in basic research in his lab, and we all lived 
in the same town on Cape Cod, so his family and mine spent a lot of time 
together. 

His English was first-rate, an accomplishment since English and Hungarian 
are not related, and learning either is difficult for the person whose 
language is the other. I was fortunate to hear him give a lecture aimed at 
the generalist. 

Albert is worthy of note because receiving the 1937 Nobel in Physiology or 
Medicine did not lead him to cease conducting pioneering research. The 
above-linked article on the investigation of the molecular motor of muscle 
mentions groundbreaking work that his lab did in isolation during World War 
II. That work continued after the war, and moved with him to the United 
States. The loss of a wife and daughter to cancer led him to shift his 
focus to that disease when he was in his late seventies; he continued that 
work until shortly before his death at 93. 

His birth and upbringing in Habsburg Hungary, a country that had yet to 
leave behind prescientific structures and roots, along with his interest in 
basic research spurred in him an interest the lag in society's progression 
from a prescientific to a scientific basis. That, combined with his 
experience as a public figure during a turbulent period in Hungary, meant 
that he was privately and publicly involved in political matters. The 
enmity of the German Nazis and their Hungarian allies drove him into 
hiding. Later on, risk to his life earned through his opposition to the 
coming Communist order in Hungary led him to move to the United States. 
There, he continued to involve himself in politics - he was one of the 
eminent scientists who contacted the Kennedy Administration to educate it 
on the nature of nuclear weapons and the threat that they posed. 

When he reached seventy, when most retire, he wrote an essay that drew on 
all that, "Lost in the Twentieth Century" 
,
 
which opens the 1963 *Annals of Biochemistry*. In 1971, in his late 
seventies, he wrote another essay, "Looking Back" 
,
 
which is primarily about science but places it in context of life and 
conditions in the US. Anyone who share's Edward's broad perspective on 
science, technology, and society should look them up. 

-- 
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/2b207bd1-fb9f-41ac-a979-d253bd7fdf74n%40googlegroups.com.

Re: Wow: AlphaFold .ipynb and Google Colab

[David Szent-Györgyi]

AlphaFold is an extraordinary advance in the speed of the development of 
knowledge. Compare the rapidity of the understanding of the structure of 
COV-2 with the decades of labor required in the 1950s and 1960s for 
determination of the structure of myosin, the protein that is the largest 
constituent of skeletal muscle, as described in this article on the 
investigation of the molecular motor of muscle 
. 

(No, I'm not a biochemist; my parents were - they spent their working lives 
on the regulation of muscle contraction). 

-- 
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/a1ac5b03-0649-453f-99a7-c4921956cac8n%40googlegroups.com.

Re: Wow: AlphaFold .ipynb and Google Colab

[David Szent-Györgyi]

My day job is technical support for basic research in life science, and 
abuts drug discovery, which is targeted work. Below is a note that I sent 
to my colleagues at the end of 2020, when last winter's COVID outbreaks 
were at a terrible high. 

--- note begins ---
This is really interesting work in life science and work in drug discovery, 
driven by computation:

>From <
https://deepmind.com/blog/article/alphafold-a-solution-to-a-50-year-old-grand-challenge-in-biology
>:


*. . . In the meantime, we’re also looking into how protein structure 
predictions could contribute to our understanding of specific diseases with 
a small number of specialist groups, for example by helping to identify 
proteins that have malfunctioned and to reason about how they interact. 
These insights could enable more precise work on drug development, 
complementing existing experimental methods to find promising treatments 
faster.We’ve also seen signs that protein structure prediction could be 
useful in future pandemic response efforts, as one of many tools developed 
by the scientific community. Earlier this year, we predicted several 
protein structures of the SARS-CoV-2 virus, including ORF3a, whose 
structures were previously unknown. At CASP14, we predicted the structure 
of another coronavirus protein, ORF8. Impressively quick work by 
experimentalists has now confirmed the structures of both ORF3a and ORF8. 
Despite their challenging nature and having very few related sequences, we 
achieved a high degree of accuracy on both of our predictions when compared 
to their experimentally determined structures.*

An associated video:


--- note ends ---

>

-- 
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/63d30dbb-9f43-423c-a9db-4b80328a79dbn%40googlegroups.com.

Re: ENB: Converting unit tests for @shadow

[David Szent-Györgyi]

For data that is generated by hand or by plugins that are not centrally 
controlled, and for tests that are difficult to write, would the 
thoroughness of property-based testing be relevant? I wrote about that 
 some 
time back. 

-- 
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/2a03ea57-a506-4c1b-a6c8-ddaabe9fb464n%40googlegroups.com.

Re: Discuss: don't support Qt6 for Leo 6.4 final?

[David Szent-Györgyi]

Qt 6.2, which is planned to be the first QT6 release that supports "all 
widely-used Qt add-on modules", is scheduled for release at the end of 
September. Its first beta was released on 6th July. See the entry on the Qt 
Developers' blog . 

Note for anyone building Qt5 from source: partway through the lifetime of 
Qt 5.15 as a Long-Term Support release, The Qt Company has limited the 
access by non-paying customers to long-term support releases. As such, the 
KDE developers are collecting a series of patches to the last public 
release of KDE 5.15 . These 
patches are meant to address security issues, crashes, and functional 
defects. 
On Tuesday, July 6, 2021 at 2:20:31 PM UTC-4 Edward K. Ream wrote:

> Leo does not need to support Qt6 for Leo 6.4b1. Indeed, b1 is focused 
> solely on supporting the leoInteg project.
>
> Yes, Leo must eventually support Qt6. The question is, does Leo need to 
> support Qt6 for Leo 6.4 final? I am inclined to say no because that will 
> give us more time for testing. Otoh, perhaps we should just blast away.
>
> Your comments, please.
>
> 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/11c53fc3-31ff-4c47-974b-3c51337192a4n%40googlegroups.com.

Re: Python project delays changes to annotations

[David Szent-Györgyi]

Edward writes:

> I'm not worried. A few searches/replaces would likely do the trick.
>

That's good to hear. That tells me that you are sure that you can follow as 
mypy adapts to the changes that follow PEP 649. 

What interests me is that the Python development community has not settled 
on a solution to the problems posed by forward references. Those developers 
are *so* far from stupid that my first assumption must be that there's more 
to this than appears at the outsider's first glance. Such a first glance 
led me to suggest simply separating text annotations from the mechanisms 
described in PEP 649, but I am not an implementor of Python! 

-- 
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/25684c21-6756-47ed-9e27-e3e31af6f39fn%40googlegroups.com.

Re: Python project delays changes to annotations

[David Szent-Györgyi]

>From the article: 

> "a Python Enhancement Proposal (PEP) was created to postpone their 
> evaluation until they were needed. The PEP-described behavior was set to 
> become the default in the upcoming Python 3.10 release, but that is not to 
> be; the postponement of evaluation by default has itself been postponed in 
> the hopes of unwinding things."


The present objection to PEP 649 is its breaking change to the 
*__annotations__*  attribute, since that attribute has been around since 
Python 3.0 and its use not restricted to types. Perhaps adding two 
attributes to objects would work: one would be the *__co_annotations__* 
attribute 
described in PEP 649, the other would be a typing-specific attribute with 
use limited to typing, that would for that use take the place of the 
existing *__annotations__* attribute. 

This would require work by the authors of code that relies on the current 
*__annotations__* attribute for typing-related information, but that may be 
the only sure answer that does not break code that uses the 
*__annotations__* attribute for other purposes. 

-- 
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/9ff058d8-644a-4070-8eb1-f4f4025904efn%40googlegroups.com.

Python project delays changes to annotations

[David Szent-Györgyi]

This was published a couple of weeks ago, on 9th June, but it is likely to 
be current as of this date (26th June). It is of interest to Leo's 
developers and other programmers who annotate their Python code with typing 
information: 

The following excerpt begins "When and how to evaluate Python annotations" 
. A careful reading of the entire article 
and the comments posted in reply is needed. If one uses a Python package 
that depends on annotations, especially one that uses typing information or 
provides that,  a check with users of and developers of that package is in 
order. 

"Annotations in Python came late to the party; they were introduced in 
Python 3 as a way to attach information to functions describing their 
arguments and return values. While that mechanism had obvious applications 
for adding type information to Python functions, standardized 
interpretations for the annotations came later with type hints 
. But evaluating the annotations at 
function-definition time caused some difficulties, especially with respect 
to forward references to type names, so a Python Enhancement Proposal (PEP) 
was created to postpone their evaluation until they were needed. The 
PEP-described behavior was set to become the default in the upcoming 
Python 3.10 release, but that is not to be; the postponement of evaluation 
by default has itself been postponed in the hopes of unwinding things."

-- 
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/6600a637-d126-4af9-a16c-32c0739597adn%40googlegroups.com.

Re: Good Monospaced Programmer's Font

[David Szent-Györgyi]

The Wikipedia article on the Croscore fonts also mentions the Noto fonts 
: 

«Noto is a font family comprising over 100 individual fonts, which are 
together designed to cover all the scripts encoded in the Unicode standard. 
As of October 2016, Noto fonts cover all 93 scripts defined in Unicode 
version 6.1 (April 2012), although fewer than 30,000 of the nearly 75,000 
CJK unified ideographs in version 6.0 are covered. In total Noto fonts 
cover nearly 64,000 characters,[citation needed] which is under half of the 
143,859 characters defined in Unicode 13.0 (released in March 2020).

The Noto family is designed with the goal of achieving visual harmony 
(e.g., compatible heights and stroke thicknesses) across multiple 
languages/scripts. Commissioned by Google, the font is licensed under the 
SIL Open Font License.»

Tracking a living, changing document such as the Unicode standard cannot be 
easy. There are multiple schemes for character sets and hinting for 
handling diacritical marks, and support for those varies across operating 
systems and applications. 

I don't know which scheme is used by the Qt stack that is the basis for 
Leo's default GUI, or whether the Qt stack uses one scheme across all its 
platforms. 

I expect the Leo plugin for Visual Studio Code shall inherit the one from 
VSCode, which is based on the Chromium browser. 

-- 
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/0ab3a8b9-97b3-4838-bfb6-c9ea550bbac0n%40googlegroups.com.

Re: Good Monospaced Programmer's Font

[David Szent-Györgyi]

Cousine is one of the Chrome OS core fonts, "Croscore fonts". Further font 
suggestions from the Wikipedia article on the Croscore fonts 
: 

Arimo  (sans serif) - 
metrically compatible with Arial; 
Tinos  (serif) - metrically 
compatible with Times New Roman; 
Carlito(sans serif, metrically compatible with Calibri), part of the 
Crosextra fonts; 
Caladea(serif, metrically compatible with Cambria), part of the Crosextra 
fonts; 
Version 2.0 of the Liberation fonts 
 is based on the Croscore 
fonts.

Packages for the Crosextra fonts are available with current Linux 
distributions. LibreOffice bundles the Liberation fonts. 

-- 
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/1c157005-0bb5-4a91-880e-ad57ea687982n%40googlegroups.com.

Re: Good Monospaced Programmer's Font

[David Szent-Györgyi]

Cousine's designer is a professional with decades of experience. 

https://en.wikipedia.org/wiki/Steve_Matteson

-- 
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/71c0cdb6-bd0c-4a20-92da-ade1b2448a7bn%40googlegroups.com.

Re: Good Monospaced Programmer's Font

[David Szent-Györgyi]

More about Cousine: 

«Cousine is an open-source monospaced typeface designed by Steve Matteson 
and available for free through Google Fonts. It was designed to be 
metrically compatible with Courier New. Cousine is available in normal, 
italic, bold and bold italic styles. . . . 

SUGGESTED FONT PAIRING

Cousine + Source Sans Pro»

https://www.typewolf.com/cousine

-- 
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/691935ec-09ae-4a72-97d0-224d2194d323n%40googlegroups.com.

Does it make sense to spend much effort supporting 32-bit Windows, or 32-bit installations on 64-bit Windows?

[David Szent-Györgyi]

>From Wikipedia's article on Windows 10 
: «Starting 
with Windows 10 version 2004, Microsoft will require new OEM devices to use 
64-bit processors, and will therefore cease the distribution of x86 
(32-bit) variants of Windows 10 via OEM channels. The 32-bit variants of 
Windows 10 will remain available via non-OEM channels, and Microsoft will 
continue to "[provide] feature and security updates on these devices".»

Not that it is a good thing to be heedless of RAM usage, but relief from 
the address-space restrictions of 32-bit Windows is a Good Thing. 

-- 
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/333efe0b-864c-4a00-a474-d0f008fbf5b3n%40googlegroups.com.

Anaconda 3.8 supports use of earlier releases of Python3

[David Szent-Györgyi]

>From the documentation 
 
for Version 3.8 of the Anaconda distribution: 

Conda treats Python the same as any other package, so it is easy to manage 
and update multiple installations.

Anaconda supports Python 2.7, 3.6, 3.7, and 3.8. The default is Python 2.7 
or 3.8, depending on which installer you used:

   - 
   
   For the installers "Anaconda" and "Miniconda," the default is 2.7.
   - 
   
   For the installers "Anaconda3" or "Miniconda3," the default is 3.8.
   

-- 
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/31501c29-0e4b-424d-b84d-be0348432389n%40googlegroups.com.

Leo deployment on Windows - past story, current story

[David Szent-Györgyi]

 

I've written 
of the 
need to discuss the deployment stories on Windows, macOS, various Unix 
distributions, various Linux distributions. Before this discussion begins, 
one must consider that there are multiple implementations of Python. For 
the moment, I'm limiting my comments to CPython running native on Windows. 

*Context: *The last time I worked on an installer for Leo or any other 
package, Leo 4.3 was the current release, and came with a single-file 
installer built using NSIS. That installer was for Windows only. NSIS as it 
stood then was flexible as it saw use in many projects, but its use was 
somewhat arcane. My work was aimed at supporting per-user installations of 
CPython as well as shared installations, and installing per-user and 
system-wide installations of Leo on top of system-wide installations of 
CPython; my hope was that the two flavors of per-user support would ease 
the work of side-by-side testing of multiple CPython releases and multiple 
Leo releases. By the time I had something to share with Edward, Windows 
Vista had brought the headaches of UAC dialog boxes that were the user 
interface for tightened security, and I had not touched those. Edward was 
already burdened by maintenance of the Windows XP-savvy installer script 
that NSIS compiles. It's possible that my work only promised more 
installer-related work for him, but it's Edward's right to comment on that 
if he wishes to. 

Contrast that with the current requirements under Windows:

   - 
   
   CPython;
   - 
   
   Qt, whose publisher has restricted access to the LTS releases to paying 
   customers, which forces non-commercial users to track development versions 
   that are released every six months; 
   - 
   
   Git, or another source code management tool that speaks enough Git to 
   pull from GitHub; 
   - 
   
   Leo's devel branch on GitHub, which mingles Leo's core with Leo's 
   plugins, some of which are clearly essential to leo as it stands.
   
What are the installer stories for each of these? 

   - 
   
   CPython comes with an installer,  one that supports setups for the 
   individual user and for all users. 
   - 
   
   The changes to Qt distribution are no gift to a project like Leo, if my 
   guess about the limits to Edward's ability to scale are as accurate as my 
   knowledge of my own. 
   - 
   
   Git, I can't speak to. It has arrived since I had spare time to develop 
   software, even limiting development to my narrow requirements.  
   - 
   
   Following Leo's devel branch on GitHub seems to require following 
   discussions among its developers here on Leo-editor. The supportive 
   responses of the people here are a major plus. 
   
What are the usage stories for each of these? 

*Cpython.* The current release of CPython is 3.9.5. Its installer supports 
installation for the current and for all users. It supports access to the 
pip  manager for packages on the Python 
Package Index  ("PyPi"). 

*Qt. *I don't know about Qt as shipped by its publisher, The Qt Company 
; on my work Windows machine, I recently installed the 
Individual 
Edition  of the Anaconda 
distribution of CPython  to obtain it. There's 
more to say about the Anaconda distribution later. 

*Python bindings for Qt. *Either Riverbank Computing's PyQt 
, or the Qt Company's 
PySide , which was developed by Qt's owner 
because of Riverbank Computing's restrictive license. Now, Qt is also under 
a restrictive license. . . .

*Git. *It is my impression that use of Git is complicated enough that it 
requires both learning and careful, careful use. I'm old and busy, meaning 
that I have limitations, and memory for the details of infrequently used 
command-line utilities is one of them. 

*Leo's devel branch on GitHub. *I am drawn to the single-file-installer and 
small-team focus of Fossil-SCM , which is built on 
engineering choices of simplicity of deployment and use. It supports both 
server-based repositories and distributed development. It can use an 
installed Git to work with GitHub repositories while work on the local 
machine is done with Fossil-SCM 
. There are 
limitations  to 
support of GitHub, and Leo's developers would need to comment on those 
before anyone did more than pull from the Leo's devel branch for 
deployment. I don't speak for anyone else, but if those limitations don't 
break the practices of Leo's developers, I'd suggest that people who don't 
use Git every day to work with GitHub repositories consider using 
Fossil-SCM. Fossil-SCM and SQLite are 

Re: Location of 'leoserver.py' & 'leoclient.py' in Leo's directory structure?

[David Szent-Györgyi]

On Thursday, May 20, 2021 at 1:39:06 PM UTC-4 tbp1...@gmail.com wrote:

> In my view, Leo *is* a 3rd party python package and should be installable 
> via pip.  It is true that some Linux systems will tinker with the 
> directories, paths, etc and want you to install certain packages using 
> their own package manager.  But Leo as a project can't cater to all these 
> possible variations.
>
> I can see a separate pip package named, say, "leo-server" or some such 
> that includes the parts that you want to work with that ordinary users 
> can't.  Such a package could I'm sure be created by a script that creates a 
> temporary directory tree with the extra parts for the packager to package 
> up.  Or maybe the existing setup.py can be enhanced to do that.
>

The last time I worked on an installer for Leo or any other package, Leo 
4.3 was the current release. That installer was for Windows only, and used 
NSIS to generate the single-file setup executable. NSIS as it stood then 
was flexible as it saw use in many projects, but its use was somewhat 
arcane. My work was aimed at supporting per-user installations of CPython 
as well as shared installations, and installing per-user and system-wide 
installations of Leo on top of system-wide installations of CPython; my 
hope was that the two flavors of per-user support would ease the work of 
side-by-side testing of multiple CPython releases and multiple Leo 
releases. By the time I had something to share with Edward, he was already 
burdened by maintenance of the source code of the script that NSIS 
compiles. It's possible that my work only promised more installer-related 
work for him, but it's Edward's right to comment on that if he wishes to. 

If I recall correctly, Leo releases are less frequent than was the case 
when Leo 4.2, 4.3, and 4.4 were under development.  Stabilizing Leo for a 
release requires work. It is also the case that an installer requires a 
matching uninstaller. Serious effort is made to minimize the periods during 
which the most recent commit devel branch on GitHub is unusable; as such, 
the expectation is that one needs to pull from the devel branch in between 
releases. 

Pip is for packages; I question whether Leo with its Qt -based GUI and with 
its plugins is best considered as a single package. In my days working with 
Leo with the Tkinter-based GUI and working solely on Windows, all I needed 
was the the single-file installer for CPython, the single-file NSIS-based 
installer executable for Leo, and the single-file installer for Mark 
Hammond's pywin32 tools - I could fit the installers on a rewritable CD, 
and install them on a new machine in three minutes, and understand the 
process without documenting it. 

Making Leo easier to install across deployment targets may increase the 
volume of requests for help, and my experience providing technical support 
for software published by my employers is that addressing deployment 
strategies in the software itself is critical to allowing the support staff 
to scale. 

Python is a great language for writing scripts and many sorts of 
applications, but its deployment story does not deliver the application 
publisher a one solution-fits-all across Windows, macOS, the various Unix 
distributions, and the various Linux distributions. The details of the 
requirements for the different deployment targets vary so greatly that I've 
just abandoned detailing those known to me here; a serious attempt to 
catalogue them for the use of Leo's developers needs to be addressed 
separately. 

That said, I think all those details need to be laid out for Leo's 
developers to consider; the rearrangement of Leo's source code for pip is 
only a start on the changes needed to support deployment, and I am sure 
that improvement of minimal support for all the targets listed in the 
preceding paragraph would require changes within Leo itself. 

-- 
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/bbe24ab1-50fa-4686-af9c-ebb0ace41c47n%40googlegroups.com.

Re: Tools of Interest: Hypothesis and Pydantic for Property-based Testing

[David Szent-Györgyi]

 

The Overview page for Pydantic offers the following Rationale 
, which makes me think that 
it might be of interest to Leo's users and Leo's developers: 

«So *pydantic* uses some cool new language features, but why should I 
actually go and use it?

*plays nicely with your IDE/linter/brain *There's no new schema definition 
micro-language to learn. If you know how to use python type hints, you know 
how to use *pydantic*. Data structures are just instances of classes you 
define with type annotations, so auto-completion, linting, mypy 
, IDEs (especially PyCharm 
), and your intuition 
should all work properly with your validated data.

*dual use **pydantic's* BaseSettings 
 class allows 
*pydantic* to be used in both a "validate this request data" context and in 
a "load my system settings" context. The main differences are that system 
settings can be read from environment variables, and more complex objects 
like DSNs and python objects are often required.

*fast *In benchmarks  
*pydantic* is faster than all other tested libraries.

*validate complex structures *use of recursive *pydantic* models 

, typing's standard types 
 (e.g. 
List, Tuple, Dictetc.) 
and validators  allow 
complex data schemas to be clearly and easily defined, validated, and 
parsed.

*extensible **pydantic* allows custom data types 
 to be 
defined or you can extend validation with methods on a model decorated with 
the validator 
 decorator.

*dataclasses integration *As well as BaseModel, *pydantic* provides a 
dataclass  decorator 
which creates (almost) vanilla python dataclasses with input data parsing 
and validation.»  

-- 
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/d9b40825-f9d0-4341-9623-4da2d847b319n%40googlegroups.com.

Re: Tools of Interest: Hypothesis and Pydantic for Property-based Testing

[David Szent-Györgyi]

 

The Overview page for Pydantic offers the following Rationale 
, which makes me think that 
it might be of interest to Leo's users and Leo's developers: 

«So *pydantic* uses some cool new language features, but why should I 
actually go and use it?

*plays nicely with your IDE/linter/brain *There's no new schema definition 
micro-language to learn. If you know how to use python type hints, you know 
how to use *pydantic*. Data structures are just instances of classes you 
define with type annotations, so auto-completion, linting, mypy 
, IDEs (especially PyCharm 
), and your intuition 
should all work properly with your validated data.

*dual use **pydantic's* BaseSettings 
 class allows 
*pydantic* to be used in both a "validate this request data" context and in 
a "load my system settings" context. The main differences are that system 
settings can be read from environment variables, and more complex objects 
like DSNs and python objects are often required.*fast *In benchmarks 
 *pydantic* is faster than 
all other tested libraries.

*validate complex structures *use of recursive *pydantic* models 

, typing's standard types 
 (e.g. 
List, Tuple, Dictetc.) 
and validators  allow 
complex data schemas to be clearly and easily defined, validated, and 
parsed.

*extensible**pydantic* allows custom data types 
 to be 
defined or you can extend validation with methods on a model decorated with 
the validator 
 decorator.

*dataclasses integration *As well as BaseModel, *pydantic* provides a 
dataclass  decorator 
which creates (almost) vanilla python dataclasses with input data parsing 
and validation.»

>

-- 
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/7e3ea30e-b0b3-45e7-ba43-930b4ed1a5c2n%40googlegroups.com.

Re: Tools of Interest: Hypothesis and Pydantic for Property-based Testing

[David Szent-Györgyi]

 

The Overview page for Pydantic offers the following Rationale 
<https://pydantic-docs.helpmanual.io/#rationale>, which makes me think that 
it might be of interest to Leo's users and Leo's developers: 

«So *pydantic* uses some cool new language features, but why should I 
actually go and use it?

*plays nicely with your IDE/linter/brain *There's no new schema definition 
micro-language to learn. If you know how to use python type hints, you know 
how to use *pydantic*. Data structures are just instances of classes you 
define with type annotations, so auto-completion, linting, mypy 
<https://pydantic-docs.helpmanual.io/usage/mypy/>, IDEs (especially PyCharm 
<https://pydantic-docs.helpmanual.io/pycharm_plugin/>), and your intuition 
should all work properly with your validated data.

*dual use **pydantic's* BaseSettings 
<https://pydantic-docs.helpmanual.io/usage/settings/> class allows 
*pydantic* to be used in both a "validate this request data" context and in 
a "load my system settings" context. The main differences are that system 
settings can be read from environment variables, and more complex objects 
like DSNs and python objects are often required.*fast *In benchmarks 
<https://pydantic-docs.helpmanual.io/benchmarks/> *pydantic* is faster than 
all other tested libraries.

*validate complex structures *use of recursive *pydantic* models 
<https://pydantic-docs.helpmanual.io/usage/models/#recursive-models>
, typing's standard types 
<https://pydantic-docs.helpmanual.io/usage/types/#standard-library-types> (e.g. 
List, Tuple, Dictetc.) 
and validators <https://pydantic-docs.helpmanual.io/usage/validators/> allow 
complex data schemas to be clearly and easily defined, validated, and 
parsed.

*extensible**pydantic* allows custom data types 
<https://pydantic-docs.helpmanual.io/usage/types/#custom-data-types> to be 
defined or you can extend validation with methods on a model decorated with 
the validator <https://pydantic-docs.helpmanual.io/usage/validators/>
 decorator.

*dataclasses integration *As well as BaseModel, *pydantic* provides a 
dataclass <https://pydantic-docs.helpmanual.io/usage/dataclasses/> decorator 
which creates (almost) vanilla python dataclasses with input data parsing 
and validation.»
On Sunday, April 25, 2021 at 8:18:57 AM UTC-4 David Szent-Györgyi wrote:

> These links might be of interest to Edward and others developing Python 
> code, including Leo. 
>
> First, a praise of property-based testing 
> <https://increment.com/testing/in-praise-of-property-based-testing/>, 
> with examples that differentiate it from example-based testing. 
>
> Second, Hypothesis, «a Python library for creating unit tests which are 
> simpler to write and more powerful when run, finding edge cases in your 
> code you wouldn’t have thought to look for. It is stable, powerful and easy 
> to add to any existing test suite.
>
> It works by letting you write tests that assert that something should be 
> true for every case, not just the ones you happen to think of.»
>
> Third, Pydantic, «Data validation and settings management using python 
> type annotations. *pydantic* enforces type hints at runtime, and provides 
> user friendly errors when data is invalid. Define how data should be in 
> pure, canonical python; validate it with *pydantic*.» This includes 
> support for "custom" (user-defined) types. Pydantic uses type hinting from 
> Versions 3.6 and later of Python. 
>
> A plug-in for Pydantic supports Hypothesis. Used together, Pydantic 1.8 
> and Hypothesis v5.29.0 allow Hypothesis to automatically load support for 
> custom types like PaymentCardNumber (a credit-card number) and 
> PositiveFloat. Current releases are Pydantic 1.8.1 and Hypothesis 6.10.0. 
>
> Documentation for Hypothesis on Read the Docs 
> <https://hypothesis.readthedocs.io/en/latest/>
> Hypothesis on PyPi <https://pypi.org/project/hypothesis/>
> Installing Hypothesis from source 
> <https://github.com/HypothesisWorks/hypothesis/blob/master/CONTRIBUTING.rst>
>
> Documentation for Pydantic on Help Manual 
> <https://pydantic-docs.helpmanual.io>
> Documentation for Pydantic's Hypothesis plug-in 
> <https://pydantic-docs.helpmanual.io/hypothesis_plugin/>
> Pydantic on PyPi <https://pypi.org/project/pydantic/>
> Pydantic on GitHub <https://github.com/samuelcolvin/pydantic>
>

-- 
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/f1d2a257-151b-403b-aaeb-2a5397a6835fn%40googlegroups.com.

Tools of Interest: Hypothesis and Pydantic for Property-based Testing

[David Szent-Györgyi]

These links might be of interest to Edward and others developing Python 
code, including Leo. 

First, a praise of property-based testing 
, with 
examples that differentiate it from example-based testing. 

Second, Hypothesis, «a Python library for creating unit tests which are 
simpler to write and more powerful when run, finding edge cases in your 
code you wouldn’t have thought to look for. It is stable, powerful and easy 
to add to any existing test suite.

It works by letting you write tests that assert that something should be 
true for every case, not just the ones you happen to think of.»

Third, Pydantic, «Data validation and settings management using python type 
annotations. *pydantic* enforces type hints at runtime, and provides user 
friendly errors when data is invalid. Define how data should be in pure, 
canonical python; validate it with *pydantic*.» This includes support for 
"custom" (user-defined) types. Pydantic uses type hinting from Versions 3.6 
and later of Python. 

A plug-in for Pydantic supports Hypothesis. Used together, Pydantic 1.8 and 
Hypothesis v5.29.0 allow Hypothesis to automatically load support for 
custom types like PaymentCardNumber (a credit-card number) and 
PositiveFloat. Current releases are Pydantic 1.8.1 and Hypothesis 6.10.0. 

Documentation for Hypothesis on Read the Docs 

Hypothesis on PyPi 
Installing Hypothesis from source 


Documentation for Pydantic on Help Manual 

Documentation for Pydantic's Hypothesis plug-in 

Pydantic on PyPi 
Pydantic on GitHub 

-- 
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/ccc7c57a-0b17-4f7f-85a6-edfd04b61bd6n%40googlegroups.com.

Re: [ctlug] M$ Joy

[David Szent-Györgyi]

On Sunday, April 11, 2021 at 4:14:30 AM UTC-4 Edward K. Ream wrote:

>
> 1. Those who are planning major writing projects would be well advised to 
> make a serious study of the strengths and weakness of the major contenders, 
> including Jupyter, LaTeX, reStructuredText, and Leo. And yes, it will take 
> some study. wysiwyg editors and simplistic markup languages like markdown 
> are too limiting. Better to invest in more powerful tools.
>
> 2. It is a great mistake to underestimate the capabilities of existing 
> tools.
>
> I have made this mistake several times. 30 years ago, I despaired of using 
> Emacs because I didn't understand that tab completion makes it unnecessary 
> to remember full command names, or to type them. Had I understood this, I 
> would likely have based Leo on Emacs. Leo's entire history would have 
> changed, and I would not have spent much of the last 30 years dealing with 
> tangential editor-related issues.
>
> In short,* please* take the time to study what is already possible. Major 
> tools typically have dozens or even hundreds of contributors. It would be 
> impossible to do better on one's own.
>

Edward is absolutely right in recommending using existing tools when 
possible. 

I am looking for a markup language for plain-text files, some of which are 
documentation meant for PDF or ODF, some of which are plain text meant for 
conversion via templates to static HTML5 for a Web site. Has anyone else 
worked with AsciiDoc format? 

AsciiDoc is meant to be less ad-hoc than Markdown and the variants thereof. 
It is meant to be semantically equivalent to DocBook XML, and its creators 
are early in an effort to write a specification  complete with an open 
Technology Compatibility Kit 
.
 


The creators of AsciiDoc offer Asciidoctor , a "
*fast*, open source 
 text 
processor and publishing toolchain for converting AsciiDoc 
 content to HTML5, DocBook, 
PDF, and other formats"; AsciiDoctor is cross-platform, written in Ruby; 
AsciidoctorJ  runs on a Java 
Virtual Machine, and Asciidoctor.js 
 in JavaScript environments, 
including Web browsers. The leaders of the Asciidoctor project write that 
AsciidoctorJ and Asciidoctor.js need to develop independently of 
Asciidoctor, which is one motivation for the creation of a specification 
and TCK. 

The Python implementation, AsciiDoc-py 
, is limited to legacy syntax 
for AsciiDoc. 

 

-- 
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/215e211e-671b-4e52-a09f-cc67feb2d415n%40googlegroups.com.

Re: David Szent-Györgyi: Please send an example .leo file

[David Szent-Györgyi]

I apologize for the delay in digging this up. 

I've shared a Dropbox link with your edreamleo  gmail  com email 
address. 

The link is to a shared folder that at present contains a Zip archive with 
a couple of  Leo files and WSF files - enough to open the Leo file. As the 
Leo file shows, I use the @root directive for each WSF file! 

Anything I can do to explain or correct problems, let me know. 
On Thursday, March 4, 2021 at 6:34:11 AM UTC-5 Edward K. Ream wrote:

> Hi David,
>
> It will be worth my time to suggest alternatives to @root. Please send me 
> an example of how you use @root.  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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/83d729ff-9bb9-4841-b768-2a7801ca9bf0n%40googlegroups.com.

Using MacPorts to deploy Leo on macOS computers

[David Szent-Györgyi]

Has anyone taken a recent look at MacPorts for deploying Leo? 

I know that using Homebrew to install Leo is the current recommendation. 
Homebrew has for years installed in */usr/local* on Intel Macs, and is now 
forced by Apple's tightening of access to that folder to install in 
*/opt/homebrew* on Apple Silicon Macs, which come with *macOS 11* "Big 
Sur";  the recommendation for the Intel Mac remains */usr/local*. 

You might call me old school, but MacPorts is my preferred system for 
deploying open-source software on the Mac I live in for work. MacPorts 
already installs under */opt*, basing its filesystem hierarchy under 
*/opt/local. *It can install precompiled binaries when available; it can 
compile everything from source code, pulling that from GitHub as needed. 

A custom installation can base the MacPorts filesystem in another folder 
underneath */opt*, such as */opt/leo-editor*. Such a custom installation 
requires compiling everything from source - no small job if one installs 
Python and Qt - but provides the option of installing Leo with all 
dependencies, keeping that installation independent of other software. 

I can forsee separate installations, one with custom installation under 
*/opt/leo-editor *for work on development of Leo, one with the default 
installation under */opt/local* for day-to-day use. 

MacPorts is written to install without stepping on software bundled with 
the operating system - and without relying on Apple to deliver the most 
recent releases of that software (such as Python!). MacPorts has good 
support for Python and for Qt, and the range of software that it supports 
means that work is already done for supporting specific versions of Python 
and Qt. All that would be needed would be a "portfile" that tells MacPorts 
how to install Leo. 

It is possible to use MacPorts to deploy macOS Applications, which would in 
Leo's case be a launcher that would run the MacPorts-hosted Python and use 
that to launch the MacPorts-hosted Leo. 

-- 
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/83c29698-b31d-4ff2-be57-44695aa5da62n%40googlegroups.com.

Re: Discuss: remove @root?

[David Szent-Györgyi]

Perhaps your current work would allow me to move to @file trees, removing 
my need for @root. 

I see in your recent posting "ENB: Aha re snippets, gnx's and literate 
programming" discussion of "snippets" that, if they work in @file trees, 
might offer  some or all of the benefits of cross-file clones. If that were 
the case, could I use snippets to allow me to clone the contents of 
VBScript files and JScript files so that the contents of those files would 
be written to the WSF files? 

It would be easiest to use a single LEO file to host all the VBScript and 
JScript and the WSF files, but if that would break the machinery, I could 
set up separate LEO files: one for the library routines and management of 
the library, and one for each for the WSF files I am looking to build. The 
only requirement would be that I have a means of including the contents of 
the referenced VBScript file and JScript file in the WSF file that I save. 
If I could make either of the single-LEO-file scheme work or the 
one-LEO-file-for-library-and-one-LEO-file-per-WSF-file schemed work, I 
could abandon the @root directive. 
On Saturday, February 27, 2021 at 1:19:28 PM UTC-5 David Szent-Györgyi 
wrote:

> Would you like to have a copy of the LEO file that contains the 
> repository? You could see you my set-up. 
>
> On Saturday, February 27, 2021 at 11:47:19 AM UTC-5 Edward K. Ream wrote:
>
>> On Thu, Feb 25, 2021 at 11:30 PM David Szent-Györgyi  
>> wrote:
>>
>>> Leo is your project, you provide free access to the fruits of your 
>>> labor, if you're going to remote @root that's your decision, but it may 
>>> cause me to ask questions I need answered if I am to preserve access to 
>>> work that I've done. 
>>>
>>
>> Please ask any questions you like.
>>
>> My question is this: what can you do with @root that is difficult or 
>> clumsy with @file? Can you provide an example of how you use @root?
>>
>> I've written about my use of Leo 4.3: it served as an easily deployed 
>>> tool for building utilities in the form of Windows Script Host files (WSF 
>>> files), and that I came up with a scheme that made it easy for me to use a 
>>> LEO file to hold the source code for the library of routines (in JScript or 
>>> VBScript) used by the WSF files as well as the source code for the 
>>> utilities I was building. Since each WSF file was independent and had to 
>>> include every library routine used therein, the libraries ended up written 
>>> to disk in multiple places in the various WSF files. 
>>>
>>
>> OK.
>>
>> These days, WSF files are frowned up on because script kiddies and other 
>>> malefactors used VBScript and similar technologies, so perhaps I shouldn't 
>>> care about preserving the ones I wrote, but I still use some of them 
>>> in-house, and they need maintenance; I don't want to lose access to my 
>>> Leo-based development environment if I can help it. 
>>>
>>
>> I'm not here to judge what people should be doing with Leo!
>>
>>> The last thing I would want to do would be cut myself off from Leo's 
>>> vibrant community; I am still a lone developer, working without help to 
>>> write utilities for work when I'm short of time for work as it is. That 
>>> said, if I must give up on using future versions of Leo, what do I do: pick 
>>> a version of Leo that is closest to my needs and create a fork? 
>>>
>>
>> Don't worry. Your objection will suffice to have Leo support @root 
>> indefinitely.  If you don't mind, I'll add your name to the comments in 
>> leoTangle.py, to tell me, and future Leo devs, who's using this feature.
>>
>> 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/97515aa4-f7a1-4ac9-80c2-4316d7c5d5fan%40googlegroups.com.

Re: Discuss: remove @root?

[David Szent-Györgyi]

Would you like to have a copy of the LEO file that contains the repository? 
You could see you my set-up. 

On Saturday, February 27, 2021 at 11:47:19 AM UTC-5 Edward K. Ream wrote:

> On Thu, Feb 25, 2021 at 11:30 PM David Szent-Györgyi  
> wrote:
>
>> Leo is your project, you provide free access to the fruits of your labor, 
>> if you're going to remote @root that's your decision, but it may cause me 
>> to ask questions I need answered if I am to preserve access to work that 
>> I've done. 
>>
>
> Please ask any questions you like.
>
> My question is this: what can you do with @root that is difficult or 
> clumsy with @file? Can you provide an example of how you use @root?
>
> I've written about my use of Leo 4.3: it served as an easily deployed tool 
>> for building utilities in the form of Windows Script Host files (WSF 
>> files), and that I came up with a scheme that made it easy for me to use a 
>> LEO file to hold the source code for the library of routines (in JScript or 
>> VBScript) used by the WSF files as well as the source code for the 
>> utilities I was building. Since each WSF file was independent and had to 
>> include every library routine used therein, the libraries ended up written 
>> to disk in multiple places in the various WSF files. 
>>
>
> OK.
>
> These days, WSF files are frowned up on because script kiddies and other 
>> malefactors used VBScript and similar technologies, so perhaps I shouldn't 
>> care about preserving the ones I wrote, but I still use some of them 
>> in-house, and they need maintenance; I don't want to lose access to my 
>> Leo-based development environment if I can help it. 
>>
>
> I'm not here to judge what people should be doing with Leo!
>
>> The last thing I would want to do would be cut myself off from Leo's 
>> vibrant community; I am still a lone developer, working without help to 
>> write utilities for work when I'm short of time for work as it is. That 
>> said, if I must give up on using future versions of Leo, what do I do: pick 
>> a version of Leo that is closest to my needs and create a fork? 
>>
>
> Don't worry. Your objection will suffice to have Leo support @root 
> indefinitely.  If you don't mind, I'll add your name to the comments in 
> leoTangle.py, to tell me, and future Leo devs, who's using this feature.
>
> 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/d2fe2977-3742-4175-8b07-89097882a10fn%40googlegroups.com.

Re: Discuss: remove @root?

[David Szent-Györgyi]

Leo is your project, you provide free access to the fruits of your labor, 
if you're going to remote @root that's your decision, but it may cause me 
to ask questions I need answered if I am to preserve access to work that 
I've done. 

I've written about my use of Leo 4.3: it served as an easily deployed tool 
for building utilities in the form of Windows Script Host files (WSF 
files), and that I came up with a scheme that made it easy for me to use a 
LEO file to hold the source code for the library of routines (in JScript or 
VBScript) used by the WSF files as well as the source code for the 
utilities I was building. Since each WSF file was independent and had to 
include every library routine used therein, the libraries ended up written 
to disk in multiple places in the various WSF files. 

These days, WSF files are frowned up on because script kiddies and other 
malefactors used VBScript and similar technologies, so perhaps I shouldn't 
care about preserving the ones I wrote, but I still use some of them 
in-house, and they need maintenance; I don't want to lose access to my 
Leo-based development environment if I can help it. 

The last thing I would want to do would be cut myself off from Leo's 
vibrant community; I am still a lone developer, working without help to 
write utilities for work when I'm short of time for work as it is. That 
said, if I must give up on using future versions of Leo, what do I do: pick 
a version of Leo that is closest to my needs and create a fork? 

Given that ease of deployment was essential, and that I was happy with the 
functions of Leo 4.3 and the Tkinter-based Leo GUI, my choice of version 
might go back quite a ways. I might have to revive the Tkinter-based GUI; 
I'd have to dig to find out how many releases of Leo ago I'd have to go. 
On Tuesday, February 16, 2021 at 4:26:24 PM UTC-5 Edward K. Ream wrote:

> leoTangle.py supports @root files. Such files are deprecated and no longer 
> documented. This is on purpose.
>
> leoTangle.py contains some of Leo's oldest and least satisfactory code. 
>
> @root is very slightly more flexible than @file, @clean etc. With @root 
> one can define sections (aka chunks) in several places. This ability is one 
> of the features of Knuth's original web and cweb projects. However, I have 
> never, ever, needed this capability. Imo, it is horrendous programming 
> style.
>
> Several (10?) years ago I proposed removing support for @root. Back then 
> at least one person objected. What do you think? Is anyone still using 
> @root?
>
> 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/bccaa651-4bac-4036-a192-785a49fde95dn%40googlegroups.com.

Re: ENB: Are huge Leo outlines possible?

[David Szent-Györgyi]

On Wednesday, December 9, 2020 at 10:11:01 AM UTC-5 tbp1...@gmail.com wrote:

> Ah, the pdp-8, a trip down memory lane.  I used an 8i extensively in the 
> early 70s, but did not make the acquaintance of TECO.  After looking it up 
> on Wikipedia, I' m glad I didn't.  Remember how 3 ascii characters were 
> packed into two 12-bit words?  And while the 8e may have come with 12k of 
> RAM, the 8i came with 4k, unless you had the money to get the extension to 
> 8k (which ours had).
>

Some of TECO's ugliness has to do with the media it supported, including 
(if I recall correctly) paper tape(!). I used it with files on floppy disk, 
fortunately for me. 

The 8/e I used had two ASR-33 teletypes and two (two!) eight-inch floppy 
disk drives, using disks which held 250KB if I recall.  We used OS/8 for 
single-user computing with access to the disk drives, and a time-sharing 
BASIC for two-user computing with paper tape for program storage. One of 
our projects was to modify a time-sharing BASIC with support for DEC's 
floppy disk drive unit to work with the third-party drive unit we used; 
after several years of work by us high school students, we figured out that 
the BASIC depended on the interrupts generated by DEC's floppy controller; 
the third-party unit used programmed I/O, and could not generate interrupts!

Ah, nostalgia. 

-- 
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/c6f5bd5e-ead6-4e36-8682-67b55176ecf5n%40googlegroups.com.

Re: ENB: Are huge Leo outlines possible?

[David Szent-Györgyi]

On Wednesday, December 9, 2020 at 10:30:54 AM UTC-5 Edward K. Ream wrote:

> Yes, and those considerations have nothing to do with teco :-)
>

Leo doesn't need the engineering underlying TECO - fortunately, it doesn't 
have to work on an architecture of segmented memory - but editing text 
files too large to fit in RAM needs careful design of the user interface. 
Here's a short description of TECO's design: 

The original TECO editors were created when computer systems were very 
memory limited, and were therefore optimized to run in small memory 
configurations. One way that this was accomplished was that TECO was a 
*pipeline 
editor*. Text was read from the input file into an edit buffer, and then 
written out to the output buffer. The only part of the file which was 
resident was the edit buffer, and this was typically kept quite small. Once 
text was paged out to the output file, it could not be called up again 
without writing out the entire contents of the files, and then re-reading 
to the point in question. 

If that is not what you plan to deliver, you're going to need to figure out 
an abstraction that doesn't kill performance, and for that you're going to 
need to define use cases. 

An image editor that I support as part of my job handles multi-image files 
that are indexed by number. Navigation among the images in a given image 
editor window is a matter of indicating which image is current. This editor 
allows tens of thousands of images in a single file; it loads into its 
memory buffer as many images as will fit. As the user moves from the first 
image to the last, the editor swaps images between a scratch file on disk 
and RAM. For operations that run image-by-image from first to last, that 
works fairly well. It slows to a crawl on other patterns of access to 
images, because the engineering cannot anticipate all cases. For some of 
those cases, the performant solution is to provide RAM enough to hold the 
all the images in the desired file - or two such images, to provide for 
creation of a modified result. 

For some customers, "RAM enough" means 128 GB. The image editor does not 
need to load all the images from disk when opening a file, but saving a 
multi-image file of 32 GB of data takes time, even on a current-day 
workstation - the data comes from memory, or from the scratch file, it has 
to be written to disk, and the metadata for each image and the file as a 
whole have to be written as well. 

-- 
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/ceed18fe-22b5-465f-811a-11ed8fea31b0n%40googlegroups.com.

Re: ENB: Are huge Leo outlines possible?

[David Szent-Györgyi]

On Saturday, October 24, 2020 at 1:07:15 PM UTC-4 Edward K. Ream wrote:

> On Sat, Oct 24, 2020 at 11:53 AM Thomas Passin wrote:
>
>> Remembering back to long ago when we only had 640k of RAM at the most, 
>> there were editors that kept three screens of data in memory at once - the 
>> current page, the previous page, and the next page.  When the user scrolled 
>> forward (say), parts of the next page would be brought in, and when 
>> necessary another page would be read in from disk. An analogy would be a 
>> long continuous (paper) scroll, where only one part in the middle would be 
>> visible at any one time.
>>
>> This scheme would seem to fit right in with your thoughts above.
>>
>
> Alas not. Leo's clone-find commands would pull in the entire db. That's 
> why we need a search that is disconnected from positions and generators.
>

That the clone-find commands are written to work on the entire database 
does not change the engineering considerations that arise from the goal of 
working on a database that is either too large to fit in RAM or is so large 
that the existing code becomes too slow for a database of the desired size 
even if that database does fit in RAM. 

I suggest looking up the user manuals for the text editor in which the 
original Emacs was first written, namely TECO 
. TECO was written for 
DEC computers with tiny address space in which to hold text, and was 
written in terms of editing  the current contents of the buffer that held 
the address space's worth of the file under modification; it features 
flexible commands for paging the file's contents into the editor's buffer, 
allowing one to modify a file too big to fit. 

TECO was the power user's text editor on the PDP-8/e that was the first 
computer I used, back in the early Seventies - a machine with 12K words of 
RAM, which were divided into 4096-word fields; the computer could directly 
address the current field as pages of 128 words, meaning that addressing 
the current field required indirect addressing. TECO allowed me to think in 
terms of a buffer without tracking fields and pages - an abstraction you 
might want to consider for Leo to handle "huge outlines".

It might be of interest to note that the original Emacs was a series of 
macros written for TECO - Emacs originally stood for "Editor Macros". 

-- 
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/16558e66-03ca-4a00-a626-0f733b9a1a60n%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[David Szent-Györgyi]

Edward writes: 

The great advantage Qt has (or had) over Tk was in the appearance of text. 
> Has Tk improved in that regard?
>

My guess is that tkinter as shipped with Python 3.6.8 and 3.7.7 and 3.8.2 
would need careful testing. The macOS interface via Tcl/Tk is undergoing 
work - at present, the ball is in the court of the developers of Tcl/Tk. 

See IDLE and tkinter with Tcl/Tk on macOS, which documents that python.org 
Python installers for versions 3.8.0+, 3.7.2+, 3.6.8 all ship with built-in 
Tcl/Tk 8.6.8. 

See Python bug tracker issue 35402 , 
which documents reverting the use of Tcl/Tk 8.6.9.1, and Python bug tracker 
issue 35485 , which documents specific 
problems and gives a reference to the Tcl/Tk ticket 
 that documents the 
problem.  The current release of Tcl/Tk is 8.6.10; that dates from November 
of 2019, and it hasn't been tried with Python as yet, but I see on the 
timeline for Tcl/Tk  that work 
on the macOS interface is under way as I type this in May of 2020, so the 
bundled Tcl/Tk 8.6.8 won't be upgraded immediately. The developers are 
working around macOS bugs, and Apple is changing the operating system 
significantly, so their work is not easy. 

-- 
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/4dc190f4-6790-4085-8432-88ac87ee59a6%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[David Szent-Györgyi]

Edward writes: 

>
> Thanks for this update. Vitalije recently created a prototype in Tk, so 
> there is actually some code available.
>
> The great advantage Qt has (or had) over Tk was in the appearance of text. 
> Has Tk improved in that regard?
>

Answer for Windows: work has been done. See the Python bug tracker issue 
26698 , which states that a fix for 
IDLE on Windows made it into Python 3.6.6rc1 and Python 3.7.0rc1. That work 
was superseded by work documented by Python bug tracker issue 33656 
. 

Issue 33656 mentions the addition of a call to a Windows API to say that tk 
scales for DPI - the change is in Iines 15-20 of the source code 

. 

That change is documented in as new in Python 3.6.6 
 and new in Python 3.7 
. In each case, the text 
reads, 

On Windows, a new API call tells Windows that tk scales for DPI. On Windows 
> 8.1+ or 10, with DPI compatibility properties of the Python binary 
> unchanged, and a monitor resolution greater than 96 DPI, this should make 
> text and lines sharper. It should otherwise have no effect. (Contributed by 
> Terry Jan Reedy in bpo-33656 .) 

-- 
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/dc51bb77-c4f1-47c3-b607-2a2bc5735b62%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[David Szent-Györgyi]

On Monday, May 4, 2020 at 8:23:17 AM UTC-4, Edward K. Ream wrote:
>
> Leo does not support a tk gui.  It hasn't for at least a decade. See 
> leoPlugins.leo#Plugins-->Gui.
>
> It's possible to run tk code from Leo, but that is another matter entirely.
>

The Leo distributions had a virtue that is not shared by the current code: 
simplicity of installation and use. I could fit the installers for Python, 
for pywin32, and the LEO files for my projects on a CD-RW or a thumb drive, 
and be ready in two minutes to work on the outlines in which I was 
developing code. The Tkinter interface of the time was not pretty, but it 
worked, and allowed me to get my work done. I miss that simplicity! 

Tkinter and enhancements for current Python are far more capable than the 
plain Tkinter in which Edward wrote the GUI that was part of Leo 4.2 and 
Leo 4.3. I wonder whether a from-scratch implementation of a Leo GUI using 
modern Tkinter could be done without the pain caused to Edward by the gaps 
in the old toolkit:

Tkinter.ttk 
 is 
themeable, to help Python-Tkinter GUIs match the appearance of native GUIs. 

The BWidget  widgets include a tree 
widget. 

I'm not assuming that Edward or another of you reading this would do the 
work. I *am *curious, because I could really use Leo as a PIM in the 
environments in which I work: macOS 10.13 "High Sierra" or later, 64-bit 
Windows 10 with IronPython already installed, and 64-bit Windows 10 with 
Python 3.7 installed. My macOS environment is stable although it changes 
every couple of years to track Apple's upgrade treadmill, the others switch 
machines frequently. So, for me, ease of installation is a need. 

I'm not asking for an explanation here of the best practices for installing 
current Leo with the Qt-based interface. If the answer to my curiosity 
about making a Tkinter GUI anew is that it simply isn't practical, I'll 
discuss my view of using current Leo and Qt in a separate thread. 

-- 
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/0eb4f36d-281d-40cb-ae76-373c523586f2%40googlegroups.com.

Re: Org Brain

[David Szent-Györgyi]

I believe that open source software ought to be guided by the desires of 
the developers. I also believe that it does no harm to provide feedback in 
the hope of broadening the goals of those developers. I'm sticking my neck 
out here, commenting on code and tools that I haven't written and haven't 
used extensively. I do not wish to disparage work that other people have 
done and made available, where my own contributions have been less by far. 
I do not operate with a sense of entitlement to the fruits of the labor of 
other people. That said, John Lunzer's comments reminded me of observations 
I have made going back some years. 

On Wednesday, June 26, 2019 at 7:15:24 AM UTC-4, john lunzer wrote:

It's been discussed here before but the way Leo handles "clones" is a cut 
> above the rest: cleanly, transparently, and natively. The cleanliness of 
> their implementation is evident in how broadly and generically they can be 
> used. They remind me a bit of symlinks in the Linux filesystem. 
>

There's a significant impedance mismatch between the full function made 
possible by the data structures of Leo and those of other applications. 
Attempting to shoehorn that full function into other applications that 
provide limited subsets of that full function is not going to be easy, 
because that requires working against that mismatch continually. I wonder 
whether one works against a different mismatch for each application that is 
to interface with Leo. How does one cope with the multiple mismatches 
without complicating Leo and thereby making Leo fragile or harder to 
install and maintain? 
 

> Emacs and any plugin I've seen thus far lacks a true cloning ability. 
> Though I actually do not think it would be too difficult to implement one's 
> self. Emacs has a feature called "indirect buffers" 
> 
>  which 
> is a true cloning ability, but lacking all structure. It likely would not 
> be difficult to do something clever with org, babel, and indirect buffers 
> to create a tree/body view very similar to Leo's. You would be able to 
> tangle, but never untangle (this is also a feature unique to Leo).
>

I think often of the engineering choices made by Guido van Rossum in 
Python's early days; where possible, he chose simpler architecture in order 
to keep the complexity of Python's implementation to a minimum, and provide 
a usable approach to a wide domain of problems. The result was a simpler 
architecture that made use of Python as a "glue" language simpler. For 
example, the Global Interpreter Lock that simplified the implementation of 
Python made multi-threading impossible, but did not prevent the use of 
multi-tasking. 

Leo is a programmable IDE that supports the use of multiple simultaneous 
editor windows, each of which can manage text in ways that are beyond the 
capabilities of other software. A great deal of work has gone into the 
elimination of complication of round-tripping of source code that is part 
of a Leo outline and is shared with people who don't use Leo. Would it not 
make sense to make the file on disk the medium of exchange? 

John writes above about clones as comparable to symlinks in one of the 
filesystems used by Linux. Is that not a significant observation, since 
file systems have provided multiple sorts of link for decades, and over 
generations of development, applications have been written to use links? 

When was the last work done on building a file system that exposes as files 
the data and metadata available via Leo's API? Years ago, I read of the 
development of FUSE, which allows the development of file system code that 
runs in user space on Linux and macOS; I see reference to similar toolkits 
for Windows. 

Leo supports headless operation with a null GUI. Would it be simpler for 
Emacs and other software to manipulate the Leo file through a Leo File 
System? 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/61e60808-040b-42e5-8917-8baad6ed4287%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: Why I think keyword args are benign

[David Szent-Györgyi]

On Tuesday, April 24, 2018 at 8:38:37 AM UTC-4, Edward K. Ream wrote:
>
>
> It looks like json.dumps may have problems with p.v.unknownAttributes 
> fields.
>
> Again, not a gotcha, but something must be done.
>

Have you had time to look into AXON as a better-for-the-purpose alternative 
to JSON 
?  

-- 
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: Python 2?

[David Szent-Györgyi]

On Sunday, March 11, 2018 at 7:19:24 PM UTC-4, Edward K. Ream wrote:
>
> I have just created #800: Replace pickle with json everywhere in Leo 
> . 
>
> Imo, this is a high priority item.  It should have been done long ago.  
> Terry, do you agree?
>
> I switch frequently, and see this a lot.
>
>
> ​Interesting.  I never see this.  It's fallen off my radar.
>

There may be a better option than JSON. I recall a blog posting about the 
limitations of JSON that are overcome by AXON 
. The 
posting states that unlike JSON, AXON supports comments, provides syntax 
for decimal and date/time values, and supports streams of values. 

The Pypi package pyaxon  runs on 
Python 2.7, 3.3, 3.4, 3.5. Source code is available on GitHub 
. 

In case the original blog posting is not available, it is quoted 
extensively in a tuicool posting . 

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

Is it time to discuss Leo in a MacInTouch lovefest for Dave Winer's MORE outliner?

[David Szent-Györgyi]

I recall reading that MORE was one of Edward's inspirations for Leo. 

A MacInTouch discussion of reminiscences of old technology is full of 
praise for MORE's technology, starting with this comment 

. 

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

[David Szent-Györgyi]

On Saturday, March 3, 2018 at 7:50:31 AM UTC-5, Israel Hands wrote:
>
> What do I use Leo for then?
>
> Content - for me content is king. Manipulate it - tag it - filter it - 
> anything you like but it's about content.
>
> So my first use of Leo is as a free form database for notes, minutes, 
> agendas,passwords, journal type stuff. Leo is a tremendously effective 
> bucket for information - and the ability to link to external files adds to 
> this capability.
> I have written simple Python scripts.  
> So I am by no means a heavy duty user in terms of features but Leo is open 
> on my computers Win10 and OSX all the time. 
>
> However there are things (and these I'm sure are very particular to me) 
> that make me look elsewhere for tools that I probably could and should use 
> Leo for that I don't.
>
> I'm a writer and generally my output is PDFs via Latex. I have looked at 
> the info on a workflow from Leo and just not found the energy to tackle it.
>
> So I use Scrivener - which is tree based - looks great and has a 
> relatively simple 'compile' mode to Latex.  Now any attempt to turn Leo 
> into Scrivener would be madness, but if someone wrote a Latex plugin that
> simple folk like me could use that would be great. However I hear the 
> argument 'there are plenty of text to Latex tools why should Leo be 
> another?' Well Leo has the tremendous advantage of not having to 'contain' 
> all the files
> within itself - it can just reference them. So in Scrivener when I output 
>  the document.tex file and then I want to make edits then I have go round 
> the whole edit in scrivener, compile, TexStudio routine. Whereas in Leo I 
> could just reference the 
> document.tex file and edit it directly from within Leo or just make the 
> final edits in TexStudio know that Leo will be able to reflect those edits 
> in the referenced file. 
>
> Secondly I use org-mode - nothing sophisticated - not even as a todo list 
> - but as my daily agenda and reminder - I need a lot of reminding.  Org's 
> capture and schedule tools are second to none. And with the addition of 
> Beorg on iOS 
> Org is surely going from strength to strength.  Seeing my Org Mode Agenda 
> in Leo would be lovely - having that agenda fire reminders from Leo would 
> be even better. 
>
> I wonder if I am alone on this island or are there other Leo users who 
> step away to do Scrivener and Org type things? 
>

You're not alone. I'm about to begin exploring Scrivener on a Mac, for 
writing technical manuals, including one that would run into the hundreds 
of pages with at least one index - grist for MultiMarkdown, I'm waiting for 
the posting of the Scrivener project for the manual for Scrivener 3. 

I've been reluctant to plunge into Org Mode since I don't necessarily want 
to live in Emacs. 

Twelve years ago or so, I used Leo under Windows to organize a software 
development effort; I loved the outliner-with-clones toolkit. I've wondered 
whether anyone uses Scrivener to track technical support work, with the 
mindset that the history of technical support for a customer is a form of 
storytelling. . . . .

Since my Leo-based project of twelve years ago, I've switched jobs and 
moved from hosting my work on a Windows computer to basing my work on a 
Mac. I haven't figured out a Mac installation of Python and Qt and 
everything else needed for Leo. I gather that work has been done on 
installing Leo via Homebrew. Past reading left me preferring MacPorts to 
Homebrew, since MacPorts addressed multiple-user Macs where Homebrew did 
not. 

But, my Mac-related struggles are grist for a separate discussion thread. . 
. .

-- 
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: Rethinking Leo's distribution process

[David Szent-Györgyi]

On Saturday, March 3, 2018 at 9:06:12 AM UTC-5, Edward K. Ream wrote:
>
>
> ​I would happily abandon all the work we have done, except perhaps 
> assoc.exe.
>

Unless I misread the current situation, the NSIS installer for Leo and all 
its files is no longer in use - the file association is all that you handle 
now. That makes sense, given the use of multiple source trees that goes 
with modern workflow. 

It was clear to me twelve years ago that the detail work of deployment was 
not your focus, you wanted to work on the technologies of Leo itself. I 
wouldn't expect that to change! 

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

[David Szent-Györgyi]

On Saturday, March 3, 2018 at 8:16:33 AM UTC-5, Edward K. Ream wrote:

> ​#774 Convert Leo trees to LaTex as in Scrivener 
>  is a new 
> enhancement request. 
>
> Googling "scrivener convert to LaTeX" yields this page 
> . 
> It doesn't look to difficult to translate this approach into Leo. I've 
> given it a 5.7.1 milestone, which means it will happen this year.
>

Would it make sense to make use of Pandoc ? 

>

-- 
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: The first, urgent task: show people what Leo already has

[David Szent-Györgyi]

On Friday, March 2, 2018 at 11:27:59 AM UTC-5, Edward K. Ream wrote:

*2. Better support for markdown*
>
> #767: Add markdown command similar to rst3 command 
> . I want to move 
> Leo's docs to markdown.
>
> #763: Use html comments to support @file x.md 
> . This will allow 
> structured markdown files.
>

Scrivener  supports 
MultiMarkdown  for technical 
writing. The Wikipedia article on Markdown mentions MultiMarkdown as well 
as other variants in its discussion of standardization efforts 
. Once one has more 
than one standard, there is no standard - which one to use? 

-- 
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: How did I came across Leo?

[David Szent-Györgyi]

On Saturday, March 3, 2018 at 7:56:48 AM UTC-5, Edward K. Ream wrote:
>
> On Sat, Mar 3, 2018 at 6:49 AM, David Szent-Györgyi <das...@gmail.com 
> > wrote:
>
> ​> ​
> My coworker's motto was, "If it's stupid, and it works, it isn't stupid"!
>
> ​Hehe.  It's an arguable point.​
>  
> ​There is also an argument for cleanups, when possible.​
> ​ Vitalije is working on collapsing Leo's tree-drawing code as we speak.
>

Cleanup and improvement are worthwhile, given time and energy that I 
couldn't spare in those days. Now, I have some time to address the matter. 
 

> ​> ​
> Do we know whether @root and @tangle work in 2018-era Leo?
>
> ​@root and Leo's tangle and untangle commands will remain "forever".  They 
> are, on purpose, no longer documented, but there is nothing whatever to be 
> gained by removing a feature that you and others still use.
>

Thank you! 

-- 
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: Rethinking Leo's distribution process

[David Szent-Györgyi]

A decade ago, when you were kindly using NSIS to generate proper Windows 
installers for each release of Leo, I worked on an enhanced NSIS installer. 
In those days, it was possible to install Python itself for all users of a 
machine or for the current user only, and I figured out how to handle those 
cases. My thought was, I would make it possible to install and test a 
development copy of Leo on a secondary Windows login, using an installation 
of Python and one of Leo for the current user only. Testing thoroughly on a 
single machine struck me as worthwhile. 

The NSIS installer required careful management of source code to make it 
work, and the syntax of NSIS scripts was unique. You ended up abandoning 
it. 

Regarding extending the *register-leo.leox* and *unregister-leo.leox *scripts: 
in 
the pre-Windows-Vista days when I worked on the enhanced NSIS installer, 
there was no concern with User Account Control privileges, and I chose not 
to address 64-bit Windows XP. Now, UACs are with us, and Microsoft supports 
the use of 32-bit applications on 64-bit Windows, so the number of possible 
scenarios is greater than it was when I worked on this. 

We also have virtual machine technology that makes it possible to run a 
testbed without multiple accounts, which might limit the need for the 
approaches I worked on. 

-- 
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: Rethinking Leo's distribution process

[David Szent-Györgyi]

On Thursday, March 1, 2018 at 12:49:48 PM UTC-5, Edward K. Ream wrote:
>
> On Thu, Mar 1, 2018 at 11:11 AM, Matt Wilkie  > wrote:
>
>>
>> - No need for sourceforge, pyinstaller, windows installer.
>>>
>>
>> The only significant advantage of those installers over the pip install 
>> route is desktop integration (menu and desktop links, file type 
>> association). This could be done from inside Leo via a settings menu 
>> item[0], though I'm not sure about the effort/profit ratio due to varying 
>> operating systems and elevation privileges.
>>
>
> ​Leo already has assoc.exe, which iirc does all this.
>

I can't find assoc.exe in the source code for Leo. Where is it? What does 
it do? 

I do find in the *scripts* folder within the Leo source code files 
*register-leo.leox* and *unregister-leo.leox *- these handle Windows 
Registry entries for using *launchLeo.py* for a simple one of the (many!) 
scenarios supported by Microsoft. Are these scripts deprecated, or are they 
in active use?

If they are in active use, they might be extended to make for easier 
testing of Leo, and more flexible use. 

-- 
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: How did I came across Leo?

[David Szent-Györgyi]

On Saturday, March 3, 2018 at 2:39:59 AM UTC-5, Edward K. Ream wrote:
>
> On Fri, Mar 2, 2018 at 11:39 PM, David Szent-Györgyi <das...@gmail.com 
> > wrote:
>
>> I employed Leo for an oddball use case, which it addressed beautifully. 
>>
>
> ​
> Quite an interesting project.  Your post is now in LeoDocs.leo and will 
> appear on Leo's web site when it gets updated. 
>

Let me know if I can clarify that posting.  

I was using commands that were by your standards less easy to use. I was 
also structuring my Leo outline in a way that risked data loss if I did a 
Wrong Thing. As such, I did not explain the details of what I'd done. The 
guideline I followed came from a coworker who had to figure out how to 
install assortments of demanding expansion cards in computers that did not 
work unless those cards were installed Just So. My coworker's motto was, 
"If it's stupid, and it works, it isn't stupid"!

I would like to maintain the utilities that I wrote using Leo all those 
years ago - at least one of them remains useful. Do we know whether @root 
and @tangle work in 2018-era Leo?

-- 
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: How did I came across Leo?

[David Szent-Györgyi]

I employed Leo for an oddball use case, which it addressed beautifully. 

How long ago did this start, perhaps 2005? 

The job that I held then required that, without help from work 
infrastructure or from colleagues, I write tools for diagnosing and 
repairing problems with installations of a complicated software package and 
the many libraries it used. The package ran under Microsoft Windows, I had 
to ship the tools easily via e-mail, and they had to run easily, without 
requiring installation or uninstallation. 

In those less paranoid days, the flexible packaging method was a Windows 
Script Host file, in which Microsoft allowed scripts in the supported 
language of one's choice to call modules written in any other supported 
scripting language. Microsoft allowed the storage of multiple modules and 
data files in the WSH file; the format Microsoft employed for this was XML. 

The conventional approach would have been to use a commercial XML editor to 
build the file. XML editors were specialty products sold for huge sums to 
industrial combines. Commercial products were aimed at Big Enterprise 
Publishing with Big Enterprise Money, not at software development by a 
solitary programmer with a garden-variety PC and no budget. I needed to 
build my own editor, or I needed to write tools to pre-process each of my 
tools' source code and the source code for the library routines, then 
assemble the preprocessed code into the multiple WSFs. This would have been 
multiple tools, at least a preprocessor akin to the Unix "m4" command and 
an executable akin to Make, and those would need maintenance. I had no 
budget for buying software. What to use instead?  

Leo offered me a targeted IDE for Python with the ability to manage all my 
source code. It offered the PIM I needed to organize my development effort. 

I had to write scripts in Visual Basic Scripting Edition (VBS), because 
Microsoft deployed it everywhere, and because a lot of modules I could use 
were written in VBScript. With that in mind, I added support for VBScript 
to Leo's syntax highlighting. Leo's architecture made that easy. 

Each of the multiple tools that I would write would end up in a WSF of its 
own. Using Leo's @file commands for the individual WSFs would steer me to 
use a preprocessor-plus-compiler-plus-Make toolkit, so instead I reached 
for Leo's heritage in Literate Programming: I used Leo's now-deprecated 
@root command instead of the @file family of commands, and forced Leo to 
Tangle the section of the outline required to generate a required WSF. 

*That* allowed me to keep a straightforward correspondence between the 
section of the Leo file for each tool and the WSF for the tool itself: once 
I told Leo to Tangle the necessary section of its outline, I *knew* the 
resulting WSFs were correctly formatted and included exactly what I 
required, and nothing more. 

Because the the representation of a module within a WSF was XML, the source 
code for that module had to be encoded, or it had to be packaged specially 
so that the Windows Script Host software would handle it in its original 
form. I did not want to do the filtering, I wanted the outline to contain 
the unchanged file in a Leo node in a form that would guarantee its correct 
representation in the WSF. I was able to figure out how to surround the 
source code's node in the Leo outline in a few extra nodes that would allow 
me to use the source code exactly as it came. *That* made it painless for 
me to add new modules to to my library.  

In those days, Leo's GUI was built on the TKinter package that shipped with 
Python. That release of TKinter is not beautiful by any means, but its 
place as one of Python's Batteries Included meant that my entire 
development environment consisted of the installer for Python; the 
installer for the pywin32 extensions to Python; the installer for Leo; and 
the comparatively tiny LEO file that contained my tools' source code, the 
source code for the library routines, and all my notes. All that went on a 
single CD-RW, and I could install Python and pywin32 and Leo on a Windows 
computer in minutes and tweak my code as needed. 

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

Electron documentation on best practices for security

[David Szent-Györgyi]

To my knowledge, none of us earn a living working on Leo and related 
projects, which means leveraging pre-existing code saves one the effort of 
reimplementing that. Electron may prove to be immensely useful for Leo and 
related projects such as a desktop application made from LeoVue. 

Since I have no experience writing code for node.js or for Electron, I 
looked up Electron's guide on security 
, which is worth 
consideration. 

-- 
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: Distribute only 64-bit executables?

[David Szent-Györgyi]

On Monday, February 5, 2018 at 12:22:30 PM UTC-5, Edward K. Ream wrote:
>
> I am thinking of installing only 64-bit software on my Windows machine, 
> and to release only 64-bit pyinstaller builds.  Here are my thoughts:
>
> 1. Every distribution option doubles the amount of testing required for a 
> release.  In practice, not all options are tested.
>
> 2. Afaik, pyenchant is the only package requiring a 32-bit build. The tail 
> is wagging the dog.
>
> 3. True, 32-bit builds should run on 64-bit machines, so 32-bit builds 
> should be more portable.  But I have my doubts.
>
> Your comments, please.
>

This is the Windows analogue of the Debian GNU/Linux's Multiarch support 
. 

One can make 32-bit builds run on 64-bit operating systems, but that's 
extra work. 

I cope with this sort of problem all the time for work, where the issue is 
installing 32-bit apps that need to talk to hardware - the publisher of the 
Windows-level driver has extra work to do to provide interfaces for 32-bit 
code. 

Corresponding challenges for Leo start with the fact that 32-bit builds run 
on 64-bit machines, as long as the 32-bit build is aware that on a 64-bit 
machine, the C:\Program Files folder is 64-bit, and that C:\Program Files 
(x86) is 32-bit. It is also the case that 64-bit libraries either have 
32-bit duplicates that don't conflict with simultaneous use of the 64-bit 
cousins, or the 64-bit libraries must handle requests from 32-bit 
applications themselves. 

If you were to return to using a NSIS-based installer for Leo, you could 
handle the complications, but you would need to know both how Windows 
requires files placed and how it requires Registry entries places, and you 
would then need to write the NSIS-based installer to address those 
requirements. 

As I recall, you had enough headaches updating the NSIS-based installer as 
files were added and removed - and that was 32-bit Leo on 32-bit Windows 
XP, without the joys of UAC dialogs to handle permissions as forced by 
Vista and more recent versions of Windows. 

Links of interest: 

NSIS 32-bit 64-bit on Stack Overflow 


Stack Overflow: writing registry value in a 64-bit system 


-- 
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: #561: Please explain why making Leo a jupyter client is important

[David Szent-Györgyi]

On Sunday, October 29, 2017 at 6:02:35 PM UTC-4, Offray Vladimir Luna 
Cárdenas wrote:
>
> Collaboration could be done as a desktop app with the proper support for 
> Jupyter kernels with ZeroMQ. As for the Python/Web/Javascript 
> integration, Dash seems pretty interesting and Flask is a minimal 
> library, which should keep things tight. Some time ago I proposed to 
> make the Leo nodes kind of a minimal browser. I don't know how difficult 
> this is, but anyway here are some links for embedded/minimal web 
> browsers and bridging Python with the web: 
>
> - https://stackoverflow.com/questions/3032666/embedded-web-browser 
> - 
> https://www.fyears.org/2017/02/electron-as-gui-of-python-apps-updated.html 
> - https://pawelmhm.github.io/python/pyqt/qt/webkit/2015/09/08/browser.html 
>

Another entry would be qutebrowser, "a keyboard-focused browser with a 
minimal GUI. It’s based on Python and PyQt5 and free software", is GPL3 
licensed, and is at < http://qutebrowser.org/ >. I have yet to try it, I 
don't know that it qualifies as light-weight, if that's desirable. 

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

Licensing concerns raised by new terms of service for GitHub

[David Szent-Györgyi]

I don't know that this is an issue, but a change of terms associated with 
an essential service need to be checked with care. 

According a blog entry posted on March 1 by Debian Developer Joey Hess, 

The new TOS is potentially very bad for copylefted Free Software. It 
> potentially neuters it entirely, so GPL licensed software hosted on Github 
> has an implicit BSD-like license. I'll leave the full analysis to the 
> lawyers, but see Thorsten's analysis 
> 
> . 
>

 Joey Hess's copy of the new Terms of Service, which can be read without 
agreeing to those terms  

Thorsten Glaser's analysis was published on February 28. begins as follows: 

The new Terms of Service of GitHub became effective today, which is quite 
> problematic — there was a review phase, but the problems were not answered, 
> and, while the language is somewhat changed from the draft, they became 
> effective immediately.
>
 

Now, the new ToS are not so bad that one immediately must stop using their 
> service for disagreement, but it’s important that certain content may no 
> longer legally be pushed to GitHub. I’ll try to explain which is affected, 
> and why.


Glaser's link to the new Terms of Service 
 

-- 
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: Why is Leo great?

[David Szent-Györgyi]

On Friday, July 8, 2016 at 10:26:45 AM UTC-4, Karsten Wolf wrote:
>
>
>
> On Tuesday, July 5, 2016 at 7:46:21 PM UTC+2, Propadovic Nenad wrote:
> ... 
>
>> I'd appreciate examples which *show* me why Leo is great. I really want 
>> to love it, honestly. I *tried* to find it extremely useful ten years ago, 
>> when I stumbled upon it after reading about the greatness of outlines 
>> (articles from Steve Litt). Yet by now I have the impression that it's most 
>> useful in a greenfield environment, when you have control of structure, 
>> anyway. Being a contractor, hopping from project to project, I almost never 
>> do such development.
>>
>
> I'm using Leo for about a month now and know the feeling of really having 
> *tried*; my first Leo encounter was with mac-only Leo 1.5 more than 10 
> years ago.
>
> After rediscovering it my personal Leo success story is a project (python 
> + bottle + bootstrap to replace a Filemaker app) which lay dormant for 
> several month and I was depressed every time I re-started development... it 
> was a mess. The main problem being diverging HTML templates.
>
> After I started unifying my templates with leo using cloned sections so 
> several pieces of every template are identical, overview came back and 
> while the project isn't pure fun it started making a lot of progress in the 
> last two weeks. . . .
>
> Despite the many uses let's not forget the origins of Leo: A literate 
> programming editor.
>
> For me it's the first time I'm *doing* instead of *reading about* literate 
> programming. With real projects. And it's increasing my productivity. And I 
> have to be cautious because Leo is capable of ugly accidents (see: Leo 
> highlights and annoyances as seen from a new user 
>  )
>
> And from my POV Literate Programming is still a field without a culture; 
> everybody does something which resembles some aspects of what Knuth wrote 
> about decades ago... but there aren't many agreed on structures and 
> procedures. So we are all dabbling in a 40 year old pioneer field which 
> brought us TeX & Metafont.
>
> That should not be all there is.
>

I used Leo 4.3 and 4.4 extensively as source code management system and 
macro processor for writing utility programs in the form of Windows Script 
Host files. 

For those of you unfamiliar with this curious technology of Microsoft's, 
these files are XML, and a given Windows Script Host file can package 
multiple scripts in multiple languages as well as resources. Unless special 
measures are taken, it is necessary to modify the source code of a given 
script to suit the requirements of XML. I structured the Leo file so that 
no such modification was required, which made it easy for me to introduce a 
new script to the outline for me to use when writing a particular utility 
program. I also figured out how to use Leo to generate multiple Windows 
Script Host files, each of which could include any or all of the scripts. 

I imagine that reading this would have Edward Ream cringing, because I'm 
describing a technique he left behind years ago: I used Leo directives that 
remainin the current source code, though they are deprecated and I do not 
know that they still work: @root, @tangle, @untangle. These commands are a 
clear inheritance from Knuth's Literate Programming. I recall Edward 
writing that they allowed a naive user to corrupt files. I used them with 
care, as a solitary programmer, and they worked flawlessly for me. 

I was a solitary programmer, working on multiple machines, needing most of 
all to take my application development environment with me easily, adding 
to it as I went. Leo 4.3 and 4.4 and Python were extremely easy for me to 
install on the Windows XP computers I used, because all I needed was: 
CPython; Python-Win32; Leo; and my .LEO file. Leo 4.3 and 4.4 used the TK 
toolkit that is part of Python's Batteries Included, and for all the flaws 
of the release of TK bundled with Python, Edward's painstaking work had it 
running well, even if it looked plain and the limitations of TK were a drag 
on his efforts. 

Leo 4.3 and 4.4 gave me a first-rate outliner with clones, and once I put 
in the effort to build my WSH development environment, Leo took care of the 
stupid bookkeeping that would clutter my head with useless trivia of the 
sort that computers can handle perfectly. Add to that the ease of 
organizing to-do lists and development notes within the outline, and Leo 
helped me make myself a more effective worker. I don't know that I can 
offer a praise higher than that. 

In years since, my work life has had me using a Macintosh computer, for 
which Leo's GUI was not a perfect fit. I am hoping that recent improvements 
in window management at the MacOS level ease to work with current Leo, 
using the modern at-commands for file management. I pine for the 
industrial-strength outliner with clones in Leo! 

My work has me returning to 

Re: Leo 5.1.1 final coming March 4

[David Szent-Györgyi]

On Thursday, February 25, 2016 at 7:38:36 AM UTC-5, Edward K. Ream wrote:
>
> I recently had an Aha about releases: minor bugs don't matter! Leo's 
> latest code is typically more stable than any previous "final" release, so 
> we should release "final" releases much more often. Say every two months or 
> so.
>
> Regular releases are important. Some people will only download so-called 
> "final" releases. And they keep Leo in the public eye.
>
> The remaining tasks before Leo 5.1.1 final are:
>
> - Get PyInstaller versions of Leo working on Windows, Linux  & MacOS.
> - Fix problems with the vim and xemacs plugins.
> - Polish the Code Academy posts.
>
 
This is the best news about Leo that I have read in some time. It arrives 
as I was preparing to write you to ask for detailed instructions for 
rolling my own PyInstaller versions for Windows and OS X. 

I expect that I am a minority among the community of Leo users, because 
following the Leo documentation and using full-blown installations of 
CPython, Qt and Leo isn't an option for me on Windows 7 or on OS X. I have 
to leave IronPython as the default Python on my Windows machine because it 
is the scripting engine for applications I user for work, and I don't have 
source code for those or the ability to configure them to ignore a 
secondary Python. I log in without Admin rights to the Mac I use, and I 
have multiple log-ins, which means that Homebrew is not useful. 

-- 
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 5.1.1 final coming March 4

[David Szent-Györgyi]

I tried the experimental PyInstaller set-up you released a few months back, 
under 64-bit Windows 7. I have not used it, because it uses Python 2.7.8, 
which is no longer supported and contains known security holes that have 
been patched in subsequent updates. Would it be possible to check all the 
bundled software and use software that is fully patched for security? As I 
type this, the documentation for Leo 5.1 lists the dependencies as: 

Docutils: current release is 0.12. 
Feedparser:current release is 5.2.1. 
Markdown: 1.0.1 is current (dating from 2004! given the numerous alternate 
implementations, I wonder whether this one is the state of the art. 
Markdown is John Gruber's creation, of course)
Python: Version 2.7.11 is the current release of CPython 2.7. 
PyEnchant: current release is 1.6.6. 
PythonTidy: current release is 1.2.2, 
PyQt4: current release is 4.11.4.
PyQt5: current release is 5.5.1.  
Sphinx: current release is 1.35+.

-- 
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: Revisiting the generation of the .nsi install script

[David Szent-Györgyi]

On Sep 7, 7:05 am, Edward K. Ream edream...@gmail.com wrote:

 I sympathize with the goal of making it easier to change the installer
 script.  I don't usually like to do that by creating three external files
 that must be kept in synch :-)  It's already bad enough that we must
 remember to bzr ls -R bzr-manifest.txt before running the install script.

 Could you live with the following scheme?  Place all boilerplate in
 nsi-installer-boilerplate.txt.  The nsi generation script (in @button make
 leo.nsi) will copy that file verbatim near the start of leo.nsi.  This seems
 a bit simpler than what you propose.

I sympathize with your desire to not abandon a scheme that works now
in favor of one that you have not seen work.

I expect that you would not relish the prospect of further labor: of
changing the outline nodes that generate the script and one-time edits
to restore the .nsi file. I won't volunteer anyone's time but my own
for this.

I could create a branch from a suitable revision of Leo's source code,
working in private until my code is finished. I could even publish it
on Launchpad for anyone else to follow along. The rest of Leo would
change during my work, but I doubt that the contents of leoDist.leo
and the files it contains would see changes from anyone other than
me.

My development would start with work to implement my scheme alongside
yours, generating a separate .nsi file and using software -- a diff
tool or Leo itself -- to prove that my scheme's .nsi file includes the
exact statements included in yours.

There -- no essay, just blunt English!

With the human aspects of this addressed, on to the technical
arguments!

Your proposal -- putting all the boilerplate in a .txt file  -- would
allow me to maintain all the code in one place. It would still mean
editing the boilerplate in the .txt file and the calls to the
boilerplate in a Python script elsewhere in the Leo outline. I see
this as similar to keeping the Leo trunk and a release branch in sync,
which you write elsewhere is causing you headaches this week. I think
the outline would be easier for developers to understand if the .nsi
file were fully represented as a first-class citizen.

The current scheme uses a button to generate the .nsi file. The scheme
that I am suggesting would still use a button.This revised button
would generate the file manifest, delete manifest and
definitions .nsi files for the real .nsi file to include. Why not
have the button call bzr to generate the manifest file and then call
the NSIS compiler to generate the .exe, and (if the compilation turns
up no errors), delete the manifest files and the .nsi file? That way
there would be no synchronization problem -- the Leo outline's button
would be the *only* way to generate the Leo installer.

I read in multiple sources that Python is a great tool for gluing
together other software. This sounds like a gluing job.

-- David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
leo-editor group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Re: Revisiting the generation of the .nsi install script

[David Szent-Györgyi]

On Sep 7, 9:01 am, Edward K. Ream edream...@gmail.com wrote:
 On Mon, Sep 7, 2009 at 7:47 AM, David Szent-Györgyi das...@gmail.comwrote:

  Your proposal -- putting all the boilerplate in a .txt file  -- would
  allow me to maintain all the code in one place. It would still mean
  editing the boilerplate in the .txt file and the calls to the
  boilerplate in a Python script elsewhere in the Leo outline.

 This seems to me to be a reasonable plan:

 - Rather than reading the boilerplate, the script generator script could
 simply generate an !include line.

 - leoDist.leo could contain @thin nsi.boilerplate.txt tree.

 This scheme would allow all aspects of the final .nsi script to be written
 in leoDist.leo.

I can try later to convince you otherwise, but it'll be best for the
users if if we go with your nsi.boilerplate.txt tree plan for now. I
will branch from the initial nsi.boilerplate.txt revision and start
enhancing the installer.

Would you like me to publish my branch before you return from
vacation? It would be available for the use of anyone who needs an
installer fix.

-- David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
leo-editor group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Revisiting the generation of the .nsi install script

[David Szent-Györgyi]

Bear with me in this long essay. I have to convince Edward to abandon
code that he has just written. I do have a replacement in mind, which
I describe. I also have a Leo story to tell -- one that shows that my
experience using Leo has soured me on working without it!

With a new scheme for generating the .nsi file just launched with the
release of Leo 4.6.3, my timing is poor, but I think the generation
needs to be revisited;. The version just finished greatly simplifies
the maintenance of the lists of files installed and files uninstalled,
but it renders maintenance of the rest of the script painfully
difficult, much more difficult than was the case with the .nsi install
scripts used for Leo 4.4 and earlier. I propose an approach that would
preserve Edward's automated generation of lists of files and allow the
maintenance of the script source code in Leo.

For the sake of the reader whose interest ends with the proposed
approach, let us start with that. It is straightforward. The list of
File commands and the list of Delete commands that represent the
files to be installed or uninstalled go in separate
LeoInstallManifest.nsi and LeoDeleteManifest.nsi files; the source
code for leo.nsi uses !include commands to use the NSIS compiler's
preprocessor to incorporate these two files. The definitions created
by the Python script are written to a LeoDefinitions.nsi file; the
source code for leo.nsi uses another !include command to pull in the
contents of that file.

This way, we can generate LeoInstallManifest.nsi and
LeoDeleteManifest.nsi and LeoDefinitions.nsi using the Python code
from the Leo 4.6.3 leoDist.leo. Edward retains the automation for
which he worked; because we can abandon the special-purpose Python
code that writes the source code for the rest of the .nsi file;
because we can abandon the one-off preprocessor written in Python; and
because the leoDist.leo outline becomes more stable because the ever-
changing manifests and definitions are generated by code that does not
change. Developers working on the logic of the installer gain because
the .nsi file lives in a Leo outline.

I have already hand-tested the use of the !include command to
include a LeoInstallManifest.msi file, and the NSIS compiler runs to
completion on the result, so I'm confident that this is feasable. The
required changes to leoDist.leo should be minimal, a few hours' work
at most.

Any comments? I am willing to get started on the changes, beginning
with a switch to my proposed approach incorporating no changes to the
installer; with that accomplished, Edward, Rob Sheppard, any other
interested folk and I can start enhancing the installer itself.

Now, on to my Leo story.

In working on the new Leo installer script, Edward went to some
trouble to automate the generation of the lists of files that are to
be installed or uninstalled -- because hand-editing those lists is at
best a distraction from the work he really wants to do. That makes
sense to me; I hate such distractions in my own development work. I
ran into many such in making changes to the logic of the installer
script as that script exists in the released Leo 4.6.3. This release
of the script is broken into small pieces, each of which is altered to
allow for preprocessing and stored in a Python string. The code in
each string is no longer exactly in NSIS installer syntax, and any
changes to it must be altered so that the preprocessor produces a
legal .nsi file.

The script is source code, and treating it as boilerplate text in
Python strings prevents the use of Leo to maintain the source code. As
the script grows more complicated, that becomes a barrier to
development. Here I illustrate.

The changes on which I am working introduce additional logic in a
number of the sections of code. In the Leo outline that contains my
installer for Version 4.4-rc1 of Leo, the added logic exists in nodes
that are children of the sections to which they apply. How to add that
logic to the Version 4.6.3 installer? I can think of two schemes for
this. According to the first, I would simply paste the longer logic in
the existing strings. That quickly buries the logic, rendering the
code Really Hard to Read. According to the second scheme, I would
replace the relevant guts of the generator. For each Python function
that required new logic, I tear out the simple string assignment and
put statement, and in its place I write more functions, each of which
contains a simple string assignment and put statement.

I tried this second scheme. For example, in place of the putOnInit
function, I produced a new putOnInit, which calls ten functions, three
of which also call functions. Why is this a Leo story? It is such
because I am used to using Leo to break down long sections of code
into comprehensible parts, and I was doing that by hand in this code.
In short, I was mimicing the Leo outline in the hand-written source
code in the hope of returning the code to Leo later! I was working
very hard in 

Re: What to do about the windows installer?

[David Szent-Györgyi]

On Jun 17, 10:07 am, Edward K. Ream edream...@gmail.com wrote:
 Problems with the windows installer persist.

 The 'make' button in dist.leo creates the installer's exe with a
 pretty gross hack: appending the .zip file to an already-existing .exe
 file.  I don't know whether this hack contributes to the problems
 users are having.  The hack uses the Python 2.5 version of the
 original .exe file, and the make button ensures that dist.leo was
 opened using Python 2.5.

 I do know that these installer problems are tiresome, and they often
 create more trouble for users than the installer is worth.  I also
 know that I'm not qualified to fix installer problems.

 Anyone have any idea what to do about this mess?

Since I never delivered my modifications to the NSIS-based Windows
installer for Leo, you might with justice question my right to comment
here. Just let me know whether you want me to share what I got done or
what I learned. Details follow.

I got the modified installer almost finished before work issues and
personal constraints forced me to put it down. The work issues are no
longer an issue, and I can manage the personal constraints at this
point.

I gather that the installers for Leo 4.5 and Leo 4.6 are written in
Python instead, and that they use the Python-standard tools. If you
wish to apply what I learned to the Python-based installer, I can
share what I learned while working on the NSIS-based one. If it would
make more sense to go back to the NSIS-based installer, a bit of work
should make it possible to incorporate my changes with current Leo and
start from there.

I tested my modified installer with Leo 4.3 and 4.4 under Windows XP
Professional; I did not have access to a Windows Vista box.  I do not
remember for certain whether I tested it with Python 2.3; I definitely
tested it with Python 2.4 and Python 2.5.

This modified installer correctly handled installation of a single Leo
for all users, using a Python installed for all users. If offered the
option of a Leo for the current user only, that worked with a Python
installed for that current user only also. Windows makes this set-up
relatively easy, and I concluded that this would simplify testing on
multiple versions of Python. It also supports testing Leo on multiple
installations of a given release of Python, which allows for testing
Leo with more than one configuration of Python.

The modified installer also checks to make sure that it does not break
in various ways.

Let me know what you want me to do.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
leo-editor group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Re: What to do about the windows installer?

[David Szent-Györgyi]

Google Groups hiccuped, and may have devoured my reply. Just in case,
I am re-writing it.

On Jun 17, 10:07 am, Edward K. Ream edream...@gmail.com wrote:
 I do know that these installer problems are tiresome, and they often
 create more trouble for users than the installer is worth.  I also
 know that I'm not qualified to fix installer problems.

 Anyone have any idea what to do about this mess?

Since I never delivered the revised NSIS-based Windows installer that
I was working on, you would be entirely within your rights to discount
what I write now, but here goes. Let me know what you want me to do.

The revised installer is almost finished. It runs on Windows XP
Professional; I had no access to Windows Vista for testing. It
correctly handles Leo 4.3 and Leo 4.4, and works with Python 2.4 and
Python 2.5.

It checks for a Python that is installed for the current user, and
then it checks for a Python installed for all users. It installs a
copy of Leo for the current user only if it finds a copy of Python
that is available to that user only. It installs a single copy of Leo
for all Windows users when it finds a copy of Python that is available
to all users.  Installing for the current user only might appear to be
of limited importance, but consider how I used it: I created a couple
of Windows users for testing the installer, and was able to test with
multiple versions of Python, multiple installation scenarios...
without breaking the set-up that I used for compiling the installer.

I gather that the installers for Leo 4.5 and Leo 4.6 are written in
Python. If you think the Python-based installer is worth continuing I
will be happy to share what I learned in my work on the NSIS-based
installer. If you think it would make more sense to pick up the NSIS
installer, a bit of work with my revised version may bring it into the
current era.

I gather that one of the goals of the switch to the Python-based
installer was to install Leo as a package. I expect that it ought to
be possible to use NSIS to drive that intelligently, too.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
leo-editor group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Re: What to do about the windows installer?

[David Szent-Györgyi]

On Jun 17, 10:07 am, Edward K. Ream edream...@gmail.com wrote:

 I do know that these installer problems are tiresome, and they often
 create more trouble for users than the installer is worth.  I also
 know that I'm not qualified to fix installer problems.

 Anyone have any idea what to do about this mess?

Since I never delivered my modifications to the NSIS-based Windows
installer for Leo, you might with justice question my right to comment
here. Just let me know whether you want me to share what I got done or
what I learned. Details follow.

I got the modified installer almost finished before work issues and
personal constraints forced me to put it down. The work issues are no
longer an issue, and I can manage the personal constraints at this
point.

I gather that the installers for Leo 4.5 and Leo 4.6 are written in
Python instead, and that they use the Python-standard tools. I gather
that one of the goals of the switch to the Python-based installer was
to install Leo as a package. I expect that it ought to be possible to
use NSIS to drive that intelligently, too.

If you wish to apply what I learned to the Python-based installer, I
can share what I learned while working on the NSIS-based one. If it
would make more sense to go back to the NSIS-based installer, a bit of
work should make it possible to incorporate my changes with current
Leo and start from there.

I tested my modified installer with Leo 4.3 and 4.4 under Windows XP
Professional; I did not have access to a Windows Vista box.  I do not
remember for certain whether I tested it with Python 2.3; I definitely
tested it with Python 2.4 and Python 2.5.

This modified installer correctly handles installation of a single Leo
for all users, using a Python installed for all users. If offers the
option of a Leo for the current user only, that worked with a Python
installed for that current user only also. This simplifies testing on
multiple versions of Python. It also supports testing Leo on multiple
installations of a given release of Python, which allows for testing
Leo with more than one configuration of Python ... without breaking
the set-up that I used for compiling the installer.

The modified installer also checks to make sure that it does not break
in various ways.

Let me know what you want me to do.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
leo-editor group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---