Re: Does emacs suppress output from thread ?
That is a very useful bit of information. Thanks! On Tue, May 18, 2010 at 6:01 AM, Moritz Ulrich wrote: > Slime supports redirecting the inferior-lisp-output to the repl: > > Add > > (add-hook 'slime-connected-hook 'slime-redirect-inferior-output) > > to your .emacs > > On Tue, May 18, 2010 at 4:39 AM, Dave Fayram wrote: >> It doesn't suppress output, it just doesn't propagate it to your repl >> buffer. Check for that output in your *inferior-lisp* buffer; it >> should be faithfully reproduced there. >> >> You might want to consider using an alternative means of logging in >> the future. Perhaps an agent that buffers lines. >> >> - dlf >> >> On Mon, May 17, 2010 at 6:26 PM, Preecha P wrote: >>> I tried to play around with thread with these lines of code. It should >>> print the value of variable but it doesn't.. >>> >>> In emacs. >>> user> (def x 5) >>> #'user/x >>> user> x >>> 5 >>> user> (import [java.lang Thread]) >>> java.lang.Thread >>> user> (.start (Thread. (fn [] (print x >>> nil >>> >>> >>> or with agent >>> user> (def foo (agent 0)) >>> #'user/foo >>> user> foo >>> # >>> user> (send foo (fn[num] (do (println num) (inc num >>> # >>> >>> I ran the exact same code in command-line and the thread could print >>> the output fine. >>> >>> Clojure 1.1.0-master-SNAPSHOT >>> user=> (def foo (agent 0)) >>> #'user/foo >>> user=> foo >>> # >>> user=> (send foo (fn[num] (do (println num) (inc num) ))) >>> 0 >>> # >>> >>> I installed everything from elpa, so I guess some of the component >>> might gone wrong. Any idea ? >>> >>> thanks. >>> >>> -- >>> 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 >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >> >> >> >> -- >> -- >> Dave Fayram >> dfay...@gmail.com >> >> -- >> 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 >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > 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 > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- -- Dave Fayram dfay...@gmail.com -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Actors not good for concurrency model
On Mon, May 17, 2010 at 11:20 PM, Peter Schuller wrote: >> Actors in Erlang DO have mutable state, you're just discouraged from >> using it. ;) No really, erl -man get and set. Sometimes you're forced >> to use this despite the best of intentions. > > I don't think anyone is trying to claim that it is impossible to > mutate shared in state in an erlang actor. I'm not sure many people here have any clue what they're talking about, especially when it comes to Erlang. I thought I'd make it clear. > The claim is rather that the intended fundamental model implemented by an > actor is not one of > shared mutable state. I'm not sure why a getValue/setValue is any different from an ='s sign. Instability and unpredictability still results. Be they actors or threads, neither really solves any sort of problem save perhaps atomic updates. This all seems quite far afield of the original claim of the article, which was primarily that Actors are not composable and thus inferior to more functional programming. Even if we lay aside the implicit assumption that composability is a benefit, we're still left with the absurdity of the statement. Monads, one of the more important and critical constructs for purely functional programming, are not composable. The whole thing is absurd, and associating it with anything clojure-esque only lets that absurdity rub off. > > -- > / Peter Schuller > > -- > 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 > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- -- Dave Fayram dfay...@gmail.com -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Does emacs suppress output from thread ?
It doesn't suppress output, it just doesn't propagate it to your repl buffer. Check for that output in your *inferior-lisp* buffer; it should be faithfully reproduced there. You might want to consider using an alternative means of logging in the future. Perhaps an agent that buffers lines. - dlf On Mon, May 17, 2010 at 6:26 PM, Preecha P wrote: > I tried to play around with thread with these lines of code. It should > print the value of variable but it doesn't.. > > In emacs. > user> (def x 5) > #'user/x > user> x > 5 > user> (import [java.lang Thread]) > java.lang.Thread > user> (.start (Thread. (fn [] (print x > nil > > > or with agent > user> (def foo (agent 0)) > #'user/foo > user> foo > # > user> (send foo (fn[num] (do (println num) (inc num > # > > I ran the exact same code in command-line and the thread could print > the output fine. > > Clojure 1.1.0-master-SNAPSHOT > user=> (def foo (agent 0)) > #'user/foo > user=> foo > # > user=> (send foo (fn[num] (do (println num) (inc num) ))) > 0 > # > > I installed everything from elpa, so I guess some of the component > might gone wrong. Any idea ? > > thanks. > > -- > 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 > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- -- Dave Fayram dfay...@gmail.com -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Actors not good for concurrency model
Actors in Erlang DO have mutable state, you're just discouraged from using it. ;) No really, erl -man get and set. Sometimes you're forced to use this despite the best of intentions. But I really have to ask, how composable were monads again? - dlf On Mon, May 17, 2010 at 3:04 AM, Peter Schuller wrote: >> far as i know..actors share a mutable queue.. so there's good possibility >> for dead-locks > > Actors as they work in erlang don't have mutable state (not > intrinsically anyway, though of course you can implement an actor that > does poke on shared data since it's your code). The 'state' in an > erlang actor is that of parameter(s) to an infinitely tail-recursive > function. > > Deadlock in a message passing system is still possible if you limit > the mailbox size (unless some other means are used to prevent it). My > understanding is that mailbox size is not limited in erlang, and that > there is no other means to avoid deadlock, meaning that while you will > not deadlock in the message passing system you can cause memory > exhaustion. > > Disclaimer: While I've played with erlang I'm not really that into it, > please correct me someone if I've misrepresented anything. > > -- > / Peter Schuller > > -- > 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 > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- -- Dave Fayram dfay...@gmail.com -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: convert this to loop/recur?
Note that your recur call is wrapped in a cons. It is *not* in the tail position. (def date-seq (fn [d1 d2] (loop [b (-> d1 (.dayOfMonth) (.withMinimumValue)) e d2] (cons b (if (time/before? b e) (recur (.plusMonths b 1) e)) ;; Inside cons, this call must return I am not on a machine with clojure at the moment, but offhand you probably want something shaped more like: (defn date-seq [d1 d2] (let [b (-> d1 (.dayOfMonth) (.withMinimumValue))]) (reverse (date-seq-helper b dend (list (defn- date-seq-helper [dbot dend dates] (let [ndates (cons dbot dates)] (if (time/before? dbot dend) (recur (.plusMonths dbot 1) dend ndates) ; Recurse from tail position ndates))) ; Or end the recursion Please note that the tail recursion is in a tail position for the helper call, meaning that there is no computation that must take place after the call to recur returns. - dlf On Mon, May 17, 2010 at 2:36 PM, Base wrote: > Hi All - > > I am trying convert a function to use loop/recur and am getting the > dreded > > "java.lang.UnsupportedOperationException: Can only recur from tail > position (repl-1:414)" error > > (at least dreded for newbies...) > > The function takes 2 joda dates and returns a sequence of dates > starting at the first of the month until it is past the second date. > This works using standard recursion but I wanted to use TCO. > > Any help is most appreciated (as usual...!) > > Thanks > > Base > > > (def date-seq > (fn [d1 d2] > (loop [b (-> d1 > (.dayOfMonth) > (.withMinimumValue)) > e d2] > (cons b (if (time/before? b e) > (recur (.plusMonths b 1) e)) > > -- > 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 > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- -- Dave Fayram dfay...@gmail.com -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
