Re: jupyter files

[Offray Vladimir Luna Cárdenas]

On 26/08/17 12:43, Edward K. Ream wrote:
> On Sat, Aug 26, 2017 at 10:11 AM, Offray Vladimir Luna Cárdenas
> > wrote:
>
>
> Usually the collaboration between Leo and other languages has been
> by being able to read/parse what these languages store (*ipynb,
> *html, *js, etc) and convert them into a Leo tree to extend,
> reorganize such "plain" files and export them back. I have
> advocated another kind of collaboration, passing from files to
> services, by connecting Leo with IPython kernel (via ZeroMQ) and
> make a Leo node equivalent to a IPython cell.
>
>
> ​I'm glad you keep trying to educate me :-)

It has been reciprocal, You, Leo and its community taught me a lot and
still do :-).

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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: jupyter files

[Edward K. Ream]

On Sat, Aug 26, 2017 at 10:11 AM, Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:


Usually the collaboration between Leo and other languages has been by being
> able to read/parse what these languages store (*ipynb, *html, *js, etc) and
> convert them into a Leo tree to extend, reorganize such "plain" files and
> export them back. I have advocated another kind of collaboration, passing
> from files to services, by connecting Leo with IPython kernel (via ZeroMQ)
> and make a Leo node equivalent to a IPython cell.
>

​I'm glad you keep trying to educate me :-)
​

> So a snipped of code in Leo can be computed and returned by/from IPython
> to the Leo tree. Leo should have some kind of directive to indicate that a
> node is an IPython output and that is associated with a particular input
> node.
>

​Interesting.​

>
> After trying with Python/Web related technologies to implement such ideas
> of outlining and live coding/documentation [3], I opted for Pharo, agile
> visualization and moldable tools, with better/quicker results for me. So, I
> can not go into further code details on implementation and just move in the
> conceptual space, because now I'm far away from Python, but I still would
> like to see the implementation of Leo/Jupyter collaboration also/mainly by
> services instead of "only" by files. I think this would open important new
> paths and visibility for Leo.
>
> [3] http://mutabit.com/offray/static/blog/output/posts/
> grafoscopio-idea-and-initial-progress.html
>

​Thanks for these thoughts.

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: jupyter files

[Edward K. Ream]

On Sat, Aug 26, 2017 at 8:30 AM, Josef  wrote:

I was hoping to be able to read into an @clean node instead of using @auto
> or @nosent, as I need to cooperate with others, not using Leo.
>

​Why is this a problem?  Just read the file into @auto the first time, then
change it to @clean.​

What do you mean by compatibility? Are you suggesting that Leo could write
>> some parts of outlines as .ipynb files?​
>>
>
> yes. But note, I am only an occasional Jupyter user. Still some people I
> work with might be inclined to cooperate via a Jupyter file, while I am
> skeptical about them using Leo - sadly.
>

​I suggest not worrying about your co-workers just yet ;-) Let's focus on
converting to and from Jupyter files in a way that works for you.


>> ​Interesting idea. The present .ipynb importer is just that: only an
>> importer.  Perhaps a post-pass could massage the imported nodes into a more
>> useful form, squirreling away less useful data somewhere for eventual use
>> by the exporter.
>>
>
> That's what I had in mind too.
>

​Oh good.  I'm glad we are thinking in the same direction.​

> ​
>>
>> ​> ​
>> I also would like to see features, to export selectively certain sections
>> to Latex:
>> Jupyter can export to Latex too, but I found a 1:1 copy not useful for
>> inclusion into a paper.
>> I need more control over the latex output, and by latex I mean not only
>> formulas.
>> I would like to export some text and output of calculations (tables,
>> graphics) to latex snippets,
>> which would then be \input to a latex document.
>>
>> ​As always,
>>  the most general and flexible solution to such problems is a custom
>> script, which by definition can do anything.
>>
>>
>> Having said that, it is simpler to define some kind of framework for
>> specifying desired parts of text.  This could be done using additional
>> markup.  Would this be useful? If so, I would glad to help you with such a
>> project.
>>
>
> In principle I like the idea of such a framework (may be more general than
> just for work with latex documents).
>
> Thinking more about it, I don't think I want to just export, but whatever
> ends up in latex must be in @clean trees, because my co-workers may end up
> editing these files too, so I need round-tripping.
>

​Again, that shouldn't be difficult.  Scripts could even convert @auto to
@clean and then do a write.
​

> For that, @clean seems to suit best, but I have difficulties to organize
> the @clean nodes in a fashion that reflects the document tree semantically.
> Latex files can be split by \input statements,
> but these may not be all on the same hierarchical level, but could even be
> nested, while @clean nodes cannot be nested as far as I know.
>

​Good to know.  I never use LaTeX myself, so I don't have any feel for the
problems.
​

> If nested @clean nodes ever become viable, great. In the meantime I stick
> to having the @clean nodes all on the same level and linking them to the
> nodes in the document tree, where they are \input.
>

​I don't see any enhancement request for nested @clean, perhaps I once
disparaged (rejected?) such a thing.  Right now it seems a reasonable thing
to want.  Please do file an enhancement request, giving a real-world LaTeX
example as motivation.​

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: jupyter files

[Offray Vladimir Luna Cárdenas]

Hi,

I think that exploratory computing (as Fernando Perez, co-lead dev of
Jupyter) would benefit largely from Leo capabilities and outlining, as
argued here, in this list, and on the web [1], because of the emergent
self-organizing nature of outlines and such kind of computation, and one
of the collateral benefits would be finer control over exportation to
other formats with the use of @directives (see for example %keywords in
the Grafoscopio Manual[2]).

[1]
http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html
[2]
http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/manual.pdf

Usually the collaboration between Leo and other languages has been by
being able to read/parse what these languages store (*ipynb, *html, *js,
etc) and convert them into a Leo tree to extend, reorganize such "plain"
files and export them back. I have advocated another kind of
collaboration, passing from files to services, by connecting Leo with
IPython kernel (via ZeroMQ) and make a Leo node equivalent to a IPython
cell. So a snipped of code in Leo can be computed and returned by/from
IPython to the Leo tree. Leo should have some kind of directive to
indicate that a node is an IPython output and that is associated with a
particular input node.

After trying with Python/Web related technologies to implement such
ideas of outlining and live coding/documentation [3], I opted for Pharo,
agile visualization and moldable tools, with better/quicker results for
me. So, I can not go into further code details on implementation and
just move in the conceptual space, because now I'm far away from Python,
but I still would like to see the implementation of Leo/Jupyter
collaboration also/mainly by services instead of "only" by files. I
think this would open important new paths and visibility for Leo.

[3]
http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html

Cheers,

Offray

On 26/08/17 08:30, Josef wrote:
>
>
> On Tuesday, 22 August 2017 20:48:56 UTC+2, Edward K. Ream wrote:
>
> On Tue, Aug 22, 2017 at 7:32 AM, Josef  > wrote:
>
> For me it is all about usability.
>
>
> ​Yes.  People like you who actually use Jupyter have insights that
> I don't have.  I welcome all your suggestions.
>
> ​> ​
> I want to be able to write code, clone bits and pieces here and
> there, disable some code.
> ​ ​
> This I do either by moving it out of the script tree or by
> commenting it out.
> ​ ​
> @ and @c work, but I am missing @ignore in @other trees, as it
> would make visually clear, which nodes are disabled.
>
> ​@ignore can never happen in @file and @auto trees because all
> information resides in the external file, so if gets ignored it is
> gone for good.
>
> @ignore could be valid in @nosent trees, because all data remains
> in the outline.  However, at present Leo rejects @ignore
> everywhere.  This seems like a mistake, but I don't think it will
> help you to fix it because you must use @auto.
>
>
> I was hoping to be able to read into an @clean node instead of using
> @auto or @nosent, as I need to cooperate with others, not using Leo.
>
>
> > Compatibility with .ipynb files would be nice, particularly in
> order to exchange files, and putting them on the web,
> but also to switch back and forth between Jupyter and Leo.
> I don't think Leo needs to implement all the nice pretty-printing
> stuff (@pyplot), plotting into a qt window is fine,
> although with longer scripts it may be good to be able to select
> which plots to execute, and which not (again @ignore?).
>
> ​What do you mean by compatibility? Are you suggesting that Leo
> could write some parts of outlines as .ipynb files?​
>
>
> yes. But note, I am only an occasional Jupyter user. Still some people
> I work with might be inclined to cooperate via a Jupyter file, while I
> am sceptical about them using Leo - sadly.
>
> Jupyter is not a high priority for me. Cooperation on latex files is.
> JupyterLab (the new and still unfinished version of Jupiter) seems to
> have some nice features, but I guess, I will still continue to work
> with Leo instead, because I need more control over the Latex output
> than Jupyter provides.
>
>
> ​> ​
> It would be good if the read .ipynb files can be run as a script
> within leo if they only contain python code,
> or using the ipython bridge when there is ipython code (a bit
> clumsy to have to start leo from the command
> ​ ​
> line in this case).
> Of course, the written back .ipynb files need to remain compatible
> with jupyter.
>
> ​Interesting idea. The present .ipynb importer is just that: only
> an importer.  Perhaps a post-pass could massage the imported nodes
> into a more useful form, squirreling away less useful data
> somewhere for eventual use by 

Re: jupyter files

[Josef]

On Tuesday, 22 August 2017 20:48:56 UTC+2, Edward K. Ream wrote:
>
> On Tue, Aug 22, 2017 at 7:32 AM, Josef  
> wrote:
>
>> For me it is all about usability. 
>>
>
> ​Yes.  People like you who actually use Jupyter have insights that I don't 
> have.  I welcome all your suggestions.
>
> ​> ​
> I want to be able to write code, clone bits and pieces here and there, 
> disable some code.
> ​ ​
> This I do either by moving it out of the script tree or by commenting it 
> out. 
> ​ ​
> @ and @c work, but I am missing @ignore in @other trees, as it would make 
> visually clear, which nodes are disabled.
>
> ​@ignore can never happen in @file and @auto trees because all information 
> resides in the external file, so if gets ignored it is gone for good.
>
> @ignore could be valid in @nosent trees, because all data remains in the 
> outline.  However, at present Leo rejects @ignore everywhere.  This seems 
> like a mistake, but I don't think it will help you to fix it because you 
> must use @auto.
>

I was hoping to be able to read into an @clean node instead of using @auto 
or @nosent, as I need to cooperate with others, not using Leo.

>
> > Compatibility with .ipynb files would be nice, particularly in order to 
> exchange files, and putting them on the web,
> but also to switch back and forth between Jupyter and Leo.
> I don't think Leo needs to implement all the nice pretty-printing stuff 
> (@pyplot), plotting into a qt window is fine,
> although with longer scripts it may be good to be able to select which 
> plots to execute, and which not (again @ignore?).
>
> ​What do you mean by compatibility? Are you suggesting that Leo could 
> write some parts of outlines as .ipynb files?​
>

yes. But note, I am only an occasional Jupyter user. Still some people I 
work with might be inclined to cooperate via a Jupyter file, while I am 
sceptical about them using Leo - sadly. 

Jupyter is not a high priority for me. Cooperation on latex files is. 
JupyterLab (the new and still unfinished version of Jupiter) seems to have 
some nice features, but I guess, I will still continue to work with Leo 
instead, because I need more control over the Latex output than Jupyter 
provides.

>
> ​> ​
> It would be good if the read .ipynb files can be run as a script within 
> leo if they only contain python code, 
> or using the ipython bridge when there is ipython code (a bit clumsy to 
> have to start leo from the command
> ​ ​
> line in this case).
> Of course, the written back .ipynb files need to remain compatible with 
> jupyter.
>
> ​Interesting idea. The present .ipynb importer is just that: only an 
> importer.  Perhaps a post-pass could massage the imported nodes into a more 
> useful form, squirreling away less useful data somewhere for eventual use 
> by the exporter. 
>

That's what I had in mind too. 

> ​
>
> ​> ​
> I also would like to see features, to export selectively certain sections 
> to Latex: 
> Jupyter can export to Latex too, but I found a 1:1 copy not useful for 
> inclusion into a paper.
> I need more control over the latex output, and by latex I mean not only 
> formulas.
> I would like to export some text and output of calculations (tables, 
> graphics) to latex snippets,
> which would then be \input to a latex document.
>
> ​As always,
>  the most general and flexible solution to such problems is a custom 
> script, which by definition can do anything.
>
>
> Having said that, it is simpler to define some kind of framework for 
> specifying desired parts of text.  This could be done using additional 
> markup.  Would this be useful? If so, I would glad to help you with such a 
> project.
>

In principle I like the idea of such a framework (may be more general than 
just for work with latex documents).

Thinking more about it, I don't think I want to just export, but whatever 
ends up in latex must be in @clean trees, because my co-workers may end up 
editing these files too, so I need round-tripping.
For that, @clean seems to suit best, but I have difficulties to organize 
the @clean nodes in a fashion that reflects the document tree semantically. 
Latex files can be split by \input statements,
but these may not be all on the same hierarchical level, but could even be 
nested, while @clean nodes cannot be nested as far as I know.
If nested @clean nodes ever become viable, great. In the meantime I stick 
to having the @clean nodes all on the same level and linking them to the 
nodes in the document tree, where they are \input.

- Josef

>
>

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.