Re: ANN: ClojureScript 0.0-3308, fixes & enhancements

[Rangel Spasov]

Works for me, thanks! 

FYI for anyone using Transit - upgrade to the latest version to prevent 
warnings.

com.lucasbradstreet/cljs-uuid-utils lib also causes warnings, I switched to 
the cljs.core/random-uuid to avoid that.

Thanks,
@raspasov

On Monday, June 1, 2015 at 11:47:58 AM UTC-7, David Nolen wrote:
>
> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-3308"]
>
> This release bumps the Clojure dependecy to 1.7.0-RC1 and includes fixes 
> and minor
> enhancements.
>
> As always feedback welcome!
>
> ## 0.0-3308
>
> ## Changes
> * Clojure 1.7.0-RC1 dependency
> * CLJS-1292: Add IPrintWithWriter implementation for TaggedLiteral
> * add cljs.core/random-uuid
> * flush immediately when forwarding Node process out & err
> * CLJS-1256 cache UUID hash value
> * CLJS-1226: Added the :end-run-test event to cljs.test and a dummy event 
> handler for it
>
> ## Fixes
> * CLJS-1200: compare behaves differently from Clojure
> * CLJS-1293: Warning settings not conveyed via REPL
> * CLJS-1291: pprint whitespace/letter checks are incomplete
> * CLJS-1288: compiler doesn't emit "goog.require" for foreign library when 
> optimization level is not set
> * check that we actually read something in cjls.repl.server/read-request
> * clarify cljs.test/run-tests docstring
> * CLJS-1285: load-file regression
> * CLJS-1284: IndexedSeq -seq implementation incorrect for i >= alength of 
> internal array
> * finish CLJS-1176, remove stray .isAlive method call
> * add zero arity `newline` to match Clojure
> * CLJS-1206: Images in HTML don't show up when served from localhost:9000
> * CLJS-1272: :include-macros description inaccurate in require
> * CLJS-1275: Corrected :test-paths in project.clj
> * CLJS-1270: Docstring for delay not printed by cljs.repl/doc
> * CLJS-1268: cljc support for cljs.closure/compile-file
> * CLJS-1269: realized? docstring refers to promise and future
> * match Clojure behavior for get on string / array. Need to coerce key 
> into int.
> * CLJS-1263: :libs regression, can no longer specify specific files
> * CLJS-1209: Reduce produces additional final nil when used w/ eduction
> * CLJS-1261: source fn fails for fns with conditional code
>
>

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

Re: Advice when running java -jar rather than a managed server like tomcat?

[Mikhail Malchevskiy]

No, it's essentially Emacs + Evil mode + many, many more "layers" in a 
great package. Really worth trying, IMHO

понедельник, 1 июня 2015 г., 19:11:44 UTC+3 пользователь Colin Yates 
написал:
>
> I recall seeing that from a while ago - weren’t they planning on rewriting 
> emacs effectively?
>
> On 1 Jun 2015, at 15:55, Mikhail Malchevskiy  > wrote:
>
> https://github.com/syl20bnr/spacemacs =)
>
> понедельник, 1 июня 2015 г., 17:05:35 UTC+3 пользователь Colin Yates 
> написал:
>>
>> Hi Karsten, 
>>
>> Unfortunately our clients are primarily windows based and the software is 
>> commercial. tmux - that takes me back! I have never forgotten the joy, or 
>> found an equivalent on KDE, Gnome, Windows or OSX of a well configured 
>> xMonad, I remember reaching for tmux as a substitute when running over ssh 
>> … Sigh - those were the days.  (all we need now is someone to point out the 
>> obvious superiority of emacs over vim for this to ignite into a flame war… 
>> oh wait…) 
>>
>> > On 1 Jun 2015, at 15:00, Karsten Schmidt  wrote: 
>> > 
>> > For smaller deployments, so far I've always had a smooth ride using 
>> > nginx as reverse proxy and running the uberjar inside tmux. No other 
>> > special sauce needed, plus you get the benefit of using nginx to serve 
>> > your static assets (if there're not on a CDN already)... 
>> > 
>> > On 1 June 2015 at 14:40, Colin Yates  wrote: 
>> >> Thanks Daniel, I am trying to reduce the required installed software 
>> on the 
>> >> client and they can’t access a maven repo from which to download 
>> >> unfortunately. Hence I am looking for a ‘self contained executable’ 
>> >> solution. 
>> >> 
>> >> You are yet-another-exclaimer of Boot; enough people have sung its 
>> praises 
>> >> to make it one of the next things I will need to investigate ;). 
>> >> 
>> >> 
>> >> On 1 Jun 2015, at 14:30, Daniel Szmulewicz  
>> >> wrote: 
>> >> 
>> >> Great conversation starter. 
>> >> 
>> >> Many of us had to take down that route. Eventually, we settle on a 
>> >> deployment solution that works for us, and we can move on with 
>> dev'ing. I'm 
>> >> sure all the answers are worthy. Please allow me to share my solution 
>> to 
>> >> this problem. It may not work for everyone, but it works for me. 
>> >> 
>> >> It can be summarized as follow: Runit supervisor + Boot. 
>> >> 
>> >> More information here: 
>> >> 
>> >> https://github.com/danielsz/boot-runit 
>> >> 
>> >> Note: this is the solution I came up with after experimenting with the 
>> >> strategies outlined in Ryan's blog post. 
>> >> http://www.rkn.io/2014/02/06/clojure-cookbook-daemons/ 
>> >> 
>> >> Now I do 'boot dev' locally and 'boot prod' on the server (with 
>> auxiliary 
>> >> 'boot dev-run' and 'boot prod-run'). 
>> >> 
>> >> Runit is a Unix classic (as in "an outstanding example of a particular 
>> >> style"), and Boot is quickly becoming a Clojure classic. 
>> >> 
>> >> More examples here: 
>> >> 
>> https://github.com/danielsz/system/blob/master/examples/boot/build.boot 
>> >> 
>> >> 
>> >> On Tuesday, May 26, 2015 at 2:38:30 PM UTC+3, Colin Yates wrote: 
>> >>> 
>> >>> Hi, 
>> >>> 
>> >>> I am venturing into new territory using http-kit, as I usually use a 
>> >>> 'managed' web server container like tomcat and have a few questions 
>> about 
>> >>> packing and running a JAR file: 
>> >>> 
>> >>> - are there are convenient service wrappers for windows and/or Linux 
>> >>> - any best practice around managing class path for things like 
>> >>> logback.xml 
>> >>> 
>> >>> I have a jar created from lein uberjar and java -jar the.jar works, 
>> but 
>> >>> this seems a long way away from automated deployment :). 
>> >>> 
>> >>> Any advice welcome - thanks! 
>> >> 
>> >> 
>> >> -- 
>> >> You received this message because you are subscribed to the Google 
>> >> Groups "Clojure" group. 
>> >> To post to this group, send email to clo...@googlegroups.com 
>> >> Note that posts from new members are moderated - please be patient 
>> with your 
>> >> first post. 
>> >> To unsubscribe from this group, send email to 
>> >> clojure+u...@googlegroups.com 
>> >> For more options, visit this group at 
>> >> http://groups.google.com/group/clojure?hl=en 
>> >> --- 
>> >> You received this message because you are subscribed to the Google 
>> Groups 
>> >> "Clojure" group. 
>> >> To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> >> email to clojure+u...@googlegroups.com. 
>> >> For more options, visit https://groups.google.com/d/optout. 
>> >> 
>> >> 
>> >> -- 
>> >> You received this message because you are subscribed to the Google 
>> >> Groups "Clojure" group. 
>> >> To post to this group, send email to clo...@googlegroups.com 
>> >> Note that posts from new members are moderated - please be patient 
>> with your 
>> >> first post. 
>> >> To unsubscribe from this group, send email to 
>> >> clojure+u...@googlegroups.com 
>> >> For more options, visit this group at 
>> >> http://groups.google.com/group/c

Re: Education on Dynamic Binding

[andy . chambers]

There's this one from 
uswitch http://oobaloo.co.uk/dynamic-error-capture-with-clojure but it 
doesn't really have a motivating example to highlight why that particular 
approach is better.

Or this one which hints at 
monads: http://adambard.com/blog/acceptable-error-handling-in-clojure/

I also found this one: https://github.com/MichaelDrogalis/dire which was 
cool because it referenced 
http://www.erlang.org/download/armstrong_thesis_2003.pdf which made for an 
interesting read.

Looks like slingshot is fairly popular so I should probably go and 
investigate that.

On Thursday, 28 May 2015 23:57:21 UTC-7, piast...@gmail.com wrote:
>
> What blog posts did you find useful?
>
>
> On Tuesday, May 26, 2015 at 10:01:29 PM UTC-4, andy.c...@fundingcircle.com 
> wrote:
>>
>> This page on Jira says that dynamic binding should be documented as "The 
>> Clojure Way" to do error handling. Was this ever done? I managed to find a 
>> few blog posts discussing approach but nothing official.
>>
>> http://dev.clojure.org/display/design/Error+Handling
>>
>> Cheers,
>> Andy
>>
>

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Leonardo Borges]

For people interested in using the 'futures' approach, this might be of
interest: https://github.com/leonardoborges/imminent


It's a library that implements composable futures for Clojure on top of
JVM's ForkJoin framework. It allows you to attach callbacks as well as
apply combinators such as map etc...


On 2 Jun 2015 3:04 pm, "Timothy Baldridge"  wrote:

> The problem with futures is that you can't attach callbacks to them, you
> can only block a thread waiting on them. So futures interface quite poorly
> with async libraries, hence the reason core.async was created in the first
> place.
>
> Core.async is a dependency, but it's hardly one that changes fast. The
> last breaking change was about a year and a half ago (Jan 2014). Besides
> that, all changes are additional "opt-in" features. That's a lot less
> change than most libraries in the Clojure ecosystem.
>
> Timothy
>
> On Mon, Jun 1, 2015 at 10:42 PM, Stanislav Yurin 
> wrote:
>
>> As for the core.async, I think it is too personal and has too much raw
>> power, to be all that restricted in some logical bottleneck upon results
>> return from the third-party lib.
>> Not counting the fact it is a (a) dependency that (b) changes fast.
>>
>> On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote:
>>
>>> Greetings
>>>
>>> I imagine most of us here would rather use core.async channels over
>>> callbacks in their application code, particularly with more complicated
>>> applications. But is it okay/preferable for Clojure libraries to force
>>> their users to use core.async channels as part of an API (an event channel,
>>> for example)?
>>>
>>> As much as I love core.async, I can't help but wonder whether sticking
>>> with callbacks for an API isn't a simpler/better design strategy. It's easy
>>> enough to drop messages on a channel in a callback, and this let's users
>>> opt-in. But if one expects core.async channels are what most would prefer
>>> anyway, is it okay to foist them upon everyone?
>>>
>>> As a follow up, does your opinion on the matter change if
>>> implementations of an API become simpler using core.async channels?
>>>
>>>
>>> Looking forward to your thoughts :-)
>>>
>>> Chris Small
>>>
>>>
>>>
>>> PS I'm asking because I'm working on a physical computing API (
>>> https://github.com/clj-bots/pin-ctrl) and debating between using
>>> channels vs callbacks for the edge detection functionality (if you're not
>>> familiar, edge detection let's you asynchronously handle changes in pin
>>> state, such as button pushes). If you're interested in this question as it
>>> applies specifically to this application, feel free to join the discussion
>>> on our gitter channel: https://gitter.im/clj-bots/chat
>>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Stanislav Yurin]

Why so? With a callback, someone should be waiting somewhere too, until 
callback is fired. 
Why not expose this choice to user. E.g. I am often waiting for the future 
in the (thread ..) and returning the result to the channel,
but again, I like this to be my choice, because there are so much ways of 
doing this.

On Tuesday, June 2, 2015 at 8:04:38 AM UTC+3, tbc++ wrote:
>
> The problem with futures is that you can't attach callbacks to them, you 
> can only block a thread waiting on them. So futures interface quite poorly 
> with async libraries, hence the reason core.async was created in the first 
> place. 
>
> Core.async is a dependency, but it's hardly one that changes fast. The 
> last breaking change was about a year and a half ago (Jan 2014). Besides 
> that, all changes are additional "opt-in" features. That's a lot less 
> change than most libraries in the Clojure ecosystem.  
>
> Timothy
>
> On Mon, Jun 1, 2015 at 10:42 PM, Stanislav Yurin  > wrote:
>
>> As for the core.async, I think it is too personal and has too much raw 
>> power, to be all that restricted in some logical bottleneck upon results 
>> return from the third-party lib. 
>> Not counting the fact it is a (a) dependency that (b) changes fast.
>>
>> On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote:
>>
>>> Greetings
>>>
>>> I imagine most of us here would rather use core.async channels over 
>>> callbacks in their application code, particularly with more complicated 
>>> applications. But is it okay/preferable for Clojure libraries to force 
>>> their users to use core.async channels as part of an API (an event channel, 
>>> for example)? 
>>>
>>> As much as I love core.async, I can't help but wonder whether sticking 
>>> with callbacks for an API isn't a simpler/better design strategy. It's easy 
>>> enough to drop messages on a channel in a callback, and this let's users 
>>> opt-in. But if one expects core.async channels are what most would prefer 
>>> anyway, is it okay to foist them upon everyone?
>>>
>>> As a follow up, does your opinion on the matter change if 
>>> implementations of an API become simpler using core.async channels?
>>>
>>>
>>> Looking forward to your thoughts :-)
>>>
>>> Chris Small
>>>
>>>
>>>
>>> PS I'm asking because I'm working on a physical computing API (
>>> https://github.com/clj-bots/pin-ctrl) and debating between using 
>>> channels vs callbacks for the edge detection functionality (if you're not 
>>> familiar, edge detection let's you asynchronously handle changes in pin 
>>> state, such as button pushes). If you're interested in this question as it 
>>> applies specifically to this application, feel free to join the discussion 
>>> on our gitter channel: https://gitter.im/clj-bots/chat
>>>
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>  

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Timothy Baldridge]

The problem with futures is that you can't attach callbacks to them, you
can only block a thread waiting on them. So futures interface quite poorly
with async libraries, hence the reason core.async was created in the first
place.

Core.async is a dependency, but it's hardly one that changes fast. The last
breaking change was about a year and a half ago (Jan 2014). Besides that,
all changes are additional "opt-in" features. That's a lot less change than
most libraries in the Clojure ecosystem.

Timothy

On Mon, Jun 1, 2015 at 10:42 PM, Stanislav Yurin  wrote:

> As for the core.async, I think it is too personal and has too much raw
> power, to be all that restricted in some logical bottleneck upon results
> return from the third-party lib.
> Not counting the fact it is a (a) dependency that (b) changes fast.
>
> On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote:
>
>> Greetings
>>
>> I imagine most of us here would rather use core.async channels over
>> callbacks in their application code, particularly with more complicated
>> applications. But is it okay/preferable for Clojure libraries to force
>> their users to use core.async channels as part of an API (an event channel,
>> for example)?
>>
>> As much as I love core.async, I can't help but wonder whether sticking
>> with callbacks for an API isn't a simpler/better design strategy. It's easy
>> enough to drop messages on a channel in a callback, and this let's users
>> opt-in. But if one expects core.async channels are what most would prefer
>> anyway, is it okay to foist them upon everyone?
>>
>> As a follow up, does your opinion on the matter change if implementations
>> of an API become simpler using core.async channels?
>>
>>
>> Looking forward to your thoughts :-)
>>
>> Chris Small
>>
>>
>>
>> PS I'm asking because I'm working on a physical computing API (
>> https://github.com/clj-bots/pin-ctrl) and debating between using
>> channels vs callbacks for the edge detection functionality (if you're not
>> familiar, edge detection let's you asynchronously handle changes in pin
>> state, such as button pushes). If you're interested in this question as it
>> applies specifically to this application, feel free to join the discussion
>> on our gitter channel: https://gitter.im/clj-bots/chat
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Stanislav Yurin]

As for the core.async, I think it is too personal and has too much raw 
power, to be all that restricted in some logical bottleneck upon results 
return from the third-party lib. 
Not counting the fact it is a (a) dependency that (b) changes fast.

On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote:
>
> Greetings
>
> I imagine most of us here would rather use core.async channels over 
> callbacks in their application code, particularly with more complicated 
> applications. But is it okay/preferable for Clojure libraries to force 
> their users to use core.async channels as part of an API (an event channel, 
> for example)? 
>
> As much as I love core.async, I can't help but wonder whether sticking 
> with callbacks for an API isn't a simpler/better design strategy. It's easy 
> enough to drop messages on a channel in a callback, and this let's users 
> opt-in. But if one expects core.async channels are what most would prefer 
> anyway, is it okay to foist them upon everyone?
>
> As a follow up, does your opinion on the matter change if implementations 
> of an API become simpler using core.async channels?
>
>
> Looking forward to your thoughts :-)
>
> Chris Small
>
>
>
> PS I'm asking because I'm working on a physical computing API (
> https://github.com/clj-bots/pin-ctrl) and debating between using channels 
> vs callbacks for the edge detection functionality (if you're not familiar, 
> edge detection let's you asynchronously handle changes in pin state, such 
> as button pushes). If you're interested in this question as it applies 
> specifically to this application, feel free to join the discussion on our 
> gitter channel: https://gitter.im/clj-bots/chat
>

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Stanislav Yurin]

I think returning futures for asynchronous calls is a good tradition in 
Clojure world.
Better than callbacks because you are leaving the threading model choice in 
the hands of the caller, which is a good thing.

On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote:
>
> Greetings
>
> I imagine most of us here would rather use core.async channels over 
> callbacks in their application code, particularly with more complicated 
> applications. But is it okay/preferable for Clojure libraries to force 
> their users to use core.async channels as part of an API (an event channel, 
> for example)? 
>
> As much as I love core.async, I can't help but wonder whether sticking 
> with callbacks for an API isn't a simpler/better design strategy. It's easy 
> enough to drop messages on a channel in a callback, and this let's users 
> opt-in. But if one expects core.async channels are what most would prefer 
> anyway, is it okay to foist them upon everyone?
>
> As a follow up, does your opinion on the matter change if implementations 
> of an API become simpler using core.async channels?
>
>
> Looking forward to your thoughts :-)
>
> Chris Small
>
>
>
> PS I'm asking because I'm working on a physical computing API (
> https://github.com/clj-bots/pin-ctrl) and debating between using channels 
> vs callbacks for the edge detection functionality (if you're not familiar, 
> edge detection let's you asynchronously handle changes in pin state, such 
> as button pushes). If you're interested in this question as it applies 
> specifically to this application, feel free to join the discussion on our 
> gitter channel: https://gitter.im/clj-bots/chat
>

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

Re: non-incanter statistical tests?

[Lee Spector]

Thanks so much Marshall.

Adding "-Djava.awt.headless=true" to my :jvm-opts does indeed fix the 
"additional java process" problem, so that's helpful if I don't find an 
alternative to incanter.

The R options are interesting but probably not a good solution in my case; I'll 
be calling these tests millions of times and I'm guessing that the overhead 
would be a problem.

FWIW another issue I've had with incanter is confusion figuring out what 
dependency to use. This wasn't clear to me from the main incanter 
documentation, searching clojars for incanter returned a lot of things that I 
didn't know what to do with, and then I eventually found the github page (which 
you also suggest) which shows [incanter "1.5.6"] under "Include in Clojure 
project", which worked... But then, looking more carefully at the clojars 
result I see that there's also 1.9.0 and now I've switched to that, and it also 
works... But this all seems very weird because the project.clj in the github 
repository lists ""1.5.7-SNAPSHOT", making me think that maybe 1.5.6 is the 
current stable version. To make matters worse I thought it might be better to 
use only the stats module and tried things like [incanter-stats "1.5.6"] and 
[incanter/incanter-stats "1.5.6"], but none of that worked and I guess now that 
maybe stats isn't a separate module? In namespaces I require only 
[incanter.stats :as stats] and that works, although it did trigger the swing 
stuff untill i added -Djava.awt.headless=true.

Anyway, I'm in somewhat better shape now but still confused about some things, 
uneasy about the comment in the source code indicating the wrongness of the 
t-test code, and hoping for something that will be easier to understand and 
work with... if there's any simpler option out there.

Thanks,

 -Lee


> On Jun 1, 2015, at 10:40 PM, Mars0i  wrote:
> 
> One option would be to call R from Clojure.   I haven't tried this, and I 
> don't know how well it would fit your needs.
> 
> Rincanter 
>  is 
> supposed to allow this.  Presumably it would bypass the Incanter functions 
> that you don't want to use.
> 
> Rincanter is apparently a wrapper around JRI , 
> a Java library for calling R.  You could probably use that directly, without 
> using Rincanter.
> 
> I can't figure out whether R-nREPL  is 
> also a possible solution, but maybe it is.
> 
> 
> About this:
> "Requiring incanter seems to be making my program launch an additional java 
> process, which is mysterious and unwelcout ome":
> 
> I think you're probably referring to the fact that some Incanter components 
> load Java's Swing library, which causes a little Java icon to appear (on my 
> Mac, at least).  Yeah, that is annoying, if you don't need graphical output.  
> But you can avoid it.
> 
> First, I'd make sure that you are using the latest Incanter library, e.g. by 
> pasting the appropriate lines (see Incanter's github repo) into a Leiningen 
> project.clj file.  If you're using the standalone Incanter 
> application--sometimes that's older, and you will have less control over 
> what's loaded.  Second, only use or require the components you need--but you 
> probably need one of the ones that loads Swing by default.  Third (this is 
> the key):  Add 
> :jvm-opts ["-Djava.awt.headless=true"]
> to your Leiningen project.clj.  That will prevent the Swing icon from popping 
> up.  
> 
> You might also want to ask for help on the numeric-clojure Google group or 
> the Incanter group, or filing issues on the Incanter github repo.  The latter 
> might not be your cup of tea, of course.
> 
> (There's an open issue about the Swing popup that I filed (#255).  Incanter 
> is a huge project, and there are understandably lots of issues that the folks 
> working on it are trying to address, presumably as quickly as they can.)
> There 
> 

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Timothy Baldridge]

I'd say stick with callbacks simply because they're harder to mess up.
There's many different ways to interface with core.async. You can return a
channel, you can require a channel as an argument. You can spin up go
blocks that park, you can have pipelines, you can create a go block per
call to an api, or one that lives for the lifetime of the app. Some APIs
can have cancelable operations, some don't. Knowing how to build an API
that fits everyones needs is really hard.

Sadly, I don't trust many people (including myself) to implement a
core.async API correctly for the needs of every application. But callbacks
are pretty hard to mess up. Just document where the callbacks are run (on a
single thread, in a thread pool, etc.) and I can easily adapt your library
to fit my application.

Timothy

On Mon, Jun 1, 2015 at 7:05 PM, Alejandro Ciniglio 
wrote:

> That’s a fair point. Although, I think manifold does have going for it
> that it’s designed to interoperate with the other abstractions we’re
> discussing, so it shouldn’t be as binding as building your API around
> core.async would be.
>
> On June 1, 2015 at 8:20:18 PM, Andrey Antukh (n...@niwi.nz) wrote:
>
>  Hi!
>
> Personally I think that manifold has the same problem that core.async. So
> if you are exposing your api using manifold you are forcing to someone to
> use manifold. It is not bad, but is the same problem as with core.async.
>
> And the same problem with callbacks. If you are using callbacks you are
> force to people to use callbacks or adapt it to whatever other abstraction.
>
> So, independently of the chosen abstraction, you are always forcing the
> user to use the chosen abstraction or adapt their code to another
> abstraction.
>
> About the original question, I think it depends that you really wants. In
> some projects I expose api using inter operable with jvm abstractions like
> (reactive-streams) or promises (completable future in jdk8), in other I
> just use core.async.
>
> There is no single solution I think!
>
> My two cents!
>
> Andrey
>
> On Mon, Jun 1, 2015 at 9:57 PM, Alejandro Ciniglio 
> wrote:
>
>> Zach Tellman talks about exactly this in his conj talk from last year
>> https://www.youtube.com/watch?v=3oQTSP4FngY
>>
>> He built a library around this that essentially gives the library user a
>> choice of either option: https://github.com/ztellman/manifold
>>
>>
>> On Monday, June 1, 2015 at 3:18:19 PM UTC-4, Christopher Small wrote:
>>>
>>>  Greetings
>>>
>>> I imagine most of us here would rather use core.async channels over
>>> callbacks in their application code, particularly with more complicated
>>> applications. But is it okay/preferable for Clojure libraries to force
>>> their users to use core.async channels as part of an API (an event channel,
>>> for example)?
>>>
>>> As much as I love core.async, I can't help but wonder whether sticking
>>> with callbacks for an API isn't a simpler/better design strategy. It's easy
>>> enough to drop messages on a channel in a callback, and this let's users
>>> opt-in. But if one expects core.async channels are what most would prefer
>>> anyway, is it okay to foist them upon everyone?
>>>
>>> As a follow up, does your opinion on the matter change if
>>> implementations of an API become simpler using core.async channels?
>>>
>>>
>>> Looking forward to your thoughts :-)
>>>
>>> Chris Small
>>>
>>>
>>>
>>> PS I'm asking because I'm working on a physical computing API (
>>> https://github.com/clj-bots/pin-ctrl) and debating between using
>>> channels vs callbacks for the edge detection functionality (if you're not
>>> familiar, edge detection let's you asynchronously handle changes in pin
>>> state, such as button pushes). If you're interested in this question as it
>>> applies specifically to this application, feel free to join the discussion
>>> on our gitter channel: https://gitter.im/clj-bots/chat
>>>
>>--
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>Andrey Antukh - Андрей Антух - 
>  http://www.niwi.nz
>  https://github.com/niwinz
>--
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> T

Re: non-incanter statistical tests?

[Mars0i]

One option would be to call R from Clojure.   I haven't tried this, and I 
don't know how well it would fit your needs.

Rincanter 
 is 
supposed to allow this.  Presumably it would bypass the Incanter functions 
that you don't want to use.

Rincanter is apparently a wrapper around JRI , 
a Java library for calling R.  You could probably use that directly, 
without using Rincanter.

I can't figure out whether R-nREPL  is 
also a possible solution, but maybe it is.


About this:
"Requiring incanter seems to be making my program launch an additional java 
process, which is mysterious and unwelcout ome":

I think you're probably referring to the fact that some Incanter components 
load Java's Swing library, which causes a little Java icon to appear (on my 
Mac, at least).  Yeah, that is annoying, if you don't need graphical 
output.  But you can avoid it.

First, I'd make sure that you are using the latest Incanter library, e.g. 
by pasting the appropriate lines (see Incanter's github repo) into a 
Leiningen project.clj file.  If you're using the standalone Incanter 
application--sometimes that's older, and you will have less control over 
what's loaded.  Second, only *use* or *require* the components you 
need--but you probably need one of the ones that loads Swing by default.  
Third (this is the key):  Add 
*:jvm-opts ["-Djava.awt.headless=true"]*
to your Leiningen project.clj.  That will prevent the Swing icon from 
popping up.  

You might also want to ask for help on the numeric-clojure Google group or 
the Incanter group, or filing issues on the Incanter github repo.  The 
latter might not be your cup of tea, of course.

(There's an open issue about the Swing popup that I filed (#255).  Incanter 
is a huge project, and there are understandably lots of issues that the 
folks working on it are trying to address, presumably as quickly as they 
can.)
There 

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Alejandro Ciniglio]

That’s a fair point. Although, I think manifold does have going for it that 
it’s designed to interoperate with the other abstractions we’re discussing, so 
it shouldn’t be as binding as building your API around core.async would be.

On June 1, 2015 at 8:20:18 PM, Andrey Antukh (n...@niwi.nz) wrote:

Hi!

Personally I think that manifold has the same problem that core.async. So if 
you are exposing your api using manifold you are forcing to someone to use 
manifold. It is not bad, but is the same problem as with core.async. 

And the same problem with callbacks. If you are using callbacks you are force 
to people to use callbacks or adapt it to whatever other abstraction.

So, independently of the chosen abstraction, you are always forcing the user to 
use the chosen abstraction or adapt their code to another abstraction.

About the original question, I think it depends that you really wants. In some 
projects I expose api using inter operable with jvm abstractions like 
(reactive-streams) or promises (completable future in jdk8), in other I just 
use core.async. 

There is no single solution I think!

My two cents!

Andrey

On Mon, Jun 1, 2015 at 9:57 PM, Alejandro Ciniglio  wrote:
Zach Tellman talks about exactly this in his conj talk from last year 
https://www.youtube.com/watch?v=3oQTSP4FngY

He built a library around this that essentially gives the library user a choice 
of either option: https://github.com/ztellman/manifold


On Monday, June 1, 2015 at 3:18:19 PM UTC-4, Christopher Small wrote:
Greetings

I imagine most of us here would rather use core.async channels over callbacks 
in their application code, particularly with more complicated applications. But 
is it okay/preferable for Clojure libraries to force their users to use 
core.async channels as part of an API (an event channel, for example)?

As much as I love core.async, I can't help but wonder whether sticking with 
callbacks for an API isn't a simpler/better design strategy. It's easy enough 
to drop messages on a channel in a callback, and this let's users opt-in. But 
if one expects core.async channels are what most would prefer anyway, is it 
okay to foist them upon everyone?

As a follow up, does your opinion on the matter change if implementations of an 
API become simpler using core.async channels?


Looking forward to your thoughts :-)

Chris Small



PS I'm asking because I'm working on a physical computing API 
(https://github.com/clj-bots/pin-ctrl) and debating between using channels vs 
callbacks for the edge detection functionality (if you're not familiar, edge 
detection let's you asynchronously handle changes in pin state, such as button 
pushes). If you're interested in this question as it applies specifically to 
this application, feel free to join the discussion on our gitter channel: 
https://gitter.im/clj-bots/chat
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Andrey Antukh - Андрей Антух - 
http://www.niwi.nz
https://github.com/niwinz
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
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/nuy2CAA89sI/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/d/optout.

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

ANN: Hildebrand 0.2.2

[Moe Aboulkheir]

First time caller.

Hildebrand is an asynchronous pure-Clojure (i.e. no Java AWS dependencies, 
etc.) DynamoDB client written on top of httpkit.  I've been developing it 
for a while now, and have used it in production, but hadn't gotten around 
to telling anyone about it. 

http://github.com/nervous-systems/hildebrand

I wrote a circuitous blog post about 
it: https://nervous.io/clojure/aws/dynamo/hildebrand/2015/06/08/hildebrand/ 
(apparently in the future), which is more informative.

 As this is the first public release, I'll just rattle off some high points:

 - Intuitive, consistent and total data representation of Dynamo schemas, 
items, filters, update specifications, etc.
 - Support for arbitrarily nested lists and maps in Dynamo items, has 
support for set types
 - Paginated/stepped query & scan with core.async channels
 - It could possibly perform decently

Take care,
Moe

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Andrey Antukh]

Hi!

Personally I think that manifold has the same problem that core.async. So
if you are exposing your api using manifold you are forcing to someone to
use manifold. It is not bad, but is the same problem as with core.async.

And the same problem with callbacks. If you are using callbacks you are
force to people to use callbacks or adapt it to whatever other abstraction.

So, independently of the chosen abstraction, you are always forcing the
user to use the chosen abstraction or adapt their code to another
abstraction.

About the original question, I think it depends that you really wants. In
some projects I expose api using inter operable with jvm abstractions like
(reactive-streams) or promises (completable future in jdk8), in other I
just use core.async.

There is no single solution I think!

My two cents!

Andrey

On Mon, Jun 1, 2015 at 9:57 PM, Alejandro Ciniglio 
wrote:

> Zach Tellman talks about exactly this in his conj talk from last year
> https://www.youtube.com/watch?v=3oQTSP4FngY
>
> He built a library around this that essentially gives the library user a
> choice of either option: https://github.com/ztellman/manifold
>
>
> On Monday, June 1, 2015 at 3:18:19 PM UTC-4, Christopher Small wrote:
>>
>> Greetings
>>
>> I imagine most of us here would rather use core.async channels over
>> callbacks in their application code, particularly with more complicated
>> applications. But is it okay/preferable for Clojure libraries to force
>> their users to use core.async channels as part of an API (an event channel,
>> for example)?
>>
>> As much as I love core.async, I can't help but wonder whether sticking
>> with callbacks for an API isn't a simpler/better design strategy. It's easy
>> enough to drop messages on a channel in a callback, and this let's users
>> opt-in. But if one expects core.async channels are what most would prefer
>> anyway, is it okay to foist them upon everyone?
>>
>> As a follow up, does your opinion on the matter change if implementations
>> of an API become simpler using core.async channels?
>>
>>
>> Looking forward to your thoughts :-)
>>
>> Chris Small
>>
>>
>>
>> PS I'm asking because I'm working on a physical computing API (
>> https://github.com/clj-bots/pin-ctrl) and debating between using
>> channels vs callbacks for the edge detection functionality (if you're not
>> familiar, edge detection let's you asynchronously handle changes in pin
>> state, such as button pushes). If you're interested in this question as it
>> applies specifically to this application, feel free to join the discussion
>> on our gitter channel: https://gitter.im/clj-bots/chat
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrey Antukh - Андрей Антух - 
http://www.niwi.nz
https://github.com/niwinz

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

Re: Clojure.data.xml fails when element size reached 33 symbols.

[nikolay . kudryavtsev]

Thanks. 

Clojure.data.xml is supposed to be lazy but there's an example in the 
documentation  that uses with-open:

(with-open [input (java.io.FileInputStream. "/tmp/foo.xml")]
(parse input))

And I think I even remember that this used to work before.

Also, a more generic question while were at it - what is the idiomatic way of 
implementing closeable sequences? 

I've found this old discussion 
 and it's still on 
the todo. Were there any changes since 2009?

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Gary Trakhman]

I think this is one of those cases where the rules are different for
libraries than applications.

Does your lib need to pull in core.async, and does it need to be coupled to
a specific version?  If it's a building block sort of lib that clojure and
the community prefers, I think the answer is no.  Is this more of an
opinionated 'framework' or set of batteries (luminus might fall in this
category)?  In that case, yes.

As an application-writer having to write some glue code feels less frustrating
than when libs make assumptions that I don't like.

On Mon, Jun 1, 2015 at 5:05 PM Eldar Gabdullin  wrote:

> I would implement everything sticking to just callbacks, then create
> separately requirable core.async version of API if that matters.
> Ideally this should be a separate lib, but practically, it seems better to
> just have a separate file.
>
> понедельник, 1 июня 2015 г., 22:18:19 UTC+3 пользователь Christopher Small
> написал:
>
>> Greetings
>>
>> I imagine most of us here would rather use core.async channels over
>> callbacks in their application code, particularly with more complicated
>> applications. But is it okay/preferable for Clojure libraries to force
>> their users to use core.async channels as part of an API (an event channel,
>> for example)?
>>
>> As much as I love core.async, I can't help but wonder whether sticking
>> with callbacks for an API isn't a simpler/better design strategy. It's easy
>> enough to drop messages on a channel in a callback, and this let's users
>> opt-in. But if one expects core.async channels are what most would prefer
>> anyway, is it okay to foist them upon everyone?
>>
>> As a follow up, does your opinion on the matter change if implementations
>> of an API become simpler using core.async channels?
>>
>>
>> Looking forward to your thoughts :-)
>>
>> Chris Small
>>
>>
>>
>> PS I'm asking because I'm working on a physical computing API (
>> https://github.com/clj-bots/pin-ctrl) and debating between using
>> channels vs callbacks for the edge detection functionality (if you're not
>> familiar, edge detection let's you asynchronously handle changes in pin
>> state, such as button pushes). If you're interested in this question as it
>> applies specifically to this application, feel free to join the discussion
>> on our gitter channel: https://gitter.im/clj-bots/chat
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Eldar Gabdullin]

I'd like to add that core.async is quite a big thing, it has lots of parts 
that could be implemented differently.

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Eldar Gabdullin]

I would implement everything sticking to just callbacks, then create 
separately requirable core.async version of API if that matters.
Ideally this should be a separate lib, but practically, it seems better to 
just have a separate file. 

понедельник, 1 июня 2015 г., 22:18:19 UTC+3 пользователь Christopher Small 
написал:
>
> Greetings
>
> I imagine most of us here would rather use core.async channels over 
> callbacks in their application code, particularly with more complicated 
> applications. But is it okay/preferable for Clojure libraries to force 
> their users to use core.async channels as part of an API (an event channel, 
> for example)? 
>
> As much as I love core.async, I can't help but wonder whether sticking 
> with callbacks for an API isn't a simpler/better design strategy. It's easy 
> enough to drop messages on a channel in a callback, and this let's users 
> opt-in. But if one expects core.async channels are what most would prefer 
> anyway, is it okay to foist them upon everyone?
>
> As a follow up, does your opinion on the matter change if implementations 
> of an API become simpler using core.async channels?
>
>
> Looking forward to your thoughts :-)
>
> Chris Small
>
>
>
> PS I'm asking because I'm working on a physical computing API (
> https://github.com/clj-bots/pin-ctrl) and debating between using channels 
> vs callbacks for the edge detection functionality (if you're not familiar, 
> edge detection let's you asynchronously handle changes in pin state, such 
> as button pushes). If you're interested in this question as it applies 
> specifically to this application, feel free to join the discussion on our 
> gitter channel: https://gitter.im/clj-bots/chat
>

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

non-incanter statistical tests?

[Lee Spector]

Does anyone know of a simple/minimal Clojure library, or just a chunk of 
Clojure source code that I could cut/paste, that implements basic statistical 
tests like t-tests and chi-squared tests? I don't want to use incanter but I'd 
also rather not write this stuff from scratch.

Thanks,

 -Lee

PS I'm not really looking to engage in debate about the pros/cons of incanter, 
but FWIW a couple of my reasons for not wanting to use it are: 1) Requiring 
incanter seems to be making my program launch an additional java process, which 
is mysterious and unwelcome, 2) I ran into division by zero errors which might 
be completely reasonable -- I haven't yet tracked down the arguments that 
produced the errors or figured out what should be done about them -- and when I 
tried to look into the code I found a lot more complexity than I was hoping to 
have to deal with, along with the comment ";;FIXME: This should never be *2!  
This is wrong...", which does not inspire confidence. I see that incanter does 
lots of cool things, and I don't want to put it down in any way, but for now I 
just want some statistical test code and I'd like to deal with as little else 
as possible.

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

Re: Opinion on core.async vs callbacks in abstract APIs?

[Alejandro Ciniglio]

Zach Tellman talks about exactly this in his conj talk from last 
year https://www.youtube.com/watch?v=3oQTSP4FngY

He built a library around this that essentially gives the library user a 
choice of either option: https://github.com/ztellman/manifold

On Monday, June 1, 2015 at 3:18:19 PM UTC-4, Christopher Small wrote:
>
> Greetings
>
> I imagine most of us here would rather use core.async channels over 
> callbacks in their application code, particularly with more complicated 
> applications. But is it okay/preferable for Clojure libraries to force 
> their users to use core.async channels as part of an API (an event channel, 
> for example)? 
>
> As much as I love core.async, I can't help but wonder whether sticking 
> with callbacks for an API isn't a simpler/better design strategy. It's easy 
> enough to drop messages on a channel in a callback, and this let's users 
> opt-in. But if one expects core.async channels are what most would prefer 
> anyway, is it okay to foist them upon everyone?
>
> As a follow up, does your opinion on the matter change if implementations 
> of an API become simpler using core.async channels?
>
>
> Looking forward to your thoughts :-)
>
> Chris Small
>
>
>
> PS I'm asking because I'm working on a physical computing API (
> https://github.com/clj-bots/pin-ctrl) and debating between using channels 
> vs callbacks for the edge detection functionality (if you're not familiar, 
> edge detection let's you asynchronously handle changes in pin state, such 
> as button pushes). If you're interested in this question as it applies 
> specifically to this application, feel free to join the discussion on our 
> gitter channel: https://gitter.im/clj-bots/chat
>

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

Re: Adding a simple hook to lein build process without writing a plugin

[Daniel Compton]

Hi Jonathon

Some combination of https://github.com/hyPiRion/lein-shell and
https://github.com/technomancy/leiningen/blob/master/doc/DEPLOY.md#releasing-simplified
may be what you need, though it depends how you want to use the results of
`git describe`.

On Tue, Jun 2, 2015 at 7:27 AM Jonathon McKitrick 
wrote:

> I'd like my build and/or deployment process to suck in the output of `git
> describe` for use as a build version in the app.  What's the simplest way
> to do that without writing a leiningen plugin?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Adding a simple hook to lein build process without writing a plugin

[Jonathon McKitrick]

I'd like my build and/or deployment process to suck in the output of `git 
describe` for use as a build version in the app.  What's the simplest way 
to do that without writing a leiningen plugin?

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

Opinion on core.async vs callbacks in abstract APIs?

[Christopher Small]

Greetings

I imagine most of us here would rather use core.async channels over
callbacks in their application code, particularly with more complicated
applications. But is it okay/preferable for Clojure libraries to force
their users to use core.async channels as part of an API (an event channel,
for example)?

As much as I love core.async, I can't help but wonder whether sticking with
callbacks for an API isn't a simpler/better design strategy. It's easy
enough to drop messages on a channel in a callback, and this let's users
opt-in. But if one expects core.async channels are what most would prefer
anyway, is it okay to foist them upon everyone?

As a follow up, does your opinion on the matter change if implementations
of an API become simpler using core.async channels?


Looking forward to your thoughts :-)

Chris Small



PS I'm asking because I'm working on a physical computing API (
https://github.com/clj-bots/pin-ctrl) and debating between using channels
vs callbacks for the edge detection functionality (if you're not familiar,
edge detection let's you asynchronously handle changes in pin state, such
as button pushes). If you're interested in this question as it applies
specifically to this application, feel free to join the discussion on our
gitter channel: https://gitter.im/clj-bots/chat

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

Re: prettier stacktraces?

[John Gabriele]

On Monday, June 1, 2015 at 2:57:50 PM UTC-4, John Gabriele wrote:
>
> On Monday, June 1, 2015 at 2:31:46 PM UTC-4, nikolay.k...@gmail.com wrote:
>>
>> I think this  is what you're 
>> looking for.
>>
>>
> Intriguing.
>
> How can I get this to work automatically? {snip}
>

Hm. {sigh} I really need to get my repl-based workflow happening. I think 
what I *should* be asking is, once I've got repl running with Emacs 
connected to it via cider, how can I see the colorized and prettified 
stacktrace when I try executing the offending function via that repl 
buffer...

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

Re: prettier stacktraces?

[John Gabriele]

On Monday, June 1, 2015 at 2:31:46 PM UTC-4, nikolay.k...@gmail.com wrote:
>
> I think this  is what you're 
> looking for.
>
>
Intriguing.

How can I get this to work automatically? I've got a project created via 
`lein new app my-app`, and I want to see the pretty stacktrace when I run 
the app via `lein run` and things blow up.

I tried just adding `[io.aviso/pretty "0.1.18"]` to my project.clj's 
:dependencies, but that doesn't change the stack trace output in my 
terminal.

Thanks.

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

ANN: ClojureScript 0.0-3308, fixes & enhancements

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

Leiningen dependency information:

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

This release bumps the Clojure dependecy to 1.7.0-RC1 and includes fixes
and minor
enhancements.

As always feedback welcome!

## 0.0-3308

## Changes
* Clojure 1.7.0-RC1 dependency
* CLJS-1292: Add IPrintWithWriter implementation for TaggedLiteral
* add cljs.core/random-uuid
* flush immediately when forwarding Node process out & err
* CLJS-1256 cache UUID hash value
* CLJS-1226: Added the :end-run-test event to cljs.test and a dummy event
handler for it

## Fixes
* CLJS-1200: compare behaves differently from Clojure
* CLJS-1293: Warning settings not conveyed via REPL
* CLJS-1291: pprint whitespace/letter checks are incomplete
* CLJS-1288: compiler doesn't emit "goog.require" for foreign library when
optimization level is not set
* check that we actually read something in cjls.repl.server/read-request
* clarify cljs.test/run-tests docstring
* CLJS-1285: load-file regression
* CLJS-1284: IndexedSeq -seq implementation incorrect for i >= alength of
internal array
* finish CLJS-1176, remove stray .isAlive method call
* add zero arity `newline` to match Clojure
* CLJS-1206: Images in HTML don't show up when served from localhost:9000
* CLJS-1272: :include-macros description inaccurate in require
* CLJS-1275: Corrected :test-paths in project.clj
* CLJS-1270: Docstring for delay not printed by cljs.repl/doc
* CLJS-1268: cljc support for cljs.closure/compile-file
* CLJS-1269: realized? docstring refers to promise and future
* match Clojure behavior for get on string / array. Need to coerce key into
int.
* CLJS-1263: :libs regression, can no longer specify specific files
* CLJS-1209: Reduce produces additional final nil when used w/ eduction
* CLJS-1261: source fn fails for fns with conditional code

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

Re: prettier stacktraces?

[nikolay . kudryavtsev]

I think this  is what you're looking 
for.

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

prettier stacktraces?

[John Gabriele]

How can I get prettier stacktraces? Would be great if it has colorized 
output in the terminal (highlighting line line indicating my .clj source 
code file).

I thought I'd try 
[clj-stacktrace](https://github.com/mmcgrana/clj-stacktrace), and updated 
my ~/.lein/profiles.clj as noted in the readme, but haven't gotten it to 
work.

Currently using Clojure v1.6.0.

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

Re: Advice when running java -jar rather than a managed server like tomcat?

[Colin Yates]

I recall seeing that from a while ago - weren’t they planning on rewriting 
emacs effectively?
> On 1 Jun 2015, at 15:55, Mikhail Malchevskiy  wrote:
> 
> https://github.com/syl20bnr/spacemacs =)
> 
> понедельник, 1 июня 2015 г., 17:05:35 UTC+3 пользователь Colin Yates написал:
> Hi Karsten, 
> 
> Unfortunately our clients are primarily windows based and the software is 
> commercial. tmux - that takes me back! I have never forgotten the joy, or 
> found an equivalent on KDE, Gnome, Windows or OSX of a well configured 
> xMonad, I remember reaching for tmux as a substitute when running over ssh … 
> Sigh - those were the days.  (all we need now is someone to point out the 
> obvious superiority of emacs over vim for this to ignite into a flame war… oh 
> wait…) 
> 
> > On 1 Jun 2015, at 15:00, Karsten Schmidt > 
> > wrote: 
> > 
> > For smaller deployments, so far I've always had a smooth ride using 
> > nginx as reverse proxy and running the uberjar inside tmux. No other 
> > special sauce needed, plus you get the benefit of using nginx to serve 
> > your static assets (if there're not on a CDN already)... 
> > 
> > On 1 June 2015 at 14:40, Colin Yates > 
> > wrote: 
> >> Thanks Daniel, I am trying to reduce the required installed software on 
> >> the 
> >> client and they can’t access a maven repo from which to download 
> >> unfortunately. Hence I am looking for a ‘self contained executable’ 
> >> solution. 
> >> 
> >> You are yet-another-exclaimer of Boot; enough people have sung its praises 
> >> to make it one of the next things I will need to investigate ;). 
> >> 
> >> 
> >> On 1 Jun 2015, at 14:30, Daniel Szmulewicz  >> > 
> >> wrote: 
> >> 
> >> Great conversation starter. 
> >> 
> >> Many of us had to take down that route. Eventually, we settle on a 
> >> deployment solution that works for us, and we can move on with dev'ing. 
> >> I'm 
> >> sure all the answers are worthy. Please allow me to share my solution to 
> >> this problem. It may not work for everyone, but it works for me. 
> >> 
> >> It can be summarized as follow: Runit supervisor + Boot. 
> >> 
> >> More information here: 
> >> 
> >> https://github.com/danielsz/boot-runit 
> >>  
> >> 
> >> Note: this is the solution I came up with after experimenting with the 
> >> strategies outlined in Ryan's blog post. 
> >> http://www.rkn.io/2014/02/06/clojure-cookbook-daemons/ 
> >>  
> >> 
> >> Now I do 'boot dev' locally and 'boot prod' on the server (with auxiliary 
> >> 'boot dev-run' and 'boot prod-run'). 
> >> 
> >> Runit is a Unix classic (as in "an outstanding example of a particular 
> >> style"), and Boot is quickly becoming a Clojure classic. 
> >> 
> >> More examples here: 
> >> https://github.com/danielsz/system/blob/master/examples/boot/build.boot 
> >>  
> >> 
> >> 
> >> On Tuesday, May 26, 2015 at 2:38:30 PM UTC+3, Colin Yates wrote: 
> >>> 
> >>> Hi, 
> >>> 
> >>> I am venturing into new territory using http-kit, as I usually use a 
> >>> 'managed' web server container like tomcat and have a few questions about 
> >>> packing and running a JAR file: 
> >>> 
> >>> - are there are convenient service wrappers for windows and/or Linux 
> >>> - any best practice around managing class path for things like 
> >>> logback.xml 
> >>> 
> >>> I have a jar created from lein uberjar and java -jar the.jar works, but 
> >>> this seems a long way away from automated deployment :). 
> >>> 
> >>> Any advice welcome - thanks! 
> >> 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "Clojure" group. 
> >> To post to this group, send email to clo...@googlegroups.com  
> >> Note that posts from new members are moderated - please be patient with 
> >> your 
> >> first post. 
> >> To unsubscribe from this group, send email to 
> >> clojure+u...@googlegroups.com  
> >> For more options, visit this group at 
> >> http://groups.google.com/group/clojure?hl=en 
> >>  
> >> --- 
> >> You received this message because you are subscribed to the Google Groups 
> >> "Clojure" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send an 
> >> email to clojure+u...@googlegroups.com . 
> >> For more options, visit https://groups.google.com/d/optout 
> >> . 
> >> 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "Clojure" group. 
> >> To post to this group, send email to clo...@googlegroups.com  
> >> Note that posts from new members are moderated - please be patient with 
> >> your 
> >> first post. 
> >> To unsubscribe from this group, send email to 
> >> clojure+u...@googlegroups.com  
> >> For more options, visit this group at 
> >> http://groups.google.com/group/clojure?hl=en 
> >> 

Re: Clojure.data.xml fails when element size reached 33 symbols.

[Sean Corfield]

On Jun 1, 2015, at 7:58 AM, nikolay.kudryavt...@gmail.com wrote:
> This happens only when I use some kind of input stream(either 
> java.io.FileInputStream or io/input-stream wrapper). Just doing (parse-str 
> (slurp file)) works.
> 
> So, when I have a file containing only this:
> aa
> 
> I get this exception:
> 1. Unhandled javax.xml.stream.XMLStreamException
>ParseError at [row,col]:[1,33] Message: Stream Closed
> 
>nil:   -1  
> com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl/next
>xml.clj:  287  clojure.data.xml/pull-seq/fn
>   LazySeq.java:   42  clojure.lang.LazySeq/sval
>   LazySeq.java:   60  clojure.lang.LazySeq/seq

Based on the this I’d say you’re tripping over lazy chunked sequence 
processing. Each chunk is typically 32 elements. You tend to get "stream 
closed" or "connection closed" errors if you let a lazy sequence escape the 
open/close logic in your code, since it gets closed after just the first chunk.

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/d/optout.

Clojure.data.xml fails when element size reached 33 symbols.

[nikolay . kudryavtsev]

Hello.

I needed to parse and emit some xml, that has no namespaces and there 
should be no extra whitespace that is added by clojure.xml.

Decided to try using clojure.data.xml. And for me it fails as soon as the 
total size of an element reaches 33 symbols.

This happens only when I use some kind of input stream(either 
java.io.FileInputStream or io/input-stream wrapper). Just doing (parse-str 
(slurp file)) works.

So, when I have a file containing only this:
aa

I get this exception:
1. Unhandled javax.xml.stream.XMLStreamException
   ParseError at [row,col]:[1,33] Message: Stream Closed

   nil:   -1  
com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl/next
   xml.clj:  287  clojure.data.xml/pull-seq/fn
  LazySeq.java:   42  clojure.lang.LazySeq/sval
  LazySeq.java:   60  clojure.lang.LazySeq/seq
   RT.java:  484  clojure.lang.RT/seq
  core.clj:  133  clojure.core/seq
   xml.clj:  178  clojure.data.xml/seq-tree/fn
  LazySeq.java:   42  clojure.lang.LazySeq/sval
  LazySeq.java:   60  clojure.lang.LazySeq/seq
  LazySeq.java:   82  clojure.lang.LazySeq/first
   RT.java:  577  clojure.lang.RT/first
  core.clj:   55  clojure.core/first
   xml.clj:  187  clojure.data.xml/seq-tree/fn/fn
  LazySeq.java:   42  clojure.lang.LazySeq/sval
  LazySeq.java:   60  clojure.lang.LazySeq/seq
 Cons.java:   39  clojure.lang.Cons/next
   RT.java:  598  clojure.lang.RT/next
  core.clj:   64  clojure.core/next
  core.clj: 2809  clojure.core/nthnext
core_print.clj:   57  clojure.core/print-sequential
core_print.clj:  143  clojure.core/fn
  MultiFn.java:  231  clojure.lang.MultiFn/invoke
  core.clj: 3322  clojure.core/pr-on
core_print.clj:  200  clojure.core/print-map/fn
core_print.clj:   58  clojure.core/print-sequential
core_print.clj:  203  clojure.core/print-map
core_print.clj:  260  clojure.core/fn
  MultiFn.java:  231  clojure.lang.MultiFn/invoke
  core.clj: 3322  clojure.core/pr-on
core_print.clj:   58  clojure.core/print-sequential
core_print.clj:  194  clojure.core/fn
  MultiFn.java:  231  clojure.lang.MultiFn/invoke
 pr_values.clj:   26  
clojure.tools.nrepl.middleware.pr-values/pr-values/fn/reify
interruptible_eval.clj:   84  
clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn/fn
  main.clj:  260  clojure.main/repl/read-eval-print
  main.clj:  277  clojure.main/repl/fn
  main.clj:  277  clojure.main/repl
   RestFn.java: 1523  clojure.lang.RestFn/invoke
interruptible_eval.clj:   72  
clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
  AFn.java:  159  clojure.lang.AFn/applyToHelper
  AFn.java:  151  clojure.lang.AFn/applyTo
  core.clj:  617  clojure.core/apply
  core.clj: 1788  clojure.core/with-bindings*
   RestFn.java:  425  clojure.lang.RestFn/invoke
interruptible_eval.clj:   56  
clojure.tools.nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj:  188  
clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
interruptible_eval.clj:  157  
clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
  AFn.java:   24  clojure.lang.AFn/run
   nil:   -1  
java.util.concurrent.ThreadPoolExecutor/runWorker
   nil:   -1  
java.util.concurrent.ThreadPoolExecutor$Worker/run
   nil:   -1  java.lang.Thread/run

The way you get to 33 symbols does not matter. This would give you the same 
error:


Any ideas?

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

Re: Advice when running java -jar rather than a managed server like tomcat?

[Mikhail Malchevskiy]

https://github.com/syl20bnr/spacemacs =)

понедельник, 1 июня 2015 г., 17:05:35 UTC+3 пользователь Colin Yates 
написал:
>
> Hi Karsten, 
>
> Unfortunately our clients are primarily windows based and the software is 
> commercial. tmux - that takes me back! I have never forgotten the joy, or 
> found an equivalent on KDE, Gnome, Windows or OSX of a well configured 
> xMonad, I remember reaching for tmux as a substitute when running over ssh 
> … Sigh - those were the days.  (all we need now is someone to point out the 
> obvious superiority of emacs over vim for this to ignite into a flame war… 
> oh wait…) 
>
> > On 1 Jun 2015, at 15:00, Karsten Schmidt > 
> wrote: 
> > 
> > For smaller deployments, so far I've always had a smooth ride using 
> > nginx as reverse proxy and running the uberjar inside tmux. No other 
> > special sauce needed, plus you get the benefit of using nginx to serve 
> > your static assets (if there're not on a CDN already)... 
> > 
> > On 1 June 2015 at 14:40, Colin Yates > 
> wrote: 
> >> Thanks Daniel, I am trying to reduce the required installed software on 
> the 
> >> client and they can’t access a maven repo from which to download 
> >> unfortunately. Hence I am looking for a ‘self contained executable’ 
> >> solution. 
> >> 
> >> You are yet-another-exclaimer of Boot; enough people have sung its 
> praises 
> >> to make it one of the next things I will need to investigate ;). 
> >> 
> >> 
> >> On 1 Jun 2015, at 14:30, Daniel Szmulewicz  > 
> >> wrote: 
> >> 
> >> Great conversation starter. 
> >> 
> >> Many of us had to take down that route. Eventually, we settle on a 
> >> deployment solution that works for us, and we can move on with dev'ing. 
> I'm 
> >> sure all the answers are worthy. Please allow me to share my solution 
> to 
> >> this problem. It may not work for everyone, but it works for me. 
> >> 
> >> It can be summarized as follow: Runit supervisor + Boot. 
> >> 
> >> More information here: 
> >> 
> >> https://github.com/danielsz/boot-runit 
> >> 
> >> Note: this is the solution I came up with after experimenting with the 
> >> strategies outlined in Ryan's blog post. 
> >> http://www.rkn.io/2014/02/06/clojure-cookbook-daemons/ 
> >> 
> >> Now I do 'boot dev' locally and 'boot prod' on the server (with 
> auxiliary 
> >> 'boot dev-run' and 'boot prod-run'). 
> >> 
> >> Runit is a Unix classic (as in "an outstanding example of a particular 
> >> style"), and Boot is quickly becoming a Clojure classic. 
> >> 
> >> More examples here: 
> >> https://github.com/danielsz/system/blob/master/examples/boot/build.boot 
> >> 
> >> 
> >> On Tuesday, May 26, 2015 at 2:38:30 PM UTC+3, Colin Yates wrote: 
> >>> 
> >>> Hi, 
> >>> 
> >>> I am venturing into new territory using http-kit, as I usually use a 
> >>> 'managed' web server container like tomcat and have a few questions 
> about 
> >>> packing and running a JAR file: 
> >>> 
> >>> - are there are convenient service wrappers for windows and/or Linux 
> >>> - any best practice around managing class path for things like 
> >>> logback.xml 
> >>> 
> >>> I have a jar created from lein uberjar and java -jar the.jar works, 
> but 
> >>> this seems a long way away from automated deployment :). 
> >>> 
> >>> Any advice welcome - thanks! 
> >> 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "Clojure" group. 
> >> To post to this group, send email to clo...@googlegroups.com 
>  
> >> Note that posts from new members are moderated - please be patient with 
> your 
> >> first post. 
> >> To unsubscribe from this group, send email to 
> >> clojure+u...@googlegroups.com  
> >> For more options, visit this group at 
> >> http://groups.google.com/group/clojure?hl=en 
> >> --- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "Clojure" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to clojure+u...@googlegroups.com . 
> >> For more options, visit https://groups.google.com/d/optout. 
> >> 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "Clojure" group. 
> >> To post to this group, send email to clo...@googlegroups.com 
>  
> >> Note that posts from new members are moderated - please be patient with 
> your 
> >> first post. 
> >> To unsubscribe from this group, send email to 
> >> clojure+u...@googlegroups.com  
> >> For more options, visit this group at 
> >> http://groups.google.com/group/clojure?hl=en 
> >> --- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "Clojure" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to clojure+u...@googlegroups.com . 
> >> For more options, visit https://groups.google.com/d/optout. 
> > 
> > 
> > 
> > -- 
> > Karsten Schmidt 
> > http://postspectacular.com | http://thi.ng | http://toxiclibs.org 
> > 
> > -- 
> > Yo

Re: [ANN] thi.ng additions/updates

[Ivan L]

this project is so cool.  I've been playing around with noise and svg 
thanks to it.  Thanks Karsten!

>
>

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

Re: Advice when running java -jar rather than a managed server like tomcat?

[Colin Yates]

Hi Karsten,

Unfortunately our clients are primarily windows based and the software is 
commercial. tmux - that takes me back! I have never forgotten the joy, or found 
an equivalent on KDE, Gnome, Windows or OSX of a well configured xMonad, I 
remember reaching for tmux as a substitute when running over ssh … Sigh - those 
were the days.  (all we need now is someone to point out the obvious 
superiority of emacs over vim for this to ignite into a flame war… oh wait…)

> On 1 Jun 2015, at 15:00, Karsten Schmidt  wrote:
> 
> For smaller deployments, so far I've always had a smooth ride using
> nginx as reverse proxy and running the uberjar inside tmux. No other
> special sauce needed, plus you get the benefit of using nginx to serve
> your static assets (if there're not on a CDN already)...
> 
> On 1 June 2015 at 14:40, Colin Yates  wrote:
>> Thanks Daniel, I am trying to reduce the required installed software on the
>> client and they can’t access a maven repo from which to download
>> unfortunately. Hence I am looking for a ‘self contained executable’
>> solution.
>> 
>> You are yet-another-exclaimer of Boot; enough people have sung its praises
>> to make it one of the next things I will need to investigate ;).
>> 
>> 
>> On 1 Jun 2015, at 14:30, Daniel Szmulewicz 
>> wrote:
>> 
>> Great conversation starter.
>> 
>> Many of us had to take down that route. Eventually, we settle on a
>> deployment solution that works for us, and we can move on with dev'ing. I'm
>> sure all the answers are worthy. Please allow me to share my solution to
>> this problem. It may not work for everyone, but it works for me.
>> 
>> It can be summarized as follow: Runit supervisor + Boot.
>> 
>> More information here:
>> 
>> https://github.com/danielsz/boot-runit
>> 
>> Note: this is the solution I came up with after experimenting with the
>> strategies outlined in Ryan's blog post.
>> http://www.rkn.io/2014/02/06/clojure-cookbook-daemons/
>> 
>> Now I do 'boot dev' locally and 'boot prod' on the server (with auxiliary
>> 'boot dev-run' and 'boot prod-run').
>> 
>> Runit is a Unix classic (as in "an outstanding example of a particular
>> style"), and Boot is quickly becoming a Clojure classic.
>> 
>> More examples here:
>> https://github.com/danielsz/system/blob/master/examples/boot/build.boot
>> 
>> 
>> On Tuesday, May 26, 2015 at 2:38:30 PM UTC+3, Colin Yates wrote:
>>> 
>>> Hi,
>>> 
>>> I am venturing into new territory using http-kit, as I usually use a
>>> 'managed' web server container like tomcat and have a few questions about
>>> packing and running a JAR file:
>>> 
>>> - are there are convenient service wrappers for windows and/or Linux
>>> - any best practice around managing class path for things like
>>> logback.xml
>>> 
>>> I have a jar created from lein uberjar and java -jar the.jar works, but
>>> this seems a long way away from automated deployment :).
>>> 
>>> Any advice welcome - thanks!
>> 
>> 
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> Karsten Schmidt
> http://postspectacular.com | http://thi.ng | http://toxiclibs.org
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because y

Re: Advice when running java -jar rather than a managed server like tomcat?

[Karsten Schmidt]

For smaller deployments, so far I've always had a smooth ride using
nginx as reverse proxy and running the uberjar inside tmux. No other
special sauce needed, plus you get the benefit of using nginx to serve
your static assets (if there're not on a CDN already)...

On 1 June 2015 at 14:40, Colin Yates  wrote:
> Thanks Daniel, I am trying to reduce the required installed software on the
> client and they can’t access a maven repo from which to download
> unfortunately. Hence I am looking for a ‘self contained executable’
> solution.
>
> You are yet-another-exclaimer of Boot; enough people have sung its praises
> to make it one of the next things I will need to investigate ;).
>
>
> On 1 Jun 2015, at 14:30, Daniel Szmulewicz 
> wrote:
>
> Great conversation starter.
>
> Many of us had to take down that route. Eventually, we settle on a
> deployment solution that works for us, and we can move on with dev'ing. I'm
> sure all the answers are worthy. Please allow me to share my solution to
> this problem. It may not work for everyone, but it works for me.
>
> It can be summarized as follow: Runit supervisor + Boot.
>
> More information here:
>
> https://github.com/danielsz/boot-runit
>
> Note: this is the solution I came up with after experimenting with the
> strategies outlined in Ryan's blog post.
> http://www.rkn.io/2014/02/06/clojure-cookbook-daemons/
>
> Now I do 'boot dev' locally and 'boot prod' on the server (with auxiliary
> 'boot dev-run' and 'boot prod-run').
>
> Runit is a Unix classic (as in "an outstanding example of a particular
> style"), and Boot is quickly becoming a Clojure classic.
>
> More examples here:
> https://github.com/danielsz/system/blob/master/examples/boot/build.boot
>
>
> On Tuesday, May 26, 2015 at 2:38:30 PM UTC+3, Colin Yates wrote:
>>
>> Hi,
>>
>> I am venturing into new territory using http-kit, as I usually use a
>> 'managed' web server container like tomcat and have a few questions about
>> packing and running a JAR file:
>>
>>  - are there are convenient service wrappers for windows and/or Linux
>>  - any best practice around managing class path for things like
>> logback.xml
>>
>> I have a jar created from lein uberjar and java -jar the.jar works, but
>> this seems a long way away from automated deployment :).
>>
>> Any advice welcome - thanks!
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Karsten Schmidt
http://postspectacular.com | http://thi.ng | http://toxiclibs.org

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

Re: Advice when running java -jar rather than a managed server like tomcat?

[Colin Yates]

Thanks Daniel, I am trying to reduce the required installed software on the 
client and they can’t access a maven repo from which to download unfortunately. 
Hence I am looking for a ‘self contained executable’ solution.

You are yet-another-exclaimer of Boot; enough people have sung its praises to 
make it one of the next things I will need to investigate ;).

> On 1 Jun 2015, at 14:30, Daniel Szmulewicz  
> wrote:
> 
> Great conversation starter. 
> 
> Many of us had to take down that route. Eventually, we settle on a deployment 
> solution that works for us, and we can move on with dev'ing. I'm sure all the 
> answers are worthy. Please allow me to share my solution to this problem. It 
> may not work for everyone, but it works for me. 
> 
> It can be summarized as follow: Runit supervisor + Boot. 
> 
> More information here: 
> 
> https://github.com/danielsz/boot-runit
> 
> Note: this is the solution I came up with after experimenting with the 
> strategies outlined in Ryan's blog post. 
> http://www.rkn.io/2014/02/06/clojure-cookbook-daemons/
> 
> Now I do 'boot dev' locally and 'boot prod' on the server (with auxiliary 
> 'boot dev-run' and 'boot prod-run').
> 
> Runit is a Unix classic (as in "an outstanding example of a particular 
> style"), and Boot is quickly becoming a Clojure classic.
> 
> More examples here: 
> https://github.com/danielsz/system/blob/master/examples/boot/build.boot
> 
> 
> On Tuesday, May 26, 2015 at 2:38:30 PM UTC+3, Colin Yates wrote:
> Hi,
> 
> I am venturing into new territory using http-kit, as I usually use a 
> 'managed' web server container like tomcat and have a few questions about 
> packing and running a JAR file:
> 
>  - are there are convenient service wrappers for windows and/or Linux
>  - any best practice around managing class path for things like logback.xml
> 
> I have a jar created from lein uberjar and java -jar the.jar works, but this 
> seems a long way away from automated deployment :).
> 
> Any advice welcome - thanks!
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

Re: Advice when running java -jar rather than a managed server like tomcat?

[Daniel Szmulewicz]

Great conversation starter. 

Many of us had to take down that route. Eventually, we settle on a 
deployment solution that works for us, and we can move on with dev'ing. I'm 
sure all the answers are worthy. Please allow me to share my solution to 
this problem. It may not work for everyone, but it works for me. 

It can be summarized as follow: Runit supervisor + Boot. 

More information here: 

https://github.com/danielsz/boot-runit

Note: this is the solution I came up with after experimenting with the 
strategies outlined in Ryan's blog post. 
http://www.rkn.io/2014/02/06/clojure-cookbook-daemons/

Now I do 'boot dev' locally and 'boot prod' on the server (with auxiliary 
'boot dev-run' and 'boot prod-run').

Runit is a Unix classic (as in "an outstanding example of a particular 
style"), and Boot is quickly becoming a Clojure classic.

More examples 
here: https://github.com/danielsz/system/blob/master/examples/boot/build.boot


On Tuesday, May 26, 2015 at 2:38:30 PM UTC+3, Colin Yates wrote:
>
> Hi,
>
> I am venturing into new territory using http-kit, as I usually use a 
> 'managed' web server container like tomcat and have a few questions about 
> packing and running a JAR file:
>
>  - are there are convenient service wrappers for windows and/or Linux
>  - any best practice around managing class path for things like logback.xml
>
> I have a jar created from lein uberjar and java -jar the.jar works, but 
> this seems a long way away from automated deployment :).
>
> Any advice welcome - thanks!
>

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

Re: Prevayler in Clojure

[Sergey Didenko]

May be you will be interested to see my toy library for prevalence in
Clojure - https://github.com/SergeyDidenko/Simple-Persistence-for-Clojure

On Sun, May 31, 2015 at 12:56 AM, Plínio Balduino 
wrote:

> Awesome, Klaus
>
> Thank you
>
> Plínio
>
> On Sat, May 30, 2015 at 4:31 PM, Klaus Wuestefeld <
> klauswuestef...@gmail.com> wrote:
>
>> Prevalence is the fastest possible and third simplest ACID persistence
>> technique, combining the two simplest ones.
>>
>> https://github.com/klauswuestefeld/prevayler-clj
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: When use Pedestal, Hoplon, Bidi and Route-one?

[Daniel Kersten]

As far as I can tell, in that table "isomorphic" means that you can go both
from "URL to route" and from "route to URL", whereas "cljs" means you can
use it from clojurescript in the browser.

I personally use bidi and its great. Because its just data, it means that
you can easily combine and compose routes. Because it works in both clj and
cljs it means you can use the same or very similar routes or routing code
both in client and server should you want to do that. I'm sure the others
are great too, but I have no experience with them (besides compojure). I
did try silk when it first came out but I found bidi easier ultimately (at
least, at the time).

On Sun, 31 May 2015 at 13:37 Krzysztof Władyka  wrote:

> Hi,
>
> I am trying figure out which one (Pedestal, Hoplon, Bidi) should i use? I
> didn't find any good article in the Internet which help me with this choice.
>
> From https://github.com/juxt/bidi i can read Pedestal is isomorphic, but
> Bidi is also cljs. What is it mean? What is the difference?
>
>
> I found compojure is to simply. I can't even generate URLs in HTML
> templates. I started looking something else. I found also route-one
> (library to generate URLs working with compojure), but i guess soon i will
> discover i need something more then compojure have again.
>
> My intuition say me to choose between: Pedestal, Hoplon and Bidi.
>
>
> What i need:
> I want have independent business model architecture like
> http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
>
> http://blog.find-method.de/index.php?/archives/209-Dependency-inversion-in-Clojure.html
>
> I don't want depend this part of code with any framework. Less dependency
> is better.
>
>
> On next stage i want inject this model business into something like
> bridge, which will be the connector with user interface. It can be time for
> framework or additional libraries.
>
> And at least i want create frontend user interface as website. It will be
> dynamic content with ClojureScript or mayby static. I don't know. I have to
> thing about both.
>
>
> What i found out in Clojure i really like conception on building my own
> set of libraries based on my preferences. But i don't want write my own
> code to use things like generate URLs for routes. So mayby i should also
> consider route-one?
>
>
> Please write something clever what help me choose one or complicate my
> live with some other option to choose :)
> https://github.com/juxt/bidi
> https://github.com/pedestal/pedestal
> https://github.com/tailrecursion/hoplon
> https://github.com/clojurewerkz/route-one
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Dunaj lite, a library-only version of Dunaj

[Jozef Wagner]

Hi,

Dunaj v0.5.0 has been released [1]. Dunaj lite, a library only version of 
Dunaj, has been updated too [2].

Highlights of the new version
* Built on top of Clojure 1.7.0 RC1
* Changed semantics of qualified specials. The handling of special symbols 
is now backwards compatible with Clojure
* Supports :let modifier in cond, when-let and if-let, similar to CLJ-200

Full list of changes can be found at [3]. Dunaj is a set of core language 
experiments aimed to improve Clojure language and its core API. It deals 
with language features that require changes across different parts of 
Clojure and which cannot be evaluated in isolation. Dunaj is an effort to 
bring Clojure even more towards simplicity, consistency and performance.

Best,
Jozef

[1] http://www.dunaj.org
[2] http://lite.dunaj.org
[3] http://www.dunaj.org/news.html

On Monday, April 13, 2015 at 10:26:29 AM UTC+2, Jozef Wagner wrote:
>
> Hi all,
>
> I've just released a version 0.4.0 of Dunaj [1], that contains some 
> bugfixes and is built on top of Clojure 1.7.0 beta1. Dunaj provides an 
> alternative core API for Clojure, introducing a set of core language 
> experiments aimed to improve Clojure language and its core API.
>
> Starting from this version, Dunaj now provides a library only version 
> called Dunaj lite. The codebase is shared, and Dunaj lite supports nearly 
> all of Dunaj’s functionalities. Dunaj lite is ideal for cases where you 
> want to evaluate Dunaj in existing projects, or in cases you cannot or 
> don’t want to use custom Clojure forks. See Dunaj lite homepage [2] for 
> more information. The main differences are:
>
> * bit more verbose and less elegant usage
> * small decrease of performance
> * no qualified special symbols
> * no changes to primitive types
>
> I've also started blogging at [3], where I plan to focus on Dunaj's 
> individual features and its usage in real world cases.
>
> Best,
> Jozef Wagner
>
> [1] http://www.dunaj.org
> [2] http://lite.dunaj.org
> [3] http://blog.wagjo.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/d/optout.

Re: complex number library

[Christopher Small]

Are these operations (*, +, etc) interoperable with core.matrix operations? 
That may end up being pretty key for a lot of numerical users.

Chris


On Sunday, May 31, 2015 at 3:55:46 PM UTC-7, Alan Forrester wrote:
>
> https://clojars.org/complex 
>
> https://github.com/alanforr/complex 
>
> Complex is a Clojure library for doing complex number calculations 
> that wraps the Java commons-math3 Complex library. 
>
> complex 
>
> A Clojure library for doing calculations with complex numbers. Wraps 
> the Java commons-math3 Complex library. 
>
> Usage 
>
> A complex number can be created by invoking the complex number 
> function. With one argument the function produces a complex number in 
> which only the real component is non-zero. With two arguments, the 
> first argument is the real part, the second argument is the imaginary 
> part: 
>
> => (complex-number 1) 
>
> Complex (1.0, 0.0) 
>
> => (complex-number 1 2) 
>
> Complex (1.0, 2.0). 
>
> The library can be used to do complex arithmetic. The + function can 
> have any number of real or complex arguments but always produces a 
> complex result. 
>
> => (+ 1 (complex-number 3 4)) 
>
> Complex (4.0, 4.0). 
>
> The same is true of the other arithmetical operations *,-,/. The 
> arithmetical functions are fastest on a per number basis when used on 
> only two arguments. They are also faster when their arguments are 
> complex. 
>
> The library also provides other functions, such as (pow a b), which 
> raises a to the power b, (sin a) which calculates the sine of a, and 
> several other functions. For details, see the docs. 
>
> Alan 
>

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

Re: complex number library

[Alan Forrester]

On 1 June 2015 at 00:42, Daniel  wrote:

> Criterium should probably be just a Dev dependency.

Okay. Fixed.

Thanks,
Alan

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