[ANN] Clojure 1.8.0-beta1

[Alex Miller]

Clojure 1.8.0-beta1 is now available.

Try it via

• Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-beta1
  
• Leiningen: [org.clojure/clojure "1.8.0-beta1"]

Below is a list of the other changes included in beta1. See the full change log here: https://github.com/clojure/clojure/blob/master/changes.md.

• CLJ-1456 Compiler now errors if too few or too many arguments to throw
  
• CLJ-1282 quote now throws if passed more or less than one arg
  
• CLJ-1210 Improved error message for (clojure.java.io/reader nil)
  
• CLJ-1414 sort and sort-by now indicate sort is stable in docstring
  
• CLJ-1765 areduce performance improvements
  
• CLJ-1724 Remove unnecessary call to seq() in LazySeq.hashCode()
  
• CLJ-1295 Improved array-map dissoc performance
  
• CLJ-1277 Speed up printing of time instants with type hints
  
• CLJ-1259 Speed up pprint and cl-format with type hints
  
• CLJ-668 Improve slurp performance by using StringWriter and jio/copy
  
• CLJ-1810 ATransientMap now marked public
  
• CLJ-1653 str of an empty list should be "()"
  
• CLJ-1567 Removed unused local in condp implementation
  
• CLJ-1351 Unused swapThunk method was being emitted for fns with keyword callsites
  
• CLJ-1329 Removed unused local in PersistentVector.cons()
  
• CLJ-1380 3-arg ExceptionInfo constructor permitted nil data
  
• CLJ-1226 set! of a deftype field using field-access syntax caused ClassCastException
  

[Lars Rune Nøstdal]

Just a heads up that http://dev.clojure.org/jira/browse/CLJ-1809 is still a problem. A lot of Clojure code fails to compile now. I hope this will be fixed before 1.8 final is out.

[Gary Trakhman]

Since upgrading our maven-based project, I'm seeing a new warning: Reflection warning, clojure/pprint/pretty_writer.clj:419:12 - call to method write can't be resolved (target class is unknown).

Once I connect with cider, I check *warn-on-reflection* and it is false.

--
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.

[Alex Miller]

CLJ-1809 will be addressed before 1.8 final.

[Alex Miller]

The reflection warning is from the pprint ticket - code changed from when the patch was created and applied. We will get that in the next beta.

[Mike Rodriguez]

Just a heads up, I tried upliftign to Clojure 1.8.0-beta1 today and had a failure that is originating from potemkin "0.4.1".  I think the issue may be in its dependent project riddley "0.1.10".

I logged an issue there at https://github.com/ztellman/riddley/issues/18.

I haven't tracked down the cause of this problem right now.  I figure this may affect more people though, since I often read of people using potemkin in their projects.  These issues didn't seem to exists when I ran against some older potemkin versions (e.g. "0.3.2" was my test case).

[Marc O'Morain]

FYI - Trying to upgrade CircleCI I get a syntax error in clj-ssh (passing too many argument to throw):

https://github.com/hugoduncan/clj-ssh/issues/39

I've logged the issue with them.

--

[Marc O'Morain]

I just ran the CircleCI code-base under 1.8 beta 1 to see if there were any gains in compile time (which is in the region of 90 seconds for our main app). The clj-ssh issue was the only third-party lib that didn't work.

Here is our compile time on Clojure 1.7 and 1.8:

Clojure 1.7:

real 1m30.622s user 1m32.535s sys 0m4.182s

real 1m33.238s user 1m36.139s sys 0m4.381s

Clojure 1.8 beta 1:

real 1m31.001s user 1m41.139s sys 0m4.432s

real 1m34.107s user 1m42.723s sys 0m4.742s

Marc

--

[Ghadi Shayban]

Marc,

Any changes up or down in run-time performance (post-startup)?

[Marc O'Morain]

I don't have a good way to measure runtime like that I'm afraid.

[Alex Miller]

This is a bug in the original code that is being caught by the stricter check on throws (at https://github.com/hugoduncan/clj-ssh/blob/develop/src/clj_ssh/ssh.clj#L301) - name there should be the final arg to ex-info, not to throw.

So I'm going to call that a good regression. :)

[Marc O'Morain]

Agreed :)

[Mike Rodriguez]

Someone else looked at the issue on https://github.com/ztellman/riddley/issues/18

This issue makes the current version of riddley, and therefore potemkin, not work on Clojure 1.8 beta1

There is a pull request to fix it at https://github.com/ztellman/riddley/pull/19

However I am wondering if it is going to affect more places. The problem is that in Clojuee 1.8 APersistentVector now implements IMapEntry (therefore j.u.Map$Entry as well), but it doesn't implement the key or val methods.
What is the reason for that change and/or is this a desired side effect of the change?

[Martin Raison]

I migrated a significant Clojure codebase to 1.8.0-beta1, and I had to solve issues caused by this IMapEntry/APersistentVector change in several places (including the pull request mentioned above). Also wondering about the rationale behind this. It's not a huge deal, but it does make some code ambiguous (if you have a function that potentially accepts any object, including vectors of 2 elements, and you want to do something specific for instances of IMapEntry).

I didn't have any other problems apart from this - and I was actually migrating from clojure 1.6.0. Great job!

[Alex Miller]

It would be great to have a ticket and some examples beyond the riddley one where this was an issue.

Thanks for trying the beta and giving feedback!

[Alex Miller]

[Pierre-Yves Ritschard]

Hi Mike,

The code at here seems to contradict you:
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentVector.java#L448-L460,
as does "(key [:a :b])" in the REPL.

The only limitation is that vectors need to be of size two to act as
IMapEntries (otherwise an IllegalOperation exception is thrown).

The change seems logical and allows key & val to be used more generically.

You're right that will fail on code that checks for (instance? IMapEntry).

A good alternative - paging Alex Miller - could be for (empty) on a
MapEntry to return an empty PersistentVector instead of nil, which would
ensure that calls to (into (empty <map-entry>) (map f <map-entry>))
would return a valid map entry (instead of a collection).

I'm happy to create a ticket for this use-case if deemed valid.

Cheers,
- pyr

[Alex Miller]

On Friday, October 16, 2015 at 3:32:43 AM UTC-5, Pierre-Yves Ritschard wrote:

Hi Mike,

The code at here seems to contradict you:
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentVector.java#L448-L460,
as does "(key [:a :b])" in the REPL.

The only limitation is that vectors need to be of size two to act as
IMapEntries (otherwise an IllegalOperation exception is thrown).

The change seems logical and allows key & val to be used more generically.

You're right that will fail on code that checks for (instance? IMapEntry).

APersistentVector implements IMapEntry, so this doesn't seem correct.

 

A good alternative - paging Alex Miller - could be for (empty) on a
MapEntry to return an empty PersistentVector instead of nil, which would
ensure that calls to (into (empty <map-entry>) (map f <map-entry>))
would return a valid map entry (instead of a collection).

It does not make sense to me for empty on a MapEntry to do what you ask (for similar reasons why empty on a record is not allowed).

[Mike Rodriguez]

Yes, I am in support of the fact that size=2 vectors now can now have `key` and `val` called on them.  This not working prior to Clojure 1.8 was occasionally the reason why I just used `first` and `second` instead of `key` and `val` before since some function transformations could result in size=2 vectors rather than true map entries.

I think that supporting `empty` on MapEntry is weird, as Alex said above.  It does sound the same as the record case. 

The only frustration I have with this change is that not all APersistentVectors really act as a map entry.  Only those of size=2 do.  So the interface becomes misleading if you try to use it to figure out from a generic standpoint, what things are map entries and what things aren't.  The ambiguity is that all vectors look like map entries.  I guess you could do the 

(instance? IMapEntry x) check along with (== 2 (count x)) for the vector case...

[Alex Miller]

Perhaps having a "map-entry?" predicate that was smarter would be helpful.

[Mike Rodriguez]

Yes a `map-entry?` predicate was sort of the direction I was leaning in that would help avoid issues like this around these changes.

[Alex Miller]

The map-entry? predicate was just committed to master and will be in the next build.

[Alex Miller]

The fix for this was applied to master today and will be in the next build.

[Alex Miller]

CLJ-1809 was applied today and will be in the next build.

[Mike Rodriguez]

Nice.  Thanks for pushing that through a Jira and into 1.8 so quickly!