weird bug with cljs.core.async + macros

[t x]

Hi,

  repo: https://github.com/txrev319/bug-report

  I have a really weird bug where:

  * (my-macro ...) ==> everything works

  * (async/go (my-macro ...)) ==> something weird happens


  A minimal failure case is documented at:
https://github.com/txrev319/bug-report/blob/master/src/app.cljx

  It depends on the macro defined in:
https://github.com/txrev319/bug-report/blob/master/src/macros.cljx

  The bug can be replicated by following the instructions at:
https://github.com/txrev319/bug-report/blob/master/README.md

  I *believe* I have included everything required to replicate the
bug. If I am missing anything, please let me know.


Extra info:

$ lein --version
Leiningen 2.2.0 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM

I'm on 64-bit OSX.


Thanks!

-- 
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/groups/opt_out.

Re: (series of swap! on atom) ==> single swap!

[t x]

Hi Jan,

  Thanks for your explanations.

  I have no idea how I managed to completely misunderstand
clojure/atom for the past few years -- I suspect it's because I never
use clojure/STM, and as a result, I've never had an atom roll back on
me.

  I've decided to switch to agents.

  Thanks again for catching this fundamental error.



On Sun, Feb 16, 2014 at 11:00 PM, Jan Herich  wrote:
> Hi t x,
>
> I think, that lock-free approach an it's semantics is more in line with
> other Clojure reference types such as refs.
> It also encourages you to only use pure functions for state transitions,
> among other things, such as significant
> performance benefits in comparison with lock based approaches, see for
> example this article.
> If you really want to update some reference with function which will also
> perform "impure" actions such as file I/O,
> consider using agents and send or send-off (the latter in case of I/O
> blocking actions), functions given to send
> and send-off are guaranteed to run only once.
>
> Dňa pondelok, 17. februára 2014 2:36:59 UTC+1 t x napísal(-a):
>>
>> Hi Jan,
>>
>>   You're right. I'm wrong.
>>
>>   I'm grateful you pointed this out -- this would have otherwise been
>> impossible to debug.
>>
>> ===
>>
>> To everyone:
>>
>>   Why can swap! be retried? This confuses me -- to implement swap!, why
>> can't we
>>
>>   * have a lock
>>
>>   * ensure that only one swap! is in session at any given time
>>
>>   * have the given swap! complete before running the next swap!
>>
>>
>> Thanks!
>>
>>
>> On Sun, Feb 16, 2014 at 3:51 PM, Jan Herich  wrote:
>> > I'm afraid your understanding of atom swap! operations is not quite
>> > correct
>> > -> update function must (or should) be pure as well.
>> > See the documentation for swap!, update function could be potentially
>> > called
>> > multiple times if there are more threads of execution
>> > updating one atomic reference -> there is simple compare and set
>> > mechanism
>> > involved, which compares the old value of the atom
>> > (input for the update function) and sets the atom to new value (return
>> > value
>> > from the update function) only value of the atom reference
>> > was not changed in between, if yes the compare and set is retried until
>> > ti
>> > succeeds.
>> >
>> > Dňa nedeľa, 16. februára 2014 23:35:24 UTC+1 t x napísal(-a):
>> >>
>> >> I believe that's the STM approach, which has the advanrtage of:
>> >>
>> >>   * can synchronize across multiple pieces of data
>> >>
>> >> but has the disadvantage of:
>> >>
>> >>   * work must be "pure" since it can be retried
>> >>
>> >>   * possibly less efficient due to possibility of retrying
>> >>
>> >>
>> >> In the example I posted above, I only need to:
>> >>
>> >>   * modify a single atom
>> >>
>> >> and the approach I presented above:
>> >>
>> >>   * can be impure, since it is guaranteed to only run once
>> >>
>> >>   * is guaranteed to succeed (without retrys)
>> >>
>> >> On Sun, Feb 16, 2014 at 2:25 PM, Ramesh  wrote:
>> >> > You can use a ref instead of an atom. And use dosync with multiple
>> >> > alter, so
>> >> > everything is safely inside a transaction.
>> >> >
>> >> > On Feb 16, 2014 2:04 PM, "t x"  wrote:
>> >> >>
>> >> >> Hi John,
>> >> >>
>> >> >>   Your solution is perfectly valid and optimal for the problem I
>> >> >> described above.
>> >> >>
>> >> >>
>> >> >>   Unfortunately, I forgot to mention an additional constraint:
>> >> >> sometimes I
>> >> >> do:
>> >> >>
>> >> >> (let [ foo (:some-selector @data-atom) ]
>> >> >>   (swap! data-atom update-in [:other-selector] ... ))
>> >> >>
>> >> >> which the -> doesn't quite work on, but my ugly hack above does
>> >> >> resolve.
>> >> >>
>> >> >>
>> >> >>   The problem being -- I want to update one part of the atom, but it
>> >> >> depends on another part of the atom.
>> >> >>
>> >> >>   I ended up with the following hack:
>> >> >>
>> >> >> (defn tswap! [atm func]
>> >> >>   (swap! atm
>> >> >>  (fn [old]
>> >> >>(let [natm (atom old)]
>> >> >>  (func natm)
>> >> >>  @natm
>> >> >>
>> >> >>
>> >> >> On Sat, Feb 15, 2014 at 4:09 PM, John D. Hume 
>> >> >> wrote:
>> >> >> > On Sat, Feb 15, 2014 at 6:04 PM, t x  wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> (defn what-I-want []
>> >> >> >>   (with-atom some-atom
>> >> >> >> assoc-in ...
>> >> >> >> assoc-in ...
>> >> >> >> update-in ...))
>> >> >> >
>> >> >> >
>> >> >> > I often do something like this and don't find it too ugly:
>> >> >> > (swap! my-atom #(-> %
>> >> >> >   (assoc-in [:k] v)
>> >> >> >   (update-in [:k2] inc)
>> >> >> >   ,,,))
>> >> >> >
>> >> >> > --
>> >> >> > 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
>> >> 

Re: [ANN] lispy.el 0.8: jump to any Clojure tag in current directory screencast

[Oleh]

Sure.

1. Setup MELPA:

(package-initialize)
(add-to-list 'package-archives
 '("melpa" . "http://melpa.milkbox.net/packages/";))

2. Install `lispy` from MELPA:

M-x package-install lispy

3. Get `clojure-semantic` from git:

cd ~/git
git clone https://github.com/kototama/clojure-semantic

4. Add to your ~/.emacs:

(add-to-list 'load-path "~/git/clojure-semantic")
(load "~/git/clojure-semantic/clojure.el")

5. Optionally, if you don't want to enable `lispy-mode` manually for each 
file,
you can set it to be on automatically:


(mapc (lambda(h) (add-hook h (lambda() (lispy-mode 1
  '(emacs-lisp-mode-hook
lisp-interaction-mode-hook
clojure-mode-hook
scheme-mode-hook
lisp-mode-hook))

6. Restart Emacs or load manually all the stuff from above and open
some Clojure project. You can call `lispy-goto` with "g" when
the point is in special position and `lispy-mode` is active or you can do 
M-x lispy-goto.
Special position means the point is before ([{ or after )]} or the region 
is active,
you can read more about it at 
https://github.com/abo-abo/lispy#special-positions-and-key-bindings .

You can call `lispy-goto-local` with "G". It will offer the tags just in 
current file, not
in whole directory.

7. Write back to me if this works so I can put up these steps as a tutorial 
somewhere.
If it doesn't work, write anyway and I'll give more details.

Oleh



On Sunday, February 16, 2014 4:28:27 PM UTC+1, Olli Piepponen wrote:
>
> This looks very neat, but I was unable to figure out how to use 
> lispy/clojure-semantic the way you were doing in your screencast. Could you 
> give a breakdown of how this works?
>
> On Saturday, February 15, 2014 4:46:48 AM UTC+7, Oleh wrote:
>>
>> Hi all,
>>
>> As a follow-up to this post - 
>> https://groups.google.com/forum/#!topic/clojure/B7dTW5PDcPM,
>> it's now possible to jump to any Clojure tag in current directory.
>> No project definitions required: CEDET will parse every source file in 
>> current directory.
>> The tags are completed with helm plugin, so it's quite fast to find a 
>> candidate to jump to.
>>
>> As a showcase, I've took this popular Clojure statistics package: 
>> https://github.com/liebke/incanter
>>
>> The screencast is here: https://vimeo.com/86727658.
>>
>> lispy is here: https://github.com/abo-abo/lispy
>> clojure-semantic is here: https://github.com/kototama/clojure-semantic
>>
>> There's currently a bug in clojure-semantic the prevents permanent 
>> storage of parsed tags,
>> maybe someone with some expertise could look into that. 
>> Also, it's generated by a bison-like grammar, so if you know bison (I 
>> don't unfortunately),
>> you could extend clojure-semantic to distinguish stuff like defmacro, 
>> defmulti, defmethod etc.
>>
>> Same functionality is also available for Emacs Lisp, Scheme and Common 
>> Lisp, if you like using
>> anything else besides Clojure:)
>>
>> regards,
>> Oleh
>>
>

-- 
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/groups/opt_out.

Re: Latex style file for formatting/coloring clojure code?

[Jean Niklas L'orange]

Hi Mark,

On Monday, February 17, 2014 12:05:24 AM UTC+1, puzzler wrote:
>
> I am unable to find a style file that supports clojure code in LaTeX.  Can 
> anyone point me in the right direction?
>

I always use Minted for this kind of stuff: See 
https://code.google.com/p/minted/

It is available in most, if not all, linux distributions. A small example 
for clojure follows:

[...]
\usepackage[section]{minted}

\begin{document}
[...]
\begin{minted}[gobble=2, frame=single}{clj}
  (with-open [reader (-> 
"META-INF/maven/my-program/my-program/pom.properties"
 io/resource
 io/reader)]
(-> (doto (java.util.Properties.)
  (.load reader))
(.getProperty "version")))
\end{minted}
[...]
\end{document}

Keep in mind that pdflatex has to be invoked with -shell-escape in order to 
allow pygments to be called. If you use latexmk (if you don't know about 
it, check it out!), then you could use the following command stored in a 
shell script or Makefile:

latexmk -pdf -pdflatex='pdflatex -shell-escape %O %S' -pvc $(REPORT).tex

At least it has been immensely useful to me.

-- JN

-- 
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/groups/opt_out.

Re: fast parallel reduction into hash-set/map

[Jean Niklas L'orange]

On Sunday, February 16, 2014 11:49:38 AM UTC+1, Mikera wrote:
>
> Wow - that's a pretty big win. I think we should try and get this into 
> Clojure ASAP.
>
> Are we too late for 1.6?
>

Yeah, this is probably too late for 1.6 =/

Anyway, cool stuff you got going on here. I'm playing around with similar 
functions myself (for a variant of RRB-Trees), but ended up with several 
issues when I attempted to splice trees which shared structure. Is there 
any indication that this will be an issue? An easy way to check this out is 
to generate a large random map/set, then randomly generate maps/sets based 
on the large one by cutting off random elements. Then you randomly splice 
those maps/sets repeatedly, repeat the cutting, and continue with the 
splicing.

-- JN

-- 
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/groups/opt_out.

clojurescript source maps: chrome's expected behavior, firefox support

[Ransom Williams]

First of all thanks to everyone working on clojure for making web 
development suck less.  I recently sandboxed a clojure server application, 
and the tooling, documentation, and availability of libraries are all 
awesome.

Anyway, I'm starting in with a clojurescript client now and want to confirm 
one detail about The Essence of 
Clojurescriptblog
 post:  Chrome (32)'s console indeed links the log message to a line in 
clojurescript, but the line number is in the enable-console-print! function 
in cljs/core rather than the call to println in hello_world/core.  Is this 
the expected behavior?  I guess I ought to read up on the details of source 
maps.

And finally, what about firefox?  The firefox (27) developer tools have 
source map support, and the debugger pulls up hello_word/core, but unlike 
chrome, it doesn't hit breakpoints, and the log message links to a 
javascript file rather than a clojurescript file.  Any word from mozillians 
on if/when-type questions?

So yeah, mainly just stopping by to say hey and thanks and to be another 
voice out there extolling the virtues of this practical lisp.

-- 
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/groups/opt_out.

Lein, Speclj & clojure 1.6.0-beta1

[Karsten Schmidt]

Hi all, am trying to test out the new hashing approach for my datatypes in
1.6 but it seems that even though I'm referring to the latest beta in my
project.clj, Speclj is overriding that dependency with 1.5.1 and I can't
run my tests. How can I force it to honor my setting and use 1.6.0-beta1? I
guess that's a more general question about leiningen's dep resolution for
plugins...

Thanks!

-- 
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/groups/opt_out.

Re: Lein, Speclj & clojure 1.6.0-beta1

[Karsten Schmidt]

Oh I just saw that's a known issue with Speclj and its setting of `:eval-in
:leiningen`

https://github.com/slagyr/speclj/issues/78

I guess i will have to switch to another test framework then...
On 17 Feb 2014 12:09, "Karsten Schmidt"  wrote:

> Hi all, am trying to test out the new hashing approach for my datatypes in
> 1.6 but it seems that even though I'm referring to the latest beta in my
> project.clj, Speclj is overriding that dependency with 1.5.1 and I can't
> run my tests. How can I force it to honor my setting and use 1.6.0-beta1? I
> guess that's a more general question about leiningen's dep resolution for
> plugins...
>
> Thanks!
>

-- 
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/groups/opt_out.

Re: Looking for advice to fine tune a simple function

[Andy-]

On Sunday, February 16, 2014 11:19:58 PM UTC-5, Bruno Kim Medeiros Cesar 
wrote:
>
> (BTW, Andy, how do you format your code so prettily?)
>
I usually just paste it into pygments.org and then paste it back into 
google groups (which accepts the generated HTML).

Cheers 

-- 
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/groups/opt_out.

Re: fast parallel reduction into hash-set/map

[Alex Miller]

It is too late, but an enhancement jira would be appropriate. I would 
highly encourage some generative tests in such a patch and perhaps looking 
at https://github.com/ztellman/collection-check. With simple.check moving 
into contrib as test.check, we expect to be able to use test.check within 
Clojure tests soon as well.


On Monday, February 17, 2014 3:28:28 AM UTC-6, Jean Niklas L'orange wrote:
>
>
>
> On Sunday, February 16, 2014 11:49:38 AM UTC+1, Mikera wrote:
>>
>> Wow - that's a pretty big win. I think we should try and get this into 
>> Clojure ASAP.
>>
>> Are we too late for 1.6?
>>
>
> Yeah, this is probably too late for 1.6 =/
>
> Anyway, cool stuff you got going on here. I'm playing around with similar 
> functions myself (for a variant of RRB-Trees), but ended up with several 
> issues when I attempted to splice trees which shared structure. Is there 
> any indication that this will be an issue? An easy way to check this out is 
> to generate a large random map/set, then randomly generate maps/sets based 
> on the large one by cutting off random elements. Then you randomly splice 
> those maps/sets repeatedly, repeat the cutting, and continue with the 
> splicing.
>
> -- JN
>

-- 
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/groups/opt_out.

Re: Looking for advice to fine tune a simple function

[Laurent Droin]

Wow, thanks Gianluco, Andy and Bruno. Lots of good feedback I am trying to 
process. It's amazing how coming up with a satisfying "functional 
programing" style function is a complex process when you've been doing 
imperative programing all your life. It's really a whole different way of 
thinking. I like it but it will take some practice and your feedback really 
helps. It looks like I'm going to spend more time on it. I'll update.

-- 
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/groups/opt_out.

Re: (series of swap! on atom) ==> single swap!

[icamts]

Hi t x and Jan,
what about performing the side effect part of the function adding a watch? 
(They are no more in alpha with the upcoming 1.6.)

Cheers,
Luca

Il giorno lunedì 17 febbraio 2014 09:29:57 UTC+1, t x ha scritto:
>
> Hi Jan, 
>
>   Thanks for your explanations. 
>
>   I have no idea how I managed to completely misunderstand 
> clojure/atom for the past few years -- I suspect it's because I never 
> use clojure/STM, and as a result, I've never had an atom roll back on 
> me. 
>
>   I've decided to switch to agents. 
>
>   Thanks again for catching this fundamental error. 
>
>
>
> On Sun, Feb 16, 2014 at 11:00 PM, Jan Herich 
> > 
> wrote: 
> > Hi t x, 
> > 
> > I think, that lock-free approach an it's semantics is more in line with 
> > other Clojure reference types such as refs. 
> > It also encourages you to only use pure functions for state transitions, 
> > among other things, such as significant 
> > performance benefits in comparison with lock based approaches, see for 
> > example this article. 
> > If you really want to update some reference with function which will 
> also 
> > perform "impure" actions such as file I/O, 
> > consider using agents and send or send-off (the latter in case of I/O 
> > blocking actions), functions given to send 
> > and send-off are guaranteed to run only once. 
> > 
> > Dňa pondelok, 17. februára 2014 2:36:59 UTC+1 t x napísal(-a): 
> >> 
> >> Hi Jan, 
> >> 
> >>   You're right. I'm wrong. 
> >> 
> >>   I'm grateful you pointed this out -- this would have otherwise been 
> >> impossible to debug. 
> >> 
> >> === 
> >> 
> >> To everyone: 
> >> 
> >>   Why can swap! be retried? This confuses me -- to implement swap!, why 
> >> can't we 
> >> 
> >>   * have a lock 
> >> 
> >>   * ensure that only one swap! is in session at any given time 
> >> 
> >>   * have the given swap! complete before running the next swap! 
> >> 
> >> 
> >> Thanks! 
> >> 
> >> 
> >> On Sun, Feb 16, 2014 at 3:51 PM, Jan Herich  
> wrote: 
> >> > I'm afraid your understanding of atom swap! operations is not quite 
> >> > correct 
> >> > -> update function must (or should) be pure as well. 
> >> > See the documentation for swap!, update function could be potentially 
> >> > called 
> >> > multiple times if there are more threads of execution 
> >> > updating one atomic reference -> there is simple compare and set 
> >> > mechanism 
> >> > involved, which compares the old value of the atom 
> >> > (input for the update function) and sets the atom to new value 
> (return 
> >> > value 
> >> > from the update function) only value of the atom reference 
> >> > was not changed in between, if yes the compare and set is retried 
> until 
> >> > ti 
> >> > succeeds. 
> >> > 
> >> > Dňa nedeľa, 16. februára 2014 23:35:24 UTC+1 t x napísal(-a): 
> >> >> 
> >> >> I believe that's the STM approach, which has the advanrtage of: 
> >> >> 
> >> >>   * can synchronize across multiple pieces of data 
> >> >> 
> >> >> but has the disadvantage of: 
> >> >> 
> >> >>   * work must be "pure" since it can be retried 
> >> >> 
> >> >>   * possibly less efficient due to possibility of retrying 
> >> >> 
> >> >> 
> >> >> In the example I posted above, I only need to: 
> >> >> 
> >> >>   * modify a single atom 
> >> >> 
> >> >> and the approach I presented above: 
> >> >> 
> >> >>   * can be impure, since it is guaranteed to only run once 
> >> >> 
> >> >>   * is guaranteed to succeed (without retrys) 
> >> >> 
> >> >> On Sun, Feb 16, 2014 at 2:25 PM, Ramesh  
> wrote: 
> >> >> > You can use a ref instead of an atom. And use dosync with multiple 
> >> >> > alter, so 
> >> >> > everything is safely inside a transaction. 
> >> >> > 
> >> >> > On Feb 16, 2014 2:04 PM, "t x"  wrote: 
> >> >> >> 
> >> >> >> Hi John, 
> >> >> >> 
> >> >> >>   Your solution is perfectly valid and optimal for the problem I 
> >> >> >> described above. 
> >> >> >> 
> >> >> >> 
> >> >> >>   Unfortunately, I forgot to mention an additional constraint: 
> >> >> >> sometimes I 
> >> >> >> do: 
> >> >> >> 
> >> >> >> (let [ foo (:some-selector @data-atom) ] 
> >> >> >>   (swap! data-atom update-in [:other-selector] ... )) 
> >> >> >> 
> >> >> >> which the -> doesn't quite work on, but my ugly hack above does 
> >> >> >> resolve. 
> >> >> >> 
> >> >> >> 
> >> >> >>   The problem being -- I want to update one part of the atom, but 
> it 
> >> >> >> depends on another part of the atom. 
> >> >> >> 
> >> >> >>   I ended up with the following hack: 
> >> >> >> 
> >> >> >> (defn tswap! [atm func] 
> >> >> >>   (swap! atm 
> >> >> >>  (fn [old] 
> >> >> >>(let [natm (atom old)] 
> >> >> >>  (func natm) 
> >> >> >>  @natm 
> >> >> >> 
> >> >> >> 
> >> >> >> On Sat, Feb 15, 2014 at 4:09 PM, John D. Hume <
> duelin@gmail.com> 
> >> >> >> wrote: 
> >> >> >> > On Sat, Feb 15, 2014 at 6:04 PM, t x  
> wrote: 
> >> >> >> >> 
> >> >> >> >> 
> >> >> >> >> (defn what-I-want [] 
> >> >> >> 

Re: clojurescript source maps: chrome's expected behavior, firefox support

[David Nolen]

On Mon, Feb 17, 2014 at 3:43 AM, Ransom Williams wrote:

> First of all thanks to everyone working on clojure for making web
> development suck less.  I recently sandboxed a clojure server application,
> and the tooling, documentation, and availability of libraries are all
> awesome.
>
> Anyway, I'm starting in with a clojurescript client now and want to
> confirm one detail about The Essence of 
> Clojurescriptblog
>  post:  Chrome (32)'s console indeed links the log message to a line in
> clojurescript, but the line number is in the enable-console-print! function
> in cljs/core rather than the call to println in hello_world/core.  Is this
> the expected behavior?  I guess I ought to read up on the details of source
> maps.
>

Nothing to do with source maps, behavior of console.log which we can do
nothing about. So yes, expected.

And finally, what about firefox?  The firefox (27) developer tools have
> source map support, and the debugger pulls up hello_word/core, but unlike
> chrome, it doesn't hit breakpoints, and the log message links to a
> javascript file rather than a clojurescript file.  Any word from mozillians
> on if/when-type questions?
>

No idea, but I'm sure many other compile to JS languages are bugging them
about it :)

David

-- 
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/groups/opt_out.

Re: [ANN] Clojure 1.6.0-beta1

[Herwig Hochleitner]

Since transients are no longer marked as alpha, I want to take this (last?)
chance to raise an interface question concerning them:

Right now, we cannot distinguish whether a transient contains a key with a
nik value or if it doesn't contain the key, because contains? doesn't work
on transients.
Is it supposed to stay that way?

There is a long standing ticket for that, which seems to have been
overlooked when promoting transients out of alpha:
http://dev.clojure.org/jira/browse/CLJ-700


2014-02-17 3:54 GMT+01:00 Mars0i :

> I like Alex's suggestions.  Another option is "something" rather than
> "some" or "exists".  "Something" has the disadvantage that it's long, so
> when you combine it with addition strings, you get something even longer.
>
> On the other hand, for me both "some" and "exists" sound like existential
> quantifiers in logic, as in "Some x is F",  "There exists an x such that
> Fx".  The clojure function *every?* plays the role of the universal
> quantifier (All x are F), and the *some* function plays the role of the
> existential quantifier, although it does more.
>
> However, a function named "something?" doesn't really sound like an
> existential quantifier (despite the fact that in English "something" can be
> used to express the existential quantifier ("something is F").  Rather,
> "something?" suggests that there's something, rather than nothing, i.e.
> rather than nil.
>
> (something? false) => false
> is still a little bit confusing, but if you think of it as saying that
> falsehood is not nothing, then maybe it makes sense.
>
>
>
> On Sunday, February 16, 2014 11:29:38 AM UTC-6, Alex Walker wrote:
>>
>> Part of Rich's objection to not-nil? variants could be that they are a
>> double negative, "not-(no value)?", which can decrease clarity and require
>> more coffee.
>>
>>
>>>- nil Means 'nothing/no-value'- represents Java null and tests
>>>logical false [clojure.org/reader]
>>>
>>>
>> To compete with some? variants, I'd suggest a positive that I found
>> strangely available:
>>
>> exists?
>> if-exists[?]
>> when-exists[?]
>>
>> Or, more proper, though potentially more overloaded: value?, if-value[?],
>> when-value[?].
>>
>> On Sunday, February 16, 2014 12:54:12 AM UTC-6, Эльдар Габдуллин wrote:
>>>
>>> Like this, just
>>>
>>> not-nil?
>>> if-not-nil
>>> when-not-nil
>>>
>>> is much better for me.
>>>
>>>
>>>
>>> суббота, 15 февраля 2014 г., 7:12:21 UTC+4 пользователь Joel Holdbrooks
>>> написал:

 As an addendum to my last comment, *not-nil?* would also be a good
 candidate. That really doesn't leave room for doubt.

 This:

  (some? false) ;; => true

 Would confuse me. On the other hand this:

 (not-nil? false) ;; => true

 Would not.

 There's really no need to complicate the naming story here. It's also
 easy to remember!

 On Friday, February 14, 2014 3:25:36 PM UTC-8, Alex Miller wrote:
>
>
>
> On Friday, February 14, 2014 2:27:49 PM UTC-6, DomKM wrote:
>>
>> Great changes! I have a question about #5.
>>
>>
>>> 5) New "some" operations
>>> Many conditional functions rely on logical truth (where "falsey"
>>> values are nil or false). Sometimes it is useful to have functions
>>> that rely on "not nilness" instead. These functions have been added
>>> to
>>> support these cases [CLJ-1343]:
>>> * some? - same as (not (nil? x))
>>> * if-some - like if-let, but checks (not (nil? test)) instead of test
>>> * when-some - like when-let, but checks (not (nil? test)) instead of
>>> test
>>
>>
>> It seems inconsistent to have "some" mean two very different things
>> within the same namespace, especially since the prior uses of "some"
>> (`some`, `some-fn`, etc.) are more in keeping with its primary definition
>> of having to do with amount (and operate on seqs or variadic arguments)
>> while the new functions have to do with existence (and operate on any
>> single value). Why not call these new functions `not-nil?`, `if-not-nil`,
>> and `when-not-nil`? Or, if "not-nil" is too unwieldy then what about
>> "exists" (`exists?`, `if-exists`, `when-exists`)?
>>
>> Are these names up for discussion?
>>
>
> Hey Dom et al,
>
> The names of these functions were chosen by Rich. There was already
> some name overloading of "some" even before these new functions with some
> (truthy) and some->/some->> (not nil). The new functions keep with the
> latter meaning. Many other names were considered, including everything 
> I've
> seen someone mention (-not-nil, exists, nnil, etc). As far as I know these
> names are final, however, I will relay all of the feedback I've seen here,
> on #clojure, and on Twitter to Rich for consideration.
>
> Alex
>
>
  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" grou

Re: [ANN] Clojure 1.6.0-beta1

[Alex Miller]

CLJ-700 is a bug, regardless of whether it is marked as alpha or not. 

This ticket has a strange history of approval statuses (pre-dating my 
involvement with jira) that caused it not to be included in 1.6 earlier. 
Unfortunately, I think it is too big a change to consider at this point in 
1.6 (due to refactoring of key interfaces, etc). I would expect it to be 
looked at for the next release.

Alex


On Monday, February 17, 2014 9:54:36 AM UTC-6, Herwig Hochleitner wrote:
>
> Since transients are no longer marked as alpha, I want to take this 
> (last?) chance to raise an interface question concerning them:
>
> Right now, we cannot distinguish whether a transient contains a key with a 
> nik value or if it doesn't contain the key, because contains? doesn't work 
> on transients.
> Is it supposed to stay that way?
>
> There is a long standing ticket for that, which seems to have been 
> overlooked when promoting transients out of alpha: 
> http://dev.clojure.org/jira/browse/CLJ-700
>
>
> 2014-02-17 3:54 GMT+01:00 Mars0i >:
>
>> I like Alex's suggestions.  Another option is "something" rather than 
>> "some" or "exists".  "Something" has the disadvantage that it's long, so 
>> when you combine it with addition strings, you get something even longer.  
>>
>> On the other hand, for me both "some" and "exists" sound like existential 
>> quantifiers in logic, as in "Some x is F",  "There exists an x such that 
>> Fx".  The clojure function *every?* plays the role of the universal 
>> quantifier (All x are F), and the *some* function plays the role of the 
>> existential quantifier, although it does more.
>>
>> However, a function named "something?" doesn't really sound like an 
>> existential quantifier (despite the fact that in English "something" can be 
>> used to express the existential quantifier ("something is F").  Rather, 
>> "something?" suggests that there's something, rather than nothing, i.e. 
>> rather than nil.
>>
>> (something? false) => false
>> is still a little bit confusing, but if you think of it as saying that 
>> falsehood is not nothing, then maybe it makes sense.
>>
>>
>>
>> On Sunday, February 16, 2014 11:29:38 AM UTC-6, Alex Walker wrote:
>>>
>>> Part of Rich's objection to not-nil? variants could be that they are a 
>>> double negative, "not-(no value)?", which can decrease clarity and require 
>>> more coffee.
>>>
>>>
- nil Means 'nothing/no-value'- represents Java null and tests 
logical false [clojure.org/reader]


>>> To compete with some? variants, I'd suggest a positive that I found 
>>> strangely available:
>>>
>>> exists?
>>> if-exists[?]
>>> when-exists[?]
>>>
>>> Or, more proper, though potentially more overloaded: value?, if-value[?], 
>>> when-value[?].
>>>
>>> On Sunday, February 16, 2014 12:54:12 AM UTC-6, Эльдар Габдуллин wrote:

 Like this, just

 not-nil?
 if-not-nil
 when-not-nil

 is much better for me.



 суббота, 15 февраля 2014 г., 7:12:21 UTC+4 пользователь Joel Holdbrooks 
 написал:
>
> As an addendum to my last comment, *not-nil?* would also be a good 
> candidate. That really doesn't leave room for doubt.
>
> This:
>   
>  (some? false) ;; => true 
>
> Would confuse me. On the other hand this:
>   
> (not-nil? false) ;; => true 
>
> Would not.
>
> There's really no need to complicate the naming story here. It's also 
> easy to remember!
>
> On Friday, February 14, 2014 3:25:36 PM UTC-8, Alex Miller wrote:
>>
>>
>>
>> On Friday, February 14, 2014 2:27:49 PM UTC-6, DomKM wrote:
>>>
>>> Great changes! I have a question about #5.
>>>  
>>>
 5) New "some" operations 
 Many conditional functions rely on logical truth (where "falsey"
 values are nil or false). Sometimes it is useful to have functions
 that rely on "not nilness" instead. These functions have been added 
 to
 support these cases [CLJ-1343]:
 * some? - same as (not (nil? x))
 * if-some - like if-let, but checks (not (nil? test)) instead of 
 test
 * when-some - like when-let, but checks (not (nil? test)) instead 
 of test
>>>
>>>
>>> It seems inconsistent to have "some" mean two very different things 
>>> within the same namespace, especially since the prior uses of "some" 
>>> (`some`, `some-fn`, etc.) are more in keeping with its primary 
>>> definition 
>>> of having to do with amount (and operate on seqs or variadic arguments) 
>>> while the new functions have to do with existence (and operate on any 
>>> single value). Why not call these new functions `not-nil?`, 
>>> `if-not-nil`, 
>>> and `when-not-nil`? Or, if "not-nil" is too unwieldy then what about 
>>> "exists" (`exists?`, `if-exists`, `when-exists`)?
>>>
>>> Are these names up for discussion?
>>>
>>
>> Hey 

Re: fast parallel reduction into hash-set/map

[Glen Mailer]

Is there a specific part of this implementation which means it needs to 
live in core?

It would be cool to have this as a library that could be used with existing 
versions of clojure (I have no idea if enough of the internals are exposed 
to make this viable)

Glen

On Saturday, 15 February 2014 23:06:24 UTC, Jules wrote:
>
> Guys,
>
> I've been playing with reducers on and off for a while but have been 
> frustrated because they don't seem to fit a particular usecase that I have 
> in mind... specifically: getting as many associations into a hash-map as as 
> I can in as short a time as possible.
>
> My understanding of the reason for this is that reducers practice a divide 
> and conquer strategy. The incoming sequence is divided up. Each 
> sub-sequence is reduced into a sub-result (possibly in parallel) and then 
> the sub-results are combined into the the final outgoing result.
>
> Unfortunately, there does not seem to be a better way of combining two 
> hash-maps other than to read each entry from one and create a new 
> corresponding association in the other. This means that each recombination 
> in the above process essentially repeats most of the work already performed 
> in the previous reduction stage.
>
> Hash-sets are implemented via hash-maps, and simpler with which to 
> demonstrate this problem:
>
> user=> (def a (doall (range 1000)))
> #'user/a
> user=> (def b (doall (range 500 1500)))
> #'user/b
> user=> (time (def c (into #{} a)))
> "Elapsed time: 6319.392669 msecs"
> #'user/c
> user=> (time (def d (into #{} b)))
> "Elapsed time: 5389.805233 msecs"
> #'user/d
> user=> (time (def e (into c d)))
> "Elapsed time: 8486.032191 msecs"
> #'user/e
>
>
> In the example above, you can see that the reduction into hash-sets of two 
> overlapping lists of 10,000,000 elements takes 6.3 and 5.4 seconds. This 
> stage can be carried out in parallel i.e. time elapsed for this stage would 
> be 6.3 seconds - but we now have two hash-sets and we want one, so we have 
> to combine them.
>
>
> user=> (time (def e (into c d)))
> "Elapsed time: 8486.032191 msecs"
> #'user/e
>
> As you can see, all the advantages of splitting the original sequence into 
> 2 and processing the two halves in parallel are lost since the 
> recombination or their results takes 8.5 seconds - more than we saved by 
> doing the reduction in parallel.
>
> So, what can we do about it ?
>
> I had a look at the code for PersistentHashMap (PersistentHashSet uses 
> PersistantHashMap internally). I realised that it was possible to "splice" 
> together the internal structure of two hash maps into a single one without 
> repeating most of the work required to build one from scratch. So, I had a 
> go at implementing it:
>
>
> user=> (time (def f (clojure.lang.PersistentHashSet/splice c d)))
> "Elapsed time: 3052.690911 msecs"
> #'user/f
>
> and:
>
> user=> (= e f)
> true
>
> Whilst this is still adding 3 seconds to our time, that 3 seconds is half 
> the time that we would have added had we executed the second reduction in 
> serial, rather than in parallel.
>
> This means that we can now reduce large datasets into sets/maps more 
> quickly in parallel than we can in serial :-) As an added benefit, because 
> splice reuses as much of the internal structure of both inputs as possible, 
> it's impact in terms of heap consumption and churn is less - although I 
> think that a full implementation might add some Java-side code complexity.
>
> If you would like to give 'splice' a try out, you will need to clone my 
> fork of clojure at github 
>
> https://github.com/JulesGosnell/clojure
>
> Please let me know if you try out the code. I would be interested to hear 
> if people think it is worth pursuing.
>
> I was also thinking that it should be possible to use a similar trick to 
> quickly and cheaply split a map/set into [roughly] equal sized pieces 
> (assuming an good hash distribution). This would enable the use of a 
> map/set as an input sequence into the parallel reduction process outlined 
> above. Currently, I believe that only a vector can be used in this way. It 
> would be harder to arrange that 'count' could be implemented efficiently on 
> these sub-maps/sets, but this is not important for the reduction process.
>
> BTW - benchmarks were run on a 3.2ghz Phenom II / clojure/master / 
> openjdk-1.7.0_51 / Fedora 20 with min and max 4gb ram.
>
> regards,
>
>
>
> Jules
>
>
>

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

Re: Lein, Speclj & clojure 1.6.0-beta1

[Glen Mailer]

:eval-in can be overridden in your project.clj, just add:

:speclj-eval-in :subprocess


I agree that the default is rather odd - especially when the only reason 
I'm aware of is "it's a bit faster"

Cheers
Glen


On Monday, 17 February 2014 12:09:13 UTC, Karsten Schmidt wrote:
>
> Hi all, am trying to test out the new hashing approach for my datatypes in 
> 1.6 but it seems that even though I'm referring to the latest beta in my 
> project.clj, Speclj is overriding that dependency with 1.5.1 and I can't 
> run my tests. How can I force it to honor my setting and use 1.6.0-beta1? I 
> guess that's a more general question about leiningen's dep resolution for 
> plugins...
>
> Thanks!
>

-- 
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/groups/opt_out.

Re: Looking for advice to fine tune a simple function

[Johanna Belanger]

Thanks for this!

On Monday, February 17, 2014 4:49:38 AM UTC-8, Andy- wrote:
>
> On Sunday, February 16, 2014 11:19:58 PM UTC-5, Bruno Kim Medeiros Cesar 
> wrote:
>>
>> (BTW, Andy, how do you format your code so prettily?)
>>
> I usually just paste it into pygments.org and then paste it back into 
> google groups (which accepts the generated HTML).
>
> Cheers 
>

-- 
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/groups/opt_out.

Re: Looking for advice to fine tune a simple function

[Johanna Belanger]

Hi,

I'm fairly new to clojure as well, but I like this way, and I *think* it's 
idiomatic:

Data structure:

[{:zone-max 100 :zone-key :hr-zone-1}
 {:zone-max 120 :zone-key :hr-zone-2}
 {:zone-max 140 :zone-key :hr-zone-3}
 {:zone-max 160 :zone-key :hr-zone-4}
 {:zone-max 333 :zone-key :hr-zone-5}]


And function:

(defn hr-zone
 "Return the HR zone as a keyword according to the bpm value"[bpm zones] 
   (:zone-key (first (filter #(<= bpm (:zone-max %)) (sort-by :zone-max 
zones)

   
That's just over my parentheses-parsing comfort level, so I'd probably 
thread it for readability:

(defn hr-zone
 "Return the HR zone as a keyword according to the bpm value"[bpm zones] (->> 
zones
 (sort-by :zone-max)
 (filter #(<= bpm (:zone-max %)))
 (first)
 (:zone-key)))

 
This returns nil if given a bpm higher than the defined zones, and it 
considers negative heart rates to be in zone one, so you might want to 
handle the boundaries differently.

Happy coding,
Johanna

On Monday, February 17, 2014 6:00:40 AM UTC-8, Laurent Droin wrote:
>
> Wow, thanks Gianluco, Andy and Bruno. Lots of good feedback I am trying to 
> process. It's amazing how coming up with a satisfying "functional 
> programing" style function is a complex process when you've been doing 
> imperative programing all your life. It's really a whole different way of 
> thinking. I like it but it will take some practice and your feedback really 
> helps. It looks like I'm going to spend more time on it. I'll update.
>
>

-- 
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/groups/opt_out.

Re: weird bug with cljs.core.async + macros

[t x]

Can anyone verify whether this bug is reproducible?

On Mon, Feb 17, 2014 at 12:28 AM, t x  wrote:
> Hi,
>
>   repo: https://github.com/txrev319/bug-report
>
>   I have a really weird bug where:
>
>   * (my-macro ...) ==> everything works
>
>   * (async/go (my-macro ...)) ==> something weird happens
>
>
>   A minimal failure case is documented at:
> https://github.com/txrev319/bug-report/blob/master/src/app.cljx
>
>   It depends on the macro defined in:
> https://github.com/txrev319/bug-report/blob/master/src/macros.cljx
>
>   The bug can be replicated by following the instructions at:
> https://github.com/txrev319/bug-report/blob/master/README.md
>
>   I *believe* I have included everything required to replicate the
> bug. If I am missing anything, please let me know.
>
>
> Extra info:
>
> $ lein --version
> Leiningen 2.2.0 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM
>
> I'm on 64-bit OSX.
>
>
> Thanks!

-- 
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/groups/opt_out.

Re: fast parallel reduction into hash-set/map

[Jules]

I've started doing some more serious testing and have not encountered any 
problems so far. I was a bit worried about the interaction of splice and 
transient/persistent!, but have not encountered any problems yet. I am 
going to read through the code again to satisfy myself that there is no 
issue lurking here.

I'll put together some proper testcases and add them to my repo.

thanks for your interest :-)

Jules


On Monday, 17 February 2014 09:28:28 UTC, Jean Niklas L'orange wrote:
>
>
>
> On Sunday, February 16, 2014 11:49:38 AM UTC+1, Mikera wrote:
>>
>> Wow - that's a pretty big win. I think we should try and get this into 
>> Clojure ASAP.
>>
>> Are we too late for 1.6?
>>
>
> Yeah, this is probably too late for 1.6 =/
>
> Anyway, cool stuff you got going on here. I'm playing around with similar 
> functions myself (for a variant of RRB-Trees), but ended up with several 
> issues when I attempted to splice trees which shared structure. Is there 
> any indication that this will be an issue? An easy way to check this out is 
> to generate a large random map/set, then randomly generate maps/sets based 
> on the large one by cutting off random elements. Then you randomly splice 
> those maps/sets repeatedly, repeat the cutting, and continue with the 
> splicing.
>
> -- JN
>

-- 
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/groups/opt_out.

Re: fast parallel reduction into hash-set/map

[Jules]

Alex,

thanks for the suggestion - I'll look at collection-check and raise the 
appropriate JIRA when I am happier with the code / idea.

Jules


On Monday, 17 February 2014 13:21:28 UTC, Alex Miller wrote:
>
> It is too late, but an enhancement jira would be appropriate. I would 
> highly encourage some generative tests in such a patch and perhaps looking 
> at https://github.com/ztellman/collection-check. With simple.check moving 
> into contrib as test.check, we expect to be able to use test.check within 
> Clojure tests soon as well.
>
>
> On Monday, February 17, 2014 3:28:28 AM UTC-6, Jean Niklas L'orange wrote:
>>
>>
>>
>> On Sunday, February 16, 2014 11:49:38 AM UTC+1, Mikera wrote:
>>>
>>> Wow - that's a pretty big win. I think we should try and get this into 
>>> Clojure ASAP.
>>>
>>> Are we too late for 1.6?
>>>
>>
>> Yeah, this is probably too late for 1.6 =/
>>
>> Anyway, cool stuff you got going on here. I'm playing around with similar 
>> functions myself (for a variant of RRB-Trees), but ended up with several 
>> issues when I attempted to splice trees which shared structure. Is there 
>> any indication that this will be an issue? An easy way to check this out is 
>> to generate a large random map/set, then randomly generate maps/sets based 
>> on the large one by cutting off random elements. Then you randomly splice 
>> those maps/sets repeatedly, repeat the cutting, and continue with the 
>> splicing.
>>
>> -- JN
>>
>

-- 
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/groups/opt_out.

Re: fast parallel reduction into hash-set/map

[Jules]

Glen,

I did start the implementation in Clojure, but had to move it under the 
skin of PersistentHashMap to achieve what I needed, so it is now written in 
Java and is part of PersistentHashMap... I don't think it would be 
practical to make it an add-on - but it would be nice :-). I'll keep it in 
mind.

Jules



On Monday, 17 February 2014 18:42:28 UTC, Glen Mailer wrote:
>
> Is there a specific part of this implementation which means it needs to 
> live in core?
>
> It would be cool to have this as a library that could be used with 
> existing versions of clojure (I have no idea if enough of the internals are 
> exposed to make this viable)
>
> Glen
>
> On Saturday, 15 February 2014 23:06:24 UTC, Jules wrote:
>>
>> Guys,
>>
>> I've been playing with reducers on and off for a while but have been 
>> frustrated because they don't seem to fit a particular usecase that I have 
>> in mind... specifically: getting as many associations into a hash-map as as 
>> I can in as short a time as possible.
>>
>> My understanding of the reason for this is that reducers practice a 
>> divide and conquer strategy. The incoming sequence is divided up. Each 
>> sub-sequence is reduced into a sub-result (possibly in parallel) and then 
>> the sub-results are combined into the the final outgoing result.
>>
>> Unfortunately, there does not seem to be a better way of combining two 
>> hash-maps other than to read each entry from one and create a new 
>> corresponding association in the other. This means that each recombination 
>> in the above process essentially repeats most of the work already performed 
>> in the previous reduction stage.
>>
>> Hash-sets are implemented via hash-maps, and simpler with which to 
>> demonstrate this problem:
>>
>> user=> (def a (doall (range 1000)))
>> #'user/a
>> user=> (def b (doall (range 500 1500)))
>> #'user/b
>> user=> (time (def c (into #{} a)))
>> "Elapsed time: 6319.392669 msecs"
>> #'user/c
>> user=> (time (def d (into #{} b)))
>> "Elapsed time: 5389.805233 msecs"
>> #'user/d
>> user=> (time (def e (into c d)))
>> "Elapsed time: 8486.032191 msecs"
>> #'user/e
>>
>>
>> In the example above, you can see that the reduction into hash-sets of 
>> two overlapping lists of 10,000,000 elements takes 6.3 and 5.4 seconds. 
>> This stage can be carried out in parallel i.e. time elapsed for this stage 
>> would be 6.3 seconds - but we now have two hash-sets and we want one, so we 
>> have to combine them.
>>
>>
>> user=> (time (def e (into c d)))
>> "Elapsed time: 8486.032191 msecs"
>> #'user/e
>>
>> As you can see, all the advantages of splitting the original sequence 
>> into 2 and processing the two halves in parallel are lost since the 
>> recombination or their results takes 8.5 seconds - more than we saved by 
>> doing the reduction in parallel.
>>
>> So, what can we do about it ?
>>
>> I had a look at the code for PersistentHashMap (PersistentHashSet uses 
>> PersistantHashMap internally). I realised that it was possible to "splice" 
>> together the internal structure of two hash maps into a single one without 
>> repeating most of the work required to build one from scratch. So, I had a 
>> go at implementing it:
>>
>>
>> user=> (time (def f (clojure.lang.PersistentHashSet/splice c d)))
>> "Elapsed time: 3052.690911 msecs"
>> #'user/f
>>
>> and:
>>
>> user=> (= e f)
>> true
>>
>> Whilst this is still adding 3 seconds to our time, that 3 seconds is half 
>> the time that we would have added had we executed the second reduction in 
>> serial, rather than in parallel.
>>
>> This means that we can now reduce large datasets into sets/maps more 
>> quickly in parallel than we can in serial :-) As an added benefit, because 
>> splice reuses as much of the internal structure of both inputs as possible, 
>> it's impact in terms of heap consumption and churn is less - although I 
>> think that a full implementation might add some Java-side code complexity.
>>
>> If you would like to give 'splice' a try out, you will need to clone my 
>> fork of clojure at github 
>>
>> https://github.com/JulesGosnell/clojure
>>
>> Please let me know if you try out the code. I would be interested to hear 
>> if people think it is worth pursuing.
>>
>> I was also thinking that it should be possible to use a similar trick to 
>> quickly and cheaply split a map/set into [roughly] equal sized pieces 
>> (assuming an good hash distribution). This would enable the use of a 
>> map/set as an input sequence into the parallel reduction process outlined 
>> above. Currently, I believe that only a vector can be used in this way. It 
>> would be harder to arrange that 'count' could be implemented efficiently on 
>> these sub-maps/sets, but this is not important for the reduction process.
>>
>> BTW - benchmarks were run on a 3.2ghz Phenom II / clojure/master / 
>> openjdk-1.7.0_51 / Fedora 20 with min and max 4gb ram.
>>
>> regards,
>>
>>
>>
>> Jules
>>
>>
>>

-- 
You received this message because you are subscrib

Re: weird bug with cljs.core.async + macros

[Manuel Paccagnella]

Tested on Linux x64, Chromium 31.0.1650.63 and Firefox 26.0. Same behaviour 
that you have seen. However, I haven't looked at the code yet.

Il giorno lunedì 17 febbraio 2014 20:34:22 UTC+1, t x ha scritto:
>
> Can anyone verify whether this bug is reproducible? 
>
> On Mon, Feb 17, 2014 at 12:28 AM, t x > 
> wrote: 
> > Hi, 
> > 
> >   repo: https://github.com/txrev319/bug-report 
> > 
> >   I have a really weird bug where: 
> > 
> >   * (my-macro ...) ==> everything works 
> > 
> >   * (async/go (my-macro ...)) ==> something weird happens 
> > 
> > 
> >   A minimal failure case is documented at: 
> > https://github.com/txrev319/bug-report/blob/master/src/app.cljx 
> > 
> >   It depends on the macro defined in: 
> > https://github.com/txrev319/bug-report/blob/master/src/macros.cljx 
> > 
> >   The bug can be replicated by following the instructions at: 
> > https://github.com/txrev319/bug-report/blob/master/README.md 
> > 
> >   I *believe* I have included everything required to replicate the 
> > bug. If I am missing anything, please let me know. 
> > 
> > 
> > Extra info: 
> > 
> > $ lein --version 
> > Leiningen 2.2.0 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM 
> > 
> > I'm on 64-bit OSX. 
> > 
> > 
> > Thanks! 
>

-- 
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/groups/opt_out.

Grouping a list by 'sublists'..

[Joerg]

Hi,

>From a for-function over some xml-input (filtered and mapped), I get this 
list:

("ITEM2" ["ITEM1"] ["B"] "A" "ITEM1" ["C"])

Now what I want is:

((myfunc ITEM2 ITEM1) (myfunc ITEM2 B) (myfunc ITEM1 C))

that is.. every string can have 0 or more vectors as follow-up items
The String "A" has not, so ideally it is not in my resulting list, but 
filtering the "A" would be a minor issue anyway

Searching for a transformation, I always get into thinking about loop-recur 
constructs,
but I think there maust be a simpler solution for this.

group-by and split-with don't seem to fit here

Best,
Joerg

-- 
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/groups/opt_out.

Re: Grouping a list by 'sublists'..

[Joerg]

so, each string(type) is used as a grouping-key, which prefixes every each 
following string-in-a-vector as an argument to myfunc in the result list.

-- 
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/groups/opt_out.

Re: Looking for advice to fine tune a simple function

[Laurent Droin]

All the good feedback here had me thinking a lot... Especially Andy who 
pushed me towards more abstraction.
I loved the idea of functions that return functions and researching all 
this led me to embrace "partials".

Here is my current implementation of "quantize". It came out of a lot of 
trial and errors (gotta love the REPL) and even though, it became more 
concise,
- I think it can be improved
- I am wondering if I'm going too far. I'm worried that it makes the 
function hard to understand for someone who would maintain it. I don't have 
enough FP experience to get an idea whether this function is well written, 
or if it's just impossible to understand. From an imperative programming 
background, it is certainly impossible to understand.

(def inf Long/MAX_VALUE)
(defn quantize
  "Given a collection of ordered numeric 'markers' such as [m n],  given a 
collection of values such as [a b c],  returns a if x <= m, returns b if m < x 
<= n, returns c if n < x  This should work for any size collections, but the 
values neeed to have  one more element than the markers."
  [x markers values]
  (let 
[f (partial (fn([%1 %2 %3] (cond (<= %1 %2) %3))) x)]
(first (filter #(not (nil? %))(map f (conj markers inf) values)


A few things I don't like:
- (conj markers inf) to artificially add an "infinite enough" value to my 
"markers" collection so that it turns [120 150 165 180] into [120 150 165 
180 ]. Too bad there is no "infinity" in Clojure.
- I hate the #(not (nil? %)) but I could not find a predicate such as 
not-nil?
- I was not able to get (some) to work in this context so I used (first 
(filter instead.
- I could probably make this more readable by applying the Clojure styling 
guide (I will)

Any idea how I could improve this function further for more elegance and 
clarity?

With this function working, I can stick it to some "foundation" library and 
create a simpler "hr" library.

My "hr" library would contain:

(def hr-zones [:z1 :z2 :z3 :z4 :z5])
(defn get-hr-zone [hr-zones-def bpm]
  (quantize bpm hr-zones-def hr-zones))



And then, my client application would have:

(def get-my-hr-zone 
  (partial get-hr-zone [120 150 165 180]))
(get-my-hr-zone 119)(get-my-hr-zone 120)(get-my-hr-zone 149)(get-my-hr-zone 
150)(get-my-hr-zone 151)



BTW, thanks Andy for the tip about Pygments.

-- 
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/groups/opt_out.

Re: weird bug with cljs.core.async + macros

[t x]

Thanks for verifying!

@tbaldridge: can you enlighten us on if:

  * I'm doing something stupid or
  * this is an actual bug in cljs/core.async?

Thanks!

On Mon, Feb 17, 2014 at 2:10 PM, Manuel Paccagnella
 wrote:
> Tested on Linux x64, Chromium 31.0.1650.63 and Firefox 26.0. Same behaviour
> that you have seen. However, I haven't looked at the code yet.
>
> Il giorno lunedì 17 febbraio 2014 20:34:22 UTC+1, t x ha scritto:
>>
>> Can anyone verify whether this bug is reproducible?
>>
>> On Mon, Feb 17, 2014 at 12:28 AM, t x  wrote:
>> > Hi,
>> >
>> >   repo: https://github.com/txrev319/bug-report
>> >
>> >   I have a really weird bug where:
>> >
>> >   * (my-macro ...) ==> everything works
>> >
>> >   * (async/go (my-macro ...)) ==> something weird happens
>> >
>> >
>> >   A minimal failure case is documented at:
>> > https://github.com/txrev319/bug-report/blob/master/src/app.cljx
>> >
>> >   It depends on the macro defined in:
>> > https://github.com/txrev319/bug-report/blob/master/src/macros.cljx
>> >
>> >   The bug can be replicated by following the instructions at:
>> > https://github.com/txrev319/bug-report/blob/master/README.md
>> >
>> >   I *believe* I have included everything required to replicate the
>> > bug. If I am missing anything, please let me know.
>> >
>> >
>> > Extra info:
>> >
>> > $ lein --version
>> > Leiningen 2.2.0 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM
>> >
>> > I'm on 64-bit OSX.
>> >
>> >
>> > Thanks!
>
> --
> 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/groups/opt_out.

-- 
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/groups/opt_out.

Re: weird bug with cljs.core.async + macros

[Michał Marczyk]

The same thing happens in Clojure:

(defmacro silly [object pat1 body1 pat2 body2]
  `(case (:tag ~object)
 ~pat1 ~body1
 ~body2))

(def out (java.io.StringWriter.))

(defn log [& args]
  (doseq [arg args]
(.write out (str arg))
(.write out "\n")))

(defn init []
  (silly {:tag :dog}
 :dog (log "without-go: woof woof")
 cat (log "without-go: unrecognized"))
  (async/go
   (silly {:tag :dog}
  :dog (log "with-go: woof woof")
  cat (log "with-go: unrecognized"

(init)

(print (str out))
without-go: woof woof
with-go: woof woof
with-go: unrecognized
nil

Cheers,
Michał


On 18 February 2014 01:01, t x  wrote:
> Thanks for verifying!
>
> @tbaldridge: can you enlighten us on if:
>
>   * I'm doing something stupid or
>   * this is an actual bug in cljs/core.async?
>
> Thanks!
>
> On Mon, Feb 17, 2014 at 2:10 PM, Manuel Paccagnella
>  wrote:
>> Tested on Linux x64, Chromium 31.0.1650.63 and Firefox 26.0. Same behaviour
>> that you have seen. However, I haven't looked at the code yet.
>>
>> Il giorno lunedì 17 febbraio 2014 20:34:22 UTC+1, t x ha scritto:
>>>
>>> Can anyone verify whether this bug is reproducible?
>>>
>>> On Mon, Feb 17, 2014 at 12:28 AM, t x  wrote:
>>> > Hi,
>>> >
>>> >   repo: https://github.com/txrev319/bug-report
>>> >
>>> >   I have a really weird bug where:
>>> >
>>> >   * (my-macro ...) ==> everything works
>>> >
>>> >   * (async/go (my-macro ...)) ==> something weird happens
>>> >
>>> >
>>> >   A minimal failure case is documented at:
>>> > https://github.com/txrev319/bug-report/blob/master/src/app.cljx
>>> >
>>> >   It depends on the macro defined in:
>>> > https://github.com/txrev319/bug-report/blob/master/src/macros.cljx
>>> >
>>> >   The bug can be replicated by following the instructions at:
>>> > https://github.com/txrev319/bug-report/blob/master/README.md
>>> >
>>> >   I *believe* I have included everything required to replicate the
>>> > bug. If I am missing anything, please let me know.
>>> >
>>> >
>>> > Extra info:
>>> >
>>> > $ lein --version
>>> > Leiningen 2.2.0 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM
>>> >
>>> > I'm on 64-bit OSX.
>>> >
>>> >
>>> > Thanks!
>>
>> --
>> 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/groups/opt_out.
>
> --
> 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/groups/opt_out.

-- 
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/groups/opt_out.

Re: weird bug with cljs.core.async + macros

[Michał Marczyk]

Just to be clear, the above is a version of t x's bug-report modified
to use a StringWriter instead of console.log.

Cheers,
Michał


On 18 February 2014 01:25, Michał Marczyk  wrote:
> The same thing happens in Clojure:
>
> (defmacro silly [object pat1 body1 pat2 body2]
>   `(case (:tag ~object)
>  ~pat1 ~body1
>  ~body2))
>
> (def out (java.io.StringWriter.))
>
> (defn log [& args]
>   (doseq [arg args]
> (.write out (str arg))
> (.write out "\n")))
>
> (defn init []
>   (silly {:tag :dog}
>  :dog (log "without-go: woof woof")
>  cat (log "without-go: unrecognized"))
>   (async/go
>(silly {:tag :dog}
>   :dog (log "with-go: woof woof")
>   cat (log "with-go: unrecognized"
>
> (init)
>
> (print (str out))
> without-go: woof woof
> with-go: woof woof
> with-go: unrecognized
> nil
>
> Cheers,
> Michał
>
>
> On 18 February 2014 01:01, t x  wrote:
>> Thanks for verifying!
>>
>> @tbaldridge: can you enlighten us on if:
>>
>>   * I'm doing something stupid or
>>   * this is an actual bug in cljs/core.async?
>>
>> Thanks!
>>
>> On Mon, Feb 17, 2014 at 2:10 PM, Manuel Paccagnella
>>  wrote:
>>> Tested on Linux x64, Chromium 31.0.1650.63 and Firefox 26.0. Same behaviour
>>> that you have seen. However, I haven't looked at the code yet.
>>>
>>> Il giorno lunedì 17 febbraio 2014 20:34:22 UTC+1, t x ha scritto:

 Can anyone verify whether this bug is reproducible?

 On Mon, Feb 17, 2014 at 12:28 AM, t x  wrote:
 > Hi,
 >
 >   repo: https://github.com/txrev319/bug-report
 >
 >   I have a really weird bug where:
 >
 >   * (my-macro ...) ==> everything works
 >
 >   * (async/go (my-macro ...)) ==> something weird happens
 >
 >
 >   A minimal failure case is documented at:
 > https://github.com/txrev319/bug-report/blob/master/src/app.cljx
 >
 >   It depends on the macro defined in:
 > https://github.com/txrev319/bug-report/blob/master/src/macros.cljx
 >
 >   The bug can be replicated by following the instructions at:
 > https://github.com/txrev319/bug-report/blob/master/README.md
 >
 >   I *believe* I have included everything required to replicate the
 > bug. If I am missing anything, please let me know.
 >
 >
 > Extra info:
 >
 > $ lein --version
 > Leiningen 2.2.0 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM
 >
 > I'm on 64-bit OSX.
 >
 >
 > Thanks!
>>>
>>> --
>>> 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/groups/opt_out.
>>
>> --
>> 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/groups/opt_out.

-- 
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/groups/opt_out.

Re: Looking for advice to fine tune a simple function

[Andy-]

On Monday, February 17, 2014 6:43:18 PM UTC-5, Laurent Droin wrote:
>
>
> (def inf Long/MAX_VALUE)
> (defn quantize
>   [x markers values]
>   (let 
> [f (partial (fn([%1 %2 %3] (cond (<= %1 %2) %3))) x)]
> (first (filter #(not (nil? %))(map f (conj markers inf) values)
>
>
The reason I didn't go with Long/MAX_VALUE is that it breaks down for 
 arbitrary precision and bigints which is a no-no for me.

There is many many ways this function could look. Mine is just one example. 
For instance many clojurist's would probably prefer to call it like this:

(quantize 0 :small 5 :med :10 :large :huge).

I didn't go through your code. But many people don't like to overuse 
anonymous functions especially if you use 3 parameters (what is %1, %2 %3?, 
if they had a name it'd be clearer). But this is just style so it's very 
subjective.

Cheers

-- 
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/groups/opt_out.

Re: weird bug with cljs.core.async + macros

[t x]

Hi Michal,

  Does this mean:

  (a) the reported behavior is normal (and my bug report is invalid) or

  (b) this error happens in both cljs + clojure ?

Thanks!

On Mon, Feb 17, 2014 at 4:33 PM, Michał Marczyk
 wrote:
> Just to be clear, the above is a version of t x's bug-report modified
> to use a StringWriter instead of console.log.
>
> Cheers,
> Michał
>
>
> On 18 February 2014 01:25, Michał Marczyk  wrote:
>> The same thing happens in Clojure:
>>
>> (defmacro silly [object pat1 body1 pat2 body2]
>>   `(case (:tag ~object)
>>  ~pat1 ~body1
>>  ~body2))
>>
>> (def out (java.io.StringWriter.))
>>
>> (defn log [& args]
>>   (doseq [arg args]
>> (.write out (str arg))
>> (.write out "\n")))
>>
>> (defn init []
>>   (silly {:tag :dog}
>>  :dog (log "without-go: woof woof")
>>  cat (log "without-go: unrecognized"))
>>   (async/go
>>(silly {:tag :dog}
>>   :dog (log "with-go: woof woof")
>>   cat (log "with-go: unrecognized"
>>
>> (init)
>>
>> (print (str out))
>> without-go: woof woof
>> with-go: woof woof
>> with-go: unrecognized
>> nil
>>
>> Cheers,
>> Michał
>>
>>
>> On 18 February 2014 01:01, t x  wrote:
>>> Thanks for verifying!
>>>
>>> @tbaldridge: can you enlighten us on if:
>>>
>>>   * I'm doing something stupid or
>>>   * this is an actual bug in cljs/core.async?
>>>
>>> Thanks!
>>>
>>> On Mon, Feb 17, 2014 at 2:10 PM, Manuel Paccagnella
>>>  wrote:
 Tested on Linux x64, Chromium 31.0.1650.63 and Firefox 26.0. Same behaviour
 that you have seen. However, I haven't looked at the code yet.

 Il giorno lunedì 17 febbraio 2014 20:34:22 UTC+1, t x ha scritto:
>
> Can anyone verify whether this bug is reproducible?
>
> On Mon, Feb 17, 2014 at 12:28 AM, t x  wrote:
> > Hi,
> >
> >   repo: https://github.com/txrev319/bug-report
> >
> >   I have a really weird bug where:
> >
> >   * (my-macro ...) ==> everything works
> >
> >   * (async/go (my-macro ...)) ==> something weird happens
> >
> >
> >   A minimal failure case is documented at:
> > https://github.com/txrev319/bug-report/blob/master/src/app.cljx
> >
> >   It depends on the macro defined in:
> > https://github.com/txrev319/bug-report/blob/master/src/macros.cljx
> >
> >   The bug can be replicated by following the instructions at:
> > https://github.com/txrev319/bug-report/blob/master/README.md
> >
> >   I *believe* I have included everything required to replicate the
> > bug. If I am missing anything, please let me know.
> >
> >
> > Extra info:
> >
> > $ lein --version
> > Leiningen 2.2.0 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM
> >
> > I'm on 64-bit OSX.
> >
> >
> > Thanks!

 --
 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/groups/opt_out.
>>>
>>> --
>>> 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/groups/opt_out.
>
> --
> 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...

Re: Looking for advice to fine tune a simple function

[Laurent Droin]

All good points Andy. Thanks. I'll continue working on it until I'm happy.

I am almost never happy with anonymous functions either. In this particular 
case, though, the function is so simple that I felt it would be overkill to 
externalize it into another function (unless I'm really going to use it 
somewhere else). The fact that we don't know what the parameters are didn't 
bother me too much:

(cond (<= %1 %2) %3))
I just wanted something that return the third parameter if parameter 1 <= 
parameter 2. It seemed too abstract to try to label the parameters.

About the Long/MAX_VALUE, I didn't like it and you're right that it will 
only work for integers (if I read correctly, they are actually long in 
Clojure) but that won't work for all other numerical types. I don't see any 
solution to my problem besides having to do a test that is different from 
all the other tests in the function.
I also like the function signature you came up with initially. It does make 
sense and it's probably more elegant than passing two collections.

But as you said, there are many ways to implement the same thing. I would 
like to follow best practices as much as possible.

-- 
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/groups/opt_out.

Re: Grouping a list by 'sublists'..

[Leif]

Hi, Joerg.

When I have a sequence I want to split into sub-sequences, I use the 
partition.* functions:
(->> your-seq (partition-by string?) (partition 2))
will get you very close to your solution.

A slightly lower-level technique if you need more control is to construct a 
lazy sequence yourself.  Refer to the source of the partition fns, e.g. 
(clojure.repl/source partition-by)
I think a combination of lazy-seq with (split-with sequential?) would work.

Yet another option is to see if it is cleaner to change the original xml 
parsing function to give you the nested data structure you want directly.

Happy coding,
Leif

On Monday, February 17, 2014 5:50:13 PM UTC-5, Joerg wrote:
>
> Hi,
>
> From a for-function over some xml-input (filtered and mapped), I get this 
> list:
>
> ("ITEM2" ["ITEM1"] ["B"] "A" "ITEM1" ["C"])
>
> Now what I want is:
>
> ((myfunc ITEM2 ITEM1) (myfunc ITEM2 B) (myfunc ITEM1 C))
>
> that is.. every string can have 0 or more vectors as follow-up items
> The String "A" has not, so ideally it is not in my resulting list, but 
> filtering the "A" would be a minor issue anyway
>
> Searching for a transformation, I always get into thinking about 
> loop-recur constructs,
> but I think there maust be a simpler solution for this.
>
> group-by and split-with don't seem to fit here
>
> Best,
> Joerg
>

-- 
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/groups/opt_out.

Re: Looking for advice to fine tune a simple function

[Laurent Droin]

So here is a new attempt at the quantize function so that I no longer have 
to deal with the "infinity" problem:

(defn quantize-2 
  [x params]
  (let [f (partial (fn [a [b c]] (cond(<= a c) b)) x)]
(or 
 (first (filter #(not (nil? %)) (map f (into [](partition 2 2 params))) 
 (last params))


params now has this form: 

[:zone-1 120 :zone-2 150 :zone-3 165 :zone-4 180 :zone-5]


i.e. the values to return are intermingled with the "boundaries". I 
normally don't like mixing things but you've gotta admit that it looks just 
like how you would draw heart rates on a schema on paper: zone1 | zone 2 | 
zone 3 | zone 4 | zone 5 and you would probably have the values 120, 150, 
165 and 180 written in between the zone names, just above the | characters.

The way I got rid of the infinity is by using the "or". I'm looking for the 
first non null value (when trying to find whether x is <= 120, <= 150, 
<=165, <=180, and if I don't find any, then it must be that we're in the 
last "category" of my params collection.

Still not sure whether it's the optimum way to do it but I'll continue 
researching (after all, this is not a professional project, I have no 
deadline, and I can keep trying to improve  - great way to learn).
The feedback I got on this post got me working and scratching my head all 
weekend. This is great. 

-- 
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/groups/opt_out.

Re: rseq for subvec in clojurescript

[Sunil S Nandihalli]

thanks Michal for the fix.


On Mon, Feb 17, 2014 at 12:58 AM, Michał Marczyk
wrote:

> It is now, thanks for the report!
>
> Ticket with patch:
>
> http://dev.clojure.org/jira/browse/CLJS-765
>
>
> On 16 February 2014 17:48, Sunil S Nandihalli
>  wrote:
> > Hi Everybody,
> >
> > I get the following error when I do a rseq on a subvec in clojurescript
> > Uncaught Error: No protocol method IReversible.-rseq defined for type
> > cljs.core/Subvec: [(:red :clockwise) (:blue :clockwise) (:yellow
> :clockwise)
> > (:yellow :clockwise) (:orange :clockwise)]
> >
> > Is this a known problem?
> > Thanks, Sunil
> >
> > --
> > 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/groups/opt_out.
>
> --
> 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/groups/opt_out.
>

-- 
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/groups/opt_out.

Re: Looking for advice to fine tune a simple function

[Laurent Droin]

So here is a new attempt at the quantize function so that I no longer have 
to deal with the "infinity" problem:

(defn quantize-2 
  [x params]
  (let [f (partial (fn [a [b c]] (cond(<= a c) b)) x)]
(println (first (filter #(not (nil? %))(map f (into [](partition 2 
params))
(or 
 (first (filter #(not (nil? %)) (map f (into [](partition 2 params) 
 (last params


params now has this form: 

[:zone-1 120 :zone-2 150 :zone-3 165 :zone-4 180 :zone-5]


i.e. the values to return are intermingled with the "boundaries". I 
normally don't like mixing things but you've gotta admit that it looks just 
like how you would draw heart rates on a schema on paper: zone1 | zone 2 | 
zone 3 | zone 4 | zone 5 and you would probably have the values 120, 150, 
165 and 180 written in between the zone names, just above the | characters.

The way I got rid of the infinity is by using the "or". I'm looking for the 
first non null value (when trying to find whether x is <= 120, <= 150, 
<=165, <=180, and if I don't find any, then it must be that we're in the 
last "category" of my params collection.

Still not sure whether it's the optimum way to do it but I'll continue 
researching (after all, this is not a professional project, I have no 
deadline, and I can keep trying to improve  - great way to learn).
The feedback I got on this post got me working and scratching my head all 
weekend. This is great. 

-- 
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/groups/opt_out.

Re: Looking for advice to fine tune a simple function

[Laurent Droin]

So here is a new attempt at the quantize function so that I no longer have 
to deal with the "infinity" problem:

(defn quantize-2 
  [x params]
  (let [f (partial (fn [a [b c]] (cond(<= a c) b)) x)]
(or 
 (first (filter #(not (nil? %)) (map f (into [](partition 2 params) 
 (last params


params now has this form: 

[:zone-1 120 :zone-2 150 :zone-3 165 :zone-4 180 :zone-5]


i.e. the values to return are intermingled with the "boundaries". I 
normally don't like mixing things but you've gotta admit that it looks just 
like how you would draw heart rates on a schema on paper: zone1 | zone 2 | 
zone 3 | zone 4 | zone 5 and you would probably have the values 120, 150, 
165 and 180 written in between the zone names, just above the | characters.

The way I got rid of the infinity is by using the "or". I'm looking for the 
first non null value (when trying to find whether x is <= 120, <= 150, 
<=165, <=180, and if I don't find any, then it must be that we're in the 
last "category" of my params collection.

Still not sure whether it's the optimum way to do it but I'll continue 
researching (after all, this is not a professional project, I have no 
deadline, and I can keep trying to improve  - great way to learn).
The feedback I got on this post got me working and scratching my head all 
weekend. This is great. 

-- 
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/groups/opt_out.

Re: Looking for advice to fine tune a simple function

[Laurent Droin]

Hmmm, looks like I can replace

#(not (nil? %))

by
(complement nil?)

which seems more elegant.

Also, it looks like I don't need that (into [] ), which will keep the code 
cleaner.

I think I could also get rid of the (or) by always adding "(last params)" 
at the end of the sequence from which I pick the first non null element. 
The problem with this is that I need to make sure I add this element at the 
end of the collection, and map returns a list, which means that I would 
need to convert it into a vector if I want to use conj.
Or maybe there's a way to guarantee that I can add an element at the end of 
the list.  I know it's not cheap but I'm not sure if it will make a 
significant difference for what I'm doing. 
I think I could really abuse the "into" function and that doesn't seem 
quite right.

-- 
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/groups/opt_out.

Re: weird bug with cljs.core.async + macros

[t x]

Building on Michal's example, here is a "more minimal example" --
which also "fails" in Clojure:


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


(defmacro silly [obj pat1 body1 other]
  `(case ~obj
 ~pat1 ~body1
 ~other))

(let []

  (def out (java.io.StringWriter.))

  (defn log [& args]
(doseq [arg args]
  (.write out (str arg))
  (.write out "\n")))


  (async/ wrote:
> Hi Michal,
>
>   Does this mean:
>
>   (a) the reported behavior is normal (and my bug report is invalid) or
>
>   (b) this error happens in both cljs + clojure ?
>
> Thanks!
>
> On Mon, Feb 17, 2014 at 4:33 PM, Michał Marczyk
>  wrote:
>> Just to be clear, the above is a version of t x's bug-report modified
>> to use a StringWriter instead of console.log.
>>
>> Cheers,
>> Michał
>>
>>
>> On 18 February 2014 01:25, Michał Marczyk  wrote:
>>> The same thing happens in Clojure:
>>>
>>> (defmacro silly [object pat1 body1 pat2 body2]
>>>   `(case (:tag ~object)
>>>  ~pat1 ~body1
>>>  ~body2))
>>>
>>> (def out (java.io.StringWriter.))
>>>
>>> (defn log [& args]
>>>   (doseq [arg args]
>>> (.write out (str arg))
>>> (.write out "\n")))
>>>
>>> (defn init []
>>>   (silly {:tag :dog}
>>>  :dog (log "without-go: woof woof")
>>>  cat (log "without-go: unrecognized"))
>>>   (async/go
>>>(silly {:tag :dog}
>>>   :dog (log "with-go: woof woof")
>>>   cat (log "with-go: unrecognized"
>>>
>>> (init)
>>>
>>> (print (str out))
>>> without-go: woof woof
>>> with-go: woof woof
>>> with-go: unrecognized
>>> nil
>>>
>>> Cheers,
>>> Michał
>>>
>>>
>>> On 18 February 2014 01:01, t x  wrote:
 Thanks for verifying!

 @tbaldridge: can you enlighten us on if:

   * I'm doing something stupid or
   * this is an actual bug in cljs/core.async?

 Thanks!

 On Mon, Feb 17, 2014 at 2:10 PM, Manuel Paccagnella
  wrote:
> Tested on Linux x64, Chromium 31.0.1650.63 and Firefox 26.0. Same 
> behaviour
> that you have seen. However, I haven't looked at the code yet.
>
> Il giorno lunedì 17 febbraio 2014 20:34:22 UTC+1, t x ha scritto:
>>
>> Can anyone verify whether this bug is reproducible?
>>
>> On Mon, Feb 17, 2014 at 12:28 AM, t x  wrote:
>> > Hi,
>> >
>> >   repo: https://github.com/txrev319/bug-report
>> >
>> >   I have a really weird bug where:
>> >
>> >   * (my-macro ...) ==> everything works
>> >
>> >   * (async/go (my-macro ...)) ==> something weird happens
>> >
>> >
>> >   A minimal failure case is documented at:
>> > https://github.com/txrev319/bug-report/blob/master/src/app.cljx
>> >
>> >   It depends on the macro defined in:
>> > https://github.com/txrev319/bug-report/blob/master/src/macros.cljx
>> >
>> >   The bug can be replicated by following the instructions at:
>> > https://github.com/txrev319/bug-report/blob/master/README.md
>> >
>> >   I *believe* I have included everything required to replicate the
>> > bug. If I am missing anything, please let me know.
>> >
>> >
>> > Extra info:
>> >
>> > $ lein --version
>> > Leiningen 2.2.0 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM
>> >
>> > I'm on 64-bit OSX.
>> >
>> >
>> > Thanks!
>
> --
> 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/groups/opt_out.

 --
 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/groups/opt_out.
>>
>> --
>> You received this message because you are subscribed to the Google
>>