--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To post to this group, send email to cloju...@googlegroups.com.
To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
At work, the biggest drivers of the Clojure versions we use are the
libraries we need. This is somewhat painful because some (congomongo)
are incompatible with 1.3 while others (lazytest) depend on 1.3. So
we're deep into 1.3 now, and phasing out our dependence on libs that
are incompatible.
Thus, 1.2.1 isn't interesting to me, personally.
--Chouser
PS. Note how none of this has anything to do with language bugs or 2.0
vs. 1.3 naming. :-)
I think adapting to changes in contrib is going to be a bigger job for
some projects to make rather than the changes to Clojure itself. Also
while the dynamicity changes will not affect any of our production
code, there are many, many places in our test suite where binding is
used in a way that would not be kosher in "real life" and will break
in 1.3. Even if we have to spend our own manpower pushing 1.2.1
through it would be less work than upgrading right now.
Also some people are also going to be wary of upgrading to _any_
pre-release version, which in some contexts may be reasonable.
-Phil
Doesn't with-redefs solve this?
Stu
Hmmm... It probably would in most cases, but it also makes
parallelization of tests a trickier problem.
-Phil
We looked into upgrading a while ago and I recall having a number of
issues, but it looks like those have been resolved.
-Phil
I presume this still includes cases of wanting to change the meaning
of things for code other than your own?
If not, it begs the question of debug builds, where a debug build
would have relaxed rebinding semantics. Of course, if you wanted to
change the meaning of things for others, you'd need a debug build from
them as well.
Another idea I had recently was to tie this to a mechanism similar to
that used by Java's assert. Then you would have a runtime flag, which
would have to be set prior to code being loaded, that could set the
different var behavior, with no overhead when not used
(theoretically). This would not require different builds.
Rich
I presume this still includes cases of wanting to change the meaning of things for code other than your own?
If not, it begs the question of debug builds, where a debug build would have relaxed rebinding semantics. Of course, if you wanted to change the meaning of things for others, you'd need a debug build from them as well.
Another idea I had recently was to tie this to a mechanism similar to that used by Java's assert. Then you would have a runtime flag, which would have to be set prior to code being loaded, that could set the different var behavior, with no overhead when not used (theoretically). This would not require different builds.
Rich
For the purposes of testing, it seems like Phil and many others are
looking to change the behavior of their app quite substantially.
That's the purpose of the flag. No one will be forced to use it.
It's on topic for 1.2.1 if having such a mechanism lets people move
forward instead.
Rich
For the purposes of testing, it seems like Phil and many others are looking to change the behavior of their app quite substantially. That's the purpose of the flag. No one will be forced to use it.
It's on topic for 1.2.1 if having such a mechanism lets people move forward instead.
Rich
Yeah, I think having a flag like that turned on for test-only
increases the distance between the behaviour of the code during test
vs production. Of course, "how do I know my tests are accurately
reflecting production" is a question that can never be satisfactorily
answered (Out of the Tarpit &c), but I'd like to avoid solutions that
could increase this in ways that may be hard to verify.
Anyhow, avoiding with-redefs in the test suite is mostly about being
able to parallelize them, but if we bite the bullet and replace all
our bindings with with-redefs, there are still pretty substantial
failures, the causes of which aren't immediately apparent. We'll want
to investigate these at some point down the line, but given the fact
that the fixes we need to Clojure 1.2 are well-understood and obvious,
that's what I'd prefer at this point.
-Phil
> On Thu, Mar 10, 2011 at 11:32 AM, Paul Stadig <pa...@stadig.name>
> wrote:
>> The tougher problem (and barrier to moving forward) seems to be to
>> be a
>> dependency that expects to dynamically bind a var at runtime, in
>> production,
>> without this flag turned on. I can't change that code, and the
>> behavior of
>> vars has changed from 1.2 to 1.3. Certainly I could run with the
>> flag turned
>> on in production. It's a kind of 1.2 "compatibility" mode. Perhaps
>> that's
>> what you're suggesting.
>
> Yeah, I think having a flag like that turned on for test-only
> increases the distance between the behaviour of the code during test
> vs production.
What are you using binding for during testing in the first place then?
Rich
Right--I meant that we use binding right now for very focused
behaviour differences that we are explicitly opting-in to, whereas
dynamic-in-test-only seems to have a wider scope. Perhaps it could be
shown to not have a big impact on test correctness; that was just my
initial reaction.
The failures in my initial attempts to run our tests against 1.3 are
not clearly due to dynamic binding changes, so I'm not sure whether
this relaxed-rebinding flag would address our needs specifically, but
it may be worth pursuing regardless.
-Phil
I would like to cut another 1.3 alpha today, and Aaron is working on creating some new top level repos for common contribs.
If there was a short list of issues keeping you off 1.3 I would much rather fix those than start the precedent of branching the past. If, after enumerating and discussing those issues, you still need a 1.2.1 I am willing to make it.
Stu
Another option is just to create your own 1.2.1 release, release it to clojars and start using it. That's what we had to do for the Keyword intern bug, as Clojure was unusable for us without that fix.Justin
Agreed. We would definitely upgrade to the official 1.2.1 if there was one.Justin
Sonian tests and Leiningen tests all check out with this patch, so I
award it two thumbs up.
Thanks a bunch!
-Phil
Thanks. I just added a new patch including a fix Rich wanted in, if anybody else is testing make sure your grab the later patch.
Stu
All clear on 1.2.1 take 2 as well.
On a related note, the 1.2.0 zip file release had a script/ directory
that contained a number of shell scripts that didn't really work very
well and appear to have been included by accident. We should ensure
that those don't get included in 1.2.1's zip.
-Phil
On a related note, the 1.2.0 zip file release had a script/ directory
that contained a number of shell scripts that didn't really work very
well and appear to have been included by accident. We should ensure
that those don't get included in 1.2.1's zip.
Note that these artifacts must be pushed by hand, using a crufty old process that is no longer in play on the master branch. If the process seems dumb that's because it is. :-)
Stu
One of the programs that used to run just fine on 1.2 with a particular max heap size now exhausts the heap space, not all of the time, but a noticeable fraction of the time. I'll look into that one a little bit more, but I suspect the max heap size I'm giving it might be right on the edge for 1.2, and is a bit too small for 1.2.1.
Andy
Andy
Stu
I see this happening when I have a ns with a "-" in it, I create a
record in that ns, then later in that same ns check the type of a
record with class. Before those class names had -'s in them (which
looks righter from a Clojure perspective) but now they will have _'s.
This makes sense from the perspective of the patch above but is
unfortunate from needing to understand the clojure/java behavior when
referring to record types.
A variant of this same issue is in the patch for CLJ-432 in the change
to test/clojure/test_clojure/protocols.clj (that test was presumably
broken in this same way for protocol names).
Example:
(ns my.rec-test
(:use [clojure.test]))
(defrecord Foo [a])
(deftest test-rec
;; 1.2.0 should use my.rec-test.Foo
;; 1.2.1 should use my.rec_test.Foo
(is (= my.rec-test.Foo (class (Foo. 1)))))
I'm not necessarily requesting anything be done here. We can make the
necessary changes in our code to move to 1.2.1 but I will note that
none of our projects actually compiled after going to 1.2.1 which was
initially alarming so take from that what you will.
Alex
Are we still evaluating this? I am thinking of doing a Leiningen 1.5.0
release soon that would default to new projects using 1.2.1, but I
will hold off if the problem Alex mentioned needs further
investigation.
-Phil
Will clojure-contrib rev to 1.2.1 for consistency with the official
release of clojure 1.2.1? Or will users just have to get used to
seeing different versions for these dependencies in their project.clj
file? :)
:dependencies [[org.clojure/clojure "1.2.1"]
[org.clojure/clojure-contrib "1.2.0"]
Sorry if I seem to keep on about contrib version numbering but keeping
track of which is the right contrib version to use with any given
clojure version can be a bit frustrating. I switched one of our
projects up to 1.3.0-alpha6 after I saw the mention of that but then
had to futz around to establish that contrib/sql was only at
1.3.0-alpha4 :)
I understand that this prior 1:1 correspondence will be completely
broken, at least for a while, with the new contrib libraries
(tools.logging at 0.1.1 yes? not yet available via maven repos?) but
is the plan to unify the version numbers again - including new contrib
- or to reset expectations completely? If the latter, how will users
easily keep track of the corresponding / correct / latest versions of
contrib pieces?
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
Railo Technologies, Inc. -- http://getrailo.com/
World Singles, LLC. -- http://worldsingles.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Good to know. Thanx.
> New contrib libraries will be released to oss.sonatype.org and sync'ed to
> Maven Central. Logging, JSON, nREPL, JMX, and finger-tree have all been
> released: http://repo2.maven.org/maven2/org/clojure/
OK. I wasn't sure where to look for the authoritative release versions.
For my own sanity, I created a page on my site that scans that repo
and shows the latest and earlier versions of the various Clojure
libraries:
http://corfield.org/clj/index.cfm
It caches the results for an hour - I figured that was "recent
enough". Is it worth adding all the Clojure contrib modules too? Or
does no one else find this hard to keep track of? :)
> "Old" clojure-contrib, the monolithic one, is deprecated as of now. No new
> development is happening there -- the first step in continuing development
> of any clojure-contrib library is to make it a "new" contrib.
So, for a while, at least, Clojure 1.3.0 programs might be a mix of
"old" contrib/foo 1.3.0 and "new" contrib pieces at different
versions? I guess I can phrase that question another way: I'm
currently using Clojure 1.3.0-alpha6 and contrib/sql 1.3.0-alpha4 -
when Clojure 1.3.0 goes final, where should I expect to find what is
currently contrib/sql 1.3.0-*? Will it become/stay clojure.contrib/sql
"1.3.0" or clojure.core.sql "1.3.0" or...?
I guess I just don't have a handle on plans for the current contrib
pieces and I haven't seen a roadmap for them (or I missed the
discussion / documentation of that).
>> New contrib libraries will be released to oss.sonatype.org and sync'ed to
>> Maven Central. Logging, JSON, nREPL, JMX, and finger-tree have all been
>> released: http://repo2.maven.org/maven2/org/clojure/
>
> OK. I wasn't sure where to look for the authoritative release versions.
>
> For my own sanity, I created a page on my site that scans that repo
> and shows the latest and earlier versions of the various Clojure
> libraries:
>
> http://corfield.org/clj/index.cfm
Much better to just use the official maven central search engine:
http://mavencentral.sonatype.com/#search|ga|1|clojure
- Chas
This weekend, we just had another keyword intern kill some work on one of our nodes. Kind of a drag!
We still waiting on something to pull the trigger here? I say push the artifacts out!
Paul
So it sounds like the announcement is waiting on the push to central
rather than any changes that may be made to 1.2.1 itself? If so it
should be OK to make Leiningen use this version since it's going to be
getting it from build.clojure.org anyway, right?
-Phil
Yes. We aren't changing anything, barring unforeseen unpleasantness.
Stu
"Much better" depends on your needs. That lists things I don't want to
see and doesn't show old versions at a glance (which I do want to
see). Nor does it list the contrib modules. As I said, that page on my
site is mostly for my own sanity - if anyone else thinks it's useful,
great, otherwise it's no big deal :)
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/