Re: to macro or not?
Mike, I mean this is just one example to prove your ideas, not to disprove. On Oct 29, 4:26 am, Mike Meyer wrote: > On Thu, 28 Oct 2010 18:12:39 -0700 (PDT) > > andrei wrote: > > > I'll try to extend Mike's answer by one more example. Consider `and` > > Lisp macro. It is not a function, because it must evaluate it's > > arguments lazily, and using macros is the only way to do it. > > Actually, this is the first case, and a classic example of it: you > need to control how many times the arguments are evaluated. > > > But try > > to apply `and` to the list of values (I know, that it's a job for a > > function `every?`, but how will you implement this function itself?): > > > (apply and (list true true false true)) ==> error > > And this is the issue of not being able to pass macros to higher order > functions. > > > You cannot do it, since and is not a function. So, you need to use > > wrapper around `and`: > > > (reduce #(and %1 %2) (list true true false true)) ==> false > > > And this is still not the perfect solution, since it is not lazy. > > > So you can see both advantages and disadvantages of using macros. > > Which is why you only want to use them when you have to. If you don't > need the advantages, why put up with the disadvantages? > > -- > Mike Meyer http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org -- 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: How to simplify cond statements
On Oct 29, 4:03 am, lprefonta...@softaddicts.ca wrote: > user=> (doc ffirst) > - > clojure.core/ffirst > ([x]) > Same as (first (first x)) > nil > user=> > > That could help a bit : Nice! I didn't know about this function, and for this concrete case it is ideal! -- 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: How to simplify cond statements
On Oct 29, 4:03 am, Andrew Gwozdziewycz wrote: > I'd hoist the empty out of the cond using an if: > > (if (empty? ps) > ret > (let [fps (first (first ps))] > (cond > ...))) Yeah, I thought about it, but it is still a bit verbose, especially with a 3 conditions loop. I mean, when you have only 3 lines in cond (and this is the most frequent case for me), adding 3 new lines to reduce... well, acceptable, but not in all cases. -- 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: How to simplify cond statements
On Oct 29, 5:40 am, David Sletten wrote:
> You could just bind another local variable in the loop form:
> (loop [ps pairs
> ret {}
> ffps (ffirst ps)]
> (cond (empty? ps) ret
> (some-test ffps) (recur (rest ps) (add-to-result ret ffps) (ffirst
> (rest ps)))
> :true (recur (rest ps) (do-sth-else ret ffps) (ffirst (rest ps )
In this case you have to pass one more parameter to each loop
iteration, and since you actually don't need this param, that breaks
loop's semantics.
Though, I haven't thought about it before, so I will give it a try.
> But you probably want to use 'reduce' instead of 'loop' anyway:
> (reduce (fn [ret [key val]] (if (some-test key) (add-to-result ret key)
> (do-sth-else ret key))) {} pairs)
Yeah, in 90-95% I use reduce. But in 5-10% function cannot be written
with it, for example, when it uses true recursion, not tail call, so I
showed only very general case I have in my code frequently.
> BTW, do you really mean to call 'add-to-result' and 'do-sth-else' with a map
> and a key but no value?
Again, just general case. But thank you for caring :)
--
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: How to simplify cond statements
Hi,
On 29 Okt., 12:11, andrei wrote:
> > You could just bind another local variable in the loop form:
> > (loop [ps pairs
> > ret {}
> > ffps (ffirst ps)]
> > (cond (empty? ps) ret
> > (some-test ffps) (recur (rest ps) (add-to-result ret ffps) (ffirst
> > (rest ps)))
> > :true (recur (rest ps) (do-sth-else ret ffps) (ffirst (rest ps )
>
> In this case you have to pass one more parameter to each loop
> iteration, and since you actually don't need this param, that breaks
> loop's semantics.
There's nothing stoping you to put a let in a loop.
(loop [ps (seq pairs)
ret {}]
(let [ffps (ffirst ps)]
(cond
(not ps) ret
(some-test ffps) (recur (next ps) (add-to-result ret ffps))
:else(recur (next ps) (do-sth-else ret ffps)
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: How to simplify cond statements
On Fri, Oct 29, 2010 at 7:14 AM, Meikel Brandmeyer wrote:
>
> There's nothing stoping you to put a let in a loop.
>
> (loop [ps (seq pairs)
> ret {}]
> (let [ffps (ffirst ps)]
> (cond
> (not ps) ret
> (some-test ffps) (recur (next ps) (add-to-result ret ffps))
> :else (recur (next ps) (do-sth-else ret ffps)
This is totally true! Scheme has been my primary Lisp since coming to
clojure, and scheme would blow up when doing (first (first ps)) [a.k.a
(ffirst ps)] so I never remember that it'll just return nil instead of
blowing up (thus the reason for the (if (empty? ..)) being hoisted in
my suggested code).
--
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: How to simplify cond statements
Errr... clarification "Scheme would blow up when doing (first (first
))."
On Fri, Oct 29, 2010 at 7:44 AM, Andrew Gwozdziewycz wrote:
> On Fri, Oct 29, 2010 at 7:14 AM, Meikel Brandmeyer wrote:
>>
>> There's nothing stoping you to put a let in a loop.
>>
>> (loop [ps (seq pairs)
>> ret {}]
>> (let [ffps (ffirst ps)]
>> (cond
>> (not ps) ret
>> (some-test ffps) (recur (next ps) (add-to-result ret ffps))
>> :else (recur (next ps) (do-sth-else ret ffps)
>
> This is totally true! Scheme has been my primary Lisp since coming to
> clojure, and scheme would blow up when doing (first (first ps)) [a.k.a
> (ffirst ps)] so I never remember that it'll just return nil instead of
> blowing up (thus the reason for the (if (empty? ..)) being hoisted in
> my suggested code).
>
>
> --
> http://www.apgwoz.com
>
--
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
Pulling threads...
Please forgive the lengthy post...
New to Clojure and trying to get a friend excited about it by demonstrating
how Clojure's functional/STM heritage makes it easy to write
concurrent/parallel code, but I can't get Clojure to
I started with Java, where 256 threads are vying to increment a single
counter 10,000 times each:
public class Concurrent {
static final int NUM_THREADS = 256;
static final int NUM_CALLS = 1;
volatile boolean started = false;
volatile int counter = 0;
synchronized void incrementCounter() { counter += 1; }
public static void main(final String[] args) throws Exception {
final Concurrent c = new Concurrent();
final Thread[] threads = new Thread[NUM_THREADS];
for (int i = 0; i < NUM_THREADS; i++) {
threads[i] = new Thread(new Runnable() {
public void run() {
while (!c.started);
for (int i = 0; i < NUM_CALLS; i++) c.incrementCounter();
}
});
threads[i].start();
}
final long start = System.currentTimeMillis();
c.started = true;
for (int i = 0; i < NUM_THREADS; i++) threads[i].join();
System.out.println("counter = "+c.counter+" and took
"+(System.currentTimeMillis() - start)+" ms.");
System.exit(0);
}
}
You may wonder why such a high thread/increment count. I needed numbers
this substantial because Java and my W510 are simply that efficient at
handling it:
$ time /opt/jdk1.6/bin/java Concurrent
counter = 256 and took 481 ms.
real0m12.782s
user1m36.286s
sys0m0.251s
(Most of the "real" time is spent creating and starting the threads. In
fact, the purpose of "started" is because it takes less time to count 10,000
times than to create a new thread, so I wanted to force all 256 threads to
"hold" until I could "start" them all simultaneously.)
This is a trivial example, but illustrates the practice of combining
volatile fields with synchronized methods... I wish that looked "harder",
because I'm trying to sell Clojure here! In any case, the following is the
first Clojure program I've ever written to "demonstrate" how easily STM
tackles this:
(def NUM_THREADS 256)
(def NUM_CALLS 1)
(def started (ref false))
(def counter (ref 0))
(defn increment-counter [] (dosync (alter counter inc)))
(def threads
(map #(Thread. %)
(repeat NUM_THREADS
#(do
(while (not @started))
(dotimes [_ NUM_CALLS] (increment-counter))
(map #(.start %) threads)
(let [start (System/currentTimeMillis)]
(dosync (ref-set started true))
(map #(.join %) threads)
(println (format "counter = %d and took %d ms." @counter (-
(System/currentTimeMillis) start
The only problem is that this DOESN'T WORK and I don't know why (I'll save a
humorous tangent about the effects of forgetting the "@" in "(while (not
@started))"). This is best illustrated by running it:
$ time /opt/jdk1.6/bin/java -jar ~/dev/lang/clojure-1.2.0/clojure.jar
java_like.clj
counter = 0 and took 1 ms.
real0m1.059s
user0m1.280s
sys0m0.058s
As you can see, it very quickly did nothing -- ignoring my "(map #(.join %)
threads)". Running the same code in the REPL produces interesting results.
The REPL, too, will print instantly and prompt me for more work. However,
it's clearly executing the threads, as repeated "@counter" invocations show
an incrementing counter. And it is absolutely dog slow: my 1/2 seconds of
spinning in native Java takes an eternal 2 1/2 minutes in Clojure.
I suspect the culprit is my "let": getting rid of it causes "(map #(.join
%) threads)" to behave as expected. But, I don't get it. Maybe "let" is
executing in another thread I don't know about and it is _that_ thread that
is waiting to join. Thoughts?
Meanwhile, this probably isn't what I want, anyway. I should be using
Clojure's own mechanisms for parallelism: pmap. My first attempt failed
miserably:
(def NUM_THREADS 256)
(def NUM_CALLS 1)
(def TOTAL (* NUM_THREADS NUM_CALLS))
(def counter (ref 0))
(defn increment-counter [_] (dosync (alter counter inc)))
(let [start (System/currentTimeMillis)]
(pmap increment-counter (range TOTAL))
(println (format "counter = %d and took %d ms." @counter (-
(System/currentTimeMillis) start
This suffers the same problem as my first attempt: it prints before it
completes. The problem is that it once it completes "@counter" returns 32
(I believe that's the size of Clojure's thread pool). I've not figured out
how to force Clojure to actually get beyond this number (I thought maybe
some element of laziness was coming into play here, but, if so, I've not
figured out how to de-lazify it)...
Interestingly, my second attempt fared better:
(def NUM_THREADS 256)
(def NUM_CALLS 1)
(def TOTAL (* NUM_THREADS NUM_CALLS))
(def counter (ref 0))
(defn increment-counter [] (dosync (alter counter inc)))
(let [start (System/currentTimeMillis)]
(apply pcalls (repeat TOT
Re: Pulling threads...
Hi, On 29 Okt., 06:58, Brian Ericson wrote: > (map #(.start %) threads) map is not a loop. It creates a lazy sequences which does - nothing. At least not until it is realised. Here you throw it away immediatelly. Hence, no work is done. Use doseq instead when your main objective are side-effects like .start or .join. It works in the repl, because the repl prints the seq and thus realises it forcing the work to be done. Hope this helps. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: apply an higher order function on an arbitrary nested data structure
Does fmap remove enough complexity to warrant it's own fn? Here's what fmap would now look like. (def fmap (partial same map)) Granted, it's probably the #1 use for same, so you might have a point. Sean On Oct 29, 12:44 am, Konrad Hinsen wrote: > On 28.10.2010, at 21:57, Sean Devlin wrote: > > > Okay, functor is a good idea but a weak implementation. My complaint > > is that it only provides functor behavior for the map function. same > > is a higher order function that works on anything, and is based on > > protocols. Take a look at the test cases to understand what I'm > > talking about. > > I agree that a muiltimethod is no longer the best choice for implementing > functor-like functionality in Clojure, now that we have protocols. But I > think that the mathematical abstraction of a functor is of use (for reasoning > about programs) and should be visible as such. "same" seems more concerned > about abstracting away implementation details, e.g. between the different map > implementations, than with implementing a well-defined mathematical concept. > > > This should replace the contrib lib, because it provide more > > functionality. > > I'd say that something like same should be used to implement something like > fmap. > > Konrad. -- 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
Jython Interoperability problem
Hi, It was possible in clojure 1.0.0 to include clojure Persistent collections in Jython: jython -Dpython.path=/clojure_1.0.0/clojure-1.0.0.jar >>>from clojure.lang import PersistentList >>>b= PersistentList.create([7, 8, 2]) >>>b (7 8 2) But with clojure 1.1.0 or 1.2.0 I get: jython -Dpython.path=/clojure-1.2.0/clojure.jar >>> from clojure.lang import PersistentList >>> b= PersistentList.create([7, 8, 2]) >>> b Traceback (most recent call last): File "", line 1, in java.lang.ExceptionInInitializerError at clojure.lang.ASeq.toString(ASeq.java:20) at org.python.core.PyJavaType$5.__call__(PyJavaType.java:542) at org.python.core.PyObjectDerived.__repr__(PyObjectDerived.java:63) at org.python.core.PySystemState.displayhook(PySystemState.java:1190) at org.python.core.PySystemStateFunctions.__call__(PySystemState.java: 1257) at org.python.core.PyObject.invoke(PyObject.java:3583) at org.python.core.Py.printResult(Py.java:1748) at org.python.pycode._pyx5.f$0(:1) at org.python.pycode._pyx5.call_function() at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyCode.call(PyCode.java:18) at org.python.core.Py.runCode(Py.java:1204) at org.python.core.Py.exec(Py.java:1248) at org.python.util.PythonInterpreter.exec(PythonInterpreter.java:181) at org.python.util.InteractiveInterpreter.runcode(InteractiveInterpreter.java: 89) at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java: 70) at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java: 46) at org.python.util.InteractiveConsole.push(InteractiveConsole.java: 110) at org.python.util.InteractiveConsole.interact(InteractiveConsole.java: 90) at org.python.util.jython.run(jython.java:316) at org.python.util.jython.main(jython.java:129) Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: Could not locate clojure/core__init.class or clojure/core.clj on classpath: at clojure.lang.RT.(RT.java:305) ... 21 more Caused by: java.io.FileNotFoundException: Could not locate clojure/ core__init.class or clojure/core.clj on classpath: at clojure.lang.RT.load(RT.java:412) at clojure.lang.RT.load(RT.java:381) at clojure.lang.RT.doInit(RT.java:416) at clojure.lang.RT.(RT.java:302) ... 21 more java.lang.ExceptionInInitializerError: java.lang.ExceptionInInitializerError Any clues? -- 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: to macro or not?
> one is told to avoid macros as long as possible. I've heard this before, but I believe it's intended to be interpreted differently. I believe, it's meant to more like "don't use them unless you need them", which some people translate into "avoid them". I have heard, as a rule of thumb, that less than 5% of your code should be macros. That's not to suggest they shouldn't be used, but rather to be selective when using them. There are probably some people who love them so much they're using them when it's not needed - resulting in code being more complex than needed, therefore difficult to maintain. > if you aren't using macros, then sorta why bother use a Lisp since you are > missing out on one of the most powerful differentiators. then Very true. > any way of teasing out when macros are ok? I try writing code without macros, first, then I look at my code and ask myself a few questions: 1. Can I create a macro which would make my code shorter and more readable/mainatainable? 2. Are there areas in my code where performance matters and macro logic could help in that regard? * This one's tricky since you really need to understand when evaluations occur and if added complexity causes bad operations or poor sequencing. Recently I've been discovering that some macro's in a more verbose/ uglier/non-idiomatic, yet strategically structured form can sometimes create 30 - 40% in run time savings. So for me, I've been challenging my dependency upon the idiomatic, to see if I can improve things. *I KNOW, I KNOW - Can you believe it? - Idiomatic code may not always be the best way! * ^_^ Tim -- 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: (count (filter ...)) much slower in 1.3 Alpha 2?
Could someone else also try the sample code I included to see if they
also experience the same ~10x slowdown for (count (filter ...)) in 1.3
Alpha 2?
On Oct 28, 12:34 pm, Btsai wrote:
> I have some code that counts the elements in a list that map to true
> in a lookup table, looking something like this:
>
> (def lookup-table {1 true, 2 false})
> (def elements (range 100))
> (count (filter lookup-table elements))
>
> On my machine, with server mode enabled, the count + filter got ~10
> times slower when I updated from 1.3 Alpha 1 to 1.3 Alpha 2:
>
> (Alpha 1)
> user=> (time (count (filter lookup-table elements)))
> "Elapsed time: 181.262702 msecs"
> 1
>
> (Alpha 2)
> user=> (time (count (filter lookup-table elements)))
> "Elapsed time: 2017.744155 msecs"
> 1
>
> Which is weird because looking up elements in the table did not become
> any slower:
>
> (Alpha 1)
> user=> (time (doseq [x elements] (lookup-table x)))
> "Elapsed time: 159.033341 msecs"
> nil
>
> (Alpha 2)
> user=> (time (doseq [x elements] (lookup-table x)))
> "Elapsed time: 159.965861 msecs"
> nil
--
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: (count (filter ...)) much slower in 1.3 Alpha 2?
I see the same problem:
Clojure 1.3.0-alpha1
user=> (load-file "/tmp/foo.clj")
"Elapsed time: 402.588654 msecs"
1
Clojure 1.3.0-alpha2
user=> (load-file "/tmp/foo.clj")
"Elapsed time: 4584.271921 msecs"
1
On Oct 29, 9:41 am, Btsai wrote:
> Could someone else also try the sample code I included to see if they
> also experience the same ~10x slowdown for (count (filter ...)) in 1.3
> Alpha 2?
>
> On Oct 28, 12:34 pm, Btsai wrote:
>
> > I have some code that counts the elements in a list that map to true
> > in a lookup table, looking something like this:
>
> > (def lookup-table {1 true, 2 false})
> > (def elements (range 100))
> > (count (filter lookup-table elements))
>
> > On my machine, with server mode enabled, the count + filter got ~10
> > times slower when I updated from 1.3 Alpha 1 to 1.3 Alpha 2:
>
> > (Alpha 1)
> > user=> (time (count (filter lookup-table elements)))
> > "Elapsed time: 181.262702 msecs"
> > 1
>
> > (Alpha 2)
> > user=> (time (count (filter lookup-table elements)))
> > "Elapsed time: 2017.744155 msecs"
> > 1
>
> > Which is weird because looking up elements in the table did not become
> > any slower:
>
> > (Alpha 1)
> > user=> (time (doseq [x elements] (lookup-table x)))
> > "Elapsed time: 159.033341 msecs"
> > nil
>
> > (Alpha 2)
> > user=> (time (doseq [x elements] (lookup-table x)))
> > "Elapsed time: 159.965861 msecs"
> > nil
--
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: (count (filter ...)) much slower in 1.3 Alpha 2?
My results are actually worse. I get about a 40x slowdown, going from ~50ms in 1.2.0 to ~2000ms in 1.3.0-alpha2. On Oct 29, 12:41 pm, Btsai wrote: > Could someone else also try the sample code I included to see if they > also experience the same ~10x slowdown for (count (filter ...)) in 1.3 > Alpha 2? -- 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: (count (filter ...)) much slower in 1.3 Alpha 2?
Confirmed. I am looking into this. For some reason the call to filter is
reflective in alpha 2.
> Could someone else also try the sample code I included to see if they
> also experience the same ~10x slowdown for (count (filter ...)) in 1.3
> Alpha 2?
>
> On Oct 28, 12:34 pm, Btsai wrote:
>> I have some code that counts the elements in a list that map to true
>> in a lookup table, looking something like this:
>>
>> (def lookup-table {1 true, 2 false})
>> (def elements (range 100))
>> (count (filter lookup-table elements))
>>
>> On my machine, with server mode enabled, the count + filter got ~10
>> times slower when I updated from 1.3 Alpha 1 to 1.3 Alpha 2:
>>
>> (Alpha 1)
>> user=> (time (count (filter lookup-table elements)))
>> "Elapsed time: 181.262702 msecs"
>> 1
>>
>> (Alpha 2)
>> user=> (time (count (filter lookup-table elements)))
>> "Elapsed time: 2017.744155 msecs"
>> 1
>>
>> Which is weird because looking up elements in the table did not become
>> any slower:
>>
>> (Alpha 1)
>> user=> (time (doseq [x elements] (lookup-table x)))
>> "Elapsed time: 159.033341 msecs"
>> nil
>>
>> (Alpha 2)
>> user=> (time (doseq [x elements] (lookup-table x)))
>> "Elapsed time: 159.965861 msecs"
>> nil
>
> --
> 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: (count (filter ...)) much slower in 1.3 Alpha 2?
Rich has fixed this on master:
http://github.com/clojure/clojure/commit/e354b01133e7cff8dc0d0eb9e90cde894c12e127
Thanks for the report!
Stu
> I have some code that counts the elements in a list that map to true
> in a lookup table, looking something like this:
>
> (def lookup-table {1 true, 2 false})
> (def elements (range 100))
> (count (filter lookup-table elements))
>
> On my machine, with server mode enabled, the count + filter got ~10
> times slower when I updated from 1.3 Alpha 1 to 1.3 Alpha 2:
>
> (Alpha 1)
> user=> (time (count (filter lookup-table elements)))
> "Elapsed time: 181.262702 msecs"
> 1
>
> (Alpha 2)
> user=> (time (count (filter lookup-table elements)))
> "Elapsed time: 2017.744155 msecs"
> 1
>
> Which is weird because looking up elements in the table did not become
> any slower:
>
> (Alpha 1)
> user=> (time (doseq [x elements] (lookup-table x)))
> "Elapsed time: 159.033341 msecs"
> nil
>
> (Alpha 2)
> user=> (time (doseq [x elements] (lookup-table x)))
> "Elapsed time: 159.965861 msecs"
> nil
>
> --
> 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: How to simplify cond statements
On Oct 29, 2:14 pm, Meikel Brandmeyer wrote: > There's nothing stoping you to put a let in a loop. Yes, but imagine a bit more complicated case, for example, instead of '(first (first ps))' write (.foo (first ps)), and it will crash. I'm looking for elegant, but general case template. -- 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: How to simplify cond statements
(first (flatten ...)) ? 2010/10/29 andrei : > > > On Oct 29, 2:14 pm, Meikel Brandmeyer wrote: >> There's nothing stoping you to put a let in a loop. > > Yes, but imagine a bit more complicated case, for example, instead of > '(first (first ps))' write (.foo (first ps)), and it will crash. I'm > looking for elegant, but general case template. > > -- > 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
Re: (count (filter ...)) much slower in 1.3 Alpha 2?
Awesome, thank you :)
On Oct 29, 2:29 pm, Stuart Halloway wrote:
> Rich has fixed this on
> master:http://github.com/clojure/clojure/commit/e354b01133e7cff8dc0d0eb9e90c...
>
> Thanks for the report!
>
> Stu
>
>
>
>
>
>
>
> > I have some code that counts the elements in a list that map to true
> > in a lookup table, looking something like this:
>
> > (def lookup-table {1 true, 2 false})
> > (def elements (range 100))
> > (count (filter lookup-table elements))
>
> > On my machine, with server mode enabled, the count + filter got ~10
> > times slower when I updated from 1.3 Alpha 1 to 1.3 Alpha 2:
>
> > (Alpha 1)
> > user=> (time (count (filter lookup-table elements)))
> > "Elapsed time: 181.262702 msecs"
> > 1
>
> > (Alpha 2)
> > user=> (time (count (filter lookup-table elements)))
> > "Elapsed time: 2017.744155 msecs"
> > 1
>
> > Which is weird because looking up elements in the table did not become
> > any slower:
>
> > (Alpha 1)
> > user=> (time (doseq [x elements] (lookup-table x)))
> > "Elapsed time: 159.033341 msecs"
> > nil
>
> > (Alpha 2)
> > user=> (time (doseq [x elements] (lookup-table x)))
> > "Elapsed time: 159.965861 msecs"
> > nil
>
> > --
> > 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
[OT] Photos from Clojure Conj 2010
Hello, I had the pleasure of attending the first Clojure Conj and I have uploaded some photographs that I took there - http://www.flickr.com/photos/ghoseb/sets/72157625254615916/ Enjoy. Regards, BG -- Baishampayan Ghose b.ghose at gmail.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: Photos from Clojure Conj 2010
Thanks for sharing these! On Oct 29, 4:40 pm, Baishampayan Ghose wrote: > Hello, > > I had the pleasure of attending the first Clojure Conj and I have > uploaded some photographs that I took there > -http://www.flickr.com/photos/ghoseb/sets/72157625254615916/ > > Enjoy. > > Regards, > BG > > -- > Baishampayan Ghose > b.ghose at gmail.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: [OT] Photos from Clojure Conj 2010
Nice pics. I am incredibly jealous of everyone that had the chance to attend. -Terrance Baishampayan Ghose wrote: Hello, I had the pleasure of attending the first Clojure Conj and I have uploaded some photographs that I took there - http://www.flickr.com/photos/ghoseb/sets/72157625254615916/ Enjoy. Regards, BG -- 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: Test for whether a function accepts a particular arity.
You can use some Reflection to find out if the function has implemented the matching invoke(args*) method see: http://gist.github.com/654851 On 29 Okt., 07:02, Ken Wesson wrote: > (defn accepts-arity? [n f] > (reduce > #(or > %1 > (= n (count %2)) > (and (= '& (last (butlast %2))) (>= n (- (count %2) 2 > false > (:arglists (meta f > > This works only if f has metadata -- anonymous lambdas don't but functions > defined using defn do. > > I thought this up while reading some intro to clojure.contrib.monad that > mentioned that m-lift needs to be given an arity; it seems to me m-lift > could probably be implemented to use the arities in the function metadata, > when available, to make this optional. -- 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 on Javascript
Has anyone thought about putting clojure on javascript? Tim Daly -- 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 on Javascript
Now that server side javascript is growing with node.js, clojure on javascript will be usefull. Nodejs is event based and not thread based so I don't know the ramifications on clojure yet. On Sat, Oct 30, 2010 at 8:33 AM, Tim Daly wrote: > Has anyone thought about putting clojure on javascript? > > Tim Daly > > -- > 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 -- http://hi.im/santosh -- 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: Test for whether a function accepts a particular arity.
There's also this, I suppose: (defn accepts-arity? [n f] (try (apply f (repeat n nil)) true (catch IllegalArgumentException e (not (.startsWith (.getMessage e) "Wrong number of args"))) (catch Throwable _ true))) This directly tests for the exception that's generated if the arity is wrong. Caveats: 1. It's somewhat evil; in particular it throws away all exceptions generated and relies on the exact wording of the throw-arity exception message text which is meant for humans and so probably isn't considered part of the api per se. In particular it might change, and this function might even stop working if you take it outside of EN_us. 2. It calls the function, so that better not have side effects or take forever to run (at least when called with nil arguments). 3. If the function, called with a valid arglist, can generate an IAE that starts with "Wrong number of args" it could produce a false negative. The likeliest source of these would be functions that contain bugs of the form of having a nested function call with a bad arity. -- 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 on Javascript
cf. node js, I thought of mentioning this link http://dosync.posterous.com/22397098 On Fri, Oct 29, 2010 at 11:10 PM, Santosh Rajan wrote: > Now that server side javascript is growing with node.js, clojure on > javascript will be usefull. Nodejs is event based and not thread based so I > don't know the ramifications on clojure yet. > > > On Sat, Oct 30, 2010 at 8:33 AM, Tim Daly wrote: > >> Has anyone thought about putting clojure on javascript? >> >> Tim Daly >> >> -- >> 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 > > > > > -- > http://hi.im/santosh > > > > -- > 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: to macro or not?
Macros in lisp get used for three general purposes, at least in my experience. The first purpose is efficiency. In common lisp you will find that you can generate very machine-efficient (aka optimized fortran level) binary instruction sequences if you add type information. This gets tedious to do in code so you write a macro. So (+ x y) has to assume that x and y are anything, including non-numeric. If you write a (plus x y) macro it can expand to (the fixnum (+ (the fixnum x) (the fixnum y))) which I have seen optimized into a single machine instruction. Macros could be used to solve the boxing/unboxing issues in Clojure. The second purpose is novel control structure. Axiom uses a type-dispatch macro that does a "method lookup" in a "class" (bad analogy but...) and the type dispatch macro gets expanded at compile time to a constant-index offset into a fixed-array data structure. So the total cost is a single index pointer fetch at runtime. You could write a "domap" macro that works like the "map" function but isn't lazy. Replace your "map" with "domap" and solve the lazy issue mentioned in another thread (or just use seq :-) ) The third purpose is a domain specific language. At work my team always communicates using certain words and phrases such as CCAs, behavior catalogs, etc. and we use a locally invented notation. I took the notation and added parentheses in all the right places and implemented macros for them. Now I can take a specification, plop in some parens, and execute the specification. This makes it much easier to ensure the implementation follows the specification. It also allows me to macro-expand the same line of code for several kinds of output Our files are XML but our displays are for humans. Since both outputs come from the same macro I know they match. Macros are not hard but you need to think like a compiler rather than a programmer. You are transforming a program into a program. Macros really bring home the point that your program is data and your data is a program. It is worth learning to write macros just for that insight alone. Tim Daly On 10/28/2010 3:55 PM, Raoul Duke wrote: hi, not looking to stir up a pot, looking to learn from people's experience. i've heard that in CL land, one is told to avoid macros as long as possible. i've heard other folks in the Clojure world say that if you aren't using macros, then sorta why bother use a Lisp since you are missing out on one of the most powerful differentiators. then reading about Conj it sounds like some folks say stay away from macros if you can. any way of teasing out when macros are ok? :-) i mean, are they only ok for the internals of the Clojure system? 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: Clojure on Javascript
A port of Clojure to JS would be interesting. Rich has expressed interest and Chouser's ClojureScript is a step in that direction. On Fri, Oct 29, 2010 at 11:28 PM, Victor Olteanu wrote: > cf. node js, I thought of mentioning this link > http://dosync.posterous.com/22397098 I'm the author of this post comparing a very, very, very early version of Aleph to Node.js. It was primarily written as a critique of, IMO, the myopic rhetoric about JS and threaded vs evented server side programming to be found on main Node.js site. Node.js is a cool project targeted at a specific audience and Ryan seems to be a talented programmer. But to me Clojure provides all the benefits and none of the limitations so I felt compelled to blog about that. JS brought me to Lisp, I would love to see the Clojure community bring Lisp back to JS. However I fail to see what advantage JS gives on the server side. From what I've seen the V8 GC and Node.js have a considerable number of years to go before they are serious contenders against the JVM for non-trivial projects, evented or no. More interesting would be something along the lines of CoffeeScript (like ClojureScript) that takes a reasonable subset Clojure and compiles into efficient JS, allowing Clojure programmers to send Clojure code to clients. 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: Clojure on Javascript
On Oct 29, 2010, at 11:09 PM, David Nolen wrote: > JS brought me to Lisp, I would love to see the Clojure community bring Lisp > back to JS. However I fail to see what advantage JS gives on the server side. > From what I've seen the V8 GC and Node.js have a considerable number of years > to go before they are serious contenders against the JVM for non-trivial > projects, evented or no. Agreed. What is the point of Javascript on the server side? Familiarity? Consistency with client-side code? > More interesting would be something along the lines of CoffeeScript (like > ClojureScript) that takes a reasonable subset Clojure and compiles into > efficient JS, allowing Clojure programmers to send Clojure code to clients. Yes! Writing Javascript makes me want to throw things. Client-side Clojure would be fantastic. -- 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: [OT] Photos from Clojure Conj 2010
On Fri, Oct 29, 2010 at 4:26 PM, Terrance Davis wrote: > Nice pics. I am incredibly jealous of everyone that had the chance to > attend. Me too! Although a friend of mine attended and got me a T shirt! (thanx Roger!) Hopefully next year's conj will get on the schedule early enough that I can avoid conflicts and attend... :) -- 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
clojure.xml questions
Hi, 1. I notice there is just the "parse" function mentioned as public: http://clojure.github.com/clojure/clojure.xml-api.html I used the other functions in clojure.xml (emit, emit-element) and the var 'element' -- they appear to work fine for me. Are they just undocumented or not guaranteed to be maintained in future versions of Clojure? 2. The emitted XML string does not have indentation. Is there a way to fix that? I know there is 'prxml' in contrib but the format it expects is different (a vector) from what 'emit' expects (a map). Regards, Shantanu -- 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
