> What you are doing I would consider unconventional
It wasn't before JavaFX was removed from the Oracle JRE. That is my point. JavaFX used to be a trivial dependency, but now it is quite painful in otherwise identical configurations, definitely not "low-impact."
> If you want to ship a cross platform jar
We do. Isn't that the point of Java, "write once run anywhere"?
This program is also used as a library in autograders. We do not want to distribute 5 versions of each autograder for 2-4 assignments. The autograder should be distributed as 1 jar. Undergrad TAs are creating that jar and may not have knowledge of complex CI pipelines etc.
> then it's probably worth your time to require a JDK with FX already installed.
That is not appropriate here. This is an educational tool, and students are enrolled in other courses that use Java frequently. We should be able to use the same JRE that students already have installed — it is unreasonable to require installing a different third-party JRE to run a digital logic simulator. It also adds another hurdle for freshmen/sophomores who may not have a natural ability for juggling different JRE installations. (Source: We tried requiring Azul and it was painful for everyone.)
> I do not have ARM versions of any of my code yet.
We have >900 students in this class, so it is necessary to support M1/M2; in fact, a large portion of our students had M1/M2 laptops. It sounds to me like you could just provide a fat jar in your case, actually. Supporting aarch64 is where we hit problems with our fat jar[1], since the aarch64 native libraries have the same name as the x86_64 libraries.
To summarize my point: yes you can make the build/install process more convoluted and avoid this problem. But we have an installation flow that has been battle-tested by thousands of students for 13 years (download circuit simulator .jar and run it) we have no good reason to abandon. The combination of the arrival of M1/M2 and JavaFX getting yanked from the JRE has made supporting our existing (extremely reasonable) flow nothing close to "low-impact."
> it's a "low impact" dependency in terms of side affects and complexity.
I wish that were true in my experience. But we have struggled to support {macOS, Windows, Linux} x {x86_64, arm64} with JavaFX and one .jar for our application.
> I'm familiar with Zotero and Calibre, though both are desktop only
There's a third-party Zotero client for Android named "Zoo for Zotero" that has worked well for me: https://play.google.com/store/apps/details?id=com.mickstarif.... However, I usually use it to read academic papers on my phone that I have already added to my library using my computer. I tried adding something new to my Zotero library on my phone as I was typing this comment, and sadly the interface seems a little clumsy: I can add papers to a collection but not a subcollection
> on a sidenote, why arent authors and researchers publishing on scihub directly?
Many compsci/physics/math researchers already submit preprints (or post-prints even) of their papers to arXiv, which is public: https://arxiv.org/. I'm confused, is there a reason why they should they submit to Sci-Hub too?
I'm excited to see that the RV32 AES instructions now have separate rs1 and rd fields, because the previous version combined them into just rt, which was kind of annoying from an implementation perspective, since you had some register that was both input and output (iirc, unlike any other RV32 instruction previously implemented on that hardware)
Hold on, who is "we"? Personally speaking, git works the way I think it does. Granted, I've written my own (simple) libgit2 frontend, so I understand the git internals fairly well, on a high level at least
I haven't looked into pijul, but why is teaching people a new tool more helpful than teaching people how the tool they already use works? (Like the OP blog post does.)
Am I blinded by the knowledge I gained from writing my little tool and learning about git internals? I get that a tool you need to learn the internals of to use is probably a bad tool, but is asking git users to understand the contents of the OP blog post really too much? Maybe I'm just a git fanboy...
I used to own a Chevy Prizm and packed it with all sorts of stuff – including carrying a huge whiteboard on the roof – so I agree that strategy works.
But what's nice about having a truck now is that I don't really have to try. I can just plop most things in the bed and go. You're right that it's not 100% necessary, but it's a great tool when you need it. That's one of the reasons they're so popular where I'm from (Georgia).
It wasn't before JavaFX was removed from the Oracle JRE. That is my point. JavaFX used to be a trivial dependency, but now it is quite painful in otherwise identical configurations, definitely not "low-impact."
> If you want to ship a cross platform jar
We do. Isn't that the point of Java, "write once run anywhere"?
This program is also used as a library in autograders. We do not want to distribute 5 versions of each autograder for 2-4 assignments. The autograder should be distributed as 1 jar. Undergrad TAs are creating that jar and may not have knowledge of complex CI pipelines etc.
> then it's probably worth your time to require a JDK with FX already installed.
That is not appropriate here. This is an educational tool, and students are enrolled in other courses that use Java frequently. We should be able to use the same JRE that students already have installed — it is unreasonable to require installing a different third-party JRE to run a digital logic simulator. It also adds another hurdle for freshmen/sophomores who may not have a natural ability for juggling different JRE installations. (Source: We tried requiring Azul and it was painful for everyone.)
> I do not have ARM versions of any of my code yet.
We have >900 students in this class, so it is necessary to support M1/M2; in fact, a large portion of our students had M1/M2 laptops. It sounds to me like you could just provide a fat jar in your case, actually. Supporting aarch64 is where we hit problems with our fat jar[1], since the aarch64 native libraries have the same name as the x86_64 libraries.
To summarize my point: yes you can make the build/install process more convoluted and avoid this problem. But we have an installation flow that has been battle-tested by thousands of students for 13 years (download circuit simulator .jar and run it) we have no good reason to abandon. The combination of the arrival of M1/M2 and JavaFX getting yanked from the JRE has made supporting our existing (extremely reasonable) flow nothing close to "low-impact."
1: https://github.com/ra4king/CircuitSim/pull/93/files#diff-648...