Re: jupyter files

[Edward K. Ream]

On Tue, Aug 29, 2017 at 6:04 AM, Josef  wrote:

>
>
> On Saturday, 26 August 2017 19:40:47 UTC+2, Edward K. Ream wrote:
>>
>> 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.​
>>
>
> Doh! Of course that is the simplest solution and works fine for the latex
> files.
>


> It won't work out of the box for jupyter files, since these contain all
> kind of stuff which should not go into the normal python node bodies,
> but still need to be written back if we want to round-trip jupyter files.
> If that other stuff is moved out of the way to be able to run jupyter
> files as scripts in Leo, then we will have to undo this moving out of the
> way when writing jupyter files back.
>

​I don't remember what the "other stuff" is, but perhaps it could be moved
into uA's.

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

[Josef]

On Saturday, 26 August 2017 19:40:47 UTC+2, Edward K. Ream wrote:
>
> 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.​
>

Doh! Of course that is the simplest solution and works fine for the latex 
files.
It won't work out of the box for jupyter files, since these contain all 
kind of stuff which should not go into the normal python node bodies,
but still need to be written back if we want to round-trip jupyter files.
If that other stuff is moved out of the way to be able to run jupyter files 
as scripts in Leo, then we will have to undo this moving out of the way 
when writing jupyter files back.
 

​
>
>> 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.
>

The enhancement request already exists, and you filed it yourself a while 
ago, although under a different title:
>> I've just created #525: Ignore @clean in descendants of @others nodes 


I will add a latex example soon, but want to write it to be useful in a 
test case, so it covers all relevant aspects. 
This may still take a bit of thinking.

- 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.

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.

Re: jupyter files

[Edward K. Ream]

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.

> 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?​

​> ​
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.
​

​> ​
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.
​

​> ​
There are two different scenarios:
when one wants to document a calculation in detail, one wants to export
almost everything to the output format.
This is what Jupyter does, with the option to suppress the input.
The other (for me more interesting) case is writing a (scientific)
document.
In that case one does not need or want an exact copy of everything, but
mostly the results, mixed with some text.

​So I take it you would like some markup to delimit the text to be output.​

​> ​
At this time Leo has commands to separate code from comments
(I haven't tried yet to output the comments to a document = tangle?),
but I think this will not be enough.
Jupyter has several node types, which need to be reflected,
and in addition we would need some way to separate between wanted output
and local calculations/comments.
In other words, @ and @c are not enough.

​Reasonable.​

​> ​
For the moment, my workflow is this:
A document tree with @clean nodes containing latex.
A separate tree with scripts for each calculation,
using some external scripts or pandas to convert output to latex longtable
or tabular table snippets
and pandas or matplotlib for plots, converting to pdf (best format for
input to pdflatex).

​Ok, it seems like we are thinking along similar lines.

​

​> ​
The connection between the document tree and the calculations is done by
links.
I would prefer a closer integration, e.g. keep the calculations (clones?)
in the document tree,
however I don't see a simple way to do that - especially not when keeping
compatibility with Jupyter.
​


Let me think about this.  It's an interesting problem.


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

[Josef]

For me it is all about usability. 
I found working with Leo I can relatively easy move around bits and pieces 
of code and experiment with different schenarios, and still keep the 
overview if the code gets large.
This is a clear advantage over Jupyter, where the code is rather 
monolithic, or Qtconsole, where its interactive, but not really good for 
literate programming.

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.

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?).

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 commandline in this case).
Of course, the written back .ipynb files need to remain compatible with 
jupyter.

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.

There are two different schenarios: 
when one wants to document a calculation in detail, one wants to export 
almost everything to the output format.
This is what Jupyter does, with the option to suppress the input.
The other (for me more interesting) case is writing a (scientific) 
document. 
In that case one does not need or want an exact copy of everything, but 
mostly the results, mixed with some text.

At this time Leo has commands to separate code from comments 
(I haven't tried yet to output the comments to a document = tangle?),
but I think this will not be enough. 
Jupyter has several node types, which need to be reflected, 
and in addition we would need some way to separate between wanted output 
and local calculations/comments.
In other words, @ and @c are not enough.

For the moment, my workflow is this:
A document tree with @clean nodes containing latex.
A separate tree with scripts for each calculation,
using some external scripts or pandas to convert output to latex longtable 
or tabular table snippets
and pandas or matplotlib for plots, converting to pdf (best format for 
input to pdflatex).

The connection between the document tree and the calculations is done by 
links.
I would prefer a closer integration, e.g. keep the calculations (clones?) 
in the document tree,
however I don't see a simple way to do that - especially not when keeping 
compatibility with Jupyter.

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.

Re: jupyter files

[Edward K. Ream]

On Mon, Aug 21, 2017 at 7:17 AM, Josef  wrote:

> Leo's @auto reads in .ipynb files, and there are now @pyplot commands, but
> I am lost at how to use these.
>

​At present these are two separate features.  #477
 hints at improving
support for Jupyter notebook files, but all is sketchy.  This issue is
marked "first" because cooperation with other programs supposedly has high
priority.
​

> How am I supposed to use the @jupyter node? Only to edit it, then run it
> in Jupyter notebook, or can I also run the script(s) in Leo?
>

​That's a good question.  I'm not sure myself.  Please feel free to make
suggestions here, or in #477.

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.