Here is something I wrote as a Clojure learning exercise.
I have a suspicion that a serious implementation of this may exist,
please let me know if that is so!
Cheers,
Victor Rodriguez.
http://gist.github.com/82727
;;; A toy to experiment with Clojure macros.
;;;
;;; (f "1 + 2 = ~(+ 1 2)") re
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 disillusion
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 8-c
Here, here!
+1 +1 +1 ... !!
On Fri, Mar 20, 2009 at 2:26 PM, Rayne 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 this wonderful
> l
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'.
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 wrote:
>
> On Fri, Mar 20, 2009 at 4:02 PM, Jeffrey Straszheim
> wrote:
> > +1
> > I think two simple atomic integers would do the trick:
> > 1. Number of transactions entered
> > 2. N
On Fri, Mar 20, 2009 at 4:02 PM, Jeffrey Straszheim
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 implement this myself in
+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 wrote:
>
> It seems that an important part of optimizing the
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?
--
R.
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 wrote:
> I Anthony Simpson, with the support of fellow Clojurists hereby
> declare March 20th, the first day of spring, Rich Hickey appreciation
> day!
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 wonder
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 bri
On Mar 20, 7:15 am, Rich Hickey 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, mult
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
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 s
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
m
e patterns- 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 wrote:
>
> New release 20090320 -
> http://clojure.googlecode.com/files/clojure_20090320.zip
>
> Incorporates all the rece
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 id
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 wrote:
> This works well as long as you don't mind the perf hit for the second
> dispatch :)
>
>
> On Fri, Mar 20, 2009 at 11:35 AM, Paul Stad
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
>
This works well as long as you don't mind the perf hit for the second
dispatch :)
On Fri, Mar 20, 2009 at 11:35 AM, Paul Stadig wrote:
> 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
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"))
#
user=> (defmethod plus-int java.lang.Double [x y] (println "one of each"))
#
user=> (defmulti plus (fn [x y] (type x)))
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 wrote:
> New release 20090320 -http://clojure.googlecode.com/files/clojure_20090320.zip
>
> I
On Mar 20, 10:56 am, Konrad Hinsen 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
v
On Mar 20, 10:15 am, Rich Hickey 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, mult
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
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
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 co
>
> 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
ab
Here: http://gist.github.com/82352
I have posted memory and cpu profiling figures.
On Mar 20, 6:56 am, Christophe Grand wrote:
> 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 J
Hi Frantisek,
Frantisek Sodomka wrote:
> On Mar 19, 11:37 pm, Jason Sankey 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-contri
On Mar 20, 1:09 am, bgray 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 you are subscribe
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 function
On Mar 19, 11:37 pm, Jason Sankey 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 test clojure
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 nearl
On Mar 19, 11:08 pm, Stuart Sierra
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 testing the language its
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 lazy
37 matches
Mail list logo
