.class files constantly going stale?

[Andrew Cholakian]

I've noticed that when writing clojure code I constantly need to 'rm -rf classes' in my project, otherwise anything related to (defrecord) or (defprotocol) doesn't update. I've tried this on OSX Lion running both JDK 1.6 and 1.7.

This isn't too hard to deal with in lein as I just run rm -rf classes && lein run, but it makes slime/swank nearly unusable.

Any ideas?

[Timothy Washington]

I'm noticing a similar problem in my environment. I have (a linux ubuntu server): 

$ uname -a

Linux ubuntu 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010 i686 GNU/Linux

$ lein version

Leiningen 1.6.2 on Java 1.6.0_21 Java HotSpot(TM) Client VM

It's not a huge problem. But I do find myself doing "rm -rf classes/" during my development cycles.

Tim Washington 

Interruptsoftware.ca 

416.843.9060 

--
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

[David Nolen]

I've never have this problem. I'm assuming you're using AOT?

David

On Sat, Feb 11, 2012 at 11:34 AM, Andrew Cholakian <andr...@gmail.com> wrote:

--

[Jay Fields]

I think this issue is related to using

defrecord

or

defrecord & defprotocol

or

defrecord, defprotocol, & extend-protocol

I've never bothered to look into the simplest case at which it fails. I have a namespace that has my defrecord, and another namespace that defines the protocol and uses extend-protocol to add behavior for my record type. If I recompile the namespace with the protocol everything is fine, if I recompile the namespace with the defrecord the protocol stops finding the implementation for the protocol. The solution is "rm -rf classes"

As a work around I rm & restart my app if I ever change my record - which is very rarely.

Cheers, Jay

[Stuart Halloway]

I think this issue is related to using

defrecord

or

defrecord & defprotocol

or

defrecord, defprotocol, & extend-protocol

I've never bothered to look into the simplest case at which it fails. I have a namespace that has my defrecord, and another namespace that defines the protocol and uses extend-protocol to add behavior for my record type. If I recompile the namespace with the protocol everything is fine, if I recompile the namespace with the defrecord the protocol stops finding the implementation for the protocol. The solution is "rm -rf classes"

As a work around I rm & restart my app if I ever change my record - which is very rarely.

A better solution is not to compile defrecords during development. If this is the default behavior of some tools, it is anti-incremental-dev and wrong IMO.

Stu

Stuart Halloway
Clojure/core
http://clojure.com

[Jay Fields]

again, I haven't felt much pain, so I'm not sure what I'm saying is entirely true, but...

In the scenario I describe I have to :import the class created by defrecord to reference it as part of extend-protocol

For example

in foo/recs.clj

(ns foo.recs)

(defrecord ARecord [a b])

in foo/prots.clj

(ns foo.prots

  (:import [foo.recs ARecord]))

(defprotocol AProto

  (handle [o]))

(extend-protocol AProto

  ARecord

  (handle [o]

    ;; do stuff

  ))

In that case, don't  you need to record to become a class, so you can reference it in foo.prots :import?

I'd really love to be wrong, so I get rid of this occasional issue. =)

Cheers, Jay

[Chas Emerick]

No; just add a (:require foo.recs) to the ns form of foo.prots, so the defrecord form(s) can be loaded; this will generate the classes at runtime, and avoid any ahead-of-time compilation.

In general, AOT is rarely necessary, and almost always a hinderance.

- Chas

[Jay Fields]

interesting, the trick is to use foo.recs.ARecord...

(extend-protocol AProto
  foo.recs.ARecord

  (handle [o]
    ;; do stuff
))

Thanks for that.

[Chas Emerick]

The :import will work as well, as long as the :require comes first.

- Chas