Re: too circular?

[Dennis Haupt]

thx


2013/8/26 Marshall Bockrath-Vandegrift 

> Dennis Haupt  writes:
>
> > (defn fib-n [n]
> > (let [fib (fn [a b] (cons a (lazy-seq (fib b (+ b a)]
> > (take n (fib 1 1
> >
> > can't i do a recursion here? how can i achieve this without doing an
> > "outer defn"?
>
> You just need to give the anonymous function a name it can use to refer
> to itself for (non-tail) recursion:
>
> (defn fib-n [n]
>   (let [fib (fn fib [a b] (cons a (lazy-seq (fib b (+ b a)]
> (take n (fib 1 1
>
> -Marshall
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: [ANN] nativot 0.1.0 (leiningen plugin) public beta

[Alex Fowler]

Oh right, there is the license hassle. I am going to contact JDotSoft and 
see if it is possible to make it all more friendly!

вторник, 27 августа 2013 г., 4:26:42 UTC+4 пользователь Mikera написал:
>
> JarClassLoader looks cool
>
> Aren't there some pretty severe licensing restrictions though? Looks like 
> it is GPLv3 or commercial license only from the website, which rules it out 
> of most EPL projects I think
>
> On Tuesday, 27 August 2013 03:50:10 UTC+8, Alex Fowler wrote:
>>
>>
>> hi, nativot is a leiningen plugin that is intended to deliver clojurians 
>> from the burden of classpath hells of any flavour.
>>
>> highlights:
>>
>> 1) built upon lein uberjar and jdotsoft jarclassloader
>> 2) makes it possible to deploy clojure application that depend upon any 
>> jar-files, native libraries, binary resources and other goodness
>> 3) you can deploy your application as a single jar, as well as a single 
>> jar with externalized resources. more on this at 
>> http://www.jdotsoft.com/JarClassLoader.php
>> 4) simple
>>
>> notes:
>>
>> 1) still in beta
>> 2) requires active internet connection
>> 3) due to some leiningen project management pecularities, requires some 
>> manual project.clj adjustment, see the description at clojars, or the 
>> description in the next post in this thread
>> 4) creates additional source folders in your project
>> 5) worships the "just put that jar/native/binary nearby and it will be 
>> included" approach instead of the traditional "repeatability" maven-induced 
>> one. USE WITH CARE. the plugin is not intended to replace the repeatability 
>> approach. actually they are better used together.
>>
>>
>> clojars link: https://clojars.org/nativot
>>
>> disclaimer: this is my first plugin for leningen and i am new to clojure, 
>> so take it easy. and thanks to Zach Tellman for kind guidance!
>>
>> any success stories, failure stories, bug reports, ideas on improvement 
>> and such are welcomed.
>>
>>
>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 - handling nils

[Max Penet]

It's a real problem for me too, I also wonder what was the intention behind 
this. I guess there could be a very good reason for this special treatement 
of nils, but I haven't seen it yet. 

I would love to hear about this from people involved in core.async 
development.

On Friday, August 16, 2013 4:44:48 AM UTC+2, Mikera wrote:
>
> Hi all,
>
> I'm experimenting with core.async. Most of it is exceptionally good, but 
> bit I'm finding it *very* inconvenient that nil can't be sent over 
> channels. In particular, you can't pipe arbitrary Clojure sequences through 
> channels (since sequences can contain nils). 
>
> I see this as a pretty big design flaw given the ubiquity of sequences in 
> Clojure code - it appears to imply that you can't easily compose channels 
> with generic sequence-handling code without some pretty ugly special-case 
> handling.
>
> Am I missing something? Is this a real problem for others too? 
>
> If it is a design flaw, can it be fixed before the API gets locked down?
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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] migae-examples: Clojure, servlets, Google App Engine

[Gregg Reynolds]

Hi list,

migae-examples  is a series of
examples demonstrating the use of Clojure to implement servlets for both
standard servlet containers and Google App Engine.  The purpose is not so
much to explain how to code as to show what's going on behind the scenes
with gen-class, the Clojure runtime, and servlet containers.  The examples
start with a minimal Java implementation and progress through use of Ring
and Compojure, to use of GAE.  (The GAE stuff is very minimal at the
moment; a Clojure wrapper for GAE services is under development).  Along
the way they show how to use a Servlet Filter to get interactive repl-like
behavior out of a servlet container.  The focus is on understanding what
happens at compile time and runtime.

The approach is a little different from that of Ring.  Ring uses an
embedded Jetty server to run web apps.  I wanted support for multiple
servlets, filters, use of web.xml, etc. and use of standalone servers.  So
these examples are a sort of record of how to figure out how to do that.
 They might be useful even for people who have been using Ring, if they
have not looked at how it all works under the covers.

The code, with a bunch of explanatory text, is at
https://github.com/greynolds/migae-examples

I also came up with a somewhat perverse hack that supports interactive
development using the GAE dev_appserver.  It's a little twisted but it
works.  See example gae2.

Feedback would be welcome, especially from people who know the gory details
of Clojure.  I made the examples as I was exploring the workings of
servlets and clojure, so some of what I say is based on knowledge but some
is based on inference, so there may be some errors of explanation.

Cheers,

Gregg

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.

stringify an interned function

[Erebus Mons]

Hello,

I am new to clojure, and I am trying to define a function that turns a 
function-name into a string, but I am stuck.

Here is what I tried:

user> (defn some-func []
true)

I am looking for a function stringify that would do the following

user> (stringify some-func)
"some-func"

I can do it with var as long it is not wrapped in a defn-form:

user> (second (clojure.string/split (str (var some-func)) #"/"))

However, if I try to put it into a defn, I get an error:

user> (defn stringify [func]
(second (clojure.string/split (str (var func)) #"/")))
CompilerException java.lang.RuntimeException: Unable to resolve var: func in 
this context, compiling:(/tmp/form-init6959523461952831160.clj:2:37) 

What am I missing here?

Thanks in advance...

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: stringify an interned function

[Jim]

On 27/08/13 10:39, Erebus Mons wrote:

I am looking for a function stringify that would do the following

user> (stringify some-func)
"some-func"


(-> #'some-func
   meta
  :name
  str)

(defn stringify [func]
 (-> func
   var
   meta
  :name
   str))



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: stringify an interned function

[Jim]

On 27/08/13 13:13, Jim wrote:

(defn stringify [func]
 (-> func
   var
   meta
  :name
   str)) 


I'm sorry this won't work...try this:

(defn stringify [fvar]
 (-> fvar
   meta
  :name
   str))

and pass in the var object like this:

(stringify (var some-func))

OR

(stringify #'some-func)

btw, you will only get the name not the namespace it belongs in...

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: stringify an interned function

[Jim]

or convert it to a macro and it should work as you hoped :)

 (defmacro stringify [f]
  `(-> ~f
   var
   meta
  :name
   str))

HTH,

Jim


On 27/08/13 13:26, Jim wrote:

On 27/08/13 13:13, Jim wrote:

(defn stringify [func]
 (-> func
   var
   meta
  :name
   str)) 


I'm sorry this won't work...try this:

(defn stringify [fvar]
 (-> fvar
   meta
  :name
   str))

and pass in the var object like this:

(stringify (var some-func))

OR

(stringify #'some-func)

btw, you will only get the name not the namespace it belongs in...

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: core.async - handling nils

[Timothy Baldridge]

The reason for not allowing nils isn't a complex one, and basically boils
down to the following:

a) to avoid race conditions, we need a single value to signal "the channel
is closed". As mentioned, nil is the obvious choice for this as it matches
lazy seqs and fits well with the rest of clojure:

(when-let [v ( wrote:

> It's a real problem for me too, I also wonder what was the intention
> behind this. I guess there could be a very good reason for this special
> treatement of nils, but I haven't seen it yet.
>
> I would love to hear about this from people involved in core.async
> development.
>
> On Friday, August 16, 2013 4:44:48 AM UTC+2, Mikera wrote:
>>
>> Hi all,
>>
>> I'm experimenting with core.async. Most of it is exceptionally good, but
>> bit I'm finding it *very* inconvenient that nil can't be sent over
>> channels. In particular, you can't pipe arbitrary Clojure sequences through
>> channels (since sequences can contain nils).
>>
>> I see this as a pretty big design flaw given the ubiquity of sequences in
>> Clojure code - it appears to imply that you can't easily compose channels
>> with generic sequence-handling code without some pretty ugly special-case
>> handling.
>>
>> Am I missing something? Is this a real problem for others too?
>>
>> If it is a design flaw, can it be fixed before the API gets locked down?
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: stringify an interned function

[Erebus Mons]

Jim wrote:

> or convert it to a macro and it should work as you hoped :)
> 
>   (defmacro stringify [f]
>`(-> ~f
> var
> meta
>:name
> str))
> 
> HTH,

Cool! That is exactly what I was looking for!

Best,

EM

> 
> Jim
> 
> 
> On 27/08/13 13:26, Jim wrote:
>> On 27/08/13 13:13, Jim wrote:
>>> (defn stringify [func]
>>>  (-> func
>>>var
>>>meta
>>>   :name
>>>str))
>>
>> I'm sorry this won't work...try this:
>>
>> (defn stringify [fvar]
>>  (-> fvar
>>meta
>>   :name
>>str))
>>
>> and pass in the var object like this:
>>
>> (stringify (var some-func))
>>
>> OR
>>
>> (stringify #'some-func)
>>
>> btw, you will only get the name not the namespace it belongs in...
>>
>> 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.

profiler?

[Jay Fields]

What are you all using these days? I've been using YourKit and I'm
fairly happy with it. Just making sure I'm not missing out on some new
hotness.

Cheers, Jay

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: profiler?

[Dennis Haupt]

yep, yourkit


2013/8/27 Jay Fields 

> What are you all using these days? I've been using YourKit and I'm
> fairly happy with it. Just making sure I'm not missing out on some new
> hotness.
>
> Cheers, Jay
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: profiler?

[Jim]

On 27/08/13 15:06, Jay Fields wrote:

What are you all using these days? I've been using YourKit and I'm
fairly happy with it. Just making sure I'm not missing out on some new
hotness.

Cheers, Jay



I used to use JVisualVM and Jconsole but for some reason both stopped 
working when I updated to Java7 u21 or something...



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: profiler?

[Ben Mabey]

On 8/27/13 8:06 AM, Jay Fields wrote:

What are you all using these days? I've been using YourKit and I'm
fairly happy with it. Just making sure I'm not missing out on some new
hotness.

Cheers, Jay

YourKit plus VisualVM in some cases (I'm not as familiar w/YourKit and I 
really like the VisualGC plugin for VisualVM).  For microbenchmarks I 
find criterium to be useful.

-Ben

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 - handling nils

[Mike Anderson]

On 27 August 2013 20:45, Timothy Baldridge  wrote:

> The reason for not allowing nils isn't a complex one, and basically boils
> down to the following:
>
> a) to avoid race conditions, we need a single value to signal "the channel
> is closed". As mentioned, nil is the obvious choice for this as it matches
> lazy seqs and fits well with the rest of clojure:
>
>
Agreed that you want a single sentinel value.

It doesn't match lazy-seqs at all though: lazy seqs can contain nils just
fine. There's a big difference between (next some-lazy-seq) [which could be
nil, indicating an empty sequence] and the actual values in the seq [which
could also be nil but don't indicate the end of the seq].


> (when-let [v (   (process v))
>
> If we chose a different value, this becomes much more ugly:
>
> (let [v (   (when-not (= v :async/closed)
> (process v)))
>
>
This can be solved easily by providing a macro or some other predicate that
knows how to check for the sentinel value correctly. e.g.

(when-more [v ( b) I question if there are any valid uses for putting nil in a channel.
> With all due respect to all who have written here, thus far, every
> complaint about nils and channels boils down to a conversion from seqs to
> channels. This is the wrong way to look at the problem. Channels are
> co-ordination primitives not data structures. Simply because a lazy seq
> looks like a channel, doesn't mean that they should be treated as such.
>
> In all the core.async code I've written I've never had to put a nil in a
> channel, so I'm left with the uncomfortable conclusion that most complaints
> on this subject are contrived. I could be wrong, but I just haven't seen a
> valid use case yet.
>
>
To me it's all about consistency with other Clojure constructs. You can
safely put nils in sequences, vectors, lists, sets etc.. nil is a valid
"value" just like anything else. So why can't you put them in a channel?

Two use cases I have encountered that motivate this:

a) what if you want to send a sequence through a channel? Since nil as a
value represents the empty sequence, you have to put in some extra special
case handling with the current core.async model.

b) what if you want to write generic code to send all the values in an
arbitrary collection through a channel? you would have to wrap/unwrap nils
at either end to make this work currently.

Both of these, I think, are reasonable and common enough use cases that
it's worth supporting them elegantly rather than forcing users to implement
their own nil-wrapping functionality.


> This all being said, there really isn't a technical reason to not allow
> nils, it just simplifies much of the design and that probably translates to
> better performance. So the restriction could be lifted if a rock solid
> reason could be found, but as of yet, I haven't seen it.
>

I don't believe there is any noticeable performance difference between
checking for nil and checking if a value is identical? to some sentinel
value (which would presumably be static, final, immutable and hence very
well optimised by the JVM). In addition, not allowing nils just means you
have to do extra work to wrap/unwrap nils as a user - which is almost
certainly a net loss on overall performance.

Still, I think consistency is more significant than the performance
argument in this case.


>
> Timothy Baldridge
>
>
> On Tue, Aug 27, 2013 at 2:12 AM, Max Penet  wrote:
>
>> It's a real problem for me too, I also wonder what was the intention
>> behind this. I guess there could be a very good reason for this special
>> treatement of nils, but I haven't seen it yet.
>>
>> I would love to hear about this from people involved in core.async
>> development.
>>
>> On Friday, August 16, 2013 4:44:48 AM UTC+2, Mikera wrote:
>>>
>>> Hi all,
>>>
>>> I'm experimenting with core.async. Most of it is exceptionally good, but
>>> bit I'm finding it *very* inconvenient that nil can't be sent over
>>> channels. In particular, you can't pipe arbitrary Clojure sequences through
>>> channels (since sequences can contain nils).
>>>
>>> I see this as a pretty big design flaw given the ubiquity of sequences
>>> in Clojure code - it appears to imply that you can't easily compose
>>> channels with generic sequence-handling code without some pretty ugly
>>> special-case handling.
>>>
>>> Am I missing something? Is this a real problem for others too?
>>>
>>> If it is a design flaw, can it be fixed before the API gets locked down?
>>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from 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 Go

Re: core.async - handling nils

[Timothy Baldridge]

All your arguments come down to this:

"I have an arbitrary seq of things I want to send down a channel". It's
exactly that concept I that I push against. Everything you've mentioned
thus far is a data structure. Channels are not data structures they are
concurrency management primitives, treat them as such and I doubt you'll
ever have a need for nils in a channel.

If we treat channels as ways of co-ordinating concurrent processes, then
nil doesn't have a use case. In every use of channels I've had thus far,
nil is better expressed as an empty collection, false, 0, :tick, or some
other "ground value".

It's these Rx style programming methods that make people think they need
this feature.

Timothy




On Tue, Aug 27, 2013 at 8:51 AM, Mike Anderson  wrote:

> On 27 August 2013 20:45, Timothy Baldridge  wrote:
>
>> The reason for not allowing nils isn't a complex one, and basically boils
>> down to the following:
>>
>> a) to avoid race conditions, we need a single value to signal "the
>> channel is closed". As mentioned, nil is the obvious choice for this as it
>> matches lazy seqs and fits well with the rest of clojure:
>>
>>
> Agreed that you want a single sentinel value.
>
> It doesn't match lazy-seqs at all though: lazy seqs can contain nils just
> fine. There's a big difference between (next some-lazy-seq) [which could be
> nil, indicating an empty sequence] and the actual values in the seq [which
> could also be nil but don't indicate the end of the seq].
>
>
>> (when-let [v (>   (process v))
>>
>> If we chose a different value, this becomes much more ugly:
>>
>> (let [v (>   (when-not (= v :async/closed)
>> (process v)))
>>
>>
> This can be solved easily by providing a macro or some other predicate
> that knows how to check for the sentinel value correctly. e.g.
>
> (when-more [v (   (process v))
>
>
>> b) I question if there are any valid uses for putting nil in a channel.
>> With all due respect to all who have written here, thus far, every
>> complaint about nils and channels boils down to a conversion from seqs to
>> channels. This is the wrong way to look at the problem. Channels are
>> co-ordination primitives not data structures. Simply because a lazy seq
>> looks like a channel, doesn't mean that they should be treated as such.
>>
>>
>> In all the core.async code I've written I've never had to put a nil in a
>> channel, so I'm left with the uncomfortable conclusion that most complaints
>> on this subject are contrived. I could be wrong, but I just haven't seen a
>> valid use case yet.
>>
>>
> To me it's all about consistency with other Clojure constructs. You can
> safely put nils in sequences, vectors, lists, sets etc.. nil is a valid
> "value" just like anything else. So why can't you put them in a channel?
>
> Two use cases I have encountered that motivate this:
>
> a) what if you want to send a sequence through a channel? Since nil as a
> value represents the empty sequence, you have to put in some extra special
> case handling with the current core.async model.
>
> b) what if you want to write generic code to send all the values in an
> arbitrary collection through a channel? you would have to wrap/unwrap nils
> at either end to make this work currently.
>
> Both of these, I think, are reasonable and common enough use cases that
> it's worth supporting them elegantly rather than forcing users to implement
> their own nil-wrapping functionality.
>
>
>> This all being said, there really isn't a technical reason to not allow
>> nils, it just simplifies much of the design and that probably translates to
>> better performance. So the restriction could be lifted if a rock solid
>> reason could be found, but as of yet, I haven't seen it.
>>
>
> I don't believe there is any noticeable performance difference between
> checking for nil and checking if a value is identical? to some sentinel
> value (which would presumably be static, final, immutable and hence very
> well optimised by the JVM). In addition, not allowing nils just means you
> have to do extra work to wrap/unwrap nils as a user - which is almost
> certainly a net loss on overall performance.
>
> Still, I think consistency is more significant than the performance
> argument in this case.
>
>
>>
>> Timothy Baldridge
>>
>>
>> On Tue, Aug 27, 2013 at 2:12 AM, Max Penet  wrote:
>>
>>> It's a real problem for me too, I also wonder what was the intention
>>> behind this. I guess there could be a very good reason for this special
>>> treatement of nils, but I haven't seen it yet.
>>>
>>> I would love to hear about this from people involved in core.async
>>> development.
>>>
>>> On Friday, August 16, 2013 4:44:48 AM UTC+2, Mikera wrote:

 Hi all,

 I'm experimenting with core.async. Most of it is exceptionally good,
 but bit I'm finding it *very* inconvenient that nil can't be sent over
 channels. In particular, you can't pipe arbitrary Clojure sequences through
 channels (since sequences can contain nils).

Re: core.async - handling nils

[David Nolen]

On Tue, Aug 27, 2013 at 10:51 AM, Mike Anderson <
mike.r.anderson...@gmail.com> wrote:

> To me it's all about consistency with other Clojure constructs. You can
> safely put nils in sequences, vectors, lists, sets etc.. nil is a valid
> "value" just like anything else. So why can't you put them in a channel?
>

Channels are *not* data structures nor are they a "place" to put something.


> a) what if you want to send a sequence through a channel? Since nil as a
> value represents the empty sequence, you have to put in some extra special
> case handling with the current core.async model.
>

You're not going to put random sequences into channels. Channels are
conduits for meaningful messages - some well considered coordination
protocol.


> Both of these, I think, are reasonable and common enough use cases that
> it's worth supporting them elegantly rather than forcing users to implement
> their own nil-wrapping functionality.
>

If you're putting arbitrary sequences into a channel and need to wrap nils,
you probably need to redesign your coordination protocol.

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: core.async - handling nils

[Brandon Bloom]

> In every use of channels I've had thus far, nil is better expressed as an
empty collection, false, 0, :tick, or some other "ground value".

I agree completely. But I'll note that you mention false being useful...

If you're writing completely general operators, like map, which are
*sometimes* quite useful, then you have no choice but to do something like
if-recv or explicitly test against nil.

> It's these Rx style programming methods that make people think they need
this feature.

I built my little Rx with channels library (asyncx) without intention to
use it directly, but because I wanted to learn how to work with channels. I
rapidly learned that the techniques are a lot more different than they
look. In particular, it's more difficult to write channel & process
combinators precisely because they are more powerful. However, in practice,
each new reusable channel/process combinator yields more complexity than it
tends to save. I'd rather intentionally choose strictly less powerful
primitives where appropriate and enforce that with encapsulation.

With that in mind, if I ever revisit asyncx, I'll probably define "push
sequences" or "streams" in terms of protocols and deftypes. I'd use
core.async to implement them, but only for the lowest level primitives. I'd
provide ways to get in to or out of the stream subsystem for interop with
channels, but the public interface would take IStream objects.


On Tue, Aug 27, 2013 at 10:58 AM, Timothy Baldridge wrote:

> All your arguments come down to this:
>
> "I have an arbitrary seq of things I want to send down a channel". It's
> exactly that concept I that I push against. Everything you've mentioned
> thus far is a data structure. Channels are not data structures they are
> concurrency management primitives, treat them as such and I doubt you'll
> ever have a need for nils in a channel.
>
> If we treat channels as ways of co-ordinating concurrent processes, then
> nil doesn't have a use case. In every use of channels I've had thus far,
> nil is better expressed as an empty collection, false, 0, :tick, or some
> other "ground value".
>
> It's these Rx style programming methods that make people think they need
> this feature.
>
> Timothy
>
>
>
>
> On Tue, Aug 27, 2013 at 8:51 AM, Mike Anderson <
> mike.r.anderson...@gmail.com> wrote:
>
>> On 27 August 2013 20:45, Timothy Baldridge  wrote:
>>
>>> The reason for not allowing nils isn't a complex one, and basically
>>> boils down to the following:
>>>
>>> a) to avoid race conditions, we need a single value to signal "the
>>> channel is closed". As mentioned, nil is the obvious choice for this as it
>>> matches lazy seqs and fits well with the rest of clojure:
>>>
>>>
>> Agreed that you want a single sentinel value.
>>
>> It doesn't match lazy-seqs at all though: lazy seqs can contain nils just
>> fine. There's a big difference between (next some-lazy-seq) [which could be
>> nil, indicating an empty sequence] and the actual values in the seq [which
>> could also be nil but don't indicate the end of the seq].
>>
>>
>>> (when-let [v (>>   (process v))
>>>
>>> If we chose a different value, this becomes much more ugly:
>>>
>>> (let [v (>>   (when-not (= v :async/closed)
>>> (process v)))
>>>
>>>
>> This can be solved easily by providing a macro or some other predicate
>> that knows how to check for the sentinel value correctly. e.g.
>>
>> (when-more [v (>   (process v))
>>
>>
>>> b) I question if there are any valid uses for putting nil in a channel.
>>> With all due respect to all who have written here, thus far, every
>>> complaint about nils and channels boils down to a conversion from seqs to
>>> channels. This is the wrong way to look at the problem. Channels are
>>> co-ordination primitives not data structures. Simply because a lazy seq
>>> looks like a channel, doesn't mean that they should be treated as such.
>>>
>>>
>>> In all the core.async code I've written I've never had to put a nil in a
>>> channel, so I'm left with the uncomfortable conclusion that most complaints
>>> on this subject are contrived. I could be wrong, but I just haven't seen a
>>> valid use case yet.
>>>
>>>
>> To me it's all about consistency with other Clojure constructs. You can
>> safely put nils in sequences, vectors, lists, sets etc.. nil is a valid
>> "value" just like anything else. So why can't you put them in a channel?
>>
>> Two use cases I have encountered that motivate this:
>>
>> a) what if you want to send a sequence through a channel? Since nil as a
>> value represents the empty sequence, you have to put in some extra special
>> case handling with the current core.async model.
>>
>> b) what if you want to write generic code to send all the values in an
>> arbitrary collection through a channel? you would have to wrap/unwrap nils
>> at either end to make this work currently.
>>
>> Both of these, I think, are reasonable and common enough use cases that
>> it's worth supporting them elegantly rather than forcing users to imp

Re: core.async - handling nils

[Timothy Baldridge]

Right, the use of false is a special case. I'm thinking of a mouse event
stream, may have a button channel that sends true or false based on the
state of the mouse button. Even saying that though, I would probably opt
for :clicked and :unclicked or somethig of that nature.

Timothy


On Tue, Aug 27, 2013 at 9:15 AM, Brandon Bloom wrote:

> > In every use of channels I've had thus far, nil is better expressed as
> an empty collection, false, 0, :tick, or some other "ground value".
>
> I agree completely. But I'll note that you mention false being useful...
>
> If you're writing completely general operators, like map, which are
> *sometimes* quite useful, then you have no choice but to do something like
> if-recv or explicitly test against nil.
>
> > It's these Rx style programming methods that make people think they
> need this feature.
>
> I built my little Rx with channels library (asyncx) without intention to
> use it directly, but because I wanted to learn how to work with channels. I
> rapidly learned that the techniques are a lot more different than they
> look. In particular, it's more difficult to write channel & process
> combinators precisely because they are more powerful. However, in
> practice, each new reusable channel/process combinator yields more
> complexity than it tends to save. I'd rather intentionally choose strictly
> less powerful primitives where appropriate and enforce that with
> encapsulation.
>
> With that in mind, if I ever revisit asyncx, I'll probably define "push
> sequences" or "streams" in terms of protocols and deftypes. I'd use
> core.async to implement them, but only for the lowest level primitives. I'd
> provide ways to get in to or out of the stream subsystem for interop with
> channels, but the public interface would take IStream objects.
>
>
> On Tue, Aug 27, 2013 at 10:58 AM, Timothy Baldridge 
> wrote:
>
>> All your arguments come down to this:
>>
>> "I have an arbitrary seq of things I want to send down a channel". It's
>> exactly that concept I that I push against. Everything you've mentioned
>> thus far is a data structure. Channels are not data structures they are
>> concurrency management primitives, treat them as such and I doubt you'll
>> ever have a need for nils in a channel.
>>
>> If we treat channels as ways of co-ordinating concurrent processes, then
>> nil doesn't have a use case. In every use of channels I've had thus far,
>> nil is better expressed as an empty collection, false, 0, :tick, or some
>> other "ground value".
>>
>> It's these Rx style programming methods that make people think they need
>> this feature.
>>
>> Timothy
>>
>>
>>
>>
>> On Tue, Aug 27, 2013 at 8:51 AM, Mike Anderson <
>> mike.r.anderson...@gmail.com> wrote:
>>
>>> On 27 August 2013 20:45, Timothy Baldridge  wrote:
>>>
 The reason for not allowing nils isn't a complex one, and basically
 boils down to the following:

 a) to avoid race conditions, we need a single value to signal "the
 channel is closed". As mentioned, nil is the obvious choice for this as it
 matches lazy seqs and fits well with the rest of clojure:


>>> Agreed that you want a single sentinel value.
>>>
>>> It doesn't match lazy-seqs at all though: lazy seqs can contain nils
>>> just fine. There's a big difference between (next some-lazy-seq) [which
>>> could be nil, indicating an empty sequence] and the actual values in the
>>> seq [which could also be nil but don't indicate the end of the seq].
>>>
>>>
 (when-let [v (>>>   (process v))

 If we chose a different value, this becomes much more ugly:

 (let [v (>>>   (when-not (= v :async/closed)
 (process v)))


>>> This can be solved easily by providing a macro or some other predicate
>>> that knows how to check for the sentinel value correctly. e.g.
>>>
>>> (when-more [v (>>   (process v))
>>>
>>>
 b) I question if there are any valid uses for putting nil in a channel.
 With all due respect to all who have written here, thus far, every
 complaint about nils and channels boils down to a conversion from seqs to
 channels. This is the wrong way to look at the problem. Channels are
 co-ordination primitives not data structures. Simply because a lazy seq
 looks like a channel, doesn't mean that they should be treated as such.


 In all the core.async code I've written I've never had to put a nil in
 a channel, so I'm left with the uncomfortable conclusion that most
 complaints on this subject are contrived. I could be wrong, but I just
 haven't seen a valid use case yet.


>>> To me it's all about consistency with other Clojure constructs. You can
>>> safely put nils in sequences, vectors, lists, sets etc.. nil is a valid
>>> "value" just like anything else. So why can't you put them in a channel?
>>>
>>> Two use cases I have encountered that motivate this:
>>>
>>> a) what if you want to send a sequence through a channel? Since nil as a
>>> 

Re: core.async - handling nils

[Softaddicts]

+1

We built a distributed software sending/receiving *messages* based on 
different protocols.

All our protocols wrap data in an envelope. The receiver can then decide how to 
handle the message based on the envelope. Obviously, nil makes a bad envelope.

A nil message on a channel never had any significance to us four years ago 
and rethinking about it we reach the same conclusion today :)


Luc P.


> On Tue, Aug 27, 2013 at 10:51 AM, Mike Anderson <
> mike.r.anderson...@gmail.com> wrote:
> 
> > To me it's all about consistency with other Clojure constructs. You can
> > safely put nils in sequences, vectors, lists, sets etc.. nil is a valid
> > "value" just like anything else. So why can't you put them in a channel?
> >
> 
> Channels are *not* data structures nor are they a "place" to put something.
> 
> 
> > a) what if you want to send a sequence through a channel? Since nil as a
> > value represents the empty sequence, you have to put in some extra special
> > case handling with the current core.async model.
> >
> 
> You're not going to put random sequences into channels. Channels are
> conduits for meaningful messages - some well considered coordination
> protocol.
> 
> 
> > Both of these, I think, are reasonable and common enough use cases that
> > it's worth supporting them elegantly rather than forcing users to implement
> > their own nil-wrapping functionality.
> >
> 
> If you're putting arbitrary sequences into a channel and need to wrap nils,
> you probably need to redesign your coordination protocol.
> 
> 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.
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.

Rxjava + Clojure Users

[Dave Ray]

Hi.

I'm writing to see if there's anyone out there using RxJava [1] from
Clojure and to get their opinion on it's current, built-in support for
non-Java languages.

Just to recap, the current implementation knows about clojure.lang.IFn
allowing functions to be passed directly to RxJava methods:

  (-> my-observable
(.map (fn [v] (Long/parseLong v)))
(.reduce +))

RxJava will automatically convert these functions to the underlying
rx.util.functions.FuncX interface and re-dispatch to the appropriate method.

So, the question is: as a user of RxJava, how valuable is this feature? Do
you just end up wrapping things anyway, so you could easily perform the
same transformation in your wrapper? Would helper fns/macros be a
sufficient alternative:

  (-> my-observable
(.map (rx/fn [v] (Long/parseLong v)))
(.reduce (rx/fn* +)))

There will be some changes in this area in the near future and we'd like to
get a feel for if/how people are using RxJava from Clojure.

Thanks!

Dave

[1] https://github.com/Netflix/RxJava

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 - handling nils

[Ben Wolfson]

On Tue, Aug 27, 2013 at 7:51 AM, Mike Anderson  wrote:

> On 27 August 2013 20:45, Timothy Baldridge  wrote:
>
>> The reason for not allowing nils isn't a complex one, and basically boils
>> down to the following:
>>
>> a) to avoid race conditions, we need a single value to signal "the
>> channel is closed". As mentioned, nil is the obvious choice for this as it
>> matches lazy seqs and fits well with the rest of clojure:
>>
>>
> Agreed that you want a single sentinel value.
>
> It doesn't match lazy-seqs at all though: lazy seqs can contain nils just
> fine. There's a big difference between (next some-lazy-seq) [which could be
> nil, indicating an empty sequence] and the actual values in the seq [which
> could also be nil but don't indicate the end of the seq].
>

And the when-first macro correctly handles this! It's not just `(when-let
[~x (first ~xs)] ~@body). when-first nicely hides away what would otherwise
be "much more ugly".



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

Heroku app using core.async?

[Bastien]

Hi,

I just managed to use core.async for the need I described in my
previous email and tried to push this to heroku, but git bitten:

  Could not find artifact core.async:core.async:jar:0.1.0-SNAPSHOT in
  clojars (https://clojars.org/repo/)

  Could not find artifact core.async:core.async:jar:0.1.0-SNAPSHOT in
  sonatype-oss-public
  (https://oss.sonatype.org/content/groups/public/)

Am I guessing right that heroku prevents downloading libraries from
external repositories listed in :repositories?

Is anyone using core.async on heroku?

Thanks!

-- 
 Bastien

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Rxjava + Clojure Users

[Ben Mabey]

On 8/27/13 10:03 AM, Dave Ray wrote:

Hi.

I'm writing to see if there's anyone out there using RxJava [1] from 
Clojure and to get their opinion on it's current, built-in support for 
non-Java languages.


Just to recap, the current implementation knows about clojure.lang.IFn 
allowing functions to be passed directly to RxJava methods:


  (-> my-observable
(.map (fn [v] (Long/parseLong v)))
(.reduce +))

RxJava will automatically convert these functions to the underlying 
rx.util.functions.FuncX interface and re-dispatch to the appropriate 
method.


So, the question is: as a user of RxJava, how valuable is this 
feature? Do you just end up wrapping things anyway, so you could 
easily perform the same transformation in your wrapper? Would helper 
fns/macros be a sufficient alternative:


  (-> my-observable
(.map (rx/fn [v] (Long/parseLong v)))
(.reduce (rx/fn* +)))

There will be some changes in this area in the near future and we'd 
like to get a feel for if/how people are using RxJava from Clojure.


Thanks!

Dave

[1] https://github.com/Netflix/RxJava




Hi Dave,
We've been using RxJava from Clojure in production for a bit now but in 
a limited fashion.  While I saw many places where I would want to wrap 
RxJava I ended up not and instead just used the built-in methods since 
they played nicely with clojure fns.  How valuable is it?  It has been 
nice for our limited use but I think for a larger project we would end 
up wrapping it anyways.  (I would probably wrap the methods like .map, 
etc, so that they just take fns). So if it makes things easier for 
RxJava to drop the support I say drop it.


I've been thinking that the clojure community could benefit from a 
clj-rx project that that would define protocols for all the Rx 
primitives and a consistent API which could be implemented in a number 
of ways but would all adhere to the Rx contract.  RxJava and core.async 
being the two most obvious implementations but others could also wrap Rx 
js libs for use in ClojureScript if they needed to.  I know your 
question is specifically about RxJava but if you are going down the 
route of wrapping it in a nice idiomatic clojure API it may be worth 
taking a step back and seeing if taking the protocol approach makes 
sense.  I'd be interesting in collaborating on this if you decide to go 
down this route.


On a related Rx/core.async note... At work we are now using core.async 
for many of the workflows where I would have otherwise reached for Rx 
(and vanilla java.util.cc).  I've been finding that some tasks are much 
easier to think about using CSP and allow you to model certain processes 
in a clearer way.  Other times I find myself reaching for the nice 
abstraction Rx brings and I usually end up implementing some of the 
functions on top of core.async (similar to what Brandon Bloom has done 
in his experimental lib). This is why thinking having a unified clj-rx 
API warrants further exploration. I'd love to hear other peoples 
thoughts on this as well.


-Ben



--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 - handling nils

[Brandon Bloom]

As long as we don't go full Haskell mode:

data Message a = Value a | Done


On Tue, Aug 27, 2013 at 11:20 AM, Timothy Baldridge wrote:

> Right, the use of false is a special case. I'm thinking of a mouse event
> stream, may have a button channel that sends true or false based on the
> state of the mouse button. Even saying that though, I would probably opt
> for :clicked and :unclicked or somethig of that nature.
>
> Timothy
>
>
> On Tue, Aug 27, 2013 at 9:15 AM, Brandon Bloom 
> wrote:
>
>> > In every use of channels I've had thus far, nil is better expressed as
>> an empty collection, false, 0, :tick, or some other "ground value".
>>
>> I agree completely. But I'll note that you mention false being useful...
>>
>> If you're writing completely general operators, like map, which are
>> *sometimes* quite useful, then you have no choice but to do something like
>> if-recv or explicitly test against nil.
>>
>> > It's these Rx style programming methods that make people think they
>> need this feature.
>>
>> I built my little Rx with channels library (asyncx) without intention to
>> use it directly, but because I wanted to learn how to work with channels. I
>> rapidly learned that the techniques are a lot more different than they
>> look. In particular, it's more difficult to write channel & process
>> combinators precisely because they are more powerful. However, in
>> practice, each new reusable channel/process combinator yields more
>> complexity than it tends to save. I'd rather intentionally choose strictly
>> less powerful primitives where appropriate and enforce that with
>> encapsulation.
>>
>> With that in mind, if I ever revisit asyncx, I'll probably define "push
>> sequences" or "streams" in terms of protocols and deftypes. I'd use
>> core.async to implement them, but only for the lowest level primitives. I'd
>> provide ways to get in to or out of the stream subsystem for interop with
>> channels, but the public interface would take IStream objects.
>>
>>
>> On Tue, Aug 27, 2013 at 10:58 AM, Timothy Baldridge > > wrote:
>>
>>> All your arguments come down to this:
>>>
>>> "I have an arbitrary seq of things I want to send down a channel". It's
>>> exactly that concept I that I push against. Everything you've mentioned
>>> thus far is a data structure. Channels are not data structures they are
>>> concurrency management primitives, treat them as such and I doubt you'll
>>> ever have a need for nils in a channel.
>>>
>>> If we treat channels as ways of co-ordinating concurrent processes, then
>>> nil doesn't have a use case. In every use of channels I've had thus far,
>>> nil is better expressed as an empty collection, false, 0, :tick, or some
>>> other "ground value".
>>>
>>> It's these Rx style programming methods that make people think they need
>>> this feature.
>>>
>>> Timothy
>>>
>>>
>>>
>>>
>>> On Tue, Aug 27, 2013 at 8:51 AM, Mike Anderson <
>>> mike.r.anderson...@gmail.com> wrote:
>>>
 On 27 August 2013 20:45, Timothy Baldridge wrote:

> The reason for not allowing nils isn't a complex one, and basically
> boils down to the following:
>
> a) to avoid race conditions, we need a single value to signal "the
> channel is closed". As mentioned, nil is the obvious choice for this as it
> matches lazy seqs and fits well with the rest of clojure:
>
>
 Agreed that you want a single sentinel value.

 It doesn't match lazy-seqs at all though: lazy seqs can contain nils
 just fine. There's a big difference between (next some-lazy-seq) [which
 could be nil, indicating an empty sequence] and the actual values in the
 seq [which could also be nil but don't indicate the end of the seq].


> (when-let [v (   (process v))
>
> If we chose a different value, this becomes much more ugly:
>
> (let [v (   (when-not (= v :async/closed)
> (process v)))
>
>
 This can be solved easily by providing a macro or some other predicate
 that knows how to check for the sentinel value correctly. e.g.

 (when-more [v (>>>   (process v))


> b) I question if there are any valid uses for putting nil in a
> channel. With all due respect to all who have written here, thus far, 
> every
> complaint about nils and channels boils down to a conversion from seqs to
> channels. This is the wrong way to look at the problem. Channels are
> co-ordination primitives not data structures. Simply because a lazy seq
> looks like a channel, doesn't mean that they should be treated as such.
>
>
> In all the core.async code I've written I've never had to put a nil in
> a channel, so I'm left with the uncomfortable conclusion that most
> complaints on this subject are contrived. I could be wrong, but I just
> haven't seen a valid use case yet.
>
>
 To me it's all about consistency with other Clojure constructs. You can
 safely put nils in sequenc

Re: Heroku app using core.async?

[Shaun Gilchrist]

Hey, I encountered late one night but it was because oss.sonatype.org was
temporarily down for scheduled maintenance. Are you still seeing this now?
I just pushed to heroku and saw it pull the core.async dep as expected:

"Retrieving
org/clojure/core.async/0.1.0-SNAPSHOT/core.async-0.1.0-20130827.050117-78.pom
from sonatype-oss-public"




On Tue, Aug 27, 2013 at 11:40 AM, Bastien  wrote:

> Hi,
>
> I just managed to use core.async for the need I described in my
> previous email and tried to push this to heroku, but git bitten:
>
>   Could not find artifact core.async:core.async:jar:0.1.0-SNAPSHOT in
>   clojars (https://clojars.org/repo/)
>
>   Could not find artifact core.async:core.async:jar:0.1.0-SNAPSHOT in
>   sonatype-oss-public
>   (https://oss.sonatype.org/content/groups/public/)
>
> Am I guessing right that heroku prevents downloading libraries from
> external repositories listed in :repositories?
>
> Is anyone using core.async on heroku?
>
> Thanks!
>
> --
>  Bastien
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Heroku app using core.async?

[Bastien]

Hi Shaun,

Shaun Gilchrist  writes:

> Hey, I encountered late one night but it was because oss.sonatype.org
> was temporarily down for scheduled maintenance. Are you still seeing
> this now? I just pushed to heroku and saw it pull the core.async dep
> as expected:
>
> "Retrieving org/clojure/core.async/0.1.0-SNAPSHOT/
> core.async-0.1.0-20130827.050117-78.pom from sonatype-oss-public"

Was a typo on my side, I used [core.async "0.1.0...] instead of
[org.clojure/core.async "0.1.0...] -- sorry for the noise and
thanks for replying.

-- 
 Bastien

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 - handling nils

[Mike Anderson]

I still don't see why you would want to to arbitrarily limit what you can
put down a channel. FWIW, plenty of other concurrency management primitives
allow nils as values (java.util.concurrent.AtomicReference, Clojure atoms /
refs / agents to name but a few).

My motivating use case is the ability to create higher order constructs
that communicate via channels, as a way of gluing concurrent processes
together. A simplified example:

(defn printer [ch id]
  (go (while true
(let [v (! ch x)

(let [ch (chan)
  pr1 (printer ch "1")
  pr2 (printer ch "2")
  sendr (sender ch)]
  (sendr ["foo" "a"])
  (sendr ["bar"]))

Using nil as a sentinel appears to prevent such constructs from working
with arbitrary Clojure values (or alternatively forces extra wrapping /
special case handling that adds complexity and overhead). Furthermore, if
different libraries start adopting different protocols / techniques for
wrapping nils then the composability of such constructs will be severely
restricted.

I may be missing something, but this seems like a reasonable use case for
core.async to support?

Of course, if anyone has an actual technical argument why it is
necessary/better to use nil as a sentinel value, I would be delighted to
learn of it and would consider myself enlightened.


On 27 August 2013 22:58, Timothy Baldridge  wrote:

> All your arguments come down to this:
>
> "I have an arbitrary seq of things I want to send down a channel". It's
> exactly that concept I that I push against. Everything you've mentioned
> thus far is a data structure. Channels are not data structures they are
> concurrency management primitives, treat them as such and I doubt you'll
> ever have a need for nils in a channel.
>
> If we treat channels as ways of co-ordinating concurrent processes, then
> nil doesn't have a use case. In every use of channels I've had thus far,
> nil is better expressed as an empty collection, false, 0, :tick, or some
> other "ground value".
>
> It's these Rx style programming methods that make people think they need
> this feature.
>
> Timothy
>
>
>
>
> On Tue, Aug 27, 2013 at 8:51 AM, Mike Anderson <
> mike.r.anderson...@gmail.com> wrote:
>
>> On 27 August 2013 20:45, Timothy Baldridge  wrote:
>>
>>> The reason for not allowing nils isn't a complex one, and basically
>>> boils down to the following:
>>>
>>> a) to avoid race conditions, we need a single value to signal "the
>>> channel is closed". As mentioned, nil is the obvious choice for this as it
>>> matches lazy seqs and fits well with the rest of clojure:
>>>
>>>
>> Agreed that you want a single sentinel value.
>>
>> It doesn't match lazy-seqs at all though: lazy seqs can contain nils just
>> fine. There's a big difference between (next some-lazy-seq) [which could be
>> nil, indicating an empty sequence] and the actual values in the seq [which
>> could also be nil but don't indicate the end of the seq].
>>
>>
>>> (when-let [v (>>   (process v))
>>>
>>> If we chose a different value, this becomes much more ugly:
>>>
>>> (let [v (>>   (when-not (= v :async/closed)
>>> (process v)))
>>>
>>>
>> This can be solved easily by providing a macro or some other predicate
>> that knows how to check for the sentinel value correctly. e.g.
>>
>> (when-more [v (>   (process v))
>>
>>
>>> b) I question if there are any valid uses for putting nil in a channel.
>>> With all due respect to all who have written here, thus far, every
>>> complaint about nils and channels boils down to a conversion from seqs to
>>> channels. This is the wrong way to look at the problem. Channels are
>>> co-ordination primitives not data structures. Simply because a lazy seq
>>> looks like a channel, doesn't mean that they should be treated as such.
>>>
>>>
>>> In all the core.async code I've written I've never had to put a nil in a
>>> channel, so I'm left with the uncomfortable conclusion that most complaints
>>> on this subject are contrived. I could be wrong, but I just haven't seen a
>>> valid use case yet.
>>>
>>>
>> To me it's all about consistency with other Clojure constructs. You can
>> safely put nils in sequences, vectors, lists, sets etc.. nil is a valid
>> "value" just like anything else. So why can't you put them in a channel?
>>
>> Two use cases I have encountered that motivate this:
>>
>> a) what if you want to send a sequence through a channel? Since nil as a
>> value represents the empty sequence, you have to put in some extra special
>> case handling with the current core.async model.
>>
>> b) what if you want to write generic code to send all the values in an
>> arbitrary collection through a channel? you would have to wrap/unwrap nils
>> at either end to make this work currently.
>>
>> Both of these, I think, are reasonable and common enough use cases that
>> it's worth supporting them elegantly rather than forcing users to implement
>> their own nil-wrapping functionality.
>>
>>
>>> This all being said, there really isn't a technical reason to no

eval/macros with functions with metadata

[Ben Wolfson]

or, the dreaded "no matching ctor found" exception.

Is there a way to write the function

(defn eval-at-one [f] (eval `(~f 1)))

such that it works when invoked like this:

(eval-at-one (fn [x] x))
 ;; --> 1

and like this

(eval-at-one (with-meta (fn [x] x) {}))
 ;; -> IllegalArgumentException No matching ctor found for class
clojure.lang.AFunction$1  clojure.lang.Reflector.invokeConstructor
(Reflector.java:163)

?

I thought that the object returned by with-meta might be hanging onto the
original, metadata-less object, which could then be retrieved and used
without difficulty, but this appears not to be the case.

-- 
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: core.async - handling nils

[guns]

On Wed 28 Aug 2013 at 09:38:06AM +0800, Mike Anderson wrote:

> Of course, if anyone has an actual technical argument why it is
> necessary/better to use nil as a sentinel value, I would be delighted to
> learn of it and would consider myself enlightened.

Forgive me if someone already mentioned this, but isn't this simply a
consequence of building on the existing Java Queue implementations?

Quoting http://docs.oracle.com/javase/7/docs/api/java/util/Queue.html:

Queue implementations generally do not allow insertion of null
elements, although some implementations, such as LinkedList, do not
prohibit insertion of null. Even in the implementations that permit
it, null should not be inserted into a Queue, as null is also used
as a special return value by the poll method to indicate that the
queue contains no elements.

I think most would agree with you that a configurable sentinel value
is best (I like using ::namespaced-keywords myself), but the existing
machinery has already decided on null, so that's what we have.

guns


pgp6xD5GT3rVU.pgp
Description: PGP signature

Re: core.async - handling nils

[Mikera]

Well, that's certainly a good explanation of why core.async works the way 
it does now - it's a natural and sensible starting point to build on Java 
Queues.

I don't think that this necessarily implies that we have to follow this 
model in the future Clojure API though. The Java designers didn't always 
get everything right :-)

There's no reason I can see why core.async can't internally substitute its 
own nil-representing value into the underlying Java infrastructure. And 
this would free users of core.async from the burden of doing this 
translation every time that the transmission of nil values is desired.

As for "configurable sentinel value": I'm less sure that there's a need for 
this. In fact, I think it's more useful to guarantee a standard sentinel 
value so that different channel-handling code can interoperate. I just 
think that this sentinel shouldn't be nil (or any other regular Clojure 
value). A simple singleton object that is privately owned by core.async 
should suffice?

On Wednesday, 28 August 2013 09:54:51 UTC+8, guns wrote:
>
> On Wed 28 Aug 2013 at 09:38:06AM +0800, Mike Anderson wrote: 
>
> > Of course, if anyone has an actual technical argument why it is 
> > necessary/better to use nil as a sentinel value, I would be delighted to 
> > learn of it and would consider myself enlightened. 
>
> Forgive me if someone already mentioned this, but isn't this simply a 
> consequence of building on the existing Java Queue implementations? 
>
> Quoting http://docs.oracle.com/javase/7/docs/api/java/util/Queue.html: 
>
> Queue implementations generally do not allow insertion of null 
> elements, although some implementations, such as LinkedList, do not 
> prohibit insertion of null. Even in the implementations that permit 
> it, null should not be inserted into a Queue, as null is also used 
> as a special return value by the poll method to indicate that the 
> queue contains no elements. 
>
> I think most would agree with you that a configurable sentinel value 
> is best (I like using ::namespaced-keywords myself), but the existing 
> machinery has already decided on null, so that's what we have. 
>
> 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.

Can you explain the result of a expression?

[ljcppunix]

Hi,

(take 1 (map #(do (print \.) %) (range)))
result: (0)

I think it should be (.0), why? thank you!

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Can you explain the result of a expression?

[Dave Sann]

chunked lazy sequences

On Wednesday, 28 August 2013 12:51:27 UTC+10, ljcp...@gmail.com wrote:
>
> Hi,
>
> (take 1 (map #(do (print \.) %) (range)))
> result: (0)
>
> I think it should be (.0), why? thank you!
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.

Easiest way to map over leaf nodes of nested sequence

[JvJ]

I feel like this question has been asked about a trillion times, but I was 
having a hard time finding a straight answer.  Is there a really 
straightforward way in the standard library or in one of the contrib 
libraries to do something like this:
(nested-map inc '(1 (2 3) (4 (5 (6) ===> '(2 (3 4) (5 (6 (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: Easiest way to map over leaf nodes of nested sequence

[Gary Fredericks]

Clojure.walk
On Aug 27, 2013 10:05 PM, "JvJ"  wrote:

> I feel like this question has been asked about a trillion times, but I was
> having a hard time finding a straight answer.  Is there a really
> straightforward way in the standard library or in one of the contrib
> libraries to do something like this:
> (nested-map inc '(1 (2 3) (4 (5 (6) ===> '(2 (3 4) (5 (6 (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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 - handling nils

[guns]

On Tue 27 Aug 2013 at 07:42:53PM -0700, Mikera wrote:

> On Wednesday, 28 August 2013 09:54:51 UTC+8, guns wrote:
> >
> > On Wed 28 Aug 2013 at 09:38:06AM +0800, Mike Anderson wrote:
> >
> > > Of course, if anyone has an actual technical argument why it is
> > > necessary/better to use nil as a sentinel value, I would be delighted to
> > > learn of it and would consider myself enlightened.
> >
> > Forgive me if someone already mentioned this, but isn't this simply a
> > consequence of building on the existing Java Queue implementations?
> >
> > Quoting http://docs.oracle.com/javase/7/docs/api/java/util/Queue.html:
> >
> > Queue implementations generally do not allow insertion of null
> > elements, although some implementations, such as LinkedList, do not
> > prohibit insertion of null. Even in the implementations that permit
> > it, null should not be inserted into a Queue, as null is also used
> > as a special return value by the poll method to indicate that the
> > queue contains no elements.
>
> I don't think that this necessarily implies that we have to follow
> this model in the future Clojure API though. The Java designers didn't
> always get everything right :-)

I agree with you that this is an inconvenience. The bit about avoiding
null even in collections that support null elements because poll uses
null as a sentinel value is a classic leaky abstraction.

That said, I haven't found designing around it to be a terrible
nuisance. I often use queues as messaging channels, so it is natural to
simply send maps or tuples instead of atomic values.

> As for "configurable sentinel value": I'm less sure that there's
> a need for this. In fact, I think it's more useful to guarantee a
> standard sentinel value so that different channel-handling code can
> interoperate. I just think that this sentinel shouldn't be nil (or
> any other regular Clojure value). A simple singleton object that is
> privately owned by core.async should suffice?

Oh, I was confused; I was thinking about sentinel values in user code.
Yes, I imagine a single private (Object.) would work just fine, with
very little overhead.

guns


pgp0C89I2s0Ka.pgp
Description: PGP signature

Re: Easiest way to map over leaf nodes of nested sequence

[JvJ]

I suppose that works, but it seems a little inelegant to do this:
(prewalk #(if (sequential? %) % (f %)) xs)
instead of just
(prewalk f xs)

On Tuesday, 27 August 2013 20:06:38 UTC-7, gfredericks wrote:
>
> Clojure.walk
> On Aug 27, 2013 10:05 PM, "JvJ" > wrote:
>
>> I feel like this question has been asked about a trillion times, but I 
>> was having a hard time finding a straight answer.  Is there a really 
>> straightforward way in the standard library or in one of the contrib 
>> libraries to do something like this:
>> (nested-map inc '(1 (2 3) (4 (5 (6) ===> '(2 (3 4) (5 (6 (7
>>
>> -- 
>> -- 
>> 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: core.async - handling nils

[Alan Busby]

On Wed, Aug 28, 2013 at 12:18 PM, guns  wrote:

> Oh, I was confused; I was thinking about sentinel values in user code.
> Yes, I imagine a single private (Object.) would work just fine, with
> very little overhead.
>

First, I'd hope that sentinel values would be handled by the back-end
implementation, as we're seeing core.sync implemented on other
systems like ZeroMQ already.

Second, as (Object.) doesn't play nicely over the wire, a random UUID
or similar value would be much preferred.

Third, I'd recommend reviewing,
http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html
to understand why core.async is not just a better queue.

Fourth, if you dislike how core.async works, just wrap it in your own
library so it works the way you'd like.
It looks like "core.async-with-nil" is available on Clojars. ;)

With nil, without nil, it's just bike shedding. Clojure gives you the
freedom to do it the way you want.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 - handling nils

[guns]

On Wed 28 Aug 2013 at 12:50:19PM +0900, Alan Busby wrote:

> On Wed, Aug 28, 2013 at 12:18 PM, guns  wrote:
>
> > Oh, I was confused; I was thinking about sentinel values in user
> > code. Yes, I imagine a single private (Object.) would work just
> > fine, with very little overhead.
>
> Third, I'd recommend reviewing,
> http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html to
> understand why core.async is not just a better queue.

In my mind, core.async is a nice marriage of BlockingQueues, async
processing, and a supercharged POSIX select(2) that works on queue
objects. Nothing about these ideas necessarily requires that null be
reserved by the channel implementation.

> Fourth, if you dislike how core.async works, just wrap it in
> your own library so it works the way you'd like. It looks like
> "core.async-with-nil" is available on Clojars. ;)
>
> With nil, without nil, it's just bike shedding. Clojure gives you the
> freedom to do it the way you want.

Rich Hickey, from: 
http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html

> While the library is still in an early state, we are ready for people
> to start trying it out and giving us feedback.

I think mikera is trying to be constructive.

For my own part, I am quite ambivalent since I am already used to
avoiding pushing nulls onto Queues. I am quite happy to accept that this
is an implementation detail and move on, but I can also see why it might
be worth it to support nil channel values to avoid confusing users that
are not familiar with this quirk of java.util.Queue.

guns


pgpQWVvS0WkaO.pgp
Description: PGP signature

Re: core.async - handling nils

[Mike Anderson]

On 28 August 2013 11:50, Alan Busby  wrote:

> On Wed, Aug 28, 2013 at 12:18 PM, guns  wrote:
>
>> Oh, I was confused; I was thinking about sentinel values in user code.
>> Yes, I imagine a single private (Object.) would work just fine, with
>> very little overhead.
>>
>
> First, I'd hope that sentinel values would be handled by the back-end
> implementation, as we're seeing core.sync implemented on other
> systems like ZeroMQ already.
>
> Second, as (Object.) doesn't play nicely over the wire, a random UUID
> or similar value would be much preferred.
>

Hi Alan,

Agreed on all the above. The issue is not so much what sentinel value is
used internally, but what sentinel value gets exposed to user code.


>
> Third, I'd recommend reviewing,
> http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html
> to understand why core.async is not just a better queue.
>
> Fourth, if you dislike how core.async works, just wrap it in your own
> library so it works the way you'd like.
> It looks like "core.async-with-nil" is available on Clojars. ;)
>

That's precisely what I'm trying to avoid, and the reason why I've been
raising the topic here - the last thing we want in the ecosystem is more
fragmentation with incompatible subsystems and protocols. That's the Lisp
Curse all over again. I think we should aspire to better in the Clojure
community - which means working together to make the best implementation
possible and rallying around it.

Sending nil as a value over channels is clearly a significant issue if
people are willing to fork or create a new wrapper for core.async in order
to achieve it. Better, in my view, to make a breaking change to core.async
now to fix this issue rather than encouraging a free-for-all.

I'm reminded of Rich Hickey's keynote "The Language of the System", which
emphasised composing systems out of simple services that communicate via
values. core.async would IMHO be a much more useful tool for realising this
sort of vision if it is able transmit arbitrary Clojure values (i.e.
including 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.