Re: core.async - extracting code from a go block

[Timothy Baldridge]

A few other things that might help:

1) you can use (put! c val) from inside any function. Sometimes if you want
to fire and forget a send, that might be the best option

2) you can wrap the code inside the sub fns inside another go. This isn't
as slow as you might think

3) think about using core.async's higher order ops like map, filter<, mux,
pub, mix, etc.

Often I've found that by rethinking the problem a bit in therms of these
ideas, it's possible to simplify the go blocks a bit.

Timothy


On Tue, Dec 31, 2013 at 7:14 PM, Cedric Greevey  wrote:

> It should work if it's inlined or a macro. It won't shrink foo's generated
> code size any if bar is a macro, but it will split up the source code into
> smaller pieces if that's all you're concerned about.
>
>
> On Tue, Dec 31, 2013 at 8:50 PM, Paul Butcher wrote:
>
>> I recently discovered that parking calls only work if they're directly
>> contained within a go block. So this works fine:
>>
>> (defn foo [ch]
>>   (go
>> (>
>>
>> But this:
>>
>> (defn bar [ch]
>>   (>
>> (defn foo [ch]
>>   (go
>> (bar ch)))
>>
>>
>> Results in Assert failed: >
>> Is there any way around this? If I have a go block that's getting too big
>> and want to extract some portion of it into a separate function, what's the
>> best approach?
>>
>>  --
>> paul.butcher->msgCount++
>>
>> Silverstone, Brands Hatch, Donington Park...
>> Who says I have a one track mind?
>>
>> http://www.paulbutcher.com/
>> LinkedIn: http://www.linkedin.com/in/paulbutcher
>> Skype: paulrabutcher
>>
>>
>>
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you 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.
>



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

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

Re: ANN - [vinyasa 0.1.0] - Give your clojure workflow more flow

[zcaudate]

I've done a write up of my workflow here:

http://z.caudate.me/give-your-clojure-workflow-more-flow/

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

[zcaudate]

I've been rethinking my clojure workflow and came up with this little 
library, allowing sweet customisations of the clojure.core namespace for 
development purposes:

https://github.com/zcaudate/vinyasa

It has three functions - pull, lein, inject - and their uses are described 
below.


Chris.

-
vinyasa

Give your clojure workflow more flow.
Installation

Add vinyasa to your profile.clj:

{:user {:plugins [...]   
:dependencies [
   [im.chit/vinyasa "0.1.0"]
   ]
}
:injections [...
 (require '[vinyasa.inject :as inj])
 (inj/inject 'clojure.core
   '[[vinyasa.inject inject]
 [vinyasa.pull pull]
 [vinyasa.lein lein]])
 ...]
  }

Usage:

If you are in emacs and are in a clojure project, you can run nrepl-jack-in and 
use the added functionality straight away. If you are running lein repl and 
are in the user namespace, reload the user namespace before using:

> (ns user)> (lein)> (pull hiccup)

pull

How many times have you forgotten a library dependency for project.clj and 
then had to restart your nrepl?pull is a convienient wrapper around the 
pomegranate library:

> (require 'hiccup.core);; => java.io.FileNotFoundException: Could not locate 
> hiccup/core__init.class or hiccup/core.clj on classpath:
> (require 'hiccup.core)> (pull 'hiccup);; => {[org.clojure/clojure "1.2.1"] 
> nil, ;; [hiccup "1.0.4"] #{[org.clojure/clojure "1.2.1"]}}
> (use 'hiccup.core)> (html [:p "hello World"]);; => "hello World"
> (pull 'hiccup "1.0.1");; => {[org.clojure/clojure "1.2.1"] nil, ;; 
> [hiccup "1.0.1"] #{[org.clojure/clojure "1.2.1"]}}

lein

Don't you wish that you had the power of leiningen within the repl itself? 
lein is that entry point. You don't have to open up another terminal window 
anymore, You can now run your commands in the repl!

> (lein);; Leiningen is a tool for working with Clojure projects. Several 
> tasks are available:;; check   Check syntax and warn on 
> reflection.;; classpath   Write the classpath of the current project 
> to output-file.;; clean   Remove all files from paths in 
> project's clean-targets.;; cljsbuild   Compile ClojureScript source 
> into a JavaScript file.  .;;  .
> (lein javac)   ;; Compile java classes
> (lein install) ;; Install to local maven repo
> (lein uberjar) ;; Create a jar-file
> (lein push);; Deploy on clojars I still use lein-clojars 

inject

I find that when I am debugging, there are additional functionality that is 
needed which is not included in clojure.core. The most commonly used 
function is pprint and it is much better if the function came with me when 
I was debugging.

The best place to put all of these functions in in the clojure.core
 namespace inject is used to add additional functionality to namespaces so 
that the functions are there right when I need them. Inject also works with 
macros and functions (unlike intern which only works with functions):

> (inject 'clojure.core '[[clojure.repl dir]]);; => will intern 
> #'clojure.repl/dir to #'clojure.core/dir
> (clojure.core/dir clojure.core);; *;; *';; *1;; *2;; *3;; *agent*;; 
> *allow-unresolved-vars*;; *assert* ...;; ...

inject can also work with multiple entries:

> (inject 'clojure.core '[[clojure.repl doc source]]);; => will create the var 
> #'clojure.core/doc and #'clojure.core/source

inject can also take a prefix:

> (inject 'clojure.core '>> '[[clojure.repl doc source]]);; => will create the 
> var #'clojure.core/>>doc and #'clojure.core/>>source

inject can use vector bindings to directly specify the name

> (inject 'clojure.core '>> '[[clojure.repl doc [source source]]]);; => will 
> create the var #'clojure.core/>>doc and #'clojure.core/source

inject - 
installation

inject allows easy customisation of your clojure.core namespace by allowing 
injecting of the functions that you have always wanted to have in your 
profiles.clj file. Here is an example taken from myprofiles.clj.

{:user {:plugins [...]
:dependencies [[spyscope "0.1.4"]
   [org.clojure/tools.namespace "0.2.4"]
   [io.aviso/pretty "0.1.8"]
   [im.chit/vinyasa "0.1.0"]]
 :injections [(require 'spyscope.core)
  (require 'vinyasa.inject)
  (vinyasa.inject/inject 'clojure.core '>
'[[vinyasa.inject [inject inject]]
  [vinyasa.pull [pull pull

Re: core.async - extracting code from a go block

[Cedric Greevey]

It should work if it's inlined or a macro. It won't shrink foo's generated
code size any if bar is a macro, but it will split up the source code into
smaller pieces if that's all you're concerned about.


On Tue, Dec 31, 2013 at 8:50 PM, Paul Butcher  wrote:

> I recently discovered that parking calls only work if they're directly
> contained within a go block. So this works fine:
>
> (defn foo [ch]
>   (go
> (
>
> But this:
>
> (defn bar [ch]
>   (
> (defn foo [ch]
>   (go
> (bar ch)))
>
>
> Results in Assert failed: 
> Is there any way around this? If I have a go block that's getting too big
> and want to extract some portion of it into a separate function, what's the
> best approach?
>
> --
> paul.butcher->msgCount++
>
> Silverstone, Brands Hatch, Donington Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> Skype: paulrabutcher
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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: core.async - extracting code from a go block

[Luc Prefontaine]

I would say use macros to avoid
hiding calls from the go macro
scope.

Luc P.

> I recently discovered that parking calls only work if they're directly 
> contained within a go block. So this works fine:
> 
> (defn foo [ch]
>   (go
> ( 
> But this:
> 
> (defn bar [ch]
>   ( 
> (defn foo [ch]
>   (go
> (bar ch)))
> 
> Results in Assert failed:  
> Is there any way around this? If I have a go block that's getting too big and 
> want to extract some portion of it into a separate function, what's the best 
> approach?
> 
> --
> paul.butcher->msgCount++
> 
> Silverstone, Brands Hatch, Donington Park...
> Who says I have a one track mind?
> 
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> Skype: paulrabutcher
> 
> 
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you 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.
> 
--
Luc Prefontaine sent by ibisMail!

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

core.async - extracting code from a go block

[Paul Butcher]

I recently discovered that parking calls only work if they're directly 
contained within a go block. So this works fine:

(defn foo [ch]
  (go
(msgCount++

Silverstone, Brands Hatch, Donington Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
Skype: paulrabutcher




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

[Michał Marczyk]

No worries.

Incidentally, akhudek's fast-zip seems to have the same issue. Here's
a PR fixing it:

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

Cheers,
Michał


On 1 January 2014 02:12, Lee Spector  wrote:
>
> On Dec 31, 2013, at 6:53 PM, Michał Marczyk wrote:
>
>> Ticket with patch at
>>
>> http://dev.clojure.org/jira/browse/CLJ-1317
>
> [and]
>> Oh, and of course you can use the amended version now to obtain the
>> expected results: ///
>
>
> Thank you so much Michał!
>
>  -Lee
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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: bug in clojure.zip when calling next on empty list node?

[Lee Spector]

On Dec 31, 2013, at 6:53 PM, Michał Marczyk wrote:

> Ticket with patch at
> 
> http://dev.clojure.org/jira/browse/CLJ-1317

[and]
> Oh, and of course you can use the amended version now to obtain the
> expected results: ///


Thank you so much Michał!

 -Lee

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

[Michał Marczyk]

Oh, and of course you can use the amended version now to obtain the
expected results:

(defn seq-zip
  "Returns a zipper for nested sequences, given a root sequence"
  {:added "1.0"}
  [root]
(zipper seq?
seq
(fn [node children] (with-meta children (meta node)))
root))

As noted in a comment on the ticket, clojure.zip/zipper's documetation
actuals asks that the children argument return a seq of nodes. The
rest of clojure.zip, however, expects nil when there are no children.
One could argue that it is that expectation that needs fixing, but I
think the current behaviour makes sense; perhaps the docstring should
be adjusted, though.

Cheers,
Michał


On 1 January 2014 00:53, Michał Marczyk  wrote:
> Ticket with patch at
>
> http://dev.clojure.org/jira/browse/CLJ-1317
>
> The problem is that seq-zip uses clojure.core/identity as the
> "children" argument to zipper. Applied to (), this returns (), but
> clojure.zip expects the "children" function to return nil when there
> are no children. The patch attached to the ticket above changes
> identity to seq inside seq-zip. This suffices to fix the behaviour
> discovered by Lee.
>
> Cheers,
> Michał
>
>
> On 1 January 2014 00:15, Lee Spector  wrote:
>>
>> On Dec 31, 2013, at 5:08 PM, Armando Blancas wrote:
>>
>>> The implementation of seq-zip uses seq? as its branching predicate. As a 
>>> result the zipper goes down on () thinking it can have children:
>>>
>>> user=> (seq? ())
>>> true
>>> user=> (seq? {})
>>> false
>>> user=> (seq? #{})
>>> false
>>> user=> (seq? [])
>>> false
>>
>> Does that mean that you think that the behavior is correct and expected?
>>
>> It goes down () thinking it can have children -- fine -- but when there 
>> aren't any children shouldn't zip/next continue until it hits the next 
>> thing? Why should it "land" on a non-existent nil instead?
>>
>> Compare:
>>
>> Traversing '((1) 0) with zip/next we get 4 items: ((1) 0), (1), 1, 0
>>
>> Traversing '(() 0) with zip/next we also get 4 items: (() 0), (), nil, 0
>>
>> It seems to me that these shouldn't both give 4 things, since the second 
>> clearly contain one less thing. That alleged nil just isn't there. Note also 
>> that:
>>
>> Traversing '((nil) 0)) with zip/next we also get 4 items: ((nil) 0), (nil), 
>> nil, 0
>>
>> That one seems right to me -- there really IS a nil there this time. But the 
>> one with () doesn't.
>>
>> If I'm alone in this then I guess I'll just write my own zip_really_next 
>> that does what I expect, but I'm curious if others also think that the 
>> current behavior is correct.
>>
>> Thanks,
>>
>>  -Lee
>>
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you 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: bug in clojure.zip when calling next on empty list node?

[Michał Marczyk]

Ticket with patch at

http://dev.clojure.org/jira/browse/CLJ-1317

The problem is that seq-zip uses clojure.core/identity as the
"children" argument to zipper. Applied to (), this returns (), but
clojure.zip expects the "children" function to return nil when there
are no children. The patch attached to the ticket above changes
identity to seq inside seq-zip. This suffices to fix the behaviour
discovered by Lee.

Cheers,
Michał


On 1 January 2014 00:15, Lee Spector  wrote:
>
> On Dec 31, 2013, at 5:08 PM, Armando Blancas wrote:
>
>> The implementation of seq-zip uses seq? as its branching predicate. As a 
>> result the zipper goes down on () thinking it can have children:
>>
>> user=> (seq? ())
>> true
>> user=> (seq? {})
>> false
>> user=> (seq? #{})
>> false
>> user=> (seq? [])
>> false
>
> Does that mean that you think that the behavior is correct and expected?
>
> It goes down () thinking it can have children -- fine -- but when there 
> aren't any children shouldn't zip/next continue until it hits the next thing? 
> Why should it "land" on a non-existent nil instead?
>
> Compare:
>
> Traversing '((1) 0) with zip/next we get 4 items: ((1) 0), (1), 1, 0
>
> Traversing '(() 0) with zip/next we also get 4 items: (() 0), (), nil, 0
>
> It seems to me that these shouldn't both give 4 things, since the second 
> clearly contain one less thing. That alleged nil just isn't there. Note also 
> that:
>
> Traversing '((nil) 0)) with zip/next we also get 4 items: ((nil) 0), (nil), 
> nil, 0
>
> That one seems right to me -- there really IS a nil there this time. But the 
> one with () doesn't.
>
> If I'm alone in this then I guess I'll just write my own zip_really_next that 
> does what I expect, but I'm curious if others also think that the current 
> behavior is correct.
>
> Thanks,
>
>  -Lee
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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: bug in clojure.zip when calling next on empty list node?

[Lee Spector]

On Dec 31, 2013, at 5:08 PM, Armando Blancas wrote:

> The implementation of seq-zip uses seq? as its branching predicate. As a 
> result the zipper goes down on () thinking it can have children:
> 
> user=> (seq? ())
> true
> user=> (seq? {})
> false
> user=> (seq? #{})
> false
> user=> (seq? [])
> false

Does that mean that you think that the behavior is correct and expected?

It goes down () thinking it can have children -- fine -- but when there aren't 
any children shouldn't zip/next continue until it hits the next thing? Why 
should it "land" on a non-existent nil instead?

Compare:

Traversing '((1) 0) with zip/next we get 4 items: ((1) 0), (1), 1, 0

Traversing '(() 0) with zip/next we also get 4 items: (() 0), (), nil, 0

It seems to me that these shouldn't both give 4 things, since the second 
clearly contain one less thing. That alleged nil just isn't there. Note also 
that:

Traversing '((nil) 0)) with zip/next we also get 4 items: ((nil) 0), (nil), 
nil, 0

That one seems right to me -- there really IS a nil there this time. But the 
one with () doesn't.

If I'm alone in this then I guess I'll just write my own zip_really_next that 
does what I expect, but I'm curious if others also think that the current 
behavior is correct.

Thanks,

 -Lee


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

[Gary Trakhman]

"hallucinated interfaces" : I like it :-).

I think of it as 'data shapes', or implicit contracts.  The added
value/cost over explicit types is it's open to interpretation and the
reader's subjectivity.  Let me tell you, when you work with large amounts
of uncommented clojure code, the flexibility afforded by this is as welcome
as it's terrifying, but the 'dbg'[1] macro is a welcome friend.

There are some projects that address making the implicit contracts
explicit, namely Prismatic's "Schema".

https://github.com/Prismatic/schema

[1] :
http://www.learningclojure.com/2010/09/clojure-macro-tutorial-part-i-getting.html


On Tue, Dec 31, 2013 at 5:08 PM, Dennis Haupt  wrote:

> i solved a few little thingy with clojure now, including some euler
> problems, java interop and an asteroids clone.
>
> my summary would be:
> * very nice to write +1. i used clojure's collections for a lot of things,
> and they made a good impression
> * you need to plan far ahead compared to java. in java, it's easy to
> "hack-fix" something if it doesn't work by adding a field somewhere and
> read its value later, or add a parameter to a call hierarchy. i know this
> isn't the way it should be done, but sometimes code quality is irrelevant
> (for example if you are just making some experiments)
> * the effort to modify code is either very low, or very high - in java, it
> was "kind of always the same". in clojure, it seems to depend a lot on the
> existing code.
> * debugging is impossible (or very hard) if you want to debug like you are
> used to do it in java - meaning stop if condition x is true and evaluate
> expressions at that point. i made some mistakes that i would have
> immediately seen in a standard debug session, but i don't know how i could
> have seen it in clojure. i needed to think a lot more or add debug output
> to understand those bugs - like flipping x and y in a grid. so, fixing bugs
> took longer than it takes in java.
> * how do you deal with complex data structures? since i cannot tell what
> the type of a parameter is, it could be anything, including a map with
> unknown content. i can only see which properties of it are immediately
> accessed. is that the trick? to "not care about what you don't care about"?
> and having something like "hallucinated interfaces"?
>
> what are your experiences?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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.

some clojure experience

[Dennis Haupt]

i solved a few little thingy with clojure now, including some euler
problems, java interop and an asteroids clone.

my summary would be:
* very nice to write +1. i used clojure's collections for a lot of things,
and they made a good impression
* you need to plan far ahead compared to java. in java, it's easy to
"hack-fix" something if it doesn't work by adding a field somewhere and
read its value later, or add a parameter to a call hierarchy. i know this
isn't the way it should be done, but sometimes code quality is irrelevant
(for example if you are just making some experiments)
* the effort to modify code is either very low, or very high - in java, it
was "kind of always the same". in clojure, it seems to depend a lot on the
existing code.
* debugging is impossible (or very hard) if you want to debug like you are
used to do it in java - meaning stop if condition x is true and evaluate
expressions at that point. i made some mistakes that i would have
immediately seen in a standard debug session, but i don't know how i could
have seen it in clojure. i needed to think a lot more or add debug output
to understand those bugs - like flipping x and y in a grid. so, fixing bugs
took longer than it takes in java.
* how do you deal with complex data structures? since i cannot tell what
the type of a parameter is, it could be anything, including a map with
unknown content. i can only see which properties of it are immediately
accessed. is that the trick? to "not care about what you don't care about"?
and having something like "hallucinated interfaces"?

what are your experiences?

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

[Armando Blancas]

The implementation of seq-zip uses seq? as its branching predicate. As a 
result the zipper goes down on () thinking it can have children:

user=> (seq? ())
true
user=> (seq? {})
false
user=> (seq? #{})
false
user=> (seq? [])
false

On Sunday, December 29, 2013 10:14:23 AM UTC-8, Lee wrote:
>
>
> I realize that many people are on holiday, but I'm hoping to get some 
> clarity about how to proceed with respect to this issue in the near future. 
>
> Can anyone tell if I'm right that this is a bug in clojure.zip? If so, 
> then is the right thing to do to post an issue on JIRA? 
>
> I've re-included the crux of the issue [slightly edited and recombined] 
> below. 
>
> Thanks, 
>
>  -Lee 
>
>
> On Dec 21, 2013, at 11:49 AM, Lee Spector wrote: 
> > When I step through a zipper made from a nested list via seq-zip, I get 
> extraneous nils after processing a nested (). 
> > 
> > Is this somehow expected behavior, or a bug, or am I misunderstanding 
> something fundamental? 
> > 
> > The problem seems to arise only when an nested empty list is present, 
> not other nested lists [... deleted ...] 
> > 
> > Here's an illustration, stepping through '(() 0) with next and printing 
> the node at each step: 
> > 
> > (loop [z (zip/seq-zip '(() 0))] 
> >  (if (zip/end? z) 
> >:done 
> >(do (println (zip/node z)) 
> >  (recur (zip/next z) 
> > 
> > That produces: 
> > 
> > (() 0) 
> > () 
> > nil 
> > 0 
> > :done 
> > 
> > I don't expect the nil to be there. 
>
> > [That is,] when traversing '(() 0) with zip/next, one should first visit 
> the root, then (), and then 0. But what actually happens is that between 
> then () and the 0 one lands on a non-existent nil node. So one ends up 
> visiting 4 nodes when there are only 3, and the extra one is a nil. 
>
>

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

[Cedric Greevey]

On Tue, Dec 31, 2013 at 9:26 AM, Jakub Holy  wrote:

> I also believe that Rich Hickey has some good reasons for why / when not
> to use actor-based concurrency. I cannot find the reference now, perhaps it
> is mentioned (also) in the StrangeLoop 2013 Clojure core.async 
> Channels
>  talk.
>

Does anyone else think we could use a central, searchable clearinghouse
containing all of the various arguments, rationales, and philosophical
essays underpinning Clojure's design choices in text format? AFAICT a lot
of that stuff is currently scattered hither and thither across the web, and
a lot of it is buried in the audio tracks of videos where search tools
can't find it, and even the videos aren't gathered in one place (e.g. a
Youtube channel) but instead are disseminated all over the place across
dozens of different hosting sites.

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

[Cedric Greevey]

Not really, as the lookups will happen at macroexpansion time and not at
runtime. It should be as efficient as a normal (case ...).


On Tue, Dec 31, 2013 at 7:00 AM, Paul Butcher  wrote:

> On 30 Dec 2013, at 16:34, Cedric Greevey  wrote:
>
> To do it with case, you'd need to wrap case in a macro that expanded to
> `(case ~thingy ~(eval case1) ...) or something along those lines
>
>
> Thanks, but I suspect that that might be another way of saying "use condp"
> :-)
>
> Cheers,
>
> --
> paul.butcher->msgCount++
>
> Silverstone, Brands Hatch, Donington Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> Skype: paulrabutcher
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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: Migrating from nrepl.el to cider

[Gary Trakhman]

I've seen the pprint error on startup often.


On Tue, Dec 31, 2013 at 9:47 AM, mwillson  wrote:

> Folks,
>
> I've recently migrated to cider on two platforms, Mac OS X (Mavericks) and
> Debian Wheezy.  With each, I encountered one issue, but different in each
> case.  If these are worth reporting formally, I'd be happy to do so.
>
> 1. Mac OS X
>
> Once cider was installed, I was unable to use cider-jack-in; it just hung.
>  In the process list was this:
>
> -bin/tcsh -c echo "lein repl :headless" | eval $SHELL -l
>
>
> tcsh is my default emacs shell but It looks like tcsh is not like other
> shells; the invocation of lein is not echo'd to the login shell.  Replacing
> the emacs default shell with /bin/bash solved the problem.
>
> This is probably a rare use-case, but I suppose could affect FreeBSD users.
>
> 2. Debian Wheezy
>
> The java environment is:
>
> OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1~deb7u1)
> OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
>
> This issue manifested itself as an error when issuing cider-jack-in.
>  Intermittently it would generate a stack trace:
>
> java.lang.IllegalAccessError: pp does not exist
>   at clojure.core$refer.doInvoke (core.clj:3849)
>   clojure.lang.RestFn.applyTo (RestFn.java:139)
>   clojure.core$apply.invoke (core.clj:619)
>   clojure.core$load_lib.doInvoke (core.clj:5394)
>   clojure.lang.RestFn.applyTo (RestFn.java:142)
>   clojure.core$apply.invoke (core.clj:619) ...
>
>
> Figuring intermittent issues might be caused by a race between the lein
> repl coming up and the cider environment, I added a short pause to
> cider-init-repl-buffer, just before the requires in nrepl-repl-requires-
> sexp are evaluated:
>
>  defun cider-init-repl-buffer (connection buffer &optional noprompt)
> "Initialize the REPL for CONNECTION in BUFFER.
>   Insert a banner, unless NOPROMPT is non-nil."
> (with-current-buffer buffer
>   (unless (eq major-mode (quote cider-repl-mode))
> (cider-repl-mode))
>   ;; use the same requires by default as clojure.main does
>   (sit-for 1) ; allow lein repl to come up fully?
>   (cider-eval-sync nrepl-repl-requires-sexp)
>   (cider-repl-reset-markers)
>   (unless noprompt
> (cider-repl--insert-banner-and-prompt nrepl-buffer-ns))
>   (cider-remember-clojure-buffer cider-current-clojure-buffer)
>   (current-buffer)))
>
>
> The problem has not recurred (yet).
>
> Anyone else seen similar things?
>
> -mark
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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: Parallel http requests

[Jan Herich]

Maybe it's not exactly what you need, but i did similar thing once - i 
needed to scrape many linked html resources to extract tree data structure, 
each request/parse operation took considerable time - around 2 seconds - i 
was using clj-http/enlive combo (which is actualy Apache HttpClient/ 
TagSoup under the hood). Therefore i needed to parallelize this operations 
as much as possible and clojure pmap function provides exactly that (with 
futures and threads under the hood). Many times i stumbled upon people 
complaining that use of the pmap actually sloves down rather then speeds 
the code, but this is because the coordination overhead for managing 
threads is substantional, so it's probably not useful for tasks where the 
actual mapping function runs very fast, but in my case, the speedup in 
comparison to normal map function was massive - here is the 
codei'm
 talking about.

Dňa utorok, 31. decembra 2013 9:46:53 UTC+1 chinmoy debnath napísal(-a):
>
> I am a newbie in clojure. I need to send multiple http requests in 
> parallel and need to have a call back when response for each request come 
> back. What will be the idiomatic way of doing it in clojure?
> Thanks in advacne
>
>

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

[Timothy Baldridge]

http-kit is great, and here's an example of using it with core.async to
manage the callbacks:
https://github.com/halgari/clojure-conj-2013-core.async-examples/blob/master/src/clojure_conj_talk/core.clj#L361

Timothy


On Tue, Dec 31, 2013 at 7:10 AM, Mikera wrote:

> I'd suggest taking a look at the http-kit client library:
>
> http://http-kit.org/client.html
>
>
> On Tuesday, 31 December 2013 08:46:53 UTC, chinmoy debnath wrote:
>>
>> I am a newbie in clojure. I need to send multiple http requests in
>> parallel and need to have a call back when response for each request come
>> back. What will be the idiomatic way of doing it in clojure?
>> Thanks in advacne
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



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

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

Migrating from nrepl.el to cider

[mwillson]

Folks,

I've recently migrated to cider on two platforms, Mac OS X (Mavericks) and 
Debian Wheezy.  With each, I encountered one issue, but different in each 
case.  If these are worth reporting formally, I'd be happy to do so.

1. Mac OS X

Once cider was installed, I was unable to use cider-jack-in; it just hung. 
 In the process list was this:

-bin/tcsh -c echo "lein repl :headless" | eval $SHELL -l


tcsh is my default emacs shell but It looks like tcsh is not like other 
shells; the invocation of lein is not echo'd to the login shell.  Replacing 
the emacs default shell with /bin/bash solved the problem.

This is probably a rare use-case, but I suppose could affect FreeBSD users.

2. Debian Wheezy

The java environment is:

OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1~deb7u1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

This issue manifested itself as an error when issuing cider-jack-in. 
 Intermittently it would generate a stack trace:

java.lang.IllegalAccessError: pp does not exist
  at clojure.core$refer.doInvoke (core.clj:3849)
  clojure.lang.RestFn.applyTo (RestFn.java:139)
  clojure.core$apply.invoke (core.clj:619)
  clojure.core$load_lib.doInvoke (core.clj:5394)
  clojure.lang.RestFn.applyTo (RestFn.java:142)
  clojure.core$apply.invoke (core.clj:619) ...


Figuring intermittent issues might be caused by a race between the lein 
repl coming up and the cider environment, I added a short pause to 
cider-init-repl-buffer, just before the requires in nrepl-repl-requires-sexp 
are 
evaluated:

 defun cider-init-repl-buffer (connection buffer &optional noprompt)
"Initialize the REPL for CONNECTION in BUFFER.
  Insert a banner, unless NOPROMPT is non-nil."
(with-current-buffer buffer
  (unless (eq major-mode (quote cider-repl-mode))
(cider-repl-mode))
  ;; use the same requires by default as clojure.main does
  (sit-for 1) ; allow lein repl to come up fully?
  (cider-eval-sync nrepl-repl-requires-sexp)
  (cider-repl-reset-markers)
  (unless noprompt
(cider-repl--insert-banner-and-prompt nrepl-buffer-ns))
  (cider-remember-clojure-buffer cider-current-clojure-buffer)
  (current-buffer)))


The problem has not recurred (yet).

Anyone else seen similar things?

-mark

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

[Jakub Holy]

I too have heard that using Akka from Clojure is not so easy, see Distributed 
Actors in 
Clojure(5/2012)
 – a discussion of options for Akka-like stuff in Clojure. Akka is 
great but “interfacing to Akka from Clojure is not 
nice, 
and certainly not idiomatic”. Though there have been some new Akka-Clojure 
libs since that (akka-clojure, 
okku ).

I also believe that Rich Hickey has some good reasons for why / when not to 
use actor-based concurrency. I cannot find the reference now, perhaps it is 
mentioned (also) in the StrangeLoop 2013 Clojure core.async 
Channels
 talk.

On Friday, December 27, 2013 9:54:16 AM UTC+1, Eric Le Goff wrote:
>
>
> Hi,
>
> After a long background with imperative languages such as Java, I recently 
> spent some time learning functionnal programming, starting with Scala. I 
> had the opporrtunity to build a demo project based on the Akka framework.
>
> Now I am starting learning Clojure, and would be curious to know if there 
> was some clojure based framework available which could implement rather 
> similar features to Akka. 
>
> In particular, I would be interested in an implementation of the Actor 
> Model [1]
>
> Thanks.
>
> Eric
>
>
> [1] http://en.wikipedia.org/wiki/Actor_model
>  

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

[Jakub Holy]

Thanks a lot, Mikera and Tim!

I have started looking into Incanter but especially Leiningen sounds as 
something that is good to know better.

Happy new year! 

On Sunday, December 29, 2013 3:53:44 AM UTC+1, Tim Visher wrote:
>
> Leiningen as well. :) 
>
> On Fri, Dec 27, 2013 at 1:53 PM, Jakub Holy 
> > 
> wrote: 
> > Hello, 
> > 
> > I'd like to sharpen my Clojure skill by contributing to an open source 
> > project and getting feedback on my patches from its developers. Can you 
> > recommend a project that would be suitable? Preferably something where 
> there 
> > is plenty of beginner-friendly bugs and in the domain of web or devops. 
> > 
> > Thanks a lot and happy new year! 
> > 
> > 
> > Best regards, Jakub 
> > -- 
> > Forget software. Strive to make an impact, deliver a valuable change. 
> > 
> > (Vær så snill og hjelp meg med å forbedre norsken min – skriftlig og 
> > muntlig. Takk!) 
> > 
> > Jakub Holy 
> > Solutions Engineer | +47 966 23 666 
> > Iterate AS | www.iterate.no 
> > The Lean Software Development Consultancy 
> > - http://theholyjava.wordpress.com/ - 
> > 
> > -- 
> > -- 
> > 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: Parallel http requests

[Mikera]

I'd suggest taking a look at the http-kit client library:

http://http-kit.org/client.html

On Tuesday, 31 December 2013 08:46:53 UTC, chinmoy debnath wrote:
>
> I am a newbie in clojure. I need to send multiple http requests in 
> parallel and need to have a call back when response for each request come 
> back. What will be the idiomatic way of doing it in clojure?
> Thanks in advacne
>
>

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

Deploying Caribou on Openshift

[Leon Talbot]

What would be the simplest way to deploy a Caribou app on openshift?

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

Parallel http requests

[chinmoy debnath]

I am a newbie in clojure. I need to send multiple http requests in parallel 
and need to have a call back when response for each request come back. What 
will be the idiomatic way of doing it in clojure?
Thanks in advacne

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

[John Mastro]

Hi Lee,

> Can anyone tell if I'm right that this is a bug in clojure.zip? If so, then 
> is the right thing to do to post an issue on JIRA?

I don't have any insight regarding whether this is a bug (haven't yet had an 
opportunity to dig into clojure.zip or zippers in general). However, I think 
you're right that opening a ticket on JIRA is the next step.

- John

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

[Paul Butcher]

On 30 Dec 2013, at 16:34, Cedric Greevey  wrote:

> To do it with case, you'd need to wrap case in a macro that expanded to 
> `(case ~thingy ~(eval case1) ...) or something along those lines


Thanks, but I suspect that that might be another way of saying "use condp" :-)

Cheers,

--
paul.butcher->msgCount++

Silverstone, Brands Hatch, Donington Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
Skype: paulrabutcher

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

[Richard Cole]

Nice to see them coming through on ClojureTV channel on youtube. I'm very 
much enjoying the presentations. Thankyou.

regards,

Richard.

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