On Wed, Mar 28, 2012 at 9:05 PM, Frank Siebenlist
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
--
You received this message because you are subscribed to the Google
Gro
leiningen v3.0 ? ;-)
On Mar 28, 2012, at 8:48 PM, Phil Hagelberg wrote:
> On Wed, Mar 28, 2012 at 8:30 PM, Frank Siebenlist
> 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
On Wed, Mar 28, 2012 at 8:30 PM, Frank Siebenlist
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
--
You received this message b
"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.
On Mar 28, 2012,
On Wed, Mar 28, 2012 at 8:03 PM, Frank Siebenlist
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 curr
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 d
>
> 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.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@go
Frank Siebenlist 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.
-Phi
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
On Wed, Mar 28, 2012 at 3:13 PM, Frank Siebenlist
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 rec
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 th
11 matches
Mail list logo
