Reading your responses I noticed my own mistake:
> - Separate code from outputs. One of the main strengths for Leo,
combining code and results into the same document, is also one of its main
limitations.
I meant " One of the main strengths for **Jupyter**, combining code and
results into
I think it's also about building on Jupyter concepts as reproducible
literate programming platform, not just cloning its current functionality
See it as an alternative to the JupyterLab application
(https://channel9.msdn.com/Events/PyData/Seattle2017/BRK11), reusing the
same capabilities from
I'm following this thread and new wave of ideas for leo with great attention. I
really like the goal of making leo a more interactive platform for
keeping/editing knowledge bases... Great job everybody!
Just my 2 cents:
Maybe sqllite is just a tool for a greater purpose, a step toward a greater
A couple of links related to "versioning" just in case they serve as an
inspiration:
http://coreobject.org/technotes/
(https://www.youtube.com/watch?v=UmpaAunTEQ0)
https://github.com/mirage/irmin
(http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-things-done-in-the-browser/)
This
A possibility could be to specify a schema for a given json file indicating how
to structure the document. That would expand the possibilities for Leo to
handle flat-file hierarchical datasets for applications like bookmarks manager,
bibliographies, etc. A similar concept is implemented in
A possibility could be to specify a schema for a given json file indicating how
to structure the document. That would expand the possibilities for Leo to
handle flat-file hierarchical datasets for applications like bookmarks manager,
bibliographies, etc. A similar concept is implemented in
A possibility could be to specify a schema for a given json file indicating how
to structure the document. That would expand the possibilities for Leo to
handle flat-file hierarchical datasets for applications like bookmarks manager,
bibliographies, etc. A similar concept is implemented in
Also, there is a young project named nteract (github.com/nteract/nteract) that
seems to be an interesting option as a lightweight and modular reusable
alternative for rendering notebook cells in a web view.
BTW, the container application in this case is electron (using node.js), which
uses
I tried a similar solution before using (https://github.com/damianavila/vIPer)
and I don't remember it being that slow... I'll recheck again
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails
Could this "multi-graph" structure be a mechanism to implement version
control in Leo? As you know, the fundamental data structure for Git and
other version control systems is also a DAG. If, in addition to the
existing tree representing the document structure, there is another tree
defining
10 matches
Mail list logo
