Forgetting (require…) => nasty bug

69 views
Skip to first unread message

Frank Siebenlist

unread,
Mar 28, 2012, 6:13:12 PM3/28/12
to Clojure, Frank Siebenlist
I've been bitten a couple of times now by the following scenario:

- Use fully qualified names in the code

- Forget to add (require…) for the associated namspace

- But one other file already require'ed the same namespace, and the compiler&runtime is happy - all works fine.

- Then you include that file in an other app…

- no other module require's that namespace before this clj-module

- boom, crash… confusion as all seem to have worked before… and now it doesn't…


Is there a way to capture those kind of bugs earlier?

Thanks, FrankS.

Phil Hagelberg

unread,
Mar 28, 2012, 6:15:37 PM3/28/12
to clo...@googlegroups.com
On Wed, Mar 28, 2012 at 3:13 PM, Frank Siebenlist
<frank.si...@gmail.com> wrote:
> I've been bitten a couple of times now by the following scenario:

Slamhound won't help you catch those issues as they arise, but it can
catch them after they've happened:

https://github.com/technomancy/slamhound/

In general though I recommend simply using :require :as for
everything; if your code won't compile without the :as alias in place
then you'll be safe.

-Phil

Frank Siebenlist

unread,
Mar 28, 2012, 6:29:35 PM3/28/12
to clo...@googlegroups.com, Frank Siebenlist

On Mar 28, 2012, at 3:15 PM, Phil Hagelberg wrote:

> ...


> In general though I recommend simply using :require :as for
> everything; if your code won't compile without the :as alias in place
> then you'll be safe.


I realize that's a pragmatic way to force compilation errors.

However, I thought of using FQNs as a best practice as it's always clear which entity you're refering to as it's… fully qualified.

Then only use require…:as if it becomes too tedious to write the full fqn, and only use "refer/use" if even that becomes too much of a pain.

Wouldn't it be better to have the compiler or (load-file) generate an error/warning, as it should be able to detect a missing require?

-FrankS.

Phil Hagelberg

unread,
Mar 28, 2012, 6:34:09 PM3/28/12
to clo...@googlegroups.com
Frank Siebenlist <frank.si...@gmail.com> writes:

> Wouldn't it be better to have the compiler or (load-file) generate an
> error/warning, as it should be able to detect a missing require?

It's been proposed in the past. I don't recall Rich's argument against
it, but I only use fully-qualified vars when debugging.

-Phil

Armando Blancas

unread,
Mar 28, 2012, 10:26:12 PM3/28/12
to clo...@googlegroups.com, Frank Siebenlist

Is there a way to capture those kind of bugs earlier?

For each namespace I get a fresh repl and (use) the one in turn, then try the whole program. 

Frank Siebenlist

unread,
Mar 28, 2012, 11:03:14 PM3/28/12
to Armando Blancas, Frank Siebenlist, clo...@googlegroups.com
Not sure if that would work for all cases…

For example, if you have a lein plugin that require's clojure.set, and you use any fqn in that ns without require'ing it in your file, then your fresh repl will not catch that (… if I understand your setup).

However, if you then run it outside of the dev-environment, i.e. without any plugins or with other plugins, you will feel the pain.

But even when your trick works for many cases, it would be preferable if the compiler would simply catch that bug for you if possible.

-FrankS.

Phil Hagelberg

unread,
Mar 28, 2012, 11:20:17 PM3/28/12
to clo...@googlegroups.com
On Wed, Mar 28, 2012 at 8:03 PM, Frank Siebenlist
<frank.si...@gmail.com> wrote:
> For example, if you have a lein plugin that require's clojure.set, and you use any fqn in that ns without require'ing it in your file, then your fresh repl will not catch that (… if I understand your setup).

The lein check task currently ensures that each namespace is
compilable, but it does all the namespaces in a single process. You
could add a "slow mode" to it that would ensure that each worked in
isolation.

-Phil

Frank Siebenlist

unread,
Mar 28, 2012, 11:30:39 PM3/28/12
to clo...@googlegroups.com, Frank Siebenlist
"slow mode"…

Is that a setup where you would bring-up a new jvm-instance for each file such that you can truly compile/test in isolation?

Or is it possible to create a sandbox in an existing jvm that would give you similar isolation? (which would be far less slow)

-FrankS.

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

Phil Hagelberg

unread,
Mar 28, 2012, 11:48:36 PM3/28/12
to clo...@googlegroups.com
On Wed, Mar 28, 2012 at 8:30 PM, Frank Siebenlist
<frank.si...@gmail.com> wrote:
> Or is it possible to create a sandbox in an existing jvm that would give you similar isolation? (which would be far less slow)

You could probably do this with isolated classloaders in most cases.

-Phil

Frank Siebenlist

unread,
Mar 29, 2012, 12:05:04 AM3/29/12
to clo...@googlegroups.com, Frank Siebenlist
leiningen v3.0 ? ;-)

Phil Hagelberg

unread,
Mar 29, 2012, 12:10:35 AM3/29/12
to clo...@googlegroups.com
On Wed, Mar 28, 2012 at 9:05 PM, Frank Siebenlist
<frank.si...@gmail.com> wrote:
> leiningen v3.0 ?  ;-)

2.0 isn't done yet; there's still a chance!

Seriously, if you'd like to add it I can give you details; maybe best
to find me on IRC.

-Phil

Reply all
Reply to author
Forward
0 new messages