We have a planned upgrade at a customer site before xmas of our oldest product.
Internal work on upgrading it to 1.7 starts in august.
If I look at the Clojure upgrade track since 2009, I can't say that I am
nervous about this.
Not at all :)
We are presently building a new product and
Thanks Andy for the extra info and for logging the follow-up Jira!
It looks like the exception changes are expected and are a potential
improvement with line numbers etc.
My the main goal was just to provide constructive feedback on here of the
issues I faced investigating the upgrade of a
On Jun 4, 2015, at 2:51 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote:
Still 3 months away from production beta.
I get twitchy if we go more than two weeks between production builds — but then
it’s the web :)
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
Hi,
Have been using 1.7 since beta1 in dev and test in a new dev.
Still 3 months away from production beta.
So far no issues. Zero, nada, nil, ...
Reader conditionals are quite amazing, we started unifying backend and front
end code.
Wow... No more split brain syndrome and a huge
I've filed http://dev.clojure.org/jira/browse/CLJ-1745
In checking Mike Rodriguez's test case for reproducing the issue, I could
reproduce the behavior change in a lein repl, but the behavior appears to
be the same with a plain Clojure REPL. See the ticket for what I found,
and feel free to edit
We took RC1 to production yesterday afternoon (after being on beta1 since
mid-April). So far so good.
I think the only 1.7 new feature we’re using so far is transducers (we wrote a
transducer that takes a result set of user-to-user messages and returns a
paginated, nested result set organized
Just to provide slightly more info, that change was made because of this
ticket: http://dev.clojure.org/jira/browse/CLJ-1169
Andy
On Wed, Jun 3, 2015 at 6:34 AM, Mike Rodriguez mjr4...@gmail.com wrote:
Sorry for the delay in getting back with a response to this. I think it
is fairly clear in
Removing Java 6 would affect clojure for android projects wouldn't it?
On Wednesday, June 3, 2015 at 9:34:07 AM UTC-4, Mike Rodriguez wrote:
Sorry for the delay in getting back with a response to this. I think it
is fairly clear in the Clojure Compiler that there is an exception that
will
Sorry for the delay in getting back with a response to this. I think it is
fairly clear in the Clojure Compiler that there is an exception that will
wrap errors that occur during macroexpansion now.
Around
here
s/Ivan/Mike Rodriguez/ sorry :)
On Wednesday, June 3, 2015 at 8:19:40 PM UTC-6, Alex Miller wrote:
Thanks Ivan and Andy, I'd appreciate a ticket in jira if only to consider
this again before release.
Thank goodness Stu H screened that one so I can blame him. ;)
On Wednesday, June 3,
Thanks Ivan and Andy, I'd appreciate a ticket in jira if only to consider
this again before release.
Thank goodness Stu H screened that one so I can blame him. ;)
On Wednesday, June 3, 2015 at 4:00:35 PM UTC-6, Andy Fingerhut wrote:
Just to provide slightly more info, that change was made
This is the kind of thing that would be considered before making the
decision. But it's coming eventually.
On Wednesday, June 3, 2015 at 3:32:15 PM UTC-6, Ivan L wrote:
Removing Java 6 would affect clojure for android projects wouldn't it?
--
You received this message because you are
I think I might have found a bug that affects multimethod dispatch
when using AOT. I've created an example repository:
https://github.com/sfnelson/clj-mm-dispatch
To me it seems similar to CLJ-979, my hypothesis is that defmethods
are using the wrong classloader to get class references. Is anyone
I just tried to upgrade a clj/cljs webapp I wrote. I got an error but it
was just a transitive dependency issue with instaparse
https://github.com/Engelberg/instaparse/issues/90.
Everything works great now that I'm using up-to-date dependencies!
On Thursday, May 21, 2015 at 11:31:16 AM UTC-5,
Tassilo, the issue with flatland.ordered.set/ordered-set was that library
had never been updated to match the change in hash function that occurred
when Clojure 1.6.0 was released.
Alan Malloy released a new version of the ordered library today that fixes
that.
That has no effect on the other
Andy Fingerhut andy.finger...@gmail.com writes:
Hi Andy,
Tassilo, the issue with flatland.ordered.set/ordered-set was that
library had never been updated to match the change in hash function
that occurred when Clojure 1.6.0 was released.
Alan Malloy released a new version of the ordered
Hi Alex,
I've spotted another bug which I've already reported
http://dev.clojure.org/jira/browse/CLJ-1739. The problem is that sets
of different kinds are equal which is of course expected, e.g.,
(= #{1 2 3} (flatland.ordered.set/ordered-set 1 2 3)) ;= true
(= #{1 2 3} (java.util.HashSet.
This a dupe of CLJ-1372.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this
Alex Miller a...@puredanger.com writes:
This a dupe of CLJ-1372.
Yes, I guessed so and therefore mentioned CLJ-1372 in the description.
What about the other related issue I mentioned (CLJ-1649). Also a dupe
of CLJ-1372?
Bye,
Tassilo
--
You received this message because you are subscribed
CLJ-1649 is separate and unrelated to what you logged.
On Thu, May 28, 2015 at 7:16 AM, Tassilo Horn t...@gnu.org wrote:
Alex Miller a...@puredanger.com writes:
This a dupe of CLJ-1372.
Yes, I guessed so and therefore mentioned CLJ-1372 in the description.
What about the other related
I've logged http://dev.clojure.org/jira/browse/CLJ-1738 for this and I'll
discuss with Rich.
On Wednesday, May 27, 2015 at 2:06:19 AM UTC-5, Marshall
Bockrath-Vandegrift wrote:
On Tue, May 26, 2015 at 11:29 PM Alex Miller a...@puredanger.com wrote:
The point I was getting at is really
On Tue, May 26, 2015 at 11:29 PM Alex Miller a...@puredanger.com wrote:
The point I was getting at is really whether you should consider this to
be broken with the old behavior too.
Such APIs are tricky to use correctly from Clojure via seqs, but it is
possible to do so with the normal
Marshall, I'm unable to test at the moment, but if you replace
(java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
with
(iterator-seq (.iterator (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit)))
will it work then?
On Tuesday, May 26, 2015 at 6:25:04 PM UTC-5, Marshall
I just ported an app with significant CLJX usage (55 files) to reader
conditionals and it works perfectly!
It looks like there is a small issue related to map literal containing
comments but I am not sure if it has been reported yet.
Julien
Le jeudi 21 mai 2015 13:31:16 UTC-3, Alex Miller a
Ugh -- looks like the iterator value re-use behavior for EnumMap entrySet
was fixed post Java 1.6 (my example was under Java 1.6, which I believe
is still a Clojure-supported version of Java?). I can throw together a
synthetic example, but I think the people following this thread get what's
And to further explicate bewildering -- I mean that I only figured out
what was happening because I was explicitly testing a library against
1.7.0-RC1 and even then had to `git bisect` *Clojure* to find the offending
commit. Otherwise the resulting behavior is just that values generated via
the
Got where I could try it and instantly became very confused.
Just...take a look. http://imgur.com/4LgBdCY
On Tuesday, May 26, 2015 at 6:25:04 PM UTC-5, Marshall Bockrath-Vandegrift
wrote:
The difference is that the original behavior allowed room to transform the
mutated object into an
Problem only arises with Clojure 1.7 + Java 1.6.
/usr/lib/jvm/*java-8-oracle*/jre/bin/java -jar
~/.m2/repository/org/clojure/clojure/1.7.0-beta3/*clojure-1.7.0-beta3*.jar
Clojure 1.7.0-beta3
user= (- (map vector (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit) (range)) (into {})
Object Pooling Considered Harmful?
I'd be willing to bet more libraries than just Hadoop are using object
pooling like this, especially older libraries written before object
instantiation was as fast as it is now.
So, if you are doing a lot of Java interop with libraries using object
pooling,
I can see in Git several areas where the compiler now catches exceptions thrown
and re throws them wrapped in this exception type. I've been out of town and
unable to make a small example yet. I will soon.
--
You received this message because you are subscribed to the Google
Groups Clojure
That's not what I see with 1.7.0-RC1 (or any of the betas). I tried with
both Java 1.7.0_25 and 1.8.0-b132.
user= *clojure-version*
{:major 1, :minor 7, :incremental 0, :qualifier RC1}
user= (- (map vector (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit) (range)) (into {})
Seems like this could certainly be an issue with any interaction with Hadoop's
infamous reduce-side iterable object reuse. I will have to test further where I
may be affected similarly.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this
No, please report if so.
On Tuesday, May 26, 2015 at 8:39:32 PM UTC-5, Julien wrote:
I just ported an app with significant CLJX usage (55 files) to reader
conditionals and it works perfectly!
It looks like there is a small issue related to map literal containing
comments but I am not sure
On Tuesday, May 26, 2015 at 8:45:25 PM UTC-5, Marshall Bockrath-Vandegrift
wrote:
Ugh -- looks like the iterator value re-use behavior for EnumMap entrySet
was fixed post Java 1.6 (my example was under Java 1.6, which I believe
is still a Clojure-supported version of Java?).
Java 1.6 is
My bad I was using an older beta. With latest RC1 the issue goes away.
Julien
Le mardi 26 mai 2015 23:24:41 UTC-3, Alex Miller a écrit :
No, please report if so.
On Tuesday, May 26, 2015 at 8:39:32 PM UTC-5, Julien wrote:
I just ported an app with significant CLJX usage (55 files) to
Some of my code is broken by
commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in
1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy
since). The culprit is the switch to producing seqs over iterators as
chunked iterators. This would appear to break seq-based
In what way is it broken? Both before and after wrapped a mutable iterator into
a caching seq. The new one is different in that it chunks so reads 32 at a time
instead of 1. However combining either with other chunking sequence operations
would have the same effect which is to say that using
The difference is that the original behavior allowed room to transform the
mutated object into an object which *could* be safely cached in a
downstream seq, while the new behavior pumps the iterator through 32
mutations before user-level code has a chance to see it. Contrived example
using the
This isn't necessarily a problem, but I figured I'd put it up in case anyone
encounters similar or so that people can be aware of it coming.
We had some tests fail when I switched to the recent 1.7 versions of Clojure
(beta3 was last I checked, but it shouldn't have changed here).
The
I'm not aware of any wholesale changes with respect to compiler exceptions. Can
you give an example?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are
I've started porting a library to use Reader Conditionals - I haven't seen
any issues with it yet but my troubles are more related to the library and
re-organizing the code than to RC specifically. I'll report back when I'm
done...
Alan
On Friday, May 22, 2015 at 2:09:28 PM UTC-7, Daniel
I noticed the other day, using beta 3, working at the REPL. Some fairly
mundane errors (I no longer remember what they were) were showing up in the
stacktrace as Compiler Exceptions which completely threw off my intuition
about where to look in my code for those errors. So you're not alone,
We haven't shipped it to production yet, but I just verified that our full
test suite at Prismatic passes on RC1 after fixing a few tests that were
erroneously depending on hash ordering. Thanks everyone for all the hard
work on this release!
On Thursday, May 21, 2015 at 9:31:08 AM UTC-7,
That is interesting Jason - please file a ticket.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To
This commit [1] for CLJ-1589 changed dispatch for InternalReduce, causing a
bug similar to CLJ-1237 [2].
[1]
https://github.com/clojure/clojure/commit/1242c4878f3d4ef30535a22f6c74144637504fbe
[2] http://dev.clojure.org/jira/browse/CLJ-1237
On Friday, May 22, 2015 at 5:01:25 PM UTC-4, Jason
One of the most significant features of 1.7 are Reader Conditionals. I'm
pretty confident after all the discussion that has gone on that we have a
good design. However I haven't seen many or any libraries which have gone
through the porting process to use Reader Conditionals.
I've worked on
Just deployed to our staging environment and ran into an unexpected stack
overflow error. Here's a reduced test case:
user (- (range 1) (mapcat (fn [_] (java.util.ArrayList. (range
10 (reduce (constantly nil)))
java.lang.StackOverflowError:
RT.java:509 clojure.lang.RT.seq
Thanks for the context.
It looks like this is actually the same as CLJ-1237, the scope of the issue
is just broader now with that commit. I left a comment there rather than
creating a new ticket.
On Friday, May 22, 2015 at 3:02:02 PM UTC-7, Ghadi Shayban wrote:
This commit [1] for
Daniel, I have seen a number of reports from people successfully porting to use
reader conditionals. A few issues have been reported and fixed. This rc period
is when people should try it and report what they see.
--
You received this message because you are subscribed to the Google
Groups
I believe this issue has been reported in this ticket:
http://dev.clojure.org/jira/browse/CLJ-1093
Currently it is not planned to be fixed in Clojure 1.7.0. Maybe a later
release will fix it.
Andy
On Thu, May 21, 2015 at 11:24 AM, Sergey Didenko sergey.dide...@gmail.com
wrote:
As I mentioned
As I mentioned in another thread, how would you type hint an empty vector?
(set! *warn-on-reflection* true)
(java.util.ArrayList. []);Reflection warning
(java.util.ArrayList. ^java.util.Collection []) ;Reflection warning
At the same time:
(java.util.ArrayList. [a]) ;OK
Thanks Andy. Throwable-map should have a docstring.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
Alex, doing a quick sweep of new public Vars in 1.7.0-RC1 that were not in
Clojure 1.6.0 (complete list of all 21 below), I noticed that the following
two do not have any doc strings. Intentional, or oversight?
*suppress-read*
Throwable-map
Andy
*suppress-read*
-Eduction
Throwable-map
cat
That may not be the right ticket. Nicola Mometto may have the number
memorized, if there is one :-)
Here is a workaround that avoids the reflection warning:
(let [^java.util.Collection x []]
(java.util.ArrayList. x))
Andy
On Thu, May 21, 2015 at 11:37 AM, Andy Fingerhut
Clojure 1.7.0-RC1 is now available.
Try it via
- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/
- Leiningen: [org.clojure/clojure 1.7.0-RC1]
The only change since 1.7.0-beta3 is CLJ-1706, which makes reader
conditional splicing an error at the top level (previously it
55 matches
Mail list logo
