Re: Luminus in Techempower benchmarks

[Jim Crossley]

Sounds good, Dmitri. I'll work up something on a fork in the next few
days and ping you. We can go from there.

Jim


On Mon, Feb 29, 2016 at 2:33 PM, Dmitri <dmitri.sotni...@gmail.com> wrote:
> Hi Jim,
>
> I'm the author of Luminus, and I'd love tow work with you to tune up the
> performance. Feel free to ping me via email or on GitHub.
>
>
> On Sunday, February 28, 2016 at 8:17:13 PM UTC-5, Jim Crossley wrote:
>>
>> I just tried a few experiments and realized the :dispatch? option is
>> broken in the latest Immutant release. :(
>>
>> This is a result of some changes we made to better support WebSockets.
>>
>> We were already hoping to get a release out this week, so we'll add that
>> to the list of fixes.
>>
>> Sorry about that,
>> Jim
>>
>> On Sunday, February 28, 2016 at 1:32:09 PM UTC-5, Jim Crossley wrote:
>>>
>>> Hi,
>>>
>>> Luminus uses Immutant, which uses Undertow, so it should be possible
>>> to tune the Luminus app to approach the performance of the TechEmpower
>>> Undertow app. The relevant options to immutant.web/run [1] are
>>> :dispatch?, :io-threads, and :worker-threads.
>>>
>>> The Undertow app sets IO threads here [2] and worker threads here [3],
>>> so you can easily set those same values in the Luminus app.
>>>
>>> But the real performance bump will come from the :dispatch? option. By
>>> default, :dispatch? is true, i.e. requests handled by threads in the
>>> IO pool are dispatched to a thread in the worker pool. For
>>> compute-bound tasks like the JSON serialization benchmark, that
>>> context switch is far more expensive than just having the IO thread
>>> return the response. So you'd want to set :dispatch? to false in that
>>> case.
>>>
>>> The tricky bit here is that the Luminus app defines all its routes in
>>> a single handler [4]. But for the more io-bound tasks, e.g.
>>> DbSqlHandler [5], you'll want the default true value of :dispatch?. So
>>> in order to get the best results for all the benchmarks, you'll need
>>> to re-organize that app to run two handlers: one that dispatches and
>>> one that doesn't. In Immutant, the simplest way to do this is to
>>> distinguish each handler with a unique :path option.
>>>
>>> I'm happy to assist whoever is maintaining that app with the tuning.
>>>
>>> Thanks,
>>> Jim
>>>
>>> [1]
>>> http://immutant.org/documentation/current/apidoc/immutant.web.html#var-run
>>> [2]
>>> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/HelloWebServer.java#L122
>>> [3]
>>> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/HelloWebServer.java#L160
>>> [4]
>>> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Clojure/luminus/hello/src/hello/routes/home.clj#L44
>>> [5]
>>> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/DbSqlHandler.java#L38
>>>
>>> On Sat, Feb 27, 2016 at 9:40 PM, gvim <gvi...@gmail.com> wrote:
>>> > In the latest round of Techempower benchmarks:
>>> >
>>> >
>>> > https://www.techempower.com/benchmarks/#section=data-r12=peak=json
>>> >
>>> > ... I was surprised to find Luminus performing no better than Hapi
>>> > (Node)
>>> > and significantly worse than Java frameworks. Figures are
>>> > requests/second:
>>> >
>>> > FORTUNES
>>> > - Hapi: 1.9
>>> > - Luminus:   0.9
>>> > - Gemini:   55.5
>>> >
>>> > JSON SERIALISATION
>>> > - Hapi: 0.3  (Raw db)
>>> > - Luminus:   0.8
>>> > - Rapidoid: 78.4
>>> >
>>> >
>>> > SINGLE QUERY
>>> > - Hapi: 2.9
>>> > - Luminus:   8.7
>>> > - Gemini:   75.8
>>> >
>>> > MULTI-QUERY
>>> > - Hapi:   33.0
>>> > - Luminus: 20.4
>>> > - Dropwizard: 65.8
>>> >
>>> > DATA UPDATES
>>> > - Hapi:20.9
>>> > - Luminus:  20.0
>>> > - Ninja:   54.7
>>> >
>>> > PLAINTEXT
>>> > - Hapi:0.7
>>> > - Luminus:  0.0
>>> > - Rapidoid:  100.0
>>> >
>>> >
>>> >
>&

Re: Luminus in Techempower benchmarks

[Jim Crossley]

I just tried a few experiments and realized the :dispatch? option is broken 
in the latest Immutant release. :(

This is a result of some changes we made to better support WebSockets.

We were already hoping to get a release out this week, so we'll add that to 
the list of fixes.

Sorry about that,
Jim

On Sunday, February 28, 2016 at 1:32:09 PM UTC-5, Jim Crossley wrote:
>
> Hi, 
>
> Luminus uses Immutant, which uses Undertow, so it should be possible 
> to tune the Luminus app to approach the performance of the TechEmpower 
> Undertow app. The relevant options to immutant.web/run [1] are 
> :dispatch?, :io-threads, and :worker-threads. 
>
> The Undertow app sets IO threads here [2] and worker threads here [3], 
> so you can easily set those same values in the Luminus app. 
>
> But the real performance bump will come from the :dispatch? option. By 
> default, :dispatch? is true, i.e. requests handled by threads in the 
> IO pool are dispatched to a thread in the worker pool. For 
> compute-bound tasks like the JSON serialization benchmark, that 
> context switch is far more expensive than just having the IO thread 
> return the response. So you'd want to set :dispatch? to false in that 
> case. 
>
> The tricky bit here is that the Luminus app defines all its routes in 
> a single handler [4]. But for the more io-bound tasks, e.g. 
> DbSqlHandler [5], you'll want the default true value of :dispatch?. So 
> in order to get the best results for all the benchmarks, you'll need 
> to re-organize that app to run two handlers: one that dispatches and 
> one that doesn't. In Immutant, the simplest way to do this is to 
> distinguish each handler with a unique :path option. 
>
> I'm happy to assist whoever is maintaining that app with the tuning. 
>
> Thanks, 
> Jim 
>
> [1] 
> http://immutant.org/documentation/current/apidoc/immutant.web.html#var-run 
> [2] 
> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/HelloWebServer.java#L122
>  
> [3] 
> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/HelloWebServer.java#L160
>  
> [4] 
> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Clojure/luminus/hello/src/hello/routes/home.clj#L44
>  
> [5] 
> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/DbSqlHandler.java#L38
>  
>
> On Sat, Feb 27, 2016 at 9:40 PM, gvim <gvi...@gmail.com > 
> wrote: 
> > In the latest round of Techempower benchmarks: 
> > 
> > 
> https://www.techempower.com/benchmarks/#section=data-r12=peak=json 
> > 
> > ... I was surprised to find Luminus performing no better than Hapi 
> (Node) 
> > and significantly worse than Java frameworks. Figures are 
> requests/second: 
> > 
> > FORTUNES 
> > - Hapi: 1.9 
> > - Luminus:   0.9 
> > - Gemini:   55.5 
> > 
> > JSON SERIALISATION 
> > - Hapi: 0.3  (Raw db) 
> > - Luminus:   0.8 
> > - Rapidoid: 78.4 
> > 
> > 
> > SINGLE QUERY 
> > - Hapi: 2.9 
> > - Luminus:   8.7 
> > - Gemini:   75.8 
> > 
> > MULTI-QUERY 
> > - Hapi:   33.0 
> > - Luminus: 20.4 
> > - Dropwizard: 65.8 
> > 
> > DATA UPDATES 
> > - Hapi:20.9 
> > - Luminus:  20.0 
> > - Ninja:   54.7 
> > 
> > PLAINTEXT 
> > - Hapi:0.7 
> > - Luminus:  0.0 
> > - Rapidoid:  100.0 
> > 
> > 
> > 
> > Any ideas? 
> > 
> > gvim 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > -- 
> > 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: Luminus in Techempower benchmarks

[Jim Crossley]

Hi,

Luminus uses Immutant, which uses Undertow, so it should be possible
to tune the Luminus app to approach the performance of the TechEmpower
Undertow app. The relevant options to immutant.web/run [1] are
:dispatch?, :io-threads, and :worker-threads.

The Undertow app sets IO threads here [2] and worker threads here [3],
so you can easily set those same values in the Luminus app.

But the real performance bump will come from the :dispatch? option. By
default, :dispatch? is true, i.e. requests handled by threads in the
IO pool are dispatched to a thread in the worker pool. For
compute-bound tasks like the JSON serialization benchmark, that
context switch is far more expensive than just having the IO thread
return the response. So you'd want to set :dispatch? to false in that
case.

The tricky bit here is that the Luminus app defines all its routes in
a single handler [4]. But for the more io-bound tasks, e.g.
DbSqlHandler [5], you'll want the default true value of :dispatch?. So
in order to get the best results for all the benchmarks, you'll need
to re-organize that app to run two handlers: one that dispatches and
one that doesn't. In Immutant, the simplest way to do this is to
distinguish each handler with a unique :path option.

I'm happy to assist whoever is maintaining that app with the tuning.

Thanks,
Jim

[1] http://immutant.org/documentation/current/apidoc/immutant.web.html#var-run
[2] 
https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/HelloWebServer.java#L122
[3] 
https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/HelloWebServer.java#L160
[4] 
https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Clojure/luminus/hello/src/hello/routes/home.clj#L44
[5] 
https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/DbSqlHandler.java#L38

On Sat, Feb 27, 2016 at 9:40 PM, gvim  wrote:
> In the latest round of Techempower benchmarks:
>
> https://www.techempower.com/benchmarks/#section=data-r12=peak=json
>
> ... I was surprised to find Luminus performing no better than Hapi (Node)
> and significantly worse than Java frameworks. Figures are requests/second:
>
> FORTUNES
> - Hapi: 1.9
> - Luminus:   0.9
> - Gemini:   55.5
>
> JSON SERIALISATION
> - Hapi: 0.3  (Raw db)
> - Luminus:   0.8
> - Rapidoid: 78.4
>
>
> SINGLE QUERY
> - Hapi: 2.9
> - Luminus:   8.7
> - Gemini:   75.8
>
> MULTI-QUERY
> - Hapi:   33.0
> - Luminus: 20.4
> - Dropwizard: 65.8
>
> DATA UPDATES
> - Hapi:20.9
> - Luminus:  20.0
> - Ninja:   54.7
>
> PLAINTEXT
> - Hapi:0.7
> - Luminus:  0.0
> - Rapidoid:  100.0
>
>
>
> Any ideas?
>
> 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.

-- 
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: Immutant survey

[Jim Crossley]

Here are the results: http://immutant.org/news/2015/04/02/survey-results/

Thanks!
Jim

On Thursday, March 12, 2015 at 12:11:27 PM UTC-4, jaju wrote:

 Very curious to know - how's the response been?

 A happy user,
 jaju

 On Fri, Mar 6, 2015 at 8:01 PM, Jim Crossley jcros...@gmail.com 
 javascript: wrote:

 Hi friends,

 If you have any opinion about Immutant [1], would you please take a few 
 moments to fill out this short survey?

   http://goo.gl/forms/syYnYtpM4v

 We're trying to get a sense of how Immutant is being used.

 Thanks so much!
 Jim

 [1] http://immutant.org

  -- 
 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: Immutant survey

[Jim Crossley]

As of this moment, we've received 46 responses, mostly positive, some
with very thoughtful feedback, for which we're very grateful.

We plan to post the results on immutant.org in a couple weeks.

Thanks,
Jim

On Thu, Mar 12, 2015 at 12:10 PM, Ravindra Jaju ravindra.j...@gmail.com wrote:
 Very curious to know - how's the response been?

 A happy user,
 jaju

 On Fri, Mar 6, 2015 at 8:01 PM, Jim Crossley jcrossl...@gmail.com wrote:

 Hi friends,

 If you have any opinion about Immutant [1], would you please take a few
 moments to fill out this short survey?

   http://goo.gl/forms/syYnYtpM4v

 We're trying to get a sense of how Immutant is being used.

 Thanks so much!
 Jim

 [1] http://immutant.org

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

Immutant survey

[Jim Crossley]

Hi friends,

If you have any opinion about Immutant [1], would you please take a few 
moments to fill out this short survey?

  http://goo.gl/forms/syYnYtpM4v

We're trying to get a sense of how Immutant is being used.

Thanks so much!
Jim

[1] http://immutant.org

-- 
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 the Undertow AJP Linstner in Immutant2

[Jim Crossley]

Cool. Submit a PR and we'll get it merged in.

Thanks!
Jim

On Fri, Feb 20, 2015 at 4:25 AM, Eunmin Kim telepopso...@gmail.com wrote:
 Hi!
 I added ajp? on immutant.web/run option to use the Undertow AJP Linstner in
 Immutant2. :)

 https://github.com/eunmin/immutant/tree/support_undertow_ajp


 --
 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] Immutant 2.0.0-beta2

[Jim Crossley]

Hi all,

We released Beta 2 of The Deuce today: 
http://immutant.org/news/2015/02/09/announcing-2-beta2/

We introduced some breaking changes, specifically around WebSockets, but we 
like the new API, as it now directly supports HTTP streams, including 
Server-Sent Events. See the Asynchrony section in the guide for more 
details: http://immutant.org/documentation/2.0.0-beta2/apidoc/guide-web.html

This work mostly came out of Toby's recent efforts to integrate Immutant 
with Sente: https://github.com/ptaoussanis/sente

We thought we were going to release a 2.0 final last November, because 
that's when WildFly 9 was expected to be released. But that hasn't happened 
yet. So now we're saying some time in the Spring. Regardless, we feel 
like beta2 is pretty stable ('course we thought that about beta1 too!) so 
we'd appreciate the feedback, especially if the new async features interest 
you.

Thanks!
Jim


-- 
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] Immutant 2.0.0-alpha1 The Deuce

[Jim Crossley]

Hey, we dropped our first Deuce today! ;-)

Details here: http://immutant.org/news/2014/08/27/announcing-2-alpha1/

Immutant has evolved from an application server for Clojure to an 
integrated suite of Clojure libraries for web, messaging, scheduling, and 
caching. And though they are now fully-functional embedded within your 
app, they each become automatically enhanced (session replication, 
load-balanced message distribution, linearly scalable caches, HA singleton 
jobs and daemons) when deployed to a WildFly cluster.

The Deuce has a much smaller footprint, a very fast Undertow web server, 
a more permissive Apache license, and hopefully cleaner API's.

Thanks,
Jim

-- 
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] lein-modules 0.3.1

[Jim Crossley]

I just released version 0.3.1 of lein-modules [1]. I've fixed a lot of 
bugs, added one feature, and slightly changed the behavior since the last 
time I announced a release.

What is it?

It's a Leiningen plugin that lets you treat a set of related projects 
stored in a single SCM repository as an aggregate. Features include 
dependency build order, flexible project inheritance, a simple dependency 
management mechanism, and automatic checkout dependencies.

We use it for Immutant's build [2], and this morning I converted two other 
multi-module projects with which I'm somewhat familiar: Pedestal [3] and 
Ring [4]. I did this mainly to harden lein-modules, just as an exercise to 
expose potential bugs. But those three may serve as examples for your own 
projects if you're interested.

Have fun!
Jim

[1] https://github.com/jcrossley3/lein-modules
[2] https://github.com/immutant/immutant
[3] 
https://github.com/jcrossley3/pedestal/commit/3dabf7190a618885e84b32999bbfd7a031c7dcde
[4] 
https://github.com/jcrossley3/ring/commit/e4d23f7a33cc035d090b028982c8e47c367146b6

-- 
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: Kwargs vs explicit parameter map for APIs?

[Jim Crossley]

We used kwargs for options extensively in Immutant 1.x, and we're moving to
explicit maps for Immutant 2.x, for the reasons cited above.

It's not obvious to me why the bad release-sharks example on the coding
standards page [1] is bad. Why should the optional config be the least
variance argument?

I had to look up laudable, btw. It's one of those good words that sounds
bad. :)

[1] http://dev.clojure.org/display/community/Library+Coding+Standards



On Wed, Apr 30, 2014 at 6:14 AM, Colin Fleming
colin.mailingl...@gmail.comwrote:

 And thinking about it (after pressing send, of course), you'd get the
 same benefit from destructuring an explicit map in the function parameter
 anyway, wouldn't you?


 On 30 April 2014 22:11, Colin Fleming colin.mailingl...@gmail.com wrote:

 But that's only true for the variables which are explicitly destructured
 in the function definition, which in my experience many are not - they're
 often later picked out of an :as args argument, perhaps dependent on a
 combination of the parameters which are explicitly destructured. Seesaw
 never does this, for example. I think it's dangerous to rely on this rather
 than the documentation since it's often an incomplete view of what the
 function requires.

 Cheers,
 Colin


 On 30 April 2014 21:03, Joachim De Beule joachim.de.be...@gmail.comwrote:

 my two cents:

 The extra readability to users when using keyword args also comes from
 the fact that a function's options are explicit in its signature. So during
 development, instead of having to look them up in the docs or in the code,
 my emacs mini-buffer simply shows them to me. Although I do agree with all
 the good reasons against keywords arguments, to me this is still the
 decisive reason to prefer them...

 Joachim

 Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves:

 On 30 April 2014 03:54, Sean Corfield se...@corfield.org wrote:

 I still think the keyword argument approach is far more readable to
 _users_


  --
 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: Kwargs vs explicit parameter map for APIs?

[Jim Crossley]

Granted, but the word bad seems harsh without any explanation, especially
if the common usage is to pass an empty map.


On Wed, Apr 30, 2014 at 11:18 AM, Alex Robbins 
alexander.j.robb...@gmail.com wrote:

 Maybe they want config in the least variance argument so it can be
 partial'ed?


 On Wed, Apr 30, 2014 at 10:03 AM, Jim Crossley j...@crossleys.org wrote:

 We used kwargs for options extensively in Immutant 1.x, and we're moving
 to explicit maps for Immutant 2.x, for the reasons cited above.

 It's not obvious to me why the bad release-sharks example on the coding
 standards page [1] is bad. Why should the optional config be the least
 variance argument?

 I had to look up laudable, btw. It's one of those good words that
 sounds bad. :)

 [1] http://dev.clojure.org/display/community/Library+Coding+Standards



 On Wed, Apr 30, 2014 at 6:14 AM, Colin Fleming 
 colin.mailingl...@gmail.com wrote:

 And thinking about it (after pressing send, of course), you'd get the
 same benefit from destructuring an explicit map in the function parameter
 anyway, wouldn't you?


 On 30 April 2014 22:11, Colin Fleming colin.mailingl...@gmail.comwrote:

 But that's only true for the variables which are explicitly
 destructured in the function definition, which in my experience many are
 not - they're often later picked out of an :as args argument, perhaps
 dependent on a combination of the parameters which are explicitly
 destructured. Seesaw never does this, for example. I think it's dangerous
 to rely on this rather than the documentation since it's often an
 incomplete view of what the function requires.

 Cheers,
 Colin


 On 30 April 2014 21:03, Joachim De Beule joachim.de.be...@gmail.comwrote:

 my two cents:

 The extra readability to users when using keyword args also comes from
 the fact that a function's options are explicit in its signature. So 
 during
 development, instead of having to look them up in the docs or in the code,
 my emacs mini-buffer simply shows them to me. Although I do agree with all
 the good reasons against keywords arguments, to me this is still the
 decisive reason to prefer them...

 Joachim

 Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves:

 On 30 April 2014 03:54, Sean Corfield se...@corfield.org wrote:

 I still think the keyword argument approach is far more readable to
 _users_


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


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

Re: Kwargs vs explicit parameter map for APIs?

[Jim Crossley]

Unless I'm missing something subtle, all of your points would hold if you
removed the  in your argument vector to turn your kwargs into an explicit
map, wouldn't they? One advantage is you'd be able to (apply f [m]), but
I'm not sure the :or logic would be any less troublesome.


On Wed, Apr 30, 2014 at 8:06 PM, Mark Engelberg mark.engelb...@gmail.comwrote:

 Here's the thing I can't stand about keyword args:

 Let's start off with a simple function that looks for keys x and y, and if
 either is missing,
 replaces the value with 1 or 2 respectively.

 (defn f [ {:keys [x y] :or {x 1 y 2}}]
   [x y])

 = (f :x 10)
 [10 2]

 So far, so good.

 Now, let's do an extremely simple test of composability.  Let's define a
 function g that destructures the keyword args, and if a certain keyword
 :call-f is set, then we're just going to turn around and call f, passing
 all the keyword args along to f.

 (defn g [ {call-f :call-f :as m}]
   (when call-f
 (apply f m)))

 = (g :call-f true :x 10)
 [1 2]

 What?  Oh right, you can't apply the function f to the map m.  This
 doesn't work.  If we want to apply f, we somehow need to apply it to a
 sequence of alternating keys and values, not a map.

 Take 2:

 (defn g [ {:keys [call-f x y] :as m}]
   (when call-f
 (f :x x :y y)))

 OK, so this time we try to workaround things by explicitly calling out the
 names of all the keywords we want to capture and pass along.  It's ugly,
 and doesn't seem to scale well to situations where you have an unknown but
 at first glance, it seems to work:

 = (g :call-f true :x 80 :y 20)
 [80 20]

 Or does it?

 = (g :call-f true :x 10)
 [10 nil]

 What is going on here?  Why is the answer coming out that :y is nil, when
 function f explicitly uses :or to have :y default to 2?

 The answer is that :or doesn't do what you think it does.  The word or
 implies that it substitutes the default value of :y any time the
 destructured :y is nil or false.  But that's not how it really works.  It
 doesn't destructure and then test against nil; instead the :or map only
 kicks in when :y is actually missing as a key of the map.

 This means that in g, when we actively destructured :y, it got set to a
 nil, and then that got passed along to f.  f's :or map didn't kick in
 because :y was set to nil, not absent.

 This is awful.  You can't pass through keyword arguments to other
 functions without explicitly destructuring them, and if you destructure
 them and pass them along explicitly, nil values aren't picked up as absent
 values, so the :or default maps don't work properly.

 To put it simply, keyword args are bad news for composability.

 It's a shame, and I'd love to see this improved (rather than just having
 the community give up on keyword arguments).

 --
 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: Kwargs vs explicit parameter map for APIs?

[Jim Crossley]

Oh, right. (f m) instead of (apply f [m]). Duh.


On Wed, Apr 30, 2014 at 11:15 PM, Colin Fleming colin.mailingl...@gmail.com
 wrote:

 I think it would because in that case you'd just pass your arg map
 straight through rather than having to reconstruct it. So if you weren't
 passed :y in g (in Mark's example), g wouldn't pass it on to f. By forcing
 the reconstruction of the map from explicit args, you're forced to use the
 value (incorrectly) destructured in g. Mark could work around it in his
 example by using (apply f (mapcat identity m)) in g, but it's far from
 intuitive.


 On 1 May 2014 15:04, Jim Crossley j...@crossleys.org wrote:

 Unless I'm missing something subtle, all of your points would hold if you
 removed the  in your argument vector to turn your kwargs into an explicit
 map, wouldn't they? One advantage is you'd be able to (apply f [m]), but
 I'm not sure the :or logic would be any less troublesome.


 On Wed, Apr 30, 2014 at 8:06 PM, Mark Engelberg mark.engelb...@gmail.com
  wrote:

 Here's the thing I can't stand about keyword args:

 Let's start off with a simple function that looks for keys x and y, and
 if either is missing,
 replaces the value with 1 or 2 respectively.

 (defn f [ {:keys [x y] :or {x 1 y 2}}]
   [x y])

 = (f :x 10)
 [10 2]

 So far, so good.

 Now, let's do an extremely simple test of composability.  Let's define a
 function g that destructures the keyword args, and if a certain keyword
 :call-f is set, then we're just going to turn around and call f, passing
 all the keyword args along to f.

 (defn g [ {call-f :call-f :as m}]
   (when call-f
 (apply f m)))

 = (g :call-f true :x 10)
 [1 2]

 What?  Oh right, you can't apply the function f to the map m.  This
 doesn't work.  If we want to apply f, we somehow need to apply it to a
 sequence of alternating keys and values, not a map.

 Take 2:

 (defn g [ {:keys [call-f x y] :as m}]
   (when call-f
 (f :x x :y y)))

 OK, so this time we try to workaround things by explicitly calling out
 the names of all the keywords we want to capture and pass along.  It's
 ugly, and doesn't seem to scale well to situations where you have an
 unknown but at first glance, it seems to work:

 = (g :call-f true :x 80 :y 20)
 [80 20]

 Or does it?

 = (g :call-f true :x 10)
 [10 nil]

 What is going on here?  Why is the answer coming out that :y is nil,
 when function f explicitly uses :or to have :y default to 2?

 The answer is that :or doesn't do what you think it does.  The word or
 implies that it substitutes the default value of :y any time the
 destructured :y is nil or false.  But that's not how it really works.  It
 doesn't destructure and then test against nil; instead the :or map only
 kicks in when :y is actually missing as a key of the map.

 This means that in g, when we actively destructured :y, it got set to a
 nil, and then that got passed along to f.  f's :or map didn't kick in
 because :y was set to nil, not absent.

 This is awful.  You can't pass through keyword arguments to other
 functions without explicitly destructuring them, and if you destructure
 them and pass them along explicitly, nil values aren't picked up as absent
 values, so the :or default maps don't work properly.

 To put it simply, keyword args are bad news for composability.

 It's a shame, and I'd love to see this improved (rather than just having
 the community give up on keyword arguments).

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

[ANN] Immutant 1.1.1 released

[Jim Crossley]

Hi all,

We released version 1.1.1 
today: http://immutant.org/news/2014/04/08/announcing-1-1-1/

We also released version 1.2.1 of the lein-immutant 
plugin: http://immutant.org/news/2014/04/08/lein-immutant-1-2-1/

Unless any bugs are reported against 1.1.1, we don't expect to release 
another in the 1.x series. We're now focusing our efforts on The Deuce:  
http://immutant.org/news/2014/04/02/the-deuce/

For those unfamiliar, Immutant is an application server for Clojure. It's 
an integrated platform built on JBoss AS7 that aims to reduce the 
incidental complexity in real-world applications. It provides support for 
Ring handlers, asynchronous messaging, caching, scheduled jobs, XA 
transactions, clustering, and daemons.

Immutant 2.x will be comprised of just libraries, one for each of the above 
services, embeddable within your standalone apps or deployable to a stock 
WildFly 8 (or EAP) app server.

Feel free to help or lurk: http://immutant.org/community/

Love,
Jim 

-- 
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: threading operators

[Jim Crossley]

Seen 
this? 
http://blog.jayfields.com/2012/09/clojure-refactoring-from-thread-last-to.html

On Friday, March 21, 2014 7:42:34 AM UTC-4, Andy Smith wrote:

 I have a chain of operations where i want to use a mixture of - and - 
 (i.e. some functions expect the previous result to be fed into the second 
 item in its sexpr and some expecting it as the last item of its sexpr. What 
 is the neatest way to chain such functions together. perhaps I should write 
 a macro to swap the second and last items of a form?

 Andy


-- 
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: Creating multi-module projects with dependencies between modules

[Jim Crossley]

Hi again David,

I just released lein-modules 0.2.1 that hopefully addresses your concerns:

1) Dependency symbols in the :versions map are more lenient now. You can 
use either the group id or the artifact id by itself.
2) You exposed a bug where versions for dependencies specified in the 
:inherited profile (or directly on the project) weren't being resolved 
correctly. Fixed now.
3) I updated the README to emphasize the requirement that 'lein modules 
install' must be run before attempting any other task. I confirmed that 
Maven projects work the exact same way.

Thanks for the feedback,
Jim

On Monday, March 17, 2014 11:19:37 PM UTC-4, Dave Kincaid wrote:

 Thanks, I'll try to show you what I have pieced together from your example 
 and the immutant project. Right now I'm just trying to make it work, so I 
 just have a project with 2 modules. There is lambda-common and lambda-etl. 
 lambda-etl should depend on lambda-common. When I run something like lein 
 modules deps or lein modules javac I get the following output:

 Could not find artifact lambda-common-module:lambda-common-module:jar:_ in 
 central (http://repo1.maven.org/maven2/)
 Could not find artifact lambda-common-module:lambda-common-module:jar:_ in 
 clojars (https://clojars.org/repo/)
 This could be due to a typo in :dependencies or network issues.
 If you are behind a proxy, try setting the 'http_proxy' environment 
 variable.
 Error encountered performing task 'deps' with profile(s): 
 'inherited,default'
 Could not resolve dependencies

 Here are the relevant files:

 project.clj in root of project:
 (def version 0.1.0-SNAPSHOT)

 (defproject lambda-clj version
   :description 
   :packaging pom
   :profiles {:dev {:dependencies [[midje/midje _]]}}

   :modules {:inherited
 {:source-paths [src/clj]
  :java-source-paths [src/java]
  :test-paths [test/clj test/java]
  :dependencies [[org.clojure/clojure _]
 [com.taoensso/timbre _]]}

 :versions {org.clojure/clojure 1.5.1
midje/midje 1.6.3
com.taoensso/timbre 3.1.6

:lambda-clj 0.1.0-SNAPSHOT

lambda-common-module :lambda-clj}}

   :codox {:sources [lambda-common/src
 lambda-etl/src]})

 lambda-common module project.clj:
 (def lambda-version 0.1.0-SNAPSHOT)

 (defproject lambda-common-module lambda-version
   :description 
   :parent [lambda-clj _ :relative-path ../pom.xml]
   :dependencies [[org.apache.thrift/libthrift 0.9.0]]
   :thrift-source-path build-support/thrift
   :thrift-java-path src/java
   :thrift-opts beans,hashcode)

 lambda-etl module project.clj:
 (def lambda-version 0.1.0-SNAPSHOT)

 (defproject lambda-etl-module lambda-version
   :description 
   :parent [lambda-clj _ :relative-path ../pom.xml]
   :dependencies [[lambda-common-module _]])

 Thanks for taking a look.

 On Monday, March 17, 2014 10:11:15 PM UTC-5, Jim Crossley wrote:

 Hi Dave,

 Inter-module deps should be supported by lein-modules. I have plenty of 
 them in the immutant source tree. The test-resources dir in the 
 lein-modules source has some examples of parent/child/sibling deps, but 
 they're pretty contrived. If you can describe the structure of your 
 projects or point me to them if public, and tell me what you tried that 
 didn't work, I can try to get you going.

 Jim


 On Mon, Mar 17, 2014 at 10:55 PM, Dave Kincaid kincai...@gmail.comwrote:

 I'm trying to create a project with multiple modules where there are 
 some dependencies between modules. So far I've tried out lein-sub and 
 lein-modules but neither one seems to handle inter-module dependencies 
 (either that or I just can't figure out how to do it). What are people 
 using for projects like this? Any open source examples I could look at?

 Thanks,

 Dave

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

Re: Creating multi-module projects with dependencies between modules

[Jim Crossley]

Hi Dave,

Inter-module deps should be supported by lein-modules. I have plenty of
them in the immutant source tree. The test-resources dir in the
lein-modules source has some examples of parent/child/sibling deps, but
they're pretty contrived. If you can describe the structure of your
projects or point me to them if public, and tell me what you tried that
didn't work, I can try to get you going.

Jim


On Mon, Mar 17, 2014 at 10:55 PM, Dave Kincaid kincaid.d...@gmail.comwrote:

 I'm trying to create a project with multiple modules where there are some
 dependencies between modules. So far I've tried out lein-sub and
 lein-modules but neither one seems to handle inter-module dependencies
 (either that or I just can't figure out how to do it). What are people
 using for projects like this? Any open source examples I could look at?

 Thanks,

 Dave

 --
 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] lein-modules 0.2.0

[Jim Crossley]

What is lein-modules?

A leiningen plugin providing support for project aggregation, letting
you define parent-child relationships between projects to achieve
interdependence-based build ordering, project inheritance based on
leiningen profiles, and centralized dependency management.

What's in this release?

- The :inherited profile is no longer special, though it will be
  merged in before :default, if present. All profiles defined in
  ancestors are now added to the child project and [un]merged as
  appropriate for the task.

- Profiles active in the parent should now be propagated to each child
  when running the 'modules' higher-order task unless
  'with-profile[s]' is among its arguments. In short,
  'with-profile[s]' should do The Right Thing, whether it appears to
  the left or the right of 'modules' in your command.

- By default, each child module's task is now run in a subprocess, but
  you can override this with the new [:modules :subprocess] boolean.
  When false, all child module tasks are run in the parent's process,
  like before. This is fine for most tasks, but it can lead to
  surprises when say, one of your child modules is a plugin, or you
  have incompatible hooks in your child modules, or when hooks/plugins
  make assumptions about the current directory. Leiningen itself is
  pretty good about absolutizing paths and relying on (:root
  project) rather than the working directory.

More details and an example available at
https://github.com/jcrossley3/lein-modules

For another example, I recently pushed my lein-ization of Immutant
to its master branch. Somewhat disturbingly, it can now be built with
*either* Maven or Leiningen. But I'm not advocating that. :)

Love,
Jim

-- 
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/groups/opt_out.

[ANN] lein-modules 0.1.0 - multi-module support in Leiningen

[Jim Crossley]

Maven multi-module projects provide support for project aggregation, 
letting you define parent-child relationships among a group of projects to 
achieve interdependence-based build ordering, limited project inheritance, 
and centralized dependency management.

Maven's pom.xml files are verbose, error-prone, and just generally gross, 
especially for multi-module projects, so I wanted to see if I could provide 
the above features using Leiningen. The fruit of my labor thus far is this 
plugin:

   https://github.com/jcrossley3/lein-modules

Project inheritance is achieved using Leiningen profiles. This is more 
flexible than Maven, where the values subject to inheritance are 
hard-coded. And profiles defined in your project's ancestors are activated 
appropriately for each task, as you would expect.

Dependency management is a lot simpler, too: it's just a map of dependency 
symbols to version strings, from which your dependency specs are populated 
by Leiningen middleware.

See the README for more details and an example.

Love,
Jim

-- 
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/groups/opt_out.

Re: [ANN] lein-modules 0.1.0 - multi-module support in Leiningen

[Jim Crossley]

I've not used lein-voom, but from a brief glance at its README, it seems to
be an attempt at solving the SNAPSHOT problem, i.e. the nightmare of
multiple interdependent projects living in different git repos all under
active development by multiple collaborators.

The scope of lein-modules is smaller: it's about organizing your code
within a single git repo. With lein-modules, you can organize it as
interdependent Leiningen projects. For example, you might have a
multi-module project that builds an bizbaz.war and another that builds an
admin.war and another that builds the bizbaz.jar containing the business
logic shared by the first two. So you clone their repo locally, containing
all three modules each with its own project.clj, and you can either build
'em all in one shot from the root or just work on one at a time. Either
way, your common config for all three is maintained in one place: the
parent project.clj.

Hope that helps,
Jim


On Mon, Feb 10, 2014 at 3:42 PM, dgrnbrg dsg123456...@gmail.com wrote:

 Could you compare lein-modules with lein-voom? I can see that they have
 different features, but I'm trying get a handle on when each might be
 appropriate.

 This looks like a great tool for large projects. Thank you!


 On Monday, February 10, 2014 9:36:13 AM UTC-5, Jim Crossley wrote:

 Maven multi-module projects provide support for project aggregation,
 letting you define parent-child relationships among a group of projects to
 achieve interdependence-based build ordering, limited project inheritance,
 and centralized dependency management.

 Maven's pom.xml files are verbose, error-prone, and just generally gross,
 especially for multi-module projects, so I wanted to see if I could provide
 the above features using Leiningen. The fruit of my labor thus far is this
 plugin:

https://github.com/jcrossley3/lein-modules

 Project inheritance is achieved using Leiningen profiles. This is more
 flexible than Maven, where the values subject to inheritance are
 hard-coded. And profiles defined in your project's ancestors are activated
 appropriately for each task, as you would expect.

 Dependency management is a lot simpler, too: it's just a map of
 dependency symbols to version strings, from which your dependency specs are
 populated by Leiningen middleware.

 See the README for more details and an example.

 Love,
 Jim

  --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [ANN] lein-modules 0.1.0 - multi-module support in Leiningen

[Jim Crossley]

I didn't communicate this as well as I would've liked, probably due to 
overloaded terminology.

The contrived example multi-module project would generate 3 artifacts. 
And the source code for those artifacts would be contained within 3 
Leiningen projects, which I refer to as modules to avoid the confusion 
of also identifying the git repo as a project.

So one git repo, identified as a conceptual project, would be organized as 
3 Leiningen projects, aka modules.

I hope I didn't make things worse,
Jim

On Monday, February 10, 2014 5:31:27 PM UTC-5, Jim Crossley wrote:

 I've not used lein-voom, but from a brief glance at its README, it seems 
 to be an attempt at solving the SNAPSHOT problem, i.e. the nightmare of 
 multiple interdependent projects living in different git repos all under 
 active development by multiple collaborators.

 The scope of lein-modules is smaller: it's about organizing your code 
 within a single git repo. With lein-modules, you can organize it as 
 interdependent Leiningen projects. For example, you might have a 
 multi-module project that builds an bizbaz.war and another that builds an 
 admin.war and another that builds the bizbaz.jar containing the business 
 logic shared by the first two. So you clone their repo locally, containing 
 all three modules each with its own project.clj, and you can either build 
 'em all in one shot from the root or just work on one at a time. Either 
 way, your common config for all three is maintained in one place: the 
 parent project.clj.

 Hope that helps,
 Jim


 On Mon, Feb 10, 2014 at 3:42 PM, dgrnbrg dsg123...@gmail.comjavascript:
  wrote:

 Could you compare lein-modules with lein-voom? I can see that they have 
 different features, but I'm trying get a handle on when each might be 
 appropriate.

 This looks like a great tool for large projects. Thank you!


 On Monday, February 10, 2014 9:36:13 AM UTC-5, Jim Crossley wrote:

 Maven multi-module projects provide support for project aggregation, 
 letting you define parent-child relationships among a group of projects to 
 achieve interdependence-based build ordering, limited project inheritance, 
 and centralized dependency management.

 Maven's pom.xml files are verbose, error-prone, and just generally 
 gross, especially for multi-module projects, so I wanted to see if I could 
 provide the above features using Leiningen. The fruit of my labor thus far 
 is this plugin:

https://github.com/jcrossley3/lein-modules

 Project inheritance is achieved using Leiningen profiles. This is more 
 flexible than Maven, where the values subject to inheritance are 
 hard-coded. And profiles defined in your project's ancestors are activated 
 appropriately for each task, as you would expect.

 Dependency management is a lot simpler, too: it's just a map of 
 dependency symbols to version strings, from which your dependency specs are 
 populated by Leiningen middleware.

 See the README for more details and an example.

 Love,
 Jim

  -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.comjavascript:
 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/groups/opt_out.




-- 
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/groups/opt_out.

Re: Clojure web server benchmarks

[Jim Crossley]

I just submitted a PR to include Immutant in the benchmarks, per a request 
from Chas on Twitter, and then I noticed Shantanu filed an issue to include 
Undertow, so I created a PR for it, too, since Immutant 2.x will be based 
on it.

The tl;dr is that Immutant performs a little worse than the :gen-class 
servlets included in the benchmarks, and a little better than the Jetty 
Ring Adapter, which is about what I'd expect. Undertow's numbers are just a 
skosh below http-kit, and can probably even be improved since the adapter's 
dep is about 20 betas behind the current release.

Jim

On Tuesday, January 14, 2014 8:39:13 AM UTC-5, Xfeep Zhang wrote:

 You 're right!

 ab has many limitations.

 Maybe httpload , wrk, Weighttp or ABs  ( several instances of AB)  are 
 better when test client and server do not run on the same computer.

 On Tuesday, January 14, 2014 5:52:59 PM UTC+8, Feng Shen wrote:

 Hi,  nginx-clojure looks great!

 A small tip: ab may not be the best tool, since it's single threaded.   A 
 better tool is wrk:  https://github.com/wg/wrk

 You can use wrk to better test nginx-clojure,  It should perform even 
 better than others.




 沈锋
 http://shenfeng.me


 On Tue, Jan 14, 2014 at 5:26 PM, Peter Taoussanis ptaou...@gmail.comwrote:

 Oh wow, that's fantastic!

 For those watching: Xfeep's fixed a number of config issues, updated all 
 the servers, and completely updated the chart.

 Absolutely well worth a look if you're interested in Clojure web server 
 performance.

 * Results are here: 
 https://github.com/ptaoussanis/clojure-web-server-benchmarks
 * His GitHub page: https://github.com/xfeep
 * His nginx/clojure lib: https://github.com/xfeep/nginx-clojure

 Cheers! :-)

 -- 
 *Peter Taoussanis*
  
 -- 
 -- 
 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/UrRLCdex7d4/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/groups/opt_out.




-- 
-- 
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/groups/opt_out.

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Jim Crossley]

Prasanna, Ryan and Justin,

Hi. I just got around to playing with Caribou today. Very nice!

I was happy to see you including Immutant config in the application
template, but you don't need it. Immutant will happily bootstrap a deployed
app using the :ring options map in project.clj. As long as you're including
that, the immutant.clj file in the application template is redundant.
Here's more info:
http://immutant.org/builds/LATEST/html-docs/initialization.html#initialization-porting

And I agree removing the immutant dependency in project.clj will greatly
reduce the number of downloaded jars. Technically, you only need that
dependency in project.clj when running *outside* of the Immutant container,
e.g. when your tests refer to the immutant namespaces.

The only other Immutant-related feedback I might offer is wrt the assets
dir, app/. Relative paths like that are only gonna work if you start up
Immutant in your project's directory, so in production you'll likely want
that to be an absolute path.

I especially like the project's name. It reminds me of the Pixies song:
https://www.youtube.com/watch?v=x6m-pwWCDKU

Thanks!
Jim


On Wed, Nov 13, 2013 at 1:25 AM, Ryan Spangler ryan.spang...@gmail.comwrote:

 Justin,

 As far as I know, Immutant is not a dependency, but an option.  Let me
 know if that is not true however.


 On Tuesday, November 12, 2013 10:13:17 PM UTC-8, Justin Smith wrote:

 Typically my first step making a caribou app is to remove the immutant
 dependency. It's pretty straightforward to take it out.

 On Tuesday, November 12, 2013 9:19:27 PM UTC-8, Prasanna Gautam wrote:

 This is really cool. Very easy to get up and running for first try. I
 have a few questions on the architecture.

 Why Immutant instead of plain ring as the default? I think the number of
 dependencies could be much lower with it.

 I know it's only alpha.. but I'm asking this on behalf of others who
 might be thinking the same.
 And, are there plans for NoSQL database support, like MongoDB, MapDB (
 http://www.mapdb.org/ - I just found out about it myself but this is
 the only decent in-memory NoSQL solution other than Berkeley DB)?

 On Tuesday, November 12, 2013 6:52:10 PM UTC-5, Ryan Spangler wrote:

 Hello Clojure,

 Excited to announce today the release of Caribou!
 http://let-caribou.in/

 We have been building web sites and web applications with it for over
 two years now and improving it every day.  Currently we have four people
 working on it and another ten using it to build things, so it is getting a
 lot of real world testing.

 It has been designed as a collection of independent libraries that
 could each be useful on their own, but which come together as a meaningful
 whole.

 We have been spending the last couple months getting it ready for a
 full open source release, and I am happy to say it is finally ready.
  Funded and supported by Instrument in Portland, OR:
 http://weareinstrument.com/  We have four projects using it in
 production, and several more about to be launched (as well as over a dozen
 internal things).

 Documentation is here:  http://caribou.github.io/
 caribou/docs/outline.html

 Source is here:  http://github.com/caribou/caribou (use this for
 issues, you don't actually need the source as it is installed through a
 lein template).

 Some of the independently useful libraries Caribou is built on are:

 * Polaris -- Routing with data (not macros) and reverse routing! :
 https://github.com/caribou/polaris
 * Lichen -- Image resizing to and from s3 or on disk:
 https://github.com/caribou/lichen
 * Schmetterling -- Debugging Clojure processes from the browser:
 https://github.com/prismofeverything/schmetterling
 * Antlers -- Useful extensions to mustache templating (helpers and
 blocks, among other things):  https://github.com/caribou/antlers
 * Groundhog -- Replay http requests: https://github.com/
 noisesmith/groundhog

 And many others.

 Basically this is an Alpha release, and I am announcing it here first
 in order to get as much feedback from the community as possible.  We have
 made it as useful as we can for our purposes and recognize that for it to
 improve from here, we really need as many people using it and building
 things with it as possible.  The documentation also needs to be put through
 its paces:  we need to see how well people are able to use it who know
 nothing about it, based only on the existing docs.

 All feedback welcome!

 Thanks for reading!  I hope you find it useful.

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

Multi-arity protocol methods implemented in different maps

[Jim Crossley]

I'm guessing this is either impossible or I'm missing something obvious. 
Say I have this:

  (defprotocol X
(foo [x] [x y]))

For the sake of implementation inheritance, I'd like to define one of the 
arities in map x1:

  (def x1 {:foo (fn [x] x1)})

And the other arity in x2:

  (def x2 {:foo (fn [x y] x2)})

Is there any way I can merge those two guys to extend them both to type T?

  (extend T
X
(merge-with ??? x1 x2))

Or something else?

Thanks,
Jim

-- 
-- 
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/groups/opt_out.

Re: Clojure Jruby (Ruby on Rails) Interop

[Jim Crossley]

Unfortunately not, Rodrigo. Frankly, TorqueBox on OpenShift is not a very
happy experience, mostly due to bundler and very limited resources on the
free OpenShift gears. Until we get those issues worked out, I don't want to
encourage anyone to combine TB and Immutant on OpenShift.

Also, we're kinda in a wait-and-see mode while the OpenShift guys integrate
Docker, as container images should be a lot easier to work with than
cartridges.

So you're ahead of us at the moment. We expect to catch up, just not sure
when.

Jim



On Thu, Oct 24, 2013 at 8:45 PM, rdelcueto rdelcu...@gmail.com wrote:

 Dear Jim,

 I just began playing with Immutant and TorqueBox.
 I realized the polyglot-openshift-quickstart* @ *GitHub is marked as
 obsolete. I found links to newer versions of immutant-quickstart and
 torquebox-quickstart, though as separate applications.
 Is there documentation or a tutorial on how to get TorqueBox and Immutant
 merged into a single OpenShift application, ala lein immutant overlay
 torquebox?

 Regards,


 On Monday, September 9, 2013 11:14:54 AM UTC-5, Jim Crossley wrote:

 Hi Rodrigo,

 I'm one of the developers of TorqueBox and Immutant. Your email prompted
 me to re-watch a screencast [1] I made in March showing how to use them
 together. I realized things have changed a little since then, so I added a
 few annotations to the video highlighting the differences. Hopefully enough
 to get you up and experimenting.

 As you've probably figured out, both TorqueBox and Immutant are
 integrated stacks, bundling some commodity services that most non-trivial
 applications need, e.g. scheduling, caching, and messaging. The intent of
 any integrated platform is to relieve administration burden. But that only
 works for you if the inherent choices within that stack fit the needs of
 your app. We think/hope default Immutant configuration and abstractions
 (e.g. queues, topics, request/respond) offers a good balance to fit a wide
 variety of apps.

 If simple integration between Ruby and Clojure apps is your chief goal, I
 think Immutant/TorqueBox is compelling, but I'm biased. I would definitely
 recommend using some sort of messaging broker, though, i.e. don't mix
 Clojure and Ruby in the same source file or project.

 Performance and security concerns are so application-specific I hate to
 make any generic statements about them other than, be fast and secure. ;-)

 But do feel free to bother us in #torquebox or #immutant on freenode with
 any questions about your particular app/needs.

 Thanks,
 Jim

 [1] 
 http://immutant.org/news/**2013/03/07/overlay-screencast/http://immutant.org/news/2013/03/07/overlay-screencast/



 On Sun, Sep 8, 2013 at 10:25 PM, rdelcueto rdel...@gmail.com wrote:

 Hi everyone,
 I'm about to start working on building a site for a startup company.

 We are a small team, and currently they've been coding the site using
 RoR (Ruby on Rails). I was thinking Clojure might be better suited for the
 task, specially because we'll need to implement a backend which is robust,
 scalable and secure, but also we'll need flexibility, which I think the RoR
 framework won't shine at all.

 At our team, we are two coders, non of us are proficient in Web
 Developing, and we have little experience with RoR, and I thought (I'm
 sure) maybe investing time learning Clojure will provide us with better
 tools.

 PROBLEM/QUESTION

 While searching for alternative solutions, I stumbled upon the
 Flightcaster case, we're they are using RoR to implement the site's
 frontend and Clojure for the system backend. I thought this was a very
 elegant solution, using each tool for what it's good at. Plus this way we
 can reuse what they've already implemented.

 I found a way to do this is by using Torquebox and Immutant, and using
 the messaging systems to communicate between Jruby and Clojure. Still I
 have no idea of how this works, and the performance and security
 implications it brings to the table. I found little information on the
 subject.

 I would appreciate if anyone could provide guidance, examples or
 documentation on the subject.

 Any reference to open source projects which use this hybrid language
 solutions on the JVM would be great to have.

 Is this the best way to solve the RoR interactions? Is there any other
 way?

 Thanks in advance and best regards,

 Rodrigo

 --
 --
 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=enhttp://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send

Re: Clojure Jruby (Ruby on Rails) Interop

[Jim Crossley]

Hi Rodrigo,

I'm one of the developers of TorqueBox and Immutant. Your email prompted me
to re-watch a screencast [1] I made in March showing how to use them
together. I realized things have changed a little since then, so I added a
few annotations to the video highlighting the differences. Hopefully enough
to get you up and experimenting.

As you've probably figured out, both TorqueBox and Immutant are integrated
stacks, bundling some commodity services that most non-trivial applications
need, e.g. scheduling, caching, and messaging. The intent of any integrated
platform is to relieve administration burden. But that only works for you
if the inherent choices within that stack fit the needs of your app. We
think/hope default Immutant configuration and abstractions (e.g. queues,
topics, request/respond) offers a good balance to fit a wide variety of
apps.

If simple integration between Ruby and Clojure apps is your chief goal, I
think Immutant/TorqueBox is compelling, but I'm biased. I would definitely
recommend using some sort of messaging broker, though, i.e. don't mix
Clojure and Ruby in the same source file or project.

Performance and security concerns are so application-specific I hate to
make any generic statements about them other than, be fast and secure. ;-)

But do feel free to bother us in #torquebox or #immutant on freenode with
any questions about your particular app/needs.

Thanks,
Jim

[1] http://immutant.org/news/2013/03/07/overlay-screencast/



On Sun, Sep 8, 2013 at 10:25 PM, rdelcueto rdelcu...@gmail.com wrote:

 Hi everyone,
 I'm about to start working on building a site for a startup company.

 We are a small team, and currently they've been coding the site using RoR
 (Ruby on Rails). I was thinking Clojure might be better suited for the
 task, specially because we'll need to implement a backend which is robust,
 scalable and secure, but also we'll need flexibility, which I think the RoR
 framework won't shine at all.

 At our team, we are two coders, non of us are proficient in Web
 Developing, and we have little experience with RoR, and I thought (I'm
 sure) maybe investing time learning Clojure will provide us with better
 tools.

 PROBLEM/QUESTION

 While searching for alternative solutions, I stumbled upon the
 Flightcaster case, we're they are using RoR to implement the site's
 frontend and Clojure for the system backend. I thought this was a very
 elegant solution, using each tool for what it's good at. Plus this way we
 can reuse what they've already implemented.

 I found a way to do this is by using Torquebox and Immutant, and using the
 messaging systems to communicate between Jruby and Clojure. Still I have no
 idea of how this works, and the performance and security implications it
 brings to the table. I found little information on the subject.

 I would appreciate if anyone could provide guidance, examples or
 documentation on the subject.

 Any reference to open source projects which use this hybrid language
 solutions on the JVM would be great to have.

 Is this the best way to solve the RoR interactions? Is there any other way?

 Thanks in advance and best regards,

 Rodrigo

 --
 --
 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/groups/opt_out.


-- 
-- 
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/groups/opt_out.

[ANN] Immutant 1.0.1 released

[Jim Crossley]

Hi all,

We addressed the bugs reported against 1.0.0, improved our Leiningen 
integration, and added some minor enhancements to our messaging and cache 
namespaces.

I've also bumped the OpenShift Immutant cartridge version to 1.0.1.

Details here:  http://bit.ly/imm101

Thanks,
Jim
 

-- 
-- 
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/groups/opt_out.

Re: [ANN] Immutant 1.0.0 released

[Jim Crossley]

Here you go, Sean: http://immutant.org/news/2013/08/20/openshift-clustering/

Feedback appreciated!

Jim

On Thursday, August 1, 2013 1:22:05 PM UTC-4, Sean Corfield wrote:

 Great news! Every conference I've been to lately, I've been bugging 
 the OpenShift guys - I know they have been rewriting the cartridge 
 spec so I'm glad to hear an Immutant cartridge is coming. Once that 
 cartridge is available, I'll have a play with it (I don't have time 
 right now to do anything that isn't standard / turn key). 

 Sean 

 On Thu, Aug 1, 2013 at 9:48 AM, Jim Crossley 
 j...@crossleys.orgjavascript: 
 wrote: 
  Nice timing, Sean! :-) 
  
  On Wednesday, I was able to finally get Immutant clustering successfully 
 on 
  OpenShift. Load-balanced messaging and web, failover for daemons and 
 jobs, 
  replication for caching, everything seems to work. This is with both 
 HornetQ 
  and Infinispan using JGroups so automatic peer discovery just works when 
 I 
  add a gear. I'm now working on the cartridge, though the quickstart will 
  work (with a slight modification I need to push) if you want to play 
 with it 
  now. 
  
  I'll blog about it soon. 
  
  Jim 
  
  
  On Thu, Aug 1, 2013 at 12:32 PM, Sean Corfield 
  seanco...@gmail.comjavascript: 

  wrote: 
  
  Excellent! I look forward to trying this! 
  
  Any plans for a Clojure / Immutant cartridge for OpenShift? 
  
  Sean 
  
  On Wed, Jul 31, 2013 at 1:49 PM, Jim Crossley 
  jcros...@gmail.comjavascript: 

  wrote: 
   Today we finally released Immutant 1.0.0! 
   
   Read about it here: http://bit.ly/imm100 
   
   For those unfamiliar, Immutant is an application server for Clojure. 
   It's an 
   integrated platform providing web, messaging, caching, scheduling, XA 
   transactions, clustering, and daemons built on JBoss AS7 that aims to 
   reduce 
   the incidental complexity found in real-world applications. 
   
   Have fun! 
   Jim 
   
   -- 
   -- 
   You received this message because you are subscribed to the Google 
   Groups Clojure group. 
   To post to this group, send email to 
   clo...@googlegroups.comjavascript: 
   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/groups/opt_out. 
   
   
  
  
  
  -- 
  Sean A Corfield -- (904) 302-SEAN 
  An Architect's View -- http://corfield.org/ 
  World Singles, LLC. -- http://worldsingles.com/ 
  
  Perfection is the enemy of the good. 
  -- Gustave Flaubert, French realist novelist (1821-1880) 
  
  -- 
  -- 
  You received this message because you are subscribed to the Google 
  Groups Clojure group. 
  To post to this group, send email to clo...@googlegroups.comjavascript: 
  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/groups/opt_out. 
  
  
  
  -- 
  -- 
  You received this message because you are subscribed to the Google 
  Groups Clojure group. 
  To post to this group, send email to clo...@googlegroups.comjavascript: 
  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/groups/opt_out. 
  
  



 -- 
 Sean A Corfield -- (904) 302-SEAN 
 An Architect's View -- http://corfield.org/ 
 World Singles, LLC. -- http://worldsingles.com/ 

 Perfection is the enemy of the good. 
 -- Gustave Flaubert, French realist novelist (1821-1880) 


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

[ANN] Immutant 1.0.0 released

[Jim Crossley]

Today we finally released Immutant 1.0.0!

Read about it here: http://bit.ly/imm100

For those unfamiliar, Immutant is an application server for Clojure. It's 
an integrated platform providing web, messaging, caching, scheduling, XA 
transactions, clustering, and daemons built on JBoss AS7 that aims to 
reduce the incidental complexity found in real-world applications.

Have fun!
Jim

-- 
-- 
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/groups/opt_out.

Re: [ANN] Immutant 1.0.0 released

[Jim Crossley]

Nice timing, Sean! :-)

On Wednesday, I was able to finally get Immutant clustering successfully on
OpenShift. Load-balanced messaging and web, failover for daemons and jobs,
replication for caching, everything seems to work. This is with both
HornetQ and Infinispan using JGroups so automatic peer discovery just works
when I add a gear. I'm now working on the cartridge, though the quickstart
will work (with a slight modification I need to push) if you want to play
with it now.

I'll blog about it soon.

Jim


On Thu, Aug 1, 2013 at 12:32 PM, Sean Corfield seancorfi...@gmail.comwrote:

 Excellent! I look forward to trying this!

 Any plans for a Clojure / Immutant cartridge for OpenShift?

 Sean

 On Wed, Jul 31, 2013 at 1:49 PM, Jim Crossley jcrossl...@gmail.com
 wrote:
  Today we finally released Immutant 1.0.0!
 
  Read about it here: http://bit.ly/imm100
 
  For those unfamiliar, Immutant is an application server for Clojure.
 It's an
  integrated platform providing web, messaging, caching, scheduling, XA
  transactions, clustering, and daemons built on JBoss AS7 that aims to
 reduce
  the incidental complexity found in real-world applications.
 
  Have fun!
  Jim
 
  --
  --
  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/groups/opt_out.
 
 



 --
 Sean A Corfield -- (904) 302-SEAN
 An Architect's View -- http://corfield.org/
 World Singles, LLC. -- http://worldsingles.com/

 Perfection is the enemy of the good.
 -- Gustave Flaubert, French realist novelist (1821-1880)

 --
 --
 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/groups/opt_out.




-- 
-- 
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/groups/opt_out.

[ANN] Immutant is now officially in beta!

[Jim Crossley]

We released Immutant 1.0.0.beta1 today! We're pretty excited about this 
milestone because we've been yapping about doing it for a few months now. 
So, finally... yay! :)

Read all about it here: http://bit.ly/immutant1b1

We released 1.0.0.beta1 of the lein-immutant plugin, 
too: http://immutant.org/news/2013/05/29/lein-immutant-1-0-0-beta1/

It's been almost two years since we started working on Immutant. And we 
very much appreciate all the support and encouragement we've received from 
the Clojure community. We're looking forward to getting a final release out 
this summer and then moving on to incorporate the new features from JBoss 
Wildfly (ahem, upgrade-able websockets) in subsequent versions.

# What is Immutant? 

Immutant is an application server for Clojure. It's an integrated platform 
built on JBoss AS7 that aims to reduce the incidental complexity in 
real-world applications. It provides support for Ring handlers, 
asynchronous messaging, caching, scheduled jobs, XA transactions, 
clustering, and highly-available daemon services. 

Thanks,
Jim

-- 
-- 
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/groups/opt_out.

[ANN] Immutant 0.10.0 released

[Jim Crossley]

Well, we had hoped to begin our 1.0 beta cycle with this release, but we 
decided we changed enough stuff that we wanted to put out one more alpha 
first, mainly because we think it's wrong to introduce any API changes with 
the first beta.

The details of what we changed are here: http://bit.ly/immutant0100

Big items on the horizon are ritz integration, zero-downtime deploys, and 
our old friend, websockets, but we likely won't hold up the beta for those.
 
# What is Immutant? 

Immutant is an application server for Clojure. It's an integrated platform 
built on JBoss AS7 that aims to reduce the incidental complexity in 
real-world applications. It provides support for Ring handlers, 
asynchronous messaging, caching, scheduled jobs, XA transactions, 
clustering, and highly-available daemon services. 

Thanks,
Jim

-- 
-- 
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/groups/opt_out.

[ANN] Immutant 0.9.0 released

[Jim Crossley]

Hi all,

We released Immutant 0.9.0 a few minutes ago, which features a much
smaller distribution size, sharing caches with TorqueBox, a friendlier
API for scheduling recurring jobs, and more stuff described here:
http://bit.ly/immutant090

Toby and I will be at Clojure/West, I think doing an unsession, so
please grab us if you want to chat about Immutant or whatever else.

# What is Immutant? 

Immutant is an application server for Clojure. It's an integrated
platform built on JBoss AS7 that aims to reduce the incidental
complexity in real-world applications. It provides support for Ring
handlers, asynchronous messaging, caching, scheduled jobs, XA
transactions, clustering, and highly-available daemon services.

Peace, Love, and Oysters,
Jim

-- 
-- 
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/groups/opt_out.

[ANN] Immutant 0.8.0 released

[Jim Crossley]

We released Immutant 0.8.0 today, which includes our new Pipelines library, 
persistent caches, and some minor features relating to web apps and 
testing. We didn't break any API's from 0.7.0, so hey, progress!

More details at http://immutant.org/news/2013/01/14/announcing-0-8-0/

# What is Immutant? 

Immutant is an application server for Clojure. It's an integrated platform 
built on JBoss AS7 that aims to reduce the incidental complexity in 
real-world applications. It provides support for Ring handlers, 
asynchronous messaging, caching, scheduled jobs, XA transactions, 
clustering, and highly-available daemon services. 

Peace, Love, and Pancakes,
Jim

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

Re: Slime and heroku setup question

[Jim Crossley]

FWIW, direct socket access via an ssh tunnel is allowed on OpenShift, so
connecting to the remote REPL (either nREPL or Swank) is simple and
requires no HTTP transport, but all of Phil's general advice regarding
the remote disk applies there, too.

For an example, see http://immutant.org/news/2012/12/11/openshift-postgresql/

Jim

Phil Hagelberg p...@hagelb.org writes:

 On Tue, Dec 11, 2012 at 6:55 PM, Jonathon McKitrick
 jmckitr...@gmail.com wrote:
 Well, I've used slime with SBCL for quite a while, but this is my first
 foray into clojure and heroku.  Are you basically saying the best approach
 is just to edit locally, push to heroku, and run?

 I suppose if you ensure everything gets required when you boot your
 app and you limit yourself to commands which operate on the region
 rather than loading from disk (and avoid reloads) then you should be
 fine. It's just easy to get into an inconsistent state between what's
 on disk locally and what's in memory during any repl-driven
 development; throwing in a third factor of the remote disk just adds
 more room for error.

 -Phil

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

[ANN] Immutant 0.7.0 released

[Jim Crossley]

We released Immutant 0.7.0 today, along with 0.14.0 of the lein-immutant 
plugin. It's mostly bug fixes and docs, but a couple of changes may break 
you: 

* We did away with the immutant.clj initialization file. Instead, we look 
on the classpath for an 'immutant.init' namespace.  
* We now evaluate the forms in deployment descriptors, so any symbols in 
there should probably be quoted.

More details at http://bit.ly/immutant070

# Clojure/Conj 

Toby and I had a great time at the Conj and received some nice feedback. 
I'm getting a handle [1] on OpenShift at the moment and hope to blog soon 
about deploying the Poorsmatic [2] app presented in my talk there, 
connecting to it via an nREPL server through an ssh tunnel, and enjoying 
the clustering advantages I demonstrated without incurring the 
multicast-less configuration headaches of the cloud.

And no, even in light of their widely-publicized hiring efforts, I've yet 
to hear from a Prismatic recruiter. ;-)
 
# What is Immutant? 

Immutant is an application server for Clojure. It's an integrated platform 
built on JBoss AS7 that aims to reduce the incidental complexity in 
real-world applications. It provides support for Ring handlers, 
asynchronous messaging, caching, scheduled jobs, XA transactions, 
clustering, and highly-available daemon services. 

Let us know if you have any questions or issues,
Jim

[1] https://github.com/immutant/openshift-quickstart
[2] https://github.com/jcrossley3/poorsmatic

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

Re: ANN: cronj - task scheduling

[Jim Crossley]

Hi,

Cool lib, but one minor correction: quartzite is backed by Quartz,
which features a number of different scheduling mechanisms, including
a unix-like CronExpression, but it's not a traditional crontab spec.
In particular, it has an additional seconds field and a pretty handy
increment operator. See
http://www.quartz-scheduler.org/api/2.1.5/org/quartz/CronExpression.html
for details.

Thanks,
Jim

On Mon, Oct 8, 2012 at 9:58 PM, zcaudate z...@caudate.me wrote:
 cronj
 This is another cron-inspired task-scheduling library. I have found
 many scheduling libraries for clojure:

  - quartzite
  - cron4j
  - clj-cronlike
  - at-at
  - monotony

 The first three all follow the cron convention. The task (also
 called a job) can only be scheduled at whole minute intervals. at-at
 has milli-second resolution, but was limited in the number of threads
 that have to be predetermined. It was good for looking after tasks
 that did not overlap between calls but not for tasks that may take an
 arbitarily long time. monotony uses core.logic, which is something
 that I am yet to understand.

 cronj is little different due to design requirements in the project
 that I am working on:
   - starts scheduled tasks at a per-second interval having high system-
 time accuracy without wasting system resourcs.

   - would spawn as many threads as needed, so that tasks started at
 earlier intervals could exist along side tasks started at later
 intervals.

   - an additional design requirement required that task handlers are
 passed a date-time object, so that the handler itself is aware of the
 time when it was initiated.

 it can be found at:
 https://github.com/zcaudate/cronj

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

Re: Clojure web framework

[Jim Crossley]

Hi Simone,

Simone Mosciatti mweb@gmail.com writes:

 Immutant ( http://immutant.org/ ) IMO is moving in a great direction,
 if I have understand is wrapping several libraries in just one
 enviroment...

Since you brought it up, I'd like to clarify terminology a bit in case
anyone thinks Immutant is a framework.

An *application* is a collection of *libraries* assembled in a
particular way to provide some service.

A *framework* enforces a particular way, essentially providing a
template for building your application.

Immutant is not a framework, it's an application server, a single
process capable of running multiple applications simultaneously,
including some commodity services like messaging, scheduling and caching
that, because they're integrated, can be easily clustered and
coordinated.

Immutant does provide libraries to invoke those services, but if and how
you use them in your application is completely up to you.

 And red hat is behind it I just find out, that usually means great
 doc...

You mean like this? ;-)
https://twitter.com/gphil/statuses/253285427702816768 

Sorry to hijack the thread,
Jim

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

[ANN] Immutant 0.4.0 released

[Jim Crossley]

Trying to stick to a bi-monthly release cycle, we announced version 0.4.0 
today: http://bit.ly/immutant040

In a nutshell, Immutant is an application server for Clojure. It's an 
integrated platform built on JBoss AS7 that aims to reduce the inherent 
accidental complexity in real world applications.

New features in this release include durable topic subscribers and 
representing JMS message properties as Clojure metadata. We also sped up 
deployments a bit and added some convenient options to the lein plugin, e.g.

  $ lein immutant deploy --context-path / --virtual-host some.host.com

More details available from the above link.

Thanks,
Jim

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

Re: Immutant 0.3.0 released

[Jim Crossley]

Hi Ali,

Ali M tclwarr...@gmail.com writes:

 Can you please elaborate more on this line ... maybe give examples 

 On Wednesday, September 12, 2012 3:45:56 AM UTC+2, Jim Crossley wrote:

 For certain applications, I would recommend using libraries to access
 external processes like Memcached, RabbitMQ, or cron, for example.
 And for others, I would recommend an app server.

At the risk of abusing a Clojure group to discuss the fitness of app
servers...

Successful applications are organic; they evolve; they have lifecycles.
Therefore they have to be managed: started, stopped, upgraded. They use
resources, so they may exhaust them and must be monitored and possibly
scaled.

When I refer to an application here, I'm referring to a single OS
process, but it may be required to interact with other processes,
perhaps a message broker or a caching service or a scheduler. Though not
maintained by you, those services each have their own lifecycles. Their
upgrade cycle is hopefully much longer than yours, so less of a concern,
but each present their own particular scaling challenges.

And maybe your app interacts with other domain-specific applications --
also written by you -- that are different enough to warrant their own
process/lifecycle but similar enough to operate on the same data.

When I refer to you here, I might be referring to you, or your team,
or the organization to which your team is responsible, amongst many
other similar teams, each with different skill levels, language/tool
preferences and areas of expertise.

The more interdependent processes you have -- each with their own
interfaces for management/monitoring/scaling -- and the more people
involved in evolving and supporting them, the more complex your
application becomes. And this is largely accidental complexity [1],
i.e. *not* the essential complexity of the problems you're trying to
solve.

An app server's *accidental* complexity, though higher than say, a
single web app, remains fairly constant as the *essential* complexity of
your domain evolves.

So recommending an app server only makes sense if its accidental
complexity is less than that of an app depending on multiple external
processes.

I hope that makes at least some sense. I've written about it before [2].
I'm happy to discuss it further, but the Immutant mailing list is
probably a better place than here. :)

Thanks,
Jim

[1] http://en.wikipedia.org/wiki/No_Silver_Bullet
[2] http://immutant.org/news/2011/11/02/enterprise-grade/

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

[ANN] Immutant 0.3.0 released

[Jim Crossley]

We released our third official version of Immutant today!

With this release we now publish the Immutant namespaces to Clojars. They 
are of limited use when run outside of Immutant, of course, but they'll at 
least compile so you can mock/stub/redefine them in your unit tests. You 
can render some of them mostly functional by adding the relevant jars to 
your project.clj, e.g. Infinispan, HornetQ, etc, and we expect to add more 
container-less functionality in future releases.

Obviously, they're completely functional *inside* an Immutant container, so 
we've published a library to facilitate integration testing, and continued 
to improve our nrepl/swank support so you can now add dependencies to your 
project on the fly without having to redeploy it.

Here's the announcement: http://bit.ly/immutant030

Enjoy and thanks,
Jim

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

Re: Immutant 0.3.0 released

[Jim Crossley]

Hi Takahiro,

When considering a specific library in isolation, e.g. HornetQ, there is 
little difference between using it within or without an app server.

Benefits of an app server include uniform deployment, centralized 
configuration, monitoring, and control, clustering capabilities to support 
scaling and high availability, multi-resource transactions, and in-process 
services like caching, messaging, and scheduling. Things that matter to 
larger organizations in which different groups produce applications that 
need to coordinate, often deployed to environments controlled by still 
other groups.

For certain applications, I would recommend using libraries to access 
external processes like Memcached, RabbitMQ, or cron, for example. And for 
others, I would recommend an app server.

As always, it depends on the requirements of the application and the 
capabilities of the organization to support it.

Thanks,
Jim

On Tuesday, September 11, 2012 7:26:21 PM UTC-4, Takahiro Hozumi wrote:

 Hi, 

 Forgive my ignorance, although I think the project must be useful, but 
 I still don't understand what is the benefit of using application 
 server. 
 What is the difference between using a particular library(e.g. 
 HornetQ) with JBoss AS7 and using the same one without JBoss AS7? 

 Cheers, 

 - Takahiro 

 On Sep 12, 4:30 am, Jim Crossley jcrossl...@gmail.com wrote: 
  We released our third official version of Immutant today! 
  
  With this release we now publish the Immutant namespaces to Clojars. 
 They 
  are of limited use when run outside of Immutant, of course, but they'll 
 at 
  least compile so you can mock/stub/redefine them in your unit tests. You 
  can render some of them mostly functional by adding the relevant jars to 
  your project.clj, e.g. Infinispan, HornetQ, etc, and we expect to add 
 more 
  container-less functionality in future releases. 
  
  Obviously, they're completely functional *inside* an Immutant container, 
 so 
  we've published a library to facilitate integration testing, and 
 continued 
  to improve our nrepl/swank support so you can now add dependencies to 
 your 
  project on the fly without having to redeploy it. 
  
  Here's the announcement:http://bit.ly/immutant030 
  
  Enjoy and thanks, 
  Jim 


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

[ANN] Immutant 0.2.0 released

[Jim Crossley]

We released our second version of Immutant today. Read all about it here: 
http://bit.ly/immutant020

For those unfamiliar with Immutant, here are the high points:

   - Simple functions with side effects triggering JBoss AS7 services
   - Very dynamic, no XML or YAML config, just Clojure
   - Deploys your Leiningen projects from disk, no war file necessary
   - Multiple apps can be deployed to a single Immutant, each with its own 
   isolated runtime
   - Embedded Swank/nREPL servers let you build your app while it's running 
   in the container

Give it a gander!

Thanks,
Jim

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

Re: Distributed transactions

[Jim Crossley]

Well, it took a little longer than I thought it would, but we announced 
support for XA on Immutant today: 
http://immutant.org/news/2012/06/26/transactions/

Enjoy!
Jim

On Saturday, December 31, 2011 7:59:27 PM UTC-5, Jim Crossley wrote:



 On Dec 31, 7:33 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: 
   On Dec 31, 1:16 pm, Jeff Heon jfh...@gmail.com wrote: 
   Immutant is going to have distributed (XA) transactions. 
   The're furiously working on it 8) 
  
  http://immutant.org/ 
  
   Furiously is probably not the right word, but XA is definitely on 
   the roadmap. It's just a matter of wiring up the TransactionManager 
   provided by JBoss AS7. We've done this already for Ruby with 
   TorqueBox, so it should be straightforward. With any luck, we'll have 
   it wired up by Februrary, certainly in time for Clojure/West. 
  
   Jim 
  
  What wiring is needed, beyond knowing how to call a Java API from 
 Clojure? 

 At a minimum, we need to obtain a TransactionManager (easy) and define 
 XAResource implementations for each resource participating in the 
 transaction (easy for messaging, not as easy for db). In ruby, the 
 activerecord jdbc adapter helps us with the latter, allowing us to 
 automatically create XAResource's for each key listed in the Rails 
 database.yml file, using standard ruby conventions to provide XA for 
 free when a rails app is deployed under TorqueBox. 

 We need to figure out what those conventions are for clojure. Or help 
 define them. 

 Also, the Java API's for XA are kinda awkward. I hope we can wrap them 
 a bit to make the common usage patterns simple. 

 Now, back to drinking.  :) 

 Jim 

  
  Stu 
  
  Stuart Halloway 
  Clojure/corehttp://clojure.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

[ANN] Immutant 0.1.0 released

[Jim Crossley]

Howdy all,

Just in time for my Clojure/West talk, we're happy to have published
our first official release of Immutant, the Clojure app server built
on JBoss AS7.

Read all about it here:  http://bit.ly/immutant010

Thanks,
Jim

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

Re: [ANN] mcache 0.2.0 released

[Jim Crossley]

Hi Dave,

This is awesome! :)

DHM davidhmar...@gmail.com writes:

[...]

 Thanks to Jim Crossly for the suggestion to look into CacheProtocol.
 Also, Jim, I hope you don't mind that I borrowed your naming scheme
 for the put functions. :-)

Not at all. I love that within a coupla weeks we've introduced two
distributed implementations of CacheProtocol.

Great work!

Jim

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

Re: mcache 0.1.0 released

[Jim Crossley]

DHM davidhmar...@gmail.com writes:

 I want to announce the release of mcache 0.1.0:
 https://github.com/davidhmartin/mcache

Very nice. One thing you might consider is implementing
core.cache/CacheProtocol [1] in terms of mcache. I've done this [2] for
the Infinispan data grid in Immutant. It'd be great to see another
distributed option for pluggable memoization.

Jim

[1] https://github.com/clojure/core.cache
[2] 
https://github.com/immutant/immutant/blob/master/modules/cache/src/main/clojure/immutant/cache.clj

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

Re: ANN: Clojure 1.4.0-beta1

[Jim Crossley]

Tassilo Horn tass...@member.fsf.org writes:

[...]

 I operate maven thru leiningen only, but probably I should get some
 understanding of maven, too.  Right now, I even cannot determine the
 maven command for fetching deps (after generating a maven pom.xml
 using lein pom). ;-)

mvn install

[...]

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

Re: ANN: Clojure 1.4.0-beta1

[Jim Crossley]

Tassilo Horn tass...@member.fsf.org writes:

[...]

 Ah, ok, seems to work.  Except that it doesn't copy the deps into my
 project but only to ~/.m2/, but that's probably the maven way.  

Correct. Though this plugin may be of interest:
http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html

 And it fetches much more than the transitive closure of my project's
 dependencies, i.e., plexus, surefire, commons-cli, doxia, and what
 not, many of them even in various different versions...

Yeah, probably due to deps of the plugins if you've never built any
maven project locally.

Jim


 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

Re: How to deal with parameters unused by intermediate functions?

[Jim Crossley]

I like that a lot, Stuart, thanks! Named params are a bonus, too:

Before I wasn't sure which was on top: (overlay x y pred)
Now it's more clear: (overlay :on x :with y :using pred)

Thanks again!
Jim

On Sat, Dec 3, 2011 at 1:03 PM, Stuart Sierra
the.stuart.sie...@gmail.comwrote:

 Map destructuring can help here:

 (defn foo [{:keys [one two] :as args}]
   (bar args))

 (defn bar [{:keys [three]}}
   ...)

 (foo {:one 1 :two 2 :three 3})

 -S

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

Re: How to deal with parameters unused by intermediate functions?

[Jim Crossley]

Unfortunately, foo is not their only caller, but that's a cool technique
I'm sure I'll find a use for. :)

Thanks,
Jim

On Sat, Dec 3, 2011 at 1:05 PM, Armando Blancas abm221...@gmail.com wrote:

 If foo is their only caller, bar and baz can be locals inside foo and
 thus giving baz direct access to foo's params. Checkout (letfn):
 http://clojuredocs.org/clojure_core/1.2.0/clojure.core/letfn

 On Dec 2, 7:34 pm, Jim Crossley j...@crossleys.org wrote:
  Hi,
 
  I have a public function foo that uses two private functions bar and baz.
  So foo calls bar which calls baz. Two of the parameters passed to foo
  aren't used by bar, only baz.
 
  Though the segregation of behavior across foo, bar, and baz makes sense
 for
  my program, I feel dirty making the params required by baz a part of
 bar's
  signature.
 
  Should I just get over it or is there a better way?
 
  Thanks,
  Jim

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

How to deal with parameters unused by intermediate functions?

[Jim Crossley]

Hi,

I have a public function foo that uses two private functions bar and baz.
So foo calls bar which calls baz. Two of the parameters passed to foo
aren't used by bar, only baz.

Though the segregation of behavior across foo, bar, and baz makes sense for
my program, I feel dirty making the params required by baz a part of bar's
signature.

Should I just get over it or is there a better way?

Thanks,
Jim

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

Re: http://immutant.org/

[Jim Crossley]

Hi Owen,

I'm one of the devs of TorqueBox and Immutant. We're trying to get the
first 2.0 release of TorqueBox out this month, so that's taking up a
good chunk of focus, but we're actively hacking on Immutant as well.

At this point, we have web (ring), messaging, and daemons mostly
working, but we don't have a good installation story yet, not to mention
a polished story for the thing we're most excited about: jruby and
clojure in a single stack, i.e. polyglot.

Keep an eye on http://immutant.org/news/ for updates, or find us in
#immutant on freenode if you start digging in and get stuck.

Thanks,
Jim

Owen Dall od...@barquin.com writes:

 We have been exploring TorqueBox with great interest for our JRuby
 apps.  So, It makes sense that the Immutant AS (Based on JBoss 7)  has
 appeared for Clojure

 Anyone in this group testing it?

 Cheers,

 Owen

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

Re: scheme to clojure translation

[Jim Crossley]

Hi

Aquahappy joshua.ay...@gmail.com writes:

[...]

 1:  (define (compose f g) (lambda (x) (f (g x
 2:  (define (twice f) (compose f f))
 3:  (define fourth (twice sq))
 4:  (fourth 3)

 I've gotten this far and then I get stuck when I try to do line 2 from
 the above:

 1:  (defn compose [f g] #(f (g %)))

This is what I came up with. Note I also defined the sq function.

user= (defn compose [f g] #(f (g %)))
#'user/compose
user= (defn twice [f] (compose f f))
#'user/twice
user= (defn sq [x] (* x x))
#'user/sq
user= (def fourth (twice sq))
#'user/fourth
user= (fourth 3)
81

Jim

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