Re: Clojure Code Style

[Richard Newman]

> Also this function generates two classes, while the
> other two variants generate 6.

Thank you for pointing this out! It -- surprisingly -- hadn't occurred  
to me before that different approaches to writing the same code would  
actually generate different sets of classes, possibly of very  
different sizes.

It's obvious in hindsight... I guess Clojure is very good at  
abstracting away the details of Java class definition, and I only look  
when inspecting jars to make sure the right namespaces and generated  
classes go in the right place.

--~--~-~--~~~---~--~~
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: Clojure Code Style

[Meikel Brandmeyer]

Hi,

On Aug 13, 6:34 am, Richard Newman  wrote:

> I find this much nicer than stacking parens:
>
> (defn clean-lines [x]
>    (non-empty
>      (trimmed-lines
>        (read-lines x)))

There is also the nice -> macro.

(defn clean-lines
  [x]
  (-> x read-lines trimmed-lines non-empty))

which comes close to your composition, but has easy
docstrings.

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: Clojure Code Style

[Meikel Brandmeyer]

Hi,

On Aug 13, 2:02 am, Sean Devlin  wrote:

> A)  Traditional definition
>
> (defn str->date-map
>   [input-string]
>   ((trans :month (comp dec :month))
>    (apply hash-map (interleave
>                     [:month :day :year]
>                     (map parse-int (re-split input-string #"/"))

I would use a bit more `let` in the whole thing.

(defn str->date-map
  [input]
  (let [parts   (map parse-int (re-split #"/"))
date(zipmap [:month :day :year] parts)
transformer (trans :month #(-> % :month dec))]
(transformer date)))

I find, that this way its easier to add comments
to certain parts if necessary and each function
call get shorter, meaning easier to read and parse.

Also this function generates two classes, while the
other two variants generate 6.

YMMV.

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: Clojure Code Style

[Stuart Halloway]

A point-free definition does not explicitly mention the values of the  
space on which the function acts.

See http://www.haskell.org/haskellwiki/Pointfree.

> On Thu, Aug 13, 2009 at 12:34 AM, Richard Newman  
>  wrote:
> This is the difference between 'conventional' and point-free style, by
> the way. Many people view point-free as being somehow more elegant,
> and I'm generally inclined to agree... apart from in cases like your
> example, where a ton of partials need to be added.
>
> What is "point-free", exactly?
>
> >


--~--~-~--~~~---~--~~
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: Clojure Code Style

[John Harrop]

On Thu, Aug 13, 2009 at 12:34 AM, Richard Newman  wrote:

> This is the difference between 'conventional' and point-free style, by
> the way. Many people view point-free as being somehow more elegant,
> and I'm generally inclined to agree... apart from in cases like your
> example, where a ton of partials need to be added.


What is "point-free", exactly?

--~--~-~--~~~---~--~~
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: Clojure Code Style

[Richard Newman]

> Let me know what you all think!

In this case, A. I've definitely been known to use composition, but  
only when the definition is simple and expressive: e.g.,

(def clean-lines (comp non-empty trimmed-lines read-lines))

I find this much nicer than stacking parens:

(defn clean-lines [x]
   (non-empty
 (trimmed-lines
   (read-lines x)))

though I've never compared efficiency, and I know it makes it harder  
to add docstrings.

This is the difference between 'conventional' and point-free style, by  
the way. Many people view point-free as being somehow more elegant,  
and I'm generally inclined to agree... apart from in cases like your  
example, where a ton of partials need to be added.

-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: ANN: Clojure Ant Tasks

[J. McConnell]

On Wed, Aug 12, 2009 at 12:03 PM, J. McConnell  wrote:

> On Wed, Aug 12, 2009 at 4:00 AM, C. Florian Ebeling <
> florian.ebel...@gmail.com> wrote:
>
>>
>> Thanks for sharing this. What I miss a bit is the ability to set the
>> *compile-path* to something other than "classes".
>
>
> Thanks for your input! Yes, this was always planned, I just didn't have a
> need for it. Anyway, I've just pushed this change to github, so the compile
> task now takes a "compilePath" attribute, which will default to "classes".
>
>
>> And might it be a
>> good idea to be able to name .clj files instead of namespaces as an
>> option? Then one could use regular ant filesets constucted
>> automatically from expressions, instead of naming namespaces
>> individually.
>
>
And now this has also been added. Both the compile and test tasks support a
nested  tag in addition to the existing  tags. Try
it out and let me know if that meets your needs.

Regards,

- J.

--~--~-~--~~~---~--~~
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: Clojure performance tests and clojure a little slower than Java

[Glen Stampoultzis]

>
> There was a good thread on this list some weeks ago which mentioned
> another JVM flag:
> -XX:+PrintOptoAssembly
>
> The original thread:
>
> http://groups.google.com/group/clojure/browse_thread/thread/314952431ec064b7?fwc=1
>
>
There's some more information about it at [1].  It looks like you need a
plugin to get it to work.  I'm on Windows and unfortunately for Windows
there doesn't seem to be a prebuilt binary for this platform.

[1] http://wikis.sun.com/display/HotSpotInternals/PrintAssembly

--~--~-~--~~~---~--~~
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: Clojure Code Style

[Wilson MacGyver]

I would also vote A, seems much more straight forward.

On Wed, Aug 12, 2009 at 8:02 PM, Sean Devlin wrote:
>
> Hello Clojurians,
> I've been experimenting with different coding styles, and I'm
> interested in the group's opinion. Which set of code is easiest to
> read?
>
> A)  Traditional definition
>
> (defn str->date-map
>  [input-string]
>  ((trans :month (comp dec :month))
>   (apply hash-map (interleave
>                    [:month :day :year]
>                    (map parse-int (re-split input-string #"/"))
>
> B)  Functional Composition
>
> (def str->date-map
>     (comp (trans :month (comp dec :month))
>           (partial apply hash-map)
>           (partial interleave [:month :day :year])
>           (partial map parse-int)
>           #(re-split % #"/"))
>
> C)  Perl's Revenge
>
> (def $ partial)
> (def & comp)
>
> (def str->date-map
>     (& (trans :month (& dec :month))
>           ($ apply hash-map)
>           ($ interleave [:month :day :year])
>           ($ map parse-int)
>           #(re-split % #"/"))
>
> Let me know what you all think!
> >
>



-- 
Omnem crede diem tibi diluxisse supremum.

--~--~-~--~~~---~--~~
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: http-agent

[Stuart Sierra]

Fixed; thanks.
-SS


On Aug 12, 2:46 am, Anniepoo  wrote:
> using http-agent threw
>
> (# matching method found: setFixedLenghtStreamingMode for class
> sun.net.www.protocol.http.HttpURLConnection>)
>
> notice the spelling error in 'setFixedLenghtSttreamingMode'  (Lenght)
>
> this from the HEAD of trunk as of Aug 11 about 11pm PDT
--~--~-~--~~~---~--~~
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: Clojure, Java JIT, and inlining

[Richard Newman]

> I don't think Vars are thread-local.  They're one of the shared
> mutable state primitives.  They can be defacto thread local if only
> used by a single thread but you need a "sufficiently smart compiler"
> to notice that.

"Vars provide a mechanism to refer to a mutable storage location that  
can be dynamically rebound (to a new storage location) on a per-thread  
basis."

That is, bindings are thread-local. set! modifies only the current  
thread's binding.

There is a root binding which is intended to be immutable:

"Currently, it is an error to attempt to set the root binding of a var  
using set!, i.e. var assignments are thread-local."

From




All of this broadly means that the scope of a particular var can be  
determined for a given thread's execution. That's not true of a ref,  
for example.

--~--~-~--~~~---~--~~
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: Clojure Code Style

[Timothy Pratley]

> Let me know what you all think!

Just thought it worth a mention that another approach to composed
partials is to use a 'pipe' macro (similar to ->). There was a very
good thread about various implementations which I can't find anymore :
( FWIW I like your use of & as comp but $ for partial doesn't appeal
to me and only saves 1 character over
#(apply hash-map %)  ;; which doesn't look very nice either. Just my
opinion :)

Regards,
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: Clojure, Java JIT, and inlining

[CuppoJava]

It is my experience also, that inlining gives the greatest performance
gain for functions that expect primitive arguments.
As Chouser said, doing this eliminates the boxing/unboxing overhead.

Here's my take on this:
The Java method signatures created by Clojure will always be Objects
in order to maintain a consistent interface. Therefore it doesn't make
sense for HotSpot to remove that boxing overhead. HotSpot sees a
"function that takes a Integer". Why should it eliminate the boxing
and treat it like a "function that takes a int"? What if the function
really did want a Integer instead of an int? This isn't a decision the
compiler can make.

Hope that helps (and is correct).
-Patrick
--~--~-~--~~~---~--~~
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: Clojure Code Style

[CuppoJava]

The first one is still the most straightforward to me personally. I
feel there's no need to introduce function composition if there's no
immediate advantage. In this case, In Clojure's case, I'm guessing
function composition comes with some performance costs as well.
  -Patrick
--~--~-~--~~~---~--~~
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: Newbie with problems building clojure-contrib

[Wilson MacGyver]

There is a branch in clojure-contrib that is 1.0 compatible.

Sent from my iPhone

On Aug 12, 2009, at 7:35 PM, Andy Fingerhut  wrote:

>
> Oh, one more thing.  If you have latest git clojure-contrib, I'd
> recommend trying it with latest git clojure, too.  Latest clojure-
> contrib might not work with clojure 1.0.0.
>
> Andy
>
> >

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

Clojure Code Style

[Sean Devlin]

Hello Clojurians,
I've been experimenting with different coding styles, and I'm
interested in the group's opinion. Which set of code is easiest to
read?

A)  Traditional definition

(defn str->date-map
  [input-string]
  ((trans :month (comp dec :month))
   (apply hash-map (interleave
[:month :day :year]
(map parse-int (re-split input-string #"/"))

B)  Functional Composition

(def str->date-map
 (comp (trans :month (comp dec :month))
   (partial apply hash-map)
   (partial interleave [:month :day :year])
   (partial map parse-int)
   #(re-split % #"/"))

C)  Perl's Revenge

(def $ partial)
(def & comp)

(def str->date-map
 (& (trans :month (& dec :month))
   ($ apply hash-map)
   ($ interleave [:month :day :year])
   ($ map parse-int)
   #(re-split % #"/"))

Let me know what you all think!
--~--~-~--~~~---~--~~
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: Newbie with problems building clojure-contrib

[Andy Fingerhut]

Oh, one more thing.  If you have latest git clojure-contrib, I'd
recommend trying it with latest git clojure, too.  Latest clojure-
contrib might not work with clojure 1.0.0.

Andy

--~--~-~--~~~---~--~~
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: Newbie with problems building clojure-contrib

[Andy Fingerhut]

I've got a Mac and I've set it up to run jvm 1.6.0 instead of 1.5.0,
but I think I've done it with 1.5.0 before, too.  You should be fine
there.  Also I have ant version 1.7.1, but again, probably not a show
stopper difference.

I put my clojure-contrib in a directory "beside" my clojure directory,
instead of within it, and I gave a full absolute path name (e.g. /
Users/andy/clojure/clojure-1.0.0.jar) instead of a relative path name
when I built clojure-contrib.  I'd recommend trying that and see if it
makes any difference for you.

Andy

--~--~-~--~~~---~--~~
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: Can Clojure be as fast as Java?

[John Harrop]

On Wed, Aug 12, 2009 at 5:25 AM, Piyush Ranjan  wrote:

> This is a troll question. I have seen similar questions posted on other
> forums about languages like ruby, CL, Haskell, Prolog, C, C++, fortran,
> bigloo(?) etc by the same poster.


Hmm. fft1976 = WrexSoul?

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

Newbie with problems building clojure-contrib

[Barry Perryman]

I'm new to clojure and I haven't touched the java platform for longer
than I can remember, and I'm having a little difficulty building
clojure-contrib.

I've made a software/clojure folder, and installed clojure 1.0
release. Under that folder I have made a clojure-contrib folder, and
got the latest code off github, and put it there.

When I try and build I get an error about walk.clj/walk__init.class
not being in the class path.

I've pasted what my mac system reports at the end, does anybody know
what I'm doing wrong?

Thanks

Barry

   $ java -version
   java version "1.5.0_19"
   Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-
b02-304)
   Java HotSpot(TM) Client VM (build 1.5.0_19-137, mixed mode,
sharing)

   $ ant -version
   Apache Ant version 1.7.0 compiled on May 21 2009

   $ ant
   Buildfile: build.xml

   init:

   check_hasclojure:
 [echo] WARNING: You have not defined a path to clojure.jar so I
can't compile files.
 [echo]   This will cause some parts of clojure.contrib not to
work (e.g., pretty print).
 [echo]   To enable compiling, run "ant -Dclojure.jar=<...path
to clojure.jar..>"
 [echo]

 compile_clojure:

 jar:

 BUILD SUCCESSFUL
 Total time: 0 seconds


   $ ant -Dclojure.jar=../clojure-1.0.0.jar
   Buildfile: build.xml

   init:

   check_hasclojure:

   compile_clojure:
 [java] Compiling clojure.contrib.accumulators to /Users/barry/
software/clojure/clojure-contrib/classes
 [java] Compiling clojure.contrib.agent-utils to /Users/barry/
software/clojure/clojure-contrib/classes
 [java] Compiling clojure.contrib.classpath to /Users/barry/
software/clojure/clojure-contrib/classes
 [java] Compiling clojure.contrib.combinatorics to /Users/barry/
software/clojure/clojure-contrib/classes
 [java] Compiling clojure.contrib.command-line to /Users/barry/
software/clojure/clojure-contrib/classes
 [java] Compiling clojure.contrib.complex-numbers to /Users/barry/
software/clojure/clojure-contrib/classes
 [java] Compiling clojure.contrib.cond to /Users/barry/software/
clojure/clojure-contrib/classes
 [java] Compiling clojure.contrib.condition to /Users/barry/
software/clojure/clojure-contrib/classes
 [java] Compiling clojure.contrib.core to /Users/barry/software/
clojure/clojure-contrib/classes
 [java] Compiling clojure.contrib.dataflow to /Users/barry/
software/clojure/clojure-contrib/classes
 [java] java.io.FileNotFoundException: Could not locate clojure/
walk__init.class or clojure/walk.clj on classpath:  (dataflow.clj:17)

   Long stack trace removed...

--~--~-~--~~~---~--~~
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: Pure-functional N-body benchmark implementation

[Aaron Cohen]

On Wed, Aug 12, 2009 at 4:49 PM, Aaron Cohen wrote:
> I'm getting a very significant performance improvement by adding a
> couple of JVM parameters (using jdk 1.6.0_14).  They are:
> -XX:+DoEscapeAnalysis
> -XX:+UseBiasedLocking (I think the -server flag is required for those
> two flags to do anything).
>
> My runtime with n = 5,000,000 goes from ~7.5 seconds to ~4.5 seconds.
>
> I can't currently check whether the java code gets the same
> performance boost, but it's possible and even likely that the clojure
> version would see a better improvement from those parameters than the
> java one.
>

I actually just confirmed that, on my computer at least, those flags
have basically no effect on the java version and a big difference on
the clojure one.

--~--~-~--~~~---~--~~
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: Can Clojure be as fast as Java?

[Chouser]

On Wed, Aug 12, 2009 at 4:36 PM, fft1976 wrote:
> On Aug 12, 2:25 am, Piyush Ranjan  wrote:
>> This is a troll question. I have seen similar questions posted on other
>> forums about languages like ruby, CL, Haskell, Prolog, C, C++, fortran,
>> bigloo(?) etc by the same poster.
>>
>> Try this link:http://www.google.co.in/search?q=fft1976%40gmail.com

I'm sure this was meant to be helpful, but rather than using
derogatory labels it's probably best to ignore any post that
feels like it may be a troll.

>
> This may be hard for those like you to fathom

Please stop.  This is a personal attack and is unwelcome,
regardless of whether you feel your post was unfairly
maligned.

--Chouser

--~--~-~--~~~---~--~~
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: Can Clojure be as fast as Java?

[fft1976]

On Aug 12, 2:25 am, Piyush Ranjan  wrote:
> This is a troll question. I have seen similar questions posted on other
> forums about languages like ruby, CL, Haskell, Prolog, C, C++, fortran,
> bigloo(?) etc by the same poster.
>
> Try this link:http://www.google.co.in/search?q=fft1976%40gmail.com

This may be hard for those like you to fathom, but for the kind of
things I do, I often care about both speed and productivity, and I
know all these languages (Ruby not so much) and then some: Python,
Scheme, ML dialects. Bigloo is a Scheme dialect.I know some Prolog,
but I don't recall discussing its speed.

I also recommend Clojure to people on USENET, when it seems like it
would be a good fit for them (the poster hadn't heard of Clojure
before):

http://groups.google.com/group/comp.lang.functional/msg/ed7c2f0a64abfe3a

Not everyone who says something difficult for you to mentally relate
to is actually trolling. (I am also an opponent of outsourcing, so
perhaps that's what really ticked you off in my posting history?!

http://groups.google.com/group/comp.lang.c++/msg/f439506b6c9d102e

Sorry about that, but I think good programmers are 100x more
productive than mediocre semi-trained ones, so outsourcing only makes
sense to silly PHBs)

--~--~-~--~~~---~--~~
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: Pure-functional N-body benchmark implementation

[Aaron Cohen]

I'm getting a very significant performance improvement by adding a
couple of JVM parameters (using jdk 1.6.0_14).  They are:
-XX:+DoEscapeAnalysis
-XX:+UseBiasedLocking (I think the -server flag is required for those
two flags to do anything).

My runtime with n = 5,000,000 goes from ~7.5 seconds to ~4.5 seconds.

I can't currently check whether the java code gets the same
performance boost, but it's possible and even likely that the clojure
version would see a better improvement from those parameters than the
java one.

--~--~-~--~~~---~--~~
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: Clojure, Java JIT, and inlining

[Chouser]

On Wed, Aug 12, 2009 at 3:03 PM, Andy
Fingerhut wrote:
>
> My apologies for the noise if this is well known in the Clojure
> community, but I'll ask anyway.
>
> One of the tweaks to my Clojure benchmarks that people have suggested
> for improving performance, and that does help, is changing some
> function definitions to macros.  This is in effect inlining those
> functions at the source level, so the Clojure compiler has a shot at
> it.
>
> Is there some reason that the Java JIT is not doing this, with the
> original code using defn, as fast as it works when using defmacro?

I think inlining via Clojure macro or :inline has the most
benefit when it allows you to avoid boxing arguments and
return values.  That is, if you have primitive locals in the
calling function and primitive locals in the called
function, the Java method signatures created by the Clojure
compiler will still be Objects and require boxing and
unboxing for each invocation.

I don't know for sure, but it appears HotSpot doesn't
(usually? ever?) remove that un/boxing when inlining.

Using a Clojure macro or :inline metadata allows the Clojure
compiler to use the same local primitives with no boxing or
unboxing.

--Chouser

--~--~-~--~~~---~--~~
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: Clojure, Java JIT, and inlining

[Aaron Cohen]

On Wed, Aug 12, 2009 at 4:24 PM, Richard Newman wrote:
>
>> I may be wrong, but doesn't a typical function invocation involve
>> dereferencing the Var holding the object that implements "IFn" and
>> calling invoke?  It seems pretty intuitive to me that this would be
>> difficult to inline by the JIT, there is a little bit of
>> synchronization going on every time a Var is dereferenced.
>
> In principle, the JIT can inline the Var lookup, and do the
> appropriate analysis to eliminate much of the work -- Vars have thread-
> local bindings, so the JVM should be pretty well aware of access and
> scope. Of course, this will only happen if everything is small enough,
> frequently used, etc. etc.
>
> I saw a presentation at JavaOne which illustrated to just what extent
> the dynamic compiler can eliminate locks, allocations, aliases,
> synchronization boundaries, do closed-world analysis of class
> hierarchies, and so on. It's pretty impressive. ("Inside Out: A Modern
> Virtual Machine Revealed", if you're interested.)
>

I don't think Vars are thread-local.  They're one of the shared
mutable state primitives.  They can be defacto thread local if only
used by a single thread but you need a "sufficiently smart compiler"
to notice that.

Hotspot definitely is smart enough in some cases, but I think for
Escape Analysis you currently need a black magic command line
parameter.  I'm playing around with: "-XX:+DoEscapeAnalysis
-XX:+UseBiasedLocking" with inconsistant results.

--~--~-~--~~~---~--~~
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: Clojure, Java JIT, and inlining

[Richard Newman]

> I may be wrong, but doesn't a typical function invocation involve
> dereferencing the Var holding the object that implements "IFn" and
> calling invoke?  It seems pretty intuitive to me that this would be
> difficult to inline by the JIT, there is a little bit of
> synchronization going on every time a Var is dereferenced.

In principle, the JIT can inline the Var lookup, and do the  
appropriate analysis to eliminate much of the work -- Vars have thread- 
local bindings, so the JVM should be pretty well aware of access and  
scope. Of course, this will only happen if everything is small enough,  
frequently used, etc. etc.

I saw a presentation at JavaOne which illustrated to just what extent  
the dynamic compiler can eliminate locks, allocations, aliases,  
synchronization boundaries, do closed-world analysis of class  
hierarchies, and so on. It's pretty impressive. ("Inside Out: A Modern  
Virtual Machine Revealed", if you're interested.)

-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: Clojure, Java JIT, and inlining

[Chas Emerick]

On Aug 12, 2009, at 3:59 PM, Richard Newman wrote:

>> Is there some reason that the Java JIT is not doing this, with the
>> original code using defn, as fast as it works when using defmacro?
>
> The macro expands into bytecode within the same Java method, rather
> than a method invocation. Some method blocks are too big to inline,
> and perhaps the JIT doesn't have enough information (or motivation) to
> do so.

To emphasize: since many common clojure forms are macros themselves,  
the fns you're writing are likely much larger than you think they  
are.  Simple things like doseq (nevermind more complicated stuff like  
for) expand into sizable chunks of clojure, which are themselves doing  
way more work per LOC than typical Java methods.  Thus, I'll bet  
typical clojure fns exceed whatever code-size windows the JIT has in  
mind for inlining far more often than Java methods.

...even 'and' results in more code than you'd likely expect intuitively:

user=> (use 'clojure.contrib.walk)
nil
user=> (macroexpand-all '(and a b c))
(let*
  [and__3314__auto__ a]
  (if
   and__3314__auto__
   (let*
[and__3314__auto__ b]
(if and__3314__auto__ c and__3314__auto__))
   and__3314__auto__))

- 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: Clojure, Java JIT, and inlining

[Aaron Cohen]

On Wed, Aug 12, 2009 at 3:59 PM, Richard Newman wrote:
>
>> Is there some reason that the Java JIT is not doing this, with the
>> original code using defn, as fast as it works when using defmacro?
>
> The macro expands into bytecode within the same Java method, rather
> than a method invocation. Some method blocks are too big to inline,
> and perhaps the JIT doesn't have enough information (or motivation) to
> do so. The JIT compiler will only inline certain hotspots where it
> predicts a benefit. Switching to a macro forces the issue by avoiding
> that runtime analysis altogether.
>
> It's also possible that more type propagation, or elimination of
> boxing (all function parameters are boxed when they cross the function
> boundary) is involved.
>
> I'm sure others will have more to add...
>

I may be wrong, but doesn't a typical function invocation involve
dereferencing the Var holding the object that implements "IFn" and
calling invoke?  It seems pretty intuitive to me that this would be
difficult to inline by the JIT, there is a little bit of
synchronization going on every time a Var is dereferenced.

I think this is why a "let local" variable is faster than def'ing a
*constant* and referencing it.  Methods like AtomicInteger.get start
showing up in the profiler when I use *constants* in tight loops at
least.

Hotspot is notoriously difficult for us to intuit about, so take this
all with a grain of salt.

--~--~-~--~~~---~--~~
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: Clojure, Java JIT, and inlining

[Richard Newman]

> Is there some reason that the Java JIT is not doing this, with the
> original code using defn, as fast as it works when using defmacro?

The macro expands into bytecode within the same Java method, rather  
than a method invocation. Some method blocks are too big to inline,  
and perhaps the JIT doesn't have enough information (or motivation) to  
do so. The JIT compiler will only inline certain hotspots where it  
predicts a benefit. Switching to a macro forces the issue by avoiding  
that runtime analysis altogether.

It's also possible that more type propagation, or elimination of  
boxing (all function parameters are boxed when they cross the function  
boundary) is involved.

I'm sure others will have more to add...

--~--~-~--~~~---~--~~
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: Parsing XML containing UTF8 with clojure.xml/parse

[Richard Newman]

> However, I get the feeling Clojure is not the problem.
> I noticed, I forgot the "UTF-8" on the *output*. beh..
> Now, Vim seems to be happy with the file.

I had a similar issue -- every Java component (e.g., Nailgun, which  
VimClojure uses) needs to be started with the right character set.

http://www.holygoat.co.uk/blog/entry/2009-07-22-1

--~--~-~--~~~---~--~~
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: Augmenting the defn attr-map

[Chas Emerick]

On Aug 12, 2009, at 3:19 PM, Mark Volkmann wrote:

> I didn't release it was valid to define names with colons in them.
> Maybe that shouldn't be allowed. I'd like to be able to specify type
> hints using UML-like syntax like the second example from Chas which
> was
>
> (defh foo [s:String unhinted-arg {a:int :a}] ...)

I *really* like the look of s:String (or String:s, which I used in my  
quickie impl, they're interchangable), but I can easily see colons  
being used for some other syntactic purpose down the road that we're  
not yet aware of (ranges come to mind, eg. [0:50] as in python).  And  
of course, colons and other special characters are very helpful in  
representing domain-specific semantics directly in code, so losing  
those special characters is an expensive choice that should be weighed  
very cautiously.

- 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: Augmenting the defn attr-map

[Chas Emerick]

On Aug 12, 2009, at 2:02 PM, tsuraan wrote:

> I didn't put it in yet, but I was thinking of just having nil in the
> type vector for unhinted variables, so you could have
>
> (defn foo {:signature [ String String nil ]} [ a b c ] ...)
>
> and then c wouldn't be hinted.  I hadn't thought of destructuring at
> all; I'm guessing that it could be done with

I'd think _ would be more idiomatic for those that like the haskell- 
esque style...?

> (defn foo {:signature [{:bar Mytype} nil nil nil]} [{blah :foo mt-obj
> :bar} a b c] ...)
>
> but that's getting pretty ugly on its own.  I'm not sure if it would
> be a win to try to do anything fancy like that.  I'm also not sure
> what the destructuring assignment syntax is for maps right now, so
> what I wrote might be total nonsense, syntactically.  I hope the idea
> is clear, anyhow.

Yeah, I think supporting a parallel argument specification is probably  
not tenable.  On the other hand, performing a relatively simple  
transformation to a set of destructuring forms is probably pretty  
straightforward -- I don't even think :as, :keys, etc would require  
any special treatment.

>> - The thing I don't like about the current type hints is (IMO) the
>> distracting quality of '#^'.  What about something like:
>>
>> (defh foo [String:s unhinted-arg {int:a :a}] ...) or
>> (defh foo [s:String unhinted-arg {a:int :a}] ...)
>>
>> That's far more visually-appealing to me, and has the nice advantages
>> of being inline in the case of destructuring and supporting sparse
>> hinting easily.  I'll bet the macro would end up being pretty simple,
>> as well.
>
> I'd hate to see somebody do it, but it's currently valid to define
> variables with colons in them, so there could be code out in the wild
> with those definition forms already.  Other than that, I like the
> looks of it.  I think the macro would be easy as well, so long as
> you're comfortable munging variable names :)

Well, that's one benefit/motivation to just have another def form,  
rather than trying to make defn support everyone's preferred variation/ 
style.

I knocked out a quickie implementation that appears to work with the  
couple of use cases I've thrown at it so far (pasted at the end of  
this msg).

Just a little exposition:

com.snowtide.clojure.utils=> (binding [*print-meta* true]
(prn (macroexpand '(deft a [Long:a b  
{[Integer:c] :c} {:keys [Double:d]}] (+ a b c d)
(def #^{:arglists (quote ([#^Long a b {[#^Integer c] :c} {:keys  
[#^Double d]}]))} a (clojure.core/fn ([#^Long a b {[#^Integer c] :c}  
{:keys [#^Double d]}] #^{:line 159} (+ a b c d

I *think* I've gotten the :tag metadata right (which I've burned  
myself on before, e.g. putting Class objects in :tag slots instead of  
symbols, etc), as this fn compiles without reflection warnings:

(deft a
   [String:b [Double:c :as java.util.List:list] {java.util.Random:d :d}]
   (.toCharArray b)
   (.size list)
   (.floatValue c)
   (.nextInt d))

A couple of nice things about this:

- it doesn't interfere with 'normal' type hints (e.g. #^Foo and Foo:b  
can coexist in the same declaration if you want to be silly about  
things)

- I think this kind of hinting could be bolted right into the existing  
destructuring functionality if Rich were so inclined (though I  
wouldn't bet on that).  This would allow you to use Foo:bar hints in  
any binding-form (e.g. let, fn, for, etc etc).

Cheers,

- Chas

---
(defn- decorate-hinted-symbol
   [sym]
   (let [[type arg] (.split (name sym) ":")]
 (if arg
   (with-meta (symbol arg) {:tag (symbol type)})
   sym)))

(defn- decorate-hinted-args
   [args]
   (cond
 (vector? args) (vec (map decorate-hinted-args args))
 (map? args) (into {} (map decorate-hinted-args args))
 (symbol? args) (decorate-hinted-symbol args)
 (keyword? args) args
 :else (throw (Exception. (str args)

(defmacro deft
   [name args & body]
   `(defn ~name
  ~(decorate-hinted-args args)
  ~...@body))

--~--~-~--~~~---~--~~
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: Augmenting the defn attr-map

[Mark Volkmann]

I didn't release it was valid to define names with colons in them.
Maybe that shouldn't be allowed. I'd like to be able to specify type
hints using UML-like syntax like the second example from Chas which
was

(defh foo [s:String unhinted-arg {a:int :a}] ...)

On Wed, Aug 12, 2009 at 1:02 PM, tsuraan wrote:
>
>> - There's already a lot of moving parts to type hinting, so adding
>> this optional approach into defn seems like it'd lead to unintended
>> consequences.  That said, there's absolutely nothing wrong with an
>> alternative def form (defh? as in 'define hinted fn') -- there's
>> plenty of them throughout contrib and elsewhere.
>
> Yeah, I tried to slip my change into a place in defn that probably
> wouldn't hurt anything, but I'm still not sure what the full
> consequences of my change are.  I'm far from a clojure expert :)
>
>> - Remember destructuring, and along with that, one of the nice thing
>> about in-place hints, as opposed to a separate definition of expected
>> types, is that the definitions can be sparse, e.g.:
>>
>> (defn foo [{blah :foo #^MyType mt-obj :bar} a b c] ...)
>>
>> It doesn't look like your macro supports hinting destructured args
>> (understandably enough, doing so given the :signatures approach would
>> likely be very difficult).
>
> I didn't put it in yet, but I was thinking of just having nil in the
> type vector for unhinted variables, so you could have
>
> (defn foo {:signature [ String String nil ]} [ a b c ] ...)
>
> and then c wouldn't be hinted.  I hadn't thought of destructuring at
> all; I'm guessing that it could be done with
>
> (defn foo {:signature [{:bar Mytype} nil nil nil]} [{blah :foo mt-obj
> :bar} a b c] ...)
>
> but that's getting pretty ugly on its own.  I'm not sure if it would
> be a win to try to do anything fancy like that.  I'm also not sure
> what the destructuring assignment syntax is for maps right now, so
> what I wrote might be total nonsense, syntactically.  I hope the idea
> is clear, anyhow.
>
>> - The thing I don't like about the current type hints is (IMO) the
>> distracting quality of '#^'.  What about something like:
>>
>> (defh foo [String:s unhinted-arg {int:a :a}] ...) or
>> (defh foo [s:String unhinted-arg {a:int :a}] ...)
>>
>> That's far more visually-appealing to me, and has the nice advantages
>> of being inline in the case of destructuring and supporting sparse
>> hinting easily.  I'll bet the macro would end up being pretty simple,
>> as well.
>
> I'd hate to see somebody do it, but it's currently valid to define
> variables with colons in them, so there could be code out in the wild
> with those definition forms already.  Other than that, I like the
> looks of it.  I think the macro would be easy as well, so long as
> you're comfortable munging variable names :)

-- 
R. Mark Volkmann
Object Computing, Inc.

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

Clojure, Java JIT, and inlining

[Andy Fingerhut]

My apologies for the noise if this is well known in the Clojure
community, but I'll ask anyway.

One of the tweaks to my Clojure benchmarks that people have suggested
for improving performance, and that does help, is changing some
function definitions to macros.  This is in effect inlining those
functions at the source level, so the Clojure compiler has a shot at
it.

Is there some reason that the Java JIT is not doing this, with the
original code using defn, as fast as it works when using defmacro?

Perhaps some JITs do inlining, but cannot do it as well as a defn ->
defmacro change permits?

Is it because of some kind of function call/return overhead that the
JIT cannot eliminate?

Thanks,
Andy
--~--~-~--~~~---~--~~
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: Augmenting the defn attr-map

[tsuraan]

> - There's already a lot of moving parts to type hinting, so adding
> this optional approach into defn seems like it'd lead to unintended
> consequences.  That said, there's absolutely nothing wrong with an
> alternative def form (defh? as in 'define hinted fn') -- there's
> plenty of them throughout contrib and elsewhere.

Yeah, I tried to slip my change into a place in defn that probably
wouldn't hurt anything, but I'm still not sure what the full
consequences of my change are.  I'm far from a clojure expert :)

> - Remember destructuring, and along with that, one of the nice thing
> about in-place hints, as opposed to a separate definition of expected
> types, is that the definitions can be sparse, e.g.:
>
> (defn foo [{blah :foo #^MyType mt-obj :bar} a b c] ...)
>
> It doesn't look like your macro supports hinting destructured args
> (understandably enough, doing so given the :signatures approach would
> likely be very difficult).

I didn't put it in yet, but I was thinking of just having nil in the
type vector for unhinted variables, so you could have

(defn foo {:signature [ String String nil ]} [ a b c ] ...)

and then c wouldn't be hinted.  I hadn't thought of destructuring at
all; I'm guessing that it could be done with

(defn foo {:signature [{:bar Mytype} nil nil nil]} [{blah :foo mt-obj
:bar} a b c] ...)

but that's getting pretty ugly on its own.  I'm not sure if it would
be a win to try to do anything fancy like that.  I'm also not sure
what the destructuring assignment syntax is for maps right now, so
what I wrote might be total nonsense, syntactically.  I hope the idea
is clear, anyhow.

> - The thing I don't like about the current type hints is (IMO) the
> distracting quality of '#^'.  What about something like:
>
> (defh foo [String:s unhinted-arg {int:a :a}] ...) or
> (defh foo [s:String unhinted-arg {a:int :a}] ...)
>
> That's far more visually-appealing to me, and has the nice advantages
> of being inline in the case of destructuring and supporting sparse
> hinting easily.  I'll bet the macro would end up being pretty simple,
> as well.

I'd hate to see somebody do it, but it's currently valid to define
variables with colons in them, so there could be code out in the wild
with those definition forms already.  Other than that, I like the
looks of it.  I think the macro would be easy as well, so long as
you're comfortable munging variable names :)

--~--~-~--~~~---~--~~
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: Augmenting the defn attr-map

[Chas Emerick]

This is an interesting path to take.  I'm not at all familiar with  
haskell, but a couple of thoughts anyway :-) :

- There's already a lot of moving parts to type hinting, so adding  
this optional approach into defn seems like it'd lead to unintended  
consequences.  That said, there's absolutely nothing wrong with an  
alternative def form (defh? as in 'define hinted fn') -- there's  
plenty of them throughout contrib and elsewhere.

- Remember destructuring, and along with that, one of the nice thing  
about in-place hints, as opposed to a separate definition of expected  
types, is that the definitions can be sparse, e.g.:

(defn foo [{blah :foo #^MyType mt-obj :bar} a b c] ...)

It doesn't look like your macro supports hinting destructured args  
(understandably enough, doing so given the :signatures approach would  
likely be very difficult).

- The thing I don't like about the current type hints is (IMO) the  
distracting quality of '#^'.  What about something like:

(defh foo [String:s unhinted-arg {int:a :a}] ...) or
(defh foo [s:String unhinted-arg {a:int :a}] ...)

That's far more visually-appealing to me, and has the nice advantages  
of being inline in the case of destructuring and supporting sparse  
hinting easily.  I'll bet the macro would end up being pretty simple,  
as well.

Cheers,

- Chas

On Aug 12, 2009, at 12:37 PM, tsuraan wrote:

>
> I'd like to add a :signature entry to the attr-map of defn, that
> provides a haskell-style type signature to functions of the
> single-arglist-body form.  I find the the normal way of providing
> hints to a function:
>
> (defn [ #^Class1 var1 #^Class2 var2 #^Class3 var3] ... )
>
> is way too noisy, and the variables get lost between the types.  What
> I'd like instead is to be able to specify the signature in the
> function metadata:
>
> (defn {:signature [ Class1 Class2 Class3 ReturnType ]}
>  [ var1 var2 var3 ]
>  ...)
>
> I've written a little patch to defn that annotates the arguments
> correctly (I think).  I'm not sure where the metadata for marking up a
> function's return type goes (Is it on the (cons `fn fdecl) part?), but
> it probably wouldn't be hard if I knew what I was doing :)
>
> Anyhow, a revised defn (I've called it defn+ to avoid clashes) is as  
> follows:
>
> (defn zip [ a b ] (map vector a b))
> (def
>
> #^{:doc "Same as (def name (fn [params* ] exprs*)) or (def
>name (fn ([params* ] exprs*)+)) with any doc-string or attrs added
>to the var metadata"
>:arglists '([name doc-string? attr-map? [params*] body]
>[name doc-string? attr-map? ([params*] body)+ attr- 
> map?])}
> defn+ (fn defn+ [name & fdecl]
>(let [m (if (string? (first fdecl))
>  {:doc (first fdecl)}
>  {})
>  fdecl (if (string? (first fdecl))
>  (next fdecl)
>  fdecl)
>  m (if (map? (first fdecl))
>  (conj m (first fdecl))
>  m)
>  fdecl (if (map? (first fdecl))
>  (next fdecl)
>  fdecl)
>  fdecl (if (vector? (first fdecl))
>  (if (:signature m)
>; we'll apply the types in the signature  
> vector as the
>; :tag metadata for each argument
>(list
>  (cons
>(apply vector
>  (for [[ tag var ]
>(zip (:signature m) (first fdecl))]
>(with-meta var {:tag tag})))
>(rest fdecl)))
>(list fdecl))
>  fdecl)
>  m (if (map? (last fdecl))
>  (conj m (last fdecl))
>  m)
>  fdecl (if (map? (last fdecl))
>  (butlast fdecl)
>  fdecl)
>  m (conj {:arglists (list 'quote (sigs fdecl))} m)]
>  (list 'def (with-meta name (conj (if (meta name) (meta  
> name) {}) m))
>(cons `fn fdecl)
>
> (. (var defn+) (setMacro))
>
> Is this something that people would think is worthwhile?  I really
> prefer haskell's type signatures to clojure's inline hints, but maybe
> it's just something that people get used to.  Anyhow, my first attempt
> at macro hacking, so kind criticism would also be welcome w.r.t.
> style, correctness, etc.
>
> >


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

Augmenting the defn attr-map

[tsuraan]

I'd like to add a :signature entry to the attr-map of defn, that
provides a haskell-style type signature to functions of the
single-arglist-body form.  I find the the normal way of providing
hints to a function:

(defn [ #^Class1 var1 #^Class2 var2 #^Class3 var3] ... )

is way too noisy, and the variables get lost between the types.  What
I'd like instead is to be able to specify the signature in the
function metadata:

(defn {:signature [ Class1 Class2 Class3 ReturnType ]}
  [ var1 var2 var3 ]
  ...)

I've written a little patch to defn that annotates the arguments
correctly (I think).  I'm not sure where the metadata for marking up a
function's return type goes (Is it on the (cons `fn fdecl) part?), but
it probably wouldn't be hard if I knew what I was doing :)

Anyhow, a revised defn (I've called it defn+ to avoid clashes) is as follows:

(defn zip [ a b ] (map vector a b))
(def

 #^{:doc "Same as (def name (fn [params* ] exprs*)) or (def
name (fn ([params* ] exprs*)+)) with any doc-string or attrs added
to the var metadata"
:arglists '([name doc-string? attr-map? [params*] body]
[name doc-string? attr-map? ([params*] body)+ attr-map?])}
 defn+ (fn defn+ [name & fdecl]
(let [m (if (string? (first fdecl))
  {:doc (first fdecl)}
  {})
  fdecl (if (string? (first fdecl))
  (next fdecl)
  fdecl)
  m (if (map? (first fdecl))
  (conj m (first fdecl))
  m)
  fdecl (if (map? (first fdecl))
  (next fdecl)
  fdecl)
  fdecl (if (vector? (first fdecl))
  (if (:signature m)
; we'll apply the types in the signature vector as the
; :tag metadata for each argument
(list
  (cons
(apply vector
  (for [[ tag var ]
(zip (:signature m) (first fdecl))]
(with-meta var {:tag tag})))
(rest fdecl)))
(list fdecl))
  fdecl)
  m (if (map? (last fdecl))
  (conj m (last fdecl))
  m)
  fdecl (if (map? (last fdecl))
  (butlast fdecl)
  fdecl)
  m (conj {:arglists (list 'quote (sigs fdecl))} m)]
  (list 'def (with-meta name (conj (if (meta name) (meta name) {}) m))
(cons `fn fdecl)

(. (var defn+) (setMacro))

Is this something that people would think is worthwhile?  I really
prefer haskell's type signatures to clojure's inline hints, but maybe
it's just something that people get used to.  Anyhow, my first attempt
at macro hacking, so kind criticism would also be welcome w.r.t.
style, correctness, etc.

--~--~-~--~~~---~--~~
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: Clojure Ant Tasks

[J. McConnell]

On Mon, Aug 10, 2009 at 9:07 AM, Chas Emerick  wrote:

>
> We have a couple of ant macros that do all of our clojure building for us
> (including auto-detecting namespaces within source directories, compiling
> only those clojure files that have changed since the last build, etc).
>

I've added support for the latter feature. Unfortunately, it doesn't support
transitive dependencies yet. But, hopefully I'll be able to get to that
soon, or maybe I'll just take the conditional compilation out until I can.

Regards,

- J.

--~--~-~--~~~---~--~~
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: Clojure Ant Tasks

[J. McConnell]

On Wed, Aug 12, 2009 at 4:00 AM, C. Florian Ebeling <
florian.ebel...@gmail.com> wrote:

>
> Thanks for sharing this. What I miss a bit is the ability to set the
> *compile-path* to something other than "classes".


Thanks for your input! Yes, this was always planned, I just didn't have a
need for it. Anyway, I've just pushed this change to github, so the compile
task now takes a "compilePath" attribute, which will default to "classes".


> And might it be a
> good idea to be able to name .clj files instead of namespaces as an
> option? Then one could use regular ant filesets constucted
> automatically from expressions, instead of naming namespaces
> individually.


Sure. I think I'd like to still offer the option of specifying namespaces,
but taking a fileset in place of or in addition to a list of namespaces
would be a good idea. I've added an issue for this in GitHub so I don't lose
track of it. Feel free to create bugs, feature requests, etc. there if you
like (though here works fine as well). Here's the ticket:

http://github.com/jmcconnell/clojure-ant-tasks/issues#issue/1

Regards,

- J.

--~--~-~--~~~---~--~~
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: Parsing XML containing UTF8 with clojure.xml/parse

[Meikel Brandmeyer]

Hi,

On Aug 12, 4:30 pm, B Smith-Mannschott  wrote:

> Please post code. Show us what you are trying to do, so we can help
> instead of just guessing.

I have a file which looks roughly like this:



In fact things are more complicated, but also happens
when I change the file to the above form. Unfortunately
I cannot share the failing file, since this is confidential
information of my company.

However, I get the feeling Clojure is not the problem.
I noticed, I forgot the "UTF-8" on the *output*. beh..
Now, Vim seems to be happy with the file.

This leads me to the conclusions, that
a) Stephen's link above was solving the problem and
b) Excel is terribly annoying.

Off-topic: can I import UTF-8 CSVs in Excel?

Sorry for the noise and many thanks for your and
Stephen's efforts.

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

Clojure Math

[Jeff Brown]

Calculating probabilities with Clojure...

http://javajeff.blogspot.com/2009/07/grails-springsource-and-clojure.html
I welcome any clever solutions you might want to contribute in Clojure.

The problem is intentionally loosely defined (exactly 3? at least 3?
etc...).  The goal isn't to have a clearly defined problem and find the
solution.  The goal is to have some math fun with Clojure.

I found Weiqi's analysis at
http://www.weiqigao.com/blog/2009/08/03/jeff_browns_probability_quiz_what_are_the_chances.htmlinteresting.



Jeff

-- 
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.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: Parsing XML containing UTF8 with clojure.xml/parse

[B Smith-Mannschott]

On Wed, Aug 12, 2009 at 16:22, Meikel Brandmeyer wrote:
>
> Hi Stephen,
>
> On Aug 12, 3:57 pm, "Stephen C. Gilardi"  wrote:
>> > I have to parse some XML files with c.x/parse. However the files
>> > contain UTF-8 characters, which end up as '?' after being parsed by
>> > c.x/parse. Is there some possibility to correctly parse the files? I
>> > suspect there is some settings somewhere in my Clojure/JVM/System
>> > which makes the whole thing fail, but I have no clue how to find out
>> > where to look...
>
>> Does this help get you going:
>>
>>        http://groups.google.com/group/clojure/msg/0f6dc9ec66b852fe
>
> Thanks for the tip. Unfortunately, it doesn't help. Now everything is
> completely chopped to pieces.
>
>> More generally, you should also be able to specify the encoding by
>> arranging for an InputStreamReader with a properly specified
>> "charset" (like "UTF8") to wrap your input byte source.
>
> I tried, but c.x/parse only accepts an InputStream. I didn't find
> a way to set the charset and that one...

You shouldn't have to. XML is funny that way:

InputStream is a stream of *bytes*, not characters. XML will try to
parse as UTF-8 if it doesn't find a  header specifying
some other encoding. So, in your case it should "just work" unless the
files I believe to be UTF-8 aren't actually UTF-8.

// 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: Parsing XML containing UTF8 with clojure.xml/parse

[B Smith-Mannschott]

Hi Meikel,

On Wed, Aug 12, 2009 at 10:16, Meikel Brandmeyer wrote:
>
> Dear Clojurians,
>
> I have to parse some XML files with c.x/parse. However the files
> contain UTF-8 characters, which end up as '?' after being parsed by
> c.x/parse. Is there some possibility to correctly parse the files? I
> suspect there is some settings somewhere in my Clojure/JVM/System
> which makes the whole thing fail, but I have no clue how to find out
> where to look...

Please post code. Show us what you are trying to do, so we can help
instead of just guessing.

// 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: Parsing XML containing UTF8 with clojure.xml/parse

[Meikel Brandmeyer]

Hi Stephen,

On Aug 12, 3:57 pm, "Stephen C. Gilardi"  wrote:
> > I have to parse some XML files with c.x/parse. However the files
> > contain UTF-8 characters, which end up as '?' after being parsed by
> > c.x/parse. Is there some possibility to correctly parse the files? I
> > suspect there is some settings somewhere in my Clojure/JVM/System
> > which makes the whole thing fail, but I have no clue how to find out
> > where to look...

> Does this help get you going:
>
>        http://groups.google.com/group/clojure/msg/0f6dc9ec66b852fe

Thanks for the tip. Unfortunately, it doesn't help. Now everything is
completely chopped to pieces.

> More generally, you should also be able to specify the encoding by  
> arranging for an InputStreamReader with a properly specified  
> "charset" (like "UTF8") to wrap your input byte source.

I tried, but c.x/parse only accepts an InputStream. I didn't find
a way to set the charset and that one...

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: Parsing XML containing UTF8 with clojure.xml/parse

[Stephen C. Gilardi]

I have to parse some XML files with c.x/parse. However the files
contain UTF-8 characters, which end up as '?' after being parsed by
c.x/parse. Is there some possibility to correctly parse the files? I
suspect there is some settings somewhere in my Clojure/JVM/System
which makes the whole thing fail, but I have no clue how to find out
where to look...


Hi Meikel,

I haven't used clojure.xml yet.

Does this help get you going:

http://groups.google.com/group/clojure/msg/0f6dc9ec66b852fe

More generally, you should also be able to specify the encoding by  
arranging for an InputStreamReader with a properly specified  
"charset" (like "UTF8") to wrap your input byte source.


--Steve



smime.p7s
Description: S/MIME cryptographic signature

Uncle Bob looking for clojure help!

[Andrew Wagner]

http://blog.objectmentor.com/articles/2009/08/11/jarvis-march-in-clojure

--~--~-~--~~~---~--~~
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: Can Clojure be as fast as Java?

[tmountain]

Primitives can only be stored inside a local (i.e., a let binding).
Primitives are auto-boxed everywhere else. A type hint implies an
object (not a primitive). See this post for more info.

http://groups.google.com/group/clojure/msg/1e0d52ae931c730d

Travis

On Aug 12, 5:54 am, Tayssir John Gabbour 
wrote:
> On this topic, how do primitives work? I heard something about
> "function boundaries." Which I interpret to mean that when a function
> returns a primitive, Clojure boxes it in some Java object. And type
> declarations can't stop this boxing from happening.
>
> Is this a correct understanding? (I doubt it is, since it leads to odd
> conclusions.) And what is the performance penalty here?
>
> (I'm not personally concerned about performance, just curious.)
>
> Thanks,
> Tayssir
>
> On Aug 11, 8:55 pm, fft1976  wrote:
>
> > I feel that this question is important enough to warrant its own
> > thread.
>
> > If you use Java's arrays and declare all types, should Clojure be as
> > fast as the equivalent Java? I had taken this for granted, but
> > empirical evidence indicates otherwise:
>
> > Andy's version of the Nbody benchmark still appears to be about 10x
> > slower than Java:
>
> > Clojure:http://github.com/jafingerhut/clojure-benchmarks/blob/9dc56d8ff53f0b8...
>
> > Java (runs 21 
> > times):http://shootout.alioth.debian.org/u32/benchmark.php?test=nbody〈=j...
>
> > Why?!
--~--~-~--~~~---~--~~
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: Can Clojure be as fast as Java?

[Piyush Ranjan]

This is a troll question. I have seen similar questions posted on other
forums about languages like ruby, CL, Haskell, Prolog, C, C++, fortran,
bigloo(?) etc by the same poster.

Try this link: http://www.google.co.in/search?q=fft1976%40gmail.com


On Wed, Aug 12, 2009 at 2:00 PM, Nicolas Oury wrote:

>
> Hello all,
>
> Just wanted to add a small remark. If you look at the shootout, most
> languages considered now to be very efficient has been once said to be
> very very slow and not usable.
>
> In the eighties, functional languages were doomed to be slow and
> unusable for anything. And Ocaml/MLton and the like are now very fast.
>
> Next laziness was thought to be too slow to be practical, and now
> someone used ghc in this thread as an example of fast language.
> I think everybody remembers what was being said about java 10 years ago.
> And now java is the goal to attain.
> I even think than C and C++ where too slow to be usable at their time.
>
> Getting a compiler to produce fast code takes time and Clojure is young.
>
>  What would be more useful than this discussion would be to take
> fragments of code that looks inexplicably slow, profile them, and
> transform them by hand to be faster.
> And keep a wiki with which transformation gives which performance
> improvement.
> This could serve 3 goals:
>  - giving ideas to people on how to optimize (the doc does not contain
> every trick);
>  - allow to write ugly but very efficient macros, that can be used in
> bottlenecks ;
>  - give ideas to which code transformation performed by the compiler
> will improve performance and by how much.
>
> What is sure is that there is no reason why clojure should be slow, when
> some functional languages (including dynamically typed ones) are fast.
> So, one day, it will be fast.
>
> Best,
>
> Nicolas.
>
>
> On Tue, 2009-08-11 at 21:20 -0700, James Sofra wrote:
> > Hi fft1976,
> >
> > > If you use Java's arrays and declare all types, should Clojure be as
> > > fast as the equivalent Java?
> >
> > 
> >
> > So is the question you are trying to ask that since we have unwrapped
> > access to Java is Java code written in Clojure as fast as if it were
> > written as actual Java code?
> >
> > I guess that is a worthwhile question since it would at least tell you
> > (if you are worried about speed) whether it is worth while dropping
> > down to write actual Java code or if you can just write your Java in
> > Clojure (as unidomatic as that Clojure code may be).
> >
> > I am sorry I don't have an answer for you, just wanted to clear up the
> > question.
> >
> > Cheers,
> > 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: Clojure performance tests and clojure a little slower than Java

[Daniel]

On Wed, Aug 12, 2009 at 12:00 PM, John Harrop wrote:
> Note: the expressions should be run three or four times. The first two or
> three timings will be longer than the later ones. (JIT?) Run until the times
> are consistent and at least three repetitions have been run in rapid
> succession.

JIT usually needs some time to kick in (especially under -server).
Check if your JVM supports the following flag:
-XX:+PrintCompilation which should print JIT compilation details.

> Note 2: someone with access to disassembly/memory debugger/perf tools might
> be able to learn more by running these loops, Andy's Clojure, and Andy's C
> on their system. Disassemblies of the JIT-generated code for the Clojure
> code and of the compiled C code would be interesting to compare, in
> particular.

There was a good thread on this list some weeks ago which mentioned
another JVM flag:
-XX:+PrintOptoAssembly

The original thread:
http://groups.google.com/group/clojure/browse_thread/thread/314952431ec064b7?fwc=1

Hope this helps.

Cheers,
Daniel

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

http-agent

[Anniepoo]

using http-agent threw

(#)

notice the spelling error in 'setFixedLenghtSttreamingMode'  (Lenght)

this from the HEAD of trunk as of Aug 11 about 11pm PDT


--~--~-~--~~~---~--~~
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: Can Clojure be as fast as Java?

[Meikel Brandmeyer]

Hi,

On Aug 12, 12:44 pm, Tayssir John Gabbour
 wrote:

> Ok, so a function like + avoids this boxing, because it's really
> replaced by a call to clojure.lang.Numbers.add()... And looking at the
> sourcecode, this is accomplished through :inline. This :inline
> declaration allows + to avoid IFn's rules, because + disappears after
> compiletime.
>
> If correct, that makes sense.

I think, this is what's going on. That also explains
why (+ 1 2 3) is slow, while (+ (+ 1 2) 3) is fast.

The first goes the usual route for function invocation,
ie. boxing is required, while the second gets inlined
and the fast path via c.l.Numbers is used.

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: Can Clojure be as fast as Java?

[Tayssir John Gabbour]

Ah, thanks Meikel for the explanation.

Ok, so a function like + avoids this boxing, because it's really
replaced by a call to clojure.lang.Numbers.add()... And looking at the
sourcecode, this is accomplished through :inline. This :inline
declaration allows + to avoid IFn's rules, because + disappears after
compiletime.

If correct, that makes sense.


Thanks for the enlightenment,
Tayssir


On Aug 12, 12:01 pm, Meikel Brandmeyer  wrote:
> Hi,
>
> On Aug 12, 11:54 am, Tayssir John Gabbour
>
>  wrote:
> > On this topic, how do primitives work? I heard something about
> > "function boundaries." Which I interpret to mean that when a function
> > returns a primitive, Clojure boxes it in some Java object. And type
> > declarations can't stop this boxing from happening.
>
> > Is this a correct understanding?
>
> This is correct, because the invoke methods of the IFn interface
> are based on Object, thus cannot return (or take) primitives.
>
> > And what is the performance penalty here?
>
> Not sure, but putting performance critical code into
> a let with unboxing the primitives proofed to be a
> good idea in the past.
>
> 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: Can Clojure be as fast as Java?

[Meikel Brandmeyer]

Hi,

On Aug 12, 11:54 am, Tayssir John Gabbour
 wrote:

> On this topic, how do primitives work? I heard something about
> "function boundaries." Which I interpret to mean that when a function
> returns a primitive, Clojure boxes it in some Java object. And type
> declarations can't stop this boxing from happening.
>
> Is this a correct understanding?

This is correct, because the invoke methods of the IFn interface
are based on Object, thus cannot return (or take) primitives.

> And what is the performance penalty here?

Not sure, but putting performance critical code into
a let with unboxing the primitives proofed to be a
good idea in the past.

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: Can Clojure be as fast as Java?

[Tayssir John Gabbour]

On this topic, how do primitives work? I heard something about
"function boundaries." Which I interpret to mean that when a function
returns a primitive, Clojure boxes it in some Java object. And type
declarations can't stop this boxing from happening.

Is this a correct understanding? (I doubt it is, since it leads to odd
conclusions.) And what is the performance penalty here?

(I'm not personally concerned about performance, just curious.)


Thanks,
Tayssir



On Aug 11, 8:55 pm, fft1976  wrote:
> I feel that this question is important enough to warrant its own
> thread.
>
> If you use Java's arrays and declare all types, should Clojure be as
> fast as the equivalent Java? I had taken this for granted, but
> empirical evidence indicates otherwise:
>
> Andy's version of the Nbody benchmark still appears to be about 10x
> slower than Java:
>
> Clojure:http://github.com/jafingerhut/clojure-benchmarks/blob/9dc56d8ff53f0b8...
>
> Java (runs 21 
> times):http://shootout.alioth.debian.org/u32/benchmark.php?test=nbody〈=j...
>
> Why?!

--~--~-~--~~~---~--~~
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: Pure-functional N-body benchmark implementation

[Nicolas Oury]

Hello,

I tried to inline everything in the main loop (the updaters loops) and
obtained on my machine a 15% speed-up.

One of the possible slowdown may come from having arrays and not object.
Maybe, each access need to perform a size check on the array. Which is
not very costly but not negligible when you have very few operations on
each elements.

I read Hot Spot removes checks when it can decide they are useless. But
it is not clear in this program they are useless.
(You take an array in a structure in each iteration and access fields
from 0 to 6. If the size is not known then it has to test acces for 1,
then 2, then 3...)
Maybe you could try each time you take a [b (bodies i)] to check that
it's size is at least 7. If Hot Spot is clever enough it would reduce
the number of checks. 
I am not sure it would do much good though, but I would like to know.

Else, you could try to put everything in one big array, and replace
bodies by their index. I wonder whether there would be a speed-up or not
from removing indirections.

Best,

Nicolas.

On Wed, 2009-08-12 at 00:26 -0400, Aaron Cohen wrote: 
> On Tue, Aug 11, 2009 at 8:13 PM, Andy
> Fingerhut wrote:
> >
> > On Aug 11, 2:36 pm, Aaron Cohen  wrote:
> >> At that point is it possible you're just paying the price of
> >> PersistentVector for the "bodies" vector?  Does it improve much if you
> >> change bodies to an array?
> >
> > About 7% faster changing bodies to a Java array of java.lang.Object's,
> > each of which happens to be a Java array of primitive doubles, as
> > before.  Now about 3.0 x Java run time.
> >
> > http://github.com/jafingerhut/clojure-benchmarks/blob/43ed2f42e6c1485541532e51eacc66488949c658/RESULTS
> >
> 
> I'm actually glad that the difference is that small there.
> 
> > 


--~--~-~--~~~---~--~~
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: ClojureQL confusion: getting a hold of the results

[Meikel Brandmeyer]

Hi,

On Aug 12, 11:43 am, Maximilian Karasz
 wrote:

> May i ask what kinds of improvements are planned for connection handling?
> Do you want to move it into the direction of persistent connections /
> connection pools?

We are currently looking into ways the user might specify connections
himself. So he has full control on how the connections are handled.
While still the simple one-shot mechanism is available for simplicity.

The details are still not settled, though.

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: ClojureQL confusion: getting a hold of the results

[Maximilian Karasz]

Hi,

On Tue, Aug 11, 2009 at 10:22 PM, Meikel Brandmeyer  wrote:

Yes. run uses a one-shot connection. When you leave the body
> the connection will be closed. Hence the second form cannot
> work, because the connection is already closed. We are currently
> working on improving the connection handling.


thanks for the confirmation and a great library :)

May i ask what kinds of improvements are planned for connection handling?
Do you want to move it into the direction of persistent connections /
connection
pools?


Cheers,

-Max

--~--~-~--~~~---~--~~
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 write a macro that writes another macro?

[Rock]

I've read what he has to say about backquotes, but he really doesn't
give as clear and concise a method for figuring out what's going on as
Graham does.

To evaluate a backquoted expression, you remove the outermost
backquote and each matching ~, and replace the expression following
each matching ~ with its value. Evaluating an expression that begins
with a ~ causes an error.

A ~ matches a backquote if there are the same number of ~ as
backquotes between them. This means that in a well-formed expression
the outermost backquote matches the innermost ~s.

THE ABOVE LAST STATEMENT IS CRUCIAL IN UNDERSTANDING HOW IT WORKS!

Suppose that x evaluates to say user/a, which evaluates to 1; and that
y evaluates to user/b, which evaluates to 2.

You can set this up pretty easily like this:

(def x `a)
(def a 1)
(def y `b)
(def b 2)

Evaluating the follwing expression

``(w ~x ~~y)

gives:

`(user/w ~user/x ~user/b)

Actually, what the REPL will print out is:

(clojure.core/seq (clojure.core/concat (clojure.core/list (quote user/
w)) (clojure.core/list user/x) (clojure.core/list user/b)))

But it's the SAME THING! ;)

Now evaluate again, and of course what you get is:

(user/w user/a 2)

A piece of cake ;)


Rock





On Aug 11, 11:07 pm, rob  wrote:
> Let Over Lambda by Hoyte contains a very lucidly well-written
> discussion of quotation levels in macros.  It also includes a pretty
> useful technique for being explicit about variable capture.  The code
> is in Common Lisp, but will mostly only differ syntactically from the
> Clojure code (for the basic example, I mean).  There is one non-
> trivial difference to implement for use in Clojure, which is that
> Lisp-1 versus Lisp-2 requires being concerned about capture of
> function names as well, but as indicated in the text this is a simple
> modification to make.
>
> On Aug 11, 1:21 pm, Rock  wrote:
>
> > For nested backquotes, Paul Graham in ANSI Common Lisp gives the
> > clearest explanation. He makes it look almost trivial. As a matter of
> > fact, once you get the hang of it, it's not at all that complicated.
>
> > I've pretty much verified that what he says concerning CL backquotes
> > applies perfectly to Clojure as well. The only difference is that you
> > have to remember that in Clojure, backquotes can *resolve* unqualified
> > symbols too (which is actually powerful and cool). So no problem
> > there.
>
> > Rock
>
> > On Aug 11, 6:00 pm, Jonathan Smith  wrote:
>
> > > For the sake of contradicting myself, in this paper Alan Bawden
> > > explains quasi-quote much better than I can.
>
> > >https://eprints.kfupm.edu.sa/60346/1/60346.pdf
>
> > > Note the explanation towards the end of defmacro and constructs such
> > > as ',' (in clojure I believe it would be '~' )
>
> > > Also note that Clojure has the added wrinkle of namespace
> > > qualification.
>
> > > On Aug 11, 1:31 am, Jonathan Smith  wrote:
>
> > > > On Aug 10, 3:20 pm, Dragan Djuric  wrote:
>
> > > > > For example:
>
> > > > > (defmacro creator [param]
> > > > >  `(defmacro created [p] `(the code...)) ;; note the nested quote...
> > > > > how to resolve that? any examples?
>
> > > > Although I wouldn't cite my own code as a necessarily *good* or easy
> > > > to understand example, I'll pimp it anyway as it is written and
> > > > already on the net...
>
> > > >http://github.com/JonathanSmith/CRIB/blob/89a3f4d9c797ef6f4e4f456001f...
>
> > > > A macro is exactly the same as a function, except it has special
> > > > evaluation rules.
> > > > You'll notice that in what I posted, I only use defmacro once,
> > > > everything else is a function that returns a list
>
> > > > (I've found that this gives me extra flexibility later on when I want
> > > > to continue extending the macro-metaphor... (or if I happen to want to
> > > > do runtime definition of certain things, I can swap out the macro for
> > > > a function call and an 'eval')).
>
> > > > You'll also notice that syntax quote qualifies every symbol that it is
> > > > passed.
> > > > Your particular example wouldn't work, because you can't define a name-
> > > > space qualified symbol. There are two ways that you could circumvent
> > > > this.
> > > > 1.) use regular old list
> > > > (list 'defmacro 'created ['p] `(code ...))
>
> > > > 2a.) Escape and quote certain things:
>
> > > > `(defmacro ~'created [p#] `(code goes here..))
>
> > > > or
>
> > > > 2b.) `(defmacro ~'created [p#]  ~(fn-that-returns-your-code p# and
> > > > probably some args and stuff))
>
> > > > or
>
> > > > 2c.)
> > > > (let [fn-that-generates-expansion
> > > >             (code-to-generate-a-fn-that-generates-an-expansion)]
> > > > `(defmacro ~'created [p#] (~fn-that-generates-expansion p#)))
>
> > > > You don't actually need to use nested backquote* (For anything**,
> > > > AFAIK), I tend to avoid it because I think it makes the code fairly
> > > > unreadable (yes, more unreadable than what I posted). I normally use a
> > > > helper function and pass the arguments (similar to a

Re: Clojure performance tests and clojure a little slower than Java

[Isak Hansen]

On Wed, Aug 12, 2009 at 7:00 AM, John Harrop wrote:

> A very straightforward version, and 875.36796ms/1 = 8.7536796ns.
> This is on a 2.5GHz machine, so that's only about 22 native instructions per
> iteration. The theoretical minimum is over 1/2 of that:
> Four fmuls
> Three fadds and an fsub
> A floating point comparison
> An integer add and an integer comparison
> A branch back to the start of the loop
> So we're within a factor of 2 of *native* code speeds (nevermind Java) here.

It's not this straightforward. Superscalar CPUs handle multiple
instructions concurrently.

I can't give you concrete numbers on the paralellism of current processors,
but had a lot of fun trying to saturate both pipelines on my first Pentium,
writing i386 assembly ages ago.


Isak

--~--~-~--~~~---~--~~
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: Can Clojure be as fast as Java?

[Nicolas Oury]

Hello all,

Just wanted to add a small remark. If you look at the shootout, most
languages considered now to be very efficient has been once said to be 
very very slow and not usable.

In the eighties, functional languages were doomed to be slow and
unusable for anything. And Ocaml/MLton and the like are now very fast.

Next laziness was thought to be too slow to be practical, and now
someone used ghc in this thread as an example of fast language.
I think everybody remembers what was being said about java 10 years ago.
And now java is the goal to attain.
I even think than C and C++ where too slow to be usable at their time.

Getting a compiler to produce fast code takes time and Clojure is young.

 What would be more useful than this discussion would be to take
fragments of code that looks inexplicably slow, profile them, and
transform them by hand to be faster.
And keep a wiki with which transformation gives which performance
improvement. 
This could serve 3 goals:
 - giving ideas to people on how to optimize (the doc does not contain
every trick);
 - allow to write ugly but very efficient macros, that can be used in
bottlenecks ;
 - give ideas to which code transformation performed by the compiler
will improve performance and by how much.

What is sure is that there is no reason why clojure should be slow, when
some functional languages (including dynamically typed ones) are fast. 
So, one day, it will be fast. 

Best,

Nicolas.
 

On Tue, 2009-08-11 at 21:20 -0700, James Sofra wrote:
> Hi fft1976,
> 
> > If you use Java's arrays and declare all types, should Clojure be as
> > fast as the equivalent Java?
> 
> 
> 
> So is the question you are trying to ask that since we have unwrapped
> access to Java is Java code written in Clojure as fast as if it were
> written as actual Java code?
> 
> I guess that is a worthwhile question since it would at least tell you
> (if you are worried about speed) whether it is worth while dropping
> down to write actual Java code or if you can just write your Java in
> Clojure (as unidomatic as that Clojure code may be).
> 
> I am sorry I don't have an answer for you, just wanted to clear up the
> question.
> 
> Cheers,
> 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
-~--~~~~--~~--~--~---

Parsing XML containing UTF8 with clojure.xml/parse

[Meikel Brandmeyer]

Dear Clojurians,

I have to parse some XML files with c.x/parse. However the files
contain UTF-8 characters, which end up as '?' after being parsed by
c.x/parse. Is there some possibility to correctly parse the files? I
suspect there is some settings somewhere in my Clojure/JVM/System
which makes the whole thing fail, but I have no clue how to find out
where to look...

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: ANN: Clojure Ant Tasks

[C. Florian Ebeling]

Thanks for sharing this. What I miss a bit is the ability to set the
*compile-path* to something other than "classes". And might it be a
good idea to be able to name .clj files instead of namespaces as an
option? Then one could use regular ant filesets constucted
automatically from expressions, instead of naming namespaces
individually.

Florian

On Mon, Aug 10, 2009 at 5:14 AM, J. McConnell wrote:
> Most of the Ant setups I've seen for building and testing Clojure code,
> including some of my own, have suffered from the fact that compilation and
> test failures still result in a "Successful" build in Ant's eyes. This can
> be confusing at best, but can cause real problems if you aren't paying close
> attention and have stale jars laying around from a previous build. The
> solution for me until now was to set up failure properties that get set when
> a compile or test fails, but it is a real pain to set this up for each new
> project.
>
> Thus, Clojure Ant Tasks was born. This is very young at this point, but does
> support the building and testing of Clojure 1.0-compatible projects. After
> defining the tasks, you just pass them a classpath and a list of namespaces
> to build/test and it will do so, failing when appropriate. Despite being
> young, I wanted to release this now to get feedback from people with larger
> projects than my own. Both clojure and clojure-contrib suffer from the
> problem that compilation and test failures aren't reported by Ant, so it
> would be great to stabilize this set of tasks and be able to take advantage
> of them there. Patches, bug reports and feature requests are all very much
> welcome. The code can be checked out from here:
>
> http://github.com/jmcconnell/clojure-ant-tasks/tree/master
>
> I hope someone finds some benefit from these. Let me know if you have any
> questions.
>
> Regards,
>
> - J.
>
> >
>



-- 
Florian Ebeling
florian.ebel...@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: Clojure performance tests and clojure a little slower than Java

[Mike Hinchey]

John, this will speed up to the same as the others if you let the 0.  IIRC
from looking at the bytecode before, the 0 is an Integer not an int.

user> (time
 (let [m (int 1) b (double 4.0) x0 (double -0.2) y0 (double
0.1) t (double 2.0) i0 (int 0)]
   (loop [x (double 0.0) y (double 0.0) i m]
 (if (> i i0)
   (let [x2 (* x x) y2 (* y y)]
 (if (< (+ x2 y2) b)
   (recur (+ (- x2 y2) x0) (+ (* t (* x y)) y0)
(unchecked-dec i))
 i))
   i
"Elapsed time: 881.387889 msecs"
0

-Mike

On Tue, Aug 11, 2009 at 10:00 PM, John Harrop  wrote:

> user=> (time (let [m (int 1) b (double 4.0) x0 (double
> -0.2) y0 (double 0.1) t (double 2.0)]
>(loop [x (double 0.0) y (double 0.0) i m]
>  (if (> i 0)
>(let [x2 (* x x) y2 (* y y)]
>  (if (< (+ x2 y2) b)
>(recur (+ (- x2 y2) x0) (+ (* t (* x y)) y0)
> (unchecked-dec i))
>  i))
>i
> "Elapsed time: 3418.8542 msecs"
> 0
>
> Shockingly, reversing the count-up to a count-down and not changing
> anything else at all makes things much, MUCH worse, about four times slower.
>
>
>

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