Looking for feedback on article about interactive programming / REPL
Hello, Small request from a Clojure/Lisp-newbie: I wrote an article on interactive programming in order to really "get" REPL / interactive work. This style of development is new to me so I'm looking for any suggestions you might have for improvement/aspects which I've overlooked! The article (+ some videos) can be found here: http://messynotebook.com/?p=1496 (The current version of the text starts out using JavaScript and Ruby as examples, then moves on to Clojure.) cheers, Thomas Kjeldahl Nilsson -- 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: Isn't STM good at building an ant colony?
If you have a fixed geometry of cells, it is quite easy to have one ref per cell. Which reduce a lot of contention. For example, on a grid where ant can go instead of representing the world as a ref to a matrix, you can represent the world as a matrix of refs. Those refs can then be update concurrently. Provided there are a lot of cells and not too much contention, iti should work well. On Sun, Sep 19, 2010 at 11:01 PM, Hozumi wrote: > Hi. > I posted following question. > > The more threads that changes the Clojure's ref are, the more does the > rate of retries per threads rise? > http://stackoverflow.com/questions/3746893/the-more-threads-that-changes-the-clojures-ref-are-the-more-does-the-rate-of-re > > I think increasing retries in O(thread^2) means that refs should not > be used to store the data that is aletered by too many threads like > big ant colony map or newral network nodes. > If modifying the data by too many threads is planned, instead of refs, > are agents best way to store it? > Any other solution? > > Thanks. > Takahiro Hozumi > > -- > 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 -- Sent from an IBM Model M, 15 August 1989. -- 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: trace facility?
On Mon, Sep 20, 2010 at 1:41 AM, Mike Meyer wrote: > It already exists - it's clojure.contrib.trace (or was - it may have > moved in 1.2). Usage is (dotrace [foo ...] (expression)) and it traces > the foo and ... functions while evaluating (expression). While we're at it, let me ask you a question about monads (which I'm trying to get my head around for a while with a little if any success) - does dotrace do the work monads are better suited for? May I say that dotrace as a macro does at compile time what monads would do at runtime? I might be mistaken, but dotrace is about changing semantics of function calls and so are monads, aren't they? Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://jaceklaskowski.pl -- 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.contrib.sql and duplicate inserts
Currently, it is not possible to insert duplicate rows using the clojure.contrib.sql module (specifically, the insert-values method). Please let me know, if I can add this. Thanks. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: trace facility?
I'd recommend taking a look at the implementation of dotrace (last function in the file): http://github.com/richhickey/clojure-contrib/blob/master/src/main/clojure/clojure/contrib/trace.clj It let-binds a wrapper function for each of the functions you want to trace, so that within the context of the traced expression those function calls resolve to the wrapped versions rather than the originals. I'm not a monad expert, but as far as I understand they are implemented in a similar fashion. The original functions of your computation get wrapped so that the monad infrastructure can carry along extra values and/or operate on return values. That said, I don't really think of either tracing or monads as a way to change the semantics of your functions. Instead the functions stay the same while the machinery around them is modified. -Jeff On Sep 20, 2:11 pm, Jacek Laskowski wrote: > On Mon, Sep 20, 2010 at 1:41 AM, Mike Meyer > > wrote: > > It already exists - it's clojure.contrib.trace (or was - it may have > > moved in 1.2). Usage is (dotrace [foo ...] (expression)) and it traces > > the foo and ... functions while evaluating (expression). > > While we're at it, let me ask you a question about monads (which I'm > trying to get my head around for a while with a little if any success) > - does dotrace do the work monads are better suited for? May I say > that dotrace as a macro does at compile time what monads would do at > runtime? I might be mistaken, but dotrace is about changing semantics > of function calls and so are monads, aren't they? > > Jacek > > -- > Jacek Laskowski > Notatnik Projektanta Java EE -http://jaceklaskowski.pl -- 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 friendly data warehouse stack
Hi, We are developing a data warehouse to facilitate reporting and data mining for cash register transaction data. It seems like many people in the Clojure community have data warehouse experience, so I wanted to ask for advice from people who have already done this before. Which libraries, databases and reporting tools do people recommend? We are happy to handle most of the data wrangling with straight Clojure (and maybe Hadoop), but we aren't sure which database to use for the final warehouse schema or how best to handle reporting. The database needs to handle many millions of records and growing, and we would like to support ad-hoc reporting and online querying of the warehouse data. The existing BI platforms I've looked into seem really heavy weight and enterprisey. Are there any lean and mean (preferably open source) reporting tools that let you dive into data and generate pretty pictures without all the cruft? Thanks, Jeff -- 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: Making Clojure really work with Google App Engine
Hi, just a few days ago I started considering GAE for a (pet-)project. Being able to develop in Clojure on GAE seems like a valuable goal to me. For example, take a look at http://the-deadline.appspot.com which was written that way. So it might be a good idea to avoid creating threads automatically or importing file/socket packages. Anyway, just my 2ct. Kind regards, 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: clojure.contrib.sql and duplicate inserts
On Sep 20, 2010, at 8:27 AM, Bart J wrote: > Currently, it is not possible to insert duplicate rows > using the clojure.contrib.sql module (specifically, the > insert-values method). > > Please let me know, if I can add this. > > Thanks. Are you saying you want to end up with duplicate rows or that you want insert-values to act differently when presented with a row that turns out to be a duplicate? What is your proposed fix? Any non-trivial contribution to clojure.contrib.sql would require that you have a contributer agreement on file with Rich as described here: http://clojure.org/contributing . --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: trace facility?
On 20 September 2010 14:55, Jeff Rose wrote: > I'd recommend taking a look at the implementation of dotrace (last > function in the file): > > http://github.com/richhickey/clojure-contrib/blob/master/src/main/clojure/clojure/contrib/trace.clj clojure and clojure-contrib have moved from github.com/richhickey to github.com/clojure. Try this for the current location of trace.clj: http://github.com/clojure/clojure-contrib/blob/master/modules/trace/src/main/clojure/clojure/contrib/trace.clj -- 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: why the big difference in speed?
Thanks Jason, this is great. I was confused earlier because I wasn't seeing reflection warnings, but it turns out that was only because I was evaluating the function definitions in the emacs buffer, and the warnings weren't visible. I have a question about gaussian-matrix3 though. What is "aset- double2"? Is that a macro that has a type hint for an array of doubles? Thanks, -Ranjit On Sep 19, 5:37 pm, Jason Wolfe wrote: > Hi Ranjit, > > The big perf differences you're seeing are due to reflective calls. > Getting the Java array bits properly type-hinted is especially tricky, > since you don't always get good reflection warnings. > > Note that aset is only fast for reference types: > > user> (doc aset) > - > clojure.core/aset > ([array idx val] [array idx idx2 & idxv]) > Sets the value at the index/indices. Works on Java arrays of > reference types. Returns val. > > So, if you want to speed things up ... here's your starting point: > > user> (set! *warn-on-reflection* true) > true > user> (import java.util.Random) > (def r (Random. )) > > (defn next-gaussian [] (.nextGaussian r)) > > (defn gaussian-matrix1 [arr L] > (doseq [x (range L) y (range L)] (aset arr x y (next-gaussian > > (defn gaussian-matrix2 [L] > (into-array (map double-array (partition L (repeatedly (* L L) > next-gaussian) > > Reflection warning, NO_SOURCE_FILE:1 - reference to field nextGaussian > can't be resolved. > > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > 10) 10)) (microbench (gaussian-matrix2 10)) ) > min; avg; max ms: 2.944 ; 4.693 ; 34.643 ( 424 iterations) > min; avg; max ms: 0.346 ; 0.567 ; 11.006 ( 3491 iterations) > > ;; Now, we can get rid of the reflection in next-guassian: > > user> (defn next-gaussian [] (.nextGaussian #^Random r)) > #'user/next-gaussian > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > 10) 10)) (microbench (gaussian-matrix2 10)) ) > min; avg; max ms: 2.639 ; 4.194 ; 25.024 ( 475 iterations) > min; avg; max ms: 0.068 ; 0.130 ; 10.766 ( 15104 iterations) > nil > > ;; which has cut out the main bottleneck in gaussian-matrix2. > ;; 1 is still slow because of its array handling. > ;; here's a fixed version: > > user> (defn gaussian-matrix3 [^doubles arr ^int L] > (doseq [x (range L) y (range L)] (aset-double2 arr (int x) (int > y) (.nextGaussian ^Random r > #'user/gaussian-matrix3 > > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > 10) 10)) (microbench (gaussian-matrix2 10)) (microbench (gaussian- > matrix3 (make-array Double/TYPE 10 10) 10)) ) > min; avg; max ms: 2.656 ; 4.164 ; 12.752 ( 479 iterations) > min; avg; max ms: 0.065 ; 0.128 ; 9.712 ( 15255 iterations) > min; avg; max ms: 0.000 ; 0.035 ; 10.180 ( 54618 iterations) > nil > > ;; which is 100x faster than where we started. > > A profiler is often a great way to figure out what's eating up time. > Personally, I've never found the need to use a disassembler. > > Cheers, Jason -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Can resultset-seq blow the stack?
Yeah this doesn't happen on using lazy-seq. Thanks! Shantanu On Sep 20, 8:52 am, "Stephen C. Gilardi" wrote: > On Sep 19, 2010, at 3:45 PM, Shantanu Kumar wrote: > > > I simulated a similar recursive call and found it > > throws StackOverflowError at 5508 levels deep on a 32-bit Sun JVM (not > > server mode) on Windows 7. > > Did your similar recursion include the lazy-seq form that wraps the > (apparently) recursive call? Each invocation of lazy-seq results in one call > to the code it wraps that's delayed until its value is requested. The > invocations do not end up nested on the stack. Instead they are executed one > by one as calling code steps through the lazy sequence. > > --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: what's up with user.clj?
BTW, shouldn't this "user.clj" trick be marked as deprecated, to be removed in a future version ? 2010/9/19 Kevin Downey > you can also run into issues with things being on the classpath for > your project, but not being on the classpath for lein, but user.clj > being on the classpath for both, so when lein runs it can't find > things your user.clj tries to load > > On Sat, Sep 11, 2010 at 8:17 AM, Stuart Sierra > wrote: > > Don't know if this is the source of the problem, but your "use" syntax > > is funky. You want: > > > >(use '[clojure.java.javadoc :only (javadoc)]) > > > > -S > > > > > > > > On Sep 11, 3:51 am, Robert McIntyre wrote: > >> In the clojure getting started guide, it says that if user.clj is > >> found on the classpath, then that file will be evaluated and the repl > >> will start with any modifications made from that file. > >> > >> My directory structure looks like this > >> > >> /src/user.clj > >> /src/rlm/quick.clj > >> /lib/*all-my-jars* > >> > >> I have a function (dirty) in quick.clj that essentially does: > >> > >> (defn dirty [] > >> (use :reload-all '[clojure.java [javadoc :only [javadoc]]) > >> (clojure.java.javadoc/add-local-javadoc "/path/to/local/javadocs")) > >> > >> (dirty) works fine at the repl if I type (do (require 'rlm.quick) > >> (rlm.quick/dirty)) > >> > >> If I define user.clj like so: > >> > >> (ns user) > >> (require 'rlm.quick) > >> (rlm.quick/dirty) > >> > >> Then I get the error : java.lang.ClassNotFoundException: > clojure.java.javadoc > >> > >> If I move the (clojure.java.javadoc/add-local-javadoc > >> "/path/to/local/javadocs") from (dirty) straight into user.clj it > >> works fine. > >> > >> what's up with this? > >> > >> --Robert McIntyre > >> > >> and user.clj reads like this > > > > -- > > 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 > -- 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
Evaluating elements of a vector in order
Hello I have a vector containing three macro calls. The third macro relies on the first having been fully evaluated. I want to define a macro to declare these three macros in order Call my vector 'stuff' then the following code inside a macro works (doall [(eval (get stuff 0)) (eval (get stuff 1)) (eval (get stuff 2))]) Is there any general solution eg (doall stuff) fails as it tells me a variable declared by the first macro (and needed by the third) is unbound. Thank you. -- 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: concurrency example about java x clojure
A few days ago I was thinking about how different it would be to write
flip-map* in Java vs Clojure. A very simple, small program, but easy
to see how Clojure can be more expressive.
public static Map flipMap(Map map)
{
Map result = new HashMap(map.size());
for (K key : map.keys()) {
result.put(map.get(key), key);
}
return result;
}
(def flip-map #(apply zipmap ((juxt vals keys) %)))
* Given a hash map, reverse its keys and values such that every K=>V
pair in the input map becomes V=>K in the output. Naturally the values
must be unique for this to work, so call that a precondition.
On Sep 17, 2:47 pm, anderson_leite wrote:
> I'm new to clojure, so sorry if this is a dummie question.
>
> Studyng clojure I can understand the syntax and so onbut I would
> like a real example comparing clojure and java.
>
> Do you know some benchmark using first just java and than showing the
> best results with 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
Clojure meetup group listing
Hey All, I know there are certainly a few groups out there (organized via Meetup.com or otherwise) which I see things posted about from time to time on the list. I'd like to propose that we make an effort to list these groups on Meetup Everywhere (http://www.meetup.com/everywhere), which is a free platform useful for finding a nearby meetup about a given topic. Please note, this is not meant to overtake your existing organization method. Everywhere is designed to be agnostic in regards to organization platform. If enough groups start listing there, it might make sense to then post a link on the Clojure site to help people find their local user group: http://www.meetup.com/Clojure I can make changes to the page as necessary. Cheers, Andrew -- http://www.apgwoz.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: why the big difference in speed?
Oops, I found aset-double2 with tab completion and figured it was build-in. Forgot it was a utility I built some time ago, a stub for a Java method that does the setting. Also, I got the type hint for the "arr" arg wrong, although it didn't seem to matter. Here's a fixed version in standard Clojure that's basically as fast: user> (defn gaussian-matrix4 [^"[[D" arr ^int L] (doseq [x (range L) y (range L)] (aset-double ^doubles (aget arr (int x)) (int y) (.nextGaussian ^Random r #'user/gaussian-matrix4 user> (do (microbench (gaussian-matrix3 (make-array Double/TYPE 10 10) 10)) (microbench (gaussian-matrix4 (make-array Double/TYPE 10 10) 10)) ) min; avg; max ms: 0.000 ; 0.033 ; 8.837( 56828 iterations) min; avg; max ms: 0.009 ; 0.038 ; 7.132( 50579 iterations) It seems like you should be able to just use aset-double with multiple indices (in place of aset-double2), but I can't seem to get the type hints right. -Jason On Sep 20, 7:36 am, Ranjit wrote: > Thanks Jason, this is great. > > I was confused earlier because I wasn't seeing reflection warnings, > but it turns out that was only because I was evaluating the function > definitions in the emacs buffer, and the warnings weren't visible. > > I have a question about gaussian-matrix3 though. What is "aset- > double2"? Is that a macro that has a type hint for an array of > doubles? > > Thanks, > > -Ranjit > On Sep 19, 5:37 pm, Jason Wolfe wrote: > > > Hi Ranjit, > > > The big perf differences you're seeing are due to reflective calls. > > Getting the Java array bits properly type-hinted is especially tricky, > > since you don't always get good reflection warnings. > > > Note that aset is only fast for reference types: > > > user> (doc aset) > > - > > clojure.core/aset > > ([array idx val] [array idx idx2 & idxv]) > > Sets the value at the index/indices. Works on Java arrays of > > reference types. Returns val. > > > So, if you want to speed things up ... here's your starting point: > > > user> (set! *warn-on-reflection* true) > > true > > user> (import java.util.Random) > > (def r (Random. )) > > > (defn next-gaussian [] (.nextGaussian r)) > > > (defn gaussian-matrix1 [arr L] > > (doseq [x (range L) y (range L)] (aset arr x y (next-gaussian > > > (defn gaussian-matrix2 [L] > > (into-array (map double-array (partition L (repeatedly (* L L) > > next-gaussian) > > > Reflection warning, NO_SOURCE_FILE:1 - reference to field nextGaussian > > can't be resolved. > > > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > > 10) 10)) (microbench (gaussian-matrix2 10)) ) > > min; avg; max ms: 2.944 ; 4.693 ; 34.643 ( 424 iterations) > > min; avg; max ms: 0.346 ; 0.567 ; 11.006 ( 3491 iterations) > > > ;; Now, we can get rid of the reflection in next-guassian: > > > user> (defn next-gaussian [] (.nextGaussian #^Random r)) > > #'user/next-gaussian > > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > > 10) 10)) (microbench (gaussian-matrix2 10)) ) > > min; avg; max ms: 2.639 ; 4.194 ; 25.024 ( 475 iterations) > > min; avg; max ms: 0.068 ; 0.130 ; 10.766 ( 15104 iterations) > > nil > > > ;; which has cut out the main bottleneck in gaussian-matrix2. > > ;; 1 is still slow because of its array handling. > > ;; here's a fixed version: > > > user> (defn gaussian-matrix3 [^doubles arr ^int L] > > (doseq [x (range L) y (range L)] (aset-double2 arr (int x) (int > > y) (.nextGaussian ^Random r > > #'user/gaussian-matrix3 > > > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > > 10) 10)) (microbench (gaussian-matrix2 10)) (microbench (gaussian- > > matrix3 (make-array Double/TYPE 10 10) 10)) ) > > min; avg; max ms: 2.656 ; 4.164 ; 12.752 ( 479 iterations) > > min; avg; max ms: 0.065 ; 0.128 ; 9.712 ( 15255 iterations) > > min; avg; max ms: 0.000 ; 0.035 ; 10.180 ( 54618 iterations) > > nil > > > ;; which is 100x faster than where we started. > > > A profiler is often a great way to figure out what's eating up time. > > Personally, I've never found the need to use a disassembler. > > > Cheers, Jason -- 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: concurrency example about java x clojure
Oh, I see you put the word "concurrency" in the subject but don't
mention it in your post. I guess my example isn't interesting for you,
then. You will get better responses if you put all relevant
information in the actual body - the subject is a space to summarize
the body, not to add to it.
On Sep 20, 9:08 am, Alan wrote:
> A few days ago I was thinking about how different it would be to write
> flip-map* in Java vs Clojure. A very simple, small program, but easy
> to see how Clojure can be more expressive.
>
> public static Map flipMap(Map map)
> {
> Map result = new HashMap(map.size());
> for (K key : map.keys()) {
> result.put(map.get(key), key);
> }
>
> return result;
>
> }
>
> (def flip-map #(apply zipmap ((juxt vals keys) %)))
>
> * Given a hash map, reverse its keys and values such that every K=>V
> pair in the input map becomes V=>K in the output. Naturally the values
> must be unique for this to work, so call that a precondition.
>
> On Sep 17, 2:47 pm, anderson_leite wrote:
>
> > I'm new to clojure, so sorry if this is a dummie question.
>
> > Studyng clojure I can understand the syntax and so onbut I would
> > like a real example comparing clojure and java.
>
> > Do you know some benchmark using first just java and than showing the
> > best results with 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: concurrency example about java x clojure
On Sep 20, 12:08 pm, Alan wrote:
> A few days ago I was thinking about how different it would be to write
> flip-map* in Java vs Clojure. A very simple, small program, but easy
> to see how Clojure can be more expressive.
>
> public static Map flipMap(Map map)
> {
> Map result = new HashMap(map.size());
> for (K key : map.keys()) {
> result.put(map.get(key), key);
> }
>
> return result;
>
> }
>
> (def flip-map #(apply zipmap ((juxt vals keys) %)))
>
> * Given a hash map, reverse its keys and values such that every K=>V
> pair in the input map becomes V=>K in the output. Naturally the values
> must be unique for this to work, so call that a precondition.
>
> On Sep 17, 2:47 pm, anderson_leite wrote:
If I was going to write flip-map it might be a tad longer, but lazy
and a bit clearer (IMO), with:
(defn flip-map [m] (into {} (map (juxt second first) m)))
--
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: concurrency example about java x clojure
There's no such thing as a lazy map. into uses reduce, which is
necessarily not lazy either.
Clarity is in the eye of the beholder, of course. I think my version
is clearer, but if you replaced second/first with val/key I'd rate
them about the same. You might even replace (just val key) with
reverse - not sure if that's more readable, but there's certainly a
case for it.
On Sep 20, 9:52 am, John Cromartie wrote:
> On Sep 20, 12:08 pm, Alan wrote:
>
>
>
> > A few days ago I was thinking about how different it would be to write
> > flip-map* in Java vs Clojure. A very simple, small program, but easy
> > to see how Clojure can be more expressive.
>
> > public static Map flipMap(Map map)
> > {
> > Map result = new HashMap(map.size());
> > for (K key : map.keys()) {
> > result.put(map.get(key), key);
> > }
>
> > return result;
>
> > }
>
> > (def flip-map #(apply zipmap ((juxt vals keys) %)))
>
> > * Given a hash map, reverse its keys and values such that every K=>V
> > pair in the input map becomes V=>K in the output. Naturally the values
> > must be unique for this to work, so call that a precondition.
>
> > On Sep 17, 2:47 pm, anderson_leite wrote:
>
> If I was going to write flip-map it might be a tad longer, but lazy
> and a bit clearer (IMO), with:
>
> (defn flip-map [m] (into {} (map (juxt second first) m)))
--
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: concurrency example about java x clojure
Hi,
Am 20.09.2010 um 18:52 schrieb John Cromartie:
>> (def flip-map #(apply zipmap ((juxt vals keys) %)))
>>
>
> If I was going to write flip-map it might be a tad longer, but lazy
> and a bit clearer (IMO), with:
>
>(defn flip-map [m] (into {} (map (juxt second first) m)))
Is there some specific reason to avoid the most straight-forward solution?
user=> (defn flip-map [m] (zipmap (vals m) (keys m)))
#'user/flip-map
user=> (flip-map {:a 1 :b 2 :c 3 :d 4 :e 5 :f 6 :g 7 :h 8})
{8 :h, 7 :g, 6 :f, 5 :e, 4 :d, 3 :c, 2 :b, 1 :a}
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure meetup group listing
I second the motion. Just moved to Edmonton, and have been looking around for fellow Clojurians. I've created an Edmonton meetup (I think), and hopefully some kindred souls will turn up :) On Sep 20, 9:33 am, Andrew Gwozdziewycz wrote: > Hey All, > > I know there are certainly a few groups out there (organized via > Meetup.com or otherwise) which I see things posted about from time to > time on the list. I'd like to propose that we make an effort to list > these groups on Meetup Everywhere (http://www.meetup.com/everywhere), > which is a free platform useful for finding a nearby meetup about a > given topic. Please note, this is not meant to overtake your existing > organization method. Everywhere is designed to be agnostic in regards > to organization platform. > > If enough groups start listing there, it might make sense to then post > a link on the Clojure site to help people find their local user group: > > http://www.meetup.com/Clojure > > I can make changes to the page as necessary. > > Cheers, > > Andrew > > --http://www.apgwoz.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: Displaying source of function typed into the REPL?
Sean, Try this, http://gist.github.com/193550 . Adjust it to your taste. Regards, Emeka On Mon, Sep 20, 2010 at 4:00 AM, Sean Corfield wrote: > That also sounds pretty useful for development. I may try that as an > exercise... > > This weekend has been a journey through The Joy of Clojure. I read > about 100 pages on Friday evening (easy going), 150 pages on Saturday > (harder going - more complex topics). Today I read another 50 pages, > skipped chapters 11 & 12 (brain too full to process - about 80 pages) > and read chapter 13 (about 20 pages). All the time I had a REPL open > and kept copy'n'pasting examples in and playing with them to get a > feel for it. It's been a really fun weekend! Now, unfortunately, I > must get chores (and work!) done before the week starts. > > See some of you at the JavaOne Clojure meetup tomorrow (Monday)? > > On Sun, Sep 19, 2010 at 6:11 PM, jlk wrote: > > Not sure how practical it is, but a while back I was playing around > > with a macro redefining defn so that it stored the function source in > > the meta-data of the function. I can't find it now but remember it > > being fairly trivial to implement. > > -- > 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 > -- *Satajanus Nig. Ltd * -- 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: Displaying source of function typed into the REPL?
On Mon, Sep 20, 2010 at 11:09 AM, Emeka wrote: > Try this, http://gist.github.com/193550 . Adjust it to your taste. So I'd say (file-repl "console.txt") and everything typed in and printed out would be written to that file for the REPL session? That would be a bit like the .jline-clojure.main.history file (but would include all output as well). -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- 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: why the big difference in speed?
Replacing the doseq's with dotimes speeds it up a little more: (defn gaussian-matrix5 [^"[[D" arr] (dotimes [x (alength arr)] (dotimes [y (alength (first arr))] (aset-double ^doubles (aget arr (int x)) (int y) (next- gaussian) but I'm getting reflection warnings on alength. I guess it doesn't cause a problem because they're only called once? Also adding type hints to the more functional version of my first attempt speeds things up quite a bit: (defn gaussian-matrix2 [L] (into-array ^doubles (map double-array (partition L (repeatedly (* L L) next- gaussian) But it's still about 4x slower than gaussian-matrix5 above. There must be a way to improve on the inner loop here that doesn't require using indices, right? On Sep 20, 12:32 pm, Jason Wolfe wrote: > Oops, I found aset-double2 with tab completion and figured it was > build-in. Forgot it was a utility I built some time ago, a stub for a > Java method that does the setting. > > Also, I got the type hint for the "arr" arg wrong, although it didn't > seem to matter. > > Here's a fixed version in standard Clojure that's basically as fast: > > user> (defn gaussian-matrix4 [^"[[D" arr ^int L] > (doseq [x (range L) y (range L)] (aset-double ^doubles > (aget arr (int x)) (int y) (.nextGaussian ^Random r > #'user/gaussian-matrix4 > user> (do (microbench (gaussian-matrix3 (make-array Double/TYPE 10 > 10) 10)) (microbench (gaussian-matrix4 (make-array Double/TYPE 10 10) > 10)) ) > min; avg; max ms: 0.000 ; 0.033 ; 8.837 ( 56828 iterations) > min; avg; max ms: 0.009 ; 0.038 ; 7.132 ( 50579 iterations) > > It seems like you should be able to just use aset-double with multiple > indices (in place of aset-double2), but I can't seem to get the type > hints right. > > -Jason > > On Sep 20, 7:36 am, Ranjit wrote: > > > Thanks Jason, this is great. > > > I was confused earlier because I wasn't seeing reflection warnings, > > but it turns out that was only because I was evaluating the function > > definitions in the emacs buffer, and the warnings weren't visible. > > > I have a question about gaussian-matrix3 though. What is "aset- > > double2"? Is that a macro that has a type hint for an array of > > doubles? > > > Thanks, > > > -Ranjit > > On Sep 19, 5:37 pm, Jason Wolfe wrote: > > > > Hi Ranjit, > > > > The big perf differences you're seeing are due to reflective calls. > > > Getting the Java array bits properly type-hinted is especially tricky, > > > since you don't always get good reflection warnings. > > > > Note that aset is only fast for reference types: > > > > user> (doc aset) > > > - > > > clojure.core/aset > > > ([array idx val] [array idx idx2 & idxv]) > > > Sets the value at the index/indices. Works on Java arrays of > > > reference types. Returns val. > > > > So, if you want to speed things up ... here's your starting point: > > > > user> (set! *warn-on-reflection* true) > > > true > > > user> (import java.util.Random) > > > (def r (Random. )) > > > > (defn next-gaussian [] (.nextGaussian r)) > > > > (defn gaussian-matrix1 [arr L] > > > (doseq [x (range L) y (range L)] (aset arr x y (next-gaussian > > > > (defn gaussian-matrix2 [L] > > > (into-array (map double-array (partition L (repeatedly (* L L) > > > next-gaussian) > > > > Reflection warning, NO_SOURCE_FILE:1 - reference to field nextGaussian > > > can't be resolved. > > > > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > > > 10) 10)) (microbench (gaussian-matrix2 10)) ) > > > min; avg; max ms: 2.944 ; 4.693 ; 34.643 ( 424 iterations) > > > min; avg; max ms: 0.346 ; 0.567 ; 11.006 ( 3491 iterations) > > > > ;; Now, we can get rid of the reflection in next-guassian: > > > > user> (defn next-gaussian [] (.nextGaussian #^Random r)) > > > #'user/next-gaussian > > > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > > > 10) 10)) (microbench (gaussian-matrix2 10)) ) > > > min; avg; max ms: 2.639 ; 4.194 ; 25.024 ( 475 iterations) > > > min; avg; max ms: 0.068 ; 0.130 ; 10.766 ( 15104 iterations) > > > nil > > > > ;; which has cut out the main bottleneck in gaussian-matrix2. > > > ;; 1 is still slow because of its array handling. > > > ;; here's a fixed version: > > > > user> (defn gaussian-matrix3 [^doubles arr ^int L] > > > (doseq [x (range L) y (range L)] (aset-double2 arr (int x) (int > > > y) (.nextGaussian ^Random r > > > #'user/gaussian-matrix3 > > > > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > > > 10) 10)) (microbench (gaussian-matrix2 10)) (microbench (gaussian- > > > matrix3 (make-array Double/TYPE 10 10) 10)) ) > > > min; avg; max ms: 2.656 ; 4.164 ; 12.752 ( 479 iterations) > > > min; avg; max ms: 0.065 ; 0.128 ; 9.712 ( 15255 iterations) > > > min; avg; max ms: 0.000 ; 0.035 ; 10.180 ( 54618 iterations) > > > nil > > > > ;; which is 100x faster than where we started. >
Re: [ANN] Leiningen 1.3.1
Hi, Having recently upgraded to this newest lein $ lein --version Leiningen 1.3.1 on Java 1.6.0_18 OpenJDK Client VM I notice that the "lein swank" command is no longer supported. $ lein swank That's not a task. Use "lein help" to list all tasks. What's the recommended way to start up a clojure server to which I can connect with slime? Thanks -- Eric ps. sorry for the basic question, but I've searched the lein documentation and the mailing list for "lein swank" but without success. I very much want to continue to use lein to handle classpath issues when starting up a clojure server. Phil Hagelberg writes: > I'm pleased to announce the release of Leiningen 1.3.1. This release > fixes a few key bugs and introduces a handful of minor features. Here > are the highlights. > > Bug Fixes: > > * Performing a standalone install (a new feature of Leiningen 1.3.0) > now pulls in all transitive dependencies. > > * Unreadable input won't cause issues in the repl. > > * Huge classpaths no longer cause slowdown on boot. > > * Namespaces for test and help tasks are no longer skipped if their > first form is not a call to the ns macro. > > * Uberjar task will not proceed if compilation fails. > > New Features: > > * The shell-wrapper scripts may be customized. > > * repl task may be used outside the context of a project. > > * If :min-lein-version is set, users of an older Leiningen version > will see a warning. > > * Dependency jar types may be specified. (test, javadoc, etc.) > > * Regexes may be used to specify namespaces in :aot list. > > We also have improved Windows support with a zip file that should get > you everything you need: > > http://github.com/downloads/technomancy/leiningen/lein-win32.zip > > More details about the changes are at http://bit.ly/lein-news > > I'm particularly interested in the shell-wrapper functionality since > right now it's quite awkward to create Clojure projects that are > first-class citizens when it comes to the command-line. I think > shell-wrappers have the potential to significantly improve the > situation. I'm hoping to write up some more documentation on this, but > you can see the basics under "Shell Wrappers" near the bottom of the > tutorial: > > http://github.com/technomancy/leiningen/blob/master/TUTORIAL.md > > As always, thanks to the contributors who submitted patches for this > release: Shantanu Kumar, Colin Jones, Isaac Hodes, Alan Dipert, John > Sanda, and Alex Ott, as well as all 47 of you who have contributed in > the past: http://www.ohloh.net/p/leiningen/contributors > > If you'd like to be involved in the next release, I've started a > thread with a roadmap for 1.4.0 on the Leiningen mailing list: > > > http://groups.google.com/group/leiningen/browse_thread/thread/8352bbb974034bff > > Enjoy! > > -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: why the big difference in speed?
I think partition is slowing you down (but haven't profiled to verify). Here's a functional version that's about 70% as fast as my "5": (defn gaussian-matrix6 [L] (to-array (for [i (range L)] (into-array Double/TYPE (for [j (range L)] (next-gaussian)) and I'd guess that's about as good as you're going to get, given that this approach is necessarily going to box and unbox the doubles, and create intermediate sequences, rather than stuffing the primitive doubles directly into the result array. -Jason On Sep 20, 12:00 pm, Ranjit wrote: > Replacing the doseq's with dotimes speeds it up a little more: > > (defn gaussian-matrix5 [^"[[D" arr] > (dotimes [x (alength arr)] > (dotimes [y (alength (first arr))] > (aset-double ^doubles (aget arr (int x)) (int y) (next- > gaussian) > > but I'm getting reflection warnings on alength. I guess it doesn't > cause a problem because they're only called once? > > Also adding type hints to the more functional version of my first > attempt speeds things up quite a bit: > > (defn gaussian-matrix2 [L] > (into-array ^doubles > (map double-array (partition L (repeatedly (* L L) next- > gaussian) > > But it's still about 4x slower than gaussian-matrix5 above. There must > be a way to improve on the inner loop here that doesn't require using > indices, right? > > On Sep 20, 12:32 pm, Jason Wolfe wrote: > > > Oops, I found aset-double2 with tab completion and figured it was > > build-in. Forgot it was a utility I built some time ago, a stub for a > > Java method that does the setting. > > > Also, I got the type hint for the "arr" arg wrong, although it didn't > > seem to matter. > > > Here's a fixed version in standard Clojure that's basically as fast: > > > user> (defn gaussian-matrix4 [^"[[D" arr ^int L] > > (doseq [x (range L) y (range L)] (aset-double ^doubles > > (aget arr (int x)) (int y) (.nextGaussian ^Random r > > #'user/gaussian-matrix4 > > user> (do (microbench (gaussian-matrix3 (make-array Double/TYPE 10 > > 10) 10)) (microbench (gaussian-matrix4 (make-array Double/TYPE 10 10) > > 10)) ) > > min; avg; max ms: 0.000 ; 0.033 ; 8.837 ( 56828 iterations) > > min; avg; max ms: 0.009 ; 0.038 ; 7.132 ( 50579 iterations) > > > It seems like you should be able to just use aset-double with multiple > > indices (in place of aset-double2), but I can't seem to get the type > > hints right. > > > -Jason > > > On Sep 20, 7:36 am, Ranjit wrote: > > > > Thanks Jason, this is great. > > > > I was confused earlier because I wasn't seeing reflection warnings, > > > but it turns out that was only because I was evaluating the function > > > definitions in the emacs buffer, and the warnings weren't visible. > > > > I have a question about gaussian-matrix3 though. What is "aset- > > > double2"? Is that a macro that has a type hint for an array of > > > doubles? > > > > Thanks, > > > > -Ranjit > > > On Sep 19, 5:37 pm, Jason Wolfe wrote: > > > > > Hi Ranjit, > > > > > The big perf differences you're seeing are due to reflective calls. > > > > Getting the Java array bits properly type-hinted is especially tricky, > > > > since you don't always get good reflection warnings. > > > > > Note that aset is only fast for reference types: > > > > > user> (doc aset) > > > > - > > > > clojure.core/aset > > > > ([array idx val] [array idx idx2 & idxv]) > > > > Sets the value at the index/indices. Works on Java arrays of > > > > reference types. Returns val. > > > > > So, if you want to speed things up ... here's your starting point: > > > > > user> (set! *warn-on-reflection* true) > > > > true > > > > user> (import java.util.Random) > > > > (def r (Random. )) > > > > > (defn next-gaussian [] (.nextGaussian r)) > > > > > (defn gaussian-matrix1 [arr L] > > > > (doseq [x (range L) y (range L)] (aset arr x y (next-gaussian > > > > > (defn gaussian-matrix2 [L] > > > > (into-array (map double-array (partition L (repeatedly (* L L) > > > > next-gaussian) > > > > > Reflection warning, NO_SOURCE_FILE:1 - reference to field nextGaussian > > > > can't be resolved. > > > > > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > > > > 10) 10)) (microbench (gaussian-matrix2 10)) ) > > > > min; avg; max ms: 2.944 ; 4.693 ; 34.643 ( 424 iterations) > > > > min; avg; max ms: 0.346 ; 0.567 ; 11.006 ( 3491 iterations) > > > > > ;; Now, we can get rid of the reflection in next-guassian: > > > > > user> (defn next-gaussian [] (.nextGaussian #^Random r)) > > > > #'user/next-gaussian > > > > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > > > > 10) 10)) (microbench (gaussian-matrix2 10)) ) > > > > min; avg; max ms: 2.639 ; 4.194 ; 25.024 ( 475 iterations) > > > > min; avg; max ms: 0.068 ; 0.130 ; 10.766 ( 15104 iterations) > > > > nil > > > > > ;; which has cut out the main bottleneck in gaussian-matrix2. > > > > ;; 1 is still slow because of its
Re: Making Clojure really work with Google App Engine
On Sep 20, 9:17 am, Stefan Kamphausen wrote: > So it might be a good idea to avoid creating threads automatically or > importing file/socket packages. I think you're right. Dependencies are always a double-edged sword, and in the case of App Engine, they are more toxic than usual. Anyway, I eliminated the ring-servlet dependency, and appengine-magic now successfully deploys simple "hello world" Ring applications. I'll send a more formal announcement to the mailing list shortly. -- 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
[ANN] appengine-magic: using Clojure with Google App Engine
I'd like to announce the release of a working version of appengine- magic, a library designed to make it easier to get started with Google App Engine using Clojure. appengine-magic abstracts away nearly all the boilerplate necessary to deploy an App Engine application. It also enables interactive development through the REPL. http://github.com/gcv/appengine-magic The library is available on Clojars. It does not currently provide any App Engine services, but I wanted to get a usable version out as quickly as possible. Please look through the README file for details. Comments welcome, as always. Constantine Vetoshev -- 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: concurrency example about java x clojure
2010/9/20 Meikel Brandmeyer
> Hi,
>
> Am 20.09.2010 um 18:52 schrieb John Cromartie:
>
> >> (def flip-map #(apply zipmap ((juxt vals keys) %)))
> >>
> >
> > If I was going to write flip-map it might be a tad longer, but lazy
> > and a bit clearer (IMO), with:
> >
> >(defn flip-map [m] (into {} (map (juxt second first) m)))
>
> Is there some specific reason to avoid the most straight-forward solution?
>
> user=> (defn flip-map [m] (zipmap (vals m) (keys m)))
> #'user/flip-map
> user=> (flip-map {:a 1 :b 2 :c 3 :d 4 :e 5 :f 6 :g 7 :h 8})
> {8 :h, 7 :g, 6 :f, 5 :e, 4 :d, 3 :c, 2 :b, 1 :a}
>
>
The fact that currently having vals and keys return seqs in the same order
is not guaranteed by the documentation ?
> 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: [ANN] Leiningen 1.3.1
On Mon, Sep 20, 2010 at 12:08 PM, Eric Schulte wrote: > Having recently upgraded to this newest lein > > $ lein --version > Leiningen 1.3.1 on Java 1.6.0_18 OpenJDK Client VM > > I notice that the "lein swank" command is no longer supported. Hi Eric! The swank command is not built-in to Leiningen, it's provided by the swank-clojure plugin. You can either add it on a per-project level by including it in :dev-dependencies in each project.clj or install it for all projects by manually placing the jar in ~/.lein/plugins. -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: appengine-magic: using Clojure with Google App Engine
On Sep 20, 10:15 pm, Constantine Vetoshev wrote: > I'd like to announce the release of a working version of appengine- > magic, a library designed to make it easier to get started with Google > App Engine using Clojure. > > appengine-magic abstracts away nearly all the boilerplate necessary to > deploy an App Engine application. It also enables interactive > development through the REPL. > > http://github.com/gcv/appengine-magic > It took me days to get a working app-engine development environment setup. This is very welcome indeed. Saul -- 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: concurrency example about java x clojure
Hello Laurent. Am 20.09.2010 um 22:38 schrieb Laurent PETIT: > The fact that currently having vals and keys return seqs in the same order is > not guaranteed by the documentation ? Touché. Hard to swallow the own pill. It is not mentioned in the documentation, but it is chouser's believe that keys, vals and seq return things in the same order and that that is promised although not mentioned. So it's quite likely safe to use. But you are correct. It's not officially in the docs, so my version is potentially broken. 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: concurrency example about java x clojure
2010/9/21 Meikel Brandmeyer > Hello Laurent. > > Am 20.09.2010 um 22:38 schrieb Laurent PETIT: > > > The fact that currently having vals and keys return seqs in the same > order is not guaranteed by the documentation ? > > Touché. Hard to swallow the own pill. It is not mentioned in the > documentation, but it is chouser's believe that keys, vals and seq return > things in the same order and that that is promised although not mentioned. > So it's quite likely safe to use. But you are correct. It's not officially > in the docs, so my version is potentially broken. > Sorry Meikel, I couldn't resist :-) But I also know about chouser's point of view, and I also hope as him and you that's it's "safe". Would be great if this guarantee could make it to the docs, though. > > Sincerely > Meikel > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] Leiningen 1.3.1
On Mon, Sep 20, 2010 at 3:08 PM, Eric Schulte wrote: > Hi, > > Having recently upgraded to this newest lein > > $ lein --version > Leiningen 1.3.1 on Java 1.6.0_18 OpenJDK Client VM > > I notice that the "lein swank" command is no longer supported. > > $ lein swank > That's not a task. Use "lein help" to list all tasks. > > What's the recommended way to start up a clojure server to which I can > connect with slime? I don't know if it's the currently recommended way, but I'm using lein swank with 1.3.1 without issue. Are you sure you have swank in your :dev-dependencies? (defproject dummy "1.0.0-SNAPSHOT" :description "FIXME: write" :dependencies [[org.clojure/clojure "1.2.0"] [org.clojure/clojure-contrib "1.2.0"]] *:dev-dependencies [[swank-clojure "1.2.0"]]*) -- http://www.apgwoz.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: why the big difference in speed?
I'm glad you think partition is the problem, because that was my guess too. But I think I have the answer. This is the fastest version I've seen so far: (defn gaussian-matrix-final [L] (into-array ^doubles (map double-array (repeat L (repeatedly L next- gaussian) If I understand what's going on now, then it looks like the only way to make this any faster is if next-gaussian could return primitives. The for, and doseq macros seems like they're pretty slow. -Ranjit On Sep 20, 3:30 pm, Jason Wolfe wrote: > I think partition is slowing you down (but haven't profiled to > verify). Here's a functional version that's about 70% as fast as my > "5": > > (defn gaussian-matrix6 [L] > (to-array (for [i (range L)] (into-array Double/TYPE (for [j > (range L)] (next-gaussian)) > > and I'd guess that's about as good as you're going to get, given that > this approach is necessarily going to box and unbox the doubles, and > create intermediate sequences, rather than stuffing the primitive > doubles directly into the result array. > > -Jason > > On Sep 20, 12:00 pm, Ranjit wrote: > > > Replacing the doseq's with dotimes speeds it up a little more: > > > (defn gaussian-matrix5 [^"[[D" arr] > > (dotimes [x (alength arr)] > > (dotimes [y (alength (first arr))] > > (aset-double ^doubles (aget arr (int x)) (int y) (next- > > gaussian) > > > but I'm getting reflection warnings on alength. I guess it doesn't > > cause a problem because they're only called once? > > > Also adding type hints to the more functional version of my first > > attempt speeds things up quite a bit: > > > (defn gaussian-matrix2 [L] > > (into-array ^doubles > > (map double-array (partition L (repeatedly (* L L) next- > > gaussian) > > > But it's still about 4x slower than gaussian-matrix5 above. There must > > be a way to improve on the inner loop here that doesn't require using > > indices, right? > > > On Sep 20, 12:32 pm, Jason Wolfe wrote: > > > > Oops, I found aset-double2 with tab completion and figured it was > > > build-in. Forgot it was a utility I built some time ago, a stub for a > > > Java method that does the setting. > > > > Also, I got the type hint for the "arr" arg wrong, although it didn't > > > seem to matter. > > > > Here's a fixed version in standard Clojure that's basically as fast: > > > > user> (defn gaussian-matrix4 [^"[[D" arr ^int L] > > > (doseq [x (range L) y (range L)] (aset-double ^doubles > > > (aget arr (int x)) (int y) (.nextGaussian ^Random r > > > #'user/gaussian-matrix4 > > > user> (do (microbench (gaussian-matrix3 (make-array Double/TYPE 10 > > > 10) 10)) (microbench (gaussian-matrix4 (make-array Double/TYPE 10 10) > > > 10)) ) > > > min; avg; max ms: 0.000 ; 0.033 ; 8.837 ( 56828 iterations) > > > min; avg; max ms: 0.009 ; 0.038 ; 7.132 ( 50579 iterations) > > > > It seems like you should be able to just use aset-double with multiple > > > indices (in place of aset-double2), but I can't seem to get the type > > > hints right. > > > > -Jason > > > > On Sep 20, 7:36 am, Ranjit wrote: > > > > > Thanks Jason, this is great. > > > > > I was confused earlier because I wasn't seeing reflection warnings, > > > > but it turns out that was only because I was evaluating the function > > > > definitions in the emacs buffer, and the warnings weren't visible. > > > > > I have a question about gaussian-matrix3 though. What is "aset- > > > > double2"? Is that a macro that has a type hint for an array of > > > > doubles? > > > > > Thanks, > > > > > -Ranjit > > > > On Sep 19, 5:37 pm, Jason Wolfe wrote: > > > > > > Hi Ranjit, > > > > > > The big perf differences you're seeing are due to reflective calls. > > > > > Getting the Java array bits properly type-hinted is especially tricky, > > > > > since you don't always get good reflection warnings. > > > > > > Note that aset is only fast for reference types: > > > > > > user> (doc aset) > > > > > - > > > > > clojure.core/aset > > > > > ([array idx val] [array idx idx2 & idxv]) > > > > > Sets the value at the index/indices. Works on Java arrays of > > > > > reference types. Returns val. > > > > > > So, if you want to speed things up ... here's your starting point: > > > > > > user> (set! *warn-on-reflection* true) > > > > > true > > > > > user> (import java.util.Random) > > > > > (def r (Random. )) > > > > > > (defn next-gaussian [] (.nextGaussian r)) > > > > > > (defn gaussian-matrix1 [arr L] > > > > > (doseq [x (range L) y (range L)] (aset arr x y (next-gaussian > > > > > > (defn gaussian-matrix2 [L] > > > > > (into-array (map double-array (partition L (repeatedly (* L L) > > > > > next-gaussian) > > > > > > Reflection warning, NO_SOURCE_FILE:1 - reference to field nextGaussian > > > > > can't be resolved. > > > > > > user> (do (microbench (gaussian-matrix1 (make-array Double/TYPE 10 > > > > > 10) 10)) (microbench (gaussian-matrix2 10)) ) > > > > > min;
Re: why the big difference in speed?
Actually it turns out the type hinting in gaussian-matrix-final isn't even necessary. I just took it out and the speed doesn't seem to change. On Sep 20, 7:43 pm, Ranjit wrote: > I'm glad you think partition is the problem, because that was my guess > too. But I think I have the answer. This is the fastest version I've > seen so far: > > (defn gaussian-matrix-final [L] > (into-array ^doubles (map double-array (repeat L (repeatedly L next- > gaussian) > > If I understand what's going on now, then it looks like the only way > to make this any faster is if next-gaussian could return primitives. > > The for, and doseq macros seems like they're pretty slow. > > -Ranjit > > On Sep 20, 3:30 pm, Jason Wolfe wrote: > > > I think partition is slowing you down (but haven't profiled to > > verify). Here's a functional version that's about 70% as fast as my > > "5": > > > (defn gaussian-matrix6 [L] > > (to-array (for [i (range L)] (into-array Double/TYPE (for [j > > (range L)] (next-gaussian)) > > > and I'd guess that's about as good as you're going to get, given that > > this approach is necessarily going to box and unbox the doubles, and > > create intermediate sequences, rather than stuffing the primitive > > doubles directly into the result array. > > > -Jason > > > On Sep 20, 12:00 pm, Ranjit wrote: > > > > Replacing the doseq's with dotimes speeds it up a little more: > > > > (defn gaussian-matrix5 [^"[[D" arr] > > > (dotimes [x (alength arr)] > > > (dotimes [y (alength (first arr))] > > > (aset-double ^doubles (aget arr (int x)) (int y) (next- > > > gaussian) > > > > but I'm getting reflection warnings on alength. I guess it doesn't > > > cause a problem because they're only called once? > > > > Also adding type hints to the more functional version of my first > > > attempt speeds things up quite a bit: > > > > (defn gaussian-matrix2 [L] > > > (into-array ^doubles > > > (map double-array (partition L (repeatedly (* L L) next- > > > gaussian) > > > > But it's still about 4x slower than gaussian-matrix5 above. There must > > > be a way to improve on the inner loop here that doesn't require using > > > indices, right? > > > > On Sep 20, 12:32 pm, Jason Wolfe wrote: > > > > > Oops, I found aset-double2 with tab completion and figured it was > > > > build-in. Forgot it was a utility I built some time ago, a stub for a > > > > Java method that does the setting. > > > > > Also, I got the type hint for the "arr" arg wrong, although it didn't > > > > seem to matter. > > > > > Here's a fixed version in standard Clojure that's basically as fast: > > > > > user> (defn gaussian-matrix4 [^"[[D" arr ^int L] > > > > (doseq [x (range L) y (range L)] (aset-double ^doubles > > > > (aget arr (int x)) (int y) (.nextGaussian ^Random r > > > > #'user/gaussian-matrix4 > > > > user> (do (microbench (gaussian-matrix3 (make-array Double/TYPE 10 > > > > 10) 10)) (microbench (gaussian-matrix4 (make-array Double/TYPE 10 10) > > > > 10)) ) > > > > min; avg; max ms: 0.000 ; 0.033 ; 8.837 ( 56828 iterations) > > > > min; avg; max ms: 0.009 ; 0.038 ; 7.132 ( 50579 iterations) > > > > > It seems like you should be able to just use aset-double with multiple > > > > indices (in place of aset-double2), but I can't seem to get the type > > > > hints right. > > > > > -Jason > > > > > On Sep 20, 7:36 am, Ranjit wrote: > > > > > > Thanks Jason, this is great. > > > > > > I was confused earlier because I wasn't seeing reflection warnings, > > > > > but it turns out that was only because I was evaluating the function > > > > > definitions in the emacs buffer, and the warnings weren't visible. > > > > > > I have a question about gaussian-matrix3 though. What is "aset- > > > > > double2"? Is that a macro that has a type hint for an array of > > > > > doubles? > > > > > > Thanks, > > > > > > -Ranjit > > > > > On Sep 19, 5:37 pm, Jason Wolfe wrote: > > > > > > > Hi Ranjit, > > > > > > > The big perf differences you're seeing are due to reflective calls. > > > > > > Getting the Java array bits properly type-hinted is especially > > > > > > tricky, > > > > > > since you don't always get good reflection warnings. > > > > > > > Note that aset is only fast for reference types: > > > > > > > user> (doc aset) > > > > > > - > > > > > > clojure.core/aset > > > > > > ([array idx val] [array idx idx2 & idxv]) > > > > > > Sets the value at the index/indices. Works on Java arrays of > > > > > > reference types. Returns val. > > > > > > > So, if you want to speed things up ... here's your starting point: > > > > > > > user> (set! *warn-on-reflection* true) > > > > > > true > > > > > > user> (import java.util.Random) > > > > > > (def r (Random. )) > > > > > > > (defn next-gaussian [] (.nextGaussian r)) > > > > > > > (defn gaussian-matrix1 [arr L] > > > > > > (doseq [x (range L) y (range L)] (aset arr x y > > > > > > (next-gaussian > > > > > > > (defn
Re: concurrency example about java x clojure
> > > The fact that currently having vals and keys return seqs in the same > > order is not guaranteed by the documentation ? At the recent Pragmatic Studio class I asked Rich and Stuart about this very point. As I recall, Rich said vals and keys do behave as one would hope, so that for a map m we can count on (zipmap (keys m) (vals m)) being equal to m. Again, as I recall the plan is to eventually update the documentation to reflect this. 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: what's up with user.clj?
If it is to be deprecated, is there a "correct" way of achieving the same result (having things automatically loaded when you create the repl?) --Robert McIntyre On Mon, Sep 20, 2010 at 11:59 AM, Laurent PETIT wrote: > BTW, shouldn't this "user.clj" trick be marked as deprecated, to be removed > in a future version ? > > 2010/9/19 Kevin Downey >> >> you can also run into issues with things being on the classpath for >> your project, but not being on the classpath for lein, but user.clj >> being on the classpath for both, so when lein runs it can't find >> things your user.clj tries to load >> >> On Sat, Sep 11, 2010 at 8:17 AM, Stuart Sierra >> wrote: >> > Don't know if this is the source of the problem, but your "use" syntax >> > is funky. You want: >> > >> > (use '[clojure.java.javadoc :only (javadoc)]) >> > >> > -S >> > >> > >> > >> > On Sep 11, 3:51 am, Robert McIntyre wrote: >> >> In the clojure getting started guide, it says that if user.clj is >> >> found on the classpath, then that file will be evaluated and the repl >> >> will start with any modifications made from that file. >> >> >> >> My directory structure looks like this >> >> >> >> /src/user.clj >> >> /src/rlm/quick.clj >> >> /lib/*all-my-jars* >> >> >> >> I have a function (dirty) in quick.clj that essentially does: >> >> >> >> (defn dirty [] >> >> (use :reload-all '[clojure.java [javadoc :only [javadoc]]) >> >> (clojure.java.javadoc/add-local-javadoc "/path/to/local/javadocs")) >> >> >> >> (dirty) works fine at the repl if I type (do (require 'rlm.quick) >> >> (rlm.quick/dirty)) >> >> >> >> If I define user.clj like so: >> >> >> >> (ns user) >> >> (require 'rlm.quick) >> >> (rlm.quick/dirty) >> >> >> >> Then I get the error : java.lang.ClassNotFoundException: >> >> clojure.java.javadoc >> >> >> >> If I move the (clojure.java.javadoc/add-local-javadoc >> >> "/path/to/local/javadocs") from (dirty) straight into user.clj it >> >> works fine. >> >> >> >> what's up with this? >> >> >> >> --Robert McIntyre >> >> >> >> and user.clj reads like this >> > >> > -- >> > 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 > > -- > 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 meetup group listing
The L.A. one is at http://www.meetup.com/Los-Angeles-Clojure-Users-Group/ On Sep 20, 8:33 am, Andrew Gwozdziewycz wrote: > Hey All, > > I know there are certainly a few groups out there (organized via > Meetup.com or otherwise) which I see things posted about from time to > time on the list. I'd like to propose that we make an effort to list > these groups on Meetup Everywhere (http://www.meetup.com/everywhere), > which is a free platform useful for finding a nearby meetup about a > given topic. Please note, this is not meant to overtake your existing > organization method. Everywhere is designed to be agnostic in regards > to organization platform. > > If enough groups start listing there, it might make sense to then post > a link on the Clojure site to help people find their local user group: > > http://www.meetup.com/Clojure > > I can make changes to the page as necessary. > > Cheers, > > Andrew > > --http://www.apgwoz.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure meetup group listing
We've got one in the Raleigh area that, while not specific to Clojure, it is a common topic (along with other JVM based languages such as Scala and Groovy): http://www.meetup.com/TriJVM/ Though a Clojure specific meetup would be nice, I know for a fact there are other Clojure users here. On Sep 20, 11:33 am, Andrew Gwozdziewycz wrote: > Hey All, > > I know there are certainly a few groups out there (organized via > Meetup.com or otherwise) which I see things posted about from time to > time on the list. I'd like to propose that we make an effort to list > these groups on Meetup Everywhere (http://www.meetup.com/everywhere), > which is a free platform useful for finding a nearby meetup about a > given topic. Please note, this is not meant to overtake your existing > organization method. Everywhere is designed to be agnostic in regards > to organization platform. > > If enough groups start listing there, it might make sense to then post > a link on the Clojure site to help people find their local user group: > > http://www.meetup.com/Clojure > > I can make changes to the page as necessary. > > Cheers, > > Andrew > > --http://www.apgwoz.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
Clojure Serial Connection
I list, i am trying to connect to a USB GSM Modem with clojure. Basically, i want to open a serial connection to my modem and be able to pass commands to it. ( I think I am new to this whole modem thing). I know I can do this in Java, but wanted to check if someone had a working solutions in Clojure. I am looking similar to this http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/14d33b36279fe104/b7d0caa5540b0281?#b7d0caa5540b0281 I have google around and not really found anything. Does anyone have any suggestions? Thanks Ivan Willig -- 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: why the big difference in speed?
On Sep 20, 4:43 pm, Ranjit wrote: > I'm glad you think partition is the problem, because that was my guess > too. But I think I have the answer. This is the fastest version I've > seen so far: > > (defn gaussian-matrix-final [L] > (into-array ^doubles (map double-array (repeat L (repeatedly L next- > gaussian) The ^doubles type hint is wrong (it means array of doubles, not seq of arrays of doubles); the compiler is just ignoring it. And the reason it's so fast is probably since you're repeating the same L gaussian values L times here. Doesn't matter how fast it runs if it returns the wrong answer :-). Anyway, that might indicate that the .nextGaussian is actually the bottleneck in the fastest versions. -Jason > If I understand what's going on now, then it looks like the only way > to make this any faster is if next-gaussian could return primitives. > > The for, and doseq macros seems like they're pretty slow. > > -Ranjit > > On Sep 20, 3:30 pm, Jason Wolfe wrote: > > > I think partition is slowing you down (but haven't profiled to > > verify). Here's a functional version that's about 70% as fast as my > > "5": > > > (defn gaussian-matrix6 [L] > > (to-array (for [i (range L)] (into-array Double/TYPE (for [j > > (range L)] (next-gaussian)) > > > and I'd guess that's about as good as you're going to get, given that > > this approach is necessarily going to box and unbox the doubles, and > > create intermediate sequences, rather than stuffing the primitive > > doubles directly into the result array. > > > -Jason > > > On Sep 20, 12:00 pm, Ranjit wrote: > > > > Replacing the doseq's with dotimes speeds it up a little more: > > > > (defn gaussian-matrix5 [^"[[D" arr] > > > (dotimes [x (alength arr)] > > > (dotimes [y (alength (first arr))] > > > (aset-double ^doubles (aget arr (int x)) (int y) (next- > > > gaussian) > > > > but I'm getting reflection warnings on alength. I guess it doesn't > > > cause a problem because they're only called once? > > > > Also adding type hints to the more functional version of my first > > > attempt speeds things up quite a bit: > > > > (defn gaussian-matrix2 [L] > > > (into-array ^doubles > > > (map double-array (partition L (repeatedly (* L L) next- > > > gaussian) > > > > But it's still about 4x slower than gaussian-matrix5 above. There must > > > be a way to improve on the inner loop here that doesn't require using > > > indices, right? > > > > On Sep 20, 12:32 pm, Jason Wolfe wrote: > > > > > Oops, I found aset-double2 with tab completion and figured it was > > > > build-in. Forgot it was a utility I built some time ago, a stub for a > > > > Java method that does the setting. > > > > > Also, I got the type hint for the "arr" arg wrong, although it didn't > > > > seem to matter. > > > > > Here's a fixed version in standard Clojure that's basically as fast: > > > > > user> (defn gaussian-matrix4 [^"[[D" arr ^int L] > > > > (doseq [x (range L) y (range L)] (aset-double ^doubles > > > > (aget arr (int x)) (int y) (.nextGaussian ^Random r > > > > #'user/gaussian-matrix4 > > > > user> (do (microbench (gaussian-matrix3 (make-array Double/TYPE 10 > > > > 10) 10)) (microbench (gaussian-matrix4 (make-array Double/TYPE 10 10) > > > > 10)) ) > > > > min; avg; max ms: 0.000 ; 0.033 ; 8.837 ( 56828 iterations) > > > > min; avg; max ms: 0.009 ; 0.038 ; 7.132 ( 50579 iterations) > > > > > It seems like you should be able to just use aset-double with multiple > > > > indices (in place of aset-double2), but I can't seem to get the type > > > > hints right. > > > > > -Jason > > > > > On Sep 20, 7:36 am, Ranjit wrote: > > > > > > Thanks Jason, this is great. > > > > > > I was confused earlier because I wasn't seeing reflection warnings, > > > > > but it turns out that was only because I was evaluating the function > > > > > definitions in the emacs buffer, and the warnings weren't visible. > > > > > > I have a question about gaussian-matrix3 though. What is "aset- > > > > > double2"? Is that a macro that has a type hint for an array of > > > > > doubles? > > > > > > Thanks, > > > > > > -Ranjit > > > > > On Sep 19, 5:37 pm, Jason Wolfe wrote: > > > > > > > Hi Ranjit, > > > > > > > The big perf differences you're seeing are due to reflective calls. > > > > > > Getting the Java array bits properly type-hinted is especially > > > > > > tricky, > > > > > > since you don't always get good reflection warnings. > > > > > > > Note that aset is only fast for reference types: > > > > > > > user> (doc aset) > > > > > > - > > > > > > clojure.core/aset > > > > > > ([array idx val] [array idx idx2 & idxv]) > > > > > > Sets the value at the index/indices. Works on Java arrays of > > > > > > reference types. Returns val. > > > > > > > So, if you want to speed things up ... here's your starting point: > > > > > > > user> (set! *warn-on-reflection* true) > > > > > > true > > > > > > user> (impo
Re: what's up with user.clj?
user.clj is very useful, I'd rather keep it. On Mon, Sep 20, 2010 at 7:33 PM, Robert McIntyre wrote: > If it is to be deprecated, is there a "correct" way of achieving the > same result (having things automatically loaded when you create the > repl?) > > --Robert McIntyre > > On Mon, Sep 20, 2010 at 11:59 AM, Laurent PETIT > wrote: >> BTW, shouldn't this "user.clj" trick be marked as deprecated, to be removed >> in a future version ? >> >> 2010/9/19 Kevin Downey >>> >>> you can also run into issues with things being on the classpath for >>> your project, but not being on the classpath for lein, but user.clj >>> being on the classpath for both, so when lein runs it can't find >>> things your user.clj tries to load >>> >>> On Sat, Sep 11, 2010 at 8:17 AM, Stuart Sierra >>> wrote: >>> > Don't know if this is the source of the problem, but your "use" syntax >>> > is funky. You want: >>> > >>> > (use '[clojure.java.javadoc :only (javadoc)]) >>> > >>> > -S >>> > >>> > >>> > >>> > On Sep 11, 3:51 am, Robert McIntyre wrote: >>> >> In the clojure getting started guide, it says that if user.clj is >>> >> found on the classpath, then that file will be evaluated and the repl >>> >> will start with any modifications made from that file. >>> >> >>> >> My directory structure looks like this >>> >> >>> >> /src/user.clj >>> >> /src/rlm/quick.clj >>> >> /lib/*all-my-jars* >>> >> >>> >> I have a function (dirty) in quick.clj that essentially does: >>> >> >>> >> (defn dirty [] >>> >> (use :reload-all '[clojure.java [javadoc :only [javadoc]]) >>> >> (clojure.java.javadoc/add-local-javadoc "/path/to/local/javadocs")) >>> >> >>> >> (dirty) works fine at the repl if I type (do (require 'rlm.quick) >>> >> (rlm.quick/dirty)) >>> >> >>> >> If I define user.clj like so: >>> >> >>> >> (ns user) >>> >> (require 'rlm.quick) >>> >> (rlm.quick/dirty) >>> >> >>> >> Then I get the error : java.lang.ClassNotFoundException: >>> >> clojure.java.javadoc >>> >> >>> >> If I move the (clojure.java.javadoc/add-local-javadoc >>> >> "/path/to/local/javadocs") from (dirty) straight into user.clj it >>> >> works fine. >>> >> >>> >> what's up with this? >>> >> >>> >> --Robert McIntyre >>> >> >>> >> and user.clj reads like this >>> > >>> > -- >>> > 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 >> >> -- >> 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 -- 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: what's up with user.clj?
On Mon, Sep 20, 2010 at 10:07 PM, Kevin Downey wrote: > On Mon, Sep 20, 2010 at 7:33 PM, Robert McIntyre wrote: >> If it is to be deprecated, is there a "correct" way of achieving the >> same result (having things automatically loaded when you create the >> repl?) > > user.clj is very useful, I'd rather keep it. Agreed; there are some neat tricks that would be really hard to do without it. -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: concurrency example about java x clojure
On Mon, Sep 20, 2010 at 7:15 PM, David Cabana wrote: >> > > The fact that currently having vals and keys return seqs in the same >> > order is not guaranteed by the documentation ? > > At the recent Pragmatic Studio class I asked Rich and Stuart about > this very point. As I recall, Rich said vals and keys do behave as one > would hope, so that for a map m we can count on (zipmap (keys m) (vals > m)) being equal to m. Again, as I recall the plan is to eventually > update the documentation to reflect this. I think it's guaranteed within a given map instance, but if you dissoc something out from it or get a new map based on the old one in some way then all bets are off. -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
