Re: Clojure Book example that has unexpected effect in trunk version of Clojure

2009-06-01 Thread Alen Ribic
For compile errors, all I see is the Stack trace in a new buffer and then when I hit 0, I'm back in my slime-repl buffer as usual. On Mon, Jun 1, 2009 at 10:19 AM, Mark Engelberg wrote: > > What happens to compile errors once you make that change.  Do they end > up in the REPL too? > > > > --~-

Re: Clojure Book example that has unexpected effect in trunk version of Clojure

2009-06-01 Thread Mark Engelberg
What happens to compile errors once you make that change. Do they end up in the REPL too? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com

Re: Clojure Book example that has unexpected effect in trunk version of Clojure

2009-06-01 Thread Alen Ribic
Thanks Mark. I can confirm that the slime function slime-redirect-inferior-output fixed the problem. Now I see the expected output from the new thread within the same slime buffer. -Alen On Sun, May 31, 2009 at 9:28 PM, Stephen C. Gilardi wrote: > > On May 31, 2009, at 1:00 PM, Mark Engelberg

Re: Clojure Book example that has unexpected effect in trunk version of Clojure

2009-05-31 Thread Stephen C. Gilardi
On May 31, 2009, at 1:00 PM, Mark Engelberg wrote: I posted about this recently. In emacs/slime, printed output on other threads does not appear. I have not found a workaround, other than running such code in a standard REPL. The output is ending up in the *inferior-lisp* buffer. This mes

Re: Clojure Book example that has unexpected effect in trunk version of Clojure

2009-05-31 Thread Mark Engelberg
I posted about this recently. In emacs/slime, printed output on other threads does not appear. I have not found a workaround, other than running such code in a standard REPL. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google

Re: Clojure Book example that has unexpected effect in trunk version of Clojure

2009-05-31 Thread Alvaro Vilanova Vidal
I have the same error, but only with emacs slime repl (any clojure version). 2009/5/31 Alen Ribic > > I thought I had the latest from trunk, but I was on rev 1371. Did an > update to latest now, rev 1382. Ran the example again and it was fine > now. > > -Al > > On Sun, May 31, 2009 at 11:48 AM,

Re: Clojure Book example that has unexpected effect in trunk version of Clojure

2009-05-31 Thread Alen Ribic
I thought I had the latest from trunk, but I was on rev 1371. Did an update to latest now, rev 1382. Ran the example again and it was fine now. -Al On Sun, May 31, 2009 at 11:48 AM, Timothy Pratley wrote: > > Hi Alen, > > I just updated to revision 1382 and it worked fine: > Clojure 1.1.0-alpha

Re: Clojure Book example that has unexpected effect in trunk version of Clojure

2009-05-31 Thread Timothy Pratley
Hi Alen, I just updated to revision 1382 and it worked fine: Clojure 1.1.0-alpha-SNAPSHOT user=> (def foo 10) #'user/foo user=> (.start (Thread. (fn [] (println foo nil 10 It also worked on whatever I was using before that. Can you confirm you are experiencing this behaviour in 1382? On Ma

Clojure Book example that has unexpected effect in trunk version of Clojure

2009-05-31 Thread Alen Ribic
I am currently reading the Programming Clojure book and have come across an unexpected result for an example in section titled "Managing Per-thread state with Vars". Code snippet is as follows (with expected result): user> (def foo 10) #'user/foo user=> (.start (Thread. (fn [] (println foo