ANN: Clojure Cookbook
Ladies and Gentlemen, I present for your viewing pleasure the Clojure Cookbook (beta :) ): http://www.gettingclojure.com/cookbook:clojure-cookbook Gregg Williams has set up a framework at Getting Clojure to gather material, primarily focused on newbies, on how to flatten the learning curve. The cookbook is a part of that vision. Inspired of course by O'Reilly's Perl Cookbook, the cookbook aims to present concrete examples along with brief discussions of specific tasks a new Clojure programmer might want to accomplish. The cookbook should complement the existing Clojure books and other documentation and provide additional examples that the other resources don't have time or space to consider. At this point I have seeded the cookbook with approximately 20 recipes. I want to emphasize that I hope this will be a community resource with others providing content or even fixing my explanations where they are incorrect or off target. At the moment the cookbook is essentially read-only aside from the comments section at the bottom of each page. But once we get a sense of the community response the site will be opened for anyone to contribute. Please take a look at the site and let us know what works and what needs to be fixed. And start thinking up your own recipes. Thanks. Have all good days, David Sletten -- 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: Some code dramatically slower in Clojure 1.3 Alpha 1?
I found that even without patching, most functions in clojure.contrib.math already correctly handle big nums in 1.3: Handles big nums in 1.3? absYes ceil Yes exact-integer-sqrt No expt No floor Yes gcdYes lcmYes round No sqrt Yes After patching the code to use +', -', *', inc', and dec', expt handled big nums correctly as well. However, exact-integer-sqrt and round still didn't. math=> (exact-integer-sqrt 234523454564564565435456456456) IllegalArgumentException No method in multimethod 'integer-length' for dispatch value: class clojure.lang.BigInt clojure.lang.MultiFn.getFn (MultiFn.java:121) math=> (round 23450928345029834502983450283405.1) 9223372036854775807 exact-integer-sqrt appears to need the integer-length multi-method to support the new clojure.lang.BigInt class. I'm guessing that's also why round is returning an incorrect result; since there's currently no case for clojure.lang.BigInt, it's falling through to the default of using Math/round, leading to truncation. Just replacing +, -, *, inc, dec with +', -', *', inc', and dec' did not result in any performance gains. I didn't want to clutter up this email with my test code, but if anyone wishes to see the code I used, just let me know. -- 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: functions left over in the vm
I generally use the ns macro to jump around my namespaces (like I use ls to change directories in the shell) , and use a convenience function I wrote called ns-nuke, which gets rid of all functions defined in that ns. Then I use reload, another convenience function, which just uses that namespace again. This works for me but then again my code is rather small. If you are using emacs, you can do C-c C-k to recompile that namespace as well. I used to restart my repl all the time but I don't ever do that anymore after making ns-nuke (and a function to add stuff to the classpath :)) You can also use user.clj to preload convenience functions, so that you no longer need to experience the pain of a million (use) statements on a restart. Here are my functions that they may be helpful to you: (defmacro ns-nuke ([] (let [current-ns# (symbol (str *ns*))] `(do (println "NUKING namespace" (quote ~current-ns#)) (clojure.lang.Namespace/remove (quote ~current-ns#)) (ns ~current-ns#) (defmacro reload [] `(do (use :reload-all (quote ~(symbol (str *ns*)) --Robert McIntyre On Sun, Sep 26, 2010 at 5:56 PM, Michael Ossareh wrote: > How are other people handling the process of reducing code in their > projects? > Situation: We've built a product, very rapidly thanks to being able to > produce stuff very quickly in clojure. However now that it is somewhat > settled I'm in the process of paring down the code, removing defunct fn's, > etc. > Problem: You compile your code, you test it, you pare down some functions or > rename a function and push that into the VM - hit refresh, everything works. > However there is a chance you are actually using a function which you have > removed from the source code. i.e. you missed a reference in another file or > something similar. Most recently I removed a pointless wrapper fn around > another fn, however the wrapped fn was declared private. Everything seemed > to be working until I compiled the source and found out that my fn's were > calling the wrappee which was still in scope within the VM . > I've now started to use lein uberjar to point out cases that I'm doing this > - and it's fine for now, however it is a bit of a throwback to the pains of > Java development. > Another solution I've been using is to regularly restart my running clojure > instance, however this has the annoyance of me losing all my locally defined > vars during dev. > Thanks for any suggestions on 'dev best practices' in this space. > Cheers, > mike > > -- > 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: functions left over in the vm
On Sun, Sep 26, 2010 at 2:56 PM, Michael Ossareh wrote: > Situation: We've built a product, very rapidly thanks to being able to > produce stuff very quickly in clojure. However now that it is somewhat > settled I'm in the process of paring down the code, removing defunct fn's, > etc. It's actually pretty easy to identify what defns don't get run in a namespace with a judicious use of alter-var-root and metadata. I've implemented this in Radagast, my simple test coverage tool: http://github.com/Seajure/radagast It's not _that_ useful for test coverage because it doesn't handle branch-level metrics, but as a "what functions are dead weight that's not getting called" detector it works great! > Problem: You compile your code, you test it, you pare down some functions or > rename a function and push that into the VM - hit refresh, everything works. > However there is a chance you are actually using a function which you have > removed from the source code. i.e. you missed a reference in another file or > something similar. We call this "getting slimed". There is currently no solution for this at least in Emacs. I would like to have a version of slime-compile-file that would remove all vars in the namespace before recompiling, but I haven't had the chance to implement it. Patches welcome, of course. > Another solution I've been using is to regularly restart my running clojure > instance, however this has the annoyance of me losing all my locally defined > vars during dev. Restarting your VM should not be an annoyance. If you are creating data or functions in order to test, you should create them in your test suite. That way it's easy to run a fully-fresh run of the tests. You don't even have to restart your swank VM; it should be totally separate to avoid contamination. -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: An Emacs command to close the various balanced expressions in Clojure
Thank you blais --- I also have troubles with paredit and this function will really help me out. keep up the good work, --Robert McIntyre On Sun, Sep 26, 2010 at 8:19 PM, Tassilo Horn wrote: > Hi, > > did you already try out paredit [1]? That mode is absolutely fabulous > for programming any lisp and provides much more than just closing > parens. > > Give it a shot! > > Bye, > Tassilo > > Footnotes: > [1] http://mumble.net/~campbell/emacs/paredit.el > > -- > 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: An Emacs command to close the various balanced expressions in Clojure
Hi, did you already try out paredit [1]? That mode is absolutely fabulous for programming any lisp and provides much more than just closing parens. Give it a shot! Bye, Tassilo Footnotes: [1] http://mumble.net/~campbell/emacs/paredit.el -- 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: An Emacs command to close the various balanced expressions in Clojure
I'm curious what you don't like about the automatic insertion scheme
that you talked about. I'm using Parenedit with emacs and I'm quite
happy with it. I think the scheme is quite simple... whenever you type
'(', it inserts ')'. Similarly with '[' and '{'.
-Patrick
On Sep 26, 7:51 pm, blais wrote:
> Hi,
>
> Writing Clojure code tends to require a larger mix of "()",
> "[]" and "{}" characters than other LISPs I use. This
> sometimes makes it a bit tiring to write those balanced
> expressions.
>
> Writing balanced expressions has been addressed in editors
> mainly by providing the automated insertion of matching
> characters when you type an opening character. This kind of
> support usually also comes with a fancy overloading of the
> default insertion behaviour of those characters to
> automatically skip extraneous ones, locking you into keeping
> everything balanced all the time; I find this extremely
> distracting and annoying to use, because it changes the
> behaviour I expect from my editor (it doesn't *always*
> insert, it is deeply troubling to me). I've tried it, and I
> could not get used to it.
>
> I came up with what I see as a better solution, and it feels
> right to me: a simple command to automatically insert the
> "correct" closing character at the current cursor location.
> For example, invoking the same command 4 times when the cursor
> is at the '|' location in the following expression will do
> the right thing:
>
> (comment
> (use '[merced.testinput :only (protocol|
>
> results in:
>
> (comment
> (use '[merced.testinput :only (protocol)]))
>
> One advantage of this approach is the absence of "modality,"
> i.e., the behaviour is the same in all contexts, e.g. when I
> type to insert, it always inserts. The new command means
> "insert to close the sequence here, whatever the sequence
> character is."
>
> If you want to try it, here is the corresponding Emacs code:
>
> (defvar close-matching-chars
> '( (?( . ?))
> (?[ . ?])
> (?{ . ?})
> (?< . >})
> ))
>
> (defun close-matching ()
> "Close with the most appropriate matching balanced character."
> (interactive)
> ;; Scan backwards until it stops.
> (let ((c (save-excursion
> (while (ignore-errors (forward-sexp -1) (not (<=
> (point) 1
> (backward-char 1)
> (string-to-char (thing-at-point 'char))
> )))
> (insert-char (cdr (assoc c close-matching-chars)) 1)
> ))
>
> Bind it to your favourite key (I use 'Ctrl-)' ):
>
> (global-set-key [(control \))] 'close-matching)
>
> Have fun,
--
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
An Emacs command to close the various balanced expressions in Clojure
Hi,
Writing Clojure code tends to require a larger mix of "()",
"[]" and "{}" characters than other LISPs I use. This
sometimes makes it a bit tiring to write those balanced
expressions.
Writing balanced expressions has been addressed in editors
mainly by providing the automated insertion of matching
characters when you type an opening character. This kind of
support usually also comes with a fancy overloading of the
default insertion behaviour of those characters to
automatically skip extraneous ones, locking you into keeping
everything balanced all the time; I find this extremely
distracting and annoying to use, because it changes the
behaviour I expect from my editor (it doesn't *always*
insert, it is deeply troubling to me). I've tried it, and I
could not get used to it.
I came up with what I see as a better solution, and it feels
right to me: a simple command to automatically insert the
"correct" closing character at the current cursor location.
For example, invoking the same command 4 times when the cursor
is at the '|' location in the following expression will do
the right thing:
(comment
(use '[merced.testinput :only (protocol|
results in:
(comment
(use '[merced.testinput :only (protocol)]))
One advantage of this approach is the absence of "modality,"
i.e., the behaviour is the same in all contexts, e.g. when I
type to insert, it always inserts. The new command means
"insert to close the sequence here, whatever the sequence
character is."
If you want to try it, here is the corresponding Emacs code:
(defvar close-matching-chars
'( (?( . ?))
(?[ . ?])
(?{ . ?})
(?< . >})
))
(defun close-matching ()
"Close with the most appropriate matching balanced character."
(interactive)
;; Scan backwards until it stops.
(let ((c (save-excursion
(while (ignore-errors (forward-sexp -1) (not (<=
(point) 1
(backward-char 1)
(string-to-char (thing-at-point 'char))
)))
(insert-char (cdr (assoc c close-matching-chars)) 1)
))
Bind it to your favourite key (I use 'Ctrl-)' ):
(global-set-key [(control \))] 'close-matching)
Have fun,
--
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 1.3.0-alpha1
Am 24.09.2010 17:09, schrieb Stuart Sierra: I have deployed release 1.3.0-alpha1 of clojure-contrib. This is the first public release of the modularized clojure-contrib. If you just want one big JAR file, download it from http://github.com/clojure/clojure-contrib/downloads If you want JARs for individual modules, look at http://build.clojure.org/releases/org/clojure/contrib/ Would it also be possible to offer a .zip file that contains all individual modules, but without the folder structure that currently is optimized for Maven? That is, a .zip containing just all the .jar files on top level, which can be easily classpathed? Sunny greetings, André -- 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
Some programs require much more memory in Clojure 1.3 alpha1
While updating the benchmark programs I wrote for the shootout web site for 1.3 alpha1, I came across a program that required much more memory to complete in 1.3 than it did in 1.2. I boiled it down to a simpler program that has similar properties. (ns filestr2 (:gen-class)) (defn -main [& args] (with-open [br (java.io.BufferedReader. *in*)] (let [dna-str (apply str (line-seq br))] (println "len=" (count dna-str (. System (exit 0))) I've checked that the function apply, str, and line-seq are identical between those two Clojure versions, except for a few minor things like type declarations and static declarations added in 1.3.0-alpha1. I'm curious if anyone can explain the cause of this significant extra memory. As an example of what I mean, when run on an input file with about 125 million characters, it requires 932 Mbytes with Clojure 1.2, but 1,736 Mbytes with Clojure 1.3 alpha1 (using the -Xmx command line option to the JVM). That was on my Mac, and I've seen similar but not identical results on an Ubuntu system. You can read more details if you are curious in the README file of this tarball: http://homepage.mac.com/jafingerhut/files/private/toomuch1.tar.bz2 It also includes a program that uses binary search to find the smallest memory required in order for the program to succeed, to the nearest 8 MB. Thanks, Andy -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Literal collection of numbers - prefer list or vector?
David Sletten writes: > Umm, kind of...The single quote is a macro character not a real > macro. And I didn't say it was a macro. It's a macro character tied to a reader macro, and it participates in read-time macroexpansion. , | user> (quote (a 'b)) | (a (quote b)) ` [...] > The reader silently converts 'pung to (quote pung) prior to > evaluation, so you have to come at it in a roundabout way: That's not conspiring; that's read-time macroexpansion working as intended. -- Steven E. Harris -- 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
functions left over in the vm
How are other people handling the process of reducing code in their projects? Situation: We've built a product, very rapidly thanks to being able to produce stuff very quickly in clojure. However now that it is somewhat settled I'm in the process of paring down the code, removing defunct fn's, etc. Problem: You compile your code, you test it, you pare down some functions or rename a function and push that into the VM - hit refresh, everything works. However there is a chance you are actually using a function which you have removed from the source code. i.e. you missed a reference in another file or something similar. Most recently I removed a pointless wrapper fn around another fn, however the wrapped fn was declared private. Everything seemed to be working until I compiled the source and found out that my fn's were calling the wrappee which was still in scope within the VM . I've now started to use lein uberjar to point out cases that I'm doing this - and it's fine for now, however it is a bit of a throwback to the pains of Java development. Another solution I've been using is to regularly restart my running clojure instance, however this has the annoyance of me losing all my locally defined vars during dev. Thanks for any suggestions on 'dev best practices' in this space. Cheers, mike -- 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: Does 'lein repl' session give slow processing for you, too?
Possibly related -- I've noticed that lein repl on Mac / Linux seems to break type hinting. $ lein repl user=> (set! *warn-on-reflection* true) true user=> (defn foo [^String s] (.charAt s 1)) Reflection warning, NO_SOURCE_PATH:2 - call to charAt can't be resolved. $ java -cp `lein classpath` clojure.main user=> (set! *warn-on-reflection* true) true user=> (defn foo [^String s] (.charAt s 1)) #'user/foo user => ... and the execution speed of foo in the first context is much slower. On Sep 25, 12:28 pm, Phil Hagelberg wrote: > On Sat, Sep 25, 2010 at 1:20 AM, Andy Fingerhut > > wrote: > > % lein repl > > > [ Here, if I do load-file, the timing results are about the same as above. > > But if I copy and paste the forms one at a time, then I get a time like the > > one below for the last form: > > > user=> (time (vec (swapping a1 10))) > > "Elapsed time: 12683.523 msecs" > > > This is easily reproducible on my system Mac and Linux systems. Happens > > every time. This is about 200 times longer than all of the previously > > mentioned timing results. ] > > > Anyone else see this? Or even better, know why it happens? > > It appears to be related to a problem with ant. Loading the exact same > repl code by manually starting a subprocess has no problem at all. > > I'm about fed up with ant; it seems that over half the problems with > Leiningen these days are either bugs in ant or problems in code that > Leiningen must include to work around bugs in ant. I'm brainstorming > ways to remove this dependency, but the JVM is pretty crippled when it > comes to things like unix process management. > > -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
VerifyError with symbol metadata, macros, and defrecord
In Clojure 1.2, compiling the code below blows up with: error: java.lang.VerifyError: (class: t1/core/One, method: signature: ()V) Incompatible argument to function (core.clj:11) Something about this problem causes damage to the running Clojure process. Once the exception happens, changing the macro to a working version will not make the sample work with the tagged symbol, almost as if the symbol 'one (below) is somehow corrupt. You either need to start a new REPL, or try to invoke the macro with a different tagged symbol. I'm honestly not even sure if (1) I don't understand something, (2) this is a bug in Clojure, or (3) this is just a remarkably unhelpful error message. (ns t1.core) (defmacro mac1 [name properties] ;; does not work: (let [key-info (keyword (first (filter #(meta %) properties)))] ;; works: ;(let [key-info (keyword (str (first (filter #(meta %) properties] (prn key-info) ;; commenting out the defrecord below also makes this work: `(defrecord ~name ~properties))) (mac1 One [^:key one, two]) -- 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: Literal collection of numbers - prefer list or vector?
On Sep 26, 2010, at 10:42 AM, Steven E. Harris wrote: > ataggart writes: > >> Vectors also permit evaluation of the literal collection's elements: >> >> user=> [(+ 1 2) (+ 3 4)] >> [3 7] >> user=> '((+ 1 2) (+ 3 4)) >> ((+ 1 2) (+ 3 4)) > > That's a false distinction. You used `quote' rather than > `list'. Macroexpand your form to see: > > , > | user> (quote ((+ 1 2) (+ 3 4))) > | ((+ 1 2) (+ 3 4)) > ` > Umm, kind of...The single quote is a macro character not a real macro. Therefore it's not subject to macroexpansion as macros are. Unfortunately the Clojure reader normally conspires against you to hide what's really going on. The reader silently converts 'pung to (quote pung) prior to evaluation, so you have to come at it in a roundabout way: (read-string "'((+ 1 2) (+ 3 4))") => (quote ((+ 1 2) (+ 3 4))) (count (read-string "'((+ 1 2) (+ 3 4))")) => 2 (class (read-string "'((+ 1 2) (+ 3 4))")) => clojure.lang.Cons (first (read-string "'((+ 1 2) (+ 3 4))")) => quote At least the Clojure printer is cooperating here. In Common Lisp the printer helps hide QUOTE too in the first line here: ? (read-from-string "'(+ 1 2)") '(+ 1 2) 8 ? (first (read-from-string "'(+ 1 2)")) QUOTE ? (length (read-from-string "'(+ 1 2)")) 2 Have all good days, David Sletten -- 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: Literal collection of numbers - prefer list or vector?
ataggart writes: > Vectors also permit evaluation of the literal collection's elements: > > user=> [(+ 1 2) (+ 3 4)] > [3 7] > user=> '((+ 1 2) (+ 3 4)) > ((+ 1 2) (+ 3 4)) That's a false distinction. You used `quote' rather than `list'. Macroexpand your form to see: , | user> (quote ((+ 1 2) (+ 3 4))) | ((+ 1 2) (+ 3 4)) ` Quote is not a list constructor. It simply returns what the reader had constructed without evaluating it, and in this case, the reader had constructed a list. What you should have supplanted the vector literal reader with was the `list' function: , | user> (list (+ 1 2) (+ 3 4)) | (3 7) | user> (vector (+ 1 2) (+ 3 4)) | [3 7] ` -- Steven E. Harris -- 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: clojure-maven-plugin 1.3.4 released
'lo all, I just released the clojure-maven-plugin 1.3.4 which should be hitting maven central in the next hour or so: I'd like to thank all those who've contributed patches for this release ( Alex Miller, Sam Umbach, Viktor Matic, Peter Schuller, Raoul Duke, Paudi Moriaty, and w...@glozer.net ( not sure your full name off hand? ) * New Autodoc goal - requires clojars repository to be added, clojure-contrib and your chosen autodoc version to be added as a dependency ( Alex Miller ) * New configuration element - also settable via -Dclojure.vmargs ( Alex Miller ) * New clojure pom type - predefines executions - just declare the plugin. * White space in classpath is now escaped ( Sam Umbach ) * New configuration element (Viktor Matic) * is no longer a required setting for clojure:run, goal now supports and -Dclojure.mainClass ( Peter Schuller ) * Added as an configuration option, automatically create and use a throw away temp dir for compiling to classes * Added utf-8 to specific swank protocol encoding, defaults to iso-8859-1 which is clojure-swanks default (w...@glozer.net) * clojure:swank now defaults to localhost, can be configured via or -Dclojure.swank.host * REPL issues on Windows "fixed" by spawning clojure in a new window ( Raoul Duke ) * New test-with-junit goal ( Paudi Moriaty ) * New param to allow escaping to be disabled - required for clojure 1.2.0 and junit ( Paudi Moriaty ) Mark -- Pull me down under... -- 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: Literal collection of numbers - prefer list or vector?
Vectors also permit evaluation of the literal collection's elements: user=> [(+ 1 2) (+ 3 4)] [3 7] user=> '((+ 1 2) (+ 3 4)) ((+ 1 2) (+ 3 4)) On Sep 25, 6:43 am, Joop Kiefte wrote: > the vector form. in idiomatic clojure, lists are practically only used > for code and macro's. > > 2010/9/25 HiHeelHottie : > > > For a literal collection of numbers which would be more idiomatic and > > why? > > > (reduce + '(1 2 3)) vs (reduce + [1 2 3]) > > > -- > > 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 > > -- > Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 > > Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over > Esperanto? Perguntas sobre o Esperanto? -http://demandoj.tk -- 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
Base64, bytes, and Clojure 1.3
A while back I wrote a Base64 encoder, and have been using it to play with the primitive enhancements in 1.3. After a bit of fiddling I was able to get it from around an order of magnitude slower than apache commons-codec down to about 5x slower. Taking Rich's exclamation that "clojure was meant to replace java, not ruby" to heart, I fired up the profiler. It turns out that calls to aset-byte were killing me. The aset-byte macro expanded into clojure.core$aset_byte.invoke(Object, Object, Object), an autoboxing nightmare. By replacing those calls with plain aset (which goes to one of the primitive RT.aset methods), it's now *faster* than commons-codec: user=> (time (dotimes [_ 1] (Base64/encodeBase64 rand- bytes-4096))) "Elapsed time: 413.225 msecs" nil user=> (time (dotimes [_ 1] (encode rand-bytes-4096))) "Elapsed time: 182.8 msecs" nil A few other things I ran into: - bit-shifting requires int or long if you want to avoid reflection, so bytes from the array had to be explicitly converted. - But you can't convert a byte to a long (missing overload on longCast), you have to use int - the let bindings are smart, but if the value is the result of some expression (e.g., case) then it needs to be wrapped in a cast if you want a primitive instead of an Object binding. http://github.com/ataggart/codec/blob/master/src/codec/base64.clj -- 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
