[ANN] Clojure 1.7.0-beta2

[Alex Miller]

Clojure 1.7.0-beta2 is now available.

Try it via

- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta2/

- Leiningen: [org.clojure/clojure "1.7.0-beta2"]

Regression fixes since 1.7.0-beta1:

1) CLJ-1711 - structmap iterator broken

2) CLJ-1709 - range wrong for step != 1

3) CLJ-1713 - range chunks are not serializable

4) CLJ-1698 - fix reader conditional bugs

Additional enhancements to new features since 1.7.0-beta1:

1) CLJ-1703 - Pretty print #error and new public function Throwable->map

2) CLJ-1700 - Reader conditionals now allowed in the REPL

3) CLJ-1699 - Allow data_readers.cljc as well as data_readers.clj

 

For a full list of changes since 1.6.0, see:

https://github.com/clojure/clojure/blob/master/changes.md

Please give it a try and let us know if things are working (or not)!

- Alex

[David McNeil]

I did a real quick test on one of our projects. I had to upgrade to the latest compojure (seems the old version used a version of instaparse that wouldn't compile) but after that it seemed to work and was noticably faster.

-David

[Andy Fingerhut]

Testing done on 1.7.0-beta2 and results:

I tested the latest released version of Eastwood, 0.2.1, on about 80 projects that I regularly test Eastwood on, comparing the results between Clojure 1.6.0 and Clojure 1.7.0-beta2.

Total run time reduced from 42.7 minutes with Clojure 1.6.0 down to 35.8 minutes with Clojure 1.7.0-beta2, a reduction of about 16%.  Cool.

Now that the Instaparse incompatibility with Clojure 1.7.0-alpha6 and later has been fixed in its version 1.3.6, and other libraries depending upon Instaparse have had their versions updated, I did not find any differences in the Eastwood results.

Ran 'mvn clean ; mvn test' on a few OS/JDK combos that are not tested as often.  Reason: there have been (or still are) build or test failures with some of them.

Windows 7 Enterprise SP1 + Oracle JDK 1.7.0_72: ok

Ubuntu 14.04.2 LTS + IBM JDK 1.7.0: ok, as long as failing tests mentioned in http://dev.clojure.org/jira/browse/CLJ-1678 are commented out

Ubuntu 14.04.2 LTS + IBM JDK 1.8.0: same as for IBM JDK 1.7.0

No problems found there.  I ran 'mvn clean ; mvn test' in a loop to look for any occasional failures in pseudo-random tests.  No failures found since the fix for this ticket: http://dev.clojure.org/jira/browse/CLJ-1691

Mac OS X 10.10.3 + Oracle JDK 1.8.0_11: ok 1395 times

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.

[Nicola Mometto]

The type-hint on init-state is wrong.

It has to be either

(defn {:tag 'longs} init-state [] (long-array 1))
or (preferred)
(defn init-state ^longs [] (long-array 1))


shlomi...@gmail.com writes:

> I tried playing around with the new primitive type hints and got the
> following weird behavior on [org.clojure/clojure "1.7.0-beta2"]:
>
> (defn ^longs init-state [] (long-array 1))
>
> (defn ^long store-state [^longs c ^long a] (aset c 0 a))
>
> running the following line resulted in an exception:
>
> (let [x (init-state)]
> (store-state x 5))
>
> 1. Caused by java.lang.VerifyError
> (class: clojure_7/core$eval13270, method: invoke signature:
> ()Ljava/lang/Object;) Unable to pop operand off an empty stack
>
> Class.java: -2
> java.lang.Class/getDeclaredConstructors0
> Class.java: 2671
> java.lang.Class/privateGetDeclaredConstructors
> Class.java: 3075 java.lang.Class/getConstructor0
> Class.java: 412 java.lang.Class/newInstance
> Compiler.java: 4843 clojure.lang.Compiler$ObjExpr/eval
> Compiler.java: 6791 clojure.lang.Compiler/eval
> Compiler.java: 7237 clojure.lang.Compiler/load
> REPL: 1 reverse-index.main/eval13258
> Compiler.java: 6792 clojure.lang.Compiler/eval
> Compiler.java: 6755 clojure.lang.Compiler/eval
> core.clj: 3079 clojure.core/eval
> main.clj: 240 clojure.main/repl/read-eval-print/fn
> main.clj: 240 clojure.main/repl/read-eval-print
> main.clj: 258 clojure.main/repl/fn
> main.clj: 258 clojure.main/repl
> RestFn.java: 1523 clojure.lang.RestFn/invoke
> interruptible_eval.clj: 58
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
> AFn.java: 152 clojure.lang.AFn/applyToHelper
> AFn.java: 144 clojure.lang.AFn/applyTo
> core.clj: 628 clojure.core/apply
> core.clj: 1866 clojure.core/with-bindings*
> RestFn.java: 425 clojure.lang.RestFn/invoke
> interruptible_eval.clj: 56
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate
> interruptible_eval.clj: 188
> clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
> interruptible_eval.clj: 157
> clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
> AFn.java: 22 clojure.lang.AFn/run
> ThreadPoolExecutor.java: 1142
> java.util.concurrent.ThreadPoolExecutor/runWorker
> ThreadPoolExecutor.java: 617
> java.util.concurrent.ThreadPoolExecutor$Worker/run
> Thread.java: 745 java.lang.Thread/run
>
> while the following line worked just fine:
>
> (store-state (init-state) 5)
>
> and also this works fine:
>
> (def a (init-state))
> (store-state a 5)
>
> (aget a 0) ;; 5
>
> What do you think?

--

[Nicola Mometto]

Fluid Dynamics writes:

> That's weirdly inconsistent with e.g. (defn ^String prefix [s n]...).

It can be surprising behaviour, but it's not an inconsistency.
As per the documentation, metadata on the symbol being def'd *is*
evaluated, metadata on the argvec isn't.
Evaluating `String` produces the java.lang.String Class -- a valid tag,
evaluating `longs` produces the clojure.core/longs function -- not a
valid tag. OTOH 'longs is a valid tag that the compiler understands.

> It also doesn't negate the original bug report. That VerifyError means that
> the Clojure compiler emitted invalid bytecode, instead of either emitting
> valid bytecode or reporting a sensible error. Any way you slice it the
> compiler is buggy if it can quietly emit broken bytecode.

The reported exception is not all of what happens.
If you try to execute that code you'll see that you get two exceptions,
the first one being "java.lang.IllegalArgumentException: Unable to
resolve classname: clojure.core$longs@3f91beef" which tells you exactly
what I told you before -- clojure.core/long is not a valid type hint.

The VerifyError is thrown later and is caused by the fact that the
compiler emits partial bytecode as it gets interrupted by the
IllegalArgumentException.

Now, if you want to argue that the compiler should immediately throw an
error as soon as the wrong type hint is used rather than silently ignore
it and fail when the type-hinted form is used, I'll agree with you and
I've proposed to make the compiler stricter a number of times on the
clojure-dev ML and talked about it on IRC but I guess either it's not a
priority for the clojure/core team or they're simply not interested in
more compile-time checks.
Either way the reported issue was a user error, not a compiler bug.

--

[Andy Fingerhut]

On Fri, May 1, 2015 at 12:53 PM, Nicola Mometto <brob...@gmail.com> wrote:

It can be surprising behaviour, but it's not an inconsistency.
As per the documentation, metadata on the symbol being def'd *is*
evaluated, metadata on the argvec isn't.
Evaluating `String` produces the java.lang.String Class -- a valid tag,
evaluating `longs` produces the clojure.core/longs function -- not a
valid tag. OTOH 'longs is a valid tag that the compiler understands.

Nicola, where have you found it documented that metadata on the symbol being def'd is evaluated?

Thanks,

Andy

[Nicola Mometto]

http://clojure.org/special_forms#Special%20Forms--(def%20symbol%20init?)

"Any metadata on the symbol will be evaluated, and become metadata on
the var itself."

--

[Andy Fingerhut]

Shoot, sorry for the noise.  Found that pretty quickly once I knew where to look.

Have you also found it documented that metadata elsewhere is *not* evaluated?

Andy

--

[Nicola Mometto]

No but the fact that metadata is not evaluated on unevaluated forms
(macro args or quoted forms) is part of normal clojure evaluation
semantics so there's no need to document it.

--

[Alex Miller]

On Fri, May 1, 2015 at 2:53 PM, Nicola Mometto <brob...@gmail.com> wrote:

Now, if you want to argue that the compiler should immediately throw an
error as soon as the wrong type hint is used rather than silently ignore
it and fail when the type-hinted form is used, I'll agree with you and
I've proposed to make the compiler stricter a number of times on the
clojure-dev ML and talked about it on IRC but I guess either it's not a
priority for the clojure/core team or they're simply not interested in
more compile-time checks.

Is there a ticket?

[Nicola Mometto]

There are a number of tickets reporting errors caused by the compiler
silently ignoring invalid type hints
http://dev.clojure.org/jira/browse/CLJ-1674
http://dev.clojure.org/jira/browse/CLJ-1232

or type hints inconsistencies
http://dev.clojure.org/jira/browse/CLJ-1577
http://dev.clojure.org/jira/browse/CLJ-1533

There are no open tickets open that I'm aware of about making the
compiler stricter on :tag values.

I would open one but there's this clojure-dev thread
https://groups.google.com/forum/#!msg/clojure-dev/hRZFuaiB_50/mzKLirgZWmUJ
where I ask what should be the allowed :tag values and I got no
clarification on it -- I see no point in spending my time working on a
patch/enhancement proposal that would break contrib libraries used by
clojure itself (there's no way to make the compiler throw on e.g. (defn
^doubles foo ..) and not throw on test.generative usages) until I know
for a fact that I would not be wasting my time

--

[Brandon Bloom]

Upgrading a couple of projects to 1.7 seems to have gone quite smoothly. Thanks!

However, I've encountered some problems with new features, like .cljc files.

Please see https://groups.google.com/forum/#!topic/clojure/TrYkq1lUuZw 

Cheers,

Brandon