Re: Let's respect CLOJURE_HOME

[Luc Préfontaine]

We use a "HOME" reference in our
quite complex software and I think
we do not qualify as n00bs...

Any root symbol that can help derive
locations is just common sense to
us. It's not used internaly in our code
(Clojure/Java/Ruby)
but it's obviously a simple way
to bootstrap our apps and establish
a common ground in the supporting
scripts we use.

It helps structuring the file space were
all our components reside in dev test
and prod.

Honestly, by the time this thread ends
on that simple and obvious matter,
Clojure 1.5 will be released...


Luc P.

Sent from my iPod

On 2010-06-30, at 17:48, Greg  wrote:


However, I don't see it helping newcomers to Clojure significantly


With respect, I'm a newcomer to Clojure, and the CLOJURE_HOME  
convention would help me significantly. :-)


I think something that needs to be acknowledged is that "newcomers"  
and "n00bs" are not necessarily idiots, they're just new to the  
platform, and they're coming from places where, as Brian pointed,  
they're used to there being a central location for things  
(PYTHON_HOME, ANT_HOME, etc.).



Lieningen or maven don't really fit with this approach as they treat
the clojure platform as just another library dependency.


Yet Maven has a MAVEN_HOME. :-)

Even if Leiningen/Maven ignore CLOJURE_HOME, that's fine, it  
certainly doesn't hurt to adopt CLOJURE_HOME as a convention for  
scripts that currently hard-code clojure.jar's location, or download  
it themselves, wasting space and adding confusion. When that happens  
it's hard to know what version of Clojure these scripts are running,  
and it makes it unwieldy then to interface it with your own code. A  
problem, I think, that doesn't just affect newcomers to Clojure.



and I'm not sure this is something we should really try and hide.


CLOJURE_HOME doesn't hide anything, it's set by the user after all.

Cheers,
Greg

On Jun 30, 2010, at 5:17 PM, Rick Moynihan wrote:


On 30 June 2010 21:14, Brian Schlining  wrote:




May I propose as a possible remedy CLOJURE_HOME. CLOJURE_HOME is  
the

absolute path of a directory containing clojure.jar and possibly
clojure-contrib.jar. Scripts should check if it's defined and  
use it instead
of hard-coded paths, as an example, here's my clj script (in  
newLISP):


On the face of it this seems like a good idea, however it doesn't
really fit with the models used by tools such as leiningen, mvn  
or the
JVM.  At best a CLOJURE_HOME initiative can only expect to work  
within

its own world of clj scripts etc.


I can't speak for leiningen but many (most?) launcher script in  
the Java
world use this as a standard convention. If you look through the  
launcher

scripts for maven, groovy, scala, ant, etc you will see environment
variables JAVA_HOME, M2_HOME (for Maven 2), GROOVY_HOME,  
SCALA_HOME and

ANT_HOME.


This is true.  And I agree that where scripts are used this technique
can be useful.  And in this regard it's a good convention.

However, I don't see it helping newcomers to Clojure significantly,  
as

the classpath issues people face are the deeper issue.  Also teaching
newcomers that this is the convention isn't really true, as tools  
like

Lieningen or maven don't really fit with this approach as they treat
the clojure platform as just another library dependency.

Clojure doesn't yet have a standard launch script.  In the past I've
argued that it'd be nice if it had one, though I now feel lein/mvn  
are

better tools for this job.  That said, having a clj launch script can
be useful, and might ease the out of box experience, but again the
true launcher will always be the java JVM executable, and I'm not  
sure

this is something we should really try and hide.

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


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient  
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clj on OSX

[Michael Kohl]

On Tue, Jun 29, 2010 at 6:22 PM, Glenn, Jacob  wrote:
> I've been using the clj script provided by ClojureX,

As you mentioned I decided to stop working on ClojureX, since David's
current approach looks more sensible to me. I hope to eventually set
aside some free time to get ClojureX's clj script into the new clj
project since it was a fairly complete script.

Michael

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

explode string

[Martin DeMello]

Anything more efficient than (map str (seq string)) ?

martin

-- 
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: explode string

[Laurent PETIT]

2010/7/1 Martin DeMello :
> Anything more efficient than (map str (seq string)) ?

I cannot think of another hof-like version that may be more efficient.

If you want to avoid at all cost the creation of intermediate Seq elements:

(defn explode-string [^String string]
  (loop [i (int 0) v (transient [])]
(if (== i (.length string))
  (persistent! v)
  (recur (inc i) (conj! v (.substring string i (inc i)))

But do you really need a so much more complex version ?

(and also note that this version fully realizes the exploded string,
which may or may not be what you're after)

-- 
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: explode string

[Chouser]

(next (.split #"(?=)" string))

But why do you one-char strings instead of just a seq of chars?

--Chouser
http://joyofclojure.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: explode string

[Nicolas Oury]

On Thu, Jul 1, 2010 at 1:36 PM, Laurent PETIT wrote:

> If you want to avoid at all cost the creation of intermediate Seq elements:
>
> (defn explode-string [^String string]
>  (loop [i (int 0) v (transient [])]
>(if (== i (.length string))
>  (persistent! v)
>  (recur (inc i) (conj! v (.substring string i (inc i)))
>
> But do you really need a so much more complex version ?
>


If you think that one day (is it already the case in some branch?) map will
have chunky evaluation,
I am not sure this one is more efficient.

-- 
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: explode string

[Laurent PETIT]

2010/7/1 Nicolas Oury :
>
>
> On Thu, Jul 1, 2010 at 1:36 PM, Laurent PETIT 
> wrote:
>>
>> If you want to avoid at all cost the creation of intermediate Seq
>> elements:
>>
>> (defn explode-string [^String string]
>>  (loop [i (int 0) v (transient [])]
>>    (if (== i (.length string))
>>      (persistent! v)
>>      (recur (inc i) (conj! v (.substring string i (inc i)))
>>
>> But do you really need a so much more complex version ?
>
> If you think that one day (is it already the case in some branch?) map will
> have chunky evaluation,
> I am not sure this one is more efficient.

hey, I just promised that my version avoids the creation of the
intermediate Seq objects :)

-- 
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: explode string

[Martin DeMello]

On Thu, Jul 1, 2010 at 6:11 PM, Chouser  wrote:
> (next (.split #"(?=)" string))
>
> But why do you one-char strings instead of just a seq of chars?

Good question :) I was working with code that wanted one character
strings, but since I'm trying to squeeze cycles anyway, it might be
more worthwhile to rewrite that code to use chars.

martin

-- 
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: explode string

[Martin DeMello]

On Thu, Jul 1, 2010 at 6:06 PM, Laurent PETIT  wrote:
> 2010/7/1 Martin DeMello :
>> Anything more efficient than (map str (seq string)) ?
>
> I cannot think of another hof-like version that may be more efficient.
>
> If you want to avoid at all cost the creation of intermediate Seq elements:
>
> (defn explode-string [^String string]
>  (loop [i (int 0) v (transient [])]
>    (if (== i (.length string))
>      (persistent! v)
>      (recur (inc i) (conj! v (.substring string i (inc i)))
>
> But do you really need a so much more complex version ?

I haven't benchmarked yet, but it's called frequently enough that it's
probably worth making it efficient. (This is in code that converts a
dictionary to a trie)

martin

-- 
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: explode string

[Martin DeMello]

On Thu, Jul 1, 2010 at 6:42 PM, Martin DeMello  wrote:
>
> I haven't benchmarked yet, but it's called frequently enough that it's
> probably worth making it efficient. (This is in code that converts a
> dictionary to a trie)

Actually, it just struck me that the main reason I'm trying so hard to
optimise this is that my app has to read in a list of strings and
create a trie every time it starts up. Is there any way to dump a trie
to disk in some marshalled format? (I could just dump to yaml, but
that would probably not be any quicker to read in and parse)

martin

-- 
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: explode string

[Nicolas Oury]

On Thu, Jul 1, 2010 at 2:12 PM, Martin DeMello wrote:

> I haven't benchmarked yet, but it's called frequently enough that it's
> probably worth making it efficient. (This is in code that converts a
> dictionary to a trie)
>

Random advices for speed or simplicity:
1. don't split the string but loop on the index of the string in the code
that insert it in the trie
2. Use transients for the nodes of your tries
3. Do not hash one char per one char but convert 8 chars into a long (if you
use only ASCII chars, 4 chars to a long else)
4. Have you tried (for simplicity) to directly use a Clojure Map or Set
instead of your trie for a dictionnary.
 For a small dictionary (collisions are not probable) it should not be much
more slower, and could be better.


3 and 4 are if you do not need escpecially a one-char trie for your
algorithm.

-- 
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's n00b attraction problem

[Heinz N. Gies]

Okay my 2 cent, just because I like long threads:

Clojure as 2 'noob attraction problems'

1) it has no simple setup that just works (I wonder if I can say 'just works' 
too often but I doubt it). Neither EMACS, nor Eclips, nor Netbeans, nor 
IntelliJ just work all have their quirks and most of them I personally found 
rather annoying especially if you just want to learn

2) It is not actually a clojure problem, but the noobs are not actually noobs, 
they are 'posioned' by a Java and C# world where they are told to make objects 
instead of anonymous functions and that you can't do Integer + int but need to 
wrap it in ugly type casts (I know that ain't true any more but show me one IT 
teacher at highschools who actually knows what is up to date and does not teach 
with rather prehistoric methods - I had IT with Modula (I doubt many of you 
even know what this is) and that isn't that long ago!). Don't get me wrong many 
of the things people learn are still good but,  big BUT, clojure is a lisp and 
that makes it different and for many simple minded individuals different is 
bad. I claim if you start to teach someone programming (who hasn't seen Java, 
C#, Ruby, Perl or whatever before) with Clojure there isn't that big of a noob 
problem. Our noob problem is that this sneaky people aren't as nooby as they 
claim, they are semi noobs! We should shoot them all, okay just kidding here :) 
no they are more then welcome just it is a different set of problem in my eyes.

Regards,
Heinz

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Exceptions

[Nicolas Oury]

On Tue, Jun 29, 2010 at 4:27 PM, Brenton  wrote:

> Nicolas,
>
> Check out error-kit in contrib.
>
>
It looks very nice, but it is a bit of a higher level feature than what I
had in mind.
It constructs some very interesting things, like conitnue.

I thought that the low-level interface to Exceptions should be made less
Java-ish as the concept is quite cross-platform.

Maybe error-kit could be split in 2 parts when it is less experimental.

-- 
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: Let's respect CLOJURE_HOME

[Greg]

> Sounds sensible in principle, though I think the issue for n00bs is
> that configuring *anything* is a barrier because even the slightest
> mistake in interpreting the documentation or configuring your
> environment is pretty painful.

OK, see my response to Rick. I think we're getting stuck on a stereotype of 
what a n00b is, and it's hurting the discussion.

I'm not suggestion (and I don't think anyone else is) that CLOJURE_HOME have 
anything to do with the existing setup processes. *Complete* n00bs, and by that 
I mean people who generally don't have much of a clue about anything, won't 
know or see or wish for a CLOJURE_HOME.

A CLOJURE_HOME convention would help everyone else, those who use 
clojure-related script/projects, etc. Newcomers (perhaps that's a better word) 
to Clojure, who come from a general UNIX background, would expect something 
like CLOJURE_HOME to exist, because it's useful convention employed frequently.

If it were a convention in Clojure, n00bs an non-n00bs alike would benefit from 
it, while those who don't need it won't be affected in any way.

- Greg

On Jun 30, 2010, at 5:46 PM, Mike Anderson wrote:

> On Jun 30, 6:45 pm, Greg  wrote:
>> It seems like a lot of n00b (and non-n00b) related problems have to do with 
>> the location of clojure.jar and clojure-contrib.jar. People generally don't 
>> like having to keep track of all the clojure.jars, and it would be nice if 
>> it was easy to switch versions for scripts like clj and such.
>> 
>> May I propose as a possible remedy CLOJURE_HOME. CLOJURE_HOME is the 
>> absolute path of a directory containing clojure.jar and possibly 
>> clojure-contrib.jar. Scripts should check if it's defined and use it instead 
>> of hard-coded paths, as an example, here's my clj script (in newLISP):
> 
> Sounds sensible in principle, though I think the issue for n00bs is
> that configuring *anything* is a barrier because even the slightest
> mistake in interpreting the documentation or configuring your
> environment is pretty painful.
> 
> For n00bs, if it is much more complicated than unzipping a Clojure
> distribution or navigating to the right Eclipse update site then
> you're already going to lose a lot of people.
> 
> For those of us n00bs who primarily use IDEs like myself, I'd vote for
> just improving the integration with the IDE's automatic management of
> classpaths / build paths etc. To give it credit, Counterclockwise does
> a decent job to get people started quickly in terms of adding the
> Clojure jars automatically to an Eclipse project.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Let's respect CLOJURE_HOME

[Greg]

> are not necessarily idiots,

Ooof.. bad choice of words there on my part, it was in jest and I did not mean 
literal "idiots". :-p

On Jun 30, 2010, at 5:48 PM, Greg wrote:

>> However, I don't see it helping newcomers to Clojure significantly
> 
> With respect, I'm a newcomer to Clojure, and the CLOJURE_HOME convention 
> would help me significantly. :-)
> 
> I think something that needs to be acknowledged is that "newcomers" and 
> "n00bs" are not necessarily idiots, they're just new to the platform, and 
> they're coming from places where, as Brian pointed, they're used to there 
> being a central location for things (PYTHON_HOME, ANT_HOME, etc.).
> 
>> Lieningen or maven don't really fit with this approach as they treat
>> the clojure platform as just another library dependency.
> 
> Yet Maven has a MAVEN_HOME. :-)
> 
> Even if Leiningen/Maven ignore CLOJURE_HOME, that's fine, it certainly 
> doesn't hurt to adopt CLOJURE_HOME as a convention for scripts that currently 
> hard-code clojure.jar's location, or download it themselves, wasting space 
> and adding confusion. When that happens it's hard to know what version of 
> Clojure these scripts are running, and it makes it unwieldy then to interface 
> it with your own code. A problem, I think, that doesn't just affect newcomers 
> to Clojure.
> 
>> and I'm not sure this is something we should really try and hide.
> 
> CLOJURE_HOME doesn't hide anything, it's set by the user after all.
> 
> Cheers,
> Greg
> 
> On Jun 30, 2010, at 5:17 PM, Rick Moynihan wrote:
> 
>> On 30 June 2010 21:14, Brian Schlining  wrote:
 
> 
> May I propose as a possible remedy CLOJURE_HOME. CLOJURE_HOME is the
> absolute path of a directory containing clojure.jar and possibly
> clojure-contrib.jar. Scripts should check if it's defined and use it 
> instead
> of hard-coded paths, as an example, here's my clj script (in newLISP):
 
 On the face of it this seems like a good idea, however it doesn't
 really fit with the models used by tools such as leiningen, mvn or the
 JVM.  At best a CLOJURE_HOME initiative can only expect to work within
 its own world of clj scripts etc.
>>> 
>>> I can't speak for leiningen but many (most?) launcher script in the Java
>>> world use this as a standard convention. If you look through the launcher
>>> scripts for maven, groovy, scala, ant, etc you will see environment
>>> variables JAVA_HOME, M2_HOME (for Maven 2), GROOVY_HOME, SCALA_HOME and
>>> ANT_HOME.
>> 
>> This is true.  And I agree that where scripts are used this technique
>> can be useful.  And in this regard it's a good convention.
>> 
>> However, I don't see it helping newcomers to Clojure significantly, as
>> the classpath issues people face are the deeper issue.  Also teaching
>> newcomers that this is the convention isn't really true, as tools like
>> Lieningen or maven don't really fit with this approach as they treat
>> the clojure platform as just another library dependency.
>> 
>> Clojure doesn't yet have a standard launch script.  In the past I've
>> argued that it'd be nice if it had one, though I now feel lein/mvn are
>> better tools for this job.  That said, having a clj launch script can
>> be useful, and might ease the out of box experience, but again the
>> true launcher will always be the java JVM executable, and I'm not sure
>> this is something we should really try and hide.
>> 
>> 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
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure's n00b attraction problem

[Greg]

> For the time being, you could use nailgun.  My clj script uses nailgun
> and for a warm start I can run clj -e "(System/exit 0)" in 20
> milliseconds.

Nice idea! I've incorporated it into my clj script as well:

http://www.taoeffect.com/other/clj.lsp.html

Run it with clj -ng and it will start the server for you if it's not already 
running, and then it will run clojure using the 'ng' command.

Even without the -ng flag, it will check if the server is already running and 
will use it if it is (unless you specify -nng, or "no-nailgun").

On Jun 30, 2010, at 4:42 PM, Brian Goslinga wrote:

> On Jun 30, 12:50 pm, David Nolen  wrote:
>> On Wed, Jun 30, 2010 at 1:42 PM, cageface  wrote:
>>> I don't know what the implementation plans are exactly for clojure-in-
>>> clojure but abandoning the JVM would be extremely unwise.
>> 
>> Clojure-in-Clojure isn't about abandoning the JVM. It's about implementing
>> more of Clojure in itself. This has several benefits, *one* of which is
>> making it easier to port Clojure to other platforms.
>> 
>> For example, I would love to see some portion of Clojure run on a platform
>> that has much faster boot times so I can use Clojure for one-off shell
>> scripts.
>> 
>> David
> For the time being, you could use nailgun.  My clj script uses nailgun
> and for a warm start I can run clj -e "(System/exit 0)" in 20
> milliseconds.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: New Primitive data types (equal branch) - impact on optimized code.

[j-g-faustus]

I'm getting some form of boxing during array access, even on the equiv
branch.

Speaking of which: (type (+ 1N 1)) => clojure.lang.BigInt means that
I'm using the correct branch, right?

Here is a simple speed test comparing 3-element vectors using Java
arrays, immutable deftype and mutable deftype:
http://gist.github.com/459383

Using the equiv branch, I get
* Java arrays: 18s
* Immutable deftype: 10s
* Mutable deftype: 2s
* Plain Java: 2s

Here is a profiler snapshot for the array case, where
java.lang.Number.init(), java.lang.Double.init() and
java.lang.Double.valueOf() take a significant chunk of the CPU time:
http://i589.photobucket.com/albums/ss334/j-g-faustus/profiling/eqv-arrays.png

>From a practical standpoint I guess it means that deftype is the way
to go if you want fast numbers today.
In this case even the immutable deftype was faster than mutable Java
arrays, so you can be fast, idiomatic and thread-safe simultaneously.

For the future, it would be nice if Java arrays were equally fast.
There is unchecked-inc-int and -long, would there be room for an
unchecked-aget/aset-int/long/double?


Regards
jf


On Jun 30, 6:14 pm, David Nolen  wrote:
> On Wed, Jun 30, 2010 at 10:19 AM, j-g-faustus
> wrote:
>
> On the equiv branch I don't see this at all. Also on the equiv branch most
> of your type hints inside the fn are unnecessary.
>

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

Managing the classpath

[Paul Moore]

First, a disclaimer - I don't have any problem with the idea of the
classpath in Java. In principle, it's pretty similar to Python's
sys.path. And jar files are much like Python having zip files on
sys.path. So I'm familiar with the idea.

Where I struggle is with the practicalities of managing the classpath.
>From what I can tell, there is no way of modifying the classpath from
a running Java/Clojure program (barring use of a custom classloader
which sounds like deep magic). So, assuming that is right, I need to
list my dependencies in advance, when I start the JVM (either by
setting the CLASSPATH environment variable, or with the -classpath
argument).

Generally, I avoid using "global" environment variables like CLASSPATH
(except if they are locally set in a wrapper script), so I guess that
I have the following options for my Clojure applications:

* Use something like lein uberjar to wrap all my dependencies up in one file
* Create an application-specific wrapper, which sets CLASSPATH (or
uses -cp) and runs my application

I have personal reservations about both of these options (I won't
elaborate, to avoid boring people with my prejudices - ask if you
really want to know) so I guess my question would be - is there
another option I have missed?

Python doesn't have these issues because (a) conventionally,
dependencies are installed into the site-packages directory which is
on the standard sys.path - it appears to me that the JVM doesn't have
such an "always available" install location, and (b) for special cases
sys.path can be manipulated at runtime (as noted above, the JVM
doesn't really have this option).

One further question - does having a lot of entries on CLASSPATH slow
down JVM code (either at startup time, or in terms of slowing down
runtime class loading)? Essentially, is there a cost to including
things like clojure-contrib "just in case"? (I don't imagine that the
cost would be significant for just one such case, but I could imagine
that if the practice were to become common, it wouldn't be long before
there were many extra entries, not just one).

I appreciate that this question is only tangentially Clojure-related.
If there is a better forum to discuss this type of question, please
feel free to direct me there.

Thanks,
Paul.

-- 
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's n00b attraction problem

[Alessio Stalla]

On Jun 30, 10:41 pm, Phil Hagelberg  wrote:
> I wasn't complaining about what you said; I was just glad someone else
> was recognizing that talk is cheap and effort is not.

Ok, sorry, I misinterpreted your words.

Peace,
Alessio

-- 
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: New Primitive data types (equal branch) - impact on optimized code.

[Nicolas Oury]

On Thu, Jul 1, 2010 at 2:27 AM, j-g-faustus wrote:

> Using the equiv branch, I get
> * Java arrays: 18s
> * Immutable deftype: 10s
> * Mutable deftype: 2s
> * Plain Java: 2s
>

That's a very encouraging result! That proves that the equiv branch, and
deftypes, can be as fast as java.

Could you test an array in Plain Java to compare what comes from arrays and
what comes from array access 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: Managing the classpath

[Laurent PETIT]

Hello,

note that with java 6 you can specify at once to add all the jars
located in a directory:

java -cp "libs/*" clojure.main

and you can place any jar you want in directory libs.

and this is composable:

java -cp "clojure.jar:libs/*" clojure.main

My 0.02€, just in case you didn't know this (rather recent) possibility.

2010/7/1 Paul Moore :
> First, a disclaimer - I don't have any problem with the idea of the
> classpath in Java. In principle, it's pretty similar to Python's
> sys.path. And jar files are much like Python having zip files on
> sys.path. So I'm familiar with the idea.
>
> Where I struggle is with the practicalities of managing the classpath.
> From what I can tell, there is no way of modifying the classpath from
> a running Java/Clojure program (barring use of a custom classloader
> which sounds like deep magic). So, assuming that is right, I need to
> list my dependencies in advance, when I start the JVM (either by
> setting the CLASSPATH environment variable, or with the -classpath
> argument).
>
> Generally, I avoid using "global" environment variables like CLASSPATH
> (except if they are locally set in a wrapper script), so I guess that
> I have the following options for my Clojure applications:
>
> * Use something like lein uberjar to wrap all my dependencies up in one file
> * Create an application-specific wrapper, which sets CLASSPATH (or
> uses -cp) and runs my application
>
> I have personal reservations about both of these options (I won't
> elaborate, to avoid boring people with my prejudices - ask if you
> really want to know) so I guess my question would be - is there
> another option I have missed?
>
> Python doesn't have these issues because (a) conventionally,
> dependencies are installed into the site-packages directory which is
> on the standard sys.path - it appears to me that the JVM doesn't have
> such an "always available" install location, and (b) for special cases
> sys.path can be manipulated at runtime (as noted above, the JVM
> doesn't really have this option).
>
> One further question - does having a lot of entries on CLASSPATH slow
> down JVM code (either at startup time, or in terms of slowing down
> runtime class loading)? Essentially, is there a cost to including
> things like clojure-contrib "just in case"? (I don't imagine that the
> cost would be significant for just one such case, but I could imagine
> that if the practice were to become common, it wouldn't be long before
> there were many extra entries, not just one).
>
> I appreciate that this question is only tangentially Clojure-related.
> If there is a better forum to discuss this type of question, please
> feel free to direct me there.
>
> Thanks,
> Paul.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Managing the classpath

[Luc Préfontaine]

Yep, we have been using this for a
year or so and this solves the
classpath/jar file location issue nicely.

Hence the usefulness of CLOJURE_HOME and alikes to locate
this single folder from a very simple wrapper script...

Luc P.

Sent from my iPod

On 2010-07-01, at 10:29, Laurent PETIT  wrote:


Hello,

note that with java 6 you can specify at once to add all the jars
located in a directory:

java -cp "libs/*" clojure.main

and you can place any jar you want in directory libs.

and this is composable:

java -cp "clojure.jar:libs/*" clojure.main

My 0.02€, just in case you didn't know this (rather recent) possibil 
ity.


2010/7/1 Paul Moore :

First, a disclaimer - I don't have any problem with the idea of the
classpath in Java. In principle, it's pretty similar to Python's
sys.path. And jar files are much like Python having zip files on
sys.path. So I'm familiar with the idea.

Where I struggle is with the practicalities of managing the  
classpath.

From what I can tell, there is no way of modifying the classpath from
a running Java/Clojure program (barring use of a custom classloader
which sounds like deep magic). So, assuming that is right, I need to
list my dependencies in advance, when I start the JVM (either by
setting the CLASSPATH environment variable, or with the -classpath
argument).

Generally, I avoid using "global" environment variables like  
CLASSPATH

(except if they are locally set in a wrapper script), so I guess that
I have the following options for my Clojure applications:

* Use something like lein uberjar to wrap all my dependencies up in  
one file

* Create an application-specific wrapper, which sets CLASSPATH (or
uses -cp) and runs my application

I have personal reservations about both of these options (I won't
elaborate, to avoid boring people with my prejudices - ask if you
really want to know) so I guess my question would be - is there
another option I have missed?

Python doesn't have these issues because (a) conventionally,
dependencies are installed into the site-packages directory which is
on the standard sys.path - it appears to me that the JVM doesn't have
such an "always available" install location, and (b) for special  
cases

sys.path can be manipulated at runtime (as noted above, the JVM
doesn't really have this option).

One further question - does having a lot of entries on CLASSPATH slow
down JVM code (either at startup time, or in terms of slowing down
runtime class loading)? Essentially, is there a cost to including
things like clojure-contrib "just in case"? (I don't imagine that the
cost would be significant for just one such case, but I could imagine
that if the practice were to become common, it wouldn't be long  
before

there were many extra entries, not just one).

I appreciate that this question is only tangentially Clojure-related.
If there is a better forum to discuss this type of question, please
feel free to direct me there.

Thanks,
Paul.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient  
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient  
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Managing the classpath

[Brian Schlining]

>
>
>
> Where I struggle is with the practicalities of managing the classpath.
> From what I can tell, there is no way of modifying the classpath from
> a running Java/Clojure program (barring use of a custom classloader
> which sounds like deep magic).
>

There's URLClassLoader for loading classes at runtime. Javadocs are at
http://java.sun.com/javase/6/docs/api/java/net/URLClassLoader.html. There's
an old thread about using it at
http://forums.sun.com/thread.jspa?threadID=300557&start=0&tstart=0

Groovy has a very elegant solution for adding dependencies (from Maven and
Ivy repos) to scripts. See http://groovy.codehaus.org/Grapes+and+grab(). If
some astute Clojure hacker with far more time than I were to grok the grape
code and create a similar dependency engine for Clojure, well it would
greatly expand Clojure's use for scripting and likely solve many of the
issues you're finding with CLASSPATH


> Python doesn't have these issues because (a) conventionally,
> dependencies are installed into the site-packages directory which is
> on the standard sys.path - it appears to me that the JVM doesn't have
> such an "always available" install location,
>

Actually there is such a thing. For most JRE's/JDK's drop the
'always-available-jars' in JRE_HOME/lib/ext. On Mac's you would place them
in /Library/Java/Extensions. Keep in mind that this is generally discouraged
in favor of setting the classpath on a per-application basis.

-- 
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlin...@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: Managing the classpath

[Kevin Livingston]

Some of the build tools like Maven can help a lot.

However, one different/related issue I have is when I have multiple
projects I am developing, say a library, LibA, and a project that uses
it ProjB, if I want to co-develop them, it can get a little hairy, and
I haven't figured out the solution...

since in the java-only world maven would (i think, I'm still a little
new to it) see LibA as a dependency to ProjB, compile it, jar it, and
put the jar on ProjB's class path.  That's great in the java world
where you (almost) always run fresh instances.  But in a Lisp with a
REPL you'd want to change something and reload just that piece.  So
I'd like to edit LibA stuff and reload it in the ProjB (already
running) REPL but it seems like the classpath will be out of whack for
this.  using something like swank through clojure-maven.


presumably people co-developing clojure-contrib and clojure core have
this same issue?
it looks like clojure is brought into the clojure-contrib as a system
dependency under a build profile... seems do-able for my problem, are
there pro's and con's to any alternatives?

Kevin




On Jul 1, 7:11 am, Paul Moore  wrote:
> First, a disclaimer - I don't have any problem with the idea of the
> classpath in Java. In principle, it's pretty similar to Python's
> sys.path. And jar files are much like Python having zip files on
> sys.path. So I'm familiar with the idea.
>
> Where I struggle is with the practicalities of managing the classpath.
> From what I can tell, there is no way of modifying the classpath from
> a running Java/Clojure program (barring use of a custom classloader
> which sounds like deep magic). So, assuming that is right, I need to
> list my dependencies in advance, when I start the JVM (either by
> setting the CLASSPATH environment variable, or with the -classpath
> argument).
>
> Generally, I avoid using "global" environment variables like CLASSPATH
> (except if they are locally set in a wrapper script), so I guess that
> I have the following options for my Clojure applications:
>
> * Use something like lein uberjar to wrap all my dependencies up in one file
> * Create an application-specific wrapper, which sets CLASSPATH (or
> uses -cp) and runs my application
>
> I have personal reservations about both of these options (I won't
> elaborate, to avoid boring people with my prejudices - ask if you
> really want to know) so I guess my question would be - is there
> another option I have missed?
>
> Python doesn't have these issues because (a) conventionally,
> dependencies are installed into the site-packages directory which is
> on the standard sys.path - it appears to me that the JVM doesn't have
> such an "always available" install location, and (b) for special cases
> sys.path can be manipulated at runtime (as noted above, the JVM
> doesn't really have this option).
>
> One further question - does having a lot of entries on CLASSPATH slow
> down JVM code (either at startup time, or in terms of slowing down
> runtime class loading)? Essentially, is there a cost to including
> things like clojure-contrib "just in case"? (I don't imagine that the
> cost would be significant for just one such case, but I could imagine
> that if the practice were to become common, it wouldn't be long before
> there were many extra entries, not just one).
>
> I appreciate that this question is only tangentially Clojure-related.
> If there is a better forum to discuss this type of question, please
> feel free to direct me there.
>
> Thanks,
> Paul.

-- 
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: Managing the classpath

[Michael Wood]

On 1 July 2010 17:49, Kevin Livingston  wrote:
> Some of the build tools like Maven can help a lot.
>
> However, one different/related issue I have is when I have multiple
> projects I am developing, say a library, LibA, and a project that uses
> it ProjB, if I want to co-develop them, it can get a little hairy, and
> I haven't figured out the solution...
>
> since in the java-only world maven would (i think, I'm still a little
> new to it) see LibA as a dependency to ProjB, compile it, jar it, and
> put the jar on ProjB's class path.  That's great in the java world
> where you (almost) always run fresh instances.  But in a Lisp with a
> REPL you'd want to change something and reload just that piece.  So
> I'd like to edit LibA stuff and reload it in the ProjB (already
> running) REPL but it seems like the classpath will be out of whack for
> this.  using something like swank through clojure-maven.

If you have a directory containing Clojure a source code tree for LibA
on the classpath for ProjB then you should be able to replace the
files without changing any classpath.

> presumably people co-developing clojure-contrib and clojure core have
> this same issue?
> it looks like clojure is brought into the clojure-contrib as a system
> dependency under a build profile... seems do-able for my problem, are
> there pro's and con's to any alternatives?

-- 
Michael Wood 

-- 
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: New Primitive data types (equal branch) - impact on optimized code.

[j-g-faustus]

I did:
"Java arrays 18s" is Java arrays in Clojure.
"Plain Java 2s" is Java arrays in Java.

Here's the Java code: http://gist.github.com/460063

That's what you meant, right?

I agree that it looks very good :)

"Mutable deftype" is a special case in that apart from the dotimes
loop counter all numeric operations are done internally in a single
mutable deftype instance, but it is still very good - in this scenario
there was close to zero overhead from using Clojure.



On Jul 1, 4:29 pm, Nicolas Oury  wrote:
> On Thu, Jul 1, 2010 at 2:27 AM, j-g-faustus 
> wrote:
>
> > Using the equiv branch, I get
> > * Java arrays: 18s
> > * Immutable deftype: 10s
> > * Mutable deftype: 2s
> > * Plain Java: 2s
>
> That's a very encouraging result! That proves that the equiv branch, and
> deftypes, can be as fast as java.
>
> Could you test an array in Plain Java to compare what comes from arrays and
> what comes from array access 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: New Primitive data types (equal branch) - impact on optimized code.

[Heinz N. Gies]

> I did:
> "Java arrays 18s" is Java arrays in Clojure.
> "Plain Java 2s" is Java arrays in Java.
One reason here is that clojures literals as 1 2 and 3 you use for array 
indexes are longs, the aget methods want int's so you've funny casting there 
which is slow for comparison I've done it on a private test thingy where I use 
longs as array indexes:

user=> (time-mtype)
(500.00 1000.00 1500.01)
Bye from Clojure
"Elapsed time: 245.152 msecs"
nil
user=> (time-type)
(500.00 1000.00 1500.01)
Bye from Clojure
"Elapsed time: 1360.897 msecs"
nil
user=> (time-arr)
(500.00 1000.00 1500.01)
Bye from Clojure
"Elapsed time: 2029.323 msecs"
nil

Regards,
Heinz

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Managing the classpath

[Daniel Gagnon]

That's really convenient to know! I just symlinked clojure.jar to
/usr/share/java where all the java jars are on k/ubuntu and now I just have
to have those two lines in my .bashrc file:

export CLASSPATH=.:/usr/share/java/*
alias clj="rlwrap java clojure.main"

On Thu, Jul 1, 2010 at 10:29 AM, Laurent PETIT wrote:

> Hello,
>
> note that with java 6 you can specify at once to add all the jars
> located in a directory:
>
> java -cp "libs/*" clojure.main
>
>

-- 
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: Managing the classpath

[Kevin Livingston]

> If you have a directory containing Clojure a source code tree for LibA
> on the classpath for ProjB then you should be able to replace the
> files without changing any classpath.

right, I've just been trying to figure out how to do that in Maven
when LibA and ProjB are separate projects (with separate poms), so
that clojure-maven will pass on the right classpath to swank.
(presumably it's going to require monkeying with the ProjB pom, so
that is aware of where the LibA source code resides - in developer
mode)

Kevin

-- 
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: Managing the classpath

[Paul Moore]

On 1 July 2010 15:29, Laurent PETIT  wrote:
> Hello,
>
> note that with java 6 you can specify at once to add all the jars
> located in a directory:
>
> java -cp "libs/*" clojure.main
>
> and you can place any jar you want in directory libs.
>
> and this is composable:
>
> java -cp "clojure.jar:libs/*" clojure.main
>
> My 0.02€, just in case you didn't know this (rather recent) possibility.

Thanks. I had actually just discovered this possibility in the last
few days. In fact, it is what raised in my mind the question of
whether having too many jars on the classpath would hurt performance.
I've not yet fully integrated the idea into my thinking.

I guess it allows the possibility of bundling all application
dependencies into a lib directory, then doing something like java -cp
"clojure.jar;lib/*" clojure.main myapp.clj

But in practical terms, I guess that's the equivalent of an uberjar.
(My biggest concern about an uberjar is that I end up with each app
having a separate bundled copy of all its dependencies. That makes
version management a huge pain - imagine a bugfix release of
clojure.jar - but is otherwise not an unreasonable option).

Paul.

-- 
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: New Primitive data types (equal branch) - impact on optimized code.

[Greg]

Ooo... sorry for the side-question, but I noticed that your code doesn't seem 
to use coercions for primitives and uses type-hints instead.

I was just asking the other day on #clojure why Clojure had coercion functions 
at all and why type hints didn't work for primitives, does this mean 1.2 will 
get rid of coercions (or make them no longer necessary) and allow type-hints 
for primitives?

If so, that's really awesome. :-D

On Jun 30, 2010, at 9:27 PM, j-g-faustus wrote:

> I'm getting some form of boxing during array access, even on the equiv
> branch.
> 
> Speaking of which: (type (+ 1N 1)) => clojure.lang.BigInt means that
> I'm using the correct branch, right?
> 
> Here is a simple speed test comparing 3-element vectors using Java
> arrays, immutable deftype and mutable deftype:
> http://gist.github.com/459383
> 
> Using the equiv branch, I get
> * Java arrays: 18s
> * Immutable deftype: 10s
> * Mutable deftype: 2s
> * Plain Java: 2s
> 
> Here is a profiler snapshot for the array case, where
> java.lang.Number.init(), java.lang.Double.init() and
> java.lang.Double.valueOf() take a significant chunk of the CPU time:
> http://i589.photobucket.com/albums/ss334/j-g-faustus/profiling/eqv-arrays.png
> 
> From a practical standpoint I guess it means that deftype is the way
> to go if you want fast numbers today.
> In this case even the immutable deftype was faster than mutable Java
> arrays, so you can be fast, idiomatic and thread-safe simultaneously.
> 
> For the future, it would be nice if Java arrays were equally fast.
> There is unchecked-inc-int and -long, would there be room for an
> unchecked-aget/aset-int/long/double?
> 
> 
> Regards
> jf
> 
> 
> On Jun 30, 6:14 pm, David Nolen  wrote:
>> On Wed, Jun 30, 2010 at 10:19 AM, j-g-faustus
>> wrote:
>> 
>> On the equiv branch I don't see this at all. Also on the equiv branch most
>> of your type hints inside the fn are unnecessary.
>> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Managing the classpath

[Paul Moore]

On 1 July 2010 16:49, Kevin Livingston  wrote:
> Some of the build tools like Maven can help a lot.

(Thanks for your other comments, which I've cut. But this one made me think).

I've heard comments like this elsewhere (with regard to both Maven and
Leiningen), but I'm not quite sure I follow. You say

[...]
> put the jar on ProjB's class path

But as I understand it, ProjB doesn't *have* a classpath in its own
right - rather, when you run ProjB, you specify a classpath (and if
you get it wrong, ProjB won't run). But there's no concrete,
discoverable entity that can be considered "ProjB's classpath", and
referenced from elsewhere. Otherwise, the often-quoted clj.bat driver
script could be written as

Get %1's classpath into CLASSPATH somehow
java clojure.main %1

and nobody would ever worry about classpaths again :-)

If Maven (and/or Leiningen) actually do maintain, for each project,
metadata including its required classpath, then I'd love to know how
to extract that metadata - because I could certainly use it to write a
generic driver script (at least for my own purposes, even if it wasn't
sufficiently general for every use).

Paul.

-- 
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 1.2: Unicode string length bug?

[ngocdaothanh]

With 1.2-master-SNAPSHOT:

(def t "車馬象士將士象馬車")
(count t)  ; => 27
(.length t)  ; => 27

With 1.1, the result is 9.

-- 
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 1.2: Unicode string length bug?

[Stuart Halloway]

I see 9 on 1.2 as well. The call to .length is a Java interop form, so it is 
very difficult to imagine how this might change.

Stu

> With 1.2-master-SNAPSHOT:
> 
> (def t "車馬象士將士象馬車")
> (count t)  ; => 27
> (.length t)  ; => 27
> 
> With 1.1, the result is 9.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: New Primitive data types (equal branch) - impact on optimized code.

[j-g-faustus]

On Jul 1, 6:24 pm, "Heinz N. Gies"  wrote:
> One reason here is that clojures literals as 1 2 and 3 you use for array 
> indexes are longs, the aget methods want int's

Agreed. If we can take the profiling snapshot I linked to at face
value, the boxing and casting adds up to ~40% of the CPU time.
Given that the speed difference between Java arrays in Java and in
Clojure is ~9x (900%), there are probably other factors here as well.

Just note that the REPL timings you are listing are for N=50 million.
My "18s vs 2s" timings are from the command line with N=500 million
and include JVM startup time. (So that I could compare it to plain
Java.)

But your private fix apparently got the relative speed difference down
to ~8x, which is an improvement.


Regards
jf


On Jul 1, 6:24 pm, "Heinz N. Gies"  wrote:
> > I did:
> > "Java arrays 18s" is Java arrays in Clojure.
> > "Plain Java 2s" is Java arrays in Java.
>
> One reason here is that clojures literals as 1 2 and 3 you use for array 
> indexes are longs, the aget methods want int's so you've funny casting there 
> which is slow for comparison I've done it on a private test thingy where I 
> use longs as array indexes:
>
> user=> (time-mtype)    
> (500.00 1000.00 1500.01)
> Bye from Clojure
> "Elapsed time: 245.152 msecs"
> nil
> user=> (time-type)
> (500.00 1000.00 1500.01)
> Bye from Clojure
> "Elapsed time: 1360.897 msecs"
> nil
> user=> (time-arr)
> (500.00 1000.00 1500.01)
> Bye from Clojure
> "Elapsed time: 2029.323 msecs"
> nil
>
> Regards,
> Heinz

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: New Primitive data types (equal branch) - impact on optimized code.

[j-g-faustus]

On Jul 1, 5:42 pm, Greg  wrote:
> Ooo... sorry for the side-question, but I noticed that your code doesn't seem 
> to use coercions for primitives and uses type-hints instead.
>
> I was just asking the other day on #clojure why Clojure had coercion 
> functions at all and why type hints didn't work for primitives, does this 
> mean 1.2 will get rid of coercions (or make them no longer necessary) and 
> allow type-hints for primitives?

Beats me, I'm just following the example from David Nolen earlier in
this thread :)

Seriously, I'm just starting out with Clojure (a few weeks) and this
is my way to get to know the language, so I'm not the right person to
ask. I may have made mistakes in my code, and will be happy to be
corrected.

Still, it looks like 1.2 may get type hints:

> ^long and ^double hints allowed on args
> other reference type hints allowed as well
> unlike for non-statics, these will be enforced.

>From http://www.assembla.com/wiki/show/clojure/Enhanced_Primitive_Support

But note also the start of the page:
> This work is not promised to become part of Clojure, as is or otherwise, now 
> or in the future.

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

Benchmarking clojure code

[Mike Meyer]

On [many an occasion] "Many people" wrote:

> user=> (time foo)
...
> "Elapsed time: 245.152 msecs"

I hate to be a wet blanket, but how accurate is this? The doc doesn't
even say whether it measures wall clock time or cpu time. Even if you
knew that, it's at best a foundation to build a real benchmarking
system on.

By "real benchmarking" I mean one that does things like run the
benchmark a few times to fill caches and let the JIT do it's thing,
etc., makes sure it runs the target code enough times to get a chunk
of time large enough to means something, and takes into account the
overhead of making multiple runs. Now do that a dozen or so times so
you can take some stats, so when you compare two timings you actually
have enough information to decide if one is really faster than the
other, or the difference is just fuzz in the measurement system.

Ok, I started building something like that, and immediately started
getting ludicrous results. Googling for Java benchmarks turned up
exactly *one* such tool (which presumably works on any runnable or
callable, but fails on Clojure functions) amongst the sets of
benchmark code (most of which didn't talk about how they measured the
time).

First thing: a timer that returns the time so I can work with it:

(defmacro nano-timer "Time body, returning nanoseconds and result"
  [body] `(do
(System/runFinalization)
(System/gc)
(let [start# (System/nanoTime)
  res# ~body]
  [(- (System/nanoTime) start#) res#])))

Second thing: run the benchmark many times, subtracting out the loop
overhead:

(defmacro loop-timer
  "Time code in a loop, returning nanoseconds taken minus loop overhead"
  [code count] `(let [overhead# (first (nano-timer (dotimes [_# ~count])))
  mytime# (first (nano-timer (dotimes [_# ~count] ~code)))]
  (- mytime# overhead#)))


Which has the annoying habit of returning negative numbers :-(. I'd
really like to know how the loop that calculates overhead takes more
time than the loop that actually runs the code, no matter how trivial
the code is!

Is anyone using anything more sophisticated than clojure.core/time for
benchmarking clojure code?

http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure 1.2: Unicode string length bug?

[ngocdaothanh]

I'm on Snow Leopard. I think there's something wrong with Terminal

-
$ java -cp clojure-1.2.0-master-20100623.220259-87.jar clojure.main
Clojure 1.2.0-master-SNAPSHOT
user=> (def t "車馬象士將士象馬車")
#'user/t
user=> t
"車馬象士將士象馬車"
user=> (count t)
27
user=> (.length t)
27
-

But if I save to a file and run that file, then the result is correct.


On Jul 2, 1:59 am, Stuart Halloway  wrote:
> I see 9 on 1.2 as well. The call to .length is a Java interop form, so it is 
> very difficult to imagine how this might change.
>
> Stu
>
>
>
> > With 1.2-master-SNAPSHOT:
>
> > (def t "車馬象士將士象馬車")
> > (count t)  ; => 27
> > (.length t)  ; => 27
>
> > With 1.1, the result is 9.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure 1.2: Unicode string length bug?

[Peter Schuller]

> I see 9 on 1.2 as well. The call to .length is a Java interop form, so it is 
> very difficult to imagine how this might change.

My guess is rather that the string is interpreted differently by the
reader; the 27 is almost certainly correct; the question is how the
string is originally constructed.

I had a very quick look at LispReader (not its history) and didn't see
anything obvious (in 30 seconds anyway). What are the chances the
reader has changed with respect to assumptions about the encoding of
*in*?

The behavior experienced by the OP may be the result of his native
system encoding being, say, shift_JIS or something which is then
interpreted as, say, UTF-8 and luckily/unluckily not failing, instead
producing a valid unicode string of length 27.

-- 
/ Peter Schuller

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure 1.2: Unicode string length bug?

[Greg]

Although I'm not exactly sure what's going on, I think this is likely an 
encoding issue and perhaps also an issue with how you're running that code.

Check how you're running this code, is it in a file or are you entering it in a 
terminal?

In my experimentation, for both 1.1 and 1.2, if I run this code in the terminal 
I'll get 27 as the answer. Why, I'm not sure, but it may have to do with the 
fact that my terminal is UTF-8.

However, if this is loaded by clojure from a file, it will return 9 for both 
1.1 and 1.2, even though the file is stored as UTF-8 as well.

The story gets weirder though, because although Java strings are UTF-16 
(*ugh*), if I save the source to a UTF-16 encoded file, clojure will throw an 
exception and won't even be able to read it:

Exception in thread "main" java.lang.Exception: Unable to resolve 
symbol: ?? in this context (test-utf16.clj:0)

So, this is weird and I'd love it if someone could explain what's going on, but 
I don't think this has to do with the clojure version (at least in my testing).

- Greg

On Jul 1, 2010, at 12:59 PM, Stuart Halloway wrote:

> I see 9 on 1.2 as well. The call to .length is a Java interop form, so it is 
> very difficult to imagine how this might change.
> 
> Stu
> 
>> With 1.2-master-SNAPSHOT:
>> 
>> (def t "車馬象士將士象馬車")
>> (count t)  ; => 27
>> (.length t)  ; => 27
>> 
>> With 1.1, the result is 9.
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure 1.2: Unicode string length bug?

[Wilson MacGyver]

I assume you are doing this from command line?
it's very likely your terminal is escaping non-ASCII characters
for you.

I get 27 using 1.1 and 1.2 snapshot using command line REPL

but if I run it from a source file, it's fine. and I get 9.

2010/7/1 ngocdaothanh :
> With 1.2-master-SNAPSHOT:
>
> (def t "車馬象士將士象馬車")
> (count t)  ; => 27
> (.length t)  ; => 27
>
> With 1.1, the result is 9.
>
> --
> 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



-- 
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: Clojure 1.2: Unicode string length bug?

[Peter Schuller]

> I'm on Snow Leopard. I think there's something wrong with Terminal

So my guess is that for some reason the terminal is not using the same
encoding as whatever is expected by Java (presumably Java looks at
LANG and friends).

-- 
/ Peter Schuller

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Benchmarking clojure code

[Peter Schuller]

> Is anyone using anything more sophisticated than clojure.core/time for
> benchmarking clojure code?

No, but last time I thought about this I figured a very simple
(benchmark ...) would simply:

* Iterate with exponentially higher repeat counts until total runtime
reaches >= 1 second (say).
* Then, iterate with the same count until the timing over some period,
say 10 seconds, has a sufficiently low standard deviation.
* Then, take that repeat count and re-run enough to reach, say, 10
seconds, of time.

Obviously the 1, 10 and std dev thesholds would be selectable, with
some default. So that in the normal case for micro-benchmarking, you'd
just do:

   (benchmark (run-my-stuff))

And it would usually "just work" even if run-my-stuff is a trivial
function that completes really really quickly (due to the exponential
growth).

Thoughts? It's obviously not meant for really serious benchmarking,
but I think it would be a good thing to have in cases where one might
now otherwise use (time ..).

-- 
/ Peter Schuller

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure 1.2: Unicode string length bug?

[Kevin Downey]

java on macs has Mac Roman as the default file encoding

On Thu, Jul 1, 2010 at 10:46 AM, Peter Schuller
 wrote:
>> I'm on Snow Leopard. I think there's something wrong with Terminal
>
> So my guess is that for some reason the terminal is not using the same
> encoding as whatever is expected by Java (presumably Java looks at
> LANG and friends).
>
> --
> / Peter Schuller
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

-- 
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: Benchmarking clojure code

[Mike Meyer]

On Thu, 1 Jul 2010 19:51:06 +0200
Peter Schuller  wrote:

> > Is anyone using anything more sophisticated than clojure.core/time for
> > benchmarking clojure code?
> 
> No, but last time I thought about this I figured a very simple
> (benchmark ...) would simply:
> 
> * Iterate with exponentially higher repeat counts until total runtime
> reaches >= 1 second (say).
> * Then, iterate with the same count until the timing over some period,
> say 10 seconds, has a sufficiently low standard deviation.
> * Then, take that repeat count and re-run enough to reach, say, 10
> seconds, of time.
> 
> Obviously the 1, 10 and std dev thesholds would be selectable, with
> some default. So that in the normal case for micro-benchmarking, you'd
> just do:
> 
>(benchmark (run-my-stuff))
> 
> And it would usually "just work" even if run-my-stuff is a trivial
> function that completes really really quickly (due to the exponential
> growth).
> 
> Thoughts? It's obviously not meant for really serious benchmarking,
> but I think it would be a good thing to have in cases where one might
> now otherwise use (time ..).

This is pretty much where I was heading when I started writing those
two macros. Wanting to be able to time very short runtimes without
timing the loop, I wrote loop-timer to deal with loop overhead. Only
to have it return negative values in the process of trying to get a
reasonable total run time. This makes that process, um, interesting.

http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure 1.2: Unicode string length bug?

[Michael Wood]

On 1 July 2010 19:46, Peter Schuller  wrote:
>> I'm on Snow Leopard. I think there's something wrong with Terminal
>
> So my guess is that for some reason the terminal is not using the same
> encoding as whatever is expected by Java (presumably Java looks at
> LANG and friends).

Just for comparison, on Linux with a UTF8 locale, Python gives similar results:

$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "車馬象士將士象馬車"
'\xe8\xbb\x8a\xe9\xa6\xac\xe8\xb1\xa1\xe5\xa3\xab\xe5\xb0\x87\xe5\xa3\xab\xe8\xb1\xa1\xe9\xa6\xac\xe8\xbb\x8a'
>>> len("車馬象士將士象馬車")
27
>>> u"車馬象士將士象馬車"
u'\u8eca\u99ac\u8c61\u58eb\u5c07\u58eb\u8c61\u99ac\u8eca'
>>> len(u"車馬象士將士象馬車")
9
>>> len("車馬象士將士象馬車".decode("utf8"))
9
>>>

-- 
Michael Wood 

-- 
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: explode string

[Martin DeMello]

On Thu, Jul 1, 2010 at 7:19 PM, Nicolas Oury  wrote:
>
> Random advices for speed or simplicity:
> 1. don't split the string but loop on the index of the string in the code
> that insert it in the trie

That's a nice idea. Will give it a go.

> 2. Use transients for the nodes of your tries

Never used transients, but from reading the docs they might be exactly
what I need, both for trie construction and for pattern matching.

> 3. Do not hash one char per one char but convert 8 chars into a long (if you
> use only ASCII chars, 4 chars to a long else)
> 4. Have you tried (for simplicity) to directly use a Clojure Map or Set
> instead of your trie for a dictionnary.

Won't work, I need to do wildcard lookups, otherwise you're right, a
set would have been my best option.

martin

-- 
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: Benchmarking clojure code

[Hugo Duncan]

On Thu, 01 Jul 2010 13:44:25 -0400, Mike Meyer  
 wrote:



Is anyone using anything more sophisticated than clojure.core/time for
benchmarking clojure code?


I wrote a benchmarking lib at http://github.com/hugoduncan/criterium

The references in the README are worth checking.

You might also find Lau's blog post of interest:  
http://www.bestinclass.dk/index.clj/2010/03/functional-fluid-dynamics-in-clojure.html


--
Hugo Duncan

--
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: Benchmarking clojure code

[Heinz N. Gies]

On Jul 1, 2010, at 21:21 , Hugo Duncan wrote:

> On Thu, 01 Jul 2010 13:44:25 -0400, Mike Meyer 
>  wrote:
> 
>> Is anyone using anything more sophisticated than clojure.core/time for
>> benchmarking clojure code?
> 
> I wrote a benchmarking lib at http://github.com/hugoduncan/criterium
Actually the initial thing I started did not even use time I used a very flawed 
method using 'time java -cp ...' But I did this on purpose since my goal was to 
benchmark clojure in comparison to Scala (or other languages) where neither 
(time) nor creterium are useable since it is language specific.

Regards,
Heinz

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Benchmarking clojure code

[Mike Meyer]

On Thu, 01 Jul 2010 15:21:03 -0400
"Hugo Duncan"  wrote:

> On Thu, 01 Jul 2010 13:44:25 -0400, Mike Meyer  
>  wrote:
> 
> > Is anyone using anything more sophisticated than clojure.core/time for
> > benchmarking clojure code?
> 
> I wrote a benchmarking lib at http://github.com/hugoduncan/criterium
> 
> The references in the README are worth checking.

I'd seen the Elliptic group posting.

This looks nice, but doesn't work with 1.1 :-(. Do you know the last
commit that did?

Better yet, can I talk you into posting a 1.1 jar file to the
downloads area, maybe along with a 1.2 RC, so users who aren't
comfortable with the Java infrastructure
(http://www.mired.org/home/mwm/papers/simple-clojure.html) can play
along?

Thanks,
 http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Managing the classpath

[Luc Préfontaine]

We have over 130 jar dependencies
on our classpath and performance is
not an issue. After the classes you
are using are loaded at least once,
there are no significant impacts.

Each app refers to the same shared lib
folder so we update a single jar and
get every app gets the update after
a restart.

Very different from a uberjar.
Every uberjar would have to
be repackaged to include the updated
jar.

We use uberjars to deliver desktop
apps. We do not update these as
often as the back end and avoid
dealing with the desktop
environment as much as possible.

Back end stuff use the shared
jar folder.

Luc P

Sent from my iPod

On 2010-07-01, at 10:49, Paul Moore  wrote:


On 1 July 2010 15:29, Laurent PETIT  wrote:

Hello,

note that with java 6 you can specify at once to add all the jars
located in a directory:

java -cp "libs/*" clojure.main

and you can place any jar you want in directory libs.

and this is composable:

java -cp "clojure.jar:libs/*" clojure.main

My 0.02€, just in case you didn't know this (rather recent) possib 
ility.


Thanks. I had actually just discovered this possibility in the last
few days. In fact, it is what raised in my mind the question of
whether having too many jars on the classpath would hurt performance.
I've not yet fully integrated the idea into my thinking.

I guess it allows the possibility of bundling all application
dependencies into a lib directory, then doing something like java -cp
"clojure.jar;lib/*" clojure.main myapp.clj

But in practical terms, I guess that's the equivalent of an uberjar.
(My biggest concern about an uberjar is that I end up with each app
having a separate bundled copy of all its dependencies. That makes
version management a huge pain - imagine a bugfix release of
clojure.jar - but is otherwise not an unreasonable option).

Paul.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient  
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Managing the classpath

[j-g-faustus]

On Jul 1, 4:49 pm, Paul Moore  wrote:
> (My biggest concern about an uberjar is that I end up with each app
> having a separate bundled copy of all its dependencies. That makes
> version management a huge pain - imagine a bugfix release of
> clojure.jar - but is otherwise not an unreasonable option).
>
> Paul.

In my former life in a Java shop, that's what we ended up doing:
Bundling everything with every app, up to and including Java. You may
notice that this is what apps like NetBeans and Eclipse are doing as
well.

Because the alternative is worse: Do you really want to depend on
whatever random version of Java or external libraries a user may or
may not have installed on their computer?
What do you do when app A needs lib-1.1 while your new and improved
app B needs lib-1.2, but lib-1.2 unfortunately breaks app A?
It's the Java version of the "DLL Hell" in early Windows.

I'm not up to date with developments since Java 1.5, but I expect that
bundling everything with every app is still the cleanest option
overall. At least for standalone applications.
If it is more like a bundle of utilities that get upgraded all at once
or not at all, it makes sense to treat them as one app that shares the
same set of resources.


jf

-- 
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: Benchmarking clojure code

[j-g-faustus]

On Jul 1, 7:51 pm, Peter Schuller  wrote:
> > Is anyone using anything more sophisticated than clojure.core/time for
> > benchmarking clojure code?

Criterium, a benchmarking library for Clojure, seems pretty good:
http://github.com/hugoduncan/criterium

Based on ideas in this article:
http://www.ibm.com/developerworks/java/library/j-benchmark1.html

The stackoverflow question where I found it, thanks to Michal Marczyk:
http://stackoverflow.com/questions/3041299/how-to-benchmark-functions-in-clojure


Getting *accurate* results can be hard, even with a benchmarking
library. Criterium runs the code 60 times and does statistical
analysis on the results, but I can still get variations above +/-10%
from run to run in the REPL.

I think benchmarking works best when
* starting a new run each time - i.e. from the command line, a "clean
slate" JVM
* having something that runs long enough to stabilize the JVM -
Criterium wants 1 min or more total runtime.
* running it more than once and checking that results are tolerably
consistent
* looking for differences in orders of magnitude rather than a couple
of percent more or less.

I suppose the good news is that differences in orders of magnitude (1x
vs 10x vs 100x) tend to stand out and do not need anything
particularly scientific apart from running it long enough a few times.

-- 
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: an anonymous recursive function

[Tim Robinson]

Hi folks,
I found some time this morning to look at this:

Mikes Letfn example worked out best for me:

>
(defmacro anaphoric-recur [parm-binds parms & body]
   "An anaphoric recursive function that takes a vector of blind
bindable vars, parameters and a function that can handle the
bindable vars. 'self' is used to call the function recursively."
  `(letfn [(~'self ~parm-binds
 (do ~...@body))]
   (~'self ~parms)))

> (anaphoric-recur [x] 5 (if (= x 0) 1 (* 2 (self (dec x)
32

To answer Mike on CL or scheme?,
This is roughly equivalent to the arc 'afn' function (a scheme
variation).

Thanks everyone.
Tim

On Jun 30, 2:13 pm, Tim Robinson  wrote:
> Thanks for all the replies. Sorry if my responses are delayed. I'm
> still on newb moderation mode, so I find my response can take 2 - 10
> hours to be published.
>
> > note that z is free in that expression, which looks suspicious.
>
> yup, it was supposed to be x. It was a copy paste error. I normally
> would evaluate the function, but in this case I was expecting errors.
>
> As for acc or other options, I was hoping to create a recursive fn
> that could generically accept an anonymous function as an argument,
> which was what I was
> thinking.
>
> Using a form like:
>
> ((recursive-fn #(do-stuff (self (dec %))) (recur self))  5)
>
> (obviously not the way - just the notion)
>
> kind of thing.
>
> When I am home tonight I can play aorund with the examples provided.
>
> Thanks,
> Tim
>
> On Jun 30, 8:59 am, Dominic Cooney  wrote:
>
>
>
> > If you name the Y combinator, then you can write recursive anonymous 
> > functions:
>
> > 
>
> > You can't use Clojure's recur as written because it isn't in tail
> > position--the result of the function isn't just the value of the recur
> > expression (in the first instance it is (* 2 (recur ...)) however I
> > note that z is free in that expression, which looks suspicious.
>
> > If your goal is to define a function that computes 2^n with
> > tail-recursion, then consider threading an "accumulator" parameter
> > through the recursive function; something like this:
>
> > ((fun [acc x]
> >     (if (= x 0)
> >       acc
> >       (recur (* 2 acc) (dec x))) 1 5)
>
> > Of course, you might consider a helper wrapper function that supplies
> > the 1 "default" accumulator.
>
> > Many functional languages optimize tail calls to jmp instructions;
> > that's hard to do efficiently in general on the JVM because it doesn't
> > support tail calls. I expect Clojure has designed recur to work the
> > way it does because some algorithms depend on the tail call
> > optimization, but the restrictions of recur make it possible to
> > compile efficiently as a jmp. So it's a nice compromise.
>
> > 
>
> > HTH,
>
> > Dominic
>
> > On Wed, Jun 30, 2010 at 2:44 PM, Tim Robinson  
> > wrote:
> > > So I am reading On Lisp + some blogs while learning Clojure (I know,
> > > scary stuff :)
>
> > > Anyway, I've been playing around to see if I can get an anonymous
> > > recursive function to work, but alas I am still a n00b and not even
> > > sure what Clojure's approach to this would be.
>
> > > How would I do this in Clojure?:
>
> > > My first attempt:
>
> > > ((fn [x]
> > >   (if (= x 0)
> > >       1
> > >       (* 2 (recur (dec z) 5)
>
> > > Then my second:
>
> > > ((fn [x]
> > >       (let [z (if (= x 0)
> > >                   1
> > >                   (* 2 x))]
> > >          (recur (dec z  5)
>
> > > Ideally one could do:
>
> > > ((recursive-fn #( if (= % 0) 1 (* 2 %)) (recur it))  5)
>
> > > Obviously none work, and I believe I understand why. I just don't
> > > understand how to actually do this or if for some reason Clojure
> > > avoids this for some reason.
>
> > > I am not actually trying to accomplish a specific task, so the example
> > > was made to be simple not meaningful. I'm just playing around to learn
> > > recursive functions and Clojure style.
>
> > > Thanks,
> > > Tim
>
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with 
> > > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+unsubscr...@googlegroups.com
> > > For more options, visit this group at
> > >http://groups.google.com/group/clojure?hl=en

-- 
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: an anonymous recursive function

[Tim Robinson]

and now  corrected!

(defmacro anaphoric-recur [parm-binds expr & parms]
"An anaphoric recursive function that takes a vector of blind
 bindable vars, an expression that can handle the bindable vars.
 and the parameters. 'self' is used to call the function
recursively."
  `(letfn [(~'self ~parm-binds
 (do ~expr))]
   (~'self ~...@parms)))

> (anaphoric-recur [x] (if (= x 0) 1 (* 2 (self (dec x 5)
32

On Jun 30, 2:13 pm, Tim Robinson  wrote:
> Thanks for all the replies. Sorry if my responses are delayed. I'm
> still on newb moderation mode, so I find my response can take 2 - 10
> hours to be published.
>
> > note that z is free in that expression, which looks suspicious.
>
> yup, it was supposed to be x. It was a copy paste error. I normally
> would evaluate the function, but in this case I was expecting errors.
>
> As for acc or other options, I was hoping to create a recursive fn
> that could generically accept an anonymous function as an argument,
> which was what I was
> thinking.
>
> Using a form like:
>
> ((recursive-fn #(do-stuff (self (dec %))) (recur self))  5)
>
> (obviously not the way - just the notion)
>
> kind of thing.
>
> When I am home tonight I can play aorund with the examples provided.
>
> Thanks,
> Tim
>
> On Jun 30, 8:59 am, Dominic Cooney  wrote:
>
>
>
> > If you name the Y combinator, then you can write recursive anonymous 
> > functions:
>
> > 
>
> > You can't use Clojure's recur as written because it isn't in tail
> > position--the result of the function isn't just the value of the recur
> > expression (in the first instance it is (* 2 (recur ...)) however I
> > note that z is free in that expression, which looks suspicious.
>
> > If your goal is to define a function that computes 2^n with
> > tail-recursion, then consider threading an "accumulator" parameter
> > through the recursive function; something like this:
>
> > ((fun [acc x]
> >     (if (= x 0)
> >       acc
> >       (recur (* 2 acc) (dec x))) 1 5)
>
> > Of course, you might consider a helper wrapper function that supplies
> > the 1 "default" accumulator.
>
> > Many functional languages optimize tail calls to jmp instructions;
> > that's hard to do efficiently in general on the JVM because it doesn't
> > support tail calls. I expect Clojure has designed recur to work the
> > way it does because some algorithms depend on the tail call
> > optimization, but the restrictions of recur make it possible to
> > compile efficiently as a jmp. So it's a nice compromise.
>
> > 
>
> > HTH,
>
> > Dominic
>
> > On Wed, Jun 30, 2010 at 2:44 PM, Tim Robinson  
> > wrote:
> > > So I am reading On Lisp + some blogs while learning Clojure (I know,
> > > scary stuff :)
>
> > > Anyway, I've been playing around to see if I can get an anonymous
> > > recursive function to work, but alas I am still a n00b and not even
> > > sure what Clojure's approach to this would be.
>
> > > How would I do this in Clojure?:
>
> > > My first attempt:
>
> > > ((fn [x]
> > >   (if (= x 0)
> > >       1
> > >       (* 2 (recur (dec z) 5)
>
> > > Then my second:
>
> > > ((fn [x]
> > >       (let [z (if (= x 0)
> > >                   1
> > >                   (* 2 x))]
> > >          (recur (dec z  5)
>
> > > Ideally one could do:
>
> > > ((recursive-fn #( if (= % 0) 1 (* 2 %)) (recur it))  5)
>
> > > Obviously none work, and I believe I understand why. I just don't
> > > understand how to actually do this or if for some reason Clojure
> > > avoids this for some reason.
>
> > > I am not actually trying to accomplish a specific task, so the example
> > > was made to be simple not meaningful. I'm just playing around to learn
> > > recursive functions and Clojure style.
>
> > > Thanks,
> > > Tim
>
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with 
> > > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+unsubscr...@googlegroups.com
> > > For more options, visit this group at
> > >http://groups.google.com/group/clojure?hl=en

-- 
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: Managing the classpath

[Alessio Stalla]

On 1 Lug, 17:47, Brian Schlining  wrote:
> > Where I struggle is with the practicalities of managing the classpath.
> > From what I can tell, there is no way of modifying the classpath from
> > a running Java/Clojure program (barring use of a custom classloader
> > which sounds like deep magic).
>
> There's URLClassLoader for loading classes at runtime. Javadocs are 
> athttp://java.sun.com/javase/6/docs/api/java/net/URLClassLoader.html. There's
> an old thread about using it 
> athttp://forums.sun.com/thread.jspa?threadID=300557&start=0&tstart=0

Using a classloader manually is sub-optimal because the rest of
Clojure, which doesn't know anything about the user-created
classloader, wouldn't use it to load classes; you'd have to use the
reflection API yourself to manipulate them.

I recently added to ABCL the possibility of modifying which
classloader to use, and to add to it dynamically new paths/URLs. I
suspect that doing the same for Clojure would be easy, if the points
where it loads classes are few - and they probably are.

> Groovy has a very elegant solution for adding dependencies (from Maven and
> Ivy repos) to scripts. Seehttp://groovy.codehaus.org/Grapes+and+grab(). If
> some astute Clojure hacker with far more time than I were to grok the grape
> code and create a similar dependency engine for Clojure, well it would
> greatly expand Clojure's use for scripting and likely solve many of the
> issues you're finding with CLASSPATH

That's really nice!

> > Python doesn't have these issues because (a) conventionally,
> > dependencies are installed into the site-packages directory which is
> > on the standard sys.path - it appears to me that the JVM doesn't have
> > such an "always available" install location,
>
> Actually there is such a thing. For most JRE's/JDK's drop the
> 'always-available-jars' in JRE_HOME/lib/ext. On Mac's you would place them
> in /Library/Java/Extensions. Keep in mind that this is generally discouraged
> in favor of setting the classpath on a per-application basis.

There's a reason for that being discouraged: if you install a new
version of the JRE/JDK, you'll have to copy your jars there by hand.
Since Java auto-updates itself, at least on Windows, that's quite
dangerous. Typically Java applications for end users come with a
launch script to set the classpath; perhaps a function to generate
such a script from Clojure would solve the problem in most cases?

Alessio

-- 
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: Managing the classpath

[Steve]

On Jul 1, 11:11 pm, Paul Moore  wrote:
>
> Where I struggle is with the practicalities of managing the classpath.
> From what I can tell, there is no way of modifying the classpath from
> a running Java/Clojure program (barring use of a custom classloader
> which sounds like deep magic). So, assuming that is right, I need to
> list my dependencies in advance, when I start the JVM (either by
> setting the CLASSPATH environment variable, or with the -classpath
> argument).
>

Making the classpath more manageable is one of the things OSGi
addresses (fine grained dependencies, versioning, runtime swapping of
libraries etc.). Last time I looked (which was quite a while ago)
there were issues with running clojure under OSGi, does anyone know if
that is still the case?

I think that a lot of the benefits that OSGi offers to Java
programmers are probably not as important for Clojure, however the
classpath/dependency management might still be useful.

- Steve

-- 
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: Benchmarking clojure code

[Mike Meyer]

On Thu, 1 Jul 2010 11:27:09 -0700 (PDT)
j-g-faustus  wrote:
> On Jul 1, 7:51 pm, Peter Schuller  wrote:
> > > Is anyone using anything more sophisticated than clojure.core/time for
> > > benchmarking clojure code?
> Criterium, a benchmarking library for Clojure, seems pretty good:
> http://github.com/hugoduncan/criterium

The author responded here.

> Based on ideas in this article:
> http://www.ibm.com/developerworks/java/library/j-benchmark1.html
> 
> The stackoverflow question where I found it, thanks to Michal Marczyk:
> http://stackoverflow.com/questions/3041299/how-to-benchmark-functions-in-clojure
> 
> 
> Getting *accurate* results can be hard, even with a benchmarking
> library. Criterium runs the code 60 times and does statistical
> analysis on the results, but I can still get variations above +/-10%
> from run to run in the REPL.
> 
> I think benchmarking works best when
> * starting a new run each time - i.e. from the command line, a "clean
> slate" JVM
> * having something that runs long enough to stabilize the JVM -
> Criterium wants 1 min or more total runtime.
> * running it more than once and checking that results are tolerably
> consistent
> * looking for differences in orders of magnitude rather than a couple
> of percent more or less.

Criterium (and the Java code based on the same ideas) has what looks
like a serious problem for microbenchmarking:

After figuring out how many times to execute the body to make it last
a minute, it times the execution of the loop that does this. Which
means the reported time includes loop overhead.

When I tried the obvious solution (time an empty loop and subtract
that value from the original) on top of time, it was sometimes
generating negative values, so the empty loop is taking more time than
the loop being timed. That's a pretty solid indication that timing the
target code was lost in the noise of timing the loop overhead.

Possibly trying this fix with all of criterium code to stabilize the
JVM would help with the problem. I'd fix it (pretty easy) and try
myself, but there's no 1.1 jar and the current sources require 1.2.

If nothing else adding code to measure the empty loop and punting if
the difference between that and the code loop is statistically
insignificant would seem like a good idea.

 http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to: an anonymous recursive function

[Mike Meyer]

On Thu, 1 Jul 2010 12:50:00 -0700 (PDT)
Tim Robinson  wrote:

> and now  corrected!
> 
> (defmacro anaphoric-recur [parm-binds expr & parms]
>   "An anaphoric recursive function that takes a vector of blind
>bindable vars, an expression that can handle the bindable vars.
>and the parameters. 'self' is used to call the function
> recursively."
>   `(letfn [(~'self ~parm-binds
>  (do ~expr))]
>(~'self ~...@parms)))
> 
> > (anaphoric-recur [x] (if (= x 0) 1 (* 2 (self (dec x 5)
> 32

Cool. I'd worry about using ~' to capture variables in a macro, except
rich hickey said that's intentional in
http://markmail.org/message/d6cubdwwxgjq4po6.

 http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Benchmarking clojure code

[Hugo Duncan]

On Thu, 01 Jul 2010 15:51:28 -0400, Mike Meyer  
 wrote:



This looks nice, but doesn't work with 1.1 :-(. Do you know the last
commit that did?


I'm not sure that I would be too confident on the correctness of any  
version that ran on 1.1.



Better yet, can I talk you into posting a 1.1 jar file to the
downloads area, maybe along with a 1.2 RC, so users who aren't
comfortable with the Java infrastructure
(http://www.mired.org/home/mwm/papers/simple-clojure.html) can play
along?


I would need to take the time to backport the lib from its existing  
state.  As far as I remember there is only very light defrecord usage to  
contend with.  I'm afraid it is not high priority for me at the moment.


I would also wonder how significant the loop overhead is, especially for  
comparing implementations of the same function, which would then have  
similar loop overhead.  It is interesting to time Thread/sleep calls with  
different sleep periods (not that sleep is going to be accurate itself,  
but a regression of loop count versus Criterium's measured time and the  
sleep time might be interesting).


Another issue with timing fast, simple functions is that jit can optimise  
a calculation to a constant if it is simple enough.


My major concern with Criterium would rather be on the percentage garbage  
collection time reported.  There still needs to be work done on removing  
the allocation of result structures from the body of the timed results.  I  
would expect that to have a bigger impact than the loop overhead.


Hugo


--
Hugo Duncan

--
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: Managing the classpath

[Brian Schlining]

>
>
> > There's URLClassLoader for loading classes at runtime. Javadocs are
> athttp://java.sun.com/javase/6/docs/api/java/net/URLClassLoader.html.
> There's
> > an old thread about using it athttp://
> forums.sun.com/thread.jspa?threadID=300557&start=0&tstart=0
>
> Using a classloader manually is sub-optimal because the rest of
> Clojure, which doesn't know anything about the user-created
> classloader, wouldn't use it to load classes; you'd have to use the
> reflection API yourself to manipulate them.
>

That's normally true, but if you look at the thread reference above it shows
you how to 'hack' the system classloader, so you can use the classes as if
they were loaded normally (on JVM startup)


> > Actually there is such a thing. For most JRE's/JDK's drop the
> > 'always-available-jars' in JRE_HOME/lib/ext. On Mac's you would place
> them
> > in /Library/Java/Extensions. Keep in mind that this is generally
> discouraged
> > in favor of setting the classpath on a per-application basis.
>
> There's a reason for that being discouraged: if you install a new
> version of the JRE/JDK, you'll have to copy your jars there by hand.
> Since Java auto-updates itself, at least on Windows, that's quite
> dangerous.


I agree it should be discouraged. Just FYI though, the current releases of
Java on Windows auto-updates in place.  So any jars you put in lib/ext will
still be there after the update. On Macs, Java updates have no effect on
/Library/Java/Extensions.

Cheers
-- 
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlin...@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: Benchmarking clojure code

[Aaron Cohen]

>
>
> If nothing else adding code to measure the empty loop and punting if
> the difference between that and the code loop is statistically
> insignificant would seem like a good idea.
>
>
It's actually notoriously hard to time the "empty loop" on the JVM. Once
you've iterated a few thousand times, the JIT will kick in and recognize the
loop does no work (or possibly even find a closed form solution for the loop
if there are simple math ops within it) and remove it entirely.

Cliff Click devotes entire talks to benchmarking in Java, how hard it is to
do correctly, and the common pitfalls:
http://www.azulsystems.com/events/javaone_2009/session/2009_J1_Benchmark.pdf

-- 
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: Benchmarking clojure code

[Mike Meyer]

On Thu, 1 Jul 2010 23:39:16 -0400
Aaron Cohen  wrote:

> > If nothing else adding code to measure the empty loop and punting if
> > the difference between that and the code loop is statistically
> > insignificant would seem like a good idea.
> It's actually notoriously hard to time the "empty loop" on the JVM. Once
> you've iterated a few thousand times, the JIT will kick in and recognize the
> loop does no work (or possibly even find a closed form solution for the loop
> if there are simple math ops within it) and remove it entirely.

If it tosses out your empty loop, then you're back where you started -
timing the loop as well as the operation.

If it finds the closed form solution for the real loop - that would
explain the results I'm seeing.

> Cliff Click devotes entire talks to benchmarking in Java, how hard it is to
> do correctly, and the common pitfalls:
> http://www.azulsystems.com/events/javaone_2009/session/2009_J1_Benchmark.pdf

()#*$Q#% PPT. But I think some of the ideas can be incorporated

Thanks,
 http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Benchmarking clojure code

[Peter Schuller]

WIth regards to benchmarking that accurately discounts loop overhead;
it seems to me that even if you apply elaborate logic, if the thing
you're benchmarking is so small that looping overhead becomes
significant, you risk making the benchmark subject to subtle
variations anyway,
-- 
/ Peter Schuller

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Benchmarking clojure code

[Peter Schuller]

> WIth regards to benchmarking that accurately discounts loop overhead;
> it seems to me that even if you apply elaborate logic, if the thing
> you're benchmarking is so small that looping overhead becomes
> significant, you risk making the benchmark subject to subtle
> variations anyway,

Oops, sorry. I started writing something and meant to discard it, but
accidentally hit send...

-- 
/ Peter Schuller

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en