Re: Issue when moving to Clojure 1.10

[Didier]

>
> I think the key is that if you are going to AOT, then everything you 
> depend on should be AOTed. The ideal place to do this is when you build the 
> final application - uberjar and aot the world. To do so, it’s best if libs 
> never AOT to give app compilers the opportunity to do so.
>

The build systems we rely on do not re-build dependent libraries 
unfortunately, and we don't use uberjar for our deployments either. Which 
means I can't delay the AOT to the last possible minute. Also, a lot of 
mixed projects happen, where Java needs the Clojure compiled classes at 
compile time. So these also can't be delayed AOT.

b) compiling only when dependent on things that are compiled
>

This is what we used to do, as we would compile everything, except Clojure 
now depends on something that isn't compiled, core specs, which causes 
conflicts. 

I'll modify our build tooling to somehow filter classes here, I already 
excluded the Clojure directory, so that solved our problem related to 
Clojure. Now I'm just wondering what is best going forward.

The transitive AOT compilation thing is a giant pain but there are ways 
> around it with tooling.
>

With tooling or with code changes? Because you mentioned writing your 
namespaces in a way so that gen-classes limit their AOT imact as much as 
possible. My issue is, I work at a very big company, and I maintain the 
Clojure build tools internally. I can't guide everyone to refactor their 
code to isolate their gen-classes, so I need to make the build tool as 
resilient as possible to all scenarios, assuming no control on the code.

So I have two options:

1) AOT everything all the time, but only include the current project 
classes in the resulting Jar.

2) AOT as little as possible, basically only namespaces with gen-class in 
them. And also only include the current project classes in the resulting 
Jar. Unless there is a dependency with protocol, now these should be 
transiently compiled as well, so I need to give a build options so people 
could specify to include certain transient namespaces into the Jar, in the 
case of protocols.

I'm personally leaning on one, as it seems like it should work in all 
cases. Am I forgetting something?

Regards!

On Saturday, 26 January 2019 15:04:33 UTC-8, Sean Corfield wrote:
>
> 2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9
>
>  
>
> My approach is to isolate the pieces that need to be AOT compiled to as 
> few namespaces as possible and have them only depend on other namespaces at 
> runtime, i.e., avoid :require in the ns clause where possible and use 
> require/resolve in the AOT-compiled functions to get at the larger body of 
> Clojure code. And, of course, to try to avoid gen-class as much as possible 
> too  
>
>  
>
> The transitive AOT compilation thing is a giant pain but there are ways 
> around it with tooling.
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Didier >
> *Sent:* Friday, January 25, 2019 10:11:45 PM
> *To:* Clojure
> *Subject:* Re: Issue when moving to Clojure 1.10 
>  
> So I got to the bottom bottom of the problem here.
>
> This is a scenario:
>
> 1) Library A depends on library B and Clojure 1.10
> 2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9
> 3) Library A does not work, because it is now using the Clojure core spec 
> 1.9 compiled transitively through the Library B AOT, and found in its Jar, 
> since .class get precedence over source files.
>
> So, this means that a library with a dependency on another one that is AOT 
> can cause spec conflicts.
>
> This is new now that spec is out. And so I first caught this when some of 
> our libs were using 1.9, and I started moving others to 1.10.
>
> The way I solved this is by hacking our build, so that the clojure 
> compiled classes from the AOT don't get included in the Jar after they are 
> compiled.
>
> In my opinion, this is a bit of a problem. What would be nice is either to 
> have a way to compile only a gen-class, and not the namespace that contains 
> it. Or not compile things transitively. Or maybe just a way for compile to 
> exclude clojure core namespaces.
>
> Now, if you depend on libraries that don't need AOT, it is not an issue. 
> But if you do, it forces you to re-compile all your dependencies and do a 
> full big bang upgrade to the new Clojure version. You can't just use libs 
> compiled with older versions of spec. While before, you were able to use 
> libs compiled with older version of Clojure from packages that use newer 
> version of Clojure.
>
> On Wednesday, 16 January 2019 20:47:43 UTC-8, Mark Derricutt wrote: 
>>
>> On 16 Jan 2019, at 18:17, Alex Miller wrote:
>>
>> Yes, it's one of the downsides of AOT. 
>>
>> I'd say it's not so 

Re: Noob question on the --> macro implementation

[Gary Fredericks]

There's probably also a difference in what happens if the form is empty. 
The current impl results in a compile error about calling nil, whereas the 
suggested implementation would result in calling the current thread value 
as a function, I think.

On Saturday, January 26, 2019 at 5:13:23 PM UTC-6, Sean Corfield wrote:
>
> I suspect it’s done for consistency with the source of -> (which has to 
> use first/next because it threads the expression between them) – using 
> first/next/x in ->> is therefore a closer parallel to using first/x/next in 
> -> so it’s easier to see the similarity (and correctness) of the code.
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of James Reeves  >
> *Sent:* Saturday, January 26, 2019 11:08:25 AM
> *To:* clo...@googlegroups.com 
> *Subject:* Re: Noob question on the --> macro implementation 
>  
> I believe he's just saying it's simpler and possibly more efficient.
>
> Unless I'm missing something subtle in the way this is resolved, I believe 
> Ujjwal is right that:
>
> `(~(first form) ~@(next form) ~x)
>
> Is equivalent to:
>
> `(~@form ~x)
>
> On Sat, 26 Jan 2019 at 19:04, Andy Fingerhut  > wrote:
>
>> When you ask "am I right?" about your proposed change, what is it that 
>> the current behavior does not do, that your change would do?  Do you have 
>> some use case in mind that works with your change, but doesn't with the 
>> current implementation? 
>>
>> Andy
>>
>> On Sat, Jan 26, 2019 at 10:50 AM Ujjwal Thaakar > > wrote:
>>
>>> Hi, 
>>> I'm trying to learn Clojure and I just curiously typed  
>>> (source ->>)
>>>  in the REPL and was wondering about this: 
>>> https://github.com/clojure/clojure/commit/749a0ad8b66c781d8176833f0ad26cfe6b9b24e3#r32075784
>>>
>>> Am I missing something?
>>>
>>> -- 
>>> 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 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.
>>
>
>
> -- 
> James Reeves 
> booleanknot.com
>
> -- 
> 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: r/fold combinef and reducef init values

[Sean Corfield]

Ah, yes… So this line…

The reducef function will be called with no arguments to produce an identity 
value in each partition.

…needs updating/removing.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Brian 
Craft 
Sent: Saturday, January 26, 2019 2:02:42 PM
To: Clojure
Subject: Re: r/fold combinef and reducef init values

hey Sean -- The ones on the reducers reference page:

https://clojure.org/reference/reducers

On Friday, January 25, 2019 at 4:05:12 PM UTC-8, Sean Corfield wrote:
Which docs are you reading? The docstring for r/fold says this – with no 
indication of calling (reducef) with no arguments (well, unless you do not 
supply combinef – in which case reducef will be used for that, so (reducef) 
would be called to seed the reductions):

"Reduces a collection using a (potentially parallel) reduce-combine
  strategy. The collection is partitioned into groups of approximately
  n (default 512), each of which is reduced with reducef (with a seed
  value obtained by calling (combinef) with no arguments). The results
  of these reductions are then reduced with combinef (default
  reducef). combinef must be associative, and, when called with no
  arguments, (combinef) must produce its identity element. These
  operations may be performed in parallel, but the results will
  preserve order."

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

From: Brian Craft
Sent: Friday, January 25, 2019 3:36 PM
Subject: r/fold combinef and reducef init values

>From the docs:

r/fold takes a reducible collection and partitions it into groups of 
approximately n (default 512) elements. Each group is reduced using the reducef 
function. The reducef function will be called with no arguments to produce an 
identity value in each partition. The results of those reductions are then 
reduced with the combinef (defaults to reducef) function. When called with no 
arguments, (combinef) must produce its identity element - this will be called 
multiple times. Operations may be performed in parallel. Results will preserve 
order.

So, this seems to say r/fold will partition the collection and reduce each 
partition using the (reducef) as the init value.

Then, all these intermediate results will be reduced with combinef, using 
(combinef) as the init value.

However, in test it seems (reducef) is never called, and (combinef) is used as 
the init value for calls to reducef.

  (defn combinef
([] {:combine :f})
([acc v] acc))

  (defn reducef
([] {:reduce :f})
([acc v]
 (println "acc" acc "v" v)
 v))

  (clojure.core.reducers/fold combinef reducef ["foo" "bar"])

; outputs:
acc {:combine :f} v foo
acc foo v bar
"bar"

The accumulator in reducef is the init value from combinef, not the init value 
from reducef.

What's going on?
--
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.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 

RE: Noob question on the --> macro implementation

[Sean Corfield]

I suspect it’s done for consistency with the source of -> (which has to use 
first/next because it threads the expression between them) – using first/next/x 
in ->> is therefore a closer parallel to using first/x/next in -> so it’s 
easier to see the similarity (and correctness) of the code.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of James 
Reeves 
Sent: Saturday, January 26, 2019 11:08:25 AM
To: clojure@googlegroups.com
Subject: Re: Noob question on the --> macro implementation

I believe he's just saying it's simpler and possibly more efficient.

Unless I'm missing something subtle in the way this is resolved, I believe 
Ujjwal is right that:

`(~(first form) ~@(next form) ~x)

Is equivalent to:

`(~@form ~x)

On Sat, 26 Jan 2019 at 19:04, Andy Fingerhut 
mailto:andy.finger...@gmail.com>> wrote:
When you ask "am I right?" about your proposed change, what is it that the 
current behavior does not do, that your change would do?  Do you have some use 
case in mind that works with your change, but doesn't with the current 
implementation?

Andy

On Sat, Jan 26, 2019 at 10:50 AM Ujjwal Thaakar 
mailto:ujjwalthaa...@gmail.com>> wrote:
Hi,
I'm trying to learn Clojure and I just curiously typed
(source ->>)
 in the REPL and was wondering about this: 
https://github.com/clojure/clojure/commit/749a0ad8b66c781d8176833f0ad26cfe6b9b24e3#r32075784

Am I missing something?

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


--
James Reeves
booleanknot.com

--
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: Issue when moving to Clojure 1.10

[Sean Corfield]

2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9

My approach is to isolate the pieces that need to be AOT compiled to as few 
namespaces as possible and have them only depend on other namespaces at 
runtime, i.e., avoid :require in the ns clause where possible and use 
require/resolve in the AOT-compiled functions to get at the larger body of 
Clojure code. And, of course, to try to avoid gen-class as much as possible too 


The transitive AOT compilation thing is a giant pain but there are ways around 
it with tooling.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Didier 

Sent: Friday, January 25, 2019 10:11:45 PM
To: Clojure
Subject: Re: Issue when moving to Clojure 1.10

So I got to the bottom bottom of the problem here.

This is a scenario:

1) Library A depends on library B and Clojure 1.10
2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9
3) Library A does not work, because it is now using the Clojure core spec 1.9 
compiled transitively through the Library B AOT, and found in its Jar, since 
.class get precedence over source files.

So, this means that a library with a dependency on another one that is AOT can 
cause spec conflicts.

This is new now that spec is out. And so I first caught this when some of our 
libs were using 1.9, and I started moving others to 1.10.

The way I solved this is by hacking our build, so that the clojure compiled 
classes from the AOT don't get included in the Jar after they are compiled.

In my opinion, this is a bit of a problem. What would be nice is either to have 
a way to compile only a gen-class, and not the namespace that contains it. Or 
not compile things transitively. Or maybe just a way for compile to exclude 
clojure core namespaces.

Now, if you depend on libraries that don't need AOT, it is not an issue. But if 
you do, it forces you to re-compile all your dependencies and do a full big 
bang upgrade to the new Clojure version. You can't just use libs compiled with 
older versions of spec. While before, you were able to use libs compiled with 
older version of Clojure from packages that use newer version of Clojure.

On Wednesday, 16 January 2019 20:47:43 UTC-8, Mark Derricutt wrote:

On 16 Jan 2019, at 18:17, Alex Miller wrote:

Yes, it's one of the downsides of AOT.

I'd say it's not so much a downside of AOT - but of having a single output path 
for classes. I've long wanted Chas's patch to be applied, or something like it.

Having everyone reinvent the mechanism whenever they happen to need AOT is kind 
of annoying - rare, but still annoying.



"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time." — Mark 
Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

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

partition & fold

[Brian Craft]

Still trying to understand reducers & transducers. Is the difference 
between r/folder and r/reducer the parallelization?

Anyone know what this error is about?

(r/foldcat (r/map #(apply + %) (r/folder (into [] (range 1000)) 
(partition-all 5

ArrayIndexOutOfBoundsException 47427  java.util.ArrayList.add 
(ArrayList.java:459)

Is this error to do with partition-all being stateful?

This works as expected, with reducer instead of folder:

(r/foldcat (r/map #(apply + %) (r/reducer (into [] (range 1000)) 
(partition-all 5  ; XXX large output


Is there some way to express "map over partitions, in parallel, without 
creating an intermediate collection" with reducers and transducers?

-- 
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: r/fold combinef and reducef init values

[Brian Craft]

hey Sean -- The ones on the reducers reference page:

https://clojure.org/reference/reducers

On Friday, January 25, 2019 at 4:05:12 PM UTC-8, Sean Corfield wrote:

> Which docs are you reading? The docstring for r/fold says this – with no 
> indication of calling (reducef) with no arguments (well, unless you do not 
> supply combinef – in which case reducef will be used for that, so (reducef) 
> would be called to seed the reductions):
>
>  
>
> "Reduces a collection using a (potentially parallel) reduce-combine
>
>   strategy. The collection is partitioned into groups of approximately
>
>   n (default 512), each of which is reduced with reducef (with a seed
>
>   value obtained by calling (combinef) with no arguments). The results
>
>   of these reductions are then reduced with combinef (default
>
>   reducef). combinef must be associative, and, when called with no
>
>   arguments, (combinef) must produce its identity element. These
>
>   operations may be performed in parallel, but the results will
>
>   preserve order."
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
>
> *From: *Brian Craft 
> *Sent: *Friday, January 25, 2019 3:36 PM
> *Subject: *r/fold combinef and reducef init values
>
>  
>
> From the docs: 
>
>  
>
> r/fold takes a reducible collection and partitions it into groups of 
> approximately n (default 512) elements. Each group is reduced using the 
> reducef function. The reducef function will be called with no arguments to 
> produce an identity value in each partition. The results of those 
> reductions are then reduced with the combinef (defaults to reducef) 
> function. When called with no arguments, (combinef) must produce its 
> identity element - this will be called multiple times. Operations may be 
> performed in parallel. Results will preserve order.
>
>  
>
> So, this seems to say r/fold will partition the collection and reduce each 
> partition using the (reducef) as the init value.
>
>  
>
> Then, all these intermediate results will be reduced with combinef, using 
> (combinef) as the init value.
>
>  
>
> However, in test it seems (reducef) is never called, and (combinef) is 
> used as the init value for calls to reducef.
>
>  
>
>   (defn combinef
>
> ([] {:combine :f})
>
> ([acc v] acc))
>
>  
>
>   (defn reducef
>
> ([] {:reduce :f})
>
> ([acc v]
>
>  (println "acc" acc "v" v)
>
>  v))
>
>  
>
>   (clojure.core.reducers/fold combinef reducef ["foo" "bar"])
>
>  
>
> ; outputs:
>
> acc {:combine :f} v foo
>
> acc foo v bar
>
> "bar"
>
>  
>
> The accumulator in reducef is the init value from combinef, not the init 
> value from reducef.
>
>  
>
> What's going on?
>
> -- 
> 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: Noob question on the --> macro implementation

[James Reeves]

I believe he's just saying it's simpler and possibly more efficient.

Unless I'm missing something subtle in the way this is resolved, I believe
Ujjwal is right that:

`(~(first form) ~@(next form) ~x)

Is equivalent to:

`(~@form ~x)

On Sat, 26 Jan 2019 at 19:04, Andy Fingerhut 
wrote:

> When you ask "am I right?" about your proposed change, what is it that the
> current behavior does not do, that your change would do?  Do you have some
> use case in mind that works with your change, but doesn't with the current
> implementation?
>
> Andy
>
> On Sat, Jan 26, 2019 at 10:50 AM Ujjwal Thaakar 
> wrote:
>
>> Hi,
>> I'm trying to learn Clojure and I just curiously typed
>> (source ->>)
>>  in the REPL and was wondering about this:
>> https://github.com/clojure/clojure/commit/749a0ad8b66c781d8176833f0ad26cfe6b9b24e3#r32075784
>>
>> Am I missing something?
>>
>> --
>> 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.
>


-- 
James Reeves
booleanknot.com

-- 
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: Noob question on the --> macro implementation

[Andy Fingerhut]

When you ask "am I right?" about your proposed change, what is it that the
current behavior does not do, that your change would do?  Do you have some
use case in mind that works with your change, but doesn't with the current
implementation?

Andy

On Sat, Jan 26, 2019 at 10:50 AM Ujjwal Thaakar 
wrote:

> Hi,
> I'm trying to learn Clojure and I just curiously typed
> (source ->>)
>  in the REPL and was wondering about this:
> https://github.com/clojure/clojure/commit/749a0ad8b66c781d8176833f0ad26cfe6b9b24e3#r32075784
>
> Am I missing something?
>
> --
> 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.

Noob question on the --> macro implementation

[Ujjwal Thaakar]

Hi,
I'm trying to learn Clojure and I just curiously typed 
(source ->>)
 in the REPL and was wondering about this: 
https://github.com/clojure/clojure/commit/749a0ad8b66c781d8176833f0ad26cfe6b9b24e3#r32075784

Am I missing something?

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

[ANN] com.cognitect.aws/api-0.8.223

[David Chelimsky]

com.cognitect.aws/api-0.8.223 is now available

CHANGES
   
   - support endpoint-override #43 
   
   - parse "map" shapes using their key spec instead of assuming keyword 
   keys #50 
   - wrap non-sequential values when the spec calls for a list #45 
   
   - config parsing bug fixes #46 
   , #48 
   
   - support refreshing credentials #47 
   

Repo: https://github.com/cognitect-labs/aws-api/
Changelog: https://github.com/cognitect-labs/aws-api/blob/master/CHANGES.md
Latest Releases of api, endpoints, and all services: 
https://github.com/cognitect-labs/aws-api/blob/master/latest-releases.edn

-- 
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: Issue when moving to Clojure 1.10

[Alex Miller]

> On Jan 26, 2019, at 12:43 AM, Didier  wrote:
> 
> Okay, so after reading through the linked issue here: 
> https://dev.clojure.org/jira/browse/CLJ-322 I'm not sure, as a tool builder, 
> what is the ideal path forward.
> 
> This is what I seem to understand would be ideal, let me know if I'm wrong:
> 
> 1) AOT compile everything. So basically, always AOT every lib. This is to 
> make sure that we don't face this issue: 
> https://dev.clojure.org/jira/browse/CLJ-1544
> 

I think the key is that if you are going to AOT, then everything you depend on 
should be AOTed. The ideal place to do this is when you build the final 
application - uberjar and aot the world. To do so, it’s best if libs never AOT 
to give app compilers the opportunity to do so.

> 2) Figure out some mechanism within the built tooling to only include the 
> classes for which the source exist in the current project being built into 
> the resulting Jar. Meaning, only namespaces found in the source folder should 
> have their compiled classes be included into the Jar.

You can avoid this by a) not aot compiling or b) compiling only when dependent 
on things that are compiled, in which case new classes are only your lib. But 
some tools (like the Maven Clojure plugin) do have the ability to filter which 
aot’ed classes you include.

> 
> This setup should minimize conflicts, from what I understand. The only thing 
> I'm not sure about is, are classes compiled with an older version of Clojure 
> and JDK always going to work with a newer version of Clojure and JDK?

As much as possible, yes. But we don’t guarantee it. So again, make the compile 
decision as late as possible.

> 
>> On Friday, 25 January 2019 22:11:46 UTC-8, Didier wrote:
>> So I got to the bottom bottom of the problem here.
>> 
>> This is a scenario:
>> 
>> 1) Library A depends on library B and Clojure 1.10
>> 2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9
>> 3) Library A does not work, because it is now using the Clojure core spec 
>> 1.9 compiled transitively through the Library B AOT, and found in its Jar, 
>> since .class get precedence over source files.
>> 
>> So, this means that a library with a dependency on another one that is AOT 
>> can cause spec conflicts.
>> 
>> This is new now that spec is out. And so I first caught this when some of 
>> our libs were using 1.9, and I started moving others to 1.10.
>> 
>> The way I solved this is by hacking our build, so that the clojure compiled 
>> classes from the AOT don't get included in the Jar after they are compiled.
>> 
>> In my opinion, this is a bit of a problem. What would be nice is either to 
>> have a way to compile only a gen-class, and not the namespace that contains 
>> it. Or not compile things transitively. Or maybe just a way for compile to 
>> exclude clojure core namespaces.
>> 
>> Now, if you depend on libraries that don't need AOT, it is not an issue. But 
>> if you do, it forces you to re-compile all your dependencies and do a full 
>> big bang upgrade to the new Clojure version. You can't just use libs 
>> compiled with older versions of spec. While before, you were able to use 
>> libs compiled with older version of Clojure from packages that use newer 
>> version of Clojure.
>> 
>>> On Wednesday, 16 January 2019 20:47:43 UTC-8, Mark Derricutt wrote:
>>> On 16 Jan 2019, at 18:17, Alex Miller wrote:
>>> 
>>> Yes, it's one of the downsides of AOT. 
>>> 
>>> I'd say it's not so much a downside of AOT - but of having a single output 
>>> path for classes. I've long wanted Chas's patch to be applied, or something 
>>> like it.
>>> 
>>> Having everyone reinvent the mechanism whenever they happen to need AOT is 
>>> kind of annoying - rare, but still annoying.
>>> 
>>> "The ease with which a change can be implemented has no relevance at all to 
>>> whether it is the right change for the (Java) Platform for all time." — 
>>> Mark Reinhold.
>>> 
>>> Mark Derricutt
>>> http://www.theoryinpractice.net
>>> http://www.chaliceofblood.net
>>> http://plus.google.com/+MarkDerricutt
>>> http://twitter.com/talios
>>> http://facebook.com/mderricutt
>>> 
> 
> -- 
> 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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/qIA7GoAVtbE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received