Re: [ANN] Clojure 1.7.0-RC1 now available

[Luc Prefontaine]

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 integrating 1.7 made sense. We 
already reused some common internal components w/o any glitches.

25 years ago I was used to smooth upgrades working on VMS.

I did not see that happening many times since then.

And we run critical services 24/7 on  premises, not in a fully controlled 
off-site environment. Our up times are insane.

Yahoo !
Luc

> On Jun 4, 2015, at 2:51 PM, Luc Prefontaine  
> 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/
> 
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
> 
> 
> 
> -- 
> 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 group, send email to
> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
--
Luc Prefontaine sent by ibisMail!

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Mike Rodriguez]

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 fairly large code base  from 
Clojure 1.6 to 1.7. 

I appreciate all the feedback from everyone. 

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Sean Corfield]

On Jun 4, 2015, at 2:51 PM, Luc Prefontaine  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/

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



-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Luc Prefontaine]

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 simplification of front end/back 
end code.
That's a huge relief on my nervous system :)

For the first time in many years I enjoy working on a web front end... finally.

Thank you all,

Luc P.

On Thu, 21 May 2015 11:30:47 -0500
Alex Miller  wrote:

> 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 would
> silently drop all but the first spliced element).
> 
> 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).
> The more and quicker feedback we get, the sooner we can release 1.7.0
> final!
> 
> - Alex
> 



-- 
Luc Préfontaine

SoftAddicts inc.
Québec, Canada
Mobil: +1 (514) 993-0320
Fax: +1 (514) 800-2017

Rabat, Maroc
Mobil: +1 212 6 98 00 64 47


-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Sean Corfield]

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 by conversion thread — a big 
simplification over how we’d done it before).

Sean

On May 21, 2015, at 9:30 AM, Alex Miller  wrote:
> 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 would silently drop all but 
> the first spliced element).
> 
> 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). The more 
> and quicker feedback we get, the sooner we can release 1.7.0 final!


-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Andy Fingerhut]

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 in case anyone else gets additional results that
differ from those.

Andy

On Wed, Jun 3, 2015 at 7:20 PM, Alex Miller  wrote:

> 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, 2015 at 4:00:35 PM UTC-6, Andy Fingerhut wrote:
>>>
>>> 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  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 wrap errors that occur during macroexpansion now.

 Around here
 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6627-L6649,
 the Compiler.macroexpand1() now has a try-catch for Throwable around the
 evaluation of the macro invocation.
 This was not the case in Clojure version 1.6.  See around
 https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Compiler.java#L6548-L6560
 for a reference point.

 I'm fairly sure that is what has caused this change in behavior that
 broke our expectations that the exception types our code through during
 macroexpansion would propagate all the way back to the caller.  Again, I
 think this was a bad expectation to have, but it is a little tricky.

 It is a little trickier for us to have any strong assertions on the
 type of exception that may come from a macro now.
 Compiler$CompilerException seems too dependent on the implementation.  So
 we've opted to just assert there would be a is-thrown? RuntimeException in
 these sorts of tests.  If we want to test something like an ExceptionInfo's
 data map, we now just have to write a helper to walk the stack trace until
 we find it - which would likely be a single "step" up the trace.

 A simple reproducing case:
 *clojure-version* ;= {:major 1, :minor 7, :incremental 0, :qualifier
 "RC1"}

 (defmacro demo [] (throw (ex-info "fail" {})))

 (demo) ;= CompilerException clojure.lang.ExceptionInfo: fail {},
 compiling:(form-init4053282905768384039.clj:1:1)

 vs.
 *clojure-version* ;= {:major 1, :minor 6, :incremental 0, :qualifier
 nil}

 (demo) ;= ExceptionInfo fail  clojure.core/ex-info (core.clj:4403)



 On Saturday, May 23, 2015 at 8:52:47 AM UTC-5, Alex Miller wrote:
>
> 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 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.

>>>
>>>  --
> 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 group, send email to
> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
> 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 clojure@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+unsubscr...@googlegroups.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

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, 2015 at 4:00:35 PM UTC-6, Andy Fingerhut wrote:
>>
>> 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  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 wrap errors that occur during macroexpansion now.
>>>
>>> Around here 
>>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6627-L6649,
>>>  
>>> the Compiler.macroexpand1() now has a try-catch for Throwable around the 
>>> evaluation of the macro invocation.
>>> This was not the case in Clojure version 1.6.  See around 
>>> https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Compiler.java#L6548-L6560
>>>  
>>> for a reference point.
>>>
>>> I'm fairly sure that is what has caused this change in behavior that 
>>> broke our expectations that the exception types our code through during 
>>> macroexpansion would propagate all the way back to the caller.  Again, I 
>>> think this was a bad expectation to have, but it is a little tricky.
>>>
>>> It is a little trickier for us to have any strong assertions on the type 
>>> of exception that may come from a macro now.  Compiler$CompilerException 
>>> seems too dependent on the implementation.  So we've opted to just assert 
>>> there would be a is-thrown? RuntimeException in these sorts of tests.  If 
>>> we want to test something like an ExceptionInfo's data map, we now just 
>>> have to write a helper to walk the stack trace until we find it - which 
>>> would likely be a single "step" up the trace.
>>>
>>> A simple reproducing case:
>>> *clojure-version* ;= {:major 1, :minor 7, :incremental 0, :qualifier 
>>> "RC1"}
>>>
>>> (defmacro demo [] (throw (ex-info "fail" {})))
>>>
>>> (demo) ;= CompilerException clojure.lang.ExceptionInfo: fail {}, 
>>> compiling:(form-init4053282905768384039.clj:1:1) 
>>>
>>> vs.
>>> *clojure-version* ;= {:major 1, :minor 6, :incremental 0, :qualifier nil}
>>>
>>> (demo) ;= ExceptionInfo fail  clojure.core/ex-info (core.clj:4403)
>>>
>>>
>>>
>>> On Saturday, May 23, 2015 at 8:52:47 AM UTC-5, Alex Miller wrote:

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

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

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 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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

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 because of this 
> ticket: http://dev.clojure.org/jira/browse/CLJ-1169
>
> Andy
>
> On Wed, Jun 3, 2015 at 6:34 AM, 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 wrap errors that occur during macroexpansion now.
>>
>> Around here 
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6627-L6649,
>>  
>> the Compiler.macroexpand1() now has a try-catch for Throwable around the 
>> evaluation of the macro invocation.
>> This was not the case in Clojure version 1.6.  See around 
>> https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Compiler.java#L6548-L6560
>>  
>> for a reference point.
>>
>> I'm fairly sure that is what has caused this change in behavior that 
>> broke our expectations that the exception types our code through during 
>> macroexpansion would propagate all the way back to the caller.  Again, I 
>> think this was a bad expectation to have, but it is a little tricky.
>>
>> It is a little trickier for us to have any strong assertions on the type 
>> of exception that may come from a macro now.  Compiler$CompilerException 
>> seems too dependent on the implementation.  So we've opted to just assert 
>> there would be a is-thrown? RuntimeException in these sorts of tests.  If 
>> we want to test something like an ExceptionInfo's data map, we now just 
>> have to write a helper to walk the stack trace until we find it - which 
>> would likely be a single "step" up the trace.
>>
>> A simple reproducing case:
>> *clojure-version* ;= {:major 1, :minor 7, :incremental 0, :qualifier 
>> "RC1"}
>>
>> (defmacro demo [] (throw (ex-info "fail" {})))
>>
>> (demo) ;= CompilerException clojure.lang.ExceptionInfo: fail {}, 
>> compiling:(form-init4053282905768384039.clj:1:1) 
>>
>> vs.
>> *clojure-version* ;= {:major 1, :minor 6, :incremental 0, :qualifier nil}
>>
>> (demo) ;= ExceptionInfo fail  clojure.core/ex-info (core.clj:4403)
>>
>>
>>
>> On Saturday, May 23, 2015 at 8:52:47 AM UTC-5, Alex Miller wrote:
>>>
>>> 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 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.
>>
>
>

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Andy Fingerhut]

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  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 wrap errors that occur during macroexpansion now.
>
> Around here
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6627-L6649,
> the Compiler.macroexpand1() now has a try-catch for Throwable around the
> evaluation of the macro invocation.
> This was not the case in Clojure version 1.6.  See around
> https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Compiler.java#L6548-L6560
> for a reference point.
>
> I'm fairly sure that is what has caused this change in behavior that broke
> our expectations that the exception types our code through during
> macroexpansion would propagate all the way back to the caller.  Again, I
> think this was a bad expectation to have, but it is a little tricky.
>
> It is a little trickier for us to have any strong assertions on the type
> of exception that may come from a macro now.  Compiler$CompilerException
> seems too dependent on the implementation.  So we've opted to just assert
> there would be a is-thrown? RuntimeException in these sorts of tests.  If
> we want to test something like an ExceptionInfo's data map, we now just
> have to write a helper to walk the stack trace until we find it - which
> would likely be a single "step" up the trace.
>
> A simple reproducing case:
> *clojure-version* ;= {:major 1, :minor 7, :incremental 0, :qualifier "RC1"}
>
> (defmacro demo [] (throw (ex-info "fail" {})))
>
> (demo) ;= CompilerException clojure.lang.ExceptionInfo: fail {},
> compiling:(form-init4053282905768384039.clj:1:1)
>
> vs.
> *clojure-version* ;= {:major 1, :minor 6, :incremental 0, :qualifier nil}
>
> (demo) ;= ExceptionInfo fail  clojure.core/ex-info (core.clj:4403)
>
>
>
> On Saturday, May 23, 2015 at 8:52:47 AM UTC-5, Alex Miller wrote:
>>
>> 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 moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
> 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 clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Ivan L]

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 wrap errors that occur during macroexpansion now.
>
> Around here 
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6627-L6649,
>  
> the Compiler.macroexpand1() now has a try-catch for Throwable around the 
> evaluation of the macro invocation.
> This was not the case in Clojure version 1.6.  See around 
> https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Compiler.java#L6548-L6560
>  
> for a reference point.
>
> I'm fairly sure that is what has caused this change in behavior that broke 
> our expectations that the exception types our code through during 
> macroexpansion would propagate all the way back to the caller.  Again, I 
> think this was a bad expectation to have, but it is a little tricky.
>
> It is a little trickier for us to have any strong assertions on the type 
> of exception that may come from a macro now.  Compiler$CompilerException 
> seems too dependent on the implementation.  So we've opted to just assert 
> there would be a is-thrown? RuntimeException in these sorts of tests.  If 
> we want to test something like an ExceptionInfo's data map, we now just 
> have to write a helper to walk the stack trace until we find it - which 
> would likely be a single "step" up the trace.
>
> A simple reproducing case:
> *clojure-version* ;= {:major 1, :minor 7, :incremental 0, :qualifier "RC1"}
>
> (defmacro demo [] (throw (ex-info "fail" {})))
>
> (demo) ;= CompilerException clojure.lang.ExceptionInfo: fail {}, 
> compiling:(form-init4053282905768384039.clj:1:1) 
>
> vs.
> *clojure-version* ;= {:major 1, :minor 6, :incremental 0, :qualifier nil}
>
> (demo) ;= ExceptionInfo fail  clojure.core/ex-info (core.clj:4403)
>
>
>
> On Saturday, May 23, 2015 at 8:52:47 AM UTC-5, Alex Miller wrote:
>>
>> 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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Mike Rodriguez]

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 
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6627-L6649,
 
the Compiler.macroexpand1() now has a try-catch for Throwable around the 
evaluation of the macro invocation.
This was not the case in Clojure version 1.6.  See 
around 
https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Compiler.java#L6548-L6560
 
for a reference point.

I'm fairly sure that is what has caused this change in behavior that broke 
our expectations that the exception types our code through during 
macroexpansion would propagate all the way back to the caller.  Again, I 
think this was a bad expectation to have, but it is a little tricky.

It is a little trickier for us to have any strong assertions on the type of 
exception that may come from a macro now.  Compiler$CompilerException seems 
too dependent on the implementation.  So we've opted to just assert there 
would be a is-thrown? RuntimeException in these sorts of tests.  If we want 
to test something like an ExceptionInfo's data map, we now just have to 
write a helper to walk the stack trace until we find it - which would 
likely be a single "step" up the trace.

A simple reproducing case:
*clojure-version* ;= {:major 1, :minor 7, :incremental 0, :qualifier "RC1"}

(defmacro demo [] (throw (ex-info "fail" {})))

(demo) ;= CompilerException clojure.lang.ExceptionInfo: fail {}, 
compiling:(form-init4053282905768384039.clj:1:1) 

vs.
*clojure-version* ;= {:major 1, :minor 6, :incremental 0, :qualifier nil}

(demo) ;= ExceptionInfo fail  clojure.core/ex-info (core.clj:4403)



On Saturday, May 23, 2015 at 8:52:47 AM UTC-5, Alex Miller wrote:
>
> 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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Geoff Shannon]

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, Alex Miller wrote:
>
> 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 would 
> silently drop all but the first spliced element).
>
> 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). The 
> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>
> - Alex
>

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Tassilo Horn]

Andy Fingerhut  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 library today that
> fixes that.

Indeed, I can confirm that it works as expected with version 1.5.3.

> That has no effect on the other CLJ tickets.  It is only a fix for the
> ordered library.

Yes, of course.

Bye,
Tassilo

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Andy Fingerhut]

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 CLJ tickets.  It is only a fix for the
ordered library.

Andy

On Thu, May 28, 2015 at 1:09 AM, Tassilo Horn  wrote:

> 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. [1 2 3])) ;=> true
>
> but sets of equal sets aren't equal anymore, e.g.,
>
>   (= #{#{1 2 3}} #{(flatland.ordered.set/ordered-set 1 2 3)}) ;=> false
>   (= #{#{1 2 3}} #{(java.util.HashSet. [1 2 3])}) ;=> false
>
> That's no recent regression in 1.7.0-RC1, though.  I can reproduce the
> bug also with 1.6.0.
>
> Bye,
> Tassilo
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> 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 clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

CLJ-1649 is separate and unrelated to what you logged.

On Thu, May 28, 2015 at 7:16 AM, Tassilo Horn  wrote:

> Alex Miller  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 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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Tassilo Horn]

Alex Miller  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 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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Tassilo Horn]

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. [1 2 3])) ;=> true

but sets of equal sets aren't equal anymore, e.g.,

  (= #{#{1 2 3}} #{(flatland.ordered.set/ordered-set 1 2 3)}) ;=> false
  (= #{#{1 2 3}} #{(java.util.HashSet. [1 2 3])}) ;=> false

That's no recent regression in 1.7.0-RC1, though.  I can reproduce the
bug also with 1.6.0.

Bye,
Tassilo

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

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  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" automatic clojure.lang.RT seq adapters 
> in Clojure <=1.6. My point is that existing Clojure code can and does 
> depend on non-chunked realization of iterator seqs, and that for such code 
> this is a breaking change.
>  
>
>> Can you point to code for "the original behavior allowed room to 
>> transform the mutated object into an object which *could* be safely cached 
>> in a 'downstream' seq"? By what means does this transformation occur? It 
>> sounds to me like you are starting with an Iterator, creating a seq, then 
>> walking the seq exactly once, one element at a time, and producing a new 
>> transformed seq or other output. 
>>
>
> Exactly -- the unfortunately Java <=1.6-only snippet I posted earlier is 
> just such an example of this.
>  
>
>> If you did reuse that IteratorSeq, all of the elements of the sequence 
>> would point to the same object which would be in the "last" state like the 
>> java 1.6 example you gave. Thus, the "caching" capability of the seq can't 
>> possibly be something you're using. And if that's true, then why are you 
>> paying the allocation and synchronization costs of making the seq at all? 
>> Why not just use the iterator directly, thus skipping all the extra 
>> allocation that these object-reusing high-performance iterators are working 
>> so hard to avoid in the first place? In 1.7, transducers would give you 
>> exactly the capability to walk the source iterator, apply a transducer 
>> version of your transformation, and output to a collection (via into), a 
>> value (via transduce), or a lazy sequence (via sequence). I think you would 
>> find this faster as well due to reduced allocation (possibly greatly 
>> reduced depending on the transformation).
>>
>
> I've personally used reducers wherever possible since they were 
> introduced, and for the Hadoop case Parkour's primary recommended API is in 
> terms of reducers [1]. For new code, the transducer-based facilities in 
> Clojure 1.7 will certainly provide more options for functional-safe 
> handling of the iterators at question.  But to repeat my main point, those 
> don't help with existing code which depends on the one-at-a-time 
> realization semantics of Iterators being reflected in one-at-a-time 
> realization in iterator-backed seqs.
>
> [1] 
> https://github.com/damballa/parkour/blob/master/doc/reducers-vs-seqs.md
>
> Thanks,
>
> -Marshall
>
>

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Marshall Bockrath-Vandegrift]

On Tue, May 26, 2015 at 11:29 PM Alex Miller  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" automatic clojure.lang.RT seq adapters
in Clojure <=1.6. My point is that existing Clojure code can and does
depend on non-chunked realization of iterator seqs, and that for such code
this is a breaking change.


> Can you point to code for "the original behavior allowed room to transform
> the mutated object into an object which *could* be safely cached in a
> 'downstream' seq"? By what means does this transformation occur? It sounds
> to me like you are starting with an Iterator, creating a seq, then walking
> the seq exactly once, one element at a time, and producing a new
> transformed seq or other output.
>

Exactly -- the unfortunately Java <=1.6-only snippet I posted earlier is
just such an example of this.


> If you did reuse that IteratorSeq, all of the elements of the sequence
> would point to the same object which would be in the "last" state like the
> java 1.6 example you gave. Thus, the "caching" capability of the seq can't
> possibly be something you're using. And if that's true, then why are you
> paying the allocation and synchronization costs of making the seq at all?
> Why not just use the iterator directly, thus skipping all the extra
> allocation that these object-reusing high-performance iterators are working
> so hard to avoid in the first place? In 1.7, transducers would give you
> exactly the capability to walk the source iterator, apply a transducer
> version of your transformation, and output to a collection (via into), a
> value (via transduce), or a lazy sequence (via sequence). I think you would
> find this faster as well due to reduced allocation (possibly greatly
> reduced depending on the transformation).
>

I've personally used reducers wherever possible since they were introduced,
and for the Hadoop case Parkour's primary recommended API is in terms of
reducers [1]. For new code, the transducer-based facilities in Clojure 1.7
will certainly provide more options for functional-safe handling of the
iterators at question.  But to repeat my main point, those don't help with
existing code which depends on the one-at-a-time realization semantics of
Iterators being reflected in one-at-a-time realization in iterator-backed
seqs.

[1] https://github.com/damballa/parkour/blob/master/doc/reducers-vs-seqs.md

Thanks,

-Marshall

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Julien]

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

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

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 still supported in Clojure 1.7 (but will likely be removed in 
the next release or two).
 

> I can throw together a synthetic example, but I think the people following 
> this thread get what's happening.  The point isn't whether this pattern is 
> a "good idea" or not (it certainly isn't) but whether existing Java APIs 
> people want to interop with use it (they certainly do).
>

The point I was getting at is really whether you should consider this to be 
broken with the old behavior too. 
 

> I presently depend on no less than 3 separate Java library APIs I 
> currently know for a fact depend on this behavior:
> - Hadoop ReduceContextImpl$ValueIterator
> - Mahout DenseVector$AllIterator/NonDefaultIterator
> - LensKit FastIterators
>

Can you point to code for "the original behavior allowed room to transform 
the mutated object into an object which *could* be safely cached in a 
'downstream' seq"? By what means does this transformation occur? It sounds 
to me like you are starting with an Iterator, creating a seq, then walking 
the seq exactly once, one element at a time, and producing a new 
transformed seq or other output. 

If you did reuse that IteratorSeq, all of the elements of the sequence 
would point to the same object which would be in the "last" state like the 
java 1.6 example you gave. Thus, the "caching" capability of the seq can't 
possibly be something you're using. And if that's true, then why are you 
paying the allocation and synchronization costs of making the seq at all? 
Why not just use the iterator directly, thus skipping all the extra 
allocation that these object-reusing high-performance iterators are working 
so hard to avoid in the first place? In 1.7, transducers would give you 
exactly the capability to walk the source iterator, apply a transducer 
version of your transformation, and output to a collection (via into), a 
value (via transduce), or a lazy sequence (via sequence). I think you would 
find this faster as well due to reduced allocation (possibly greatly 
reduced depending on the transformation).
 

> It is an option to explicitly construct `IteratorSeq` instances (I 
> actually had verified that approach this afternoon for the Hadoop API in 
> Parkour), but I'm not happy about it. That approach places a definite 
> burden on integration library maintainers to implement the change, and on 
> end-users to realize they need to upgrade for Clojure 1.7 compatibility. 
> The `Iterator` interface just fundamentally in no way guarantees that the 
> `next()` yielded values are functional-safe in the sense necessary to 
> support chunking. I understand the desire to increase performance, but I 
> don't think it's worth the potential silent and bewildering breakage in 
> interop.
>

It would be possible to restore the non-chunking IteratorSeq behavior but 
retain it for eduction and the other places where we first made the swap. 
I'm not quite ready yet to concede that that's necessary. It seems like the 
only constraints under which this usage makes sense is exactly the case 
where it's unnecessary and even harmful.

 

> On Tue, May 26, 2015 at 9:18 PM Alex Miller  wrote:
>
>> 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 {}) (java.util.EnumMap.) 
>> (.entrySet) (map str) (into []))
>> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" 
>> "MINUTES=4" "HOURS=5" "DAYS=6"]
>>
>> Re "implementing the not-uncommon Java pattern of mutating and 
>> re-yielding the same object on each `next()` invocation". I'm assuming that 
>> you're somehow expecting to traverse one seq node, then having an 
>> opportunity to mutate something (the source, the iterator, the return 
>> object) in between each new advancement of the seq node? That seems a) not 
>> common at all, b) a bad idea even in Java and c) dangerous even before this 
>> change. In either case you end up with a seq that points to a succession of 
>> the same repeated (mutable and mutating) object - this violates most 
>> expectations we as Clojure users have of sequences. Any sort of chunking 
>> (map, filter, etc) over the top of that seq would force realization up to 
>> 32 elements beyond the head causing the same issue. 
>>
>> The original one-at-a-time IteratorSeq is still there (for now) and you 
>> can still make one if you want via (clojure.lang.IteratorSeq/create iter) 
>> but I would consider it deprecated. I think a custom lazy-seq or a 
>> loop-recu

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

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 if it has been reported yet.
>
> Julien
>

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Mike Rodriguez]

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 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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Marshall Bockrath-Vandegrift]

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 deep guts of a complex Java API suddenly became nonsensical.

On Tue, May 26, 2015 at 9:45 PM Marshall Bockrath-Vandegrift <
llas...@gmail.com> 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?).  I can throw together a
> synthetic example, but I think the people following this thread get what's
> happening.  The point isn't whether this pattern is a "good idea" or not
> (it certainly isn't) but whether existing Java APIs people want to interop
> with use it (they certainly do).
>
> I presently depend on no less than 3 separate Java library APIs I
> currently know for a fact depend on this behavior:
> - Hadoop ReduceContextImpl$ValueIterator
> - Mahout DenseVector$AllIterator/NonDefaultIterator
> - LensKit FastIterators
>
> It is an option to explicitly construct `IteratorSeq` instances (I
> actually had verified that approach this afternoon for the Hadoop API in
> Parkour), but I'm not happy about it. That approach places a definite
> burden on integration library maintainers to implement the change, and on
> end-users to realize they need to upgrade for Clojure 1.7 compatibility.
> The `Iterator` interface just fundamentally in no way guarantees that the
> `next()` yielded values are functional-safe in the sense necessary to
> support chunking. I understand the desire to increase performance, but I
> don't think it's worth the potential silent and bewildering breakage in
> interop.
>
>
> On Tue, May 26, 2015 at 9:18 PM Alex Miller  wrote:
>
>> 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 {}) (java.util.EnumMap.)
>> (.entrySet) (map str) (into []))
>> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3"
>> "MINUTES=4" "HOURS=5" "DAYS=6"]
>>
>> Re "implementing the not-uncommon Java pattern of mutating and
>> re-yielding the same object on each `next()` invocation". I'm assuming that
>> you're somehow expecting to traverse one seq node, then having an
>> opportunity to mutate something (the source, the iterator, the return
>> object) in between each new advancement of the seq node? That seems a) not
>> common at all, b) a bad idea even in Java and c) dangerous even before this
>> change. In either case you end up with a seq that points to a succession of
>> the same repeated (mutable and mutating) object - this violates most
>> expectations we as Clojure users have of sequences. Any sort of chunking
>> (map, filter, etc) over the top of that seq would force realization up to
>> 32 elements beyond the head causing the same issue.
>>
>> The original one-at-a-time IteratorSeq is still there (for now) and you
>> can still make one if you want via (clojure.lang.IteratorSeq/create iter)
>> but I would consider it deprecated. I think a custom lazy-seq or a
>> loop-recur would be a better way to handle this case, which in my opinion
>> is highly unusual. That said, my ears are open if this is an issue for a
>> large number of people.
>>
>>
>> On Tuesday, May 26, 2015 at 6:24:54 PM UTC-5, Marshall
>> Bockrath-Vandegrift wrote:
>>>
>>> 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 Java standard libary:
>>>
>>> Clojure 1.6.0:
>>> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
>>> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
>>> #=> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3"
>>> "MINUTES=4" "HOURS=5" "DAYS=6"]
>>>
>>> Clojure 1.7.0-RC1:
>>> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
>>> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
>>> #=> ["DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6"]
>>>
>>> IMHO the latter behavior demonstrates a mismatch where chunked seqs and
>>> iterators are simple incompatible.
>>>
>>> On Tue, May 26, 2015 at 5:33 PM Alex Miller  wrote:
>>>
 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 

Re: [ANN] Clojure 1.7.0-RC1 now available

[Leif]

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, it's probably advisable to test against 1.7-RC.

--Leif

On Tuesday, May 26, 2015 at 9:19:00 PM UTC-4, Alex Miller wrote:
>
> 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 {}) (java.util.EnumMap.) 
> (.entrySet) (map str) (into []))
> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" "MINUTES=4" 
> "HOURS=5" "DAYS=6"]
>
> Re "implementing the not-uncommon Java pattern of mutating and re-yielding 
> the same object on each `next()` invocation". I'm assuming that you're 
> somehow expecting to traverse one seq node, then having an opportunity to 
> mutate something (the source, the iterator, the return object) in between 
> each new advancement of the seq node? That seems a) not common at all, b) a 
> bad idea even in Java and c) dangerous even before this change. In either 
> case you end up with a seq that points to a succession of the same repeated 
> (mutable and mutating) object - this violates most expectations we as 
> Clojure users have of sequences. Any sort of chunking (map, filter, etc) 
> over the top of that seq would force realization up to 32 elements beyond 
> the head causing the same issue. 
>
> The original one-at-a-time IteratorSeq is still there (for now) and you 
> can still make one if you want via (clojure.lang.IteratorSeq/create iter) 
> but I would consider it deprecated. I think a custom lazy-seq or a 
> loop-recur would be a better way to handle this case, which in my opinion 
> is highly unusual. That said, my ears are open if this is an issue for a 
> large number of people.
>
>
> On Tuesday, May 26, 2015 at 6:24:54 PM UTC-5, Marshall Bockrath-Vandegrift 
> wrote:
>>
>> 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 Java standard libary:
>>
>> Clojure 1.6.0:
>> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
>> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
>> #=> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" 
>> "MINUTES=4" "HOURS=5" "DAYS=6"]
>>
>> Clojure 1.7.0-RC1:
>> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
>> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
>> #=> ["DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6"]
>>
>> IMHO the latter behavior demonstrates a mismatch where chunked seqs and 
>> iterators are simple incompatible.
>>
>> On Tue, May 26, 2015 at 5:33 PM Alex Miller > > wrote:
>>
>>> 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 that mutable iterator with anything else, or having expectations 
>>> about its rate of consumption was as dubious before as it is now.
>>>
>>> Unless of course I misunderstand your intent, which possible because I 
>>> am on a phone without easy access to look further at the commit and am 
>>> going by memory.
>>>
>>>
>>>
>>> On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift <
>>> lla...@gmail.com > wrote:
>>>
>>> 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 traversal of any 
>>> iterator implementing the not-uncommon Java pattern of mutating and 
>>> re-yielding the same object on each `next()` invocation.
>>>
>>> I'm unable to find an existing ticket for this apparent-regression.  
>>> Should I create one, or did I miss the existing ticket, or is there some 
>>> mitigating issue which makes this a non-problem?
>>>
>>> Thanks.
>>>
>>> -Marshall
>>>
>>> On Thu, May 21, 2015 at 12:31 PM Alex Miller >> > wrote:
>>>
 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-b

Re: [ANN] Clojure 1.7.0-RC1 now available

[Marshall Bockrath-Vandegrift]

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
happening.  The point isn't whether this pattern is a "good idea" or not
(it certainly isn't) but whether existing Java APIs people want to interop
with use it (they certainly do).

I presently depend on no less than 3 separate Java library APIs I currently
know for a fact depend on this behavior:
- Hadoop ReduceContextImpl$ValueIterator
- Mahout DenseVector$AllIterator/NonDefaultIterator
- LensKit FastIterators

It is an option to explicitly construct `IteratorSeq` instances (I actually
had verified that approach this afternoon for the Hadoop API in Parkour),
but I'm not happy about it. That approach places a definite burden on
integration library maintainers to implement the change, and on end-users
to realize they need to upgrade for Clojure 1.7 compatibility. The
`Iterator` interface just fundamentally in no way guarantees that the
`next()` yielded values are functional-safe in the sense necessary to
support chunking. I understand the desire to increase performance, but I
don't think it's worth the potential silent and bewildering breakage in
interop.


On Tue, May 26, 2015 at 9:18 PM Alex Miller  wrote:

> 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 {}) (java.util.EnumMap.)
> (.entrySet) (map str) (into []))
> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" "MINUTES=4"
> "HOURS=5" "DAYS=6"]
>
> Re "implementing the not-uncommon Java pattern of mutating and re-yielding
> the same object on each `next()` invocation". I'm assuming that you're
> somehow expecting to traverse one seq node, then having an opportunity to
> mutate something (the source, the iterator, the return object) in between
> each new advancement of the seq node? That seems a) not common at all, b) a
> bad idea even in Java and c) dangerous even before this change. In either
> case you end up with a seq that points to a succession of the same repeated
> (mutable and mutating) object - this violates most expectations we as
> Clojure users have of sequences. Any sort of chunking (map, filter, etc)
> over the top of that seq would force realization up to 32 elements beyond
> the head causing the same issue.
>
> The original one-at-a-time IteratorSeq is still there (for now) and you
> can still make one if you want via (clojure.lang.IteratorSeq/create iter)
> but I would consider it deprecated. I think a custom lazy-seq or a
> loop-recur would be a better way to handle this case, which in my opinion
> is highly unusual. That said, my ears are open if this is an issue for a
> large number of people.
>
>
> On Tuesday, May 26, 2015 at 6:24:54 PM UTC-5, Marshall Bockrath-Vandegrift
> wrote:
>>
>> 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 Java standard libary:
>>
>> Clojure 1.6.0:
>> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
>> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
>> #=> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3"
>> "MINUTES=4" "HOURS=5" "DAYS=6"]
>>
>> Clojure 1.7.0-RC1:
>> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
>> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
>> #=> ["DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6"]
>>
>> IMHO the latter behavior demonstrates a mismatch where chunked seqs and
>> iterators are simple incompatible.
>>
>> On Tue, May 26, 2015 at 5:33 PM Alex Miller  wrote:
>>
>>> 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 that mutable iterator with anything else, or having expectations
>>> about its rate of consumption was as dubious before as it is now.
>>>
>>> Unless of course I misunderstand your intent, which possible because I
>>> am on a phone without easy access to look further at the commit and am
>>> going by memory.
>>>
>>>
>>>
>>> On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift <
>>> llas...@gmail.com> wrote:
>>>
>>> Some of my code is broken by
>>> commit c47e1bbcfa227723df28

Re: [ANN] Clojure 1.7.0-RC1 now available

[Julien]

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 écrit :
>
> 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 would 
> silently drop all but the first spliced element).
>
> 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). The 
> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>
> - Alex
>

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

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 {}) (java.util.EnumMap.) 
(.entrySet) (map str) (into []))
["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" "MINUTES=4" 
"HOURS=5" "DAYS=6"]

Re "implementing the not-uncommon Java pattern of mutating and re-yielding 
the same object on each `next()` invocation". I'm assuming that you're 
somehow expecting to traverse one seq node, then having an opportunity to 
mutate something (the source, the iterator, the return object) in between 
each new advancement of the seq node? That seems a) not common at all, b) a 
bad idea even in Java and c) dangerous even before this change. In either 
case you end up with a seq that points to a succession of the same repeated 
(mutable and mutating) object - this violates most expectations we as 
Clojure users have of sequences. Any sort of chunking (map, filter, etc) 
over the top of that seq would force realization up to 32 elements beyond 
the head causing the same issue. 

The original one-at-a-time IteratorSeq is still there (for now) and you can 
still make one if you want via (clojure.lang.IteratorSeq/create iter) but I 
would consider it deprecated. I think a custom lazy-seq or a loop-recur 
would be a better way to handle this case, which in my opinion is highly 
unusual. That said, my ears are open if this is an issue for a large number 
of people.


On Tuesday, May 26, 2015 at 6:24:54 PM UTC-5, Marshall Bockrath-Vandegrift 
wrote:
>
> 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 Java standard libary:
>
> Clojure 1.6.0:
> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
> #=> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" 
> "MINUTES=4" "HOURS=5" "DAYS=6"]
>
> Clojure 1.7.0-RC1:
> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
> #=> ["DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6"]
>
> IMHO the latter behavior demonstrates a mismatch where chunked seqs and 
> iterators are simple incompatible.
>
> On Tue, May 26, 2015 at 5:33 PM Alex Miller  wrote:
>
>> 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 that mutable iterator with anything else, or having expectations 
>> about its rate of consumption was as dubious before as it is now.
>>
>> Unless of course I misunderstand your intent, which possible because I am 
>> on a phone without easy access to look further at the commit and am going 
>> by memory.
>>
>>
>>
>> On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift <
>> llas...@gmail.com> wrote:
>>
>> 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 traversal of any 
>> iterator implementing the not-uncommon Java pattern of mutating and 
>> re-yielding the same object on each `next()` invocation.
>>
>> I'm unable to find an existing ticket for this apparent-regression.  
>> Should I create one, or did I miss the existing ticket, or is there some 
>> mitigating issue which makes this a non-problem?
>>
>> Thanks.
>>
>> -Marshall
>>
>> On Thu, May 21, 2015 at 12:31 PM Alex Miller  wrote:
>>
>>> 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 would 
>>> silently drop all but the first spliced element).
>>>
>>> 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). The 
>>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>>>
>>> - Alex
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojur

Re: [ANN] Clojure 1.7.0-RC1 now available

[Leif]

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 {}) (java.util.EnumMap.) 
(.entrySet) (map str) (into []))
["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" "MINUTES=4" 
"HOURS=5" "DAYS=6"]

/usr/lib/jvm/*java-7-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 {}) (java.util.EnumMap.) 
(.entrySet) (map str) (into []))
["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" "MINUTES=4" 
"HOURS=5" "DAYS=6"]

/usr/lib/jvm/*java-6-oracle*/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 {}) (java.util.EnumMap.) 
(.entrySet) (map str) (into []))
["DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6"]

--Leif

On Tuesday, May 26, 2015 at 8:39:14 PM UTC-4, Daniel wrote:
>
> 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 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 Java standard libary:
>>
>> Clojure 1.6.0:
>> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
>> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
>> #=> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" 
>> "MINUTES=4" "HOURS=5" "DAYS=6"]
>>
>> Clojure 1.7.0-RC1:
>> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
>> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
>> #=> ["DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6"]
>>
>> IMHO the latter behavior demonstrates a mismatch where chunked seqs and 
>> iterators are simple incompatible.
>>
>> On Tue, May 26, 2015 at 5:33 PM Alex Miller  wrote:
>>
>>> 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 that mutable iterator with anything else, or having expectations 
>>> about its rate of consumption was as dubious before as it is now.
>>>
>>> Unless of course I misunderstand your intent, which possible because I 
>>> am on a phone without easy access to look further at the commit and am 
>>> going by memory.
>>>
>>>
>>>
>>> On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift <
>>> lla...@gmail.com> wrote:
>>>
>>> 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 traversal of any 
>>> iterator implementing the not-uncommon Java pattern of mutating and 
>>> re-yielding the same object on each `next()` invocation.
>>>
>>> I'm unable to find an existing ticket for this apparent-regression.  
>>> Should I create one, or did I miss the existing ticket, or is there some 
>>> mitigating issue which makes this a non-problem?
>>>
>>> Thanks.
>>>
>>> -Marshall
>>>
>>> On Thu, May 21, 2015 at 12:31 PM Alex Miller  
>>> wrote:
>>>
 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 would 
 silently drop all but the first spliced element).

 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). 
 The more and quicker feedback we get, the sooner we can release 1.7.0 
 final!

 - Alex

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

Re: [ANN] Clojure 1.7.0-RC1 now available

[Daniel]

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 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 Java standard libary:
>
> Clojure 1.6.0:
> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
> #=> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" 
> "MINUTES=4" "HOURS=5" "DAYS=6"]
>
> Clojure 1.7.0-RC1:
> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
> #=> ["DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6"]
>
> IMHO the latter behavior demonstrates a mismatch where chunked seqs and 
> iterators are simple incompatible.
>
> On Tue, May 26, 2015 at 5:33 PM Alex Miller  > wrote:
>
>> 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 that mutable iterator with anything else, or having expectations 
>> about its rate of consumption was as dubious before as it is now.
>>
>> Unless of course I misunderstand your intent, which possible because I am 
>> on a phone without easy access to look further at the commit and am going 
>> by memory.
>>
>>
>>
>> On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift <
>> lla...@gmail.com > wrote:
>>
>> 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 traversal of any 
>> iterator implementing the not-uncommon Java pattern of mutating and 
>> re-yielding the same object on each `next()` invocation.
>>
>> I'm unable to find an existing ticket for this apparent-regression.  
>> Should I create one, or did I miss the existing ticket, or is there some 
>> mitigating issue which makes this a non-problem?
>>
>> Thanks.
>>
>> -Marshall
>>
>> On Thu, May 21, 2015 at 12:31 PM Alex Miller > > wrote:
>>
>>> 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 would 
>>> silently drop all but the first spliced element).
>>>
>>> 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). The 
>>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>>>
>>> - Alex
>>>
>>> -- 
>>> 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.
>>>
>>  -- 
>> 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.
>>
>>  -- 
>> 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.
>>
>

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

Re: [ANN] Clojure 1.7.0-RC1 now available

[Daniel]

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 Bockrath-Vandegrift 
wrote:
>
> 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 Java standard libary:
>
> Clojure 1.6.0:
> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
> #=> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" 
> "MINUTES=4" "HOURS=5" "DAYS=6"]
>
> Clojure 1.7.0-RC1:
> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
> #=> ["DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6"]
>
> IMHO the latter behavior demonstrates a mismatch where chunked seqs and 
> iterators are simple incompatible.
>
> On Tue, May 26, 2015 at 5:33 PM Alex Miller  > wrote:
>
>> 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 that mutable iterator with anything else, or having expectations 
>> about its rate of consumption was as dubious before as it is now.
>>
>> Unless of course I misunderstand your intent, which possible because I am 
>> on a phone without easy access to look further at the commit and am going 
>> by memory.
>>
>>
>>
>> On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift <
>> lla...@gmail.com > wrote:
>>
>> 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 traversal of any 
>> iterator implementing the not-uncommon Java pattern of mutating and 
>> re-yielding the same object on each `next()` invocation.
>>
>> I'm unable to find an existing ticket for this apparent-regression.  
>> Should I create one, or did I miss the existing ticket, or is there some 
>> mitigating issue which makes this a non-problem?
>>
>> Thanks.
>>
>> -Marshall
>>
>> On Thu, May 21, 2015 at 12:31 PM Alex Miller > > wrote:
>>
>>> 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 would 
>>> silently drop all but the first spliced element).
>>>
>>> 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). The 
>>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>>>
>>> - Alex
>>>
>>> -- 
>>> 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.
>>>
>>  -- 
>> 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.
>>
>>  -- 
>> 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.
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googleg

Re: [ANN] Clojure 1.7.0-RC1 now available

[Marshall Bockrath-Vandegrift]

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 Java standard libary:

Clojure 1.6.0:
(->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#=> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3"
"MINUTES=4" "HOURS=5" "DAYS=6"]

Clojure 1.7.0-RC1:
(->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#=> ["DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6"]

IMHO the latter behavior demonstrates a mismatch where chunked seqs and
iterators are simple incompatible.

On Tue, May 26, 2015 at 5:33 PM Alex Miller  wrote:

> 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
> that mutable iterator with anything else, or having expectations about its
> rate of consumption was as dubious before as it is now.
>
> Unless of course I misunderstand your intent, which possible because I am
> on a phone without easy access to look further at the commit and am going
> by memory.
>
>
>
> On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift <
> llas...@gmail.com> wrote:
>
> 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 traversal of any
> iterator implementing the not-uncommon Java pattern of mutating and
> re-yielding the same object on each `next()` invocation.
>
> I'm unable to find an existing ticket for this apparent-regression.
> Should I create one, or did I miss the existing ticket, or is there some
> mitigating issue which makes this a non-problem?
>
> Thanks.
>
> -Marshall
>
> On Thu, May 21, 2015 at 12:31 PM Alex Miller  wrote:
>
>> 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 would
>> silently drop all but the first spliced element).
>>
>> 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). The
>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>>
>> - Alex
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to clojure-...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/clojure-dev.
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> For more options, visit https://groups.google.com/d/optout.
>
>  --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> 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 clojure@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+unsubscr...@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+unsubscr...

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

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 that mutable iterator 
with anything else, or having expectations about its rate of consumption was as 
dubious before as it is now.

Unless of course I misunderstand your intent, which possible because I am on a 
phone without easy access to look further at the commit and am going by memory.



> On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift  
> wrote:
> 
> 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 
> traversal of any iterator implementing the not-uncommon Java pattern of 
> mutating and re-yielding the same object on each `next()` invocation.
> 
> I'm unable to find an existing ticket for this apparent-regression.  Should I 
> create one, or did I miss the existing ticket, or is there some mitigating 
> issue which makes this a non-problem?
> 
> Thanks.
> 
> -Marshall
> 
>> On Thu, May 21, 2015 at 12:31 PM Alex Miller  wrote:
>> 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 would silently 
>> drop all but the first spliced element).
>> 
>> 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). The 
>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>> 
>> - Alex
>> -- 
>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to clojure-...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/clojure-dev.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> 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 clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Marshall Bockrath-Vandegrift]

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 traversal of any
iterator implementing the not-uncommon Java pattern of mutating and
re-yielding the same object on each `next()` invocation.

I'm unable to find an existing ticket for this apparent-regression.  Should
I create one, or did I miss the existing ticket, or is there some
mitigating issue which makes this a non-problem?

Thanks.

-Marshall

On Thu, May 21, 2015 at 12:31 PM Alex Miller  wrote:

> 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 would
> silently drop all but the first spliced element).
>
> 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). The
> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>
> - Alex
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> 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 clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Mark Engelberg]

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,
something definitely changed.

On Sat, May 23, 2015 at 6:44 AM, Mike Rodriguez  wrote:

> 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 Clojure compiler now seems to wrap many (most/all?) exceptions thrown
> with a Compiler$CompilerException.
>
> We had some tests around macros that checked for certain exceptions being
> thrown - like ExceptionInfo or IllegalStateException etc. these were
> exceptions we explicitly through in macro error handling for compile-time
> error feedback with context.
> We used the typically clojure.test is-thrown? Style which makes an
> instanceof assertion.
>
> Arguably our tests were wrong to expect our macroexpansion exception types
> to be propagated all the way up to the caller without being wrapped first.
> However this was slightly surprising.
>
> To be better prepared for future changes like this, it looks like we
> should assert no more specific than a RuntimeException (or possibly
> Exception, but I doubt Clojure would switch to checked exceptions).
>
> --
> 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 group, send email to
> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
> 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 clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alan Moore]

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 Compton wrote:
>
> 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 porting a few libraries and everything has gone mostly 
> smoothly. However I'd feel more confident that we've got the right design 
> if we had more people trying to port their libraries/projects to cljc and 
> reporting their experiences.
>
> Is this a reasonable concern, or am I missing something and this isn't 
> necessary?
> On Fri, 22 May 2015 at 7:35 pm Jason Wolfe > 
> wrote:
>
>> 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, Alex Miller wrote:
>>>
>>> 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 would 
>>> silently drop all but the first spliced element).
>>>
>>> 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). The 
>>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>>>
>>> - Alex
>>>
>>  -- 
>> 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.
>>
>

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Jason Wolfe]

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 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 Wolfe wrote:
>>
>> 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
>>   core.clj:135 clojure.core/seq
>>   core.clj:698 clojure.core/concat[fn]
>>LazySeq.java:40 clojure.lang.LazySeq.sval
>>LazySeq.java:49 clojure.lang.LazySeq.seq
>>ChunkedCons.java:59 clojure.lang.ChunkedCons.chunkedNext
>>   core.clj:671 clojure.core/chunk-next
>>  protocols.clj:119 clojure.core.protocols/fn
>>   protocols.clj:19 clojure.core.protocols/fn[fn]
>>   protocols.clj:31 clojure.core.protocols/seq-reduce
>>   protocols.clj:75 clojure.core.protocols/fn
>>   protocols.clj:13 clojure.core.protocols/fn[fn]
>>  protocols.clj:152 clojure.core.protocols/fn
>>   protocols.clj:19 clojure.core.protocols/fn[fn]
>>   protocols.clj:31 clojure.core.protocols/seq-reduce
>>   protocols.clj:75 clojure.core.protocols/fn
>>   protocols.clj:13 clojure.core.protocols/fn[fn]
>>  protocols.clj:122 clojure.core.protocols/fn
>>   protocols.clj:19 clojure.core.protocols/fn[fn]
>>   protocols.clj:31 clojure.core.protocols/seq-reduce
>>   protocols.clj:75 clojure.core.protocols/fn
>>   protocols.clj:13 clojure.core.protocols/fn[fn]
>>  protocols.clj:152 clojure.core.protocols/fn
>>   protocols.clj:19 clojure.core.protocols/fn[fn]
>>   protocols.clj:31 clojure.core.protocols/seq-reduce
>>   protocols.clj:75 clojure.core.protocols/fn
>>   protocols.clj:13 clojure.core.protocols/fn[fn]
>>  protocols.clj:122 clojure.core.protocols/fn
>>   protocols.clj:19 clojure.core.protocols/fn[fn]
>>   protocols.clj:31 clojure.core.protocols/seq-reduce
>>   protocols.clj:75 clojure.core.protocols/fn
>>   protocols.clj:13 clojure.core.protocols/fn[fn]
>>  protocols.clj:152 clojure.core.protocols/fn
>>   protocols.clj:19 clojure.core.protocols/fn[fn]
>>   protocols.clj:31 clojure.core.protocols/seq-reduce
>>   protocols.clj:75 clojure.core.protocols/fn
>>   protocols.clj:13 clojure.core.protocols/fn[fn]
>>  protocols.clj:122 clojure.core.protocols/fn
>>   protocols.clj:19 clojure.core.protocols/fn[fn]
>>   protocols.clj:31 clojure.core.protocols/seq-reduce
>>   protocols.clj:75 clojure.core.protocols/fn
>>   protocols.clj:13 clojure.core.protocols/fn[fn]
>>  protocols.clj:152 clojure.core.protocols/fn
>>   protocols.clj:19 clojure.core.protocols/fn[fn]
>>   protocols.clj:31 clojure.core.protocols/seq-reduce
>>   protocols.clj:75 clojure.core.protocols/fn
>>   protocols.clj:13 clojure.core.protocols/fn[fn]
>>  protocols.clj:122 clojure.core.protocols/fn
>>   protocols.clj:19 clojure.core.protocols/fn[fn]
>> 
>>
>> On Thursday, May 21, 2015 at 9:31:08 AM UTC-7, Alex Miller wrote:
>>>
>>> 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 would 
>>> silently drop all but the first spliced element).
>>>
>>> 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). The 
>>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>>>
>>> - Alex
>>>
>>

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.goog

Re: [ANN] Clojure 1.7.0-RC1 now available

[Ghadi Shayban]

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 Wolfe wrote:
>
> 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
>   core.clj:135 clojure.core/seq
>   core.clj:698 clojure.core/concat[fn]
>LazySeq.java:40 clojure.lang.LazySeq.sval
>LazySeq.java:49 clojure.lang.LazySeq.seq
>ChunkedCons.java:59 clojure.lang.ChunkedCons.chunkedNext
>   core.clj:671 clojure.core/chunk-next
>  protocols.clj:119 clojure.core.protocols/fn
>   protocols.clj:19 clojure.core.protocols/fn[fn]
>   protocols.clj:31 clojure.core.protocols/seq-reduce
>   protocols.clj:75 clojure.core.protocols/fn
>   protocols.clj:13 clojure.core.protocols/fn[fn]
>  protocols.clj:152 clojure.core.protocols/fn
>   protocols.clj:19 clojure.core.protocols/fn[fn]
>   protocols.clj:31 clojure.core.protocols/seq-reduce
>   protocols.clj:75 clojure.core.protocols/fn
>   protocols.clj:13 clojure.core.protocols/fn[fn]
>  protocols.clj:122 clojure.core.protocols/fn
>   protocols.clj:19 clojure.core.protocols/fn[fn]
>   protocols.clj:31 clojure.core.protocols/seq-reduce
>   protocols.clj:75 clojure.core.protocols/fn
>   protocols.clj:13 clojure.core.protocols/fn[fn]
>  protocols.clj:152 clojure.core.protocols/fn
>   protocols.clj:19 clojure.core.protocols/fn[fn]
>   protocols.clj:31 clojure.core.protocols/seq-reduce
>   protocols.clj:75 clojure.core.protocols/fn
>   protocols.clj:13 clojure.core.protocols/fn[fn]
>  protocols.clj:122 clojure.core.protocols/fn
>   protocols.clj:19 clojure.core.protocols/fn[fn]
>   protocols.clj:31 clojure.core.protocols/seq-reduce
>   protocols.clj:75 clojure.core.protocols/fn
>   protocols.clj:13 clojure.core.protocols/fn[fn]
>  protocols.clj:152 clojure.core.protocols/fn
>   protocols.clj:19 clojure.core.protocols/fn[fn]
>   protocols.clj:31 clojure.core.protocols/seq-reduce
>   protocols.clj:75 clojure.core.protocols/fn
>   protocols.clj:13 clojure.core.protocols/fn[fn]
>  protocols.clj:122 clojure.core.protocols/fn
>   protocols.clj:19 clojure.core.protocols/fn[fn]
>   protocols.clj:31 clojure.core.protocols/seq-reduce
>   protocols.clj:75 clojure.core.protocols/fn
>   protocols.clj:13 clojure.core.protocols/fn[fn]
>  protocols.clj:152 clojure.core.protocols/fn
>   protocols.clj:19 clojure.core.protocols/fn[fn]
>   protocols.clj:31 clojure.core.protocols/seq-reduce
>   protocols.clj:75 clojure.core.protocols/fn
>   protocols.clj:13 clojure.core.protocols/fn[fn]
>  protocols.clj:122 clojure.core.protocols/fn
>   protocols.clj:19 clojure.core.protocols/fn[fn]
> 
>
> On Thursday, May 21, 2015 at 9:31:08 AM UTC-7, Alex Miller wrote:
>>
>> 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 would 
>> silently drop all but the first spliced element).
>>
>> 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). The 
>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>>
>> - Alex
>>
>

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

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 "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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

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 unsubscribe from this group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Daniel Compton]

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 porting a few libraries and everything has gone mostly
smoothly. However I'd feel more confident that we've got the right design
if we had more people trying to port their libraries/projects to cljc and
reporting their experiences.

Is this a reasonable concern, or am I missing something and this isn't
necessary?
On Fri, 22 May 2015 at 7:35 pm Jason Wolfe  wrote:

> 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, Alex Miller wrote:
>>
>> 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 would
>> silently drop all but the first spliced element).
>>
>> 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). The
>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>>
>> - Alex
>>
>  --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> 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 clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Jason Wolfe]

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
  core.clj:135 clojure.core/seq
  core.clj:698 clojure.core/concat[fn]
   LazySeq.java:40 clojure.lang.LazySeq.sval
   LazySeq.java:49 clojure.lang.LazySeq.seq
   ChunkedCons.java:59 clojure.lang.ChunkedCons.chunkedNext
  core.clj:671 clojure.core/chunk-next
 protocols.clj:119 clojure.core.protocols/fn
  protocols.clj:19 clojure.core.protocols/fn[fn]
  protocols.clj:31 clojure.core.protocols/seq-reduce
  protocols.clj:75 clojure.core.protocols/fn
  protocols.clj:13 clojure.core.protocols/fn[fn]
 protocols.clj:152 clojure.core.protocols/fn
  protocols.clj:19 clojure.core.protocols/fn[fn]
  protocols.clj:31 clojure.core.protocols/seq-reduce
  protocols.clj:75 clojure.core.protocols/fn
  protocols.clj:13 clojure.core.protocols/fn[fn]
 protocols.clj:122 clojure.core.protocols/fn
  protocols.clj:19 clojure.core.protocols/fn[fn]
  protocols.clj:31 clojure.core.protocols/seq-reduce
  protocols.clj:75 clojure.core.protocols/fn
  protocols.clj:13 clojure.core.protocols/fn[fn]
 protocols.clj:152 clojure.core.protocols/fn
  protocols.clj:19 clojure.core.protocols/fn[fn]
  protocols.clj:31 clojure.core.protocols/seq-reduce
  protocols.clj:75 clojure.core.protocols/fn
  protocols.clj:13 clojure.core.protocols/fn[fn]
 protocols.clj:122 clojure.core.protocols/fn
  protocols.clj:19 clojure.core.protocols/fn[fn]
  protocols.clj:31 clojure.core.protocols/seq-reduce
  protocols.clj:75 clojure.core.protocols/fn
  protocols.clj:13 clojure.core.protocols/fn[fn]
 protocols.clj:152 clojure.core.protocols/fn
  protocols.clj:19 clojure.core.protocols/fn[fn]
  protocols.clj:31 clojure.core.protocols/seq-reduce
  protocols.clj:75 clojure.core.protocols/fn
  protocols.clj:13 clojure.core.protocols/fn[fn]
 protocols.clj:122 clojure.core.protocols/fn
  protocols.clj:19 clojure.core.protocols/fn[fn]
  protocols.clj:31 clojure.core.protocols/seq-reduce
  protocols.clj:75 clojure.core.protocols/fn
  protocols.clj:13 clojure.core.protocols/fn[fn]
 protocols.clj:152 clojure.core.protocols/fn
  protocols.clj:19 clojure.core.protocols/fn[fn]
  protocols.clj:31 clojure.core.protocols/seq-reduce
  protocols.clj:75 clojure.core.protocols/fn
  protocols.clj:13 clojure.core.protocols/fn[fn]
 protocols.clj:122 clojure.core.protocols/fn
  protocols.clj:19 clojure.core.protocols/fn[fn]


On Thursday, May 21, 2015 at 9:31:08 AM UTC-7, Alex Miller wrote:
>
> 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 would 
> silently drop all but the first spliced element).
>
> 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). The 
> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>
> - Alex
>

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Jason Wolfe]

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, Alex Miller wrote:
>
> 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 would 
> silently drop all but the first spliced element).
>
> 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). The 
> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>
> - Alex
>

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Andy Fingerhut]

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 
wrote:

> 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  > wrote:
>
>> 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
>>
>> P.S. May be it's offtopic, because I see the same behavior in Clojure
>> 1.5.1
>>
>> --
>> 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 group, send email to
>> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
>> 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 clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Andy Fingerhut]

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 
wrote:

> 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
>
> P.S. May be it's offtopic, because I see the same behavior in Clojure 1.5.1
>
> --
> 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 group, send email to
> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
> 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 clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-RC1 now available

[Sergey Didenko]

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

P.S. May be it's offtopic, because I see the same behavior in Clojure 1.5.1

-- 
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 group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.