Thank you!
On Fri, Nov 23, 2012 at 3:04 PM, dmiller wrote:
> Frank:
>
> Fixed in the master branch (which is 1.5 dev).
> I also created a new branch named clojure-1.4.1 that is still a 1.4
> version, with the the patch.
> Also created binary distribution zip files for the new 1.4.1 release.
> S
Frank:
Fixed in the master branch (which is 1.5 dev).
I also created a new branch named clojure-1.4.1 that is still a 1.4
version, with the the patch.
Also created binary distribution zip files for the new 1.4.1 release.
Several other bug fixes included in this update.
-David
On Friday, Novem
Thank you David for looking into this so quickly. For now I am working
around this by not destructuring, but I look forward to the patch. Thanks.
-Frank
On Thursday, November 15, 2012 7:41:39 PM UTC-5, dmiller wrote:
>
> The difference is that the JVM version is correct and the CLR
> implemen
The difference is that the JVM version is correct and the CLR
implementation has a bug.
I'll fix it in the current branch and try to get a patched 1.4 out as soon
as I can.
-- Above is all you really need to know, but I find myself forced to
continue. :) --
This bug has sitting there from the
Binding to [& rst] must realize an element of the sequence, to determine if
there are any left, and it promises to never bind (), only nil.
On Thursday, November 15, 2012 7:23:05 AM UTC-8, ffailla wrote:
>
> I believe I have discovered differing behavior between the JVM and CLR
> implementations
I believe I have discovered differing behavior between the JVM and CLR
implementations when running the following statement:
user> (let [foo (repeatedly (fn [] (let [r (rand)]
(println "in-repeat: " r)
r)))
[f & rst] foo]
(println "return: " f))
When run on the JVM with clojure 1.4.0,
