core.async

[Rich Hickey]

I've blogged a bit about the new core.async library:

http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html

Please try it out.

Thanks,

Rich

[David Nolen]

Excellent!

I've been playing around the ClojureScript support ... needs work ... but already A-M-A-Z-I-N-G.

David

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

[Nahuel Greco]

Very nice! Selectable channels FTW.

Btw, are you aware of the Erlang selective-receive model? Is often very overlooked but it showed big advantages over unfiltered channels. See this: http://www.erlang.se/euc/05/1500Wiger.ppt

Saludos,
Nahuel Greco.

[Nahuel Greco]

I forgot the second Ulf Wiger link, related to the previous one: http://www.infoq.com/presentations/Death-by-Accidental-Complexity

Saludos,
Nahuel Greco.

[Alex Baranosky]

Very cool stuff.  

One point of feedback though: I thought Clojure Core had done a great job of avoiding a Haskell-like symbol-heavy.  I might've been mis-informed, but I thought this tendency to avoid  symbol-heavy naming was intentional.  For example, instead of `-?>` in 1.5 we got `some->`. I thought it was a great compromise for readability.  In core.async, we've got a lot more symbols.  Are people in love with names like `<!` and `>!!`, or is there room for rethinking the naming?

Best,

Alex

[Brandon Bloom]

> Are people in love with names like `<!` and `>!!`, or is there room for rethinking the naming?

These operators are important and common enough to justify being *syntax* in Go, which is pretty minimal on syntax overall.

Personally, I think the names are pretty good.

[Brandon Bloom]

> CSP proper is amenable to certain kinds of automated correctness analysis.

> No work has been done on that front for core.async as yet.

Although a far cry from Go's race detector, Go did ship with one feature that is helpful for preventing a certain class of bugs: explicit restriction to a send-only or receive-only channel via constraining conversion or assignment. See http://golang.org/ref/spec#Channel_types

Although Go utilizes the type system to accomplish this at compile time, core.async could achieve the same effect at runtime. Essentially, there could be two conversion functions for wrapping a channel in a read-only or write-only proxy object.

I'm not sure if this is actually useful, but I'm curious: Has this been considered?

[Philip Potter]

Looks awesome! I've just taken a moment to think of all the possibilities this could allow.

One question: can multiple concurrent IoC threads be multiplexed over multiple JVM threads? One advantage go's goroutines have is that they work fine for single-thread concurrency, but if more cores are available they can use them.

Phil

[Thomas Heller]

Hey,

this looks very interesting. However I'm a little concerned about the semantics of >! and <!.

https://gist.github.com/thheller/5890363

(ns thheller.async-test
  (:use clojure.test)
  (:require [clojure.core.async :as async :refer (go >! <! >!! <!!)]))
 
(def c (async/chan))
 
(defn do-some-work [work]
  (throw (ex-info "no way" {:work work})))
 
(go (loop [work-done 0]
      (let [[reply-to work] (<! c)
            reply (do-some-work work)]
        (>! reply-to reply)
        (recur (inc work-done))
        )))
 
(let [me (async/chan)]
  (>!! c [me :work-work])
  (<!! me) ;; never returns
  )

The go-thread dies on the first message and never replies, the other thread waiting for a reply (be it the current thread as in my example, or another go-thread) will now be stuck. Thus I need an extra timeout for EVERY <! I ever do, you hinted as much in your blog post. Waiting for messages that never arrive.

However you may also run into situations where >! never returns, cause the consumer died and the buffer is full. How do you "return" from that? Can I do alt! (timeout) on a put? Or does a full buffer throw?

From what I understand one can "<!" the result of the outer (go ...) to detect that it in fact "ended"? I guess there could be some helper functions which restart go-threads in case of accidental deaths. Although right now an exception does not seem to close the go result channel.

I still prefer Erlang (Actors) since it seems way easier to reason about and process links and monitors (supervisors) certainly make failures alot easier to detect/handle.

Any words on the state of the CLJS port? Looking through the code I found that setTimeout(fn, 0) is used alot. HTML5 Spec [1,2,3] says "If the currently running task is a task that was created by the setTimeout() method, and timeout is less than 4, then increase timeout to 4." That may cause some trouble, thought I mention this.

Anyways, its pretty nice piece of work and I will certainly play with it for a while.

Cheers,

/thomas

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers

[2] https://developer.mozilla.org/en-US/docs/Web/API/window.setTimeout#Minimum.2F_maximum_delay_and_timeout_nesting

[3] http://dbaron.org/log/20100309-faster-timeouts

[Peter Taoussanis]

Oh man, how is everyone _not_ running around screaming about this right now?

It seems to me that the Clojure space suffers from an unusual malady: it's busy sitting here quietly advancing half of applied computer science, and no one seems to notice the full extent of its import.

Man, I'm sometimes forced to just stop for a moment and sit in awe at how lucky I've been to see this stuff develop and to get to use it.

Clojure was huge. And before we're close to digesting its potential, there's protocols. And Clojurescript. Then Datomic. Reducers. Now this.

And it's not about everything being necessarily _novel_, though there is often novelty. For me it's largely about the cohesiveness of the design and the consistency of the overarching vision. Everything _fits_. I feel like I'm using tools and ideas that weren't just developed with care, or cleverness, or experience, but all of those things in a kind of harmony that's vanishingly rare to find in any field.

I honestly feel like I'm witnessing history being made.

Thank you Rich Hickey, and everyone else in this community for making my work every day so enjoyable.

- Peter Taoussanis

[Baishampayan Ghose]

On Sat, Jun 29, 2013 at 4:37 PM, Peter Taoussanis <ptaou...@gmail.com> wrote:
> I honestly feel like I'm witnessing history being made.

We all are.

-BG

--
Baishampayan Ghose
b.ghose at gmail.com

[Jim - FooBar();]

On 29/06/13 12:07, Peter Taoussanis wrote:
>
> I honestly feel like I'm witnessing history being made.
>
> Thank you Rich Hickey, and everyone else in this community for making
> my work every day so enjoyable.
>

+100! that makes 2 of us :)

Thanks indeed Rich (and everyone else of course)...

Jim

[JeremyS]

Hi guys,

Some time ago I was thinking how nice it would be to have Clojure on top of Go to be able to use channels and goroutines...

Well, I stand corrected, we don't need Go, it is now done as a library ! Clojure is a golden inspiration mine, every time something 

new arrives, if I am not running around like a headless chicken, since my mind (and so my head) is blown away, I am very close to...

Exciting times !!!

Cheers,

Jeremys.

[David Nolen]

Only experience will tell if setTimeout is a problem. I doubt it. I've toyed around with a queueing dispatcher that waits till we get 32 events with flush after 6ms (the time span between which mouse events may arrive under OS X). This permits queueing and dispatching a million events in less than half a second.

I know Dart selects the best dispatching mechanism available - setTimeout, DOM mutation observer etc

We should also explore our options.

David 

[Ben Wolfson]

So how does all this compare to lamina?

--

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

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

[Rich Hickey]

On Saturday, June 29, 2013 1:32:26 AM UTC-4, Brandon Bloom wrote:

> CSP proper is amenable to certain kinds of automated correctness analysis.

> No work has been done on that front for core.async as yet.

Although a far cry from Go's race detector, Go did ship with one feature that is helpful for preventing a certain class of bugs: explicit restriction to a send-only or receive-only channel via constraining conversion or assignment. See http://golang.org/ref/spec#Channel_types

Although Go utilizes the type system to accomplish this at compile time, core.async could achieve the same effect at runtime. Essentially, there could be two conversion functions for wrapping a channel in a read-only or write-only proxy object.

I'm not sure if this is actually useful, but I'm curious: Has this been considered?

Yes, that's why some of the args are called 'ports'. We will probably have read/write ports representing just one end of a channel.

Rich  

[Rich Hickey]

Links and monitors can be applied as well to channel-using processes, and remain an interesting area for further work.

Rich

[Joseph Smith]

It seems to me that the Clojure space suffers from an unusual malady: it's busy sitting here quietly advancing half of applied computer science, and no one seems to notice the full extent of its import.

And it makes me sound like a broken record with my colleagues: "Oh! Clojure has..."

 

---

Joseph Smith

@solussd

[David Pollak]

What's the entry in project.clj to use the core.async stuff?

Thanks!

[Brandon Bloom]

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

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/PZ6sM2WXR1Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Cedric Greevey]

On Sat, Jun 29, 2013 at 7:07 AM, Peter Taoussanis <ptaou...@gmail.com> wrote:

Oh man, how is everyone _not_ running around screaming about this right now?

It seems to me that the Clojure space suffers from an unusual malady: it's busy sitting here quietly advancing half of applied computer science, and no one seems to notice the full extent of its import.

Man, I'm sometimes forced to just stop for a moment and sit in awe at how lucky I've been to see this stuff develop and to get to use it.

Agreed. But the lack of notice means we're "in on the ground floor", so to speak, and can run circles around rival programming shops until they catch on. :)

 

Clojure was huge. And before we're close to digesting its potential, there's protocols. And Clojurescript. Then Datomic. Reducers. Now this.

One of these things is not like the others; one of these things is not open source ...

 

And it's not about everything being necessarily _novel_, though there is often novelty. For me it's largely about the cohesiveness of the design and the consistency of the overarching vision. Everything _fits_. I feel like I'm using tools and ideas that weren't just developed with care, or cleverness, or experience, but all of those things in a kind of harmony that's vanishingly rare to find in any field.

I honestly feel like I'm witnessing history being made.

Thank you Rich Hickey, and everyone else in this community for making my work every day so enjoyable.

The NSA is probably getting a FISA warrant right now to search Hickey's home and place of business for any evidence of a flying saucer or time machine, on the grounds that either would have national security implications. :P

[Jozef Wagner]

This is great news! Especially that it is designed also to support other hosts besides JVM.

BTW how do IOC threads compare (e.g. in performance and ability to use ForkJoinPool) to coroutines such as those in pulsar? [1] [2]

[1] http://blog.paralleluniverse.co/post/49445260575/quasar-pulsar

[2] http://puniverse.github.io/pulsar/manual/core.html#fibers

Jozef

On Friday, June 28, 2013 9:06:47 PM UTC+2, Rich Hickey wrote:

[David Pollak]

On Sun, Jun 30, 2013 at 3:00 AM, Brandon Bloom <brandon...@gmail.com> wrote:

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

Thanks!

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

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

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

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

Rock on!
 

[Sean Corfield]

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

It's accessible like this:

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

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

[David Pollak]

Thanks!

[dennis zhuang]

It's so cool,great job!

But i don't find any way to do io blocking operations such as socket.read in 'go'.

Is there a roadmap to make alts! working with java NIO selector that waits on socket channels?

Then we can read/write data with socket/file channel in go without blocking.

Thanks,it's really awesome!

2013/7/1 David Pollak <dpoll...@gmail.com>

--
庄晓丹
Email:        killm...@gmail.com xzh...@avos.com
Site:           http://fnil.net
Twitter:      @killme2008

[Cedric Greevey]

The obvious approach is to use a future or other thread as an intermediary between the blocking I/O read and a channel, then use !< on the channel in a go; something like:

(go

  (let [c (chan)]

    (future (>!! c (my-blocking-io-read some-stream)))

    (let [thingy (!< c)

      (do-something-with thingy))))

The channel can then be used in alts! and what-not as well, if you want to react to any of several possible "next things", only one of which is the I/O read completing and returning a value.

This *does* suggest making a small async.io library that provides a nonblocking read operation that returns a channel, and maybe other related facilities, such as a line-chan that pops line after line from the input I/O source when read from, byte-chan (for binary files), edn-chan (top level edn forms read from input), etc.

[Devin Walters]

Interesting post. Thanks Cedric.

'(Devin Walters)