Re: Help with strange test output when deftest used inside a macro

[Gary Verhaegen]

is is looking for specific patterns and, if it can't find a known one, defaults 
to assuming its argument is a random predicate and prints that.

So what's happening here is the syntax quote expands (resolves) = to 
clojure.core/= and thus it doesn't match the pattern for = anymore.

So you'd need for = to not be expanded and stay as exactly the = symbol after 
macroexpansion. There are various ways to achieve that, but I can't think of a 
generic, elegant one. In the trivial example you posted you can just replace = 
with ~'=, I think, though that might not be so easy on more complex macros.

You can also take a look at the assert-expr and report multimethods in 
clojure.test.

> On 9 Oct 2017, at 22:32, Timothy Baldridge  wrote:
> 
> The problem isn't the macro, it's your use of syntax quoting. `(= x y) gets 
> expanded at read-time into `(clojure.core/= x y)`. Not much you can do about 
> that. Although I'd suggest perhaps changing your code a bit to not require 
> macros. 
> 
> deftest mostly just creates a defn with some extra metadata and the like. One 
> option would be to use a dynamic var to setup your config information. Or 
> better yet have the test itself read the config data the way your normal app 
> would. This not only exercises the same config codepaths, but it also keeps 
> the code quite functional. 
> 
>> On Mon, Oct 9, 2017 at 2:40 PM, Matt Grimm  wrote:
>> Hello,
>> 
>> I'm generating deftest's using a helper macro that takes a variety of test 
>> parameters and though the tests function correctly, the output of a failed 
>> test is not exactly right. The expect value is shown as the un-evaluated 
>> test form, and the actual value is shown as the result of evaluating the 
>> test form. I realize 'is' is a macro itself, but I'm not quite sure how to 
>> expand or escape the guts of my macro to make the output match that of a 
>> normal test.
>> 
>> Whereas a normal test failure looks like this (some output elided):
>> 
>> user=> (deftest normal-test
>>   #_=>   (is (= [0 1 5] (range 3
>> #'user/normal-test
>> user=> (run-tests)
>> 
>> FAIL in (normal-test)
>> 
>> expected: [0 1 5]
>>   actual: ((0 1 2))
>> 
>> A failure for a deftest defined within a macro comes out like this:
>> 
>> user=> (defmacro defnesttest [v]
>>   #_=>   `(deftest nested-test
>>   #_=>  (is (= [0 1 5] ~v
>> #'user/defnesttest
>> user=> (defnesttest (range 3))
>> #'user/nested-test
>> user=> (run-tests)
>> 
>> FAIL in (nested-test)
>> 
>> expected: (clojure.core/= [0 1 5] (range 3))
>>   actual: false
>> 
>> Thanks for any insight,
>> m.
>> -- 
>> 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.
> 
> 
> 
> -- 
> “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+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: Is there a better way to get to `Classname[].class` ?

[Gary Verhaegen]

What Alex suggested is probably the best approach here. Note: there's a typo in 
my message, the name of the class needs to be as Alex says for the type hint 
too, i.e. the L and ; are essential for this to work.

> On 9 Oct 2017, at 18:31, pericles macedo  wrote:
> 
> Hey Gary, thanks for the help
> I'm not sure if a type hint would work in this case, as the attribute expect 
> a class literal, and not a variable of that specific class. Thanks for the 
> example though, I didn't know that was a valid type hint.
> About what I'm trying to do, I'm using a gitlab api gem 
> (https://github.com/timols/java-gitlab-api), and I need to do some java 
> interop with it.
> I'm trying to get a list of projects filtered by name, but the call java does 
> doesn't build the search attribute, so I just get all projects, not filtered 
> by name.
> I'm able to get on java by using something like 
> `connection.retrieve().getAll(buildUrl(project), GitlabProject[].class);`. 
> The getAll expects a string, and a class literal.
> If the return from gitlab wasn't an array, I could just use GitlabProject on 
> clojure, and that would give me a result. As it's an array, I get an error 
> showing it can't build a GitlabProject out of ARRAY_START.
> 
> My solution to make that call was 
> (def get-project  
>  
> (memoize  
> 
>   (fn [project]   
>
> (-> connection
>
> .retrieve 
>   
> (.getAll (build-url project) (array-class-for 
> GitlabProject)) 
>   
>
> (defn array-class-for [class-name]
> 
>   (class (make-array class-name 1)))
> 
> 
> 
>> On Monday, October 9, 2017 at 9:20:37 AM UTC-7, Gary Verhaegen wrote:
>> You can generally use ^"[fully.qualified.ClassName" as the type hint, if 
>> that's what you're trying to do. I'm not quite sure of the benefits of 
>> typing an array when it's not a primitive one, though.
>> 
>> What are you trying to accomplish, if we zoom back a little bit? Maybe 
>> there's a better way to do whatever you're trying to do.
>> 
>>> On 9 Oct 2017, at 16:36, pericles macedo  wrote:
>>> 
>>> Hey Guys,
>>> I wanted to know if there is a better way to get to the same result as 
>>> `GitlabProject[].class`
>>> after some digging around, I got to this array of class definition by doing 
>>> something like `(class (make-array GitlabProject 1))`. But I don't know if 
>>> there is a better way to get to this same result. 
>>> In Java, this array of class is sent as an attribute that is used to build 
>>> the array of objects that is returned. like: `retrieve().getAll(tailUrl, 
>>> GitlabProject[].class);`
>>> 
>>> 
>>> Thanks for your time,
>>> Pericles Dantas
>>> -- 
>>> 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 em

Re: any? in clojure 1.9.0 alpha

[Gordon Syme]

With respect, I have searched prior conversations and have not found a 
justification for why any? is in clojure.core rather than clojure.spec.

All the problems people have raised with any? are due to it be a predicate with 
a very specific use-case (defining specs) but placed in a namespace where it 
masquerades as general purpose.

In clojure.spec any? could have a docstring documenting its intent for speccing 
which would be a great help for new folks.

With a terse, general purpose docstring in clojure.core it leads to confusion, 
semantic mismatches and becomes yet another "gotcha" for new Clojure developers.

I understand that there are more constraints in the development of the language 
and its core libraries than we are exposed to, and that this conversation is 
frustrating for you, but please take note that the Clojure community is trying 
hard to collaborate on this issue.

Respectfully

-Gordon

-- 
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: Is there a better way to get to `Classname[].class` ?

[Peter Hull]

I actually preferred your solution, pericles, because it doesn't require 
memorising the "[L...;" syntax, and works if you don't know the class at 
compile time. By the way you can use make-array to create a zero size array 
which might be (ever so slightly) more efficient.

For reference (apologies if you already knew this), the class name syntax 
is outlined here:
https://docs.oracle.com/javase/9/docs/api/java/lang/Class.html#getName--
and for the full details
https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.9.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.

Re: any? in clojure 1.9.0 alpha

[Jozef Wagner]

Clojure isn't for the most part a community effort therefore decisions 
about the language and it's core library are seldom made in the 
collaboration with the community.

In my opinion, if you want your language change proposal to be considered, 
you have to justify and back it up by a strong real world scenario.

>From my experience, help from the community to the Clojure language itself 
is most sought in the areas of bugfixing and documentation and performance 
improvements.

Jozef

On Tuesday, October 10, 2017 at 11:42:42 AM UTC+2, Gordon Syme wrote:
>
> With respect, I have searched prior conversations and have not found a 
> justification for why any? is in clojure.core rather than clojure.spec.
>
> All the problems people have raised with any? are due to it be a predicate 
> with a very specific use-case (defining specs) but placed in a namespace 
> where it masquerades as general purpose.
>
> In clojure.spec any? could have a docstring documenting its intent for 
> speccing which would be a great help for new folks.
>
> With a terse, general purpose docstring in clojure.core it leads to 
> confusion, semantic mismatches and becomes yet another "gotcha" for new 
> Clojure developers.
>
> I understand that there are more constraints in the development of the 
> language and its core libraries than we are exposed to, and that this 
> conversation is frustrating for you, but please take note that the Clojure 
> community is trying hard to collaborate on this issue.
>
> Respectfully
>
> -Gordon
>
>

-- 
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: Help with strange test output when deftest used inside a macro

[Matt Grimm]

Excellent, thanks! The actual macro is indeed a little more complicated, 
but the test assertions are limited to (is (= ...)), so replacing = with 
~'= works perfectly.

On Tuesday, October 10, 2017 at 3:10:37 AM UTC-6, Gary Verhaegen wrote:
>
> is is looking for specific patterns and, if it can't find a known one, 
> defaults to assuming its argument is a random predicate and prints that.
>
> So what's happening here is the syntax quote expands (resolves) = to 
> clojure.core/= and thus it doesn't match the pattern for = anymore.
>
> So you'd need for = to not be expanded and stay as exactly the = symbol 
> after macroexpansion. There are various ways to achieve that, but I can't 
> think of a generic, elegant one. In the trivial example you posted you can 
> just replace = with ~'=, I think, though that might not be so easy on more 
> complex macros.
>
> You can also take a look at the assert-expr and report multimethods in 
> clojure.test.
>
> On 9 Oct 2017, at 22:32, Timothy Baldridge  > wrote:
>
> The problem isn't the macro, it's your use of syntax quoting. `(= x y) 
> gets expanded at read-time into `(clojure.core/= x y)`. Not much you can do 
> about that. Although I'd suggest perhaps changing your code a bit to not 
> require macros. 
>
> deftest mostly just creates a defn with some extra metadata and the like. 
> One option would be to use a dynamic var to setup your config information. 
> Or better yet have the test itself read the config data the way your normal 
> app would. This not only exercises the same config codepaths, but it also 
> keeps the code quite functional. 
>
> On Mon, Oct 9, 2017 at 2:40 PM, Matt Grimm  > wrote:
>
>> Hello,
>>
>> I'm generating deftest's using a helper macro that takes a variety of 
>> test parameters and though the tests function correctly, the output of a 
>> failed test is not exactly right. The expect value is shown as the 
>> un-evaluated test form, and the actual value is shown as the result of 
>> evaluating the test form. I realize 'is' is a macro itself, but I'm not 
>> quite sure how to expand or escape the guts of my macro to make the output 
>> match that of a normal test.
>>
>> Whereas a normal test failure looks like this (some output elided):
>>
>> user=> (deftest normal-test
>>   #_=>   (is (= [0 1 5] (range 3
>> #'user/normal-test
>> user=> (run-tests)
>>
>> FAIL in (normal-test)
>>
>> expected: [0 1 5]
>>   actual: ((0 1 2)) 
>>
>> A failure for a deftest defined within a macro comes out like this:
>>
>> user=> (defmacro defnesttest [v]
>>   #_=>   `(deftest nested-test
>>   #_=>  (is (= [0 1 5] ~v
>> #'user/defnesttest
>> user=> (defnesttest (range 3))
>> #'user/nested-test
>> user=> (run-tests)
>>
>> FAIL in (nested-test)
>>
>> expected: (clojure.core/= [0 1 5] (range 3))
>>   actual: false
>>
>> Thanks for any insight,
>> m.
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> “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 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 
"Cloj

Updating repeated nested structures?

[Rob Nikander]

Hi,

Say I have a map like this:

(def m {:qs [{:nums [3 1 2]} {:nums [7 4]}]})

I want to transform each number with a function (say, `inc`). I imagine 
something like this:

(update-in m [:qs * :cell-fns] #(map inc %))  
; or 
(update-in m [:qs * :cell-fns *] inc)  


But of course you can't write that.  The following code works, but I don't 
like reading it:

(update m :qs   
(fn [qs]
  (mapv
(fn [q] 
  (update q :nums #(mapv inc %)))
qs)))
=> {:qs [{:nums [4 2 3]} {:nums [8 5]}]}

Is there an idiomatic way to do this, that looks more like the shorter 
`update-in` idea?

Rob



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

About determinism of async

[JokkeB]

I'm wondering about a case when using async:

I have a channel where I write from multiple threads. One of the sources is 
a go-loop with a timeout, so each second I write something to the channel. 
If I do two consecutive writes inside the go block, can another thread 
write between the two writes? Or can I rely on the two messages being 
consecutive in the channel?

-- 
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: About determinism of async

[Gary Trakhman]

I think a core assumption is that all writes can yield control at any time
to other worker go processes.  I wouldn't rely on the consecutive behavior
even if it were true, nondeterminism is a good assumption with core.async.
If you need that particular guarantee, consider a call to partition?

On Tue, Oct 10, 2017 at 10:30 AM JokkeB  wrote:

> I'm wondering about a case when using async:
>
> I have a channel where I write from multiple threads. One of the sources
> is a go-loop with a timeout, so each second I write something to the
> channel. If I do two consecutive writes inside the go block, can another
> thread write between the two writes? Or can I rely on the two messages
> being consecutive in the channel?
>
> --
> 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: About determinism of async

[JokkeB]

Thanks for the response. That's what I suspected.

How does partition help me in this case? I can't see any way of using it.

How about onto-chan, would that be deterministic? Or any other function?

tiistai 10. lokakuuta 2017 17.33.22 UTC+3 Gary Trakhman kirjoitti:
>
> I think a core assumption is that all writes can yield control at any time 
> to other worker go processes.  I wouldn't rely on the consecutive behavior 
> even if it were true, nondeterminism is a good assumption with core.async.  
> If you need that particular guarantee, consider a call to partition?
>
> On Tue, Oct 10, 2017 at 10:30 AM JokkeB > 
> wrote:
>
>> I'm wondering about a case when using async:
>>
>> I have a channel where I write from multiple threads. One of the sources 
>> is a go-loop with a timeout, so each second I write something to the 
>> channel. If I do two consecutive writes inside the go block, can another 
>> thread write between the two writes? Or can I rely on the two messages 
>> being consecutive in the channel?
>>
>> -- 
>> 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: Updating repeated nested structures?

[Timothy Baldridge]

My answer to most of these questions is often "write it once, stuff it in a
function, and forget about it".

Really though I often see this as a data-modeling and naming problem. For
example, you could go and write a `(update-cells cell-list f & args)` that
wraps custom logic for finding and manipulating cells.

In addition, think about ways to flatten the structure. It's a little hard
to figure out what you're trying to do here, but in general try to keep
data one or two layers deep, not only is it easier to manipulate, but it's
also easier to reason about. Once you get 3-4 layers deep in hashmaps, it
gets a bit messy, regardless of the tools you're using.



On Tue, Oct 10, 2017 at 2:18 PM, Rob Nikander 
wrote:

> Hi,
>
> Say I have a map like this:
>
> (def m {:qs [{:nums [3 1 2]} {:nums [7 4]}]})
>
> I want to transform each number with a function (say, `inc`). I imagine
> something like this:
>
> (update-in m [:qs * :cell-fns] #(map inc %))
> ; or
> (update-in m [:qs * :cell-fns *] inc)
>
>
> But of course you can't write that.  The following code works, but I don't
> like reading it:
>
> (update m :qs
> (fn [qs]
>   (mapv
> (fn [q]
>   (update q :nums #(mapv inc %)))
> qs)))
> => {:qs [{:nums [4 2 3]} {:nums [8 5]}]}
>
> Is there an idiomatic way to do this, that looks more like the shorter
> `update-in` idea?
>
> Rob
>
>
>
> --
> 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.
>



-- 
“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+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: About determinism of async

[Gary Trakhman]

So, at the point where you need 2 things to be consecutive, wrap them up in
a vector so they're one thing. `(partition-all 2)` will return a transducer
xform that chunks up your message stream by 2
https://clojuredocs.org/clojure.core/partition-all, and if you need to undo
it you can do so with the `cat` transducer
https://clojuredocs.org/clojure.core/cat .

On Tue, Oct 10, 2017 at 10:42 AM JokkeB  wrote:

> Thanks for the response. That's what I suspected.
>
> How does partition help me in this case? I can't see any way of using it.
>
> How about onto-chan, would that be deterministic? Or any other function?
>
>
> tiistai 10. lokakuuta 2017 17.33.22 UTC+3 Gary Trakhman kirjoitti:
>
>> I think a core assumption is that all writes can yield control at any
>> time to other worker go processes.  I wouldn't rely on the consecutive
>> behavior even if it were true, nondeterminism is a good assumption with
>> core.async.  If you need that particular guarantee, consider a call to
>> partition?
>>
>> On Tue, Oct 10, 2017 at 10:30 AM JokkeB  wrote:
>>
> I'm wondering about a case when using async:
>>>
>>> I have a channel where I write from multiple threads. One of the sources
>>> is a go-loop with a timeout, so each second I write something to the
>>> channel. If I do two consecutive writes inside the go block, can another
>>> thread write between the two writes? Or can I rely on the two messages
>>> being consecutive in the channel?
>>>
>>> --
>>> 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 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: Updating repeated nested structures?

[Rob Nikander]

Gah. I changed one name and not another. I meant:

(update-in m [:qs * :nums] ...)



On Tuesday, October 10, 2017 at 10:18:56 AM UTC-4, Rob Nikander wrote:
>
> Hi,
>
> Say I have a map like this:
>
> (def m {:qs [{:nums [3 1 2]} {:nums [7 4]}]})
>
> I want to transform each number with a function (say, `inc`). I imagine 
> something like this:
>
> (update-in m [:qs * :cell-fns] #(map inc %))  
> ; or 
> (update-in m [:qs * :cell-fns *] inc)  
>
>
> But of course you can't write that.  The following code works, but I don't 
> like reading it:
>
> (update m :qs   
> (fn [qs]
>   (mapv
> (fn [q] 
>   (update q :nums #(mapv inc %)))
> qs)))
> => {:qs [{:nums [4 2 3]} {:nums [8 5]}]}
>
> Is there an idiomatic way to do this, that looks more like the shorter 
> `update-in` idea?
>
> Rob
>
>
>
>

-- 
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.spec] Stricter map validations?

[Leon Grapenthin]

In terms of code loading, acyclic dependencies turned out to be a great 
design choice in Clojure - why its benefits shouldn't apply to or be 
justified for spec loading is totally unclear to me.

To make my point more clear let me recap. I am simply asking for s/keys to 
throw if provided specs aren't registered. Because my colleagues and I 
myself made costly mistakes that would have been prevented. The most common 
scenario is a typo like the one I have illustrated above.

I have asked what benefits justify current behavior?

The only justification comes from Sean saying that it helps him 
prototyping. While I agree I also observe that this is simultaneously the 
trapdoor leading to such silently passing specs. And why prototyping needs 
should not be a primary concern in how s/keys behaves.

I have tried to make a case for current behavior: It allows to say a key is 
there, without saying anything about its value. I have pointed out (s. a.) 
why this IMO has too little utility to justify anything.

Regarding Clojure being a dynamic lanugage this doesn't really make a 
difference here: There is not much dynamic going on about registration and 
spec in general. Registration etc. is evaluated at compile time.  Note that 
s/def, s/keys etc. are all macros whose expansion is evaluated at compile 
time.

On Monday, October 9, 2017 at 7:20:42 PM UTC+2, Beau Fabry wrote:
>
> > The argument that existence of specs provided to s/keys can only be 
> checked at runtime is false.
>
> > The argument that that recursive specs are impossible if existence of 
> specs provided to s/keys was checked at compile time is also false. 
>
> Could you explain to us why this is false? Clojure is a dynamic language, 
> as such I don't see how you could define a time when all specs need to be 
> present. How would I enter this spec at the repl if spec definition was 
> required at s/keys invocation time?
>
 

>
> On Friday, October 6, 2017 at 4:32:41 PM UTC-7, Leon Grapenthin wrote:
>>
>> The argument that existence of specs provided to s/keys can only be 
>> checked at runtime is false.
>>
>> The argument that that recursive specs are impossible if existence of 
>> specs provided to s/keys was checked at compile time is also false. 
>>
>> The usecase for libraries is not convincing: If the libraries author 
>> states "the map has to have a key K" nobody can spec K further since that 
>> would be a race condition among consumers (who s/defs K first?). Requiring 
>> the libraries author to declare K as any? would at least require him to 
>> decide and convey his intent.
>>
>> The argument that not checking a value associated with a key is 
>> corresponding to a guding design principle of map specs being based on a 
>> keyset is not stating enough to justify discussed behavior. The utility of 
>> knowing that a keyset is present is close to none, which should be the main 
>> reasons why s/keys validates values. Again: Saying "A map that has a key 
>> called ::foo" is pretty pointless in Clojure. If every map in every Clojure 
>> program I wrote had a key ::foo they would all produce the exact same 
>> results as if they didn't and I bet yours would, too. 
>>
>> Prototyping is indeed a bit more easy if one does not have to to declare 
>> every spec used in a s/keys. However, that is particularly damning if you 
>> forget to add that spec later or mistype its name when doing so. Which 
>> happens, and which is why I'm unhappy with this design letting such typical 
>> human errors pass compilation. It would also help my prototyping needs if I 
>> could reference symbols that are not declared, but I prefer the compiler 
>> errors before going live. 
>>
>> On Saturday, October 7, 2017 at 12:01:34 AM UTC+2, Sean Corfield wrote:
>>>
>>> As one of the (apparently pretty uncommon) users who actually does 
>>> happily define s/keys specs without correspondingly speccing the leaves as 
>>> an "incrementally lock down/validate" approach, I wouldn't be too upset if 
>>> I lost that ability and it started throwing an error. I mean it throws an 
>>> error if I go to generate it anyway.
>>>
>>>  
>>>
>>> **puts hand up!**
>>>
>>>  
>>>
>>> I don’t want to have to write (s/def ::some-key any?) all over the 
>>> place as I’m developing specs, just to satisfy an overly eager checker (in 
>>> my mind). Worse, since the check would need to be deferred until validation 
>>> time, as Beau notes, the omission of an “any?” key spec might not even show 
>>> up until much further down the line.
>>>
>>>  
>>>
>>> To me, this default behavior of silently not checking the _*value*_ 
>>> associated with a _*key*_ is in keeping with the design principles of 
>>> spec which focus on maps being based on a *key set*, while offering 
>>> functions to allow you to optionally check values.
>>>
>>>  
>>>
>>> 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."

Re: Clojure examples

[John M. Switlik]

And so, starting today with Google App Engine. 

-- 
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: Updating repeated nested structures?

[hitesh]

It's not terse, but it is easier to follow.

(defn flip
  [f x y]
  (f y x))

(defn update-nums
  [m f]
  (update m :qs
  (fn [x]
(flip map x
  (fn [x]
(update-in x [:nums]
   #(map f %)))

;; (update-nums m inc)
;;=> {:qs ({:nums (4 2 3)} {:nums (8 5)})}





On Tuesday, October 10, 2017 at 12:27:45 PM UTC-4, Rob Nikander wrote:
>
> Gah. I changed one name and not another. I meant:
>
> (update-in m [:qs * :nums] ...)
>
>
>
> On Tuesday, October 10, 2017 at 10:18:56 AM UTC-4, Rob Nikander wrote:
>>
>> Hi,
>>
>> Say I have a map like this:
>>
>> (def m {:qs [{:nums [3 1 2]} {:nums [7 4]}]})
>>
>> I want to transform each number with a function (say, `inc`). I imagine 
>> something like this:
>>
>> (update-in m [:qs * :cell-fns] #(map inc %))  
>> ; or 
>> (update-in m [:qs * :cell-fns *] inc)  
>>
>>
>> But of course you can't write that.  The following code works, but I 
>> don't like reading it:
>>
>> (update m :qs   
>> (fn [qs]
>>   (mapv
>> (fn [q] 
>>   (update q :nums #(mapv inc %)))
>> qs)))
>> => {:qs [{:nums [4 2 3]} {:nums [8 5]}]}
>>
>> Is there an idiomatic way to do this, that looks more like the shorter 
>> `update-in` idea?
>>
>> Rob
>>
>>
>>
>>

-- 
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: Updating repeated nested structures?

[Gary Trakhman]

I wrote a terrible terrible function once to help with this while bored in
jury duty, called flipartial, in the style of core's 'let's expand/optimize
out the most common arities':

(defn flipartial
  "A combo of partial/flip, makes it easier to fake-curry
non-data-last functions.
In general, only used for small/obvious things, because it's about as hard to
mentally reverse complex positional args in usage as this was to implement, and
reversing large lazy seqs is generally more explicit and rare."
  ([f]
   (fn
 ([] (f))
 ([x] (f x))
 ([x y] (f y x))
 ([x y z] (f z y x))
 ([x y z & args] (apply f (concat (reverse args) [z y x])
  ([f arg1]
   (fn
 ([] (f arg1))
 ([x] (f x arg1))
 ([x y] (f y x arg1))
 ([x y z] (f z y x arg1))
 ([x y z & args] (apply f (concat (reverse args) [z y x arg1])
  ([f arg1 arg2]
   (fn
 ([] (f arg2 arg1))
 ([x] (f x arg2 arg1))
 ([x y] (f y x arg2 arg1))
 ([x y z] (f z y x arg2 arg1))
 ([x y z & args] (apply f (concat (reverse args) [z y x arg2 arg1])
  ([f arg1 arg2 arg3]
   (fn
 ([] (f arg3 arg2 arg1))
 ([x] (f x arg3 arg2 arg1))
 ([x y] (f y x arg3 arg2 arg1))
 ([x y z] (f z y x arg3 arg2 arg1))
 ([x y z & args] (apply f (concat (reverse args) [z y x arg3 arg2 arg1])
  ([f arg1 arg2 arg3 & more]
   (fn
 ([] (apply f (concat (reverse more) [arg3 arg2 arg1])))
 ([x] (apply f x (concat (reverse more) [arg3 arg2 arg1])))
 ([x y] (apply f y x (concat (reverse more) [arg3 arg2 arg1])))
 ([x y z] (apply f z y x (concat (reverse more) [arg3 arg2 arg1])))
 ([x y z & args] (apply f (concat (reverse args) [z y x]
  (reverse more) [arg3 arg2 arg1]))




On Tue, Oct 10, 2017 at 4:17 PM hitesh  wrote:

> It's not terse, but it is easier to follow.
>
> (defn flip
>   [f x y]
>   (f y x))
>
> (defn update-nums
>   [m f]
>   (update m :qs
>   (fn [x]
> (flip map x
>   (fn [x]
> (update-in x [:nums]
>#(map f %)))
>
> ;; (update-nums m inc)
> ;;=> {:qs ({:nums (4 2 3)} {:nums (8 5)})}
>
>
>
>
>
> On Tuesday, October 10, 2017 at 12:27:45 PM UTC-4, Rob Nikander wrote:
>>
>> Gah. I changed one name and not another. I meant:
>>
>> (update-in m [:qs * :nums] ...)
>>
>>
>>
>> On Tuesday, October 10, 2017 at 10:18:56 AM UTC-4, Rob Nikander wrote:
>>>
>>> Hi,
>>>
>>> Say I have a map like this:
>>>
>>> (def m {:qs [{:nums [3 1 2]} {:nums [7 4]}]})
>>>
>>> I want to transform each number with a function (say, `inc`). I imagine
>>> something like this:
>>>
>>> (update-in m [:qs * :cell-fns] #(map inc %))
>>> ; or
>>> (update-in m [:qs * :cell-fns *] inc)
>>>
>>>
>>> But of course you can't write that.  The following code works, but I
>>> don't like reading it:
>>>
>>> (update m :qs
>>> (fn [qs]
>>>   (mapv
>>> (fn [q]
>>>   (update q :nums #(mapv inc %)))
>>> qs)))
>>> => {:qs [{:nums [4 2 3]} {:nums [8 5]}]}
>>>
>>> Is there an idiomatic way to do this, that looks more like the shorter
>>> `update-in` idea?
>>>
>>> Rob
>>>
>>>
>>>
>>> --
> 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: Updating repeated nested structures?

[aleks m s]

I agree with someone else that the first thing you should do is see if you 
can flatten the data in some way. I find that namespaced keywords often 
help with that. If it doesn't make sense to flatten it, however, I'd use 
specter . It's for exactly this 
use-case and really nice, despite the somewhat funky syntax.

(ns foo.core
  (:require
   [com.rpl.specter :as sp]))

(def m {:qs [{:nums [3 1 2]} {:nums [7 4]}]})

(sp/transform [:qs sp/ALL :nums sp/ALL] inc m)
;;=> {:qs [{:nums [4 2 3]} {:nums [8 5]}]}




On Tuesday, October 10, 2017 at 11:18:56 AM UTC-3, Rob Nikander wrote:
>
> Hi,
>
> Say I have a map like this:
>
> (def m {:qs [{:nums [3 1 2]} {:nums [7 4]}]})
>
> I want to transform each number with a function (say, `inc`). I imagine 
> something like this:
>
> (update-in m [:qs * :cell-fns] #(map inc %))  
> ; or 
> (update-in m [:qs * :cell-fns *] inc)  
>
>
> But of course you can't write that.  The following code works, but I don't 
> like reading it:
>
> (update m :qs   
> (fn [qs]
>   (mapv
> (fn [q] 
>   (update q :nums #(mapv inc %)))
> qs)))
> => {:qs [{:nums [4 2 3]} {:nums [8 5]}]}
>
> Is there an idiomatic way to do this, that looks more like the shorter 
> `update-in` idea?
>
> Rob
>
>
>
>

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

Is the Learning Guide in Order?

[Tomiwa Ademidun]

Hey guys,

I Finally started learning Lisp/Clojure thanks to inspiration from the 
great Paul Graham's essays . First, I 
wanted to say I appreciate your work in putting together the tutorial and 
clojure-docs website, its very helpful and I really appreciate all your 
efforts.

After working through the introduction 
, I'm about to 
start the language guide 
. I was just 
wondering if there is a recommended order in which to work through the 
guide (or should I do a tutorial and then use the guide as a reference?). 
I'm assuming I should start with functions, if so, what comes after that as 
I am a bit overwhelmed by all the things I don't know :)


Thanks,
Tomiwa

-- 
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] zprint 0.4.3

[Kim Kinnear]

 

A new version of zprint, a full function Clojure and Clojurescript code and 
data pretty printer: https://github.com/kkinnear/zprint is available.


You can use zprint in a variety of ways:

   - As a "filter" that will accept Clojure(script) source on stdin and 
   produce formatted source on stdout.  Even using the JVM it starts up in 
   under 1 second.  See* here 
   * for 
   details. 
   - As a library that you use at the repl in order to pretty print Clojure 
   structures or function definitions (with included specs in 1.9.0-beta2).  
   You can type (czprint-fn ) and see the formatted source of 
   any function (for which (doc ...) works) at the repl.  
   - As a full file reformatter, you can use lein zprint 
    to reformat entire source 
   files.  When used in this way, you can embed ;!zprint "comments" in the 
   files to alter the formatting as you desire.  While zprint does a good job 
   on specs by default, using ;!zprint {:style :spec} at the start of a spec 
   file makes the spec formatting truly excellent. 
   - Using lumo or planck to create a "filter" to format Clojure(script) 
   source. 

Zprint is configurable by using a ~/.zprintrc file, functions at the repl, 
or in an options map passed directly to its functions.  You can configure 
the way it prints Clojure source in a wide variety of ways, including some 
standard "styles" (e.g. :spec, :community) as well as by changing any of 
the detailed arguments to get code to look the way *you *want it to look.

Zprint has a number of heuristics designed to make code look "cleaner", 
with the goal to make code more understandable.  Give it a try and see what 
you think!


Here is one example, using the {:style :justified}, which isn't the default 
or my normal favorite style, but sometimes it does make things quite a bit 
clearer:


(czprint-fn defn {:width 90 :style :justified})


[this is shifted right because I used an image to preserve the formatting 
for this posting, it comes out left justified normally]





This illustrates several interesting capabilities of zprint:


   1. You can see the pretty printed source for any function for which (doc 
   ...) will work.
   2. The "c" in (czprint-fn ...) means "color" the output.  This only 
   works at the repl, of course.
   3. In Clojure 1.9.0-beta2 zprint will include any specs for the function 
   in the doc-string.  Sort of like (doc ...), but it will also format them, 
   and this shows how well zprint will format them by default.
   4. This shows a function printed with {:style :justified}, which doesn't 
   always look good, but in this case adds considerable clarity to the local 
   bindings in the let.

-- 
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: About determinism of async

[Rangel Spasov]

I think simply wrapping the two values in a vector is the only thing that's 
needed in this case. Simply do a put like (>!! ch [my-val-1 my-val-2]) and 
take from the channel from another place. If my-val-1 and my-val-2 are not 
immediately available, you can have a separate mechanism (atoms, (loop 
[...] (recur ...)) or another set of core.async channels perhaps) that 
"collects" them until they are ready to be sent together as one value.  

partition-all on its own does not really help with the ordering here. For 
example:

(let [ch (chan 42 (partition-all 2))]
  (>!! ch :x')
  (thread   ;in another thread 
far, far away
(!! ch :y'))

  (!! ch :x'')

  ;take from ch
  ( [:x' :x'']

or 

=> [:x' :y']

But again as I said, you can employ partition-all separately as a 
"collecting" mechanism before doing the (>!! ch [my-val-1 my-val-2]). 
Didn't write an example for that but let me know if that's not clear and I 
can put together a few lines.

On Tuesday, October 10, 2017 at 7:50:20 AM UTC-7, Gary Trakhman wrote:
>
> So, at the point where you need 2 things to be consecutive, wrap them up 
> in a vector so they're one thing. `(partition-all 2)` will return a 
> transducer xform that chunks up your message stream by 2 
> https://clojuredocs.org/clojure.core/partition-all, and if you need to 
> undo it you can do so with the `cat` transducer 
> https://clojuredocs.org/clojure.core/cat .  
>
> On Tue, Oct 10, 2017 at 10:42 AM JokkeB > 
> wrote:
>
>> Thanks for the response. That's what I suspected.
>>
>> How does partition help me in this case? I can't see any way of using it.
>>
>> How about onto-chan, would that be deterministic? Or any other function?
>>
>>
>> tiistai 10. lokakuuta 2017 17.33.22 UTC+3 Gary Trakhman kirjoitti:
>>
>>> I think a core assumption is that all writes can yield control at any 
>>> time to other worker go processes.  I wouldn't rely on the consecutive 
>>> behavior even if it were true, nondeterminism is a good assumption with 
>>> core.async.  If you need that particular guarantee, consider a call to 
>>> partition?
>>>
>>> On Tue, Oct 10, 2017 at 10:30 AM JokkeB  wrote:
>>>
>> I'm wondering about a case when using async:

 I have a channel where I write from multiple threads. One of the 
 sources is a go-loop with a timeout, so each second I write something to 
 the channel. If I do two consecutive writes inside the go block, can 
 another thread write between the two writes? Or can I rely on the two 
 messages being consecutive in the channel?

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

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