<< Back to previous view

[ASYNC-109] Clarify timeout doc to mention that close! should not be called on a timeout channel Created: 11/Dec/14  Updated: 12/Dec/14

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

Type: Defect Priority: Major
Reporter: Ryan Neufeld Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: documentation

Attachments: Text File clarify-timeout-doc.patch    
Patch: Code

 Description   

After running into a race-condition involving closed timeout channels, it seems like it would be appropriate to mention that `close!` should never be called on a timeout channel in its docstring. The attached patch tweaks the doc string to that effect. Please advise if you'd like the wording changed a bit.



 Comments   
Comment by Howard Lewis Ship [ 12/Dec/14 11:03 AM ]

Alternately/additionally, it would be nice if close! on a timeout channel would throw an exception.





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





Generated at Fri Dec 19 06:24:16 CST 2014 using JIRA 4.4#649-r158309.