Re: [ANN] incise 0.1.0 - An extensible static site generator

[Jan Herich]

Hello Ryan,

Thank you for the project, i was always missing a good static site 
generator written in clojure ! 
You took some interesting design decisions with extensibility. I'm 
currently working on the 
similar project , even if my design 
is very different, because my needs are different - i want to 
have templates in pure html and be able to declaratively specify specific 
areas, because of that
my project is based on enlive html library.


Dňa utorok, 14. januára 2014 8:35:33 UTC+1 Ryan McGowan napísal(-a):
>
> Hi all!
>
> After consuming quite a bit of my spare time for the past several months, 
> I have finally released version 0.1.0  of 
> incise. It is a static site generator written in Clojure (of course). I 
> like it quite a bit and I think others might benefit from it too.  I am 
> very open to contributions, suggestions or criticisms (just open an 
> issue)
> .
>
> Necessary links:
>
>- https://clojars.org/incise
>- http://www.ryanmcg.com/incise/ - README generated into website using 
>itself (it's called being meta).
>- https://github.com/RyanMcG/incise
>- https://github.com/RyanMcG/lein-incise - Yes there is a plugin
>- 
>http://www.ryanmcg.com/2014/1/13/static-website-generation-with-incise/ - 
>Very short post about it. Basically points to the README and makes the 
>disclaimer that it's not a big deal.
>- https://github.com/RyanMcG/incise-example-project - super simple 
>example project
>- http://www.ryanmcg.com/incise-example-project/ - and its generated 
>output
>
> Thanks,
>
> Ryan McGowan
>

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

[Xfeep Zhang]

I have committed some update.


   - org.clojure/clojure 1.4.0 --> 1.5.1
   - compojure 1.1.4 --> 1.1.6
   - ring 1.1.6 --> 1.2.1
   - aleph 0.3.0-beta13 --> 0.3.0
   - http-kit 1.3.0-alpha2 --> 2.1.16
   - ring-netty-adapter 0.0.3 --> netty-ring-adapter 0.4.6
   - remove testing about pure nginx which generally dosen't service 
   dymanic contents without other modules. 
   - add nginx with php5-fpm 5.5 testing
   - add nginx-clojure 0.1.0 testing
   - add 128 clients testing

Cheers :-)


On Monday, January 13, 2014 3:13:34 PM UTC+8, Peter Taoussanis wrote:
>
> You are welcome.
>> My Github user name is xfeep. 
>> I'm glad to join the repo. Thanks for your invitation!
>>
>
> Okay, great - I have added you. You can make any changes you like. I would 
> be happy if you or someone else wants to maintain (update) the repo.
>
> 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 clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: closing-buffer

[Michał Marczyk]

Ah, of course, the mutex is not reentrant.

So, one possible way to fix the situation would be to close the owned
channel manually by resetting its "closed" atom to true. Thinking
through all the implications should make for an interesting exercise.
:-) (For example, I think cleanup is performed correctly anyway, but I
haven't put in the time to make sure properly. Clearly this relies on
the implementation details of channels, so even if it is in fact not
broken with the current alpha, it might be in the future, and so it
might still be a better idea to implement a new channel. And so on.)

Here's the implementation, see below for an example from the REPL:

(defn closing-buffer [n]
  (let [b (async/buffer n)
c (clojure.lang.Box. nil)]
(reify
  clojure.core.async.impl.protocols/Buffer
  (full? [this]
false)
  (remove! [this]
(clojure.core.async.impl.protocols/remove! b))
  (add! [this itm]
(if (clojure.core.async.impl.protocols/full? b)
  (do
(reset! (.-closed
^clojure.core.async.impl.channels.ManyToManyChannel (.-val c)) true)
nil)
  (clojure.core.async.impl.protocols/add! b itm)))
  clojure.core.async.impl.protocols/UnblockingBuffer
  clojure.lang.Counted
  (count [this]
(count b))
  PBufferThatMightCloseAChannel
  (this-is-your-channel! [this given-c]
(if (nil? (.-val c))
  (do
(set! (.-val c) given-c)
true)
  false)

(defn closing-channel [n]
  (let [b (closing-buffer n)
c (async/chan b)]
(this-is-your-channel! b c)
c))

>From the REPL:

user> (def test-chan (closing-channel 2))
#'user/test-chan
user> (async/>!! test-chan :foo)
nil
user> (async/>!! test-chan :foo)
nil
user> (async/>!! test-chan :foo)
nil
user> (async/ (async/ (async/ (async/>!! test-chan :foo)
nil
user> (async/ wrote:
> If I understand your strategy correctly, it works as follows:
>
> * write new buffer class
> * extend buffer class with a field/atom that stores the channel that owns
> the buffer
>
> * on overflow, call (async/close!) on the owned channel
>
> However, looking at :
>
> *
> https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L179
> *
> https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L55
>
> isn't this a deadlock by acquiring the mutex while holding the mutex?
>
>
> On Mon, Jan 13, 2014 at 10:27 PM, Michał Marczyk 
> wrote:
>>
>> Instead of actually implementing a new channel type, you could use the
>> regular MTMCs, but with your own factory function, custom buffers and
>> a sprinkle of mutability:
>>
>> (defprotocol PBufferThatMightCloseAChannel
>>   (this-is-your-channel! [this c]
>> "Informs the buffer that c is the channel it might need to close"))
>>
>> ;; implement a buffer with an impl for the above protocol;
>> ;; have it close the appropriate channel on overflow;
>> ;; suppose closing-buffer is the factory function
>> ;; producing such channels
>>
>> (defn closing-channel [n]
>>   (let [b (closing-buffer n)
>> c (chan b)]
>> (this-is-your-channel! b c)
>> c))
>>
>> Cheers,
>> Michał
>>
>>
>> On 14 January 2014 05:47, t x  wrote:
>> > I am aware of:
>> >
>> >   DroppingBuffer and SliddingBuffer
>> >
>> > I would like to build a channel with different semantics:
>> >
>> >   When I try to put an item on a full channel:
>> >
>> >   * DroppingBuffer drops the new item
>> >   * SliddingBuffer evicts the oldest item
>> >
>> >   * ClosingBuffer should _close the channel_
>> >
>> > (thus, the receiver eventually gets a nil, and realizes "ah, was
>> > disconnected")
>> >
>> > Now, I am looking at the github core.async code:
>> >
>> > DroppingBuffer:
>> >
>> > https://github.com/clojure/core.async/blob/76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/clojure/core/async/impl/buffers.clj#L33-L45
>> >
>> > ManyToManyChannel:
>> >
>> > https://github.com/clojure/core.async/blob/76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/clojure/core/async/impl/channels.clj#L31-L198
>> >
>> > ## Problem:
>> >
>> > DroppingBuffer is easy to understand. However, I don't think I can
>> > implement
>> > "ClosingBuffer" as Buffer.
>> >
>> > I feel taht "ClosingBuffer" can only be implemneted at the Channel
>> > Level.
>> >
>> > However, the Channel Code is complicated.
>> >
>> > Is there a neat hack / trick to do what I described above?
>> >
>> > Thanks!
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> > your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojur

Re: Eastwood lint tools - some Qs

[Colin Fleming]

Ah, I see - that makes sense, thanks.


On 14 January 2014 19:49, Andy Fingerhut  wrote:

> defn is a macro, and thus macro-expanded during Eastwood analysis, I
> believe ignoring the :arglists.  I think it is really only the :arglists of
> functions that matter for Eastwood :wrong-arity warnings
>
> Andy
>
>
> On Mon, Jan 13, 2014 at 10:22 PM, Colin Fleming <
> colin.mailingl...@gmail.com> wrote:
>
>> Interesting - but there must be some sort of magic there since otherwise
>> every call to defn would be flagged, since its :arglists implies it has 6
>> arguments. And in fact, there's nothing there indicating that the body is
>> in fact the body.
>>
>>
>> On 14 January 2014 18:56, Andy Fingerhut wrote:
>>
>>> Nicola can answer more authoritatively, as I haven't checked that part
>>> of tools.analyzer recently, but I am pretty sure that the :arglists with
>>> things like doc-string? attr-map? are simply treated as if they were normal
>>> positional arguments, with no 'guessing' that they are optional due their
>>> symbols ending with a question mark.
>>>
>>> A function with :arglists ([x & xs]) is checked that it takes 1 or more
>>> args, so only warning if a call is made with 0 args.  That is why the
>>> current release of Eastwood will give incorrect :wrong-arity warning
>>> messages if one manually sets :arglists for a function to something other
>>> than what defn would make it.
>>>
>>> For macros, they are all expanded during Eastwood analysis, so any
>>> incorrect number of arguments should cause an exception to be thrown during
>>> analysis, much like it would if you attempted to compile such code.
>>>
>>> Andy
>>>
>>>
>>> On Mon, Jan 13, 2014 at 6:57 PM, Colin Fleming <
>>> colin.mailingl...@gmail.com> wrote:
>>>
 This is an interesting discussion, I've been thinking about some of
 these problems as I move towards adding inspections in Cursive. arglist
 parsing is a real problem in Clojure. I'd like to be able to flag
 invocations of functions with bad arities in the editor, but it's very
 difficult. Even defn is complicated, given that its :arglists is:

 :arglists '([name doc-string? attr-map? [params*] prepost-map? body]
 [name doc-string? attr-map? ([params*] prepost-map? body)+
 attr-map?])

 and its actual args declaration is:

 [&form &env name & fdecl]

 There's really no way to parse either of them automatically well. Does
 Eastwood use the actual fn declaration or :arglists for linting? What would
 it do in the case above? It's impossible to tell if doc-string? is a
 boolean or if it's an optional arg.

 Oh, and I agree that invalid :arglists as documentation is probably a
 bad idea, since it'll inevitably make this sort of tooling more difficult
 than it already is.


 On 14 January 2014 14:03, Sean Corfield  wrote:

> On Jan 13, 2014, at 3:09 PM, Nicola Mometto 
> wrote:
> > To be honest I don't like the idea of libraries attaching not-valid
> > :arglists meta to Vars at all since the doc[1] for `def` says that
> :arglists
> > will be "a list of vector(s) of argument forms, as were supplied to
> > defn" and the clojure Compiler uses :arglists for type-hints
> handling.
>
> I agree with you in principle - and I'm happy to change java.jdbc to
> avoid the issue.
>
> Could Eastwood (or j.t.a) flag invalid :arglists? The "example" ones
> in both java.jdbc and congomongo are clearly "invalid" according the
> special forms page (but they silently "work"). Perhaps if Eastwood finds
> invalid / suspicious metadata in :arglists, it could use a different 
> linter
> warning?
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "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 b

Re: Nginx-Clojure Let You Deploy Clojure Web App on Nginx Without Any Java Web Server

[Xfeep Zhang]

I have done the first one. The result is 
HERE( 
https://github.com/ptaoussanis/clojure-web-server-benchmarks )
Thanks Taoussanis for his invitation to the project 
clojure-web-server-benchmarkshosted
 on Github.

On Tuesday, January 14, 2014 10:31:03 AM UTC+8, Xfeep Zhang wrote:
>
> You're welcome.
>
> I think there are several difficult phases :
>
> (1)  update the test program in 
> clojure-web-server-benchmarks,
>  make the some packages to be the latest. (eg. http-kit from 1.3.0-alpha2 
> --> 2.1.16) and add nginx-php testing
> (2)  test about real world size contents by group eg. tiny, small, medium, 
> huge. 
> (3)  test about real world connection circumstances where a lot of 
> connection is inactive but keep open.
> (4)  try some real asynchronous test to fetch external resources (eg. rest 
> service , db) before response to the client. eg.  using 
> libdrizzlea no-blocking mysql  client from  
> https://launchpad.net/drizzle
>
> On Tuesday, January 14, 2014 2:41:50 AM UTC+8, Sergey Didenko wrote:
>>
>> Looks very interesting, thank you for your work!
>>
>> I wonder how this is going to improve latency in comparison to nginx + 
>> http-kit for some real world test that is not using heavy DB operations.
>>
>>
>> On Mon, Jan 13, 2014 at 5:57 AM, Xfeep Zhang  wrote:
>>
>>>
>>> So far I have found why nginx-clojure is slower than http-kit when 1 
>>> concurrents. (when < = 1000 concurrents nginx-clojure is faster than 
>>> http-kit.)
>>> I have set too many connections per nginx worker (worker_connections = 
>>> 2) . This make nginx only use one worker to handle ab  requests (every 
>>> request is tiny).
>>> I plan to take note of 
>>> c-erlang-java-performanceand
>>>  fork 
>>> clojure-web-server-benchmarksto
>>>   do some  real world tests.
>>>
>>>
>>>
>>> On Sunday, January 12, 2014 11:21:06 PM UTC+8, Xfeep Zhang wrote:

 Sorry for my mistake!

 1. In the static file test, the ring-jetty result is about 10 
 concurrents. NOT 1 concurrents  ("Concurrency Level:  10" in  the 
 ab report ).
 2. In the small string test, All results about three server are about 
 10 concurrents. NOT 1 concurrents.

 There are right results about these two mistake :

 1. static file test

 (3) ring-jetty  more bad than 10 concurrents
 ===
 Document Path:  /
 Document Length:29686 bytes

 *Concurrency Level:  1*
 Time taken for tests:   6.303 seconds
 Complete requests:  10
 Failed requests:0
 Write errors:   0
 Total transferred:  298220 bytes
 HTML transferred:   296860 bytes
 Requests per second:15864.43 [#/sec] (mean)
 Time per request:   630.341 [ms] (mean)
 Time per request:   0.063 [ms] (mean, across all concurrent 
 requests)
 Transfer rate:  462020.65 [Kbytes/sec] received

 Connection Times (ms)
   min  mean[+/-sd] median   max
 Connect:   12  328 535.0 433041
 Processing:25  124 112.9 963523
 Waiting:8   47  99.4 283523
 Total: 52  452 544.51574546

 Percentage of the requests served within a certain time (ms)
   50%157
   66%305
   75%   1071
   80%   1102
   90%   1139
   95%   1155
   98%   1462
   99%   3100
  100%   4546 (longest request)


 2. simple string (1 concurrents)

 http-kit is the fastest.  But nginx-clojure is too young and has vast 
 room for growth ：）

 (1) nginx-clojure-0.1.0

 Document Path:  /
 Document Length:15 bytes

 *Concurrency Level:  1*
 Time taken for tests:   2.834 seconds
 Complete requests:  10
 Failed requests:0
 Write errors:   0
 Total transferred:  1700 bytes
 HTML transferred:   150 bytes
 Requests per second:35291.16 [#/sec] (mean)
 Time per request:   283.357 [ms] (mean)
 Time per request:   0.028 [ms] (mean, across all concurrent 
 requests)
 Transfer rate:  5858.88 [Kbytes/sec] received

 Connection Times (ms)
   min  mean[+/-sd] median   max
 Connect:   51  118  21.6118 178
 Processing:73  150  33.8146 263
 Waiting:   42  110  32.0104 246
 Total:177  268  25.6269 327

 Percentage of the requests served within a certain time

Re: closing-buffer

[Michał Marczyk]

A sketch of a different approach:

alt!  / alts! on the main channel and an extra channel with :priority
true when putting. Use an unblocking buffer in the extra channel. If
you end up putting on the extra channel, close the main channel.
(core.async channels can be closed multiple times.)

Here a consumer could take something off the channel before we close,
making it possible to a different producer to put something on the
channel possibly before we close, meaning that the channel doesn't,
strictly speaking, get closed as soon as an "overflowing put" arrives.
Of course if the timing is that close, the end result is no different
to what would happen had we arrived at a slightly later time.


On 14 January 2014 09:37, Michał Marczyk  wrote:
> Ah, of course, the mutex is not reentrant.
>
> So, one possible way to fix the situation would be to close the owned
> channel manually by resetting its "closed" atom to true. Thinking
> through all the implications should make for an interesting exercise.
> :-) (For example, I think cleanup is performed correctly anyway, but I
> haven't put in the time to make sure properly. Clearly this relies on
> the implementation details of channels, so even if it is in fact not
> broken with the current alpha, it might be in the future, and so it
> might still be a better idea to implement a new channel. And so on.)
>
> Here's the implementation, see below for an example from the REPL:
>
> (defn closing-buffer [n]
>   (let [b (async/buffer n)
> c (clojure.lang.Box. nil)]
> (reify
>   clojure.core.async.impl.protocols/Buffer
>   (full? [this]
> false)
>   (remove! [this]
> (clojure.core.async.impl.protocols/remove! b))
>   (add! [this itm]
> (if (clojure.core.async.impl.protocols/full? b)
>   (do
> (reset! (.-closed
> ^clojure.core.async.impl.channels.ManyToManyChannel (.-val c)) true)
> nil)
>   (clojure.core.async.impl.protocols/add! b itm)))
>   clojure.core.async.impl.protocols/UnblockingBuffer
>   clojure.lang.Counted
>   (count [this]
> (count b))
>   PBufferThatMightCloseAChannel
>   (this-is-your-channel! [this given-c]
> (if (nil? (.-val c))
>   (do
> (set! (.-val c) given-c)
> true)
>   false)
>
> (defn closing-channel [n]
>   (let [b (closing-buffer n)
> c (async/chan b)]
> (this-is-your-channel! b c)
> c))
>
> From the REPL:
>
> user> (def test-chan (closing-channel 2))
> #'user/test-chan
> user> (async/>!! test-chan :foo)
> nil
> user> (async/>!! test-chan :foo)
> nil
> user> (async/>!! test-chan :foo)
> nil
> user> (async/ :foo
> user> (async/ :foo
> user> (async/ nil
> user> (async/>!! test-chan :foo)
> nil
> user> (async/ nil
>
> Cheers,
> Michał
>
>
> On 14 January 2014 07:41, t x  wrote:
>> If I understand your strategy correctly, it works as follows:
>>
>> * write new buffer class
>> * extend buffer class with a field/atom that stores the channel that owns
>> the buffer
>>
>> * on overflow, call (async/close!) on the owned channel
>>
>> However, looking at :
>>
>> *
>> https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L179
>> *
>> https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L55
>>
>> isn't this a deadlock by acquiring the mutex while holding the mutex?
>>
>>
>> On Mon, Jan 13, 2014 at 10:27 PM, Michał Marczyk 
>> wrote:
>>>
>>> Instead of actually implementing a new channel type, you could use the
>>> regular MTMCs, but with your own factory function, custom buffers and
>>> a sprinkle of mutability:
>>>
>>> (defprotocol PBufferThatMightCloseAChannel
>>>   (this-is-your-channel! [this c]
>>> "Informs the buffer that c is the channel it might need to close"))
>>>
>>> ;; implement a buffer with an impl for the above protocol;
>>> ;; have it close the appropriate channel on overflow;
>>> ;; suppose closing-buffer is the factory function
>>> ;; producing such channels
>>>
>>> (defn closing-channel [n]
>>>   (let [b (closing-buffer n)
>>> c (chan b)]
>>> (this-is-your-channel! b c)
>>> c))
>>>
>>> Cheers,
>>> Michał
>>>
>>>
>>> On 14 January 2014 05:47, t x  wrote:
>>> > I am aware of:
>>> >
>>> >   DroppingBuffer and SliddingBuffer
>>> >
>>> > I would like to build a channel with different semantics:
>>> >
>>> >   When I try to put an item on a full channel:
>>> >
>>> >   * DroppingBuffer drops the new item
>>> >   * SliddingBuffer evicts the oldest item
>>> >
>>> >   * ClosingBuffer should _close the channel_
>>> >
>>> > (thus, the receiver eventually gets a nil, and realizes "ah, was
>>> > disconnected")
>>> >
>>> > Now, I am looking at the github core.async code:
>>> >
>>> > DroppingBuffer:
>>> >
>>> > https://github.com/clojure/core.async/blob/76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/clojure/core/async/impl/buffers.clj#L33-L45
>

Re: closing-buffer

[Michał Marczyk]

Just to avoid any possibility of giving the impression that I'm
offering the above as a well-tested component: I wouldn't actually use
closing-channel as defined above without giving much more thought to
all implications. The current version is just a quick sketch.

Also, if the alt! / alts! approach works satisfactorily, or if another
approach based on the available public primitives does, I'd definitely
avoid implementing new funky stuff.

Fun problem to think about, though.


On 14 January 2014 09:47, Michał Marczyk  wrote:
> A sketch of a different approach:
>
> alt!  / alts! on the main channel and an extra channel with :priority
> true when putting. Use an unblocking buffer in the extra channel. If
> you end up putting on the extra channel, close the main channel.
> (core.async channels can be closed multiple times.)
>
> Here a consumer could take something off the channel before we close,
> making it possible to a different producer to put something on the
> channel possibly before we close, meaning that the channel doesn't,
> strictly speaking, get closed as soon as an "overflowing put" arrives.
> Of course if the timing is that close, the end result is no different
> to what would happen had we arrived at a slightly later time.
>
>
> On 14 January 2014 09:37, Michał Marczyk  wrote:
>> Ah, of course, the mutex is not reentrant.
>>
>> So, one possible way to fix the situation would be to close the owned
>> channel manually by resetting its "closed" atom to true. Thinking
>> through all the implications should make for an interesting exercise.
>> :-) (For example, I think cleanup is performed correctly anyway, but I
>> haven't put in the time to make sure properly. Clearly this relies on
>> the implementation details of channels, so even if it is in fact not
>> broken with the current alpha, it might be in the future, and so it
>> might still be a better idea to implement a new channel. And so on.)
>>
>> Here's the implementation, see below for an example from the REPL:
>>
>> (defn closing-buffer [n]
>>   (let [b (async/buffer n)
>> c (clojure.lang.Box. nil)]
>> (reify
>>   clojure.core.async.impl.protocols/Buffer
>>   (full? [this]
>> false)
>>   (remove! [this]
>> (clojure.core.async.impl.protocols/remove! b))
>>   (add! [this itm]
>> (if (clojure.core.async.impl.protocols/full? b)
>>   (do
>> (reset! (.-closed
>> ^clojure.core.async.impl.channels.ManyToManyChannel (.-val c)) true)
>> nil)
>>   (clojure.core.async.impl.protocols/add! b itm)))
>>   clojure.core.async.impl.protocols/UnblockingBuffer
>>   clojure.lang.Counted
>>   (count [this]
>> (count b))
>>   PBufferThatMightCloseAChannel
>>   (this-is-your-channel! [this given-c]
>> (if (nil? (.-val c))
>>   (do
>> (set! (.-val c) given-c)
>> true)
>>   false)
>>
>> (defn closing-channel [n]
>>   (let [b (closing-buffer n)
>> c (async/chan b)]
>> (this-is-your-channel! b c)
>> c))
>>
>> From the REPL:
>>
>> user> (def test-chan (closing-channel 2))
>> #'user/test-chan
>> user> (async/>!! test-chan :foo)
>> nil
>> user> (async/>!! test-chan :foo)
>> nil
>> user> (async/>!! test-chan :foo)
>> nil
>> user> (async/> :foo
>> user> (async/> :foo
>> user> (async/> nil
>> user> (async/>!! test-chan :foo)
>> nil
>> user> (async/> nil
>>
>> Cheers,
>> Michał
>>
>>
>> On 14 January 2014 07:41, t x  wrote:
>>> If I understand your strategy correctly, it works as follows:
>>>
>>> * write new buffer class
>>> * extend buffer class with a field/atom that stores the channel that owns
>>> the buffer
>>>
>>> * on overflow, call (async/close!) on the owned channel
>>>
>>> However, looking at :
>>>
>>> *
>>> https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L179
>>> *
>>> https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L55
>>>
>>> isn't this a deadlock by acquiring the mutex while holding the mutex?
>>>
>>>
>>> On Mon, Jan 13, 2014 at 10:27 PM, Michał Marczyk 
>>> wrote:

 Instead of actually implementing a new channel type, you could use the
 regular MTMCs, but with your own factory function, custom buffers and
 a sprinkle of mutability:

 (defprotocol PBufferThatMightCloseAChannel
   (this-is-your-channel! [this c]
 "Informs the buffer that c is the channel it might need to close"))

 ;; implement a buffer with an impl for the above protocol;
 ;; have it close the appropriate channel on overflow;
 ;; suppose closing-buffer is the factory function
 ;; producing such channels

 (defn closing-channel [n]
   (let [b (closing-buffer n)
 c (chan b)]
 (this-is-your-channel! b c)
 c))

 Cheers,
 Michał


 On 14 January 2014 05:47, t x  wrote:
 > I am aware o

Re: How to handle configuration in Clojure?

[James Trunk]

Thanks for all the great links and ideas you have all posted, now I have 
plenty of reading and thinking to do!

> I am curious about what you mean by 'thread safety'.
Perhaps "thread safety" is the wrong term, but what I meant was the 
limitations dynamic binding introduces around thread dispatching, which 
Stuart Sierra explains in this blog 
post
.

Cheers,
James

On Monday, January 13, 2014 7:10:38 PM UTC+1, Stefan Kanev wrote:
>
> On 13/01/14, James Trunk wrote: 
> > The downsides to dynamic vars seem to be: hiddenness, thread safety, and 
> > more complex tests (binding before each test). 
>
> I am curious about what you mean by 'thread safety'.  As far as I know, 
> dynamic variables are thread-local, which means that they are 
> thread-safe, at least to some extend.  I assume you mean something 
> specific? 
>
> -- 
> Stefan Kanev  ¦  @skanev  ¦  http://skanev.com/ 
> If a program manipulates a large amount of data, it does so in a small 
> number 
> of ways. 
>

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

[Stefan Kanev]

On 14/01/14, James Trunk wrote:
> > I am curious about what you mean by 'thread safety'.
> Perhaps "thread safety" is the wrong term, but what I meant was the 
> limitations dynamic binding introduces around thread dispatching, which 
> Stuart Sierra explains in this blog 
> post

Fair enough.  Thanks for the elaboration.

-- 
Stefan Kanev  ¦  @skanev  ¦  http://skanev.com/
Bringing computers into the home won't change either one, but may revitalize
the corner saloon.

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

[Peter Taoussanis]

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 clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Nginx-Clojure Let You Deploy Clojure Web App on Nginx Without Any Java Web Server

[Feng Shen]

Hi, 

Thanks for your work on nginx-clojure. It looks great!  

As I know Nginx spawns many processes(correct me if I am wrong),  does that 
mean, there will be many JVM process?




On Tuesday, January 14, 2014 4:44:18 PM UTC+8, Xfeep Zhang wrote:
>
>
> I have done the first one. The result is 
> HERE( 
> https://github.com/ptaoussanis/clojure-web-server-benchmarks )
> Thanks Taoussanis for his invitation to the project 
> clojure-web-server-benchmarkshosted
>  on Github.
>
> On Tuesday, January 14, 2014 10:31:03 AM UTC+8, Xfeep Zhang wrote:
>>
>> You're welcome.
>>
>> I think there are several difficult phases :
>>
>> (1)  update the test program in 
>> clojure-web-server-benchmarks,
>>  make the some packages to be the latest. (eg. http-kit from 1.3.0-alpha2 
>> --> 2.1.16) and add nginx-php testing
>> (2)  test about real world size contents by group eg. tiny, small, 
>> medium, huge. 
>> (3)  test about real world connection circumstances where a lot of 
>> connection is inactive but keep open.
>> (4)  try some real asynchronous test to fetch external resources (eg. 
>> rest service , db) before response to the client. eg.  using 
>> libdrizzlea no-blocking mysql  client from  
>> https://launchpad.net/drizzle
>>
>> On Tuesday, January 14, 2014 2:41:50 AM UTC+8, Sergey Didenko wrote:
>>>
>>> Looks very interesting, thank you for your work!
>>>
>>> I wonder how this is going to improve latency in comparison to nginx + 
>>> http-kit for some real world test that is not using heavy DB operations.
>>>
>>>
>>> On Mon, Jan 13, 2014 at 5:57 AM, Xfeep Zhang  wrote:
>>>

 So far I have found why nginx-clojure is slower than http-kit when 
 1 concurrents. (when < = 1000 concurrents nginx-clojure is faster than 
 http-kit.)
 I have set too many connections per nginx worker (worker_connections = 
 2) . This make nginx only use one worker to handle ab  requests (every 
 request is tiny).
 I plan to take note of 
 c-erlang-java-performanceand
  fork 
 clojure-web-server-benchmarksto
   do some  real world tests.



 On Sunday, January 12, 2014 11:21:06 PM UTC+8, Xfeep Zhang wrote:
>
> Sorry for my mistake!
>
> 1. In the static file test, the ring-jetty result is about 10 
> concurrents. NOT 1 concurrents  ("Concurrency Level:  10" in  the 
> ab report ).
> 2. In the small string test, All results about three server are about 
> 10 concurrents. NOT 1 concurrents.
>
> There are right results about these two mistake :
>
> 1. static file test
>
> (3) ring-jetty  more bad than 10 concurrents
> 
> ===
> Document Path:  /
> Document Length:29686 bytes
>
> *Concurrency Level:  1*
> Time taken for tests:   6.303 seconds
> Complete requests:  10
> Failed requests:0
> Write errors:   0
> Total transferred:  298220 bytes
> HTML transferred:   296860 bytes
> Requests per second:15864.43 [#/sec] (mean)
> Time per request:   630.341 [ms] (mean)
> Time per request:   0.063 [ms] (mean, across all concurrent 
> requests)
> Transfer rate:  462020.65 [Kbytes/sec] received
>
> Connection Times (ms)
>   min  mean[+/-sd] median   max
> Connect:   12  328 535.0 433041
> Processing:25  124 112.9 963523
> Waiting:8   47  99.4 283523
> Total: 52  452 544.51574546
>
> Percentage of the requests served within a certain time (ms)
>   50%157
>   66%305
>   75%   1071
>   80%   1102
>   90%   1139
>   95%   1155
>   98%   1462
>   99%   3100
>  100%   4546 (longest request)
>
>
> 2. simple string (1 concurrents)
>
> http-kit is the fastest.  But nginx-clojure is too young and has vast 
> room for growth ：）
>
> (1) nginx-clojure-0.1.0
>
> Document Path:  /
> Document Length:15 bytes
>
> *Concurrency Level:  1*
> Time taken for tests:   2.834 seconds
> Complete requests:  10
> Failed requests:0
> Write errors:   0
> Total transferred:  1700 bytes
> HTML transferred:   150 bytes
> Requests per second:35291.16 [#/sec] (mean)
> Time per request:   283.357 [ms] (mean)
> Time per request:   0.028 [ms] (mean, across all concurrent 
> requests)
> Transf

Re: Clojure web server benchmarks

[Shen, Feng]

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

> 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 clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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+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.

Hello, here´s a new clojur adict... with a question.

[Andreas Olsson]

How can i "println" an index of a vector?

tryed. 

(println vector index)

like 

(println x 0)

dosnt work.

/ a swede.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Hello, here´s a new clojur adict... with a question.

[Omer Iqbal]

(println (v 0))

(v 0) would give you the element at index 0
(println ..) would print whatever you supply as its argument.

Cheers,
Omer


On Tue, Jan 14, 2014 at 6:44 PM, Andreas Olsson wrote:

>
> How can i "println" an index of a vector?
>
> tryed.
>
> (println vector index)
>
> like
>
> (println x 0)
>
> dosnt work.
>
> / a swede.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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: Hello, here´s a new clojur adict... with a question.

[Andreas Olsson]

Cant get this to work.

(def sx2(atom [2 3 4]))

(println (sx2 3))


Den tisdagen den 14:e januari 2014 kl. 12:04:27 UTC+1 skrev Omer Iqbal:
>
> (println (v 0))
>
> (v 0) would give you the element at index 0
> (println ..) would print whatever you supply as its argument.
>
> Cheers,
> Omer
>
>
> On Tue, Jan 14, 2014 at 6:44 PM, Andreas Olsson 
> 
> > wrote:
>
>>
>> How can i "println" an index of a vector?
>>
>> tryed. 
>>
>> (println vector index)
>>
>> like 
>>
>> (println x 0)
>>
>> dosnt work.
>>
>> / a swede.
>>
>> -- 
>> -- 
>> 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/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: Hello, here´s a new clojur adict... with a question.

[Jim - FooBar();]

an atom cannot be used as a function! deref it first to get the vector 
inside and then try again...


Jim


On 14/01/14 11:25, Andreas Olsson wrote:

Cant get this to work.

(def sx2(atom [2 3 4]))

(println (sx2 3))


Den tisdagen den 14:e januari 2014 kl. 12:04:27 UTC+1 skrev Omer Iqbal:

(println (v 0))

(v 0) would give you the element at index 0
(println ..) would print whatever you supply as its argument.

Cheers,
Omer


On Tue, Jan 14, 2014 at 6:44 PM, Andreas Olsson
> wrote:


How can i "println" an index of a vector?

tryed.

(println vector index)

like

(println x 0)

dosnt work.

/ a swede.
-- 
-- 
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/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.


--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Hello, here´s a new clojur adict... with a question.

[Andreas Olsson]

thanks... this works

(println ((deref sx2) 4))



Den tisdagen den 14:e januari 2014 kl. 12:29:02 UTC+1 skrev Jim foo.bar:
>
>  an atom cannot be used as a function! deref it first to get the vector 
> inside and then try again... 
>
> Jim
>
>
> On 14/01/14 11:25, Andreas Olsson wrote:
>  
>  Cant get this to work.
>
>  (def sx2(atom [2 3 4]))
>
>  (println (sx2 3))
>  
>  
> Den tisdagen den 14:e januari 2014 kl. 12:04:27 UTC+1 skrev Omer Iqbal: 
>>
>> (println (v 0)) 
>>
>>  (v 0) would give you the element at index 0
>> (println ..) would print whatever you supply as its argument.
>>
>>  Cheers,
>> Omer
>>  
>>
>> On Tue, Jan 14, 2014 at 6:44 PM, Andreas Olsson wrote:
>>
>>>
>>> How can i "println" an index of a vector?
>>>
>>>  tryed. 
>>>  
>>>  (println vector index)
>>>
>>>  like 
>>>
>>>  (println x 0)
>>>
>>>  dosnt work.
>>>
>>>  / a swede.
>>>  -- 
>>> -- 
>>> 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/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.com 
> 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/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: Hello, here´s a new clojur adict... with a question.

[James Reeves]

You could also write:

(println (@sx2 4))


On 14 January 2014 11:35, Andreas Olsson  wrote:

> thanks... this works
>
> (println ((deref sx2) 4))
>
>
>
> Den tisdagen den 14:e januari 2014 kl. 12:29:02 UTC+1 skrev Jim foo.bar:
>
>>  an atom cannot be used as a function! deref it first to get the vector
>> inside and then try again...
>>
>> Jim
>>
>>
>> On 14/01/14 11:25, Andreas Olsson wrote:
>>
>>  Cant get this to work.
>>
>>  (def sx2(atom [2 3 4]))
>>
>>  (println (sx2 3))
>>
>>
>> Den tisdagen den 14:e januari 2014 kl. 12:04:27 UTC+1 skrev Omer Iqbal:
>>>
>>> (println (v 0))
>>>
>>>  (v 0) would give you the element at index 0
>>> (println ..) would print whatever you supply as its argument.
>>>
>>>  Cheers,
>>> Omer
>>>
>>>
>>> On Tue, Jan 14, 2014 at 6:44 PM, Andreas Olsson wrote:
>>>

 How can i "println" an index of a vector?

  tryed.

  (println vector index)

  like

  (println x 0)

  dosnt work.

  / a swede.
  --
 --
 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/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.com
>> 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/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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Hello, here´s a new clojur adict... with a question.

[Andreas Olsson]

Okay,.. 

..learning one step at a time hear. =)

I´m good at basic.. this is some thing else.

Den tisdagen den 14:e januari 2014 kl. 12:38:34 UTC+1 skrev James Reeves:
>
> You could also write:
>
> (println (@sx2 4))
>
>
> On 14 January 2014 11:35, Andreas Olsson 
> > wrote:
>
>> thanks... this works
>>
>> (println ((deref sx2) 4))
>>
>>
>>
>> Den tisdagen den 14:e januari 2014 kl. 12:29:02 UTC+1 skrev Jim foo.bar:
>>
>>>  an atom cannot be used as a function! deref it first to get the vector 
>>> inside and then try again... 
>>>
>>> Jim
>>>
>>>
>>> On 14/01/14 11:25, Andreas Olsson wrote:
>>>  
>>>  Cant get this to work.
>>>
>>>  (def sx2(atom [2 3 4]))
>>>
>>>  (println (sx2 3))
>>>  
>>>  
>>> Den tisdagen den 14:e januari 2014 kl. 12:04:27 UTC+1 skrev Omer Iqbal: 

 (println (v 0)) 

  (v 0) would give you the element at index 0
 (println ..) would print whatever you supply as its argument.

  Cheers,
 Omer
  

 On Tue, Jan 14, 2014 at 6:44 PM, Andreas Olsson wrote:

>
> How can i "println" an index of a vector?
>
>  tryed. 
>  
>  (println vector index)
>
>  like 
>
>  (println x 0)
>
>  dosnt work.
>
>  / a swede.
>  -- 
> -- 
> 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/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.com
>>> 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/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.com
>> 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/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: Nginx-Clojure Let You Deploy Clojure Web App on Nginx Without Any Java Web Server

[Xfeep Zhang]

You are welcome! 

Yes, you are right.  One JVM instance is embed  per Nginx Worker process.  
The number of Nginx Workers  is generally the same with the number of CPU.

If one Worker crashs the Nginx Master will create a new one so you don't 
worry about JVM crashs accidentally.

Although there will be several JVM instances,  there 's only one main 
thread attached with the Nginx Woker process.

So the JVM instance uses less memory and no thread context switch cost in 
every JVM instance.

In some cases If you can  use only one JVM instance,  you can set the Nginx 
Worker number to be 1 and set jvm_workers > 1,  nginx-clojure will create 

a thread pool with fixed number of thread.

to handle requests for you.

On Tuesday, January 14, 2014 5:50:34 PM UTC+8, Feng Shen wrote:
>
> Hi, 
>
> Thanks for your work on nginx-clojure. It looks great!  
>
> As I know Nginx spawns many processes(correct me if I am wrong),  does 
> that mean, there will be many JVM process?
>
>
>
>
> On Tuesday, January 14, 2014 4:44:18 PM UTC+8, Xfeep Zhang wrote:
>>
>>
>> I have done the first one. The result is 
>> HERE( 
>> https://github.com/ptaoussanis/clojure-web-server-benchmarks )
>> Thanks Taoussanis for his invitation to the project 
>> clojure-web-server-benchmarkshosted
>>  on Github.
>>
>> On Tuesday, January 14, 2014 10:31:03 AM UTC+8, Xfeep Zhang wrote:
>>>
>>> You're welcome.
>>>
>>> I think there are several difficult phases :
>>>
>>> (1)  update the test program in 
>>> clojure-web-server-benchmarks,
>>>  make the some packages to be the latest. (eg. http-kit from 1.3.0-alpha2 
>>> --> 2.1.16) and add nginx-php testing
>>> (2)  test about real world size contents by group eg. tiny, small, 
>>> medium, huge. 
>>> (3)  test about real world connection circumstances where a lot of 
>>> connection is inactive but keep open.
>>> (4)  try some real asynchronous test to fetch external resources (eg. 
>>> rest service , db) before response to the client. eg.  using 
>>> libdrizzlea no-blocking mysql  client from  
>>> https://launchpad.net/drizzle
>>>
>>> On Tuesday, January 14, 2014 2:41:50 AM UTC+8, Sergey Didenko wrote:

 Looks very interesting, thank you for your work!

 I wonder how this is going to improve latency in comparison to nginx + 
 http-kit for some real world test that is not using heavy DB operations.


 On Mon, Jan 13, 2014 at 5:57 AM, Xfeep Zhang  wrote:

>
> So far I have found why nginx-clojure is slower than http-kit when 
> 1 concurrents. (when < = 1000 concurrents nginx-clojure is faster 
> than 
> http-kit.)
> I have set too many connections per nginx worker (worker_connections = 
> 2) . This make nginx only use one worker to handle ab  requests 
> (every 
> request is tiny).
> I plan to take note of 
> c-erlang-java-performanceand
>  fork 
> clojure-web-server-benchmarksto
>   do some  real world tests.
>
>
>
> On Sunday, January 12, 2014 11:21:06 PM UTC+8, Xfeep Zhang wrote:
>>
>> Sorry for my mistake!
>>
>> 1. In the static file test, the ring-jetty result is about 10 
>> concurrents. NOT 1 concurrents  ("Concurrency Level:  10" in  
>> the 
>> ab report ).
>> 2. In the small string test, All results about three server are about 
>> 10 concurrents. NOT 1 concurrents.
>>
>> There are right results about these two mistake :
>>
>> 1. static file test
>>
>> (3) ring-jetty  more bad than 10 concurrents
>> 
>> ===
>> Document Path:  /
>> Document Length:29686 bytes
>>
>> *Concurrency Level:  1*
>> Time taken for tests:   6.303 seconds
>> Complete requests:  10
>> Failed requests:0
>> Write errors:   0
>> Total transferred:  298220 bytes
>> HTML transferred:   296860 bytes
>> Requests per second:15864.43 [#/sec] (mean)
>> Time per request:   630.341 [ms] (mean)
>> Time per request:   0.063 [ms] (mean, across all concurrent 
>> requests)
>> Transfer rate:  462020.65 [Kbytes/sec] received
>>
>> Connection Times (ms)
>>   min  mean[+/-sd] median   max
>> Connect:   12  328 535.0 433041
>> Processing:25  124 112.9 963523
>> Waiting:8   47  99.4 283523
>> Total: 52  452 544.51574546
>>
>> Percentage of the requests served within a certain time (ms)
>>   50%157
>

Re: Hello, here´s a new clojur adict... with a question.

[Chris Ford]

Unless you are worrying about concurrency, you probably don't need an atom
at all:

(def sx2 [2 3 4])

(println (sx2 1))


On 14 January 2014 14:45, Andreas Olsson  wrote:

> Okay,..
>
> ..learning one step at a time hear. =)
>
> I´m good at basic.. this is some thing else.
>
> Den tisdagen den 14:e januari 2014 kl. 12:38:34 UTC+1 skrev James Reeves:
>>
>> You could also write:
>>
>> (println (@sx2 4))
>>
>>
>> On 14 January 2014 11:35, Andreas Olsson  wrote:
>>
>>> thanks... this works
>>>
>>> (println ((deref sx2) 4))
>>>
>>>
>>>
>>> Den tisdagen den 14:e januari 2014 kl. 12:29:02 UTC+1 skrev Jim foo.bar:
>>>
  an atom cannot be used as a function! deref it first to get the
 vector inside and then try again...

 Jim


 On 14/01/14 11:25, Andreas Olsson wrote:

  Cant get this to work.

  (def sx2(atom [2 3 4]))

  (println (sx2 3))


 Den tisdagen den 14:e januari 2014 kl. 12:04:27 UTC+1 skrev Omer Iqbal:
>
> (println (v 0))
>
>  (v 0) would give you the element at index 0
> (println ..) would print whatever you supply as its argument.
>
>  Cheers,
> Omer
>
>
> On Tue, Jan 14, 2014 at 6:44 PM, Andreas Olsson 
> wrote:
>
>>
>> How can i "println" an index of a vector?
>>
>>  tryed.
>>
>>  (println vector index)
>>
>>  like
>>
>>  (println x 0)
>>
>>  dosnt work.
>>
>>  / a swede.
>>  --
>> --
>> 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/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.com
 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/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.com
>>> 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/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.
>

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

Re: closing-buffer

[Alex Miller]

>From my perspective, a buffer is below the abstraction level of a channel. 
If you want a channel with special behavior, it seems like you should 
implement a channel.

On Monday, January 13, 2014 10:47:22 PM UTC-6, t x wrote:
>
> I am aware of:
>
>   DroppingBuffer and SliddingBuffer
>
> I would like to build a channel with different semantics:
>
>   When I try to put an item on a full channel:
>
>   * DroppingBuffer drops the new item
>   * SliddingBuffer evicts the oldest item
>
>   * ClosingBuffer should _close the channel_
>
> (thus, the receiver eventually gets a nil, and realizes "ah, was 
> disconnected")
>
> Now, I am looking at the github core.async code:
>
> DroppingBuffer: 
> https://github.com/clojure/core.async/blob/76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/clojure/core/async/impl/buffers.clj#L33-L45
>
> ManyToManyChannel: 
> https://github.com/clojure/core.async/blob/76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/clojure/core/async/impl/channels.clj#L31-L198
>
> ## Problem:
>
> DroppingBuffer is easy to understand. However, I don't think I can 
> implement "ClosingBuffer" as Buffer.
>
> I feel taht "ClosingBuffer" can only be implemneted at the Channel Level.
>
> However, the Channel Code is complicated.
>
> Is there a neat hack / trick to do what I described above?
>
> Thanks!
>

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

Re: go "kill infinite loop"

[Alex Miller]

Two notes:

1)The provided core.async go-loop macro is a small enhancement for the (go 
(loop )) case.
2) Be careful using when using falsey tests like when or if - these will 
stop on nil but will also stop on false coming through the channel. Might 
be ok here, but it's something to be aware of.

Alex


On Monday, January 13, 2014 11:45:52 PM UTC-6, Mark Mandel wrote:
>
> I found this macro I wrote really useful for exactly this type of thing:
> https://github.com/markmandel/while-let
>
> As long as you are happy for your go loop to stop when nil comes through 
> (i.e. when it gets closed).
>
> (go (while-let [data ((println data)))
>
>
> Mark
>
>
> On Tue, Jan 14, 2014 at 4:34 PM, t x >wrote:
>
>> Understood. Thanks for the clarification.
>>
>>
>> On Mon, Jan 13, 2014 at 9:28 PM, Ben Mabey 
>> > wrote:
>>
>>> On Mon Jan 13 18:11:10 2014, t x wrote:
>>>
 Consider the following code block:


 (defn make-stupid []
   (go (loop []
 (recur

 (def x (make-stupid))

 ;; ... is there a way to kill this infinite go-loop ?

>>>
>>> No, you can not kill the loop with the go channel that is bound to x. 
>>>  You need to return a stop, a.k.a. poison, channel that the go block checks 
>>> before recurring. Something like:
>>>
>>> (let [stop (chan)]
>>>  (go
>>>   (loop []
>>> (when (alt! stop false :default :keep-going)
>>>   ...
>>>   (recur
>>>  stop)
>>>
>>> -Ben
>>>
>>> -- 
>>> -- 
>>> 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/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.com
>> 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/groups/opt_out.
>>
>
>
>
> -- 
> E: mark@gmail.com 
> T: http://www.twitter.com/neurotic
> W: www.compoundtheory.com
>
> 2 Devs from Down Under Podcast
> http://www.2ddu.com/
>  

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

[Xfeep Zhang]

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

ANN: core.match 0.2.1

[David Nolen]

The only significant change is the bugfix MATCH-92, keywords with dots now
supported.

http://github.com/clojure/core.match

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

Very strange behaviour in reducers

[Yves Parès]

Hello!
When mapping and reducing a map, it seems arguments are passed differently 
to the function that is mapped depending on whether you reduce with 
r/reduce or r/fold:

(r/fold +
(r/map (fn [k v] (inc v)) {:a 4 :b 5}))
But:
(r/reduce +
(r/map (fn [[k v]] (inc v)) {:a 4 :b 5}))

The function r/mapped is the same each time, but if the return value of 
r/map is further reduce with r/fold, it received 2 arguments (key and 
value). However, if it is reduced with r/reduce, the fn is called with ONE 
pair [k v].

Is that normal?

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

[Arlandis Lawrence]

The errors I'm getting indicate that the tables don't exist.
"Table "itinerary" not found; SQL statement:
 DELETE FROM "itinerary" [42102-164]
 org.h2.jdbc.JdbcSQLException: Table "itinerary" not found; SQL 
statement:
 DELETE FROM "itinerary" [42102-164]
  at 
org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
  at org.h2.message.DbException.get(DbException.java:169)
  at org.h2.message.DbException.get(DbException.java:146)
  at org.h2.command.Parser.readTableOrView(Parser.java:4753)
  at org.h2.command.Parser.readTableOrView(Parser.java:4731)
  at org.h2.command.Parser.readSimpleTableFilter(Parser.java:709)
  at org.h2.command.Parser.parseDelete(Parser.java:731)
  at org.h2.command.Parser.parsePrepared(Parser.java:336)
  at org.h2.command.Parser.parse(Parser.java:279)
  at org.h2.command.Parser.parse(Parser.java:251)
  at org.h2.command.Parser.prepareCommand(Parser.java:217)
  at org.h2.engine.Session.prepareLocal(Session.java:415)
  at org.h2.engine.Session.prepareCommand(Session.java:364)
  at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1121)
  at 
org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:71)
  at 
org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:267)
  at 
com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:213)
  ... 4 stack levels elided ...
  at korma.db$exec_sql.invoke(db.clj:206)
  at korma.db$do_query$fn__2578.invoke(db.clj:227)
  ... 1 stack levels elided ...
  at korma.db$do_query.invoke(db.clj:226)
  at korma.core$exec.invoke(core.clj:474)"

I've verified that using postgres instead of h2 works and that the 
migrations actually occur in the h2 in-memory database, but for some reason 
korma doesn't see the tables.
I suspect that korma is actually connecting to a different database, or is 
connecting after the original in-memory database has closed (I used the 
"DB_CLOSE_DELAY=-1" argument to try and mitigate this). 
Do you have any tips for examining the in-memory database manually in h2 or 
verifying that the databases I'm connecting to are the same?

On Monday, January 13, 2014 4:35:30 PM UTC-6, Christopher Allen wrote:
>
> Try it without H2 and check the contents of the database manually. "Korma 
> cooperating" doesn't mean a lot if the tables don't actually exist.
>
> Error messages should be provided in future.
>
> On Monday, January 13, 2014 1:44:28 PM UTC-8, Arlandis Lawrence wrote:
>>
>> I'm trying to use H2's in-memory database feature for running specs, so 
>> I'm using Ragtime to run migrations before the test.
>> Problem is, I can't get Korma to cooperate. Could someone take a look at 
>> this gist and see if it makes sense?
>>
>> https://gist.github.com/arlandism/8408370
>>
>

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

[Ghadi Shayban]

This code actually results in a subtle race condition as channels need to 
be locked internally.  It also won't work for other implementations of 
channel, of which there are several in core.async besides 
ManytoManyChannel. (For example, map< returns a reified channel.)  Knowing 
whether a channel is closed at put-time (with some restrictions) is a 
current work item in core.async.


On Monday, January 13, 2014 5:12:58 AM UTC-5, t x wrote:
>
> (let [c (async/chan 10)]
>   (println @(.-closed c))
>   (async/close! c)
>   (println @(.-closed c)))
>
>
> And we're done. Sorry for the spam. Last message send in case someone 
> finds my question via Google.
>
>
> On Mon, Jan 13, 2014 at 2:11 AM, t x >wrote:
>
>> Is there anyway, to "pierce the deftype"
>>
>>
>> https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L31
>>
>> to read the "closed" field of the ManytoMany Channel?
>>
>> That's basically all I need to do.
>>
>>
>> On Mon, Jan 13, 2014 at 1:47 AM, t x >wrote:
>>
>>> Hi,
>>>
>>>   I have the following problem:
>>>
>>>   I have a set of channels #{ ... }
>>>
>>>   some of the channels are closed, some of the channels are open
>>>
>>>   * for the channels that are open, I want to (>! chan msg)
>>>
>>>   * for the channels that are closed, I want to remove the channel from 
>>> the hash-set
>>>
>>>
>>> ## Problems:
>>>
>>> (1) (>! ... ...) always returns nil, regardless of whether the channel 
>>> is open or closed, and thus useless
>>>
>>> (2) I could use (>> but then would remove an item from the channel, which I don't want to do
>>>
>>>
>>> ## Question:
>>>
>>> Thus, without changing the state of the channel, is there a way to see 
>>> if the channel is open/closed?
>>>
>>> Thanks!
>>>
>>
>>
>

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

Re: >! on channels that are not yet closed

[Timothy Baldridge]

It's a known problem (putting into a closed channel), and one we have a
possible solution for (it's in one of the branches of core.async). I'll
bring it up this Friday and see if we can't make some progress on the code.

Timothy


On Tue, Jan 14, 2014 at 10:43 AM, Ghadi Shayban  wrote:

> This code actually results in a subtle race condition as channels need to
> be locked internally.  It also won't work for other implementations of
> channel, of which there are several in core.async besides
> ManytoManyChannel. (For example, map< returns a reified channel.)  Knowing
> whether a channel is closed at put-time (with some restrictions) is a
> current work item in core.async.
>
>
>
> On Monday, January 13, 2014 5:12:58 AM UTC-5, t x wrote:
>
>> (let [c (async/chan 10)]
>>   (println @(.-closed c))
>>   (async/close! c)
>>   (println @(.-closed c)))
>>
>>
>> And we're done. Sorry for the spam. Last message send in case someone
>> finds my question via Google.
>>
>>
>> On Mon, Jan 13, 2014 at 2:11 AM, t x  wrote:
>>
>>> Is there anyway, to "pierce the deftype"
>>>
>>> https://github.com/clojure/core.async/blob/master/src/
>>> main/clojure/clojure/core/async/impl/channels.clj#L31
>>>
>>> to read the "closed" field of the ManytoMany Channel?
>>>
>>> That's basically all I need to do.
>>>
>>>
>>> On Mon, Jan 13, 2014 at 1:47 AM, t x  wrote:
>>>
 Hi,

   I have the following problem:

   I have a set of channels #{ ... }

   some of the channels are closed, some of the channels are open

   * for the channels that are open, I want to (>! chan msg)

   * for the channels that are closed, I want to remove the channel from
 the hash-set


 ## Problems:

 (1) (>! ... ...) always returns nil, regardless of whether the channel
 is open or closed, and thus useless

 (2) I could use (>>> but then would remove an item from the channel, which I don't want to do


 ## Question:

 Thus, without changing the state of the channel, is there a way to see
 if the channel is open/closed?

 Thanks!

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



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: closing-buffer

[t x]

Hi Michal,

  After a good night's sleep, I've decided to not fight this battle at the
buffer layer.

  However, I appreciate (1) the code you've written and (2) the initial
suggestion (which got me interested enough to dig into internals of
Channels.clj / Mutex.clj / ... )



On Tue, Jan 14, 2014 at 5:31 AM, Alex Miller  wrote:

> From my perspective, a buffer is below the abstraction level of a channel.
> If you want a channel with special behavior, it seems like you should
> implement a channel.
>
>
> On Monday, January 13, 2014 10:47:22 PM UTC-6, t x wrote:
>>
>> I am aware of:
>>
>>   DroppingBuffer and SliddingBuffer
>>
>> I would like to build a channel with different semantics:
>>
>>   When I try to put an item on a full channel:
>>
>>   * DroppingBuffer drops the new item
>>   * SliddingBuffer evicts the oldest item
>>
>>   * ClosingBuffer should _close the channel_
>>
>> (thus, the receiver eventually gets a nil, and realizes "ah, was
>> disconnected")
>>
>> Now, I am looking at the github core.async code:
>>
>> DroppingBuffer: https://github.com/clojure/core.async/blob/
>> 76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/
>> clojure/core/async/impl/buffers.clj#L33-L45
>>
>> ManyToManyChannel: https://github.com/clojure/core.async/blob/
>> 76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/
>> clojure/core/async/impl/channels.clj#L31-L198
>>
>> ## Problem:
>>
>> DroppingBuffer is easy to understand. However, I don't think I can
>> implement "ClosingBuffer" as Buffer.
>>
>> I feel taht "ClosingBuffer" can only be implemneted at the Channel Level.
>>
>> However, the Channel Code is complicated.
>>
>> Is there a neat hack / trick to do what I described above?
>>
>> Thanks!
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: go "kill infinite loop"

[t x]

@Alex:

  Noted.

  In practice, it's not much of a problem to me, since objects I'm sending
over the channel are of the form:
  {:tag :message
   :return-chan ...
   :data ... actual message }



On Tue, Jan 14, 2014 at 5:39 AM, Alex Miller  wrote:

> Two notes:
>
> 1)The provided core.async go-loop macro is a small enhancement for the (go
> (loop )) case.
> 2) Be careful using when using falsey tests like when or if - these will
> stop on nil but will also stop on false coming through the channel. Might
> be ok here, but it's something to be aware of.
>
> Alex
>
>
> On Monday, January 13, 2014 11:45:52 PM UTC-6, Mark Mandel wrote:
>
>> I found this macro I wrote really useful for exactly this type of thing:
>> https://github.com/markmandel/while-let
>>
>> As long as you are happy for your go loop to stop when nil comes through
>> (i.e. when it gets closed).
>>
>> (go (while-let [data (>(println data)))
>>
>>
>> Mark
>>
>>
>> On Tue, Jan 14, 2014 at 4:34 PM, t x  wrote:
>>
>>> Understood. Thanks for the clarification.
>>>
>>>
>>> On Mon, Jan 13, 2014 at 9:28 PM, Ben Mabey  wrote:
>>>
 On Mon Jan 13 18:11:10 2014, t x wrote:

> Consider the following code block:
>
>
> (defn make-stupid []
>   (go (loop []
> (recur
>
> (def x (make-stupid))
>
> ;; ... is there a way to kill this infinite go-loop ?
>

 No, you can not kill the loop with the go channel that is bound to x.
  You need to return a stop, a.k.a. poison, channel that the go block checks
 before recurring. Something like:

 (let [stop (chan)]
  (go
   (loop []
 (when (alt! stop false :default :keep-going)
   ...
   (recur
  stop)

 -Ben


 --
 --
 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/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.com
>>>
>>> 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/groups/opt_out.
>>>
>>
>>
>>
>> --
>> E: mark@gmail.com
>>
>> T: http://www.twitter.com/neurotic
>> W: www.compoundtheory.com
>>
>> 2 Devs from Down Under Podcast
>> http://www.2ddu.com/
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "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: >! on channels that are not yet closed

[t x]

@Ghadi,


Are you referring to the race condition between:

(check if channel is closed)
### BAM SOMETHING HAPPENS
(put something on to the channel)

?


I agree it's a race condition, however after some refactoring, I no longer
care if I'm >!-ing onto a closed channel, as long as I eventually know that
the channel is closed. (Usage case; I have a list of channels that I need
to blast; I want to drop the already closed channels from the list.)


On Tue, Jan 14, 2014 at 9:56 AM, Timothy Baldridge wrote:

> It's a known problem (putting into a closed channel), and one we have a
> possible solution for (it's in one of the branches of core.async). I'll
> bring it up this Friday and see if we can't make some progress on the code.
>
> Timothy
>
>
> On Tue, Jan 14, 2014 at 10:43 AM, Ghadi Shayban wrote:
>
>> This code actually results in a subtle race condition as channels need to
>> be locked internally.  It also won't work for other implementations of
>> channel, of which there are several in core.async besides
>> ManytoManyChannel. (For example, map< returns a reified channel.)  Knowing
>> whether a channel is closed at put-time (with some restrictions) is a
>> current work item in core.async.
>>
>>
>>
>> On Monday, January 13, 2014 5:12:58 AM UTC-5, t x wrote:
>>
>>> (let [c (async/chan 10)]
>>>   (println @(.-closed c))
>>>   (async/close! c)
>>>   (println @(.-closed c)))
>>>
>>>
>>> And we're done. Sorry for the spam. Last message send in case someone
>>> finds my question via Google.
>>>
>>>
>>> On Mon, Jan 13, 2014 at 2:11 AM, t x  wrote:
>>>
  Is there anyway, to "pierce the deftype"

 https://github.com/clojure/core.async/blob/master/src/
 main/clojure/clojure/core/async/impl/channels.clj#L31

 to read the "closed" field of the ManytoMany Channel?

 That's basically all I need to do.


 On Mon, Jan 13, 2014 at 1:47 AM, t x  wrote:

> Hi,
>
>   I have the following problem:
>
>   I have a set of channels #{ ... }
>
>   some of the channels are closed, some of the channels are open
>
>   * for the channels that are open, I want to (>! chan msg)
>
>   * for the channels that are closed, I want to remove the channel
> from the hash-set
>
>
> ## Problems:
>
> (1) (>! ... ...) always returns nil, regardless of whether the channel
> is open or closed, and thus useless
>
> (2) I could use ( but then would remove an item from the channel, which I don't want to do
>
>
> ## Question:
>
> Thus, without changing the state of the channel, is there a way to see
> if the channel is open/closed?
>
> Thanks!
>


>>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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+u

Re: >! on channels that are not yet closed

[t x]

@Timothy:

Looking forward to your changes. Thanks for all the existing work with
core.async! (I was half tempted to switch to Scala to use Akka right before
core.async came out.)


On Tue, Jan 14, 2014 at 10:30 AM, t x  wrote:

> @Ghadi,
>
>
> Are you referring to the race condition between:
>
> (check if channel is closed)
> ### BAM SOMETHING HAPPENS
> (put something on to the channel)
>
> ?
>
>
> I agree it's a race condition, however after some refactoring, I no longer
> care if I'm >!-ing onto a closed channel, as long as I eventually know that
> the channel is closed. (Usage case; I have a list of channels that I need
> to blast; I want to drop the already closed channels from the list.)
>
>
> On Tue, Jan 14, 2014 at 9:56 AM, Timothy Baldridge 
> wrote:
>
>> It's a known problem (putting into a closed channel), and one we have a
>> possible solution for (it's in one of the branches of core.async). I'll
>> bring it up this Friday and see if we can't make some progress on the code.
>>
>> Timothy
>>
>>
>> On Tue, Jan 14, 2014 at 10:43 AM, Ghadi Shayban wrote:
>>
>>> This code actually results in a subtle race condition as channels need
>>> to be locked internally.  It also won't work for other implementations of
>>> channel, of which there are several in core.async besides
>>> ManytoManyChannel. (For example, map< returns a reified channel.)  Knowing
>>> whether a channel is closed at put-time (with some restrictions) is a
>>> current work item in core.async.
>>>
>>>
>>>
>>> On Monday, January 13, 2014 5:12:58 AM UTC-5, t x wrote:
>>>
 (let [c (async/chan 10)]
   (println @(.-closed c))
   (async/close! c)
   (println @(.-closed c)))


 And we're done. Sorry for the spam. Last message send in case someone
 finds my question via Google.


 On Mon, Jan 13, 2014 at 2:11 AM, t x  wrote:

>  Is there anyway, to "pierce the deftype"
>
> https://github.com/clojure/core.async/blob/master/src/
> main/clojure/clojure/core/async/impl/channels.clj#L31
>
> to read the "closed" field of the ManytoMany Channel?
>
> That's basically all I need to do.
>
>
> On Mon, Jan 13, 2014 at 1:47 AM, t x  wrote:
>
>> Hi,
>>
>>   I have the following problem:
>>
>>   I have a set of channels #{ ... }
>>
>>   some of the channels are closed, some of the channels are open
>>
>>   * for the channels that are open, I want to (>! chan msg)
>>
>>   * for the channels that are closed, I want to remove the channel
>> from the hash-set
>>
>>
>> ## Problems:
>>
>> (1) (>! ... ...) always returns nil, regardless of whether the
>> channel is open or closed, and thus useless
>>
>> (2) I could use (> nil, but then would remove an item from the channel, which I don't want 
>> to
>> do
>>
>>
>> ## Question:
>>
>> Thus, without changing the state of the channel, is there a way to
>> see if the channel is open/closed?
>>
>> Thanks!
>>
>
>
  --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/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 m

Re: [ANN] incise 0.1.0 - An extensible static site generator

[Ryan McGowan]

Hey Jan,

My decisions were mostly in an effort to reduce the number of hard
dependencies. If you do a search on the incise repository for
"hiccup",
you'll see it is not used in any core functionality (besides server to
generate a trivial 404 page). The only place hiccup is really used are in
layout implementations. You could easily implement a layout without using
any of the helper macros (deflayout, defpartial) that supports hiccup
instead. Version 0.2.0 is going to break apart the project to remove as
many dependencies as possible from incise-core.

Thanks,

Ryan


On Tue, Jan 14, 2014 at 12:26 AM, Jan Herich  wrote:

> Hello Ryan,
>
> Thank you for the project, i was always missing a good static site
> generator written in clojure !
> You took some interesting design decisions with extensibility. I'm
> currently working on the
> similar project , even if my
> design is very different, because my needs are different - i want to
> have templates in pure html and be able to declaratively specify specific
> areas, because of that
> my project is based on enlive html library.
>
>
> Dňa utorok, 14. januára 2014 8:35:33 UTC+1 Ryan McGowan napísal(-a):
>
>> Hi all!
>>
>> After consuming quite a bit of my spare time for the past several months,
>> I have finally released version 0.1.0  of
>> incise. It is a static site generator written in Clojure (of course). I
>> like it quite a bit and I think others might benefit from it too.  I am
>> very open to contributions, suggestions or criticisms (just open an
>> issue) .
>>
>> Necessary links:
>>
>>- https://clojars.org/incise
>>- http://www.ryanmcg.com/incise/ - README generated into website
>>using itself (it's called being meta).
>>- https://github.com/RyanMcG/incise
>>- https://github.com/RyanMcG/lein-incise - Yes there is a plugin
>>- http://www.ryanmcg.com/2014/1/13/static-website-generation-
>>with-incise/ - Very short post about it. Basically points to the
>>README and makes the disclaimer that it's not a big deal.
>>- https://github.com/RyanMcG/incise-example-project - super simple
>>example project
>>- http://www.ryanmcg.com/incise-example-project/ - and its generated
>>output
>>
>> Thanks,
>>
>> Ryan McGowan
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/8AI4JIfVCB8/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

Effects of diving into Clojure

[gvim]

I recently took the plunge into learning Clojure and love it. Since I 
tend to be single-minded/all-or-nothing about these things I'm now 
finding it very difficult to switch mindset when I have to work with 
Ruby. Anyone else experienced this? If you get deeply into a programming 
language it alters the way you think and approach design/solutions which 
is one reason I've never understood the advice to try to learn many 
programming languages. With Clojure the functional/Lisp structure is so 
radically different and elegant that switching to standard OO/mutable 
state/infix approaches starts to feel alien. Maybe it's just me.


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

Re: Nginx-Clojure Let You Deploy Clojure Web App on Nginx Without Any Java Web Server

[Mingli Yuan]

Hi, Xfeep,

Thanks for your contribution, and the project looks interesting.

For me, the idea of driving ring webapp behind nginx is not new.
We use uwsgi to drive our ring app behind nginx in our production.
uwsgi support JVM and ring for almost one year, and I think the code is
relative stable right now.

- it support a native protocol between nginx and uwsgi which is more
efficient than http
- it support unix socket
- and a rich uwsgi api layer to provide some means to communicate between
webapps
- and according to the performance tests by the author, it is a little bit
faster than jetty.

It is on our production for half a year, quite stable, and very harmonious
with the python app.

I am not want to sale the solution of uwsgi, but it worth taking a look and
make some comparison.

Regards,
Mingli


On Tue, Jan 14, 2014 at 9:12 PM, Xfeep Zhang  wrote:

> You are welcome!
>
> Yes, you are right.  One JVM instance is embed  per Nginx Worker process.
> The number of Nginx Workers  is generally the same with the number of CPU.
>
> If one Worker crashs the Nginx Master will create a new one so you don't
> worry about JVM crashs accidentally.
>
> Although there will be several JVM instances,  there 's only one main
> thread attached with the Nginx Woker process.
>
> So the JVM instance uses less memory and no thread context switch cost in
> every JVM instance.
>
> In some cases If you can  use only one JVM instance,  you can set the
> Nginx Worker number to be 1 and set jvm_workers > 1,  nginx-clojure will
> create
>
> a thread pool with fixed number of thread.
>
> to handle requests for you.
>
>
> On Tuesday, January 14, 2014 5:50:34 PM UTC+8, Feng Shen wrote:
>>
>> Hi,
>>
>> Thanks for your work on nginx-clojure. It looks great!
>>
>> As I know Nginx spawns many processes(correct me if I am wrong),  does
>> that mean, there will be many JVM process?
>>
>>
>>
>>
>> On Tuesday, January 14, 2014 4:44:18 PM UTC+8, Xfeep Zhang wrote:
>>>
>>>
>>> I have done the first one. The result is 
>>> HERE(
>>> https://github.com/ptaoussanis/clojure-web-server-benchmarks )
>>> Thanks Taoussanis for his invitation to the project
>>> clojure-web-server-benchmarkshosted
>>>  on Github.
>>>
>>> On Tuesday, January 14, 2014 10:31:03 AM UTC+8, Xfeep Zhang wrote:

 You're welcome.

 I think there are several difficult phases :

 (1)  update the test program in 
 clojure-web-server-benchmarks,
  make the some packages to be the latest. (eg. http-kit from 1.3.0-alpha2
 --> 2.1.16) and add nginx-php testing
 (2)  test about real world size contents by group eg. tiny, small,
 medium, huge.
 (3)  test about real world connection circumstances where a lot of
 connection is inactive but keep open.
 (4)  try some real asynchronous test to fetch external resources (eg.
 rest service , db) before response to the client. eg.  using 
 libdrizzlea no-blocking mysql  client from
 https://launchpad.net/drizzle

 On Tuesday, January 14, 2014 2:41:50 AM UTC+8, Sergey Didenko wrote:
>
> Looks very interesting, thank you for your work!
>
> I wonder how this is going to improve latency in comparison to nginx +
> http-kit for some real world test that is not using heavy DB operations.
>
>
> On Mon, Jan 13, 2014 at 5:57 AM, Xfeep Zhang  wrote:
>
>>
>> So far I have found why nginx-clojure is slower than http-kit when
>> 1 concurrents. (when < = 1000 concurrents nginx-clojure is faster 
>> than
>> http-kit.)
>> I have set too many connections per nginx worker (worker_connections
>> = 2) . This make nginx only use one worker to handle ab  requests
>> (every request is tiny).
>> I plan to take note of 
>> c-erlang-java-performanceand
>>  fork
>> clojure-web-server-benchmarksto
>>   do some  real world tests.
>>
>>
>>
>> On Sunday, January 12, 2014 11:21:06 PM UTC+8, Xfeep Zhang wrote:
>>>
>>> Sorry for my mistake!
>>>
>>> 1. In the static file test, the ring-jetty result is about 10
>>> concurrents. NOT 1 concurrents  ("Concurrency Level:  10" in  
>>> the
>>> ab report ).
>>> 2. In the small string test, All results about three server are
>>> about 10 concurrents. NOT 1 concurrents.
>>>
>>> There are right results about these two mistake :
>>>
>>> 1. static file test
>>>
>>> (3) ring-jetty  more bad than 10 concurrents
>>> 
>>> ===
>>> Document Path:  /
>>> Document Length:  

Re: Very strange behaviour in reducers

[Filip Štaffa]

Hi Yves,

I guess it is because r/reduce calls r/reduce-kv (which is specific for 
map), while r/fold it does not have such special handling

Filip

On Tuesday, January 14, 2014 4:43:10 PM UTC+1, Yves Parès wrote:
>
> Hello!
> When mapping and reducing a map, it seems arguments are passed differently 
> to the function that is mapped depending on whether you reduce with 
> r/reduce or r/fold:
>
> (r/fold +
> (r/map (fn [k v] (inc v)) {:a 4 :b 5}))
> But:
> (r/reduce +
> (r/map (fn [[k v]] (inc v)) {:a 4 :b 5}))
>
> The function r/mapped is the same each time, but if the return value of 
> r/map is further reduce with r/fold, it received 2 arguments (key and 
> value). However, if it is reduced with r/reduce, the fn is called with ONE 
> pair [k v].
>
> Is that normal?
>

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

[Gary Trakhman]

Maybe don't switch mindset? Write code that looks like idiomatic ruby but
has what appears to rubyists as QWAN.

I think it's possible and maybe even desirable for bad things to feel more
foreign when your understanding increases.


On Tue, Jan 14, 2014 at 2:01 PM, gvim  wrote:

> I recently took the plunge into learning Clojure and love it. Since I tend
> to be single-minded/all-or-nothing about these things I'm now finding it
> very difficult to switch mindset when I have to work with Ruby. Anyone else
> experienced this? If you get deeply into a programming language it alters
> the way you think and approach design/solutions which is one reason I've
> never understood the advice to try to learn many programming languages.
> With Clojure the functional/Lisp structure is so radically different and
> elegant that switching to standard OO/mutable state/infix approaches starts
> to feel alien. Maybe it's just me.
>
> 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/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: Effects of diving into Clojure

[Mark]

I have felt your pain.  I started life with Smalltalk and more or less 
spent the last 15 years in Java.  When I started Clojure, it was very hard 
to break my thinking habits.  Particularly, I was lost without manifest 
typing.  I didn't realize how much types documented my system and allowed 
very lazy thinking on my part.  I had less trouble with immutability as I 
had developed the habit of coding immutable objects in Java.  

I started dabbling in Clojure about a year ago and started coding a serious 
project about 3 months ago.  Only recently have I gotten used to thinking 
about mapping functions over data as opposed to looping through a 
collection although I still find myself coding loop/recur and then 
realizing I could use map.  I've also developed very different work habits 
due to the REPL.  

In my own case, the particular changes in my thinking that have really 
aided me are:

   1. Being able to visualize the data structure that a function is 
   operating on
   2. I find that my code falls into two categories:  computing new data or 
   transforming data structures
   3. Never try to compute new data and transform data at the same time
   4. Much of the time computing new data is either map or reduce. 
Understanding these two (especially the flexibility of reduce) is huge
   5. 80% of the time that I want to transform data, postwalk is the answer

I'm sure that as I get to know the Clojure libraries better, the specifics 
around #4 and #5 will change but I bet the first three are pretty constant.

On Tuesday, January 14, 2014 11:01:14 AM UTC-8, g vim wrote:
>
> I recently took the plunge into learning Clojure and love it. Since I 
> tend to be single-minded/all-or-nothing about these things I'm now 
> finding it very difficult to switch mindset when I have to work with 
> Ruby. Anyone else experienced this? If you get deeply into a programming 
> language it alters the way you think and approach design/solutions which 
> is one reason I've never understood the advice to try to learn many 
> programming languages. With Clojure the functional/Lisp structure is so 
> radically different and elegant that switching to standard OO/mutable 
> state/infix approaches starts to feel alien. Maybe it's just me. 
>
> 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/groups/opt_out.

Re: Effects of diving into Clojure

[gvim]

It's been the other way round for me. I always felt Ruby was doing too 
much under the hood. So much so that I bought "Ruby Under A Microscope" 
just to find out what was going on. I found it very easy to switch to 
Clojure because everything is so much more transparent. Now Ruby just 
feels awkward though I still need to use it due to its mindshare in the 
web development domain.


gvim


On 14/01/2014 19:18, Mark wrote:

I have felt your pain.  I started life with Smalltalk and more or less
spent the last 15 years in Java.  When I started Clojure, it was very
hard to break my thinking habits.  Particularly, I was lost without
manifest typing.  I didn't realize how much types documented my system
and allowed very lazy thinking on my part.  I had less trouble with
immutability as I had developed the habit of coding immutable objects in
Java.

I started dabbling in Clojure about a year ago and started coding a
serious project about 3 months ago.  Only recently have I gotten used to
thinking about mapping functions over data as opposed to looping through
a collection although I still find myself coding loop/recur and then
realizing I could use map.  I've also developed very different work
habits due to the REPL.

In my own case, the particular changes in my thinking that have really
aided me are:

 1. Being able to visualize the data structure that a function is
operating on
 2. I find that my code falls into two categories:  computing new data
or transforming data structures
 3. Never try to compute new data and transform data at the same time
 4. Much of the time computing new data is either map or reduce.
  Understanding these two (especially the flexibility of reduce) is huge
 5. 80% of the time that I want to transform data, postwalk is the answer

I'm sure that as I get to know the Clojure libraries better, the
specifics around #4 and #5 will change but I bet the first three are
pretty constant.



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

[Mark]

I misread the critical piece of your post :)  You are, indeed, a step ahead 
of me

On Tuesday, January 14, 2014 11:30:13 AM UTC-8, g vim wrote:
>
> It's been the other way round for me. I always felt Ruby was doing too 
> much under the hood. So much so that I bought "Ruby Under A Microscope" 
> just to find out what was going on. I found it very easy to switch to 
> Clojure because everything is so much more transparent. Now Ruby just 
> feels awkward though I still need to use it due to its mindshare in the 
> web development domain. 
>
> gvim 
>
>
> On 14/01/2014 19:18, Mark wrote: 
> > I have felt your pain.  I started life with Smalltalk and more or less 
> > spent the last 15 years in Java.  When I started Clojure, it was very 
> > hard to break my thinking habits.  Particularly, I was lost without 
> > manifest typing.  I didn't realize how much types documented my system 
> > and allowed very lazy thinking on my part.  I had less trouble with 
> > immutability as I had developed the habit of coding immutable objects in 
> > Java. 
> > 
> > I started dabbling in Clojure about a year ago and started coding a 
> > serious project about 3 months ago.  Only recently have I gotten used to 
> > thinking about mapping functions over data as opposed to looping through 
> > a collection although I still find myself coding loop/recur and then 
> > realizing I could use map.  I've also developed very different work 
> > habits due to the REPL. 
> > 
> > In my own case, the particular changes in my thinking that have really 
> > aided me are: 
> > 
> >  1. Being able to visualize the data structure that a function is 
> > operating on 
> >  2. I find that my code falls into two categories:  computing new data 
> > or transforming data structures 
> >  3. Never try to compute new data and transform data at the same time 
> >  4. Much of the time computing new data is either map or reduce. 
> >   Understanding these two (especially the flexibility of reduce) is 
> huge 
> >  5. 80% of the time that I want to transform data, postwalk is the 
> answer 
> > 
> > I'm sure that as I get to know the Clojure libraries better, the 
> > specifics around #4 and #5 will change but I bet the first three are 
> > pretty constant. 
> > 
>

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

[Travis Vachon]

+1 here. I'm afraid the only solution I've found is to stop writing
Ruby. ¯\_(ツ)_/¯

On Tue, Jan 14, 2014 at 2:39 PM, Mark  wrote:
> I misread the critical piece of your post :)  You are, indeed, a step ahead
> of me
>
>
> On Tuesday, January 14, 2014 11:30:13 AM UTC-8, g vim wrote:
>>
>> It's been the other way round for me. I always felt Ruby was doing too
>> much under the hood. So much so that I bought "Ruby Under A Microscope"
>> just to find out what was going on. I found it very easy to switch to
>> Clojure because everything is so much more transparent. Now Ruby just
>> feels awkward though I still need to use it due to its mindshare in the
>> web development domain.
>>
>> gvim
>>
>>
>> On 14/01/2014 19:18, Mark wrote:
>> > I have felt your pain.  I started life with Smalltalk and more or less
>> > spent the last 15 years in Java.  When I started Clojure, it was very
>> > hard to break my thinking habits.  Particularly, I was lost without
>> > manifest typing.  I didn't realize how much types documented my system
>> > and allowed very lazy thinking on my part.  I had less trouble with
>> > immutability as I had developed the habit of coding immutable objects in
>> > Java.
>> >
>> > I started dabbling in Clojure about a year ago and started coding a
>> > serious project about 3 months ago.  Only recently have I gotten used to
>> > thinking about mapping functions over data as opposed to looping through
>> > a collection although I still find myself coding loop/recur and then
>> > realizing I could use map.  I've also developed very different work
>> > habits due to the REPL.
>> >
>> > In my own case, the particular changes in my thinking that have really
>> > aided me are:
>> >
>> >  1. Being able to visualize the data structure that a function is
>> > operating on
>> >  2. I find that my code falls into two categories:  computing new data
>> > or transforming data structures
>> >  3. Never try to compute new data and transform data at the same time
>> >  4. Much of the time computing new data is either map or reduce.
>> >   Understanding these two (especially the flexibility of reduce) is
>> > huge
>> >  5. 80% of the time that I want to transform data, postwalk is the
>> > answer
>> >
>> > I'm sure that as I get to know the Clojure libraries better, the
>> > specifics around #4 and #5 will change but I bet the first three are
>> > pretty constant.
>> >
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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: Effects of diving into Clojure

[Bob Hutchison]

On Jan 14, 2014, at 2:01 PM, gvim  wrote:

> I recently took the plunge into learning Clojure and love it. Since I tend to 
> be single-minded/all-or-nothing about these things I'm now finding it very 
> difficult to switch mindset when I have to work with Ruby. Anyone else 
> experienced this?

I think everyone who makes the attempt to learn more than one different 
programming language experiences this at some early point (like their second 
major language :-), and then suffers unpredictably recurring bouts over time.

> If you get deeply into a programming language it alters the way you think and 
> approach design/solutions which is one reason I've never understood the 
> advice to try to learn many programming languages.

You’ve described one of the most important reasons behind that advice. Do you 
really think your Ruby experience has not informed your Clojure experience? And 
when you go back to Ruby do you really forget what you learned from Clojure? 
Even the most ‘useless’ of languages have something interesting to say about 
the problem they're designed to address (and for me, that’d be COBOL).

> With Clojure the functional/Lisp structure is so radically different and 
> elegant that switching to standard OO/mutable state/infix approaches starts 
> to feel alien. Maybe it's just me.

No it’s not just you. Hardly! However, I’d caution you against allowing this 
situation to continue. Preference is one thing. Isolating yourself from 
demonstrably successful ideas is another. Not to mention abandoning everything 
you’ve attained through the learning of Ruby. Keep going back and forth until 
all that’s left is preference.

Sorry for the pontificating :-)

Cheers,
Bob

> 
> 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/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: Effects of diving into Clojure

[gvim]

No, you're probably right. It's just that there never seem to be enough 
hours in a day/life :(


gvim


On 14/01/2014 20:26, Bob Hutchison wrote:


No it’s not just you. Hardly! However, I’d caution you against allowing this 
situation to continue. Preference is one thing. Isolating yourself from 
demonstrably successful ideas is another. Not to mention abandoning everything 
you’ve attained through the learning of Ruby. Keep going back and forth until 
all that’s left is preference.

Sorry for the pontificating :-)


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

[Bob Hutchison]

On Jan 14, 2014, at 3:46 PM, gvim  wrote:

> No, you're probably right. It's just that there never seem to be enough hours 
> in a day/life :(

You’re not alone there either :-)

Cheers,
Bob

> 
> gvim
> 
> 
> On 14/01/2014 20:26, Bob Hutchison wrote:
> 
>> No it’s not just you. Hardly! However, I’d caution you against allowing this 
>> situation to continue. Preference is one thing. Isolating yourself from 
>> demonstrably successful ideas is another. Not to mention abandoning 
>> everything you’ve attained through the learning of Ruby. Keep going back and 
>> forth until all that’s left is preference.
>> 
>> Sorry for the pontificating :-)
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to 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: go "kill infinite loop"

[Mark Mandel]

On Wed, Jan 15, 2014 at 12:39 AM, Alex Miller  wrote:

> 2) Be careful using when using falsey tests like when or if - these will
> stop on nil but will also stop on false coming through the channel. Might
> be ok here, but it's something to be aware of.


Oooh! that is a really good point! I honestly didn't think of that.  In my
case, it won't but it's definitely something to consider.

Mark


-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast
http://www.2ddu.com/

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

[Mimmo Cosenza]

On Jan 14, 2014, at 9:26 AM, Ivan L  wrote:

> This is excellent work!  I played around with cljs-start tonight, thanks so 
> much for your work.

I'm glad you find it useful.

> 
> One hopefully quick question.  Assuming the CCW lein headless start and then 
> (run) and (browser-repl), how can the cljs namespace being edited be updated?

I have to admit that I touched CCW for the very first time last weekend, 
because Laurent Petit needed an example of austin configuration and usage for 
improving CCW interoperability with complex project/templates.

So, I really don't how to keep the CLJS repl updated in CCW.  
> 
> My first thought was to simply use ccw to reload or evaluate selection to 
> repl, but it seems to fail randomly (or maybe its missing dependences?  

Pay attention at the namespaces in the cljs repl and in the editor window. 
Again I don't know about CCW, but is the same thing I do in emacs. 

> Another thought would be to run another repl external to eclipse and have 
> that be cljsbuild auto and keep on reloading the page (localhost:3000) 
> manually.

Depends on the workflow that works better for you.

Recently I found my self in the following situation:
- no matter how better is becoming the CLJS REPL experience, I still prefer the 
CLJ REPL. To me, JS in an accident. Is here to stay, like the R&R, but less 
JS/HTML/CSS code I read, the better for my eyes and my brain too

Because of this bad attitude towards JS, I'm starting experimenting the 
following workflow:

Principles and guide lines
- keep the CLJS code which implements logics separated from the CLJS code which 
implements rendering (which I'm very bad for). 
- write the CLJS code which implements the logic in pure CLJ code (i.e. cljx 
lein plugin);
- write the CLJS code which implements the unit tests of the above code in pure 
CLJ code (.cljx extensions);
- use a testing lib with the same API on both sides (i.e. java and JS). The 
only one I'm aware of is clojurescript.test/clojure.test (in the near future 
I'd like to introduce double-check too in my workflow).

Now the corresponding workflow:
- open your project in the editor/ide you prefer (last week for the very first 
time I did not use emacs)
- from a terminal launch the `lein cljx auto` task. 
- from an other terminal, launch the `lein cljsbuild once` task 
- launch the `lein test-refresh` task (test-refresh is a lein plugin)

Now in one terminal you can see the clix running when you save your code. It 
generates both clj and cljs code, but at the beginning I take care of CLJ only. 

In the other terminal you see the unit testing being re-executed because in the 
mean time the newly generated clj code/unit tests code have been recompiled. 
The test-refresh does this work for you. 

I always like to have a CLJ REPL around me to test something small that allows 
me to isolate what I need at the moment. I don't know how to do it with CCW, 
but I do it both in emacs and in Light Table, so there should be a way to 
reload the clj/cljs code from  CCW into the REPL. 

When the code works for CLJ:

- I launch the `lein cljsbuild auto` task from a third terminal. Hopefully 
everything get compiled. If not, fix the bug. In is not you bug, it could be a 
subtle difference between CLJ and CLJS, or, better, a bug in CLJS that you 
search/submit in JIRA
- If everything gets compiled, I launch the `lein cljsbuild test` command from 
a fourth terminal. 
- If all tests passed, then you have to repeat them with more aggressive 
compilation options. 

Do the following:
- lein clean
- lein with-profiles simple do clix once, cljsbuild once, cljsbuild test

You can eventually add a lein :alias for the above chain.

If everything is still working with the simple compilation, you can now go on 
with the :advanced compiler option.

- lein with-profiles simple clean
- lein with-profiles advanced clix once, cljsbuild once, cljsbuild test

At the moment this is the shortest path I found to have something to work with. 
I think I should add hardness to cljs-start, the sort of thing Stuart Sierra 
did.

There are two things that really annoy me at the moment:
- the fact that I can't use the :none compilation option in the :dev profile, 
because clojurescript.test does not support it. This is a pity, because the 
compilation time with the :none compilation its really unbelievable fast after 
the very first time, while the :whitespace compilation time gets you irritable
- the fact that that I did not find a test-plugin correspondent for 
cljurescript.test. Probably with some efforts someone could make test-refresh a 
two sides guy.

HIH

 Mimmo
  
> 
> What do you suggest?
> 
> Thanks again, thanks for such great work.
> 
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, sen

Re: Granularity in Leiningen profile loading

[Phil Hagelberg]

Can you be more specific about what you did and what you would expect to 
happen in that case?

-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
--- 
You received this message because you are subscribed to 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: Granularity in Leiningen profile loading

[gvim]

In ~/.lein/profiles.clj I have:

{:user {:plugins [[lein-ritz "0.7.0"] [lein-ancient "0.5.4"]]
:dependencies [[org.clojure/core.typed "0.2.21"]
   [org.clojure/core.match "0.2.0"]
   [co.paralleluniverse/pulsar "0.3.0"]]}}

... and I ~/.lein/projfiles.d/cljs.clj I have:

{:plugins [[lein-cljsbuild "1.0.1"]]
 :dependencies [[org.clojure/clojurescript "0.0-2138"]
[om "0.1.5"]]}

After `line new yes` I added a profiles entry to my project.clj file and 
now have:


(defproject yes "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME";
  :license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.5.1"]]
  :profiles {:clj {}})

... but after `lein deps :tree` the cljs profile still isn't loaded.

I was expecting the deps from ~/.lein/profiles.d/cljs.clj to be loaded 
into the 'yes' project. How should this profile be specified in my 
project.clj file?


gvim



On 14/01/2014 23:53, Phil Hagelberg wrote:

Can you be more specific about what you did and what you would expect to
happen in that case?

-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
---
You received this message because you are subscribed to 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: Ragtime w/ Korma

[Christopher Allen]

Verify with clojure.java.jdbc would by my first approach, but it's not 
clear to me how you can know migratus and Korma aren't touching two 
different instantiations of the H2 in memory database using c.j.j.

I don't know anything about H2. I'm a PostgreSQL user.


On Tuesday, January 14, 2014 7:50:07 AM UTC-8, Arlandis Lawrence wrote:
>
> The errors I'm getting indicate that the tables don't exist.
> "Table "itinerary" not found; SQL statement:
>  DELETE FROM "itinerary" [42102-164]
>  org.h2.jdbc.JdbcSQLException: Table "itinerary" not found; SQL 
> statement:
>  DELETE FROM "itinerary" [42102-164]
>   at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
>   at org.h2.message.DbException.get(DbException.java:169)
>   at org.h2.message.DbException.get(DbException.java:146)
>   at org.h2.command.Parser.readTableOrView(Parser.java:4753)
>   at org.h2.command.Parser.readTableOrView(Parser.java:4731)
>   at org.h2.command.Parser.readSimpleTableFilter(Parser.java:709)
>   at org.h2.command.Parser.parseDelete(Parser.java:731)
>   at org.h2.command.Parser.parsePrepared(Parser.java:336)
>   at org.h2.command.Parser.parse(Parser.java:279)
>   at org.h2.command.Parser.parse(Parser.java:251)
>   at org.h2.command.Parser.prepareCommand(Parser.java:217)
>   at org.h2.engine.Session.prepareLocal(Session.java:415)
>   at org.h2.engine.Session.prepareCommand(Session.java:364)
>   at 
> org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1121)
>   at 
> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:71)
>   at 
> org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:267)
>   at 
> com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:213)
>   ... 4 stack levels elided ...
>   at korma.db$exec_sql.invoke(db.clj:206)
>   at korma.db$do_query$fn__2578.invoke(db.clj:227)
>   ... 1 stack levels elided ...
>   at korma.db$do_query.invoke(db.clj:226)
>   at korma.core$exec.invoke(core.clj:474)"
>
> I've verified that using postgres instead of h2 works and that the 
> migrations actually occur in the h2 in-memory database, but for some reason 
> korma doesn't see the tables.
> I suspect that korma is actually connecting to a different database, or is 
> connecting after the original in-memory database has closed (I used the 
> "DB_CLOSE_DELAY=-1" argument to try and mitigate this). 
> Do you have any tips for examining the in-memory database manually in h2 
> or verifying that the databases I'm connecting to are the same?
>
> On Monday, January 13, 2014 4:35:30 PM UTC-6, Christopher Allen wrote:
>>
>> Try it without H2 and check the contents of the database manually. "Korma 
>> cooperating" doesn't mean a lot if the tables don't actually exist.
>>
>> Error messages should be provided in future.
>>
>> On Monday, January 13, 2014 1:44:28 PM UTC-8, Arlandis Lawrence wrote:
>>>
>>> I'm trying to use H2's in-memory database feature for running specs, so 
>>> I'm using Ragtime to run migrations before the test.
>>> Problem is, I can't get Korma to cooperate. Could someone take a look at 
>>> this gist and see if it makes sense?
>>>
>>> https://gist.github.com/arlandism/8408370
>>>
>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Nginx-Clojure Let You Deploy Clojure Web App on Nginx Without Any Java Web Server

[Xfeep Zhang]

Hi Mingli, 

Thanks for  your suggestion.

Nginx-Clojure is quite different from uwsgi when supports JVM.

Nginx-Clojure make JVM embed into Nginx worker process. JVM and Nginx 
worker have  the same memory process space.

 Nginx-Clojure heavy uses pointer operation just like C to handle memory 
with Nginx worker. 

 If I'm not wrong,  uwsgi create every process for every request, or shared 
JVM processes between request?

When using Nginx-Clojure there's no IPC cost  even no thread switch cost if 
jvm_workers = 0 which is default.

So it's why Nginx-Clojure is so fast! 


On Wednesday, January 15, 2014 3:07:13 AM UTC+8, Mingli Yuan wrote:
>
> Hi, Xfeep,
>
> Thanks for your contribution, and the project looks interesting.
>
> For me, the idea of driving ring webapp behind nginx is not new. 
> We use uwsgi to drive our ring app behind nginx in our production.
> uwsgi support JVM and ring for almost one year, and I think the code is 
> relative stable right now.
>
> - it support a native protocol between nginx and uwsgi which is more 
> efficient than http
> - it support unix socket
> - and a rich uwsgi api layer to provide some means to communicate between 
> webapps
> - and according to the performance tests by the author, it is a little bit 
> faster than jetty.
>
> It is on our production for half a year, quite stable, and very harmonious 
> with the python app.
>
> I am not want to sale the solution of uwsgi, but it worth taking a look 
> and make some comparison.
>
> Regards,
> Mingli
>
>
> On Tue, Jan 14, 2014 at 9:12 PM, Xfeep Zhang 
> > wrote:
>
>> You are welcome! 
>>
>> Yes, you are right.  One JVM instance is embed  per Nginx Worker 
>> process.  The number of Nginx Workers  is generally the same with the 
>> number of CPU.
>>
>> If one Worker crashs the Nginx Master will create a new one so you don't 
>> worry about JVM crashs accidentally.
>>
>> Although there will be several JVM instances,  there 's only one main 
>> thread attached with the Nginx Woker process.
>>
>> So the JVM instance uses less memory and no thread context switch cost in 
>> every JVM instance.
>>
>> In some cases If you can  use only one JVM instance,  you can set the 
>> Nginx Worker number to be 1 and set jvm_workers > 1,  nginx-clojure will 
>> create 
>>
>> a thread pool with fixed number of thread.
>>
>> to handle requests for you.
>>
>>
>> On Tuesday, January 14, 2014 5:50:34 PM UTC+8, Feng Shen wrote:
>>>
>>> Hi, 
>>>
>>> Thanks for your work on nginx-clojure. It looks great!  
>>>
>>> As I know Nginx spawns many processes(correct me if I am wrong),  does 
>>> that mean, there will be many JVM process?
>>>
>>>
>>>
>>>
>>> On Tuesday, January 14, 2014 4:44:18 PM UTC+8, Xfeep Zhang wrote:


 I have done the first one. The result is 
 HERE( 
 https://github.com/ptaoussanis/clojure-web-server-benchmarks )
 Thanks Taoussanis for his invitation to the project 
 clojure-web-server-benchmarkshosted
  on Github.

 On Tuesday, January 14, 2014 10:31:03 AM UTC+8, Xfeep Zhang wrote:
>
> You're welcome.
>
> I think there are several difficult phases :
>
> (1)  update the test program in 
> clojure-web-server-benchmarks,
>  make the some packages to be the latest. (eg. http-kit from 1.3.0-alpha2 
> --> 2.1.16) and add nginx-php testing
> (2)  test about real world size contents by group eg. tiny, small, 
> medium, huge. 
> (3)  test about real world connection circumstances where a lot of 
> connection is inactive but keep open.
> (4)  try some real asynchronous test to fetch external resources (eg. 
> rest service , db) before response to the client. eg.  using 
> libdrizzle  a no-blocking mysql  
> client from  https://launchpad.net/drizzle
>
> On Tuesday, January 14, 2014 2:41:50 AM UTC+8, Sergey Didenko wrote:
>>
>> Looks very interesting, thank you for your work!
>>
>> I wonder how this is going to improve latency in comparison to nginx 
>> + http-kit for some real world test that is not using heavy DB 
>> operations.
>>
>>
>> On Mon, Jan 13, 2014 at 5:57 AM, Xfeep Zhang  wrote:
>>
>>>
>>> So far I have found why nginx-clojure is slower than http-kit when 
>>> 1 concurrents. (when < = 1000 concurrents nginx-clojure is faster 
>>> than 
>>> http-kit.)
>>> I have set too many connections per nginx worker (worker_connections 
>>> = 2) . This make nginx only use one worker to handle ab  requests 
>>> (every request is tiny).
>>> I plan to take note of 
>>> c-erlang-java-performanceand
>>>  fork 
>>> clojure-web-server-benchmarks

Re: Granularity in Leiningen profile loading

[Phil Hagelberg]

gvim writes:

> ... but after `lein deps :tree` the cljs profile still isn't loaded.

That's normal; you would need to run `lein with-profile cljs deps :tree`
to activate a profile. But if you have dependencies that are needed for
your project to compile, it's a very bad idea to omit them from
project.clj; they should be put in :dependencies.

-Phil


pgp0K5QH5EirU.pgp
Description: PGP signature

Re: Nginx-Clojure Let You Deploy Clojure Web App on Nginx Without Any Java Web Server

[Xfeep Zhang]

I have check the uwsgi document again and the JVM integration document is 
HERE 
http://uwsgi-docs.readthedocs.org/en/latest/JWSGI.html
 .

When using uwsgi to integrate JVM, the JVM process is not the same process 
of Nginx worker.

So it can not avoid IPC cost or socket cost ! So it will use more system 
handle (at least double ones) and more copy operataion between process 

and maybe more memory cost.

So I think using uwsgi to integrate JVM maybe will not be so fast!


On Wednesday, January 15, 2014 10:10:40 AM UTC+8, Xfeep Zhang wrote:
>
> Hi Mingli, 
>
> Thanks for  your suggestion.
>
> Nginx-Clojure is quite different from uwsgi when supports JVM.
>
> Nginx-Clojure make JVM embed into Nginx worker process. JVM and Nginx 
> worker have  the same memory process space.
>
>  Nginx-Clojure heavy uses pointer operation just like C to handle memory 
> with Nginx worker. 
>
>  If I'm not wrong,  uwsgi create every process for every request, or 
> shared JVM processes between request?
>
> When using Nginx-Clojure there's no IPC cost  even no thread switch cost 
> if jvm_workers = 0 which is default.
>
> So it's why Nginx-Clojure is so fast! 
>
>
> On Wednesday, January 15, 2014 3:07:13 AM UTC+8, Mingli Yuan wrote:
>>
>> Hi, Xfeep,
>>
>> Thanks for your contribution, and the project looks interesting.
>>
>> For me, the idea of driving ring webapp behind nginx is not new. 
>> We use uwsgi to drive our ring app behind nginx in our production.
>> uwsgi support JVM and ring for almost one year, and I think the code is 
>> relative stable right now.
>>
>> - it support a native protocol between nginx and uwsgi which is more 
>> efficient than http
>> - it support unix socket
>> - and a rich uwsgi api layer to provide some means to communicate between 
>> webapps
>> - and according to the performance tests by the author, it is a little 
>> bit faster than jetty.
>>
>> It is on our production for half a year, quite stable, and very harmonious 
>> with the python app.
>>
>> I am not want to sale the solution of uwsgi, but it worth taking a look 
>> and make some comparison.
>>
>> Regards,
>> Mingli
>>
>>
>> On Tue, Jan 14, 2014 at 9:12 PM, Xfeep Zhang  wrote:
>>
>>> You are welcome! 
>>>
>>> Yes, you are right.  One JVM instance is embed  per Nginx Worker 
>>> process.  The number of Nginx Workers  is generally the same with the 
>>> number of CPU.
>>>
>>> If one Worker crashs the Nginx Master will create a new one so you don't 
>>> worry about JVM crashs accidentally.
>>>
>>> Although there will be several JVM instances,  there 's only one main 
>>> thread attached with the Nginx Woker process.
>>>
>>> So the JVM instance uses less memory and no thread context switch cost 
>>> in every JVM instance.
>>>
>>> In some cases If you can  use only one JVM instance,  you can set the 
>>> Nginx Worker number to be 1 and set jvm_workers > 1,  nginx-clojure will 
>>> create 
>>>
>>> a thread pool with fixed number of thread.
>>>
>>> to handle requests for you.
>>>
>>>
>>> On Tuesday, January 14, 2014 5:50:34 PM UTC+8, Feng Shen wrote:

 Hi, 

 Thanks for your work on nginx-clojure. It looks great!  

 As I know Nginx spawns many processes(correct me if I am wrong),  does 
 that mean, there will be many JVM process?




 On Tuesday, January 14, 2014 4:44:18 PM UTC+8, Xfeep Zhang wrote:
>
>
> I have done the first one. The result is 
> HERE( 
> https://github.com/ptaoussanis/clojure-web-server-benchmarks )
> Thanks Taoussanis for his invitation to the project 
> clojure-web-server-benchmarkshosted
>  on Github.
>
> On Tuesday, January 14, 2014 10:31:03 AM UTC+8, Xfeep Zhang wrote:
>>
>> You're welcome.
>>
>> I think there are several difficult phases :
>>
>> (1)  update the test program in 
>> clojure-web-server-benchmarks,
>>  make the some packages to be the latest. (eg. http-kit from 
>> 1.3.0-alpha2 
>> --> 2.1.16) and add nginx-php testing
>> (2)  test about real world size contents by group eg. tiny, small, 
>> medium, huge. 
>> (3)  test about real world connection circumstances where a lot of 
>> connection is inactive but keep open.
>> (4)  try some real asynchronous test to fetch external resources (eg. 
>> rest service , db) before response to the client. eg.  using 
>> libdrizzle  a no-blocking mysql  
>> client from  https://launchpad.net/drizzle
>>
>> On Tuesday, January 14, 2014 2:41:50 AM UTC+8, Sergey Didenko wrote:
>>>
>>> Looks very interesting, thank you for your work!
>>>
>>> I wonder how this is going to improve latency in comparison to nginx 
>>> + http

Guide to the ClojureScript Analyzer & Compiler

[David Nolen]

I think Light Table, Clojure, and ClojureScript users will find this guide
informative:
http://swannodette.github.io/2014/01/14/clojurescript-analysis--compilation/

Cheers,
David

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Nginx-Clojure Let You Deploy Clojure Web App on Nginx Without Any Java Web Server

[Roberto De Ioris]

> Hi Mingli,
>
> Thanks for  your suggestion.
>
> Nginx-Clojure is quite different from uwsgi when supports JVM.
>
> Nginx-Clojure make JVM embed into Nginx worker process. JVM and Nginx
> worker have  the same memory process space.
>
>  Nginx-Clojure heavy uses pointer operation just like C to handle memory
> with Nginx worker.
>
>  If I'm not wrong,  uwsgi create every process for every request, or
> shared
> JVM processes between request?

uWSGI creates a pool of processes with a number of threads in each and
then they are used for the whole server life cycle. (a pretty standard
behaviour)


>
> When using Nginx-Clojure there's no IPC cost  even no thread switch cost
> if
> jvm_workers = 0 which is default.
>
> So it's why Nginx-Clojure is so fast!
>

i strongly suggest you to avoid the "performance" as a selling point, your
project is cool but not for performance (and you are using a pipe to
transfer requests data from nginx to the jvm so there ipc in place too,
even if you can improve things using OS-specific syscall like splice).

It is cool because it simplify deployments, but nginx is not an
application server, so things like multi-strategy gracefully reloads,
stuck-requests managers, offloading and so on are not available.

Regarding the "ipc problem", you generally put a load balancer on front of
your app, so there is always ipc

Do not get me wrong, as i have already said your project is cool, but you
should focus not on performance but on better integration with the nginx
api for writing non-blocking apps (if possible), something at uWSGI
unfortunately failed (the JVM has no support for switching stacks out of
the box, something that is required for async mode in uWSGI)


-- 
Roberto De Ioris
http://unbit.it

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

Re: Ragtime w/ Korma

[Sean Corfield]

How exactly are you running the code? The Gist really doesn't provide
enough information for anyone to be able to diagnose this...

On Tue, Jan 14, 2014 at 5:15 PM, Christopher Allen  wrote:
> Verify with clojure.java.jdbc would by my first approach, but it's not clear
> to me how you can know migratus and Korma aren't touching two different
> instantiations of the H2 in memory database using c.j.j.
>
> I don't know anything about H2. I'm a PostgreSQL user.
>
>
>
> On Tuesday, January 14, 2014 7:50:07 AM UTC-8, Arlandis Lawrence wrote:
>>
>> The errors I'm getting indicate that the tables don't exist.
>> "Table "itinerary" not found; SQL statement:
>>  DELETE FROM "itinerary" [42102-164]
>>  org.h2.jdbc.JdbcSQLException: Table "itinerary" not found; SQL
>> statement:
>>  DELETE FROM "itinerary" [42102-164]
>>   at
>> org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
>>   at org.h2.message.DbException.get(DbException.java:169)
>>   at org.h2.message.DbException.get(DbException.java:146)
>>   at org.h2.command.Parser.readTableOrView(Parser.java:4753)
>>   at org.h2.command.Parser.readTableOrView(Parser.java:4731)
>>   at org.h2.command.Parser.readSimpleTableFilter(Parser.java:709)
>>   at org.h2.command.Parser.parseDelete(Parser.java:731)
>>   at org.h2.command.Parser.parsePrepared(Parser.java:336)
>>   at org.h2.command.Parser.parse(Parser.java:279)
>>   at org.h2.command.Parser.parse(Parser.java:251)
>>   at org.h2.command.Parser.prepareCommand(Parser.java:217)
>>   at org.h2.engine.Session.prepareLocal(Session.java:415)
>>   at org.h2.engine.Session.prepareCommand(Session.java:364)
>>   at
>> org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1121)
>>   at
>> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:71)
>>   at
>> org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:267)
>>   at
>> com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:213)
>>   ... 4 stack levels elided ...
>>   at korma.db$exec_sql.invoke(db.clj:206)
>>   at korma.db$do_query$fn__2578.invoke(db.clj:227)
>>   ... 1 stack levels elided ...
>>   at korma.db$do_query.invoke(db.clj:226)
>>   at korma.core$exec.invoke(core.clj:474)"
>>
>> I've verified that using postgres instead of h2 works and that the
>> migrations actually occur in the h2 in-memory database, but for some reason
>> korma doesn't see the tables.
>> I suspect that korma is actually connecting to a different database, or is
>> connecting after the original in-memory database has closed (I used the
>> "DB_CLOSE_DELAY=-1" argument to try and mitigate this).
>> Do you have any tips for examining the in-memory database manually in h2
>> or verifying that the databases I'm connecting to are the same?
>>
>> On Monday, January 13, 2014 4:35:30 PM UTC-6, Christopher Allen wrote:
>>>
>>> Try it without H2 and check the contents of the database manually. "Korma
>>> cooperating" doesn't mean a lot if the tables don't actually exist.
>>>
>>> Error messages should be provided in future.
>>>
>>> On Monday, January 13, 2014 1:44:28 PM UTC-8, Arlandis Lawrence wrote:

 I'm trying to use H2's in-memory database feature for running specs, so
 I'm using Ragtime to run migrations before the test.
 Problem is, I can't get Korma to cooperate. Could someone take a look at
 this gist and see if it makes sense?

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