[ANN] core.async 0.1.319.0-6b1aca-alpha

[Alex Miller]

core.async 0.1.319.0-6b1aca-alpha (catchy right?) is now available. 

 

Try it via 

- Download: http://central.maven.org/maven2/org/clojure/core.async/0.1.319.0-6b1aca-alpha/

- Or securely: https://repo1.maven.org/maven2/org/clojure/core.async/0.1.319.0-6b1aca-alpha/

- Leiningen: [org.clojure/core.async "0.1.319.0-6b1aca-alpha"]

core.async 0.1.319.0-6b1aca-alpha has the following changes from prior release:

1) Transducers support as outlined in Rich's blog post:

http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming

You will need Clojure 1.7.0-alpha1 to create the transducers used by core.async.

With the addition of transducers, many of the async operators (map>,filter>,reduce>,etc) have been deprecated and will eventually be removed. One of the benefits of transducers is that we can define transformations once (in core) but use them on channels as well.

2) New: pipeline, pipeline-blocking, and pipeline-async

Pipeline sits between two channels and applies a transducer function with a specified parallelism, output order is retained. Please read the docstrings for all the details:

http://clojure.github.io/core.async/#clojure.core.async/pipeline

http://clojure.github.io/core.async/#clojure.core.async/pipeline-blocking

http://clojure.github.io/core.async/#clojure.core.async/pipeline-async

3) partial solution to cljs ASYNC-81, remove all instances of (assert nil ...)…

http://dev.clojure.org/jira/browse/ASYNC-81

4) allow exceptions on 'go' thread pool to propagate - ASYNC-76

http://dev.clojure.org/jira/browse/ASYNC-76

Prior code was trapping uncaught exceptions bubbling out of "go" loops or "thread" calls, printing the exception (so you could at least debug it), and swallowing the exception. We've rolled that back so that exceptions now bubble up to the top of the thread where Java uncaught exception handlers come into play. This has the benefit of giving control back to the application and the downside of again hiding that exception by default.

In general, go and thread blocks should be looking for and dealing with exceptions in an appropriate way (like sending a message on a channel, closing a channel, logging, whatever makes sense for you).

If an unexpected exception escapes out of those blocks, one way to retrieve it is to install a default uncaught exception handler (presuming this does not collide with one already defined in your environment):

(Thread/setDefaultUncaughtExceptionHandler 

  (reify Thread$UncaughtExceptionHandler 

    (uncaughtException [_ thread ex] 

          ;; do what you want here, this prints to stderr

 (.printStackTrace ex))))

This is a first step, more to come in this area.

[henry w]

In the original blog post there was mention of network channels being a possible area of interest. Do you know if this is on the roadmap? Or is there a roadmap for core.async?

Thanks
Henry

[Alex Miller]

Timothy Baldridge has worked on it off and on. It is hard (maybe not possible?) to extend channel semantics over the network. So I don't think this is coming soon. Most people create threads at the edges that negotiate in app-specific ways between internal channels external network I/O.

[henry w]

Ok thanks. Just curious.

--
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 a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/DSdmEjWP15U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.