That's a general problem with multiple threads printing to the same
stream, and not something that can be easily avoided.
-Stuart
On Jul 25, 12:48 pm, ronen wrote:
> Iv stumbled this also when using Threads, (http://
> javadevelopmentforthemasses.blogspot.com/2009/07/easiest-singleton-
> around
Iv stumbled this also when using Threads, (http://
javadevelopmentforthemasses.blogspot.com/2009/07/easiest-singleton-
around.html)
user=> (defn singleton-factory []
(println "creating object")
(+ 1 2))
user=> (use 'clojure.contrib.singleton)
nil
user=> (def t-singleton (per-thr
On Fri, Jul 17, 2009 at 11:31 AM, Stephen C. Gilardi wrote:
> It looks like somehow you're seeing a very old REPL or it's not the default
> REPL you get from launching Clojure via clojure.main.
>
I can confirm the described behavior for the enclojure REPL.
--~--~-~--~~~--
On Jul 17, 2009, at 9:05 AM, AlamedaMike wrote:
As I say, technically very trivial, but it violates the principal of
least surprise (for me). I bring it up only because of reasons of
broader acceptance by the business community. I know how some of them
think, and even trivial stuff like this wi
Sounds like a good application of the broken window principle to me.
On Fri, Jul 17, 2009 at 9:05 AM, AlamedaMike wrote:
>
> This is so trivial from a technical standpoint I'm embarrassed to
> mention it. The REPL is accepting more than one sexp on a line and
> then generating output for all of
This is so trivial from a technical standpoint I'm embarrassed to
mention it. The REPL is accepting more than one sexp on a line and
then generating output for all of them in an unusual fashion. In the
following, all text after the first line is generated by clojure
(except for the comment, of co
