<< Back to previous view

[ASYNC-5] Go macro fails on quoted lists Created: 15/Jul/13  Updated: 16/Jul/13  Resolved: 16/Jul/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Brandon Bloom Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: None


 Description   

Minimal reproduction:

(go '(1 2 3))

Error:

Exception in thread "async-dispatch-6" java.lang.ClassCastException: java.lang.Long cannot be cast to clojure.lang.IFn



 Comments   
Comment by Timothy Baldridge [ 16/Jul/13 7:46 AM ]

Fixed in master: https://github.com/clojure/core.async/commit/403d2cf1812f51bacd42130d5509fc881d44e4bc





[ASYNC-1] String representation for channels Created: 11/Jul/13  Updated: 12/Jul/13  Resolved: 11/Jul/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Pepijn de Vos Assignee: Rich Hickey
Resolution: Declined Votes: 0
Labels: None

Attachments: Text File 0001-string-representation-for-channels.patch    
Patch: Code

 Description   

When working with channels, I frequently have no idea what's inside it and who's blocking on it.

This simple patch shows the number of items in the buffer, as well as the number of putters and takers.



 Comments   
Comment by Timothy Baldridge [ 11/Jul/13 9:13 AM ]

It should be noted that this patch simply adds .toString to the channel type. It does not provide extra members such as count-takers, or count-putters. I would have serious problems with the latter, but simply adding .toString seems very much in line with what we already have for atoms. The output of .toString can be out of date the moment the function is executed, but since it's only really useful for debugging anyways, I don't think we care.

Comment by Timothy Baldridge [ 11/Jul/13 9:23 AM ]

As the docs for LinkedList notes, these structures are not thread-safe (hence all the locking done in put/take).

http://docs.oracle.com/javase/6/docs/api/java/util/LinkedList.html

So this patch runs the danger of something going really wrong.

Comment by Pepijn de Vos [ 12/Jul/13 3:07 AM ]

What could go wrong? Count is not a structural modification, right? Or can you corrupt a list by merely taking its count while someone else is adding a thing?

If the general idea of a readable toString method sounds good, I'd be happy to add locking if necessary.





[ASYNC-7] Recur fails within case Created: 15/Jul/13  Updated: 16/Jul/13  Resolved: 16/Jul/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Brandon Bloom Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: None


 Description   

Minimal reproduction:

(go (loop [] (case 1 1 (recur))))

Produces error:

IllegalArgumentException No implementation of method: :emit-instruction of protocol: #'clojure.core.async.impl.ioc-macros/IEmittableInstruction found for class: clojure.core.async.impl.ioc_macros.Jmp clojure.core/-cache-protocol-fn (core_deftype.clj:541)



 Comments   
Comment by Timothy Baldridge [ 16/Jul/13 7:37 AM ]

Fixed in master. https://github.com/clojure/core.async/commit/9ac00f931ba86fbfbcbec60e43e101796b8d5130





[ASYNC-9] nested 'go' blocks doesn't seems to work very well Created: 15/Jul/13  Updated: 19/Jul/13  Resolved: 19/Jul/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Nahuel Greco Assignee: Rich Hickey
Resolution: Completed Votes: 0
Labels: None
Environment:

Clojure 1.5.1 / core.async 0.1.0-SNAPSHOT



 Description   

This raises an IllegalArgumentException:

(go
(go
(<! (timeout 2000))
true))

But this seems to work ok:

(go (go true))



 Comments   
Comment by Timothy Baldridge [ 15/Jul/13 11:28 PM ]

Works fine in master (latest from core.async github) please try a fresh checkout.

Comment by Nahuel Greco [ 16/Jul/13 12:14 AM ]

Thanks, Now it works ok.

Comment by Timothy Baldridge [ 19/Jul/13 8:50 AM ]

Closing as something in master has fixed the issue.





[ASYNC-16] Faulty rebinding of loop bindings in go macro Created: 01/Aug/13  Updated: 03/Aug/13  Resolved: 03/Aug/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Ghadi Shayban Assignee: Ghadi Shayban
Resolution: Completed Votes: 0
Labels: None

Patch: Code and Test

 Description   

Below from https://groups.google.com/d/msg/clojure/MJc-69TgjR0/9HZqE7-kM9UJ

There seems to be an issue with the rebinding of loop-bindings using loop/recur in go blocks,
specifically when you are just changing the order of the original bindings in a recur call.

Take this snippet for example:
(require '[clojure.core.async :refer [go timeout]])
(go (loop [a :black, b :white]
(println a b)
(<! (timeout 1000))
(recur b a)))

Instead of repeatedly printing

:black :white
:white :black
:black :white
:white :black
(...)

it actually prints

:black :white
:white :white
:white :white
:white :white
(...)

Note however, that

(require '[clojure.core.async :refer [go timeout]])
(go (loop [a :black, b :white]
(println a b)
(<! (timeout 1000))
(recur (identity b) (identity a))))

works correctly.



 Comments   
Comment by Ghadi Shayban [ 03/Aug/13 1:45 PM ]

Root cause:
Recurring with (recur b a) will emit semantically invalid code.
essentially
(let [b a
a b]

instead of something like:
(let [temp-b b
b a
a b]

Preliminary patch is on branch ASYNC-16.

TODO: add basic test and port the patch to cljs

Comment by Ghadi Shayban [ 03/Aug/13 2:06 PM ]

fixed with tests + cljs port.





[ASYNC-3] set! usage in ClojureScript go block results in set locals error Created: 11/Jul/13  Updated: 09/Aug/13  Resolved: 09/Aug/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Timothy Baldridge
Resolution: Completed Votes: 1
Labels: None


 Description   

Probably because of intermediate locals generated by SSA form, valid set! expressions get converted into set! on locals. I was trying to set the 'innerHTML' property of a HTML element stored in a top level var in a go block when I encountered this.



 Comments   
Comment by Timothy Baldridge [ 09/Aug/13 4:14 PM ]

fixed in https://github.com/clojure/core.async/commit/018d26a0faf40f48d7b95c23777224deef91a126





[ASYNC-17] Loop bindings cant's see prior bindings made in the same loop when the loop is in a go block Created: 08/Aug/13  Updated: 09/Aug/13  Resolved: 09/Aug/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Kevin Marolt Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: None


 Description   

Loop bindings cant's see prior bindings made in
the same loop when the loop is in a go block:

(require '[clojure.core.async :refer [go]])
(go (loop [x 41 y (inc x)] (println y)))

Rather than printing 42, it either complains that x can't be
resolved in that context (in Clojure), or that x ist an undeclared
Var (in ClojureScript).



 Comments   
Comment by Timothy Baldridge [ 08/Aug/13 9:54 AM ]

Confirmed as a bug, loop bindings happen in parallel in the current code. This should be changed to match normal CLJ semantics.

Comment by Timothy Baldridge [ 09/Aug/13 4:16 PM ]

fixed in https://github.com/clojure/core.async/commit/d445dd3d6a231f52989f45021f58a5a1413cee17





[ASYNC-14] Possible incorrect behavior on apply >! within go block Created: 28/Jul/13  Updated: 16/Aug/13  Resolved: 16/Aug/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Jeff Sigmon Assignee: Timothy Baldridge
Resolution: Declined Votes: 0
Labels: None
Environment:

Java 1.7.0_15 Java HotSpot(TM) 64-Bit Server VM
clojure 1.5.1
core.async 0.1.0-SNAPSHOT



 Description   

Below is code taken form the example file at https://github.com/clojure/core.async/blob/master/examples/walkthrough.clj

(let [c (chan)]
  (go (>! c "hello"))
    (assert (= "hello" (<!! (go (<! c)))))
    (close! c)))

I get different behavior when I change the first go block above to apply the >! function. In this case the execution hangs on the second go block. An example is below:

(let [c (chan)]
  (go (apply >! [c "hello"]))
    (assert (= "hello" (<!! (go (<! c)))))
    (close! c)))


 Comments   
Comment by Jeff Sigmon [ 28/Jul/13 9:35 AM ]

Sorry about the misleading indentation in the code above...

Comment by Ghadi Shayban [ 28/Jul/13 10:59 PM ]

<! and >! are not normal IFn's or applicative function calls. They are akin to special forms or value-less macros compiled by the go macro. Maybe we can improve the docstring to show that those forms can't be applied across its arguments.

>! macro docstring:

puts a val into port. nil values are not allowed. Must be called inside a (go ...) block. Will park if no buffer space is available.

The >! var in clojure.core.async is just a hook to attach some docstring metadata. Its state can be nil and the go macro would still work the same.

Comment by Timothy Baldridge [ 16/Aug/13 7:24 AM ]

<! and >! are not functions, they are go macro special forms. They should be treated as macros. This is not a feature we plan to implement.

Comment by Timothy Baldridge [ 16/Aug/13 7:25 AM ]

If you need behavior like you show above, consider using a destructuring let/loop/fn





[ASYNC-18] CompilerException attempting to perform a transaction inside go block Created: 15/Aug/13  Updated: 16/Aug/13  Resolved: 16/Aug/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Adam Wittenberg Assignee: Timothy Baldridge
Resolution: Declined Votes: 0
Labels: bug


 Description   

When setting up a transaction inside of a go block, receiving the following error:

CompilerException java.lang.RuntimeException: No such var: clojure.core/runInTransaction, compiling:(NO_SOURCE_PATH:2:8)

(require '[clojure.core.async :as async :refer :all])

(def bar (ref []))
(def c (chan))

(defn foo []
(<!! (go (dosync
(doseq [i (range 10)]
(alter bar conj (<! c)))))))



 Comments   
Comment by Timothy Baldridge [ 16/Aug/13 9:08 AM ]

There are two problems with the example given.

a) dosync wraps the body of the body of the transaction in a fn. Go block translation stops at fn boundaries. The same applies to doseq.

b) The bigger problem is that this example code is incorrect. A transaction body may executed multiple times in that case some messages received from the channel may be dropped.

Closing this issue as the examples are flawed. However I will recommend that you look into doing the takes outside of the transaction, and then using a function to execute the transaction outside the body of a go.





[ASYNC-19] Exceptions hang return channel of go blocks Created: 19/Aug/13  Updated: 19/Aug/13  Resolved: 19/Aug/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Brian Kirkbride Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: None


 Description   

If the body of a (go) block throws an exception, the return channel hangs forever. It is unclear whether this is intended behavior or not. The behavior of (thread) blocks differs and is what I would have expected.

For example:

(<!! (go (/ 1 0)))
; hangs forever
(<!! (thread (/ 1 0)))
; returns nil immediately

Closing the channel is definitely more convenient. It's arguable that the caller is responsible for choosing their own failure semantics, but it should probably be consistent between (thread) and (go).

Would it make sense to wrap `body` with `(try ~@body (catch Throwable t# nil))` inside of the (go) macro?



 Comments   
Comment by Timothy Baldridge [ 19/Aug/13 4:33 PM ]

Fixed in https://github.com/clojure/core.async/commit/5f1d08a390a460b0408563c3118a82a81b3fd083





[ASYNC-23] Support channel buffers of unlimited size Created: 10/Sep/13  Updated: 15/Sep/13  Resolved: 15/Sep/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Constantine Vetoshev Assignee: Timothy Baldridge
Resolution: Declined Votes: 0
Labels: None
Environment:

Clojure
ClojureScript


Attachments: Text File 0001-Add-unlimited-size-buffer-implementation.patch    
Patch: Code and Test

 Description   

It is sometimes useful to use buffered async channels and not worry about either pre-allocating their size, or the way sliding and dropping buffers can lose potentially critical data passing through the channel.

The attached patch adds support for clojure.core.async/unlimited-buffer and cljs.core.async/unlimited-buffer for this purpose.



 Comments   
Comment by Timothy Baldridge [ 15/Sep/13 3:55 PM ]

One of the key aspects of core.async is that back-pressure and sliding/dropping buffers allow for decoupling of processes. A unbounded queue introduces many problems. Now a incorrectly designed system can crash, but not for some time. With the other buffer types a bug in the system will either a) allow producers to continue, or b) backup the producers allowing for easier debugging.

This patch doesn't really fit with CSP theory. And one of the main goals of core.async is to make users recognize where there are unbounded buffers, and allow them to remove them. Closing as this doesn't fit with the goals of the library.





[ASYNC-2] incorrect behavior in CLJS when using <! in loop/recur binding Created: 11/Jul/13  Updated: 27/Sep/13  Resolved: 27/Sep/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Timothy Baldridge
Resolution: Declined Votes: 0
Labels: None


 Description   
(loop [x (<! c)]
   ...)

does not work correctly, you will get nil values on some reads off this channel, you have to write

(loop []
  (let [x (<! c)]
    ...))

in order to only get nil when the channel closes.



 Comments   
Comment by Alexander Redington [ 12/Jul/13 10:48 AM ]

David Nolen I have tried to reproduce on https://github.com/aredington/core.async/blob/ASYNC-2-TEST/src/test/clojure/clojure/core/async/ioc_macros_test.clj#L191 but cannot generate failures. Is there a way to adjust the test to more reliably provoke failure?

Comment by David Nolen [ 26/Jul/13 9:27 AM ]

Sorry I should have been more specific this appears to affect ClojureScript core.async not Clojure.

Comment by Timothy Baldridge [ 27/Sep/13 8:21 AM ]

Can't reproduce





[ASYNC-20] Case macro in go block ignores default expression Created: 20/Aug/13  Updated: 27/Sep/13  Resolved: 27/Sep/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Leon Grapenthin Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: bug, go
Environment:

Clojure 1.5.1 in the JVM, core.async-0.1.0-20130819.220150-69



 Description   

To reproduce the error use this code:
(go (case true
false false
nil))

An IllegalArgumentException will be thrown (as if there was no default expression).
Exception in thread "async-dispatch-46" java.lang.IllegalArgumentException: No matching clause: true



 Comments   
Comment by Timothy Baldridge [ 27/Sep/13 8:34 AM ]

fixed in: https://github.com/clojure/core.async/commit/f9b24552cf4f6b8b86f3377c7b7a42a618a9fd76





[ASYNC-26] putting on a mult with no chans tapped breaks the mult badly Created: 07/Oct/13  Updated: 31/Oct/13  Resolved: 31/Oct/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Leon Grapenthin Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: None


 Description   

This is happening because of
;;wait for all
(<! dchan)

(https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L664)

With no channels in the mult the helper function done will never be invoked and the mult will never work again.
If this is intended behaviour an exception would be nice.



 Comments   
Comment by Timothy Baldridge [ 31/Oct/13 9:19 AM ]

Fixed in: https://github.com/clojure/core.async/commit/3f98058f168a5e0bec67e662fadc5c13c97b1500#diff-5c087e8e400be45f4d03e0a618ef9d46





[ASYNC-24] dosync does not work inside go macro Created: 15/Sep/13  Updated: 31/Oct/13  Resolved: 31/Oct/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Michael Ummels Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: bug,, go
Environment:

Clojure 1.5.1 in the JVM, core.async-0.1.0-20130827.050117-78"



 Description   

The following code results in an exception:

=> (go (dosync nil))

CompilerException java.lang.RuntimeException: No such var: clojure.core/runInTransaction



 Comments   
Comment by Michael Ummels [ 09/Oct/13 2:05 AM ]

Fixed in master. Please close.

Comment by Timothy Baldridge [ 31/Oct/13 9:20 AM ]

Fixed in master





[ASYNC-33] core.async needs to be updated for 0.0-2024 Created: 08/Nov/13  Updated: 08/Nov/13  Resolved: 08/Nov/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: None


 Description   

ClojureScript has changed in a few important way behind the scenes and core.async taps into some of these details. Currently when building the test core.async stackoverflows.



 Comments   
Comment by David Nolen [ 08/Nov/13 2:04 PM ]

I poked around a bit Timothy but I don't see anything obvious and I don't know the internals quite well enough to understand why this would be. At first I thought I might have borked macros in some way, but ClojureScript builds just fine and core.match also seems unaffected.

Comment by David Nolen [ 08/Nov/13 5:08 PM ]

I sorted this out, this was because of the inlining macros for data structures, core.async convert these to function calls which just get inlined again creating a loop, fixed the inlining macros to emit constructor calls instead of literals.





[ASYNC-30] Broken namespace reference in async.cljs Created: 31/Oct/13  Updated: 10/Nov/13  Resolved: 10/Nov/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Colin Jones Assignee: Rich Hickey
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File cljs_core_ns.patch    

 Description   

On master currently:

WARNING: No such namespace: core at line 524 public/javascript/cljs/core/async.cljs

I'm not too savvy on the cljs internals, but this definitely seems to break our project's use of core.async with the latest core.async release (which we went to in order to try and get up to the latest cljs release).



 Comments   
Comment by Ghadi Shayban [ 10/Nov/13 12:16 PM ]

Fixed as of 1bf8cf4d528ede5 on Nov 1





[ASYNC-44] property access syntax within go blocks is broken Created: 08/Dec/13  Updated: 10/Dec/13  Resolved: 10/Dec/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Travis Vachon Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File async_44.patch     Text File property-access.patch    
Patch: Code and Test

 Description   

`(.-foo x)` is being compiled into `x._foo()` inside a go block.

Patch here:

https://github.com/clojure/core.async/pull/41



 Comments   
Comment by Travis Vachon [ 10/Dec/13 9:54 AM ]

add git am able patch

Comment by Timothy Baldridge [ 10/Dec/13 5:52 PM ]

fixed in master.





[ASYNC-47] It is odd that the thread macro does not maintain per-thread bindings, the way the go macro does Created: 10/Dec/13  Updated: 12/Dec/13  Resolved: 12/Dec/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Howard Lewis Ship Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: None


 Description   

As stated, it is odd that thread and go are dissimilar in this way; if there's a rationale for it, I'd prefer to see it documented; otherwise, it would be nice to see thread do what go does.



 Comments   
Comment by Timothy Baldridge [ 12/Dec/13 9:36 PM ]

You're right, it is. I'll get it fixed ASAP.

Comment by Timothy Baldridge [ 12/Dec/13 10:28 PM ]

Fixed in master





[ASYNC-56] Pubs fail (in CLJS only) if there are no subscribers for a topic Created: 19/Feb/14  Updated: 19/Feb/14  Resolved: 19/Feb/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Jonas Enlund Assignee: Rich Hickey
Resolution: Completed Votes: 0
Labels: None


 Description   

The following code throws "Uncaught Error: No protocol method Mux.muxch* defined for type null":

(def c (async/chan))
(def p (async/pub c :topic))
(async/put! c {:topic :foo})

If a sub is registered for the :foo topic everything works as expected. I suspect the reason is that this line is missing from the CLJS source.



 Comments   
Comment by David Nolen [ 19/Feb/14 8:23 AM ]

fixed https://github.com/clojure/core.async/commit/ca148ebf812576b9eaa777adac6927ac22349a62





[ASYNC-52] Go block run by multiple threads at the same time for a single chan instance Created: 29/Jan/14  Updated: 20/Apr/14  Resolved: 20/Apr/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Gerrit Jansen van Vuuren Assignee: Rich Hickey
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

I'm using channels instead of agents to provide serial access to resources.
The logic is: (ch is buffered)
go loop:
f = read ch
(f)

f is a function that in my test case writes to a output stream, sometimes f will close the output stream, and recreate a new one. The output stream is held in a shared atom. If the go block takes one value after another everything should run fine. The thing is I get an output stream closed exception. After several runs it 'seems' to me that the go block is run by different threads at the same time.

If I change the go block to a thread the error goes away.

To reproduce the error:
clone https://github.com/gerritjvv/fun-utils

and run in leiningen

(use 'fun-utils.chtest)
(test-star)

The file is https://github.com/gerritjvv/fun-utils/blob/master/src/fun_utils/chtest.clj

The go block is on line 24.



 Comments   
Comment by Gerrit Jansen van Vuuren [ 29/Jan/14 5:49 PM ]

please ignore and close this.
I've found the cause: I was creating a new channel on every write .





[ASYNC-60] close! should deblock putting operations like >!! Created: 23/Mar/14  Updated: 09/May/14  Resolved: 09/May/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Alexander Kauer Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: None
Environment:

[org.clojure/clojure "1.5.1"]
[org.clojure/core.async "0.1.278.0-76b25b-alpha"]



 Description   

When closing a full or bufferless channel then currently blocked insertions should be deblocked and treated as if they tried to insert the value into a closed channel in the first place. Currently the putting operation blocks forever.

Example:

(defn -main
"I don't do a whole lot ... yet."
[& args]
(let [ch (chan)]
(thread
(Thread/sleep 1000)
(close! ch)
(println "channel closed"))
(>!! ch 42)
(println "never reached")))

Yields only "channel closed" and keeps blocked forever.



 Comments   
Comment by Alexander Kauer [ 27/Mar/14 5:22 PM ]

Duplicate of Issue ASYNC-36

Comment by Timothy Baldridge [ 09/May/14 11:25 AM ]

this is a duplicate, but I added a note to the close! doc string to explain the semantics better.





[ASYNC-8] Add constrained read/write-only ports Created: 15/Jul/13  Updated: 09/May/14  Resolved: 09/May/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Brandon Bloom Assignee: Timothy Baldridge
Resolution: Declined Votes: 0
Labels: None


 Description   

Proof of concept patch here:

https://github.com/clojure/core.async/pull/20/files

As discussed in IRC, this adds support for read-only and write-only "ports", which are constrained wrappers around channels. Write-only ports allow both put and close operations, were as read-only ports allow only take operations. Unsupported operations throw.

I'm open to suggestions for better names than <port and >port.



 Comments   
Comment by Timothy Baldridge [ 09/May/14 11:28 AM ]

Do we do not have plans to implement this at this time, however, impl/ReadPort and impl/WritePort could accomplish this if needed. These interfaces are still considered "alpha" and may change, but if you need to write your own port< feel free to do so and maintain it in your project.





[ASYNC-21] CLJS -> ioc-macros/fixup-aliasses throws exception Created: 02/Sep/13  Updated: 09/May/14  Resolved: 09/May/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Creighton Kirkendall Assignee: Timothy Baldridge
Resolution: Declined Votes: 0
Labels: None

Attachments: Text File 0001-added-a-check-to-fixup-aliases-for-namespace-to-stop.patch    
Patch: Code

 Description   

Under certain circumstances I get the following exception when using a 'go' block.

Caused by: java.lang.ClassCastException: clojure.lang.Namespace cannot be cast to clojure.lang.Named
             core.clj:1505 clojure.core/name
        ioc_macros.clj:613 cljs.core.async.impl.ioc-macros/fixup-aliases
        ioc_macros.clj:625 cljs.core.async.impl.ioc-macros/eval4971[fn]
        ioc_macros.clj:110 cljs.core.async.impl.ioc-macros/all[fn]

This is caused by the calling (name ns) where ns is namespace instead of calling (ns-name) first. The exception is thrown by the 'go' block in 'basic-test' here: https://gist.github.com/ckirkendall/6415293



 Comments   
Comment by Ghadi Shayban [ 18/Nov/13 11:12 PM ]

Creighton, do you still encounter the issue against release 0.1.256.0-1bf8cf-alpha?

Comment by Timothy Baldridge [ 09/May/14 11:29 AM ]

Closed due to no further information.





[ASYNC-48] Recur fails within catch Created: 21/Dec/13  Updated: 09/May/14  Resolved: 09/May/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Gerrit Jansen van Vuuren Assignee: Timothy Baldridge
Resolution: Declined Votes: 0
Labels: bug


 Description   

This is related to
http://dev.clojure.org/jira/browse/ASYNC-7

Having a loop in a go block and the recur inside a catch statement causes an IllegalArgumentException.

The code is:

(go
(loop [i 0]
(try
(do
(+ 1 1))
(catch Exception e (do
(prn e)
(recur (inc i)))))))

;; IllegalArgumentException No implementation of method: :emit-instruction of protocol: #'clojure.core.async.impl.ioc-
;; macros/IEmittableInstruction found for class: clojure.core.async.impl.ioc_macros.Jmp clojure.core/-cache-protocol-fn
;;(core_deftype.clj:541)



 Comments   
Comment by Leon Grapenthin [ 25/Dec/13 9:14 AM ]

This doesn't work outside of a go block either.

Comment by Timothy Baldridge [ 09/May/14 11:30 AM ]

Closing due to example not being valid code.





[ASYNC-25] Dependency on clojurescript is introduced into clojure only projects Created: 05/Oct/13  Updated: 23/Jun/14  Resolved: 23/Jun/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Hugo Duncan Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

When using core.async in a clojure only project, a dependency on Clojurescript is introduced.

Consider making the clojurescript dependency have "provided" scope, or moving it to a :dev profile.



 Comments   
Comment by Alex Miller [ 23/Jun/14 10:05 AM ]

Looks like this was already done - seems to be marked provided in pom and does not show up as transitive dependency in using project.





[ASYNC-62] recur across try possible, leaks ExceptionFrames Created: 27/Mar/14  Updated: 23/Jun/14  Resolved: 23/Jun/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Philip Lewis Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None
Environment:

[org.clojure/clojure "1.5.1"]
[org.clojure/core.async "0.1.278.0-76b25b-alpha"]



 Description   

This shouldn't compile, but it does and generates nested ExceptionFrames until it crashes:

(go-loop [] (try (if 1 (recur))))

Without the if, it throws java.lang.IllegalArgumentException: No implementation of method: :emit-instruction of protocol: #'clojure.core.async.impl.ioc-macros/IEmittableInstruction found for class: clojure.core.async.impl.ioc_macros.Jmp.

Outside of a go block it throws an UnsupportedOperationException (either "can only recur from tail" or "cannot recur across try").



 Comments   
Comment by Alex Miller [ 23/Jun/14 10:59 AM ]

On latest CLJ version (0.1.303.0-886421-alpha), I see "java.lang.UnsupportedOperationException: Can only recur from tail position" from this code.





[ASYNC-28] try/catch inside go block may cause a reflection warning - 0.1.222.0-83d0c2-alpha Created: 08/Oct/13  Updated: 23/Jun/14  Resolved: 23/Jun/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Howard Lewis Ship Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

I have this code:

(go
  (try
     ...
    (catch Throwable t
          (l/errorf t "Acceptor %s exception: %s" channel-key (.getMessage t))
          (ctx/trigger-error-handlers t))))

I get a reflection warning: reference to field getMessage can't be resolved.

This does not occur if the same code is moved outside the go block.

My assumption is that an implicit type hint (t is of type Throwable) is lost in the process of converting the block to a state machine.

Adding an explicit type hint does not fix the problem.

Further, the warning is associated with the line containing the go symbol, not the catch symbol. See ASYNC-27.



 Comments   
Comment by Alex Miller [ 23/Jun/14 11:04 AM ]

I tried this on the latest (0.1.303.0-886421-alpha) and saw no reflection warnings.

(require '[clojure.core.async :refer (go)])
(set! *warn-on-reflection* true)
(go 
  (try 1 
    (catch Throwable t (println "Got ex: " (.getMessage t)))))

If you still see this, please provide an example that is reproducible, thanks!





[ASYNC-70] documentation of thread macro should include behavior of nil (closes the channel) Created: 15/May/14  Updated: 23/Jun/14  Resolved: 23/Jun/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Howard Lewis Ship Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: reader
Environment:

0.1.278.0



 Description   

I needed the ability to invoke some code in a thread, and have the channel close if nil was returned.

Digging though the code, I discovered it already does this, but it is no documented in the docstring.

I'll supply a patch shortly.



 Comments   
Comment by Alex Miller [ 23/Jun/14 11:15 AM ]

The thread docstring says: "Returns a channel which will receive the result of the body when completed." The special case of a null return value is actually handled by ignoring it (because you are not allowed to explicitly put nils on a channel). The channel is closed on completion regardless. I'm not sure I get what needs to be added here and no patch, so closing. Reopen if there is a concrete suggestion to evaluate.





[ASYNC-75] alts!! not working on a channel which is subscribed to a pub-channel Created: 23/Jun/14  Updated: 24/Jun/14  Resolved: 24/Jun/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Daniel Ziltener Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None
Environment:

Clojure 1.6.0, core.async 0.1.303.0-886421-alpha



 Description   

Error message: Exception in thread "main" java.lang.UnsupportedOperationException: count not supported on this type: ManyToManyChannel

Minimal failing case:

(require '[clojure.core.async :refer (chan pub sub put! alts!!)])
(def out (chan))
(def publisher (pub out #(:topic %)))
(def s (chan))
(sub publisher :1 s)

(put! out {:topic :1 :content "Yes!"})
(alts!! s :default "Oh no.")


 Comments   
Comment by Alex Miller [ 24/Jun/14 6:51 AM ]

Your use of alts!! has a bug - the ports passed to it is expected to be a vector, not a single operation:

(alts!! [s] :default "Oh no.")





[ASYNC-76] Exceptions cannot be captured by default uncaught exception handler Created: 02/Jul/14  Updated: 06/Aug/14  Resolved: 06/Aug/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Stuart Sierra Assignee: Stuart Sierra
Resolution: Completed Votes: 6
Labels: None

Attachments: Text File 0001-ASYNC-76-do-not-catch-exceptions-on-thread-pool.patch     Text File 0002-ASYNC-76-propagate-exceptions-with-tests.patch    
Patch: Code and Test
Approval: Ok

 Description   

Both core.async thread pools have a try/catch which catches and prints exceptions thrown in callbacks. This prevents application code from using the built-in mechanisms of the JVM to handle exceptions on arbitrary threads, namely Thread.setDefaultUncaughtExceptionHandler

In addition, the pool for 'thread' and 'thread-call' does not close the channel when an exception is thrown, which may lead to deadlocks.

Current Patch: 0002-ASYNC-76-propagate-exceptions-with-tests.patch

Approach: For the callback/go thread pool, do not catch exceptions at all. For the 'thread' pool, remove the 'catch' and close the channel in a 'finally'.

Background: Printing exceptions was added shortly after changing the arity to the 'put!' callback, to aid in debugging, see commit 9fcae995. Prior to this, the 'thread-call' function has always dropped exceptions silently; see commit 0b8e6171.

Duplicate of ASYNC-71 and similar to ASYNC-61, both of which request that the thread pools dispatch errors to a handler function Var which application code can alter.

An earlier issue (no JIRA ticket) occurred when tasks were submitted to the ThreadPoolExecutor with .submit, which returns a Future, instead of .execute.



 Comments   
Comment by Timothy Baldridge [ 03/Jul/14 8:13 AM ]

These threads are created in a fixed size thread pool. Won't you need to set the exception handler on the Executor constructor instead of on the thread itself?

Comment by Stuart Sierra [ 03/Jul/14 8:18 AM ]

No, the default uncaught exception handler is global for the whole JVM. Thread.setDefaultUncaughtExceptionHandler is static.

The exception handler can be overridden on a per-thread or per-thread-group basis.

Comment by Alex Miller [ 06/Aug/14 10:23 AM ]

applied to master





[ASYNC-80] Fix documentation (or code) - related to "transformer" and deprecated counterparts Created: 28/Jul/14  Updated: 07/Aug/14  Resolved: 07/Aug/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Max Penet Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

When looking at the documentation now there are a bunch of functions marked as deprecated with the following message:
"Deprecated - this function will be removed. Use transformer instead"

However the `transformer` doesn't exist yet in the currently released version, or master for that matter...
It would be welcome to fix the doc for those who are using the various transformer functions already, even if they are deprecated.






[ASYNC-84] Issue with (require [clojure.core.async :as async]) Created: 08/Aug/14  Updated: 02/Sep/14  Resolved: 02/Sep/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Adam Krieg Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

I was attempting to try out the new transducer stuff with core.async, but was thwarted by namespace issues.

(ns my-ns
(require [clojure.core.async :as async]))

Yields:

java.lang.IllegalArgumentException: No single method: add_BANG_STAR of interface: clojure.core.async.impl.protocols.Buffer found for function: add!* of protocol: Buffer

My dependencies are as follows:

<dependency>
<groupId>org.clojure</groupId>
<artifactId>clojure</artifactId>
<version>1.7.0-alpha1</version>
</dependency>

<dependency>
<groupId>org.clojure</groupId>
<artifactId>core.async</artifactId>
<version>0.1.319.0-6b1aca-alpha</version>
</dependency>



 Comments   
Comment by Ghadi Shayban [ 11/Aug/14 11:30 PM ]

This sounds like a code reloading issue. Have you tried removing your target/ directory and restarting the REPL?

Totally unrelated, but ns declarations take keyword :require instead of symbol.

Comment by Alex Miller [ 02/Sep/14 9:41 AM ]

Can't reproduce





[ASYNC-6] alts! assumes nth works on ports argument Created: 15/Jul/13  Updated: 27/Sep/13  Resolved: 27/Sep/13

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Brandon Bloom Assignee: Timothy Baldridge
Resolution: Completed Votes: 0
Labels: None


 Description   

The docstring for alts! reads:

ports is a set of channel endpoints, which
can be either a channel to take from or a vector of
[channel-to-put-to val-to-put], in any combination.

However, trying to use an actual set yields the following exception:

java.lang.UnsupportedOperationException: nth not supported on this type: PersistentHashSet



 Comments   
Comment by Brandon Bloom [ 07/Aug/13 2:32 PM ]

Discussed at length in IRC on Aug 7th: http://www.raynes.me/logs/irc.freenode.net/clojure/2013-08-07.txt

Comment by Rich Hickey [ 07/Aug/13 9:28 PM ]

The documentation should be changed. alts requires an efficiently nth-able collection (e.g. a vector), else it will be slow.

https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L183

If CLJS supports nth on sets it is broken.

Comment by Brandon Bloom [ 07/Aug/13 9:52 PM ]

> alts requires an efficiently nth-able collection

Is that the case? Or does alts actually only require efficiently sampling a single element from a collection?

Efficient nth is a reasonable proxy, since the only choice we have for randomness is rand-int. However, one could imagine a CollSample protocol that would allow efficient random choice leveraging data-structure-specific knowledge, much as CollReduce works. Given the world as it exists now, I agree that this is a doc bug.

> If CLJS supports nth on sets it is broken.

That's the conclusion we came to in IRC. David quickly fixed this:
https://github.com/clojure/clojurescript/commit/a113b08a8c2811b0590cc6a36b2e9e5adc1c4c1e

Comment by Timothy Baldridge [ 27/Sep/13 8:47 AM ]

fixed in master





[ASYNC-53] Definition of UnblockingBuffer Protocol makes core.async incompatible with clojure 1.4 Created: 03/Feb/14  Updated: 23/Jun/14  Resolved: 23/Jun/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Kuldeep Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None

Attachments: Text File 0001-Compatibility-with-1.4.patch    
Patch: Code

 Description   

An empty protocol could not be compiled with clojure 1.4. I have attached a patch to show the problem locations.

Thanks



 Comments   
Comment by Alex Miller [ 23/Jun/14 8:53 PM ]

core.async is only intended to be compatible with Clojure 1.5.1+.





[ASYNC-82] Channels should accept Metadata Created: 02/Aug/14  Updated: 03/Aug/14  Resolved: 03/Aug/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Alexander Kiel Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Currently channels do not implement IObj and so do not accept metadata. My use case is no annotate channels with a name so that I can print out its name after an alts!.



 Comments   
Comment by Ghadi Shayban [ 03/Aug/14 10:09 PM ]

For efficiency reasons, channels are plain deftypes, which don't accept metadata.

Since channels are identities, they can be used in a map or set, and you can store the names or info out-of-band. May I suggest the following pattern:

(let [in (chan)
      out (chan)

      names {in :request
             out :response}
      val (rand-int 50)
      [v ch] (alts! [in [out val]])]
  (names ch))




[ASYNC-81] Spurious Closure warnings when using new ClojureScript dependency Created: 01/Aug/14  Updated: 04/Aug/14  Resolved: 04/Aug/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

Closure now emits a warning if core.async generates code with dead branches.



 Comments   
Comment by Ghadi Shayban [ 03/Aug/14 10:10 PM ]

David, do you have a minimal reproducing example?

Comment by David Nolen [ 04/Aug/14 7:57 AM ]

Sorry for not looking into this more closely first. It turns out the pattern of (assert nil "text") is the culprit - it compiles to a JavaScript if statement with null as the test and null as the success statement. We should drop this pattern for a simple throw in my opinion.

Comment by David Nolen [ 04/Aug/14 12:37 PM ]

this is fixed in master https://github.com/clojure/core.async/commit/41262e26b4d2b3070d23f927c25f585d9dc48951. The other dead code warnings from Closure needed to addressed in the ClojureScript compiler itself which is also resolved https://github.com/clojure/clojurescript/commit/8013f0fd0a7803c01efca90e757d316c0a1e1ec0





[ASYNC-89] mistake in core.async put! docstring Created: 02/Sep/14  Updated: 02/Sep/14  Resolved: 02/Sep/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Bruce Adams Assignee: Bruce Adams
Resolution: Completed Votes: 0
Labels: None

Attachments: File docstring.diff    
Patch: Code
Approval: Vetted

 Description   

In [1], correct statement should be "passing false iff port is already closed" instead of current "passing true iff port is already closed".

Current behavior is that put callback fn gets true if a channel is not already closed:

user=> (require '[clojure.core.async :as async])
nil
user=> (def c (async/chan 1))
#'user/c
user=> (async/put! c :foo #(println "got " %))
got  true
true
user=> (async/close! c)
nil
user=> (async/put! c :foo #(println "got " %))
got  false
false

From Jozef Wagner in https://groups.google.com/forum/#!topic/clojure-dev/zduW2jMndZ4

[1] https://github.com/clojure/core.async/blob/422f8b25f0c4d5e3aea5113436c735e553422be7/src/main/clojure/clojure/core/async.clj#L140






[ASYNC-31] put! does not throw on closed channel Created: 02/Nov/13  Updated: 02/Sep/14  Resolved: 02/Sep/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Chris Perkins Assignee: Unassigned
Resolution: Duplicate Votes: 1
Labels: None
Environment:

rev 1bf8cf4



 Description   

The docstring of put! says "Will throw if closed". However, put!-ing to a closed channel appears to succeed, and even calls the supplied callback.

I'm not sure which is incorrect - the behavior or the docstring (or my intepretation of it) - but it does appear that the implementation of mult is expecting an exception from put!, in order to do cleanup.



 Comments   
Comment by Justin Balthrop [ 10/Feb/14 4:53 PM ]

The doc string for put! no longer says "Will throw if closed" for clojure.core.async, though it does still say this for cljs.core.async (and doesn't seem to work).

It looks like Rich started switching put! to return true unless the channel is closed in cf8dc1bf207e646c14b2bf44763737fcb5f08c78. The docstring reflects this change, but from my testing, put! still always returns nil.

Comment by Sung Pae [ 02/Apr/14 3:25 PM ]

Since this is likely a docstring mismatch, I'd like to add that the docstring for clojure.core.async/put states:

Asynchronously puts a val into port, calling fn1 (if supplied) when complete, passing true iff port is already closed.

fn1 is passed `false` when the port is closed, not `true`.

Comment by Alex Miller [ 02/Sep/14 9:39 AM ]

Docstring addressed with ASYNC-89





[ASYNC-38] keep</> instead of map</> Created: 18/Nov/13  Updated: 02/Sep/14  Resolved: 02/Sep/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Leon Grapenthin Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: documentation, enhancement, errormsgs


 Description   

One problem with using map< is when the supplied function returns nil. In such case (using the latest implementation from core.async [org.clojure/core.async "0.1.256.0-1bf8cf-alpha"]) one can take nil from a channel created with map<. This is otherwise only possible with closed channels. Putting nil on a channel normally throws an IllegalArgumentException.

With the current implementation of map< it is not possible to determine whether the source-channel was closed or the supplied function returned nil.

Notice that putting onto a channel created with map> throws an IllegalArgumentException when the supplied function returns nil as if you would put nil onto a channel.

My proposal is to add keep</> (where nil values returned from the supplied function are ignored and nothing is put) to the core library or to implement map</> as keep</> since having a real map</> instead of keep</> hardly makes sense when nil is not permitted anyways.



 Comments   
Comment by Leon Grapenthin [ 24/Apr/14 3:44 AM ]

It is still an issue in "0.1.278.0-76b25b-alpha" that you can only use impl.protocols/closed? to consistently determine whether a channel created with map</> was closed - if nil is one of your predicates return values.

Of course, you could use a predicate that never returns nil. But what should be the benefit of map</> being able to magically pass nil while everything else isn't?

Comment by Alex Miller [ 02/Sep/14 9:43 AM ]

All of the transformation functions (like map<) are deprecated and will go away to be replaced with applying transducers to channels.





[ASYNC-50] Add bang(!) to the names of channel ops with side effects Created: 16/Jan/14  Updated: 02/Sep/14  Resolved: 02/Sep/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Jozef Wagner Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Some channel ops immediatelly change the given channel, thus they have side effects. This include async/map, filter<, remove<, mapcat<, pipe, split, reduce, onto-chan, etc. All 'mutating' basic channel operations have bang at the end of their name (<Unable to render embedded object: File (, >) not found., alt!, ...). If we want to be consistent with this, bang should be added to every channel function which has side effects.



 Comments   
Comment by Alex Miller [ 02/Sep/14 9:56 AM ]

Rich named these and there are no plans to change them.





[ASYNC-88] Add Sonatype repository info to README for unreleased library Created: 27/Aug/14  Updated: 02/Sep/14  Resolved: 02/Sep/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Bridget Hillyer Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: documentation


 Description   

It could be confusing for those not very familiar with Leiningen, Maven, etc. that there is a separate way to obtain SNAPSHOT versions of libraries vs. Released versions of libraries.

I believe an easy fix would be to have the following information directly in the README of unreleased contrib libraries (of which core.async is one):

To use Clojure and contrib library SNAPSHOTS in your Leiningen project, add the following to your project.clj:

:repositories {"sonatype-oss-public" "https://oss.sonatype.org/content/groups/public/"}



 Comments   
Comment by Alex Miller [ 02/Sep/14 9:50 AM ]

Done.

Comment by Alex Miller [ 02/Sep/14 10:02 AM ]

Actually, I have un-done this for core.async as we don't ever release SNAPSHOT versions of core.async, so it's thus a bit confusing. The canonical place we point people for this repo setup info is:

http://dev.clojure.org/display/community/Maven+Settings+and+Repositories

Comment by Bridget Hillyer [ 02/Sep/14 10:11 AM ]

I realized that this does not affect core.async after I made this ticket. Maybe something was down that day so I couldn't get the canonical release? So, right, this is not valid for core.async. But it would be for other (contrib?) libraries that do get SNAPSHOTs released.

The setup info that you pointed out:
http://dev.clojure.org/display/community/Maven+Settings+and+Repositories
would probably be useful from a usability standpoint in the READMEs themselves, including core.async.





[ASYNC-59] Channel returned by cljs.core.async/map> is missing protocol method Channel.closed? Created: 08/Mar/14  Updated: 10/Sep/14  Resolved: 02/Sep/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Kevin Neaton Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug, patch
Environment:

[org.clojure/clojure "1.5.1"]
[org.clojure/clojurescript "0.0-2173"]
[org.clojure/core.async "0.1.278.0-76b25b-alpha"]


Attachments: Text File 0001-Fixed-map-by-including-impl.-for-closed.patch    
Patch: Code

 Description   

E.g.

(let [ch (->> (chan) (map> inc) (filter> even?))]
  (doseq [i (range 10)] (put! ch i)))

When filter> checks to see if the channel returned by map> is closed?, this code fails because the channel returned by map> does not implement the Channel.closed? protocol method.



 Comments   
Comment by Alex Miller [ 02/Sep/14 9:54 AM ]

map> and filter> have been deprecated and will be removed in a future release. They have been replaced with applying transducers to a channel which is now available.

Comment by Kevin Neaton [ 10/Sep/14 9:08 AM ]

Great, thanks for the update.





[ASYNC-87] Add variant of pipe which accepts mapping fn Created: 24/Aug/14  Updated: 02/Sep/14  Resolved: 02/Sep/14

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Brandon van Beekum Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

I'd propose something like:

(pipe from to mapping-fn ex-handler)

Currently I am doing the following to patch two channels together with a transform fn:

(defn my-pipe [from to f exh]
(let [map-ch (chan 1 f exh)]
(async/pipe from map-ch)
(async/pipe map-ch to)))



 Comments   
Comment by Alex Miller [ 02/Sep/14 9:16 AM ]

You can do this now with async/pipeline (with concurrent execution, blocking, async, etc):

(async/pipeline 1 to f from)





Generated at Tue Sep 30 16:55:40 CDT 2014 using JIRA 4.4#649-r158309.