Re: How are @latex nodes used?

[Edward K. Ream]

On Sun, Nov 14, 2021 at 11:49 AM tbp1...@gmail.com 
wrote:

So before I enable *@latex *nodes in VR3, I'd appreciate some guidance
> about  how people want to use it.
>

I never use LaTex, so I will be no help :-)

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/CAMF8tS1ThJS4vo-hfHb63XniqZ6z3_c0K_%2BzofM52FRRLfwb_w%40mail.gmail.com.

How are @latex nodes used?

[tbp1...@gmail.com]

Viewrendered can render *@latex* nodes in a restricted way.  I was reminded 
of this by an issue of @LewisNeal . VR3 does 
not at present but it would be easy to duplicate VR's capability.  I have 
two questions about it before I move to enable it in VR3.  One is minor, 
the other more existential.  The minor one first:

The code claims that in Windows/python the rendering is not available. But 
all the rendering code does is to insert the node's text into a basic html 
string that includes an import for the MathJax script.  That does not 
depend on Windows or the python version in any way.  So why is this 
restriction there?  It makes me think that @latex nodes used to be able to 
do more at some time in the past.

The more existential question is: what is this capability for, anyway?  
What is the use case? It must mostly be for rendering math, but math almost 
always requires some text along with it.  Mathjax can render plain text 
using the *\\text{}* macro, but this is awkward  and limited.

VR3 can already render math in ReStructured and Markdown text pages, and 
can mix text and math more easily.  I think that full latex rendering - 
beyond what Mathjax can do - is not going to be in the cards for VR/VR3.  
You would have to use a full-fledged latex processor, and they are very 
slow and finicky about the content. TexWorks, for example, sometimes 
requires manual input to deal with hiccups.

So before I enable *@latex *nodes in VR3, I'd appreciate some guidance 
about  how people want to use 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/7742fb8b-c266-456d-ad0e-d526fb89677bn%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 
>>  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. 
>>
>
> 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.

ENB: The python importer

[Edward K. Ream]

#2327  suggests 
improving the python importer. This issue is scheduled for Leo 6.7, but it 
may make it into 6.6.

This Engineering Notebook post consists of notes to myself.  Feel free to 
ignore.

*Defects*

I've put up with the following defects of the python importer for way too 
long:

1. Perfect import checks can fail due to underindented lines, especially 
comment lines.
2. Perfect import checks can fail due to misplaced (or missing?) decorator 
lines.
3. The python post-pass code is a bit of a mess.
4. The python importer's main line, py_i.gen_lines, may be more complex 
than necessary.

*The causes of complexity*

The python importer is *far* more complex than the python-to-typescript 
command:

- The importer must, without fail, handle strings and docstrings properly. 
This requirement entails the entire token-state logic.
- Decorators complicate how the code recognizes the start and end of 
classes and functions.
- Allocating "in-between" lines (lines between functions or methods) is 
always going to be tricky.  Presumably, the post pass will play a part.

*The goals*

The python importer must import *all* python files exactly, except for 
*underindented 
comment lines*.

The python importer should be allowed to adjust underindented comment lines 
by adding needed indentation.

The python perfect import checks should warn about adjusted comment lines, 
but the python importer should *not* insert @ignore directives merely due 
to adjusted comment lines.


*Open questions*

1. Which code should handle decorators: the main line or the post pass?

2. Which code should handle in-between lines?

*Summary*

The python importer is shockingly inadequate:

- The importer inserts @ignore directives for way too many files.
- The post pass does not account for the *indentation level* implied by 
@others directives. Indented @others directives increase this level. 
- The code that handles decorators is complex and buggy.
- The post-pass needs a redesign.

The overall design and organization of Leo's importers will remain 
completely unchanged. Only the Py_Importer class will change.

I'll fix #2327  for 
Leo 6.6 if possible, but I shall not hurry this project.

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/5015aafe-5d26-4514-892b-d7ffd96c434an%40googlegroups.com.