AOT(?) bug on loading

[AdamClements]

I'm trying to use clj-tuple in a lein-droid project, and it works fine in debug mode, but as soon as I change to release mode I get an odd exception

...
Caused by: java.lang.NullPointerException
AndroidRuntime:     at java.io.File.fixSlashes(File.java:185)
AndroidRuntime:     at java.io.File.<init>(File.java:134)
AndroidRuntime:     at clojure.lang.DalvikDynamicClassLoader.defineMissingClass(DalvikDynamicClassLoader.java:84)

I've made a minimal project which reproduces this at https://github.com/AdamClements/clj-tuple-droid-repro-case which also has the full stacktrace and more details.

It looks like an AOT bug as it's in the middle of an eval block, but I'm not sure where to start, and what is making it want to try to load files at this stage... any pointers appreciated!

If I remove the clj-tuple dependency and simply use persistent vectors, the rest of my (non-trivial, lots of other dependencies) project works identically to debug mode, no problems.

Thanks.

[ztellman]

I use byte-streams in AOT projects, which uses clj-tuple, so this is likely specific to Android. I'll do what I can to track down the problem, though. Are there any special caveats w.r.t. use of eval in Android I should be aware of?

[AdamClements]

Not that I know of, I'm chasing the lein-droid guys too, I'll report back if I get any extra info.

More concern longer term is the new production mode clojure stuff (I'm thinking of oxcart specifically) which will forbid use of eval in production mode for speed reasons. Is there any way to simplify and remove the eval? Or should I be looking at forking and making a simpler tuple library - I would only want 2 3 and 4 value tuples, and any conj/editing operation would just instantly change it to a persistentvector (I'm using this for passing around coordinates, very rarely do they need structural sharing when transformed)

[AdamClements]

So if I simply delete all the eval'd code, it works fine. What do I lose? As far as I can tell, I lose the ability to conj onto a tuple, which imho makes no sense for a tuple anyway - I'm using these for vectors etc. where the cardinality doesn't change.

What would I need to change to make a simpler version of this library where any modification operation simply replaces the whole thing with a vector (possibly with the exception of updating at a specific index)

[ztellman]

I can get rid of the eval, all I need to do is define the eval'd code in a
macro. I'll get a release out sometime today.

On Wed, Jun 18, 2014 at 8:34 AM, AdamClements notifications@github.com
wrote:

So if I simply delete all the eval'd code, it works fine. What do I lose?
As far as I can tell, I lose the ability to conj onto a tuple, which imho
makes no sense for a tuple anyway - I'm using these for vectors etc. where
the cardinality doesn't change.

What would I need to change to make a simpler version of this library
where any modification operation simply replaces the whole thing to a
vector (possibly with the exception of updating at a specific index)

—
Reply to this email directly or view it on GitHub
#13 (comment).

[AdamClements]

Any update on this?

[ztellman]

Sorry, this slipped my mind entirely. Feel free to bug me sooner if this ever happens again.