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





Generated at Fri Aug 01 21:34:22 CDT 2014 using JIRA 4.4#649-r158309.