Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jupyter Notebook support #200

Open
bigoh1 opened this issue Jan 25, 2024 · 11 comments
Open

Jupyter Notebook support #200

bigoh1 opened this issue Jan 25, 2024 · 11 comments
Labels
enhancement New feature or request

Comments

@bigoh1
Copy link

bigoh1 commented Jan 25, 2024

Hi everyone :)

First, let me thank all of you guys. I have a huge respect for your dedication and unpaid hard work.

I've been exploring Mathics on and off as a substitute to Wolfram Mathematica, because I don't really want to depend on a closed-source (even though, for my purposes at least, free to use) project ):

So my question is:
• are there any plans to make a jupyter-kernel for Mathics?
• If yes (or if it exists) could you please point out where I can find that? (+ possible ways to contribute)

@bigoh1
Copy link
Author

bigoh1 commented Jan 25, 2024

Hm, and I also can't add the 'enhancement' label for some reason 🤔

@rocky rocky added the enhancement New feature or request label Jan 25, 2024
@rocky
Copy link
Member

rocky commented Jan 25, 2024

Jupyter integration is briefly mentioned in the 2023 Roadmap. Basically, Boxing needs to be revised before we can contemplate doing this in a responsible fashion. I have made sure to include it in the discussion going into the 2024 Roadmap.

First, let me thank all of you guys. I have a huge respect for your dedication and unpaid hard work.

Feel free to join on or making a donation to the project.

@mmatera
Copy link
Contributor

mmatera commented Jan 25, 2024

In https://github.com/mmatera/iwolfram I have a project that (used to) work with both WMA and Mathics (as well as other implementations). Maybe it would be a good moment to check if it is still work with the last version of jupyter.

@adamantinum
Copy link

It seems to work, plots apart, with Mathics.
immagine

With Wolfram plots work, but lines cannot be edited, you must add new lines using the lower box.
immagine

In both cases, jupyter returns some weird traceback in the terminal:

[MetaKernelApp] ERROR | Exception in control handler:
Traceback (most recent call last):
  File "/home/alessandro/.local/lib/python3.11/site-packages/ipykernel/kernelbase.py", line 362, in process_control
    await result
  File "/home/alessandro/.local/lib/python3.11/site-packages/ipykernel/kernelbase.py", line 1036, in debug_request
    reply_content = await reply_content
                    ^^^^^^^^^^^^^^^^^^^
  File "/home/alessandro/.local/lib/python3.11/site-packages/ipykernel/kernelbase.py", line 1091, in do_debug_request
    raise NotImplementedError
NotImplementedError

@mmatera
Copy link
Contributor

mmatera commented Feb 8, 2024

Indeed, this package requires some maintenance, because come changes both in the packages in which this is based (Metakernel and Jupyter), as well as in WMA. If there is interest on this, I could look to review this and start to fix these issues.

@mmatera
Copy link
Contributor

mmatera commented Feb 8, 2024

Of course, help on this would be very welcome...

@adamantinum
Copy link

I think it could be useful to see if there is enough interest in the project. Django seems fine, it allows to rotate 3D plots, while jupyter does not. It would just need some additions such as autocompletion.
If something more specific is wanted, there exists https://github.com/JerryI/wolfram-js-frontend that could be used, but I think Mathics hasn't still implemented all the builtins needed to make it work.

@rocky
Copy link
Member

rocky commented Feb 8, 2024

From the look of it, wolfram-js-frontend is pretty cool!

The Mathics3 equivalent to wolframscript mentioned in wolfram-js is called mathicsscript.

In reality, iwolfram is going to need a lot of work to get it working, more akin to a rewrite. And at that point we should assess whether it is worth the effort or hook into wolfram-js.

Of course those who do the work have the final say as to whether they want to do the work to revise or rewrite iwolfram. I am just suggesting that those who are interested in doing this work might consider instead to contributing to getting wolfram-js instead. Maybe there are things from iwolfram that can be incorporated into that?

[Mathics-Django] would just need some additions such as autocompletion.

While in the long term Mathics Django will probably be deprecated in favor of Jupyter or something like wolfram-js, in reality Mathics Django will be around for a long time. We have a large backlog of stuff that is going to take while to get through. See 2024 Roadmap

If you are interested in adding autocompletion to Mathics-Django, mathicsscript has some completion code one might be able to adapt.

I think Mathics hasn't still implemented all the builtins needed to make it work.

This is definitely true. If there is a way to get closer or come up with a plan to implement builtins to ease wolfram-js-frontend incrementally, that would be awesome.

@adamantinum
Copy link

adamantinum commented Feb 8, 2024

I'll see what I could be able to do.

This is definitely true. If there is a way to get closer or come up with a plan to implement builtins to ease wolfram-js-frontend incrementally, that would be awesome.

I think the most important, and probably the most complex, thing to implement is the Paclet system used by Wolfram.

@mmatera
Copy link
Contributor

mmatera commented Feb 8, 2024

I have to say, the goal of IWolfram was not to be a specific front-end for Mathics, but a Jupyter kernel for anything that provides a command line interpreter for WL.

Also, some time ago I started to write the support for Mathics-threejs 3D graphics, but I guess it is outdated now.

On the other hand, something that I tried to avoid there was using things like MathLink or the Wolfram Paclet system, which goes beyond the language standard and depends more on its implementation.

@rocky
Copy link
Member

rocky commented Feb 9, 2024

I think the most important, and probably the most complex, thing to implement is the Paclet system used by Wolfram.

When I looked at wolfram-js-frontend I saw that it registered itself as a Paclet, but not that relies on this kind of packaging.

In general, isn't it true that there are parts of Paclet or some kinds of Paclets that are highly WMA implementation-specific while there can be others that are not specific to a particular WMA implementation (and therefore could be run in Mathics3)?

And can't a lot of Paclet be written in WMA or Mathics3?

I suspect and believe that is also true for some of the other (older?) WMA packaging mechanisms as well as its testing system. If that is so, it would be awesome if we had code that mimics the behavior of those. And if along the way we need to fix some bugs, we should do that.

In general, it is true that in Mathics3 we have had an extensibility and interoperability problem for a while that while we are getting better at is still in need of work.

Part of the problem here is that I am not really a WMA programmer and don't know the language or the ecosystem all that well.

In Mathics3/mathics-core#961 under "Miscellaneous Small Things" we have:

Be on the lookout for Open-Source WMA Packages like KnotTheory or Rubi that can be run in Mathics3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants