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]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/c4401dca-c02a-4859-a4fe-e652fc7e6548n%40googlegroups.com.
