An open call to the community: Let's prepare for 1.3

[Chris Granger]

Hey Folks,

With the release of 1.3 growing ever nearer, it's time that we as a community do everything we can to make the migration smooth. In general, this means relatively simple changes to the libs under your control, but I also think we should take this opportunity to do some house cleaning.

If you maintain a clojure library (even if "library" just means some random thing up on github that a few people use), please consider doing the following over the next few weeks:

• Try migrating your lib to 1.3
• Create a 1.3 branch
• Remove earmuffs around any non-rebound vars
• Add earmuffs to any vars that are rebound using thread-level binding
• Add ^:dynamic to these vars
• If you rely on the built in Numerics, check to see if the new changes in 1.3 affect you.
• Do some house cleaning
• If you are no longer maintaining this library, simply note so at the top of your Readme. If the reason is that a better alternative has spring up, link to it.
• Take a look at your dev dependencies and determine if any of them should remain in light of the ability to globally install leiningen plugins. If you have swank-clojure as a dependency, please remove it: this has been the source of numerous issues.

None of these are complicated or particularly time consuming, and the impact they will have as people try to migrate forward will be tremendous. Also, don't fall into the trap of thinking "no one could possibly be using this tiny project" - I bet they are and bet they'll want to continue to :)

If I've missed some steps, please reply with them. Are there more house cleaning things we should do? Have you run into any other issues migrating to 1.3 (the steps listed here were purely what was necessary for me and the few others I've talked to)?

Cheers,
Chris.

[Alan Malloy]

I prefer to use ^{:dynamic true} instead of ^:dynamic, unless you're
recommending intentionally breaking compatibility with 1.2 so as to
encourage people to move to 1.3.

On Sep 3, 12:27 pm, Chris Granger <ibdk...@gmail.com> wrote:
> Hey Folks,
>
> With the release of 1.3 growing ever nearer, it's time that we as a
> community do everything we can to make the migration smooth. In general,
> this means relatively simple changes to the libs under your control, but I
> also think we should take this opportunity to do some house cleaning.
>
> If you maintain a clojure library (even if "library" just means some random
> thing up on github that a few people use), please consider doing the
> following over the next few weeks:
>

>    - *Try migrating your lib to 1.3*
>       - Create a 1.3 branch
>       - Remove earmuffs around any non-rebound vars
>       - Add earmuffs to any vars that are rebound using thread-level binding
>       - Add ^:dynamic to these vars
>       - If you rely on the built in Numerics, check to see if the new
>       changes<http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics>in
> 1.3 affect you.
>    - *Do some house cleaning*
>       - If you are no longer maintaining this library, simply note so at the

>       top of your Readme. If the reason is that a better alternative has spring
>       up, link to it.

>       - Take a look at your dev dependencies and determine if any of them

>       should remain in light of the ability to globally install
> leiningen plugins.

>       *If you have swank-clojure as a dependency, please remove it*: this

[Mark Rathwell]

> I prefer to use ^{:dynamic true} instead of ^:dynamic, unless you're
> recommending intentionally breaking compatibility with 1.2 so as to
> encourage people to move to 1.3.

What is meant by "breaking compatibility"? I haven't noticed any
issues using ^:dynamic with 1.2, am I missing something?

Thanks.

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

[Brian Goslinga]

On Sep 3, 3:13 pm, Alan Malloy <a...@malloys.org> wrote:
> I prefer to use ^{:dynamic true} instead of ^:dynamic, unless you're
> recommending intentionally breaking compatibility with 1.2 so as to
> encourage people to move to 1.3.

Presumably you would be doing this on a 1.3 branch of your code.

[Alan Malloy]

On Sep 3, 1:36 pm, Mark Rathwell <mark.rathw...@gmail.com> wrote:
> > I prefer to use ^{:dynamic true} instead of ^:dynamic, unless you're
> > recommending intentionally breaking compatibility with 1.2 so as to
> > encourage people to move to 1.3.
>

> What is meant by "breaking compatibility"?  I haven't noticed any
> issues using ^:dynamic with 1.2, am I missing something?

Huh, interesting. I assumed ^:foo meta syntax was new to 1.3, and
wouldn't compile at all in 1.2. But now I see that in 1.2 it's
equivalent to ^{:tag :foo} - not useful, but not damaging either. I
guess I'll start using ^:dynamic myself.

[Lee Hinman]

I recommend the lein-multi plugin for testing against multiple
versions of Clojure: https://github.com/maravillas/lein-multi

Makes it easy to make sure you continue to support both 1.2 and 1.3
for a while.

On Sep 3, 1:27 pm, Chris Granger <ibdk...@gmail.com> wrote:
> Hey Folks,
>
> With the release of 1.3 growing ever nearer, it's time that we as a
> community do everything we can to make the migration smooth. In general,
> this means relatively simple changes to the libs under your control, but I
> also think we should take this opportunity to do some house cleaning.
>
> If you maintain a clojure library (even if "library" just means some random
> thing up on github that a few people use), please consider doing the
> following over the next few weeks:
>

>    - *Try migrating your lib to 1.3*
>       - Create a 1.3 branch

>       - Remove earmuffs around any non-rebound vars
>       - Add earmuffs to any vars that are rebound using thread-level binding
>       - Add ^:dynamic to these vars
>       - If you rely on the built in Numerics, check to see if the new

>       changes<http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics>in
> 1.3 affect you.
>    - *Do some house cleaning*

>       - If you are no longer maintaining this library, simply note so at the

>       top of your Readme. If the reason is that a better alternative has spring
>       up, link to it.

>       - Take a look at your dev dependencies and determine if any of them

>       should remain in light of the ability to globally install
> leiningen plugins.

>       *If you have swank-clojure as a dependency, please remove it*: this

[Sean Corfield]

On Sat, Sep 3, 2011 at 3:43 PM, Lee Hinman <matthew...@gmail.com> wrote:
> I recommend the lein-multi plugin for testing against multiple
> versions of Clojure: https://github.com/maravillas/lein-multi
>
> Makes it easy to make sure you continue to support both 1.2 and 1.3
> for a while.

Good idea.

One thing that folks may not yet be aware of is that Clojure/core now
have matrix tests for all the new contrib libraries - across Clojure
1.2.0, 1.2.1 and 1.3.0-beta3 and various JVMs (Sun 1.5, Sun 1.6,
Oracle 1.7, IBM 5, OpenJDK 1.6).

http://build.clojure.org/

e.g., http://build.clojure.org/job/java.jdbc-test-matrix/ (these were
all blue the previous time I looked so I think there's some "work in
progress" going on right now).
--
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/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Luc Prefontaine]

Being curious I checked references to contrib in our code base.
Anyone knows what will happen to clojure.contrib.def and clojure.contrib.trace ?

Luc P.

--
Luc P.

================
The rabid Muppet

[Sean Corfield]

On Sat, Sep 3, 2011 at 4:40 PM, Luc Prefontaine
<lprefo...@softaddicts.ca> wrote:
> Being curious I checked references to contrib in our code base.
> Anyone knows what will happen to clojure.contrib.def and clojure.contrib.trace ?

According to http://dev.clojure.org/display/design/Contrib+Library+Names
some of c.c.def went into clojure.core.incubator and c.c.trace has no
"future" home at present. Some namespaces will go away because what
was in them exists in another namespace (much as stuff moved from
c.c.string to clojure.string).

As an example, defnk (from c.c.def) has disappeared in the reorg
because map destructuring is built-in now.

[Luc Prefontaine]

Thanx

I crossed another list in a different page stating the new names and structures but did not find
this one. I'll keep the bookmark.

So the only thing left on my list is c.c.trace. Any ideas of the future plans ?
Need a volunteer ? Is there a bigger plan to regroup dev utilities ?

Luc

On Sat, 3 Sep 2011 17:29:14 -0700
Sean Corfield <seanco...@gmail.com> wrote:

> On Sat, Sep 3, 2011 at 4:40 PM, Luc Prefontaine
> <lprefo...@softaddicts.ca> wrote:
> > Being curious I checked references to contrib in our code base.
> > Anyone knows what will happen to clojure.contrib.def and
> > clojure.contrib.trace ?
>
> According to
> http://dev.clojure.org/display/design/Contrib+Library+Names some of
> c.c.def went into clojure.core.incubator and c.c.trace has no
> "future" home at present. Some namespaces will go away because what
> was in them exists in another namespace (much as stuff moved from
> c.c.string to clojure.string).
>
> As an example, defnk (from c.c.def) has disappeared in the reorg
> because map destructuring is built-in now.

--

[Sean Corfield]

On Sat, Sep 3, 2011 at 5:37 PM, Luc Prefontaine
<lprefo...@softaddicts.ca> wrote:
> So the only thing left on my list is c.c.trace. Any ideas of the future plans ?

Stuart Sierra may chip in since he seems to have been the author of that?

It does look useful.

[Phil Hagelberg]

On Sat, Sep 3, 2011 at 5:37 PM, Luc Prefontaine
<lprefo...@softaddicts.ca> wrote:
> So the only thing left on my list is c.c.trace. Any ideas of the future plans ?
> Need a volunteer ? Is there a bigger plan to regroup dev utilities ?

Personally I've found Slime's tracing to be a suitable replacement for
c.c.trace. It has the advantage that you don't need to modify the
source to add the tracing, though of course it only works in Emacs.
Just hit C-c C-t to toggle tracing for a given defn.

-Phil

[Luc Prefontaine]

Hi Phil,

We use Eclipse/CCW, not much choices here, we have a mixed language app and
as I age I have less memory space for different dev tools :)

I'll ask Stuart if he has any plans for this.

--

[Meikel Brandmeyer]

Hi,

Am 03.09.2011 um 23:12 schrieb Alan Malloy:

> Huh, interesting. I assumed ^:foo meta syntax was new to 1.3, and
> wouldn't compile at all in 1.2. But now I see that in 1.2 it's
> equivalent to ^{:tag :foo} - not useful, but not damaging either. I
> guess I'll start using ^:dynamic myself.

#^something was equivalent to #^{:tag something}. Back when we did types not with defrecord but with (with-meta {:foo :bar} {:tag ::my-type}) it actually was useful. With the advent of defrecord this need for this diminished. So, it at least was useful.

Sincerely
Meikel

[Alan Malloy]

Well, ^something still is equivalent to ^{:tag something}, which as I
understand it is useful for compiler typehinting. I just was unaware
that this worked for keywords as well as symbols, though when you
point out that tags were used for custom types this makes more sense.

[Sean Corfield]

On Sun, Sep 4, 2011 at 12:59 AM, Alan Malloy <al...@malloys.org> wrote:
> Well, ^something still is equivalent to ^{:tag something}, which as I
> understand it is useful for compiler typehinting.

It's probably also worth noting that metadata combines in 1.3.0:

(defn ^:foo ^:bar fubar [] )

In 1.2.1, this gives:

user=> (meta #'user/fubar)
{:ns #<Namespace user>, :name fubar, :file "NO_SOURCE_PATH", :line 7,
:arglists ([]), :tag :foo}

In 1.3.0, this gives:

user=> (meta #'user/fubar)
{:arglists ([]), :foo true, :bar true, :ns #<Namespace user>, :name
fubar, :line 1, :file "NO_SOURCE_PATH"}

[Stuart Sierra]

FYI, I spoke with Luc and told him I'm happy to have c.c.trace continue its life if he or someone else will volunteer to maintain it. It will need some changes to work with 1.3 because of how it uses `binding`, but that should be possible using `with-redefs`.

-S

[Herwig Hochleitner]

2011/9/3 Alan Malloy <al...@malloys.org>

Huh, interesting. I assumed ^:foo meta syntax was new to 1.3, and

wouldn't compile at all in 1.2. But now I see that in 1.2 it's
equivalent to ^{:tag :foo} - not useful, but not damaging either. I
guess I'll start using ^:dynamic myself.

Actually, it causes compiler errors, when the compiler tries to use the keyword as a typehint. Unfortunately, this occurs in a pseudo-randomly when compiling code that uses the "hinted" var and leads to really cryptic error messages.

> java.lang.RuntimeException: java.lang.IllegalArgumentException: Unable to resolve classname: :dynamic

[Meikel Brandmeyer (kotarak)]

Woops. And indeed I'm wrong. It was {:type ::my-type}, not {:tag ::my-type}. Nevermind.

So ^ now distinguishes between keywords and classes, which it didn't before.

Sorry for the noise.

[Mark Rathwell]

Sorry, trying to clarify, we're saying don't use ^:dynamic if you want
to be compatible with 1.2? Instead use the full form ^{:dynamic
true}?

Thanks.

[Laurent PETIT]

2011/9/5 Mark Rathwell <mark.r...@gmail.com>

Yes. More generally : not using ^:anything in your code is a necessary condition for your code to be compatible with 1.2 (maybe not sufficient, I do not remember all the potential incompatibilities)
 

Thanks.

[Luc Prefontaine]

My CA has been mailed yesterday, should be in by Friday.
I'll post my registration request to clojure-dev around that time.
I'll have a look at the issue this week.

Luc

--

[Stefan Kamphausen]

Hi Chris,

could you please elaborate a bit on the swank-clojure issue?  Alternatively just point me to the threads that I should have read more closely.

Thanks and kind regards,
Stefan

[Phil Hagelberg]

On Mon, Sep 5, 2011 at 1:26 PM, Stefan Kamphausen
<ska...@googlemail.com> wrote:
> could you please elaborate a bit on the swank-clojure issue?  Alternatively
> just point me to the threads that I should have read more closely.

Now that Leiningen has user-level plugins, there's no need to put
swank in project.clj since you don't want to force everyone who works
on your project to download it. Just install it once for your own
user. Basically :dev-dependencies should only contain things without
which the tests or other build steps will not function.

I'll try to make this more explicit in the documentation.

-Phil

[Anthony Grimes]

Cake's global project allows for dev deps to be set for all projects, so this applies to cake as well.