About Leo and rust

[Edward K. Ream]

Vitalije has been looking into enhancing (somehow!) Leo with rust.  This is a worthy project, for several reasons, which need not be listed here. 

Project champions never need my permission to follow their dreams.  Indeed, a champion is someone who persists in a dream despite indifference or even resistance from others.

This post explores various constraints on the final result of prototyping.  Let's use the "you can do this if" guidelines. Leo can work with rust if:

1. Distributing Leo doesn't become substantially harder.  Not sure what this means.  In any case, we can ignore this constraint during prototyping.

2. Leo continues to use Qt for its gui.  Again, this constraint can be ignored during prototyping, but it should be taken seriously.

Imo, adding rust wrappers for the (C++) Qt code is something that the Qt people themselves might well offer.  Or the same effect might be gotten in other ways.  If not, rewriting leo.core.leoQt in rust would likely suffice.  So this will not likely be a gotcha.

3. All parts of Leo continue to work unchanged.  This includes the python api.

I believe this is feasible, despite rust being less "dynamic" than python.  I've said several times that Leo's flexibility does not derive from python's dynamic nature.  For example, @command, @button and all the rest do not depend on monkey-patching Leo's classes.  The "dynamism" of @button happens just by creating new entries in tables.  That can be done in any language.

Likewise, adding a plugin just adds to existing data structures.  Adding a rust plugin would likely be feasible using a python wrapper around the rust code.  Or some other way.

There are a few places where Leo's code does monkey-patch code, but they aren't gotcha's.  The same effect could be gotten in other ways.

Summary

I have listed several constraints on integrating rust with Leo's python code base.  All are subject to revision.  I see no gotchas.  Have at it!

Edward

[Matthew Piziak]

I love these kinds of posts from maintainers. Thanks for being so explicit about your architectural constraints.

I like using Rust as a performance trapdoor for higher-level languages, since it's fast and it has no garbage collector (which means it doesn't fight with the calling language). Also, I used to be a minor contributor and it's the finest language community I've ever collaborated with—the upstream support and encouragement is top notch.

Good luck Vitalije et al.!

[Offray Vladimir Luna Cárdenas]

Thanks for this encouragements to experiment with Leo in new directions.

At some point I plan to retake the Pharo Chronicles, but I think that Leo/Grafoscopio integration would be done at file reading level. I would like to read some Leo outlines from Grafoscopio.

Cheers,

Offray

--
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+...@googlegroups.com.
To post to this group, send email to leo-e...@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/87fbf3c1-94c3-40d1-9681-45a7e7ed202e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Thu, Jul 18, 2019 at 11:33 AM Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

Thanks for this encouragements to experiment with Leo in new directions.

At some point I plan to retake the Pharo Chronicles, but I think that Leo/Grafoscopio integration would be done at file reading level. I would like to read some Leo outlines from Grafoscopio.

That's good news.  I'll help any way I can.

Edward

[Paul Jackson]

On Saturday, July 6, 2019 at 12:04:56 PM UTC-5, Edward K. Ream wrote:

Vitalije has been looking into enhancing (somehow!) Leo with rust.  This is a worthy project, for several reasons, which need not be listed here. 

There is some work providing Qt wrappers for use in Rust at  https://github.com/rust-qt, and some discussion of this at https://www.vandenoever.info/blog/2018/09/16/browsing_your_mail_with_rust_and_qt.html.   See also https://libraries.io/github/rust-qt/ritual.  This chap has a 26 minute presentation discussing connecting Rust and Qt using a JSON data model: https://archive.fosdem.org/2018/schedule/event/rust_qt_binding_generator/

At first glance, it looks challenging.  Due to the "impedance mismatch" between C++ as used by Qt, and Rust, only a subset of Qt is available to Rust code.

===

I also just noticed that there is no "Leo colorizer control file for rust mode" in Rust, as of the version of Leo I am running: Leo 6.0-b1, master branch, build 445dfa149e 2019-06-18 09:45:56 -0500.  If I knew Leo and Rust well enough to code my way out of a paper bag, I might contribute such myself, but I'm a rank newbie at both.  So I'll almost certainly not get to that in any forseeable future.

[Edward K. Ream]

On Thu, Jul 18, 2019 at 10:07 PM Paul Jackson <thepyth...@gmail.com> wrote:

On Saturday, July 6, 2019 at 12:04:56 PM UTC-5, Edward K. Ream wrote:

Vitalije has been looking into enhancing (somehow!) Leo with rust.  This is a worthy project, for several reasons, which need not be listed here. 

There is some work providing Qt wrappers for use in Rust at  https://github.com/rust-qt, and some discussion of this at https://www.vandenoever.info/blog/2018/09/16/browsing_your_mail_with_rust_and_qt.html.   See also https://libraries.io/github/rust-qt/ritual.

At first glance, it looks challenging.  Due to the "impedance mismatch" between C++ as used by Qt, and Rust, only a subset of Qt is available to Rust code.

Thanks for these links.  I've bookmarked them.  Wrapping libraries is always going to be a major project.  We'll see what happens...

Edward