Re: Actors not good for concurrency model

[Bill Allen]

On Sun, May 16, 2010 at 3:19 PM, Fabio Kaminski wrote:

> Sorry about using the list like twitter..
>
> but i thought this is a pretty good "article" about functional programming
> side effects, and why actors are not very good design decision..
>
> Actors not good for concurrency model :
>
> http://pchiusano.blogspot.com/2010/01/actors-are-not-good-concurrency-model.html
>
> just another prove that Rich thoughts are pretty concise ,
> and that all are pretty well materialized in clojure's framework.
>
> what convinced me to embrace clojure, is that it choose to make the right
> thing , instead of the popular one..
>
> as haskell community says wisely : "avoid success at all costs " :)
>
> There's no question in my mind that Rich's thoughts are pretty concise. But
then again, there's no question in my mind that Joe Armstrong's thoughts
aren't also pretty concise. There is no system that can fundamentally
guarantee against programming errors in the single core or multi core case.
Erlang has provided a number of constructs that mitigate against poor
multi-processor programming mistakes, but remember, that's mitigate, not
prevent. The article struck me as a long diatribe on a subject that the
author knows just enough about to believe he's an expert when he's really
just scratching at the surface.

Let me be clear. Actors are a proven model to build good, in fact, excellent
concurrent and high reliability systems. That statement doesn't take
anything away from the advances that clojure is bringing to the state of the
art. For us to believe that clojure is pointing the way to a better solution
doesn't require us to say that actors/Erlang sucks.

-- 
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: ANN: try clojure

[Rayne]

A new version is out, and can be checked out here: http://www.try-clojure.org/

This new version fixes some bugs with the old version. Thanks to some
clever work by Heinz, def has been allowed, so you can define
functions and such.

The other bug thing is that I have started on a tutorial. It's just a
few steps, and it's no where near complete, and it makes unrealistic
leaps in difficulty between steps, but the steps will be filled in
soon. This is just a first-cut kind of thing that I've written today,
just to get it out of the way. More serious work will be done
tomorrow.

Enjoy.

On May 17, 11:09 am, Rayne  wrote:
> Thanks for reporting that. I'll fix that in the next version. As soon
> as I finish at least a few pages of the tutorial, I'll have Heinz
> deploy it on his server.
>
> On May 17, 7:51 am, Daniel Werner 
> wrote:
>
>
>
>
>
> > Having a web-based zero-deployment-effort REPL is pretty nifty,
> > especially for newcomers. Thanks Rayne/Heinz/etc.!
>
> > Already found a small bug: HTML entities are apparently quoted twice
> > and appear in the output.
>
> >Clojure> "blah"
> > "blah"
> >Clojure> filter
> > #
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email tocloj...@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 
> > athttp://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 tocloj...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email 
> toclojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://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

Re: a default value for get-in?

[Meikel Brandmeyer]

Hi,

On Tue, May 18, 2010 at 11:11:48PM +0200, Heinz N. Gies wrote:

> Hmm this is slowish, you walk ks twice that way, i think the if-let
> way is better, performance wise. Not sure if it really matters but for
> really nested maps this might make a difference.

If we restrict key "sequences" to vectors we could use pop and peek.
However, I would expect key sequences to be sufficiently short for
that to be a non-issue in the wild.

And even if its slow: it is correct in all cases. I prefer slow,
working programs over fast, broken ones.

Sincerely
Meikel

-- 
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: a default value for get-in?

[Heinz N. Gies]

On May 18, 2010, at 23:08 , Meikel Brandmeyer wrote:

> Hi,
...
> It's always a good idea to use things we already have:
...
>   (get (get-in m (butlast ks)) (last ks) not-found)))

Hmm this is slowish, you walk ks twice that way, i think the if-let way is 
better, performance wise. Not sure if it really matters but for really nested 
maps this might make a difference.

-- 
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: a default value for get-in?

[Meikel Brandmeyer]

Hi,

On Tue, May 18, 2010 at 04:16:01PM -0400, Russell Christopher wrote:

> Although that would return the default for a key with a nil value. So you're
> probably right reduce would have to change.
> 
> On Tue, May 18, 2010 at 3:49 PM, Russell Christopher <
> russell.christop...@gmail.com> wrote:
> 
> > (defn get-in
> > ([m ks]
> >  (reduce get m ks))
> >   ([m ks not-found]
> >(if-let [res (get-in m ks)] res not-found)))
> >
> > Longer but still uses reduce

It's always a good idea to use things we already have:

(defn get-in
  ([m ks]
   (reduce get m ks))
  ([m ks not-found]
   (get (get-in m (butlast ks)) (last ks) not-found)))

Sincerely
Meikel

-- 
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: a default value for get-in?

[Russell Christopher]

Although that would return the default for a key with a nil value. So you're
probably right reduce would have to change.

On Tue, May 18, 2010 at 3:49 PM, Russell Christopher <
russell.christop...@gmail.com> wrote:

> (defn get-in
> ([m ks]
>  (reduce get m ks))
>   ([m ks not-found]
>(if-let [res (get-in m ks)] res not-found)))
>
> Longer but still uses reduce
>
>
>
> On Tue, May 18, 2010 at 12:20 PM, Stefan Kamphausen <
> ska2...@googlemail.com> wrote:
>
>> Hi,
>>
>> On May 17, 9:34 pm, braver  wrote:
>> > If get-in is to be consistent with get, it better allow to specify a
>> > default value:
>> >
>> > (get-in nested-structure [k1 k2 ... kN] :default something)
>> >
>> > -- would it make sense to add that to the standard get-in?
>>
>> while I certainly agree from the users point of view, as an
>> implementer, I'd hate to break the very nice implementation of get-
>> in.  One would have to change reduce first. ;-)
>>
>> Cheers,
>> stefan
>>
>> --
>> 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

Re: swank-clojure and GNU Emacs 23 - package.el install issues

[atreyu]

Hi folks
I had the same issue and i got round the problem desinstalling clojure-
mode and slime-repl from elpa before installing swank-clojure (which
installs the previous two again)

My env is a liitle bit strange. I have Vista with Clojure Box (with
its own installation of slime-swank-clojure) and Ubuntu with emacs via
apt-get sharing my .emacs.d with the technomancy's starter kit.

Well I've got the thing working but with two small errors:

1.- swank-clojure.el refers to symbol "ignore-protocol-version" in
swank/swank.clj in the init repl script but i have not seen any
reference to this symbol in the last version of swank. Commenting the
reference  has been fixed.

2.- Before launch repl emacs warning the version of swank (2010)
was different of slime version (nil) and asked me to continue. I found
this code:

(defvar slime-protocol-version nil)
(setq slime-protocol-version
  (eval-when-compile (slime-changelog-date)))

but in the launch of repl the value of slime-protocol-version was nil
Repeating

(require 'slime)
(setq slime-protocol-version
  (eval-when-compile (slime-changelog-date)))

in my user.el  i avoid the warning

I am a emacs newbie and i guess i am doing unnecesary and silly
workarounds. sure someone has a clever explication and solution

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

[alux]

If it doesnt fit, use a bigger hammer.

This one isn't perfect, but works even with a Maven-started swank.

; use with (System/setOut (sys-out-replacer))
(import (java.io PrintStream PipedInputStream PipedOutputStream))
(defn sys-out-replacer []
 (let [pin (PipedInputStream.)
   out (PrintStream. (PipedOutputStream. pin))
   current-out *out*
   pusher (fn [] (let [b (.read pin)]
   (binding [*out* current-out]
 (.write *out* b))
   (.flush out)
   (recur)))]
   (.start (Thread. pusher))
   out))

Feedback highly welcome.

Regards, alxu

On 18 Mai, 21:09, alux  wrote:
> Hi.
>
> (add-hook 'slime-connected-hook 'slime-redirect-inferior-output)
>
> works for me if I start Clojure with M-x slime
> But if I start it with Maven, and try to connect, it prevents the REPL
> from starting.
>
> Mini Buffer says:
> "error in process filter: No inferior lisp process"
>
> Hm.
>
> (I actually didnt expect this to work, but to prevent me from working
> isnt nice ;-)
>
> Greetings, alux
>
> On 18 Mai, 20:37, Dave Fayram  wrote:
>
>
>
> > 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 
> > athttp://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the G

Re: a default value for get-in?

[Russell Christopher]

(defn get-in
([m ks]
 (reduce get m ks))
  ([m ks not-found]
   (if-let [res (get-in m ks)] res not-found)))

Longer but still uses reduce


On Tue, May 18, 2010 at 12:20 PM, Stefan Kamphausen
wrote:

> Hi,
>
> On May 17, 9:34 pm, braver  wrote:
> > If get-in is to be consistent with get, it better allow to specify a
> > default value:
> >
> > (get-in nested-structure [k1 k2 ... kN] :default something)
> >
> > -- would it make sense to add that to the standard get-in?
>
> while I certainly agree from the users point of view, as an
> implementer, I'd hate to break the very nice implementation of get-
> in.  One would have to change reduce first. ;-)
>
> Cheers,
> stefan
>
> --
> 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

Re: Actors not good for concurrency model

[Peter Schuller]

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

My (unproven) gut feeling is that people are afraid of machine
concurrency, and the removal of machine-level concurrency issues (by
use of appropriate high-level abstractions) cause a belief, which is
in my estimation mistaken, that you are therefor rid of *all*
concurrency issues.

In any case, for the record, I did not mean to imply that i agreed,
overall, with the originally posted article.

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

Re: Does emacs suppress output from thread ?

[alux]

Hi.

(add-hook 'slime-connected-hook 'slime-redirect-inferior-output)

works for me if I start Clojure with M-x slime
But if I start it with Maven, and try to connect, it prevents the REPL
from starting.

Mini Buffer says:
"error in process filter: No inferior lisp process"

Hm.

(I actually didnt expect this to work, but to prevent me from working
isnt nice ;-)

Greetings, alux


On 18 Mai, 20:37, Dave Fayram  wrote:
> 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 
> athttp://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

Re: Does emacs suppress output from thread ?

[Dave Fayram]

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: Does emacs suppress output from thread ?

[Moritz Ulrich]

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

Re: Actors not good for concurrency model

[Dave Fayram]

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: swank-clojure and GNU Emacs 23 - package.el install issues

[Justin Kramer]

Er, to clarify: I believe I wiped out all elpa *packages* before using
the new package.el, not the elpa dir itself.

Good luck,

Justin

On May 18, 12:50 pm, Justin Kramer  wrote:
> I should note that I wiped out my elpa dir before using the new
> package.el. Also, there is this other package.el from Phil's emacs-
> starter-kit, which may or may not provide different results:
>
> http://github.com/technomancy/emacs-starter-kit/raw/master/package.el
>
> Justin
>
> On May 18, 11:05 am, Terrence Brannon  wrote:
>
>
>
>
>
> > On Tue, May 18, 2010 at 1:34 AM, Justin Kramer  wrote:
> > > Per Phil Hagelberg's suggestion on IRC, I downloaded and used his
> > > package.el, which fixed the issue for me:
>
> > >http://github.com/technomancy/package.el/raw/master/package.el
>
> > I copied that package.el over ~/emacs.d./elpa/package.el and now I get
> > ""Bad url: :clojure-mode-1.7.1.el"
>
> > Stack backtrace follows:
>
> > Debugger entered--Lisp error: (error "Bad url: :clojure-mode-1.7.1.el")
> >   signal(error ("Bad url: :clojure-mode-1.7.1.el"))
> >   error("Bad url: %s" ":clojure-mode-1.7.1.el")
> >   url-retrieve-internal("clojure-mode-1.7.1.el" (lambda (&rest
> > --cl-rest--) (apply #[... "\302\303\304p#\210 \305L\210    pL\207"
> > [G25101 G25100 url-debug retrieval "Synchronous fetching done (%S)" t]
> > 4] (quote --asynch-buffer--) (quote --retrieval-done--) --cl-rest--))
> > (nil))
> >   url-retrieve("clojure-mode-1.7.1.el" (lambda (&rest --cl-rest--)
> > (apply #[... "\302\303\304p#\210 \305L\210 pL\207" [G25101 G25100
> > url-debug retrieval "Synchronous fetching done (%S)" t] 4] (quote
> > --asynch-buffer--) (quote --retrieval-done--) --cl-rest--)))
> >   url-retrieve-synchronously("clojure-mode-1.7.1.el")
> >   (let ((buffer ...)) (save-excursion (set-buffer buffer)
> > (package-handle-response) (re-search-forward "^$" nil ...)
> > (forward-char) (delete-region ... ...) (package-unpack-single ...
> > version desc requires) (kill-buffer buffer)))
> >   package-download-single(clojure-mode "1.7.1" "Major mode for Clojure
> > code" nil)
> >   (cond ((eq kind ...) (package-download-tar elt v-string)) ((eq kind
> > ...) (package-download-single elt v-string ... ...)) (t (error
> > "Unknown package kind: " ...)))
> >   (let* ((desc ...) (v-string ...) (kind ...)) (cond (... ...) (...
> > ...) (t ...)))
> >   (lambda (elt) (let* (... ... ...) (cond ... ... ...)))(clojure-mode)
> >   mapc((lambda (elt) (let* (... ... ...) (cond ... ... ...))) 
> > (clojure-mode))
> >   package-download-transaction((clojure-mode))
> >   (let ((transaction ...)) (package-download-transaction transaction))
> >   (let ((pkg-desc ...)) (unless pkg-desc (error "Package '%s' not
> > available for installation" ...)) (let (...)
> > (package-download-transaction transaction)))
> >   package-install(clojure-mode)
> >   (cond ((eq cmd 68) (when ... ...) (message "Deleting %s-%s..."
> > pkg-name pkg-vers) (package-delete pkg-name pkg-vers) (message
> > "Deleting %s-%s... done" pkg-name pkg-vers)) ((eq cmd 73)
> > (package-install ...)))
> >   (let ((cmd ...) (pkg-name ...) (pkg-vers ...) (pkg-status ...))
> > (cond (... ... ... ... ...) (... ...)))
> >   (while (not (eobp)) (let (... ... ... ...) (cond ... ...)) (forward-line))
> >   package-menu-execute()
> >   call-interactively(package-menu-execute nil nil)
> >   recursive-edit()
> >   byte-code("\306 �...@\307=\203!
>
> > --
> > 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 
> > athttp://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 
> athttp://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

Re: swank-clojure and GNU Emacs 23 - package.el install issues

[Justin Kramer]

I should note that I wiped out my elpa dir before using the new
package.el. Also, there is this other package.el from Phil's emacs-
starter-kit, which may or may not provide different results:

http://github.com/technomancy/emacs-starter-kit/raw/master/package.el

Justin

On May 18, 11:05 am, Terrence Brannon  wrote:
> On Tue, May 18, 2010 at 1:34 AM, Justin Kramer  wrote:
> > Per Phil Hagelberg's suggestion on IRC, I downloaded and used his
> > package.el, which fixed the issue for me:
>
> >http://github.com/technomancy/package.el/raw/master/package.el
>
> I copied that package.el over ~/emacs.d./elpa/package.el and now I get
> ""Bad url: :clojure-mode-1.7.1.el"
>
> Stack backtrace follows:
>
> Debugger entered--Lisp error: (error "Bad url: :clojure-mode-1.7.1.el")
>   signal(error ("Bad url: :clojure-mode-1.7.1.el"))
>   error("Bad url: %s" ":clojure-mode-1.7.1.el")
>   url-retrieve-internal("clojure-mode-1.7.1.el" (lambda (&rest
> --cl-rest--) (apply #[... "\302\303\304p#\210 \305L\210    pL\207"
> [G25101 G25100 url-debug retrieval "Synchronous fetching done (%S)" t]
> 4] (quote --asynch-buffer--) (quote --retrieval-done--) --cl-rest--))
> (nil))
>   url-retrieve("clojure-mode-1.7.1.el" (lambda (&rest --cl-rest--)
> (apply #[... "\302\303\304p#\210 \305L\210 pL\207" [G25101 G25100
> url-debug retrieval "Synchronous fetching done (%S)" t] 4] (quote
> --asynch-buffer--) (quote --retrieval-done--) --cl-rest--)))
>   url-retrieve-synchronously("clojure-mode-1.7.1.el")
>   (let ((buffer ...)) (save-excursion (set-buffer buffer)
> (package-handle-response) (re-search-forward "^$" nil ...)
> (forward-char) (delete-region ... ...) (package-unpack-single ...
> version desc requires) (kill-buffer buffer)))
>   package-download-single(clojure-mode "1.7.1" "Major mode for Clojure
> code" nil)
>   (cond ((eq kind ...) (package-download-tar elt v-string)) ((eq kind
> ...) (package-download-single elt v-string ... ...)) (t (error
> "Unknown package kind: " ...)))
>   (let* ((desc ...) (v-string ...) (kind ...)) (cond (... ...) (...
> ...) (t ...)))
>   (lambda (elt) (let* (... ... ...) (cond ... ... ...)))(clojure-mode)
>   mapc((lambda (elt) (let* (... ... ...) (cond ... ... ...))) (clojure-mode))
>   package-download-transaction((clojure-mode))
>   (let ((transaction ...)) (package-download-transaction transaction))
>   (let ((pkg-desc ...)) (unless pkg-desc (error "Package '%s' not
> available for installation" ...)) (let (...)
> (package-download-transaction transaction)))
>   package-install(clojure-mode)
>   (cond ((eq cmd 68) (when ... ...) (message "Deleting %s-%s..."
> pkg-name pkg-vers) (package-delete pkg-name pkg-vers) (message
> "Deleting %s-%s... done" pkg-name pkg-vers)) ((eq cmd 73)
> (package-install ...)))
>   (let ((cmd ...) (pkg-name ...) (pkg-vers ...) (pkg-status ...))
> (cond (... ... ... ... ...) (... ...)))
>   (while (not (eobp)) (let (... ... ... ...) (cond ... ...)) (forward-line))
>   package-menu-execute()
>   call-interactively(package-menu-execute nil nil)
>   recursive-edit()
>   byte-code("\306 �...@\307=\203!
>
> --
> 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 
> athttp://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

Re: 18 build errors with clojure contrib

[James Reeves]

On 18 May 2010 16:31, Terrence Brannon  wrote:
> Per http://riddell.us/ClojureOnUbuntu.html
>
> I tried to build clojure contrib but there were 18 build errors.

I get the same issue, which is odd, because the continuous integration
server works.

Regardless, would I be correct in guessing that you are more
interested in using Clojure-Contrib than patching it? If so, there are
easier ways to get started with Clojure and Clojure-Contrib.

Perhaps the best place to start is Stuart's LabREPL project:
http://github.com/relevance/labrepl

That contains comprehensive instructions for getting started on
various different IDEs and OSs, and also provides an interactive way
for you to learn and experiment with Clojure.

- James

-- 
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: a default value for get-in?

[Stefan Kamphausen]

Hi,

On May 17, 9:34 pm, braver  wrote:
> If get-in is to be consistent with get, it better allow to specify a
> default value:
>
> (get-in nested-structure [k1 k2 ... kN] :default something)
>
> -- would it make sense to add that to the standard get-in?

while I certainly agree from the users point of view, as an
implementer, I'd hate to break the very nice implementation of get-
in.  One would have to change reduce first. ;-)

Cheers,
stefan

-- 
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: Assembla instructions for java -cp clojure.jar yield java.lang.NoClassDefFoundError: clojure/main

[Terrence Brannon]

My bad... ".jar" was left off the the first argument :)

On Tue, May 18, 2010 at 12:04 PM, Terrence Brannon  wrote:
> re: http://www.assembla.com/wiki/show/clojure/Getting_Started_with_Emacs
>
>
> """java -cp path/to/clojure.jar clojure.main"""
>
> this suggestion fails:
>
> metap...@locohost:~/prg/tmp$ java -cp /home/metaperl/.clojure/clojure
> clojure.main
> Exception in thread "main" java.lang.NoClassDefFoundError: clojure/main
> Caused by: java.lang.ClassNotFoundException: clojure.main
>        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>        at java.security.AccessController.doPrivileged(Native Method)
>        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> Could not find the main class: clojure.main.  Program will exit.
> metap...@locohost:~/prg/tmp$
>
> by the way, clojure.el does not have complete usage instructions in
> it, particularly the need to set the inferior-lisp-program correctly.
>
> I thought it was standard practice to include complete install instructions.
>

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

Assembla instructions for java -cp clojure.jar yield java.lang.NoClassDefFoundError: clojure/main

[Terrence Brannon]

re: http://www.assembla.com/wiki/show/clojure/Getting_Started_with_Emacs


"""java -cp path/to/clojure.jar clojure.main"""

this suggestion fails:

metap...@locohost:~/prg/tmp$ java -cp /home/metaperl/.clojure/clojure
clojure.main
Exception in thread "main" java.lang.NoClassDefFoundError: clojure/main
Caused by: java.lang.ClassNotFoundException: clojure.main
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: clojure.main.  Program will exit.
metap...@locohost:~/prg/tmp$

by the way, clojure.el does not have complete usage instructions in
it, particularly the need to set the inferior-lisp-program correctly.

I thought it was standard practice to include complete install instructions.

-- 
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: functional check slower than imperative?

[Christophe Grand]

Hi,

On Tue, May 18, 2010 at 4:59 PM, braver  wrote:

> On May 18, 10:47 am, "Heinz N. Gies"  wrote:
> > Out of curiosity, can you remove the pmap and run them in the opposite
> order? as first (time (reps-sorted1? dreps)) then (time (reps-sorted2?
> dreps))?
>
> user=> (time (reps-sorted1? dreps))
> "Elapsed time: 8254.967 msecs"
> true
> (defn reps-sorted2? [dreps]
>   (->> dreps (map (fn [[_ days]]  ; NB pmap 3x slower here!
> (let [s (map first days)]
>  (every? true? (map >= s (cons (first s) s))
>(every? true?)))
> #'user/reps-sorted2?
> user=> (time (reps-sorted2? dreps))
> "Elapsed time: 15635.756 msecs"
> true
>
> Still twice as slower...
>


As David said pmap introduces some overhead you need to compensate by
batching your work.

On why the higher-order-function style is slower: it's mainly caused by
allocation, you have to reduce the amount of intermediaries seqs.
eg (every? true? (map f coll)) introduces a intermediate seq (map f coll)
which is uncalled for. (every? f coll) doesn't and is thus faster. Try:

(defn reps-sorted2? [dreps]
 (every? (fn [[_ days]]
   (let [s (map first days)]
 (every? true? (map >= s (cons (first s) s
   dreps

It should not be as fast as the iterative version because of your other
every? true?. Sadly here one can't refactor this call as above because
(every? f coll1 coll2) is not supported.
What you can do though is to define a sorted-by helper function to work
around this limitation:

(defn sorted-by? [pred s]
  (if-let [ns (next s)]
(let [[a b] s]
  (and (pred a b) (recur pred ns)))
true))

(sorted-by? is indeed iterative but every? implementation is iterative too
so I don't think I'm cheating here)

Then you can rewrite reps-sorted2? to:
(defn reps-sorted2? [dreps]
 (every? #(sorted-by? >= (map first (val %))) dreps))

and it should be as fast as the iterative version.

However, according to your sample data you seem to be checking if the keys
of a hashmap are sorted...

hth,

Christophe



-- 
Brussels, 23-25/6 http://conj-labs.eu/
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.cgrand.net/ (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

Re: protocols and satisfies?

[Nicolas Oury]

Sorry for the noise.

protocols and datatypes are amazingly cool by the way.

On Tue, May 18, 2010 at 3:51 PM, Adrian Cuthbertson <
adrian.cuthbert...@gmail.com> wrote:

> > Actually, it seems to do what I thought.
>
> Right, indeed
>
> (satisfies? PStr ss)
> -> true
>
> --
> 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

Re: swank-clojure and GNU Emacs 23 - package.el install issues

[Terrence Brannon]

On Tue, May 18, 2010 at 1:34 AM, Justin Kramer  wrote:
> Per Phil Hagelberg's suggestion on IRC, I downloaded and used his
> package.el, which fixed the issue for me:
>
> http://github.com/technomancy/package.el/raw/master/package.el

I copied that package.el over ~/emacs.d./elpa/package.el and now I get
""Bad url: :clojure-mode-1.7.1.el"

Stack backtrace follows:

Debugger entered--Lisp error: (error "Bad url: :clojure-mode-1.7.1.el")
  signal(error ("Bad url: :clojure-mode-1.7.1.el"))
  error("Bad url: %s" ":clojure-mode-1.7.1.el")
  url-retrieve-internal("clojure-mode-1.7.1.el" (lambda (&rest
--cl-rest--) (apply #[... "\302\303\304p#\210 \305L\210 pL\207"
[G25101 G25100 url-debug retrieval "Synchronous fetching done (%S)" t]
4] (quote --asynch-buffer--) (quote --retrieval-done--) --cl-rest--))
(nil))
  url-retrieve("clojure-mode-1.7.1.el" (lambda (&rest --cl-rest--)
(apply #[... "\302\303\304p#\210 \305L\210  pL\207" [G25101 G25100
url-debug retrieval "Synchronous fetching done (%S)" t] 4] (quote
--asynch-buffer--) (quote --retrieval-done--) --cl-rest--)))
  url-retrieve-synchronously("clojure-mode-1.7.1.el")
  (let ((buffer ...)) (save-excursion (set-buffer buffer)
(package-handle-response) (re-search-forward "^$" nil ...)
(forward-char) (delete-region ... ...) (package-unpack-single ...
version desc requires) (kill-buffer buffer)))
  package-download-single(clojure-mode "1.7.1" "Major mode for Clojure
code" nil)
  (cond ((eq kind ...) (package-download-tar elt v-string)) ((eq kind
...) (package-download-single elt v-string ... ...)) (t (error
"Unknown package kind: " ...)))
  (let* ((desc ...) (v-string ...) (kind ...)) (cond (... ...) (...
...) (t ...)))
  (lambda (elt) (let* (... ... ...) (cond ... ... ...)))(clojure-mode)
  mapc((lambda (elt) (let* (... ... ...) (cond ... ... ...))) (clojure-mode))
  package-download-transaction((clojure-mode))
  (let ((transaction ...)) (package-download-transaction transaction))
  (let ((pkg-desc ...)) (unless pkg-desc (error "Package '%s' not
available for installation" ...)) (let (...)
(package-download-transaction transaction)))
  package-install(clojure-mode)
  (cond ((eq cmd 68) (when ... ...) (message "Deleting %s-%s..."
pkg-name pkg-vers) (package-delete pkg-name pkg-vers) (message
"Deleting %s-%s... done" pkg-name pkg-vers)) ((eq cmd 73)
(package-install ...)))
  (let ((cmd ...) (pkg-name ...) (pkg-vers ...) (pkg-status ...))
(cond (... ... ... ... ...) (... ...)))
  (while (not (eobp)) (let (... ... ... ...) (cond ... ...)) (forward-line))
  package-menu-execute()
  call-interactively(package-menu-execute nil nil)
  recursive-edit()
  byte-code("\306   @\307=\203!

-- 
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: functional check slower than imperative?

[Laurent PETIT]

2010/5/18 braver :
> On May 18, 10:27 am, David Nolen  wrote:
>> On Tue, May 18, 2010 at 10:18 AM, braver  wrote:
>> The documentation is pretty clear about how pmap works. Your work needs to
>> be greater than the coordination overhead. You probably need to batch your
>> work before trying to call pmap.
>
> David -- note that loop outperforms every? by 4x without pmap.  So
> forget pmap, we know it's overhead-y, why does every? lose?

Guesses :

In the iterative solution, loop is optimized for tail cal
In the higher order functions solution, you have a lot of embedded
calls to map function, and also call to every? function. Those
functions produce (and every? consumes) seq objects.

Please note that loop is as functional as the combination of every?
and map. It's just the "iterative" style versus hof style.

-- 
Laurent

-- 
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: functional check slower than imperative?

[braver]

On May 18, 10:47 am, "Heinz N. Gies"  wrote:
> Out of curiosity, can you remove the pmap and run them in the opposite order? 
> as first (time (reps-sorted1? dreps)) then (time (reps-sorted2? dreps))?

user=> (time (reps-sorted1? dreps))
"Elapsed time: 8254.967 msecs"
true
(defn reps-sorted2? [dreps]
  (->> dreps (map (fn [[_ days]]  ; NB pmap 3x slower here!
(let [s (map first days)]
  (every? true? (map >= s (cons (first s) s))
(every? true?)))
#'user/reps-sorted2?
user=> (time (reps-sorted2? dreps))
"Elapsed time: 15635.756 msecs"
true

Still twice as slower...
-- Alexy

-- 
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: protocols and satisfies?

[Adrian Cuthbertson]

> Actually, it seems to do what I thought.

Right, indeed

(satisfies? PStr ss)
-> true

-- 
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: protocols and satisfies?

[Meikel Brandmeyer]

Hi,

On May 18, 4:24 pm, Nicolas Oury  wrote:

> I tried satisfies? but it does not seem to do what I supposed it did.

What did you actually think it does?

user=> (defprotocol P (bar [x]))
P
user=> (satisfies? P (reify :as this P (bar [])))
true
user=> (satisfies? P 5)
nil

(Note: this was an older snapshot. Hence the obsolete reify syntax.)

Sincerely
Meikel

-- 
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: functional check slower than imperative?

[Heinz N. Gies]

On May 18, 2010, at 16:18 , braver wrote:

> user=> (time (reps-sorted2?
> dreps))
> "Elapsed time: 127606.905 msecs"
> true
> user=> (time (reps-sorted1? dreps))
> "Elapsed time: 8368.616 msecs"
> true
> 
> As you can see, the imperative solution vastly outperforms the
> functional one, even though the functional allows for pmap!  Without
> the pmap, it actually did faster, in 40 seconds.  Why is FP slower
> here?
> 
Out of curiosity, can you remove the pmap and run them in the opposite order? 
as first (time (reps-sorted1? dreps)) then (time (reps-sorted2? dreps))?

Regards,
Heinz

-- 
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: protocols and satisfies?

[Adrian Cuthbertson]

> What is the canonical way to know whether something satisfies (is satisfies
> the right terminology?) a protocol.

You're looking for extends? ...
(doc extends?)
-
clojure.core/extends?
([protocol atype])
  Returns true if atype extends protocol

(defprotocol PStr "String extra functions." (strcat [s1 s2]))
(defrecord Mys [mys] PStr (strcat [this s2] (str (get this :mys) s2)))

(def ss (Mys. "foo"))
 (.strcat ss "/bar")
-> "foo/bar"

(extends? PStr Mys)
-> true

-Rgds, Adrian.

-- 
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: protocols and satisfies?

[Nicolas Oury]

Actually, it seems to do what I thought.

My bad, problem of loaded stuff in REPL... Shame on me.

On Tue, May 18, 2010 at 3:24 PM, Nicolas Oury wrote:

> Dear all,
>
> I am trying to play with the features of 1.2.
>
> What is the canonical way to know whether something satisfies (is satisfies
> the right terminology?) a protocol.
>
> I tried satisfies? but it does not seem to do what I supposed it did.
>
> May someone more knowledgeable  than me explain me?
>
> Best regards,
>
> Nicolas.
>

-- 
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: functional check slower than imperative?

[braver]

On May 18, 10:27 am, David Nolen  wrote:
> On Tue, May 18, 2010 at 10:18 AM, braver  wrote:
> The documentation is pretty clear about how pmap works. Your work needs to
> be greater than the coordination overhead. You probably need to batch your
> work before trying to call pmap.

David -- note that loop outperforms every? by 4x without pmap.  So
forget pmap, we know it's overhead-y, why does every? lose?

-- Alexy

-- 
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: functional check slower than imperative?

[David Nolen]

On Tue, May 18, 2010 at 10:18 AM, braver  wrote:

> I have a huge graph of the form
>
> {"john" {1 {"alice" 1, "bob" 3}, 4 {"alice" 2, "stan" 1}, "alice" {1
> {"john" 1, "mandy" 2}, 2 {"john" 3, "stan" 2}}}
>
> It shows for each user days on which he communicated, and for each
> day, with whom and how many times he addressed that person.
> Essentially this is an adjacency list -- here it's a map --
> representation of a graph.
>
> I need to verify that for any top-level user, the days in his
> adjacency list, as returned by seq'ing the adjacency map.  I've
> written these functions to do it, with the help of the #clojure folks:
>
> (defn reps-sorted1? [dreps & [progress]]
>  (loop [[[user ureps :as userdays] :as users] (seq dreps) i 0]
>(if ureps
>  (if (loop [prev 0 [[day _] :as days] (seq ureps)]
>(when (and progress (= 0 (mod i progress))) (print ".")
> (.flush System/out))
>(if day (if (<= prev day)
>  (recur day (next days))
>(do (println userdays) false)) true))
>(recur (next users) (inc i)) false) true)))
>
> (defn reps-sorted2? [dreps]
>  (->> dreps (pmap (fn [[_ days]]
>(let [s (map first days)]
>  (every? true? (map >= s (cons (first s) s))
>(every? true?)))
>
> user=> (time (reps-sorted2?
> dreps))
> "Elapsed time: 127606.905 msecs"
> true
> user=> (time (reps-sorted1? dreps))
> "Elapsed time: 8368.616 msecs"
> true
>
> As you can see, the imperative solution vastly outperforms the
> functional one, even though the functional allows for pmap!  Without
> the pmap, it actually did faster, in 40 seconds.  Why is FP slower
> here?
>
> -- Alexy
>

The documentation is pretty clear about how pmap works. Your work needs to
be greater than the coordination overhead. You probably need to batch your
work before trying to call pmap.

David

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

protocols and satisfies?

[Nicolas Oury]

Dear all,

I am trying to play with the features of 1.2.

What is the canonical way to know whether something satisfies (is satisfies
the right terminology?) a protocol.

I tried satisfies? but it does not seem to do what I supposed it did.

May someone more knowledgeable  than me explain me?

Best regards,

Nicolas.

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

functional check slower than imperative?

[braver]

I have a huge graph of the form

{"john" {1 {"alice" 1, "bob" 3}, 4 {"alice" 2, "stan" 1}, "alice" {1
{"john" 1, "mandy" 2}, 2 {"john" 3, "stan" 2}}}

It shows for each user days on which he communicated, and for each
day, with whom and how many times he addressed that person.
Essentially this is an adjacency list -- here it's a map --
representation of a graph.

I need to verify that for any top-level user, the days in his
adjacency list, as returned by seq'ing the adjacency map.  I've
written these functions to do it, with the help of the #clojure folks:

(defn reps-sorted1? [dreps & [progress]]
  (loop [[[user ureps :as userdays] :as users] (seq dreps) i 0]
(if ureps
  (if (loop [prev 0 [[day _] :as days] (seq ureps)]
(when (and progress (= 0 (mod i progress))) (print ".")
(.flush System/out))
(if day (if (<= prev day)
  (recur day (next days))
(do (println userdays) false)) true))
(recur (next users) (inc i)) false) true)))

(defn reps-sorted2? [dreps]
  (->> dreps (pmap (fn [[_ days]]
(let [s (map first days)]
  (every? true? (map >= s (cons (first s) s))
(every? true?)))

user=> (time (reps-sorted2?
dreps))
"Elapsed time: 127606.905 msecs"
true
user=> (time (reps-sorted1? dreps))
"Elapsed time: 8368.616 msecs"
true

As you can see, the imperative solution vastly outperforms the
functional one, even though the functional allows for pmap!  Without
the pmap, it actually did faster, in 40 seconds.  Why is FP slower
here?

-- Alexy

-- 
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: with-meta

[Heinz N. Gies]

On May 18, 2010, at 14:38 , gL wrote:

> Yes, (count mat8x8) is the appropriate method
> 
> Using meta was my mistake to avoid passing the matrix dimension over
> and over again.

well you can make a function matrix-dim that memorizes the return values :)

-- 
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: with-meta

[gL]

Yes, (count mat8x8) is the appropriate method

Using meta was my mistake to avoid passing the matrix dimension over
and over again.


On May 18, 2:23 pm, "Heinz N. Gies"  wrote:
> On May 18, 2010, at 14:13 , gL wrote:
>
>
>
> > Hi
>
> > is it good coding style to
>
> > (def mat8x8
> >     (with-meta
> >       [[0 0 0 0 0 0 0 0]
> ...
> >       [0 0 0 0 0 0 0 0]]
> >       {:dim 8}))
>
> > and later on to retrieve the matrix dimension with "(:dim (meta
> > )"?
>
> I personally would say no, since the dimension is data not meta information, 
> then again I'm never sure myself when to use meta. I'd go with something like 
> a map that holds :data (the map) and :dim (the dimension) or just do (count 
> mat8x8).
>
> Regards,
> Heinz
>
> --
> 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 
> athttp://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

Re: Does emacs suppress output from thread ?

[Dave Fayram]

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: Dynamic use of protocols

[Mikhail Kryshen]

I don't see how creating MultiFn directly is any less safe than using
defmulti which also creates mutable object. And multimethods are never
pure functions (may return different values for the same argument
after defmethod call). I think the documentation should explicitly
state mutability and non-pureness of multimethods.

By the way, what was the motivation to make multimethods mutable?


On 17 май, 20:52, Sean Devlin  wrote:
> You could create a local instance of clojure.lang.MultiFn in a let
> binding, and access it directly.  You can see the definition of the
> object here:
>
> http://github.com/richhickey/clojure/blob/master/src/jvm/clojure/lang...
>
> The very good reason you DO NOT DO THIS is that this object is
> MUTABLE.
>
> I STRONGLY RECOMMEND that you use a dispatch fn that returns a
> keyword, and use that to select a closure from a hash map for local
> bindings.
>
> Sean
>
> On May 17, 10:41 am, Mikhail Kryshen  wrote:
>
>
>
>
>
> > On 17 май, 12:07, Laurent PETIT  wrote:
>
> > > Yes,
>
> > > as David wrote,
>
> > > What you're describing is not single-dispatch-based polymorphism (e.g.
> > > like in java), it's double dispatch (because you want to dispatch to
> > > the implementation of the protocol function based on both the type and
> > > another parameter which may be totally dynamic, or materialized -when
> > > serialized- by some key in the configuration - spring bean name,
> > > etc.).
>
> > That makes sense. It looks like I was trying to avoid explicit
> > double-dispatch by manipulating the protocol at runtime. Is it abuse
> > of dynamic features of Clojure?
>
> > > Protocols are based on a single dispatch mechanism, as classical
> > > "class based" languages (e.g. Java) are.
>
> > > When you write "kind of expandability almost free with well-designed
> > > OO systems", I guess this design implies some kind of implementation
> > > of the Strategy pattern, or more probably Delegation pattern.
>
> > What I was actually talking about is the possibility to avoid global
> > state and being able to extend existing implementation to multiple
> > instances without much refactoring.
>
> > Protocols and multimethods both have global state. From what I saw in
> > Clojure source protocols are manipulated by changing root binding of
> > associated var, and multimethods are actually mutable functions
> > changed by defmethod (I see inconsistency here).
>
> > There is no standard way to create multimethod or protocol without
> > binding it to global var. Why is it possible to create non-global
> > function but not multimethod?
>
> > --
> > Mikhail
>
> > --
> > 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 
> > athttp://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 
> athttp://groups.google.com/group/clojure?hl=en

--
Mikhail

-- 
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: with-meta

[Heinz N. Gies]

On May 18, 2010, at 14:13 , gL wrote:

> Hi
> 
> is it good coding style to
> 
> (def mat8x8
> (with-meta
>   [[0 0 0 0 0 0 0 0]
...
>   [0 0 0 0 0 0 0 0]]
>   {:dim 8}))
> 
> and later on to retrieve the matrix dimension with "(:dim (meta
> )"?

I personally would say no, since the dimension is data not meta information, 
then again I'm never sure myself when to use meta. I'd go with something like a 
map that holds :data (the map) and :dim (the dimension) or just do (count 
mat8x8). 

Regards,
Heinz

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

with-meta

[gL]

Hi

is it good coding style to

(def mat8x8
 (with-meta
   [[0 0 0 0 0 0 0 0]
[0 0 0 0 0 0 0 0]
[0 0 0 1 0 0 0 0]
[0 0 0 1 0 0 0 0]
[0 0 0 1 0 0 0 0]
[0 0 0 0 0 0 0 0]
[0 0 0 0 0 0 0 0]
[0 0 0 0 0 0 0 0]]
   {:dim 8}))

and later on to retrieve the matrix dimension with "(:dim (meta
)"?

Many 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

Re: autoloading code at repl startup

[Lauri Pesonen]

On 11 May 2010 11:59, Lauri Pesonen  wrote:
>
> At least in my setup ~/.clojure/user.clj does not get loaded unless
> ~/.clojure is in the JVM classpath.

(replying to myself)

So I've made this work with swank-clojure-project by adding this to my
emacs config:

(add-hook 'swank-clojure-project-hook
  '(lambda ()
 (add-to-list 'swank-clojure-classpath "~/.clojure")))

Now ~/.clojure is in the classpath when clojure is started and
user.clj gets loaded and all is peachy.

This fixes the issue for me partly, except that swank-clojure-project
seems to on its way to retirement (?) so this approach won't really be
a long term solution.

-- 
  ! Lauri

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

[Base]

Thank you all so much!!  As always, I learn a lot from this forum.

On May 18, 12:50 am, Jarkko Oranen  wrote:
> On May 18, 2:23 am, Base  wrote:
>
> > (defn lazy-date-seq [d1 d2]
> >   (let [start (-> d1
> >                 (.dayOfMonth)
> >                 (.withMinimumValue))]
> >      (lazy-seq
> >        (cons start
> >          (if (joda/before? start d2)
> >            (lazy-date-seq (.plusMonths start 1) d2))
>
> > The lazy version worked like a champ and appears (to me) to be more in
> > the vain of Lisp (with a touch of Haskell).
> > Is the author of the blog correct about using lazy seq in this way?
> > Assuming that he is correct and I converted date-seq to a loop/recur
> > format to use TCO, would one of these be preferable over the other in
> > terms of idiomatic clojure?
>
> The lazy version is more idiomatic. By default, you should make
> sequences lazy unless there is a compelling reason to do otherwise.
>
> In this case it also avoids the stack building problem that the
> recursive version has.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.To post to this group, send email 
> tocloj...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email 
> toclojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://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

Re: labrepl - Enclojure/Maven integration

[Rick Moynihan]

On 18 May 2010 00:29, Pratik Patel  wrote:
>> How does labrepl integrate with Enclojure, and does anyone manage to
>> use an IDE effectively with lein/maven?
>
> * Now right click on the labrepl project and select "Start Project Repl".
> * This will open a new window that says "Clojure Repl (labrepl):
> * Punch this into this repl window and you're all set:
> (require 'labrepl)
> (labrepl/-main)
>
> You can also right click on any of the .clj files and right click ->
> load into repl.
>
> hope this helps,
> pratik

Sorry for my poorly worded question, but I was actually wondering how
to get non-labrepl projects to integrate with Enclojure, in the same
way the labrepl project does...  i.e. How can I get an integrated REPL
in a maven/leiningen project under Netbeans with the menu's you
describe?

It seems to me that Enclojure is lacking in this department;
especially because almost all Clojure code seems to be built with
maven and leiningen these days...  How do Enclojure users use these
libraries???

R.

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

[Preecha P]

Thanks for the explanation. I think I'll look at swank-clojure later
since emacs went haywire last time I touched it..

On May 18, 2:33 pm, alux  wrote:
> I should add, that a new thread runs in the default environment again.
>
> You may set the *out* variable in your thread with "binding":
>
> (let [dummy *out*] ; to have a name for the current *out*
>     (.start (Thread. (fn [] (binding [*out* dummy] (prn x))
>
> Regards, alux
>
> On 18 Mai, 09:26, alux  wrote:
>
>
>
> > Hi Preecha,
>
> > output in Clojure is sent to *out* (a variable that refers to
> > System.out by default). If you use emacs / slime this variable will be
> > set differently. You should find your threads output in the swank-
> > REPL, if you can find it somewhere.
>
> > Regards, alux
>
> > On 18 Mai, 03:26, 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 
> > > athttp://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 
> > athttp://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 
> athttp://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

Re: Does emacs suppress output from thread ?

[Rick Moynihan]

On 18 May 2010 08:33, alux  wrote:
> I should add, that a new thread runs in the default environment again.
>
> You may set the *out* variable in your thread with "binding":
>
> (let [dummy *out*] ; to have a name for the current *out*
>    (.start (Thread. (fn [] (binding [*out* dummy] (prn x))
>

Sadly though this doesn't work with Java libs, using System.out, does
anyone know of a trick to redirect their output to the slime REPL too?

R.

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

[alux]

I should add, that a new thread runs in the default environment again.

You may set the *out* variable in your thread with "binding":

(let [dummy *out*] ; to have a name for the current *out*
(.start (Thread. (fn [] (binding [*out* dummy] (prn x))


Regards, alux

On 18 Mai, 09:26, alux  wrote:
> Hi Preecha,
>
> output in Clojure is sent to *out* (a variable that refers to
> System.out by default). If you use emacs / slime this variable will be
> set differently. You should find your threads output in the swank-
> REPL, if you can find it somewhere.
>
> Regards, alux
>
> On 18 Mai, 03:26, 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 
> > athttp://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 
> athttp://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

Re: Does emacs suppress output from thread ?

[alux]

Hi Preecha,

output in Clojure is sent to *out* (a variable that refers to
System.out by default). If you use emacs / slime this variable will be
set differently. You should find your threads output in the swank-
REPL, if you can find it somewhere.

Regards, alux

On 18 Mai, 03:26, 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 
> athttp://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