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
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
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
f
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 (transie
(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
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
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))
>> (pe
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 worthwhil
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:
>
> (
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
op
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 loo
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 th
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 Exception
> 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
> 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
> 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 t
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
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
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 Goog
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 tes
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
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:
>
>
>
> 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
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...
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
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 nu
> 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 p
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, Laur
> 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 se
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:lib
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
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
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 m
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
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.
G
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
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 b
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
> 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 construct
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 th
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:
>
>
> 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 sub
> 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).
* The
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 Jav
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 h
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 compariso
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 u
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
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 t
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/criteri
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
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
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.i
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
bindabl
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."
`(
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).
>
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, assumi
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.c
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 th
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 fi
>
>
> > 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
>
>
> 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,
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"
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 Schulle
> 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, so
65 matches
Mail list logo
