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 "r
On Sat, Oct 1, 2011 at 9:52 PM, Daniel 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...
--
Sean A Corfield -- (904)
On Sat, Oct 1, 2011 at 10:16 PM, Tal Liron 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 part of Clojure, i
Sorry, posted the wrong data describing the problem. Here it is.
https://gist.github.com/1257122
On Oct 2, 12:39 am, Daniel wrote:
> This might be an issue with my log4j properties file, Cake, or
> tools.logging, Here's my log4j.properties file:
> https://gist.github.com/1257086
>
> It should
This might be an issue with my log4j properties file, Cake, or
tools.logging, Here's my log4j.properties file: https://gist.github.com/1257086
It should back up the current log file into an old, dated version at
midnight, and use a new, undated log file. Instead it appears to halt
program execut
On 10/01/2011 11:49 PM, Sean Corfield wrote:
I'm curious, what parts of contrib are you relying on that haven't
found active maintainers? Perhaps we can figure out how to address
that, to reduce your pain?
It's not that they weren't maintained. Well, I actually don't
Resolved in the Cake forum. Apparently 'cake test' implies use of the
'test' context, so you can layer specific details onto it with
defcontext with no problems.
Excellent way, by the way, to test projects with different
datasources. I seem to recall somebody else having problems with this
issue
user=> (= 23.0 23)
false
user=> (= 23 23)
true
"compares numbers and collections in a type-independent manner"
This kind of breakage was probably to be expected with the numerics
changes in 1.3. I am also interested in this.
On Oct 1, 4:34 pm, Chris Perkins wrote:
> I am trying to upgrade so
On Sat, Oct 1, 2011 at 8:10 PM, Tal Liron wrote:
> I did realize pretty early on that the contribs were not all of prime
> quality, but what other choice did I have? Fall back to standard JVM API?
I'm curious, what parts of contrib are you relying on that haven't
found active maintainers? Perhaps
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 Clojuresphere?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to cloju
Let's talk about another context here, we have been in prod since Jan. 2009.
With a pre V1.0 version of Clojure and we used contrib in the state it was in
these early days.
Staying away from contrib in production was never a concern to us.
We just made the commitment to live with it and wait for
On Saturday, October 1, 2011 9:34:46 PM UTC-5, David Nolen wrote:
>
> To give some context:
>
I appreciate the context, David, and I agree that the change needed to
happen. It's likely my fault for not being enough in the loop to realize
what the 1.3 change would mean for me. I expected some b
On Sat, Oct 1, 2011 at 9:49 PM, Tal Liron wrote:
> On Saturday, October 1, 2011 8:25:21 PM UTC-5, Andy Fingerhut wrote:
>>
>> Tal, did you consider the possibility of staying with Clojure 1.2.1 and
>> its libraries? Or was that not under consideration for some reason?
>>
>
> It was a considerati
> Staying with 1.2 meant not only staying with the Clojure core, which worked
> fine, but also losing any progress on any of the contribs, which was frankly
> more important to me than core language changes. Perhaps part of the really
> big issue here is not Clojure per se, but the contribs. In
On Saturday, October 1, 2011 8:25:21 PM UTC-5, Andy Fingerhut wrote:
>
> Tal, did you consider the possibility of staying with Clojure 1.2.1 and its
> libraries? Or was that not under consideration for some reason?
>
It was a consideration, but the cons seemed to outweigh the pros.
Staying with
Tal, did you consider the possibility of staying with Clojure 1.2.1 and its
libraries? Or was that not under consideration for some reason?
Andy
On Sat, Oct 1, 2011 at 6:03 PM, Tal Liron wrote:
> On Tuesday, September 27, 2011 1:57:03 PM UTC-5, Arthur Edelstein wrote:
>>
>> So my request for C
On Tuesday, September 27, 2011 1:57:03 PM UTC-5, Arthur Edelstein wrote:
>
> So my request for Clojure's future development, is that backwards
> compatibility not be broken. This means that Clojure code needs a way
> of designating what Clojure version it is targeted for.
>
I'm with you, Arthur.
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-snapshot";
"local-
I am trying to upgrade some code to 1.3, and I'm not sure how to do the
equivalent of a 1.2-style equality comparison.
user> (= {:foo 23} {:foo 23.0})
false
This used to be true. I see that = is now documented to compare same-type
numbers only, but == can be used for 1.2-compatible comparisons
https://github.com/flatland/cake/wiki/Contexts
I can't get 'cake test @testing' to work. Here's a really simple
example
https://gist.github.com/1256509
cake repl @testing works just fine though
$ cake repl @testing
user=> cake/*project*
{:dependencies {clojure {:version "1.3.0"}, org.neo4j/n
There's a good chance ClojureScript will be using a newer version of Rhino -
which will address this problem. Should get rolled into master in the next
few days.Thanks for your patience!
David
On Sat, Oct 1, 2011 at 11:23 AM, Volker Schlecht
wrote:
> Has anyone succeeded in solving this issue fo
Has anyone succeeded in solving this issue for OpenJDK yet?
So far all solutions I've seen discussed boiled down to using Oracle's
JDK ...
On Aug 14, 6:44 pm, Tzach wrote:
> I have a similar problem, but I could not solve it like you did:
> running on Ubuntu 11.04,
> $JAVA_HOME set to /usr/lib/jv
Razvan Rotaru wrote:
> Is there a way to attach metadata to defrecord ?
Is this what you are looking for?
(defrecord MyRecord [a b])
(let [r (with-meta (MyRecord. 1 2) {:extra 100})]
(meta r))
;;-> {:extra 100}
-David
--
You received this message because you are subscribed to the Google
Gro
Hi,
Is there a way to attach metadata to defrecord ?
Razvan
--
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
f
On Fri, Sep 30, 2011 at 6:17 PM, Alex Miller wrote:
> Yes, we are working on getting them published. Rich Hickey's keynote
> is in the first batch and has already been edited, just waiting to be
> synced to slides and scheduled at InfoQ.
You know that you should have saved the best to last and ma
25 matches
Mail list logo
