RC 16: Last chance to test against Clojure 1.5 before it ships

[Stuart Halloway]

If you care about Clojure 1.5 compatibility for your codebase, please test it against RC 16 as soon as possible.

You can get the source and build it yourself from [1], or wait for Maven Central [2] to pick up the CI build, which usually takes a few hours.

Thanks!

Stu

[1] https://github.com/clojure/clojure

[2] http://bit.ly/WEnjAi

[Tassilo Horn]

Stuart Halloway <stuart....@gmail.com> writes:

> If you care about Clojure 1.5 compatibility for your codebase, please
> test it against RC 16 as soon as possible.

My code using tons of protocols, some deftypes, and the new reducers
here and there still compiles, runs, and all tests pass. That said,
I've always used the most bleeding-edge 1.5 alphas, betas, RCs, so that
actually means only that there's no breakage to features I use in a very
recent commit while there might still be compatibitily issues when
coming from 1.4.

Bye,
Tassilo

[Andy Fingerhut]

Eric:

1 was a result of a change made by choice:

    https://github.com/clojure/clojure/blob/master/changes.md#210-set-and-map-constructor-functions-allow-duplicates

The ticket linked there has a link to a design page on it, which in turn has a link to an earlier discussion thread on the Clojure group about it.

2. I'm not sure about this, but I think this was a change for ticket CLJ-157:

    http://dev.clojure.org/jira/browse/CLJ-157

Given your description of it, I found it a bit funny that I categorized that one under "Improved error messages" in the changes file.  Probably time to file a new ticket related to improving the issues you point out.

Andy

On Feb 15, 2013, at 8:12 PM, Eric Arthen wrote:

Stu,

I changed my code from 1.4.0 to 1.5.0 RC 16 (about 70 source files) and ran into two small things.They are probably not bugs but they confused me.

I have not been following 1.5 development in detail, so these are probably not at all new. So far everything else seems ok, which is great.

1. array-map used to throw an illegal argument exception on duplicate keys, but now it succeeds and uses the last value in the array. This change seems okay, I just had a case that used the old behavior and it took a bit to realize what happened.

  

(array-map :a 1 :a 2 :b 0 :a 3 :b 1)

{:a 3, :b 1}

2. The defn macro used to be permissive when it had nothing but the function name, but now it complains. That seems like an improvement, but the problem is that it gives no information of what source file or line the problem is at so it took me a while to find it.

I was defining a mocked out function, so I just had this: (defn x)

That was okay in 1.4.0, but now it returns the error below. I just replaced it by (def x), so it was easy to fix once I saw it.

It seems to me macro errors never tell about where in the source they happen, so I assume that must be very hard to fix and that we're still stuck with this in 1.5.0. I must admit that trying to debug macro issues (esp. in the 'ns' macro) are almost the only time I've found myself cursing at clojure itself. Most of the time it is a joy.

Exception in thread "main" java.lang.IllegalArgumentException: Parameter declaration missing

at clojure.core$assert_valid_fdecl.invoke(core.clj:6716)

at clojure.core$sigs.invoke(core.clj:223)

at clojure.core$defn.doInvoke(core.clj:301)

at clojure.lang.RestFn.invoke(RestFn.java:445)

at clojure.lang.Var.invoke(Var.java:423)

at clojure.lang.AFn.applyToHelper(AFn.java:167)

at clojure.lang.Var.applyTo(Var.java:532)

at clojure.lang.Compiler.macroexpand1(Compiler.java:6468)

at clojure.lang.Compiler.macroexpand(Compiler.java:6529)

at clojure.lang.Compiler.eval(Compiler.java:6603)

at clojure.lang.Compiler.load(Compiler.java:7064)

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__5028.invoke(core.clj:5530)

at clojure.core$load.doInvoke(core.clj:5529)

at clojure.lang.RestFn.invoke(RestFn.java:408)

at clojure.core$load_one.invoke(core.clj:5336)

at clojure.core$load_lib$fn__4977.invoke(core.clj:5375)

at clojure.core$load_lib.doInvoke(core.clj:5374)

at clojure.lang.RestFn.applyTo(RestFn.java:142)

at clojure.core$apply.invoke(core.clj:619)

at clojure.core$load_libs.doInvoke(core.clj:5413)

at clojure.lang.RestFn.applyTo(RestFn.java:137)

at clojure.core$apply.invoke(core.clj:619)

at clojure.core$require.doInvoke(core.clj:5496)

at clojure.lang.RestFn.invoke(RestFn.java:421)

at midje.repl$load_facts$fn__5948.invoke(repl.clj:205) <-- yes this was in a midje test case, but it does not tell where in my code it is

at midje.repl$load_facts.doInvoke(repl.clj:191)

at clojure.lang.RestFn.invoke(RestFn.java:397)

at user$eval6011.invoke(NO_SOURCE_FILE:1)

at clojure.lang.Compiler.eval(Compiler.java:6619)

at clojure.lang.Compiler.eval(Compiler.java:6609)

at clojure.lang.Compiler.eval(Compiler.java:6582)

at clojure.core$eval.invoke(core.clj:2852)

at clojure.main$eval_opt.invoke(main.clj:302)

at clojure.main$initialize.invoke(main.clj:321)

at clojure.main$null_opt.invoke(main.clj:356)

at clojure.main$main$fn__6656.invoke(main.clj:434)

at clojure.main$main.doInvoke(main.clj:431)

at clojure.lang.RestFn.invoke(RestFn.java:421)

at clojure.lang.Var.invoke(Var.java:419)

at clojure.lang.AFn.applyToHelper(AFn.java:163)

at clojure.lang.Var.applyTo(Var.java:532)

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

Subprocess failed

-Eric

--
--
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/groups/opt_out.
 
 

[vemv]

Couldn't clojure.lang.ExceptionInfo be imported by default? That'd surely help making ExceptionInfo the idiomatic exception to be thrown.

[Baishampayan Ghose]

You can create an ExceptionInfo instance easily by using the core fn
`ex-info`. So something like ... (throw (ex-info {:foo "bar"})) works
fine. ~BG

> --
> --
> 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/groups/opt_out.
>
>

--
Baishampayan Ghose
b.ghose at gmail.com

[vemv]

ah nice, never realised that, thank you. still it'd be somewhat more consistent to import ExceptionInfo:

(throw (Exception.))
(throw (IndexOutOfBoundsException.))
(throw (IllegalArgumentException.))
;; ...there's quite clearly a pattern here, which many are accustomed to
(throw (ex-info "" {})) ;; ex-info (however more pleasant is it to type) breaks that pattern

OTOH, I see ex-info is "alpha, subject to change" so relying on Java constructors may not be the right choice right now.

[Dave Sann]

timely comment.

you can create and throw it but catching it requires the imported type. (not withstanding catching the generic Exception on the JVM).

see the link for suggestion/discussion on making this more "uniform" for clj and cljs:

https://groups.google.com/d/topic/clojurescript/A3wH_Hm3OmQ/discussion

Dave

[Dave Sann]

I don't expect this to go into 1.5.

But the point raised by vemv is a good one.

Clojurescript makes ExceptionInfo available by default. If this were also the case in clojure - it would help with portable code. Specifically catching ExceptionInfo. (longer comments on the thread referenced previously).

Dave

[vemv]

Your additional points make more evident the need to put some final effort on the design of ExceptionInfo - leaving it "alpha" would be pretty unfortunate.

[Tim McCormack]

On Wednesday, February 13, 2013 10:33:42 PM UTC-5, Stuart Halloway wrote:

If you care about Clojure 1.5 compatibility for your codebase, please test it against RC 16 as soon as possible.

(I mistakenly posted this already to the *read-eval* thread, but it really belongs here... apologies for the double-post.)

The command-line eval feature is broken under -Dclojure.read.eval=unknown in beta13 and RC16 (not sure which is newer):

$ java -Dclojure.read.eval=unknown -jar ~/.m2/repository/org/clojure/clojure/1.5.0-RC16/clojure-1.5.0-RC16.jar -e "(+ 1 2)"
Exception in thread "main" java.lang.RuntimeException: Reading disallowed - *read-eval* bound to :unknown

 - timmc

 

[Sean Corfield]

This raises a question I've wondered about for a while: I believe
Clojure makes java.lang.* available by default but not clojure.lang.*
- what is the logic behind that? (I'm not questioning whether it's
right or wrong, just curious as to why...)

Thanx,
Sean

> "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?hl=en.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

[Mikera]

This is sensible because:

java.lang.* is important for interop (classes like Object,String etc.) and is pretty much guaranteed to retain backwards compatibility for the foreseeable future. It's pretty much the JVM equivalent of the clojure.core namespace.

clojure.lang.* has a lot of classes / interfaces that should really be considered as implementation details. Hence we shouldn't encourage people to rely on them in regular Clojure code.