Re: Offline Clojure docs

[Erik Bakstad]

If you are a Mac user I highly recommend Dash  it 
has all kinds of documentation available for download, and the search is 
very nice as well.

-Erik

kl. 07:31:40 UTC+2 mandag 1. juli 2013 skrev David Pollak følgende:
>
> Thanks everyone for the super helpful suggestions!
>
>
> On Mon, Jul 1, 2013 at 9:04 AM, Mark Engelberg 
> 
> > wrote:
>
>> Download here:
>> https://github.com/clojure/clojure/tree/gh-pages
>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

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

core.async - question about close!

[Mark Engelberg]

Is close! merely a convenience function to ensure that future puts to a
channel will not be permitted, or is it essential to close! a channel so
that it will be garbage collected?

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

Re: core.async

[David Pollak]

Thanks!


On Mon, Jul 1, 2013 at 8:13 AM, Sean Corfield wrote:

> On Sun, Jun 30, 2013 at 4:42 PM, David Pollak 
> wrote:
> > Looking forward to it
> > being published (even as SNAPSHOT) in a Maven repo.
>
> It's accessible like this:
>
> (defproject async "0.1.0-SNAPSHOT"
>   :description "FIXME: write description"
>   :url "http://example.com/FIXME";
>   :license {:name "Eclipse Public License"
> :url "http://www.eclipse.org/legal/epl-v10.html"}
>   :repositories {"sonatype-oss-public"
> "https://oss.sonatype.org/content/groups/public/"}
>   :dependencies [[org.clojure/clojure "1.5.1"]
>  [org.clojure/core.async "0.1.0-SNAPSHOT"]])
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Offline Clojure docs

[David Pollak]

Thanks everyone for the super helpful suggestions!


On Mon, Jul 1, 2013 at 9:04 AM, Mark Engelberg wrote:

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

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

Re: Microsoft Rx -style operations with core.async

[Brandon Bloom]

Then maybe we need (go-as [c arg] ...)

On Sunday, June 30, 2013 8:15:45 PM UTC-4, David Nolen wrote:
>
> Because of blocking on read/write on unbuffered channels - users might 
> need more flexibility.
>
>
> On Sun, Jun 30, 2013 at 8:13 PM, Brandon Bloom 
> 
> > wrote:
>
>> > My understanding with some member of the core.async team is that most 
>> channel based APIs fns should *take* a channel and only construct one as a 
>> default.
>>
>> Could you elaborate on and motivate that?
>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

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

Re: [ANN] byte-streams: a rosetta stone for all the byte representations the jvm has to offer

[Dan Burkert]

Very cool, I've got a couple of question: the readme references optimized 
transfers, what qualifies as an optimized transfer?  Also, would it be 
possible for byte-streams to give an estimation of the number of memory 
copies that happen in a given conversion (maybe this is as simple as the 
number of steps...)?  Thanks for releasing this!

-- Dan

On Saturday, June 29, 2013 1:57:58 PM UTC-4, Zach Tellman wrote:
>
> I've recently been trying to pull out useful pieces from some of my more 
> monolithic libraries.  The most recent result is 'byte-streams' [1], a 
> library that figures how how to convert between different byte 
> representations (including character streams), and how to efficiently 
> transfer bytes between various byte sources and sinks.  The net result is 
> that you can do something like:
>
>   (byte-streams/convert (File. "/tmp/foo") String {:encoding "utf-8"})
>
> and get a string representation of the file's contents.  Of course, this 
> is already possible using 'slurp', but you could also convert it to a 
> CharSequence, or lazy sequence of ByteBuffers, or pretty much anything else 
> you can imagine.  This is accomplished by traversing a graph of available 
> conversions (don't worry, it's memoized), so simply defining a new 
> conversion from some custom type to (say) a ByteBuffer will transitively 
> allow you to convert it to any other type.
>
> As an aside, this sort of conversion mechanism isn't limited to just byte 
> representations, but I'm not sure if there's another large collection of 
> mostly-isomorphic types out there that would benefit from this.  If anyone 
> has ideas on where else this could be applied, I'd be interested to hear 
> them.
>
> Zach
>
> [1] https://github.com/ztellman/byte-streams
>

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

Re: Translating simple path finding problem from prolog to core.logic

[Craig Ching]

Thanks Norman!  Not sure how I didn't realize that was happening, but it's 
working exactly as you describe.  Thanks much for your help!

Cheers,
Craig

On Sunday, June 30, 2013 2:40:48 PM UTC-5, Norman Richards wrote:
>
> Just like the prolog, you are generating an infinite number of solutions. 
>  run* will try and give you all of them.  You can use clojure's lazy seq 
> operations (first, take, etc...) or just ask for however many you want:
>
> > (run 10 [q] (path2 1 7 q))
>
> ((1 4 3 7) 
> 
>  
>  (1 2 4 3 7)   
> 
>  
>  (1 4 5 7) 
> 
>  
>  (1 2 4 5 7)   
> 
>  
>  (1 4 3 6 5 7) 
> 
>  
>  (1 2 4 3 6 5 7)   
> 
>  
>  (1 4 5 6 5 7) 
> 
>  
>  (1 2 4 5 6 5 7)   
> 
>  
>  (1 4 3 7 5 7) 
> 
>  
>  (1 2 4 3 7 5 7))  
>
>

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

Re: Offline Clojure docs

[Mark Engelberg]

Download here:
https://github.com/clojure/clojure/tree/gh-pages

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

Re: ANN: faster zipper implementation

[Alexander Hudek]

Thanks Zach! I've pulled your changes to 0.3.0-SNAPSHOT. Updated benchmark:

Case:  :clojure.zip
Evaluation count : 75480 in 60 samples of 1258 calls.
 Execution time mean : 805.666773 µs
Execution time std-deviation : 4.815877 µs
   Execution time lower quantile : 797.942766 µs ( 2.5%)
   Execution time upper quantile : 816.578299 µs (97.5%)

Found 2 outliers in 60 samples (3. %)
low-severe 2 (3. %)
 Variance from outliers : 1.6389 % Variance is slightly inflated by outliers

Case:  :fast-zip
Evaluation count : 297900 in 60 samples of 4965 calls.
 Execution time mean : 202.892179 µs
Execution time std-deviation : 848.456881 ns
   Execution time lower quantile : 201.212286 µs ( 2.5%)
   Execution time upper quantile : 204.187311 µs (97.5%)

Found 1 outliers in 60 samples (1.6667 %)
low-severe 1 (1.6667 %)
 Variance from outliers : 1.6389 % Variance is slightly inflated by outliers

I did try adding some inline forms, but they didn't seem to help. See this 
branch:

https://github.com/akhudek/fast-zip/tree/no-protocol+inline



On Sunday, June 30, 2013 7:46:53 PM UTC-4, Zach Tellman wrote:
>
> This is really cool, thanks for doing this.  I was able to eke out another 
> 1.8x speedup by replacing '=' with 'identical?' for the keyword comparisons 
> [1]. There also might be further room for improvement by defining inline 
> forms for some of the smaller functions.
>
> Zach
>
> [1] 
> https://github.com/ztellman/fast-zip/commit/ee7a64630389f36a539771658586a093369f7939
>
> On Sunday, June 30, 2013 1:18:05 PM UTC-7, Alexander Hudek wrote:
>>
>> I've updated the clojure.zip implementation to use records internally. 
>> This
>> achieves a speedup of roughly 2x. You can find the library below and on
>> clojars:
>>
>> https://github.com/akhudek/fast-zip
>>
>> It's a drop in replacement for clojure.zip in terms of interface and 
>> usage. 
>> However, since the internal representation has changed, fast-zip 
>> locations 
>> cannot be used with the clojure.zip implementation. E.g. you cannot
>> create a zipper with fast-zip, then use clojure.zip/next on the result. 
>> You 
>> must use fast.zip.core/next instead. 
>>
>> In addition to the micro-benchmark provided, I've tried this in a larger 
>> project
>> that makes extensive use of zippers and found a similar speedup.
>>
>> Comments and suggestions welcome.
>>
>> Alex
>>
>

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

Re: Offline Clojure docs

[Sean Corfield]

There are a couple of iPhone apps with Clojure docs:

https://itunes.apple.com/us/app/clojuredoc/id401479442?mt=8 <-- free,
hasn't been updated for ages, but this is what I use anyway

https://itunes.apple.com/us/app/clojure-bee-api-documentation/id524862532?mt=8
<-- $0.99, hasn't been updated in a year, no idea about this one

Sean

On Sun, Jun 30, 2013 at 4:44 PM, David Pollak  wrote:
> Folks,
>
> Is there an offline package of Clojure docs (the full core.* api docs, cheat
> sheets, etc.)?
>
> I'm traveling with intermittent Internet connectivity (I'm in China now and
> it's marginal but I'm going to the UP in Michigan where there's no Internet
> within 15 miles of where I'm staying).
>
> With all the travel and flying and such, it'd be great to have all the docs
> without having to clone all the various source repositories.
>
> Thanks for your help.
>
> David
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



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

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

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

Re: Microsoft Rx -style operations with core.async

[David Nolen]

Because of blocking on read/write on unbuffered channels - users might need
more flexibility.


On Sun, Jun 30, 2013 at 8:13 PM, Brandon Bloom wrote:

> > My understanding with some member of the core.async team is that most
> channel based APIs fns should *take* a channel and only construct one as a
> default.
>
> Could you elaborate on and motivate that?
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Microsoft Rx -style operations with core.async

[Brandon Bloom]

> My understanding with some member of the core.async team is that most
channel based APIs fns should *take* a channel and only construct one as a
default.

Could you elaborate on and motivate that?

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

Re: core.async

[Sean Corfield]

On Sun, Jun 30, 2013 at 4:42 PM, David Pollak  wrote:
> Looking forward to it
> being published (even as SNAPSHOT) in a Maven repo.

It's accessible like this:

(defproject async "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME";
  :license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
  :repositories {"sonatype-oss-public"
"https://oss.sonatype.org/content/groups/public/"}
  :dependencies [[org.clojure/clojure "1.5.1"]
 [org.clojure/core.async "0.1.0-SNAPSHOT"]])
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

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

Re: Microsoft Rx -style operations with core.async

[David Nolen]

On Sun, Jun 30, 2013 at 7:46 PM, Brandon Bloom wrote:

> Two bits of core.async feedback:
>
> 1) The (let [c chan] (go ...) c) pattern is *extremely-common*. Might be
> nice to have something like (go-as c ...) that expands to that pattern.
>

My understanding with some member of the core.async team is that most
channel based APIs fns should *take* a channel and only construct one as a
default.

Awesome stuff by the way doing Rx over core.async

David

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

Re: Microsoft Rx -style operations with core.async

[Ben Wolfson]

On Sun, Jun 30, 2013 at 4:46 PM, Brandon Bloom wrote:

>
> 2) It's somewhat annoying to always have to consider boolean false all the
> time. Since nil signifies a closed channel, if, when, if-let, and when-let
> are extremely convenient. Unfortunately, they are subtly bugged! You need
> nil? checks everywhere, cluttering up relatively nice code.
>
> Since nil-as-closed also has the consequence that you can't send nil over
channels, one way around this would be to uniformly give everything sent a
wrapper indicating that there's something inside; on the receiving end, you
could have a macro or function to test whether the received item was nil or
wrapped and take one branch in the former case and transparently remove the
wrapper and proceed with the inner value in the other branch in the latter.
Er, and that relates to the beginning of the sentence because then you
could also send nil over the channels, if you wanted to.

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

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

Re: Offline Clojure docs

[guns]

On Mon  1 Jul 2013 at 07:44:17AM +0800, David Pollak wrote:

> Is there an offline package of Clojure docs (the full core.* api docs,
> cheat sheets, etc.)?

If you work with an editor with clojure REPL integration, you can
fashion your own cheat sheet.

I have a vim command that dumps a list of all public vars with arglists
(filtered by an optional pattern) into a scratch buffer like this:

;;; clojure.core {{{1

clojure.core/*1
clojure.core/*2
clojure.core/*3
…
clojure.core/xml-seq  [root]
clojure.core/zero?[x]
clojure.core/zipmap   [keys vals]

;;; clojure.core.protocols {{{1

…

Then I use the REPL commands in the buffer to look up docs, source, and
search vars with the editor. It's quite handy, and always up to date.

The funny {{{1 bits are fold markers that allow code folding by
namespace. A cheat sheet in org-mode format would be pretty nice for
emacs.

My apologies if you've already considered this. If you haven't, I hope
you find the suggestion useful.

guns

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

Re: Microsoft Rx -style operations with core.async

[David Pollak]

On Mon, Jul 1, 2013 at 7:46 AM, Brandon Bloom wrote:

> Two bits of core.async feedback:
>
> 1) The (let [c chan] (go ...) c) pattern is *extremely-common*. Might be
> nice to have something like (go-as c ...) that expands to that pattern.
>
> 2) It's somewhat annoying to always have to consider boolean false all the
> time. Since nil signifies a closed channel, if, when, if-let, and when-let
> are extremely convenient. Unfortunately, they are subtly bugged! You need
> nil? checks everywhere, cluttering up relatively nice code.
>

It'd be really nice to have a "closed" token that one could construct a
channel with so the token could be at the app level... although I guess
this wouldn't deal with the if-let/when-let issue.


>
>
> On Sun, Jun 30, 2013 at 5:27 PM, Brandon Bloom 
> wrote:
>
>> Hi all,
>>
>> Today, primarily for my own edification, I've been implementing as many
>> Microsoft Reactive Extensions operators as I can using core.async. The
>> results have been *spectacular*. core.async is an absolute pleasure to work
>> with. I'm so happy with how they have turned out, that I really want to
>> share.
>>
>> You can find my work-in-progress here:
>> https://github.com/brandonbloom/asyncx
>>
>> The primary file of interest is:
>> https://github.com/brandonbloom/asyncx/blob/master/src/asyncx/core.clj
>>
>> At the time of this message, I've implemented the bulk of the relevant
>> operators described here:
>> http://msdn.microsoft.com/en-us/library/hh242961(v=vs.103).aspx
>>
>> All of my implementations utilize parking operations, so this library
>> should be fully portable to ClojureScript.
>>
>> My notes describe any difference from Rx, notable omissions, and known
>> issues:
>> https://github.com/brandonbloom/asyncx/blob/master/notes
>> I'll probably work more on this tonight and will update my notes as I go.
>>
>> Rich & team: I understand that you guys will probably take a run at
>> implementing this sort of library in the not too distant future. Please let
>> me know if and how I can contribute to that effort.
>>
>> Cheers,
>> Brandon
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> 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/L4nEVho555k/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Microsoft Rx -style operations with core.async

[Brandon Bloom]

Two bits of core.async feedback:

1) The (let [c chan] (go ...) c) pattern is *extremely-common*. Might be
nice to have something like (go-as c ...) that expands to that pattern.

2) It's somewhat annoying to always have to consider boolean false all the
time. Since nil signifies a closed channel, if, when, if-let, and when-let
are extremely convenient. Unfortunately, they are subtly bugged! You need
nil? checks everywhere, cluttering up relatively nice code.


On Sun, Jun 30, 2013 at 5:27 PM, Brandon Bloom wrote:

> Hi all,
>
> Today, primarily for my own edification, I've been implementing as many
> Microsoft Reactive Extensions operators as I can using core.async. The
> results have been *spectacular*. core.async is an absolute pleasure to work
> with. I'm so happy with how they have turned out, that I really want to
> share.
>
> You can find my work-in-progress here:
> https://github.com/brandonbloom/asyncx
>
> The primary file of interest is:
> https://github.com/brandonbloom/asyncx/blob/master/src/asyncx/core.clj
>
> At the time of this message, I've implemented the bulk of the relevant
> operators described here:
> http://msdn.microsoft.com/en-us/library/hh242961(v=vs.103).aspx
>
> All of my implementations utilize parking operations, so this library
> should be fully portable to ClojureScript.
>
> My notes describe any difference from Rx, notable omissions, and known
> issues:
> https://github.com/brandonbloom/asyncx/blob/master/notes
> I'll probably work more on this tonight and will update my notes as I go.
>
> Rich & team: I understand that you guys will probably take a run at
> implementing this sort of library in the not too distant future. Please let
> me know if and how I can contribute to that effort.
>
> Cheers,
> Brandon
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/L4nEVho555k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: ANN: faster zipper implementation

[Zach Tellman]

This is really cool, thanks for doing this.  I was able to eke out another 
1.8x speedup by replacing '=' with 'identical?' for the keyword comparisons 
[1]. There also might be further room for improvement by defining inline 
forms for some of the smaller functions.

Zach

[1] 
https://github.com/ztellman/fast-zip/commit/ee7a64630389f36a539771658586a093369f7939

On Sunday, June 30, 2013 1:18:05 PM UTC-7, Alexander Hudek wrote:
>
> I've updated the clojure.zip implementation to use records internally. This
> achieves a speedup of roughly 2x. You can find the library below and on
> clojars:
>
> https://github.com/akhudek/fast-zip
>
> It's a drop in replacement for clojure.zip in terms of interface and 
> usage. 
> However, since the internal representation has changed, fast-zip locations 
> cannot be used with the clojure.zip implementation. E.g. you cannot
> create a zipper with fast-zip, then use clojure.zip/next on the result. 
> You 
> must use fast.zip.core/next instead. 
>
> In addition to the micro-benchmark provided, I've tried this in a larger 
> project
> that makes extensive use of zippers and found a similar speedup.
>
> Comments and suggestions welcome.
>
> Alex
>

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

Offline Clojure docs

[David Pollak]

Folks,

Is there an offline package of Clojure docs (the full core.* api docs,
cheat sheets, etc.)?

I'm traveling with intermittent Internet connectivity (I'm in China now and
it's marginal but I'm going to the UP in Michigan where there's no Internet
within 15 miles of where I'm staying).

With all the travel and flying and such, it'd be great to have all the docs
without having to clone all the various source repositories.

Thanks for your help.

David

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

Re: ANN: faster zipper implementation

[Zach Tellman]

This is really cool, thanks for taking the time to do this.  I was able to 
eke out another 1.8x speedup by changing the keyword equality checks with 
'identical?' [1], and there might be some further room for improvement by 
defining inline forms for some of the smaller functions.

Zach

[1] 
https://github.com/ztellman/fast-zip/commit/ee7a64630389f36a539771658586a093369f7939

On Sunday, June 30, 2013 1:18:05 PM UTC-7, Alexander Hudek wrote:
>
> I've updated the clojure.zip implementation to use records internally. This
> achieves a speedup of roughly 2x. You can find the library below and on
> clojars:
>
> https://github.com/akhudek/fast-zip
>
> It's a drop in replacement for clojure.zip in terms of interface and 
> usage. 
> However, since the internal representation has changed, fast-zip locations 
> cannot be used with the clojure.zip implementation. E.g. you cannot
> create a zipper with fast-zip, then use clojure.zip/next on the result. 
> You 
> must use fast.zip.core/next instead. 
>
> In addition to the micro-benchmark provided, I've tried this in a larger 
> project
> that makes extensive use of zippers and found a similar speedup.
>
> Comments and suggestions welcome.
>
> Alex
>

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

Re: core.async

[David Pollak]

On Sun, Jun 30, 2013 at 3:00 AM, Brandon Bloom wrote:

> I don't think it's published to a maven repository yet. You can check it
> out, install it with `lein install`, then depend on it via [core.async
> "0.1.0-SNAPSHOT"]
>


Thanks!

I flew over to China (from SFO) and played with core.async on the way over.

OMG... it's just totally amazing... both at the conceptual level and at the
execution level (okay, I haven't instrumented it, but some of the basic
games I've been playing with it have been spectacular.)

I've thrown a challenge to the Lift community to build something like it in
Scala while I am traveling in July... but I think in a language without
full macro support, it will be very difficult. The original (now dead)
Scala Actor implementation tried to do continuations (which is what you
need to make 'go' work without blocking a thread while waiting on
channels), but failed in the execution (lots of exceptions for flow of
control, lots of nasty limitations that were not compiler enforced... and
when you're dealing with a statically typed language, the compiler should
enforce the rules).

Anyway, the core.async stuff is really, really nice. Hats off and a huge
"way to go, dudes!" to the team that made it happen. Looking forward to it
being published (even as SNAPSHOT) in a Maven repo.

Rock on!


>
>
> On Sat, Jun 29, 2013 at 2:50 PM, David Pollak wrote:
>
>> What's the entry in project.clj to use the core.async stuff?
>>
>> Thanks!
>>
>>
>> On Sat, Jun 29, 2013 at 9:44 AM, Joseph Smith wrote:
>>
>>> It seems to me that the Clojure space suffers from an unusual malady:
>>> it's busy sitting here quietly advancing half of applied computer science,
>>> and no one seems to notice the full extent of its import.
>>>
>>> And it makes me sound like a broken record with my colleagues: "Oh!
>>> Clojure has..."
>>>
>>>
>>>
>>>---
>>> Joseph Smith
>>> @solussd
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Jun 29, 2013, at 6:07 AM, Peter Taoussanis 
>>> wrote:
>>>
>>> Oh man, how is everyone _not_ running around screaming about this right
>>> now?
>>>
>>> It seems to me that the Clojure space suffers from an unusual malady:
>>> it's busy sitting here quietly advancing half of applied computer science,
>>> and no one seems to notice the full extent of its import.
>>>
>>> Man, I'm sometimes forced to just stop for a moment and sit in awe at
>>> how lucky I've been to see this stuff develop and to get to use it.
>>>
>>> Clojure was huge. And before we're close to digesting its potential,
>>> there's protocols. And Clojurescript. Then Datomic. Reducers. Now this.
>>>
>>> And it's not about everything being necessarily _novel_, though there is
>>> often novelty. For me it's largely about the cohesiveness of the design and
>>> the consistency of the overarching vision. Everything _fits_. I feel like
>>> I'm using tools and ideas that weren't just developed with care, or
>>> cleverness, or experience, but all of those things in a kind of harmony
>>> that's vanishingly rare to find in any field.
>>>
>>> I honestly feel like I'm witnessing history being made.
>>>
>>> Thank you Rich Hickey, and everyone else in this community for making my
>>> work every day so enjoyable.
>>>
>>> - Peter Taoussanis
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>>
>>>  --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from ne

Re: Microsoft Rx -style operations with core.async

[Brandon Bloom]

> I don't know the semantics of the MS functions so maybe this mirrors them

This code is not an attempt to replicate the semantics of Rx, just provide
a comparable set of operators.

> the implementations of take-while and drop-while remove an "extra"
element from the argument channel, right?

Yes. All of these operations inherently consume values from channels. Your
c variable is no longer usable once you've given it out to a consumer that
expects exclusive access.

Channels and Push Sequences are different in many ways. In particular,
callback-based push sequences can have multiple subscribers. That's why
there are no fan-out operations listed on that Msft reference page: All
subscription can implicitly fan out.

I've only thought briefly about this, but there are potentially many
different strategies for fan out (eg
buffering/blocking/dropping/sliding).It's not yet obvious to me what the
various higher level operators should look like (or be called). I'm open to
suggestions. I also haven't studied the design space from the Golang
perspective yet either. Maybe that community has some good 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/groups/opt_out.

Re: Microsoft Rx -style operations with core.async

[Ben Wolfson]

I don't know the semantics of the MS functions so maybe this mirrors them,
but the implementations of take-while and drop-while remove an "extra"
element from the argument channel, right?

user> (def c (chan))
#'user/c
user> (go (doseq [i (range 10)] (>! c i)))
#
user> (def d (take-while even? c))
#'user/d
user> ( (wrote:

> Hi all,
>
> Today, primarily for my own edification, I've been implementing as many
> Microsoft Reactive Extensions operators as I can using core.async. The
> results have been *spectacular*. core.async is an absolute pleasure to work
> with. I'm so happy with how they have turned out, that I really want to
> share.
>
> You can find my work-in-progress here:
> https://github.com/brandonbloom/asyncx
>
> The primary file of interest is:
> https://github.com/brandonbloom/asyncx/blob/master/src/asyncx/core.clj
>
> At the time of this message, I've implemented the bulk of the relevant
> operators described here:
> http://msdn.microsoft.com/en-us/library/hh242961(v=vs.103).aspx
>
> All of my implementations utilize parking operations, so this library
> should be fully portable to ClojureScript.
>
> My notes describe any difference from Rx, notable omissions, and known
> issues:
> https://github.com/brandonbloom/asyncx/blob/master/notes
> I'll probably work more on this tonight and will update my notes as I go.
>
> Rich & team: I understand that you guys will probably take a run at
> implementing this sort of library in the not too distant future. Please let
> me know if and how I can contribute to that effort.
>
> Cheers,
> Brandon
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

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

core.async implemented on top of Pulsar

[pron]

Hi.
So I wanted to see how easy it would be to implement core.async on top of 
Pulsar. It turned out to be quite trivial, but the exercise shows the 
different approaches of the two projects.

First, Pulsar  is the Clojure API to 
Quasar , which, in turn, is a new 
concurrency framework for the JVM (introduced 
here
). 
At its heart it is an implementation of true lightweight threads (fibers) 
on the JVM. Fibers are created by instrumenting the bytecode of selected 
methods, turning them into continuations and running them in a 
ForkJoinPool. Then, Quasar/Pulsar provide communication mechanism in the 
form of Go-like channels and dataflow variables. The last layer is 
Erlang-like actors, complete with selective receive plus other OTP goodies 
like gen-server, supervisors and more. We are currently working on version 
0.2, which we will hopefully release at the end of the week, whose main 
feature is clustering (channels and actors can communicate over the 
network).

Anyway, this is the core.async implementation on top of 
Pulsar.
 
I haven't implemented alts yet, because that's the only feature that would 
take more than a couple of lines; I might have the time to do it tomorrow. 
core.async turns Clojure expressions into continuations at the Clojure 
level, while Pulsar works at the bytecode level, so this alone has a few 
consequences. First, the Pulsar implementation can't run ClojureScript. 
Second, several limitations put in place by core.async become unnecessary, 
first and foremost is the distinction between ! and >!!. 
In the Pulsar implementation you can use either the bang or the double-bang 
form inside or outside a go block. It makes no difference. 

Then, we have the channels. Pulsar's channels are lock-free, and are 
single-consumer by default. It seems to me that channels should be 
single-consumer, but I'd like to hear other opinions on the matter. Making 
channels single-consumer not only saves a couple of CASs, it also opens the 
door to some operations that would require locks without this assumption 
(though, just to be sure, the channels in our core.async implementation are 
all multi-producer multi-consumer; I'm just not sure that's the right 
choice). Multiple consumers are also a problem when it comes to 
distributing channels over the network (for now, only our single-consumer 
channels can be distributed).

Distribution brings us to alts. While easy to implement with Quasar/Pulsar 
on a single machine, I'm not sure how easily they can be distributed. If 
you have an alt possibly sending a message to one of two distributed 
queues, it will require quite a few roundtrips, and possibly even a 
consensus protocol (though maybe not) to make sure the message is sent to 
one, and only one channel. Not any better is the problem on waiting on 
several distributed channels - that requires a distributed transaction.

One of the things I like most about Quasar/Pulsar is how synchronization is 
carried out at the fiber level. Because fibers run in a FJPool, true 
thread-blocking locks are a no-no (they can wreak havoc on FJ). But Quasar 
abstracts threads and fibers into something called "strands"; a strand is 
simply a fiber or a thread. This gives a single, identical API, for dealing 
with both fibers and threads. As a result, converting 
thread-synchronization constructs to such that can work with both fibers 
and threads is almost automatic. When a thread parks, it actually parks, 
but when a fiber parks it is simply descheduled off the FJPool, and when it 
"unparks" it is re-forked on the pool and continues right where it left off.

We have big plans for Quasar/Pulsar, but I don't want to spoil all the 
surprises. I'd love to hear some feedback.

Ron

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

Microsoft Rx -style operations with core.async

[Brandon Bloom]

Hi all,

Today, primarily for my own edification, I've been implementing as many 
Microsoft Reactive Extensions operators as I can using core.async. The 
results have been *spectacular*. core.async is an absolute pleasure to work 
with. I'm so happy with how they have turned out, that I really want to 
share.

You can find my work-in-progress here:
https://github.com/brandonbloom/asyncx

The primary file of interest is:
https://github.com/brandonbloom/asyncx/blob/master/src/asyncx/core.clj

At the time of this message, I've implemented the bulk of the relevant 
operators described here:
http://msdn.microsoft.com/en-us/library/hh242961(v=vs.103).aspx

All of my implementations utilize parking operations, so this library 
should be fully portable to ClojureScript.

My notes describe any difference from Rx, notable omissions, and known 
issues:
https://github.com/brandonbloom/asyncx/blob/master/notes
I'll probably work more on this tonight and will update my notes as I go.

Rich & team: I understand that you guys will probably take a run at 
implementing this sort of library in the not too distant future. Please let 
me know if and how I can contribute to that effort.

Cheers,
Brandon

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

ANN: faster zipper implementation

[Alexander Hudek]

I've updated the clojure.zip implementation to use records internally. This
achieves a speedup of roughly 2x. You can find the library below and on
clojars:

https://github.com/akhudek/fast-zip

It's a drop in replacement for clojure.zip in terms of interface and usage. 
However, since the internal representation has changed, fast-zip locations 
cannot be used with the clojure.zip implementation. E.g. you cannot
create a zipper with fast-zip, then use clojure.zip/next on the result. You 
must use fast.zip.core/next instead. 

In addition to the micro-benchmark provided, I've tried this in a larger 
project
that makes extensive use of zippers and found a similar speedup.

Comments and suggestions welcome.

Alex

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

Re: Translating simple path finding problem from prolog to core.logic

[Norman Richards]

Just like the prolog, you are generating an infinite number of solutions.
 run* will try and give you all of them.  You can use clojure's lazy seq
operations (first, take, etc...) or just ask for however many you want:

> (run 10 [q] (path2 1 7 q))

((1 4 3 7)


 (1 2 4 3 7)


 (1 4 5 7)


 (1 2 4 5 7)


 (1 4 3 6 5 7)


 (1 2 4 3 6 5 7)


 (1 4 5 6 5 7)


 (1 2 4 5 6 5 7)


 (1 4 3 7 5 7)


 (1 2 4 3 7 5 7))

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

Re: core.logic: question on ordering in conjunction

[Norman Richards]

On Sun, Jun 30, 2013 at 12:58 PM, Steven Devijver wrote:

> How does one recognize a relational or non-relational goal?



If you are using anything that doesn't decompose down to the core
relational operators, like == and conde, you are likely non-relational.  In
this case, you are asking questions like "is this value ground" which is
clearly a stateful question about where you are in the search.  (what you
are doing is very similar to core.logic's project, and if you search for
that you'll probably find some discussion of the issues)

As a general rule, if you can change the order of your goals and get
different answers, you are probably doing something non-relational.  That
doesn't mean to are doing something wrong - it just means you are going
beyond the pure relational model and are potentially more constrained in
how you can express your problem.  (in this case, being order dependant)

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

Re: core.logic: question on ordering in conjunction

[Steven Devijver]

How does one recognize a relational or non-relational goal?

Thanks for the fd example.

On Sunday, June 30, 2013 7:34:58 PM UTC+2, Norman Richards wrote:
>
> What you are trying to do is non-relational, and will only work when you 
> put the non-relational pluso at the end.  
>
> You can obviously use the finite domain extensions to core.logic to 
> accomplish this:
>
> (defn fd-pluso [t1 t2 s]
>   (fd/eq (= s (+ t1 t2
>
> (run* [q]
>   (fresh [a]
> (fd/in q a (fd/interval Integer/MAX_VALUE))
> (fd-pluso q 4 a)
> (== a 7)))
>
> => (3)
>
> I don't know how you achieve this result in core.logic without the finite 
> domain support.
>  

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

Re: core.logic: question on ordering in conjunction

[Norman Richards]

What you are trying to do is non-relational, and will only work when you
put the non-relational pluso at the end.

You can obviously use the finite domain extensions to core.logic to
accomplish this:

(defn fd-pluso [t1 t2 s]
  (fd/eq (= s (+ t1 t2

(run* [q]
  (fresh [a]
(fd/in q a (fd/interval Integer/MAX_VALUE))
(fd-pluso q 4 a)
(== a 7)))

=> (3)

I don't know how you achieve this result in core.logic without the finite
domain support.

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

core.logic: question on ordering in conjunction

[Steven Devijver]

I wrote this goal:

(use 'clojure.core.logic)
(use 'clojure.core.logic.protocols)
 
(defn pluso [t1 t2 s]
  (fn goal [a]
(let [args (map (partial walk a) [t1 t2 s])
  fresh? (map lvar? args)
  ground? (map not fresh?)
  [t1 t2 s] args]
  (cond
(= [true  true  true ] ground?) (if (= s (+ t1 t2)) a nil)
(= [true  true  false] ground?) (unify a s  (+ t1 t2))
(= [true  false true ] ground?) (unify a t2 (- s t1))
(= [false true  true ] ground?) (unify a t1 (- s t2))
:else 
a ;; Returning the substitution map will mark this goal as successful
  ;; while it is neither successful nor failed. The fresh variables
  ;; might be ground later.



When I run this query I get (_0) while I'm expecting (3). The root of the 
problem is the returning of the substitution map if more than one variable 
is not ground.

(run* [q] 
  (fresh [a] 
(pluso q 4 a)
(== a 7)))


I've tried returning a choice but this leads to an endless loop.

Is it at all possible to somehow adapt the goal to await the grounding of 
the a-variable? What if the fresh variables are never ground?

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

Translating simple path finding problem from prolog to core.logic

[Craig Ching]

Hello fellow logicians!

I'm trying to translate the following prolog problem to core.logic:

>From http://tjeyamy.blogspot.com/2011/02/path-finding-in-prolog.html


edge(1,2).
edge(1,4).
edge(2,4).
edge(3,6).
edge(3,7).
edge(4,3).
edge(4,5).
edge(5,6).
edge(5,7).
edge(6,5).
edge(7,5).
edge(8,6).
edge(8,7).

path(X,Y,[X,Y]):- edge(X,Y).
path(X,Y,[X|Xs]):- edge(X,W), path(W,Y,Xs).

path(1, 7, P).

%Results
Z = [1, 2, 4, 3, 6, 5, 7];
Z = [1, 2, 4, 3, 6, 5, 6, 5, 7];


Here are a couple of my own attempts using core.logic:

(defrel edge x y)

(fact edge 1 2)
(fact edge 1 4)
(fact edge 2 4)
(fact edge 3 6)
(fact edge 3 7)
(fact edge 4 3)
(fact edge 4 5)
(fact edge 5 6)
(fact edge 5 7)
(fact edge 6 5)
(fact edge 7 5)
(fact edge 8 6)
(fact edge 8 7)

(defn path2 [x y p]
  (conde
   [(fresh []
   (conso x [y] p)
   (edge x y))]
   [(fresh [w r]
   (conso x r p)
   (edge x w)
   (path2 w y r))]))

(defne path3 [x y p]
  ([ x y [x . [y] ] ]
 (edge x y))
  ([ x y [x . r] ]
 (fresh [w]
(edge x w)
(path3 w y r

Hopefully I've understood enough that path3 is just the pattern matching 
version of path2 ;-)  What happens, though, is that both of these end up in 
an infinite loop.  Any hints about what I'm doing wrong?  I'm sure I'm 
missing something fundamental here.  Is there some sort of debugging I can 
do to figure this out?  Or some way to trace execution?

Thanks for any help!

Cheers,
Craig

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

Re: Help deciphering ArityException message

[Dave Kincaid]

Thanks, Stefan. That sounds like good advice.

Dave

On Sunday, June 30, 2013 5:09:23 AM UTC-5, Stefan Kamphausen wrote:
>
> Just a little hint which may help you in the future.
>
> First, note the trailing $fn in reformat-headers$fn which tells you, that 
> your problem is with an anonymous function.
>
> Second, you know that there is a second form for anonymous functions which 
> uses fn instead of the reader macro.
>
> Third, fn can take a name for the anonymous function.  That way you get a 
> better pointer in your exception, where the problem originated.
>
>
> Recently, I find myself using the reader macros less, only for functions 
> which are basically just one form which are totally self-explanatory.  The 
> usage of fn has two advantages: it can be nested and the parameters help 
> documenting the expected input.  Using fn with a name yields better 
> exceptions plus serves a documentation purpose by naming what should happen.
>
> Just my ct.
>
>
> Kind regards,
> Stefan
>
>
>

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

clojure on raspberry pi looks decent

[Jim - FooBar();]

Hi all,

I'd just like to report some benchmarks of clojure (jdk1.8-ea) and 
clojure-py(python 2.7.3) on the raspberry pi. JVM startup time is an 
issue and since I don't know python I consider clojure-py a good 
alternative for demonstrating clojure on the pi.


so here we go:

>lein trampoline repl
needs roughly 2 minutes (!!!) when invoked inside a project with :aot & 
:main enabled in the project.clj


>lein repl
needs just under 1 minute to start when not inside a project

>clojurepy
needs roughly 18 seconds to start a bare repl (1/3 of leiningen)


BUT,
as soon as we've got a vm up and running

>(reduce * (range 1N 51)) ;; (! 50)
needs 17ms with python but roughly 4ms with java


For the sake of completeness, the pure Java version of factorial (using 
exactly the same types) needs roughly 2.5ms
by python is so non-existent that even though I can write factorial I 
can't write a proper timing function!!! (fail...)


not bad at all in my opinion... :)
generally, even with leiningen I find that once the vm is up and as long 
as I don't use concurrency, the experience is very  smooth...


now if only there was an editor to support clojure syntax-highlighting...


Jim


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Help deciphering ArityException message

[Stefan Kamphausen]

Just a little hint which may help you in the future.

First, note the trailing $fn in reformat-headers$fn which tells you, that 
your problem is with an anonymous function.

Second, you know that there is a second form for anonymous functions which 
uses fn instead of the reader macro.

Third, fn can take a name for the anonymous function.  That way you get a 
better pointer in your exception, where the problem originated.


Recently, I find myself using the reader macros less, only for functions 
which are basically just one form which are totally self-explanatory.  The 
usage of fn has two advantages: it can be nested and the parameters help 
documenting the expected input.  Using fn with a name yields better 
exceptions plus serves a documentation purpose by naming what should happen.

Just my ct.


Kind regards,
Stefan


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

Re: What the hell is this???

[Devin Walters]

Context would help.

On Jun 30, 2013, at 12:46 AM, Cedric Greevey  wrote:

> I'm not sure if this is a bug in clooj or in Clojure itself:
> 
> 
> Evaluating file...CompilerException java.lang.ClassFormatError: Unknown 
> constant tag 117 in class file [redacted]/core$eval215, 
> compiling:(NO_SOURCE_PATH:156:1034) 
> 
> 
> What *is* certain is that nothing I type into the source code should be able 
> to cause ClassFormatError. So the bug isn't mine.
> 
> Now, someone tell me how to fix it.
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

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

What the hell is this???

[Cedric Greevey]

I'm not sure if this is a bug in clooj or in Clojure itself:


Evaluating file...CompilerException java.lang.ClassFormatError: Unknown
constant tag 117 in class file [redacted]/core$eval215,
compiling:(NO_SOURCE_PATH:156:1034)


What *is* certain is that nothing I type into the source code should be
able to cause ClassFormatError. So the bug isn't mine.

Now, someone tell me how to fix it.

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

Re: Suggested 'server' for hosting clojure web app

[Philip Potter]

The app server and process monitoring questions have been covered
elsethread. There hasn't been much talk about the static content.

I'd say there are two main strategies available here:

a. set appropriate caching headers on your static pages & use a caching
proxy such as varnish
b. precompile your assets and serve them straight from disk using nginx's
try_files directive

Option a is probably easier to get going with, and for a personal blog
probably good enough. For option b, I'd use sprockets if I were in the ruby
world, but I'm not sure what clojure libraries are in this space.

Phil
On Jun 29, 2013 6:59 PM, "Ravindra Jaju"  wrote:

> Thank you Daniel and James. I appreciate the detailed response and advice.
>
> I'll make myself more clear and specify what I have in mind. I don't want
> hot-deploys, for sure. :) I erred when I mentioned "without restarting" -
> that certainly changes quite a few things!
>
> Here's what I have in mind for my app as well as the deployment design.
> Its main goals are primarily to (1) Get more familiar with clojure dev
> since I enjoy it, (2) host my personal blog (mostly markdown, processed at
> runtime or pre-preprocessed), and (3) some dynamic content.
>
> | nginx | > | static content - markdown, possibly preprocessed -
> with markdown-clj | --> | clojure app for some dynamic content |
>
> I've only started using luminus, and it serves markdown by processing it
> at runtime, which makes my content serving dependent on the app-server. I
> have the option of pre-processing markdown and serving it completely
> statically with nginx. Until then, I'm okay right now using the app to
> serve it.
>
> It is at this point where I need advice. I currently only know of running
> the clojure app via "lein ring server" (or equivalent) from the
> command-line - no scripts which can run it like those init scripts with
> start/stop/reload support. nginx runs fine as a daemon, but I need to
> figure out the java side.
>
> 1] Upstart is good - so, I will need to figure out the equivalent on
> Fedora (which is what I use - primarily because I'm too familiar with it
> and have been an RH/Fedora guy since about ~1995). Essentially, a daemon
> monitor which will restart in case of failures. I've been somewhat rusty
> with the recent releases of all Linux-es from the systems admin point of
> view.
> 2] Is there a suggested way to manage the java process - especially
> starting and stopping? I'm okay with a few seconds of downtime, and I can
> write scripts to do this myself, but don't want to reinvent the wheel if
> there are already some tools/scripts/practices which make it
> straightforward. I'm especially looking for current practices with folks
> who use clojure with jetty/http-kit like servers, and not jboss et al. :)
>
> Best regards,
> jaju
>
>
>
> On Sat, Jun 29, 2013 at 10:36 PM, James Reeves wrote:
>
>> If you just want to deploy your application, and don't particularly care
>> about having control over your system architecture, you might want to
>> consider a platform like Heroku.
>>
>> Otherwise, a common solution, and one I'd personally recommend, is to
>> have a standalone app executed via Upstart, running behind an nginx proxy.
>>
>> Upstart allows you to run a process as a daemon, and it can do useful
>> things like automatically restart a process if it unexpectedly terminates.
>> Upstart is by no means the only program that does this, but it's the one
>> Ubuntu uses and is therefore stable and well-tested.
>>
>> A HTTP proxy server like nginx is useful for buffering against restarts
>> and application failures. You can configure nginx to buffer a request while
>> your server restarts, or to distribute request over a cluster of processes,
>> or to cache static content.
>>
>> You could create the standalone app manually, with a -main function that
>> calls run-jetty, or use the lein-ring plugin and the "lein ring uberjar"
>> command to do it for you.
>>
>> - James
>>
>>
>> On 29 June 2013 15:47, Ravindra Jaju  wrote:
>>
>>> I want to deploy a small web app - serving mostly static content. I'm
>>> using Luminus (http://www.luminusweb.net/) - which is quite neat in the
>>> way it builds itself from well-known components.
>>>
>>> I'm having trouble deciding how to deploy it. I want some automation
>>> while deploying upgrades, and would like it to be light-weight. Jetty,
>>> http-kit, or immutant?
>>> (I tried immutant - but it seems to be taking up too much memory for my
>>> comfort, on my modest server.)
>>>
>>> Jetty and http-kit - I would like to hear about how I can deploy them as
>>> nice system daemons, with monitoring etc. so that they can be brought up
>>> automatically if something goes wrong. I'm also unable to find out how I
>>> can do a re-deploy without restarting.
>>>
>>> Any help or pointers appreciated!
>>>
>>> Thanks,
>>> jaju
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To 

Re: Suggested 'server' for hosting clojure web app

[Philip Potter]

I think systemd will also handle process monitoring. You could also use
runit, which runs in user space so you can use it on any distro.
On Jun 30, 2013 12:15 AM, "Maciej Mazur"  wrote:

> On Sat, 29 Jun 2013 21:31:22 +0100, James Reeves wrote:
>
> > On 29 June 2013 18:59, Ravindra Jaju  wrote:
> >
> >> 1] Upstart is good - so, I will need to figure out the equivalent on
> >> Fedora (which is what I use - primarily because I'm too familiar with
> >> it and have been an RH/Fedora guy since about ~1995). Essentially, a
> >> daemon monitor which will restart in case of failures. I've been
> >> somewhat rusty with the recent releases of all Linux-es from the
> >> systems admin point of view.
> >>
> >>
> > Since Fedora 9, Upstart has been the default on that as well, so you're
> > in luck :)
>
> Actually Upstart has been replaced by systemd since Fedora 15
>
> Maciej Mazur
>
>

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