<< Back to previous view

[ASYNC-4] record literals become ordinary maps Created: 15/Jul/13  Updated: 23/Aug/13

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

Type: Defect Priority: Major
Reporter: Alex Miller Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

(Copied from GitHub issue #13 - https://github.com/clojure/core.async/issues/13)

clojure.core.async> (defrecord Foo [x])
clojure.core.async.Foo

Works:

clojure.core.async> (def f (Foo. 4))
#'clojure.core.async/f
clojure.core.async> (<!! (go f))
#clojure.core.async.Foo{:x 4}

Turns record into a map:

clojure.core.async> #clojure.core.async.Foo{:x 4}
#clojure.core.async.Foo{:x 4}
clojure.core.async> (<!! (go #clojure.core.async.Foo{:x 4}))
{:x 4}


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

0c6e663493 contains a fix on the Clojure side, would appreciate help porting to cljs.

Comment by David Nolen [ 08/Aug/13 8:35 AM ]

I think on the ClojureScript we'll have to query the analyzer to know if we have a record or not.





[ASYNC-8] Add constrained read/write-only ports Created: 15/Jul/13  Updated: 23/Aug/13

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

Type: Defect Priority: Major
Reporter: Brandon Bloom Assignee: Unassigned
Resolution: Unresolved 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.






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

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

Type: Defect Priority: Major
Reporter: Hugo Duncan Assignee: Rich Hickey
Resolution: Unresolved 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.






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

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

Type: Defect Priority: Major
Reporter: Howard Lewis Ship Assignee: Rich Hickey
Resolution: Unresolved 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.






[ASYNC-32] onto-chan retains head of input sequence causing OutOfMemoryError Created: 06/Nov/13  Updated: 06/Nov/13

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

Type: Defect Priority: Major
Reporter: Brian Lubeski Assignee: Rich Hickey
Resolution: Unresolved Votes: 0
Labels: None
Environment:

org.clojure/core.async 0.1.242.0-44b1e3-alpha


Attachments: File patch.clj    
Patch: Code

 Description   

Consider the following example:

(let [c (a/chan)]
(a/onto-chan c (iterate inc 0))
(while true
(a/<!! c)))

onto-chan is holding on to the head of the input sequence as it is unfolded, resulting in an (eventual) OutOfMemoryError.

I've attached a diff showing changes I made to onto-chan that fixed the problem for me.






[ASYNC-21] CLJS -> ioc-macros/fixup-aliasses throws exception Created: 02/Sep/13  Updated: 18/Nov/13

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

Type: Defect Priority: Major
Reporter: Creighton Kirkendall Assignee: Rich Hickey
Resolution: Unresolved 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?





[ASYNC-46] Add optional default channel to 'pub' Created: 09/Dec/13  Updated: 09/Dec/13

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

Type: Enhancement Priority: Major
Reporter: Steffen Dienst Assignee: Rich Hickey
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-Add-default-channel-for-pub.patch    
Patch: Code and Test

 Description   

If there is no subscriber for a topic the message gets silently dropped. I suggest to add an optional default channel that receives all those messages. The default channel can then be used in scenarios, where the complete set of topics might be unknown beforehand.
This functionality resembles the 'dead letter' pattern in messaging systems.






[ASYNC-48] Recur fails within catch Created: 21/Dec/13  Updated: 25/Dec/13

Status: Open
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: Unresolved 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.





[ASYNC-51] Core.async memory leak in Safari and Mobile Safari Created: 21/Jan/14  Updated: 23/Jan/14

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

Type: Defect Priority: Major
Reporter: Bruce Hauman Assignee: Rich Hickey
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Mobile Safari on iOS 7.0; Safari 6.1 on OSX Lion



 Description   

Chaining together channels apparently leaks memory in Safari.

A statement such as

(def test [input-chan]
(map< identity (map< identity (map< identity input-chan))))

will leak memory when the channels are used. The longer the chain the more memory.

I have created an example repository and an example page.

The repo and the example code is here:
https://github.com/bhauman/checkmemleak/blob/master/src/checking_safari_leak/core.cljs

The demonstration page is here:
This link will leak
http://rigsomelight.com/checkmemleak/?leak=true
This link will not
http://rigsomelight.com/checkmemleak

The leak is pretty darn severe.



 Comments   
Comment by Bruce Hauman [ 21/Jan/14 4:55 PM ]

I have just confirmed this is also a problem in Safari Version 7.0.1 (9537.73.11) on Mavericks.

Comment by Bruce Hauman [ 23/Jan/14 7:13 PM ]

I updated the example page.

http://rigsomelight.com/checkmemleak/index.html

This link wont leak:
http://rigsomelight.com/checkmemleak/index.html#comp-partial

This link will leak:
http://rigsomelight.com/checkmemleak/index.html#map<

There is navigation to try the different implementations and optimization modes.

To be clear map<-chain, custom-map, map<, and map> all exhibit the leak in :none and simple optimization modes.





[ASYNC-49] cljs IOC macro issue with double-dot form Created: 12/Jan/14  Updated: 12/Jan/14

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

Type: Defect Priority: Major
Reporter: Paul Butcher Assignee: Rich Hickey
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ClojureScript 0.0-2138
core.async 0.1.267.0-0d7780-alpha



 Description   

This ClojureScript compiles and runs as expected:

(let [circle (dom/getElement "circle")]
  (go-loop [x 20]
    (<! (timeout 10))
    (set! (.-value (.-baseVal (.-cx circle))) x)
    (recur (inc x))))

But if I change the set! line to:

(set! (.. circle -cx -baseVal -value) x)

I get the following error:

Wrong number of args (3) passed to: core$-DOT

For further discussion see https://groups.google.com/d/topic/clojurescript/ONMaEho4K0c/discussion






[ASYNC-27] Compilation errors inside go block always reported as first line of block Created: 08/Oct/13  Updated: 11/Feb/14

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

Type: Defect Priority: Major
Reporter: Howard Lewis Ship Assignee: Rich Hickey
Resolution: Unresolved Votes: 1
Labels: errormsgs


 Description   

I've noticed that when there are any errors inside a go block, the line number of the error is always the line containing the go symbol.

I suspect that some meta data on the forms that are converted into a state machine is being lost in the process.

This is quite annoying and quite leaky (in the abstraction sense). It makes it that much harder to track down the source of errors.



 Comments   
Comment by Timothy Baldridge [ 22/Nov/13 2:49 PM ]

Working on this, may be a few weeks out yet.

Comment by Hugo Duncan [ 11/Feb/14 5:18 PM ]

This effects both compilation errors and line numbers in stack trace frames.





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

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

Type: Defect Priority: Major
Reporter: Philip Lewis Assignee: Rich Hickey
Resolution: Unresolved 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").






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

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

Type: Defect Priority: Major
Reporter: Alexander Kauer Assignee: Rich Hickey
Resolution: Unresolved 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





[ASYNC-43] queue-dispatcher should fall back to process.nextTick if setImmediate is not available Created: 07/Dec/13  Updated: 05/Mar/14

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

Type: Defect Priority: Major
Reporter: Travis Vachon Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: cljs

Attachments: Text File async_43.patch     Text File nextTick.patch    

 Description   

discussion here:

https://groups.google.com/forum/#!searchin/clojurescript/nextTick/clojurescript/RW1FMv0UoPE/hsMHI4SLKXYJ

discussion of the differences between setImmediate and nextTick here:

http://stackoverflow.com/questions/15349733/setimmediate-vs-nexttick

it sounds to me like nextTick should be ok, but I'm not familiar with the design decisions in the current implementation

I'm happy to create a patch - will do that shortly.



 Comments   
Comment by Travis Vachon [ 07/Dec/13 7:28 PM ]

patch here: https://github.com/clojure/core.async/pull/40

Comment by Travis Vachon [ 08/Dec/13 8:52 PM ]

just the code, not entirely sure how to test this, but have tested manually in the parse.com cloud code environment

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

add git am able patch

Comment by Travis Vachon [ 05/Mar/14 5:21 PM ]

just want to ping this issue - anything else it needs to be mergable? I'm using a core.async fork at the moment and would love to get back on the main line!





[ASYNC-42] (try (catch :default)) inside a cljs go block raises an exception Created: 07/Dec/13  Updated: 10/Dec/13

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

Type: Defect Priority: Major
Reporter: Travis Vachon Assignee: David Nolen
Resolution: Unresolved Votes: 1
Labels: cljs

Attachments: Text File async_42.patch     Text File try-catch-default.patch    

 Description   

test demonstrating issue and patch fixing it here: https://github.com/clojure/core.async/pull/39



 Comments   
Comment by Travis Vachon [ 08/Dec/13 8:51 PM ]

code + test

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

add {{git am}}able patch





[ASYNC-58] mult channel deadlocks when untapping a consuming channel whilst messages are being queued/blocked Created: 20/Feb/14  Updated: 22/Apr/14

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

Type: Defect Priority: Major
Reporter: Mathieu Gauthron Assignee: Rich Hickey
Resolution: Unresolved Votes: 0
Labels: deadlock, mult, untap
Environment:

Mac 10.7.5; java version "1.7.0_40"; [org.clojure/clojure "1.5.1"]; [org.clojure/core.async "0.1.267.0-0d7780-alpha"]; Tested with cider and emacs 24.3



 Description   

Use Case:

I have two (or more) listeners tapped onto a mult channel. I want to use them all then have one (or more) of them to leave at will without blocking the other consumer(s) or the publisher. Initially they work fine until one of them wants to stop listening. I thought the listener which drops out needs to (be a good citizen and) untap its channel from mult (otherwise a deadlock is systematic). However if messages are put into the mult before the leaving listener has had a chance to untap its channel, it creates a deadlock on the main thread (which is putting more messages simultaneously). I do not find a way to guarantee that I can untap the channel in time to avoid this race condition.

Other comments:
Once I have reproduced the deadlock, the repl is frozen until I interrupt with ctr-c.
I have also tried to close the tapped channel before untapping it but the result was the same.

Issue:
In the following snippet, the last (println "I'm done. You will never see this") is never reached. The publisher and the remaining consumer (consumer 1) are deadlocked even though consumer 2 was trying to leave in good terms.

Code:

(let [to-mult (chan 1)
m (mult to-mult)]

;;consumer 1
(let [c (chan 1)]
(tap m c)
(go (loop []
(when-let [v (<! c)]
(println "1 Got! " v)
(recur))
(println "1 Exiting!"))))

;;consumer 2
(let [c (chan 1)]
(tap m c)
(go (loop []
(when-let [v (<! c)]
(when (= v 42) ;; exit when value is not 42
(println "2 Got! " v)
(recur)))
(println "2 about to leave!")
(Thread/sleep 5000) ;; wait a bit to exacerbate the race condition
(untap m c) ;; before unsubscribing this reader
(println "2 Exiting."))))

(println "about to put a few messages that work")
(doseq [a (range 10)]
(>!! to-mult 42))
(println "about to put a message that will force the exit of 2")
(>!! to-mult 43)
(println "about to put a few more messages before reader 2 is unsubscribed to show the deadlock")
(doseq [a (range 10)]
(println "putting msg" a)
(>!! to-mult 42))
(println "I'm done. You will never see this"))

Output:
about to put a few messages that work
2 Got! 42
1 Got! 42
2 Got! 42
1 Got! 42
1 Got! 42
2 Got! 42
1 Got! 42
1 Got! 42
2 Got! 42
2 Got! 42
2 Got! 42
2 Got! 1 Got! 42
422 Got! 42

1 Got! 42
1 Got! 42
2 Got! 42
1 Got! 42
about to put a message that will force the exit of 2
1 Got! 42
2 Got! about to put a few more messages before reader 2 is unsubscribed to show the deadlock
42
putting msg 1 Got! 0
2 about to leave!
43
1 Got! 42
putting msg 1
putting msg 2
putting msg 3
1 Got! 42
2 Exiting.

Question: Is this expected? Is there a workaround?



 Comments   
Comment by Ghadi Shayban [ 22/Apr/14 10:18 AM ]

Mathieu, this is probably expected. It's important to note that to guarantee correct ordering/flow when using a mult, you should enforce it on the source/producer side of the mult, and not asynchronously on the tap side.

Mult will deref a stable set taps just before distributing a value to them, and does not adjust dynamically during value distribution except when a tap has been closed [1]. If you would like to stably untap without closing the tap you can/should let the 'producer' do it in an ordered fashion in between values on the input channel.

Knowing that a put occurred to a closed channel is new on release 0.1.278.

In general, walking away on the consuming side of a channel is tricky. Depending on the semantics of your processes, if the producer side of a channel isn't aware that a close! can happen from the consumer side, you might have to launch a draining operation.

(defn drain [c] (go (when (some? (<! c)) (recur))))

Golang disallows closing a read-only channel FWIW [2]

Better documentation is probably warranted.

[1] https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L680-L682
[2] http://golang.org/ref/spec#Close





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

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

Type: Defect Priority: Minor
Reporter: Jozef Wagner Assignee: Rich Hickey
Resolution: Unresolved 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.






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

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

Type: Defect Priority: Minor
Reporter: Kuldeep Assignee: Rich Hickey
Resolution: Unresolved 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






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

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

Type: Defect Priority: Minor
Reporter: Kevin Neaton Assignee: Rich Hickey
Resolution: Unresolved 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.






[ASYNC-61] Exceptions thrown inside go/thread blocks propagate up and out of ThreadPoolExcecutor Created: 24/Mar/14  Updated: 24/Mar/14

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

Type: Enhancement Priority: Minor
Reporter: Howard Lewis Ship Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: exceptions
Environment:

core.async 0.1.267.0-0d7780-alpha on JDK 1.7



 Description   

If a go or thread blocks throws an exception, there is nothing in Clojure to catch and handle (or report) the exception. Instead, it propagates up to the ThreadExcecutor which invokes its NO-OP afterExecute() method and is re-thrown, ultimately being displayed on the System.err:

Exception in thread "async-dispatch-32" java.lang.IllegalStateException: Fall down, go boom!
at flashiz.resources.orders$index.invoke(orders.clj:26)
at clojure.lang.Var.invoke(Var.java:411)
at clojure.lang.AFn.applyToHelper(AFn.java:159)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.core$apply.invoke(core.clj:617)
at io.aviso.rook$rook_dispatcher.invoke(rook.clj:225)
at flashiz.async$wrap_sync_handler$fn__9005.invoke(async.clj:34)
at flashiz.resources$authorize_async_rook_middleware$fn_9356$fn9402$state_machine3245auto__9403$fn_9405.invoke(resources.clj:21)
at flashiz.resources$authorize_async_rook_middleware$fn_9356$fn9402$state_machine3245auto___9403.invoke(resources.clj:21)
at clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:945)
at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:949)
at clojure.core.async.impl.ioc_macros$take_BANG_$fn__3261.invoke(ioc_macros.clj:958)
at clojure.core.async.impl.channels.ManyToManyChannel$fn__2256.invoke(channels.clj:80)
at clojure.lang.AFn.run(AFn.java:24)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)

It would be nice if execution of the go/thread block was wrapped in an exception handler that delegated to a default function to report the exception. My goal is to be able to alter that function to report it more nicely and/or write it to a persistent log file.






[ASYNC-40] do not transform forms that have :no-transform metadata attached Created: 29/Nov/13  Updated: 30/Nov/13

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

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Interaction between core.match clauses and the core.async transform is undesirable. core.async should respect some hook so that some forms are left alone. For example:

(match [x y]
  [1 2] ...
  [3 4] ...)

All code generated for [1 2] and [3 4] would have this metadata attached to it.



 Comments   
Comment by Rich Hickey [ 30/Nov/13 9:25 AM ]

Can you be more specific? This seems like a bad idea, and I wonder why it's desired.

Comment by David Nolen [ 30/Nov/13 2:12 PM ]

To show how bad the interaction is between core.async and a library like core.match that also generates a lot of code consider the following:

(defn foo [e]
  (match [e]
    [{:type :mouse :client-x x :client-y y}] [x y]
    [{:type :mouse :page-x x :page-y y}] [x y]
    [{:type :touch :page-x x :page-y y}] [x y]
    [{:type :key :char-code c}] c))

Without core.async, core.match produces a reasonable amount of code for this typical use of core.match to efficiently match maps - ~230 lines of pretty printed JavaScript.

But if the user wraps this typical expression in a go block:

(defn foo [in]
  (go (while true
        (let [[e c] (<! in)]
          (match [e]
            [{:type :mouse :client-x x :client-y y}] [x y]
            [{:type :mouse :page-x x :page-y y}] [x y]
            [{:type :touch :page-x x :page-y y}] [x y]
            [{:type :key :char-code c}] c)))))

It generates nearly 4200 lines of pretty-printed JavaScript. I fail to see the value of core.async transforming the optimized conditionals generated by core.match, it just generates 18X more code and the extra generated code is obviously useless - a user is matching a value, they cannot put arbitrary computations in the patterns.

https://gist.github.com/swannodette/7723758





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

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

Type: Defect Priority: Minor
Reporter: Chris Perkins Assignee: Rich Hickey
Resolution: Unresolved 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`.





[ASYNC-63] Variable called 'new' in vector in go block in CLJS causes "Object has no method 'call'" error Created: 07/Apr/14  Updated: 07/Apr/14

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

Type: Defect Priority: Minor
Reporter: James Henderson Assignee: Rich Hickey
Resolution: Unresolved Votes: 0
Labels: bug, cljs
Environment:

ClojureScript 0.0-2202, core.async 0.1.267.0-0d7780-alpha, openjdk 7u51


Attachments: File compiled-cljs.js     File test_cases.clj    

 Description   

I seem to be having trouble with the combination of:

  • a variable named 'new'
  • wrapped in a vector
  • after a <! call in a go block.

Removing any of these conditions seems to work fine.

I've attached a few minimal examples in test_cases.clj and the JavaScript that the first error compiles down to in compiled-cljs.js - the errors occur on line 4 (I think inst_39771 is 21 in this case)

An obvious workaround is not to name the variable 'new'

Please let me know if you need anything more from me, and please go easy on me if this is in the wrong place/badly labelled etc - it's my first Clojure JIRA bug report

Thanks,

James



 Comments   
Comment by James Henderson [ 07/Apr/14 4:07 PM ]

Sorry, just spotted there's a newer release of core.async - I've reproduced this with 0.1.278.0-76b25b-alpha as well.

James





[ASYNC-57] reify in go macro compile error Created: 20/Feb/14  Updated: 22/Apr/14

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

Type: Defect Priority: Minor
Reporter: Lijin Liu Assignee: Rich Hickey
Resolution: Unresolved Votes: 0
Labels: None
Environment:

[org.clojure/clojure "1.5.1"]
[org.clojure/core.async "0.1.267.0-0d7780-alpha"]



 Description   

(go
(reify java.util.Collection
(add [this o]
(println o)
(println this)
true)))

clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Unable to resolve symbol: this in this context



 Comments   
Comment by Ghadi Shayban [ 22/Apr/14 9:55 AM ]

Reassigning to minor. The go macro will obviously not rewrite parking ops inside the reify. Lifting the reify into a var is a decent workaround.





[ASYNC-55] Notification of items dropped from sliding/dropping buffers Created: 12/Feb/14  Updated: 22/Apr/14

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

Type: Enhancement Priority: Minor
Reporter: Chris Perkins Assignee: Rich Hickey
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File drop-notification.diff    
Patch: Code and Test

 Description   

I would like to know when items are dropped from sliding or dropping buffers, so that I can do things like logging and keeping metrics.

The attached patch has one possible mechanism for doing this, by adding an optional second argument to sliding-buffer and dropping-buffer - a one-argument function that will be called with dropped items.



 Comments   
Comment by Ghadi Shayban [ 22/Apr/14 10:41 AM ]

Hi Chris, I think this use-case can be handled the combination of a go process + collection directly without modification to the existing buffer impls. I'd be concerned about making buffers pay for a non-essential field.

I like using the library primitives to make sure they are minimally complete.

(If you really really want to make your own buffer, no one will stop you =) It's still an impl protocol, but it's relatively stable. Just beware that buffer operations run within the context of a channel lock, so make sure to dispatch the overflow function to the async threadpool using dispatch/run).





[ASYNC-39] Processes spawned by mix never terminate Created: 21/Nov/13  Updated: 24/Apr/14

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

Type: Defect Priority: Minor
Reporter: Leon Grapenthin Assignee: Rich Hickey
Resolution: Unresolved Votes: 0
Labels: chan, mix
Environment:

"0.1.256.0-1bf8cf-alpha"



 Description   

Once a mix has been created, the go-loop inside mix will always recur. Obviously, input-channels can be unmixed and the output-channel could be closed, but the process would still never terminate.

Probably mixes should support something like (stop) to to make the mix-associated process garbage-collectable. Operations on a stopped mix should probably throw.



 Comments   
Comment by Ghadi Shayban [ 22/Apr/14 10:44 AM ]

On 0.1.278 the mix process terminates when its output channel closes [1].

[1] https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L778

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

Yes, it has been fixed using the new return behavior of put!. (I can't find an option to close this issue)





[ASYNC-38] keep</> instead of map</> Created: 18/Nov/13  Updated: 24/Apr/14

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

Type: Enhancement Priority: Minor
Reporter: Leon Grapenthin Assignee: Rich Hickey
Resolution: Unresolved 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?





[ASYNC-54] MAX-QUEUE-SIZE has a wrong type-hint Created: 11/Feb/14  Updated: 11/Feb/14

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

Type: Defect Priority: Trivial
Reporter: Nicola Mometto Assignee: Rich Hickey
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-Fix-MAX-QUEUE-SIZE-type-hint-def-evaluates-the-metad.patch    

 Description   

Since `def` evaluated the metadata on the symbol by design, primitive type hints needs to be quoted to avoid resolving to the homonimous clojure.core function






Generated at Fri Apr 25 02:19:14 CDT 2014 using JIRA 4.4#649-r158309.