Fork me on GitHub
Matthew Davidson (kingmob)03:12:42

@p-himik Sorry you had to go through that. We can't really remove the duplicate namespaces, but we can make one import the vars from the other, which should prevent this issue in the future. Fundamentally, single-segment namespaces are problematic, and are discouraged for good reason these days. We know they interfere with Graal, and there's certainly more lurking time bombs, because they violate the widespread assumption that a class will be in a package.

🙏 1
Matthew Davidson (kingmob)10:12:29

Eugene, let us know if that fixes your issue, and if so I'll announce the release more widely


Fantastic! That seems to be working just fine. Thank you for such a prompt fix.

Matthew Davidson (kingmob)08:12:54

I've also got an updated Aleph 0.6.1 with updated deps, but I think it's going to wait until the new year, since nobody's around... 🎄

🎉 1

Thanks for the fix, just went through the same pain 😬 @kingmob Happy to help shepherding through a 0.6.1 release!


Argh, spoke too soon


Looks like I actually have a different problem, it seemed similar


Execution error (ClassCastException) at clj_commons.byte_streams.graph.ConversionGraph/assoc_conversion (graph.clj:117).
class clj_commons.byte_streams.graph.Type cannot be cast to class clj_commons.byte_streams.graph.Type (clj_commons.byte_streams.graph.Type is in unnamed module of loader 'app'; clj_commons.byte_streams.graph.Type is in unnamed module of loader clojure.lang.DynamicClassLoader @157345d0)


Happens when compiling a code base which has a def-conversion . Commenting it out gets rid of the error.


It does use the new clj-commons.byte-streams namespace tho :thinking_face:


will try to come up with a minimal repro and file an issue


OK so far unable to come up with an isolated repro 😕


Are you 100% sure that the new version of the library is on the classpath?


yeah pretty much


no other versions in -Stree or -Spath


Just to be absolutely sure - you use those flags with the right aliases you actually use when running the app, right? When I was facing this issue, I had to use a step debugger and manually and menially go backwards from the problematic call site. But it worked.


Intermediate update: Looks like I'm running into here, i.e. I'm also aot-compiling sources here but using rather than Leiningen. was a similar issue. I think I might be able to come up with an isolated repro now ...


ok whittling down ...

Matthew Davidson (kingmob)15:01:05

AOT is always error-prone. At least every other year, I run into a problem caused by an AOT uberjar that has competing classes in it that it shouldn’t. It can be hard to debug since it depends heavily on the classpath order, making it intermittent.


OK found a way to work around it in my original case


@kingmob in you suggested to re-open that issue if it re-surfaces. Do you want me to put my repro in a comment there or rather make separate issue for it?

Matthew Davidson (kingmob)09:01:32

@U06GVE6NR Does the use of deftype+ help any? We can reopen the issue and add to it, or start a new issue. Either is fine with me. More importantly, is this something we can fix or workaround? Or is it, at best, a bug in the clojure compiler we should make people aware of?


@kingmob deftype+ doesn't make a difference in this situation alas 😕 Thanks for the idea, tho!


In the light of my latest understanding, I think I would just point to the jira issue in the README, mentioning the error message for discoverability via web search


Will file an issue anyway!


Ah interesting, it doesn't even have to do with a custom type being involved


OK: -- was actually able to come up with a fix / workaround!


Thanks for the fix, just went through the same pain 😬 @kingmob Happy to help shepherding through a 0.6.1 release!