-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
Comments
Hm, and I also can't add the 'enhancement' label for some reason 🤔 |
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.
Feel free to join on or making a donation to the project. |
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. |
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. |
Of course, help on this would be very welcome... |
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. |
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?
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.
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'll see what I could be able to do.
I think the most important, and probably the most complex, thing to implement is the Paclet system used by Wolfram. |
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. |
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:
|
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)
The text was updated successfully, but these errors were encountered: