a question about using the delay macro
hi clojure-community, yesterday i came across the following use of the delay-macro: (defn pooled-data-source [db-connection-settings] ; this Fn creates and returns object of type PooledDataSource ) (defn pooled-data-source-as-singleton [db-connection-settings] (let [datasource (delay (pooled-data-source db-connection- settings))] @datasource)) i am not sure, what the exact semantic of this is and if it's safe in a multithreaded context. What is the difference to using def/defonce ? Someone who can explain ? thanks & have a nice time -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: a question about using the delay macro
Hi,
Am Montag, 22. August 2011 11:53:32 UTC+2 schrieb faenvie:
>
> yesterday i came across the following use of
> the delay-macro:
>
> (defn pooled-data-source
> [db-connection-settings]
> ; this Fn creates and returns object of type PooledDataSource
> )
>
> (defn pooled-data-source-as-singleton
> [db-connection-settings]
> (let [datasource (delay (pooled-data-source db-connection-
> settings))]
> @datasource))
>
> i am not sure, what the exact semantic of this is and if
> it's safe in a multithreaded context.
>
> What is the difference to using def/defonce ?
>
> Someone who can explain ?
>
This snippet does not work as the original author intended. You can remove
the whole delay incantations and everything will work as before. That's
because each call of pooled-data-source-as-singleton creates a new delay,
forces it and throws it away immediately. What probably was intended, is the
use of memoize:
(def ^{:arglists ([db-connection-settings])} pooled-data-source-as-singleton
(memoize pooled-data-source))
The intention is to delay the creation of the datapool instance until
runtime and not do it on load time. This is also nice if you have your db
connection configurable in some non-code form. If you have only one db
connection, which is hardwired in some Var at load time, you can go with the
following:
(let [db-connection-pool (delay (pooled-data-source
db-connection-settings))]
(defn pooled-data-source-as-singleton
[]
@db-connection-pool))
This is maybe, what the original author had in mind.
Hope, I'm not too far off.
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Problem in downloading StringTemplate using lein deps.
Hi, There is no jar available for StringTemplate in clojars. But StringTemplate v3.2 jar is available in Maven. So I included the necessary entry for StringTemplate in project.clj and tried downloading using lein deps. It gives me the below error - Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.pom from central Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.pom from clojars Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.pom from central Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.jar from central Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.jar from clojars Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.jar from central An error has occurred while processing the Maven artifact tasks. Diagnosis: Unable to resolve artifact: Missing: -- 1) stringtemplate:stringtemplate:jar:3.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=stringtemplate -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=stringtemplate -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.maven:super-pom:jar:2.0 2) stringtemplate:stringtemplate:jar:3.2 -- 1 required artifact is missing. for artifact: org.apache.maven:super-pom:jar:2.0 from the specified remote repositories: clojars (http://clojars.org/repo/), central (http://repo1.maven.org/maven2) Exception in thread "main" Unable to resolve artifact: Missing: -- 1) stringtemplate:stringtemplate:jar:3.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=stringtemplate -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=stringtemplate -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.maven:super-pom:jar:2.0 2) stringtemplate:stringtemplate:jar:3.2 -- 1 required artifact is missing. for artifact: org.apache.maven:super-pom:jar:2.0 from the specified remote repositories: clojars (http://clojars.org/repo/), central (http://repo1.maven.org/maven2) (NO_SOURCE_FILE:0) at clojure.lang.Compiler.eval(Compiler.java:5440) at clojure.lang.Compiler.eval(Compiler.java:5391) at clojure.core$eval.invoke(core.clj:2382) at clojure.main$eval_opt.invoke(main.clj:235) at clojure.main$initialize.invoke(main.clj:254) at clojure.main$script_opt.invoke(main.clj:270) at clojure.main$main.doInvoke(main.clj:354) at clojure.lang.RestFn.invoke(RestFn.java:457) at clojure.lang.Var.invoke(Var.java:377) at clojure.lang.AFn.applyToHelper(AFn.java:172) at clojure.lang.Var.applyTo(Var.java:482) at clojure.main.main(main.java:37) Caused by: Unable to resolve artifact: Missing: -- 1) stringtemplate:stringtemplate:jar:3.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=stringtemplate -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=stringtemplate -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.maven:super-pom:jar:2.0 2) stringtemplate:stringtemplate:jar:3.2 -- 1 required artifact is missing. for artifact: org.apache.maven:super-pom:jar:2.0 from the specified remote repositories: clojars (http://clojars.org/repo/), central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.ant.DependenciesTask.doExecute(DependenciesTask.java:175) at org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:678) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:90) at clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:265) at leiningen.deps$do_deps.invoke(deps.clj:131) at leiningen.deps$deps.doInvoke(deps.clj:195) at clojure.lang.RestFn.invoke
Re: Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
The alternative to using eval and large code generation that I've seen is to use the compiled tree of closures approach used by CL-PPCRE. If the JVM is smart enough, it may do the inlining for you on the hot code. http://en.wikibooks.org/wiki/Common_Lisp/External_libraries/CL-PPCRE#Regular_Expressions_as_Trees_and_Closures http://xach.livejournal.com/131456.html?thread=226944 http://gigamonkeys.wordpress.com/2007/07/27/compiling-queries-without-eval/ I agree, benchmarks, experience, and just plain old time will be needed. -Brent On Aug 21, 11:47 pm, David Nolen wrote: > On Sun, Aug 21, 2011 at 11:27 PM, Brent Millare > wrote: > > > I have a question about the presentation. > > > You mention that you can't achieve the same dispatching performance in > > the open case compared to the closed space. > > I meant to say that the problem is hard. No completely unsolvable. > > > In my imaginary implementation, extend-pred takes the predicate label, > > the pattern, and the code to be executed (note its code, not a > > function, so you lose the ability to make closures). Each time extend- > > pred is run, a new dispatch tree is compiled with the code to be > > executed integrated into the tree. (This would be done by saving (and > > updating) the code and patterns in a data structure that gets parsed > > and generates code that is the match macro wrapped into a function.) > > It's certainly a possibility. I haven't ruled it out yet. > > I'm mostly concerned with explosive code generation. match by taking the > decision tree approach already favors performance over code size. There are > patterns that are exponential in the amount of code they generate. > Fortunately Maranget did some measurements with real world patterns - code > size for decision trees built with good heuristics were never more than > 1.5-2X the size of their backtracking counterparts. > > For pattern matching code size is a one time cost. For predicate dispatch, > that's a lot of code to generated, since every new predicate case will > produce an entirely new tree. But perhaps people won't care that much. Only > time and experience reports will tell. > > David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Prisoner's Dilemma in Clojure
Hi, I was curious to see Marginalia in action, but was then surprised to see a lot of code like this: ;; Produce a total score as the sum of the points awarded during each round. (defn total [strategy] (reduce + (:points strategy))) That is, no more docstring, which is replaced in favor of a comment preprending the form it comments. Isn't it an annoyance to loose, in the REPL, the possibility to have nice descriptions when sending e.g. (doc total)? 2011/8/19 Christian Romney > Hi all, > > As part of my attempt to learn Clojure, I've cooked up a simple > Prisoner's Dilemma simulation. I'd love any feedback the group would > care to provide about my implementation, as I'm eager to improve. I've > got thick skin so fire away! > > Annotated source: > http://xmlblog.github.com/prisoners/ > > Github Project: > https://github.com/xmlblog/prisoners > > Needless to say, forks and contributions would be most welcome. > > Thanks! > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Prisoner's Dilemma in Clojure
I'm not sure why this code was written this way, but Marginalia has no problem using docstrings. Compare it's own docs: http://fogus.me/fun/marginalia/ and the code they were generated from: https://github.com/fogus/marginalia/blob/master/src/marginalia/core.clj Cheers, Dave On Mon, Aug 22, 2011 at 9:43 AM, Laurent PETIT wrote: > Hi, > > I was curious to see Marginalia in action, but was then surprised to see a > lot of code like this: > > ;; Produce a total score as the sum of the points awarded during each round. > > (defn total [strategy] > > (reduce + (:points strategy))) > > That is, no more docstring, which is replaced in favor of a comment > preprending the form it comments. > > > > Isn't it an annoyance to loose, in the REPL, the possibility to have nice > descriptions when sending e.g. (doc total)? > > > 2011/8/19 Christian Romney >> >> Hi all, >> >> As part of my attempt to learn Clojure, I've cooked up a simple >> Prisoner's Dilemma simulation. I'd love any feedback the group would >> care to provide about my implementation, as I'm eager to improve. I've >> got thick skin so fire away! >> >> Annotated source: >> http://xmlblog.github.com/prisoners/ >> >> Github Project: >> https://github.com/xmlblog/prisoners >> >> Needless to say, forks and contributions would be most welcome. >> >> Thanks! >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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: Problem in downloading StringTemplate using lein deps.
Stringtemplate is [org.antlr/Stringtemplate "3.2"]. Clojure libraries are generally available in Clojars, open source Java libraries are often available in Maven Central. The lein project.clj dependency format is [goupId/artifactId "version"], from the maven pom format: org.antlr stringtemplate 3.2 You can easily search for available Java libraries at: search.maven.org (or) mvnrepository.com On Mon, Aug 22, 2011 at 8:51 AM, mmwaikar wrote: > Hi, > > There is no jar available for StringTemplate in clojars. But StringTemplate > v3.2 jar is available in Maven. So I included the necessary entry for > StringTemplate in project.clj and tried downloading using lein deps. It > gives me the below error - > > Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.pom from > central > Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.pom from > clojars > Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.pom from > central > Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.jar from > central > Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.jar from > clojars > Downloading: stringtemplate/stringtemplate/3.2/stringtemplate-3.2.jar from > central > An error has occurred while processing the Maven artifact tasks. > Diagnosis: > > Unable to resolve artifact: Missing: > -- > 1) stringtemplate:stringtemplate:jar:3.2 > > Try downloading the file manually from the project website. > > Then, install it using the command: > mvn install:install-file -DgroupId=stringtemplate > -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar > -Dfile=/path/to/file > > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=stringtemplate > -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > > Path to dependency: > 1) org.apache.maven:super-pom:jar:2.0 > 2) stringtemplate:stringtemplate:jar:3.2 > > -- > 1 required artifact is missing. > > for artifact: > org.apache.maven:super-pom:jar:2.0 > > from the specified remote repositories: > clojars (http://clojars.org/repo/), > central (http://repo1.maven.org/maven2) > > > > Exception in thread "main" Unable to resolve artifact: Missing: > -- > 1) stringtemplate:stringtemplate:jar:3.2 > > Try downloading the file manually from the project website. > > Then, install it using the command: > mvn install:install-file -DgroupId=stringtemplate > -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar > -Dfile=/path/to/file > > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=stringtemplate > -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > > Path to dependency: > 1) org.apache.maven:super-pom:jar:2.0 > 2) stringtemplate:stringtemplate:jar:3.2 > > -- > 1 required artifact is missing. > > for artifact: > org.apache.maven:super-pom:jar:2.0 > > from the specified remote repositories: > clojars (http://clojars.org/repo/), > central (http://repo1.maven.org/maven2) > > (NO_SOURCE_FILE:0) > at clojure.lang.Compiler.eval(Compiler.java:5440) > at clojure.lang.Compiler.eval(Compiler.java:5391) > at clojure.core$eval.invoke(core.clj:2382) > at clojure.main$eval_opt.invoke(main.clj:235) > at clojure.main$initialize.invoke(main.clj:254) > at clojure.main$script_opt.invoke(main.clj:270) > at clojure.main$main.doInvoke(main.clj:354) > at clojure.lang.RestFn.invoke(RestFn.java:457) > at clojure.lang.Var.invoke(Var.java:377) > at clojure.lang.AFn.applyToHelper(AFn.java:172) > at clojure.lang.Var.applyTo(Var.java:482) > at clojure.main.main(main.java:37) > Caused by: Unable to resolve artifact: Missing: > -- > 1) stringtemplate:stringtemplate:jar:3.2 > > Try downloading the file manually from the project website. > > Then, install it using the command: > mvn install:install-file -DgroupId=stringtemplate > -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar > -Dfile=/path/to/file > > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=stringtemplate > -DartifactId=stringtemplate -Dversion=3.2 -Dpackaging=jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > > Path to dependency: > 1) org.apache.maven:super-pom:jar:2.0 > 2) stringtemplate:stringtemplate:jar:3.2 > > -- > 1 required artifact is missing. > > for artifact: > org.apache.maven:super-pom:jar:2.0 > > from the specified remote repositories: > clojars (http://clojars.org/repo/), > central (http://repo1.maven.org/maven2) > > > at > org.apache.maven.artifact.ant.DependenciesTask.doExecute(DependenciesTask.java:175) > at > org.
Re: Prisoner's Dilemma in Clojure
2011/8/22 Dave Ray > I'm not sure why this code was written this way, but Marginalia has no > problem using docstrings. Compare it's own docs: > > http://fogus.me/fun/marginalia/ > > and the code they were generated from: > > https://github.com/fogus/marginalia/blob/master/src/marginalia/core.clj > ok, thanks Dave -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Apply concat and mapcat evaluate seqs unnecessarily
user=> (defn f [[x]] (println "computing x:" (inc x)) (vector (inc x))) #'user/f user=> (->> (iterate f [0]) (take 0)) () user=> (->> (iterate f [0]) (apply concat) (take 0)) computing x: 1 computing x: 2 computing x: 3 () user=> (->> (iterate f [0]) (mapcat identity) (take 0)) computing x: 1 computing x: 2 computing x: 3 () Is there a way to rewrite mapcat (or apply concat) so that they don't evaluate the incoming seq unnecessarily? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Generating new exception classes in clojure
OK, I'm not sure if I'm just missing something obvious here, or if there really is no way to do this. What I want to be able to do is to be able to create new exception classes, in the repl, and be able to throw them and catch them. What I want to be able to do is something like: (defexception my-new-exception) (defn foo [] (throw (my-new-exception))) (defn bar [] (try (foo) (catch my-new-exception e ...))) I can't figure out how to do this. - gen-class only generates the class during AOT compilation. This solution needs to work at the REPL. - Exceptions need to inherit from java.lang.Throwable- not just wrap it. So proxy doesn't work, nor does datatypes or protocols (I think). - java.lang.Throwable is a concrete class, not an interface, so deftype and defrecord don't work. - I'd rather not drop down to ASM level to get things to work. - I'd rather deal with ASM than have to write Java code for every new exception I need. I'm kind of surprised I'm the first person who hit this problem. In fact, I'd be very surprised if that were the case. So what's the normal solution to this problem? Brian -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Aw: Re: Prisoner's Dilemma in Clojure
Hi, Am Montag, 22. August 2011 16:08:20 UTC+2 schrieb lpetit: > > 2011/8/22 Dave Ray > >> I'm not sure why this code was written this way, but Marginalia has no >> problem using docstrings. Compare it's own docs: >> [...] > > ok, thanks Dave > that Marginalia also understands docstrings notwithstanding I still look at this type of comments with some skepticism since it encourages the documentation outside its "natural" position. Just think of all the people that are used to JavaDoc: where would they write their documentation? Actually, I'd rather vote for even more strictness here, because it has been bothering me for close to 15 years now that docstrings break the homoiconicity of Lisp. Just my 2ct, though. (And I love Marginalia, since It let's me create wonderful material for Clojure talks; of course using out-of-place comments ;-) Cheers, Stefan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: a question about using the delay macro
Or you could use Boing to create your data source and hide most of that wiring
away from your code.
I am doing a sales pitch here for my own stuff :)))
https://github.com/lprefontaine/Boing/blob/master/examples/spring-1-to-boing.clj
Luc P.
On Mon, 22 Aug 2011 03:04:29 -0700 (PDT)
"Meikel Brandmeyer (kotarak)" wrote:
> Hi,
>
> Am Montag, 22. August 2011 11:53:32 UTC+2 schrieb faenvie:
> >
> > yesterday i came across the following use of
> > the delay-macro:
> >
> > (defn pooled-data-source
> > [db-connection-settings]
> > ; this Fn creates and returns object of type PooledDataSource
> > )
> >
> > (defn pooled-data-source-as-singleton
> > [db-connection-settings]
> > (let [datasource (delay (pooled-data-source db-connection-
> > settings))]
> > @datasource))
> >
> > i am not sure, what the exact semantic of this is and if
> > it's safe in a multithreaded context.
> >
> > What is the difference to using def/defonce ?
> >
> > Someone who can explain ?
> >
>
> This snippet does not work as the original author intended. You can
> remove the whole delay incantations and everything will work as
> before. That's because each call of pooled-data-source-as-singleton
> creates a new delay, forces it and throws it away immediately. What
> probably was intended, is the use of memoize:
>
> (def ^{:arglists ([db-connection-settings])}
> pooled-data-source-as-singleton (memoize pooled-data-source))
>
> The intention is to delay the creation of the datapool instance until
> runtime and not do it on load time. This is also nice if you have
> your db connection configurable in some non-code form. If you have
> only one db connection, which is hardwired in some Var at load time,
> you can go with the following:
>
> (let [db-connection-pool (delay (pooled-data-source
> db-connection-settings))]
> (defn pooled-data-source-as-singleton
> []
> @db-connection-pool))
>
> This is maybe, what the original author had in mind.
>
> Hope, I'm not too far off.
>
> Sincerely
> Meikel
>
--
Luc P.
The rabid Muppet
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure Speed performance test
Below is a Clojure solution that runs in 8.58 microseconds on my machine. I only did it for the 40, 3 case. Records are linked. The list reduction solution runs in 23.4 and the element recursion in 27.3 --art (defrecord Soldier [val r]) (def v (vec (map #(Soldier. % (inc %)) (range 40 (def v2 (assoc v 39 (Soldier. 39 0))) (defn move [v i] (let [r1 (v i) r2 (:r (v (:r r1)))] [(:r (v r2)) (assoc v (:r r1) (Soldier. (:val r1) (:r (v r2] )) (defn joe [v] (loop [v v i 0 count 39] (if (zero? count) (inc i) (let [[a b] (move v i)] (recur b a (dec count)) (prn (joe v2)) (let [start (System/currentTimeMillis) iterations 10] (doseq [i (range 10)] (joe v2)) (let [end (System/currentTimeMillis)] (println (/ (* (- end start) 1000.00) iterations) " microseconds"))) On Aug 18, 12:40 am, Roberto Mannai wrote: > Hello, > I recently stumbled upon this > page:http://java.dzone.com/articles/contrasting-performance > They are comparing several languages (Java, Scala, Python, Erlang, > Clojure, Ruby, Groovy, Javascript), and Clojure rated very badly: > > Object Oriented List Reduction > Element Recursion > Java 1.6 0.637 1.435 > 2.816 > Clojure 1.2.1 - 25.966 > 28.753 > > Maybe the clojure's scripts were not very idiomatic? If some guru > wants to check them, here's the source code: > -https://github.com/dnene/josephus/blob/master/element-recursion/josep... > - https://github.com/dnene/josephus/blob/master/list-reduction/josephus... > > All the best, > Roberto -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Apply concat and mapcat evaluate seqs unnecessarily
Hi, Am 22.08.2011 um 16:32 schrieb Asim Jalis: > Is there a way to rewrite mapcat (or apply concat) so that they don't > evaluate the incoming seq unnecessarily? user=> (defn f [[x]] (println "Computing x:" x) [(inc x)]) #'user/f user=> (defn lazy-mapcat [f coll] (lazy-seq (when-let [s (seq coll)] (concat (f (first s)) (lazy-mapcat f (rest s)) #'user/lazy-mapcat user=> (->> [0] (iterate f) (take 0)) () user=> (->> [0] (iterate f) (apply concat) (take 0)) Computing x: 0 Computing x: 1 Computing x: 2 () user=> (->> [0] (iterate f) (mapcat identity) (take 0)) Computing x: 0 Computing x: 1 Computing x: 2 () user=> (->> [0] (iterate f) (lazy-mapcat identity) (take 0)) () Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Apply concat and mapcat evaluate seqs unnecessarily
This is my attempt to take Meikel's code and extend it to accept arbitrarily many collections as 'mapcat' does: (defn lazy-mapcat [f & colls] (lazy-seq (when (every? seq colls) (concat (apply f (map first colls)) (apply lazy-mapcat f (map rest colls)) user=> (->> (iterate f [0]) (lazy-mapcat identity) (take 1)) (0) user=> (defn g [x y] (println "computing x + y:" (+ x y)) [(+ x y)]) #'user/g user=> (take 1 (mapcat g (range) (range))) computing x + y: 0 computing x + y: 2 computing x + y: 4 computing x + y: 6 (0) user=> (take 1 (lazy-mapcat g (range) (range))) (computing x + y: 0 0) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Apply concat and mapcat evaluate seqs unnecessarily
Nice. Are there any technical reasons this isn't the default implementation of mapcat in Clojure.core? On Mon, Aug 22, 2011 at 9:27 AM, Meikel Brandmeyer wrote: > Hi, > > Am 22.08.2011 um 16:32 schrieb Asim Jalis: > >> Is there a way to rewrite mapcat (or apply concat) so that they don't >> evaluate the incoming seq unnecessarily? > > user=> (defn f [[x]] (println "Computing x:" x) [(inc x)]) > #'user/f > user=> (defn lazy-mapcat > [f coll] > (lazy-seq > (when-let [s (seq coll)] > (concat (f (first s)) (lazy-mapcat f (rest s)) > #'user/lazy-mapcat > user=> (->> [0] (iterate f) (take 0)) > () > user=> (->> [0] (iterate f) (apply concat) (take 0)) > Computing x: 0 > Computing x: 1 > Computing x: 2 > () > user=> (->> [0] (iterate f) (mapcat identity) (take 0)) > Computing x: 0 > Computing x: 1 > Computing x: 2 > () > user=> (->> [0] (iterate f) (lazy-mapcat identity) (take 0)) > () > > Sincerely > Meikel > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Prisoner's Dilemma in Clojure
On Aug 22, 10:04 am, Dave Ray wrote: > I'm not sure why this code was written this way, but Marginalia has no > problem using docstrings. Compare it's own docs: > Chalk it up to noob mistake... :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Prisoner's Dilemma in Clojure
On Aug 21, 9:57 pm, Base wrote: > Very very nice! > Thanks for the encouragement! I should publicly thank Alan Malloy as well, who took the trouble to submit a patch improving some rather unidiomatic code. Thanks to all who have looked at it–I really appreciate the feedback. I'm really excited by Clojure, and the quality of the community plays a huge part in that. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
> For pattern matching code size is a one time cost. For predicate dispatch, > that's a lot of code to generated, since every new predicate case will > produce an entirely new tree. But perhaps people won't care that much. Only > time and experience reports will tell. If you want, you can be lazy about compilation and only compile right before the call to the predicate only if a new predicate has been added since the last compilation. Also, we can be smart about how we do the cached tree check. After extend-pred is called, it wraps the current DAG tree with a compilation step. During the compilation step (made right before the call), the new DAG tree is made and replaces the old one. Note that there is no longer a check for new predicates. -Brent -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
Actually to simply further, instead of wrapping the old DAG tree, it simply replaces the DAG tree with the compilation step. The compilation step then makes the new DAG tree and calls it. On Aug 22, 3:07 pm, Brent Millare wrote: > > For pattern matching code size is a one time cost. For predicate dispatch, > > that's a lot of code to generated, since every new predicate case will > > produce an entirely new tree. But perhaps people won't care that much. Only > > time and experience reports will tell. > > If you want, you can be lazy about compilation and only compile right > before the call to the predicate only if a new predicate has been > added since the last compilation. Also, we can be smart about how we > do the cached tree check. After extend-pred is called, it wraps the > current DAG tree with a compilation step. > > During the compilation step (made right before the call), the new DAG > tree is made and replaces the old one. Note that there is no longer a > check for new predicates. > > -Brent -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
On Mon, Aug 22, 2011 at 3:07 PM, Brent Millare wrote: > > For pattern matching code size is a one time cost. For predicate > dispatch, > > that's a lot of code to generated, since every new predicate case will > > produce an entirely new tree. But perhaps people won't care that much. > Only > > time and experience reports will tell. > > If you want, you can be lazy about compilation and only compile right > before the call to the predicate only if a new predicate has been > added since the last compilation. Also, we can be smart about how we > do the cached tree check. After extend-pred is called, it wraps the > current DAG tree with a compilation step. > > During the compilation step (made right before the call), the new DAG > tree is made and replaces the old one. Note that there is no longer a > check for new predicates. > > -Brent Interesting idea. One possible down side of lazy runtime compilation is that it makes it more difficult to target ClojureScript. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Generating new exception classes in clojure
You can use proxy for this. It doesn't create wrappers, it creates a proper subclass with methods that delegate to clojure functions via var lookup. -- Dave -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Generating new exception classes in clojure
How can I catch a proxied Throwable class without catching everything? I suppose I could grab the class and go at it with reflection... Brian On Mon, Aug 22, 2011 at 3:21 PM, David Powell wrote: > You can use proxy for this. It doesn't create wrappers, it creates a > proper subclass with methods that delegate to clojure functions via var > lookup. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Generating new exception classes in clojure
> How can I catch a proxied Throwable class without catching everything? I > suppose I could grab the class and go at it with reflection... I wrestled with this problem for a while, and got to "you can't do it". At least, not without AOT compilation of some sort. I did come up with a horrible, horrible hack that I'm simultaneously happy with and ashamed of. You can check it out here: https://github.com/candera/artifact/blob/master/src/artifact/error.clj Tests are here in case they helps understand how it's supposed to work: https://github.com/candera/artifact/blob/master/test/artifact/test/error_tests.clj Again, this is a hack. Don't Try It At Home. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Generating new exception classes in clojure
On Mon, Aug 22, 2011 at 11:02 AM, Brian Hurt wrote: > What I want to be able to do is to be able to create new exception classes, > in the repl, and be able to throw them and catch them. At the risk of sounding curmudgeonly: are you sure that's what you want? I suspect you really just want to be able to classify exceptions. For this purpose I highly recommend Slingshot: https://github.com/scgilardi/slingshot which can do this and a whole lot more. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Speed performance test
On Aug 18, 6:50 am, David Nolen wrote:
> The Clojure code posted there is pretty awful and shows a gross, gross
> misunderstanding of Clojure data types. I submitted one improved version
> already, but didn't spend the time to make it really, really fast.
>
> For this particular kind of pointless benchmark it's not hard to get
> identical Java perf. If you want to see how I suggest you look at the Alioth
> benchmarks where the Clojure code shows a much better understanding of the
> language and the fast paths and where the microbenchmarks are quite so
> micro.
I'm sure you meant to say - "I suggest you look at the Alioth
benchmarks where the Clojure code shows a much better understanding of
the language and the fast paths and where the microbenchmarks are " -
not - " quite so micro." :-)
As it happens, back in 2005 when trying to come up with new tasks for
what would become the benchmarks game, I considered trying something
based on the Josephus problem as a replacement for the old Doug Bagley
"List processing" task.
http://web.archive.org/web/20040805114635/http://www.bagley.org/~doug/shootout/bench/lists/
But it just seemed perverse not to solve such a simple problem with an
array and integer add/subtract like this -
public static int countoffSoldiers(int n, int kth)
{
int[] soldiers = new int[n];
for (int i = 0 ; i < n ; i++) soldiers[i] = i+1;
//int k = kth-1, survivedLastRound = n; // standard Josephus
problem
int k = 0, survivedLastRound = n;
while (survivedLastRound > 1) {
int survived = 0;
for (int i = 0 ; i < survivedLastRound; i++)
if (i != k) {
soldiers[survived++] = soldiers[i];
} else {
k += kth;
}
k -= survivedLastRound; // wrap around
survivedLastRound = survived;
}
return soldiers[0];
}
> >http://java.dzone.com/articles/contrasting-performance
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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 Speed performance test
On Aug 18, 7:34 am, Michael Jaaka wrote: > For list reduction it is said to remove every third solder but just > with 1 step they remove 1 soldier. There is something wrong Scully. The author knows, and says that "variant" seemed more interesting. (It should be easy enough to factor out the difference between the "variant" and the standard Josephus problem into one line of code.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
