I have had a similar thing happen with the core.match/match macro - a lot
of examples simply break when put inside a go block. I thought it might
have been something to do with aot compilation but I'm not sure.
Adam
On 18 Feb 2014 05:33, t x txrev...@gmail.com wrote:
Building on Michal's
On 18 February 2014 02:14, t x txrev...@gmail.com wrote:
Does this mean:
(a) the reported behavior is normal (and my bug report is invalid) or
(b) this error happens in both cljs + clojure ?
I'd say (b).
--
You received this message because you are subscribed to the Google
Groups
While I haven't tested the code, I can see one obvious mistake.
https://github.com/txrev319/bug-report/blob/master/src/app.cljx#L20
cat is undefined?
Also why is it macros.cljX? Not sure what happens when cljs encounters a
defmacro but it should throw an error no?
HTH,
/thomas
On Monday,
On Tue, Feb 18, 2014 at 11:18 AM, Thomas Heller th.hel...@gmail.com wrote:
While I haven't tested the code, I can see one obvious mistake.
https://github.com/txrev319/bug-report/blob/master/src/app.cljx#L20
cat is undefined?
That isn't a mistake. `silly` expands into a case, which expects
I'm unable to decipher from these examples exactly what is expected and
what is going on. Can someone write me a concise 1 paragraph description of
the problem. Something like:
When a case is emitted from a macro into the body of a go, . happens
I think it's probably something related to how
Well, while case allows for symbols it still doesn't make sense to use it
except :tag switches between keywords and symbols to. Apart from that cat
pat2 is never actually used.
(defmacro silly [object pat1 body1 pat2 body2]
`(case (:tag ~object)
~pat1 ~body1
~body2))
But as
Hi Timothy,
One paragraph summary:
When a macro expands to case inside of a go-block, it appears that
the _ELSE_ clause of the case is always run. (Even after a previous
clause has matched.)
Slightly longer summary:
In these lines:
@Thomas:
(this is completely unrelated to the actual bug)
This particular code was simplified from a more complicated macro
-- where for the else clause, I want to capture the original value, so
it would be something like:
(silly obj
:dog dog-line
cat cat-line) ==
(case (:tag
When a macro expands to case inside of a go-block, it appears that
the _ELSE_ clause of the case is always run. (Even after a previous
clause has matched.)
Thanks, I'll get a test in the project for this, it'll probably be fixed in
the next alpha release. Until then, cond or condp might work?
Hi Timothy,
I've picked case over cond/condp because I want a O(1) dispatch
rather than linear execution since there are many patterns [though I'm
probably guilty of premature optimization here].
I've currently been working around it via two techniques:
** Refactoring it into a function.
On 18 February 2014 22:15, t x txrev...@gmail.com wrote:
I've picked case over cond/condp because I want a O(1) dispatch
rather than linear execution since there are many patterns [though I'm
probably guilty of premature optimization here].
Actually in ClojureScript case dispatch is O(n),
On 18 February 2014 22:31, Michał Marczyk michal.marc...@gmail.com wrote:
Actually in ClojureScript case dispatch is O(n), since it's
implemented as a macro expanding to cond.
As of release 2156:
https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1119
--
You received
Looking at
https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1144-L1147
, you win. :-)
On Tue, Feb 18, 2014 at 1:33 PM, Michał Marczyk
michal.marc...@gmail.com wrote:
On 18 February 2014 22:31, Michał Marczyk michal.marc...@gmail.com wrote:
Actually in ClojureScript
Due to asm.js some JS engines are starting to compile switch statements
where the cases are integers into jump tables. Compiler enhancement that
compiles optimizable case expressions to JS switch statements would be a
welcome enhancement - http://dev.clojure.org/jira/browse/CLJS-713.
David
On
Great! First cut at compiling case to switch (when given numbers and
strings only as tests at the moment, but this can be improved) here:
https://github.com/michalmarczyk/clojurescript/tree/713-compile-case-to-switch
I'll post more details on the ticket.
Cheers,
Michał
On 18 February 2014
With apologies for potential stupidity:
* (get {... } key) is an operation that is O(log n) worst case (if
using Red-Black trees) or O(1) average case (hashing)
* (get { ... } key) does not have integer/string limitation
Therefore: why are we not compiling down to get ? Are the big-Oh
constants
Firstly, I think you over estimate the cost of an if. Ifs are very very
fast, especially if you are doing identical? checks (like a case is doing).
A simple pointer comparison such as (keyword-identical? :foo :foo) is going
to be way faster than a hashmap lookup.
Secondly, ifs are very JIT
switch can be compiled to a direct array indexing operation or a
binary search. I believe that's what the JVM does for tableswitch and
lookupswitch, respectively.
On 19 February 2014 01:02, t x txrev...@gmail.com wrote:
With apologies for potential stupidity:
* (get {... } key) is an operation
@Timothy, Michal:
Understood. Thanks for clarifying!
On Tue, Feb 18, 2014 at 5:09 PM, Michał Marczyk
michal.marc...@gmail.com wrote:
switch can be compiled to a direct array indexing operation or a
binary search. I believe that's what the JVM does for tableswitch and
lookupswitch,
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
Can anyone verify whether this bug is reproducible?
On Mon, Feb 17, 2014 at 12:28 AM, t x txrev...@gmail.com 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
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,
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
manuel.paccagne...@gmail.com wrote:
Tested on Linux x64, Chromium 31.0.1650.63 and Firefox
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}
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 michal.marc...@gmail.com wrote:
The same thing happens in Clojure:
(defmacro silly [object pat1 body1 pat2 body2]
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
michal.marc...@gmail.com wrote:
Just to be clear, the above is a version of t x's
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 [
27 matches
Mail list logo
