help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [was Promotion of octave ...] Octave material for presentations


From: Kai Torben Ohlhus
Subject: Re: [was Promotion of octave ...] Octave material for presentations
Date: Tue, 26 Nov 2019 19:48:22 +0900
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1

On 11/26/19 6:45 AM, Juan Pablo Carbajal wrote:
> 
> [...]
> 
> Feel free to add what you consider useful. The slides you link is the
> material I use every year at the CERN course, hence it is dynamic.
> 
> The slides for the presentation at HSR are here [1], inparticualr look
> at [2], all the material should be available on the root folders img/
> and includes/
> 
> [...]
> 

Thanks, I added your material.

> BTW, I remember you were working on a nb extension for publish, how is
> it going? Also, would you be able to weigh how much work would be to
> create a sphynx extension for Octave?
> 
> [1] https://gitlab.com/kakila/talks
> [2] https://gitlab.com/kakila/talks/tree/master/2018_GNUOctave_HSR
> 

The efforts of this work got stalled.  Without JSON support bug #53100
[1] this simply is too complicated parsing and writing ipynb-files
(JSON) on my own.  Unfortunately, as time goes by the number of possible
implementations increases and [1] got stuck in some analysis paralysis.

Since I worked on publish between 2016 and 2018, Jupyter(Lab) has really
become a great tool, which you can run offline on you local machine,
with Octave as back-end (as I did in my presentation on Friday).  Thus I
find there is hardly a need to further go down the road to "improve" the
Matlab-invented publish-syntax (I prefer Markdown).

The remaining projects after solving [1] I have in mind is:

(A) Import/open .ipynb files as Octave scripts.  All Markdown sections
are imported as comments and remain untouched.  Output cells are ignored.

(B) Exporting/saving by "publish" back to .ipynb files with output
cells.  Generating graphics as inline base64-encoded objects might be
tough, but not impossible.

What do you mean by "sphinx extension"?  You mean something like

   publish ("myscript.m", "sphinx")

resulting in some "myscript.rst" for further processing inside a sphinx
documentation project?  This would not be too hard, just implementing
[2] for "sphinx" or "rst".  Or being able to parse sphinx documentation
inside m-code, similar to [3]?

Best,
Kai

[1] https://savannah.gnu.org/bugs/?53100
[2]
https://hg.savannah.gnu.org/hgweb/octave/file/ae821ac9ec74/scripts/miscellaneous/private/__publish_latex_output__.m
[3] https://github.com/sphinx-contrib/matlabdomain



reply via email to

[Prev in Thread] Current Thread [Next in Thread]