Cleanup and modernize codebase

[metasoarous]

This is a start at cleaning up the codebase:

• Replace :use with :require (and dependent code accordingly)
• Replace tabs with spaces (messes with parinfer something fierce)
• Switch to deps.edn and clj/clojure toolchain

There are still some namespaces to clean up, but I've got it at least part way compiling with deps.edn now.

Biggest bit of review which would be appreciated here would be a look at how we add the jlink jar. The directions and lein setup here are very confusing, and we can't actually refer to env variables from within deps.edn files. So I'm thinking the best way forward here is to use pomegranate (or something) to add the jar dynamically to the classpath. You can see the new src/clojuratica/jlink.clj file for this. This seems to work (at least for importing things from jlink), and would mean users don't have to manually install the jar to their maven directory and mess around with updating the version numbers and such. They should be able to just point an env var to the correct place in the mathematica install and let the code take it from there. If this makes sense to everyone, we can just require this namespace to make sure it's loaded before everything else.

Please let me know what you think!

Thanks!

[qazwsxpawel]

Exciting stuff.

I've been tinkering with this a little bit today. Not sure if it's improving things much (my tinkering), you can check out the https://github.com/scicloj/Clojuratica/tree/further-cleanup branch it's built on top of this one.

• it works :)
• I think the jlink stuff is OK for now as is (w/ pomegranate)
  • I've added a bit more stuff around computing cross-platform paths etc. (but that will need to be tested and improved)
  • not a huge fan of side effects on ns loading, I moved all of that into a separate init namespace with a docstring explaining what's going on, so that it's maybe a bit clearer what's going?
• moved stuff out of user ns, there is a new dev and short explanation in the readme, keeping user light and happy, so you can always start the repl cleanly
• added basic clj-kondo support (empty config/.gitignore)
• I suggested a change from math macro to WL -- wolfram language, so we now have this example in the readme

  (WL (Dot [1 2 3] [4 5 6]))

Overall, I think it's good progress and we should generally be optimistically merging stuff into the main branch.

Feel free to merge this one and review changes I've made in the other one. After that is in we will have some working baseline for making things better.

Thanks!

[metasoarous]

Awesome; Thanks @qazwsxpawel!

Last night before heading to bed, I tried getting this stuff to work, but started running into the initialization process and threw in the towel. How wonderful to wake up and see that you've carried the torch through to having it working again!

I had to modify the jlink code slightly to get Linux paths working again, and also noticed that using JLINK_JAR was no longer working based on the updated flow. But actually, your changes and work on the kernel initialization process made me realize that really we should be operating explicitly against either MATHEMATICA_INSTALL_PATH or WOLFRAM_INSTALL_PATH, since if installed in a non default location, you'll need to explicitly set the base for both the JLink.jar and the MathKernel. I wasn't sure which name to add though, based on preference for Wolfram Language > Mathematica for generality (noticed your math -> WL switch, btw), so I updated so that you could use either. It's actually not perfectly clear to me whether all of these pathways will actually work for a Wolfram Language (sans Mathematica) installation, so that's something we should maybe check in with the Wolfram team about.

In any case, after all that, and a few minor updates to the dev namespace, I was able to get the examples there working!

Right now I'm spending a bit of time consolidating everything in the README and will try to push that shortly. But if this looks good to everyone, I'd say lets merge and we can tackle further improvement separately.

Thanks again!

[metasoarous]

PS I agree that I'm not wild about the side-effecting namespaces. I don't know if there's a way around it for the classpath hacking, since quite a few of the other namespaces will need to have the jar available before they can be eval'd. But for the init! step itself, maybe we actually just make that something you explicitly call as part of the API? I don't know that we have to decide immediately, but something to consider.

[qazwsxpawel]

Agreed with all the above. Looks good, feel free to merge.

After that I would probably would like to make the linters happy (clj-kondo)—just being pedantic. But that's a small thing and can be done after merge.

After that would be nice to:

• update Wolfram on the progress (like you said)
  • and get some test notebooks from them (so we can make a "stress test" out of them ;))
• have some very basic test(s), nothing fancy, just some "sanity checks" for ourselves for development
• have some investigation / roadmap
  • overview where we stand vis a vis what's changed in WL
  • there are two interesting points already mentioned in the README: visualisations and using WL associations instead of hand rolled HashMap which is what's happening atm
  • part of that process maybe verifying how much of the documentations still holds: esp.: http://clojuratica.weebly.com/intro.html and http://clojuratica.weebly.com/tutorial.html and

What do you think?

[metasoarous]

Cool cool; Merge complete! Thanks again for your work on this.

Agree regarding next steps. Let's create a set of issues to track the technical items, and start on an email thread to Wolfram folks.