Sorry, posted the wrong data describing the problem. Here it is.
https://gist.github.com/1257122
On Oct 2, 12:39 am, Daniel doubleagen...@gmail.com wrote:
This might be an issue with my log4j properties file, Cake, or
tools.logging, Here's my log4j.properties file:
On Sat, Oct 1, 2011 at 10:16 PM, Tal Liron tal.li...@gmail.com wrote:
And the issue for me now is concern about what will happen to all
these contribs in the future if a core language feature changes, such as the
dynamic Var issue in 1.3. If these contribs are not being built and shipped
as
On Sat, Oct 1, 2011 at 9:52 PM, Daniel doubleagen...@gmail.com wrote:
user= (= 23.0 23)
false
With every language I've ever worked in, I've always been told that
comparing floating point numbers for equality is a bad idea so I'm
actually glad to see that the above comparison is false...
--
On 10/02/2011 01:05 AM, Sean Corfield wrote:
Actually I think you're in a better position now. The
"new contrib"
libraries are all actively maintained and are expected to be
compatible with both Clojure 1.2.x and 1.3.0. I'm also hearing a
possibility that a
On Sat, Oct 1, 2011 at 11:24 PM, Tal Liron tal.li...@gmail.com wrote:
You're right, it sounds in line with my hopes!
Great!
Would it be possible to think of a better name for this sister project than
new contrib? Something that implies its tight relationship with Clojure? I
suggest Clojure
Actually I am mostly looking forward to Phil's Getting Cozy with Emacs.
I am very disappointed that there aren't more buzz about it.
Come on people - it's about Emacs!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
user= (= 23.0 23)
false
user= (= 23 23)
true
This is the correct behavior. If the doc string is confusing, please propose
alternate language.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To
The changes I posted previously solved the problem for me on open-jdk
6 on ubuntu. All I had to do was fix the package name and add the
optimization level and everything worked fine. I haven't checked to
see if master has changed in a way that would affect this patch. As I
mentioned above,
The big picture is falling into place for core.match. The most significant
change is that we now have two compilation schemes based on the presence of
recur. If recur is not present we use a much more efficient backtracking
strategy which results in dramatically less code generation.
There a lot
Follow-up question: Can someone explain the rationale behind the change to =
semantics between integers and floating-point numbers? I have read the
design page (
http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics), but all
it seems to have is this somewhat cryptic description:
Phil's was a 3 hour workshop and was not recorded sorry.
On Oct 2, 4:01 am, Andreas Liljeqvist bon...@gmail.com wrote:
Actually I am mostly looking forward to Phil's Getting Cozy with Emacs.
I am very disappointed that there aren't more buzz about it.
Come on people - it's about Emacs!
Dave Sann daves...@gmail.com writes:
Hi,
I run Artifactory as a local repository manager. Currently, I am adding
:omit-default-repositories true
:repositories {releases http://artifactory/artifactory/libs-release;
snapshots
user= (def m { 3.0 :a 3 :b})
#'user/a
user= a
{3.0 :a, 3 :b}
user= (get m 3.0 )
:a
user= (get m 3 )
:b
user=
if 3.0 and 3 were to be considered equals, you could not represent the above
map,
the second entry would squash the first.
Now if we want to allow such maps, then we cannot consider
Right. I didn't see this earlier (http://dev.clojure.org/display/doc/
Documentation+for+1.3+Numerics). We're all on the same page now. (=
If the doc string is confusing, please propose alternate language.
Updating the '=' docstring to match that page sounds appropriate ie
adding ...,but not
Luc,
I think you are mistaken.
user= (clojure-version)
1.2.1
user= (def m {3.0 :a 3 :b})
#'user/m
user= (get m 3.0)
:a
user= (get m 3)
:b
user= (= 3 3.0)
true
user=
Do you have another example?
- Chris
--
You received this message because you are subscribed to the Google
Groups Clojure
Hi,
I hope, people are aware that Oracle considers OpenJDK to be the standard
choice for Linux users now and removed the special distributor's license.
See http://robilad.livejournal.com/90792.html
Kind regards,
Stefan
--
You received this message because you are subscribed to the Google
I think he's saying that it boiled down to consistency ie it's
inconsistent to allow maps where 3 != 3.0, but make 3 = 3.0 fit
clojure equality semantics. I don't know if that's satisfying, but
it's fair.
On Oct 2, 3:31 pm, Chris Perkins chrisperkin...@gmail.com wrote:
Luc,
I think you are
What I meant is that (= 3 3.0) is the erroneous behavior.
Either it's equal every where (including as keys in maps) or not.
You cannot have both semantics coexists. It's all or nothing.
Look at this the other way around (1.2):
user= {3 :a 3 :b}
java.lang.IllegalArgumentException: Duplicate
Ok, I follow you now. That makes sense. Sort-of :)
On the other hand, it's only inconsistent if you consider clojure's = to map
to java's .equals method, but it does not:
user= (clojure-version)
1.2.1
user= (= 3 3.0)
true
user= (.equals 3 3.0)
false
So it doesn't really violate the contract
You can now use core.match with ClojureScript. This is far less tested than
Clojure, feel free to open issues - http://dev.clojure.org/jira/browse/MATCH
David
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
Stu's comment actually worries me in this respect: the fact that each contrib
has its own version may make it easier to evaluate them separately, but it
would appear to me as a defeatist goal for Clojure moving forward.
Things that are simple can be composited. Things that are compounds
Erg, Make that 0.2.0-alpha3.
David
On Sun, Oct 2, 2011 at 5:05 PM, David Nolen dnolen.li...@gmail.com wrote:
You can now use core.match with ClojureScript. This is far less tested than
Clojure, feel free to open issues -
http://dev.clojure.org/jira/browse/MATCH
David
--
You received
On Sunday, October 2, 2011 4:30:51 PM UTC-5, stuart@gmail.com wrote:
Modularity helps, not hurts, in achieving this.
I can see that now. Thanks to everyone who provided clarifications about the
new contrib organization!
Contrarily, it seems that effort is being put into cleaning up
In practice, in most languages, it's uncertain to test for equality between
floating point values.
This is mainly a side effect of internal representations.
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
It's probably safer to keep things that way. Ints (or longs) are
Hey folks!
I released Noir 1.2.0 today. Highlights include:
* Clojure 1.3.0 support
* Named routes
* (url-for) to find the url given a named route
* App Engine support
* Lots of exciting points for other lib integration
Full change log here:
Hi all,
tools.trace 0.7.1 is now available. It passed all the matrix compatibility
tests.
I added tests to it so it's really going through some testing :)
This is mainly a repackaging of the original contrib.trace code written by
Stuart Sierra.
This release allows deftrace to accept a doc
Contrarily, it seems that effort is being put into cleaning up the core and
jettisoning anything merely suspected of being superfluous.
That certainly isn't an objective. Can you list some examples of things that
in your opinion were casually jettisoned?
I didn't use the word casually.
Make sure you have leiningen installed, that way we can use the lein-
noir plugin to create a new noir project.
Is there anything like this for Cake?
On Oct 2, 5:10 pm, Chris Granger ibdk...@gmail.com wrote:
Hey folks!
I released Noir 1.2.0 today. Highlights include:
* Clojure 1.3.0
I like your website design.
--
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
Hello folks,
I've been playing a little with core.match and thought it would be fun to
make a defmatch macro:
https://gist.github.com/1258277
The super simple macro I came up with enables this:
(defmacro defmatch [name bindings patterns]
`(defn ~name ~bindings
(match ~bindings
The link to Design-Wiki needs updating, it uses your personal GitHub
account and 404s
On Oct 2, 7:44 pm, David Nolen dnolen.li...@gmail.com wrote:
The big picture is falling into place for core.match. The most significant
change is that we now have two compilation schemes based on the presence
Thanks for the report. The design wiki link is now removed.
On Sun, Oct 2, 2011 at 4:35 PM, Alasdair MacLeod alasdair.clj@gmail.com
wrote:
The link to Design-Wiki needs updating, it uses your personal GitHub
account and 404s
On Oct 2, 7:44 pm, David Nolen dnolen.li...@gmail.com wrote:
Not currently. That and a number of other features are in the queue.
Justin
On Sunday, October 2, 2011 12:45:44 AM UTC-4, Daniel wrote:
Say I want to get a full list of _current_ dependents for clojure-1.2
or contrib, for upgrade purposes ... is there currently a way to do
that on
Playing with it I've come up with this code which Clojure barfs on:
(defn- n-gensyms [n]
(take n (repeatedly gensym)))
(defmacro defmatch [name patterns]
(let [bindings# ~(n-gensyms (count (first (patterns]
`(defn ~name bindings#
(match bindings#)
~@patterns)))
Here's what the patch looks like for openjdk-6 with the latest master,
where the mozilla-specific lines have moved to the rhino.js file:
diff --git a/src/clj/cljs/repl/rhino.clj b/src/clj/cljs/repl/rhino.clj
index cbe4f2a..15c5bf1 100644
--- a/src/clj/cljs/repl/rhino.clj
+++
Look at the rhino-eval branch of ClojureScript.
David
On Sun, Oct 2, 2011 at 1:59 PM, db donald.bl...@gmail.com wrote:
The changes I posted previously solved the problem for me on open-jdk
6 on ubuntu. All I had to do was fix the package name and add the
optimization level and everything
A very basic version that works:
(defmacro defmatch [name patterns]
(let [bindings (take (count (first patterns))
(repeatedly #(gensym ocr-)))]
`(defn ~name [~@bindings]
(match [~@bindings]
~@patterns
A bit more work is required to
On 10/02/2011 05:20 PM, Stuart Halloway wrote:
I was referring to the aggregate contrib, not a curated
subset (which I agree is a good idea). Maybe we should call the
aggregated thing the Libraries Formerly Known as Contrib
(LFKAC).
38 matches
Mail list logo
