Pushing xeus-octave forward

[SylvainCorlay]

Hey @rapgenic,

I am looking into putting some resources from my team at QuantStack to push this project forward - although I don't know if you are still planning on working on the project as it has not been active in a few months.

Would you be open to transfer it to the jupyter-xeus organisation (that is affiliated with the Jupyter project) so that we can continue the work on the project?

One objective that I would like to work on is to make a build in WASM to work with the JupyterLite fully in-browser distribution of JupyterLab.

Looking forward to hearing from you,

[rapgenic]

Hi @SylvainCorlay,

First of all I want to apologise for not answering earlier to your messages.

Secondly, I want to tell you that I am very glad of your interest in this project, even though I haven't been too responsive to your requests until now... That was mainly because I still had some plans about this project (my main idea was trying to upstream it to the octave project, given the recent modifications to the core which make the integration a little more difficult).

However it's clearer then ever that I do not have the resources to do this alone (or even to do it at all), and it would be a pity to abandon a project that took a few years of my life just because it's difficult for me to let it go...

It's obviously an amazing thing that an organization like yours is willing to put their time on xeus-octave and it's only good for the project, so please tell me what we need to do (i.e. if there's something i need to know to do the transfer) and let's go ahead with this!

Just a thing: I had done a whole lot of work (around 50 commits) in the temp/33/template branch (which should really be called development), where I adapted the project to your template, did a first implementation of the xwidgets and started porting for octave 7.

Let's keep in touch anyway, in the future I'd still like to contribute a bit of my free time to xeus-octave.

Good luck for the WASM porting, that will be amazing!

Thank you and all your team! Giulio

[SylvainCorlay]

Thanks for getting back to me. I am glad to see that you still mean to push this forward.

Just a thing: I had done a whole lot of work (around 50 commits) in the temp/33/template branch (which should really be called development), where I adapted the project to your template, did a first implementation of the xwidgets and started porting for octave 7.

Wow that's amazing. we should definitely look into that, and maybe discuss this in a call so that you can tell us about your ideas for the future of the project!

The idea of the WASM port is to enable the use of JupyterLite (notebook, console, or full lab UI) so that it is easy to embed on any website (this is how we can serve a Python console on the NumPy.org website, or in the Pandas documentation, without any backend). This would make it possible for any teacher (for example) to embed executable code snippets on their blog or course website. Even though we would not have all the toolboxes available, we could reach a much greater number of users... I am interested in demonstrating that this is possible with other languages than Python...

Depending on how we can go ahead, we could for example move it to the jupyter-xeus organisation while posting a short post on the Jupyter blog about the transfer and plans for the future - or wait to reach some kind of milestone before doing so while working here.

[rapgenic]

I suggest we do the transfer right now, to avoid stalling this and so that you can start working right now.

I really like the idea of the WASM port (also because I'd like to have a purely web based octave instance, i.e. without server) and I explored the idea when I integrated your template into the codebase, however I was quickly scared by the amount and variety of dependencies that must be compiled to WASM, hence the good luck...

As I previously said I do not have time right now to be actively involved with the project, although I can support on my spare time you if you have questions, so I think you should go ahead as you prefer: if you want to publish a post right now that's good for me, if you have a milestone in mind and you'd rather wait, that's good for me as well!

As for my future plans, I'd like to have the xwidgets implementation completed (a few widgets are missing) and battle tested, it might be nice to have some documentation as well... I'd also like to port the opengl backend to a stable GLFW 3.4 as soon as it is out, for better multi platform compatibility.

I'm also open to a call (maybe in a few days) if you need to discuss any detail about the project, but we probably should talk about that via email or some more private channel...

[AntoinePrv]

Hi @rapgenic , as I've mentionned, I'm working with Sylvain @QuantStack on this.

It's obviously an amazing thing that an organization like yours is willing to put their time on xeus-octave and it's only good for the project, so please tell me what we need to do (i.e. if there's something i need to know to do the transfer) and let's go ahead with this!

I suggest we do the transfer right now, to avoid stalling this and so that you can start working right now.

That's great, according to Github documentation you need be part of an organization to transfer a repository to it. Since I don't want to assume anything about jupyter-xeus, the easiest is perhaps that you transfer to @SylvainCorlay (for which he will receive an email), then he can transfer to jupyter-xeus. You can do so in the repository Settings > General > Transfer, the type SylvainCorlay. You should keep all permissions to the repository in the process. The email expires quite fast (24h) so can you ping me here so we make sure we do it in time.

As I previously said I do not have time right now to be actively involved with the project, although I can support on my spare time you if you have questions

Let's keep in touch anyway, in the future I'd still like to contribute a bit of my free time to xeus-octave.

Of course we'd like to keep you as a maintainer as much as you can offer. You know the code much better. Reviewing or commenting on PR would be very appreciated.

I'm also open to a call (maybe in a few days) if you need to discuss any detail about the project, but we probably should talk about that via email or some more private channel...

Can we contact you through your Github commit email?

had done a whole lot of work (around 50 commits) in the temp/33/template branch

I'd like to help with temp/33/template but the changes are a bit overwhelming. I'm trying to figure the different changes and pick/test/merge them one by one. If I understand correctly, in this branch there is:

• 1/ Moving to the cookie cutter
• 2/ Moving to the new Xeus release
• 3/ Moving to octave 7 (partial)?
• 4/ Some xwidget work
• 5/ OpenGL and GLFW / Glad

I'd like to get the first three in without waiting for xwidget and OpenGL, so that we can set up a clean CI testing and deployment pipeline. Is there any order in the commits so that I could get them independently (especially 2/ and 3/) ?

I'm also completely new to 5/. I'm not sure what is the difference between OpenGL / Mesa / GLFW / GLAD... Any detail is highly appreciated.

I really like the idea of the WASM port (also because I'd like to have a purely web based octave instance, i.e. without server) and I explored the idea when I integrated your template into the codebase, however I was quickly scared by the amount and variety of dependencies that must be compiled to WASM, hence the good luck...

Yes, there are quite a few dependencies! I think we should focus on them all before we do anything with xeus-octave.

If you want to publish a post right now that's good for me, if you have a milestone in mind and you'd rather wait, that's good for me as well!

@SylvainCorlay, I'd say we get 1/ 2/ 3/ in before the post, so that we have good foundations, then we can mention 4/ 5/ wasm and any other in the post.

[rapgenic]

@AntoinePrv @SylvainCorlay I'll do the transfer in a few minutes!

Can we contact you through your Github commit email?

Let's use this one so that I don't miss it.

I've had a look at the branch and I was mistaken about updating to octave 7, I did a few tests locally but did not commit anything.

Other than that your list is correct. Regarding the commit subdivision, as you can see they're a bit messy, however I think the code didn't change much from the master branch (other than the GL modifications and the widgets, which are however easily separated from the rest of the code).

OpenGL is a whole world on its own, and quite a complicated one, and I'm still not sure I've understood all of it. I'll try to explain what I know, but beware it might not be completely correct. Basically the rendering in octave happens via OpenGL, which is a graphic API exposed by the graphic card drivers (which means that each OS or even graphic card uses different libraries *.so or *.dll, and also means that a graphic card is needed). To be able to use this API, you must first have an OpenGL context, which is assigned by the display manager (e.g. Xorg or Wayland) or the OS (that's the case of Windows or MacOS) each one with different APIs.

To solve this mess we use:

• Glad as a library loader: it finds at runtime the correct OpenGL libraries and makes them available to the software
• GLFW as a multiplatform way to get a OpenGL context to draw to.

Osmesa is a special case, which provides a software OpenGL implementation in case we do not have a graphic card (e.g. Binder instance where otherwise the plots would not work, and they won't with the software in master).

Another detail is that I actually build GLFW 3.4 (which is still in development) in-tree, this is because previous versions did not allow to choose at runtime the backend in linux (that is Xorg, Wayland or Osmesa) but it was decided at build time by the GLFW package maintainer of each distro.

I believe it might be easier to support OpenGL in the WASM port, because the OpenGL calls should be translated to WebGL, but I'm not sure if GLFW/Glad might need to be excluded. I know for sure that Emscripten is able to emulate the SDL library so it might be possible to use that instead of GLFW but it's just speculation...

Regarding the xwidgets, the structure is quite complete, only a few widgets are missing, so don't consider it too experimental!

[rapgenic]

I cannot do the transfer as the destination repository already exists

[AntoinePrv]

Thank you for your detailed reply!

I cannot do the transfer as the destination repository already exists

It should be deleted now.

[rapgenic]

Still not working.... This is the error message

SylvainCorlay already has a repository in the rapgenic/xeus-octave network

[AntoinePrv]

We tried something else, could you try again?

[rapgenic]

Done!

[SylvainCorlay]

Closing this discussion item as closed as xeus-octave has now been moved to the jupyter-xeus organization. We will track the other specific subjects mentioned in this conversation in separate issues.