Re: [ANN] Clojure 1.9.0-alpha4

[Martin Raison]

I support this change. Not only is it closer to the GIGO philosophy, but 
"let x in S" is actually a very reasonable use-case. Sometimes I just want 
an element from a set and I don't care about which particular one.

Your code may break if you're using try/catch to handle sets in a special 
way, but I can't imagine a situation where using clojure.core/set? wouldn't 
be simpler and more appropriate.

Le samedi 4 juin 2016 09:32:09 UTC-7, Atamert Ölçgen a écrit :
>
> Hi Alex,
>
> On Sat, Jun 4, 2016 at 3:22 PM, Alex Miller  > wrote:
>
>> Why?
>>
>
> Because unordered collections shouldn't have heads defined.
>
> Is (first #{3 1 2}) => 3? or 2? or 1?
>
> (I just tried it in a REPL and it is apparently 1.)
>
>  
>
>>
>> --
>> 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.
>>
>
>
>
> -- 
> Kind Regards,
> Atamert Ölçgen
>
> ◻◼◻
> ◻◻◼
> ◼◼◼
>
> www.muhuk.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: [ANN] core.async 0.2.374

[Martin Raison]

Thanks!

Le mercredi 11 novembre 2015 14:30:34 UTC-8, Alex Miller a écrit :
>
> Dependency info:  [org.clojure/core.async "0.2.374"]
>
> This release bumps the versions of all upstream dependencies. In 
> particular, this pulls in new versions of tools.analyzer.jvm, tools.reader, 
> etc.
>
> The following bug was fixed via the tools.analyzer.jvm update:
>
>- ASYNC-149  - Fix 
>compilation of recur in case in go block
>
>

-- 
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] core.async-0.2.371

[Martin Raison]

Awesome, thanks!

Le mercredi 28 octobre 2015 14:06:41 UTC-7, Alex Miller a écrit :
>
> I am happy to announce a long-overdue core.async release.
>
> Dependency info:  [org.clojure/core.async "0.2.371"]
>
> There are a few new features in this release:
>
> 1) *promise-chan* is a function that returns a new kind of channel (with 
> a custom buffer) with promise semantics. Specifically, channels make a 
> one-time transition to having a deliverable value. *promise-chan* takes 
> an optional transducer, and an optional exception-handler (like chan). A 
> promise channel can take exactly one value that consumers will receive. 
> Once full, puts complete but val is dropped (no transfer).
> Consumers will block until either a value is placed in the channel or the 
> channel is closed (and nil will be delivered). 
>
> 2) *offer!* and *poll!* are two new non-blocking functions available on 
> channels.
>
> offer! puts a val into a channel if it can do so immediately and will 
> never block. Returns true if offer succeeds.
> poll! takes a val from a channel if it can do so immediately and will 
> never block. Return a value if successful, nil otherwise.
>
> All changes:
>
>- ASYNC-103  - NEW 
>promise-chan
>- ASYNC-104  - NEW 
>non-blocking offer!, poll!
>- ASYNC-124  - dispatch 
>multiple pending takers resulting from expanding transducer
>- ASYNC-101  - 
>async/reduce now respects reduced
>- ASYNC-112  - replace 
>"transformer" with "transducer" in deprecation messages
>- ASYNC-6  - alts! docs 
>updated to explicitly state ports is a vector
>- Support (try (catch :default)) in CLJS exception handling
>- Use cljs.test
>- Updated tools.analyzer.jvm version (and other upstream deps) - fixes 
>various analyzer errors
>
>
>

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

[Martin Raison]

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

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



Le jeudi 15 octobre 2015 16:28:16 UTC-7, Mike Rodriguez a écrit :
>
> Someone else looked at the issue on 
> https://github.com/ztellman/riddley/issues/18
>
> This issue makes the current version of riddley, and therefore potemkin, 
> not work on Clojure 1.8 beta1
>
> There is a pull request to fix it at 
> https://github.com/ztellman/riddley/pull/19
>
> However I am wondering if it is going to affect more places. The problem 
> is that in Clojuee 1.8 APersistentVector now implements IMapEntry 
> (therefore j.u.Map$Entry as well), but it doesn't implement the key or val 
> methods. 
> What is the reason for that change and/or is this a desired side effect of 
> the change?
>
>

-- 
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] cats 1.0.0

[Martin Raison]

Great work!

Le jeudi 17 septembre 2015 04:47:42 UTC-7, Alejandro Gómez a écrit :
>
> Hello everyone, 
>
> I'm glad to announce the 1.0.0 release of cats[1], a library with 
> category theory 
> and algebraic abstractions for Clojure(Script). This release packs a lot 
> of new 
> features and it also has breaking changes. We're happy with the API and 
> we've settled 
> it in this 1.0.0 release, the next steps[2] are better context 
> management and improvements 
> to monad transformers. 
>
> Here's a full changelog[3] and the updated documentation[4] and API 
> reference[5]. 
>
> As always, any feedback is very welcome. 
>
> Cheers, 
>
> Al 
>
> [1]: https://github.com/funcool/cats 
> [2]: https://github.com/funcool/cats/issues 
> [3]: 
> https://github.com/funcool/cats/blob/master/CHANGELOG.md#version-100 
> [4]: https://funcool.github.io/cats/latest/ 
> [5]: https://funcool.github.io/cats/latest/api/ 
>

-- 
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: Using go/! like C#'s async/await

[Martin Raison]

Hey Thomas,

Thanks for the great feedback! A few clarifications below.
 

 It should be noted that your async macro does in fact use the dispatcher 
 just like a normal go would, the only difference is that it will start 
 executing immediately in the current thread until the first pause instead 
 of dispatching. After the pause the dispatcher will run it though which 
 is not guaranteed to be the same thread.


I agree that the dispatcher will eventually be used, but the idea is that 
if your code is deeply nested, this will only happen at the deepest level 
(when an actual go block is used). So the dispatcher will only be run 
there, instead of running for every single wrapping function call. The idea 
is for the codebase to look like this (across multiple functions):

(async ... (! (async ... (! (async ... (! (async ... (! (async ... (! 
(go long-running stuff, run in a different thread)))

Here the dispatcher is only run once, instead of 6 times. All the glue 
code is run in the calling thread.
 

 Therefore I'm not actually sure a ThreadLocal will work. Did you test that 
 you get the actual correct result?


I do get the correct result, although your concern is valid. I think it 
works because the generated state machine calls ioc/return-chan in the 
curent thread. If part of the computation has been dispatched to an other 
thread, then the result of that dispatched computation will be brought back 
into the current thread with an actual channel before being fed to 
ioc/return-chan. I would love to know if there are situations where 
return-chan would be called directly from another thread, since I haven't 
observed that so far and I'm not familiar enough with the state machine 
internals.
 

 Your benchmark is also not very useful, you are basically just measuring 
 the frameworks overhead which is tiny to what it provides. In actual 
 programs most of the time will not be spent in core.async internals, at 
 least not from what I have observed so far. go blocks are actually pretty 
 cheap.


Measuring the framework overhead was in fact my intention, but I agree it 
would be useful to know if the core.async overhead can actually be 
significant in a real-world application. Typically an IO-bound application 
passing lots of requests to other servers and doing very light 
transformation on the results.
 

-- 
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: Using go/! like C#'s async/await

[Martin Raison]

Fair point, thanks a lot for the insight. Any pointers to a significant 
data-flow oriented clojure codebase would be awesome, because that's not 
something I see a lot in the wild, and I'm still trying to wrap my head 
around how to implement this on a very complex system.

Le jeudi 30 juillet 2015 08:37:18 UTC-7, tbc++ a écrit :

 My advice is to treat channel ops (! and !) as IO, which they are. In 
 functional programming we try to stay away from doing IO deep down inside a 
 call stack. So don't do that. Instead use async/pipeline functions and 
 channel transducers to create pipelines and flow the data through them. 

 A sort of anti-pattern I see a lot is creating a lot of one-shot channels 
 and go blocks inside every function. The problem, as you see is that this 
 creates a lot of garbage. A much more efficient plan is to stop using 
 core.async as a RPC-like system, and start using it more like a dataflow 
 language: Identity data sources and sinks, and then transform and flow the 
 data between them via core.async. 

 It's interesting to note that core.async started as something that looked 
 a lot like C#'s Async/Await, but that was dropped in favor of CSP pretty 
 quickly. So there's reasons why the language isn't optimized for this sort 
 of programming style. 

 Timothy

 On Thu, Jul 30, 2015 at 9:17 AM, Martin Raison martin...@gmail.com 
 javascript: wrote:

 Hey Thomas,

 Thanks for the great feedback! A few clarifications below.
  

 It should be noted that your async macro does in fact use the dispatcher 
 just like a normal go would, the only difference is that it will start 
 executing immediately in the current thread until the first pause instead 
 of dispatching. After the pause the dispatcher will run it though which 
 is not guaranteed to be the same thread.


 I agree that the dispatcher will eventually be used, but the idea is that 
 if your code is deeply nested, this will only happen at the deepest level 
 (when an actual go block is used). So the dispatcher will only be run 
 there, instead of running for every single wrapping function call. The idea 
 is for the codebase to look like this (across multiple functions):

 (async ... (! (async ... (! (async ... (! (async ... (! (async ... 
 (! (go long-running stuff, run in a different thread)))

 Here the dispatcher is only run once, instead of 6 times. All the glue 
 code is run in the calling thread.
  

 Therefore I'm not actually sure a ThreadLocal will work. Did you test 
 that you get the actual correct result?


 I do get the correct result, although your concern is valid. I think it 
 works because the generated state machine calls ioc/return-chan in the 
 curent thread. If part of the computation has been dispatched to an other 
 thread, then the result of that dispatched computation will be brought back 
 into the current thread with an actual channel before being fed to 
 ioc/return-chan. I would love to know if there are situations where 
 return-chan would be called directly from another thread, since I haven't 
 observed that so far and I'm not familiar enough with the state machine 
 internals.
  

 Your benchmark is also not very useful, you are basically just measuring 
 the frameworks overhead which is tiny to what it provides. In actual 
 programs most of the time will not be spent in core.async internals, at 
 least not from what I have observed so far. go blocks are actually pretty 
 cheap.


 Measuring the framework overhead was in fact my intention, but I agree it 
 would be useful to know if the core.async overhead can actually be 
 significant in a real-world application. Typically an IO-bound application 
 passing lots of requests to other servers and doing very light 
 transformation on the results.
  

 -- 
 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 
 javascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/d/optout.




 -- 
 “One of the main causes of the fall of the Roman Empire was that–lacking 
 zero–they had no way to indicate successful termination of their C 
 programs.”
 (Robert Firth) 


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

Using go/! like C#'s async/await

[Martin Raison]

go blocks tend to spread in Clojure programs just like async/await in 
C#/Hack/Python, etc. The problem is that they aren't cheap.

I was curious to know what you guys think of the following workaround: 
http://blog.martinraison.com/clojure/2015/07/27/clojure-core-async-go-blocks-everywhere.html
(TL;DR: use go only in the few functions that do some actual work, in all 
other places use an alternate version - called async in the article - 
that doesn't use the dispatcher and doesn't create a chan. The only thing 
async does is handling the state machine stuff, so that !, alt!, etc 
work as expected.)

Does that seem reasonable or do you see a better way to do this?

-- 
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: core.async status?

[Martin Raison]

thanks!

Le samedi 4 juillet 2015 20:38:22 UTC-7, Alex Miller a écrit :

 Oh just busy. We will get to a new release at some point.

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

core.async status?

[Martin Raison]

I'm a big fan of core.async. Is there any specific roadmap for its 
development? The latest release has been 0.1.346.0-17112a-alpha for the 
past 9 months. Of course I perfectly understand if the answer is not 
enough time, not enough resources - I'm just hoping for a small status 
update, given how important this library is for the clojure ecosystem :)

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

CLJ-703 - 10x compilation time decrease after applying one-line patch, no downsides.

[Martin Raison]

Hi all,

This issue has been around for a while without much activity, although a 
very simple fix is already there: http://dev.clojure.org/jira/browse/CLJ-703

We have a pretty big Clojure project that we compile on machines with slow 
hard-drives, on CentOS 6. We noticed that compilation had become extremely 
slow, however CPU usage was always below 10%.

Simply removing the line cfs.getFD().sync(); inside 
src/jvm/clojure/lang/Compiler.java 
dramatically improved the compilation time (Something like 10x, although at 
this level of increase, measurement almost doesn't make sense anymore :)).

We've been using the suggested fix (remove-sync-only.patch) for a few weeks 
and haven't observed any issues.

It seems we should really figure out whether this line is actually 
necessary, or if it was added there just in case. Even if some situations 
require it, the speed bump is so huge that we might want some special-case 
logic.

Martin

-- 
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: CLJ-703 - 10x compilation time decrease after applying one-line patch, no downsides.

[Martin Raison]

I'm glad to hear that. Thanks!

Le vendredi 8 mai 2015 14:23:03 UTC-7, Alex Miller a écrit :

 Yes.


 On Friday, May 8, 2015 at 3:09:06 PM UTC-5, Andy Fingerhut wrote:

 Just to clarify, Alex, since your idea of next release might be 
 different than those who aren't following Clojure 1.7 alphas/betas/etc. 
 carefully.

 Do you mean hoping to look at it for Clojure 1.8, since Clojure 1.7 is 
 to the point of primarily fixing critical bugs and regressions ?

 Andy

 On Fri, May 8, 2015 at 12:07 PM, Alex Miller al...@puredanger.com 
 wrote:

 I'm hoping to look at it for the next release.

 Alex

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