Re: Minor macroexpand issue
On 30 Aug 2010, at 23:18, Frederic Koehler wrote: I accidentally noticed this: On clojure 1.2, macroexpanding with a function name which is a class, causes this ugly error: (macroexpand '(Object)) java.lang.Exception: Expecting var, but Object is mapped to class java.lang.Object (repl-1:2) when presumably it should just give '(Object). I have no clue for any actual use cases of naming your functions after classes, but: (let [Object (fn [] 3)] (Object)) is technically valid clojure code, so macroexpand shouldn't just die... You are right that (let [Object (fn [] 3)] (Object)) is valid Clojure code, and it works as expected. However, (Object) is not a valid expression. It fails with exactly the same error message as (macroexpand '(Object)) so I'd say this is consistent behaviour. 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
Re: Is nil a compile-time literal?
My interpretation is that the hash code issue (if correct) is an implementation detail, and that this should indeed be considered a bug because nil certainly seems like a compile-time literal to me. It's also an especially useful value in the context of something like case. In any case, thanks for your response. On Aug 30, 5:12 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: case does constant-time dispatch using the hash codes of the test values. Since nil is Java null, it doesn't have a hash code, so case can't handle it. I wouldn't call it a bug, but there is work to be done on extending case to edge cases like this. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Help speed up an inner loop?
Ah, I see that I was mistaken about the timing. Sorry about that. After a lot of fiddling around, I cam up with this faster form: (defn countnl-lite [#^bytes buf] (areduce buf idx count (int 0) (if (= (clojure.lang.RT/aget buf idx) 10) (unchecked-add count 1) count))) Key points are initializing count to a primitive integer and directly calling clojure's aget to avoid an unnecessary integer cast. On my system: The unmodified countnl function takes ~ 180 msecs Without AOT compilation countnl-lite takes around 66 msecs With AOT compilation countnl-lite takes ~46 msecs The java method takes ~19 msecs. I've lost a factor of 2.25 somewhere and it makes me sad that I can't find it. I would be very interested if anyone could improve countnl-lite. --Robert McIntyre On Mon, Aug 30, 2010 at 8:41 PM, Alan a...@malloys.org wrote: I think this misses the point. Of course java, c, and clojure will all have roughly the same wall-clock time for this program, since it is dominated by the I/O. You can even see that in the output from $ time java Iterate: less than 0.5s was spent in user space, the rest was spent in system code - that is, mostly doing I/O. The java version is a second faster as counted by the wall clock, and this is unlikely to be a coincidence: tsuraan's timing data suggests that the clojure program takes 80ms longer in each loop, and loops 10 times. That comes out to 0.8 seconds, which is quite close to the differential you observed when timing from the command line. On Aug 30, 1:38 pm, Robert McIntyre r...@mit.edu wrote: I don't know what the heck is going here, but ignore the time the program is reporting and just pay attention to how long it actually takes wall-clock style and you'll see that your clojure and java programs already take the same time. Here are my findings: I saved Iterate.java into my rlm package and ran: time java -server rlm.Iterate results: time java -server rlm.Iterate Wanted 16777216 got 16777216 bytes counted 65341 nls in 27 msec Wanted 16777216 got 16777216 bytes counted 65310 nls in 27 msec Wanted 16777216 got 16777216 bytes counted 66026 nls in 21 msec Wanted 16777216 got 16777216 bytes counted 65473 nls in 19 msec Wanted 16777216 got 16777216 bytes counted 65679 nls in 19 msec Wanted 16777216 got 16777216 bytes counted 65739 nls in 19 msec Wanted 16777216 got 16777216 bytes counted 65310 nls in 21 msec Wanted 16777216 got 16777216 bytes counted 65810 nls in 18 msec Wanted 16777216 got 16777216 bytes counted 65531 nls in 21 msec Wanted 16777216 got 16777216 bytes counted 65418 nls in 21 msec real 0m27.469s user 0m0.472s sys 0m26.638s I wrapped the last bunch of commands in your clojure script into a (run) function: (defn run [] (let [ifs (FileInputStream. /dev/urandom) buf (make-array Byte/TYPE *numbytes*)] (dotimes [_ 10] (let [sz (.read ifs buf)] (println Wanted *numbytes* got sz bytes) (let [count (time (countnl buf))] (println Got count nls)) and ran (time (run)) at the repl: (time (run)) Wanted 16777216 got 16777216 bytes Elapsed time: 183.081975 msecs Got 65894 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.001814 msecs Got 65949 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.061934 msecs Got 65603 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.031131 msecs Got 65563 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.122567 msecs Got 65696 nls Wanted 16777216 got 16777216 bytes Elapsed time: 182.968066 msecs Got 65546 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.058508 msecs Got 65468 nls Wanted 16777216 got 16777216 bytes Elapsed time: 182.932395 msecs Got 65872 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.074646 msecs Got 65498 nls Wanted 16777216 got 16777216 bytes Elapsed time: 187.733636 msecs Got 65434 nls Elapsed time: 28510.331507 msecs nil Total running time for both programs is around 28 seconds. The java program seems to be incorrectly reporting it's time. --Robert McIntyre On Mon, Aug 30, 2010 at 4:03 PM, tsuraan tsur...@gmail.com wrote: Just to try to see if clojure is a practical language for doing byte-level work (parsing files, network streams, etc), I wrote a trivial function to iterate through a buffer of bytes and count all the newlines that it sees. For my testing, I've written a C version, a Java version, and a Clojure version. I'm running each routine 10 times over a 16MB buffer read from /dev/urandom (the buffer is refreshed between each call to the newline counting function). With gcc -O0, I get about 80ms per 16MB buffer. With gcc -O3, I get ~14ms per buffer. With javac (and java -server) I get 20ms per 16MB buffer. With clojure, I get 105ms per buffer (after the jvm warms up). I'm guessing that the huge boost that java and gcc -O3 get is from
Re: Problem reloading source file with imports
Thanks Robert. That makes a lot of sense and I was able to follow your
advice last night and get my source file to reload successfully by adding
:only [indexed] to my :use clause (because indexed was the only function
that I was using in this case).
The thing that still confuses me is that I can successfully load a source
file that imports the whole of clojure.contrib.seq once (with warnings) but
an attempt to reload that source file then fails - even if I edit the source
file to remove the whole :use clause before reloading. That's weird but I'm
working again and that's the important thing - thanks.
On 30 August 2010 21:05, Robert McIntyre r...@mit.edu wrote:
Sorry, I was tired and didn't explain very well.
Right now you have a naked
(:use clojure.contrib.seq-utils)
somewhere.
You want to use partition-by, but that's already in core, so you might
just get rid of the :use altogether.
But maybe there are some other functions in seq-utils that you do want
to use --- in that case, do
(:use [clojure.contrib [seq-utils :only [functions you want]]])
or
(:use [clojure.contrib [seq-utils :only []]])
to avoid stepping on core and also to document what you actually use.
If you really want the seq-utils version of partition-by, then you can do:
(:use [clojure.contrib [seq-utils :as whatever]])
whatever/partition-by
And if you really want to replace the core version with the seq
version without any namespacing, do
(:refer-clojure :exclude [partition-by])
(:use [clojure.contrib [seq-utils :only [partition-by]]])
does that help?
--Robert McIntyre
On Mon, Aug 30, 2010 at 2:43 PM, Chris Jenkins cdpjenk...@gmail.com
wrote:
How would using the :only keyword help here? Just to be clear, the
problem
here is that attempting to load my source file the second time fails
(loading the first time having succeeded, albeit with a few warnings
about
replacing symbols from clojure.core), which makes it very difficult for
me
to use swank-clojure, for example, because I can't hit C-c C-k twice on
the
same file.
Here is the failure when I try to load the file for the second time:
java.lang.IllegalStateException: partition-by already refers to:
#'clojure.contrib.seq-utils/partition-by in namespace: test.core
(core.clj:1)
So here's my main question: If I'm working in the REPL and I edit a file
that I've preu'vviously loaded, how can I cause the file to be reloaded
without
hitting that error? If my .clj file doesn't :use any other clojure
modules
then reloading works fine but, if it imports anything, then the second
(load-file...) fails.
On 30 August 2010 11:05, Robert McIntyre r...@mit.edu wrote:
Yeah, they changed that from clojure 1.1 and it's really annoying ---
as far as I know, your only options right now are to either select
exactly which functions
from seq-utils you want using the :only keyword, or if you really want
to use the seq-utils version
you can use refer-clojure and the :exclude keyword. Or, you can use
the :as keyword in the :use form
to qualify the import so that you don't actually replace anything.
If you accidently get this warning and don't want to restart the repl
you can do
(ns-unmap 'your-namespace 'offending-function), fix the naked import,
and reload.
--Robert McIntyre
On Mon, Aug 30, 2010 at 5:54 AM, Chris Jenkins cdpjenk...@gmail.com
wrote:
Since I switched to Clojure 1.2, I see an error message whenever I try
to
reload a source file that imports anything. The error message is of
the
form
already refers to xxx, as though it is complaining that it
can't
import the same thing twice.
For example, I have a minimal source file that looks like this:
(ns test.core
(:use clojure.contrib.seq-utils))
I can load it (once!) into the Clojure REPL successfully:
$ java -cp lib/clojure-contrib-1.2.0.jar:lib/clojure-1.2.0.jar
clojure.main
Clojure 1.2.0
user= (load-file src/test/core.clj)
WARNING: partition-by already refers to: #'clojure.core/partition-by
in
namespace: test.core, being replaced by:
#'clojure.contrib.seq-utils/partition-by
WARNING: frequencies already refers to: #'clojure.core/frequencies in
namespace: test.core, being replaced by:
#'clojure.contrib.seq-utils/frequencies
WARNING: shuffle already refers to: #'clojure.core/shuffle in
namespace:
test.core, being replaced by: #'clojure.contrib.seq-utils/shuffle
WARNING: reductions already refers to: #'clojure.core/reductions in
namespace: test.core, being replaced by:
#'clojure.contrib.seq-utils/reductions
WARNING: partition-all already refers to: #'clojure.core/partition-all
in
namespace: test.core, being replaced by:
#'clojure.contrib.seq-utils/partition-all
WARNING: group-by already refers to: #'clojure.core/group-by in
namespace:
test.core, being replaced by: #'clojure.contrib.seq-utils/group-by
WARNING: flatten already refers to:
Re: Problem reloading source file with imports
Hi, On 31 Aug., 12:00, Chris Jenkins cdpjenk...@gmail.com wrote: The thing that still confuses me is that I can successfully load a source file that imports the whole of clojure.contrib.seq once (with warnings) but an attempt to reload that source file then fails - even if I edit the source file to remove the whole :use clause before reloading. That's weird but I'm working again and that's the important thing - thanks. What happens is the following: 1. partition-by from core is created in the namespace. 2. partition-by is overwritten by the seq-utils version = warning - now the reload happens. reload does not nuke the old version of the namespace. so the old bindings are still in effect. - 3. partition-by is supposed to be overwritten by the core version. = error I think this is some special treatment for core. But I don't clearly remember. You can consult the archives of the group. There was some discussion on this topic. 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: defrecord issue in unit tests
--Doh! Thanks, David, that worked On Aug 30, 8:29 am, David Nolen dnolen.li...@gmail.com wrote: On Mon, Aug 30, 2010 at 6:37 AM, garf gary.overg...@gmail.com wrote: I am getting the following error when I switched from defstruct to defrecord **Unable to resolve classname: Rule-record (RecordInitTest.clj:8)** I only have this problem when definition usage is split between two files, i.e. defrecord creates a Java class, you need to import it. 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: Help speed up an inner loop?
Consider trying to use == in place of where you have =, which can be faster when comparing numbers for equality. Source for this and a few other performance tips: http://gnuvince.wordpress.com/2009/05/11/clojure-performance-tips/ Andy On Mon, Aug 30, 2010 at 11:46 PM, Robert McIntyre r...@mit.edu wrote: Ah, I see that I was mistaken about the timing. Sorry about that. After a lot of fiddling around, I cam up with this faster form: (defn countnl-lite [#^bytes buf] (areduce buf idx count (int 0) (if (= (clojure.lang.RT/aget buf idx) 10) (unchecked-add count 1) count))) Key points are initializing count to a primitive integer and directly calling clojure's aget to avoid an unnecessary integer cast. On my system: The unmodified countnl function takes ~ 180 msecs Without AOT compilation countnl-lite takes around 66 msecs With AOT compilation countnl-lite takes ~46 msecs The java method takes ~19 msecs. I've lost a factor of 2.25 somewhere and it makes me sad that I can't find it. I would be very interested if anyone could improve countnl-lite. --Robert McIntyre On Mon, Aug 30, 2010 at 8:41 PM, Alan a...@malloys.org wrote: I think this misses the point. Of course java, c, and clojure will all have roughly the same wall-clock time for this program, since it is dominated by the I/O. You can even see that in the output from $ time java Iterate: less than 0.5s was spent in user space, the rest was spent in system code - that is, mostly doing I/O. The java version is a second faster as counted by the wall clock, and this is unlikely to be a coincidence: tsuraan's timing data suggests that the clojure program takes 80ms longer in each loop, and loops 10 times. That comes out to 0.8 seconds, which is quite close to the differential you observed when timing from the command line. On Aug 30, 1:38 pm, Robert McIntyre r...@mit.edu wrote: I don't know what the heck is going here, but ignore the time the program is reporting and just pay attention to how long it actually takes wall-clock style and you'll see that your clojure and java programs already take the same time. Here are my findings: I saved Iterate.java into my rlm package and ran: time java -server rlm.Iterate results: time java -server rlm.Iterate Wanted 16777216 got 16777216 bytes counted 65341 nls in 27 msec Wanted 16777216 got 16777216 bytes counted 65310 nls in 27 msec Wanted 16777216 got 16777216 bytes counted 66026 nls in 21 msec Wanted 16777216 got 16777216 bytes counted 65473 nls in 19 msec Wanted 16777216 got 16777216 bytes counted 65679 nls in 19 msec Wanted 16777216 got 16777216 bytes counted 65739 nls in 19 msec Wanted 16777216 got 16777216 bytes counted 65310 nls in 21 msec Wanted 16777216 got 16777216 bytes counted 65810 nls in 18 msec Wanted 16777216 got 16777216 bytes counted 65531 nls in 21 msec Wanted 16777216 got 16777216 bytes counted 65418 nls in 21 msec real0m27.469s user0m0.472s sys 0m26.638s I wrapped the last bunch of commands in your clojure script into a (run) function: (defn run [] (let [ifs (FileInputStream. /dev/urandom) buf (make-array Byte/TYPE *numbytes*)] (dotimes [_ 10] (let [sz (.read ifs buf)] (println Wanted *numbytes* got sz bytes) (let [count (time (countnl buf))] (println Got count nls)) and ran (time (run)) at the repl: (time (run)) Wanted 16777216 got 16777216 bytes Elapsed time: 183.081975 msecs Got 65894 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.001814 msecs Got 65949 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.061934 msecs Got 65603 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.031131 msecs Got 65563 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.122567 msecs Got 65696 nls Wanted 16777216 got 16777216 bytes Elapsed time: 182.968066 msecs Got 65546 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.058508 msecs Got 65468 nls Wanted 16777216 got 16777216 bytes Elapsed time: 182.932395 msecs Got 65872 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.074646 msecs Got 65498 nls Wanted 16777216 got 16777216 bytes Elapsed time: 187.733636 msecs Got 65434 nls Elapsed time: 28510.331507 msecs nil Total running time for both programs is around 28 seconds. The java program seems to be incorrectly reporting it's time. --Robert McIntyre On Mon, Aug 30, 2010 at 4:03 PM, tsuraan tsur...@gmail.com wrote: Just to try to see if clojure is a practical language for doing byte-level work (parsing files, network streams, etc), I wrote a trivial function to iterate through a buffer of bytes and count all the newlines that it sees. For my testing, I've written a C version, a Java version, and a Clojure version. I'm running
Re: Help speed up an inner loop?
Hi, On 31 Aug., 08:46, Robert McIntyre r...@mit.edu wrote: Without AOT compilation countnl-lite takes around 66 msecs With AOT compilation countnl-lite takes ~46 msecs Did you measure start-up time in your runs? AOT compilation should have no impact on the runtime speed. 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: Help speed up an inner loop?
I am not convince that (make-array Byte/TYPE *numbytes*) creates an array of primitives. And I think byte [] is an array of primitives. That would make a difference. I don't know if clojure has a byte-array. It seems that there is no byte-array as there is int-array. Could you try your code with int-array, or could you just write two static methods in a Java class to read and write an int from a byte array? Best, Nicolas. -- 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: Help speed up an inner loop?
On Tue, Aug 31, 2010 at 1:53 PM, Nicolas Oury nicolas.o...@gmail.com wrote: I am not convince that (make-array Byte/TYPE *numbytes*) creates an array of primitives. Actually it does, sorry for the noise. Should check before sending emails. Best, Nicolas. -- 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
Question re Mikael Sundberg's Getting started with compojure
Hi, I've been reading Mikael Sundberg's Getting started with compojure [1] and been wondering how to reload a function display (without Emacs and swank) so I don't have to restart repl. I'd love to update the function while running lein repl. Is it possible?* How? [1] http://cleancode.se/2010/08/30/getting-started-with-compojure.html * I know it's possible, but dunno how and therefore the question :) Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://jaceklaskowski.pl -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Why do is used in this function?
Hey, Having this function: (defn printall [s] (if (not (empty? s)) (do (println (str Item: (first s))) (recur (rest s) Why do is used here? what happens if I drop it? Thanks for help and time. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why do is used in this function?
Hey, Having this function: (defn printall [s] (if (not (empty? s)) (do (println (str Item: (first s))) (recur (rest s) Why do is used here? what happens if I drop it? Thanks for help and time. In Clojure and most other Lisps, `if' has the following structure - (if test then else) If you want to have multiple forms in the `then' or `else' clause, you have to group them together, else it will become a part of the `then' clause (or will throw an error since if can take only three args). This also tells you that you are performing a side-effect since (do foo bar) will return the return value of bar and that of foo will be completely discarded. Coming back to your example, if you drop the do, then only the println part will be the `then' clause and the recur part will become the 'else' clause and will get executed only when the test is false. This will make the function print the first item and exit. I hope that was clear enough. 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: Question re Mikael Sundberg's Getting started with compojure
I'm not sure if this is the question you are asking, but to reload a namespace in a repl, depending on whether you are use-ing the ns or require-ing it, there are :reload and :reload-all keyword arguments accepted: (require '[foo.something :as something] :reload) (require '[foo.something :as something] :reload-all) ... On Tue, Aug 31, 2010 at 10:24 AM, Jacek Laskowski ja...@laskowski.net.plwrote: Hi, I've been reading Mikael Sundberg's Getting started with compojure [1] and been wondering how to reload a function display (without Emacs and swank) so I don't have to restart repl. I'd love to update the function while running lein repl. Is it possible?* How? [1] http://cleancode.se/2010/08/30/getting-started-with-compojure.html * I know it's possible, but dunno how and therefore the question :) Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://jaceklaskowski.pl -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@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: Question re Mikael Sundberg's Getting started with compojure
On Tue, Aug 31, 2010 at 4:44 PM, Mark Rathwell mark.rathw...@gmail.com wrote: I'm not sure if this is the question you are asking, but to reload a namespace in a repl, depending on whether you are use-ing the ns or require-ing it, there are :reload and :reload-all keyword arguments accepted: (require '[foo.something :as something] :reload) (require '[foo.something :as something] :reload-all) Thanks! That was it. As we're at it, how does people reload functions while connected to a remote Clojure app from within Emacs? Do they also (require...:reload)? Is there a tutorial/article about it? Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://jaceklaskowski.pl -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why do is used in this function?
One solution to remove it is to use when. (when (not (empty? s) (println (str Item: (first s))) (recur (rest s As there is only one case for a when, you can give multiple instructions for this case without grouping them Even better: (when-not (empty? s) (println (str Item: (first s))) (recur (rest s -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why do is used in this function?
Another tip: per the doc for 'empty?', (seq s) is preferred over (not (empty? s)). Oh, and 'str' isn't necessary since 'println' adds spaces between arguments: (defn printall [s] (when (seq s) (println Item: (first s)) (recur (rest s Justin On Aug 31, 10:57 am, Nicolas Oury nicolas.o...@gmail.com wrote: One solution to remove it is to use when. (when (not (empty? s) (println (str Item: (first s))) (recur (rest s As there is only one case for a when, you can give multiple instructions for this case without grouping them Even better: (when-not (empty? s) (println (str Item: (first s))) (recur (rest s -- 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: Extending Clojure's STM with external transactions
I'd like to see a day when programmers need to worry about persistence about as much as they worry about garbage collection now. Me too, but of course beware of leaky abstractions. -- 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: Question re Mikael Sundberg's Getting started with compojure
On 31 August 2010 16:52, Jacek Laskowski ja...@laskowski.net.pl wrote: As we're at it, how does people reload functions while connected to a remote Clojure app from within Emacs? Do they also (require...:reload)? Is there a tutorial/article about it? One possibility is to open the remote file wherein the function in question is defined, modify it as appropriate, then either enter (require :reload ...) at the REPL or press C-c C-k (a SLIME / Swank binding) in the buffer with the modified code. (Or press C-c C-c with point inside the top-level form in question.) Another possibility -- which is open even if the app has been packaged as a .jar / .war file -- is to switch to the appropriate namespace at the REPL and evaluate the appropriate defn; or maybe stay in the user namespace and use clojure.core/intern / alter-var-root / .bindRoot to replace the root binding of the Var holding the function. Sincerely, Michał -- 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: Help speed up an inner loop?
(defn countnl-lite [#^bytes buf] (areduce buf idx count (int 0) (if (= (clojure.lang.RT/aget buf idx) 10) (unchecked-add count 1) count))) Key points are initializing count to a primitive integer and directly calling clojure's aget to avoid an unnecessary integer cast. Are you using clojure 1.2? If I try to set count to be (int 0) rather than 0, I get this error: Exception in thread main java.lang.RuntimeException: java.lang.IllegalArgumentException: recur arg for primitive local: count must be matching primitive Even if I replace inc with the unchecked-add, or cast the result of the inc to be int (replace (inc count) with (int (inc count)) ) it gives me that error. Sort of strange... -- 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: Help speed up an inner loop?
Replace also (unchecked-add count 1) with (unchecked-add count (int 1)) (this should get easier in 1.3) On Tue, Aug 31, 2010 at 4:20 PM, tsuraan tsur...@gmail.com wrote: (defn countnl-lite [#^bytes buf] (areduce buf idx count (int 0) (if (= (clojure.lang.RT/aget buf idx) 10) (unchecked-add count 1) count))) Key points are initializing count to a primitive integer and directly calling clojure's aget to avoid an unnecessary integer cast. Are you using clojure 1.2? If I try to set count to be (int 0) rather than 0, I get this error: Exception in thread main java.lang.RuntimeException: java.lang.IllegalArgumentException: recur arg for primitive local: count must be matching primitive Even if I replace inc with the unchecked-add, or cast the result of the inc to be int (replace (inc count) with (int (inc count)) ) it gives me that error. Sort of strange... -- 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: Help speed up an inner loop?
Replace also (unchecked-add count 1) with (unchecked-add count (int 1)) (this should get easier in 1.3) That didn't change anything for my tests, but this code: (defn countnl [#^bytes buf] (areduce buf idx count (int 0) (if (= (aget buf idx) 10) (unchecked-add count 1) count))) does 34ms runs (the .java code does 20ms runs on the same machine). The biggest things that make a difference are replacing (inc count) with (unchecked-add count 1), initializing count to (int 0) rather than 0, and getting rid of the (let [nl (byte 0)]...). I was a bit disappointed that the let statement was so expensive, since I really prefer seeing a variable to a magic number. Has somebody written a macro that can be used to rewrite code replacing variable references with their constant values? It would be of limited use (constants only), but it would make the code prettier :) For posterity, here are some variations on countnl and their timings on my machine: all runs are invoked with this command: java -server -cp clojure.jar clojure.main iterate.clj; clojure.jar is from the clojure-1.2.zip distribution (defn countnl [#^bytes buf] (let [nl (byte 10)] (areduce buf idx count 0 (if (= (aget buf idx) nl) (inc count) count Wanted 16777216 got 16777216 bytes Elapsed time: 184.172834 msecs Got 65875 nls Wanted 16777216 got 16777216 bytes Elapsed time: 193.546018 msecs Got 64995 nls Wanted 16777216 got 16777216 bytes Elapsed time: 142.546453 msecs Got 65677 nls Wanted 16777216 got 16777216 bytes Elapsed time: 135.843933 msecs Got 66117 nls Wanted 16777216 got 16777216 bytes Elapsed time: 134.882156 msecs Got 65449 nls Wanted 16777216 got 16777216 bytes Elapsed time: 134.864881 msecs Got 65393 nls Wanted 16777216 got 16777216 bytes Elapsed time: 134.854118 msecs Got 65065 nls Wanted 16777216 got 16777216 bytes Elapsed time: 134.82848 msecs Got 65346 nls Wanted 16777216 got 16777216 bytes Elapsed time: 134.803702 msecs Got 65783 nls Wanted 16777216 got 16777216 bytes Elapsed time: 134.832489 msecs Got 65566 nls (defn countnl [#^bytes buf] (let [nl (byte 10)] (areduce buf idx count (int 0) (if (= (aget buf idx) nl) (inc count) count Wanted 16777216 got 16777216 bytes Elapsed time: 238.409697 msecs Got 65698 nls Wanted 16777216 got 16777216 bytes Elapsed time: 208.872818 msecs Got 65381 nls Wanted 16777216 got 16777216 bytes Elapsed time: 88.786986 msecs Got 65358 nls Wanted 16777216 got 16777216 bytes Elapsed time: 88.76816 msecs Got 65686 nls Wanted 16777216 got 16777216 bytes Elapsed time: 88.899431 msecs Got 65683 nls Wanted 16777216 got 16777216 bytes Elapsed time: 88.783275 msecs Got 65491 nls Wanted 16777216 got 16777216 bytes Elapsed time: 88.735416 msecs Got 65749 nls Wanted 16777216 got 16777216 bytes Elapsed time: 88.762987 msecs Got 65837 nls Wanted 16777216 got 16777216 bytes Elapsed time: 88.749591 msecs Got 65759 nls Wanted 16777216 got 16777216 bytes Elapsed time: 88.72971 msecs Got 65366 nls (defn countnl [#^bytes buf] (areduce buf idx count (int 0) (if (= (aget buf idx) 10) (inc count) count))) Wanted 16777216 got 16777216 bytes Elapsed time: 185.465613 msecs Got 65344 nls Wanted 16777216 got 16777216 bytes Elapsed time: 186.856418 msecs Got 65529 nls Wanted 16777216 got 16777216 bytes Elapsed time: 73.778183 msecs Got 65662 nls Wanted 16777216 got 16777216 bytes Elapsed time: 73.675509 msecs Got 65034 nls Wanted 16777216 got 16777216 bytes Elapsed time: 73.674777 msecs Got 65459 nls Wanted 16777216 got 16777216 bytes Elapsed time: 73.630553 msecs Got 65172 nls Wanted 16777216 got 16777216 bytes Elapsed time: 73.668685 msecs Got 64939 nls Wanted 16777216 got 16777216 bytes Elapsed time: 73.74801 msecs Got 65462 nls Wanted 16777216 got 16777216 bytes Elapsed time: 73.699187 msecs Got 65602 nls Wanted 16777216 got 16777216 bytes Elapsed time: 73.611555 msecs Got 64937 nls (defn countnl [#^bytes buf] (areduce buf idx count (int 0) (if (= (aget buf idx) 10) (unchecked-add count 1) count))) Wanted 16777216 got 16777216 bytes Elapsed time: 82.865761 msecs Got 65266 nls Wanted 16777216 got 16777216 bytes Elapsed time: 34.228646 msecs Got 65522 nls Wanted 16777216 got 16777216 bytes Elapsed time: 33.989741 msecs Got 65537 nls Wanted 16777216 got 16777216 bytes Elapsed time: 33.947045 msecs Got 65688 nls Wanted 16777216 got 16777216 bytes Elapsed time: 33.941481 msecs Got 65395 nls Wanted 16777216 got 16777216 bytes Elapsed time: 33.952149 msecs Got 65822 nls Wanted 16777216 got 16777216 bytes Elapsed time: 33.972258 msecs Got 65495 nls Wanted 16777216 got 16777216 bytes Elapsed time: 33.903989 msecs Got 65244 nls Wanted 16777216 got 16777216 bytes Elapsed time: 33.927276 msecs Got 65331 nls Wanted 16777216 got 16777216 bytes Elapsed time: 33.917789 msecs Got 65470 nls (defn
Re: Why do is used in this function?
On Tue, Aug 31, 2010 at 11:08 AM, Justin Kramer jkkra...@gmail.com wrote: Another tip: per the doc for 'empty?', (seq s) is preferred over (not (empty? s)). Oh, and 'str' isn't necessary since 'println' adds spaces between arguments: (defn printall [s] (when (seq s) (println Item: (first s)) (recur (rest s Good tips! Another option: (defn printall [s] (doseq [i s] (println Item: i))) --Chouser http://joyofclojure.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: ANN: SQLRat - A Clojure 1.2 library to access Relational Databases using DataTypes
SQLRat 0.1 GA is pushed to Clojars. Maven/Lein details here: http://clojars.org/org.bituf/sqlrat The same is also reflected here: http://code.google.com/p/bitumenframework/ # Changes and TODO ## 0.2 / planned - [TODO] Support large sized query result-sets (by adding lazy loading option) - [TODO] Optimistic locks using time stamps - [TODO] DSL for the WHERE clause - [] Add :groupby and :orderby arguments to find-xxx functions ## 0.1 / 2010-Aug-31 (GMT + 5:30) - Entity definitions, meta data, relations - CRUD (Create, Retrieve, Update, Delete) functions for entities - Small-to-medium sized query result-sets (eager-fetching is the only option) - Query by COUNT(*) function - User can specify columns, WHERE clause in retrieve functions - CRUD (Create, Retrieve, Update, Delete) functions for entity- relations - Avoid N+1 Select Feel free to kick the tires and do share your experience/impression. Regards, Shantanu On Aug 18, 11:38 pm, Shantanu Kumar kumar.shant...@gmail.com wrote: Hi, I have uploaded source code (Apache 2 license) forSQLRat- a library for Clojure 1.2 to access relational databases using DataTypes (entities). It also lets you define relations between entities and navigate them. While this is a part of what typically Object- Relational Mapping (ORM) frameworks do, it is not an ORM framework per se -- it does not implement State managent, Identity management, Lazy loading, Eager fetching etc. The code is quite rough around the edges right now and beta-quality at best (at 0.1-SNAPSHOT), but it works nevertheless. I intend to release it as GA soon after Clojure 1.2 goes GA too. The source code is here:http://bitbucket.org/kumarshantanu/sqlrat/ Discussions can be posted here:http://groups.google.com/group/bitumenframework You may also like to keep a tab at this:http://code.google.com/p/bitumenframework/ The intent of this announcement is to gather feedback, so that I can fix as many warts as I can before doing a 0.1 GA release. It is not on Clojars yet, but the GA will eventually be there. The most important parts to review would be the API it exposes, followed by the implementation details. So, I would request you to give the library a try, ask questions (I would be happy to answer), give feedback, make suggestions and if you can, fork and contribute as well. The usage can be found in the dbblog.clj file, which contains the unit tests and describes how the library can be used. 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
Lisp/Scheme Style Guide
This is the best I've seen so I thought I'd share (pulled from a post on the guile mailing list) http://mumble.net/~campbell/scheme/style.txt (note: the attached copy opens in Org-mode in Emacs for easier reading) -- 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=enRiastradh's Lisp Style Rules-*- org -*- Copyright (C) 2007 Taylor R. Campbell All rights reserved. Copies and quotations of this document are freely permitted, provided that this copyright notice is preserved in copies and that the author is cited in quotations. This is a guide to Lisp style, written by Taylor R. Campbell, to describe the standard rules of Lisp style as well as a set of more stringent rules for his own style. This guide should be useful for Lisp in general, but there are [or will be in the final draft] parts that are focussed on or specific to Scheme or Common Lisp. This guide is written primarily as a collection of rules, with rationale for each rule. (If a rule is missing rationale, please inform the author!) Although a casual reader might go through and read the rules without the rationale, perhaps reasoning that reading of the rationale would require more time than is available, such a reader would derive little value from this guide. In order to apply the rules meaningfully, their spirit must be understood; the letter of the rules serves only to hint at the spirit. The rationale is just as important as the rules. There are many references in this document to `Emacs', `GNU Emacs', `Edwin', and so on. In this document, `Emacs' means any of a class of editors related in design to a common ancestor, the EMACS editor macros written for TECO on ITS on the PDP-10 in the middle of the nineteen seventies. All such editors -- or `all Emacsen', since `Emacsen' is the plural of `Emacs' -- have many traits in common, such as a very consistent set of key bindings, extensibility in Lisp, and so on. `GNU Emacs' means the member of the class of editors collectively known as Emacsen that was written for the GNU Project in the middle of the nineteen eighties, and which is today probably the most popular Emacs. `Edwin' is MIT Scheme's Emacs, which is bundled as part of MIT Scheme, and not available separately. There are other Emacsen as well, such as Hemlock and Climacs, but as the author of this document has little experience with Emacsen other than GNU Emacs and Edwin, there is little mention of other Emacsen. This guide is a work in progress. To be written: - Indentation rules for various special operators. - Philosophical rambling concerning naming. - Rules for breaking lines. - Many more examples. - A more cohesive explanation of the author's principles for composing programs, and their implications. - Rules for writing portable code. - Some thoughts concerning extensions to the lexical syntax. - Rules for writing or avoiding macros. - Some unfinished rationale. - More on documentation. - The `Dependencies' subsection of the `General Layout' section should be put in a different section, the rest of which has yet to be written, on organization of programs, module systems, and portable code. Feedback is welcome; address any feedback by email to the host mumble.net's user `campbell', or by IRC to Riastradh in the #scheme channel on Freenode (irc.freenode.net). Feedback includes reports of typos, questions, requests for clarification, and responses to the rationale, except in the case of round brackets versus square brackets, the argument surrounding which is supremely uninteresting and now not merely a dead horse but a rotting carcass buzzing with flies and being picked apart by vultures. As this document has grown, the line between standard Lisp rules and the author's own style has been blurred. The author is considering merging of the partition, but has not yet decided on this with certainty. Opinions on the subject are welcome -- is the partition still useful to keep the author's biases and idiosyncrasies out of the standard rules, or has the partition with its arbitrary nature only caused disorganization of the whole document? Unfortunately, this document is entirely unscientific. It is at best a superstition or philosophy, but one that the author of this document has found to have improved his programs. Furthermore, the author is somewhat skeptical of claims of scientific analyses of these matters: analyzing human behaviour, especially confined to the set of excellent programmers who often have strong opinions about their methods for building programs, is a very tricky task. * Standard Rules These are the standard rules
Re: Help speed up an inner loop?
This one is quite good for me. (defn countnl [#^bytes buf] (let [nl (int 10)] (areduce buf idx count (int 0) (if (== (int (aget buf idx)) nl) (unchecked-inc count) count It appears that == is not resolved for bytes. So converting to int works fine. In this situation, inlining (int 10) does not buy much. This one, though, is even faster and should be not far from the java one, if you want to try it. (defn countnl [#^bytes buf] (let [nl (int 10) n (int (alength buf))] (loop [idx (int n) count (int 0)] (if (zero? idx) count (let [idx (unchecked-dec idx)] (if (== (int (aget buf idx)) nl) (recur idx (unchecked-inc count)) (recur idx count))) It would be interesting to know why it is nearly twice as fast as the areduce version on my computer. Best, Nicolas. -- 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: Help speed up an inner loop?
This one is quite good for me. (defn countnl [#^bytes buf] (let [nl (int 10)] (areduce buf idx count (int 0) (if (== (int (aget buf idx)) nl) (unchecked-inc count) count It appears that == is not resolved for bytes. So converting to int works fine. aha, converting to int works for me as well. With bytes it triggers the reflection warning and takes minutes to run. with the int conversion, it runs in an average of 28ms (just a little over java). Here's something really strange: I de-inlined the newline int, so my function looks like this: (defn countnl [#^bytes buf] (let [nl (int 10)] (areduce buf idx count (int 0) (if (== (int (aget buf idx)) nl) (unchecked-add count (int 1)) count On my machine, this is running in 19.6ms (after the warmup it's really constant). That's the exact speed as the java code, which is really cool. it actually works the same way if you just replace the inlined 10 with (int 10), and it makes it just as fast as the explicit looping code below. Somehow on my earlier tests the let binding was really slowing things down, but in this latest function it seems to have no effect. weird... In this situation, inlining (int 10) does not buy much. interesting; for me replacing the 10 with (int 10) brings my times from 28.7ms to 19.6ms. This one, though, is even faster and should be not far from the java one, if you want to try it. (defn countnl [#^bytes buf] (let [nl (int 10) n (int (alength buf))] (loop [idx (int n) count (int 0)] (if (zero? idx) count (let [idx (unchecked-dec idx)] (if (== (int (aget buf idx)) nl) (recur idx (unchecked-inc count)) (recur idx count))) It would be interesting to know why it is nearly twice as fast as the areduce version on my computer. That runs in 21.3ms for me, which actually makes it a tiny bit slower than the code above (and slightly slower than the java code). -- 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: Help speed up an inner loop?
On Tue, Aug 31, 2010 at 8:43 PM, tsuraan tsur...@gmail.com wrote: In this situation, inlining (int 10) does not buy much. interesting; for me replacing the 10 with (int 10) brings my times from 28.7ms to 19.6ms. I meant putting (int 10) instead of nl and a let. Anyway, it seems that we can get to java speed, but with some hard work. I have read somewhere than 1.3 will help a lot to achieve this performance with less work. -- 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: Lisp/Scheme Style Guide
Can we please drop this? This is going to go nowhere fast, like other thread on closing parens on new lines. Whoever wrote this did a terrible job, at least WRT that topic. Not only did he misrepresent the trailing parenthesis style (not all parenthesis must be trailed), but the so-called rationale given for choosing stacked parens over trailed parens is laughably devoid of any rational thought: Rationale: The parentheses grow lonely if their closing brackets are all kept separated and segregated. - Greg On Aug 31, 2010, at 9:47 AM, Eric Schulte wrote: This is the best I've seen so I thought I'd share (pulled from a post on the guile mailing list) http://mumble.net/~campbell/scheme/style.txt (note: the attached copy opens in Org-mode in Emacs for easier reading) -- 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=enstyle.txt -- 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: Lisp/Scheme Style Guide
The concept of the One-Style-To-Rule-Them-All is just childish. It is akin to the enforcement of school uniforms, and in many ways perhaps worse. The imposition of aesthetic preferences upon others is likely to result in the following: - A counter-reaction, such as argument, insults, flame wars - Animosity amongst members of the group - Noise on the channel - The fostering of a militant, prickly community (i.e. the one that LISP is famous for) Clojure is an opportunity to depart from all of that. - Greg On Aug 31, 2010, at 1:52 PM, Greg wrote: Can we please drop this? This is going to go nowhere fast, like other thread on closing parens on new lines. Whoever wrote this did a terrible job, at least WRT that topic. Not only did he misrepresent the trailing parenthesis style (not all parenthesis must be trailed), but the so-called rationale given for choosing stacked parens over trailed parens is laughably devoid of any rational thought: Rationale: The parentheses grow lonely if their closing brackets are all kept separated and segregated. - Greg On Aug 31, 2010, at 9:47 AM, Eric Schulte wrote: This is the best I've seen so I thought I'd share (pulled from a post on the guile mailing list) http://mumble.net/~campbell/scheme/style.txt (note: the attached copy opens in Org-mode in Emacs for easier reading) -- 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=enstyle.txt -- 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
reflection warnings with defprotocol/deftype with type hints
Hi all, I am puzzled by the type hint support in deftype. I can add type hints to defprotocol: user= (defprotocol PTest (test-it ^boolean [this ^String msg])) PTest … but adding them to deftype fails: user= (deftype Test [^String name] PTest (test-it [this msg] (str test name : msg \space (.length msg java.lang.IllegalArgumentException: Can't find matching method: test_it, leave off hints for auto match. (NO_SOURCE_FILE:1) So I write the deftype without type hints: user= (deftype Test [^String name] PTest (test-it [this msg] (str test name : msg \space (.length msg user.Test But then, I get reflection warnings: user= (set! *warn-on-reflection* true) true user= (test-it (Test. one) two) test one: two 3 8/31/10 11:11:49 PM [0x0-0x29029].org.fiji[382] Reflection warning, NO_SOURCE_PATH:3 - reference to field length can't be resolved. In any case length is a method, not a field, in String. The above is just a minimal example. I am experiencing this issue in just about all deftype that I need to type-hint. The error when type-hinting suggests that the latter is unnecessary, that it could be deduced from the hints in the protocol definition--but that is not the case. What am I missing? Thanks for any help. Albert -- http://albert.rierol.net -- 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: reflection warnings with defprotocol/deftype with type hints
I haven't quite figured out type hinting either, but here's one thing I realized I was doing wrong that you might want to try. (.length msg) is a reader macro that expands to (. msg length). The docs for the . special form state that if no arguments are provided for an instance member, it is assumed to be a field. You can specify that it is a no-argument method by instead writing (. msg (length)). Whether that will fix the issue you're having I don't know, but it should be a step in the right direction. On Aug 31, 2:20 pm, Albert Cardona sapri...@gmail.com wrote: Hi all, I am puzzled by the type hint support in deftype. I can add type hints to defprotocol: user= (defprotocol PTest (test-it ^boolean [this ^String msg])) PTest … but adding them to deftype fails: user= (deftype Test [^String name] PTest (test-it [this msg] (str test name : msg \space (.length msg java.lang.IllegalArgumentException: Can't find matching method: test_it, leave off hints for auto match. (NO_SOURCE_FILE:1) So I write the deftype without type hints: user= (deftype Test [^String name] PTest (test-it [this msg] (str test name : msg \space (.length msg user.Test But then, I get reflection warnings: user= (set! *warn-on-reflection* true) true user= (test-it (Test. one) two) test one: two 3 8/31/10 11:11:49 PM [0x0-0x29029].org.fiji[382] Reflection warning, NO_SOURCE_PATH:3 - reference to field length can't be resolved. In any case length is a method, not a field, in String. The above is just a minimal example. I am experiencing this issue in just about all deftype that I need to type-hint. The error when type-hinting suggests that the latter is unnecessary, that it could be deduced from the hints in the protocol definition--but that is not the case. What am I missing? Thanks for any help. Albert --http://albert.rierol.net -- 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
picking out a tag from a nested struct-map and xml-seq
Hi- I'm brand new to Clojure and FP, reading a bunch and working on my first programming task (reading in values from an xml file and a text file and then creating a new text file with some lines/sections of the original text file replaced based on the content of the xml). I found some helpful info here: http://www.chrisumbel.com/article/clojure_xml_parsing_xml-seq on reading the xml file, but I'm a couple more levels deep than that article. I don't know much about Clojure yet, but I have a feeling I'm not doing it the right/idiomatic/best way. I've basically got three nested calls to doseq, and I think it is mostly due to my own unfamiliarity with Clojure and the better options I would have to do this in FP. I'm getting the ver tag in the xml then checking one of its attribs to make sure I'm pulling from the version I want, and then I get the content of the mods tag. I've tried to somewhat simplify this case so the following isn't tested after being extracted from my sandbox. TIA! (defn- dig-through-struct Hides a pair of nested doseq calls from my main function [xml-as-struct] (doseq [y (:content xml-as-struct) :when (= :type (:tag y))] (doseq [z (:content y) :when (= :mods (:tag z))] (println The content I want (:content z) (defn- get-replacement-values Pulls from xml values we want to replace/update/add [x-file] (let [xml-file (File. x-file)] (xml-seq (parse xml-file)) (for [testing-ver `(1.4 1.6)] (doseq [x (xml-seq (parse xml-file)) :when (= :ver (:tag x))] (let [iva (:inner-ver-attrib (:attrs x))] (if (= testing-ver iva) (dig-through-struct x testing-ver iva) (println Did not match the ver we want testing-ver iva))) And this is my xml: proj bunch of attribs ... ver inner-ver-attrib=1.4 (or 1.6 etc, this is a tag I'm interested in conditionally checking) bunch of attribs ... type bunch of attribs ... mods remove entry-namefiles/entry-name entrypath_old\foo_old.c/entry entrypath_old1\foo_old.h/entry /remove add entry-namefiles/entry-name entrypath\foo.c/entry entrypath1\foo.h/entry /add change entry-nameopts/entry-name from-bar=1/from to-bar=2/to /change /mods /type/version/project -- 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
Problem with installing and running labrepl in Eclipse
Hi everyone, I'm a computational linguist coming from Python and want to learn Clojure. So I thought it would be a good idea to start with labrepl. I'm working on Mac OS X 10.6 (Snow Leopard) with the 32bit Cocoa version of Eclipse 3.6 (Helios). I followed the instructions on the labrepl github page (http://github.com/relevance/labrepl) and everything went just fine except for running labrepl. I right clicked on the project in the Package Explorer and started a REPL. I typed (require 'labrepl), hit Enter and then got the following error message: java.io.FileNotFoundException: Could not locate compojure/ core__init.class or compojure/core.clj on classpath: (labrepl.clj:1) After looking into the local Eclipse and labrepl directories, it seems that Compojure and Incanter have not been installed. In fact, I can only find the clojure.jar and clojure-contrib.jar that have been installed by the Counterclockwise plugin. On the labrepl website it says that up-to-date versions of Clojure, contrib, incanter, compojure and a bunch of other libraries to explore should be installed together with labrepl. But Compojure and Incanter are definitely missing on my machine. So what did I do wrong? I did not encounter an error during installation. Do I have to install Compojure manually? I greatly appreciate any advice from you. Thank you very much in advance! :-) Best regards from Germany, Peter -- 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: Lisp/Scheme Style Guide
The concept of the One-Style-To-Rule-Them-All is just childish. Have you read Style is Substance? http://www.artima.com/weblogs/viewpost.jsp?thread=74230 -- 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: Lisp/Scheme Style Guide
On Tue, Aug 31, 2010 at 4:52 PM, Greg g...@kinostudios.com wrote: Can we please drop this? This is going to go nowhere fast, like other thread on closing parens on new lines. Whoever wrote this did a terrible job, at least WRT that topic. Not only did he misrepresent the trailing parenthesis style (not all parenthesis must be trailed), but the so-called rationale given for choosing stacked parens over trailed parens is laughably devoid of any rational thought: I'd like to quickly point out, that you attempt to put an end to the discussion, and then offer opinion. That's a great way to *start* the conversation. -- 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
Keep getting this error No implementation of method: :arraySet of protocol
The full error is No implementation of method: :arraySet of protocol: #'ndarray.NDArray/ ArrayProtocol found for class: ndarray.NDArray.NDArray (NDArray.clj:0) and the code is this (ns ndarray.NDArray (:import java.lang.Object)) (def ... (reify Object)) (defprotocol ArrayProtocol (fixIndex [this where axis]) (component [this axis where]) (arraySet [this indices])) (deftype NDArray [dimensions strides strideOverwrites start data] ArrayProtocol (arraySet [this indices] SET) (fixIndex [this where axis] nil) (component [this axis where] nil)) (defn arange [ input] (let [data (apply range input)] (NDArray. [(count data)] [1] [] 0 data))) (println (arraySet (arange 20) nil)) I've been at this for a while now and while typing a small defprotocol and small defrecord into an interpreter works putting this in Eclipse gives me the error. -- 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: Lisp/Scheme Style Guide
I apologize for apparently re-opening some fresh wounds. I wasn't trying to assert that these guidelines should be universally adopted or enforced. There are a number of conventions that exist for writing lisp, and I thought that this paper was interesting because it - collects and explicitly states many of these conventions which are rarely spelled out explicitly - attempts to explain some of the conventions that can be mystifying at first - offers genuinely good readability and maintenance reasons for some of the mentioned conventions but please, don't mis-understand my intentions, I see nothing wrong with personal coding idosynchronies, I myself have been known to drop the occasional ((fn [el] (body-which-uses el)) (form-which-defines-el)) just because I've grown tired of `let'. That said even if you don't follow common conventions it can be useful to know what they are. Sorry for troll baiting, it was not my intent. -- Eric Greg g...@kinostudios.com writes: The concept of the One-Style-To-Rule-Them-All is just childish. It is akin to the enforcement of school uniforms, and in many ways perhaps worse. The imposition of aesthetic preferences upon others is likely to result in the following: - A counter-reaction, such as argument, insults, flame wars - Animosity amongst members of the group - Noise on the channel - The fostering of a militant, prickly community (i.e. the one that LISP is famous for) Clojure is an opportunity to depart from all of that. - Greg On Aug 31, 2010, at 1:52 PM, Greg wrote: Can we please drop this? This is going to go nowhere fast, like other thread on closing parens on new lines. Whoever wrote this did a terrible job, at least WRT that topic. Not only did he misrepresent the trailing parenthesis style (not all parenthesis must be trailed), but the so-called rationale given for choosing stacked parens over trailed parens is laughably devoid of any rational thought: Rationale: The parentheses grow lonely if their closing brackets are all kept separated and segregated. - Greg On Aug 31, 2010, at 9:47 AM, Eric Schulte wrote: This is the best I've seen so I thought I'd share (pulled from a post on the guile mailing list) http://mumble.net/~campbell/scheme/style.txt (note: the attached copy opens in Org-mode in Emacs for easier reading) -- 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=enstyle.txt -- 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: Minor macroexpand issue
If you were to say, (macroexpand '(foo)), it returns (foo), even if it's not defined in the context, so I'd say it's a little unexpected. More annoying is the result this has on macroexpand-all, which breaks because of this weird behaviour: (use 'clojure.walk) (walk/macroexpand-all '(let [Object (fn [])] (Object))) java.lang.RuntimeException: java.lang.Exception: Expecting var, but Object is mapped to class java.lang.Object (NO_SOURCE_FILE:0) Of course, this example is somewhat (not super-) obvious, but in more complex cases it could be fairly annoying. On Tue, 2010-08-31 at 08:14 +0200, Konrad Hinsen wrote: On 30 Aug 2010, at 23:18, Frederic Koehler wrote: I accidentally noticed this: On clojure 1.2, macroexpanding with a function name which is a class, causes this ugly error: (macroexpand '(Object)) java.lang.Exception: Expecting var, but Object is mapped to class java.lang.Object (repl-1:2) when presumably it should just give '(Object). I have no clue for any actual use cases of naming your functions after classes, but: (let [Object (fn [] 3)] (Object)) is technically valid clojure code, so macroexpand shouldn't just die... You are right that (let [Object (fn [] 3)] (Object)) is valid Clojure code, and it works as expected. However, (Object) is not a valid expression. It fails with exactly the same error message as (macroexpand '(Object)) so I'd say this is consistent behaviour. 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 -- 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: Problem with installing and running labrepl in Eclipse
Well, you seem to describe a problem with the m2eclipse plugin, which may not have recognized the project as a maven project. This is a third party plugin, hard to help with this. Alternatively, could you try the (still experimental) labrepl support ccw offers ? Go to File New Examples Other Clojure examples xxx labrepl xxx. Don't be afraid if the installation takes a long time, labrepl has lots of dependencies to dowload. (note: on Mac OS, maybe the top menu to reach is not named File, but under Eclipse File ?) 2010/8/31 Peter Stahl pemist...@googlemail.com: Hi everyone, I'm a computational linguist coming from Python and want to learn Clojure. So I thought it would be a good idea to start with labrepl. I'm working on Mac OS X 10.6 (Snow Leopard) with the 32bit Cocoa version of Eclipse 3.6 (Helios). I followed the instructions on the labrepl github page (http://github.com/relevance/labrepl) and everything went just fine except for running labrepl. I right clicked on the project in the Package Explorer and started a REPL. I typed (require 'labrepl), hit Enter and then got the following error message: java.io.FileNotFoundException: Could not locate compojure/ core__init.class or compojure/core.clj on classpath: (labrepl.clj:1) After looking into the local Eclipse and labrepl directories, it seems that Compojure and Incanter have not been installed. In fact, I can only find the clojure.jar and clojure-contrib.jar that have been installed by the Counterclockwise plugin. On the labrepl website it says that up-to-date versions of Clojure, contrib, incanter, compojure and a bunch of other libraries to explore should be installed together with labrepl. But Compojure and Incanter are definitely missing on my machine. So what did I do wrong? I did not encounter an error during installation. Do I have to install Compojure manually? I greatly appreciate any advice from you. Thank you very much in advance! :-) Best regards from Germany, Peter -- 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: Lisp/Scheme Style Guide
Speaking of style conventions, am I the only one who finds it mildly irksome that in any Clojure code, half the identifiers are lisp-style-multiword-names while the other half are javaCamlCaseMethodNames. It feels so inconsistent. I'd be happier if Clojure just moved completely to caml case (takes up less width). Thoughts? -- 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: Lisp/Scheme Style Guide
XMLHttpRequest vs. xml-http-request. I rest my case. On Aug 31, 2010, at 3:35 PM, Mark Engelberg wrote: Speaking of style conventions, am I the only one who finds it mildly irksome that in any Clojure code, half the identifiers are lisp-style-multiword-names while the other half are javaCamlCaseMethodNames. It feels so inconsistent. I'd be happier if Clojure just moved completely to caml case (takes up less width). Thoughts? -- 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: Lisp/Scheme Style Guide
On Aug 31, 2010, at 2:35 PM, fin wrote: The concept of the One-Style-To-Rule-Them-All is just childish. Have you read Style is Substance? http://www.artima.com/weblogs/viewpost.jsp?thread=74230 No, I hadn't, thanks for the link. I tried to read the whole thing but stopped after reading what he considered to be logic. Premise #2 and #4 were introduced as facts yet consisted of 100% subjective opinion, that is, I think in fact quite questionable. I can rip them apart if you'd like: Premise 2: There is not now, nor will there ever be, a programming style whose benefit is significantly greater than any of the common styles. All you have to do is take one look at the blood that has been spilled over this topic to see how untrue this statement is. People get very passionate about their preferred style, and if you ask them to write in another style they will complain and cringe and claim that some such or other capability of theirs is being hampered. He is making an objective claim about something that is totally, completely, subjective. Premise 4: For any non-trivial project, a common coding style is a good thing. Relevant quote: having several folks hacking on the same code with conflicting coding styles introduces more pain than any single style imposes on any single person. Here he introduces the concept of conflicting coding styles without explaining what the hell that is. I have seen many projects that have different code style interspersed throughout, yet how they were conflicting is beyond me. This is yet another area where he confuses subjectivity with objectivity. Whether or not a code style is in so-called conflict with another is a completely subjective phenomenon that depends on the observer. In fact I regularly use different code styles within my own code, and they are in no way in conflict, in fact, to me they very much appear to work together in harmony. Some scenarios lend themselves to one style, while others lend themselves to a different one. Further, he doesn't really treat the word project with the sophistication it deserves. A code project is a rather complex thing. A single project may in fact be composed of multiple, disparate projects, written by different authors. How he can claim that Every project I know of has a style is beyond me and leads me to question how observant or aware he is of the code he has used, for practically every significant project that I've used, participated in, or created has relied on the integration of various other bits of code and libraries written by different authors with different styles. My ability to not complain and adapt to understanding their style has not hurt but helped me as a programmer. He is right about one thing though, and that is that so long as style is not a matter of language syntax, there will be people who bring up this discussion again and again because they are for some reason or other incapable of handling a different style of code, just like some time ago white people in America were incapable of allowing blacks to drink from the same drinking fountains as they. Therefore there are actually two solutions to this problem. One of them is apparently easy, and the other is hard. Either you: 1) Mandate code style to be a part of the language's syntax. or you: 2) Grow up and learn to accept the reality that some people think differently from you. It seems to me that the very spirit of LISP leans towards the second solution. LISP is, after all, a very dynamic, open, and extensible language. It does not mandate that you use very many special forms or constructs or keywords. It even allows the creation of new languages within itself. Such as spirit of freedom and openness is what I love about LISP, and why I think Mr. Arnold is mistaken. - Greg -- 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: Lisp/Scheme Style Guide
On Tue, 31 Aug 2010 15:40:10 -0600 Eric Schulte schulte.e...@gmail.com wrote: I apologize for apparently re-opening some fresh wounds. I wasn't trying to assert that these guidelines should be universally adopted or enforced. There are a number of conventions that exist for writing lisp, and I thought that this paper was interesting because it - collects and explicitly states many of these conventions which are rarely spelled out explicitly - attempts to explain some of the conventions that can be mystifying at first - offers genuinely good readability and maintenance reasons for some of the mentioned conventions That was pretty much my impression as well - it was more a collection of stylistic best practices than a real style guide - at least until he gets down to Naming, at which point it starts becoming a bit more opinion than observed practices. mike -- Mike Meyer m...@mired.org 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: NullPointerExecption after Java class import
You could call (import) directly after you've initialised the Gate class:
(gate-init foo)
(import gate.Factory)
; use Factory class as required
Cheers,
Stuart
On 31 August 2010 01:01, zm zygiman...@medelis.lt wrote:
Initialization exception can be avoided if Factory class is
initialized indirectly:
(let [factory (.newInstance (Class/forName gate.Factory))] ...)
The problem is that Factory can only be initialized (its static
fields) after Gate.init was called. But clojure reader (or what it is)
initializes all the classes mentioned in the namespace. Thus Factory
gets created before cojure function calls which do Gate/init.
Is this workaround ok? Or are there better ways to solve it?
On Aug 30, 2:39 pm, zm zygiman...@medelis.lt wrote:
Indeed if exception is thrown in static initializer block then clojure
import throws exception as well.
The following class will cause this:
package aaa;
public class Test {
static{
Object o = null;
o.toString();
}
}
Then in clojure:
(ns x (:import (aaa Test))
Results in:
Exception in thread main java.lang.ExceptionInInitializerError
(core.clj:1)
Why does this happen in clojure? If you do the same in java, import
aaa.Test, then nothing happens. NLP will be thrown when you actualy
try to initialize the class.
On Aug 30, 6:12 am, Stuart Campbell stu...@harto.org wrote:
Hello,
I don't know this library specifically, but the NPE is probably
occurring in
a static initialisation block. I believe static initialisation occurs
when
the class is first loaded.
Regards,
Stuart
On 30 August 2010 06:42, zm zygiman...@medelis.lt wrote:
I am using GATE java libs in my clojure code and behaviour of the
application changes after Java class import. I don't even have to
initialize it.
This runs fine (a bit shorter version than it is):
(ns gate
(:import
(gate Gate)
(java.io File)))
(defn gate-init
[gate-home]
(Gate/setGateHome (File. gate-home))
(Gate/init)))
Now if I import gate.Factory class, like this (gate Gate Factory), I
get the exception:
Caused by: java.lang.NullPointerException
at gate.Factory.createResource(Factory.java:154)
How can import of a class cause this?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com
clojure%2bunsubscr...@googlegroups.comclojure%252bunsubscr...@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.comclojure%2bunsubscr...@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: Lisp/Scheme Style Guide
On Tue, 31 Aug 2010 15:41:13 -0700 Greg g...@kinostudios.com wrote: On Aug 31, 2010, at 2:35 PM, fin wrote: The concept of the One-Style-To-Rule-Them-All is just childish. Have you read Style is Substance? http://www.artima.com/weblogs/viewpost.jsp?thread=74230 No, I hadn't, thanks for the link. I tried to read the whole thing but stopped after reading what he considered to be logic. Premise #2 and #4 were introduced as facts yet consisted of 100% subjective opinion, that is, I think in fact quite questionable. I can rip them apart if you'd like: Except you didn't. At best, you ripped apart a straw man based. Premise 2: There is not now, nor will there ever be, a programming style whose benefit is significantly greater than any of the common styles. All you have to do is take one look at the blood that has been spilled over this topic to see how untrue this statement is. People get very passionate about their preferred style, and if you ask them to write in another style they will complain and cringe and claim that some such or other capability of theirs is being hampered. Um, read the explanation: he's talking about productivity and code quality. He didn't say people didn't care about styles, or weren't passionate about styles. Which means you haven't addressed his issues, just your straw man. He is making an objective claim about something that is totally, completely, subjective. Productivity and code quality are totally, completely, subjective? So all the many, many words written about things agile development, quality engineering, productivity measures, software lifecycles, and so on - are basically meaningless, because they're trying to improve things that are totally, completely subjective? Premise 4: For any non-trivial project, a common coding style is a good thing. Relevant quote: having several folks hacking on the same code with conflicting coding styles introduces more pain than any single style imposes on any single person. I'm willing to grant that one on slightly less solid ground. He's assuming that 1) the project chose a reasonable style, as opposed to one designed to obfuscate code, and 2) that the people involved are likewise not outliers, and can deal with any reasonable coding style. But granted that, his statement pretty much stands as is. Here he introduces the concept of conflicting coding styles without explaining what the hell that is. I have seen many projects that have different code style interspersed throughout, yet how they were conflicting is beyond me. This is yet another area where he confuses subjectivity with objectivity. Whether or not a code style is in so-called conflict with another is a completely subjective phenomenon that depends on the observer. In fact I regularly use different code styles within my own code, and they are in no way in conflict, in fact, to me they very much appear to work together in harmony. Some scenarios lend themselves to one style, while others lend themselves to a different one. My ability to not complain and adapt to understanding their style has not hurt but helped me as a programmer. OK, maybe you're one of the outliers, and don't have any problems with reasonable (or even unreasonable) styles. Yeah, I can see how that would help you. I also regularly work on such projects myself, and changing styles in mid-stream is similar to changing languages in mid-stream: I have to reset how my mind parses things. That projects *have* style guides indicate that others also have this problem. Just like Ken said - adopting any single reasonable style causes me (and probably most people) a lot less grief than letting me use my (or them use their) preferred style but having to switch styles between files, or worse yet, functions. Either you: 1) Mandate code style to be a part of the language's syntax. or you: 2) Grow up and learn to accept the reality that some people think differently from you. And the reason for the posting: you missed a VERY common third alternative. Or at least, it's commonly suggested, though I don't know that any project has actually implemented it: 3) Have your scm format code to canonical form when it's checked in. mike -- Mike Meyer m...@mired.org 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: Minor macroexpand issue
I agree, that's not the expected behavior. The form is just data, it doesn't have to be valid code. Since '(Object) is not a macro (Object is a Symbol there, not a class) it should just return the form just like (identity) does: user= (identity '(Object)) (Object) But macroexpand-1 does some extra work for the interop sugar. I suspect that the error comes when it tries to work out a static member. user= (macroexpand-1 '(.length s)) (. s length) user= (macroexpand-1 '(Boolean/TRUE)) (. Boolean TRUE) user= (macroexpand-1 '(String.)) (new String) On Aug 31, 3:17 pm, Frederic Koehler f.koehler...@gmail.com wrote: If you were to say, (macroexpand '(foo)), it returns (foo), even if it's not defined in the context, so I'd say it's a little unexpected. More annoying is the result this has on macroexpand-all, which breaks because of this weird behaviour: (use 'clojure.walk) (walk/macroexpand-all '(let [Object (fn [])] (Object))) java.lang.RuntimeException: java.lang.Exception: Expecting var, but Object is mapped to class java.lang.Object (NO_SOURCE_FILE:0) Of course, this example is somewhat (not super-) obvious, but in more complex cases it could be fairly annoying. On Tue, 2010-08-31 at 08:14 +0200, Konrad Hinsen wrote: On 30 Aug 2010, at 23:18, Frederic Koehler wrote: I accidentally noticed this: On clojure 1.2, macroexpanding with a function name which is a class, causes this ugly error: (macroexpand '(Object)) java.lang.Exception: Expecting var, but Object is mapped to class java.lang.Object (repl-1:2) when presumably it should just give '(Object). I have no clue for any actual use cases of naming your functions after classes, but: (let [Object (fn [] 3)] (Object)) is technically valid clojure code, so macroexpand shouldn't just die... You are right that (let [Object (fn [] 3)] (Object)) is valid Clojure code, and it works as expected. However, (Object) is not a valid expression. It fails with exactly the same error message as (macroexpand '(Object)) so I'd say this is consistent behaviour. 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- Hide quoted text - - Show quoted text - -- 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: Lisp/Scheme Style Guide
On Aug 31, 2010, at 5:26 PM, Mike Meyer wrote: Um, read the explanation: he's talking about productivity and code quality. He didn't say people didn't care about styles, or weren't passionate about styles. Which means you haven't addressed his issues, just your straw man. There is no straw man, I understood his point fully. People choose various styles for various reasons, and those reasons include productivity and code quality. I listed many reasons related to productivity and code quality in a blog post describing the reasons some choose to trail their parenthesis: http://gregslepak.posterous.com/on-lisps-readability It is also interesting to note, that among the responses to that post, it was brought up that some prefer to stack their parenthesis because it compactifies their code, thereby letting them see more code per-square inch of screen real-estate. They mentioned that this could be very useful if, for example, you're in a situation were you don't have a large screen to work on (i.e. a netbook). I think that's a very valid reason to prefer stacked parenthesis. It's rational and it relates to productivity. More power to them. I don't use a netbook though and usually code on a large monitor, so I can write using trailing parenthesis and get the added benefits that I mentioned in the post. To each his own! As someone once observed, programming is very much like painting or other artistic endeavors. It would be a tragedy if The State ordered Picasso to make his paintings more realistic, (Yes, we can see how you might imagine that to be a building, but We say it has to be done this way.), or to use a particular kind or brush or stroke. There is always controversy when someone steps outside the wall of How Things Are Done. But that is what makes life interesting and worthwhile. The same song played over and over eventually loses its magic. So there are both practical and philosophical reasons to embrace the existence of diversity in code style, and of all the languages out there, it would be ironic and most tragic if the language that facilitates the most freedom of expression, were to be hijacked by the Style Police. - Greg On Tue, 31 Aug 2010 15:41:13 -0700 Greg g...@kinostudios.com wrote: On Aug 31, 2010, at 2:35 PM, fin wrote: The concept of the One-Style-To-Rule-Them-All is just childish. Have you read Style is Substance? http://www.artima.com/weblogs/viewpost.jsp?thread=74230 No, I hadn't, thanks for the link. I tried to read the whole thing but stopped after reading what he considered to be logic. Premise #2 and #4 were introduced as facts yet consisted of 100% subjective opinion, that is, I think in fact quite questionable. I can rip them apart if you'd like: Except you didn't. At best, you ripped apart a straw man based. Premise 2: There is not now, nor will there ever be, a programming style whose benefit is significantly greater than any of the common styles. All you have to do is take one look at the blood that has been spilled over this topic to see how untrue this statement is. People get very passionate about their preferred style, and if you ask them to write in another style they will complain and cringe and claim that some such or other capability of theirs is being hampered. Um, read the explanation: he's talking about productivity and code quality. He didn't say people didn't care about styles, or weren't passionate about styles. Which means you haven't addressed his issues, just your straw man. He is making an objective claim about something that is totally, completely, subjective. Productivity and code quality are totally, completely, subjective? So all the many, many words written about things agile development, quality engineering, productivity measures, software lifecycles, and so on - are basically meaningless, because they're trying to improve things that are totally, completely subjective? Premise 4: For any non-trivial project, a common coding style is a good thing. Relevant quote: having several folks hacking on the same code with conflicting coding styles introduces more pain than any single style imposes on any single person. I'm willing to grant that one on slightly less solid ground. He's assuming that 1) the project chose a reasonable style, as opposed to one designed to obfuscate code, and 2) that the people involved are likewise not outliers, and can deal with any reasonable coding style. But granted that, his statement pretty much stands as is. Here he introduces the concept of conflicting coding styles without explaining what the hell that is. I have seen many projects that have different code style interspersed throughout, yet how they were conflicting is beyond me. This is yet another area where he confuses subjectivity with objectivity. Whether or not a code style is in so-called conflict with another is a completely subjective
Ed Lambda: Functional programming meetup in Edinburgh
Hi guys, I'm running a meetup for functional programming in Edinburgh. The first one will be on the 13th of September at Malone's Irish Bar (14 Forrest Road) and will continue every 2nd monday of each month. For the first meetup I think we'll just be having a chat and getting to know each other but I hope to be able to expand it to talks and coding dojos once we have some regular numbers. For more details: http://meetup.com/ed-lambda/ And we're on Twitter: http://twitter.com/ed_lambda -- 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: Lisp/Scheme Style Guide
It would be a tragedy if The State ordered Picasso to make his paintings more realistic I think your confusing the virtue in shuffling parentheses around. If you want to place your parentheses on their own line then more power to you, it's your style -- but don't confuse it with making high art. The beauty is in the painting, not in the fact that you choose to hang it upside-down. :f -- 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: picking out a tag from a nested struct-map and xml-seq
Hi Peter, The library clojure.contrib.zip-filter is pretty good at this sort of thing. For example: (require '[clojure.xml :as xml]) (require '[clojure.contrib.zip-filter.xml :as zx]) (require '[clojure.zip :as zip]) (defn get-mods-for-iva Returns the mods node if one exists under a version node whose inner-ver-attrib matches test-iva. Otherwise, returns nil. [x-zip test-iva] (zx/xml1- x-zip (zx/tag= :version) (zx/attr= :inner-ver-attrib test-iva) (zx/tag= :type) (zx/tag= :mods))) (defn get-replacement-values Returns a seq of mods nodes if available in x-file for versions 1.4 and 1.6 respectively. [x-file] (let [x-zip (zip/xml-zip (xml/parse x-file)) test-ivas [1.4 1.6]] (map (partial get-mods-for-iva x-zip) test-ivas))) ``clojure.contrib.zip-filter.xml/xml1-'' filters an xml-zip tree using predicates on tags, attributes or text values of nodes. You can chain predicates together (like in ``clojure.core/-'') to navigate trees conditionally. If a predicate returns false or nil, the whole form returns nil, so you know there is no complete match. In the ``get-mods-for-iva'' function above, we start with the complete tree ``x-zip'', and filter for version, then version inner-ver-attrib=test-iva, then type, and finally mods. In ``get-replacement-values'', we parse the XML file and derive an xml-zip tree from it. We then call ``get-mods-for-iva'' for each of the pre-defined versions, and return a seq of their results. This may not be the best solution, and I may have misinterpreted your exact XML structure, but the code shows a simple, functional style. We try to avoid do* forms and side effects (printing during calculation) where possible, collecting results of function calls instead. I hope it helps! On Wed, Sep 1, 2010 at 7:10 AM, Peter buckmeist...@gmail.com wrote: Hi- I'm brand new to Clojure and FP, reading a bunch and working on my first programming task (reading in values from an xml file and a text file and then creating a new text file with some lines/sections of the original text file replaced based on the content of the xml). I found some helpful info here: http://www.chrisumbel.com/article/clojure_xml_parsing_xml-seq on reading the xml file, but I'm a couple more levels deep than that article. I don't know much about Clojure yet, but I have a feeling I'm not doing it the right/idiomatic/best way. I've basically got three nested calls to doseq, and I think it is mostly due to my own unfamiliarity with Clojure and the better options I would have to do this in FP. I'm getting the ver tag in the xml then checking one of its attribs to make sure I'm pulling from the version I want, and then I get the content of the mods tag. I've tried to somewhat simplify this case so the following isn't tested after being extracted from my sandbox. TIA! (defn- dig-through-struct Hides a pair of nested doseq calls from my main function [xml-as-struct] (doseq [y (:content xml-as-struct) :when (= :type (:tag y))] (doseq [z (:content y) :when (= :mods (:tag z))] (println The content I want (:content z) (defn- get-replacement-values Pulls from xml values we want to replace/update/add [x-file] (let [xml-file (File. x-file)] (xml-seq (parse xml-file)) (for [testing-ver `(1.4 1.6)] (doseq [x (xml-seq (parse xml-file)) :when (= :ver (:tag x))] (let [iva (:inner-ver-attrib (:attrs x))] (if (= testing-ver iva) (dig-through-struct x testing-ver iva) (println Did not match the ver we want testing-ver iva))) And this is my xml: proj bunch of attribs ... ver inner-ver-attrib=1.4 (or 1.6 etc, this is a tag I'm interested in conditionally checking) bunch of attribs ... type bunch of attribs ... mods remove entry-namefiles/entry-name entrypath_old\foo_old.c/entry entrypath_old1\foo_old.h/entry /remove add entry-namefiles/entry-name entrypath\foo.c/entry entrypath1\foo.h/entry /add change entry-nameopts/entry-name from-bar=1/from to-bar=2/to /change /mods /type/version/project -- 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.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Abhishek Reddy http://abhishek.geek.nz -- 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
Re: reflection warnings with defprotocol/deftype with type hints
Hi Albert, I made sense of this by keeping the concept of defprotocol separate from definterface and deftype. defprotocol is like multimethods and deftype is like creating an implementation of an interface. You then need to instantiate a new instance of the deftype to execute its methods. The following repl session shows this; ./repl.sh Clojure 1.2.0-master-SNAPSHOT user= (set! *warn-on-reflection* true) true user= (defprotocol PTest (test-it [msg])) PTest user= (extend-protocol PTest nil (test-it[msg] Nix)) nil user= (extend-protocol PTest String (test-it[msg] msg)) nil user= (definterface ITest (test_it ^boolean [^String msg])) user.ITest user= (deftype Test [] ITest (test-it [this msg] ( (.length msg) 0))) user.Test user= (test-it nil) Nix user= (test-it two) two user= (let [tt (Test.)] (.test-it tt hello)) true Note where you do and don't need type hints (there are no reflection warnings). Also note that I used test_it in the definterface. There are probably ways of creating types on protocols, but I haven't tried that yet. -Hth, Adrian On Tue, Aug 31, 2010 at 11:20 PM, Albert Cardona sapri...@gmail.com wrote: Hi all, I am puzzled by the type hint support in deftype. I can add type hints to defprotocol: user= (defprotocol PTest (test-it ^boolean [this ^String msg])) PTest … but adding them to deftype fails: user= (deftype Test [^String name] PTest (test-it [this msg] (str test name : msg \space (.length msg java.lang.IllegalArgumentException: Can't find matching method: test_it, leave off hints for auto match. (NO_SOURCE_FILE:1) So I write the deftype without type hints: user= (deftype Test [^String name] PTest (test-it [this msg] (str test name : msg \space (.length msg user.Test But then, I get reflection warnings: user= (set! *warn-on-reflection* true) true user= (test-it (Test. one) two) test one: two 3 8/31/10 11:11:49 PM [0x0-0x29029].org.fiji[382] Reflection warning, NO_SOURCE_PATH:3 - reference to field length can't be resolved. In any case length is a method, not a field, in String. The above is just a minimal example. I am experiencing this issue in just about all deftype that I need to type-hint. The error when type-hinting suggests that the latter is unnecessary, that it could be deduced from the hints in the protocol definition--but that is not the case. What am I missing? Thanks for any help. Albert -- http://albert.rierol.net -- 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
