Re: defrecord can't impl some interface methods

[Leon Grapenthin]

Great thanks, I just upvoted that. 

-- 
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: How do I use spec and deftype together?

[Leon Grapenthin]

Spec doesn't check object fields. The defrecord case works because 
defrecord implements map.

On Wednesday, July 4, 2018 at 12:47:26 PM UTC+2, markus...@gmail.com wrote:
>
> The same question was asked on
> https://clojurians-log.clojureverse.org/clojure-spec/2018-01-19
> but I did not find an answer.
>
> An example, where defrecord works fine but deftype fails:
>
> (do
>   (require '[clojure.spec.alpha :as s])
>   (defprotocol Foo (foo [this]))
>   (defrecord Bar [bar] Foo (foo [this] (.bar this)))
>   (deftype   Baz [bar] Foo (foo [this] (.bar this)))
>   (s/def ::bar number?)
>   [(s/valid? (s/keys :req-un [::bar]) (->Bar 0))
>(s/valid? (s/keys :req-un [::bar]) (->Baz 0))]) ;[true false]
>
>
> How do I have to change the last line so that it yields true as well?
>

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

defrecord can't impl some interface methods

[Leon Grapenthin]

IDK if it has always been this case, but this doesn't compile in Clojure 1.9

(defprotocol Cleanable (clean [this]))

(defrecord Cleaner [] Cleanable (clean [this] "cleaned!"))

This is likely because java.util.Map implements a clean method with the 
same amount of args (0) and defrecord somehow also implements java.util.Map.

Is this intended or ticket-worthy?

-- 
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] spec.alpha 0.2.168 and core.specs.alpha 0.2.36

[Leon Grapenthin]

Looks like the README of core.specs.alpha has the core.specs deps info by 
mistake.

Thank you for the relases.

On Tuesday, June 26, 2018 at 8:41:17 PM UTC+2, Alex Miller wrote:
>
> spec.alpha 0.2.168 is now available with the following changes:
>
>- CLJ-2182  Always check 
>preds for s/& on nil input
>- CLJ-2178  Return 
>resolved pred for s/& explain-data
>- CLJ-2177  Return valid 
>resolved pred in s/keys explain-data
>- CLJ-2167  Properly 
>check for int? in int-in-range? - thanks David Bürgin!
>- CLJ-2166  added 
>function name to instrument exception map - thanks Josh Jones!
>- CLJ-2111  Clarify 
>docstring for :kind in s/every
>- CLJ-2068  Capture form 
>of set and function instances in spec
>- CLJ-2060  Remove a 
>spec by s/def of nil
>- CLJ-2046  gen random 
>subsets of or'd req keys in map specs - thanks David Chelimsky!
>- CLJ-2026  Prevent 
>concurrent loads in dynaload
>- CLJ-2176  s/tuple 
>explain-data :pred problem
>
> core.specs.alpha 0.2.36 is now available with the following changes:
>
>
>- CLJ-2186 : Map 
>bindings should be :kind map?
>- CLJ-2314 : allow 
>string array hinting in genclass return type
>
> If you are using Clojure 1.9.0 (or 1.10.0-alpha*), you'll be getting the 
> prior version of these libs automatically as deps but you can override 
> those by explicitly specifying these as dependencies of your library:
>
> {:deps
>  {org.clojure/spec.alpha {:mvn/version "0.2.168"}
>   org.clojure/core.specs.alpha {:mvn/version "0.2.36"}}}
>
>
>

-- 
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: Custom core.async go threadpools? Using go parking for heavy calculation parallelism throughput?

[Leon Grapenthin]

I remember a Rich Hickey talk on core.async where he mentioned building 
blocking takes/puts into the compiler, as a possible future extension, making 
the go macro obsolete. Is that on any roadmap?

Tesser I have to look at again, it seemed to go into a similar direction.

Fork/Join /w reducers is not a possibility in my algorithm since forks itself 
dynamically.

-- 
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: Custom core.async go threadpools? Using go parking for heavy calculation parallelism throughput?

[Leon Grapenthin]

Yeah, that goes in a direction I thought about after my post. I'm going to 
implement sth. like this and we will see how much code overhead is 
necessary. 

At the time it appears to me that being able to locally dedicate threads to 
the go mechanism would make this much easier (than a hand controlled 
implementation) in the same way that Erlangs VM can park everything and 
utilizes only as many threads as cores exist for everything...

Thanks for info regarding pmap, I will check it out.

On Tuesday, May 1, 2018 at 3:45:49 PM UTC+2, Justin Smith wrote:
>
> Just a couple of small points (and not yet a full answer):
>
> > A node can obviously not pmap over all the child nodes (would spawn 
> exponential amount of threads)
>
> pmap is not that naive, it uses a pool sized with the assumption that its 
> work is CPU bound
>
> > (2) Made me wonder why I couldn't use the go machinery for this. Parent 
> nodes that would "wait" for their child nodes to complete would park, 
> making their thread available to their child nodes.
>
> This is why async/thread exists, it returns a channel you can park in, and 
> you can use channels coming into the blocks starting threads to control the 
> parallelism by hand.
>
> On Tue, May 1, 2018, 03:41 Leon Grapenthin <grapent...@gmail.com 
> > wrote:
>
>> Recently I worked on an algorithm where a distributed tree is (sort of) 
>> flattened in a way that each node runs a commutative aggregation over all 
>> of its child nodes calculations.
>>
>> 1 A node can obviously not pmap over all the child nodes (would spawn 
>> exponential amount of threads).
>>
>> 2 If I want to limit the threads using a threadpool, child nodes will 
>> quickly run out of threads and we can't reuse their parents threads because 
>> they are blocking, waiting for the child nodes to complete, calculating 
>> nothing.
>>
>> It sure could be possible to implement this with an unlimited threadpool 
>> and some machinery that ensures that no more than N computations are 
>> happening in parallel. Nonetheless an insane amount of threads would be 
>> spawned.
>>
>> (2) Made me wonder why I couldn't use the go machinery for this. Parent 
>> nodes that would "wait" for their child nodes to complete would park, 
>> making their thread available to their child nodes.
>>
>> So of course I could just do it, but the per node computations are 
>> presumably too heavy for the lightweight go threadpool.
>>
>> How realistic/useful would it be to have sth. like a (go-with threadpool 
>> []) in this scenario? 
>>
>> -- 
>> 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.

Custom core.async go threadpools? Using go parking for heavy calculation parallelism throughput?

[Leon Grapenthin]

Recently I worked on an algorithm where a distributed tree is (sort of) 
flattened in a way that each node runs a commutative aggregation over all 
of its child nodes calculations.

1 A node can obviously not pmap over all the child nodes (would spawn 
exponential amount of threads).

2 If I want to limit the threads using a threadpool, child nodes will 
quickly run out of threads and we can't reuse their parents threads because 
they are blocking, waiting for the child nodes to complete, calculating 
nothing.

It sure could be possible to implement this with an unlimited threadpool 
and some machinery that ensures that no more than N computations are 
happening in parallel. Nonetheless an insane amount of threads would be 
spawned.

(2) Made me wonder why I couldn't use the go machinery for this. Parent 
nodes that would "wait" for their child nodes to complete would park, 
making their thread available to their child nodes.

So of course I could just do it, but the per node computations are 
presumably too heavy for the lightweight go threadpool.

How realistic/useful would it be to have sth. like a (go-with threadpool 
[]) in this scenario? 

-- 
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: Why does the `def-` not exist?

[Leon Grapenthin]

I guess unqualified meta keywords are reserved for the compiler anyway so it 
could just warn if it doesn't know a unqualified kw.

-- 
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: Why does the `def-` not exist?

[Leon Grapenthin]

The one issue with the lack of def- is the existence of defn-. If defn- 
didn't exist, no one would ask for def-. I believe this is where the 
"regret" comes from.
The other issue with the lack of def- is that its annoying to type 
^:prviate. I don't see how you could accidentally mistype it (never 
happened IME) or the need for compiler aid. 
If beginners think that there is a magic postfix syntax, I don't see how 
this is a problem. They are beginners and naturally there will be many 
things that fail their intuition.
Compiler auto injection on postfix magic I'm strongly opposed to.

@Alex thanks for your long reply yesterday and the statistics! I'll get 
back to that. 


On Wednesday, February 28, 2018 at 8:06:51 PM UTC+1, Didier wrote:
>
> I think the issue is not with the lack of def-, but with the use of 
> metadata for private, as well as the presence of defn-.
>
> Becauae defn- exists, most newcomers think that postfix - on var defining 
> special forms, macros and fns is how you mark things as private.
>
> But its not, defn- is a syntactic hack.
>
> The compiler and runtime looks for the private metadata on the Var for 
> that. But metadata is easy to typo and always confusing as to where it 
> needs to be inserted.
>
> Not sure there's a solution. Maybe reserved meta could be turned into a 
> different syntax of reserved keywords which the compiler could validate if 
> its misplaced or mistyped? Or postfix - on any first symbol in a form could 
> be special syntax where the compiler auto-injects the private meta on the 
> returned Var.
>
>

-- 
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: Why does the `def-` not exist?

[Leon Grapenthin]

I'm sure you'd all use def- if it existed. Even if you could just type the 
much simplified ^:private, use an editor snippet, refer your own macro, or 
create a whole new namespace for it. You'd do none of that. You'd totally 
fall for the trap and type def-, the syntactic aid that should not be there.

There is "regret over even adding defn-"? You used defn- just recently in 
the tools.deps.alpha core namespace 9 times. Rich used it in clojure.spec 
core namespace 46 times. :)))

Jokes aside, if Rich simply doesn't want it that's fine of course - it's 
his language. However if people ask me again I will just say that instead. 
Believe it or not, I got this question three times last year and the "copy 
N things" argument failed 3/3.

The impl ns pattern recommended by Timothy is truly a very good one that I 
apply a lot myself, especially in larger projects and when "private" macro 
helpers are involved (and probably the only solid workaround recommended 
here because it has value in itself).

How much do I def things? - I haven't done the computation but I'm pretty 
sure that I def more things ^:private than I def things public. Little 
lookup tables etc.. Also I'd argue that def is the second most used top 
level form after defn. If not, the ones that come before don't have 
^:private semantics. Well, if there was any chance for def- left I'd do a 
statistic over available codebases - let me know.


On Tuesday, February 27, 2018 at 2:41:15 AM UTC+1, Alex Miller wrote:
>
> We're not going to add def-. There is regret over even adding defn-, but 
> we don't take things away...
>
> At one point all of the current metadata niceties didn't exist (used to be 
> #^{:private true} some may recall) and defn- seemed worth doing I presume 
> (pre-dates my involvementT). But then that was all simplified down to just 
> ^:private and it's preferred to compose the pieces rather than copy N 
> things. 
>
> There used to be a slew of these in the old clojure-contrib (
> https://github.com/clojure/clojure-contrib/blob/master/modules/def/src/main/clojure/clojure/contrib/def.clj
>  
> - but no def- !). 
>
> How often do you def things anyway (much less private things)? 
>
> On Monday, February 26, 2018 at 1:50:40 PM UTC-6, Leon Grapenthin wrote:
>>
>> I have written enough Clojure so that I can assure you that every few 
>> days when I type ^:private again I am still annoyed by it. Not every time, 
>> but probably every second or third time.
>>
>> Its just in the way of the prototyping typing (micro-)flow. SHIFT-6 you 
>> don't hit so often so you have to hit it right. On german keyboards, by the 
>> way, ^ is a much more annoying character to type. Then a colon, did I miss 
>> the colon? What did I want to do again?
>>
>> When prototyping an API ns its important to distinguish what is private 
>> and what isn't. If only I could just write def- without any overhead.
>>
>> First world aka best language problems, I know...
>>
>> But whats left for an enthusiast except bikeshedding? We both know that a 
>> JIRA discussion on this will not happen due to a lack of importance. And 
>> unless somebody manages to convince Rich, this feature won't happen.
>>
>> Fair enough. I'd consider myself a power user since 1.5.1 and value its 
>> conservative governance above every other kind.  
>> The "lets not start postfixing lots of macros with -" argument a good one 
>> in general and probably was a good one at the time. But not in this case 
>> because defn and def are the two most used and most elementary top level 
>> forms. 
>>
>> This argument didn't convince anyone who has asked me about this. The 
>> counter argument goes "I don't want the - postfix for anything else, just 
>> for def because I use it a lot" -rightfully so.
>>
>> The lack of def- is just unnecessary typing overhead in lots of cases. It 
>> could be removed at the cost 5m on a beautiful day. I'd appreciate it :)
>>
>> On Monday, February 26, 2018 at 6:52:51 PM UTC+1, Alexander Yakushev 
>> wrote:
>>>
>>> - Not that often. When I know for certain, I add ^:private. Not like 
>>> it's much more work. If I didn't know ahead of time, I would forget to add 
>>> the private flag in either case.
>>> - Never.
>>> - Can't recollect such an event.
>>> - A few times. As far as I can tell, people appreciate the metadata 
>>> approach since it is unique and powerful. The lack of one particular 
>>> non-critical syntactic sugar is never an issue.
>>>
>>> I won't mind having def- as much as I don't mind not having it. Pretty 
>>> much the same as for defn- – Eart

Re: Why does the `def-` not exist?

[Leon Grapenthin]

I have written enough Clojure so that I can assure you that every few days 
when I type ^:private again I am still annoyed by it. Not every time, but 
probably every second or third time.

Its just in the way of the prototyping typing (micro-)flow. SHIFT-6 you 
don't hit so often so you have to hit it right. On german keyboards, by the 
way, ^ is a much more annoying character to type. Then a colon, did I miss 
the colon? What did I want to do again?

When prototyping an API ns its important to distinguish what is private and 
what isn't. If only I could just write def- without any overhead.

First world aka best language problems, I know...

But whats left for an enthusiast except bikeshedding? We both know that a 
JIRA discussion on this will not happen due to a lack of importance. And 
unless somebody manages to convince Rich, this feature won't happen.

Fair enough. I'd consider myself a power user since 1.5.1 and value its 
conservative governance above every other kind.  
The "lets not start postfixing lots of macros with -" argument a good one 
in general and probably was a good one at the time. But not in this case 
because defn and def are the two most used and most elementary top level 
forms. 

This argument didn't convince anyone who has asked me about this. The 
counter argument goes "I don't want the - postfix for anything else, just 
for def because I use it a lot" -rightfully so.

The lack of def- is just unnecessary typing overhead in lots of cases. It 
could be removed at the cost 5m on a beautiful day. I'd appreciate it :)

On Monday, February 26, 2018 at 6:52:51 PM UTC+1, Alexander Yakushev wrote:
>
> - Not that often. When I know for certain, I add ^:private. Not like it's 
> much more work. If I didn't know ahead of time, I would forget to add the 
> private flag in either case.
> - Never.
> - Can't recollect such an event.
> - A few times. As far as I can tell, people appreciate the metadata 
> approach since it is unique and powerful. The lack of one particular 
> non-critical syntactic sugar is never an issue.
>
> I won't mind having def- as much as I don't mind not having it. Pretty 
> much the same as for defn- – Earth wouldn't stop turning if you had to type 
> defn ^:private once in a while.
>
> And while I agree with you that it would be somewhat useful, bikeshedding 
> only gets you so far.
>
> On Monday, February 26, 2018 at 7:17:05 PM UTC+2, Leon Grapenthin wrote:
>>
>> - How many times do you just write (def ...) instead of (def ^:private 
>> ...) because you are not sure whether you need the definition yet, want to 
>> save effort, and then you forget to add ^:private later?
>> - How many times have you implemented def- yourself into your project and 
>> then used only half of the time because you had to require and :refer the 
>> thing from some util namespace which is just as annoying as typing 
>> ^:private?
>> - How many times do you use autocomplete on some namespace and find 
>> internals because their dev forgot ^:private?
>> - How many times in a year do you have to explain to a Clojure newbie 
>> that there is defn- but no def-?
>>
>> IME the statistic strongly supports def- - and I don't see why it would 
>> hurt.
>> Having def- in clojure.core will not magically result in having defmacro- 
>> and defmulti- and xyz-. Its a false and the only counterargument I have 
>> seen.
>>
>> It would be very useful, though.
>>
>> On Monday, February 26, 2018 at 1:44:27 PM UTC+1, Alexander Yakushev 
>> wrote:
>>>
>>> Usually, it is better to use metadata rather than create an exponential 
>>> explosion of names. Public/private is just one dimension, but you also have 
>>> static/non-static, dynamic/non-dynamic, etc. Then you have functions, vars, 
>>> macros, perhaps modified functions (like schema.core/defn). Cartesian 
>>> product of those would be huge.
>>>
>>> defn- is an exclusion from the rule probably because it is used more 
>>> often than others.
>>>
>>> On Monday, February 26, 2018 at 10:58:43 AM UTC+2, Promise. wrote:
>>>>
>>>> `defn-` => `defn`
>>>> 'def-` => `def`
>>>>
>>>

-- 
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] clj 1.9.0.348 and tools.deps.alpha 0.5.398

[Leon Grapenthin]

Thank you Alex. Regarding 1 I don't think I really see why I would want 
this but it seems interesting.

Regarding 2 and everything else I'm really happy with the tool and the docs 
are great.

(My cljs usage with this right now is to just build cp and launch 
figwheel.) Cljs libs and how this is gonna play with cljs's own deps.cljs 
and npm-deps I'm looking forward very much to a combined effort. Especially 
if npm dependency resolution will be moved away from the compiler.

On Monday, February 26, 2018 at 6:15:55 PM UTC+1, Alex Miller wrote:
>
>
>
> On Monday, February 26, 2018 at 10:59:53 AM UTC-6, Leon Grapenthin wrote:
>>
>> Thank you for this tool. 
>>
>> I'm using this for a rather large new project right now and already love 
>> how precise and minimalistic this tool is. Features like -Sverbose, -Stree 
>> and now -Sdescribe are very helpful.
>>
>> Although it is probably not intended I don't think we will be using 
>> Leiningen and Boot as much in the long term future as we do now.
>>
>> Two questions though:
>> 1 I'm having trouble understanding :default-deps from the documentation
>> ":default-deps provides a set of default coordinate versions to use if 
>> no coordinate is specified. The default deps can be used across a set of 
>> shared projects to act as a dependency management system"
>> Don't get it. How can a dependency have no coordinate specified? And the 
>> second sentence I don't understand at all. How is possible to use default 
>> deps across shared projects and then they become a dependency management 
>> system ?!?
>>
>
> This stems from some very early design work with the notion of allowing 
> for an external source of dependency versions shared across projects. So 
> the idea is that you would declare a lib but not declare a coordinate for 
> it. And then you would use this with an alias (which could be a shared 
> alias in your ~/.clojure/deps.edn that applies across projects) to declare 
> the default dep coordinate versions used across multiple projects. Where we 
> are at the moment, I'm not sure this is very easy to use or leverage but is 
> an area with a ton of future potential, similar to ideas of 
> "dependencyManagement" in maven/lein. We've learned a lot since that early 
> work and I'm not sure we would come to the same conclusions with a fresh 
> re-think now.
>  
>
>> 2 In a CLJ/CLJS project I'm not using :deps because I have a clj, a 
>> clj-dev, a cljs and a cljs-dev alias. For development I combine clj and 
>> clj-dev or cljs and cljs-dev. They all have :extra-deps, but no :deps. Is 
>> this the intended usage? 
>>
>
> I think that's fine - :deps are really declaring dependencies for your 
> project classpath and importantly for other projects that use your project. 
> I suspect in your case there are none of the latter (you're an app, not a 
> lib or a service) and in the former there are really multiple kinds of 
> classpaths you need to build so this makes sense.
>
> Most of the original design work was focused on Clojure, not 
> ClojureScript, so the docs may not be particularly well targeted to your 
> use and that's why they don't seem to match to your usage well. I think we 
> could use some good docs, probably on clojurescript.org, with that 
> intent. Things are both changing and being discovered at a pretty rapid 
> pace right now around cljs usage of the clj tool.
>
>

-- 
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: Why does the `def-` not exist?

[Leon Grapenthin]

- How many times do you just write (def ...) instead of (def ^:private ...) 
because you are not sure whether you need the definition yet, want to save 
effort, and then you forget to add ^:private later?
- How many times have you implemented def- yourself into your project and 
then used only half of the time because you had to require and :refer the 
thing from some util namespace which is just as annoying as typing 
^:private?
- How many times do you use autocomplete on some namespace and find 
internals because their dev forgot ^:private?
- How many times in a year do you have to explain to a Clojure newbie that 
there is defn- but no def-?

IME the statistic strongly supports def- - and I don't see why it would 
hurt.
Having def- in clojure.core will not magically result in having defmacro- 
and defmulti- and xyz-. Its a false and the only counterargument I have 
seen.

It would be very useful, though.

On Monday, February 26, 2018 at 1:44:27 PM UTC+1, Alexander Yakushev wrote:
>
> Usually, it is better to use metadata rather than create an exponential 
> explosion of names. Public/private is just one dimension, but you also have 
> static/non-static, dynamic/non-dynamic, etc. Then you have functions, vars, 
> macros, perhaps modified functions (like schema.core/defn). Cartesian 
> product of those would be huge.
>
> defn- is an exclusion from the rule probably because it is used more 
> often than others.
>
> On Monday, February 26, 2018 at 10:58:43 AM UTC+2, Promise. wrote:
>>
>> `defn-` => `defn`
>> 'def-` => `def`
>>
>

-- 
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] clj 1.9.0.348 and tools.deps.alpha 0.5.398

[Leon Grapenthin]

Thank you for this tool. 

I'm using this for a rather large new project right now and already love 
how precise and minimalistic this tool is. Features like -Sverbose, -Stree 
and now -Sdescribe are very helpful.

Although it is probably not intended I don't think we will be using 
Leiningen and Boot as much in the long term future as we do now.

Two questions though:
1 I'm having trouble understanding :default-deps from the documentation
":default-deps provides a set of default coordinate versions to use if no 
coordinate is specified. The default deps can be used across a set of 
shared projects to act as a dependency management system"
Don't get it. How can a dependency have no coordinate specified? And the 
second sentence I don't understand at all. How is possible to use default 
deps across shared projects and then they become a dependency management 
system ?!?

2 In a CLJ/CLJS project I'm not using :deps because I have a clj, a 
clj-dev, a cljs and a cljs-dev alias. For development I combine clj and 
clj-dev or cljs and cljs-dev. They all have :extra-deps, but no :deps. Is 
this the intended usage? 

Clarification would be appreciated - Thanks.


On Monday, February 26, 2018 at 3:07:16 AM UTC+1, Alex Miller wrote:
>
> New releases of tools.deps.alpha and the Clojure tools (clj, clojure) are 
> now available.
>
> clj 1.9.0.348 updates:
>
> - Added -Scp option to skip computing a classpath and use the provided one
> - Added -Sdescribe to output config env and parsed arg info as data
> - Added --prefix to linux-install.sh (INST-9)
> - Added man pages to installation (INST-18)
> - Fix uberjar construction to avoid overlap of file and directory with 
> same name
> - Add missing license file
>
> tools.deps.alpha 0.5.398 updates: 
>
> - Refactoring and API updates
>   - tools.deps.alpha - now requires all included extensions
>   - tools.deps.alpha - added missing docstrings
>   - tools.deps.alpha/lib-location - finds the file path location of lib if 
> it were downloaded
>   - tools.deps.alpha.reader/clojure-env - added call to shell out to call 
> `clojure` to grab outer env
>   - tools.deps.alpha.script.make_classpath - refactored to expose more 
> resuable parts
> - Improve error if cache dir can't be created
> - Updated Maven-related deps
>
>

-- 
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: Anyone mourns the loss of: tryclj.com ?

[Leon Grapenthin]

On tryclj I entered my first Clojure forms. The 5 minutes tutorial was 
great because it made me want to learn more. Whether JS or JVM, we should 
get a substitute up and running, preferably on the home page.

On Saturday, December 16, 2017 at 4:29:23 AM UTC+1, Didier wrote:
>
> Just realized that: tryclj.com is gone.
>
> I wonder if clojure.org could come to the rescue, and add a try-me web 
> repl on it. I feel like tryclj when I first got started and became 
> interested was a great gateway.
>
> repl.it is just a little too bloated for my liking as a replacement.
>

-- 
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] Clojure 1.9.0-beta3

[Leon Grapenthin]

Have you considered calling it clojure.spec.alpha.skip-macros
?

Would make sense if you intend to ignore that setting in 2.0 (or any later 
release with spec nonalpha)

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

Re: [core.spec] Stricter map validations?

[Leon Grapenthin]

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."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com  <clo...@googlegroups.com 
> > on behalf of Beau Fabry <imf...@gmail.com >
> *Sent:* Friday, October 6, 2017 9:10:36 AM
> *To:* Clojure
> *Subject:* Re: [core.spec] Stricter map validations? 
>  
> A use case that comes to mind is a system/library that specifies the 
> structure of some inputs/outputs, but lets users/consumers (optionally) 
> specify further validation of the leaves. I suppose that would be possible 
> with (s/def ::foo any?) but you'd have to be a bit more careful about load 
> order. The other use case (which is mine) is I'm just lazy and only want to 
> write out broad strokes specs sometimes without getting into the nitty 
> gritty. 
>
> If s/keys were to validate that the keys it's provided have specs it would 
> have to do it at validation time, so you wouldn't get the error until 
> something was actually validated against that key spec. Trying to do it at 
> definition time would break recursive specs.
>
> 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.
>
> On Friday, October 6, 2017 at 8:58:38 AM UTC-7, Leon Grapenthin wrote: 
>>
>> Thanks, Beau. 
>>
>> I am still interested why this default behavior has been chosen. It 
>> doesn't seem like a reasonable trade-off at this point.
>>
>> It enables me to say: "The map must have this key", without specifying 
>> how the data mapped to it will look like.
>>
>> If I ever wanted to do that, I could as well spec that key with "any?".
&g

Re: [core.spec] Stricter map validations?

[Leon Grapenthin]

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. 

So prototyping is indeed 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 the compiler errors before I 
go 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."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com  <clo...@googlegroups.com 
> > on behalf of Beau Fabry <imf...@gmail.com >
> *Sent:* Friday, October 6, 2017 9:10:36 AM
> *To:* Clojure
> *Subject:* Re: [core.spec] Stricter map validations? 
>  
> A use case that comes to mind is a system/library that specifies the 
> structure of some inputs/outputs, but lets users/consumers (optionally) 
> specify further validation of the leaves. I suppose that would be possible 
> with (s/def ::foo any?) but you'd have to be a bit more careful about load 
> order. The other use case (which is mine) is I'm just lazy and only want to 
> write out broad strokes specs sometimes without getting into the nitty 
> gritty. 
>
> If s/keys were to validate that the keys it's provided have specs it would 
> have to do it at validation time, so you wouldn't get the error until 
> something was actually validated against that key spec. Trying to do it at 
> definition time would break recursive specs.
>
> 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.
>
> On Friday, October 6, 2017 at 8:58:38 AM UTC-7, Leon Grapenthin wrote: 
>>
>> Thanks, Beau. 
>>
>> I am still interested why this default behavior has been chosen. It 
>> doesn't seem like a reasonable trade-off at this point.
>>
>> It enables me to say: "The map must have this key", without specifying 
>> how the data mapped to it will look like.
>>
>> If I ever wanted to do that, I could as well spec that key with "any?".
>>
>

Re: [core.spec] Stricter map validations?

[Leon Grapenthin]

Thanks, Beau. 

I am still interested why this default behavior has been chosen. It doesn't 
seem like a reasonable trade-off at this point.

It enables me to say: "The map must have this key", without specifying how 
the data mapped to it will look like.

If I ever wanted to do that, I could as well spec that key with "any?".

What are other benefits? They must justify the expense of likely runtime 
errors.


On Friday, October 6, 2017 at 5:34:16 PM UTC+2, Beau Fabry wrote:
>
> Leon, perhaps you could add this code to your test suite?
>
> boot.user=> (let [kws (atom #{})]
>#_=>   (clojure.walk/postwalk (fn [x] (when (qualified-keyword? x) 
> (swap! kws conj x)) x) (map s/form (vals (s/registry 
> (clojure.set/difference @kws (set (keys (s/registry
>#_=> )
> #{:clojure.spec.alpha/v :clojure.spec.alpha/k}
> boot.user=>
>
> On Friday, October 6, 2017 at 5:56:29 AM UTC-7, Leon Grapenthin wrote:
>>
>> Open maps/specs are fine.
>>
>> s/keys supporting unregistered specs are not.
>>
>> At least to me. I just fixed two more bugs in production that were would 
>> not have happened.
>>
>> What are the supposed benefits of this feature? 
>>
>> I can only infer "being able to require keys without their spec being 
>> known" which is a usecase I had exactly 0.00% of the time so far.
>>
>> Anything I have missed?
>>
>> Kind regards,
>>  Leon.
>>
>>
>> On Wednesday, October 4, 2017 at 7:05:29 PM UTC+2, Beau Fabry wrote:
>>>
>>> Seems like that's the reasonable place to check it, otherwise you're 
>>> forced into an ordering for your specs and cannot write recursive strict 
>>> map specs.
>>>
>>> On Wednesday, October 4, 2017 at 8:59:59 AM UTC-7, Yuri Govorushchenko 
>>> wrote:
>>>>
>>>> Thanks. This approach is also different from the macro because it will 
>>>> check specs existence at the validation time, not at the s/def call.
>>>>
>>>> On Wednesday, October 4, 2017 at 4:18:16 PM UTC+3, Moritz Ulrich wrote:
>>>>>
>>>>> Yuri Govorushchenko <yuri@gmail.com> writes: 
>>>>>
>>>>> > Thank you the pointers! So far I ended up with writing a small `map` 
>>>>> macro 
>>>>> > which is similar to `s/keys` but checks that keys are already in the 
>>>>> > registry: 
>>>>> https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2 
>>>>>
>>>>> Note that you can simply combine a custom predicate and `s/keys` in 
>>>>> clojure.spec to verify that all keys in a given map have a underlying 
>>>>> spec: 
>>>>>
>>>>> ``` 
>>>>> (s/def ::whatever (s/and (s/keys ...) 
>>>>>  #(every? keyword? (keys %)) 
>>>>>  #(every? (comp boolean s/get-spec) (keys %)) 
>>>>> ) 
>>>>> ``` 
>>>>>
>>>>

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

Open maps/specs are fine.

s/keys supporting unregistered specs are not.

At least to me. I just fixed two more bugs in production that were would 
not have happened.

What are the supposed benefits of this feature? 

I can only infer "being able to require keys without their spec being 
known" which is a usecase I had exactly 0.00% of the time so far.

Anything I have missed?

Kind regards,
 Leon.


On Wednesday, October 4, 2017 at 7:05:29 PM UTC+2, Beau Fabry wrote:
>
> Seems like that's the reasonable place to check it, otherwise you're 
> forced into an ordering for your specs and cannot write recursive strict 
> map specs.
>
> On Wednesday, October 4, 2017 at 8:59:59 AM UTC-7, Yuri Govorushchenko 
> wrote:
>>
>> Thanks. This approach is also different from the macro because it will 
>> check specs existence at the validation time, not at the s/def call.
>>
>> On Wednesday, October 4, 2017 at 4:18:16 PM UTC+3, Moritz Ulrich wrote:
>>>
>>> Yuri Govorushchenko  writes: 
>>>
>>> > Thank you the pointers! So far I ended up with writing a small `map` 
>>> macro 
>>> > which is similar to `s/keys` but checks that keys are already in the 
>>> > registry: 
>>> https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2 
>>>
>>> Note that you can simply combine a custom predicate and `s/keys` in 
>>> clojure.spec to verify that all keys in a given map have a underlying 
>>> spec: 
>>>
>>> ``` 
>>> (s/def ::whatever (s/and (s/keys ...) 
>>>  #(every? keyword? (keys %)) 
>>>  #(every? (comp boolean s/get-spec) (keys %)) ) 
>>> ``` 
>>>
>>

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

My critique is not towards closed keysets but about being able to (s/keys 
:req [::some-kw]) without having defined the spec ::some-kw, but e.g. 
::soem-kw instead. This can trip you up badly, and not at compile time. I'd 
be surprised if this never happened to you.

Regarding open maps and keysets I'm fine with them. However, I use 
select-keys after validating data over the wire. Would be nice if there 
were some "select-spec" for open specs.

On Tuesday, October 3, 2017 at 5:03:01 AM UTC+2, Alex Miller wrote:
>
>
> On Monday, October 2, 2017 at 12:30:57 PM UTC-5, Leon Grapenthin wrote:
>>
>> I second this from my experience, using spec quite extensively since its 
>> release.
>>
>> We already had some invalid data passing silently because of this. It can 
>> easily happen if you have a typo in the spec.
>>
>> Also we never experienced benefits from being able to not spec keys 
>> required in s/keys. It appears to be a pretty obsolete feature, making 
>> vulnerabilities more likely.
>>
>
> It is more common to experience the negative effects of restricting key 
> sets as you evolve through versions, and in fact we have experienced on 
> virtually every consulting project we'd done including spec at Cognitect. 
> So I do not think it is at all obsolete.
>
>
>

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

My critique is not towards closed keysets but about being able to (s/keys :req 
[::some-kw]) without having defined the spec ::some-kw, but e.g. ::soem-kw 
instead. This can trip you up badly, and not at compile time. I'd be surprised 
if this never happened to you.

Regarding open maps and keysets I'm fine with them. However, I use select-keys 
after validating data over the wire. Would be nice if there were some 
"select-spec" for open specs.

-- 
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 ship Clojure 1.9!

[Leon Grapenthin]

Since spec is mainly a dependency of 1.9. to improve error reporting over 
1.8 (correct me if I'm wrong), I'd like to point out this ticket 
again: https://dev.clojure.org/jira/browse/CLJ-2013

It solves what I determined the root cause of this report 
https://groups.google.com/d/msg/clojure/mIlKaOiujlo/6b0So2siCgAJ which 
triggered a lengthy discussion at the time.

Also, the standard error reporter should sort problems by depth (length) of 
part as a default.

Thanks for looking into it,
 Leon.

On Thursday, September 28, 2017 at 4:00:16 PM UTC+2, stuart@gmail.com 
wrote:
>
> Clojure 1.9 has been quite stable throughout the alpha period, and we now 
> hope to release after a very short beta. Please test your existing programs 
> on the latest beta (see below), and respond on this thread ASAP if you 
> discover anything you believe to be a regression.
>
> Thanks!
> Stu
>
> ;; Clojure deps.edn
> org.clojure/clojure {:mvn/version "1.9.0-beta1"}
>
> ;; lein & boot
> [org.clojure/clojure "1.9.0-beta1"]
>
>

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

I second this from my experience, using spec quite extensively since its 
release.

We already had some invalid data passing silently because of this. It can 
easily happen if you have a typo in the spec.

Also we never experienced benefits from being able to not spec keys 
required in s/keys. It appears to be a pretty obsolete feature, making 
vulnerabilities more likely.

On Monday, October 2, 2017 at 5:37:31 PM UTC+2, Yuri Govorushchenko wrote:
>
> Hi!
>
> I have some noobie questions for which I couldn't google the compelling 
> answers.
>
> 1) Is there any way to ensure that the keys I used in `s/keys` have the 
> associated specs defined? At compile time or at least at runtime. Maybe via 
> an additional library? I could imagine a macro (smt. like `s/keys-strict` 
> or `s/map-pairs`, as maps can also be viewed as sets of spec'ed pairs) 
> which additionally checks that all keys have specs registered. I'm OK with 
> sacrificing some flexibility (e.g. being able to define key specs after map 
> specs, dynamically, etc.) in favour of more strictness.
>
> Motivation: I don't fully trust my map validation code when using 
> `core.spec`. `s/keys` doesn't require that the key has the spec registered 
> to validate its value. Although this may be flexible but in practice can 
> lead to errors. Specifically, it's quite easy to forget to create a spec 
> for a key, mistype it or forget to require the namespace in which key spec 
> is defined (e.g. if the common key specs reside in a dedicated ns):
>
> ```
> ; totally forgot to define a spec for ::foo
> (s/def ::bar (s/keys :req [::foo]))
>
> ; fooo vs. foo typo
> (s/def ::fooo string?)
> (s/def ::bar (s/keys :req [::foo]))
>
> ; :common/foo vs. ::common/foo typo
> (s/def ::bar (s/keys :req [:common/foo]))
>
> ; didn't require common.core ns (spec for :common.core/foo is not added to 
> global registry)
> (s/def ::bar (s/keys :req [:common.core/foo]))
> ```
>
> These subtle mistakes can lead to map validations passing silently (as 
> long as keysets are correct).
>
> Related to this: there're feature requests for Cursive IDE which try to 
> address typing and reading mistakes related to keywords, e.g. 
> https://github.com/cursive-ide/cursive/issues/1846 and 
> https://github.com/cursive-ide/cursive/issues/1864.
>
> After using Schema for a while it's difficult to appreciate the way 
> `core.spec` defines it's own global registry which uses keywords instead of 
> using spec instances and good old variables, especially since Cursive IDE 
> has quite a nice support for variables already. But I think this is another 
> topic which was already discussed, e.g. in 
> https://groups.google.com/forum/#!topic/clojure/4jhSCZaFQFY ("Spec 
> without global registry?").
>
> 2) What is the motivation for library having a "loose" default behaviour 
> of `s/keys` and no "strict" variant at all for spec-ing both keys and 
> values at the same tome? I think in majority of cases I'd need to spec both 
> keys and values of the map instead of only keys and would expect the 
> library to have built-in API for this. Maybe for the future references it 
> would be beneficial to add concrete code examples into motivation in the 
> core.spec guide (
> https://clojure.org/about/spec#_map_specs_should_be_of_keysets_only) 
> which would better illustrate the described benefits of the current lib 
> behaviour?
>
> Thanks.
>

-- 
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: Code Review -- Testing truthiness twice

[Leon Grapenthin]

fix

(defn get-if [m pred]
  (let [[match & more] (filter (comp pred key) m)]
(if (and match (not more)) (val match


Apologies.

On Sunday, October 1, 2017 at 11:44:27 PM UTC+2, Leon Grapenthin wrote:
>
> 1. In general this style of iteration is not idiomatic unless you are 
> hunting performance or write sth. that simply can't be composed from core 
> sequence library (s. b.). If you have to write this style, look at 
> `when-first`, `seq`, `next`. Study implementation of core library.
>
> More idiomatic implementation is
>
> (defn get-if [m pred]
>   (let [[match & more] (filter (comp pred key) m)]
> (if-not more (val match
>
> 2. Let bindings to prevent repeated evaluation are fine. 
> 3. First position is fine, but you should use loop/recur or an inner 
> let-bound lambda instead of exposing found in the public API of the function
> 4. Again, look at core functions. Rich does naming very carefully and 
> consistent. In (1) I called it pred, because its called pred in functions 
> like filter or some.
> 5. See 1
>
>
> On Sunday, October 1, 2017 at 11:11:55 PM UTC+2, Scott Barrett wrote:
>>
>> Clojure noob, here. I'm very excited to be learning about this language 
>> and becoming a part of this community :) I'm writing a function that works 
>> well, but seems just a bit wrong to me, stylistically speaking. I was 
>> hoping I could get some guidance from you all.
>>
>> Here's the code:
>>
>> (defn get-if
>>   "Gets the value of a map if exactly one key matches a predicate, 
>> otherwise nil"
>>   ([m predicate?] (get-if nil m predicate?))
>>   ([found m predicate?]
>>(if-let [e (first m)]
>>  (let [pred (predicate? (key e))]
>>(if (not (and pred found))
>>  (recur (if pred (val e) found) (rest m) predicate?))
>>  found
>>
>> This has gone through a few revisions to get it as concise as possible, 
>> but here are my questions/remarks:
>>
>>1. Is it idiomatic to use if-let to move through a collection the way 
>>I have? In my experience with lispy languages, recursion over sequences 
>>tend to take the form (if (null item) accumlated-value 
>>(recur-over-rest)). This if-let form turns that on its head, which 
>>looks a little backwards at first to me, but it saves a level of 
>>indentation which is generally preferable in my experience.
>>2. The main part of this code that's bugging me is the let form, 
>>which is a total hack to keep from testing (predicate? (key e)) 
>>twice. Even still, I have to test the truthiness of pred twice; once in 
>> the 
>>(not (and ...)) form and once again in the if of the recur form. I 
>>feel like a clever use of (and ...) or (or ...) would save me here, 
>>but I haven't come upon a solution using those forms yet.
>>3. In general, when using recursion and multiple arities to get a 
>>result, is there an order that is preferred for the extra recursion 
>>accumulation values? Here I have [m predicate?] and [found m 
>>predicate?] versions of the function, but after looking at it for so 
>>long I think it might be more natural to put found as the last argument, 
>> as 
>>in [m predicate? found], but I'm wondering if there's a standard to 
>>follow with things like this.
>>4. When passing functions as arguments, as I have here with the 
>>predicate? function, is there a standard naming convention? I used a 
>>question mark here, but would predicate be preferable, or even simply 
>>f?
>>5. Is writing this function even necessary? I didn't see a function 
>>that serves the same purpose in the standard libraries, but I'm very new 
>>and could easily have missed something!
>>
>> I know that's a lot to ask for such a short segment of code. Feel free to 
>> answer as many/few of these questions as you'd like, as any help would be 
>> greatly appreciated (though, if you're going to answer one, I think point 
>> #2 is the most important) :)
>>
>>
>> Thanks in advance, fellow clojurians!
>>
>

-- 
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: Code Review -- Testing truthiness twice

[Leon Grapenthin]

1. In general this style of iteration is not idiomatic unless you are 
hunting performance or write sth. that simply can't be composed from core 
sequence library (s. b.). If you have to write this style, look at 
`when-first`, `seq`, `next`. Study implementation of core library.

More idiomatic implementation is

(defn get-if [m pred]
  (let [[match & more] (filter (comp pred key) m)]
(if-not more (val match

2. Let bindings to prevent repeated evaluation are fine. 
3. First position is fine, but you should use loop/recur or an inner 
let-bound lambda instead of exposing found in the public API of the function
4. Again, look at core functions. Rich does naming very carefully and 
consistent. In (1) I called it pred, because its called pred in functions 
like filter or some.
5. See 1


On Sunday, October 1, 2017 at 11:11:55 PM UTC+2, Scott Barrett wrote:
>
> Clojure noob, here. I'm very excited to be learning about this language 
> and becoming a part of this community :) I'm writing a function that works 
> well, but seems just a bit wrong to me, stylistically speaking. I was 
> hoping I could get some guidance from you all.
>
> Here's the code:
>
> (defn get-if
>   "Gets the value of a map if exactly one key matches a predicate, 
> otherwise nil"
>   ([m predicate?] (get-if nil m predicate?))
>   ([found m predicate?]
>(if-let [e (first m)]
>  (let [pred (predicate? (key e))]
>(if (not (and pred found))
>  (recur (if pred (val e) found) (rest m) predicate?))
>  found
>
> This has gone through a few revisions to get it as concise as possible, 
> but here are my questions/remarks:
>
>1. Is it idiomatic to use if-let to move through a collection the way 
>I have? In my experience with lispy languages, recursion over sequences 
>tend to take the form (if (null item) accumlated-value 
>(recur-over-rest)). This if-let form turns that on its head, which 
>looks a little backwards at first to me, but it saves a level of 
>indentation which is generally preferable in my experience.
>2. The main part of this code that's bugging me is the let form, which 
>is a total hack to keep from testing (predicate? (key e)) twice. Even 
>still, I have to test the truthiness of pred twice; once in the (not 
>(and ...)) form and once again in the if of the recur form. I feel 
>like a clever use of (and ...) or (or ...) would save me here, but I 
>haven't come upon a solution using those forms yet.
>3. In general, when using recursion and multiple arities to get a 
>result, is there an order that is preferred for the extra recursion 
>accumulation values? Here I have [m predicate?] and [found m 
>predicate?] versions of the function, but after looking at it for so 
>long I think it might be more natural to put found as the last argument, 
> as 
>in [m predicate? found], but I'm wondering if there's a standard to 
>follow with things like this.
>4. When passing functions as arguments, as I have here with the 
>predicate? function, is there a standard naming convention? I used a 
>question mark here, but would predicate be preferable, or even simply f
>?
>5. Is writing this function even necessary? I didn't see a function 
>that serves the same purpose in the standard libraries, but I'm very new 
>and could easily have missed something!
>
> I know that's a lot to ask for such a short segment of code. Feel free to 
> answer as many/few of these questions as you'd like, as any help would be 
> greatly appreciated (though, if you're going to answer one, I think point 
> #2 is the most important) :)
>
>
> Thanks in advance, fellow clojurians!
>

-- 
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: ClojureScript 1.9.854

[Leon Grapenthin]

Yes, it does make CLJSJS obsolete and the new method is to include Node 
modules from NPM.

CLJSJS was never the one true way, especially for production. It lacked 
deduplication of transitive dependencies that were not packed per CLJSJS 
and of course support for dependencies that where are not included in 
CLJSJS. 
It was nice to get started quickly, but in production one compiled its own 
bundle of js deps e. g. via webpack, and handwritten (or handcopypasted) 
externs.

As a newcomer, you won't have to deal with all that in the future, which is 
one of the many benefits of this release.

Nonetheless this new functionality will probably take an iteration or two 
until its stable.

On Sunday, July 30, 2017 at 9:42:32 PM UTC+2, Daniel wrote:
>
> For someone who is new to clojurescript and pretty confused by 
> clojurescript dependency management in general, does this release obsolete 
> cljsjs for new projects and what is the new method?
>
> On Friday, July 28, 2017 at 4:55:04 PM UTC-5, David Nolen wrote:
>>
>> ClojureScript, the Clojure compiler that emits JavaScript source code.
>>
>> README and source code: https://github.com/clojure/clojurescript
>>
>> Leiningen dependency information:
>>
>> [org.clojure/clojurescript "1.9.854"]
>>
>> This is a significant feature release. Notable new features include
>> comprehensive NPM dependency support, overhauled code splitting,
>> enhanced JavaScript module preprocessing, declared global exports for
>> foreign libs, and checked array operations. There are also a large
>> number of fixes, changes, and minor enhancementes. For more detailed
>> descriptions of the major enhancements, please refer to the last month
>> of posts https://clojurescript.org/news/news.
>>
>> As always, feedback welcome!
>>
>> ## 1.9.854
>>
>> ### Enhancements
>> * CLJS-2280: Provide process.env :preload and auto-configure
>> * CLJS-2279: Infer `:module-type ` for provided `node_modules`
>> * CLJS-2250: Support :foreign-libs overrides via :provides
>> * CLJS-2243: Self-host: Add support for :global-exports
>> * CLJS-2232: Self-host: Add support for string-based requires
>> * add *print-fn-bodies* knob, set to false
>> * CLJS-2198: Safe array operations
>> * CLJS-2217: Support `:rename` for JS modules
>> * CLJS-2214: Support :global-exports for foreign libraries
>> * CLJS-1428: Add a cljs.core/*command-line-args* var
>> * CLJS-2061: Support ns :require for JS libs, allow strings along with 
>> symbol
>> * CLJS-2148: Add warnings for invalid use of aget and aset
>> * CLJS-2143: Add support for symbol preprocess values
>>
>> ### Changes
>> * CLJS-2273: Bump tools.reader to 1.0.3 and development dependencies
>> * CLJS-2235: Allow passing extra maven opts to build scripts
>> * CLJS-2267: Allow ^:const inlined vars to affect if emission
>> * CLJS-2245: Add support for using a local `node_modules` installation 
>> through a new `:node-modules` compiler flag
>> * CLJS-2002: Don't throw when no *print-fn* is set
>> * support Clojure primitive array type hints, core.async no longer
>>   gives warnings
>> * CLJS-2213: Node.js target should use node_modules index to emit 
>> platform specific require
>> * CLJS-2200: bump to tools.reader 1.0.2
>> * CLJS-2135: require macro prints last result of loaded-libs
>> * CLJS-2192: Add ChakraCore testing facilities
>> * CLJS-1800: Defer to tools.reader for cljs.reader functionality
>> * CLJS-2163: Clean up uses of aget / aset on objects
>> * CLJS-2184: Add `ns-publics` and `ns-imports`
>> * CLJS-2183: Assert arguments are quoted symbols in some core macros
>> * CLJS-2182: Assert argument to resolve is a quoted symbol
>> * CLJS-2186: Update docstrings for aget/aset to be consistent with Clojure
>> * CLJS-2180: Allow compiling `:modules` with whitespace optimizations
>> * CLJS-1822: Use `:file-min` when processing JS modules with advanced 
>> optimizations
>> * CLJS-2169: Error when compiling with :source-map and advanced 
>> optimizations
>> * CLJS-2037: Throw if overwriting alias in current namespace
>> * CLJS-2160: Add loaded? and prefetch functions to cljs.loader
>> * CLJS-2148: Add unsafe-get and use goog.object
>> * CLJS-2161: Bump Closure Compiler to June 2017 release
>>
>> ### Fixes
>> * CLJS-1854: Self-host: Reload ns with const
>> * CLJS-2278: JavaScript object literals are printed wth keys that cannot 
>> be read
>> * CLJS-2276: Self-host: Need test.check dep for CLJS-2275
>> * CLJS-2275: cljs.spec.alpha/fdef resolves eagerly
>> * CLJS-2259: Extra .cljs_node_repl directory containing cljs.core output
>> * CLJS-2274: Update CI script to install deps
>> * CLJS-2269: Warn on top level code split loads
>> * CLJS-2272: Tests that depended on default install deps behavior failing
>> * CLJS-2255: Clean up :npm-deps
>> * CLJS-2263: Docstring for neg-int? backwards
>> * CLJS-2262: Correct comment that *warn-on-infer* is file-scope
>> * CLJS-2258: Stack overflow regression for sequence xform applied to 
>> eduction
>> * CLJS-2256: Generated code doesn't add 

Re: ANN: ClojureScript 1.9.854

[Leon Grapenthin]

Amazing release, trying it out right now.

Just wanted to see if including this 
works: https://github.com/coopermaruyama/react-web3

I try to :require it via [react-web3 :as w3]

Unfortunately this gives me a not-found error. Also I noticed that CLJS 
indeed downloaded react-web3 to "node_modules", but the folder is missing 
from the node_modules folder in the compilers output.

Am I requiring it wrong, or is it not supported for some reason?

Kind regards,
 Leon.

On Friday, July 28, 2017 at 11:54:42 PM UTC+2, David Nolen wrote:
>
> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "1.9.854"]
>
> This is a significant feature release. Notable new features include
> comprehensive NPM dependency support, overhauled code splitting,
> enhanced JavaScript module preprocessing, declared global exports for
> foreign libs, and checked array operations. There are also a large
> number of fixes, changes, and minor enhancementes. For more detailed
> descriptions of the major enhancements, please refer to the last month
> of posts https://clojurescript.org/news/news.
>
> As always, feedback welcome!
>
> ## 1.9.854
>
> ### Enhancements
> * CLJS-2280: Provide process.env :preload and auto-configure
> * CLJS-2279: Infer `:module-type ` for provided `node_modules`
> * CLJS-2250: Support :foreign-libs overrides via :provides
> * CLJS-2243: Self-host: Add support for :global-exports
> * CLJS-2232: Self-host: Add support for string-based requires
> * add *print-fn-bodies* knob, set to false
> * CLJS-2198: Safe array operations
> * CLJS-2217: Support `:rename` for JS modules
> * CLJS-2214: Support :global-exports for foreign libraries
> * CLJS-1428: Add a cljs.core/*command-line-args* var
> * CLJS-2061: Support ns :require for JS libs, allow strings along with 
> symbol
> * CLJS-2148: Add warnings for invalid use of aget and aset
> * CLJS-2143: Add support for symbol preprocess values
>
> ### Changes
> * CLJS-2273: Bump tools.reader to 1.0.3 and development dependencies
> * CLJS-2235: Allow passing extra maven opts to build scripts
> * CLJS-2267: Allow ^:const inlined vars to affect if emission
> * CLJS-2245: Add support for using a local `node_modules` installation 
> through a new `:node-modules` compiler flag
> * CLJS-2002: Don't throw when no *print-fn* is set
> * support Clojure primitive array type hints, core.async no longer
>   gives warnings
> * CLJS-2213: Node.js target should use node_modules index to emit platform 
> specific require
> * CLJS-2200: bump to tools.reader 1.0.2
> * CLJS-2135: require macro prints last result of loaded-libs
> * CLJS-2192: Add ChakraCore testing facilities
> * CLJS-1800: Defer to tools.reader for cljs.reader functionality
> * CLJS-2163: Clean up uses of aget / aset on objects
> * CLJS-2184: Add `ns-publics` and `ns-imports`
> * CLJS-2183: Assert arguments are quoted symbols in some core macros
> * CLJS-2182: Assert argument to resolve is a quoted symbol
> * CLJS-2186: Update docstrings for aget/aset to be consistent with Clojure
> * CLJS-2180: Allow compiling `:modules` with whitespace optimizations
> * CLJS-1822: Use `:file-min` when processing JS modules with advanced 
> optimizations
> * CLJS-2169: Error when compiling with :source-map and advanced 
> optimizations
> * CLJS-2037: Throw if overwriting alias in current namespace
> * CLJS-2160: Add loaded? and prefetch functions to cljs.loader
> * CLJS-2148: Add unsafe-get and use goog.object
> * CLJS-2161: Bump Closure Compiler to June 2017 release
>
> ### Fixes
> * CLJS-1854: Self-host: Reload ns with const
> * CLJS-2278: JavaScript object literals are printed wth keys that cannot 
> be read
> * CLJS-2276: Self-host: Need test.check dep for CLJS-2275
> * CLJS-2275: cljs.spec.alpha/fdef resolves eagerly
> * CLJS-2259: Extra .cljs_node_repl directory containing cljs.core output
> * CLJS-2274: Update CI script to install deps
> * CLJS-2269: Warn on top level code split loads
> * CLJS-2272: Tests that depended on default install deps behavior failing
> * CLJS-2255: Clean up :npm-deps
> * CLJS-2263: Docstring for neg-int? backwards
> * CLJS-2262: Correct comment that *warn-on-infer* is file-scope
> * CLJS-2258: Stack overflow regression for sequence xform applied to 
> eduction
> * CLJS-2256: Generated code doesn't add newline after sourceMappingURL 
> comment
> * CLJS-2254: Module Indexing: Provide relative paths for a package's main 
> module
> * CLJS-2248: Build API tests rely on Yarn
> * CLJS-2239: Self-host: Add `:target :nodejs` to the docstrings in cljs.js
> * CLJS-2251: Follow-up fix to CLJS-2249 and related commit
> * CLJS-2249: Provide a test for d4b871cce73
> * CLJS-2246: Revert CLJS-2245 and CLJS-2240 and fix `lein test`
> * CLJS-2244: Orphaned processed JS modules breaks :modules
> * CLJS-2242: Lots of undeclared Var warns in cljs.spec.gen.alpha
> * CLJS-2241: 

Re: [clojure.spec/form] Need for evaluated subspecs

[Leon Grapenthin]

Hi Alex, thanks for replying. Indeed I don't have practical use for s/form 
right now; I'm just trying to guess what could be a good use in the future 
:) 

On Thursday, May 18, 2017 at 10:01:25 PM UTC+2, Alex Miller wrote:
>
>
>
> On Thursday, May 18, 2017 at 12:37:26 PM UTC-5, Leon Grapenthin wrote:
>>
>> I also have this problem. 
>>
>> 1. If I create a dynamic spec constructor per defmacro and invoke it, 
>> it's s/form gives the primitive specs form - because spec doesn't provide 
>> me with a way to facilitate specs that capture their form.
>>
>
> The idea of providing custom form serialization support is one I have 
> spent quite a bit of time looking at (in particular wrt s/&, s/keys*, and 
> the range specs, but in practice the same problem is being worked around in 
> the coll specs, etc). I've done spikes on three possible directions for 
> this and I can't say any of them is an unambiguous win so it's going to 
> require some Rich time at some point to make further decisions. In some 
> ways it's an analogous problem to how custom gens are implemented.
>  
>
>> 2. If I apply that invocation to another primitive spec, s/form of that 
>> just contains the macro invocation form.
>>
>> If this is intentional, I'd also like to know the underlying design rule 
>> (not the reasons why that is so in the current implementation): Why should 
>> this result in two different forms for one and the same spec to deal with, 
>> instead of one.
>>
>
> The principle is to capture the spec form at the time of construction for 
> the purposes of a) reporting and b) serialization via s/form. That seems 
> satisfied in both cases. 
>  
>
>> The reason to create "dynamic" spec constructors is usually to avoid 
>> boilerplate when writing specs. Unless I'm missing what I shouldn't do, I'd 
>> prefer to have direct support for that spares me having to deal with two 
>> forms.
>>
>
> In what way are you "dealing with" two forms? Why is that a problem?
>  
>
>>
>> Kind regards,
>>  Leon.
>>
>> On Thursday, May 18, 2017 at 6:35:46 PM UTC+2, Alex Miller wrote:
>>>
>>>
>>>
>>> On Wednesday, May 17, 2017 at 3:02:17 PM UTC-5, marian...@vacuumlabs.com 
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am writing a function that transforms Specs to another formats 
>>>> (similar to the JSON Schema). Assuming from this post 
>>>> <http://www.metosin.fi/blog/clojure-spec-as-a-runtime-transformation-engine/>,
>>>>  
>>>> I am not the only one. There is no surprise that I am using 
>>>> clojure.spec/form. Unfortunately I am not fully satisfied with its 
>>>> output. To illustrate the problem let's suppose that my transformer will 
>>>> be 
>>>> used by a third person who like to write its own spec-generating helpers:
>>>>
>>>> (require '[clojure.spec.alpha :as spec])
>>>>
>>>> (spec/def ::forgivable-keyword (spec/conformer (fn [x] (cond (keyword? 
>>>> x) x
>>>>  (string? 
>>>> x) (keyword x)
>>>>  true 
>>>> ::spec/invalid
>>>>
>>>> (defn kw-enum [& enum-values] (spec/and ::forgivable-keyword (apply 
>>>> hash-set enum-values)))
>>>>
>>>>
>>> s/and (and all of the spec forms) are macros to facilitate capturing the 
>>> spec form for use in s/form and error reporting.
>>>
>>> In this case, (apply hash-set enum-values) is not either a predicate or 
>>> a set and thus is not a valid spec to use in s/and. 
>>>
>>> I presume what you're looking for is the ability to dynamically create 
>>> specs - for this, please consider using either eval or a macro.
>>>
>>>  
>>>
>>>> Cool! Let's look how can my transformer cope with it!
>>>>
>>>> (spec/form (kw-enum :a :b :c))
>>>> ; (clojure.spec.alpha/and 
>>>> :my-ns/forgivable-keyword (clojure.core/apply clojure.core/hash-set 
>>>> enum-values))
>>>>
>>>> Ouch! Have I just seen a local symbol in the form? I am sorry third 
>>>> person, I won't be able to transform the output of your spec-generating 
>>>> functions. Unless they are macros:
>>>>
>>>> (defmacro 
>>>> kw-enum [& enum-values] `(spec/and ::forgivable-keyword 

Re: [clojure.spec/form] Need for evaluated subspecs

[Leon Grapenthin]

I also have this problem. 

1. If I create a dynamic spec constructor per defmacro and invoke it, it's 
s/form gives the primitive specs form - because spec doesn't provide me 
with a way to facilitate specs that capture their form.

2. If I apply that invocation to another primitive spec, s/form of that 
just contains the macro invocation form.

If this is intentional, I'd also like to know the underlying design rule 
(not the reasons why that is so in the current implementation): Why should 
this result in two different forms for one and the same spec to deal with, 
instead of one.

The reason to create "dynamic" spec constructors is usually to avoid 
boilerplate when writing specs. Unless I'm missing what I shouldn't do, I'd 
prefer to have direct support for that spares me having to deal with two 
forms.

Kind regards,
 Leon.

On Thursday, May 18, 2017 at 6:35:46 PM UTC+2, Alex Miller wrote:
>
>
>
> On Wednesday, May 17, 2017 at 3:02:17 PM UTC-5, marian...@vacuumlabs.com 
>  wrote:
>>
>> Hi,
>>
>> I am writing a function that transforms Specs to another formats (similar 
>> to the JSON Schema). Assuming from this post 
>> ,
>>  
>> I am not the only one. There is no surprise that I am using 
>> clojure.spec/form. Unfortunately I am not fully satisfied with its 
>> output. To illustrate the problem let's suppose that my transformer will be 
>> used by a third person who like to write its own spec-generating helpers:
>>
>> (require '[clojure.spec.alpha :as spec])
>>
>> (spec/def ::forgivable-keyword (spec/conformer (fn [x] (cond (keyword? x) 
>> x
>>  (string? x) 
>> (keyword x)
>>  true 
>> ::spec/invalid
>>
>> (defn kw-enum [& enum-values] (spec/and ::forgivable-keyword (apply 
>> hash-set enum-values)))
>>
>>
> s/and (and all of the spec forms) are macros to facilitate capturing the 
> spec form for use in s/form and error reporting.
>
> In this case, (apply hash-set enum-values) is not either a predicate or a 
> set and thus is not a valid spec to use in s/and. 
>
> I presume what you're looking for is the ability to dynamically create 
> specs - for this, please consider using either eval or a macro.
>
>  
>
>> Cool! Let's look how can my transformer cope with it!
>>
>> (spec/form (kw-enum :a :b :c))
>> ; (clojure.spec.alpha/and 
>> :my-ns/forgivable-keyword (clojure.core/apply clojure.core/hash-set 
>> enum-values))
>>
>> Ouch! Have I just seen a local symbol in the form? I am sorry third 
>> person, I won't be able to transform the output of your spec-generating 
>> functions. Unless they are macros:
>>
>> (defmacro kw-enum [& enum-values] `(spec/and ::forgivable-keyword ~(apply 
>> hash-set enum-values)))
>>
>> (spec/form (kw-enum :a :b :c))
>> ; (clojure.spec.alpha/and :my-ns/forgivable-keyword #{:c :b :a})
>>
>> This approach looks better. How does it work in combination with other 
>> specs?
>>
>> (spec/form (spec/nilable (kw-enum :a :b :c)))
>> ; (clojure.spec.alpha/nilable (my-ns/kw-enum :a :b :c))
>>
>> There we are. A third-person's function is in the form. We could use eval to 
>> resolve it, but do we want to? 
>>
>
> Sure. It resolved to a spec last time, why not this time? OR, why do you 
> need to resolve it at all? (this to some degree depends on the use case)
>  
>
>> It has been already evaluated once. What if there are some side effects?
>>
>
> Then I'd say you already have more important problems.
>  
>
>> Practically, one has no option to write spec-generating function and 
>> maintain usability of the spec/form at the same time. Therefore one of 
>> four situations must have happened. Either I got something wrong, Specs are 
>> not meant to be introspected, Specs are not meant to be generated or 
>> spec/form is badly designed. Which one is it?
>>
>
> Seems to me like you can generate and introspect this fine. I think that 
> if you are introspecting spec forms, you will encounter resolved symbols 
> referring to functions. How you approach the use of those depends on your 
> context.
>
> Another option still coming (work in progress) is to use specs on spec 
> forms (CLJ-2112) to create conformed spec data, then s/unform back to a 
> spec form. 
>  
>
>>
>> (In the case of the fourth one I have some suggestions, but lets keep 
>> them for later conversation)
>>
>> Thanks for your time
>>
>> Marian
>>
>

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

Re: [ANN] Clojure 1.9 / clojure.spec split

[Leon Grapenthin]

Thanks for the update, this seems like a good decision allowing things to 
evolve more quickly.

Does that also mean that there are no breaking changes intended to current 
non .alpha namespaces/APIs? 

Kind regards,
 Leon

On Wednesday, April 26, 2017 at 5:30:56 PM UTC+2, Alex Miller wrote:
>
> We are moving spec out of the Clojure repo/artifact and into a library to 
> make it easier to evolve spec independently from Clojure. While we consider 
> spec to be an essential part of Clojure 1.9, there are a number of design 
> concerns to resolve before it can be finalized. This allows us to move 
> towards a production Clojure release (1.9) that depends on an alpha version 
> of spec. Users can also pick up newer versions of the spec alpha library as 
> desired. Additionally, this is a first step towards increased support for 
> leveraging dependencies within Clojure.
>
>
> We will be creating two new contrib libraries that will contain the 
> following (renamed) namespaces:
>
>
> *org.clojure/spec.alpha*
> clojure.spec.alpha  (previously clojure.spec)
> clojure.spec.gen.alpha  (previously clojure.spec.gen)
> clojure.spec.test.alpha (previously clojure.spec.test)
>
>
> *org.clojure/core.specs.alpha*
> clojure.core.specs.alpha(previously clojure.core.specs)
>
>
> In most cases, we expect that users have aliased their reference to the 
> spec namespaces and updating to the changed namespaces will only require a 
> single change at the point of the require.
>
>
> *How will ClojureScript's spec implementation change?*
>
>
> ClojureScript will also change namespace names to match Clojure. 
> Eventually, the ClojureScript implementation may move out of ClojureScript 
> and into the spec.alpha library - this is still under discussion.
>
>
> *Why do the libraries and namespaces end in alpha?*
>
>
> The "alpha" indicates that the spec API and implementation is still 
> subject to change.
>
>
> *What will happen when the spec api is no longer considered alpha?*
>
>
> At that point we expect to release a non-alpha version of the spec library 
> (with non-alpha namespaces). Users may immediately begin to use that 
> version of spec along with whatever version of Clojure it depends on. 
> Clojure itself will depend on it at some later point. Timing of all these 
> actions is TBD.
>
>
> *Will the library support Clojure 1.8 or older versions?*
>
>
> No. spec uses new functions in Clojure 1.9 and it has never been a goal to 
> provide spec for older versions. Rather, we are trying to accelerate the 
> release of a stable Clojure 1.9 so that users can migrate forward to a 
> stable production release with access to an alpha version of spec, and 
> access to ongoing updated versions as they become available.
>
>
>

-- 
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: (doseq/lazy/interop)? problem, different behaviour when adding a println

[Leon Grapenthin]

Hi Lucas,
 lazy sequences, as the one produced by the map/filter construct, aren't 
realized at once. I. e. they are returned as a sequence, but your map and 
filter lambdas are only invoked once somebody looks at whats in the 
sequence. Usually, steps are evaluated in chunks of size 32.

Your filter lambda is depending on mutable Java map.

When you count a lazy sequence, all elements are realized. 

So depending on whether you invoke count, the lambda will be invoked with a 
different version of the Java map.

You should solve this by eliminating the mutable state Java map - it makes 
your filter lambda impure. Lazy evaluation does not work with impure 
functions.

I'd recommend to learn about reduce, which will help you to write this much 
more concisely.

Kind regards, 
 Leon.

On Saturday, April 22, 2017 at 2:41:09 PM UTC+2, Lucas Wiener wrote:
>
> Hi all,
>
> I'm working on solving the problem http://adventofcode.com/2016/day/11 , 
> and ran into some weird behaviour. I have solved the actual problem, so 
> let's not focus on it.
>
> Here's my code:
>
> (defn compute3
>   {:test (fn []
>(is= (compute3 (create-state "F4 .  .  .  .  .  "
> "F3 .  .  .  LG .  "
> "F2 .  HG .  .  .  "
> "F1 E  .  HM .  LM "))
> 11))}
>   [state]
>   (let [done-simple-state (state->simple-state (construct-finished-state 
> state))
> inner-fn (fn [states steps java-memory-map]
>(println "On step" steps)
>(println "Number of states" (count states))
>(let [next-states (->> states
>   (map (fn [state]
>  (->> (get-next-states 
> state)
>   (filter (fn [s] 
> (nil? (.get java-memory-map (state->simple-state s
>   (flatten))]
>  ;; (println (count next-states)) <- Uncomment this 
> line to change the behavior
>  (if (.get java-memory-map done-simple-state)
>steps
>(do (doseq [next-state next-states]
>  (.put java-memory-map (state->simple-state 
> next-state) steps))
>(recur next-states (inc steps) 
> java-memory-map)]
> (inner-fn [state] 0 (java.util.HashMap.
>
> When running this in the repl I get the following output:
>
> On step 0
> Number of states 1
> On step 1
> Number of states 1
> On step 2
> Number of states 3
> On step 3
> Number of states 11
> On step 4
> Number of states 14
> On step 5
> Number of states 22
> On step 6
> Number of states 37
> On step 7
> Number of states 48
> On step 8
> Number of states 35
> On step 9
> Number of states 22
> On step 10
> Number of states 17
> On step 11
> Number of states 7
>
> However, if I uncomment the println statement I get the following output 
> in the REPL:
>
> On step 0
> Number of states 1
> 1
> On step 1
> Number of states 1
> 3
> On step 2
> Number of states 3
> 11
> On step 3
> Number of states 11
> 15
> On step 4
> Number of states 15
> 28
> On step 5
> Number of states 28
> 63
> On step 6
> Number of states 63
> 107
> On step 7
> Number of states 107
> 90
> On step 8
> Number of states 90
> 82
> On step 9
> Number of states 82
> 115
> On step 10
> Number of states 115
> 81
> On step 11
> Number of states 81
> 110
>
> Please note that "On step 4" prints "Number of states 14" and "Number of 
> states 15"  differently.
>
> Any thoughts?
>

-- 
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: clojure.spec explain and multi-arity functions with first optional argument

[Leon Grapenthin]

Please try whether my CLJ-2013 
 patch fixes the issue for 
you. From my observation it should.

On Saturday, April 22, 2017 at 7:31:48 PM UTC+2, Yegor Timoshenko wrote:
>
> (require '[clojure.spec :as s])
> (require '[clojure.spec.test :refer [instrument]])
>
> (defn request ([url]) ([params url]))
>
> (s/fdef request
>   :args (s/cat :params (s/? map?) :url string?))
>
> (instrument `request)
> (request [] "")
>
> ExceptionInfo Call to #'user/request did not conform to spec:
> In: [0] val: [] fails at: [:args :url] predicate: string?
> :clojure.spec/args  ([] "")
> :clojure.spec/failure  :instrument
> :clojure.spec.test/caller  {:file "form-init1226863901212006294.clj", 
> :line 1, :var-scope user/eval2193}
>   clojure.core/ex-info (core.clj:4725)
>
> I expected that it would fail at `map?` predicate rather than at `string?` 
> predicate.
> s/or produces better explanation, but at the same time is relatively more 
> verbose:
>
> (require '[clojure.spec :as s])
> (require '[clojure.spec.test :refer [instrument]])
>
> (defn request ([url]) ([params url]))
>
> (s/fdef request
>   :args (s/or :simple (s/cat :url string?)
>:advanced (s/cat :params map? :url string?)))
>
> (instrument `request)
> (request [] "")
>
> ExceptionInfo Call to #'user/request did not conform to spec:
> In: [0] val: [] fails at: [:args :simple :url] predicate: string?
> In: [0] val: [] fails at: [:args :advanced :params] predicate: map?
> :clojure.spec/args  ([] "")
> :clojure.spec/failure  :instrument
> :clojure.spec.test/caller  {:file "form-init1226863901212006294.clj", 
> :line 1, :var-scope user/eval2208}
>   clojure.core/ex-info (core.clj:4725)
>
> Is it subject to improvement? https://dev.clojure.org/jira/browse/CLJ-1982 
> might be the same issue.
>

-- 
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 it normal for exercise-fn to return examples that don't conform?

[Leon Grapenthin]

Generated samples aren't unique.

Conform like this:

(s/conform (:args (s/get-spec `wtv)) [0])


On Thursday, March 30, 2017 at 2:55:35 AM UTC+2, Didier wrote:
>
> If you look at this example:
>
> (defn wtv [in] (if (= 0 in) 0 10))
> (s/fdef wtv
> :args (s/cat :in int?)
> :ret (s/and int? #(not= 0 %)))
>
> (s/exercise-fn `wtv)
> (s/conform `wtv (wtv 0))
>
> You'll see that exercise gives you most of the time the following sample:
>
> [(0) 0]
>
> But this fails to conform:
>
> => (s/conform `wtv (wtv 0))
>
> => :clojure.spec/invalid
>
>
>  Also, why does exercise give repeated samples? Shouldn't they be unique?
>
> ([(0) 0] 
>  [(-1) 10] 
>  [(0) 0] 
>  [(-1) 10] 
>  [(-2) 10] 
>  [(2) 10] 
>  [(0) 0] 
>  [(-1) 10] 
>  [(-2) 10] 
>  [(0) 0]) 
>
> Thanks
>

-- 
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: Version control at the function level - a la Rich

[Leon Grapenthin]

Look for https://github.com/Datomic/codeq. Certainly there is more 
potential to pursue this nowadays with tools.analyzer. There is also an 
open source Java git implementation which might be worth checking out as a 
replacement for shelling out.

I find this an interesting topic to explore. Here is an interesting thread 
on the Erlang board, where Joe Armstrong (the Erlang inventor) also 
suggested this 
idea http://erlang.org/pipermail/erlang-questions/2011-May/058768.html - He 
mentioned it in a recent conversation with Alan Kay. I haven't read it all 
but it is certainly interesting to study to find out why they didn't 
implement it - to see if we could do better. (Limitations of erlang vs. 
limitations of the concept as a whole).

On Friday, February 17, 2017 at 10:39:12 PM UTC+1, Terje Dahl wrote:
>
> I recall Rich Hickey talking about this a few years back, but can't find 
> anything about it.  
> Am I just imaging it?
> Or could someone point me in the right direction
>

-- 
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: cognitect.http-client submit spec mismatch

[Leon Grapenthin]

It is this: https://mvnrepository.com/artifact/com.cognitect/http-client

One encounters the problem when enabling instrumentation and calling submit 
incorrectly.

On Friday, February 17, 2017 at 3:37:39 PM UTC+1, Alex Miller wrote:
>
> What is cognitect.http-client and how are you encountering the problem?
>
> On Friday, February 17, 2017 at 4:05:28 AM UTC-6, Leon Grapenthin wrote:
>>
>> I don't know where else to file this bug:
>>
>> - The spec of submit is in the .specs namespace, and it does not refer to 
>> the correct var.
>>
>>
>>

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

cognitect.http-client submit spec mismatch

[Leon Grapenthin]

I don't know where else to file this bug:

- The spec of submit is in the .specs namespace, and it does not refer to 
the correct var.


-- 
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: if nil is true

[Leon Grapenthin]

Hi Sayth, welcome to Clojure.

Read like this:

(nil? nil) 
;-> true
Is nil nil? True. 

(true? nil) 
;-> false
Is nil true? False.

Kind regards,
 Leon.

On Monday, January 30, 2017 at 8:34:09 AM UTC+1, Sayth Renshaw wrote:
>
> Hi
>
> If nil is true 
>
> clojure-noob.core> (nil? nil)
> true
>
> Then why doesn't nil return from this statement as the first true value?
>
> clojure-noob.core> (or false nil true)
> true
>
> Sausages does as expected.
>
> clojure-noob.core> (or false "sausages" true)
> "sausages"
>
> Thanks
>
> Sayth
>

-- 
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: clojure.spec: behaviour of ? macro

[Leon Grapenthin]

Hi Marc, 

 note that the return of gen/sample is 10 examples. Each one is a 
collection.

So the collection [] matches your spec, as does [:c]. And so on.

A regex-op outside of a regex-op always specs a collection. If used within 
another regex-op, it just specs an element.

To illustrate:
(gen/sample (s/gen (s/cat :kw (s/? #{:a :b :c :d})) :num number?))

((-2.0) (:a -3.0) (0) (1) (-2.625) (:a -1) (:d -1.5625) (0.75) (:a -24) (:d 
-22))


Kind regards,
 Leon.
On Saturday, January 28, 2017 at 6:29:39 PM UTC+1, Marc Wilhelm Küster 
wrote:
>
> Good afternoon,
>
> like obviously quite a few others on this list I am looking into the 
> upcoming (and IMHO absolutely great) clojure.spec 
> During this I noted that the  ? macro seems to behave differently from 
> what I would have naively expected from its documentation (cf. 
> https://clojure.github.io/clojure/branch-master/clojure.spec-api.html#clojure.spec/?
> ):
>
> ? macro
>
> Usage: (? pred-form)
>
> Returns a regex op that matches zero or one value matching
> pred. Produces a single value (not a collection) if matched.
>
>
> In contract, with the namespaces set to 
> [clojure.spec :as s]
> [clojure.spec.gen :as gen]
>
> the following snippet
>
> (s/def ::abcd #{:a :b :c :d})
> (gen/sample (s/gen (s/? ::abcd)))
>
> returns a collection of collections:
> ([] [:c] [:d] [:b] [:b] [] [:a] [] [:d] [])
>
> I would have expected to find either the value itself or nothing, a 
> behaviour that would seem to me also more practical when composing larger 
> records with optional elements. However, I might be misreading the 
> documentation and would be grateful for any clarification
>
> Best regards,
>
> Marc
>
>

-- 
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: Spec of conform of spec

[Leon Grapenthin]

Alex, I thought about this and it appears to be a convenience problem. Spec 
is e. g. excellent to parse a e. g. a Query DSL (which is my current side 
project) via conform. But then you have that large data structure that you 
want to break down and operate on in several functions. So you need to have 
the specs for the conformed structure built by spec. 

I found a surprisingly easy way to do so:

(defmacro conformed
  "Takes a spec conformable and unformable spec.  Returns a spec that
  validates and generates conformed values per spec."
  [spec]
  `(s/with-gen (fn [v#]
 (try
   (= v#
  (s/conform ~spec (s/unform ~spec v#)))
   (catch Throwable _# false)))
 (fn []
   (gen/fmap (fn [v#] (s/conform ~spec v#))
 (s/gen ~spec)

Do you think it's a good idea to pursue this way?

Kind regards, 
 Leon.
On Thursday, September 1, 2016 at 2:33:17 PM UTC+2, Alex Miller wrote:
>
> I think you may be confusing the return value of a predicate value (acting 
> as a spec) with the return value of the function passed to conformer.
>
> In the former case a predicate function's return value is a logically 
> truthy value and a return of nil or false indicates the value is invalid.
>
> The function passed to a conformer is expected to return either a 
> conformed value or ::s/invalid.
>
>

-- 
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: s/def: Rationale, tradeoffs? When to emulate this pattern?

[Leon Grapenthin]

While I can follow "we have namespaced names" I find it difficult to follow 
"too much stuff onto vars and var meta". I feel this is what OP is asking 
for.

- What is meant by "too much"? When is var metadata "too much"?
- What problem can/did result from "too much"?
- Why is this assumed limitation always stated as primary motivation? Are 
there not other reasons like enabling non var-tied specs like for keywords?
- Have s/fdefs been considered for vars? What is the reason/intended use 
for s/fdefs in the global registry?

Kind regards,
 Leon

On Tuesday, November 29, 2016 at 5:16:36 PM UTC+1, Alex Miller wrote:
>
> At the risk of repeating what you already said, we are pushing too much 
> stuff onto vars and var meta. We have namespaced names so there's no reason 
> to push more stuff into vars and we can use an independent registry.
>
>
> On Tuesday, November 29, 2016 at 8:57:47 AM UTC-6, kovasb wrote:
>>
>> Spec is surprisingly easy to grok given how much it does. 
>>
>> s/def jumped out at me as an out-of-the-box choice, that I could not 
>> immediately rationalize. 
>>
>> So I'm wondering: why not just use standard def? What does one gain/lose?
>>
>> This is not just an academic question. Lots of people like me look at 
>> Clojure's APIs as an example to follow, so now I'm wondering when I should 
>> make the same choice.
>>
>> I asked Rich about this at the Lisp NYC meetup, the response was to the 
>> effect of "vars are already overloaded, lets use a separate database", 
>> which makes sense but the implications of that are not clicking. 
>>
>>
>>
>>
>>

-- 
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: s/def: Rationale, tradeoffs? When to emulate this pattern?

[Leon Grapenthin]

The registry is stored in a global atom which is usually considered an 
anti-pattern in library code. It makes sense here though, based on the idea 
that global conflicts are avoided by namespaced keywords.

What bothers me though is reloadability. When I hit 
clojure.tools.namespace.repl/reload-all, I potentially end up with zombie 
specs which can have unexpected effects (note s/keys allows undefed kws). 
Not wanting to hijack this thread, but is this gonna be resolved in ctn or 
somehow?

Kind regards,
 Leon.

On Tuesday, November 29, 2016 at 5:16:36 PM UTC+1, Alex Miller wrote:
>
> At the risk of repeating what you already said, we are pushing too much 
> stuff onto vars and var meta. We have namespaced names so there's no reason 
> to push more stuff into vars and we can use an independent registry.
>
>
> On Tuesday, November 29, 2016 at 8:57:47 AM UTC-6, kovasb wrote:
>>
>> Spec is surprisingly easy to grok given how much it does. 
>>
>> s/def jumped out at me as an out-of-the-box choice, that I could not 
>> immediately rationalize. 
>>
>> So I'm wondering: why not just use standard def? What does one gain/lose?
>>
>> This is not just an academic question. Lots of people like me look at 
>> Clojure's APIs as an example to follow, so now I'm wondering when I should 
>> make the same choice.
>>
>> I asked Rich about this at the Lisp NYC meetup, the response was to the 
>> effect of "vars are already overloaded, lets use a separate database", 
>> which makes sense but the implications of that are not clicking. 
>>
>>
>>
>>
>>

-- 
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: When to halt-when?

[Leon Grapenthin]

Thanks for answering, Alex. I do already understand the limitations of 
halt-when from the implementation point of view.

To make my question more clear: What kind of practical problem is halt-when 
designed to solve, especially as a very limited transducer?

I am failing derive any practical problem from your examples and similar 
ones I have made up for myself - Inputs / transducers producing custom 
error objects that one wants to return don't really seem like something one 
encounters when writing Clojure, do they?

Kind regards,
 Leon.

On Thursday, November 3, 2016 at 8:03:16 PM UTC+1, Alex Miller wrote:
>
> halt-when does require some knowledge about the transducible context where 
> it is used, particularly because it will be exposed to the completed result 
> of the computation. I think it's really primarily applicable for something 
> like transduce (and not as much for into, sequence, eduction, or chan for 
> differing reasons).
>
> (transduce (comp (halt-when :err) (map inc)) + 0
>
>   (range 5))
>
> ;;=> 15
>
>
> (transduce (comp (halt-when :err) (map inc)) + 0
>
>(concat (range 3) [{:err "oops"}] (range 3)))
>
> ;;=> {:err "oops"}
>
>
>
>
>
> On Thursday, November 3, 2016 at 1:06:36 PM UTC-5, Leon Grapenthin wrote:
>>
>> What is the intended usage of halt-when? 
>>
>> The naming of halt-when hints at imperative / non-collection contexts but 
>> I'm failing to guess what such a context could look like? 
>>
>> What is an intended usecase for the default behavior "the input that 
>> triggered the predicate will be returned"? 
>>
>> For collection contexts, it seems odd that the transduced result is not 
>> opaque to retf because it requires one to make the transducer depend on the 
>> later application which breaks promise/design of transducers as reusable 
>> algorithmic transformations in many contexts.
>>
>> To illustrate
>>
>> (into [] (halt-when true? conj) [false false true])
>>
>> Doesn't work because into internally uses transients. One has to 
>> (halt-when true? conj!), then [false false true] is returned - but it is a 
>> hack using the internals of into.
>>
>> (sequence (halt-when true? conj) [false false true])
>>
>> Returns (false false), a different result.
>>
>> For core.async channels I can imagine that it doesn't work at all, but 
>> have not tried.
>>
>

-- 
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: comp and partial vs ->>

[Leon Grapenthin]

This style is only good if you do damn good naming on your "explaining 
variables". So while more names can really improve readability, bad names 
do the opposite by adding confusion and misdirection. This pattern enforces 
naming for every step. Good names are difficult, so I can only recommend to 
not use this style as a "silver bullet" or default. If you don't have time 
for the names in the first place, prefer threading macros, which still 
provide for great readability and can be edited with less typing overhead.

Note that you could have used the same names as right hand comments in the 
threading macro which IMO is the best of both worlds.

Regarding this discussion in general, I find #(my-fn %) to be preferable 
over (partial my-fn) in most cases. My understanding is that partial was 
introduced to the language before the terse lambda #/% syntax and is mostly 
superseded by it. 

In summary comp and partial are specifically useful if you transform 
functions algorithmically! If you just need to chain a few things while 
typing, #(... %) syntax and the arrow macro are most intuitive to write and 
read.

On Monday, October 31, 2016 at 3:50:08 AM UTC+1, Mikera wrote:
>
> On Thursday, 27 October 2016 22:56:42 UTC+8, JHacks wrote:
>>
>> I have some confusion about how the function `comp` works, especially as
>> compared to the threading macro `->>`.
>>
>> From the book *Clojure Programming* (pages 70-71 of Chapter 2: Functional
>> Programming), the following two functions are described as functionally
>> equivalent:
>>
>> (def camel->keyword
>>   (comp keyword
>> str/join
>> (partial interpose \-)
>> (partial map str/lower-case)
>> #(str/split % #"(?<=[a-z])(?=[A-Z])")))
>>
>> (defn camel->keyword*
>>   [s]
>>   (->> (str/split s #"(?<=[a-z])(?=[A-Z])")
>>(map str/lower-case)
>>(interpose \-)
>>str/join
>>keyword))
>>
>> Why does the first function, `camel->keyword`, need to use `partial` with 
>> the
>> `map` and `interpose` functions? The second function, `camel->keyword*`, 
>> does
>> not need to use `partial`.
>>
>
> I actually prefer the following style to both of the above:
>
> (defn camel->keyword*
>  [s]
>  (let [words (str/split s #"(?<=[a-z])(?=[A-Z])")
>lc-words (map str/lower-case words)
>joined-words (str/join "-" lc-words)]
>(keyword joined-words))) 
>
> Reasons:
> - Your intermediate values are explicitly named, which helps to make the 
> code self-describing
> - It is (marginally) more performant than the composed function case (I 
> think exactly matches the threading macro)
> - You can use the intermediate values in more than one of the following 
> steps if needed, which can make refactoring / adding new features easier
> - The ordering is (to me) more logical as it describes the stages of the 
> transformation in the order they are performed.
> - It is less "Clever". Clever code is generally bad for maintenance and 
> future understanding. Both functional composition and the 
> code-transformation effects of the threading macro represent conceptual 
> overhead that you don't need to pay (in this case).
>
>
>  
>

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

When to halt-when?

[Leon Grapenthin]

What is the intended usage of halt-when? 

The naming of halt-when hints at imperative / non-collection contexts but 
I'm failing to guess what such a context could look like? 

What is an intended usecase for the default behavior "the input that 
triggered the predicate will be returned"? 

For collection contexts, it seems odd that the transduced result is not 
opaque to retf because it requires one to make the transducer depend on the 
later application which breaks promise/design of transducers as reusable 
algorithmic transformations in many contexts.

To illustrate

(into [] (halt-when true? conj) [false false true])

Doesn't work because into internally uses transients. One has to (halt-when 
true? conj!), then [false false true] is returned - but it is a hack using 
the internals of into.

(sequence (halt-when true? conj) [false false true])

Returns (false false), a different result.

For core.async channels I can imagine that it doesn't work at all, but have 
not tried.

-- 
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 an easy way for s/keys spec to work against both qualified/unqualiffied keys at the same time?

[Leon Grapenthin]

They are not exclusive

(s/def ::baz (skeys :req [::foo] :req-un [::bar]))

works.

On Friday, October 14, 2016 at 7:07:39 AM UTC+2, Ikuru Kanuma wrote:
>
> Hi,
>
> I was reading the official spec guide's explanation for the s/keys macro, 
> played around with it a bit,
> and was a little surprised that the :req and :req-un are exclusive specs 
> as illustrated below:
>
> (ns my.ns
>   (:require [clojure.spec :as s]))
>
> (s/def ::some-number int?)
> (s/def ::map-with-numbers1 (s/keys :req [::some-number]))
> (s/valid? ::map-with-numbers1 {::some-number 3}) => true
> (s/valid? ::map-with-numbers1 {:some-number 3}) => false
>
> (s/def ::map-with-numbers2 (s/keys :req-un [::some-number]))
> (s/valid? ::map-with-numbers2 {::some-number 3}) => false
> (s/valid? ::map-with-numbers2 {:some-number 3}) => true
>
> In other words, would there a convenient way to specify a spec that would 
> work for both qualified/unqualified keys at the same time?
> ;;Want a spec that validates as follows
> (s/valid? ::map-with-numbers {::some-number 3}) => true
> (s/valid? ::map-with-numbers {:some-number 3}) => true
>
> Regards,
>
> Ikuru
>

-- 
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: complex made simple?

[Leon Grapenthin]

Rich has mentioned Polyas "How to solve it" in several talks. It's a great 
book on the matter.

On Friday, October 14, 2016 at 11:59:56 AM UTC+2, Alan Forrester wrote:
>
> In Rich Hickey's talk "Simple Made Easy" he mentioned that there are 
> ways to take a system that somebody else wrote that is complex and 
> simplify it. 
>
> Can anyone recommend some resources on how to do this? 
>
> Thanks, 
> Alan Forrester 
>

-- 
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: Clojure docstring style

[Leon Grapenthin]

Couldn"t you just do it like this?

1. Parse docstring into symbols
2. If symbol is defined in the current ns, hyperlink
3. If symbol is namespace-qualified, hyperlink
4. If symbol is name of an arg, hyperlink

This should leave very few false positives where an english word is the 
name of a var in your ns or of an fn-arg which I'd expect to be very rare - 
would be more than good enough for me.

Docstring syntax for IDEs and generators is something I never liked. They 
are strings, not data, by definition. There are already too many 
conventions for different tools so a a common convention is not likely to 
happen so this would fragment how docstrings look like even more.

On Sunday, May 15, 2016 at 7:42:11 PM UTC+2, cskksc wrote:
>
> Hello,
> We are working on a new feature in CIDER which would parse a docstring and 
> create hyperlinks that follow the functions/vars/interop-forms mentioned 
> there.
> It is very similar to the "See Also" links shown by ClojureDocs 
> . Right now, we are using backticks to identify 
> the reference forms and create links.
>
> So a function like;
>
> (defn test-mde
>   "Does something with `user-ns/user-fn`.
>Also see: `clojure.core/map`, `clojure.core/reduce`, `defn`"
>   []
>   (+ 1 1))
>
> would create hyperlinks for map, reduce, defn and user-ns/user-fn forms.
>
> What style do you tend to use in such docstrings ?
> It would help us figure out whether to continue with the backticks or do 
> something else, like adding a configuration variable for this.
>
> Thanks,
> Chaitanya
>

-- 
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 top use cases

[Leon Grapenthin]

It is not just convenience. For example agents don't provide functionality 
like buffering, backpressure and select aka alts. If you send an action to 
an agent you don't get to know when it's done or to choose what to do if it 
is currently busy. 

On Monday, September 19, 2016 at 11:49:13 AM UTC+2, Matan Safriel wrote:
>
> Thanks, and I put the blog post on my reading list. 
> Although I can't avoid thinking that we already have asynchronous idioms 
> in the core language itself, like agents. I think the crux for server-side 
> is more about the convenient piping, rather than the mere asynchronism 
> itself, but I might be wrong in any of this.
>
> On Mon, Sep 19, 2016 at 9:14 AM, Mond Ray  > wrote:
>
>> Pushing asynchrony further into the stack is useful for reliability and 
>> fault tolerance. We can also use it as a basis for Complex Event Processing 
>> using time series windows. 
>>
>> I wrote up a few examples in my blog 
>> 
>>  
>> if you have the time to check out a longer explanation with code.
>>
>> I recently wrote a small set of functions to enable HTML5 Server Sent 
>> Events from any Kafka topic which also uses core.async (with an example 
>> using Aleph and Compojure). You might like to check that repo 
>>  out too.
>>
>> Ray
>>
>> On Sunday, 18 September 2016 08:37:38 UTC+2, Matan Safriel wrote:
>>>
>>> Hi,
>>>
>>> It's very easy to see how core.async solves callback hell for front-end 
>>> development with clojurescript.
>>> In what use cases would you use it for server-side? we already have 
>>> non-blocking IO from Java, and we have clojure agents. So what's a bunch of 
>>> salient use cases?
>>> Are there prominent clojure http server implementations which rely on it 
>>> for transcending the threaded web service paradigm?
>>>
>>> Thanks,
>>> Matan
>>>
>>> -- 
>> 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/peJXvE0nBZs/unsubscribe.
>> To unsubscribe from this group and all its topics, 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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Leon Grapenthin]

Hi Alex, I could track down why explain stops 
early. http://dev.clojure.org/jira/browse/CLJ-2013

On Wednesday, August 24, 2016 at 11:33:43 PM UTC+2, Leon Grapenthin wrote:

>
>
> On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote:
>>
>> predicate: (cat :args (* :clojure.core.specs/binding-form) :varargs (? 
>> (cat :amp #{(quote &)} :form :clojure.core.specs/binding-form))), 
>>
>> the predicate that is actually failing in the spec, probably not 
>> particularly helpful given the complexity (and recursiveness) of the 
>> destructuring specs
>>
>>
>> Extra input 
>>
>> this is the part of cat that I think could be made more explicit - could 
>> be saying here that the value it had (above) was expected to match the next 
>> part of the cat (binding-form). So that could say the equivalent of 
>> "Expected binding-form but had non-matching value ..." and could even find 
>> what parts of that value matched and maybe which didn't (the :or keys) such 
>> that you'd have a more precise description. There is some more stuff Rich 
>> and I have worked on around "hybrid maps" which is the case here with map 
>> destructuring - it's particularly challenging to get a good error out of 
>> that at the moment, but there's more that can be done.
>>
>>
> Thank you for doing the walkthrough. I observed this too and became 
> sceptical why spec doesn't go further down the path and apparently stops at 
> ::binding-form.
> I could isolate the problem a bit by changing the spec of ::arg-list and 
> temporarily removing the :varargs branch.
>
> (s/def ::arg-list
>   (s/and
> vector?
> (s/cat :args (s/* ::binding-form)
> ;;   :varargs (s/? (s/cat :amp #{'&} :form ::binding-form))
>)))
>
> This leads to a much better message:
>
> (s/explain (:args (s/get-spec 'clojure.core/defn))
>'[foo [{:or {a/b 42}}]])
>
> In: [1 0] val: {:or #:a{b 42}} fails spec: :clojure.core.specs/local-name 
> at: [:bs :arity-1 :args :args :sym] predicate: simple-symbol?
> In: [1 0 0] val: ([:or #:a{b 42}]) fails spec: 
> :clojure.core.specs/seq-binding-form at: [:bs :arity-1 :args :args :seq] 
> predicate: (cat :elems (* :clojure.core.specs/binding-form) :rest (? (cat 
> :amp #{(quote &)} :form :clojure.core.specs/binding-form)) :as (? (cat :as 
> #{:as} :sym :clojure.core.specs/local-name))),  Extra input
> In: [1 0 :or a/b 0] val: a/b fails spec: :clojure.core.specs/or at: [:bs 
> :arity-1 :args :args :map :or 0] predicate: simple-symbol?
> In: [1 0] val: {:or #:a{b 42}} fails spec: :clojure.core.specs/arg-list 
> at: [:bs :arity-n :bodies :args] predicate: vector?
>
> The third one is the desired one and very precise - it seems to be usually 
> the one with the largest :in path. The length of the :in path seems a good 
> sorting criterium for reporting.
>
> However I was not able to track the issue further down. I also wasn't able 
> to reproduce a more minimal case of this problem. It seems like a bug in 
> how spec parses and must have something to do with s/cat and the :varargs 
> branch.
>

-- 
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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Leon Grapenthin]

On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote:
>
> predicate: (cat :args (* :clojure.core.specs/binding-form) :varargs (? 
> (cat :amp #{(quote &)} :form :clojure.core.specs/binding-form))), 
>
> the predicate that is actually failing in the spec, probably not 
> particularly helpful given the complexity (and recursiveness) of the 
> destructuring specs
>
>
> Extra input 
>
> this is the part of cat that I think could be made more explicit - could 
> be saying here that the value it had (above) was expected to match the next 
> part of the cat (binding-form). So that could say the equivalent of 
> "Expected binding-form but had non-matching value ..." and could even find 
> what parts of that value matched and maybe which didn't (the :or keys) such 
> that you'd have a more precise description. There is some more stuff Rich 
> and I have worked on around "hybrid maps" which is the case here with map 
> destructuring - it's particularly challenging to get a good error out of 
> that at the moment, but there's more that can be done.
>
>
Thank you for doing the walkthrough. I observed this too and became 
sceptical why spec doesn't go further down the path and apparently stops at 
::binding-form.
I could isolate the problem a bit by changing the spec of ::arg-list and 
temporarily removing the :varargs branch.

(s/def ::arg-list
  (s/and
vector?
(s/cat :args (s/* ::binding-form)
;;   :varargs (s/? (s/cat :amp #{'&} :form ::binding-form))
   )))

This leads to a much better message:

(s/explain (:args (s/get-spec 'clojure.core/defn))
   '[foo [{:or {a/b 42}}]])

In: [1 0] val: {:or #:a{b 42}} fails spec: :clojure.core.specs/local-name 
at: [:bs :arity-1 :args :args :sym] predicate: simple-symbol?
In: [1 0 0] val: ([:or #:a{b 42}]) fails spec: 
:clojure.core.specs/seq-binding-form at: [:bs :arity-1 :args :args :seq] 
predicate: (cat :elems (* :clojure.core.specs/binding-form) :rest (? (cat 
:amp #{(quote &)} :form :clojure.core.specs/binding-form)) :as (? (cat :as 
#{:as} :sym :clojure.core.specs/local-name))),  Extra input
In: [1 0 :or a/b 0] val: a/b fails spec: :clojure.core.specs/or at: [:bs 
:arity-1 :args :args :map :or 0] predicate: simple-symbol?
In: [1 0] val: {:or #:a{b 42}} fails spec: :clojure.core.specs/arg-list at: 
[:bs :arity-n :bodies :args] predicate: vector?

The third one is the desired one and very precise - it seems to be usually 
the one with the largest :in path. The length of the :in path seems a good 
sorting criterium for reporting.

However I was not able to track the issue further down. I also wasn't able 
to reproduce a more minimal case of this problem. It seems like a bug in 
how spec parses and must have something to do with s/cat and the :varargs 
branch.

-- 
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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Leon Grapenthin]

I welcome the strict checking over backwards compatibility for broken 
syntax. E. g. allowing things like symbols in the ns decl would require 
supporting that as a feature in future updates, analyzer code, other hosts 
etc. The Clojure devs should not have to worry things with so little use.

Still the error messages are simply far from good enough and that is what 
appears to me as the main problem OP has. If the compiler had pointed him 
to two fixes he could have done in a minute then he had not complained and 
instead felt more happy with his new compiler. 

Here is my story when I loaded a large codebase today with 1.9-alpha11:

Call to clojure.core/defn did not conform to spec: In: [1 0] val:
   ({:keys [money/major money/minor money/currency], :or #:money{major
   0, minor 0, currency :EUR}}) fails spec:
   :clojure.core.specs/arg-list at: [:args :bs :arity-1 :args]
   predicate: (cat :args (* :clojure.core.specs/binding-form) :varargs
   (? (cat :amp #{(quote &)} :form
   :clojure.core.specs/binding-form))), Extra input In: [1 0] val:
   {:keys [money/major money/minor money/currency], :or #:money{major
   0, minor 0, currency :EUR}} fails spec:
   :clojure.core.specs/arg-list at: [:args :bs :arity-n :bodies :args]
   predicate: vector?  :clojure.spec/args (format-money [{:keys
   [money/major money/minor money/currency], :or #:money{major 0,
   minor 0, currency :EUR}}] (str major "," (if (zero? minor) "-"
   minor) " €"))


I know where the problem is immediately  because I looked at above error 
and quickly jumped to the code that didn't work. Then I guessed it right 
because I know what has been changed from Alex Release notes and because I 
had recently inquired on this board about :or destructoring and probably 
because I am a long time Clojure user. The problem is that :or in map 
destructuring with namespaced keywords was not officially supported before 
1.9 (but sadly worked exactly opposite to how it is supported now)

Compare that the more common story of someone who has not followed every 
newspiece lately and just wants to upgrade from 1.8 to 1.9 - How could he 
tell whats wrong from above error message? Following above error message by 
looking up specs and following index paths like [1 0] is a manual process 
that costs and feels like debugging a difficultly hidden bug. The 
time/utility distance to a hand written macro assert like "Keys in :or 
destructoring must be unqualified symbols" currently does not justify the 
use of specs for such things. It's by far worse than the NPE Stacktraces 
popping up from nowhere that one learns to value and utilize after a month 
or so in Clojure. 

It seems that improving the error messages we can calculate from specs data 
is something that more people should think about and improve for 1.9. I'd 
be willing to invest time if needed / input is welcome. Alternatively a way 
to integrate custom error messages into specs directly could also be 
helpful.
 
(But I still don't really see how above spec tells me that I shouldn't use 
qualified symbols in :or destructoring - do you?)

On Monday, August 22, 2016 at 5:08:57 PM UTC+2, Alex Miller wrote:
>
> I've added library related fixes related to core specs to an info page at:
>
> http://dev.clojure.org/display/design/Errors+found+with+core+specs
>
>
> On Sunday, August 21, 2016 at 8:24:20 PM UTC-5, Alex Miller wrote:
>>
>> On Sunday, August 21, 2016 at 5:28:57 PM UTC-5, lvh ‌ wrote:
>>>
>>> FYI, while I disagree with your conclusion (I think we should go fix 
>>> libraries instead), I ran into the same issue just now for roughly the same 
>>> reason, except the thing that pulled in an old version of core.unify was 
>>> core.typed, which pulls in 0.5.3 through core.contracts. 
>>>
>>
>> BTW, core.contracts was also updated to 0.0.6 last week to use the latest 
>> core.unify.
>>
>>

-- 
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] Automatic Clojure Type Annotations

[Leon Grapenthin]

Wow. I can imagine this saving a day or two when trying to type or spec a 
legacy codebase.

Wouldn't it also be / Is it possible to infer deeper calling levels?

I. e. if (defn f [x] (g x)) generate types/specs for g and f from (f 42)?

Because when one doesn't have unit tests, she could gain exponentially more 
types/specs from only calling some top level functions with constants.

Thank you for doing this and kind regards, Leon.

On Wednesday, August 17, 2016 at 8:14:04 PM UTC+2, Ambrose 
Bonnaire-Sergeant wrote:
>
> Here's a demo of generating clojure.spec specs + Typed Clojure types
> for functions and macros.
>
> https://www.youtube.com/watch?v=DRJeHthzOjk
>
> Thanks for your support!
> Ambrose
>
> On Sun, Aug 14, 2016 at 10:33 PM, Ambrose Bonnaire-Sergeant <
> abonnair...@gmail.com > wrote:
>
>> Hi,
>>
>> Happy to announce a new open-source Clojure tool
>> to generate core.typed type annotations from tests. It's part of a
>> new crowdfunding campaign 
>> 
>>  
>> I'm running, read on for details!
>>
>> # What is it?
>>
>> This tool infers top-level annotations by instrumenting
>> your code, running tests, and finally inserts inferred
>> annotations directly in your source code.
>>
>> Here's a quick gif 
>>  demonstrating 
>> the tool.
>>
>> You can read more about the ideas behind the tool here 
>> .
>>
>> # Prototype: Write Tests, Get Types!
>>
>> The latest core.typed release contains a
>> prototype for Automatic Annotation inference.
>>
>> Try it out here !
>>
>> # Crowdfunding
>>
>> I am running a crowdfunding campaign 
>> 
>>  
>> to support
>> Automatic Annotations for Typed Clojure. The money
>> will help me keep working on Typed Clojure and travel
>> to industry conferences.
>>
>> I will be writing more about how this tool works, and
>> the general applicability of the infrastructure its
>> based on. 
>>
>> For example:
>> - clojure.spec generative tests can help generate type annotations, and
>> - the infrastructure could even be repurposed to generate clojure.spec 
>> specs!
>> - mutually recursive map structures can be inferred
>> - ideas for polymorphic inference
>>
>> There are only 7 days left and we need $7,500 to
>> reach our goal. Please help by contributing!
>>
>> Thanks for your support!
>> Ambrose
>>
>
>

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

[Leon Grapenthin]

1.9 could still support the behavior that worked in 1.8 and in CLJS, too, 
or throw a compile time Exception. 

If we had known this change in behavior, fixing it in the codebase wouldn't 
have been much trouble. But a missing default can lead to errors far away 
so it takes time to get to the ground of this.

If there was no (working) other way to provide a default for namespaced 
keys in 1.8 I believe that many people will have tried adding the ns and 
ran with it.


On Wednesday, July 6, 2016 at 2:17:14 PM UTC+2, Alex Miller wrote:
>
> This *is* different than 1.8 (and prior) because it has been buggy since 
> namespaced keys were added (due to a lack of tests - entirely my fault). 
> Nothing was ever documented about this behavior - it was purely accidental 
> and I would consider it in the realm of "unspecified".
>
> In 1.9 I added additional tests and tightened up this code in the process 
> of adding the namespaced key support. 
>

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

[Leon Grapenthin]

@Alex Miller: Please reconsider. What you state does not apply to 1.8, i. 
e. the ns is required in :or and such code is broken in 1.9

1.8/1.9 differences:
(let [{:keys [a/b] :or {b 42}} {}] 
  b)
=>
1.8: nil
1.9: 42(let [{:keys [a/b] :or {a/b 42}} {}] 
  b)
=>
1.8: 42
1.9: nil




On Wednesday, July 6, 2016 at 1:43:46 PM UTC+2, Alex Miller wrote:
>
> This is the correct behavior. The :or map keys are always the local names 
> being bound (not the keys being looked up in the map). 
>
> > On Jul 6, 2016, at 4:40 AM, Leon Grapenthin <grapent...@gmail.com 
> > wrote: 
> > 
> > Another small bug report: 
> > 
> > (let [{:keys [a/b] :or {a/b 42}} {}] 
> >   b) 
> > 
> > Evaluates to nil, but should evaluate to 42 
> > 
> > (let [{:keys [a/b] :or {b 42}} {}] 
> >b) 
> > 
> > Evaluates to 42, but should evaluate to nil. 
>

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

[Leon Grapenthin]

Small bug report

Throwable->map in core_print.clj doesn't handle Throwable.getCause 
returning null in L463. This results in a NPE in StrackTraceElement->vec in 
the same file in some cases, so printing a stacktrace results in a new 
Exception which is a bit confusing.

On Tuesday, July 5, 2016 at 9:50:47 PM UTC+2, Alex Miller wrote:
>
> Clojure 1.9.0-alpha9 is now available.
>
> Try it via
>
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha9
> - Leiningen: [org.clojure/clojure "1.9.0-alpha9"]
>
> 1.9.0-alpha9 includes the following changes since 1.9.0-alpha8:
>
> - NEW clojure.spec/assert - a facility for adding spec assertions to your 
> code. See the docs for *compile-asserts* 
> 
>  
> and assert 
> 
>  
> for more details.
>
> - clojure.spec/merge - now merges rather than flows in conform/unform
>
> - clojure.spec.test/instrument now reports the caller that caused an :args 
> spec failure and ignores spec'ed macros
>
> - clojure.spec.test - `test`, `test-fn`, `testable-syms` renamed to 
> `check`, `check-fn`, and `checkable-syms` to better reflect their purpose. 
> Additionally, some of the return value structure of `check` has been 
> further improved.
>
> - clojure.core/Throwable->map formerly returned StackTraceElements which 
> were later handled by the printer. Now the StackTraceElements are converted 
> to data such that the return value is pure Clojure data, as intended.
>
>
>
>
>

-- 
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: clojure.spec Invalid token error from different namespace when specs are registered with number

[Leon Grapenthin]

I believe that this is a problem with how the reader resolves aliased 
keywords as the problem can be reproduced without spec. You should file a 
JIRA ticket.

On Wednesday, June 29, 2016 at 9:22:49 AM UTC+2, Mamun wrote:
>
> Hi,
>
> Invalid token error from different namespace when specs are registered 
> with number
>
> Example 
>
> ;one.clj
>
> (s/def ::a string?)
> (s/def ::1 int?)
>
> ::1  ;Ok
> ::a  ;Ok
>
> ;one-test.clj
>
> :one/1  ;; Error
> :one/a  ;;Ok
>
> ;(gen/sample (s/gen ::1))
> ;(gen/sample (s/gen ::a))
>
>
>
> I am not sure, it is bug or not. But error should display in same 
> namespace also. 
>
> Clojure version: [org.clojure/clojure "1.9.0-alpha8"]
>
>
> Br,
> Mamun
>

-- 
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: clojure.spec Invalid token error from different namespace when specs are registered with number

[Leon Grapenthin]

Have isolated more: Namespaced keywords with numbers in the name all don't 
work, but when using double-colon syntax they can be fabricated. 

:a/1 -> RuntimeException Invalid token: :a/1 
 clojure.lang.Util.runtimeException (Util.java:221)
:user/1 ->  RuntimeException Invalid token: :a/1 
 clojure.lang.Util.runtimeException (Util.java:221)

::1 -> :user/1


On Wednesday, June 29, 2016 at 4:21:49 PM UTC+2, Leon Grapenthin wrote:
>
> I believe that this is a problem with how the reader resolves aliased 
> keywords as the problem can be reproduced without spec. You should file a 
> JIRA ticket.
>
> On Wednesday, June 29, 2016 at 9:22:49 AM UTC+2, Mamun wrote:
>>
>> Hi,
>>
>> Invalid token error from different namespace when specs are registered 
>> with number
>>
>> Example 
>>
>> ;one.clj
>>
>> (s/def ::a string?)
>> (s/def ::1 int?)
>>
>> ::1  ;Ok
>> ::a  ;Ok
>>
>> ;one-test.clj
>>
>> :one/1  ;; Error
>> :one/a  ;;Ok
>>
>> ;(gen/sample (s/gen ::1))
>> ;(gen/sample (s/gen ::a))
>>
>>
>>
>> I am not sure, it is bug or not. But error should display in same 
>> namespace also. 
>>
>> Clojure version: [org.clojure/clojure "1.9.0-alpha8"]
>>
>>
>> Br,
>> Mamun
>>
>

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

[Leon Grapenthin]

This is fantastic. Spec really seems to turn out like a "killer-feature" 
for Clojure.

On Wednesday, June 29, 2016 at 12:13:25 AM UTC+2, Alex Miller wrote:
>
> Clojure 1.9.0-alpha8 is now available.
>
> Try it via
>
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha8
> - Dependency: [org.clojure/clojure "1.9.0-alpha8"]
>
> 1.9.0-alpha8 includes the following changes since 1.9.0-alpha7:
>
> The collection spec support has been greatly enhanced, with new controls 
> for conforming, generation, counts, distinct elements and collection kinds. 
> See the docs for every, every-kv, coll-of and map-of for details.
>
> instrumenting and testing has been streamlined and made more composable, 
> with powerful new features for spec and gen overrides, stubbing, and 
> mocking. See the docs for these functions in clojure.spec.test: instrument, 
> test, enumerate-ns and summarize-results.
>
> Namespaced keyword reader format, printing and destructuring have been 
> enhanced for lifting namespaces up for keys, supporting more succinct use 
> of fully-qualified keywords. Updated docs will be added to clojure.org 
> soon.
>
> Many utilities have been added, for keys spec merging, fn exercising, Java 
> 1.8 timestamps, bounded-count and more.
>
> Changelog:
>
> clojure.spec:
>
> - [changed] map-of - now conforms all values and optionally all keys, has 
> additional kind, count, gen options
> - [changed] coll-of - now conforms all elements, has additional kind, 
> count, gen options. No longer takes init-coll param.
> - [added] every - validates a collection by sampling, with many additional 
> options
> - [added] every-kv - validates a map by sampling, with many additional 
> options
> - [added] merge
> - [changed] gen overrides can now be specified by either name or path
> - [changed] fspec generator - creates a function that generates return 
> values according to the :ret spec and ignores :fn spec
> - [added] explain-out - produces an explain output string from an 
> explain-data result
> - [changed] explain-data - output is now a vector of problems with a :path 
> element, not a map keyed by path
> - [added] get-spec - for looking up a spec in the registry by keyword or 
> symbol
> - [removed] fn-spec - see get-spec
> - [added] exercise-fn - given a spec'ed function, returns generated args 
> and the return value
> - All instrument functions moved to clojure.spec.test
>
> clojure.spec.test:
>
> - [changed] instrument - previously took a var, now takes either a symbol, 
> namespace symbol, or a collection of symbols or namespaces, plus many new 
> options for stubbing or mocking. Check the docstring for more info.
> - [removed] instrument-ns - see instrument
> - [removed] instrument-all - see instrument
> - [changed] unstrument - previously took a var, now takes a symbol, 
> namespace symbol, or collection of symbol or namespaces
> - [removed] unstrument-ns - see unstrument
> - [removed] unstrument-all - see unstrument
> - [added] instrumentable-syms - syms that can be instrumented
> - [added] with-instrument-disabled - disable instrument's checking of 
> calls within a scope
> - [changed] check-var renamed to test and has a different signature, check 
> docs
> - [changed] run-tests - see test
> - [changed] run-all-tests - see test
> - [changed] check-fn - renamed to test-fn
> - [added] abbrev-result - returns a briefer description of a test
> - [added] summarize-result - returns a summary of many tests
> - [added] testable-syms - syms that can be tested
> - [added] enumerate-namespace - provides symbols for vars in namespaces
>
> clojure.core:
>
> - [changed] - inst-ms now works with java.time.Instant instances when 
> Clojure is used with Java 8
> - [added] bounded-count - if coll is counted? returns its count, else 
> counts at most first n elements of coll using its seq
>
>

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

[Leon Grapenthin]

I welcome the current naming because for the naming to be consistent it is 
also necessary that names and forms of spec describe what is expected of 
specified data. 

In fact every does require every element to conform to a spec, not just 
some so it is semantically correct. 

(s/sample (s/and number? pos?)) as spec for the return value of (range) 
lacks the clarity of (s/every (s/and number? pos?)).


On Wednesday, June 29, 2016 at 12:37:22 AM UTC+2, Daniel Compton wrote:
>
> I know these were just changed from map-of and coll-of, but the names 
> every and every-kv seem a little confusing. every and every-kv only sample 
> from collections, whereas the name implies that everything in the 
> collection is checked. Additionally, there is an every? in clojure.core 
> which does check a predicate for every value in the collection.
>
> I (loosely) suggest sample and sample-kv as other names, but am not 100% 
> sure I like them.
>
> Thoughts?
>
> On Wed, Jun 29, 2016 at 10:13 AM Alex Miller  > wrote:
>
>> Clojure 1.9.0-alpha8 is now available.
>>
>> Try it via
>>
>> - Download: 
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha8
>> - Dependency: [org.clojure/clojure "1.9.0-alpha8"]
>>
>> 1.9.0-alpha8 includes the following changes since 1.9.0-alpha7:
>>
>> The collection spec support has been greatly enhanced, with new controls 
>> for conforming, generation, counts, distinct elements and collection kinds. 
>> See the docs for every, every-kv, coll-of and map-of for details.
>>
>> instrumenting and testing has been streamlined and made more composable, 
>> with powerful new features for spec and gen overrides, stubbing, and 
>> mocking. See the docs for these functions in clojure.spec.test: instrument, 
>> test, enumerate-ns and summarize-results.
>>
>> Namespaced keyword reader format, printing and destructuring have been 
>> enhanced for lifting namespaces up for keys, supporting more succinct use 
>> of fully-qualified keywords. Updated docs will be added to clojure.org 
>> soon.
>>
>> Many utilities have been added, for keys spec merging, fn exercising, 
>> Java 1.8 timestamps, bounded-count and more.
>>
>> Changelog:
>>
>> clojure.spec:
>>
>> - [changed] map-of - now conforms all values and optionally all keys, has 
>> additional kind, count, gen options
>> - [changed] coll-of - now conforms all elements, has additional kind, 
>> count, gen options. No longer takes init-coll param.
>> - [added] every - validates a collection by sampling, with many 
>> additional options
>> - [added] every-kv - validates a map by sampling, with many additional 
>> options
>> - [added] merge
>> - [changed] gen overrides can now be specified by either name or path
>> - [changed] fspec generator - creates a function that generates return 
>> values according to the :ret spec and ignores :fn spec
>> - [added] explain-out - produces an explain output string from an 
>> explain-data result
>> - [changed] explain-data - output is now a vector of problems with a 
>> :path element, not a map keyed by path
>> - [added] get-spec - for looking up a spec in the registry by keyword or 
>> symbol
>> - [removed] fn-spec - see get-spec
>> - [added] exercise-fn - given a spec'ed function, returns generated args 
>> and the return value
>> - All instrument functions moved to clojure.spec.test
>>
>> clojure.spec.test:
>>
>> - [changed] instrument - previously took a var, now takes either a 
>> symbol, namespace symbol, or a collection of symbols or namespaces, plus 
>> many new options for stubbing or mocking. Check the docstring for more info.
>> - [removed] instrument-ns - see instrument
>> - [removed] instrument-all - see instrument
>> - [changed] unstrument - previously took a var, now takes a symbol, 
>> namespace symbol, or collection of symbol or namespaces
>> - [removed] unstrument-ns - see unstrument
>> - [removed] unstrument-all - see unstrument
>> - [added] instrumentable-syms - syms that can be instrumented
>> - [added] with-instrument-disabled - disable instrument's checking of 
>> calls within a scope
>> - [changed] check-var renamed to test and has a different signature, 
>> check docs
>> - [changed] run-tests - see test
>> - [changed] run-all-tests - see test
>> - [changed] check-fn - renamed to test-fn
>> - [added] abbrev-result - returns a briefer description of a test
>> - [added] summarize-result - returns a summary of many tests
>> - [added] testable-syms - syms that can be tested
>> - [added] enumerate-namespace - provides symbols for vars in namespaces
>>
>> clojure.core:
>>
>> - [changed] - inst-ms now works with java.time.Instant instances when 
>> Clojure is used with Java 8
>> - [added] bounded-count - if coll is counted? returns its count, else 
>> counts at most first n elements of coll using its seq
>>
>> -- 
>> 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 
>> 

Re: tips on writing modern idiomatic code

[Leon Grapenthin]

https://github.com/bbatsov/clojure-style-guide is a good place to start. 

On Tuesday, June 21, 2016 at 2:46:22 PM UTC+2, Sergey Didenko wrote:
>
> Hi,
>
> What would you advise for writing-rewriting your Clojure code in MODERN 
> idiomatic way?
>
> Using Kibit?
>
> Pasting your code samples on some review site?
>
> Asking help in IRC channel?
>
> Asking here?
>
> Reading some noticeable open source projects? 
>
> Reading some new Clojure book?
>
> I ask about the latest Clojure specifically. 
>
> I have not given very focused attention to Clojure since version 1.4 and 
> would like to grasp the WHOLE PICTURE of "good" modern Clojure. Currently 
> it feels like a lot of latest knowledge is located in different pieces all 
> over the internet. Or may be I just don't know where to look.
>
>
>

-- 
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: Spec of conform of spec

[Leon Grapenthin]

Yes I have tried that. As soon as you use things like `or` or `alt` it 
becomes quite the tedious manual effort and you don't get away with s/keys 
anymore.

On Saturday, June 18, 2016 at 8:35:20 PM UTC+2, Josh Tilles wrote:
>
> Have you considered choosing labels that are themselves qualified 
> keywords with registered specs? That might feel like a workaround, but 
> I think it could get you most of what you’re looking for.
>
> For example:
>
> ```
> (s/def ::even-spec even?)
> ;= :user/even-spec
> (s/def ::odd-spec odd?)
> ;= :user/odd-spec
> (s/def ::label-even (s/spec ::even-spec))
> ;= :user/label-even
> (s/def ::label-odd (s/spec ::odd-spec))
> ;= :user/label-odd
> (s/conform (s/cat ::label-even ::even-spec, ::label-odd ::odd-spec) [2 3])
> ;= {:user/label-even 2, :user/label-odd 3}
> (s/conform (s/cat ::label-odd ::even-spec) [2])
> ;= {:user/label-odd 2}
> (s/valid? (s/keys) *1)
> ;= false
> (s/explain (s/keys) *2)
> ; In: [:user/label-odd] val: 2 fails spec: :user/label-odd at: 
> [:user/label-odd] predicate: odd?
> ;= nil
> ```
>
>
> On Saturday, June 18, 2016, Leon Grapenthin <grapent...@gmail.com 
> > wrote:
>
>> Assume I parse with conform. 
>>
>> Then I have functions that operate on the value returned by conform. I 
>> want to spec them.
>>
>> But I can't get a spec for the value returned by conform (so that I can 
>> spec said functions) automatically.
>>
>> Imagine `(s/conform-spec ::my-spec)` would return the spec of the result 
>> of calling (s/confom ::my-spec foo)
>>
>> So it would probably be valuable if a spec could give a spec of what its 
>> conform* returns`
>>
>> -- 
>> 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: Spec of conform of spec

[Leon Grapenthin]

I am not sure whether I understand what you mean. 

Behavior of conform for predicates is to return its return value if it is 
logically true, ::s/invalid otherwise. Thus the predicate itself is the 
spec to its conform*.

s/conformer is only limiting as much as it is to unform, a user would have 
to provide a spec for conforms result as well as he has to provide an 
unform-fn if he wants unforming.

If each spec implemented a conform-spec* method, a spec could very well 
provide a spec of it's conform.

On Saturday, June 18, 2016 at 5:03:33 PM UTC+2, Alex Miller wrote:
>
> Given that conform takes an arbitrary (opaque) function, I don't think 
> that's generically possible.
>
>
> On Saturday, June 18, 2016 at 7:37:33 AM UTC-5, Leon Grapenthin wrote:
>>
>> Assume I parse with conform. 
>>
>> Then I have functions that operate on the value returned by conform. I 
>> want to spec them.
>>
>> But I can't get a spec for the value returned by conform (so that I can 
>> spec said functions) automatically.
>>
>> Imagine `(s/conform-spec ::my-spec)` would return the spec of the result 
>> of calling (s/confom ::my-spec foo)
>>
>> So it would probably be valuable if a spec could give a spec of what its 
>> conform* returns`
>>
>>

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

Spec of conform of spec

[Leon Grapenthin]

Assume I parse with conform. 

Then I have functions that operate on the value returned by conform. I want 
to spec them.

But I can't get a spec for the value returned by conform (so that I can 
spec said functions) automatically.

Imagine `(s/conform-spec ::my-spec)` would return the spec of the result of 
calling (s/confom ::my-spec foo)

So it would probably be valuable if a spec could give a spec of what its 
conform* returns`

-- 
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: instrumenting clojure.core

[Leon Grapenthin]

Thanks Alex, I was experimenting along similar lines. It might work since 
the lazy seq is not realized at this point and :f might not have been 
called. Otherwise the last clause would always hold true or never be called 
(due to earlier ArityException). It covers more of a test for map itself 
(how does map invoke the lambda?) than that it spec's maps arguments.

I have tried various other ways like conformers etc. and have the 
impression that if checking and reporting on correct arity of lambdas 
before invocation is going to become a concern of spec it would appear that 
a new function like "arities f -> set of numbers" as a language feature 
would be truly helpful.

It is certainly going to be interesting where the line to a type system 
will be drawn. For instance generating and checking (in worst case only a 
subset of) required types for :f is only possible if one takes samples from 
the passed colls dynamically which I am not sure spec is capable of or 
designed for. 

Looking forward to further developments of spec :)

On Tuesday, June 14, 2016 at 1:22:23 PM UTC+2, Alex Miller wrote:
>
> I was suggesting that you could do something like this (although I'm 
> pretty sure this doesn't work right now):
>
> (s/fdef map
>   :args (s/cat :f (s/fspec :args (s/+ ::s/any))
>:colls (s/* seqable?))
>   :ret (s/or :seq seqable? :transducer ifn?)
>   :fn #(if (zero? (count (-> % :args :colls)))
>  ;; transducer
>  (ifn? (-> % :ret))
>  ;; lazy seq
>  (and (seqable? (-> % :ret))
>   (= (count (-> % :args :f :args))
>  (count (-> % :args :colls))
>
>
>
> In the map :args, spec the mapping function as well, then use :fn which 
> can either relate the args and ret of the main function OR relationships 
> between the args, as I'm doing at the very end. The input to :fn is the 
> conformed output of the :args and :ret specs. 
>
> But like I said, there are several problems with this right now and I need 
> to discuss more with Rich whether something like this should be possible 
> (mostly the args fspec is where I'm seeing issues.
>
>
> On Monday, June 13, 2016 at 7:57:16 PM UTC-5, Alistair Roche wrote:
>>
>> Oh, I see what you mean now, Leon. Apologies for not reading more 
>> closely! Yours is a much more interesting puzzle.
>>
>> Here's an attempt I made 
>> <https://gist.github.com/atroche/2248efce0dee46a92d021a8bf7e96237>, 
>> groping towards it using reflection, but I couldn't even get that to work. 
>> Would be curious to see what the solution is there, and even more so (like 
>> you) to see if it can be done without reflection.
>>
>> On 13 June 2016 at 17:21, Leon Grapenthin <grapent...@gmail.com 
>> > wrote:
>>
>>> Thank Alistair, but that does not really address my question. Alex 
>>> suggested using :fn of fspec to check arity of a higher-order argument.
>>>
>>> But I could not find a tool to check function arity. Also I doubt :fn is 
>>> going to work since I'd expect it to be invoked /after/ the call - i. e. 
>>> the call would fail before the arity check.
>>>
>>> Note that in your example you can only use spec/generic testing to check 
>>> arity because you know the argument types. You can't test a generic higher 
>>> order fn for just arity like this because the generator won't know the 
>>> correct types to generate.
>>>
>>>
>>> On Monday, June 13, 2016 at 4:00:30 AM UTC+2, Alistair Roche wrote:
>>>>
>>>> Hi Leon,
>>>>
>>>> I think you're looking for fspec 
>>>> <https://clojure.github.io/clojure/branch-master/clojure.spec-api.html#clojure.spec/fspec>,
>>>>  
>>>> unless I'm misunderstanding something. I wrote up an example 
>>>> <https://gist.github.com/atroche/731f80376985773c60d5e943b38d8052> 
>>>> that might be helpful.
>>>>
>>>> @Ryan thanks for starting this thread, and @Alex thanks for responding. 
>>>> It's been an interesting discussion!
>>>>
>>>> Cheers,
>>>>
>>>>
>>

-- 
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: instrumenting clojure.core

[Leon Grapenthin]

Thank Alistair, but that does not really address my question. Alex 
suggested using :fn of fspec to check arity of a higher-order argument.

But I could not find a tool to check function arity. Also I doubt :fn is 
going to work since I'd expect it to be invoked /after/ the call - i. e. 
the call would fail before the arity check.

Note that in your example you can only use spec/generic testing to check 
arity because you know the argument types. You can't test a generic higher 
order fn for just arity like this because the generator won't know the 
correct types to generate.

On Monday, June 13, 2016 at 4:00:30 AM UTC+2, Alistair Roche wrote:
>
> Hi Leon,
>
> I think you're looking for fspec 
> <https://clojure.github.io/clojure/branch-master/clojure.spec-api.html#clojure.spec/fspec>,
>  
> unless I'm misunderstanding something. I wrote up an example 
> <https://gist.github.com/atroche/731f80376985773c60d5e943b38d8052> that 
> might be helpful.
>
> @Ryan thanks for starting this thread, and @Alex thanks for responding. 
> It's been an interesting discussion!
>
> Cheers,
>
>
> On Monday, 13 June 2016 07:17:56 UTC+10, Leon Grapenthin wrote:
>>
>> Alex, thank you for the long and detailed response.
>>
>> The direct linking issue and Ryans last example make me wonder whether 
>> the hard rule
>>
>> "If A and B are both instrumented and if A ever calls B violating B's 
>> spec, A's spec is broken" 
>>
>> holds? If so the direct-linking issue would probably be  a non-concern 
>> since instrumentation within the standard library would not matter because 
>> one could assume that the core lib has been tested already against it's own 
>> specs. If the latter is true (I'm not quite sure) it would appear 
>> worthwhile to look for a counter-example against the former in the standard 
>> library.
>>
>> I'd highly appreciate if you could give an example for checking the arity 
>> of a passed in function since I don't see how to do that right now except 
>> for maybe using reflection?
>>
>> On Sunday, June 12, 2016 at 5:45:17 PM UTC+2, Alex Miller wrote:
>>>
>>>
>>> On Sunday, June 12, 2016 at 9:22:24 AM UTC-5, Leon Grapenthin wrote:
>>>>
>>>> That looks great already. I'm also interested in what the official 
>>>> workflow for adding specs to core is going to be and whether contributions 
>>>> are desired.
>>>>
>>>
>>> Still much to be determined about this but I expect that specs for core 
>>> will be provided and maintained by us, because while there are a lot of 
>>> obvious specs in core, there are also a lot of far more subtle ones. Some 
>>> of the predicates added in the latest alpha5 (seqable?, and the 
>>> simple/qualified ident/keyword/symbol) will not coincidentally be useful in 
>>> these. There are also a lot of cases where there is a judgement call on how 
>>> precise to be (any likely tradeoffs with testing, performance, conciseness).
>>>
>>> Also, there is a significant difference between specs for macros and 
>>> functions in core. Macro args specs will always be checked during 
>>> macroexpansion and this is a path toward better error messages for things 
>>> like defn, ns, etc. I think it would make a lot of sense to deliver those 
>>> with core. Specs for the functions in core are things you likely want 
>>> instrumented at dev time, not at prod time, and fights a bit with direct 
>>> linking. So, one option would be a dev build of Clojure, without direct 
>>> linking and with automatic instrumentation of the functions in core. 
>>> Another would be providing the core function specs externally or optionally 
>>> alongside Clojure. We've only begun discussing how this will wind up.
>>>
>>> I don't agree with the map spec provided because I expect the args and 
>>> ret to be seqable?, not sequential?. For example, you can map over sets, 
>>> which are seqable but not sequential. This kind of subtlety is why I expect 
>>> we will provide the specs for core. Once they exist, we'll be interested in 
>>> tickets on them of course.
>>>
>>> There are also interesting :fn specs you can write on map - you could 
>>> check that if the count of the coll args is 0 that the return is ifn? (a 
>>> transducer) and that if there is at least one coll then the ret is a coll. 
>>> If the colls are all finite, the return coll will have count equal to the 
>>> minimum of the count of the arg colls. I think the transducer/coll 
>>> difference is defin

Re: instrumenting clojure.core

[Leon Grapenthin]

Alex, thank you for the long and detailed response.

The direct linking issue and Ryans last example make me wonder whether the 
hard rule

"If A and B are both instrumented and if A ever calls B violating B's spec, 
A's spec is broken" 

holds? If so the direct-linking issue would probably be  a non-concern 
since instrumentation within the standard library would not matter because 
one could assume that the core lib has been tested already against it's own 
specs. If the latter is true (I'm not quite sure) it would appear 
worthwhile to look for a counter-example against the former in the standard 
library.

I'd highly appreciate if you could give an example for checking the arity 
of a passed in function since I don't see how to do that right now except 
for maybe using reflection?

On Sunday, June 12, 2016 at 5:45:17 PM UTC+2, Alex Miller wrote:
>
>
> On Sunday, June 12, 2016 at 9:22:24 AM UTC-5, Leon Grapenthin wrote:
>>
>> That looks great already. I'm also interested in what the official 
>> workflow for adding specs to core is going to be and whether contributions 
>> are desired.
>>
>
> Still much to be determined about this but I expect that specs for core 
> will be provided and maintained by us, because while there are a lot of 
> obvious specs in core, there are also a lot of far more subtle ones. Some 
> of the predicates added in the latest alpha5 (seqable?, and the 
> simple/qualified ident/keyword/symbol) will not coincidentally be useful in 
> these. There are also a lot of cases where there is a judgement call on how 
> precise to be (any likely tradeoffs with testing, performance, conciseness).
>
> Also, there is a significant difference between specs for macros and 
> functions in core. Macro args specs will always be checked during 
> macroexpansion and this is a path toward better error messages for things 
> like defn, ns, etc. I think it would make a lot of sense to deliver those 
> with core. Specs for the functions in core are things you likely want 
> instrumented at dev time, not at prod time, and fights a bit with direct 
> linking. So, one option would be a dev build of Clojure, without direct 
> linking and with automatic instrumentation of the functions in core. 
> Another would be providing the core function specs externally or optionally 
> alongside Clojure. We've only begun discussing how this will wind up.
>
> I don't agree with the map spec provided because I expect the args and ret 
> to be seqable?, not sequential?. For example, you can map over sets, which 
> are seqable but not sequential. This kind of subtlety is why I expect we 
> will provide the specs for core. Once they exist, we'll be interested in 
> tickets on them of course.
>
> There are also interesting :fn specs you can write on map - you could 
> check that if the count of the coll args is 0 that the return is ifn? (a 
> transducer) and that if there is at least one coll then the ret is a coll. 
> If the colls are all finite, the return coll will have count equal to the 
> minimum of the count of the arg colls. I think the transducer/coll 
> difference is definitely worth spec'ing and would trigger errors in cases 
> where some forgets the coll and accidentally gets a transducer. Is the 
> cardinality check worth it? Probably not.
>
> identity could have a :fn spec that checks that the input and output are 
> identical. That's really the only thing you care about (other than the 
> cardinality of the input). Is this spec really helping you though? Not 
> every spec pays for it's weight and this may be one that isn't worth doing.
>  
>
>> The last example seems like it could be better because the user has to 
>> infer how identity was called within map.
>>
>> So what we'd want is a codependent spec where we can say if you give N 
>> sequences you have to give a fnN. Is this possible with the current ops?
>>
>
> Yes, with fspec - you could have a :fn spec on map that checked that the 
> arity of the fn passed to map matched the number of colls you were passed. 
> That would be better here than the identity spec.
>  
>
>>
>>
>> On Sunday, June 12, 2016 at 3:52:33 PM UTC+2, Ryan Fowler wrote:
>>>
>>> Is there an effort to write specs for Clojure's core namespaces? Apologies 
>>> if this has already been addressed.
>>>
>>> I've been tinkering with trivial (and probably wrong) fdefs on 
>>> clojure.core/map and clojure.core/identity. It seems that the spec 
>>> exception messages are way better than what we have now.
>>>
>>> Code is here: 
>>> https://gist.github.com/ryfow/69a64e966d48258dfa9dcb5aa74005eb 
>>> <https://www.google.com/url?q=https%3A%2F%2Fgist

Re: instrumenting clojure.core

[Leon Grapenthin]

That looks great already. I'm also interested in what the official workflow 
for adding specs to core is going to be and whether contributions are 
desired.

The last example seems like it could be better because the user has to 
infer how identity was called within map.

So what we'd want is a codependent spec where we can say if you give N 
sequences you have to give a fnN. Is this possible with the current ops?


On Sunday, June 12, 2016 at 3:52:33 PM UTC+2, Ryan Fowler wrote:
>
> Is there an effort to write specs for Clojure's core namespaces? Apologies 
> if this has already been addressed.
>
> I've been tinkering with trivial (and probably wrong) fdefs on 
> clojure.core/map and clojure.core/identity. It seems that the spec 
> exception messages are way better than what we have now.
>
> Code is here: 
> https://gist.github.com/ryfow/69a64e966d48258dfa9dcb5aa74005eb
>
>
> =
> Before instrumenting clojure.core/map
> =
> Form: (into [] (map nil [1 2 3] [1 2 3]))
> Exception Class:  java.lang.NullPointerException
> Message:  nil
>
> Form: (into [] (map 1 [1 2 3] [1 2 3]))
> Exception Class:  java.lang.ClassCastException
> Message:  java.lang.Long cannot be cast to clojure.lang.IFn
>
> Form: (into [] (map identity 4))
> Exception Class:  java.lang.IllegalArgumentException
> Message:  Don't know how to create ISeq from: java.lang.Long
>
> =
> After instrumenting clojure.core/map
> =
> Form: (into [] (map nil [1 2 3] [1 2 3]))
> Exception Class:  clojure.lang.ExceptionInfo
> Message:  Call to #'clojure.core/map did not conform to spec:
> In: [0] val: nil fails at: [:args :fn] predicate: ifn?
> :clojure.spec/args  (nil [1 2 3] [1 2 3])
>
>
> Form: (into [] (map 1 [1 2 3] [1 2 3]))
> Exception Class:  clojure.lang.ExceptionInfo
> Message:  Call to #'clojure.core/map did not conform to spec:
> In: [0] val: 1 fails at: [:args :fn] predicate: ifn?
> :clojure.spec/args  (1 [1 2 3] [1 2 3])
>
>
> Form: (into [] (map identity 4))
> Exception Class:  clojure.lang.ExceptionInfo
> Message:  Call to #'clojure.core/map did not conform to spec:
> In: [1] val: 4 fails at: [:args :seq] predicate: sequential?
> :clojure.spec/args  (#object[clojure.core$identity 0x15a04efb 
> "clojure.core$identity@15a04efb"] 4)
>
>
> =
> Before instrumenting clojure.core/identity
> =
> Form: (into [] (map identity [1 2 3] [1 2 3]))
> Exception Class:  clojure.lang.ArityException
> Message:  Wrong number of args (2) passed to: core/identity
>
> =
> After instrumenting clojure.core/identity
> =
> Form: (into [] (map identity [1 2 3] [4 5 6]))
> Exception Class:  clojure.lang.ExceptionInfo
> Message:  Call to #'clojure.core/identity did not conform to spec:
> In: [1] val: (4) fails at: [:args] predicate: (cat :one-argument 
> identity),  Extra input
> :clojure.spec/args  (1 4)
>
>
>

-- 
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: Variadic run!

[Leon Grapenthin]

run is a high performance version of (dorun (map ...)), implemented via 
reduce which also doesn't support a variadic fn. Probably (dorun (map ...)) 
is what you are looking for?

On Sunday, May 29, 2016 at 10:27:54 PM UTC+2, Claudius Nicolae wrote:
>
> run! can eagerly map a function over a coll.
> I think it would be nice to support multiple collections, making it an 
> eager version of map.
>
> My particular use case is running a test over two colls.
>
> (defn check [m1 m2]
>   (is (almost= (:x m1) (:x m2)))
>   (is (= (:y m1) (:y m2
> (run check coll1 coll2)
>

-- 
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: Variadic run!

[Leon Grapenthin]

Have you considered (concat coll1 coll2)?

On Sunday, May 29, 2016 at 10:27:54 PM UTC+2, Claudius Nicolae wrote:
>
> run! can eagerly map a function over a coll.
> I think it would be nice to support multiple collections, making it an 
> eager version of map.
>
> My particular use case is running a test over two colls.
>
> (defn check [m1 m2]
>   (is (almost= (:x m1) (:x m2)))
>   (is (= (:y m1) (:y m2
> (run check coll1 coll2)
>

-- 
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: clojure.spec

[Leon Grapenthin]

That's amazing, David - and much sooner than expected. Thanks for porting so 
fast. Going to use in production asap :)

One question: What is the direction regarding macros? Given that error messages 
are going to be greatly improved once macros are specified I am curious of 
course- can one just write macro specs in Clojure, instrument and figwheel?

An implementation question: Why was this not implemented in conditional 
Clojure? Just to keep separate codebases or not a good fit for other reasons?

-- 
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: clojure.spec

[Leon Grapenthin]

Just had a chance to play around with spec. Looks like this is going to 
destroy a lot of problem space :) Thanks.

Probably a bug:
  (s/exercise
(s/and
 set?
 (s/coll-of
  (s/with-gen keyword?
#(gen/elements [:s1 :s2 :s3]))
  #{})))
;->
([#{} #{}] [#{} #{}] [#{} #{}] [#{:o-85:1ywl} #{:o-85:1ywl}] [#{} #{}] [#{} 
#{}] [#{} #{}] 
[#{:_Qi.Qj?dtMZh_s*3.x.sTxm9-E.NHr!?b5f0Ir2.u.+bof*-P.r.m_y**e0ntq.W+*.+?Urxe+Xp+/Q}
 
#{:_Qi.Qj?dtMZh_s*3.x.sTxm9-E.NHr!?b5f0Ir2.u.+bof*-P.r.m_y**e0ntq.W+*.+?Urxe+Xp+/Q}]
 
[#{} #{}] [#{} #{}])

Reverse argument order to s/and and it works.

On Monday, May 23, 2016 at 4:12:29 PM UTC+2, Rich Hickey wrote:
>
> Introducing clojure.spec 
>
> I'm happy to introduce today clojure.spec, a new core library and support 
> for data and function specifications in Clojure. 
>
> Better communication 
>
> Clojure is a dynamic language, and thus far we have relied on 
> documentation or external libraries to explain the use and behavior of 
> functions and libraries. But documentation is difficult to produce, is 
> frequently not maintained, cannot be automatically checked and varies 
> greatly in quality. Specs are expressive and precise. Including spec in 
> Clojure creates a lingua franca with which we can state how our programs 
> work and how to use them. 
>
> More leverage and power 
>
> A key advantage of specifications over documentation is the leverage they 
> provide. In particular, specs can be utilized by programs in ways that docs 
> cannot. Defining specs takes effort, and spec aims to maximize the return 
> you get from making that effort. spec gives you tools for leveraging specs 
> in documentation, validation, error reporting, destructuring, 
> instrumentation, test-data generation and generative testing. 
>
> Improved developer experience 
>
> Error messages from macros are a perennial challenge for new (and 
> experienced) users of Clojure. specs can be used to conform data in macros 
> instead of using a custom parser. And Clojure's macro expansion will 
> automatically use specs, when present, to explain errors to users. This 
> should result in a greatly improved experience for users when errors occur. 
>
> More robust software 
>
> Clojure has always been about simplifying the development of robust 
> software. In all languages, dynamic or not, tests are essential to quality 
> - too many critical properties are not captured by common type systems. 
> spec has been designed from the ground up to directly support generative 
> testing via test.check https://github.com/clojure/test.check. When you 
> use spec you get generative tests for free. 
>
> Taken together, I think the features of spec demonstrate the ongoing 
> advantages of a powerful dynamic language like Clojure for building robust 
> software - superior expressivity, instrumentation-enhanced REPL-driven 
> development, sophisticated testing and more flexible systems. I encourage 
> you to read the spec rationale and overview  http://clojure.org/about/spec. 
> Look for spec's inclusion in the next alpha release of Clojure, within a 
> day or so. 
>
> Note that spec is still alpha, and some details are likely to change. 
> Feedback welcome. 
>
> I hope you find spec useful and powerful! 
>
> Rich 
>
>

-- 
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: Callback fn in core.async/put!

[Leon Grapenthin]

Looking at it again, it seems like the current docstring is quite up to 
date. Are sure you are on the latest version?

On Wednesday, April 27, 2016 at 9:31:46 PM UTC+2, Alan Thompson wrote:
>
> Thanks for the update. I verified the true/false behavior and submitted a 
> JIRA:  http://dev.clojure.org/jira/browse/ASYNC-167
> Alan
>
> On Wed, Apr 27, 2016 at 12:34 AM, Leon Grapenthin <grapent...@gmail.com 
> > wrote:
>
>> It is true if the put did succeeded, false if the channel was already 
>> closed.
>>
>> Should be clarified in the docstr. "Will throw if closed." is also not 
>> true.
>>
>>
>> On Wednesday, April 27, 2016 at 5:48:09 AM UTC+2, Alan Thompson wrote:
>>>
>>> The docs for put! say
>>>
>>> (put! port val)
>>> (put! port val fn0)
>>> (put! port val fn0 on-caller?)
>>> Asynchronously puts a val into port, calling fn0 (if supplied) when
>>>  complete. nil values are not allowed. Will throw if closed. If
>>>  on-caller? (default true) is true, and the put is immediately
>>>  accepted, will call fn0 on calling thread.  Returns nil.
>>>
>>>
>>> but it doesn't say much about fn0.  Apparently it needs to be a 1-arg 
>>> function (error msg for otherwise).  But, what is the arg passed to it?
>>>
>>> Alan
>>>
>> -- 
>> 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: Callback fn in core.async/put!

[Leon Grapenthin]

It is true if the put did succeeded, false if the channel was already 
closed.

Should be clarified in the docstr. "Will throw if closed." is also not true.

On Wednesday, April 27, 2016 at 5:48:09 AM UTC+2, Alan Thompson wrote:
>
> The docs for put! say
>
> (put! port val)
> (put! port val fn0)
> (put! port val fn0 on-caller?)
> Asynchronously puts a val into port, calling fn0 (if supplied) when
>  complete. nil values are not allowed. Will throw if closed. If
>  on-caller? (default true) is true, and the put is immediately
>  accepted, will call fn0 on calling thread.  Returns nil.
>
>
> but it doesn't say much about fn0.  Apparently it needs to be a 1-arg 
> function (error msg for otherwise).  But, what is the arg passed to it?
>
> Alan
>

-- 
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: How to configure a library from a file in the project that has it as a dependency?

[Leon Grapenthin]

It's very simple: Leave configuration file management and stuff out of the 
lib. Instead, pass the translations dictionary to your library as an 
argument.

On your app level, you could still load the desired dictionary from a 
config file but the lib should stay independent of this.


On Wednesday, April 20, 2016 at 6:09:12 AM UTC+2, Shantanu Kumar wrote:
>
> How about accepting a fn as argument to provide the config required? In 
> that case the user is free to use whichever library/hand-rolled code to 
> read config from a file.
>
> Shantanu
>
> On Tuesday, 19 April 2016 22:15:22 UTC+5:30, Facundo Olano wrote:
>>
>> Hi! I started to use clojure a couple of months ago and now I'm 
>> struggling to extract a little library from a larger project I'm working on.
>>
>> The lib is a gettext-like tool that allows translating strings based on a 
>> translations dictionary. I'd like to be able to include the lib as a 
>> dependency of the larger project and point to my translations dictionary 
>> from a setting in a configuration file (Ideally I would use project.clj to 
>> avoid having a lib specific file just for one setting).
>>
>> My problem is I'm not sure how to read a configuration file in my project 
>> from the generated JAR of the lib (if that's even possible and not a bad 
>> idea for some reason). I tried using configleaf 
>>  and it worked while I 
>> included the lib as a checkout project but it seems the config file gets 
>> freezed to whatever it is when the lib's JAR is packed.
>>
>> I wonder if there's a straightforward and idiomatic way to achieve this. 
>> "That's a terrible idea" type of answers are also welcome :P
>>
>> Thanks, 
>> Facundo.
>>
>

-- 
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] CIDER 0.12 (Seattle)

[Leon Grapenthin]

Is there still a one page version of the manual so that I can use full text 
search like on the old README? Asking beacuse the readthedocs search 
function returns 0 results for "shortcut" or "shortcuts".

Besides thank you very much.

On Sunday, April 17, 2016 at 4:54:44 AM UTC+2, Bozhidar Batsov wrote:
>
> Hey everyone,
>
> CIDER 0.12 (Seattle) is out! It packs a lot of small improvements and bug 
> fixes!
>
> Check out the release notes here 
> https://github.com/clojure-emacs/cider/releases/tag/v0.12.0
>
> We've also got a brand new user manual 
> http://cider.readthedocs.org/en/stable/ for your
> consideration. We'd love to get some help and feedback to make it better. 
>
> Enjoy!
>

-- 
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] CIDER 0.11 Released!

[Leon Grapenthin]

Congratulations. Cider is really awesome!

On Thursday, March 3, 2016 at 6:42:48 AM UTC+1, Bozhidar Batsov wrote:
>
> Hey everyone,
>
> CIDER 0.11 (a.k.a. Bulgaria) is finally out!
>
> Today Bulgarians (like me) celebrate the country's Liberation Day and the 
> rest of the
> world will get to celebrate the release of CIDER 0.11. :-)
>
> Once again we've got a ton of new features, refinements and bugfixes and I 
> hope you're going to love them!
>
> The changelog is here 
> https://github.com/clojure-emacs/cider/releases/tag/v0.11.0
>
> Enjoy!
>
>

-- 
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] walmartlabs/active-status 0.1.2

[Leon Grapenthin]

That seems like a cool thing to have. Thank you.


On Tuesday, February 2, 2016 at 10:31:10 PM UTC+1, Howard M. Lewis Ship 
wrote:
>
> Library for allowing a command line application to report status of 
> multiple asynchronous jobs using an update-in-place status board 
> implemented using terminal capabilities.  Jobs push updates into the status 
> board via core.async channels. Handy for really long running commands.
>
>
> https://github.com/walmartlabs/active-status
>
> -- 
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>

-- 
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] New clojure.org!

[Leon Grapenthin]

Have you considered linking to or embedding Rich Hickeys videos "Clojure 
for Java programmers", "Clojure for Lisp programmers" and "Clojure data 
structures"?

When I was learning the language they served as excellent introductory 
material and among facts really conveyed a "feeling" for the language. 
Maybe David Nolen could add a ClojureScript for Javascript developers in 
similar style?

On Sunday, January 17, 2016 at 5:24:11 PM UTC+1, Alex Miller wrote:
>
> The site does does not have any "learning" material at all. The material 
> on the existing site is intended to be authoritative reference material, 
> written by Rich (or in a few cases me). 
>
> We will add more learning / getting started material - this is definitely 
> the biggest gap in the existing site (although things like Clojure for the 
> Brave and True are great alternatives).
>
> We actually have a body of work in this area already and I will be 
> integrating it as I have time to.
>
>
> On Sun, Jan 17, 2016 at 9:09 AM, Brent Millare  > wrote:
>
>> I think another useful way to look at the issue that Alan brings up is to 
>> view it as a top down vs bottom up approach to learning the language. The 
>> site favors a top down approach, leading with the rationale and concepts 
>> rather than examples that can act like hooks that encourage the reader to 
>> investigate further even without complete understanding. While I'm more of 
>> a default top down thinker myself, I know and respect many bottom up 
>> thinkers. I believe enhancing the website to address both learning 
>> approaches will increase its usability not to just beginners but also to 
>> experienced programmers.
>>
>>
>> On Friday, January 15, 2016 at 7:16:08 PM UTC-5, Alan Moore wrote:
>>>
>>> Great job everyone! I really like the layout and the color scheme, very 
>>> pleasing to the eye and professional looking.
>>>
>>> My *only* constructive comment is that a total newbie landing on 
>>> clojure.org is faced with a lot of reading when maybe they should be 
>>> presented with super basic code examples, just to give them a general feel 
>>> of what Clojure code looks like. Much of this does exist on the site but is 
>>> maybe less accessible and not as up-front as it could be. I'll submit some 
>>> suggestions via the public repo and do my part to help out :-)
>>>
>>> All in all this is looking great and I appreciate the hard work in 
>>> getting it to this point. Thanks Alex for organizing the effort!
>>>
>>> Alan
>>>
>>> On Thursday, January 14, 2016 at 7:45:06 AM UTC-8, Alex Miller wrote:

 The new http://clojure.org is alive!

 Most of the content on the site is the same content as before (but in a 
 new shinier package). However, the site is now sourced from the public 
 repo 
 at https://github.com/clojure/clojure-site and is open for 
 contribution. Contributions (via pull request) require a signed Clojure 
 Contributor Agreement, just as with Clojure itself - if you've already 
 signed it, then you don't need to do anything additional.

 We have been working on several new guides for the new Guides section 
 and you can see things in process at 
 https://github.com/clojure/clojure-site/issues - feel free to discuss 
 on issues there or threads here with a [DOC] indicator. Or on the #docs 
 channel on Slack.

 Big thanks to Tom Hickey on the design for the new site! As always, he 
 was a pleasure to work with.

 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/Qn55soAb5zQ/unsubscribe.
>> To unsubscribe from this group and all its topics, 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 

Re: [ANN] New clojure.org!

[Leon Grapenthin]

Amazing. I really like the clean and minimalistic design.

Congratulations!

On Thursday, January 14, 2016 at 4:45:06 PM UTC+1, Alex Miller wrote:
>
> The new http://clojure.org is alive!
>
> Most of the content on the site is the same content as before (but in a 
> new shinier package). However, the site is now sourced from the public repo 
> at https://github.com/clojure/clojure-site and is open for contribution. 
> Contributions (via pull request) require a signed Clojure Contributor 
> Agreement, just as with Clojure itself - if you've already signed it, then 
> you don't need to do anything additional.
>
> We have been working on several new guides for the new Guides section and 
> you can see things in process at 
> https://github.com/clojure/clojure-site/issues - feel free to discuss on 
> issues there or threads here with a [DOC] indicator. Or on the #docs 
> channel on Slack.
>
> Big thanks to Tom Hickey on the design for the new site! As always, he was 
> a pleasure to work with.
>
> Alex
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CIDER 0.10 is out!

[Leon Grapenthin]

Wow. The debugger is simply awesome. Thanks! 

The inline evaluation with in buffer display is also a cool feature. And it 
works really well with the debugger.

Upgrading highly recommended :)

On Saturday, December 26, 2015 at 4:11:53 PM UTC+1, frye wrote:
>
>
> On Tue, Dec 22, 2015 at 10:57 AM, Artur Malabarba  > wrote:
>
>> Hi Timothy, 
>> Glad you liked it! :-)
>>
>> > The only thing I'm wondering, is if the debugger has:
>> > a step into function
>>
>> Not yet. :-(
>> For now, you can instrument in advance the function you want to step into.
>>
>> > ability to set a break point in a 3rd party lib (where you can't put 
>> #break or #debug)
>>
>> This should be working. What I always do is visit the function in 
>> question with `cider-find-var` and then just instrument it with the usual 
>> command `C-u C-M-x`.
>>
>> If you want to instrument it using the reader macros (#break and #dbg) 
>> you can do that too. Just issue `M-x read-only-mode` to disable 
>> readonly-ness and treat this buffer like a regular file.
>>
> Ah makes sense. Will do. 
>
>> > a way to continue to next break point (right now, continue just leaves 
>> the current break and completes execution, without stopping on other 
>> breakpoints)
>>
>> Could you clarify what you mean by this? 
>> You can step to the next breakpoint with n, but I'm guessing that's not 
>> what you want. 
>>
> I thought 'n' just steps to the next form to be evaluated (not the next 
> breakpoint). I probably didn't use it correctly. 
>
>
> Schweet. Thank-you man :) 
>
>  
>

-- 
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: Why "some-fn" is not called "some-pred" or "every-pred" is not called "every-fn" and vicer-versa.

[Leon Grapenthin]

Do you have an example where it would be more useful?

On Monday, December 21, 2015 at 2:20:41 AM UTC+1, Mike Rodriguez wrote:
>
> The distinction between names is important when one is a predicate and the 
> other is not. However I think it would be more useful if it were every-fn 
> since it is often more useful to have the final return value vs just true 
> false. This is consistent with the behavior or and and or. So some-fn seems 
> to get it right and every-pred deviates for some reason. 

-- 
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: Why "some-fn" is not called "some-pred" or "every-pred" is not called "every-fn" and vicer-versa.

[Leon Grapenthin]

every-pred is guaranteed to return a boolean value. some-fn returns the 
first logical true value of one of the fns passed. 

On Sunday, December 20, 2015 at 6:42:42 PM UTC+1, Jesus Bejarano wrote:
>
> Seems to me like it would be more consistent, right?
>

-- 
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 channel /w transducer which thread?

[Leon Grapenthin]

Pipeline must have a way of controlling on which thread the execution 
happens, otherwise it would parallize very little.

It does so by creating a new channel for each put with a buffer of 1 and an 
xf. It makes a blocking >!! and only after it unblocks it puts that new 
channel to the consumer that takes the value from there.

So at least in this limited case where there is space in the buffer and 
there is no pending take - Is it safe to assume that the xf is applied 
immediately?

On Thursday, December 17, 2015 at 4:28:27 PM UTC+1, Herwig Hochleitner 
wrote:
>
> 2015-12-16 16:22 GMT+01:00 Leon Grapenthin <grapent...@gmail.com 
> >:
>
>> The blocking put is made on a separate thread (channel named res), then 
>> later a blocking take from that same channel is made in the second go-loop.
>>
>
>> Or are you saying "if it takes too long, parallelize via pipeline"? In my 
>> case I can't because the transducer is stateful. I can run multiple 
>> pipelines with multiple transducer instances if I split up the inputs 
>> manually and later merge the outputs. But since the transducer does all of 
>> the relevant work, I need to determine where it runs. 
>>
>
>> The only alternative I see is to re-implement the transducer process 
>> within a thread/loop body and run multiple of those.
>>
>
> If you don't care about message ordering, you don't need pipline. I 
> suppose you could solve the "where does it run" problem by using a 
> ThreadLocal, but that feels pretty dirty. Running parallel loops taking 
> from the same source channel and putting into the same target channel, is 
> pretty easy to implement by hand. I have some code doing batch-indexing, 
> where I used this paradigm, if you're interested.
>
> I am not familiar with the JVM locking mechanism of core.async so what 
>> should I be worried about when the "transducer is executed inside the 
>> channel lock"? Are other channels going to have to wait if it is too slow?
>>
>
> The channel lock only affects put! and take! on a channel, as well as 
> transducers attached to that channel, so no need to worry about this for 
> your regular go-blocks.
>
>

-- 
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 channel /w transducer which thread?

[Leon Grapenthin]

Is it safe to say that a transducer in a channel always executes on the 
producer thread?

Kind regards, 
Leon.

-- 
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 channel /w transducer which thread?

[Leon Grapenthin]

Thanks for your reply. I just studied the pipeline code and am now 
wondering how it can affect on which thread the transducer runs if the 
answer to the question is unspecified.

The blocking put is made on a separate thread (channel named res), then 
later a blocking take from that same channel is made in the second go-loop.

Or are you saying "if it takes too long, parallelize via pipeline"? In my 
case I can't because the transducer is stateful. I can run multiple 
pipelines with multiple transducer instances if I split up the inputs 
manually and later merge the outputs. But since the transducer does all of 
the relevant work, I need to determine where it runs.

The only alternative I see is to re-implement the transducer process within 
a thread/loop body and run multiple of those.

I am not familiar with the JVM locking mechanism of core.async so what 
should I be worried about when the "transducer is executed inside the 
channel lock"? Are other channels going to have to wait if it is too slow?




On Wednesday, December 16, 2015 at 2:06:24 PM UTC+1, tbc++ wrote:
>
> When the transducer code was originally added to core.async I asked Rich 
> this very question. He declined to specify where the transducer is run. The 
> reasoning is simple: since the transducer is executed inside the channel 
> lock, your transducers should always be fast enough that you don't care 
> where they are run. If the transducer is going to take long enough that you 
> care about where it executes, you should use async/pipeline instead. 
>
> Timothy
>
> On Wed, Dec 16, 2015 at 4:16 AM, Leon Grapenthin <grapent...@gmail.com 
> > wrote:
>
>> Is it safe to say that a transducer in a channel always executes on the 
>> producer thread?
>>
>> Kind regards, 
>> Leon.
>>
>> -- 
>> 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 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-RC1 is now available

[Leon Grapenthin]

Does this mean putting it in the arglist always works and there is rarely a 
practical reason to do anything else?

On Thursday, November 12, 2015 at 8:36:20 PM UTC+1, Nicola Mometto wrote:
>
> It.. depends :(
>
> If your type hint is a *primitive* then you want to put it in the arglist. 
> If you put it in the Var, the best case scenario is that you'll get either 
> reflection warnings or boxed maths, and the worst case scenario is a 
> Compiler/bytecode error.
>
> If your type hint is an array type hint (^objects, ^ints ..) you want to 
> put it in the arglist or in the Var as a quoted symbol (^{:tag 'objects}).
>
> If your type hint is a non primitive class, you want to put it in the Var 
> or in the arglist as a fully qualified symbol (not necessary anymore since 
> 1.8)
>
> If your type hint is a string representing a class, you can safely put it 
> in either place.
>
> On 12 Nov 2015, at 19:28, Michael Blume  
> wrote:
>
> Sorry, I'm confused now -- is the appropriate place to give a return type 
> hint for a function the arg list and not the function name? I've always 
> seen the function name hinted.
>
> On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto  > wrote:
>
>> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
>>
>> On 12 Nov 2015, at 19:14, Nicola Mometto  
>> wrote:
>>
>>
>> Depends on how you look at it.
>> From my point of view, both examples are using an otherwise valid type 
>> hint, at an invalid location, and in both cases the emitted code is 
>> nonsensical.
>> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
>> with a compile time error, this one should too.
>>
>>
>> On 12 Nov 2015, at 16:47, Alex Miller  
>> wrote:
>>
>> Neither is acceptable, so I either misunderstand or disagree with your 
>> question. :) 
>>
>> The code below is an invalid type hint at that location. Are you maybe 
>> saying this should throw an error on definition?
>>
>> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
>> Which now throws an error.
>>
>>
>> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>>>
>>> This is :rettag in action.
>>> Any reason why this error should be acceptable while the CLJ-1846 one 
>>> isn't?
>>>
>>> On 12 Nov 2015, at 12:55, Alex Miller >> > wrote:
>>>
>>> That's not a valid type hint. Var meta is evaluated, in this case to the 
>>> double function object. You really want:
>>>
>>> (defn timespi ^double [^double x] (* x 3.14))
>>>
>>>
>>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebo...@gmail.com 
>>>  wrote:

 Hello,

 the following stops executing on 1.8.0-rc1 or current master-head 
 (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix 
 for CLJ-1846):

 [/Users/reborg]$ repl
 Clojure 1.8.0-master-SNAPSHOT
 user=> (defn ^double timespi [^double x] (* x 3.14))
 #'user/timespi
 user=> (timespi 2)
 AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; 
 is abstract  user/timespi (NO_SOURCE_FILE:-1)

 It works if you enable direct linking (or if you use 1.7.0).

 Renzo

>>>
>> -- 
>> 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 clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> 

Re: [ANN] Let's make clojure.org better!

[Leon Grapenthin]

I'd like to say that as a Clojure programmer I really like the current 
page.  

The reference documentation is an excellent resource. It does not answer 
all questions, but it answers the most critical ones very concisely and I 
hope that you intend to keep it like that.

If one thing about the page could be done better it is its appearance 
towards people who heard about Clojure the first time and want to learn 
more about it.

I think I learned about Clojure back ago when researching something Lisp 
related and in that context listened to a Rich Hickey talk. I thought: He 
created a programming language? It must either be insanely great or 
idealistic but unpractical. I went to the clojure.org website and thought: 
Oh, so he created the website for it as well (I think that is not true but 
that is what I thought), concluded that the language can't be very popular 
and probably does not have many users. It immediately ranked lower on the 
list of languages I wanted to try out. That was around 2012. The page 
failed to make me want to try out Clojure immediately mostly because it 
didn't make me trust in it on first sight. Listing high profile companies 
that are using Clojure might help.

If I remember correctly, it was a few weeks later when out of curiosity I 
opened the Youtube video "Clojure for Lisp programmers" that made me want 
to try out Clojure. There is also one "Clojure for Java programmers" and 
"Clojure Data structures" on ClojureTV. I think these should be put on the 
front page and be one click away. A 5 minute tutorial, probably with an 
in-browser REPL like tryclj.com should also be one click away. On a side 
note, "Clojure data structures" could be redone for the web as audience and 
enhanced with some visualization directed towards people who have no idea 
how immutable DS in a Lisp "feel". 

Kind regards,
 Leon.





On Thursday, November 12, 2015 at 11:58:41 AM UTC+1, Nando Breiter wrote:
>
> Expanding on the content idea for new-comers *to Clojure*, like me, (but 
> not necessarily to programming in general), I've found the approachs taken 
> by Living Clojure and PurelyFunctional.tv to be really helpful. Both Carin 
> Meier and Eric Normand (for example) take a relatively shallow angle of 
> attack and yet maintain an engaging pace, focusing on key areas of the 
> language. They lay out a *path* to learn, and invite the new-comer to 
> follow along. Not everyone might need tutoring like this, but judging from 
> the recommendations I've seen, others seem to appreciate it.
>
> The Getting Started page is currently a list of resources. That's 
> certainly needed. But it can take someone new to Clojure a considerable 
> amount of time to dive into all of it. And it's easy to get bogged down. 
> While there may be value in letting folks sort it out and slog through it 
> all for themselves, there's no learning path laid out on the website. Hence 
> I think a dedicated page or section named, for instance, "How to learn 
> Clojure" might be helpful. 
>
> What should go in this section? Content that would help someone having at 
> least some difficulty learning Clojure. Content that would help them sort 
> out how to approach learning the language. Content that would help them 
> prioritize which resources to use at which level.
>
>
>
>
>
>
>
> Aria Media Sagl
> Via Rompada 40
> 6987 Caslano
> Switzerland
>
> +41 (0)91 600 9601
> +41 (0)76 303 4477 cell
> skype: ariamedia
>
> On Wed, Nov 11, 2015 at 9:24 PM, Harrison Maseko  > wrote:
>
>> Content idea: Would be nice to have a section for new-comers to 
>> programming, introducing them to programming through Clojure. All of the 
>> existing Clojure books that I know of are aimed at those with intermediate 
>> to advanced programming skills in Clojure or another language. The content 
>> and learning gradient in those books can be steep and could put off a 
>> beginner. Although Clojure is such an advanced language, I think it's 
>> possible to implant programming concepts in a complete beginner by using a 
>> subset of Clojure. But maybe the the clojure.org Website is not the 
>> right place for that?
>> Thanks,
>> H
>>
>>
>> On Tuesday, November 10, 2015 at 5:57:45 PM UTC+2, Alex Miller wrote:
>>>
>>> Hi Hildeberto,
>>>
>>> I built spikes of the site in a number of technologies like Cryogen, 
>>> Stasis, Sphinx, Asciidoctor, and some of the other Ruby-based static 
>>> generators as well. In the end, I found that JBake was the best match for 
>>> our goals at this time. The site build architecture has been decided and 
>>> we're not interested in revisiting that at this time. At some point down 
>>> the road, based on experience and tool evolution, we may take another look, 
>>> but not soon. 
>>>
>>> Cryogen is a great tool and I would recommend it to others. One problem 
>>> I had with it was its flexibility with respect to the url structure. I 
>>> actually think for the purposes of creating a blog etc that is a 

scheduling with core.async?

[Leon Grapenthin]

Is it recommended to use core.asyncs timeout channel to wait on hour or 
even longer for light scheduling tasks?

High precision is a nongoal.

Kind regards,
 Leon.

-- 
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] com.stuartsierra/component 0.3.0 now with ClojureScript

[Leon Grapenthin]

Thanks for the release.

Given that you were originally sceptical towards CLJS support, is there a 
particular application or use case that made your change your mind?

Kind regards,
 Leon.

On Friday, September 18, 2015 at 10:51:19 PM UTC+2, Stuart Sierra wrote:
>
> 'Component' - lifecycle and dependency management for objects with runtime 
> state.
>
> https://github.com/stuartsierra/component
>
> Leiningen dependency: 
> [com.stuartsierra/component "0.3.0"]
>
>
> Changes in this release:
>
> * Added ClojureScript support via Conditional Read (.cljc)
>
> * Minimum Clojure version is now 1.7.0
>
> * Exceptions have been modified slightly for cross-platform compatibility.
>
> * No public API changes from 0.2.3
>
>
> License: MIT  http://opensource.org/licenses/MIT
>
>

-- 
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: Weird GenSyms behaviour across different quoted blocks in a macro

[Leon Grapenthin]

What Ambrose said and:

There is no need to use a hash for i in the for form. It is misleading 
because one thinks it will become a generated symbol as part of the 
generated form which is untrue.

On Wednesday, August 26, 2015 at 11:08:12 PM UTC+2, Rafik NACCACHE wrote:

 Suppose I have the following macro, which generates a function that does 
 some repetitive generation, let's say:

 (defmacro a-macro
   [m]
   `(fn [f#]
  ~(for [i# m]
 `(*  (:val f#) ~i# 

 Note how I start with a quoted block in which I emit the fn header, and in 
 which I use a gensym to capture its input, F#. I unquote to do my iterative 
 processing, then I quote again to emit my macro output.

 If I macroexpand this:
 (clojure.pprint/pprint  (macroexpand '(a-macro (1 2 3

 I get :

 (fn*
  ([f__11552__auto__]  
   ((clojure.core/* (:val f__11551__auto__) 1)
(clojure.core/* (:val f__11551__auto__) 2)
(clojure.core/* (:val f__11551__auto__) 3

 And I have a problem. The auto gensym for args declaration (...11522) is 
 different from the gensyms applying this arg in my generated function body 
 (...11551), so I cannot call my function.

 Any Idea why is that? And Can you please help me to sort this kind of 
 situation?

 Thank you;

 Rafik


-- 
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: Function syntax

[Leon Grapenthin]

It is a matter of personal style.

Note that there is a max function.

On Thursday, August 13, 2015 at 1:53:23 PM UTC+2, Herwig Hochleitner wrote:

 Yep, I meant the thing, `vector` is doing. Thanks!

 2015-08-13 13:36 GMT+02:00 Amith George strid...@gmail.com javascript:
 :

 Maybe you meant to use `vector` instead of `vec`? `vec` doesn't accept 
 variable args. Hence my original question. 

 On Thursday, 13 August 2015 16:24:43 UTC+5:30, Herwig Hochleitner wrote:

 2015-08-13 11:13 GMT+02:00 Amith George strid...@gmail.com:


 Could you please explain why is the `vec` needed? From what I 
 understand, we are expected to treat the variadic args argument as a seq, 
 nothing more. 


 What Tassilo said.
 Also, it's not nessecary to use `vec`, but you need a function that 
 creates a seqable from varargs, like vec, list, ... .
 That's what the  rest argument syntax does for you: create a collection 
 object from a variable number of arguments.
 ​

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




-- 
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: add-watch and writing data into a core.async channel

[Leon Grapenthin]

Use put!

On Friday, July 31, 2015 at 8:21:18 AM UTC+2, Raymond Huang wrote:

 I'd like to use `add-watch` on an atom which writes the data to a 
 core.async channel. So far, I've come up with this, but it seems bad 
 because I create a new go-routine everytime something happens.

 (add-watch ref watch-id #(go (a/! user-changes %)))

 This seems like a bad idea to me because I am creating a new go routine 
 everytime. Furthermore, I'd like this to be portable between Clojure  
 Clojurescript.

 I can't think of how I'd be able to solve 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: #{:eduction :performance} Trying to understand when to use eduction

[Leon Grapenthin]

Stuart and Alex, thank you for your replies and recommondations.

I take it then that the problem is the seq casting performed in apply and 
in reduce1. 

For now the only way to avoid applys seq casting seems to be a hackish 
.doInvoke call.

Kind regards,
 Leon.


On Sunday, July 19, 2015 at 6:34:37 PM UTC+2, Alex Miller wrote:



 On Sunday, July 19, 2015 at 10:53:25 AM UTC-5, Stuart Sierra wrote:

 Hi Leon,

 I think this is an edge case related to how varargs functions are 
 implemented in Clojure.

 The varargs arity of `max` is implemented with `reduce1`: core.clj line 
 1088 
 https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/clj/clojure/core.clj#L1088

 `reduce1` is a simplified implementation of reduce defined early in 
 clojure.core before the optimized reduction protocols have been loaded: 
 core.clj 
 line 894 
 https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/clj/clojure/core.clj#L894.
  
 `reduce1` is implemented in terms of lazy sequences, with support for 
 chunking.

 So `apply max` defaults to using chunked lazy sequence operations. `map` 
 and `range` both return chunked sequences.

 `eduction` returns an Iterable, so when you `apply max` on it, it turns 
 the Iterable into a Seq, but it's not a chunked seq. Therefore, it's 
 slightly slower than `apply max` on a chunked seq.


 seqs on eductions *are* chunked - they will fall into this case during 
 seq: 
 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L524-L525
  
 which produces a chunked sequence over an Iterable.
  

 In this case, to ensure you're using the fast-path internal reduce over `
 eduction`, you can use `reduce` directly:
 (reduce max 0 (eduction (map inc) (range 10)))
 You must provide an init value because `eduction` does not assume the 
 init with first element behavior of sequences.

 This version, in my informal benchmarking, is the fastest.

 Lots of functions in clojure.core use `reduce1` in their varargs 
 implementation. Perhaps they could be changed to use the optimized `
 reduce`, but this might add a lot of repeated definitions as 
 clojure.core is bootstrapping itself. I'm not sure.


 For various bootstrapping reasons, this is a hard change.
  

 In general, I would not assume that `eduction` is automatically faster 
 than lazy sequences. It will be faster only in the cases where it can use 
 the optimized reduction protocols such as InternalReduce. If the optimized 
 path isn't available, many operations will fall back to lazy sequences for 
 backwards-compatibility. 

 I would suggest using `eduction` only when you *know* you're going to 
 consume the result with `reduce` or `transduce`. As always, test first, and 
 profilers are your friend. :)


 Use eduction for delayed eager *non-cached* execution. Seqs give you 
 delayed *cached* execution. 
 If you're doing a transformation once, or if the thing you're doing would 
 consume too many resources if cached, then use eduction.
 If you need to do a transformation once and then use the result multiple 
 times, it's better to use sequence+transducer to get the caching effect and 
 the benefits of reduced allocation during transformation.

 Chunked seqs are surprisingly fast, particularly when all of the 
 operations in a nested transformation are chunked. However, every new layer 
 adds another set of (chunked) sequence allocation. Eduction or anything 
 transducer-based is going to do no seq allocation and execute as a single 
 eager pass. Generally this means that transducer stuff will win more if the 
 collection source is reducible, if the inputs are large (more input = 
 more win), or if the number of transformations is 1 (more transformations 
 = more wins).

  


 –S



 On Saturday, July 18, 2015 at 9:11:45 AM UTC-4, Leon Grapenthin wrote:

 My understanding was that if I pass an eduction to a process using 
 reduce, I can save the computer time and space because the per step 
 overhead of lazy sequences is gone and also the entire sequence does not 
 have to reside in memory at once.

 When I time the difference between (apply max (map inc (range 10))) 
 and (apply max (eduction (map inc) (range 10))), the lazy-seq variant 
 wins.

 I'd like to understand why, and when eductions should be used instead.



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

#{:eduction :performance} Trying to understand when to use eduction

[Leon Grapenthin]

My understanding was that if I pass an eduction to a process using reduce, 
I can save the computer time and space because the per step overhead of 
lazy sequences is gone and also the entire sequence does not have to reside 
in memory at once.

When I time the difference between (apply max (map inc (range 10))) and 
(apply max (eduction (map inc) (range 10))), the lazy-seq variant wins.

I'd like to understand why, and when eductions should be used instead.

-- 
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: Advice on introducing a Java dev to Clojure

[Leon Grapenthin]

I have tried various different approaches from convincing of Clojure 
advantages in the Java devs concrete domain, showing off incredibly awesome 
toy projects, larger projects, not tryng to sell, trying to sell, sending 
ClojureTV videos and what not approach you can think of. I have not managed 
to introduce one Java dev to Clojure in a way that he picked it up and had 
no interest before. I have spent many hours thinking about how I could 
improve my evangelizing skills. And today I believe that what you can do 
is very little and your approach does not affect the outcome a lot. There 
is enough motivating and introductional content about Clojure on the web. 
If someone isn't motivated by all this and your initial impulse, he is 
simply not able to upgrade. It might be a lack of time, a lack of interest 
in programming altogether aka silent burnout, the fear of having to learn 
new things, the fear of forgetting old things, the fear of not wanting to 
leave a comfort zone, the fear of not being able to autocompleteprogram or 
the fact that someone is simply happy with clicking classes together and 
writing a new group by implementation every few days and being paid for it 
very well and many other reasons. 

In many cases an existing comfort zone is an obstacle that you can't 
change. Almost nobody leaves his comfort zone only because you told him 
about something else outside of it, even if its gold and he believes you. 
OTOH people who leave their comfort zone on purpose every now and then do 
it because they are intrinsically motivated to do so. If they are out of 
ideas where to go, they will ask you for one and then selling Clojure is 
about as easy as mentioning between one and three interesting facts about 
it. They will be watching Rich Hickey talks in a minute.

Unless a programmer is adventureous and likes to try out new languages or 
has decided that he wants to learn something new, there is little you can 
do. In the other case there is little that you have to do.

Personally I have simply decided not to waste time on trying to convince 
programmers to learn Clojure, instead I try to help those who are. 

OTOH spending time on improving evangelizing and elevator pitching is still 
well spent if you want to convince managers. I find Rich Hickeys rationale 
on the Clojure page is a great starting point and there is also a great 
talk by Paul deGrandis (Clojure minimizes risk).

On Friday, July 10, 2015 at 12:20:23 AM UTC+2, Johanna Belanger wrote:

 Hi :)

 I've recently broached the subject of Clojure with another dev in my 
 organization, and his response was basically What's Clojure? and I'm not 
 sure how to answer that in a way that might inspire him. It's a 
 dynamically-typed functional Lisp with persistent immutable data structures 
 that runs on the JVM doesn't seem like it will grab his interest. =)

 I work primarily in .NET, and he does enterprise Java. I don't know him 
 well enough to know how happy he is with it. He did express interest in 
 learning .Net.

  I came to an appreciation of Clojure through 

 -CQRS (the power of decomplection!)
 -Sussman and Abelson's SICP class at MIT online (the power of 
 homoiconicity and functions!)
 -the death of Silverlight (alternatives to Javascript in the browser?)

 By the time I found Rich Hickey's talks (eg Simple Made Easy) I was pretty 
 well primed to love Clojure. I've been using it for little personal 
 projects and prototyping for a couple of years, but I haven't put it in 
 production because no one else here knows it.

 Could anyone tell me how they got from enterprise Java to Clojure?

 Thanks very much,
 Johanna



-- 
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: Advice on introducing a Java dev to Clojure

[Leon Grapenthin]

I have tried various different approaches from convincing of Clojure 
advantages in the Java devs concrete domain, showing off incredibly awesome 
toy projects, larger projects, not tryng to sell, trying to sell, sending 
ClojureTV videos and what not approach you can think of. I have not managed 
to introduce one Java dev to Clojure in a way that he picked it up and had 
no interest before. I have spent many hours thinking about how I could 
improve my evangelizing skills. And today I believe that what you can do 
is very little and your approach does not affect the outcome a lot. There 
is enough motivating and introductional content about Clojure on the web. 
If someone isn't motivated by all this and your initial impulse, he is 
simply not able to upgrade. It might be a lack of time, a lack of interest 
in programming altogether aka silent burnout, the fear of having to learn 
new things, the fear of forgetting old things, the fear of not wanting to 
leave a comfort zone, the fear of not being able to autocompleteprogram or 
the fact that someone is simply happy with clicking classes together and 
writing a new group by implementation every few days and being paid for it 
very well and many other reasons. 

In many cases an existing comfort zone is an obstacle that you can't 
change. Almost nobody leaves his comfort zone only because you told him 
about something else outside of it, even if its gold and he believes you. 
OTOH people who leave their comfort zone on purpose every now and then do 
it because they are intrinsically motivated to do so. If they are out of 
ideas where to go, they will ask you for one and then selling Clojure is 
about as easy as mentioning between one and three interesting facts about 
it. They will be watching Rich Hickey talks in a minute.

Unless a programmer is adventureous and likes to try out new languages or 
has decided that he wants to learn something new, there is little you can 
do. In the other case there is little that you have to do.

Personally I have simply decided not to waste time on trying to convince 
programmers to learn Clojure, instead I try to help those who are. 

OTOH spending time on improving evangelizing and elevator pitching is still 
well spent if you want to convince managers. I find Rich Hickeys rationale 
on the Clojure page is a great starting point and there is also a great 
talk by Paul deGrandis (Clojure minimizes risk).

On Friday, July 10, 2015 at 12:20:23 AM UTC+2, Johanna Belanger wrote:

 Hi :)

 I've recently broached the subject of Clojure with another dev in my 
 organization, and his response was basically What's Clojure? and I'm not 
 sure how to answer that in a way that might inspire him. It's a 
 dynamically-typed functional Lisp with persistent immutable data structures 
 that runs on the JVM doesn't seem like it will grab his interest. =)

 I work primarily in .NET, and he does enterprise Java. I don't know him 
 well enough to know how happy he is with it. He did express interest in 
 learning .Net.

  I came to an appreciation of Clojure through 

 -CQRS (the power of decomplection!)
 -Sussman and Abelson's SICP class at MIT online (the power of 
 homoiconicity and functions!)
 -the death of Silverlight (alternatives to Javascript in the browser?)

 By the time I found Rich Hickey's talks (eg Simple Made Easy) I was pretty 
 well primed to love Clojure. I've been using it for little personal 
 projects and prototyping for a couple of years, but I haven't put it in 
 production because no one else here knows it.

 Could anyone tell me how they got from enterprise Java to Clojure?

 Thanks very much,
 Johanna



-- 
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: Different macro definitions via reader conditionals?

[Leon Grapenthin]

@Mike: Great post. I think you should make it more explicit that the :cljs 
branch of the macro is never used on Clojure and CLJS/JVM.

Kind regards, Leon.


On Thursday, July 2, 2015 at 3:20:17 PM UTC+2, Mike Fikes wrote:

 I’m interested in whether there is a nice answer to this as well. 

 FWIW, I was recently pondering a closely related subject—portability that 
 additionally extends to bootstrapped ClojureScript:

   http://blog.fikesfarm.com/posts/2015-06-19-portable-macro-musing.html

 (Hoping things don’t become excessively combinatorial.)

 - Mike

 On Jul 2, 2015, at 8:09 AM, Michael Sperber spe...@deinprogramm.de 
 javascript: wrote:

 I'd like to define a macro differently for Clojure and for ClojureScript.

 Is there a way to do this via reader conditionals?  (My mind boggles.)

 Regards,
 Mike

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




-- 
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: Different macro definitions via reader conditionals?

[Leon Grapenthin]

It seems like the only way is to define two macros and call the desired one 
using reader conditionals.

On Thursday, July 2, 2015 at 2:09:55 PM UTC+2, Michael Sperber wrote:

 I'd like to define a macro differently for Clojure and for ClojureScript.

 Is there a way to do this via reader conditionals?  (My mind boggles.)

 Regards,
 Mike


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