Re: Clojure docstring style

2016-05-15 Thread James Reeves 
On 16 May 2016 at 00:57, Christopher Small  wrote:
>
> Seems like this shouldn't be a problem as long as you only try to render a
> link if there's actually such a var.
>

You could have some text you wish to render as code, which doesn't relate
to a var but by coincidence happens to have the same name. For instance,
you might have a docstring that references the SQL `update` command, which
has the same name as a function in clojure.core. To my mind it's better to
be explicit about what you want to link.

- James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: :default catch blocks with core.async and clojurescript

2016-05-15 Thread Kevin Downey 
On 05/14/2016 09:31 PM, cameron wrote:
> I'm having an issue where :default catch blocks are not working in
> clojurescript when in a go block.
> 
> The following code prints "a str" as expected:
> 
> (prn (try
>(throw "a str")
>(catch :default e e )))
> 
> The same code in a go block results in an unhandled exception 
> (go (prn (try
> (throw "a str")
> (catch :default e e 
> 
> I can see an old core.async issue that added support for :default
> (http://dev.clojure.org/jira/browse/ASYNC-42) 
> but no other references, is this a regression or something I'm missing?
> 
> I'm using clojurescript  "1.8.51"  and core.async "0.2.374"
> 
> Cameron.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

You will likely find that (throw (js/String. "a str")) will work the
same in both.

This issue has two parts:

1. String literals are somehow not objects or something in javascript (I
don't entirely understand this, but I vaguely recall that it is a thing)

2. The go macro uses js/Object as the exception type in the "catch all"
exception handler it creates to emulate exception handling.

You can verify that the combination of these two things causes this
problem by playing with this code:

(try (throw "foo") (catch js/Object e :good))

(try (throw (js/String. "foo")) (catch js/Object e :good))

(try (throw "foo") (catch :default e :good))

The "Fix" for the issue you linked didn't change "js/Object" to
":default" in the catch all, so it didn't actually fix anything.

-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure docstring style

2016-05-15 Thread Christopher Small 

Seems like this shouldn't be a problem as long as you only try to render a 
link if there's actually such a var. This might be a little messier, but 
would make things (overall) nicer (I think) because you wouldn't have to 
think about a separate bit of syntax. The rendering would just happen 
differently depending on whether or not there was something to link to. I 
already do markdown in most of my docstrings anyway, and I'd prefer not 
having to rewrite a bunch of docstrings to take advantage of such a 
feature; I'm sure there are others with me as well :-)

This arguably violates least-surprise / separation of concerns, but in my 
opinion not so significantly that the costs outweigh the benefits (again, 
as long as you only tried to link if you knew it was a var).

My 2 cents...

Chris


On Sunday, May 15, 2016 at 2:03:02 PM UTC-7, James Reeves wrote:
>
> If the docstrings are written in markdown, this would conflict as 
> something in backticks isn't necessarily a var name.
>
> In Codox, I used the wiki-link style: [[clojure.core/map]].
>
> - James
>
> On 15 May 2016 at 18:40, cskksc  wrote:
>
>> Hello,
>> We are working on a new feature in CIDER which would parse a docstring 
>> and create hyperlinks that follow the functions/vars/interop-forms 
>> mentioned there.
>> It is very similar to the "See Also" links shown by ClojureDocs 
>> . Right now, we are using backticks to identify 
>> the reference forms and create links.
>>
>> So a function like;
>>
>> (defn test-mde
>>   "Does something with `user-ns/user-fn`.
>>Also see: `clojure.core/map`, `clojure.core/reduce`, `defn`"
>>   []
>>   (+ 1 1))
>>
>> would create hyperlinks for map, reduce, defn and user-ns/user-fn forms.
>>
>> What style do you tend to use in such docstrings ?
>> It would help us figure out whether to continue with the backticks or do 
>> something else, like adding a configuration variable for this.
>>
>> Thanks,
>> Chaitanya
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure docstring style

2016-05-15 Thread James Reeves 
If the docstrings are written in markdown, this would conflict as something
in backticks isn't necessarily a var name.

In Codox, I used the wiki-link style: [[clojure.core/map]].

- James

On 15 May 2016 at 18:40, cskksc  wrote:

> Hello,
> We are working on a new feature in CIDER which would parse a docstring and
> create hyperlinks that follow the functions/vars/interop-forms mentioned
> there.
> It is very similar to the "See Also" links shown by ClojureDocs
> . Right now, we are using backticks to identify
> the reference forms and create links.
>
> So a function like;
>
> (defn test-mde
>   "Does something with `user-ns/user-fn`.
>Also see: `clojure.core/map`, `clojure.core/reduce`, `defn`"
>   []
>   (+ 1 1))
>
> would create hyperlinks for map, reduce, defn and user-ns/user-fn forms.
>
> What style do you tend to use in such docstrings ?
> It would help us figure out whether to continue with the backticks or do
> something else, like adding a configuration variable for this.
>
> Thanks,
> Chaitanya
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Clojure docstring style

2016-05-15 Thread cskksc 
Hello,
We are working on a new feature in CIDER which would parse a docstring and 
create hyperlinks that follow the functions/vars/interop-forms mentioned 
there.
It is very similar to the "See Also" links shown by ClojureDocs 
. Right now, we are using backticks to identify 
the reference forms and create links.

So a function like;

(defn test-mde
  "Does something with `user-ns/user-fn`.
   Also see: `clojure.core/map`, `clojure.core/reduce`, `defn`"
  []
  (+ 1 1))

would create hyperlinks for map, reduce, defn and user-ns/user-fn forms.

What style do you tend to use in such docstrings ?
It would help us figure out whether to continue with the backticks or do 
something else, like adding a configuration variable for this.

Thanks,
Chaitanya

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why do transducers on channels need buffer size of at least 1?

2016-05-15 Thread Alex Miller 
(chan 0) is not actually valid (should just be (chan)) - I have a ticket to 
error on this more visibly.
http://dev.clojure.org/jira/browse/ASYNC-143

Trasducers may produce more than one value (per things like the mapcat 
transducer) and thus a buffer is required so that there is somewhere to put 
those values when they are produced. This is mentioned in the docstring for 
chan:
http://clojure.github.io/core.async/#clojure.core.async/chan

"If a transducer is supplied a buffer must be specified."



On Sunday, May 15, 2016 at 4:56:03 AM UTC-5, JvJ wrote:
>
>
> I don't have much experience with core.async, and I recently tried using 
> channels with transducers.  Strangely, I found that you need a buffer with 
> a size
> of at least one in order for the transducer to be applied.
>
> I have a few toy functions:
>
> (defn push-nums
>   "Push a few numbers on a channel."
>   [n c]
>   (go (loop [i 0]
> (when (< i n)
>   (>! c i)
>   (recur (inc i
>   (>! c :end)))
>
> (defn print-nums
>   "Take the numbers from the channel and print them."
>   [c]
>   (go
> (loop []
> (let [n (   (when (not= :end n)
> (println "A num: " n)
> (recur
> (println "Finished with nums!!")))
>
>
> I used them in two different scenarios:
>
>
> (let [c (chan 0 (map inc))] (push-nums 5 c) (print-nums c))
> ;=> A num:  0
> ;=> A num:  1
> ;=> A num:  2
> ;=> A num:  3
> ;=> A num:  4
> ;=> Finished with nums!!
>
> (let [c (chan 1 (map inc))] (push-nums 5 c) (print-nums c))
> ;=> A num:  1
> ;=> A num:  2
> ;=> A num:  3
> ;=> A num:  4
> ;=> A num:  5
>
>
>  The transducer only gets applied when the argument 1 is passed in.  I 
> assume this is by design, but I don't like the fact that
> using transducers effectively limits certain options with channels.
>
> Does anyone know if there's a type of buffer that can be used to get 
> around this?
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Why do transducers on channels need buffer size of at least 1?

2016-05-15 Thread JvJ 

I don't have much experience with core.async, and I recently tried using 
channels with transducers.  Strangely, I found that you need a buffer with 
a size
of at least one in order for the transducer to be applied.

I have a few toy functions:

(defn push-nums
  "Push a few numbers on a channel."
  [n c]
  (go (loop [i 0]
(when (< i n)
  (>! c i)
  (recur (inc i
  (>! c :end)))

(defn print-nums
  "Take the numbers from the channel and print them."
  [c]
  (go
(loop []
(let [n ( A num:  0
;=> A num:  1
;=> A num:  2
;=> A num:  3
;=> A num:  4
;=> Finished with nums!!

(let [c (chan 1 (map inc))] (push-nums 5 c) (print-nums c))
;=> A num:  1
;=> A num:  2
;=> A num:  3
;=> A num:  4
;=> A num:  5


 The transducer only gets applied when the argument 1 is passed in.  I 
assume this is by design, but I don't like the fact that
using transducers effectively limits certain options with channels.

Does anyone know if there's a type of buffer that can be used to get around 
this?



-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.