On the idea of a Leo core in a machine efficient fast language, I think that Nim is a worth exploration also, as is syntax is Python inspired, compiles to JavaScript, has good metaprogramming facilities. I have found it pretty productive when I need a more low level or multi-paradigm, cross browser approach to my coding needs.
https://nim-lang.org/ Offray On 16/12/20 2:17 p. m., vitalije wrote: > Here are some ideas which you are free to ignore if you find them > uninteresting or useless. > > There is also a possibility to have Leo's core implemented in rust (or > some other low level language) and exported as both python extension > module and node module. I've started to work on this idea, but right > now I am too busy to work on that project (mini_leo > <https://github.com/vitalije/mini_leo/>). > > I did offer Felix to use this code (instead of leoBridge) when he > started his project, but he wasn't interested. > > Exporting rust functions to python and node is easy. There is a > possibility to export same functions as a wasm module for use in the > browsers too. > > I don't fully remember current state of the project but IIRC there are > already functions for reading/writing .leo files, derived at-file > files, iterating through outlines, basic outline manipulations. > Here is a benchmark test: > > Python 3.7.0 (default, Jun 28 2018, 13:15:42) > [GCC 7.2.0] :: Anaconda, Inc. on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> def f(): > with open('leo/test/activeUnitTests.txt', 'r') as inp: > s = inp.read() > return _minileo.outline_from_str(s) > >>> import _minileo > >>> import timeit > >>> print(timeit.timeit(f, number=100)/100*1000, 'ms') > 6.344196610007202 ms > > As you can guess function outline_from_str parses derived at-file > content and builds outline. leo/test/activeUnitTests.txt used to be > the largest derived file in Leo's code. There is also a function > load_leo to load outline from .leo file along with all external > (derived) files. > > I've also some ideas of using sqlite3 in combination with a few > functions written in rust for dealing with the outlines. I had some > very promising experiments with this idea. The sqlite3 proves to be > fast enough (faster than python) for iterating outlines, handling > undo/redo, searching for nodes,... > And exporting this functionality to all scripting languages (python, > nodejs, and javascript in browsers) is straightforward. > > I don't know when will I have the time to continue work on this > project, but the code is there, for what it's worth. > > Reimplementing Leo's core classes in Python to be compiled to > JavaScript, today, is IMHO a bad idea (YMMV). Python is great for > other parts of Leo, but not so great for the core. If the core should > be reimplemented at all, I believe it would be complete waste of time > unless it is reimplemented in a language that is substantially faster > than the current python implementation. Rust seems to be fine choice > these days for this task. The library can be cross compiled to work on > any machine, including browser and it also allows exporting native > rust functions to both python and nodejs. But Rust isn't the only one > in town. There are also zig and v languages. Both of them claim that > they've fixed almost all problems with C language. Both of them offer > good cooperation with python, nodejs and javascript in browser. > > I dream of a Leo core module that could be easily used in server code, > browser front-end and native gui front-end. With such a module and > little bit of scripting it would be trivial to have outlines displayed > on the web and editing outlines remotely. Imagine the combination of > leo-ver-serv (which keeps detailed history of my Leo outlines taking > snapshots every few idle seconds), editing outlines remotely, and > displaying outlines in browser. That combination would be better for > hosting code than github. Currently presentation of Leo outlines on > github is terrible. Imagine that people can see the code organized in > Leo outlines, and even to suggest some change by editing nodes > directly in browser. > > My two cents. > Vitalije > On Wednesday, December 16, 2020 at 5:27:06 PM UTC+1 Edward K. Ream wrote: > > This Engineering Notebook post considers strategies for > implementing the crucial parts of Leo in javascript. leojs issue > #9 <https://github.com/boltex/leojs/issues/9> recaps what must be > done. The following must be present in leojs 0.1: > > - Leo's Position and VNode classes, > - Outline-oriented undo, > - Outline-oriented search. > > That's a lot of complex code! > > True, leojs is worth any amount of work. However, it would be > stupid to dive into coding! This morning I considered some cute > possibilities for doing significant parts of the work in python. > Then I thought to google: "python to javascript" :-) > > One of the first hits was this overview > > <https://www.infoworld.com/article/3209651/how-to-convert-python-to-javascript-and-back-again.html>, > which leads to: > > - JavaScripthon <https://github.com/metapensiero/metapensiero.pj>: > a Python 3 to ES6 JavaScript translator. > - RapyScript <https://github.com/atsepkov/RapydScript>: > pre-compiler for JavaScript. > The syntax is very similar to Python but allows JavaScript as well. > - Transcript <http://www.transcrypt.org/>: compile python to JS. > - Pscript <https://github.com/flexxui/pscript>: the compiler part > of flexx <https://flexx.readthedocs.io/en/stable/index.html>. > > *Summary* > > This has been a much shorter post than I first imagined :-) One or > more of the tools listed above will likely suffice. A little > googling pays off! > > leoInteg requires Leo's bridge to provide most of Leo's > functionality. The communication between Leo's bridge and leoInteg > is fraught with difficulties. Transcribing the essentials of Leo's > core into JS will eliminate many of those difficulties. > > Besides transliteration, other problems will surely arise. Félix > and I will deal with those problems as they arise. Time to > evaluate transpilers! > > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/leo-editor/c4401dca-c02a-4859-a4fe-e652fc7e6548n%40googlegroups.com > <https://groups.google.com/d/msgid/leo-editor/c4401dca-c02a-4859-a4fe-e652fc7e6548n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/2e00ecd4-9715-2dad-b79b-fe5d13a62e29%40riseup.net.
