Re: Expanding symbols and expression in macros.

[Ken Wesson]

On Wed, Jul 13, 2011 at 10:33 AM, Andrea Tortorella  wrote:
> I'm not an expert in macros, and maybe this is a stupid question but i
> think there should be a general pattern for this.
>
> I' ve a function:
>
> (defn choose* [f & choices]
>  "Applies f to one of the choices"
> . .)
>
> And this macro:
>
> (defmacro choose [[c choices] & body]
>  `(choose* (fn [~c] ~@body) ~@choices))
>
> Now if i call it with a literal sequence:
>
> (choose [x [:a :b :c]]
>   (println x))
>
> it correctly expands to:
>
> (choose* (fn [x] (println x)) :a :b :c)
>
> but if i have:
>
> (def y [:a :b :c])
> (choose [x y]
>  (println x))
>
> it gives me an error: don't know how to create ISeq from symbol.
>
> with an expression:
>
> (choose [x (vec 2 3 4)]
>   (println x))
>
> it expands to:
>
> (choose* (fn [x] (println x)) vec 2 3 4)
>
> I knew it could not be that simple, and i also understand why i get
> theese expansions, but i don't get how to solve it.
> So what's the pattern for something like this, where you want to
> evaluate a symbol or an expression before expansion?
>
> Andrea

Macros splice in an unevaluated expression.

You'll get what you want if you change the definition of choose* to:

(defn choose* [f choices]
  "Applies f to one of the choices"
  . .)

so it takes a function and a sequence argument, rather than a function
and a variable number of element arguments, and of choose to:

(defmacro choose [[c choices] & body]
  `(choose* (fn [~c] ~@body) ~choices))

so it doesn't splice choices. Your last example

(choose [x (vec 2 3 4)]
  (println x))

should now expand to:

(choose* (fn [x] (println x)) (vec 2 3 4))

which means the new choose* will run with choices bound to the vector
[2 3 4] as you desired.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

-- 
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: Expanding symbols and expression in macros.

[Luc Prefontaine]

(defmacro choose [[c choices] & body]
  `(choose* (fn [~c] ~@body) ~choices)) <--- not ~@, just ~

~@ expects a sequence result
In your first example, [:a :b :c] is a sequence but in the second example, y is 
not.

body is a sequence (& body), using ~@ there is ok there.

Luc P.

On Wed, 13 Jul 2011 07:33:57 -0700 (PDT)
Andrea Tortorella  wrote:

> I'm not an expert in macros, and maybe this is a stupid question but i
> think there should be a general pattern for this.
> 
> I' ve a function:
> 
> (defn choose* [f & choices]
>   "Applies f to one of the choices"
> . .)
> 
> And this macro:
> 
> (defmacro choose [[c choices] & body]
>  `(choose* (fn [~c] ~@body) ~@choices))
> 
> Now if i call it with a literal sequence:
> 
> (choose [x [:a :b :c]]
>(println x))
> 
> it correctly expands to:
> 
> (choose* (fn [x] (println x)) :a :b :c)
> 
> but if i have:
> 
> (def y [:a :b :c])
> (choose [x y]
>   (println x))
> 
> it gives me an error: don't know how to create ISeq from symbol.
> 
> with an expression:
> 
> (choose [x (vec 2 3 4)]
>(println x))
> 
> it expands to:
> 
> (choose* (fn [x] (println x)) vec 2 3 4)
> 
> I knew it could not be that simple, and i also understand why i get
> theese expansions, but i don't get how to solve it.
> So what's the pattern for something like this, where you want to
> evaluate a symbol or an expression before expansion?
> 
> Andrea
> 



-- 
Luc P.


The rabid Muppet

-- 
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: meta data question

[Tim Robinson]

That'll do - Thank you both.
Tim

On Jul 13, 8:12 pm, Luc Prefontaine 
wrote:
> By string I mean human readable...
>
> On Wed, 13 Jul 2011 21:56:58 -0400
>
>
>
>
>
>
>
>
>
> Luc Prefontaine  wrote:
> > # is a string representation of
> > the fn object, not the object itself.
>
> > user=> (def a get)
> > #'user/a
> > user=> (meta a)
> > {:ns #, :name get, :file
> > "clojure/core.clj", :line 1154, :arglists ([map key] [map key
> > not-found]), :added "1.0", :inline-arities #{2 3}, :inline
> > #, :doc "Returns
> > the value mapped to key, not-found or nil if key not present."}
>
> > works because a contains the fn object (get in this case).
>
> > If your intent is to get the meta data of an unnamed fn at runtime
> > the above solves your issue.
>
> > Luc P.
>
> > On Wed, 13 Jul 2011 18:35:00 -0700 (PDT)
> > Tim Robinson  wrote:
>
> > > I know I can get the meta data using the following form:
>
> > > => (meta #'get)
> > > {:ns #, :name get, :file "clojure/
> > > core.clj"
>
> > > Is there a means to get the meta data from the stored function
> > > without using its identifier?
>
> > > ie. knowing this result:
>
> > > => get
> > > #
>
> > > Can I somehow do this:
>
> > > =>(meta #)
> > > java.lang.Exception: Unreadable form...
>
> > > Thanks,
> > > Tim
>
> --
> Luc P.
>
> 
> The rabid Muppet

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

Expanding symbols and expression in macros.

[Andrea Tortorella]

I'm not an expert in macros, and maybe this is a stupid question but i
think there should be a general pattern for this.

I' ve a function:

(defn choose* [f & choices]
  "Applies f to one of the choices"
. .)

And this macro:

(defmacro choose [[c choices] & body]
 `(choose* (fn [~c] ~@body) ~@choices))

Now if i call it with a literal sequence:

(choose [x [:a :b :c]]
   (println x))

it correctly expands to:

(choose* (fn [x] (println x)) :a :b :c)

but if i have:

(def y [:a :b :c])
(choose [x y]
  (println x))

it gives me an error: don't know how to create ISeq from symbol.

with an expression:

(choose [x (vec 2 3 4)]
   (println x))

it expands to:

(choose* (fn [x] (println x)) vec 2 3 4)

I knew it could not be that simple, and i also understand why i get
theese expansions, but i don't get how to solve it.
So what's the pattern for something like this, where you want to
evaluate a symbol or an expression before expansion?

Andrea

-- 
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: How to add jar files to leiningen projects?

[Mark Rathwell]

The listing is nice...maybe would be nice to be able to limit the listing to
one artifact, or a match of artifacts with wildcards, not sure if the
feature would be used enough to justify the work though, but something like:

lein localrepo list "*ring*"

would output:

[ring]
  ring-core (0.2.0, 0.2.0-RC2, 0.3.5, 0.3.7, 0.3.8)
  ring-devel (0.3.5, 0.3.7, 0.3.8)
  ring-jetty-adapter (0.2.0-RC2, 0.3.5, 0.3.7, 0.3.8)
  ring-servlet (0.2.0-RC2, 0.3.5, 0.3.7, 0.3.8)

[lein-ring]
  lein-ring (0.3.2, 0.4.0, 0.4.3)

 - Mark

On Wed, Jul 13, 2011 at 6:57 PM, Shantanu Kumar wrote:

> Am glad it worked for you. I have updated the plugin to version 0.2
> with "list" functionality. Will appreciate any feedback/suggestion.
>
> https://github.com/kumarshantanu/lein-localrepo
>
> Regards,
> Shantanu
>
> On Jul 12, 6:40 pm, Mark Rathwell  wrote:
> > Works great, Shantanu.  Thanks!
> >
> > On Tue, Jul 12, 2011 at 3:12 AM, Shantanu Kumar <
> kumar.shant...@gmail.com>wrote:
> >
> >
> >
> >
> >
> >
> >
> > > > It would be ideal if it could be run outside of the project
> structure, as
> > > > would be the case if an additional arity was added to the install
> > > function
> > > > in leiningen.install.
> >
> > > Thanks for the report -- I have pushed version 0.1.1 so it should now
> > > be possible to install it as a plugin and run from any directory.
> >
> > > Regards,
> > > Shantanu
> >
> > > --
> > > 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
>

-- 
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: meta data question

[Luc Prefontaine]

By string I mean human readable...

On Wed, 13 Jul 2011 21:56:58 -0400
Luc Prefontaine  wrote:

> # is a string representation of
> the fn object, not the object itself.
> 
> user=> (def a get)
> #'user/a
> user=> (meta a)
> {:ns #, :name get, :file
> "clojure/core.clj", :line 1154, :arglists ([map key] [map key
> not-found]), :added "1.0", :inline-arities #{2 3}, :inline
> #, :doc "Returns
> the value mapped to key, not-found or nil if key not present."}
> 
> works because a contains the fn object (get in this case).
> 
> If your intent is to get the meta data of an unnamed fn at runtime
> the above solves your issue.
> 
> Luc P.
> 
> On Wed, 13 Jul 2011 18:35:00 -0700 (PDT)
> Tim Robinson  wrote:
> 
> > I know I can get the meta data using the following form:
> > 
> > => (meta #'get)
> > {:ns #, :name get, :file "clojure/
> > core.clj"
> > 
> > Is there a means to get the meta data from the stored function
> > without using its identifier?
> > 
> > ie. knowing this result:
> > 
> > => get
> > #
> > 
> > Can I somehow do this:
> > 
> > =>(meta #)
> > java.lang.Exception: Unreadable form...
> > 
> > Thanks,
> > Tim
> > 
> 
> 
> 



-- 
Luc P.


The rabid Muppet

-- 
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: meta data question

[Ken Wesson]

On Wed, Jul 13, 2011 at 9:35 PM, Tim Robinson  wrote:
> I know I can get the meta data using the following form:
>
> => (meta #'get)
> {:ns #, :name get, :file "clojure/
> core.clj"
>
> Is there a means to get the meta data from the stored function without
> using its identifier?
>
> ie. knowing this result:
>
> => get
> #
>
> Can I somehow do this:
>
> =>(meta #)
> java.lang.Exception: Unreadable form...

=> (let [a get] (meta a))
{:ns #, :name get, :file "clojure/core.clj",
:line 1154, :arglists ([map key] [map key not-found]), :added "1.0",
:inline-arities #{2 3}, :inline #, :doc "Returns the value mapped to
key, not-found or nil if key not present."}

Current versions, at least, put the meta on the function object itself
and not just the Var. (This was with 1.2). So if you have the
function, in a local like a above, you can get at the metadata.

With just the class name? You can create an instance and call the function:

=> (let [a (.newInstance clojure.core$get)] (a {:x 42} :x))
42

But the new instance won't have any metadata:

=> (let [a (.newInstance clojure.core$get)] (meta a))
nil

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

-- 
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: meta data question

[Luc Prefontaine]

# is a string representation of the fn 
object, not the object
itself.

user=> (def a get)
#'user/a
user=> (meta a)
{:ns #, :name get, :file "clojure/core.clj", :line 
1154, :arglists ([map key] [map key not-found]), :added "1.0", :inline-arities 
#{2 3}, :inline #, :doc 
"Returns the value mapped to key, not-found or nil if key not present."}

works because a contains the fn object (get in this case).

If your intent is to get the meta data of an unnamed fn at runtime the above 
solves your issue.

Luc P.

On Wed, 13 Jul 2011 18:35:00 -0700 (PDT)
Tim Robinson  wrote:

> I know I can get the meta data using the following form:
> 
> => (meta #'get)
> {:ns #, :name get, :file "clojure/
> core.clj"
> 
> Is there a means to get the meta data from the stored function without
> using its identifier?
> 
> ie. knowing this result:
> 
> => get
> #
> 
> Can I somehow do this:
> 
> =>(meta #)
> java.lang.Exception: Unreadable form...
> 
> Thanks,
> Tim
> 



-- 
Luc P.


The rabid Muppet

-- 
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: Build tool for mixed Clojure/Java projects

[Ken Wesson]

On Wed, Jul 13, 2011 at 7:49 PM, Mike Meyer  wrote:
> On Tue, 12 Jul 2011 22:21:39 -0400
> Ken Wesson  wrote:
>> >> Which means it's not really case 4 at all.
>> >
>> > Well, it's very clearly not cases 1, 2 or 3.
>>
>> No, it's case zero: standard multi-developer, multi-computer, single
>> canonical master copy on one computer/cluster somewhere. The thing
>> cases 1 through 4 were *alternatives* to.
>>
>> Technically true, but meaningless. The master gets tens of zillions of
>> submissions
>
> Completely and totally wrong.

Meyer, your *opinion* of me has been made *abundantly* clear by your
numerous recent posts publicly attacking my character and questioning
my intelligence and/or honesty. Everyone, by now, knows you hate me
and knows what you think of me. There is therefore no point in your
repeating it over and over again, and no point in your replying to any
more of my posts since it's a foregone conclusion what you are going
to say and that I am not going to agree with it.

That you would go so far as to suggest that Linus doesn't get large
numbers of kernel patches crossing his (perhaps not literal) desk,
when such is simply not a logical belief to hold, purely for the
purpose of publicly disagreeing with me as an excuse for belittling me
once again, proves that you have little interest in reasoned discourse
with me.

Meanwhile, I have no interest at all in any other kind of discourse,
so it seems we have nothing to talk about.

Good-bye.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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

meta data question

[Tim Robinson]

I know I can get the meta data using the following form:

=> (meta #'get)
{:ns #, :name get, :file "clojure/
core.clj"

Is there a means to get the meta data from the stored function without
using its identifier?

ie. knowing this result:

=> get
#

Can I somehow do this:

=>(meta #)
java.lang.Exception: Unreadable form...

Thanks,
Tim

-- 
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: Results from 2011 State of Clojure survey

[Sean Corfield]

On Wed, Jul 13, 2011 at 6:25 PM, Chas Emerick  wrote:
>> True. Look at the results - the top five big wins are:
>> * Functional programming
>> * Platform (JVM) compatibility / interop
>> * The REPL
>> * Immutability
>>
> My phrasing may very well have gotten in the way.  "Big wins" isn't exactly 
> precise language. :-(

Well, I think it clearly identified the "big wins" so it worked in
that respect! :)
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
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: Results from 2011 State of Clojure survey

[Chas Emerick]

On Jul 13, 2011, at 8:37 PM, Sean Corfield wrote:

> On Wed, Jul 13, 2011 at 11:41 AM, Phil Hagelberg  wrote:
>> Or it could just be that some of the other things on that list were so
>> compelling that they overshadowed these.
>> 
>> * The REPL
>> * Functional Programming
>> * Ease of development
> 
> True. Look at the results - the top five big wins are:
> * Functional programming
> * Platform (JVM) compatibility / interop
> * The REPL
> * Immutability
> 
> Next are Macros, Concurrency, Ease of development.  Also "big wins". I
> think folks would have to check almost everything to put the features
> Chas highlighted into the "big wins" category.
> 
> Perhaps a more interesting question for next year would be: "Which of
> the following Clojure features are you using?" - they don't have to be
> big wins but it would be nice to know how widely used they are.

My phrasing may very well have gotten in the way.  "Big wins" isn't exactly 
precise language. :-(

- Chas

-- 
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: Using Clojure To Debug Java Apps

[Sean Corfield]

That looks very interesting Dave - can you give a bit more information
on what sorts of things you can actually do once you have a REPL
connected? (in terms of how to access / explore things inside the
running Java application)

On Wed, Jul 13, 2011 at 4:06 PM, David Powell  wrote:
> I wrote a tool called liverepl a while ago:
> https://github.com/djpowell/liverepl
> It effectively lets you get a repl into a Java or Clojure process, but it
> has the nice feature that it works with any Java processes without requiring
> any modifications to the code.  It uses the Java Attach API, which jvisualvm
> and jconsole use to inject the repl server into the process, and then it
> connects the console to that server.  It has some special support for Tomcat
> servers too, so that you can repl into a specific webapp.

-- 
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: Results from 2011 State of Clojure survey

[Sean Corfield]

On Wed, Jul 13, 2011 at 11:41 AM, Phil Hagelberg  wrote:
> Or it could just be that some of the other things on that list were so
> compelling that they overshadowed these.
>
> * The REPL
> * Functional Programming
> * Ease of development

True. Look at the results - the top five big wins are:
* Functional programming
* Platform (JVM) compatibility / interop
* The REPL
* Immutability

Next are Macros, Concurrency, Ease of development.  Also "big wins". I
think folks would have to check almost everything to put the features
Chas highlighted into the "big wins" category.

Perhaps a more interesting question for next year would be: "Which of
the following Clojure features are you using?" - they don't have to be
big wins but it would be nice to know how widely used they are.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
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: Results from 2011 State of Clojure survey

[Sean Corfield]

On Wed, Jul 13, 2011 at 3:52 AM, Albert Cardona  wrote:
> What prevents me from using it is that clojure 1.3.* is still alpha or
> early beta, and it's been for a long time.

Well, those features are all in Clojure 1.2.0 so nothing is preventing
you using them.

That said, so far I haven't had much need for those features, although
we just added our first code using multimethods in the last week or so
(very slick solution to an event sourced email delivery analysis
problem - we dispatch on a dynamic combination of event and current
state so multimethods were the obvious, simplest and, in this case,
probably fastest solution!).

We're already using Clojure 1.3.0 in production at World Singles (in
fact our build today updated us to Beta 1 - we previously went live
with Alpha 7 and then used Alpha 8 in dev/QA for a while but were on
Beta 1 by the time we scheduled our next production build). We also
just added a cron job that uses lein run to execute a new scheduled
process - I was pleased at how straightforward that was, although of
course it "downloaded the world" the first time it ran (thank you
Maven!).
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
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: Results from 2011 State of Clojure survey

[Luc Prefontaine]

We use 1.2 in prod with protocols... no need to wait for 1.3
Luc P.

On Wed, 13 Jul 2011 06:52:01 -0400
Albert Cardona  wrote:

> Chas,
> 
> "It seems that relatively few people are taking advantage of some of
> Clojure’s most sophisticated and unique features: metadata; protocols,
> records, and types; and multimethods.  These facilities are absolutely
> game-changers, at least IMO.  Either most domains have no use for them
> (I can’t believe that), or most people don’t know how to use them
> effectively, thus they are left unused.  Those of us that write about
> and teach Clojure, take note."
> 
> 
> What prevents me from using it is that clojure 1.3.* is still alpha or
> early beta, and it's been for a long time.
> If clojure 1.3 was released and development continued into 1.4, I
> predict that protocols and records would suddenly start being used a
> lot more.
> 
> Albert
> 



-- 
Luc P.


The rabid Muppet

-- 
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: Results from 2011 State of Clojure survey

[Brian Marick]

On Jul 13, 2011, at 6:03 AM, Ambrose Bonnaire-Sergeant wrote:

> I've found that (some of) Clojure's advanced features are best taught in 
> terms of simpler ideas
> that most programmers would be familiar with.

+1


-
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
Occasional consulting on Agile
www.exampler.com, www.twitter.com/marick

-- 
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: Build tool for mixed Clojure/Java projects

[Mike Meyer]

On Tue, 12 Jul 2011 22:21:39 -0400
Ken Wesson  wrote:
> >> Which means it's not really case 4 at all.
> >
> > Well, it's very clearly not cases 1, 2 or 3.
> 
> No, it's case zero: standard multi-developer, multi-computer, single
> canonical master copy on one computer/cluster somewhere. The thing
> cases 1 through 4 were *alternatives* to.
>
> Technically true, but meaningless. The master gets tens of zillions of
> submissions

Completely and totally wrong.  Linus developed the model used by the
Linux kernel specifically to avoid having some master copy on a
central server with tens of zillions of submissions. He wrote a SCM
that allowed the distributed, ad-hoc model to work without such a
central server. All because his experience with the kernel up to that
point was that he had reached the scalability limits of your case zero
model.

And now you're claiming it's a central server model in order to
justify your erroneous assumption that having a repository implies
having a server? I'm not sure whether that's more funny or pathetic.

http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

-- 
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: Using Clojure To Debug Java Apps

[David Powell]

I wrote a tool called liverepl a while ago:

https://github.com/djpowell/liverepl

It effectively lets you get a repl into a Java or Clojure process, but it
has the nice feature that it works with any Java processes without requiring
any modifications to the code.  It uses the Java Attach API, which jvisualvm
and jconsole use to inject the repl server into the process, and then it
connects the console to that server.  It has some special support for Tomcat
servers too, so that you can repl into a specific webapp.

-- 
Dave

-- 
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: Using Clojure To Debug Java Apps

[cran1988]

This is great !!!
But you should posting it in a blog and compare it with other
solutions.

On Jul 12, 2:31 am, Asim Jalis  wrote:
> I have been using the Clojure REPL to debug a large Java server app.
> It's great for exploratory testing and for validating assumptions
> about how the system works. I wanted to post the code here in case
> someone else finds this useful.
>
> 1. Stick this in a class that is loaded early in the server/app.
>
> public static class Repl {
>     public static final String PORT = "18081";
>     public static final String NS = "user";
>
>     private final String initResult; public String getInitResult() {
> return initResult; }
>
>     public Object invoke(String fn) { try { return
> clojure.lang.RT.var(NS, fn).invoke(); } catch (Exception e) { return
> null; } }
>     public Object invoke(String fn, Object arg1) { try { return
> clojure.lang.RT.var(NS, fn).invoke(arg1); } catch (Exception e) {
> return null; } }
>     public Object invoke(String fn, Object arg1, Object arg2) { try {
> return clojure.lang.RT.var(NS, fn).invoke(arg1, arg2); } catch
> (Exception e) { return null; } }
>     public Object invoke(String fn, Object arg1, Object arg2, Object
> arg3) { try { return clojure.lang.RT.var(NS, fn).invoke(arg1, arg2,
> arg3); } catch (Exception e) { return null; } }
>
>     public Repl() {
>         String result;
>         try {
>             clojure.lang.Var eval = clojure.lang.RT.var("clojure.core", 
> "eval");
>             clojure.lang.Var read =
> clojure.lang.RT.var("clojure.core", "read-string");
>             String create_repl_server =
>               "(do " +
>                 "(use '[clojure.contrib.server-socket :only
> [create-repl-server]])" +
>                 "(create-repl-server " + PORT + ")" + ")";
>             result = eval.invoke(read.invoke(create_repl_server)).toString();
>         } catch (Exception e) {
>             result = e.toString();
>         }
>         initResult = result;
>     }}
>
> public static final Repl REPL = new Repl();
>
> 2. Use this on the command line to start the REPL:
>
> rlwrap --logfile $HOME/tmp/clj.log telnet localhost 18081
>
> Now from the REPL you can create Java objects and call methods at will.
>
> 3. To call a Clojure function called some-function in "user" namespace
> from Java, use something like this:
>
> REPL.invoke("some-function", "arg1"));

-- 
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: How to add jar files to leiningen projects?

[Shantanu Kumar]

Am glad it worked for you. I have updated the plugin to version 0.2
with "list" functionality. Will appreciate any feedback/suggestion.

https://github.com/kumarshantanu/lein-localrepo

Regards,
Shantanu

On Jul 12, 6:40 pm, Mark Rathwell  wrote:
> Works great, Shantanu.  Thanks!
>
> On Tue, Jul 12, 2011 at 3:12 AM, Shantanu Kumar 
> wrote:
>
>
>
>
>
>
>
> > > It would be ideal if it could be run outside of the project structure, as
> > > would be the case if an additional arity was added to the install
> > function
> > > in leiningen.install.
>
> > Thanks for the report -- I have pushed version 0.1.1 so it should now
> > be possible to install it as a plugin and run from any directory.
>
> > Regards,
> > Shantanu
>
> > --
> > 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: Repeating a vector n times

[Ken Wesson]

On Wed, Jul 13, 2011 at 5:17 PM, Sam Ritchie  wrote:
> Ken, that'll result in the original vector back out again.
> (vec (take 3 (cycle [1 2 3]))) => [1 2 3].
> I think you mean:
> (vec (take (* n (count xs)) (cycle xs

I wasn't using "n" to mean the number of repetitions of the xs but the
total number of desired elements. One advantage of this method is if
you want the first 20 elements from repeating a vector of seven items
it won't set your hair on fire. :)

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

-- 
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: Repeating a vector n times

[Sam Ritchie]

Ken, that'll result in the original vector back out again.

(vec (take 3 (cycle [1 2 3]))) => [1 2 3].

I think you mean:

(vec (take (* n (count xs)) (cycle xs

On Wed, Jul 13, 2011 at 5:13 PM, Ken Wesson  wrote:

> On Wed, Jul 13, 2011 at 11:21 AM, Bhinderwala, Shoeb
>  wrote:
> > Thanks Tamreen. Your solution will have to be wrapped in another vec
> call. I
> > will use Miekel’s:
> >
> >
> >
> >(reduce into [] (repeat n xs)).
>
> What about (vec (take n (cycle xs)))?
>
> --
> Protege: What is this seething mass of parentheses?!
> Master: Your father's Lisp REPL. This is the language of a true
> hacker. Not as clumsy or random as C++; a language for a more
> civilized age.
>
> --
> 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: Repeating a vector n times

[Ken Wesson]

On Wed, Jul 13, 2011 at 11:21 AM, Bhinderwala, Shoeb
 wrote:
> Thanks Tamreen. Your solution will have to be wrapped in another vec call. I
> will use Miekel’s:
>
>
>
>    (reduce into [] (repeat n xs)).

What about (vec (take n (cycle xs)))?

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

-- 
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: Results from 2011 State of Clojure survey

[Ken Wesson]

On Wed, Jul 13, 2011 at 2:41 PM, Phil Hagelberg  wrote:
> Albert Cardona  writes:
>
>> "It seems that relatively few people are taking advantage of some of
>> Clojure’s most sophisticated and unique features: metadata; protocols,
>> records, and types; and multimethods.  These facilities are absolutely
>> game-changers, at least IMO.  Either most domains have no use for them
>> (I can’t believe that), or most people don’t know how to use them
>> effectively, thus they are left unused.  Those of us that write about
>> and teach Clojure, take note."
>
> Or it could just be that some of the other things on that list were so
> compelling that they overshadowed these.
>
> * The REPL
> * Functional Programming
> * Ease of development

Good point. Though the items on that question were not mutually
exclusive (you could tick more than one), it's likely some people
ticked the one they thought most compelling and that others ticked
three or four, but only the ones they considered to be "bread and
butter" rather than "the icing on the cake".

> These are the bread-and-butter of programming, so much that I'd have a
> hard time ever working in (or even taking seriously) a language that
> didn't support them.

What about ones that seem to go out of their way not to? Java comes to
mind. VB adds in "from Microsoft" and "no free software
implementation" for added fun. :)

Languages that do have those three items you considered crucial:
Lisps, of course, and I think Python and maybe even Ruby. Smalltalk
may be a bit of an oddball case: with its "BlockContext" closures it
has roughly half of FP available (there are limits on creating and
returning and then reusing them, or using them in multiple threads)
and its "Transcript" objects are something of a REPL (it's even
possible to create new classes and methods at it by typing the right
incantations, something like BaseClass subclass: NewName ...) and
interactive development and debugging there can make development
somewhat easier than in, say, Java.

Particularly, it's rapid prototyping and quickie testing that the REPL
helps, and modularization and making small, composable, easily
testable bits and clever HOF-based abstractions that FP helps, that
contributes to the third item on your list.

> I'm a fan of using multimethods to achieve
> polymorphism, but polymorphism is only needed in a small subset of the
> code I write, while the features above affect *everything*.

Hence icing vs. bread-and-butter. Or put another way you may
appreciate the socket wrench in the toolbox even if the jobs you do
mean you mostly use the hammer, the needle-nose pliers, the
screwdrivers, and the rotary tool and reach for the wrench only
occasionally.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

-- 
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: monads > macros

[Ken Wesson]

On Wed, Jul 13, 2011 at 1:37 PM, Raoul Duke  wrote:
> On Wed, Jul 13, 2011 at 5:20 AM, Ken Wesson  wrote:
>> Oh, I'm not saying my own is exploding -- just that macros can be
>> tough for some people to get their heads around, and monads even more
>> so, so combining the two ...
>
> maybe call them something else and it won't be so bad. when people see
> the need for something, they are generally willing to pursue it and
> learn it, i think. the people using clojure are probably somewhat
> self-selectingly smart enough ;-) as long as you don't call them
> monads ha ha.

I'd probably be more insulted by being called macro.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

-- 
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: Results from 2011 State of Clojure survey

[Phil Hagelberg]

Albert Cardona  writes:

> "It seems that relatively few people are taking advantage of some of
> Clojure’s most sophisticated and unique features: metadata; protocols,
> records, and types; and multimethods.  These facilities are absolutely
> game-changers, at least IMO.  Either most domains have no use for them
> (I can’t believe that), or most people don’t know how to use them
> effectively, thus they are left unused.  Those of us that write about
> and teach Clojure, take note."

Or it could just be that some of the other things on that list were so
compelling that they overshadowed these.

* The REPL
* Functional Programming
* Ease of development

These are the bread-and-butter of programming, so much that I'd have a
hard time ever working in (or even taking seriously) a language that
didn't support them. I'm a fan of using multimethods to achieve
polymorphism, but polymorphism is only needed in a small subset of the
code I write, while the features above affect *everything*.

-Phil

-- 
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: Results from 2011 State of Clojure survey

[Chas Emerick]

Indeed, all of these features were introduced in 1.2.0.  Metadata has been 
around since (roughly) the beginning.

It's true that metadata being available only for "Clojure types" (those that 
implement clojure.lang.IObj) is unfortunate — but I wouldn't say that that's 
reason to consider the mechanism unreliable.

Multimethods shouldn't be shunned, insofar as they can succinctly solve 
modeling problems that no other mechanism can.  When you need to haul a big 
load, avoiding the big rig because it's not as fast as the race car doesn't 
make much sense. :-)

- Chas

On Jul 13, 2011, at 7:57 AM, Jonathan Fischer Friberg wrote:

> All those are available in 1.2, or am I missing something?
> 
> From my own experience:
> metadata, when I started to learn clojure, I thought "this is awesome". When 
> I realized that metadata only applies to clojure types, it felt unreliable 
> and I never got to using it.
> 
> protocols & records/types - they're straightforward, I use them.
> 
> multimethods - since close to every mention of multimethods also involves 
> telling how slow they are, these are most often shunned.
> 
> Jonathan
> 
> On Wed, Jul 13, 2011 at 12:52 PM, Albert Cardona  wrote:
> Chas,
> 
> "It seems that relatively few people are taking advantage of some of
> Clojure’s most sophisticated and unique features: metadata; protocols,
> records, and types; and multimethods.  These facilities are absolutely
> game-changers, at least IMO.  Either most domains have no use for them
> (I can’t believe that), or most people don’t know how to use them
> effectively, thus they are left unused.  Those of us that write about
> and teach Clojure, take note."
> 
> 
> What prevents me from using it is that clojure 1.3.* is still alpha or
> early beta, and it's been for a long time.
> If clojure 1.3 was released and development continued into 1.4, I
> predict that protocols and records would suddenly start being used a
> lot more.
> 
> Albert
> 
> --
> http://albert.rierol.net
> http://www.ini.uzh.ch/~acardona/
> 
> --
> 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

-- 
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: monads > macros

[Raoul Duke]

On Wed, Jul 13, 2011 at 5:20 AM, Ken Wesson  wrote:
> Oh, I'm not saying my own is exploding -- just that macros can be
> tough for some people to get their heads around, and monads even more
> so, so combining the two ...

maybe call them something else and it won't be so bad. when people see
the need for something, they are generally willing to pursue it and
learn it, i think. the people using clojure are probably somewhat
self-selectingly smart enough ;-) as long as you don't call them
monads ha ha.

-- 
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: Reworking :pre condition to add an error message

[Timothy Washington]

I do think a simple String error message is all that the user of the
function should provide. From there, An AssertionError can throw up
something along the lines of what you said - Expected… , Found… , Message.
That would give enough information for reporting at least in a test
framework. To get more precise information, like you said, that
AssertionError could also throw up class/file information, etc. that a
debugger could use. I would guard against designing these things to
accomodate a context outside of it's execution scope. In the ideal
functional world, the input and output are wholly localized. Any
Error/Exception thrown can be consumed or chained to give very precise
failure reasoning.


As for how that would fit into the entire exception chain, that's still
being thought (see here).
There are already a few approaches, and I think this (see
here)
is the context of how the core team is approaching this problem.


Cheers
Tim


On Tue, Jul 12, 2011 at 6:01 AM, Shantanu Kumar wrote:

> As I am the culprit of having introduced it with a naive example, I'd
> better admit it may not be very useful in practical scenarios across a
> wide variety of use cases. For example, when there is an assertion
> error with message "`m` should be a map" 14 levels down the stack, I'd
> really wish it said "`m` -- Expected: map, Found: vector [:foo :bar]"
> so that I can debug it quickly.
>
> Pre-conditions and Post-conditions are a valuable debugging aid, and
> to enable that we need very precise information. Unfortunately passing
> a string error message cannot encapsulate enough error context. A more
> complex example can be where the correctness of input must be
> determined collectively (in association with other args) -- in those
> cases one can only fall back on comparing input values and raise
> IllegalArgumentException accordingly.
>
> Regards,
> Shantanu
>
> On Jul 11, 10:40 pm, Timothy Washington  wrote:
> >
>

-- 
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: Repeating a vector n times

[Bhinderwala, Shoeb]

Thanks Tamreen. Your solution will have to be wrapped in another vec
call. I will use Miekel's:

 

   (reduce into [] (repeat n xs)).

 



From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On
Behalf Of Tamreen Khan
Sent: Wednesday, July 13, 2011 11:02 AM
To: clojure@googlegroups.com
Subject: Re: Repeating a vector n times

 

Damn, Meikel's solution is better, I was thinking:

 

(apply concat (repeat n xs))

 

On Wed, Jul 13, 2011 at 10:54 AM, Bhinderwala, Shoeb
 wrote:

I have to write a function that will take a vector as input, repeat the
elements multiple times and return back a single vector of the repeated
items. I came up with the following but am wondering if there is a
better or simpler way to write this:

(def xs ["a" "b" "c"])

(defn repeat-vec-n 

  [xs n]

  (vec 

(reduce concat [] 

  (take n (repeat xs)

OUTPUT:

user=> xs

["a" "b" "c"]

user=> (repeat-vec-n xs 3)

["a" "b" "c" "a" "b" "c" "a" "b" "c"]

-- Shoeb

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

-- 
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: Repeating a vector n times

[Tamreen Khan]

Damn, Meikel's solution is better, I was thinking:

(apply concat (repeat n xs))

On Wed, Jul 13, 2011 at 10:54 AM, Bhinderwala, Shoeb <
sabhinderw...@wellington.com> wrote:

> **
>
> I have to write a function that will take a vector as input, repeat the
> elements multiple times and return back a single vector of the repeated
> items. I came up with the following but am wondering if there is a better
> or simpler way to write this:
>
> (def xs ["a" "b" "c"])
>
> (defn repeat-vec-n
>
>   [xs n]
>
>   (vec
>
> (reduce concat []
>
>   (take n (repeat xs)
>
> OUTPUT:
>
> user=> xs
>
> ["a" "b" "c"]
>
> user=> (repeat-vec-n xs 3)
>
> ["a" "b" "c" "a" "b" "c" "a" "b" "c"]
>
> ***-- Shoeb*
>
>  --
> 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

Aw: Repeating a vector n times

[Meikel Brandmeyer]

Hi,

you could use (reduce into [] (repeat n xs)).

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

Repeating a vector n times

[Bhinderwala, Shoeb]

I have to write a function that will take a vector as input, repeat the
elements multiple times and return back a single vector of the repeated
items. I came up with the following but am wondering if there is a
better or simpler way to write this:

(def xs ["a" "b" "c"])

(defn repeat-vec-n 
  [xs n]
  (vec 
(reduce concat [] 
  (take n (repeat xs)

OUTPUT:
user=> xs
["a" "b" "c"]

user=> (repeat-vec-n xs 3)
["a" "b" "c" "a" "b" "c" "a" "b" "c"]

-- Shoeb

-- 
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: Change in reduce behavior in 1.3.0?

[Sebastián Galkin]

> At what point in time it realises the elements is mood in the end

Yes. Probably the whole point of (finite) lazy seqs is some sort of side 
effect. Be it memory consumption, processing time, or other forms of 
side-effect. But, shouldn't map, filter, reduce and others, with its 
lazy-friendly behavior help us deal with the side effects in a predictable 
manner? Maybe reduce doesn't belong to that group, and that's why you 
proposed a change in contract.

> But why rely on unlikeliness when one can easily fix this?

Yes, I already changed it to not depend on reduce realization order.
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: Change in reduce behavior in 1.3.0?

[Meikel Brandmeyer]

Hi,

Am Mittwoch, 13. Juli 2011 16:15:28 UTC+2 schrieb Sebastián Galkin:
>
> > Making assumptions between the order of realization of seq elements and 
> calls to the reducing functions seems crazy to me, really. 
>
> May be, but it's not as much about the order as about the laziness. New 
> reduce is less lazy than previous, and maybe unnecessarily so. If you think 
> of a collection, you don't care, since is going to be completely reduced 
> anyway, but if your seq is a lazy-seq, you want as much laziness as you can 
> have. 
>

reduce is always eager and will consume the total sequence. At what point in 
time it realises the elements is mood in the end, unless two elements of 
your seq won't fit in memory at the same time (or you got side-effects...). 
So, I still think reduce shouldn't do that, although hitting a case 
triggering this issue is rather unlikely in practise.

But why rely on unlikeliness when one can easily fix this?

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: Change in reduce behavior in 1.3.0?

[Sebastián Galkin]

> Making assumptions between the order of realization of seq elements and 
calls to the reducing functions seems crazy to me, really. 

May be, but it's not as much about the order as about the laziness. New 
reduce is less lazy than previous, and maybe unnecessarily so. If you think 
of a collection, you don't care, since is going to be completely reduced 
anyway, but if your seq is a lazy-seq, you want as much laziness as you can 
have. 

My 1E-3M$

-- 
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: Change in reduce behavior in 1.3.0?

[Laurent PETIT]

2011/7/13 Sebastián Galkin 

> Oh I see it now, the call is inverted in 1.2.1 core.clj. Thanks, it was
> driving me crazy.
>
> Regarding Meikel comment on clojure-dev
>
> > I will open a ticket to either apply the shown fix, or modify the
> contract of reduce to require pureness of f.
>
> I think that changing reduce contract, such a basic building block, may be
> a little harsh.
>

Making assumptions between the order of realization of seq elements and
calls to the reducing functions seems crazy to me, really.

I don't even see why a ticket should be opened, or the contract of reduce
should be changed.

My 0.02€,

-- 
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: Change in reduce behavior in 1.3.0?

[Sebastián Galkin]

Oh I see it now, the call is inverted in 1.2.1 core.clj. Thanks, it was 
driving me crazy.

Regarding Meikel comment on clojure-dev

> I will open a ticket to either apply the shown fix, or modify the contract 
of reduce to require pureness of f.

I think that changing reduce contract, such a basic building block, may be a 
little harsh.

-- 
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: Question on eliminating recur

[FL]

On Jul 13, 1:16 am, Christian Marks <9fv...@gmail.com> wrote:
> Thank you. Based on this I've simplified the code further.

You could combine the test for a cycle leader
with the cycle length count--but your original
code, which calculates cycle lengths only if
a cycle leader is identified, is more efficient!

> (ns knuth
>     (:require [clojure.contrib.math :as math]))
>
> (defn random-perm [n]  (shuffle (range n)))
>
 (defn cycle-leader-length [perm i]
         (loop [cycle 1 j (nth perm i)]
                 (cond (< j i) 1
                       (= j i) cycle
                       :else     (recur (inc cycle) (nth perm j)

(defn order-perm [perm]   (reduce  (fn [order i]  (math/lcm (cycle-
leader-length perm i) order)) 1 perm))

-- 
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: Results from 2011 State of Clojure survey

[James Sofra]

I think for me at least leveraging the polymorphism that the seq
abstraction provides gets you such a long way compared to collection
libs in other languages that you don't have to reach for the other
features as quickly.
I think Rich even stated that as one of the reasons for delaying their
introduction in the first place, he wanted people to become
comfortable making full use of seqs.

Cheers,
James S

On Jul 13, 9:03 pm, Ambrose Bonnaire-Sergeant
 wrote:
> I've found that (some of) Clojure's advanced features are best taught in
> terms of simpler ideas
> that most programmers would be familiar with.
>
> For example, excuse the plug, I motivated multimethods by relating them to
> simple conditionals
> like "case". I think I succeeded in making MMs just look like a fancier
> conditional, which is much
> more friendly than an "arbitrary dispatch mechanism" ;)
>
> http://pragprog.com/magazines/2011-07/growing-a-dsl-with-clojure
>
> I'm brainstorming how we could approach teaching the other features you
> mentioned similarly.
>
> Thanks,
> Ambrose
>
>
>
> On Wed, Jul 13, 2011 at 6:52 PM, Albert Cardona  wrote:
> > Chas,
>
> > "It seems that relatively few people are taking advantage of some of
> > Clojure’s most sophisticated and unique features: metadata; protocols,
> > records, and types; and multimethods.  These facilities are absolutely
> > game-changers, at least IMO.  Either most domains have no use for them
> > (I can’t believe that), or most people don’t know how to use them
> > effectively, thus they are left unused.  Those of us that write about
> > and teach Clojure, take note."
>
> > What prevents me from using it is that clojure 1.3.* is still alpha or
> > early beta, and it's been for a long time.
> > If clojure 1.3 was released and development continued into 1.4, I
> > predict that protocols and records would suddenly start being used a
> > lot more.
>
> > Albert
>
> > --
> >http://albert.rierol.net
> >http://www.ini.uzh.ch/~acardona/
>
> > --
> > 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: monads > macros

[Ken Wesson]

On Wed, Jul 13, 2011 at 7:19 AM, Konrad Hinsen
 wrote:
> On 13 Jul 2011, at 05:04, Ken Wesson wrote:
>
>>> One approach that has been proposed to improve composability of macros is
>>> to
>>> adopt a continuation-passing style. This would make macros a candidate
>>> for
>>> the continuation monad, so perhaps monads may be of use in implementing
>>> complex macros.
>>
>> That popcorn-popping sound you hear is heads exploding out there in
>> the audience.
>
> Maybe this article will help understand what I was referring to - noting
> that this is for Scheme and not Clojure:
>
> http://okmij.org/ftp/papers/CPS-Macros.ps.gz

Oh, I'm not saying my own is exploding -- just that macros can be
tough for some people to get their heads around, and monads even more
so, so combining the two ...

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

-- 
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: Results from 2011 State of Clojure survey

[Ambrose Bonnaire-Sergeant]

Hi,

On Wed, Jul 13, 2011 at 7:57 PM, Jonathan Fischer Friberg <
odysso...@gmail.com> wrote:
>
> multimethods - since close to every mention of multimethods also involves
> telling how slow they are, these are most often shunned.
>
>
I don't get that impression. MM's seem to be pushed as a "first choice" for
implementing prototypes over protocols, much like maps are often recommended
over records.

At least on this mailing list, maybe more generally you hear recounting
their experience of converting MM to protocols as an optimization.

Thanks,
Ambrose

-- 
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: Results from 2011 State of Clojure survey

[Jonathan Fischer Friberg]

All those are available in 1.2, or am I missing something?

>From my own experience:
metadata, when I started to learn clojure, I thought "this is awesome". When
I realized that metadata only applies to clojure types, it felt unreliable
and I never got to using it.

protocols & records/types - they're straightforward, I use them.

multimethods - since close to every mention of multimethods also involves
telling how slow they are, these are most often shunned.

Jonathan

On Wed, Jul 13, 2011 at 12:52 PM, Albert Cardona  wrote:

> Chas,
>
> "It seems that relatively few people are taking advantage of some of
> Clojure’s most sophisticated and unique features: metadata; protocols,
> records, and types; and multimethods.  These facilities are absolutely
> game-changers, at least IMO.  Either most domains have no use for them
> (I can’t believe that), or most people don’t know how to use them
> effectively, thus they are left unused.  Those of us that write about
> and teach Clojure, take note."
>
>
> What prevents me from using it is that clojure 1.3.* is still alpha or
> early beta, and it's been for a long time.
> If clojure 1.3 was released and development continued into 1.4, I
> predict that protocols and records would suddenly start being used a
> lot more.
>
> Albert
>
> --
> http://albert.rierol.net
> http://www.ini.uzh.ch/~acardona/
>
> --
> 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: monads > macros

[Konrad Hinsen]

On 13 Jul 2011, at 05:04, Ken Wesson wrote:

One approach that has been proposed to improve composability of  
macros is to
adopt a continuation-passing style. This would make macros a  
candidate for
the continuation monad, so perhaps monads may be of use in  
implementing

complex macros.


That popcorn-popping sound you hear is heads exploding out there in
the audience.


Maybe this article will help understand what I was referring to -  
noting that this is for Scheme and not Clojure:


http://okmij.org/ftp/papers/CPS-Macros.ps.gz

Konrad.

--
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: Results from 2011 State of Clojure survey

[Ambrose Bonnaire-Sergeant]

I've found that (some of) Clojure's advanced features are best taught in
terms of simpler ideas
that most programmers would be familiar with.

For example, excuse the plug, I motivated multimethods by relating them to
simple conditionals
like "case". I think I succeeded in making MMs just look like a fancier
conditional, which is much
more friendly than an "arbitrary dispatch mechanism" ;)

http://pragprog.com/magazines/2011-07/growing-a-dsl-with-clojure

I'm brainstorming how we could approach teaching the other features you
mentioned similarly.

Thanks,
Ambrose

On Wed, Jul 13, 2011 at 6:52 PM, Albert Cardona  wrote:

> Chas,
>
> "It seems that relatively few people are taking advantage of some of
> Clojure’s most sophisticated and unique features: metadata; protocols,
> records, and types; and multimethods.  These facilities are absolutely
> game-changers, at least IMO.  Either most domains have no use for them
> (I can’t believe that), or most people don’t know how to use them
> effectively, thus they are left unused.  Those of us that write about
> and teach Clojure, take note."
>
>
> What prevents me from using it is that clojure 1.3.* is still alpha or
> early beta, and it's been for a long time.
> If clojure 1.3 was released and development continued into 1.4, I
> predict that protocols and records would suddenly start being used a
> lot more.
>
> Albert
>
> --
> http://albert.rierol.net
> http://www.ini.uzh.ch/~acardona/
>
> --
> 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: Results from 2011 State of Clojure survey

[Albert Cardona]

Chas,

"It seems that relatively few people are taking advantage of some of
Clojure’s most sophisticated and unique features: metadata; protocols,
records, and types; and multimethods.  These facilities are absolutely
game-changers, at least IMO.  Either most domains have no use for them
(I can’t believe that), or most people don’t know how to use them
effectively, thus they are left unused.  Those of us that write about
and teach Clojure, take note."


What prevents me from using it is that clojure 1.3.* is still alpha or
early beta, and it's been for a long time.
If clojure 1.3 was released and development continued into 1.4, I
predict that protocols and records would suddenly start being used a
lot more.

Albert

-- 
http://albert.rierol.net
http://www.ini.uzh.ch/~acardona/

-- 
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: Change in reduce behavior in 1.3.0?

[Meikel Brandmeyer]

Hi,

Am Mittwoch, 13. Juli 2011 11:02:40 UTC+2 schrieb bsmith.occs:
>
> On Wed, Jul 13, 2011 at 08:43, Meikel Brandmeyer  wrote:
> > Hi,
> >
> > I think the culprit is here:
> > 
> https://github.com/clojure/clojure/blob/5f9d6a02c530a02251197e1b844af37440a6b569/src/clj/clojure/core/protocols.clj#L64
> >
> > The line "(recur cls (next s) f (f val (first s)))" must be written as
> >
> > (let [v (f val (first s))]
> >   (recur cls (next s) f v))
> >
> > for your scenario to work.
>
> I'm probably being a little dense this morning, but...
>
> I've stared at both examples for some time now and still don't see why
> the first should behave differently than the second.
>
> Can you give me a hint?
>
Because - although not guaranteed - clojure evaluates function arguments 
from the left to the right. So the next element in the sequence is realised 
before the function f is called. In the second snippet f will be called 
always before the next element is realised. If f is pure, there won't be a 
difference. If f is not pure, it will be a difference. Especially if next 
relies on side-effects of f (or vice versa) as in the scenario described by 
the OP.

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: Change in reduce behavior in 1.3.0?

[Ben Smith-Mannschott]

On Wed, Jul 13, 2011 at 08:43, Meikel Brandmeyer  wrote:
> Hi,
>
> I think the culprit is here:
> https://github.com/clojure/clojure/blob/5f9d6a02c530a02251197e1b844af37440a6b569/src/clj/clojure/core/protocols.clj#L64
>
> The line "(recur cls (next s) f (f val (first s)))" must be written as
>
> (let [v (f val (first s))]
>   (recur cls (next s) f v))
>
> for your scenario to work.

I'm probably being a little dense this morning, but...

I've stared at both examples for some time now and still don't see why
the first should behave differently than the second.

Can you give me a hint?

// Ben

-- 
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: monads > macros

[Konrad Hinsen]

On 12 Jul 2011, at 23:18, Alan Malloy wrote:


On Jul 12, 12:01 pm, Konrad Hinsen  wrote:
The composability issue with macros lies in writing them, not using  
them.


Strongly disagree. Macros compose reasonably well when writing them
(eg, using let in the implementation of with-open is trivial); it's


That's not composition, that's use. What I mean by composition is  
writing a complex macro in terms of simpler macros and macro  
composers, just as one writes complex functions in terms of simple  
functions and higher-order functions. There is no equivalent of higher- 
order functions in the macro universe, for example.



composing already-written macros with other pieces of your codebase
that's hard. (reduce and xs) won't test that every element of xs is
truthy, because and is a macro and thus can't be used as a higher-
order function.


That's exactly the kind of problem I was thinking of. So in fact we  
agree, except for the label to put on the problem.


Konrad.

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