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).
Here's
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 m
Look at the rhino-eval branch of ClojureScript.
David
On Sun, Oct 2, 2011 at 1:59 PM, db 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 worked fine. I haven'
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
+++ b/src/clj/cljs/repl/rh
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)))
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 Cloju
Thanks for the report. The design wiki link is now removed.
On Sun, Oct 2, 2011 at 4:35 PM, Alasdair MacLeod wrote:
> The link to Design-Wiki needs updating, it uses your personal GitHub
> account and 404s
>
> On Oct 2, 7:44 pm, David Nolen wrote:
> > The big picture is falling into place for c
The link to Design-Wiki needs updating, it uses your personal GitHub
account and 404s
On Oct 2, 7:44 pm, David Nolen 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 of
> recur. If recur
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
~@
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 thi
"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 wrote:
> Hey folks!
>
> I released Noir 1.2.0 today. Highlights include:
>
> * Clojure 1.3.0 support
> * Named
>> 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 "casu
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 stri
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: https://github.com/ibdknox/noir/blob/master/history.md
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
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
Erg, Make that 0.2.0-alpha3.
David
On Sun, Oct 2, 2011 at 5:05 PM, David Nolen 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 this message because
> 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 ty
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 clojur
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 contr
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 ke
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 wrote:
> Luc,
>
> I think you are mistaken.
>
> user=> (cl
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
Gr
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 "Cloj
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
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 conside
Dave Sann 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"
> "http://artifactory/artifactory/libs-snapsho
Phil's was a 3 hour workshop and was not recorded sorry.
On Oct 2, 4:01 am, Andreas Liljeqvist 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!
--
You recei
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:
"
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 o
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, there
> Stuart,
>
> The documentation is clear (to me) about comparing numbers directly - that
> part is fine. My question was about whether there is an equivalent of the new
> == comparison that works on containers with floating-point numbers inside.
>
> I had guessed that == would recursively compa
Stuart,
The documentation is clear (to me) about comparing numbers directly - that
part is fine. My question was about whether there is an equivalent of the
new == comparison that works on containers with floating-point numbers
inside.
I had guessed that == would recursively compare the conten
> 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" gr
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
On Sat, Oct 1, 2011 at 11:24 PM, Tal Liron 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 Core".
Given
36 matches
Mail list logo
