Happy new year! Great to see you back here. Caused by: java.lang.NoSuchFieldException: ns This error is usually caused by some lower level code which tries to print a namespace as a symbol, which you can nowadays just do using (symbol *ns*) instead of (.ns whatever)

Oh, I think this is because someone is trying to get the namespace from a var

Happy new year to you too!

ok, the “ns” exception message from sci was causing me to wonder if this was some sort of sci internal issue

could be, but I've seen this error message often enough by now :)

I guess Clojure doesn't have a nice way to get the namespace from a var without using Java interop

To make code SCI compatible I usually go through the metadata instead

I’m interning vars for *compile-path* and `*compiler-options*`, which could be part of the issue

Could sci indicate the location of the offending code?

In some cases it can... is it possible to make a clojure.test repro with this pretty bad internal stack trace leaking out?

I’m trying to update tools.bbuild to latest tolos.build, so I could PR that - would that be ok as a repro?

yeah

it’s on the update-to-tools-build-0.9.0 branch of tools.bbuild. You’ll need the PR version of tools-deps-native.

I’m running bb test from tools.bbuild

does it even build for you locally?

I mean, the PR is failing right?

oh, maybe I made a mistake cleaning up. let me check.

the linux PR is failing for a different unrelated reason I think it can be fixed by copying this file to the repo: https://github.com/babashka/babashka/blob/master/script/setup-musl

It looks like an http client is used somewhere on the top level maybe?

Perhaps upgrading graalvm helps btw

I’m using 22.3 - just pushed ci changes for the same

ok. perhaps the error is related to the s3 client, e.g. https://github.com/clojure/tools.deps.alpha/commit/f97452b478775796967baa17b2d5b9a5f660556e The changes over the past year, introduced quite some requiring-resolve which is terrible with graalvm native image

I think it's safest to update tools deps alpha to a version which is closer to the one before (or git/sha) so we can detect better where problems are coming from

I was using an older compile script locally - updating the correct one

the tools-deps-native pr is now failing with the stack trace I originally posted

I'll take a look

@U0HFRSY0M What bb version are you using?

This is what I'm seeing with the last bb from homebrew: https://gist.github.com/borkdude/978f4336daf5879c22b131f4ce7dc9fe

1.0.168

I'm trying to push a branch, but it fails on trying to clone: git fetch --force origin +refs/heads/hugoduncan-update-to-tools-deps-latest:refs/remotes/origin/hugoduncan-update-to-tools-deps-latest

https://app.circleci.com/pipelines/github/babashka/tools-deps-native/97/workflows/a534558b-ee61-440a-8ded-c2282132d220/jobs/225

https://app.circleci.com/pipelines/github/babashka/tools-deps-native/94/workflows/d7a4922c-3df9-4119-8e49-cde20cf3c05e/jobs/216

yes, I saw that

but right now I'm trying stuff and I can't get it to clone the repo

I'll try re-adding this project to circleci, something is weird

that helped...

what are you trying to achieve with the changes? just updating to latest xcode, etc?

I wanted to ensure that the latest bb is used there since I see an acceptable error message locally

and xcode was necessary to update since 12.0.0 isn't supported, it just didn't run anymore

what’s the local error?

https://clojurians.slack.com/archives/CLX41ASCS/p1672685686770089?thread_ts=1672672825.744419&cid=CLX41ASCS

am I doing something wrong?

that error comes from the test using the babashka branch, which is still on tools.deps.alpha, vs the PR which is using my branch of tools.bbuild, updated to use tools.deps

hmm, I thought I cloned your changed locally

maybe before I changed the test script

$ git pull [email protected]:hugoduncan/tools-deps-native-experiment.git update-to-tools-deps-latest
From 
 * branch            update-to-tools-deps-latest -> FETCH_HEAD
Already up to date.

https://github.com/babashka/tools-deps-native/pull/22/commits/97d5caf27dcb96160691ce32ff841a0a08ce80bd

oh...

is it sufficient to make that change on top of your latest commit?

that is my latest commit, no?

O wait, it already has this?

(do (shell "git clone ")
      (shell {:dir "tools.bbuild"} "git checkout update-to-tools-build-0.9.0"))

I have that locally

I guess you also have to update the first one

when the repo already exists

yeah that worked

@U0HFRSY0M Does this output make more sense to you? https://gist.github.com/borkdude/978f4336daf5879c22b131f4ce7dc9fe

(this is with a local change to babashka)

so it’s now throwing an exception with a message “clojure.core/vec” rather than “ns”?

what I did instead was print the SCI stacktrace instead of the internal stacktrace

this is the change I made: https://github.com/babashka/babashka/commit/fc2762bdd2cfe23ed2acbd8c5b784bede3b3c0a2

your last but one slack message (-6mins) is refusing to load here

that was a joke since I was waiting for your reply

ahh - I am still trying to understand the new trace. an exception message of “clojure.core/vec” doesn’t say much to me, and the line numbers in the stack trace don’t seem to point to the actual problem.

hmm ok

we can also run this code with JVM Clojure right?

to check what JVM clojure.test does

this requires you to use the jvm pods library

that particular test, probably - i’ll give it a go

will have to be later though…

sure, no problem

thanks for the help so far : )

np!

summary of current state: the error seems to be caused by the attempt to intern *compile-path* and *compiler-options*. Also the tools.build tests user reader-conditional which is unavailable in bb. any workarounds for either of the above?

The intern hacks are I think what you needed, but the ns needs to be a real namespace object, not a symbol. I fixed this in the branch

And I also added reader-conditional to SCI + bb master. I used --dev-build to install the babashka dev build in CI

In the hugoduncan-update-to-tools-deps-latest branch that I pushed

For testing locally, you can install the bb from master using:

bash <(curl -s ) --dir $(pwd) --dev-build
            

Now we're getting somewhere I think: https://app.circleci.com/pipelines/github/babashka/tools-deps-native/102/workflows/6798a7c9-700e-4e13-815f-59596ce4525f/jobs/237

I'm getting:

Ran 33 tests containing 95 assertions.
0 failures, 5 errors.

So one thing is:

Unable to resolve classname: org.eclipse.aether.artifact.DefaultArtifact

in test-install-no-pom

Then there still is: Caused by: java.lang.NoSuchFieldException: ns

I pushed a more-or-less fix to update-to-tools-build-0.9.0 for the compile script. The vars were printed wrong and the .ns field was used to obtain the namespace name which you can't do in SCI right now

So now we're just left with:

FAIL in (test-compile) (/Users/borkdude/dev/tools.bbuild/src/test/clojure/clojure/tools/build/tasks/test_compile_clj.clj:17)
expected: (true? (.exists (jio/file (project-path "target/classes/foo/bar.class"))))
  actual: (not (true? false))

Ahj, I found another issue. pprint-ing a var in SCI doesn't work properly $ bb -e "(clojure.pprint/pprint #'inc)" #<Var@3d01336f: #object[clojure.core$inc 0x69addece "clojure.core$inc@69addece"]>

That fixes the weird errors too:

0 failures, 1 errors.

Ran 30 tests containing 96 assertions.
0 failures, 0 errors.

Tests work now: https://app.circleci.com/pipelines/github/babashka/tools-deps-native/105/workflows/2a432a3c-091b-4947-93c3-3d8b5a9b3dce/jobs/243

Tests also pass on Windows!

https://ci.appveyor.com/project/borkdude/tools-deps-native/builds/45825819

it looks like I woke up at just the right time

I'll make a release of tools-deps-native binary so we can also merge the bbuild one

then we only have to release a new version of bb...

perhaps the compile-path thing can be fixed nicer in bb itself before I release it

anyway, the pod should be in good shape now

I was wondering why reflect-config-cleaned.json is checked in?

maybe to have things more reproducible?

I don’t see it ever being used as an input in its construction

did you force push this branch maybe...? https://github.com/babashka/tools.bbuild/tree/update-to-tools-build-0.9.0

I think it made the build fail on tools-deps-native ;-)

woops, looks like I pushed instead of pulling. Hopefully you still have the branch locally

I do, shall I force push mine?

please do

done, I'll re-run the build

I should have probably used a different branch, sorry ;)

i’m just grateful for all the fixes 🙂

do you have any plans using tools.bbuild for real things?

I want to use it with my makejack project. I also thought that a bb script to invoke a project’s (tools.build based) build scripts would be useful.

Progress is very intermittent though…

no problem, just understanding the rationale better :-)

Basically trying to make it easy to run tools.build based tooling with babashka. Something of a complement to the babashka first approach provided by babashka tasks.

ok, released tools-deps-native v0.1.0 here https://github.com/babashka/tools-deps-native

I'll take a look at: • gettting compile-path, etc into bb ✅ • cleaning up and merging the tools.bbuild branch later this week

sounds good - thank you for the time you have put into this

done