You mean AOT ?

No? Just starting my project in development.

Tests are slow, starting the REPL is slow...

Hum, I think for Clojure you just need to make sure your JDK is for M1

How do I do that? 🙂 I haven't really understood the JDK-side of things.

Hum, I guess how did you install the JDK ?

Actually,.run the command: java --version

And see if it says x86 or Mac-O Arm64

Sorry, it's been quite a while since I set up JDK and that part of Clojure is basically trial-and-error for me.

java --version
Unrecognized option: --version
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

it's supposed to be java -version (just one dash)

Thanks!

> java -version
openjdk version "1.8.0_292"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_292-b10)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.292-b10, mixed mode)

Hum, ok that's not very clear if it's Intel or arm haha

maybe try

file `which java

although, I would probably recommend updating to a newer version of java regardless

I also see you have Java 8 though, and I think Java 17 is the first one officially supporting M1

Do you use brew? Most people setup JDK and Clojure use brew on Mac normally.

You can also install sdk-man, it allows you to choose (and switch!) your JDK and will pick the correct one for your architecture

Also, do you know that it should be faster because you've also used it on an Intel Mac or a PC before? Otherwise, Clojure does have relatively slow startup time, between 200ms to 5 seconds depending how much you do at initialization and how many dependencies you use. And if you're doing something intense in a def it will slow thing down as well, like if you're starting a server for example.

@U0ETXRFEW's startup of the same project is about 10x faster...

Time for breakfast, I'll check out sdk-man!

And maybe it's time to upgrade to Java 17...

Ah, ya probably Java 17 and making sure you've got the arm one will fix things.

sdk-man rocks. And to my experience, making sure only arm binaries are used all over is key. And Java 19 is fine.

You can check that you are running an ARM based JVM with

(System/getProperty "os.arch")

I usually use fish as my terminal. I had to switch to bash to install sdk-man and installed Java 17. Which succeeded. But fish is still running Java 8... Sorry about this, everything about terminals and java versions i very confusing to me.

And if I enter bash from fish, it's back to Java 8.

And sdk-man is no longer there.

I can help you in a huddle, @UGDTSFM4M. You know where to start it. 😃

Never made the switch to fish, but I'm sure we'll figure it out.

😄 I should really be giving my kid breakfast... Are you available in 10-20?

I am.

omg, we were using intel java on our m1 macs 💥

It’s really a common mistake, I did that for 9 months, too. The build of the Java Software I was working on was 30% faster afterwards 🙈

thank you for asking this question @UGDTSFM4M 😄 we just realised our Java version was not for M1, and we just switched. its like getting a new laptop all over again

its like we all just got M3s

So awesome! It will prolong battery run rime a lot as well. And lower the energy consumption even if plugged in.

BTW we're using asdf as a version manager for the whole team, and we've finally solved the problem of "which version of java/clojure/python/js/aws-cli/... you got installed?"

Oh, wow, really glad my question alerted others on this!

And thanks @U0ETXRFEW for clearing up my shell confusion.

Wrangling PATHs trips up everyone

I wasn't able to get sdk-man to work on fish so I changed my default shell i VS code to zsh

ChatGPT claims that adding this to your fish config should do the trick:

set -gx SDKMAN_DIR $HOME/.sdkman
source $SDKMAN_DIR/bin/sdkman-init.sh

Download https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.1 for darwin aarch64 and

export GRAALVM_HOME=~/Downloads/graalvm-ce-java17-22.3.1/Contents/Home
export JAVA_HOME=$GRAALVM_HOME
export PATH=$JAVA_HOME/bin:$PATH

The arm version of Java I have was JDK17 as there wasn’t a stable Java8 available.

@U0ETXRFEW, nah, didn't work. I think that sdkman-init.sh doesn't play well with fish.

That's what I thought. ChatGPT has learnt from humans, obviously.

And those humans didn’t get it to work either 🙂

tip: open activity monitor and add column “type” by right clicking the column header, there you can verify which arch you are using

java 8 apple silicon are available from azul (https://www.azul.com/downloads/?version=java-8-lts&package=jdk), openjdk silicon builds from 11 (https://formulae.brew.sh/formula/openjdk@11)

GraalVM is also an option, very easy to download and use (mentioned earlier in this thread). Just a tar.gz + set some env variables. I switch versions all the time by just setting those env vars

If you have the Arm64 version of homebrew, brew install openjdk also installs the Arm64 jdk

I don't know the answer to this, but another valid question is: "are there any decent libraries for simple NLP text classification in Java"?

Was going to say ☝️ - we used to use CoreNLP, but we had issue with the license (GPL), there are other Java libraries around and usually are very easy to use directly

In case you're okay with replacing "in Clojure" with "from Clojure", then you can use spaCy via libpython-clj

I think #C0BQDEJ8M may have more answers?

https://github.com/simongray/datalinguist this is a good wrapper for CoreNLP that makes it very compatible with datalog-flavored DBs. YMMV with CoreNLP; the GPL license may restrict you from certain types of applications.

As suggested above, spaCy (via libpython-clj) is pretty good. but if you're working with the integer representation of tokens you should beware that it uses ints to represent lexemes. Python 3 and on use BigNums for ints, so they do not have a fixed size in bits. Which means you can encounter an overflow when converting; SpaCy's int-based representations are frequently larger numbers than can be expressed in a 64-bit unsigned int (which is the conversion pathway for Python int types). I got burned by this when I was doing some NLP work not too long ago. Carin Meier wrote a good guide for getting started with spaCy from Clojure: http://gigasquidsoftware.com/blog/2021/03/15/breakfast-with-zero-shot-nlp/

Thank you all! I will look into using spaCy

it is trivial, but mostly pointless

No clue whether there are any repercussions:

Clojure 1.11.1
user=> (defmacro m [x] (println x))
#'user/m
user=> (alter-meta! #'m assoc :macro false)
{:arglists ([x]), :line 1, :column 1, :file "NO_SOURCE_PATH", :name m, :ns #object[clojure.lang.Namespace 0x6fe46b62 "user"], :macro false}
user=> m
#object[user$m 0x3b152928 "user$m@3b152928"]
user=> (m nil nil 1)
1
nil

macro expansion happens at compile time, what are you going to do with a macro at runtime

user=> and
Syntax error compiling at (REPL:0:0).
Can't take value of a macro: #'clojure.core/and
user=> #'and
#'clojure.core/and
user=> @#'and
#object[clojure.core$and 0x18e8473e "clojure.core$and@18e8473e"]
user=> (type @#'and)
clojure.core$and
user=> (fn? @#'and)
true
user=>

thanks

yeah I get that it's a very specific thing to do and normally the wrong thing

Huh, TIL plain deref circumvents that error.

maybe deref works because the underlying fn value doesn't have the metadata? I've seen clojure code somewhere in a tooling library that recursively calls (= form (macroexpand-1 form)) to check for macros but could one just check the metadata? except in clojurescript you won't have the var to find the metadata so just have to call it?

clojurescript is a whole other kettle of fish

when you formally describe macros, you sort of end up with a tower of meta languages, where the macros for clojure are written in "meta clojure" and the macros for "meta clojure" are written in "meta meta clojure" etc. lisps sort of by pass the tower by saying the meta langauge is the same as the language

but for clojurescript the meta langauge is clojure, not clojurescript (unless you are using self hosted clojurescript)

part of the reason I asked "what are you going to do with macros at runtime" is calling a macro outside of the context of the compiler expanding out all macros and then compiling code is generally pointless

the function of the macro expects to be passed forms (not runtime values, but because of the meta language = language it can be hard to distinguish the two) and returns forms, which may contain more macros, and for those forms to have a runtime value they need to be compiled and executed

SCI needs the function form of a macro with two extra initial arguments

The solution of course is to write that function first then call it from a defmacro, but just wanted to note that if you have a bunch of existing macros or macros from another library, that would be a use case for wanting to recover the function

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296463 is the "fixed in 19.0.2" bug

https://bugs.openjdk.org/browse/JDK-8297168 is the not-yet-backported bug

We downgraded to JDK 18 and the process runs fine. On 19.0.2, that same process slowly climbs to 100% heap and then OoM. We have not yet tried it without --enable-preview but might do that next week as a test.

that looks like 1 jar, not a "ton"

that looks like a timestamped version under a SNAPSHOT. did you change something to stop looking for snapshots maybe?

oh actually it was seven

Failed to read artifact descriptor for org.hipparchus:hipparchus-core:jar:2.0-20210614.200156-32
Failed to read artifact descriptor for org.hipparchus:hipparchus-clustering:jar:2.0-20210614.200233-32
Failed to read artifact descriptor for org.hipparchus:hipparchus-fft:jar:2.0-20210614.200242-32
Failed to read artifact descriptor for org.hipparchus:hipparchus-fitting:jar:2.0-20210614.200229-32
Failed to read artifact descriptor for org.hipparchus:hipparchus-ode:jar:2.0-20210614.200217-32
Failed to read artifact descriptor for org.hipparchus:hipparchus-optim:jar:2.0-20210614.200223-32
Failed to read artifact descriptor for org.hipparchus:hipparchus-stat:jar:2.0-20210614.200203-32

It doesn't say that it checked maven central (not sure if it usually prints that out) which is where it seems to be hosted, https://mvnrepository.com/artifact/org.hipparchus/hipparchus-core

I posted a question here on the package owner’s forum: https://forum.orekit.org/t/snapshot-version-unpublished/2273

usually it prints the last place it looked, which may have nothing to do with where it is

right, to my knowledge, the :repositories key in our project.clj hasn’t changed

you might want to look at the metadata in your local repo

~/.m2/repository/org/hipparchus/hipparchus

resolver-status.properties, maven-metadata-central.xml, maven-metadata-local.xml

@U7RJTCH6J no snapshots there that i can find

x.y-SNAPSHOT is a virtual version that is resolved to the newest timestamped version based on what it can see in public repos, that info is cached here based on your update frequency (usually 1 day)

I’ll have a team member look for that file, I cleared it from my own system when trying to reproduce the problem

since maven repos are generally append only, it would be unusual for a specific timestamped version to disappear. but changing your env such that you stopped looking at whatever repo held the newest version seems more likely

okay, I’ll check git blame then

no changes I can find, strange. not sure what happened. maybe the forum question will turn up something

it's more likely you than them :)

do you think they would have a record of if this version was ever published?

no idea

Do you have an old uberjar lying around? You should be able to figure out if a version went "missing" or if a version changed to an unreachable artifact due to using something like a "-RELEASE" version. You might also be able to find a computer that ran the software and check their local maven cache.

You could also try to find out why the missing artifact is transitively included to to try and figure out if you can just explicitly include a stable release version.

Did you anger the developer? https://www.theregister.com/2016/03/23/npm_left_pad_chaos/

in file ~/.m2/repository/org/hipparchus/hipparchus-core/2.0-SNAPSHOT/maven-metadata-orekit.xml:

#NOTE: This is a Maven Resolver internal implementation file, its format can be changed without prior notice.
#Fri Feb 03 14:43:19 EST 2023
maven-metadata-clojars.xml.error=
maven-metadata-clojars.xml.lastUpdated=1675453399308
maven-metadata-github-ssh.xml.error=Could not transfer metadata org.hipparchus\:hipparchus-core\:2.0-SNAPSHOT/maven-metadata.xml from/to github-ssh (git\://github.com)\: Cannot access git\://github.com with type default using the available connector factories\: BasicRepositoryConnectorFactory
maven-metadata-github-ssh.xml/@default-github-ssh-git\://github.com/.lastUpdated=1675453399076
maven-metadata-orekit.xml.lastUpdated=1675447330819
maven-metadata-sonatype-snapshots.xml.error=
maven-metadata-sonatype-snapshots.xml.lastUpdated=1675453399339
maven-metadata-sonatype.xml.error=
maven-metadata-sonatype.xml.lastUpdated=1675453399189

#NOTE: This is a Maven Resolver internal implementation file, its format can be changed without prior notice.
#Fri Feb 03 14:43:19 EST 2023
maven-metadata-clojars.xml.error=
maven-metadata-clojars.xml.lastUpdated=1675453399308
maven-metadata-github-ssh.xml.error=Could not transfer metadata org.hipparchus\:hipparchus-core\:2.0-SNAPSHOT/maven-metadata.xml from/to github-ssh (git\://github.com)\: Cannot access git\://github.com with type default using the available connector factories\: BasicRepositoryConnectorFactory
maven-metadata-github-ssh.xml/@default-github-ssh-git\://github.com/.lastUpdated=1675453399076
maven-metadata-orekit.xml.lastUpdated=1675447330819
maven-metadata-sonatype-snapshots.xml.error=
maven-metadata-sonatype-snapshots.xml.lastUpdated=1675453399339
maven-metadata-sonatype.xml.error=
maven-metadata-sonatype.xml.lastUpdated=1675453399189

#NOTE: This is a Maven Resolver internal implementation file, its format can be changed without prior notice.
#Wed Jan 11 20:09:07 EST 2023
hipparchus-core-2.0-20210603.152039-26.pom>orekit=
hipparchus-core-2.0-20210614.200156-32.jar>orekit=
hipparchus-core-2.0-20210614.200156-32.pom>orekit=
hipparchus-core-2.0-20210615.122822-33.pom>orekit=
hipparchus-core-2.0-20210619.064621-36.pom>orekit=
hipparchus-core-2.0-20210628.192448-39.pom>orekit=
hipparchus-core-2.0-20210704.190153-45.pom>orekit=
hipparchus-core-2.0-20210730.210246-58.pom>orekit=

These are all the metadata files from a colleague’s local cache from when it used to be available

maybe trying to use a git dep as a maven dep?

I don’t know what that means

that maven-metadata-github-ssh.xml.error line seems weird, but maybe it's not a big deal

is there a way to check what library is even trying to use it. lein deps :tree just returns the same errors about not being able to find them

maven-metadata-sonatype-snapshots.xml.lastUpdated

same deal happened with lein pom; mvn dependency:tree -Dverbose=true

you could try generating a pom and using mvn -X -e - sometimes the error messages are more illuminating

I’ll try these suggestions. Thanks guys, have to step out. I’ll report back if I find anything

Welp, they said snapshot versions are temporary: > Hi, > The snapshot versions are just temporary, they are not expected to remain on the long term. > Indeed, even the released 2.0 version is already old. > For production purposes, you should try to stick to released versions that will remain on maven central indefinitely. > The latest published version of Hipparchus is 2.3. See for example https://central.sonatype.com/artifact/org.hipparchus/hipparchus-core/2.3 for the core module (all modules are released simultaneously).