[ANN] Clojure 1.7.0-alpha5 now available

1,972 views
Skip to first unread message

Alex Miller

unread,
Jan 10, 2015, 10:37:04 AM1/10/15
to clo...@googlegroups.com, cloju...@googlegroups.com
Clojure 1.7.0-alpha5 is now available.

Try it via
- Leiningen: [org.clojure/clojure "1.7.0-alpha5"]

A few of the highlights in alpha5:

1) New transducer arities for map-indexed, distinct, and interpose.
The transducer versions are generally faster than the sequence versions.
See CLJ-1601 for more details.

2) The set and vec functions should now be faster in many cases. Some of the
vec improvements will not kick in until CLJ-1499 is committed in the future.
See CLJ-1546 and CLJ-1618 for more details.

3) Two particularly troublesome AOT classloading bugs have been addressed - 
CLJ-979 and CLJ-1544. Many other tickets were found to be duplicates of one of
these as well. Big thanks to Nicola Mometto for doing the hard work on 
debugging and providing fixes for these.

For all changes new in alpha5, see the issues marked "(alpha5)" in the
full changes below.

------------------------------------------------------------
Clojure 1.7.0-alpha5 has the changes below from 1.6.0:

## 1 New and Improved Features

### 1.1 Transducers

Transducers is a new way to decouple algorithmic transformations from their
application in different contexts. Transducers are functions that transform
reducing functions to build up a "recipe" for transformation.


Many existing sequence functions now have a new arity (one fewer argument
than before). This arity will return a transducer that represents the same
logic but is independent of lazy sequence processing. Functions included are:

* conj (conjs to [])
* map
* mapcat
* filter
* remove
* take
* take-while
* drop
* drop-while
* cycle
* take-nth
* replace
* partition-by
* partition-all
* keep
* keep-indexed
* map-indexed (alpha5)
* distinct (alpha5)
* interpose (alpha5)

Additionally some new transducer functions have been added:

* cat - concatenates the contents of each input
* de-dupe - removes consecutive duplicated values
* random-sample - returns items from coll with random probability

And this function can be used to make completing transforms:

* completing

There are also several new or modified functions that can be used to apply
transducers in different ways:

* sequence - takes a transformation and a coll and produces a lazy seq
* transduce - reduce with a transformation (eager)
* eduction - returns a reducible/seqable/iterable seq of applications of the transducer to items in coll. Applications are re-performed with every reduce/seq/iterator.
* run! - run the transformation for side effects on the collection

There have been a number of internal changes to support transducers:

* volatiles - there are a new set of functions (volatile!, vswap!, vreset!, volatile?) to create and use volatile "boxes" to hold state in stateful transducers. Volatiles are faster than atoms but give up atomicity guarantees so should only be used with thread isolation.
* array iterators - added support for iterators over arrays

Some related issues addressed during development:

### 1.2 Keyword and Symbol Construction

In response to issues raised in [CLJ-1439](http://dev.clojure.org/jira/browse/CLJ-1439),
several changes have been made in symbol and keyword construction:

1) The main bottleneck in construction of symbols (which also occurs inside keywords) was
interning of the name and namespace strings. This interning has been removed, resulting
in a performance increase.

2) Keywords are cached and keyword construction includes a cache check. A change was made
to only clear the cache reference queue when there is a cache miss.

### 1.3 Warn on Boxed Math

One source of performance issues is the (unintended) use of arithmetic operations on
boxed numbers. To make detecting the presence of boxed math easier, a warning will now
be emitted about boxed math if \*unchecked-math* is set to :warn-on-boxed (any truthy
value will enable unchecked-math, only this specific value enables the warning).

Example use:

    user> (defn plus-2 [x] (+ x 2))  ;; no warning, but boxed
#'user/plus-2
    user> (set! *unchecked-math* :warn-on-boxed)
true
    user> (defn plus-2 [x] (+ x 2)) ;; now we see a warning
    Boxed math warning, NO_SOURCE_PATH:10:18 - call: public static java.lang.Number
clojure.lang.Numbers.unchecked_add(java.lang.Object,long).
    #'user/plus-2
user> (defn plus-2 [^long x] (+ x 2)) ;; use a hint to avoid boxing
#'user/plus-2


### 1.4 update - like update-in for first level

`update` is a new function that is like update-in specifically for first-level keys:

    (update m k f args...)

Example use:

    user> (update {:a 1} :a inc)
{:a 2}
user> (update {:a 1} :a + 2)
{:a 3}
user> (update {} :a identity)  ;; missing returns nil
{:a nil}


## 2 Enhancements

### 2.1 Error messages

  Invalid defrecord results in exception attributed to consuming ns instead of defrecord ns
  Report line,column, and source in defmacro errors
  Give more specific hint if namespace with "-" not found to check file uses "_"

### 2.2 Documentation strings

  clojure.java.io/input-stream has incorrect docstring
  Fix typo in gen-class doc-string
  Fix typo in filterv example
  Fix typo in defmulti docstring
  Fix typo in deftype docstring
  Fix typo in clojure.main usage

### 2.3 Performance

  Improve performance of partial with more unrolling
  clojure.core/set should use transients for better performance
  Cache unknown multimethod value default dispatch
  Reduce compile times by avoiding unnecessary calls to Class.forName()
  vec is now faster on almost all inputs
  set is now faster on almost all inputs

### 2.4 Other enhancements

  Improve apropos to show some indication of namespace of symbols found
  Hints don't work with #() form of function
  Removes owner-thread check from transients - this check was preventing some valid usage of transients in core.async where a transient is created on one thread and then used again in another pooled thread (while still maintaining thread isolation).
  Extracted IAtom interface implemented by Atom.
  Don't initialize classes when importing them
  Class name clash between top-level functions and defn'ed ones
  Update to latest test.generative and add dependency on test.check
  vec now works with things that only implement Iterable or IReduceInit
  set now works with things that only implement Iterable or IReduceInit
  PersistentList/creator doesn't handle ArraySeqs correctly

## 3 Bug Fixes

  Reduce broken on some primitive vectors
  Equality bug on records created with nested calls to map->record
  Unable to set compiler options via system properties except for AOT compilation
  NPE when AOTing overrided clojure.core functions
  reductions does not check for reduced value
  Using def with metadata {:type :anything} throws ClassCastException during printing
  Error when calling primitive functions with destructuring in the arg vector
  Piping seque into seque can deadlock
  <= is incorrect when args include Double/NaN
  Make cached string value of Keyword and Symbol transient
  clojure.core/bean should implement Iterable
  Make refer of Clojure core function not throw exception on reload
  LazySeq equals() should not use equiv() logic
  into (and other fns that rely on reduce) require only IReduceInit
  PersistentVector now directly implements reduce without init
  Transient collections should guarantee thread visibility
  Some IReduce/IReduceInit implementors don't respect reduced
  Clojure resolves to wrong deftype classes when AOT compiling or reloading
  AOT bug involving namespaces loaded before AOT compilation started

Alex Miller

unread,
Jan 11, 2015, 9:34:07 AM1/11/15
to clo...@googlegroups.com
I would greatly appreciate hearing any feedback about this (or any other) alpha, even if it's just: everything looks ok.

We've had a couple of regressions reported and that is hugely helpful as we can quickly turn around fixes for the next one.

Interested particularly in: regressions, performance +/-, and for this alpha, AOT.

Plínio Balduino

unread,
Jan 11, 2015, 11:45:50 AM1/11/15
to Clojure Official
Hi there, Alex and Clojure team

Is there a planned date for the stable version release?

Regards

Plínio

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

adrian...@mail.yu.edu

unread,
Jan 11, 2015, 1:08:17 PM1/11/15
to clo...@googlegroups.com
For my projects swapping 1.7.0-alpha4 -> alpha5 has not culminated in any abnormalities. So... looking good thus far on my end. 

Luc Préfontaine

unread,
Jan 11, 2015, 5:51:07 PM1/11/15
to clo...@googlegroups.com
So far so good, will go in prod with it next Wednesday.
Will run some heavy integrated tests in the next 48 hours.
Will report if anything shows up.

Thank you,
Luc P.


> For my projects swapping 1.7.0-alpha4 -> alpha5 has not culminated in any
> abnormalities. So... looking good thus far on my end.
>
> On Sunday, January 11, 2015 at 11:45:50 AM UTC-5, Plinio Balduino wrote:
> >
> > Hi there, Alex and Clojure team
> >
> > Is there a planned date for the stable version release?
> >
> > Regards
> >
> > Plínio
> >
> > On Sun, Jan 11, 2015 at 12:34 PM, Alex Miller <al...@puredanger.com
> > <javascript:>> wrote:
> >
> >> I would greatly appreciate hearing any feedback about this (or any other)
> >> alpha, even if it's just: everything looks ok.
> >>
> >> We've had a couple of regressions reported and that is hugely helpful as
> >> we can quickly turn around fixes for the next one.
> >>
> >> Interested particularly in: regressions, performance +/-, and for this
> >> alpha, AOT.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clo...@googlegroups.com
> >> <javascript:>
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+u...@googlegroups.com <javascript:>
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google Groups
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to clojure+u...@googlegroups.com <javascript:>.
> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Luc Préfontaine<lprefo...@softaddicts.ca> sent by ibisMail!

Sean Corfield

unread,
Jan 11, 2015, 7:55:14 PM1/11/15
to clo...@googlegroups.com
On Jan 11, 2015, at 6:34 AM, Alex Miller <al...@puredanger.com> wrote:
> I would greatly appreciate hearing any feedback about this (or any other) alpha, even if it's just: everything looks ok.

I upgraded an app that uses core.async (0.1.346.0-17112a-alpha) and got this exception on the ns that brings in clojure.core.async - it uses the latest versions of both core.cache and core.memoize as transitive dependencies, with no conflicts:

Exception in thread "main" java.lang.IllegalArgumentException: No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization, compiling:(async.clj:433:6)
at clojure.lang.Compiler.macroexpand1(Compiler.java:6619)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6694)
at clojure.lang.Compiler.analyze(Compiler.java:6499)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6696)
at clojure.lang.Compiler.analyze(Compiler.java:6499)
at clojure.lang.Compiler.analyze(Compiler.java:6460)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5836)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5271)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3900)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6706)
at clojure.lang.Compiler.analyze(Compiler.java:6499)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6696)
at clojure.lang.Compiler.analyze(Compiler.java:6499)
at clojure.lang.Compiler.access$200(Compiler.java:38)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:560)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6708)
at clojure.lang.Compiler.analyze(Compiler.java:6499)
at clojure.lang.Compiler.analyze(Compiler.java:6460)
at clojure.lang.Compiler.eval(Compiler.java:6771)
at clojure.lang.Compiler.load(Compiler.java:7194)
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.load(RT.java:440)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5436.invoke(core.clj:5863)
at clojure.core$load.doInvoke(core.clj:5862)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5653)
at clojure.core$load_lib$fn__5383.invoke(core.clj:5708)
at clojure.core$load_lib.doInvoke(core.clj:5707)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$load_libs.doInvoke(core.clj:5746)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$require.doInvoke(core.clj:5829)
at clojure.lang.RestFn.invoke(RestFn.java:551)
at dynamo.auth$eval1147$loading__5322__auto____1148.invoke(auth.clj:5)
at dynamo.auth$eval1147.invoke(auth.clj:5)
...
Caused by: java.lang.IllegalArgumentException: No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization
at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:555)
at clojure.core.cache$eval1710$fn__1773$G__1699__1780.invoke(cache.clj:20)
at clojure.core.cache$through.invoke(cache.clj:53)
at clojure.core.memoize$through_STAR_.invoke(memoize.clj:52)
at clojure.lang.Atom.swap(Atom.java:65)
at clojure.core$swap_BANG_.invoke(core.clj:2236)
at clojure.core.memoize$build_memoizer$fn__12665.doInvoke(memoize.clj:134)
...

Sean Corfield

unread,
Jan 11, 2015, 8:07:42 PM1/11/15
to clo...@googlegroups.com
The full Caused by stacktrace is this:

Caused by: java.lang.IllegalArgumentException: No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization
at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:555)
at clojure.core.cache$eval1710$fn__1773$G__1699__1780.invoke(cache.clj:20)
at clojure.core.cache$through.invoke(cache.clj:53)
at clojure.core.memoize$through_STAR_.invoke(memoize.clj:52)
at clojure.lang.Atom.swap(Atom.java:65)
at clojure.core$swap_BANG_.invoke(core.clj:2236)
at clojure.core.memoize$build_memoizer$fn__12665.doInvoke(memoize.clj:134)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.AFunction$1.doInvoke(AFunction.java:29)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.tools.analyzer.jvm$desugar_host_expr.invoke(jvm.clj:117)
at clojure.tools.analyzer.jvm$macroexpand_1.invoke(jvm.clj:174)
at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:281)
at clojure.lang.MultiFn.invoke(MultiFn.java:238)
at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer$analyze_let.invoke(analyzer.clj:505)
at clojure.tools.analyzer$fn__12469.invoke(analyzer.clj:530)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:283)
at clojure.lang.MultiFn.invoke(MultiFn.java:238)
at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:284)
at clojure.lang.MultiFn.invoke(MultiFn.java:238)
at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer$fn__12392.invoke(analyzer.clj:295)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer$analyze_body.invoke(analyzer.clj:366)
at clojure.tools.analyzer$analyze_let.invoke(analyzer.clj:520)
at clojure.tools.analyzer$fn__12471.invoke(analyzer.clj:540)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:283)
at clojure.lang.MultiFn.invoke(MultiFn.java:238)
at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:284)
at clojure.lang.MultiFn.invoke(MultiFn.java:238)
at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer$fn__12392.invoke(analyzer.clj:295)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:283)
at clojure.lang.MultiFn.invoke(MultiFn.java:238)
at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.tools.analyzer$analyze.invoke(analyzer.clj:123)
at clojure.tools.analyzer.jvm$analyze$fn__14085.invoke(jvm.clj:476)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1864)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at clojure.tools.analyzer.jvm$analyze.invoke(jvm.clj:474)
at clojure.tools.analyzer.jvm$analyze.invoke(jvm.clj:467)
at clojure.core.async.impl.ioc_macros$state_machine.invoke(ioc_macros.clj:1062)
at clojure.core.async$go.doInvoke(async.clj:384)
at clojure.lang.RestFn.invoke(RestFn.java:442)
at clojure.lang.Var.invoke(Var.java:388)
at clojure.lang.AFn.applyToHelper(AFn.java:160)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.lang.Compiler.macroexpand1(Compiler.java:6606)

Sean Corfield

unread,
Jan 11, 2015, 8:17:27 PM1/11/15
to clo...@googlegroups.com
I tried upgrading a few more apps and ran into this same problem in the absence of core.async - but in the presence of core.cache and core.memoize so I'm trying to create a small test case to isolate the issue.

Sean
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



Alex Miller

unread,
Jan 11, 2015, 9:00:52 PM1/11/15
to clo...@googlegroups.com
No, we do not work from planned release dates. When it's done, we ship it.

The current plan is to do at least one more alpha with a version of feature expressions that is a bit slimmer than the current available patches to make that available for people to experiment (presumably along with tools.reader and Clojurescript releases).

Depending on feedback from that we will move to beta (aka "feature complete"). I expect most if not all outstanding 1.7 tickets to be done by then. At that point, it's just grinding things down till release.

Alex Miller

unread,
Jan 11, 2015, 9:13:22 PM1/11/15
to clo...@googlegroups.com
Thanks Sean. I'm hoping to get new releases of core.cache and core.menoize in th near future too but seems worth looking into.

Sean Corfield

unread,
Jan 11, 2015, 9:49:25 PM1/11/15
to clo...@googlegroups.com
On Jan 11, 2015, at 6:13 PM, Alex Miller <al...@puredanger.com> wrote:
> Thanks Sean. I'm hoping to get new releases of core.cache and core.menoize in th near future too but seems worth looking into.

I'm having a hard time producing a standalone repro case. It fails in the context of every single one of our apps, but doesn't fail in a project with just Clojure 1.7.0 Alpha 5 and the latest core.cache and core.memoize so it would seem to be an interaction with something else we're using. Will continue to work on narrowing this down this week.

Updated releases of core.cache and core.memoize would be nice - they've both had a few updates since the last published releases.

Mike Fikes

unread,
Jan 11, 2015, 9:50:32 PM1/11/15
to clo...@googlegroups.com
Alex, 1.7.0-alpha5 looks OK to me. It passed with some regression testing for an AOTd http-kit compojure / core.async REST server using Lucene, clojure/java.jdbc / MySQL, Java 1.7.0_65 on Ubuntu 10.04.1 LTS.

Rangel Spasov

unread,
Jan 12, 2015, 4:43:09 AM1/12/15
to clo...@googlegroups.com
Hey guys,

I noticed that PersistentVector.create() is missing one arity that used to exist before:

PersistentVector.create(List items)


NoSuchMethodError clojure.lang.PersistentVector.create(Ljava/util/List;)Lclojure/lang/PersistentVector; 

I can fix the library, I don't think it will be a big problem, just making sure that's something you guys were OK with breaking - it's more like an implementation detail as far as I can see. 

Thanks,
Rangel
@raspasov

Mikera

unread,
Jan 12, 2015, 4:59:09 AM1/12/15
to clo...@googlegroups.com
It seems a little odd that there is an "ArrayList" override but not "List". Presumably that is there as an optimisation since ArrayList is such a common case?

It seems to have happened in this commit for CLJ-1546, which replaces the "List" override with "ArrayList"
https://github.com/clojure/clojure/commit/4afd4a7c14c48b5baf3c03196053066483cb4223

I'd probably recommend keeping the old "List" override around: it is more general, potentially useful for Interop and will help avoid breakage like this (even if it is just an implementation detail).

Bronsa

unread,
Jan 12, 2015, 6:00:53 AM1/12/15
to clo...@googlegroups.com

Do the failing projects require AOT compilation? we used to see a similar exception in eastwood when reloading core.cache and  one of the AOT patches committed can cause some namespaces to be reloaded

Jony Hudson

unread,
Jan 12, 2015, 6:51:52 AM1/12/15
to clo...@googlegroups.com, cloju...@googlegroups.com
I have a set of micro-benchmarks on a project that is compute-heavy (symbolic regression, genetic programming). I see no performance regressions :-)

Jony

Alex Miller

unread,
Jan 12, 2015, 9:29:20 AM1/12/15
to clo...@googlegroups.com
Rangel - I have filed http://dev.clojure.org/jira/browse/CLJ-1638 to replace the method, which seems like the best solution. 

Alex Miller

unread,
Jan 12, 2015, 9:30:16 AM1/12/15
to clo...@googlegroups.com
Do you have the full stack trace in the cases where you see this without core.async?

Alex Miller

unread,
Jan 12, 2015, 10:51:24 AM1/12/15
to clo...@googlegroups.com
Yes, ArrayList is a particularly common case (see http://insideclojure.org/2015/01/07/vec-perf/). I'm going to reinstate the prior one though, no reason to break people (even if they are using an internal method).

Sean Corfield

unread,
Jan 12, 2015, 11:02:45 AM1/12/15
to clo...@googlegroups.com
On Jan 12, 2015, at 3:00 AM, Bronsa <brob...@gmail.com> wrote:

Do the failing projects require AOT compilation? we used to see a similar exception in eastwood when reloading core.cache and  one of the AOT patches committed can cause some namespaces to be reloaded


We have one (very small) AOT’d library that interfaces with log4j. All our main projects depend on that. We did lein clean on all our projects and rebuilt all of them from scratch on Alpha 5.

Sean Corfield

unread,
Jan 12, 2015, 11:06:50 AM1/12/15
to clo...@googlegroups.com
Here’s what I see reproducing this in the REPL - this main project doesn't use core.async (but does use a very small AOT'd library). I'm going to try to cut this down to see if I can repro outside our main project (worldsingles.cache is a thin wrapper over core.cache and core.memoize - moving that exact same code to a fresh project, without any other dependencies, works so it's something in combination with our other dependencies):

user=> (require 'worldsingles.cache)
nil
user=> (defn foo[n] (+ 13 n))
#'user/foo
user=> (worldsingles.cache/memo foo "site")
#<clojure.lang.AFunction$1@7090307d>
user=> (*1 42)

IllegalArgumentException No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization clojure.core/-cache-protocol-fn (core_deftype.clj:555)
user=> (pst *e)
IllegalArgumentException No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization
clojure.core/-cache-protocol-fn (core_deftype.clj:555)
clojure.core.cache/eval2178/fn--2241/G--2167--2248 (cache.clj:20)
clojure.core.cache/through (cache.clj:53)
clojure.core.memoize/through* (memoize.clj:52)
clojure.lang.Atom.swap (Atom.java:65)
clojure.core/swap! (core.clj:2236)
clojure.core.memoize/build-memoizer/fn--12665 (memoize.clj:134)
clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
user/eval2486 (form-init7972562298655212181.clj:1)
clojure.lang.Compiler.eval (Compiler.java:6767)
clojure.lang.Compiler.eval (Compiler.java:6730)
clojure.core/eval (core.clj:3076)
nil
user=> (clojure.stacktrace/print-stack-trace *e)
java.lang.IllegalArgumentException: No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization
at clojure.core$_cache_protocol_fn.invoke (core_deftype.clj:555)
clojure.core.cache$eval2178$fn__2241$G__2167__2248.invoke (cache.clj:20)
clojure.core.cache$through.invoke (cache.clj:53)
clojure.core.memoize$through_STAR_.invoke (memoize.clj:52)
clojure.lang.Atom.swap (Atom.java:65)
clojure.core$swap_BANG_.invoke (core.clj:2236)
clojure.core.memoize$build_memoizer$fn__12665.doInvoke (memoize.clj:134)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
clojure.lang.RestFn.invoke (RestFn.java:408)
user$eval2486.invoke (form-init7972562298655212181.clj:1)
clojure.lang.Compiler.eval (Compiler.java:6767)
clojure.lang.Compiler.eval (Compiler.java:6730)
clojure.core$eval.invoke (core.clj:3076)
clojure.main$repl$read_eval_print__7311$fn__7314.invoke (main.clj:239)
clojure.main$repl$read_eval_print__7311.invoke (main.clj:239)
clojure.main$repl$fn__7320.invoke (main.clj:257)
clojure.main$repl.doInvoke (main.clj:257)
clojure.lang.RestFn.invoke (RestFn.java:1523)
clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__876.invoke (interruptible_eval.clj:67)
clojure.lang.AFn.applyToHelper (AFn.java:152)
clojure.lang.AFn.applyTo (AFn.java:144)
clojure.core$apply.invoke (core.clj:626)
clojure.core$with_bindings_STAR_.doInvoke (core.clj:1864)
clojure.lang.RestFn.invoke (RestFn.java:425)
clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke (interruptible_eval.clj:51)
clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__918$fn__921.invoke (interruptible_eval.clj:183)
clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__911.invoke (interruptible_eval.clj:152)
clojure.lang.AFn.run (AFn.java:22)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617)
java.lang.Thread.run (Thread.java:745)
nil
user=>

Nicola Mometto

unread,
Jan 12, 2015, 11:10:15 AM1/12/15
to clo...@googlegroups.com

Can you try a custom version of clojure 1.7.0-alpha5 with commit
e5a104e894ed82f244d69513918d570cee5df67d reverted and see if you still
get the exception?

Nicola
--

Sean Corfield

unread,
Jan 12, 2015, 11:32:11 AM1/12/15
to clo...@googlegroups.com
On Jan 12, 2015, at 8:09 AM, Nicola Mometto <brob...@gmail.com> wrote:
> Can you try a custom version of clojure 1.7.0-alpha5 with commit
> e5a104e894ed82f244d69513918d570cee5df67d reverted and see if you still
> get the exception?

Yes, reverting that one commit and creating Clojure 1.7.0-aot5 and rebuilding and testing our project against that version does still produce that same exception.

Sean Corfield

unread,
Jan 12, 2015, 12:24:16 PM1/12/15
to clo...@googlegroups.com
I have confirmed that reverting this commit addresses the problems we are encountering:

https://github.com/clojure/clojure/commit/9f277c80258b3d2951128ce26a07c30ad0b47af0

"CLJ-979: make clojure resolve to the correct Class instances"

Since we routinely run our test suite against master, and we hadn't seen this failure last week, it had to be one of the handful of commits made immediately prior to releasing Alpha 5.

Sean

Andy Fingerhut

unread,
Jan 12, 2015, 12:30:57 PM1/12/15
to clo...@googlegroups.com
Nicola, Sean:

I am _not_ testing with Sean's code, so can't comment whether my results will correspond with his.

I have found that between Clojure 1.7.0-alpha4 and 1.7.0-alpha5, and the latest Eastwood version 0.2.1 released, I get an exception trying to lint the namespace clojure.reflect in Clojure itself with 1.7.0-alpha5, but not with 1.7.0-alpha4, and the exception message is similar in that it has to do with "No implementation of method: ..." for a protocol.

I went through several of the individual commits between alpha4 and alpha5, and found it was the commit for CLJ-979 that introduced the change in behavior.  I can even take the CLJ-979 patch and patch it into Clojure 1.7.0-alpha4, and I get the same exception.  Details of the exception and stack trace I get below.

Andy

I created a project directory to run the command below in.  It simply has a dependency on my custom-built version of Clojure.

% lein do clean, eastwood '{:namespaces [clojure.reflect]}'

== Eastwood 0.2.1 Clojure 1.7.0-alpha4c979only JVM 1.7.0_45

== Linting clojure.reflect ==

Exception thrown during phase :analyze+eval of linting namespace clojure.reflect

IllegalArgumentException No implementation of method: :do-reflect of protocol: #'clojure.reflect/Reflector found for class: clojure.reflect.JavaReflector

clojure.core/-cache-protocol-fn (core_deftype.clj:555)

clojure.reflect/eval6486/fn--6487/G--6470--6490 (form-init6080826551765301071.clj:1)

clojure.core/partial/fn--4490 (core.clj:2489)

clojure.reflect/type-reflect (reflect.clj:100)

clojure.core/apply (core.clj:632)

eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/type-reflect (utils.clj:24)

eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/members*--1293 (utils.clj:271)

clojure.core/apply (core.clj:626)

eastwood.copieddeps.dep3.clojure.core.memoize/through*/fn--1072 (memoize.clj:66)

eastwood.copieddeps.dep4.clojure.core.cache/through/fn--872 (cache.clj:55)

eastwood.copieddeps.dep3.clojure.core.memoize/through*/fn--1068/fn--1069 (memoize.clj:65)

eastwood.copieddeps.dep3.clojure.core.memoize/d-lay/reify--1063 (memoize.clj:54)

clojure.core/deref (core.clj:2202)

eastwood.copieddeps.dep3.clojure.core.memoize/build-memoizer/fn--1123 (memoize.clj:152)

clojure.lang.AFunction$1.doInvoke (AFunction.java:29)

eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/members (utils.clj:280)

eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/instance-members (utils.clj:289)

eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/instance-methods (utils.clj:299)

eastwood.copieddeps.dep2.clojure.tools.analyzer.passes.jvm.validate/validate-call (validate.clj:91)

eastwood.copieddeps.dep2.clojure.tools.analyzer.passes.jvm.validate/eval2056/fn--2058 (validate.clj:148)

clojure.lang.MultiFn.invoke (MultiFn.java:229)

eastwood.copieddeps.dep2.clojure.tools.analyzer.passes.jvm.validate/validate (validate.clj:264)

clojure.lang.Var.invoke (Var.java:379)

eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--579 (passes.clj:171)

eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--581 (passes.clj:173)

eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--581 (passes.clj:173)

eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--581 (passes.clj:173)

clojure.core/partial/fn--4492 (core.clj:2496)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:102)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192 (ast.clj:96)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182 (ast.clj:51)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6414 (protocols.clj:65)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children (ast.clj:56)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced (ast.clj:64)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:99)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192 (ast.clj:96)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182 (ast.clj:51)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6414 (protocols.clj:65)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children (ast.clj:56)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced (ast.clj:64)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:99)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192 (ast.clj:96)

eastwood.copieddeps.dep1.clojure.tools.analyzer.utils/mapv' (utils.clj:208)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182 (ast.clj:51)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:58)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6414 (protocols.clj:65)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children (ast.clj:56)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced (ast.clj:64)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:99)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192 (ast.clj:96)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182 (ast.clj:51)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:58)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6414 (protocols.clj:65)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children (ast.clj:56)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced (ast.clj:64)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:99)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192 (ast.clj:96)

eastwood.copieddeps.dep1.clojure.tools.analyzer.utils/mapv' (utils.clj:208)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182 (ast.clj:51)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:58)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6414 (protocols.clj:65)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children (ast.clj:56)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced (ast.clj:64)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:99)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192 (ast.clj:96)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182 (ast.clj:51)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6414 (protocols.clj:65)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children (ast.clj:56)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced (ast.clj:64)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:99)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192 (ast.clj:96)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182 (ast.clj:51)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6414 (protocols.clj:65)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children (ast.clj:56)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced (ast.clj:64)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:99)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192 (ast.clj:96)

eastwood.copieddeps.dep1.clojure.tools.analyzer.utils/mapv' (utils.clj:208)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182 (ast.clj:51)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:58)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6414 (protocols.clj:65)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children (ast.clj:56)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced (ast.clj:64)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:99)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192 (ast.clj:96)

eastwood.copieddeps.dep1.clojure.tools.analyzer.utils/mapv' (utils.clj:208)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182 (ast.clj:51)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6414 (protocols.clj:65)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children (ast.clj:56)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced (ast.clj:64)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:99)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192 (ast.clj:96)

eastwood.copieddeps.dep1.clojure.tools.analyzer.utils/mapv' (utils.clj:208)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182 (ast.clj:51)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6414 (protocols.clj:65)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children (ast.clj:56)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced (ast.clj:64)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:99)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192 (ast.clj:96)

eastwood.copieddeps.dep1.clojure.tools.analyzer.utils/mapv' (utils.clj:208)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182 (ast.clj:51)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6414 (protocols.clj:65)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children (ast.clj:56)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced (ast.clj:64)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191 (ast.clj:99)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk (ast.clj:95)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/postwalk (ast.clj:115)

eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/postwalk (ast.clj:113)

eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/analyze--586 (passes.clj:175)

clojure.core/comp/fn--4458 (core.clj:2434)

clojure.core/comp/fn--4458 (core.clj:2434)

eastwood.analyze-ns/run-passes (analyze_ns.clj:157)

eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm/analyze/fn--3553 (jvm.clj:474)

clojure.core/apply (core.clj:626)

clojure.core/with-bindings* (core.clj:1864)

eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm/analyze (jvm.clj:470)

eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm/analyze+eval (jvm.clj:518)

eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm/analyze+eval/fn--3574 (jvm.clj:505)

clojure.core/mapv/fn--6657 (core.clj:6558)

clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)

clojure.core.protocols/fn--6433 (protocols.clj:103)

clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)

clojure.core.protocols/seq-reduce (protocols.clj:31)

clojure.core.protocols/fn--6418 (protocols.clj:53)

clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)

clojure.core/reduce (core.clj:6461)

clojure.core/mapv (core.clj:6558)

eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm/analyze+eval (jvm.clj:503)

eastwood.analyze-ns/analyze-file/fn--4173/fn--4175 (analyze_ns.clj:279)

eastwood.analyze-ns/analyze-file/fn--4173 (analyze_ns.clj:276)

eastwood.analyze-ns/analyze-file (analyze_ns.clj:274)

eastwood.analyze-ns/analyze-ns (analyze_ns.clj:327)

eastwood.lint/lint-ns (lint.clj:569)

eastwood.lint/eastwood-core/fn--6336 (lint.clj:1041)

eastwood.lint/eastwood-core (lint.clj:1040)

eastwood.lint/eastwood (lint.clj:1154)

eastwood.lint/eastwood-from-cmdline (lint.clj:1167)

clojure.lang.Var.invoke (Var.java:379)

eastwood.versioncheck/run-eastwood (versioncheck.clj:15)

user/eval21 (form-init6080826551765301071.clj:1)

clojure.lang.Compiler.eval (Compiler.java:6767)

clojure.lang.Compiler.eval (Compiler.java:6757)

clojure.lang.Compiler.load (Compiler.java:7194)

clojure.lang.Compiler.loadFile (Compiler.java:7150)

clojure.main/load-script (main.clj:274)

clojure.main/init-opt (main.clj:279)

clojure.main/initialize (main.clj:307)

clojure.main/null-opt (main.clj:342)

clojure.main/main (main.clj:420)

clojure.lang.Var.invoke (Var.java:383)

clojure.lang.Var.applyTo (Var.java:700)

clojure.main.main (main.java:37)


The following form was being processed during the exception:

(defprotocol

 TypeReference

 "A TypeReference can be unambiguously converted to a type name on\n   the host platform.\n\n   All typerefs are normalized into symbols. If you need to\n   normalize a typeref yourself, call typesym."

 (typename

  [o]

  "Returns Java name as returned by ASM getClassName, e.g. byte[], java.lang.String[]"))



Shown again with metadata for debugging (some metadata elided for brevity):

^{:line 48}

(^{:line 48} defprotocol

 ^{:line 48} TypeReference

 "A TypeReference can be unambiguously converted to a type name on\n   the host platform.\n\n   All typerefs are normalized into symbols. If you need to\n   normalize a typeref yourself, call typesym."

 ^{:line 54}

 (^{:line 54} typename

  ^{:line 54} [^{:line 54} o]

  "Returns Java name as returned by ASM getClassName, e.g. byte[], java.lang.String[]"))



An exception was thrown while analyzing namespace clojure.reflect 

Lint results may be incomplete.  If there are compilation errors in

your code, try fixing those.  If not, check above for info on the

exception.


Exception thrown while analyzing last namespace.


== Warnings: 0 (not including reflection warnings)  Exceptions thrown: 1

Subprocess failed





tcrayford

unread,
Jan 12, 2015, 1:37:05 PM1/12/15
to clo...@googlegroups.com, cloju...@googlegroups.com
I said this already on twitter, but I see heavy (5-10x slower) perf regressions on my benchmark suite from 1.7-alpha5 vs 1.6. I am trying the other alphas now - I have a comprehensive benchmark suite that takes 4 hours or so to run, and it's a bit backed up right now (I only have one box to run it on). I'm also going to point YourKit at 1.7-alpha5 soon on the worst regressing benchmarks (not all of them have such heavy regressions, and a few benchmarks are dramatically faster) and see what happens - will report back here once I have something more to say.

Alex Miller

unread,
Jan 12, 2015, 1:37:27 PM1/12/15
to clo...@googlegroups.com
I would be helpful to me at this point to have a jira regarding this problem which I will presume for the time being is the same in both Andy and Sean's case.
...

Sean Corfield

unread,
Jan 12, 2015, 2:32:48 PM1/12/15
to clo...@googlegroups.com

Sean Corfield

unread,
Jan 12, 2015, 9:26:08 PM1/12/15
to clo...@googlegroups.com
On Jan 12, 2015, at 11:32 AM, Sean Corfield <se...@corfield.org> wrote:

It turned out to be due to core.typed whose JAR includes AOT’d versions of core.cache and core.memoize amongst others. I’ve left this issue open with comments for input from Clojure/core and opened a new issue against core.typed instead.

Sean Corfield

unread,
Jan 12, 2015, 9:31:17 PM1/12/15
to clo...@googlegroups.com
Oh, and all our apps now pass / work correctly on 1.7.0-alpha5 (I stripped Typed Clojure out of our code base to make it all work).

Sean

Janne Lemmetti

unread,
Jan 14, 2015, 9:29:13 AM1/14/15
to clo...@googlegroups.com
I noticed that with alpha5, I can no longer build an uberjar with {:aot :all} if I depend on [gloss "0.2.4"]:

$ lein uberjar
Compiling alpha5-test.core
java.lang.Exception: Cyclic load dependency: [ /manifold/stream ]->/manifold/stream/graph->[ /manifold/stream ]->/byte_streams->/gloss/core/formats->/gloss/data/bytes->/gloss/core/codecs->/gloss/io->/alpha5_test/core, compiling:(manifold/stream/graph.clj:1:1)
at clojure.core$throw_if.doInvoke(core.clj:5612)
at clojure.lang.RestFn.invoke(RestFn.java:442)
at clojure.core$check_cyclic_dependency.invoke(core.clj:5763)
at clojure.core$load.doInvoke(core.clj:5860)
...

Minimal project to reproduce with:

project.clj:

(defproject alpha5-test "0.1.0-SNAPSHOT"
:dependencies [[org.clojure/clojure "1.7.0-alpha5"] [gloss "0.2.4"]]
:profiles {:uberjar {:aot :all}})

src/alpha5_test/core.clj:

(ns alpha5-test.core (:require [gloss.io :refer [decode-all]]))


Br, Janne

Andy Fingerhut

unread,
Jan 14, 2015, 10:08:08 AM1/14/15
to clo...@googlegroups.com
I can reproduce this.  I have also determined that the change in behavior is due to the patch applied for ticket CLJ-1544 [1] [2].  There doesn't appear to be an actual dependency cycle in the manifold lib, but I've only looked at this for a few mins.

Andy


--

Nicola Mometto

unread,
Jan 14, 2015, 10:14:02 AM1/14/15
to clo...@googlegroups.com

There actually is a dependency cycle in manifold, it's just not in the
ns macro:

manifold.stream.graph depends on manifold.graph here:
https://github.com/ztellman/manifold/blob/master/src/manifold/stream/graph.clj#L5
maniphold.stream depends on manifold.stream.graph here:
https://github.com/ztellman/manifold/blob/master/src/manifold/stream.clj#L410

Whether or not this will be considered a regression or not, it's not up
to me to decide. I suggest opening a ticket in JIRA to discuss this
further.

Nicola
--

Andy Fingerhut

unread,
Jan 14, 2015, 4:09:46 PM1/14/15
to clo...@googlegroups.com
Nicola, who is patient enough to remind me of things we have talked about already before.  Now I recall running across this weirdness in the Manifold library before, since it caused Eastwood to fail when run on Manifold.

Created a Clojure ticket to record anything discovered about this issue, or any decisions made about it going forward:


Andy

Colin Fleming

unread,
Jan 15, 2015, 2:53:39 AM1/15/15
to clo...@googlegroups.com
I discovered this problem with Cursive too. Stephen Gilardi had a great analysis when I asked about it here: https://groups.google.com/d/topic/clojure/wrVFuCjf0_Y/discussion. tl;dr - Clojure only produces an error on dependency cycles when the dependencies appear in the ns form, or at least did until now.

Steve Miner

unread,
Jan 15, 2015, 10:42:23 AM1/15/15
to clo...@googlegroups.com
Alpha5 works for me.

I noticed that the doc-string for *unchecked-math* doesn't mention the :warn-on-boxed behavior.

Suggestion: "While bound to true, compilations of +, -, *, inc, dec and the coercions will be done without overflow checks. While bound to :warn-on-boxed, a warning will be emitted when compilation uses boxed math. Default: false."


Alex Miller

unread,
Jan 16, 2015, 4:07:26 PM1/16/15
to clo...@googlegroups.com, cloju...@googlegroups.com
Just to follow up on this, Tom reported to me on Twitter that the box giving slow results was bad and the regression was not repeatable on another box.

Alex

Sean Corfield

unread,
Jan 20, 2015, 3:57:49 PM1/20/15
to cloju...@googlegroups.com, clo...@googlegroups.com
Just FYI, we took 1.7.0-alpha5 into production today. We’ll let you know if we run into any issues. Other than tripping over the AOT/JIT thing with core.typed, it’s been smooth sailing on dev/QA…

…and we actually have a transducer in production now!

Sean

Alan Moore

unread,
Jan 20, 2015, 8:24:01 PM1/20/15
to clo...@googlegroups.com
How is the feature expressions feature progressing? I haven't heard much about it recently - we are looking at converting a CLJS project from using crossovers to feature expressions...

Alan

On Sunday, January 11, 2015 at 6:00:52 PM UTC-8, Alex Miller wrote:
No, we do not work from planned release dates. When it's done, we ship it.

The current plan is to do at least one more alpha with a version of feature expressions that is a bit slimmer than the current available patches to make that available for people to experiment (presumably along with tools.reader and Clojurescript releases).

Depending on feedback from that we will move to beta (aka "feature complete"). I expect most if not all outstanding 1.7 tickets to be done by then. At that point, it's just grinding things down till release.

Alex Miller

unread,
Jan 21, 2015, 9:07:13 AM1/21/15
to clo...@googlegroups.com
I am actively working on an updated set of patches, hopefully for inclusion in the next alpha.

Alex

Alan Moore

unread,
Jan 21, 2015, 6:58:24 PM1/21/15
to clo...@googlegroups.com
Sweet - thanks for the reply. I hope I didn't sound impatient... I'm very grateful for your hard work on it. I'd offer to help but I'm sure it is beyond me and my crazy-mad Clojure skillz(tm). I think I'll leave the hard stuff to the real experts :-)

Alan

Adam Clements

unread,
Jan 22, 2015, 12:49:50 PM1/22/15
to clo...@googlegroups.com
I think I am seeing static initialisers being run at AOT time when the class is used as a type hint tag. This isn't a regression from previous versions of clojure, but with the forNameNonLoading changes that have gone in recently I was under the impression that this shouldn't be a problem any more.

My specific case has a static initialiser which loads a native library (and I don't have the appropriate binary architecture for the machine doing the compilation).

The function definition 
(defn some-function [^com.my_class.ExampleWhichLoadsNative x] ...)

fails at AOT compile time with the (abridged) stack trace containing:
...
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6715)
at clojure.lang.Compiler.analyze(Compiler.java:6499)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6696)
at clojure.lang.Compiler.analyze(Compiler.java:6499)
at clojure.lang.Compiler.access$200(Compiler.java:38)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:560)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6708)
at clojure.lang.Compiler.analyze(Compiler.java:6499)
at clojure.lang.Compiler.analyze(Compiler.java:6460)
at clojure.lang.Compiler.compile1(Compiler.java:7285)
at clojure.lang.Compiler.compile(Compiler.java:7356)
at clojure.lang.RT.compile(RT.java:406)
...
Caused by:
...
        <my class clinit>
        at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:274)
at clojure.lang.RT.classForName(RT.java:2127)
at clojure.lang.RT.classForName(RT.java:2136)
at clojure.lang.Compiler$HostExpr.maybeClass(Compiler.java:1000)
at clojure.lang.Compiler$HostExpr.tagToClass(Compiler.java:1092)
at clojure.lang.Compiler.tagClass(Compiler.java:8187)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5218)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3900)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6706)
...

--

Adam Clements

unread,
Jan 22, 2015, 1:24:10 PM1/22/15
to clo...@googlegroups.com
Just to follow up, doing the obvious (though perhaps naïve) fix of changing forName to forNameNonLoading in the referenced maybeClass does seem to fix the issue and I can now AOT compile my application without needing the binaries for this machine. I don't know whether this change would have any other repercussions though.

clojure+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

Aaron Cohen

unread,
Jan 22, 2015, 2:12:39 PM1/22/15
to clo...@googlegroups.com
This is a different though related problem to http://dev.clojure.org/jira/browse/CLJ-1315

That problem was trying to solve "require" un-necessarily importing classes, your example is a type hint with a similar issue.

I do think you're correct, it looks like a reasonable change, but it would require some investigative work to see if it breaks anything.

--Aaron



For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

Jozef Wagner

unread,
Jan 26, 2015, 1:49:35 PM1/26/15
to clo...@googlegroups.com, cloju...@googlegroups.com
With CLJ-979 applied, lein may crash when doing :aot :all. This is caused when lein forces recompilation of already compiled classes. Not sure whether this should be considered a lein of clojure bug though.

See https://github.com/wagjo/aotbug for contrived example.

Jozef


On Saturday, January 10, 2015 at 4:37:04 PM UTC+1, Alex Miller wrote:
Clojure 1.7.0-alpha5 is now available.

Nicola Mometto

unread,
Jan 29, 2015, 1:25:01 PM1/29/15
to cloju...@googlegroups.com, clo...@googlegroups.com

Jozef, I looked into this and opened a ticket with a proposed patch to
fix this issue: http://dev.clojure.org/jira/browse/CLJ-1650
--

Jozef Wagner

unread,
Jan 29, 2015, 1:37:14 PM1/29/15
to clo...@googlegroups.com
Thank you very much Nicola!

Colin Fleming

unread,
Feb 17, 2015, 11:37:51 PM2/17/15
to clo...@googlegroups.com
I added a comment in CLJ-979, I believe I have a case which is broken by the change in delegation order, if I'm correct in my understanding of what the CLJ-979 change is actually doing.
Reply all
Reply to author
Forward
0 new messages