Re: [ANN] thurber: Clojure on Apache Beam (distributed batch/streaming)

[Beau Fabry]

Hi Aaron,

I was I guess the lead developer on clj-headlights. If you have any 
questions feel free to hit me up. It is afaik not actively maintained by 
anyone anymore.

Cheers,
Beau

On Wednesday, January 22, 2020 at 8:21:57 AM UTC-8, Aaron D. wrote:
>
>
> Hi Dominic thank you!
>
> Are you maintainer/contrib to datasplash, I would be happy to swap notes, 
> synthesize ideas.
>
> My org looked at datasplash. The biggest dealbreaker for us was 
> datasplash's AOT-orientation; its AOT packaging meant we couldn't float its 
> dependencies, and didn't like the requirement to AOT compile our own code.
>
> With thurber I started w/ this goal to avoid AOT, be highly dynamic in the 
> repl, but was also able to focus on certain performance areas from the 
> bottom-up. thurber also eschews sugared/dsl-ish api for more 
> direct/explicit interop w the Beam SDK leaving this implementation concern 
> to layers above (though I may implement if interest)-- just a different 
> 'opinionated' take here.
>
> My org had been using Onyx for streaming use cases but its original 
> developers have moved on and we were concerned with its long-term 
> viability. Many of the ideals of thurber are consistent with Onyx's and 
> reaching previous Onyx users like ourselves was another line of sight for 
> thurber.
>
> We'd also looked at clj-headlights 
>  - this was the other 
> clojure Beam lib we'd surveyed in this space. 
>
> On Wednesday, January 22, 2020 at 7:30:17 AM UTC-6, Dominic Parry wrote:
>>
>> Hi!
>>
>> Congratulations on the library! It makes me super happy when people build 
>> clojure libraries for the Google cloud ecosystem. I wanted to draw your 
>> attention to datasplash (https://github.com/ngrunwald/datasplash) which 
>> has made a start on this. I thought perhaps you could leverage some of it.
>>
>> Hope you have a great day!
>> On 21 Jan 2020, 23:10 +0200, atdixon , wrote:
>>
>> Here is thurber (https://github.com/atdixon/thurber) (at early alpha 
>> release) that enables Clojure on Apache Beam platforms like Google Dataflow.
>>
>> thurber's goals include:
>>
>> - Full support for Beam capabilities
>> - AOT-less (AOT not required; full dynamic support for serializing 
>> functions, including inlined functions, and proxies)
>> - Macro-less (very few, always optional, macros)
>> - Performance focus (core optimized for large volume data streaming)
>> - Idiomatic Clojure focus (Clojure functions are automatically 
>> distributable functional transforms, lazy sequences over iterative output, 
>> ..)
>>
>> When coming to Apache Beam and wanting to use Clojure there are a few 
>> hurdles to overcome, some discussed here in the past.  Clojure's Java 
>> interop commonly falls short in the domain of distributed big data Java 
>> platforms (proxies and functions not serializable, no support for 
>> generation of generic type signatures, minimal/insufficient support for 
>> method annotations, suboptimal dynamic binding performance, etc)
>>
>> thurber bridges these issues internally, giving a full dynamic/Clojure 
>> experience on top of Apache Beam.
>>
>> (For Onyx users, thurber + Beam meet the same ideals 
>>  
>> as 
>> Onyx on a well-backed platform.)
>>
>> This is early alpha release and feedback on the API & facilities are 
>> welcome.
>>
>> For the curious, the walkthrough covers most of thurber capability: 
>> https://github.com/atdixon/thurber/blob/master/demo/walkthrough.clj
>>
>> --
>> 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
>> clo...@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 clo...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/clojure/c18cc8e1-01c9-4688-bff3-6d50f128d0e4%40googlegroups.com
>>  
>> 
>> .
>>
>>

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

Re: Translation of the QuickCheck properties in the paper "How to specify it!" by John Hughes into clojure test.check

[Beau Fabry]

Added a reporting property and tweaked the key generator to be closer to 
the numbers in the paper

On Thursday, July 18, 2019 at 8:25:25 AM UTC-7, Beau Fabry wrote:
>
> https://github.com/bfabry/specify-it
>
> Attempted translation of the QuickCheck properties in this paper:
>
> "How to specify it!" - John Hughes
>
> https://www.dropbox.com/s/tx2b84kae4bw1p4/paper.pdf?dl=0
>
> Into Clojure test.check properties. I recreated the first 5 bugs in the 
> paper
> (and the test.check properties do fail on them) but got bored after that 
> as they
> assumed an implementation of `union` that isn't as silly as mine.
> Run the properties by redefining the vars at the top of `bst-spec` to 
> point to the implementation of your choice and running `check-props`. 
> There's also a BST that passes all the tests
> in `bst`. It's stupidly slow.
>
> Would love some help in how to make the `bst-spec` namespace 
>
> 1. have less boilerplate
> 2. be more idiomatic.
> 3. I couldn't figure out how to make properties that test shrinking as in 
> the paper
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/b396098d-d920-4130-8440-86aeb3b1ac5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Translation of the QuickCheck properties in the paper "How to specify it!" by John Hughes into clojure test.check

[Beau Fabry]

https://github.com/bfabry/specify-it

Attempted translation of the QuickCheck properties in this paper:

"How to specify it!" - John Hughes

https://www.dropbox.com/s/tx2b84kae4bw1p4/paper.pdf?dl=0

Into Clojure test.check properties. I recreated the first 5 bugs in the 
paper
(and the test.check properties do fail on them) but got bored after that as 
they
assumed an implementation of `union` that isn't as silly as mine.
Run the properties by redefining the vars at the top of `bst-spec` to 
point to the implementation of your choice and running `check-props`. 
There's also a BST that passes all the tests
in `bst`. It's stupidly slow.

Would love some help in how to make the `bst-spec` namespace 

1. have less boilerplate
2. be more idiomatic.
3. I couldn't figure out how to make properties that test shrinking as in 
the paper

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/5fd30de8-508c-43b7-8da3-4e7686828241%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.8 vs 1.9 performance

[Beau Fabry]

We updated 2 apps to 1.9 about a month ago, I believe another team is 
planning to update next week. No issues.

On Monday, December 25, 2017 at 2:45:01 AM UTC-8, John Stevenson wrote:
>
> Our team has been running in production on Clojure 1.9 release candidates 
> for the last 4 months.  We process about 30 million transactions every day 
> without breaking a sweat, thanks in part to core.async, so performance is 
> excellent for us.  As we started with 1.9 I'm unable to give advice about 
> comparable performance or upgrade issues, however, I don't recall any 
> issues with libraries and Clojure 1.9
>
> We will be upgrading to the final 1.9 release in the new year, which 
> simply means running our performance tests in a non-production environment 
> for a week or so.
> ​
> Thanks
> John
>
>

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

[Beau Fabry]

One way to prevent that would be to only ever use aliases for fully 
qualified keywords, never type out the whole thing. 

On Thursday, November 9, 2017 at 11:22:24 PM UTC-8, Didier wrote:
>
> I just stumbled upon another potential mistake here. When you have specs 
> split across namespaces. Its possible for a map spec in one namespace to 
> have one of its key's use a spec from another namespace. If you forget to 
> require that other namespace though, you won't know, and your map will 
> always validate.
>
> (s/def ::spec (s/keys :req [:other/spec]))
>
> If :other/spec is not registered, ::spec still will succeed at being 
> registered. And then, assuming :other/spec is defined as:
>
> (s/def :other/spec int?)
>
> I wouldn't matter, since:
>
> (s/valid? ::spec {:other/spec "123"})
>
> Will return true.
>
> But if you register :other/spec, it would return false.
>
> Normally, this has not been an issue for me, but now that I share my specs 
> more, I've got specs in different namespace using one another, and I've 
> already made this mistakes a few time, causing validation I thought was 
> there to protect me, to actually be missing.
>
> So I made my own keys macro:
>
> (defmacro known-keys
>   [& {:keys [req req-un opt opt-un gen] :as args}]
>   (letfn [(known-spec? [k] (boolean (s/get-spec k)))]
> (doseq [e (concat req req-un opt opt-un)]
>   (when (not (known-spec? e))
> (throw (ex-info (str e " is not a currently registered spec.") 
> args)
>   `(s/keys ~@(interleave (keys args) (vals args
>
> Which first checks that all keys are currently registered, and if so, it 
> delegates back to s/keys. Otherwise it throws an exception at macro 
> expansion time.
>
> I think this would also solve OPs problem, since it would throw if typos 
> are made also.
>
> On Saturday, 14 October 2017 04:45:47 UTC-7, stuart@gmail.com wrote:
>>
>> Hi Leon,
>>
>> I think it would be a mistake to introduce temporal coupling to prevent 
>> typos. Here is an alternative that lets you identify "missing" keys specs at
>> the time and place of your choosing, and then handle them as you deem 
>> appropriate, without imposing those decisions on other users of spec:
>>
>> https://gist.github.com/stuarthalloway/f4c4297d344651c99827769e1c3d34e9
>>
>> Regards,
>> Stu
>>
>>
>>
>>
>> On Tue, Oct 10, 2017 at 12:33 PM, Leon Grapenthin <grapent...@gmail.com> 
>> wrote:
>>
>>> 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 
>>

Re: [ANN] Clojure 1.9.0-RC1

[Beau Fabry]

We've switched both of our main projects to RC1 and have had no issues yet.

On Thursday, November 9, 2017 at 11:49:07 PM UTC-8, Sean Corfield wrote:
>
> We have three processes running RC1 in production as of today. Looks good 
> so far. We’ve had everything else up and running on Beta 4 in production 
> since Monday, also looking good.
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Alex Miller  >
> *Sent:* Tuesday, November 7, 2017 6:58:24 AM
> *To:* Clojure
> *Subject:* [ANN] Clojure 1.9.0-RC1 
>  
> Clojure 1.9.0-RC1 is now available.
>
> Try it via
>
> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-RC1
> - Leiningen: [org.clojure/clojure "1.9.0-RC1"]
>
> 1.9.0-RC1 is the same as 1.9.0-beta4.
>
> We would appreciate anything you can do to try out this release. We do not 
> plan to make any further changes prior to 1.9.0 release unless regressions 
> are found.
>
> -- 
> 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: Don't Laugh - How to Get the Name of an Anonymous Function

[Beau Fabry]

If I had to guess I'd say the name of the function isn't stored with it

nil
boot.user=> (clojure.reflect/reflect (fn foo [] nil))
{:bases #{clojure.lang.AFunction}, :flags #{:public :final}, :members 
#{#clojure.reflect.Constructor{:name boot.user$eval1530$foo__1531, 
:declaring-class boot.user$eval1530$foo__1531, :parameter-types [], 
:exception-types [], :flags #{:public}} #clojure.reflect.Method{:name 
invoke, :return-type java.lang.Object, :declaring-class 
boot.user$eval1530$foo__1531, :parameter-types [], :exception-types [], 
:flags #{:public


On Monday, October 23, 2017 at 10:57:42 PM UTC-7, Shantanu Kumar wrote:
>
> Not sure whether you can deterministically recover the exact name at all 
> times, but the following can get you started:
>
> (re-matches #".*\$(.*)__.*" (.getName (class (fn cool-func! [] (println 
> "hi")
>
> I have altered the name to `cool-func!` on purpose to show where it may 
> break.
>
>
> Shantanu
>
> On Tuesday, 24 October 2017 10:35:12 UTC+5:30, Nick Mudge wrote:
>>
>> Let's say I have this anonymous function:
>>
>> (fn cool [] (println "hi"))
>>
>> How can I extract the name from it?
>>
>> Obviously the name of the function is stored with the function. How can I 
>> get to it?
>>
>>
>>

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

Re: [core.spec] Stricter map validations?

[Beau Fabry]

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

boot.user=> (s/def ::val string?)
:boot.user/val
boot.user=> (s/def ::tree (s/keys :opt-un [::val ::branches]))
:boot.user/tree
boot.user=> (s/def ::branches (s/tuple ::tree ::tree))
:boot.user/branches

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

Re: [core.spec] Stricter map validations?

[Beau Fabry]

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

[Beau Fabry]

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?

[Beau Fabry]

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

[Beau Fabry]

We've been using 1.9 in a small app for a while with no issues. After 
upgrading schema to the latest version (with the PR above) I've also 
successfully run our larger codebase with 1.9.

On Tuesday, October 3, 2017 at 4:41:14 AM UTC-7, stuart@gmail.com wrote:
>
> Hi Mark,
>
> I think this approach totally makes sense, and the alpha naming exists to 
> inform this kind of decision-making.
>
> For libraries where the use of spec does not have to be user-facing, I am 
> putting specs in separate (Clojure) namespaces, and loading them in such a 
> way that they can coexist with non (or maybe different) spec environments. 
> But that is extra work for sure.
>
> Stu
>
> On Mon, Oct 2, 2017 at 3:35 PM, Mark Engelberg  > wrote:
>
>> On Mon, Oct 2, 2017 at 7:55 AM, Stuart Halloway > > wrote:
>>
>>> Hi David,
>>>
>>> Spec will be in alpha for a while. That is part of the point of it being 
>>> a separate library. Can you say more about what problems this is causing?
>>>
>>> Stu
>>>
>>>
>> As a library maintainer, I am forced to upgrade and release my library 
>> any time something I depend upon makes a breaking change.  I don't get paid 
>> for maintaining open source libraries, it's something I do in my spare 
>> time, so I prefer to do it on my own schedule.  When an underlying library 
>> makes a breaking change, I get dozens of urgent requests from people who 
>> need me to cut a new release ASAP, and by Murphy's Law, that often happens 
>> when I have very little time to do it.  It's a nuisance.
>>
>> Clojure is pretty good about not making breaking changes, but it happens 
>> from time to time.  Clojurescript is less good about not making breaking 
>> changes, and therefore, maintaining Clojurescript libraries is more of a 
>> headache.  On the plus side, Clojurescript users seem to care very little 
>> about backwards compatibility (most keep up with the latest version), so 
>> sometimes it is easier to make a change to keep up with a change in 
>> Clojurescript than one in Clojure, where I am expected to not only support 
>> the latest breaking change, but also the last several releases.
>>
>> Anything that is labeled as "alpha" is waving a big red flag that there 
>> could be breaking changes at any time with little warning.  For my 
>> libraries which depend on spec, there's no way I'm going to bring them out 
>> of alpha status until spec comes out of alpha status.  If I make an 
>> official release of something that depends on spec, then I'm going to be on 
>> the hook to rapidly cut a new release every time spec changes, which could 
>> be at any time.  I don't want that hassle.  I don't want to make a promise 
>> to the community to maintain a stable product if the thing I depend upon 
>> has not made a similar promise.  When spec reaches a point where the API 
>> will not be changing, or rather, when we know that new changes will only be 
>> additive, I can begin to trust that it won't be a huge maintenance headache 
>> to release something based on spec.
>>
>> -- 
>> 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: [core.spec] Stricter map validations?

[Beau Fabry]

fwiw, I vote for leaving it. It's extra flexibility and is afaict a fairly 
easy error to catch. Here's a function that I think should give you every 
qualified keyword that is used in a spec but that does not have a spec 
defined for it:
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 Monday, October 2, 2017 at 10:30:57 AM UTC-7, 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.
>
> 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: [core.spec] Stricter map validations?

[Beau Fabry]

> 1) Is there any way to ensure that the keys I used in `s/keys` have the 
associated specs defined?

I think you should be able to do this by writing a function that uses 
s/registry s/form and s/get-spec


On Monday, October 2, 2017 at 8:37:31 AM UTC-7, 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: Is there a way to use spec/fdef function specs with clojure.test ?

[Beau Fabry]

Can't you just assert on the return value of spec.test.check in a 
clojure.test test? ie, this is a test in one of our repos:
(deftest ^:spec generative
(is (not-any? :failure (st/check [`export/invert-table->account-ids]
On Friday, September 29, 2017 at 3:36:26 AM UTC-7, Khalid Jebbari wrote:
>
> I've managed to get something working. Very dirty and hardcoded most 
> things though, so not reusable at all. The key here is to parse the return 
> of spec/describe and retrieve the value for the :arg, convert it to real 
> spec with eval and retrieve its generator.
>
> (defspec a-test
>  (let [args (nth (s/describe 'foo.core/bar) 2)
>spec-code (map #(if (symbol? %) (symbol 
> "clojure.spec.alpha" (str %)) %) args)
>spec (eval spec-code)
>args-gen (s/gen spec)]
>(prop/for-all [argz args-gen]
>  (s/valid? ::ret-spec (apply foo.core/bar argz)
>
>
> In the end one shoot write a proper spec/describe parser ?
>
> Or has someone a better idea ?
>
>
> On Friday, September 29, 2017 at 12:08:57 PM UTC+2, Khalid Jebbari wrote:
>>
>> Hello,
>>
>> I'm struggling to find a way to to use the fdef specs I wrote in 
>> clojure.test tests. I can run them fine in the repl with spec/exercise-fn 
>> or spec.test/check, really nice when developping by the way. Now that I'm 
>> happy with the result I'd like to encode this knowledge in tests to prevent 
>> regressions. I don't need more tests that this, not specific property etc.
>>
>> I found no way to plug the spec.test/check in clojure.test or easily 
>> reuse fdef specs. test.check/defspec and quickcheck expect properties as 
>> their argument. spec/describe return a LazySeq that I found hard to exploit 
>> without a lot of manual wiring, parsing and trial-and-errors.
>>
>> If I had to write it by hand, it would look like :
>>
>> (defspec myspec 100 (prop/for-all [one (spec/gen ::first-arg) 
>>two (spec/gen 
>> ::second-arg)]
>> (is (true? (spec/valid? 
>> ::ret-spec (myfunc one two
>>
>> The problem is that it's incomplete with regards to spec possibilities : 
>> spec/or, spec/nilable etc. and I use them. Also I the function changes (in 
>> any way) the test becomes irrelevant instantly.
>>
>> A colleague resorted to manually calling spec.test/check in clojure.test 
>> and manually verifying the output of the function (the :result boolean, the 
>> :num-tests etc.). Feels way too manual, and doesn't report the shrunk value 
>> as nicely as test.check does.
>>
>>
>> Maybe I missed something completely. spec/describe seems the best bet to 
>> introspect the spec and use it in for-all calls. But still too manual.
>>
>> Any help much appreciated.
>>
>

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

[Beau Fabry]

Identified an issue with 
prismatic/schema https://github.com/plumatic/schema/pull/399

On Thursday, September 28, 2017 at 9:18:52 AM UTC-7, Nathan Fisher wrote:
>
> Hi Stuart,
>
> Looks like any project using lein-cljsbuild will be affected.
>
> I forked and bumped the Clojure and ClojureScript version to latest and 
> got the same error with their simple project:
>
> See Commit:
>
> https://github.com/nfisher/lein-cljsbuild/commit/5df5d3c5bb447b51a75abbbccdc72447814883a0
>
> STR
>
> 1. git clone https://github.com/nfisher/lein-cljsbuild
> 2. cd lein-cljsbuild/example/projects/simple
> 3. lein cljsbuild once
>
> Patch attached if you want to apply directly to 
> https://github.com/emezeske/lein-cljsbuild
>
> Cheers,
> Nathan
>
> On Thu, 28 Sep 2017 at 16:13 Stuart Halloway  > wrote:
>
>> Hi Nathan,
>>
>> I suspect that is the same as 
>> https://github.com/clojure/clojurescript/commit/89914d2ead964122f99e638edda0cd96d330cb66.
>>   
>> I don't have a sense of how many CLJS project this is going to cascade 
>> into, or what all will be needed. Anyone?
>>
>> Stu
>>
>> On Thu, Sep 28, 2017 at 10:44 AM, Nathan Fisher > > wrote:
>>
>>> Hi Stuart,
>>>
>>> Working to create a minimal test case but upgrading from alpha19 to 
>>> beta1 seems to have broken lein-cljsbuild.
>>>
>>> I get the following error:
>>>
>>> >> snip >>
>>>
>>> *SEVERE: 
>>> /Users/nathanfisher/workspace/mklpq/target/cljsbuild-compiler-0/cljs/core.js:3579:
>>>  
>>> ERROR - Parse error. primary expression expected*
>>>
>>> *case ##Inf:*
>>>
>>> *  ^*
>>>
>>>
>>> *Sep 28, 2017 3:23:10 PM com.google.javascript.jscomp.LoggerErrorManager 
>>> printSummary*
>>>
>>> *WARNING: 1 error(s), 0 warning(s)*
>>>
>>> *ERROR: JSC_PARSE_ERROR. Parse error. primary expression expected at 
>>> /Users/nathanfisher/workspace/mklpq/target/cljsbuild-compiler-0/cljs/core.js
>>>  
>>> line 3579 : 6*
>>> << snip <<
>>>
>>> Changes in my project.clj deps are as follows: 
>>>
>>> *- [org.clojure/clojure "1.9.0-alpha19" :scope "provided"]*
>>>
>>> *+ [org.clojure/clojure "1.9.0-beta1" :scope "provided"]*
>>>
>>> A revert on my project.clj to alpha19 eliminates the error.
>>>
>>> Cheers!
>>>
>>> Nathan
>>>
>>> On Thu, 28 Sep 2017 at 15:00 Stuart Halloway >> > 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 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.

>>> -- 
>>> - sent from my mobile
>>>
>>> -- 
>>> 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 

Re: Obtaining the predicate of a spec

[Beau Fabry]

Not sure if I'm being glib here but #(s/valid? ::pm-hours %) returns a 
predicate that has the exact same results as #(s/int-in-range? 12 24 %)

On Friday, September 22, 2017 at 1:10:51 PM UTC-7, Didier wrote:
>
> I'd try to call describe on the spec. As far as I know that's the only 
> introspection feature of spec. See if it returns what you need.

-- 
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: Contribute Specter to Clojure core?

[Beau Fabry]

> The main thing that makes me hesitate to suggest this is getting 
bottlenecked on Clojure's dev process.

Imo this is a big deal. I like the way specter has the ability to add new 
generally useful navigators and paths with new versions as people 
"discover" them, I don't think that's a great fit for the overhead of a 
language release process.

On Wednesday, February 15, 2017 at 8:02:55 AM UTC+11, Nathan Marz wrote:
>
> One of the most common questions I get about Specter is whether it will 
> ever become part of Clojure core. I think it's an interesting proposal and 
> would like to see what the community and core team thinks.
>
> The primary reason for contributing would be that Specter makes Clojure a 
> stronger language. For a language that embraces simplicity, I've always 
> viewed the complexity of dealing with nested data structures a glaring 
> weakness of Clojure. The existing stuff in Clojure, like clojure.walk, 
> zippers, update-in, etc., just doesn't cut it. This problem is very common, 
> and Specter completely solves it with near-optimal performance.
>
> The main thing that makes me hesitate to suggest this is getting 
> bottlenecked on Clojure's dev process. However, Specter is very well 
> developed at this point so it doesn't need to move fast anymore.
>
> Please share your 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: Simple clojure example improvements sought

[Beau Fabry]

Haha, the one line was more an artifact of me entering it that way than a 
recommendation, if I was committing to master it would probably look like

(map-indexed
  (fn [person-num _person_name]
(->> optij
(map (fn [[attribute-name attribute-vals]] {attribute-name (nth 
attribute-vals person-num)}))
(into {})))
  (:name optij))

On Tuesday, January 10, 2017 at 6:13:28 PM UTC-8, hiskennyness wrote:
>
>
>
> On Tuesday, January 10, 2017 at 2:37:22 PM UTC-5, Beau Fabry wrote:
>>
>> With specter:
>>
>> (map-indexed (fn [i name] (sp/transform sp/MAP-VALS #(nth % i) optij)) 
>> (:name optij))
>> => ({:name :tom, :age 1, :tone :do} {:name :dick, :age 2, :tone :re} 
>> {:name :harry, :age 3, :tone :mi})
>>
>
> One line! With specter, but still nice.
>
> But to me this is the downside of specter and even Clojure: the code 
> starts to get opaque. I am reminded of the C Puzzle Book which offered 
> simple data and a few lines of code and defied us to guess what the code 
> produced.
>
> My big take-away here is map-indexed. Forgot about that and it would have 
> greatly simplified my original efforts.
>  
>
>>
>> Without:
>>
>> (map-indexed (fn [i name] (into {} (map (fn [[k v]] [k (nth v i)]) 
>> optij))) (:name optij))
>> => ({:name :tom, :age 1, :tone :do} {:name :dick, :age 2, :tone :re} 
>> {:name :harry, :age 3, :tone :mi})
>>
>>
> Gonna have to study that one. :) Still one line, tho! Cool.
>
> -kt
>
>>
>>>

-- 
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: Simple clojure example improvements sought

[Beau Fabry]

sorry that last nth should've been (nth % i nil)

On Tuesday, January 10, 2017 at 11:37:22 AM UTC-8, Beau Fabry wrote:
>
> With specter:
>
> (map-indexed (fn [i name] (sp/transform sp/MAP-VALS #(nth % i) optij)) 
> (:name optij))
> => ({:name :tom, :age 1, :tone :do} {:name :dick, :age 2, :tone :re} 
> {:name :harry, :age 3, :tone :mi})
>
> Without:
>
> (map-indexed (fn [i name] (into {} (map (fn [[k v]] [k (nth v i)]) 
> optij))) (:name optij))
> => ({:name :tom, :age 1, :tone :do} {:name :dick, :age 2, :tone :re} 
> {:name :harry, :age 3, :tone :mi})
>
> If I didn't know which key was the canonical full list, ie some could be 
> shorter and in that case I wanted nil:
>
> (map (fn [i] (sp/transform sp/MAP-VALS #(nth % i) optij)) (range 0 (inc 
> (apply max (map (comp count vals) optij)
> => ({:name :tom, :age 1, :tone :do} {:name :dick, :age 2, :tone :re} 
> {:name :harry, :age 3, :tone :mi})
>
>
> On Tuesday, January 10, 2017 at 7:27:24 AM UTC-8, hiskennyness wrote:
>>
>> Whenever I code something like this I get the feeling a clojure guru 
>> could do it more simply, and I love learning new tricks.
>>
>> Here is my simple (real-world, btw) problem and solution. Is there a 
>> better way?
>>
>> ;; Problem: given optimized* json maps (* to avoid duplicating keys):
>> (def optij {:name [:tom :dick :harry]
>>:age [1 2 3]
>>:tone [:do :re :mi]})
>>
>> ;; ... produce normal repetitious maps
>> (comment
>>   [{:name :tom, :age 1, :tone :do}
>>{:name :dick, :age 2, :tone :re}
>>{:name :harry, :age 3, :tone :mi}])
>>
>> ;; goal #1: pivot so I can use zipmap
>> (comment
>>   ((:tom 1 :do) (:dick 2 :re) (:harry 3 :mi)))
>>
>> ;; my goal #1 approach (improvements welcome):
>> (apply (partial map (fn [& vs] vs))
>>(vals optij))
>>
>> (apply (partial map vector)
>>(vals optij))
>>
>> ;; my overall approach (improvements welcome):
>> (let [ks (keys optij)
>>   vs-pivoted (apply (partial map vector)
>> (vals optij))]
>>   (vec (for [attributes vs-pivoted]
>>  (zipmap ks attributes
>>
>>
>> Final fun question: is the original idea of compressing JSON this way 
>> commonplace? I thought everyone was just saying to hell with the 
>> duplication and taking the convenience of self-defining objects, but 
>> apparently one source is not.
>>
>

-- 
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: Simple clojure example improvements sought

[Beau Fabry]

With specter:

(map-indexed (fn [i name] (sp/transform sp/MAP-VALS #(nth % i) optij)) 
(:name optij))
=> ({:name :tom, :age 1, :tone :do} {:name :dick, :age 2, :tone :re} {:name 
:harry, :age 3, :tone :mi})

Without:

(map-indexed (fn [i name] (into {} (map (fn [[k v]] [k (nth v i)]) optij))) 
(:name optij))
=> ({:name :tom, :age 1, :tone :do} {:name :dick, :age 2, :tone :re} {:name 
:harry, :age 3, :tone :mi})

If I didn't know which key was the canonical full list, ie some could be 
shorter and in that case I wanted nil:

(map (fn [i] (sp/transform sp/MAP-VALS #(nth % i) optij)) (range 0 (inc 
(apply max (map (comp count vals) optij)
=> ({:name :tom, :age 1, :tone :do} {:name :dick, :age 2, :tone :re} {:name 
:harry, :age 3, :tone :mi})


On Tuesday, January 10, 2017 at 7:27:24 AM UTC-8, hiskennyness wrote:
>
> Whenever I code something like this I get the feeling a clojure guru could 
> do it more simply, and I love learning new tricks.
>
> Here is my simple (real-world, btw) problem and solution. Is there a 
> better way?
>
> ;; Problem: given optimized* json maps (* to avoid duplicating keys):
> (def optij {:name [:tom :dick :harry]
>:age [1 2 3]
>:tone [:do :re :mi]})
>
> ;; ... produce normal repetitious maps
> (comment
>   [{:name :tom, :age 1, :tone :do}
>{:name :dick, :age 2, :tone :re}
>{:name :harry, :age 3, :tone :mi}])
>
> ;; goal #1: pivot so I can use zipmap
> (comment
>   ((:tom 1 :do) (:dick 2 :re) (:harry 3 :mi)))
>
> ;; my goal #1 approach (improvements welcome):
> (apply (partial map (fn [& vs] vs))
>(vals optij))
>
> (apply (partial map vector)
>(vals optij))
>
> ;; my overall approach (improvements welcome):
> (let [ks (keys optij)
>   vs-pivoted (apply (partial map vector)
> (vals optij))]
>   (vec (for [attributes vs-pivoted]
>  (zipmap ks attributes
>
>
> Final fun question: is the original idea of compressing JSON this way 
> commonplace? I thought everyone was just saying to hell with the 
> duplication and taking the convenience of self-defining objects, but 
> apparently one source is not.
>

-- 
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: with-redefs does not work for macros

[Beau Fabry]

Not an answer to your question, but I usually just redefine 
clojure.tools.logging/log* instead for tests.

On Monday, April 27, 2015 at 9:34:14 AM UTC-7, Vebjorn Ljosa wrote:
>
> In one of my tests, I was trying to mock something 
> (`clojure.tools.logging/warn`) that happened to be a macro. It had me 
> puzzled for a while until I discovered that `with-redefs` resets the value 
> of the vars after the body is executed, but does not reset the flag that 
> says that the var is a macro:
>
> $ lein repl
> Clojure 1.6.0
> …
> user=> (defmacro foo [] `(prn "I am a macro")) 
> #'user/foo 
> user=> (clojure.test/function? 'foo)
> false
> user=> (with-redefs [foo (fn [] 42)])
> nil
> user=> (clojure.test/function? foo) 
> true
> user=> (foo) 
> ArityException Wrong number of args (0) passed to: user/foo 
> clojure.lang.AFn.throwArity (AFn.java:429) 
> user=> (foo 42 42) 
> (clojure.core/prn "I am a macro")
>
> Is this a bug?
>
> I looked at the source for `with-redefs-fn`, and the fix appears simple: 
> record for each val whether it's a macro or not, and then call the 
> `(setMacro)` method on the vars that should be macros after resetting their 
> values.
>
> Vebjorn
>

-- 
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.test/instrument causes clojure.spec/exercise-fn to use generators which fail the args spec!?

[Beau Fabry]

You have two possible branches for your ::fizbuzz arguments, a one-arity 
and a 3-arity. The 1-arity branch allows for the value 1, which when passed 
to the function fizzbuzz recursively calls the function fizzbuzz with the 
arguments (3 5 1) is not a valid set of values for ::fizzbuzz and so raises 
an exception.

The reason you only get the exception when you've instrumented the 
function, is because the non-conforming set of arguments is constructed in 
the 1-arity, and doesn't get checked against ::fizzbuzz unless 
instrumentation is turned on.


On Thursday, October 20, 2016 at 3:17:19 PM UTC+11, J.-F. Rompre wrote:
>
> I am trying to learn clojure.spec and tried my hand at a spec for a 
> fizzbuzz function. 
> For some strange reason, generators created for it fail the same spec 
> during clojure.spec/exercise-fn !
>
> Stranger, this happens only if the same function is first instrumented 
> using clojure.spec.stest/instrument.
> Otherwise (commenting out the instrument call), exercise-fn generates 
> compliant inputs and returns.
>
> I tried to reproduce this with a trivial example to show here but 
> couldn't, so created a gist to illustrate the issue: 
>  https://gist.github.com/KingCode/101ff425f1abd9693a7e8c4b5d389e74
>
> Thanks for any comment and enlightening, I can't wait to use spec 
> productively :)
> JF
>

-- 
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: multi-spec and unqualified keys

[Beau Fabry]

Changing these two lines works, but I don't know whether it would cause 
other issues

```
(defmulti event-type :type)
(s/def :event/event (s/multi-spec event-type :type))
```

On Monday, October 3, 2016 at 4:01:32 AM UTC-7, Karol Hosiawa wrote:
>
> I don't know how to define multi-spec so that it works with unqualified 
> keys and generators.
>
> An example from the official guide:
>
> https://clojure.org/guides/spec#_multi_spec
>
>
> (s/def :event/type keyword?)
> (s/def :event/timestamp int?)
> (s/def :search/url string?)
> (s/def :error/message string?)
> (s/def :error/code int?)
>
> (defmulti event-type :event/type)
> (defmethod event-type :event/search [_]
>   (s/keys :req-un [:event/type :event/timestamp :search/url]))
> (defmethod event-type :event/error [_]
>   (s/keys :req-un [:event/type :event/timestamp :error/message 
> :error/code]))
>
> (s/def :event/event (s/multi-spec event-type :event/type))
>
>
> I changed :req to :req-un 
>
> Now when I try to generate some data:
>
> (s/exercise :event/event 1)
>
> I get both :type and :event/type keys:
>
> ([{:type :V, :timestamp -1, :message "", :code -1, :event/type 
> :event/error} 
>   {:type :V, :timestamp -1, :message "", :code -1, :event/type 
> :event/error}])
>
> I'd like to have only the unqualified :type key in there.
>
> What am I missing ?
>
> Any help much appreciated.
> Karol
>
>

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

[Beau Fabry]

You're probably right, I was confusing actors with agents.

On Tuesday, September 20, 2016 at 7:05:19 PM UTC-7, Matan Safriel wrote:
>
> Actually, I am not sure clojure implements the actor model, which I can 
> only construe as the Erlang actor model here. I am almost certain the core 
> language explicitly does not: http://clojure.org/about/state
>
> It can be shoehorned somehow (see okku) but I would probably not venture 
> saying clojure supports the actor model.
>
> Sent from my mobile
>
>  Original Message 
> From:Beau Fabry 
> Sent:Wed, 21 Sep 2016 03:47:29 +0300
> To:Clojure 
> Subject:Re: core.async top use cases
>
> I'm no expert on this, but the Actor model and the CSP model seem to be 
> two different ways to model a concurrent system. Clojure supports them 
> both. Personally I find the CSP model a simpler and easier to understand 
> one than Actors, and so pretty much default to it. You might find 
> non-clojure related sources comparing the tradeoffs between the two though?
>
>
> On Monday, September 19, 2016 at 11:50:53 PM UTC-7, Matan Safriel wrote:
>>
>> Thanks but I'm not entirely sure about this. I could use agents for side 
>> effects too, or at least I thought so. Care to further clarify?
>>
>>
>>  Original Message 
>> From:William la Forge 
>> Sent:Tue, 20 Sep 2016 02:37:20 +0300
>> To:Clojure 
>> Subject:Re: core.async top use cases
>>
>> The really nice thing to me is that async handles side-effects while 
>> agents do not.
>>
>> -- 
>> 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 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: core.async top use cases

[Beau Fabry]

I'm no expert on this, but the Actor model and the CSP model seem to be two 
different ways to model a concurrent system. Clojure supports them both. 
Personally I find the CSP model a simpler and easier to understand one than 
Actors, and so pretty much default to it. You might find non-clojure 
related sources comparing the tradeoffs between the two though?


On Monday, September 19, 2016 at 11:50:53 PM UTC-7, Matan Safriel wrote:
>
> Thanks but I'm not entirely sure about this. I could use agents for side 
> effects too, or at least I thought so. Care to further clarify?
>
>
>  Original Message 
> From:William la Forge 
> Sent:Tue, 20 Sep 2016 02:37:20 +0300
> To:Clojure 
> Subject:Re: core.async top use cases
>
> The really nice thing to me is that async handles side-effects while 
> agents do not.
>
> -- 
> 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: In clojure.spec, how to declare all valid keys in a map

[Beau Fabry]

boot.user=> (s/def ::my-map (s/and (s/keys :req [::a ::b])  (s/map-of #{::a 
::b} any?)))
boot.user=> (s/explain ::my-map {::a 1 ::b 2 ::BAD 3})
In: [:boot.user/BAD 0] val: :boot.user/BAD fails spec: :boot.user/my-map 
at: [0] predicate: #{:boot.user/a :boot.user/b}

Seems better

On Tuesday, September 20, 2016 at 5:38:10 AM UTC-7, David Goldfarb wrote:
>
> In clojure.spec, how can I declare a map that accepts only certain keys?  
>
> *{::a 1 ::b 2 ::BAD 3}* does conform to *(s/keys :req :req [::a ::b])*, 
> but I want a spec that will be bothered by ::BAD or any other undeclared 
> key.
>
> My use case: I am introducing spec to some legacy code, and I want to be 
> warned if I have failed to specify some elements that may appear in my map.
>
>
> Question 2:
>
>  So, assuming that this is not possible currently, I brute-forced it with:
>
> *(defn- key-checker [valid-keys]*
> *  (fn [map-to-check]*
> *(empty? (clojure.set/difference (into #{} (keys map-to-check)) 
> valid-keys*
>
> *(s/def ::my-map (s/and (s/keys :req [::a ::b])  (key-checker #{::a 
> ::b})))*
>
>
> Ignoring the ugly, and easily fixable, smell of the duplicated set of 
> keys, this has a bigger problem:
>
> If the predicate fails, the error that assert gives me is *"{... big ugly 
> map ...} fails predicate: (key-checker #{::a ::b})"* with no easy way for 
> the viewer to see which key failed. Can I somehow hook into the explain 
> mechanism to give a more useful message?
>

-- 
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 can I evaluate local symbols using eval function in Clojure?

[Beau Fabry]

Hi Philos,

Without getting into how to implement this, the `spyscope` library and the 
`clojure.tools.logging` library implement this pattern in their `spy` macro 
and #spy/d reader literal respectively. So you could either add them to 
your development toolkit (recommended) or you could read their 
implementations.

https://github.com/clojure/tools.logging/blob/master/src/main/clojure/clojure/tools/logging.clj#L120
https://github.com/dgrnbrg/spyscope

Cheers,
Beau

On Tuesday, September 6, 2016 at 4:30:09 AM UTC-7, Philos Kim wrote:
>
> I appreciate your reply.
>
> The following is the entire code where I encountered this problem.
> My intention was for debugging purpose to print the result of every nested 
> expression in a form.
>
>
> (ns debux.lab
>   (:require (clojure [walk :as walk])))
>
> ;; For debugging
> (defmacro dbg_
>   [form]
>   `(let [return# ~form]
>  (println ">> dbg_:" (pr-str '~form) "=>" return# "<<")
>  return#))
>
> (def a 2)
> (def b 3)
> (def c 5)
>
> (defn- dispatch
>   [node]
>   (cond
> (list? node)
> (do (eval `(dbg_ ~node))
> node)
>
> (and (symbol? node)
>  (not (fn? (eval `~node
> (do (eval `(dbg_ ~node))
> node)
>
> :else node))
>
> (defn- tree-walk
>   [tree]
>   (walk/postwalk dispatch tree))
>
>
> ;; dbg for nested expressions
> (defmacro dbgn [form]
>   (tree-walk form))
>
>
> ;;; test samples
>
> ;; This works because every symbol is declared in global symbols
> (dbgn (* c (+ a b)))
> ; >> dbg_: c => 5 <<
> ; >> dbg_: a => 2 <<
> ; >> dbg_: b => 3 <<
> ; >> dbg_: (+ a b) => 5 <<
> ; >> dbg_: (* c (+ a b)) => 25 <<
>
>
> ;; This works too, because literal syntax-quotes are used.
> (let [a 10 b 20 c 30]
>   (eval `(* ~c (+ ~a ~b
> ; => 900
>
>
> ;; But this doesn't work, because literal syntax-quotes can't be used in 
> this case.
> (let [a 10 b 20 c 30]
>   (dbgn (* c (+ a b
> ;   2. Unhandled clojure.lang.Compiler$CompilerException
> ;  Error compiling work/philos/debux/src/debux/lab.clj at (52:3)
> ;   
> ;   1. Caused by java.lang.UnsupportedOperationException
> ;  Can't eval locals
> ;   
> ;Compiler.java: 5943 
>  clojure.lang.Compiler$LocalBindingExpr/eval
> ;Compiler.java: 6932  clojure.lang.Compiler/eval
> ;Compiler.java: 6890  clojure.lang.Compiler/eval
> ; core.clj: 3105  clojure.core/eval
> ; core.clj: 3101  clojure.core/eval
> ;..
>
>
> Any suggestion 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.

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Beau Fabry]

Just specifically on a custom REPL printer, wouldn't that negate the 
benefits Alex sees in people becoming accustomed to reading spec error 
messages? If every error report from each different environment potentially 
looks different? Also, from the position of a community maintainer Brian is 
most commonly going to be seeing the lowest common denominator error 
messages in bug reports filed, and it probably wouldn't be helpful for him 
to be getting multiple representations of the same error in different 
reports.

On Wednesday, August 24, 2016 at 6:39:51 AM UTC-7, stuart@gmail.com 
wrote:
>
> Brian originally raised 5 points that were concrete & specific, and 
> therefore potentially actionable. That is usefully-shaped feedback, thanks 
> Brian!  My take on those points, which I will recast in my own words:
>
> 1. "Loosen rules about ns form to match what people have actually done." 
>  This is pretty unlikely, for reasons already covered.
>
> 2. "You can tailor a much better specific message for 'require should be a 
> keyword' than what spec makes today." There are several possible things to 
> explore here. The most interesting one is "can spec come closer to a 
> bespoke message while maintaining its simplicity and composability?"  We 
> want to make all errors better, not one error awesome. Ideas welcome!  
>
> 3. "Follow the inverted pyramid so people see what is most important." 
>  This kind of thing is easily done in a layer above spec, e.g. a custom 
> REPL printer for spec macro errors. Worth working on but not critical to 
> getting spec right.
>
> 4. "Name the problem namespace."  Spec does way better than this already, 
> finding the precise file and line.  If there are places where this is 
> busted we should fix them.
>
> 5. "I don't want to see the stack trace."  Then filter it out of your 
> REPL.  Intermediaries should never discard telemetry, but end consumers can 
> choose to.
>
> Cheers,
> Stu
>
>
>
> On Wed, Aug 24, 2016 at 5:57 AM, Colin Fleming  > wrote:
>
>> Sure, at the end of the day I don't really care about thre 
>> require/:require issue, it just seems a little incongruent with previous 
>> decisions which have promoted backwards compatibility. I generally prefer 
>> increased strictness, so I'm fine with the change. I do care about the 
>> error messages, though.
>>
>> On 24 August 2016 at 21:32, Mond Ray  
>> wrote:
>>
>>> I agree Colin, this feels more like the beatings shall continue until 
>>> morale improves ;-)
>>>
>>> More seriously, I understand the point of the musical instruments 
>>> analogy to be a reminder to programmers that learning a language and 
>>> understanding it in depth will increase your power and expressivity with 
>>> that language. That should not be used as a reason to increase the 
>>> difficulties caused by obscure error reporting. My initial understanding of 
>>> the sales pitch for specs was that it would serve to improve error messages 
>>> as the macro expansions / transformations would be more tractable in the 
>>> compiler. I get that it is a work in progress but let's retain that 
>>> original goal.
>>>
>>> Unlike you however, I would prefer correctness and the consequent 
>>> ripples over the continuing acceptance of incorrect expressions. My 
>>> reasoning is that code which has fewer compatibility style branches will be 
>>> easier to equip with the necessary instrumentation for generating more 
>>> human friendly error messages.
>>>
>>> Ray
>>>
>>> PS I think this require vs :require thing comes from the way that 
>>> novices confuse the ns macro with the function that pulls dependencies in 
>>> at the REPL. Cutting / pasting between the REPL and the file can allow that 
>>> to bleed in. I know it confused me.
>>>
>>> On Wednesday, 24 August 2016 01:09:48 UTC+2, Colin Fleming wrote:

 But creating error messages that are optimal for a user with no 
> knowledge or Clojure or spec is just not the goal.


 This is a totally false dichotomy. No-one in this thread is asking for 
 that. This thread has several examples of expert Clojure users for whom 
 the 
 error messages are incomprehensible. 

 I am equally unapologetic about thinking that the musical instrument 
 analogy is mostly bogus here. There are things that will always be 
 difficult about learning Clojure because they're conceptual, such as 
 functional programming. I think the analogy is fair there, they are just 
 things that will require effort and practice to learn. But the error 
 messages are about giving people the information they need *so that 
 they can actually learn from their mistakes*. Clojure has historically 
 been appallingly bad at that, and no-one should expect their users to 
 flail 
 around randomly trying things to see what works. I've spoken to various 
 smart people who have described their experience of using Clojure 

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Beau Fabry]

While I think the spec errors are pretty unfriendly, it's probably worth 
remembering that most of the times you'll get one you would have got an 
inscrutable ClassCastException or incorrect behaviour from a totally 
different place in the codebase prior to spec. It's definitely a huge 
improvement on that.

The :require issue was an unfortunate first encounter with a spec error 
because it caught a situation that wasn't actually causing a problem, I 
think most spec errors users see in the wild that won't be true for.

On Tuesday, August 23, 2016 at 6:49:38 AM UTC-7, Brian Marick wrote:
>
>
> On Aug 22, 2016, at 7:50 PM, Alex Miller  > wrote:
>
>
> You've complained in other channels about the "learning to read" error 
> messages part and I think you've taken it entirely the wrong way or maybe I 
> just disagree. There are benefits from reporting errors in a generic, 
> consistent way. […]
>
>
> Do there exist examples of what is desired for error messages in 
> 1.9-final? Not promises, but a “this is what we’re shooting for”? What 
> would you all like the specific error messages complained about in this 
> thread to look like? 
>
> Colin Fleming wrote: "The error message produced by the code I demoed at 
> the conj last year would be:
>
> Unexpected symbol 'require' at  while parsing 
> namespace clauses. Expected :refer-clojure, :require, :use, :import, :load 
> or :gen-class.”
>
> Is that the goal? I fear that the goal is that it should be my job to 
> understand "(cat :attr-map (? map?) :clauses 
> :clojure.core.specs/ns-clauses)”. For what little it’s worth, I consider 
> that completely unacceptable. 
>
> - Getting the error data (specifically the explain-data output) to be both 
> sufficient and generically useful is the first priority. I think at this 
> point that's pretty close and unlikely to change significantly. 
>
>
> My bias here is that I come from the learned-from-bitter-experience 
> tradition that believes it’s very risky to (1) get the infrastructure 
> right, and then (2) pop down the user-visible features on top of it. Very 
> often, the infrastructure turns out to be a poor match for the actual needs 
> of the features. But, since (1) is already done, the features - and 
> consequently the users - suffer. 
>
> Please understand I’m not being insulting when I say that everyone has 
> weaknesses and blind spots, even undoubted geniuses. In Clojure, error 
> messages and documentation (especially doc strings) have long been glaring 
> weaknesses. So I am wishing to be helpful when I counsel *quickly* getting 
> to worked examples of output, especially output that novices are likely to 
> encounter. And exposing those messages to typical users, ones who are not 
> familiar with core.spec. 
>
> That seems prudent. 
>
> I believe strongly enough in good error messages that I would be willing 
> to do some of the scut work, if needed.
>

-- 
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 screencast: Testing

[Beau Fabry]

Sweet. Looking forward to it. Enjoying the casts so far very quick ramp up. 
Nice work

On Wednesday, July 27, 2016 at 11:52:36 AM UTC-7, stuart@gmail.com 
wrote:
>
> Yes.  Short answer: Make a model of the input space. Coming in a future 
> screencast. :-)
>
> Stu
>
> On Wed, Jul 27, 2016 at 2:13 PM, Beau Fabry <imf...@gmail.com 
> > wrote:
>
>> With the passing test of `my-index-of`, is there any way to be confident 
>> that test.check generated inputs that checked the branch of the :fn spec 
>> where a return other than nil happened? All of the invocations of 
>> `exercise-fn` in the screencast only managed to get nil as a result.
>>
>>
>> On Wednesday, July 27, 2016 at 9:22:27 AM UTC-7, Alex Miller wrote:
>>>
>>> Check out the 2nd screencast about spec, this time on testing with check 
>>> and instrument:
>>>
>>> http://blog.cognitect.com/blog/2016/7/26/clojure-spec-screencast-testing
>>>
>> -- 
>> 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: Clojure spec screencast: Testing

[Beau Fabry]

With the passing test of `my-index-of`, is there any way to be confident 
that test.check generated inputs that checked the branch of the :fn spec 
where a return other than nil happened? All of the invocations of 
`exercise-fn` in the screencast only managed to get nil as a result.

On Wednesday, July 27, 2016 at 9:22:27 AM UTC-7, Alex Miller wrote:
>
> Check out the 2nd screencast about spec, this time on testing with check 
> and instrument:
>
> http://blog.cognitect.com/blog/2016/7/26/clojure-spec-screencast-testing
>

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

[Beau Fabry]

Right, and I don't think the "this is closed we shouldn't discuss it 
anymore" line is great when people are advocating for a piece of 
functionality. I understand Alex doesn't want endless threads bikeshedding 
basically arbitrary naming choices, but that's not the same as people 
making simple points of "I think X would be a good addition because of Y" 
with no back and forth.

Maybe enough people saying "yes that sounds like a good idea because Y" in 
this thread will convince someone else that they should create a lib that 
mirrors the old functionality, this is the general Clojure group and not 
clojure-dev after all.

Sorry about the meta.

On Tuesday, July 19, 2016 at 3:51:09 PM UTC+10, Sean Corfield wrote:
>
> Well, both Alex and Rich have said the change is deliberate and there are 
> no plans to change that decision – and Rich talked about ways you can add 
> return value testing manually based on specs (if you want, but he won’t 
> help you) – so it seems like a “closed” topic to me? (and Alex has shut 
> down a couple of other threads that have continued on past a clear line of 
> decision)
>
>  
>
> I was sad to see :ret checking go away but I accept Rich’s line of 
> thinking on this and I’ll adjust my workflow accordingly. I find Rich’s 
> point that instrumentation is now about ensuring functions are _*called*_ 
> correctly rather than trying to establish that they _*behave*_ correctly 
> oddly compelling, now that I’ve had some time to think about it and play 
> with it 
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org
>
>  
>
> *From: *Beau Fabry 
> *Sent: *Monday, July 18, 2016 8:50 PM
> *To: *Clojure 
> *Subject: *Re: Thoughts on clojure.spec
>
>  
>
> I think that was an explanation of why it's not particularly valuable in 
> unit tests, but not really an explanation of why it wouldn't be useful in 
> lower environments or canary boxes in distributed deployments. This thread 
> has also touched on how not everything is gen-testable because of 
> complexity, and I'd add that side-effects are another reason for that. We 
> also have "you can just use assert on the return value" which is true, but 
> seeing as I already have a database of expected return values that I've 
> defined then it seems natural to be able to use that database to gain some 
> extra testing value rather than define it again.
>
>  
>
> I'm not trying to argue for inclusion, if clojure core doesn't want to 
> implement the feature then those who see value in it can trivially 
> implement it themselves, but I haven't read anything that's made me think 
> it wouldn't be useful.
>
>
> On Tuesday, July 19, 2016 at 12:53:49 PM UTC+10, Sean Corfield wrote:
>
> Rich has given a pretty good explanation of why this was removed 
> elsewhere. And in this thread, a week ago, he explained again why 
> gen-testing :ret and :fn specs was the better approach.
>
>  
>
> 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
>
>  
>
> On 7/18/16, 7:46 PM, "Oliver George" <clo...@googlegroups.com on behalf 
> of oli...@condense.com.au> wrote:
>
>  
>
> Here's the commit removing that aspect of instrument-all.  Not a big 
> change.
>
>  
>
>
> https://github.com/clojure/clojure/commit/30dd3d8554ff96f1acda7cbe31470d92df2f565a
>
>  
>
> As an aside, I also love the idea of the Clojure community fostering a 
> culture of gen testing each chunk of well defined functionality.  If it's 
> truly achievable the Clojure community could become known as an unstoppable 
> force of robust code.
>
>  
>
> It would be something of a challenge for many of us... especially those 
> wanting this particular feature!
>
>  
>
>  
>
> On 19 July 2016 at 10:36, Beau Fabry <imf...@gmail.com> wrote:
>
> > Do you find it frustrating that there's no way to turn on 
> instrumentation of function outputs for manual testing?
>
>  
>
> Yes. I've mentioned this elsewhere but I think being able to turn on 
> output checking in lower environments (dev, test, master, staging) is 
> getting extra values from specs basically for free. Being able to do it 
> seems pragmatic. I'm hoping it won't be too difficult to write an 
> `overinstrument-all` that gives me that when I want it.
>
>
> On Tuesday, July 12, 2016 at 5:36:39 PM UTC+10, Maarten Truyens wrote:
>
> I would also truly appreciate instrumentation of function outputs for 
> manual outputs. I understand the rationale for not having it as t

Re: Thoughts on clojure.spec

[Beau Fabry]

I think that was an explanation of why it's not particularly valuable in 
unit tests, but not really an explanation of why it wouldn't be useful in 
lower environments or canary boxes in distributed deployments. This thread 
has also touched on how not everything is gen-testable because of 
complexity, and I'd add that side-effects are another reason for that. We 
also have "you can just use assert on the return value" which is true, but 
seeing as I already have a database of expected return values that I've 
defined then it seems natural to be able to use that database to gain some 
extra testing value rather than define it again.

I'm not trying to argue for inclusion, if clojure core doesn't want to 
implement the feature then those who see value in it can trivially 
implement it themselves, but I haven't read anything that's made me think 
it wouldn't be useful.

On Tuesday, July 19, 2016 at 12:53:49 PM UTC+10, Sean Corfield wrote:
>
> Rich has given a pretty good explanation of why this was removed 
> elsewhere. And in this thread, a week ago, he explained again why 
> gen-testing :ret and :fn specs was the better approach.
>
>  
>
> 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
>
>  
>
> On 7/18/16, 7:46 PM, "Oliver George" <clo...@googlegroups.com 
>  on behalf of oli...@condense.com.au > wrote:
>
>  
>
> Here's the commit removing that aspect of instrument-all.  Not a big 
> change.
>
>  
>
>
> https://github.com/clojure/clojure/commit/30dd3d8554ff96f1acda7cbe31470d92df2f565a
>
>  
>
> As an aside, I also love the idea of the Clojure community fostering a 
> culture of gen testing each chunk of well defined functionality.  If it's 
> truly achievable the Clojure community could become known as an unstoppable 
> force of robust code.
>
>  
>
> It would be something of a challenge for many of us... especially those 
> wanting this particular feature!
>
>  
>
>  
>
> On 19 July 2016 at 10:36, Beau Fabry <imf...@gmail.com > 
> wrote:
>
> > Do you find it frustrating that there's no way to turn on 
> instrumentation of function outputs for manual testing?
>
>  
>
> Yes. I've mentioned this elsewhere but I think being able to turn on 
> output checking in lower environments (dev, test, master, staging) is 
> getting extra values from specs basically for free. Being able to do it 
> seems pragmatic. I'm hoping it won't be too difficult to write an 
> `overinstrument-all` that gives me that when I want it.
>
>
> On Tuesday, July 12, 2016 at 5:36:39 PM UTC+10, Maarten Truyens wrote:
>
> I would also truly appreciate instrumentation of function outputs for 
> manual outputs. I understand the rationale for not having it as the 
> default, but could it perhaps be specified as an option s/instrument? 
> (Considering that it was present in the first alphas, I would assume that 
> such option should not be far-fetched.)
>
> -- 
>
>  
>
>

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

[Beau Fabry]

> Do you find it frustrating that there's no way to turn on instrumentation 
of function outputs for manual testing?

Yes. I've mentioned this elsewhere but I think being able to turn on output 
checking in lower environments (dev, test, master, staging) is getting 
extra values from specs basically for free. Being able to do it seems 
pragmatic. I'm hoping it won't be too difficult to write an 
`overinstrument-all` that gives me that when I want it.

On Tuesday, July 12, 2016 at 5:36:39 PM UTC+10, Maarten Truyens wrote:
>
> I would also truly appreciate instrumentation of function outputs for 
> manual outputs. I understand the rationale for not having it as the 
> default, but could it perhaps be specified as an option s/instrument? 
> (Considering that it was present in the first alphas, I would assume that 
> such option should not be far-fetched.)
>

-- 
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 a call fail without type hints? (Understanding reflected calls)

[Beau Fabry]

My guess is the class generated by jnr-ffi can't be inspected with 
reflection for some reason or other, you should try poking at that sodium 
instance 
with http://clojure.github.io/clojure/branch-master/clojure.reflect-api.html 
in a repl and see what you get!

In terms of "how expensive reflection is" I can help you out quickly there 
though and say "very". Reflection is very expensive. If it's going to run 
more than once a minute you should try and avoid reflection.

On Thursday, June 30, 2016 at 12:08:34 PM UTC-7, lvh ‌ wrote:
>
> Hi, 
>
>
> In my project, caesium, I’m binding against libsodium using jnr-ffi. This 
> involves creating an Interface with a bunch of methods. This all works 
> swimmingly, most of the time. 
>
> I have two functions that differ only in their arguments being type 
> hinted: 
>
> (defn secretbox-easy-to-byte-bufs-nocast! 
>   [^ByteBuffer out ^ByteBuffer msg ^ByteBuffer nonce ^ByteBuffer key] 
>   (.crypto_secretbox_easy sodium out msg (.remaining msg) nonce key) 
>   out) 
>
> (defn secretbox-easy-refl! 
>   [out msg nonce key] 
>   (.crypto_secretbox_easy sodium out msg (.remaining msg) nonce key) 
>   out) 
>
> When calling this function with direct byte buffers (and only with direct 
> byte buffers!), the call fails. First few lines of traceback: 
>
>   actual: java.lang.IllegalArgumentException: No matching method found: 
> crypto_secretbox_easy for class caesium.binding.Sodium$jnr$ffi$0 
>  at clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:80) 
> clojure.lang.Reflector.invokeInstanceMethod (Reflector.java:28) 
> caesium.crypto.secretbox$secretbox_easy_refl_BANG_.invokeStatic 
> (secretbox.clj:85) 
>
> The type hinted version works fine. 
>
> Is this expected behavior, or a bug? I’m trying to measure how expensive 
> reflection is, and wasn’t expecting this problem. DirectByteBuffer appears 
> undocumented, but it is a subclass of MappedByteBuffer, implementing 
> ByteBuffer. 
>
>
> lvh

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

[Beau Fabry]

I think Alex's point was given any arbitrary function can be used as the 
conform part of the spec, this wouldn't be possible. Ie

boot.user=> (s/conform (s/conformer inc) 1)
2

On Saturday, June 18, 2016 at 10:35:10 AM UTC-7, Leon Grapenthin wrote:
>
> 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.

Re: clojure.spec

[Beau Fabry]

You just need to come up with qualified names for them:

user=> (require '[clojure.spec :as s])
nil
user=> (s/def :base/attack (s/and integer? pos? #(<= % 1000)))
:base/attack
user=> (s/def :base/bonus (s/keys :req-un [:bonus/category]))
:base/bonus
user=> (s/valid? :base/event {:attack 100 :bonus {:category {:heavy 100}}})
true

Not sure about channels.

On Friday, May 27, 2016 at 12:36:56 AM UTC-7, Pedro Pereira Santos wrote:

> Hello,
>
> How can I differentiate between the same keyword, but with difference 
> semantics? Example:
>
> {:attack 100
>  :bonus {:attack {:category {:heavy 100
>
> I have:
> (s/def ::attack (s/and pos? #(<= 1 1000))
> (s/def ::bonus (s/keys :req-un [::attack ; <--- 
>
> Is there a way to do this?
>
> --
>
> Another question: is there a way to spec a fn that handles channels? 
> Something like:
>
> (s/fdef some-fn
>  :args (s/cat :ch (s/chan ::unq/model))
>  :ret (s/chan :unq/model))
>
> --
>
> And yet another: I have a game project with some test.check scenarios. The 
> test run takes 8s without instrumenting and 22s with instrumentation, and 
> this makes me think on starting to split tests in test suites. Is there 
> something to handle this in clojure.test?
>
> Thanks!
>
>
> On Thu, May 26, 2016 at 7:00 PM Beau Fabry <imf...@gmail.com > 
> wrote:
>
>> I'm in a similar position to you Wesley, I'm all for generative testing, 
>> but sometimes I prefer not to spec out the full depth of the tree (ie some 
>> input leaves with s/Any) and just turn on validation in staging and see 
>> what happens. The cpu-time wasted there doesn't matter much to me. Looking 
>> forward to seeing where things end up. Spec certainly seems really well 
>> thought through.
>>
>> Aside: Great work on the docs Alex. Much much more comprehensive and 
>> readable than is usually available for an alpha feature in *any* language.
>>
>>
>> On Thursday, May 26, 2016 at 6:57:24 AM UTC-7, Wesley Hall wrote:
>>>
>>> Thanks Rich, for this and your work in general. After 15 years of 
>>> working with Java, it has been a real joy to find clojure (let's face it, 
>>> that pun alone is pure gold!). 
>>>
>>> I might try my hand at the macrology you describe as an exercise... 
>>> everybody stand well back
>>>
>>> On Thursday, 26 May 2016 14:43:04 UTC+1, Rich Hickey wrote:
>>>>
>>>> If you name (register) your (sub)specs with s/def and you can reuse 
>>>> them as much as you like. 
>>>>
>>>> (s/def ::argi (s/cat :i integer?)) 
>>>> (s/def ::fnii (s/fspec :args ::argi :ret integer?)) 
>>>> (s/conform ::fnii +) 
>>>> (s/valid? ::argi '(42)) 
>>>>
>>>> However you are talking about calling ‘instrument’ so I don’t think you 
>>>> are in the HOF case. So you shouldn’t be using fspec but fdef: 
>>>>
>>>> (s/fdef fooi :args (s/cat :i integer?) :ret integer?) 
>>>>
>>>> (defn fooi [i] 
>>>>   (let [spec (-> `fooi s/fn-specs :args)] 
>>>> (assert (s/valid? spec (list i)) (s/explain-str spec (list i 
>>>>   42) 
>>>>
>>>> (fooi "42") 
>>>> user=> AssertionError Assert failed: In: [0] val: "42" fails at: [:i] 
>>>> predicate: integer? 
>>>>
>>>> Obviously some macrology could make this more succinct, as is being 
>>>> discussed elsewhere. 
>>>>
>>>> > On May 26, 2016, at 9:17 AM, Wesley Hall <wesle...@gmail.com> wrote: 
>>>> > 
>>>> > spec is not a contract system. 
>>>> > 
>>>> > Forgive me for I am about to sin :). 
>>>> > 
>>>> > I have a little RPC framework that I use to do simple remoting 
>>>> between clojurescript in the browser and ring based web services. I'm 
>>>> currently using schema to validate arguments received from clients and 
>>>> return appropriate exceptions upon non-conforming invocations. 
>>>> > 
>>>> > The idea of being able to perform generative testing against a 
>>>> specification for these functions is really appealing but if I am using 
>>>> generative testing to verify that my functions behave properly if invoked 
>>>> as intended it does feel like there would be some benefit to ensuring that 
>>>> the conditions under which the function has been tested are enforced at 
>>>> runtime for those functions on the edges of my

Re: clojure.spec

[Beau Fabry]

I'm in a similar position to you Wesley, I'm all for generative testing, 
but sometimes I prefer not to spec out the full depth of the tree (ie some 
input leaves with s/Any) and just turn on validation in staging and see 
what happens. The cpu-time wasted there doesn't matter much to me. Looking 
forward to seeing where things end up. Spec certainly seems really well 
thought through.

Aside: Great work on the docs Alex. Much much more comprehensive and 
readable than is usually available for an alpha feature in *any* language.

On Thursday, May 26, 2016 at 6:57:24 AM UTC-7, Wesley Hall wrote:
>
> Thanks Rich, for this and your work in general. After 15 years of working 
> with Java, it has been a real joy to find clojure (let's face it, that pun 
> alone is pure gold!). 
>
> I might try my hand at the macrology you describe as an exercise... 
> everybody stand well back
>
> On Thursday, 26 May 2016 14:43:04 UTC+1, Rich Hickey wrote:
>>
>> If you name (register) your (sub)specs with s/def and you can reuse them 
>> as much as you like. 
>>
>> (s/def ::argi (s/cat :i integer?)) 
>> (s/def ::fnii (s/fspec :args ::argi :ret integer?)) 
>> (s/conform ::fnii +) 
>> (s/valid? ::argi '(42)) 
>>
>> However you are talking about calling ‘instrument’ so I don’t think you 
>> are in the HOF case. So you shouldn’t be using fspec but fdef: 
>>
>> (s/fdef fooi :args (s/cat :i integer?) :ret integer?) 
>>
>> (defn fooi [i] 
>>   (let [spec (-> `fooi s/fn-specs :args)] 
>> (assert (s/valid? spec (list i)) (s/explain-str spec (list i 
>>   42) 
>>
>> (fooi "42") 
>> user=> AssertionError Assert failed: In: [0] val: "42" fails at: [:i] 
>> predicate: integer? 
>>
>> Obviously some macrology could make this more succinct, as is being 
>> discussed elsewhere. 
>>
>> > On May 26, 2016, at 9:17 AM, Wesley Hall  wrote: 
>> > 
>> > spec is not a contract system. 
>> > 
>> > Forgive me for I am about to sin :). 
>> > 
>> > I have a little RPC framework that I use to do simple remoting between 
>> clojurescript in the browser and ring based web services. I'm currently 
>> using schema to validate arguments received from clients and return 
>> appropriate exceptions upon non-conforming invocations. 
>> > 
>> > The idea of being able to perform generative testing against a 
>> specification for these functions is really appealing but if I am using 
>> generative testing to verify that my functions behave properly if invoked 
>> as intended it does feel like there would be some benefit to ensuring that 
>> the conditions under which the function has been tested are enforced at 
>> runtime for those functions on the edges of my API. 
>> > 
>> > I'd definitely prefer a manual conformity check over instrumentation in 
>> these cases, but it seems like an fspec cannot be used for this purpose 
>> (from within the function itself). I'd rather not define my specs twice. 
>> > 
>> > Seems like I might be destined to make cheeky instrument calls after 
>> each of these edge functions, in the same was the always-validate metadata 
>> is used in schema. 
>> > 
>> > Do I have a desperate need to be convinced otherwise? :) 
>> > 
>> > -- 
>> > 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: surprising behaviour from dissoc on records

[Beau Fabry]

Interesting. I think it makes sense in that `dissoc` is a function for 
removing a kv pair from a map, not a function for setting v to nil given a 
k. I could definitely see tripping up on this though.

On Friday, February 19, 2016 at 8:07:16 AM UTC-8, Alex Miller wrote:
>
> You can find some of the background for this at 
> http://clojure.org/reference/datatypes. Records are intended to capture 
> "application domain information" - where the fields are known. Dissoc'ing 
> means you are removing not just a value, but the whole "field", and the 
> implication here is that you devolve from a thing of that "type" to a plain 
> map. Similarly, "empty" is not implemented on records (because you then 
> remove all the "fields").
>
> This is an intentional choice made by Rich in the design of records. I 
> think it's reasonable to argue that this creates some surprises in the use 
> of records - particularly in dissoc and empty. Afaik there is no plan for 
> this behavior to change, however.
>
>
>
> On Friday, February 19, 2016 at 8:30:47 AM UTC-6, Stig Brautaset wrote:
>>
>>
>> Dissoc behaviour on records really surprised me: 
>>
>> user> (defrecord Foo [bar]) 
>> ;; => user.Foo 
>> user> (def foo (->Foo nil)) 
>> ;; => #'user/foo 
>> user> (dissoc foo :bar) 
>> ;; => {} 
>> user> (assoc foo :bar nil) 
>> ;; => #user.Foo{:bar nil} 
>>
>> It lead to a bug where a component of mine, which I was using to 
>> dispatch in a multimethod was replaced with an empty map: 
>>
>>
>> https://github.com/stig/accounts/commit/f4124b69cfc9fdc201b29f97e33a5b7bd6279e7f
>>  
>>
>> *toy project alert* 
>>
>> As an aside, I'm now starting to understand why all the components 
>> examples use `assoc foo :bar nil` rather than dissoc... 
>>
>> Stig 
>>
>>

-- 
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: Java API type hint question

[Beau Fabry]

Tell the compiler that the type you're passing to the constructor is a 
Collection, so it will know which constructor to use without reflection.

(set! *warn-on-reflection* true)
=> true
(import '(java.util ArrayList Collection))
=> java.util.Collection
(ArrayList. (list 1 2))
Reflection warning, 
/Users/bfabry/Library/Caches/IdeaIC15/tmp/form-init108635367050123227.clj:1:1 
- call to java.util.ArrayList ctor can't be resolved.
=> [1 2]
(ArrayList. ^Collection (list 1 2))
=> [1 2]



On Tuesday, January 26, 2016 at 1:56:19 PM UTC-8, Ritchie Cai wrote:
>
> Quoting for small example like I mention is not an issue, but in general, 
> I need to pass an vector or list, since that's what I get, in which case I 
> cannot quote. 
>
> On Tuesday, January 26, 2016 at 3:52:17 PM UTC-6, Michael Willis wrote:
>>
>> What's not practical about quoting?  I thought it was considered more 
>> idiomatic than doing (list ...)
>>
>> On Sunday, January 17, 2016 at 2:48:29 PM UTC-6, Ritchie Cai wrote:
>>>
>>> Hi all,
>>>
>>> I'm trying to create a Java ArrayList object from a Clojure collection 
>>> to pass to another Java API. I get reflection warnings when the elements 
>>> are not primitive types, in this case I'm using SparseIndexedVector 
>>> class from vectorz library.
>>>
>>> (ArrayList. [c0 c1 c2])
>>> Reflection warning, *cider-repl localhost*:77:11 - call to 
>>> java.util.ArrayList ctor can't be resolved.
>>>
>>> where c0 c1 c2 are of type SparseIndexedVector. Alternatively, I can 
>>> create create ArrayList then add elements one by one in a loop.
>>>
>>> (doto (ArrayList.)
>>>(.add c0)
>>>(.add c1)
>>>(.add c2))
>>>
>>> But I'm wondering if there is away to get rid of the the reflection 
>>> warning when calling ArrayList constructor. 
>>>
>>> Also, quoting a list will not give reflection warning:
>>>
>>> (ArrayList. '(c0 c1 c2))  ;; no warning
>>>
>>> (ArrayList. (list c0 c1 c2)) 
>>> Reflection warning, *cider-repl localhost*:77:11 - call to 
>>> java.util.ArrayList ctor can't be resolved.
>>>
>>> However, quoting is not very practical.
>>>
>>> Thanks
>>> Ritchie
>>>
>>>

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

[Beau Fabry]

@Brian no, is an issue with reduce-fsm (which is 
fixed) https://github.com/cdorrat/reduce-fsm/issues/9

On Tuesday, December 15, 2015 at 9:42:01 AM UTC+11, Brian Marick wrote:
>
> Noam: does this mean it's not an issue with Midje? If it is, I'll look 
> into it. 
>
> Noam Ben-Ari wrote: 
> > After upgrading to [reduce-fsm "0.1.4"] all my tests pass with RC3 :-) 
> > 
> > On Tuesday, December 8, 2015 at 3:14:21 PM UTC+2, Noam Ben-Ari wrote: 
> > 
> > Thanks for the prompt response, I have filed a ticket to the library 
> > author: 
> > 
> > https://github.com/cdorrat/reduce-fsm/issues/9 
> >  
> > 
> > On Tuesday, December 8, 2015 at 3:07:34 PM UTC+2, Nicola Mometto 
> wrote: 
> > 
> > Before 1.8, clojure would accept wrong forms like (throw 
> > my-exception 1 2 3). 
> > 
> > This is now an exception 
> > http://dev.clojure.org/jira/browse/CLJ-1456 
> > . 
> > 
> > 
> >  > On 8 Dec 2015, at 13:05, Noam Ben-Ari  
> wrote: 
> >  > 
> >  > Hi, 
> >  > I have just tried 1.8.0-RC3 and saw a problem. 
> >  > 
> >  > I have a project in which I run tests with `lein midje`, and 
> > this runs fine with 1.7.0. 
> >  > 
> >  > When I change the clojure dependency to 1.8.0-RC3 and run it 
> > I get this exception: 
> >  > 
> >  > --- 
> >  > 
> >  > Exception in thread "main" java.lang.RuntimeException: Too 
> > many arguments to throw, throw expects a single Throwable 
> > instance, compiling:(reduce_fsm.clj:203:5) 
> >  > 
> >  > --- 
> >  > 
> >  > Let me know what other information I can give to help. 
> >  > 
> >  > Thanks, 
> >  > Noam. 
> >  > 
> >  > On Wednesday, December 2, 2015 at 6:03:31 PM UTC+2, Alex 
> > Miller wrote: 
> >  > Clojure 1.8.0-RC3 is now available. This build is a "release 
> > candidate"! We would appreciate any and all testing you can do 
> > on your own libraries or internal projects to find problems. 
> >  > 
> >  > Try it via 
> >  > • Download: 
> > https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC3 
> >  
> >  > • Leiningen: [org.clojure/clojure "1.8.0-RC3"] 
> >  > Below are the changes since 1.8.0-RC2. See the full 1.8 
> > change log here: 
> > https://github.com/clojure/clojure/blob/master/changes.md 
> > . 
> >  > • CLJ-1845 / CLJ-1851 New ^:redef to mark vars that 
> > should not be direct linked 
> >  > • The metadata ^:redef can be used to mark 
> > function vars that should not be direct linked 
> >  > • clojure.core/load was previously marked 
> > with ^:dynamic for this purpose, but is now marked ^:redef 
> >  > • CLJ-1856 Direct linking breaks clojure.test 
> > location reporting for failures 
> >  > • CLJ-1854 Set line number in bytecode prior to 
> > invokeStatic call 
> >  > • CLJ-1853 In socket server, require the ns of the 
> > accept-fn before resolving it 
> >  > 
> >  > -- 
> >  > 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 

Re: Self-referential gen-class usage

[Beau Fabry]

Forgive me for resurrecting a 7 year old thread, but is this still the 
solution?

On Thursday, June 26, 2008 at 7:56:18 AM UTC-7, Chas Emerick wrote:
>
> At some point, I came to need to define a generated Java class that 
> had methods that returned instances of the class being generated.  The 
> gen-and-save-class form looked like this: 
>
> (gen-load-save-class 
>   "." 
>   'pkg.Foo 
>   :implements [Bar] 
>   :init 'new-foo 
>   :constructors {[(. Float TYPE)] []} 
>   :methods [['union [java.util.Collection] 'pkg.Foo]]  ;<--- 
>   :state 'state) 
>
> The problem is with the usage of 'pkg.Foo in the union method 
> signature def.  gen-class expects classes for those signature 
> definitions, and since the pkg.Foo class doesn't exist yet, I can't 
> reference it in the signature. 
>
> On a lark, I thought I'd try a macro that would generate and load a 
> class (without any references to the generated class), and then 
> generate and save that same class with all of the method definitions, 
> etc.  (By no means efficient, since the bytecode is being generated 
> twice, but this is mostly fun and I didn't want to futz with using gen- 
> class directly and then handling writing out or loading the bytecode.) 
> The result is this: 
>
> (defmacro gen-load-save-class [path name & options] 
>   (let [optmap (apply hash-map options) 
> save-only-opts #{:methods :constructors} 
> trimmed-opts (reduce #(if (save-only-opts %2) %1 (concat %1 
> [%2] [(optmap %2)])) [] (keys optmap))] 
> `(do (gen-and-load-class ~name ~@trimmed-opts) 
>  (eval '(gen-and-save-class ~path ~name ~@options) 
>
> gen-load-save-class has the same signature as gen-and-save-class.  It 
> pulls out the options to gen-class that can contain self-references 
> (only :methods and :constructors at the moment, I believe), generates 
> and loads the result of that trimmed-down option set, and then 
> generates and saves the full class definition. 
>
> One interesting wrinkle is that the gen-and-save-class form needs to 
> be wrapped in an eval; otherwise clojure will attempt to resolve 
> references to the generated classname in the options to gen-and-save- 
> class before it even gets to the point of evaluating the gen-and-load- 
> class call. 
>
> I know Rich is aware of this use-case (referring to the generated 
> classname when using gen-class), so a real solution will probably be 
> forthcoming sooner or later, but this was an interesting exercise in 
> the meantime. 
>
> - Chas 
>

-- 
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 make a function of a map argument ?

[Beau Fabry]

(map m [:a :b]) is a nice trick, we use it a lot in cascalog queries:
(map ?account [:id :updated-at :created-at] :> ?id ?updated-at ?created-at)

Where juxt would require more ceremony because of the need for 
serialization ((mapfn [m] ((juxt :id :updated-at :created-at) m)) ?account 
:> ?id ?updated-at ?created-at)

On Friday, October 23, 2015 at 7:42:24 AM UTC-7, Colin Yates wrote:
>
> Kicking myself I didn’t grok (map m [:a :b])!
>
> On 23 Oct 2015, at 15:32, Aaron Cohen  
> wrote:
>
> I think you might find the following blog post helpful: 
> http://blog.jayfields.com/2011/01/clojure-select-keys-select-values-and.html
>
> What you are asking for is basically (clojure.string/join (select-values 
> my-map vals)) where select-values is defined in several ways in the linked 
> blog post.
>
> For code golf points, the briefest example from the blog that would work 
> for your purposes might be:
>
> (defn select-values [m ks] (map m ks))
>
> So:
>
> user=> (def my-map { :name "roelof", :city "big-secret" })
>
> user=> (clojure.string/join ", " (map my-map [:name :city]))
> "roelof, big-secret"
>
>
> On Fri, Oct 23, 2015 at 7:49 AM, r/ Wobben  > wrote:
>
>> Hello, 
>>
>> As a challenge I need to convert a map structure to a csv structure. 
>>
>> So ( { :name "roelof", :city secret }) need to be converted to roelof, 
>> secret. 
>>
>> I think I can use something like (map clojure.string/join  ..) for it but 
>> it seems I have to make a function out of the :name roelof part to get 
>> roelof back. 
>>
>> I could use  get for then I do not know how to call 1 records of the 
>> whole map. 
>>
>> Can someone explain in simple English how I can solve this one ? 
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

Re: defprotocol/deftype namespacing

[Beau Fabry]

I can't think of any (def* forms that allow you to specify a namespace, so 
imo it would be strange if they did. 

On Thursday, September 24, 2015 at 11:58:08 AM UTC-7, Gregg Reynolds wrote:
>
> Is there some compelling reason why deftype and defprotocol do not allow 
> specification of a namespace?  They install their products in the current  
> namespace, in contrast to gen-class and gen-interface.
>
> Thanks
> Gregg
>

-- 
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: No recent activity for core.async?

[Beau Fabry]

The docs have also diverged from the current official release, I'm looking 
forward to a new release :-)

On Saturday, September 26, 2015 at 4:24:18 AM UTC-7, Gary Verhaegen wrote:
>
> That question has been asked recently and the official answer was that a 
> new release is coming "soon". There was no promise that the next release 
> would get the project out of alpha, though.
>
> On Saturday, 26 September 2015, Rafik NACCACHE  > wrote:
>
>> core.async didn't move since more than a year.
>>
>> Is any new release coming soon? I actually use this library intensively, 
>> and the fact it is staying alpha for more than a year starts giving me some 
>> shivers :)
>>
>> Thank you for any updates !!
>>
>> -- 
>> 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: range function wrong in 1.7.0-beta?

[Beau Fabry]

Ouch. Suspect this is the 
problem 
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LongRange.java#L161

Pretty sure that boolean should be round the other way.

On Saturday, April 18, 2015 at 12:32:40 PM UTC-7, Mathias De Wachter wrote:

 Hi,

 this looks like quite a serious bug to me (at least it messed up my 
 project):

 First taking the code taken from grimoire:

 clojurechess.position (defn range
   Returns a lazy seq of nums from start (inclusive) to end
   (exclusive), by step, where start defaults to 0, step to 1, and end to
   infinity. When step is equal to 0, returns an infinite sequence of
   start. When start is equal to end, returns empty list.
   {:added 1.0
:static true}
   ([] (range 0 Double/POSITIVE_INFINITY 1))
   ([end] (range 0 end 1))
   ([start end] (range start end 1))
   ([start end step]
(lazy-seq
 (let [b (chunk-buffer 32)
   comp (cond (or (zero? step) (= start end)) not=
  (pos? step) 
  (neg? step) )]
   (loop [i start]
 (if (and ( (count b) 32)
  (comp i end))
   (do
 (chunk-append b i)
 (recur (+ i step)))
   (chunk-cons (chunk b) 
   (when (comp i end) 
 (range i end step)
 WARNING: range already refers to: #'clojure.core/range in namespace: 
 clojurechess.position, being replaced by: #'clojurechess.position/range
 #'clojurechess.position/range
 clojurechess.position (range 0 11 2)
 (0 2 4 6 8 10)

 which is what I'd expect and relied on.

 Now, looking at the new code:

 clojurechess.position (clojure.repl/source clojure.core/range)
 (defn range
   Returns a lazy seq of nums from start (inclusive) to end
   (exclusive), by step, where start defaults to 0, step to 1, and end to
   infinity. When step is equal to 0, returns an infinite sequence of
   start. When start is equal to end, returns empty list.
   {:added 1.0
:static true}
   ([]
(iterate inc' 0))
   ([end]
(if (instance? Long end)
  (clojure.lang.LongRange/create end)
  (clojure.lang.Range/create end)))
   ([start end]
(if (and (instance? Long start) (instance? Long end))
  (clojure.lang.LongRange/create start end)
  (clojure.lang.Range/create start end)))
   ([start end step]
(if (and (instance? Long start) (instance? Long end) (instance? Long 
 step))
  (clojure.lang.LongRange/create start end step)
  (clojure.lang.Range/create start end step
 nil
 clojurechess.position (clojure.lang.Range/create 0 11 2)
 (0 2 4 6 8 10)
 clojurechess.position (clojure.lang.LongRange/create 0 11 2)
 (0 2 4 6 8)
 clojurechess.position (clojure.core/range 0 11 2)
 (0 2 4 6 8)

 So the culprit is clojure.lang.LongRange/create.



-- 
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: Where can one find low hanging fruit for open source contribution?

[Beau Fabry]

LightTable, the editor written in Clojurescript is currently looking for 
contributors, and have started tagging issues as beginner friendly. 
https://github.com/LightTable/LightTable

On Saturday, September 27, 2014 4:34:19 PM UTC+10, kurofune wrote:

 I am an looking for a good, active, open source Clojure library/project to 
 contribute to, but am not sure where to start. Could somebody give an 
 intermediate level programmer a  few pointers as to where to begin? 


-- 
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 this a reasonable use of core.async?

[Beau Fabry]

Yeah Dan Thomas's code is an awesome example for anyone looking to solve a 
similar solution with variable load. In my case this is a predictable batch 
process and I know the load exactly :-) I ended up implementing the futures 
approach for the reasons you listed, as it was our only use of core.async 
and now it's gone from our dependencies :-)

On Thursday, September 18, 2014 6:11:24 PM UTC+10, Dan Kersten wrote:

 I personally think Thomas' is best if load may vary as it is more 
 predictable and straightforward to understand. If we're talking about line 
 code, here's a shortened version that I don't feel sacrifices readability 
 (typed on a phone so please excuse typos...):

 (let [exec (Executors newFixedThreadPool 4)
results (- widgets
 (mapv (fn [it] (.submit exec 
 #(long-running-widget-processor it
(mapv #(.get %)))]
   (.shutdown exec)
   results)

 I think the pure futures version kinda like what Gary suggested is best 
 though because it's straightforward, to the point, idiomatic and you 
 eliminate the need for core.async.

 Having said that,  if you are already using core.async elsewhere in your 
 project then I don't see anything particularly wrong with your way.
  On 18 Sep 2014 06:41, Beau Fabry imf...@gmail.com javascript: 
 wrote:

 Larry your solution includes the cognitive overhead of another entire 
 library and process model. future is part of core, and as I realised when 
 Gary posted the doall's were unnecessary anyway.

 On Thursday, September 18, 2014 3:26:36 PM UTC+10, larry google groups 
 wrote:


  Thanks for that Larry but I think this is a bit of overkill for my 
 scenario.

 If I'm counting correctly, your original example has 10 lines of code, 
 and my example has 11 lines of code (minus the try/catch and the closure 
 and the namespace declaration). So these 2 solutions are the same length. 
 These are the 11 lines of code: 

 (def ^:private persistence-channel (lamina/channel))

 (defn persist-this-item [context-wrapper-for-database-call]
   (lamina/enqueue persistence-channel
   (fn [] (persistence/make-consistent 
 context-wrapper-for-database-call

 (defn worker []
   (loop [closure-with-item-inside @(lamina/read-channel 
 persistence-channel)]
  (closure-with-item-inside)
 (recur @(lamina/read-channel persistence-channel

 (defn start-workers []
   (dotimes [_ 6]
 (future (worker

 Maybe its just that I'm familiar with the code, but these 11 lines of 
 code seem cleaner to me than your 10 lines of code, at least in part 
 because you are doing stuff like calling (doall) which strikes me as a bit 
 suspicious. 

 Do you really feel the 1 extra line of code is overkill? This solution 
 seems to do what you want, and it's the same length as your solution. 





 On Wednesday, September 17, 2014 8:48:09 PM UTC-4, Beau Fabry wrote:

 Thanks for that Larry but I think this is a bit of overkill for my 
 scenario. The code I pasted is almost verbatim what we have in our 
 production codebase, so the ability to queue new jobs etc is really not 
 needed. Cheers though.

 On Thursday, September 18, 2014 9:38:47 AM UTC+10, larry google groups 
 wrote:


  We don't have streams of data here, the long running tasks have 
 side-effects. I would 
  prefer to avoid adding another whole framework just to run a few 
 long running jobs in p//. 


 I guess I should show you some code, so you can see how simple this 
 is. I'll copy-and-paste some code that I use. 

 One simple way I use Lamina is to save stuff to a database. I don't 
 want the save action happening in my main thread, so I put the data in 
 a 
 channel, and I let some workers pull that data off the channel and put it 
 in the database. So what follows is the whole file, this about 30 lines 
 of 
 code, including some try/catch stuff that you probably don't need: 

 (ns loupi.persistence-queue
   (:require
[loupi.persistence :as persistence]
[slingshot.slingshot :as ss]
[lamina.core :as lamina]))

 (def ^:private persistence-channel (lamina/channel))

 (defn persist-this-item [context-wrapper-for-database-call]
   (lamina/enqueue persistence-channel
   (fn []
 (ss/try+ 
  (persistence/make-consistent 
 context-wrapper-for-database-call)
  (catch Object o (ss/throw+ {:type 
 :loupi.supervisor/problem
  :message Error in 
 persistence-queue/persist-this-itme.
  :data o}))

 (defn worker []
   (loop [closure-with-item-inside @(lamina/read-channel 
 persistence-channel)]
 (ss/try+ 
  (closure-with-item-inside)
  (catch Object o (ss/throw+ {:type :loupi.supervisor/problem
  :message Error in 
 persistence-queue/worker.
  :closure closure-with-item-inside

Re: Is this a reasonable use of core.async?

[Beau Fabry]

pmap isn't an option as the processes kicked off could affect other systems 
load if we can't control the level of parallelization. futures seem like 
they'd work quite well (the return value of the jobs is nil, it's a doseq). 
I might rewrite it with futures at some point. Although it really just 
seems like a slightly cleaner way of doing exactly what I did with 
core.async :-)

Thanks Gary!

On Wednesday, September 17, 2014 5:31:34 PM UTC+10, Gary Verhaegen wrote:

 Sounds like a job for a future. Something like:

 (- job-list
   (partition-in-sublists 4)
   (map #(future (do-job-on-sublist %)))
   (mapv deref))

 This is untested and written on a phone, so might not even be 
 syntactically correct, but the future calls will create new threds to 
 execute the do-job functions on the sublists, and the deref call on a 
 future is blocking. If the result from the futures is not important, I 
 guess you could save some memory by using map and doall instead of mapv, 
 though I doubt it would make any difference if you have only 4 sublists.

 Alternatively, have you looked at pmap ?

 On Wednesday, 17 September 2014, Beau Fabry imf...@gmail.com 
 javascript: wrote:

 We don't have streams of data here, the long running tasks have 
 side-effects. I would prefer to avoid adding another whole framework just 
 to run a few long running jobs in p//. 

 I have a list of jobs to do, I'm partitioning that list up into 4 sub 
 lists to be worked through by 4 p// workers, I then want to block and wait 
 until all 4 workers have finished their tasks. 

 On Wednesday, September 17, 2014 3:27:07 AM UTC+10, larry google groups 
 wrote:


 This does not look correct to me. Perhaps someone else has more insight 
 into this. I am suspicious about 2 things: 

 1.) your use of doall

 2.) your use of (thread) 

 It looks to me like you are trying to hack together a kind of pipeline 
 or channel. Clojure has a wealth of libraries that can handle that for you. 
 The main thing you are trying to do is this:

 (long-running-widget-processor widget))


 You go to some trouble to set up workers, all to ensure that 
 long-running-widget-processor is handled in its own thread. 

 I would suggest you look at Lamina:

 https://github.com/ztellman/lamina

 In particular, look at pipelines:

 https://github.com/ztellman/lamina/wiki/Pipelines





 On Friday, September 5, 2014 1:46:02 AM UTC-4, Beau Fabry wrote:

 Is the kinda ugly  constant (doall usage a sign that I'm doing 
 something silly?

 (let [num-workers 4
   widgets-per-worker (inc (int (/ (count widgets) num-workers)))
   bucketed-widgets (partition-all widgets-per-worker widgets)
   workers (doall (map (fn [widgets]
   (thread
 (doseq [widget widgets]
   (long-running-widget-processor widget))
 true))
bucketed-widgets))]
   (doall (map !! workers)))

 https://gist.github.com/bfabry/ad830b1888e4fc550f88

 All comments appreciated :-)

 Cheers,
 Beau

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



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

Re: Is this a reasonable use of core.async?

[Beau Fabry]

Thanks for that Larry but I think this is a bit of overkill for my 
scenario. The code I pasted is almost verbatim what we have in our 
production codebase, so the ability to queue new jobs etc is really not 
needed. Cheers though.

On Thursday, September 18, 2014 9:38:47 AM UTC+10, larry google groups 
wrote:


  We don't have streams of data here, the long running tasks have 
 side-effects. I would 
  prefer to avoid adding another whole framework just to run a few long 
 running jobs in p//. 


 I guess I should show you some code, so you can see how simple this is. 
 I'll copy-and-paste some code that I use. 

 One simple way I use Lamina is to save stuff to a database. I don't want 
 the save action happening in my main thread, so I put the data in a 
 channel, and I let some workers pull that data off the channel and put it 
 in the database. So what follows is the whole file, this about 30 lines of 
 code, including some try/catch stuff that you probably don't need: 

 (ns loupi.persistence-queue
   (:require
[loupi.persistence :as persistence]
[slingshot.slingshot :as ss]
[lamina.core :as lamina]))

 (def ^:private persistence-channel (lamina/channel))

 (defn persist-this-item [context-wrapper-for-database-call]
   (lamina/enqueue persistence-channel
   (fn []
 (ss/try+ 
  (persistence/make-consistent 
 context-wrapper-for-database-call)
  (catch Object o (ss/throw+ {:type 
 :loupi.supervisor/problem
  :message Error in 
 persistence-queue/persist-this-itme.
  :data o}))

 (defn worker []
   (loop [closure-with-item-inside @(lamina/read-channel 
 persistence-channel)]
 (ss/try+ 
  (closure-with-item-inside)
  (catch Object o (ss/throw+ {:type :loupi.supervisor/problem
  :message Error in 
 persistence-queue/worker.
  :closure closure-with-item-inside
  :data o})))
 (recur @(lamina/read-channel persistence-channel

 (defn start-workers []
   (dotimes [_ 6]
 (println Starting up the persist queue workers.)
 (future (worker



 I call (start-workers) when the app starts. When I save something to the 
 database, I call (persist-this-item) and I put a closure on the channel. 
 The workers eventually grab that closure and execute it. 

 Clearly, that closure can do whatever you like. To borrow from your 
 original example, that closure is where you would put: 

   (long-running-widget-processor widget)








 On Tuesday, September 16, 2014 10:00:07 PM UTC-4, Beau Fabry wrote:

 We don't have streams of data here, the long running tasks have 
 side-effects. I would prefer to avoid adding another whole framework just 
 to run a few long running jobs in p//. 

 I have a list of jobs to do, I'm partitioning that list up into 4 sub 
 lists to be worked through by 4 p// workers, I then want to block and wait 
 until all 4 workers have finished their tasks. 

 On Wednesday, September 17, 2014 3:27:07 AM UTC+10, larry google groups 
 wrote:


 This does not look correct to me. Perhaps someone else has more insight 
 into this. I am suspicious about 2 things: 

 1.) your use of doall

 2.) your use of (thread) 

 It looks to me like you are trying to hack together a kind of pipeline 
 or channel. Clojure has a wealth of libraries that can handle that for you. 
 The main thing you are trying to do is this:

 (long-running-widget-processor widget))


 You go to some trouble to set up workers, all to ensure that 
 long-running-widget-processor 
 is handled in its own thread. 

 I would suggest you look at Lamina:

 https://github.com/ztellman/lamina

 In particular, look at pipelines:

 https://github.com/ztellman/lamina/wiki/Pipelines





 On Friday, September 5, 2014 1:46:02 AM UTC-4, Beau Fabry wrote:

 Is the kinda ugly  constant (doall usage a sign that I'm doing 
 something silly?

 (let [num-workers 4
   widgets-per-worker (inc (int (/ (count widgets) num-workers)))
   bucketed-widgets (partition-all widgets-per-worker widgets)
   workers (doall (map (fn [widgets]
   (thread
 (doseq [widget widgets]
   (long-running-widget-processor widget))
 true))
bucketed-widgets))]
   (doall (map !! workers)))

 https://gist.github.com/bfabry/ad830b1888e4fc550f88

 All comments appreciated :-)

 Cheers,
 Beau



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

Re: Is this a reasonable use of core.async?

[Beau Fabry]

Larry your solution includes the cognitive overhead of another entire 
library and process model. future is part of core, and as I realised when 
Gary posted the doall's were unnecessary anyway.

On Thursday, September 18, 2014 3:26:36 PM UTC+10, larry google groups 
wrote:


  Thanks for that Larry but I think this is a bit of overkill for my 
 scenario.

 If I'm counting correctly, your original example has 10 lines of code, and 
 my example has 11 lines of code (minus the try/catch and the closure and 
 the namespace declaration). So these 2 solutions are the same length. These 
 are the 11 lines of code: 

 (def ^:private persistence-channel (lamina/channel))

 (defn persist-this-item [context-wrapper-for-database-call]
   (lamina/enqueue persistence-channel
   (fn [] (persistence/make-consistent 
 context-wrapper-for-database-call

 (defn worker []
   (loop [closure-with-item-inside @(lamina/read-channel 
 persistence-channel)]
  (closure-with-item-inside)
 (recur @(lamina/read-channel persistence-channel

 (defn start-workers []
   (dotimes [_ 6]
 (future (worker

 Maybe its just that I'm familiar with the code, but these 11 lines of code 
 seem cleaner to me than your 10 lines of code, at least in part because you 
 are doing stuff like calling (doall) which strikes me as a bit suspicious. 

 Do you really feel the 1 extra line of code is overkill? This solution 
 seems to do what you want, and it's the same length as your solution. 





 On Wednesday, September 17, 2014 8:48:09 PM UTC-4, Beau Fabry wrote:

 Thanks for that Larry but I think this is a bit of overkill for my 
 scenario. The code I pasted is almost verbatim what we have in our 
 production codebase, so the ability to queue new jobs etc is really not 
 needed. Cheers though.

 On Thursday, September 18, 2014 9:38:47 AM UTC+10, larry google groups 
 wrote:


  We don't have streams of data here, the long running tasks have 
 side-effects. I would 
  prefer to avoid adding another whole framework just to run a few long 
 running jobs in p//. 


 I guess I should show you some code, so you can see how simple this is. 
 I'll copy-and-paste some code that I use. 

 One simple way I use Lamina is to save stuff to a database. I don't want 
 the save action happening in my main thread, so I put the data in a 
 channel, and I let some workers pull that data off the channel and put it 
 in the database. So what follows is the whole file, this about 30 lines of 
 code, including some try/catch stuff that you probably don't need: 

 (ns loupi.persistence-queue
   (:require
[loupi.persistence :as persistence]
[slingshot.slingshot :as ss]
[lamina.core :as lamina]))

 (def ^:private persistence-channel (lamina/channel))

 (defn persist-this-item [context-wrapper-for-database-call]
   (lamina/enqueue persistence-channel
   (fn []
 (ss/try+ 
  (persistence/make-consistent 
 context-wrapper-for-database-call)
  (catch Object o (ss/throw+ {:type 
 :loupi.supervisor/problem
  :message Error in 
 persistence-queue/persist-this-itme.
  :data o}))

 (defn worker []
   (loop [closure-with-item-inside @(lamina/read-channel 
 persistence-channel)]
 (ss/try+ 
  (closure-with-item-inside)
  (catch Object o (ss/throw+ {:type :loupi.supervisor/problem
  :message Error in 
 persistence-queue/worker.
  :closure closure-with-item-inside
  :data o})))
 (recur @(lamina/read-channel persistence-channel

 (defn start-workers []
   (dotimes [_ 6]
 (println Starting up the persist queue workers.)
 (future (worker



 I call (start-workers) when the app starts. When I save something to the 
 database, I call (persist-this-item) and I put a closure on the channel. 
 The workers eventually grab that closure and execute it. 

 Clearly, that closure can do whatever you like. To borrow from your 
 original example, that closure is where you would put: 

   (long-running-widget-processor widget)








 On Tuesday, September 16, 2014 10:00:07 PM UTC-4, Beau Fabry wrote:

 We don't have streams of data here, the long running tasks have 
 side-effects. I would prefer to avoid adding another whole framework just 
 to run a few long running jobs in p//. 

 I have a list of jobs to do, I'm partitioning that list up into 4 sub 
 lists to be worked through by 4 p// workers, I then want to block and wait 
 until all 4 workers have finished their tasks. 

 On Wednesday, September 17, 2014 3:27:07 AM UTC+10, larry google groups 
 wrote:


 This does not look correct to me. Perhaps someone else has more 
 insight into this. I am suspicious about 2 things: 

 1.) your use of doall

 2.) your use of (thread) 

 It looks to me like you

Re: Is this a reasonable use of core.async?

[Beau Fabry]

We don't have streams of data here, the long running tasks have 
side-effects. I would prefer to avoid adding another whole framework just 
to run a few long running jobs in p//. 

I have a list of jobs to do, I'm partitioning that list up into 4 sub lists 
to be worked through by 4 p// workers, I then want to block and wait until 
all 4 workers have finished their tasks. 

On Wednesday, September 17, 2014 3:27:07 AM UTC+10, larry google groups 
wrote:


 This does not look correct to me. Perhaps someone else has more insight 
 into this. I am suspicious about 2 things: 

 1.) your use of doall

 2.) your use of (thread) 

 It looks to me like you are trying to hack together a kind of pipeline or 
 channel. Clojure has a wealth of libraries that can handle that for you. 
 The main thing you are trying to do is this:

 (long-running-widget-processor widget))


 You go to some trouble to set up workers, all to ensure that 
 long-running-widget-processor 
 is handled in its own thread. 

 I would suggest you look at Lamina:

 https://github.com/ztellman/lamina

 In particular, look at pipelines:

 https://github.com/ztellman/lamina/wiki/Pipelines





 On Friday, September 5, 2014 1:46:02 AM UTC-4, Beau Fabry wrote:

 Is the kinda ugly  constant (doall usage a sign that I'm doing something 
 silly?

 (let [num-workers 4
   widgets-per-worker (inc (int (/ (count widgets) num-workers)))
   bucketed-widgets (partition-all widgets-per-worker widgets)
   workers (doall (map (fn [widgets]
   (thread
 (doseq [widget widgets]
   (long-running-widget-processor widget))
 true))
bucketed-widgets))]
   (doall (map !! workers)))

 https://gist.github.com/bfabry/ad830b1888e4fc550f88

 All comments appreciated :-)

 Cheers,
 Beau



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

Is this a reasonable use of core.async?

[Beau Fabry]

Is the kinda ugly  constant (doall usage a sign that I'm doing something 
silly?

(let [num-workers 4
  widgets-per-worker (inc (int (/ (count widgets) num-workers)))
  bucketed-widgets (partition-all widgets-per-worker widgets)
  workers (doall (map (fn [widgets]
  (thread
(doseq [widget widgets]
  (long-running-widget-processor widget))
true))
   bucketed-widgets))]
  (doall (map !! workers)))

https://gist.github.com/bfabry/ad830b1888e4fc550f88

All comments appreciated :-)

Cheers,
Beau

-- 
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] Gorilla REPL 0.3.3 - inline docs, CIDER compatibility

[Beau Fabry]

A client library may be another option, I haven't looked into it. Off the 
top of my head I doubt the cascalog code distribution for the m/r jobs 
would work with any clients. This is akin to deploying new code to run on 
the cluster, in this case via a repl, so I don't think any existing API is 
going to support it. You could certainly connect a client that runs PIG 
jobs or something, but that's a lot less powerful than being able to 
distribute just-defined clojure functions out to the cluster as map 
operations on the fly :-)

Sort've like the difference between being able to connect to postgres via 
odbc and run sql, and spinning up a repl inside of postgres that can 
dynamically define functions that play with the raw data

On Wednesday, September 3, 2014 12:08:52 AM UTC+10, Jony Hudson wrote:

 On Tuesday, 2 September 2014 01:36:49 UTC+1, Beau Fabry wrote:

 Just a little bit of showing off of the previous post :-) 
 http://i.imgur.com/zpfP9Ja.png


 Nice! Would love to hear more about how you use it. I've only tinkered 
 with Hadoop locally, so I'm very fuzzy on the concepts - you need to run 
 Gorilla in-process on one of the hadoop nodes, rather than connecting to 
 hadoop with a client library?


 Jony


-- 
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: Useless Java error messages

[Beau Fabry]

apologies, not a leiningen plugin. https://github.com/AvisoNovate/pretty

On Wednesday, September 3, 2014 2:17:21 AM UTC+10, John Gabriele wrote:

 On Monday, September 1, 2014 7:24:54 PM UTC-4, Beau Fabry wrote:

 The pretty-errors leiningen plugin might be worth a look


 Hm... I don't see that particular plug-in in the [main lein plug-in list](
 https://github.com/technomancy/leiningen/wiki/Plugins).

 Do you mean [clj-stacktrace](https://github.com/mmcgrana/clj-stacktrace)? 
 (not a lein plug-in)



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

Re: Using an atom for a caching map

[Beau Fabry]

Indeed you're right, I was confused. The dosync call was a naive attempt to 
avoid the CAS operation you were worried about earlier. I suppose another 
option would be to use compare-and-set! with a lazy seq.

(compare-and-set! cache-atom (dissoc @cache-atom k) (assoc @cache-atom k 
(lazy-seq (cons (expensive k) '()
(first (@cache-atom k))

On Monday, September 1, 2014 7:10:52 PM UTC+10, Colin Fleming wrote:

 Hi Beau,

 I've not used the STM stuff at all, but my understanding is that dosync is 
 intended for co-ordinated updates to refs, and has no effect on atoms. It's 
 really intended for co-ordinating updates to multiple refs rather than as a 
 synchronisation primitive on a single entity. I might be wrong though, as I 
 say I've never used it.

 Cheers,
 Colin


 On 31 August 2014 00:58, Beau Fabry imf...@gmail.com javascript: 
 wrote:

 I must be missing something, because this is too simple?

 (defn get-maybe-cached [cache key]
   (dosync
 (if-let [v (get @cache key)]
   v
   (do
 (reset! cache (assoc @cache key (calculate key)))
 (get @cache key)


 On Saturday, August 30, 2014 3:27:05 PM UTC+10, Colin Fleming wrote:

 Hi all,

 I want to use a map to cache values based on a key. I'm planning to use 
 an atom for this. My basic operation is give me the value for this key - 
 if the value exists in the map then that value should be returned, 
 otherwise a new value should be calculated, inserted in the map and then 
 returned. My plan is to implement something like the following:


 (defn ensure [cache key]  (if (contains? cache key)cache(assoc 
 cache key (calc-value key(let [value (get (swap! cache ensure key) 
 key)]  ... do my thing with value ...)


 So 'ensure' ensures that the cache contains the value for key, the swap! 
 operation returns the cache with the value and then I get it out. This 
 works but feels a little clumsy, is there a better way to do this?

 Also, looking at the Atom source code, I see that this will cause a CAS 
 operation even if the value returned from swap! is identical to the 
 original value. It seems like a reasonable optimisation would be to check 
 if the values are identical and not update if so - is there a reason this 
 might not be a good idea?

 Thanks,
 Colin

  -- 
 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: [ANN] Gorilla REPL 0.3.3 - inline docs, CIDER compatibility

[Beau Fabry]

Started looking into Gorilla for use at work today. Even prior to this 
release I was incredibly impressed. Amazing work everyone involved.
 

On Monday, September 1, 2014 9:12:49 PM UTC+10, Jony Hudson wrote:

 Ohh, and there are some new docs on how to use Gorilla alongside your 
 favourite editor/IDE:

 http://gorilla-repl.org/editors.html


 Jony


-- 
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: Useless Java error messages

[Beau Fabry]

The pretty-errors leiningen plugin might be worth a look

On Tuesday, September 2, 2014 7:58:31 AM UTC+10, g vim wrote:

 On 01/09/2014 17:50, Luc Prefontaine wrote: 
  Where do you see a Java error here ? 
  
  I see the Clojure implementation 
  reporting that you are 
  trying to apply a numeric operator 
  to a null/nil value :) 
  
  I agree the JVM stack traces are not nice 
  and polluted by all the frames which 
  may/may not be relevant. 
  
  The messages are not always as clear as 
  this one either. 
  
  You do not have any source file 
  line number anywhere in the stack 
  trace pointing to your code ? 
  
  Luc P. 
  

 Sorry, I was a bit trigger-happy with this one. Turns out it was Emacs 
 cider truncating the stack trace to a single line. Someone on IRC 
 pointed me to `(pst)` within Emacs cider which displays the full stack 
 trace. 

 gvim 


-- 
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] Gorilla REPL 0.3.3 - inline docs, CIDER compatibility

[Beau Fabry]

For what it's worth we're using Gorilla *after* leiningen. Leiningen is 
used to make an uberjar, but then we start the gorilla server in our own 
main. This is because we're running gorilla inside of our hadoop 
environment. This way we have a gorilla instance that can issue live 
cascalog queries to the cluster :-)

On Tuesday, September 2, 2014 7:26:51 AM UTC+10, stuart@gmail.com wrote:

 Hi Jony,

 I sent you a pull request.  I believe adding those items is correct and 
 necessary for producing a usable JAR, and that the build works so long as 
 you have a recent version of leiningen.

 Stu


 On Mon, Sep 1, 2014 at 5:04 PM, Jony Hudson jonye...@gmail.com 
 javascript: wrote:

 Ahh, nice, yes that's a simple way to do it if you can manage to add the 
 code somewhere.

 Regarding the dependencies - Leiningen adds both of the dependencies you 
 list. I did declare them explicitly at one point, but I recall having some 
 odd error, so I decided to take them back out rather than debug it! It's 
 possibly related to this, but like I say I didn't put any time into 
 investigating it, so could be a red herring: 
 https://github.com/technomancy/leiningen/issues/1569


 Jony


 On Monday, 1 September 2014 21:57:07 UTC+1, stuart@gmail.com wrote:

 And now, answering part of my own question.  It appears the following 
 almost just works from a maven project that references gorilla:

   (require '[gorilla-repl.core :as gorilla])
   (gorilla/run-gorilla-server {:port 8990})

 The only problem is that gorilla's declaration of its own dependencies 
 appears incomplete.  When I try to run the snippet above, I fail for lack 
 of org.clojure/tools.nrepl and clojure-complete.  Adding them as explicit 
 dependencies in my own project fixes the problem.  My quick guess is that 
 these two libs need to be added to gorilla's own dependencies.  (One 
 wonders why it works inside of lein...)

 Stu

  -- 
 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: [ANN] Gorilla REPL 0.3.3 - inline docs, CIDER compatibility

[Beau Fabry]

Just a little bit of showing off of the previous post 
:-) http://i.imgur.com/zpfP9Ja.png

On Tuesday, September 2, 2014 9:36:50 AM UTC+10, Beau Fabry wrote:

 For what it's worth we're using Gorilla *after* leiningen. Leiningen is 
 used to make an uberjar, but then we start the gorilla server in our own 
 main. This is because we're running gorilla inside of our hadoop 
 environment. This way we have a gorilla instance that can issue live 
 cascalog queries to the cluster :-)

 On Tuesday, September 2, 2014 7:26:51 AM UTC+10, stuart@gmail.com 
 wrote:

 Hi Jony,

 I sent you a pull request.  I believe adding those items is correct and 
 necessary for producing a usable JAR, and that the build works so long as 
 you have a recent version of leiningen.

 Stu


 On Mon, Sep 1, 2014 at 5:04 PM, Jony Hudson jonye...@gmail.com wrote:

 Ahh, nice, yes that's a simple way to do it if you can manage to add the 
 code somewhere.

 Regarding the dependencies - Leiningen adds both of the dependencies you 
 list. I did declare them explicitly at one point, but I recall having some 
 odd error, so I decided to take them back out rather than debug it! It's 
 possibly related to this, but like I say I didn't put any time into 
 investigating it, so could be a red herring: 
 https://github.com/technomancy/leiningen/issues/1569


 Jony


 On Monday, 1 September 2014 21:57:07 UTC+1, stuart@gmail.com wrote:

 And now, answering part of my own question.  It appears the following 
 almost just works from a maven project that references gorilla:

   (require '[gorilla-repl.core :as gorilla])
   (gorilla/run-gorilla-server {:port 8990})

 The only problem is that gorilla's declaration of its own dependencies 
 appears incomplete.  When I try to run the snippet above, I fail for lack 
 of org.clojure/tools.nrepl and clojure-complete.  Adding them as explicit 
 dependencies in my own project fixes the problem.  My quick guess is that 
 these two libs need to be added to gorilla's own dependencies.  (One 
 wonders why it works inside of lein...)

 Stu

  -- 
 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: Macro that modifies the body of a function

[Beau Fabry]

This isn't a multimethod, it's a multiple-arity function. Anyway, you just 
need to detect that someone has tried to define a multiple arity method and 
change your definition accordingly. Something like below. I haven't 
actually tried this code so it's almost definitely wrong but you get the 
gist.

(defmacro deftry [ definition]
  (if (vec? (second definition))
(let [[name args  body] definition]
`(defn ~name ~args
   (try ~@body
 (catch Error e#
   (println error caught: e#)
(let [[name  definitions] definition]
  `(defn ~name ~@(map (fn [[args body]] `(~args (try ~@body (catch 
Error e# (println err caught)
  definitions)


On Sunday, August 31, 2014 8:26:12 PM UTC+10, Yehonathan Sharvit wrote:

 I tried to write a macro that wraps the code a function with a try/catch 
 statement. It works fine for regular functions but it doesn't work for 
 multimethods.  I understand the reason, but I don't know how to fix it. 

 Here is my code:

 (defmacro deftry [name args  body] 
 https://groups.google.com/forum/#!topic/clojurescript/To0AnQVC3lg;
   `(defn ~name ~args
  (try ~@body
(catch Error e#
  (println error caught: e#)


 Usage:
 1. regular function = it works fine

 (deftry foo []
   (throw (Error. foo)))


 2. multimethods = it breaks
 (deftry foo 
 ([a] 3)
 ([] 5))

  

-- 
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: Macro that modifies the body of a function

[Beau Fabry]

 I am impressed that you were able to write a macro without any repl...

Pretty amazed myself. Never seems to happen when it's code that I'm trying 
to write for myself :-)

On Monday, September 1, 2014 12:06:45 AM UTC+10, Yehonathan Sharvit wrote:

 Thanks a lot Beau.

 Your code almost worked.

 This is the working code -- you just forgot the '' between args and body 
 :)  
 I am impressed that you were able to write a macro without any repl...



 (defmacro deftry [ definition]
   (if (vector? (second definition))
 (let [[name args  body] definition]
   `(defn ~name ~args
  (try ~@body
(catch Error e#
  (println error caught: e#)
 (let [[name  definitions] definition]
   `(defn ~name ~@(map (fn [[args  body]] `(~args (try ~@body (catch 
 Error e# (println err caught e#)
   definitions)








 On Sunday, 31 August 2014 13:56:03 UTC+3, Beau Fabry wrote:

 This isn't a multimethod, it's a multiple-arity function. Anyway, you 
 just need to detect that someone has tried to define a multiple arity 
 method and change your definition accordingly. Something like below. I 
 haven't actually tried this code so it's almost definitely wrong but you 
 get the gist.

 (defmacro deftry [ definition]
   (if (vec? (second definition))
 (let [[name args  body] definition]
 `(defn ~name ~args
(try ~@body
  (catch Error e#
(println error caught: e#)
 (let [[name  definitions] definition]
   `(defn ~name ~@(map (fn [[args body]] `(~args (try ~@body (catch 
 Error e# (println err caught)
   definitions)


 On Sunday, August 31, 2014 8:26:12 PM UTC+10, Yehonathan Sharvit wrote:

 I tried to write a macro that wraps the code a function with a try/catch 
 statement. It works fine for regular functions but it doesn't work for 
 multimethods.  I understand the reason, but I don't know how to fix it. 

 Here is my code:

 (defmacro deftry [name args  body] 
 https://groups.google.com/forum/#!topic/clojurescript/To0AnQVC3lg;
   `(defn ~name ~args
  (try ~@body
(catch Error e#
  (println error caught: e#)


 Usage:
 1. regular function = it works fine

 (deftry foo []
   (throw (Error. foo)))


 2. multimethods = it breaks
 (deftry foo 
 ([a] 3)
 ([] 5))

  

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

Re: Using an atom for a caching map

[Beau Fabry]

I must be missing something, because this is too simple?

(defn get-maybe-cached [cache key]
  (dosync
(if-let [v (get @cache key)]
  v
  (do
(reset! cache (assoc @cache key (calculate key)))
(get @cache key)

On Saturday, August 30, 2014 3:27:05 PM UTC+10, Colin Fleming wrote:

 Hi all,

 I want to use a map to cache values based on a key. I'm planning to use an 
 atom for this. My basic operation is give me the value for this key - if 
 the value exists in the map then that value should be returned, otherwise a 
 new value should be calculated, inserted in the map and then returned. My 
 plan is to implement something like the following:


 (defn ensure [cache key]  (if (contains? cache key)cache(assoc cache 
 key (calc-value key(let [value (get (swap! cache ensure key) key)]  ... 
 do my thing with value ...)


 So 'ensure' ensures that the cache contains the value for key, the swap! 
 operation returns the cache with the value and then I get it out. This 
 works but feels a little clumsy, is there a better way to do this?

 Also, looking at the Atom source code, I see that this will cause a CAS 
 operation even if the value returned from swap! is identical to the 
 original value. It seems like a reasonable optimisation would be to check 
 if the values are identical and not update if so - is there a reason this 
 might not be a good idea?

 Thanks,
 Colin


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