Phil Hagelberg a écrit :
But I did notice you have the use test-is line commented out in the
implementation; it seems a bit unfortunate to have to uncomment that to
run the tests and hope you remember to re-comment it before you commit.
The last commit was during the transition to
On Mar 19, 11:08 pm, Stuart Sierra the.stuart.sie...@gmail.com
wrote:
Hi Frantisek!
I can see where this is useful, and the only reason I haven't
implemented something like it for a test-is already is that I don't
expect it would be very commonly used outside of the very specific
case of
On Mar 19, 11:37 pm, Jason Sankey ja...@zutubi.com wrote:
I pretty much have it working for the test-clojure suite now, although
I'm sure the code could use review by a more experienced eye. I've been
looking at adding the other two top-level suites (test-contrib and
datalog) too, but their
Hello Vincent,
Vincent Foley a écrit :
Hello,
For the past few days, I've been trying, unsuccessfully, to make an
application I wrote faster. A Java program that performs, more or
less, the same task takes 12 seconds (on my machine) to parse 1000
files; my Clojure program takes nearly 3
I'm in the process of working on a *nix system library that will be
able to perform tasks based on OS type (Linux, Solaris, AIX, etc.) and
possibly filesystem type in the future. While doing this commands
vary across the operating systems. To get around this I plan on
writing a dispatch
Hi Frantisek,
Frantisek Sodomka wrote:
On Mar 19, 11:37 pm, Jason Sankey ja...@zutubi.com wrote:
I pretty much have it working for the test-clojure suite now, although
I'm sure the code could use review by a more experienced eye. I've been
looking at adding the other two top-level suites
On Mar 20, 1:09 am, bgray graybran...@gmail.com wrote:
(defmulti something :os-type)
(defmethod something Mac OS X [os x y]
(+ x y))
Try:
(defmulti something (fn [os x y] (:os-type os)))
- James
--~--~-~--~~~---~--~~
You received this message because
Here: http://gist.github.com/82352
I have posted memory and cpu profiling figures.
On Mar 20, 6:56 am, Christophe Grand christo...@cgrand.net wrote:
Hello Vincent,
Vincent Foley a écrit :
Hello,
For the past few days, I've been trying, unsuccessfully, to make an
application I wrote
I like the sequential let too. For one thing, it allows for the breaking
apart of complex expressions into more comprehensible parts, with well named
intermediate variables resulting in self documenting code.
About the 7-part *let* as shown in your example: Could we get some opinions
about
On Mar 20, 2009, at 14:35, Joshua Fox wrote:
I thought of let as a sort of variable declaration, and so, one
would want to keep it simple and not do complex calculations in the
let binding expressions.
On the other hand, the sequential mutually-dependent let bindings
are of course
New release 20090320 - http://clojure.googlecode.com/files/clojure_20090320.zip
Incorporates all the recent additions - fully lazy seqs, :let option
for doseq/for, letfn for mutually recursive local fns, synchronous
watches, multi-arg set/union/difference/intersection, counted?, per-
defmulti
Providing a :default implementation for multimethods is a very common
and useful technique, but it is really useful only for multimethods
that dispatch on a single argument. What I am looking for is an
equivalent technique for multiple-argument dispatch.
Suppose you have a multimethod + of
On Mar 20, 10:15 am, Rich Hickey richhic...@gmail.com wrote:
New release 20090320 -http://clojure.googlecode.com/files/clojure_20090320.zip
Incorporates all the recent additions - fully lazy seqs, :let option
for doseq/for, letfn for mutually recursive local fns, synchronous
watches, multi
On Mar 20, 10:56 am, Konrad Hinsen konrad.hin...@laposte.net wrote:
Providing a :default implementation for multimethods is a very common
and useful technique, but it is really useful only for multimethods
that dispatch on a single argument.
I disagree about that. No dispatch value,
Congrats, and a HUGE thank you to you and everyone else in the
community that has contributed code or their good spirit to the
community.
- Chas
On Mar 20, 10:15 am, Rich Hickey richhic...@gmail.com wrote:
New release 20090320 -http://clojure.googlecode.com/files/clojure_20090320.zip
You could use multiple multi-methods:
user= (defmulti plus-int (fn [x y] (type y)))
#'user/plus-int
user= (defmethod plus-int :default [x y] (println the first is an int))
#MultiFn clojure.lang.mult...@11992cc
user= (defmethod plus-int java.lang.Double [x y] (println one of each))
#MultiFn
I am updating some of the examples in the FP chapter to use letfn, and
the book is already up-to-date on fully lazy seqs.
Any other new features jump out as must discuss in book?
Stu
New release 20090320 -
http://clojure.googlecode.com/files/clojure_20090320.zip
Incorporates all
It's also not as maintainable as using a single multi-method.
Like I said, not pretty, but it works.
Paul
On Fri, Mar 20, 2009 at 11:38 AM, David Nolen dnolen.li...@gmail.comwrote:
This works well as long as you don't mind the perf hit for the second
dispatch :)
On Fri, Mar 20, 2009 at
Rich,
Can we please track this as an issue.
--Steve
On Feb 13, 2009, at 11:13 AM, Stephen C. Gilardi wrote:
How does this interact with:
http://code.google.com/p/clojure/issues/detail?id=3
I don't know enough to answer properly. Perhaps we can make it moot
by fixing issue 3.
I have
- the diversity and
friendliness of the community is amazing.
All built on top of the JVM, whodathunk?
David
On Fri, Mar 20, 2009 at 10:15 AM, Rich Hickey richhic...@gmail.com wrote:
New release 20090320 -
http://clojure.googlecode.com/files/clojure_20090320.zip
Incorporates all the recent additions
On Mar 20, 2009, at 16:35, Paul Stadig wrote:
You could use multiple multi-methods:
...
Not pretty, as you said, but also not quite the same in behaviour as
a single multimethod dispatching on both arguments. Multiple dispatch
can be made symmetric in the arguments, whereas a chain of
On Mar 20, 2009, at 16:18, Rich Hickey wrote:
Providing a :default implementation for multimethods is a very common
and useful technique, but it is really useful only for multimethods
that dispatch on a single argument.
I disagree about that. No dispatch value, composite or not, is still a
On Mar 20, 2009, at 12:39 PM, Stephen C. Gilardi wrote:
Rich,
Can we please track this as an issue.
Yes, sure.
Rich
--Steve
On Feb 13, 2009, at 11:13 AM, Stephen C. Gilardi wrote:
How does this interact with:
http://code.google.com/p/clojure/issues/detail?id=3
I don't know
On Mar 20, 7:15 am, Rich Hickey richhic...@gmail.com wrote:
New release 20090320 -http://clojure.googlecode.com/files/clojure_20090320.zip
Incorporates all the recent additions - fully lazy seqs, :let option
for doseq/for, letfn for mutually recursive local fns, synchronous
watches, multi
I Anthony Simpson, with the support of fellow Clojurists hereby
declare March 20th, the first day of spring, Rich Hickey appreciation
day!
Rich Hickey has certainly done a lot for us, making this wonderful
language and continuing to take his time to work on it. He is
dedicated and he wants to
I join the crowd lauding our BDFL!
Thank Rich and long live Clojure!
Rayne a écrit :
I Anthony Simpson, with the support of fellow Clojurists hereby
declare March 20th, the first day of spring, Rich Hickey appreciation
day!
Rich Hickey has certainly done a lot for us, making this wonderful
Hooray! I will definately give a big thanks here from Denmark
for all your hard work Rich!
Keep up the good work,
Lau
On Mar 20, 7:26 pm, Rayne disciplera...@gmail.com wrote:
I Anthony Simpson, with the support of fellow Clojurists hereby
declare March 20th, the first day of spring, Rich
It seems that an important part of optimizing the performance of a
Clojure application may be to attempt to minimize the number of
retries that are performed in transactions. What are good ways to
detect and count retries other than explicitly adding code inside
dosync calls to count them?
--
+1
I think two simple atomic integers would do the trick:
1. Number of transactions entered
2. Number completed, or exited through exception.
The amount 1 exceeds 2 is your retry rate.
On Fri, Mar 20, 2009 at 4:38 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote:
It seems that an
On Fri, Mar 20, 2009 at 4:02 PM, Jeffrey Straszheim
straszheimjeff...@gmail.com wrote:
+1
I think two simple atomic integers would do the trick:
1. Number of transactions entered
2. Number completed, or exited through exception.
The amount 1 exceeds 2 is your retry rate.
Right. I could
The last I looked it would need to be added at the Java level.
On Fri, Mar 20, 2009 at 5:32 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote:
On Fri, Mar 20, 2009 at 4:02 PM, Jeffrey Straszheim
straszheimjeff...@gmail.com wrote:
+1
I think two simple atomic integers would do the trick:
I'm trying to install clojure on Debian 5.0 and having some troubles.
Typing ant in the clojure directory gives me the error:
compile-java:
[javac] Compiling 119 source files to /home/dan/opt/clojure/classes
[javac] Compliance level '1.4' is incompatible with target level
'1.5'. A
Here, here!
+1 +1 +1 ... !!
On Fri, Mar 20, 2009 at 2:26 PM, Rayne disciplera...@gmail.com wrote:
I Anthony Simpson, with the support of fellow Clojurists hereby
declare March 20th, the first day of spring, Rich Hickey appreciation
day!
Rich Hickey has certainly done a lot for us, making
I have not had a chance to merge the parallel updates in to life-
conway.clj in the files section yet, but for now I thought I would
note I did make one fun enhancement, which is to have each thread
color code the cells. So all cells with the same color were processed
by one pmap thread. On my
I wrote my first program in Fortran in 1975. Since then I've worked in
Assember, Jcl, Rexx, Lisp 370, C, C++, VB (the low-light of my
career), and a host of scripting/macro tools. I started with Java in
1998 and my own business in 2002 (web apps and backends with
Java/Jsp/Js). I became
35 matches
Mail list logo
