[ANN] Shrubbery 0.2.0, a stubbing, spying, and mocking library for Clojure protocols

[Glen Mailer]

This looks neat Brian!

People who find this useful may also like a similar lib I wrote that provides 
mocking tools at a single function level: https://github.com/glenjamin/q

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

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

[Tassilo Horn]

Luc Prefontaine  writes:

> There's a better 'fix'. 
> Run your builds on SSDs or on a memory based file system.

"Performance problems are solved best by throwing more hardware at
them."  Seriously?!

No, I completely agree with Bozhidar in that regular bugfix releases
would be a good thing.  Clojure releases already have a minor version,
so we might as well use it.

Bye,
Tassilo

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

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

[Luc Prefontaine]

There's a better 'fix'. 
Run your builds on SSDs or on a memory based file system.

With the RAM available these days, any build can be done on a memory based file 
system.

It speeds up every step by a huge factor. Not only compilation.

You only need to copy your targets
to a 'permanent' place.

We have been doing this for years to shrink build times. We AOT most of our 
code base.

Luc P.

> I'll just say one more time that the team should really consider doing
> bug-fix releases in the future. This problem sounds serious enough to be
> handled as quickly as possible. Clojure 1.6 was released over one year ago,
> so I'm guessing 1.8 is more than a year away from now. Waiting for major
> releases for a bug fix in not exactly the greatest user experience.
> 
> On 9 May 2015 at 05:18, Alexander Hudek  wrote:
> 
> > I'd like to chime in here in support of this, our company has been running
> > a modified clojure build because of this for over a year now.
> >
> > Alex
> >
> >
> > On Friday, May 8, 2015 at 2:12:50 PM UTC-4, Martin Raison wrote:
> >>
> >> Hi all,
> >>
> >> This issue has been around for a while without much activity, although a
> >> very simple fix is already there:
> >> http://dev.clojure.org/jira/browse/CLJ-703
> >>
> >> We have a pretty big Clojure project that we compile on machines with
> >> slow hard-drives, on CentOS 6. We noticed that compilation had become
> >> extremely slow, however CPU usage was always below 10%.
> >>
> >> Simply removing the line "cfs.getFD().sync();" inside 
> >> "src/jvm/clojure/lang/Compiler.java"
> >> dramatically improved the compilation time (Something like 10x, although at
> >> this level of increase, measurement almost doesn't make sense anymore :)).
> >>
> >> We've been using the suggested fix (remove-sync-only.patch) for a few
> >> weeks and haven't observed any issues.
> >>
> >> It seems we should really figure out whether this line is actually
> >> necessary, or if it was added there "just in case". Even if some situations
> >> require it, the speed bump is so huge that we might want some special-case
> >> logic.
> >>
> >> Martin
> >>
> >  --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> 
> -- 
> 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.
> 
--
Luc Prefontaine sent by ibisMail!

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

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

[Bozhidar Batsov]

I'll just say one more time that the team should really consider doing
bug-fix releases in the future. This problem sounds serious enough to be
handled as quickly as possible. Clojure 1.6 was released over one year ago,
so I'm guessing 1.8 is more than a year away from now. Waiting for major
releases for a bug fix in not exactly the greatest user experience.

On 9 May 2015 at 05:18, Alexander Hudek  wrote:

> I'd like to chime in here in support of this, our company has been running
> a modified clojure build because of this for over a year now.
>
> Alex
>
>
> On Friday, May 8, 2015 at 2:12:50 PM UTC-4, Martin Raison wrote:
>>
>> Hi all,
>>
>> This issue has been around for a while without much activity, although a
>> very simple fix is already there:
>> http://dev.clojure.org/jira/browse/CLJ-703
>>
>> We have a pretty big Clojure project that we compile on machines with
>> slow hard-drives, on CentOS 6. We noticed that compilation had become
>> extremely slow, however CPU usage was always below 10%.
>>
>> Simply removing the line "cfs.getFD().sync();" inside 
>> "src/jvm/clojure/lang/Compiler.java"
>> dramatically improved the compilation time (Something like 10x, although at
>> this level of increase, measurement almost doesn't make sense anymore :)).
>>
>> We've been using the suggested fix (remove-sync-only.patch) for a few
>> weeks and haven't observed any issues.
>>
>> It seems we should really figure out whether this line is actually
>> necessary, or if it was added there "just in case". Even if some situations
>> require it, the speed bump is so huge that we might want some special-case
>> logic.
>>
>> Martin
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Alexander Hudek]

I'd like to chime in here in support of this, our company has been running 
a modified clojure build because of this for over a year now.

Alex

On Friday, May 8, 2015 at 2:12:50 PM UTC-4, Martin Raison wrote:
>
> Hi all,
>
> This issue has been around for a while without much activity, although a 
> very simple fix is already there: 
> http://dev.clojure.org/jira/browse/CLJ-703
>
> We have a pretty big Clojure project that we compile on machines with slow 
> hard-drives, on CentOS 6. We noticed that compilation had become extremely 
> slow, however CPU usage was always below 10%.
>
> Simply removing the line "cfs.getFD().sync();" inside 
> "src/jvm/clojure/lang/Compiler.java" 
> dramatically improved the compilation time (Something like 10x, although at 
> this level of increase, measurement almost doesn't make sense anymore :)).
>
> We've been using the suggested fix (remove-sync-only.patch) for a few 
> weeks and haven't observed any issues.
>
> It seems we should really figure out whether this line is actually 
> necessary, or if it was added there "just in case". Even if some situations 
> require it, the speed bump is so huge that we might want some special-case 
> logic.
>
> Martin
>

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

Re: [ANN] Bocko 0.2.0

[David Sargeant]

I guess HLIN and VLIN have a historical significance.  Still kind of 
confusing, but I understand now how you arrived at those names. 

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

[David Sargeant]

Looks like fun. I would change `hlin` to `hline` and `vlin` to `vline`. 
It's only one more character to type, but much clearer to read.

-- 
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 goeth the STM experiment?

[piastkrakow]

This seems to be true:

"I would have to say that the biggest surprise is how little they're needed 
in Clojure."

Run this search on Google: 

agent send clojure site:github.com

The first 5 pages point me to examples from several years ago, or error 
reports, or unit tests. Nothing substantial or recent. I think it is 
interesting how many of the results are blog posts or gists -- people talk 
about agents much more then they actually use them. 

Still, there are some examples: 

https://github.com/aphyr/riemann/blob/302cff942f308771b1d8d837cdf9ce2c9090daed/src/riemann/pool.clj

(defmacro with-pool "Evaluates body in a try expression with a symbol 
'thingy claimed from the given pool, with specified claim timeout. Releases 
thingy at the end of the body, or if an exception is thrown, invalidates 
them and rethrows. Example: ; With client, taken from connection-pool, 
waiting 5 seconds to claim, send ; client a message. (with-pool [client 
connection-pool 5] (send client a-message))" [[thingy pool timeout] & body] ; 
Destructuring bind could change nil to a, say, vector, and cause ; 
unbalanced claim/release. `(let [thingy# (claim ~pool ~timeout) ~thingy 
thingy#] (try (let [res# (do ~@body)] (release ~pool thingy#) res#) (catch 
Throwable t# (invalidate ~pool thingy#) (throw t#)



And:

https://github.com/clojure/java.jmx/blob/master/src/main/clojure/clojure/java/jmx.clj


(deftype Bean [state-ref] DynamicMBean (getMBeanInfo [_] (MBeanInfo. (.. _ 
getClass getName) ; class name "Clojure Dynamic MBean" ; description (
map->attribute-infos @state-ref) ; attributes nil ; constructors nil ; 
operations nil)) (getAttribute [_ attr] (@state-ref (keyword attr))) (
getAttributes [_ attrs] (let [result (AttributeList.)] (doseq [attr attrs] (
.add result (Attribute. attr (.getAttribute _ attr result)) (
setAttribute [_ attr] (let [attr-name (.getName attr) attr-value (.getValue 
attr) state-update {(keyword attr-name) attr-value}] (condp = (type 
state-ref) clojure.lang.Agent (await (send state-ref (fn [state 
state-update] (merge state state-update)) state-update)) clojure.lang.Atom (
swap! state-ref merge state-update) clojure.lang.Ref (dosync (ref-set 
state-ref (merge @state-ref state-update)) (setAttributes [_ attrs] (let 
[attr-names (map (fn [attr] (.setAttribute _ attr) (.getName attr)) attrs)] 
(.getAttributes _ (into-array attr-names)



I would love to see some other examples.




 

On Wednesday, May 6, 2015 at 9:49:47 PM UTC-4, Surgo wrote:
>
> I'm not saying this is everyone's experience or anything, but at times I 
> have at times considered some deeper STM-work with agents but I could not 
> seem to penetrate the documentation at the time. I do not know if it's 
> different now
>
> -- Morgon
>
> On Wednesday, May 6, 2015 at 5:38:08 PM UTC-4, James Reeves wrote:
>>
>> On 6 May 2015 at 21:58, Alex Miller  wrote:
>>
>>> I would have to say that the biggest surprise is how little they're 
>>> needed in Clojure. The combination of immutable data, functions to update 
>>> complex data structures, and fast pure function updates with atoms actually 
>>> satisfies a large percentage of real use cases.
>>>
>>
>> I'll echo this. I've been using Clojure for years, and I can't recall 
>> ever needing refs (or agents for that matter).
>>
>> - James
>>
>

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

[ANN] kibit-helper.el 0.1.1 on melpa.org

[James Elliott]

If you are in the set of Clojure developers who use Emacs and the Kibit 
 Leiningen plugin, you may be interested 
in kibit-helper . I started out 
by submitting a small pull request to Kibit to fix the sample Emacs lisp 
code in their README so the links to your source code when navigating 
errors would work properly, and then added a new command to enable you to 
automatically apply most suggestions from Kibit when you decide you like 
them. At the suggestion of the Kibit maintainers, I moved this out of the 
README and into its own Emacs Lisp package.

So now, if you are already using MELPA, all you need to do is M-x 
package-install kibit-helper. (If you have the old code from the Kibit 
README in your .emacs you will want to remove that and reload Emacs). For 
more information, please see the kibit-helper page on GitHub 
.

Cheers,

  -James

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

Re: ANN: ClojureScript 0.0-2496, cljs.test - a clojure.test port

[Matthew Boston]

Here's the commit I used when swapping cljs.test from clojurescript.test:

https://github.com/testdouble/clojurescript.csv/commit/ad68052e311df423e245ec4d2a7ee5572b2a3a35

Note the runner.js file line 26 is calling the exported function to run all 
the tests.

On Friday, May 8, 2015 at 12:49:07 AM UTC-6, puzzler wrote:
>
> I can't find any documentation or examples for using the new cljs.test 
> namespace.  Can someone point me in the right direction?  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: Clarity Keyboard by SwiftKey - Written in Clojure

[Adam Clements]

Haven't played with j2objc, but have had a play with compiling the core in
RoboVM using lein-fruit. The limitations are a bit different on iOS though,
for example the 40mb hard limit on ram usage for a keyboard before it is
forceably kicked out of memory, and that's around the low end of what we're
getting at the moment on Android, so it might need some different
optimizations before becoming a viable option there. In theory it should be
doable though.

Adam

On Fri, 8 May 2015 7:05 pm adrians  wrote:

> Just tried the keyboard on my old Galaxy Nexus and I have to say that it
> felt really responsive (prediction works great, too). This really validates
> Clojure (well Skummet) for Android development, IMO. Congrats on pushing
> the boundaries and for the writeup around what you've done. I'm curious if
> you're looking at j2objc in combination with Skummet for projects targeting
> Android + iOS.
>
> Cheers
>
>
> On Friday, May 8, 2015 at 7:18:50 AM UTC-4, Adam Clements wrote:
>>
>> Hi all,
>>
>> Just thought you might be interested to know that last week we (SwiftKey)
>> released an Android app, written from the ground up in Clojure, which as of
>> this morning has had 65k downloads. It's a keyboard we're using to test UI
>> ideas which didn't fit well with the existing app. We also took the
>> opportunity to try out a totally different tech stack, central to which are
>> Clojure and core.async.
>>
>> There's a tech blog on the subject at my personal blog
>>  which
>> is reposted on SwiftKey's tech blog
>>  and
>> you can download the app and try it out from Google Play
>> 
>>
>> Many thanks go to everyone who's worked on clojure and clojure-android
>> for making this possible, it's been a dream to develop! I hope this goes to
>> show that it's perfectly reasonable and possible to develop significant,
>> responsive mobile applications in pure Clojure.
>>
>> I'd be interested to know your thoughts and comments, and if you're
>> interested we are currently hiring here at SwiftKey, both for this project
>> and in general.
>>
>> Thanks,
>> Adam Clements
>>
>>  --
> 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: CLJ-703 - 10x compilation time decrease after applying one-line patch, no downsides.

[Martin Raison]

I'm glad to hear that. Thanks!

Le vendredi 8 mai 2015 14:23:03 UTC-7, Alex Miller a écrit :
>
> Yes.
>
>
> On Friday, May 8, 2015 at 3:09:06 PM UTC-5, Andy Fingerhut wrote:
>>
>> Just to clarify, Alex, since your idea of "next release" might be 
>> different than those who aren't following Clojure 1.7 alphas/betas/etc. 
>> carefully.
>>
>> Do you mean "hoping to look at it for Clojure 1.8, since Clojure 1.7 is 
>> to the point of primarily fixing critical bugs and regressions" ?
>>
>> Andy
>>
>> On Fri, May 8, 2015 at 12:07 PM, Alex Miller  
>> wrote:
>>
>>> I'm hoping to look at it for the next release.
>>>
>>> Alex
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

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

[Alex Miller]

Yes.


On Friday, May 8, 2015 at 3:09:06 PM UTC-5, Andy Fingerhut wrote:
>
> Just to clarify, Alex, since your idea of "next release" might be 
> different than those who aren't following Clojure 1.7 alphas/betas/etc. 
> carefully.
>
> Do you mean "hoping to look at it for Clojure 1.8, since Clojure 1.7 is to 
> the point of primarily fixing critical bugs and regressions" ?
>
> Andy
>
> On Fri, May 8, 2015 at 12:07 PM, Alex Miller  > wrote:
>
>> I'm hoping to look at it for the next release.
>>
>> Alex
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: What is "best practice" regarding transducers

[Steve Miner]

I wouldn’t make any claims about “best practices” but I’ve been playing with 
transducers in my little project:

https://github.com/miner/transmuters

I have a blog post about how to “chain” transducers.  (Not sure that’s the best 
term.)  Basically, I wanted to use a transducer that might terminate (as with 
‘take’), and then have another transducer pick up the input from there.  The 
“chain” transducer is like a sequential combination of transducers.  Of course, 
you can mix ‘chain’ and ‘comp’ to make work flows.

http://conjobble.velisco.com/blog_posts/transducer-chain

In any case, it was a fun experiment for me.

Steve Miner
stevemi...@gmail.com


> On May 6, 2015, at 11:15 AM, larry google groups  
> wrote:
> 
> I would like to write a detailed blog post about how developers are actually 
> using transducers. If you have a public project on Github that is using 
> transducers, would you please point me to it? I would like to see what you 
> did. 
> 
> If you are not using transducers, but you plan to in the near future, I would 
> be curious to see the code where you think they could help you.

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

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

[Andy Fingerhut]

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

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

Andy

On Fri, May 8, 2015 at 12:07 PM, Alex Miller  wrote:

> I'm hoping to look at it for the next release.
>
> Alex
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to 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: ANN: ClojureScript 0.0-3255 - pretty printer & latest Closure Compiler / Library

[David Nolen]

I forgot to add that with this release there are now AOTed artifacts for
ClojureScript and all of its Clojure dependencies.

[org.clojure/clojurescript "0.0-3255" :classifier "aot" :exclusions
[org.clojure/tools.reader org.clojure/data.json]]
[org.clojure/tools.reader "0.9.2" :classifier "aot"]
[org.clojure/data.json "0.2.6" :classifier "aot"]

Should do the trick and should significantly improve cold compile and REPL
start times. Feedback on the AOTed ClojureScript artifact is most welcome.

David

On Fri, May 8, 2015 at 3:23 PM, David Nolen  wrote:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-3255"]
>
> A big thanks goes out to Jonathan Boston and Shaun Lebron for this
> release. Thanks to their efforts ClojureScript now includes a full
> port of clojure.pprint under the cljs.pprint namespace. This was the
> last major namespace in need of porting to ClojureScript.
>
> The release also bumps several dependencies: Clojure 1.7.0-beta2,
> tools.reader 0.9.2, Closure Compiler v20150505, and Closure Library
> 0.0-20150505-021ed5b3.
>
> This release also fixes some regressions around async testing,
> docstring REPL support, arglist meta, and more.
>
> As always feedback welcome!
>
> ## 0.0-3255
>
> ### Changes
> * Update Closure Library dependency
> * CLJS-1252: Update Closure Compiler Dependency to v20150505
> * .clj -> .cljc for important analysis / compilation bits
> * add public cljs.compiler.api namespace
> * CLJS-1224: cljs.repl: Memoize stack frame mapping
> * depend on tools.reader 0.9.2
>
> ### Enhancements
> * add cljs.pprint/pp macro
> * CLJS-710: port clojure.pprint
> * CLJS-1178: Compiler does not know Math ns is not not-native
> * add getBasis methods to deftype and defrecord ctors a la Clojure JVM
> * support ^long and ^double type hints
>
> ### Fixes
> * fix cljs-1198 async testing regression
> * CLJS-1254: Update REPL browser agent detection CLJS-1253: Create/Use
>   new Closure Library Release
> * CLJS-1225: Variadic function with same name as parent function gives
>   runtime error in advanced compile mode.
> * CLJS-1246: Add cljs.core/record? predicate.
> * CLJS-1239: Make eduction variadic.
> * CLJS-1244: tagged-literal precondition check missing wrapping vector
> * CLJS-1243: Add TaggedLiteral type & related fns
> * CLJS-1240: Add cljs.core/var?
> * CLJS-1214: :arglists meta has needless quoting CLJS-1232: bad
>   arglists for doc, regression
> * CLJS-1212: Error in set ctor for > 8-entry map literal
> * CLJS-1218: Syntax quoting an alias created with :require-macros
>   throws ClassCastException
> * CLJS-1213: cljs.analyzer incorrectly marks all defs as tests when
>   eliding test metadata
> * CLJS-742: Compilation with :output-file option set fails
>
>

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

ANN: ClojureScript 0.0-3255 - pretty printer & latest Closure Compiler / Library

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "0.0-3255"]

A big thanks goes out to Jonathan Boston and Shaun Lebron for this
release. Thanks to their efforts ClojureScript now includes a full
port of clojure.pprint under the cljs.pprint namespace. This was the
last major namespace in need of porting to ClojureScript.

The release also bumps several dependencies: Clojure 1.7.0-beta2,
tools.reader 0.9.2, Closure Compiler v20150505, and Closure Library
0.0-20150505-021ed5b3.

This release also fixes some regressions around async testing,
docstring REPL support, arglist meta, and more.

As always feedback welcome!

## 0.0-3255

### Changes
* Update Closure Library dependency
* CLJS-1252: Update Closure Compiler Dependency to v20150505
* .clj -> .cljc for important analysis / compilation bits
* add public cljs.compiler.api namespace
* CLJS-1224: cljs.repl: Memoize stack frame mapping
* depend on tools.reader 0.9.2

### Enhancements
* add cljs.pprint/pp macro
* CLJS-710: port clojure.pprint
* CLJS-1178: Compiler does not know Math ns is not not-native
* add getBasis methods to deftype and defrecord ctors a la Clojure JVM
* support ^long and ^double type hints

### Fixes
* fix cljs-1198 async testing regression
* CLJS-1254: Update REPL browser agent detection CLJS-1253: Create/Use
  new Closure Library Release
* CLJS-1225: Variadic function with same name as parent function gives
  runtime error in advanced compile mode.
* CLJS-1246: Add cljs.core/record? predicate.
* CLJS-1239: Make eduction variadic.
* CLJS-1244: tagged-literal precondition check missing wrapping vector
* CLJS-1243: Add TaggedLiteral type & related fns
* CLJS-1240: Add cljs.core/var?
* CLJS-1214: :arglists meta has needless quoting CLJS-1232: bad
  arglists for doc, regression
* CLJS-1212: Error in set ctor for > 8-entry map literal
* CLJS-1218: Syntax quoting an alias created with :require-macros
  throws ClassCastException
* CLJS-1213: cljs.analyzer incorrectly marks all defs as tests when
  eliding test metadata
* CLJS-742: Compilation with :output-file option set fails

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

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

[Alex Miller]

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

Alex

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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 needs a web framework with more momentum

[Hari Krishnan]

Sven,

I like this idea.  Thanks.

-Hari

On Wednesday, May 6, 2015 at 11:46:35 AM UTC-7, Sven Richter wrote:
>
> Hi,
>
> I had a short chat with Dmitri (the owner of luminus) and we both agreed 
> that this is a good plan. I just don't have much time right now (family 
> things), but as soon as there is more I will develop a prototype, 
> integrating the features of closp and closp-crud into luminus and make them 
> available as a luminus profile.
>
> Best Regards,
> Sven
>
> Am Mittwoch, 6. Mai 2015 18:08:03 UTC+2 schrieb Sven Pedersen:
>>
>> Hey Sven,
>> It looks to me like you could really polish the +auth part and integrate 
>> most of that part of closp into Luminus. I'd be happy to help with that. 
>> Then you could make a +closp that depends on +auth and build the UI parts, 
>> etc. Having a working +auth with a default db configuration, possibly with 
>> both yesql and korma as back end options, would make auth/authz trivial to 
>> set up. Then you could also focus on what makes closp unique.
>> --Sven
>>
>> On Tuesday, May 5, 2015 at 1:27:21 AM UTC-4, Sven Richter wrote:
>>>
>>> Hi Dmitri,
>>>
>>> When I was building closp I was taking luminus as the base for it with 
>>> some minor adoptions. I just had a look at the website of luminus and saw 
>>> the massive amount of work you put into the documentation again. If that 
>>> sounds reasonable for you I'd like to try to move closp and closp-crud to 
>>> luminus as an opionated part of it.
>>> So if you call lein new luminus projectname +closp you will basically 
>>> get what you get now with closp. You can look here for the additions: 
>>> https://github.com/sveri/closp.
>>> I would like to maintain that "branch".
>>>
>>> I am not sure if that will work out the way I think, but I'd like to 
>>> evaluate it at least. It would be nice to have a common base and a common 
>>> documentation for it.
>>>
>>> Best Regards,
>>> Sven
>>>
>>> Am Dienstag, 5. Mai 2015 02:38:41 UTC+2 schrieb Dmitri:

 As others have pointed out the comparison isn't really valid. Luminus 
 intentionally aims to leverage existing libraries that are maintained 
 independently whenever possible. I've been doing web dev with Clojure for 
 the past 4 years and overall I do prefer the approach of using composable 
 libraries over monolithic frameworks. With the Clojure web stack it's much 
 easier to tell what's actually happening during the request/response 
 lifecycle as things tend to be explicit. With frameworks like Rails a lot 
 of stuff happens implicitly and requires a lot of in depth knowledge to 
 work with effectively.

 However, there are a some downsides to the libraries over frameworks 
 approach as well. The biggest issue is that it's difficult to track what 
 libraries are actively maintained and which ones play nicely together. 
 Since most libraries are maintained by individuals it's common for them to 
 become abandoned. Another problem is that each app becomes a unique 
 snowflake since there aren't a lot of established patterns for structuring 
 them. Finally, security is an issue for Clojure web apps as a lot of it 
 done in rather ad hoc fashion. While this works great for people who are 
 well versed in the Clojure web ecosystem it's a huge barrier for newcomers.

 I think that the best way to address the problem is via organizations 
 where related projects are maintained by groups of contributors. This 
 helps 
 discovery of projects, and it helps spread the burden of maintenance for 
 them. This approach is already working in the wild on GitHub with Ring, 
 Reagent, and Luminus orgs. Meanwhile, Leiningen templates are a great way 
 to provide reasonable defaults for different types of applications and can 
 be used to address issues such as security.

 Also, I'm certainly open to contributions for Luminus. I moved it to an 
 org recently and new members would be very welcome. :)


 On Saturday, May 2, 2015 at 4:43:53 PM UTC-4, g vim wrote:
>
> I recently did some research into web frameworks on Github. Here's 
> what 
> I found: 
>
>
> FRAMEWORK   LANG  CONTRIBUTORS COMMITS 
>
> LuminusClojure28678 
> CaribouClojure 2275 
>
> BeegoGolang991522 
>
> PhoenixElixir  1241949 
>
> YesodHaskell   1303722 
>
> LaravelPHP2684421 
>
> PlayScala   4176085 
>
> SymfonyPHP113020914 
>
> RailsRuby   269151000 
>
>
> One could conclude from this that the Clojure community isn't that 
> interested in web development but the last Clojure survey s

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

[Martin Raison]

Hi all,

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

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

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

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

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

Martin

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

Re: Clarity Keyboard by SwiftKey - Written in Clojure

[adrians]

Just tried the keyboard on my old Galaxy Nexus and I have to say that it 
felt really responsive (prediction works great, too). This really validates 
Clojure (well Skummet) for Android development, IMO. Congrats on pushing 
the boundaries and for the writeup around what you've done. I'm curious if 
you're looking at j2objc in combination with Skummet for projects targeting 
Android + iOS.

Cheers

On Friday, May 8, 2015 at 7:18:50 AM UTC-4, Adam Clements wrote:
>
> Hi all, 
>
> Just thought you might be interested to know that last week we (SwiftKey) 
> released an Android app, written from the ground up in Clojure, which as of 
> this morning has had 65k downloads. It's a keyboard we're using to test UI 
> ideas which didn't fit well with the existing app. We also took the 
> opportunity to try out a totally different tech stack, central to which are 
> Clojure and core.async.
>
> There's a tech blog on the subject at my personal blog 
>  which 
> is reposted on SwiftKey's tech blog 
>  and 
> you can download the app and try it out from Google Play 
> 
>
> Many thanks go to everyone who's worked on clojure and clojure-android for 
> making this possible, it's been a dream to develop! I hope this goes to 
> show that it's perfectly reasonable and possible to develop significant, 
> responsive mobile applications in pure Clojure.
>
> I'd be interested to know your thoughts and comments, and if you're 
> interested we are currently hiring here at SwiftKey, both for this project 
> and in general.
>
> Thanks,
> Adam Clements
>
>

-- 
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.java.jdbc bug?

[Sean Corfield]

BTW, your tone comes across as rather snarky which isn’t going to make people 
want to assist you.

If you have concrete, constructive suggestions to make, and you care enough to 
create a JIRA account and create a ticket for broader discussion, you’re likely 
to find your comments taken more seriously.

Sean

On May 7, 2015, at 11:03 PM, Alain Picard  wrote:
> This would be easy if the current connection was known to be held in a 
> special variable, say, *database*.  :-)
> 
> I will  "fix" for my special case in my own code base, but this not seem to 
> me to be a "correct" solution
> for an important system library.

-- 
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: separation of concerns w/o encapsulation

[James Reeves]

On 8 May 2015 at 18:40, Andy Fingerhut  wrote:

> James, are you saying that with such a core.typed annotation for function
> available in that example, that it would give a warning if available or any
> of the functions it calls accesses any keys other than :stock and :reserved
> ?
>

Yes and no. The function can access other keys, but their type will be
"Any", limiting their use.

For instance, if I changed the function to include an additional key,
without changing the type annotation:

(defn available [{:keys [stock reserved pending-delivery]}]
  (- stock reserved pending-delivery))

Then core.typed would raise a type error, since [Int Int Any] is not a
valid type signature for clojure.core/-.

However, it might be worth raising the suggestion to Ambrose to add a way
of failing immediately if an unknown key is used, rather than just
assigning the "Any" type.

- James

-- 
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: separation of concerns w/o encapsulation

[Andy Fingerhut]

James, are you saying that with such a core.typed annotation for function
available in that example, that it would give a warning if available or any
of the functions it calls accesses any keys other than :stock and :reserved
?

If so, that is quite impressive.

Andy

On Fri, May 8, 2015 at 10:36 AM, James Reeves  wrote:

> Avoiding encapsulation doesn't mean that every function needs to act on a
> huge global data structure. On the contrary, one of the core ideas of
> Clojure is that we should try to reduce incidental interconnections. What
> you describe in your example is essentially complexity creep.
>
> Ideally, functions should access only the data they need. For instance,
> you might have a function:
>
> (defn available [{:keys [stock reserved]}]
>   (- stock reserved))
>
> In the function arguments we're deliberately restricting the data down to
> two keys. We could also use core.typed to enforce this for us:
>
> (ann available ['{:stock Int, :reserved Int} -> Int])
>
> - James
>
> On 8 May 2015 at 17:29, Brian Craft  wrote:
>
>> Talk on the list about encapsulation usually comes back to some variation
>> of "you don't need it when you have immutable data structures". But in the
>> long term I'm finding the problem of working w/o encapsulation is not the
>> danger of data being mutated under you. Rather, it's the danger of all the
>> module boundaries blurring over time, leading to the big ball of mud: a
>> very fragile code base where everything depends on everything else.
>>
>> E.g. if you model your application with a plain data structure which you
>> pass around to different modules, each concerned with a small part of that
>> data structure, the tendency over time is for every module to become
>> concerned with every part of that data structure.  Then you have no
>> separation, nothing is reusable, and the code is very fragile.
>>
>> How do you avoid this, practically? In OO it would be enforced with
>> encapsulation, so the next developer (which might be me, six months later)
>> trying to fix a bug, or add a feature, knows "Oh, I shouldn't peek in here:
>> this module isn't supposed to depend on that piece of data".
>>
>> --
>> 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.
>

-- 
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: separation of concerns w/o encapsulation

[James Reeves]

Avoiding encapsulation doesn't mean that every function needs to act on a
huge global data structure. On the contrary, one of the core ideas of
Clojure is that we should try to reduce incidental interconnections. What
you describe in your example is essentially complexity creep.

Ideally, functions should access only the data they need. For instance, you
might have a function:

(defn available [{:keys [stock reserved]}]
  (- stock reserved))

In the function arguments we're deliberately restricting the data down to
two keys. We could also use core.typed to enforce this for us:

(ann available ['{:stock Int, :reserved Int} -> Int])

- James

On 8 May 2015 at 17:29, Brian Craft  wrote:

> Talk on the list about encapsulation usually comes back to some variation
> of "you don't need it when you have immutable data structures". But in the
> long term I'm finding the problem of working w/o encapsulation is not the
> danger of data being mutated under you. Rather, it's the danger of all the
> module boundaries blurring over time, leading to the big ball of mud: a
> very fragile code base where everything depends on everything else.
>
> E.g. if you model your application with a plain data structure which you
> pass around to different modules, each concerned with a small part of that
> data structure, the tendency over time is for every module to become
> concerned with every part of that data structure.  Then you have no
> separation, nothing is reusable, and the code is very fragile.
>
> How do you avoid this, practically? In OO it would be enforced with
> encapsulation, so the next developer (which might be me, six months later)
> trying to fix a bug, or add a feature, knows "Oh, I shouldn't peek in here:
> this module isn't supposed to depend on that piece of data".
>
> --
> 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.

[ANN] Shrubbery 0.2.0, a stubbing, spying, and mocking library for Clojure protocols

[Brian Guthrie]

Clojure protocols are a great way to encapsulate operations with side
effects, but suffer from a lack of general test tooling. Shrubbery provides
a small set of basic building blocks for working with them:

 * stub, which accepts a protocol and a hashmap of functions and returns an
implementation with those functions (functions without implementations
return nil);
 * spy, which accepts a protocol and some implementation and returns a new
implementation that tracks the number of times each of its members were
called;
 * mock, which wraps a stub in a spy, allowing callers to supply basic
function implementations and assert against those calls; and
 * received?, which in conjunction with the Matcher protocol provides a way
to query spies and mocks

Shrubbery was written with clojure.test and Cursive in mind. It should work
nicely with goodies like jump-to-reference and rename-function.

Source here: https://github.com/bguthrie/shrubbery

One major caveat is that it's heavily reliant on macros; my attempts to
reify protocols programmatically didn't work out in the end. However,
Shrubbery's macros introduce no new syntax and carry no side effects.

Feedback welcome!

Cheers,

Brian

-- 
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 (defn- ...) but (def ^:private? ...)

[Andy Fingerhut]

I am not aware of any JIRA ticket for this, but there could be one lurking
there somewhere.

Here is a link to a previous discussion about it on this group:
https://groups.google.com/d/msg/clojure/r_ym-h53f1E/y1S31QXNhcAJ

Andy

On Fri, May 8, 2015 at 9:26 AM, Leon Grapenthin 
wrote:

> Do you have a link to the discussion? Is this really the reasoning?
>
> I find it insufficient, because there aren't many defs supporting private :
>
> def, defn, defmacro and definline if I am remembering correctly.
>
> I am kind of tired of writing def ^:private. def- would really be nice to
> have. defmacro- as well.
>
> Is there a JIRA ticket about this?
>
> On Thursday, May 7, 2015 at 4:36:44 PM UTC+2, Herwig Hochleitner wrote:
>
>> 2015-05-07 16:12 GMT+02:00 Stig Brautaset :
>>
>>> Is it because the def form can also be ^:dynamic?
>>>
>> Hm, cognitect turned it down, because basically "if you go down this
>> road, why stop with def- ? and before you know, you've got a core namespace
>> full of def*-"
>>
>>> At any rate, I did an attempt at my first macro to create a (def- ...)
>>> form, but it doesn't seem to work. Can you not attach metadata in a macro?
>>>
>> You can, but it works differently than in normal source. Remember, that ^
>> attaches metadata the literal, that you annotate. so ^:private ~sym is the
>> symbol ~sym with a private metadata key. The quasiquoting, however,
>> rebuilds the form and inserts the sym parameter in place of the ~sym form.
>> So to attach the metadata to actual def'ed symbol, you need to attach it to
>> the output, the macro generates, like this: `(def ~(with-meta sym {:private
>> true}) ...)
>>
>  --
> 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.

separation of concerns w/o encapsulation

[Brian Craft]

Talk on the list about encapsulation usually comes back to some variation 
of "you don't need it when you have immutable data structures". But in the 
long term I'm finding the problem of working w/o encapsulation is not the 
danger of data being mutated under you. Rather, it's the danger of all the 
module boundaries blurring over time, leading to the big ball of mud: a 
very fragile code base where everything depends on everything else.

E.g. if you model your application with a plain data structure which you 
pass around to different modules, each concerned with a small part of that 
data structure, the tendency over time is for every module to become 
concerned with every part of that data structure.  Then you have no 
separation, nothing is reusable, and the code is very fragile.

How do you avoid this, practically? In OO it would be enforced with 
encapsulation, so the next developer (which might be me, six months later) 
trying to fix a bug, or add a feature, knows "Oh, I shouldn't peek in here: 
this module isn't supposed to depend on that piece of data".

-- 
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 (defn- ...) but (def ^:private? ...)

[Leon Grapenthin]

Do you have a link to the discussion? Is this really the reasoning? 

I find it insufficient, because there aren't many defs supporting private :

def, defn, defmacro and definline if I am remembering correctly.

I am kind of tired of writing def ^:private. def- would really be nice to 
have. defmacro- as well. 

Is there a JIRA ticket about this?

On Thursday, May 7, 2015 at 4:36:44 PM UTC+2, Herwig Hochleitner wrote:
>
> 2015-05-07 16:12 GMT+02:00 Stig Brautaset  >:
>
>> Is it because the def form can also be ^:dynamic?
>>
> Hm, cognitect turned it down, because basically "if you go down this road, 
> why stop with def- ? and before you know, you've got a core namespace full 
> of def*-" 
>
>> At any rate, I did an attempt at my first macro to create a (def- ...) 
>> form, but it doesn't seem to work. Can you not attach metadata in a macro?
>>
> You can, but it works differently than in normal source. Remember, that ^ 
> attaches metadata the literal, that you annotate. so ^:private ~sym is the 
> symbol ~sym with a private metadata key. The quasiquoting, however, 
> rebuilds the form and inserts the sym parameter in place of the ~sym form. 
> So to attach the metadata to actual def'ed symbol, you need to attach it to 
> the output, the macro generates, like this: `(def ~(with-meta sym {:private 
> true}) ...)
>

-- 
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 (defn- ...) but (def ^:private? ...)

[Stig Brautaset]

Hi Herwig,

On Thursday, 7 May 2015 15:36:44 UTC+1, Herwig Hochleitner wrote:
>
> 2015-05-07 16:12 GMT+02:00 Stig Brautaset  >:
>
>> Is it because the def form can also be ^:dynamic?
>>
> Hm, cognitect turned it down, because basically "if you go down this road, 
> why stop with def- ? and before you know, you've got a core namespace full 
> of def*-" 
>

And that is a fine justification :-) I was just curious.
 

> Can you not attach metadata in a macro?
>>
> You can, but it works differently than in normal source. Remember, that ^ 
> attaches metadata the literal, that you annotate. so ^:private ~sym is the 
> symbol ~sym with a private metadata key. The quasiquoting, however, 
> rebuilds the form and inserts the sym parameter in place of the ~sym form. 
> So to attach the metadata to actual def'ed symbol, you need to attach it to 
> the output, the macro generates, like this: `(def ~(with-meta sym {:private 
> true}) ...)
>

Thank you for this explanation, it makes sense now!

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: Clarity Keyboard by SwiftKey - Written in Clojure

[Dave Sann]

Very good news for clojure-android.

Keen to hear more.

Dave


On Friday, 8 May 2015 21:18:50 UTC+10, Adam Clements wrote:
>
> Hi all, 
>
> Just thought you might be interested to know that last week we (SwiftKey) 
> released an Android app, written from the ground up in Clojure, which as of 
> this morning has had 65k downloads. It's a keyboard we're using to test UI 
> ideas which didn't fit well with the existing app. We also took the 
> opportunity to try out a totally different tech stack, central to which are 
> Clojure and core.async.
>
> There's a tech blog on the subject at my personal blog 
>  which 
> is reposted on SwiftKey's tech blog 
>  and 
> you can download the app and try it out from Google Play 
> 
>
> Many thanks go to everyone who's worked on clojure and clojure-android for 
> making this possible, it's been a dream to develop! I hope this goes to 
> show that it's perfectly reasonable and possible to develop significant, 
> responsive mobile applications in pure Clojure.
>
> I'd be interested to know your thoughts and comments, and if you're 
> interested we are currently hiring here at SwiftKey, both for this project 
> and in general.
>
> Thanks,
> Adam Clements
>
>

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

Clarity Keyboard by SwiftKey - Written in Clojure

[Adam Clements]

Hi all,

Just thought you might be interested to know that last week we (SwiftKey)
released an Android app, written from the ground up in Clojure, which as of
this morning has had 65k downloads. It's a keyboard we're using to test UI
ideas which didn't fit well with the existing app. We also took the
opportunity to try out a totally different tech stack, central to which are
Clojure and core.async.

There's a tech blog on the subject at my personal blog
 which
is reposted on SwiftKey's tech blog
 and
you can download the app and try it out from Google Play


Many thanks go to everyone who's worked on clojure and clojure-android for
making this possible, it's been a dream to develop! I hope this goes to
show that it's perfectly reasonable and possible to develop significant,
responsive mobile applications in pure Clojure.

I'd be interested to know your thoughts and comments, and if you're
interested we are currently hiring here at SwiftKey, both for this project
and in general.

Thanks,
Adam Clements

-- 
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 needs a web framework with more momentum

[Daniel Kersten]

I haven't used Luminus since before 2.0, so I guess it may have changed a
lot since. At the time, I was disheartened by the amount of code generated.
I will take another look when I get time.

On Tue, 5 May 2015 at 14:06 Dmitri  wrote:

> Luminus uses a minimal amount of generated code. It completely embraces
> the composable library approach. The difference from rolling your own each
> time is that it provides some structure and it's a curated set of libraries
> that are known to work well together.
>
>
> On Tuesday, May 5, 2015 at 3:46:09 AM UTC-4, Dan Kersten wrote:
>
>> On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:
>>>
>> One potential problem with this "web framework" as app template approach
>>> is upgrade-ability.  When 2.0 of your "framework" comes out, what happens
>>> to an app generated from 1.0 that wants to benefit from the new
>>> capabilities?
>>>
>>
>> This is the reason I don't use Luminus or Modularity or others that rely
>> heavily on leiningen template-based codegen. Its very difficult to upgrade
>> the generated code, especially if you've had to add to or modify it.
>>
>> I'm experimenting with an approach that would generate only the
>> project.clj file and directory structure (putting everything else into
>> libraries), but don't yet have anything to release (my code is currently
>> very targeted at my own use case, but in time I'd like to generalize it a
>> bit and let others at 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.
>

-- 
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.lang.LazySeq cannot be cast to clojure.lang.IFn

[Ray Miller]

Looks like the exception is thrown during config parsing. You probably
need to enclose the email addresses in a vector [] rather than a list
().

Ray.

On 8 May 2015 at 08:01, Alexey Astafyev  wrote:
> I'm new to Riemann and Clojure. All I want to do is to send email
> notifications to three email groups when some service's TTL is expired. I
> created some sort of config file where I store a list of emails:
>
> {
>   :email_group_1 (
>   "fi...@example.com"
>   "sec...@example.ru"
>  )
>   :email_group_2 (
>   "th...@example.com"
>  )
> }
>
>
> My riemann config looks like this:
>
> (logging/init {:console true})
> (import org.apache.log4j.Level)
> (logging/set-level Level/DEBUG)
>
> (require '[clojure.java.io :as io])
> (import '[java.io PushbackReader])
>
> (let [host "0.0.0.0"]
>   (tcp-server {:host host :port 60001})
>   (udp-server {:host host})
>   (ws-server  {:host host :port 60003}))
> (repl-server  {:host "127.0.0.1"})
>
> (def cwd (System/getProperty "user.dir"))
>
> (def emails
>   (with-open [r (io/reader (str cwd "/etc/emails.clj"))]
>  (read (PushbackReader. r
>
> (periodically-expire 5)
>
> (def email (mailer))
>
> (defn notify [& egroups]
>   (for [egroup egroups]
> (rollup 1 60 (apply email (emails egroup)
>
> (let [index (index)]
>   (streams
> (default :ttl 60
>   index
>
>   (expired
>   (where (service "service_connect_active")
> #(info "expired" %)
> (notify :email_group_1 :email_group_2))
>
>
> Code looks good (for me), but when this service is expired I get the
> following error:
>
> 09:45:39 riemann.1  | INFO [2015-05-08 10:45:39,313] Thread-5 -
> riemann.config - expired {:ttl 60, :time 357766884827/250, :state expired,
> :service service_connect_active, :host ava.local}
> 09:45:39 riemann.1  | WARN [2015-05-08 10:45:39,319] Thread-5 -
> riemann.config - clojure.lang.LazySeq@841649b8 threw
> 09:45:39 riemann.1  | java.lang.ClassCastException: clojure.lang.LazySeq
> cannot be cast to clojure.lang.IFn
> 09:45:39 riemann.1  |   at
> riemann.config$eval66$stream__70$fn__75.invoke(riemann.development.config:34)
> 09:45:39 riemann.1  |   at
> riemann.config$eval66$stream__70.invoke(riemann.development.config:45)
> 09:45:39 riemann.1  |   at
> riemann.streams$match$stream__3514$fn__3525.invoke(streams.clj:1209)
> 09:45:39 riemann.1  |   at
> riemann.streams$match$stream__3514.invoke(streams.clj:1209)
> 09:45:39 riemann.1  |   at
> riemann.streams$default$stream__3731$fn__3742.invoke(streams.clj:1328)
> 09:45:39 riemann.1  |   at
> riemann.streams$default$stream__3731.invoke(streams.clj:1328)
> 09:45:39 riemann.1  |   at
> riemann.core$stream_BANG_$fn__4415.invoke(core.clj:19)
> 09:45:39 riemann.1  |   at riemann.core$stream_BANG_.invoke(core.clj:18)
> 09:45:39 riemann.1  |   at
> riemann.core$reaper$worker__4529$fn__4539.invoke(core.clj:303)
> 09:45:39 riemann.1  |   at
> riemann.core$reaper$worker__4529.invoke(core.clj:297)
> 09:45:39 riemann.1  |   at
> riemann.service.ThreadService$thread_service_runner__1973$fn__1974.invoke(service.clj:71)
> 09:45:39 riemann.1  |   at
> riemann.service.ThreadService$thread_service_runner__1973.invoke(service.clj:70)
> 09:45:39 riemann.1  |   at clojure.lang.AFn.run(AFn.java:22)
> 09:45:39 riemann.1  |   at java.lang.Thread.run(Thread.java:745)
>
>
> Could someone please help me? 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.

-- 
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.lang.LazySeq cannot be cast to clojure.lang.IFn

[Luc Préfontaine]

Dunno riemann but I would say that you need a closure here,
not an immediate call to notify. The closure will be called when expiration is 
reached.

So use #(notify ...) instead.

In your current code notify gets called, return a lazy seq (for) and then 
the lazy seq is called as a function when the service expires. Oups...

Second thing, use doseq, not for if you want the side effects do be done in
your notify fn. for will not get your side effects done, it only returns a lazy 
seq.

Luc P.

Sent from my iPad

> On May 8, 2015, at 08:01, Alexey Astafyev  wrote:
> 
> I'm new to Riemann and Clojure. All I want to do is to send email 
> notifications to three email groups when some service's TTL is expired. I 
> created some sort of config file where I store a list of emails:
> 
> {
>   :email_group_1 (
>   "fi...@example.com"
>   "sec...@example.ru"
>  )
>   :email_group_2 (
>   "th...@example.com"
>  )
> }
> 
> My riemann config looks like this:
> 
> (logging/init {:console true})
> (import org.apache.log4j.Level)
> (logging/set-level Level/DEBUG)
> 
> (require '[clojure.java.io :as io])
> (import '[java.io PushbackReader])
> 
> (let [host "0.0.0.0"]
>   (tcp-server {:host host :port 60001})
>   (udp-server {:host host})
>   (ws-server  {:host host :port 60003}))
> (repl-server  {:host "127.0.0.1"})
> 
> (def cwd (System/getProperty "user.dir"))
> 
> (def emails
>   (with-open [r (io/reader (str cwd "/etc/emails.clj"))]
>  (read (PushbackReader. r
> 
> (periodically-expire 5)
> 
> (def email (mailer))
> 
> (defn notify [& egroups]
>   (for [egroup egroups]
> (rollup 1 60 (apply email (emails egroup)
> 
> (let [index (index)]
>   (streams
> (default :ttl 60
>   index
> 
>   (expired
>   (where (service "service_connect_active")
> #(info "expired" %)
> (notify :email_group_1 :email_group_2))
> 
> Code looks good (for me), but when this service is expired I get the 
> following error:
> 
> 09:45:39 riemann.1  | INFO [2015-05-08 10:45:39,313] Thread-5 - 
> riemann.config - expired {:ttl 60, :time 357766884827/250, :state expired, 
> :service service_connect_active, :host ava.local}
> 09:45:39 riemann.1  | WARN [2015-05-08 10:45:39,319] Thread-5 - 
> riemann.config - clojure.lang.LazySeq@841649b8 threw
> 09:45:39 riemann.1  | java.lang.ClassCastException: clojure.lang.LazySeq 
> cannot be cast to clojure.lang.IFn
> 09:45:39 riemann.1  |   at 
> riemann.config$eval66$stream__70$fn__75.invoke(riemann.development.config:34)
> 09:45:39 riemann.1  |   at 
> riemann.config$eval66$stream__70.invoke(riemann.development.config:45)
> 09:45:39 riemann.1  |   at 
> riemann.streams$match$stream__3514$fn__3525.invoke(streams.clj:1209)
> 09:45:39 riemann.1  |   at 
> riemann.streams$match$stream__3514.invoke(streams.clj:1209)
> 09:45:39 riemann.1  |   at 
> riemann.streams$default$stream__3731$fn__3742.invoke(streams.clj:1328)
> 09:45:39 riemann.1  |   at 
> riemann.streams$default$stream__3731.invoke(streams.clj:1328)
> 09:45:39 riemann.1  |   at 
> riemann.core$stream_BANG_$fn__4415.invoke(core.clj:19)
> 09:45:39 riemann.1  |   at riemann.core$stream_BANG_.invoke(core.clj:18)
> 09:45:39 riemann.1  |   at 
> riemann.core$reaper$worker__4529$fn__4539.invoke(core.clj:303)
> 09:45:39 riemann.1  |   at 
> riemann.core$reaper$worker__4529.invoke(core.clj:297)
> 09:45:39 riemann.1  |   at 
> riemann.service.ThreadService$thread_service_runner__1973$fn__1974.invoke(service.clj:71)
> 09:45:39 riemann.1  |   at 
> riemann.service.ThreadService$thread_service_runner__1973.invoke(service.clj:70)
> 09:45:39 riemann.1  |   at clojure.lang.AFn.run(AFn.java:22)
> 09:45:39 riemann.1  |   at java.lang.Thread.run(Thread.java:745)
> 
> Could someone please help me? 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.

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

Re: JDK8

[Max Penet]

We've been running Oracle JDK8 on 30'ish servers  (clj based web api, 
aggregation/streaming service, cassandra 2.1+, elastic search, etc) without 
any (noticeable) hiccups for a couple of weeks here. 


On Thursday, May 7, 2015 at 10:25:13 PM UTC+2, Pierre-Yves Ritschard wrote:
>
> Hi,
>
> There hasn't been a JDK version thread in a while and a few projects we 
> rely on will soon require a JDK8. Are people running large apps on JDK8 and 
> if so, which one ? I'd be intent on trying to stick with OpenJDK if at all 
> possible.
>
> Cheers,
>
>

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

clojure.lang.LazySeq cannot be cast to clojure.lang.IFn

[Alexey Astafyev]

I'm new to Riemann and Clojure. All I want to do is to send email 
notifications to three email groups when some service's TTL is expired. I 
created some sort of config file where I store a list of emails:

{
  :email_group_1 (
  "fi...@example.com"
  "sec...@example.ru"
 )
  :email_group_2 (
  "th...@example.com"
 )
}


My riemann config looks like this:

(logging/init {:console true})
(import org.apache.log4j.Level)
(logging/set-level Level/DEBUG)

(require '[clojure.java.io :as io])
(import '[java.io PushbackReader])

(let [host "0.0.0.0"]
  (tcp-server {:host host :port 60001})
  (udp-server {:host host})
  (ws-server  {:host host :port 60003}))
(repl-server  {:host "127.0.0.1"})

(def cwd (System/getProperty "user.dir"))

(def emails
  (with-open [r (io/reader (str cwd "/etc/emails.clj"))]
 (read (PushbackReader. r

(periodically-expire 5)

(def email (mailer))

(defn notify [& egroups]
  (for [egroup egroups]
(rollup 1 60 (apply email (emails egroup)

(let [index (index)]
  (streams
(default :ttl 60
  index

  (expired
  (where (service "service_connect_active")
#(info "expired" %)
(notify :email_group_1 :email_group_2))


Code looks good (for me), but when this service is expired I get the 
following error:

09:45:39 riemann.1  | INFO [2015-05-08 10:45:39,313] Thread-5 - 
riemann.config - expired {:ttl 60, :time 357766884827/250, :state expired, 
:service service_connect_active, :host ava.local}
09:45:39 riemann.1  | WARN [2015-05-08 10:45:39,319] Thread-5 - 
riemann.config - clojure.lang.LazySeq@841649b8 threw
09:45:39 riemann.1  | java.lang.ClassCastException: clojure.lang.LazySeq 
cannot be cast to clojure.lang.IFn
09:45:39 riemann.1  |   at 
riemann.config$eval66$stream__70$fn__75.invoke(riemann.development.config:34)
09:45:39 riemann.1  |   at 
riemann.config$eval66$stream__70.invoke(riemann.development.config:45)
09:45:39 riemann.1  |   at 
riemann.streams$match$stream__3514$fn__3525.invoke(streams.clj:1209)
09:45:39 riemann.1  |   at 
riemann.streams$match$stream__3514.invoke(streams.clj:1209)
09:45:39 riemann.1  |   at 
riemann.streams$default$stream__3731$fn__3742.invoke(streams.clj:1328)
09:45:39 riemann.1  |   at 
riemann.streams$default$stream__3731.invoke(streams.clj:1328)
09:45:39 riemann.1  |   at 
riemann.core$stream_BANG_$fn__4415.invoke(core.clj:19)
09:45:39 riemann.1  |   at riemann.core$stream_BANG_.invoke(core.clj:18)
09:45:39 riemann.1  |   at 
riemann.core$reaper$worker__4529$fn__4539.invoke(core.clj:303)
09:45:39 riemann.1  |   at 
riemann.core$reaper$worker__4529.invoke(core.clj:297)
09:45:39 riemann.1  |   at 
riemann.service.ThreadService$thread_service_runner__1973$fn__1974.invoke(service.clj:71)
09:45:39 riemann.1  |   at 
riemann.service.ThreadService$thread_service_runner__1973.invoke(service.clj:70)
09:45:39 riemann.1  |   at clojure.lang.AFn.run(AFn.java:22)
09:45:39 riemann.1  |   at java.lang.Thread.run(Thread.java:745)


Could someone please help me? 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.