Re: swank-clojure: swank-clojure-init-files not used
Cosmin Stejerean writes: Hi Cosmin, >> I'd like that slime loads ~/.clojure/user.clj when starting the >> clojure REPL. Therefore I added that file to >> `swank-clojure-init-files'. This variable is used in >> `swank-clojure-cmd' to build the java invocation command line. >> >> But that didn't work. So I wanted to debug `swank-clojure-cmd' to >> see what's wrong, but it seems that whole function is never called >> when I do `M-x slime'. >> >> I use the current HEAD versions of both swank-clojure and slime from >> their respective version control systems. > > As a workaround you can try adding ~/.clojure to the classpath, > Clojure will automatically load user.clj if found on the classpath. Yes, I've thought that, too. But incidentially swank-clojure seems to add only jar files in `swank-clojure-extra-classpaths' to the classpath. By default that are all jars in ~/.clojure + all jars in `swank-clojure-extra-classpaths'. When adding ~/.clojure/ to `swank-clojure-extra-classpaths' and starting SLIME, htop shows that this directory is not in the -cp java option. Sending a SIGINT kills the clojure process and doesn't interrupt the current Thread only... Bye, Tassilo --~--~-~--~~~---~--~~ 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 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: Parallel Game of Life
Nice! A few more days of work and I've time to play with these kind of
things again. Here are some comments, based on your description.
As game of life is a cellular automata, you do not need any blocking
at all, so you could use agents, rather than refs. It does become an
asynchronous CA then, but that fits for game of life :).
Every cell would be an agent. Agents read the state of their
neighbouring cells and update their own state. If world is a vector of
agents, then (doseq [a world] (send a update)) (apply await world)
would update the whole grid once, using all the processors that java
can find.
On Mar 16, 5:31 am, Scott Fraser wrote:
> I have taken Larry's "Game of Life" example that he originally posted
> here:
>
> http://groups.google.com/group/clojure/msg/fdfc88f1ba95bdee
>
> ...and updated it to use all the CPU's your JVM has access to. My
> first attempts ran into the classic map -> pmap slowdown. My next
> attempt had too much dosync, in that there were many threads but they
> were all waiting for each other.
>
> I finally rewrote the calc-state routine to batch the units of work
> into meaty sizes, and to minimize the dosync granularity. It gets the
> batches of new-state together, then goes and applies these in batches.
> In both events I use pmap.
>
> Now it is running really fast on my 4-core Intel i7. You will really
> notice a difference at larger grid sizes. On my i7 it keeps the 8 (due
> to hyperthreading) "cpus" busy at about 60% when I run a huge grid.
>
> I also updated paint-cells with a type hint that greatly reduces
> reflection in that performance critical code.
>
> I am very new to clojure and would appreciate feedback. I am concerned
> I may have overcomplicated things with my usage of the map/pmap form.
> I am guessing there may be a simpler way to write what I did.
>
> Note at the start it will automatically select how many "available-
> procs" you have. Try tweaking this on your hardware to see how it
> impacts performance. Watching the threads with a profiler is
> interesting.
>
> Here is is:
>
> (def cells (ref {}))
> (def running (ref false))
> ;(def x-cells ( * 32 4))
> ;(def y-cells ( * 48 4))
> (def x-cells 32)
> (def y-cells 32)
> (def range-cells (for [x (range x-cells) y (range y-cells)] [x y]))
> (def length-range-cells (count range-cells))
> (def cell-size 10)
> (def life-delay 0)
> (def life-initial-prob 3)
> (def available-procs (.. java.lang.Runtime getRuntime
> availableProcessors))
>
> (defn determine-initial-state [x y]
> (= 0 (rand-int life-initial-prob)))
>
> (defn determine-new-state [x y]
> (let [alive (count (for [dx [-1 0 1] dy [-1 0 1]
> :when (and (not (= 0 dx dy))
> (cells [ (mod (+ x dx) x-cells)
> (mod (+ y dy) y-cells)]))]
> :alive))]
> (if (cells [x y])
> (< 1 alive 4)
> (= alive 3
>
> (defn update-batch-of-new-cells [new-cells list-of-batches]
> (dosync
> (dorun (map #(commute new-cells assoc (first %) (second %))
> list-of-batches))
> ))
>
> (defn calc-batch-of-new-cell-states [cell-state batch-cells]
> (doall (map
> #(let [new-cell-state (cell-state (first %) (second %))]
> [[(first %) (second %)] new-cell-state])
> batch-cells)))
>
> (defn calc-state [cell-state]
> (let [new-cells (ref {})]
> (dorun (pmap #(update-batch-of-new-cells new-cells %)
> (pmap #(calc-batch-of-new-cell-states cell-state %)
> (for [cpu (range available-procs)] (take-nth available-
> procs (drop cpu range-cells))
> (dosync (ref-set cells @new-cells
>
> (defn paint-cells [#^java.awt.Graphics graphics]
> (doseq [[[x,y] state] @cells]
> (doto graphics
> (. setColor (if state Color/RED Color/WHITE))
> (. fillRect (* cell-size x) (* cell-size y) cell-size cell-
> size
>
> (defn toggle-thread [#^JPanel panel button]
> (if @running
> (do (dosync (ref-set running false))
> (. button (setText "Start")))
> (do (dosync (ref-set running true))
> (. button (setText "Stop"))
> (. (Thread.
> #(loop []
> (calc-state determine-new-state)
> (. panel repaint)
> (if life-delay (Thread/sleep life-delay))
> (if @running (recur
> start
>
> (defn -main[]
>
> (calc-state determine-initial-state)
>
> (let [f (JFrame.)
> b (JButton. "Start")
> panel (proxy [JPanel] [] (paint [graphics] (paint-cells
> graphics)))]
>
> (doto f
> (. setLayout (BorderLayout.))
> (. setLocation 100 100)
> (. setPreferredSize (Dimension. (* cell-size x-cells) (+ 60 (*
> cell-size y-cells
> (. add b BorderLayout/SOUTH)
> (. add panel BorderLayout/CENTER)
> (. setDefaultCloseOperation JFrame/EXIT_ON_CLOSE)
> (. pack)
> (. setVisible true))
>
> (. b addActionListener
> (proxy [ActionList
Re: "08" and "09" are invalid numbers, but "01" through "07" are fine?
I couldn't find anything on the http://clojure.org/reader page, but someone had just posted an example of notation for alternative bases. It looks like you just enter r user=> 2r1000 8 user=> 3r300 java.lang.NumberFormatException: For input string: "300" user=> 3r200 18 Paul On Sun, Mar 15, 2009 at 10:53 PM, Aaron Brooks wrote: > > Rather than going to the horrible effort of looking up to see > if Clojure had support for binary notation, I had a Clojure prompt so > I just tried it and got semi-surprising results: > > user=> #b010001 > java.lang.Exception: No dispatch macro for: b > 4097 > > I'm not surprised that Clojure complains of not knowing what manner of > macro #b is but I was impressed (?) that it still yielded the correct > value. Somewhere, deep in Clojure's little heart, it wants to do other > bases. > > So, here's a request -- can we get macro dispatch for other base > numbers? The CL notation is reasonable, already known and quite > readable. Besides, Clojure tells me it /really/ /wants/ to... ;-) > > -Aaron > > On Fri, Mar 13, 2009 at 9:19 AM, David Sletten wrote: > > > > > > On Mar 13, 2009, at 3:07 AM, Michael Wood wrote: > >> > >> This is pretty standard behaviour. > >> > >> On the other hand, it's not universal. > >> > >> sbcl: > >> > >> * 07 > >> > >> 7 > >> * 08 > >> > >> 8 > >> > > > > Common Lisp uses a separate syntax for binary/octal/hex literals. Legal: > > #b1011, #o377, #xDEADBEEF, #36rZZZ (Base 36 anyone?) > > Illegal: > > #b2, #o8, #xQUICKSAND > > > > (Of course, #36rCLOJURE => 27432414842 :-) ) > > > > Aloha, > > David Sletten > > > > > > > > > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
Symbols evaluated at compile time?
Hi, in this code: (defn main [] (check-services)) (defn check-services [] 1) if I call slime-eval-defun on "main" before calling it on "check- services", Clojure aborts with: java.lang.Exception: Unable to resolve symbol: check-services in this context (NO_SOURCE_FILE:3) [Thrown class clojure.lang.Compiler$CompilerException] Is it expected? --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
Elena a écrit : > Hi, > > in this code: > > (defn main [] > (check-services)) > > (defn check-services [] > 1) > > if I call slime-eval-defun on "main" before calling it on "check- > services", Clojure aborts with: > > java.lang.Exception: Unable to resolve symbol: check-services in this > context (NO_SOURCE_FILE:3) > [Thrown class clojure.lang.Compiler$CompilerException] > > Is it expected? > Yes, it prevents typos to go unnoticed. You can write a forward declaration : (declare check-services); equivalent to (def check-services) (defn main [] (check-services)) (defn check-services [] 1) HTH Christophe -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.blogspot.com/ (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 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: Symbols evaluated at compile time?
On 16.03.2009, at 11:35, Elena wrote: > in this code: > > (defn main [] > (check-services)) > > (defn check-services [] > 1) > > if I call slime-eval-defun on "main" before calling it on "check- > services", Clojure aborts with: > > java.lang.Exception: Unable to resolve symbol: check-services in this > context (NO_SOURCE_FILE:3) > [Thrown class clojure.lang.Compiler$CompilerException] > > Is it expected? Yes. Clojure checks that symbols are defined before they are used. You can put (declare check-services) before your definition of main to define the symbol and make it clear to the (human) reader that you indeed to give the real definition later. 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 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: Symbols evaluated at compile time?
On Mar 16, 10:40 am, Christophe Grand wrote: > > Yes, it prevents typos to go unnoticed. You can write a forward > declaration : > > (declare check-services); equivalent to (def check-services) > > (defn main [] > (check-services)) > > (defn check-services [] > 1) > OK, thanks. I was expecting a behavior similar to Scheme (and maybe Common Lisp). Doesn't that hampers interactive development? I mean: you have to develop the program in a more controlled manner. --~--~-~--~~~---~--~~ 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 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: Promise for absense of side effects
Meikel Brandmeyer schrieb: > I remember some presentation of someone doing this for, > I think, Python. There you hint things, where the type is > known and the compiler inferred the rest as far as possible. > What cannot be inferred was cast to a special type called > "dynamic". So this roughly worked like type hints in Clojure. > Just with a bit more inference and "dynamic" meaning > "reflection". Did you mean this: http://wiki.jvmlangsummit.com/pdf/28_Siek_gradual.pdf It was presented at the JVM Summit, so Rich may already have given a thought to 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 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 -~--~~~~--~~--~--~---
Which Java book(s) to order
Hi, My background: about 40 years experience in many fields of computing, mainly in the Scientific Computing Area. My experience ranges from working with small machines (not in physical size - 4 Kbyte core memory) in 1970, early adapter of Unix (1976), early experimentor with Linux (from version 0.12 I seem to remember), and I have used or experimented with MANY programming languages, including LISP, Objective-C, Smalltalk, Scheme, Python and Ruby but didnt make real practical use of many due to political restrictions and standards within the company I worked for. Now I am being drawn to dig into Clojure, and being retired, I should have enough time for that. HOWEVER, for some reason I always kept clear from JAVA... The reason for that I wont go into at this moment. Clojure and also the JVM make me recosider this. The JVM is something which cant be ignored, certainly seeing the very good use of it for example by Clojure and JRuby. (It does remind me of the P-code what was generated by the first Pascal compiler) The question: As i think I should get a better understanding of Java and the environment of the JVM to better understand the Clojure environment, I need to get one or two books on that, to lay a base to build upon. So I need suggestions on my order with Amazon: What book or books should I order to base my JAVA knowledgde on ? Of course if this information is available in a good, readable way on the web, I would appreciate it to have some pointers, but I want to have at least ONE real book to fall back to. Thanks for your suggestions. Leo Noordhuizen - The Netherlands --~--~-~--~~~---~--~~ 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 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: Which Java book(s) to order
2009/3/16 DonLeo :
> What book or books should I order to base my JAVA knowledge on ?
I would suggest the following:
1. Thinking in Java by Bruce Eckel
I learned C++ by reading Thinking in C++ by the same author so it was
a natural progression to move on to this book. It's very big but then
so is the Java language :)
2. Effective Java by Joshua Bloch
Not for learning Java but excellent for learning how to write quality
Java code. A must read IMO.
3. Java Concurrency in Practise
I have not read this yet but I want to as Rich praises it in his
concurrency talk.
Cheers,
Paul Drummond
--
Iode Software Ltd, registered in England No. 6299803.
Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.
This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.
--~--~-~--~~~---~--~~
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
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: Which Java book(s) to order
On Mar 16, 2009, at 12:19 AM, DonLeo wrote: > > Hi, > > My background: about 40 years experience in many fields of computing, > mainly in the Scientific Computing Area. My experience ranges from > working with small machines (not in physical size - 4 Kbyte core > memory) in 1970, early adapter of Unix (1976), early experimentor with > Linux (from version 0.12 I seem to remember), and I have used or > experimented with MANY programming languages, including LISP, > Objective-C, Smalltalk, Scheme, Python and Ruby but didnt make real > practical use of many due to political restrictions and standards > within the company I worked for. > Now I am being drawn to dig into Clojure, and being retired, I should > have enough time for that. HOWEVER, for some reason I always kept > clear from JAVA... The reason for that I wont go into at this moment. > Clojure and also the JVM make me recosider this. The JVM is something > which cant be ignored, certainly seeing the very good use of it for > example by Clojure and JRuby. (It does remind me of the P-code what > was generated by the first Pascal compiler) > > The question: As i think I should get a better understanding of Java > and the environment of the JVM to better understand the Clojure > environment, I need to get one or two books on that, to lay a base to > build upon. So I need suggestions on my order with Amazon: > > What book or books should I order to base my JAVA knowledgde on ? > > Here are 3 good books on Java fundamentals: 1. Java Programming from the Beginning http://www.amazon.com/Java-Programming-Beginning-K-King/dp/0393974375/ ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1237204475&sr=8-1 Two caveats here: -This book may be too rudimentary considering your experience. A good intro to OOP though if you're looking for it. -I thought he had a newer edition out. This one is from 2000, so it doesn't cover the new stuff in Java 1.5 2. Just Java http://www.amazon.com/Just-Java-6th-Microsystems-Press/dp/0131482114/ ref=sr_1_1?ie=UTF8&s=books&qid=1237204784&sr=1-1 3. Learning Java http://www.amazon.com/Learning-Java-Pat-Niemeyer/dp/0596008732/ ref=sr_1_1?ie=UTF8&s=books&qid=1237204946&sr=1-1 Pretty up-to-date and covers a lot of ground. Aloha, David Sletten --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: filter1 interesting?
On Mar 14, 11:26 am, Stuart Sierra wrote: > I've added a "seek" function to clojure.contrib.seq-utils: > > (defn seek > "Returns the first item of coll for which (pred item) returns > logical true. > Consumes sequences up to the first match, will consume the entire > sequence > and return nil if no match is found." > [pred coll] > (first (filter pred coll))) > Sorry to jump in late, but one problem with seek is that it is a homophone of seq. Did anyone consider ffilter or find-first? Rich --~--~-~--~~~---~--~~ 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 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: Which Java book(s) to order
I hate "+1" emails, but this is essentially just that.
"Java Concurrency in Practice" gets my vote as the most important book
to read about Java. I always keep it and "Effective Java" close at
hand. Both of these are references for when you "know some java";
they're not really tutorials.
I haven't read "Thinking in Java", so I can't comment on that one.
On Mar 16, 7:50 am, Paul Drummond wrote:
> 2009/3/16 DonLeo :
>
> > What book or books should I order to base my JAVA knowledge on ?
>
> I would suggest the following:
>
> 1. Thinking in Java by Bruce Eckel
>
> I learned C++ by reading Thinking in C++ by the same author so it was
> a natural progression to move on to this book. It's very big but then
> so is the Java language :)
>
> 2. Effective Java by Joshua Bloch
>
> Not for learning Java but excellent for learning how to write quality
> Java code. A must read IMO.
>
> 3. Java Concurrency in Practise
>
> I have not read this yet but I want to as Rich praises it in his
> concurrency talk.
>
> Cheers,
> Paul Drummond
> --
> Iode Software Ltd, registered in England No. 6299803.
>
> Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
> & Wear, DH5 8NE.
>
> This message is intended only for the use of the person(s) ("the
> intended recipient(s)") to whom it is addressed. It may contain
> information which is privileged and confidential within the meaning of
> applicable law. If you are not the intended recipient, please contact
> the sender as soon as possible. The views expressed in this
> communication may not necessarily be the views held by The Company.
--~--~-~--~~~---~--~~
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
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: Which Java book(s) to order
The 3rd edition of Thinking in Java is available on the author's website for
free.
http://www.mindview.net/Books/TIJ/
Paul
On Mon, Mar 16, 2009 at 8:47 AM, Mark Feeney wrote:
>
> I hate "+1" emails, but this is essentially just that.
>
> "Java Concurrency in Practice" gets my vote as the most important book
> to read about Java. I always keep it and "Effective Java" close at
> hand. Both of these are references for when you "know some java";
> they're not really tutorials.
>
> I haven't read "Thinking in Java", so I can't comment on that one.
>
> On Mar 16, 7:50 am, Paul Drummond wrote:
> > 2009/3/16 DonLeo :
> >
> > > What book or books should I order to base my JAVA knowledge on ?
> >
> > I would suggest the following:
> >
> > 1. Thinking in Java by Bruce Eckel
> >
> > I learned C++ by reading Thinking in C++ by the same author so it was
> > a natural progression to move on to this book. It's very big but then
> > so is the Java language :)
> >
> > 2. Effective Java by Joshua Bloch
> >
> > Not for learning Java but excellent for learning how to write quality
> > Java code. A must read IMO.
> >
> > 3. Java Concurrency in Practise
> >
> > I have not read this yet but I want to as Rich praises it in his
> > concurrency talk.
> >
> > Cheers,
> > Paul Drummond
> > --
> > Iode Software Ltd, registered in England No. 6299803.
> >
> > Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
> > & Wear, DH5 8NE.
> >
> > This message is intended only for the use of the person(s) ("the
> > intended recipient(s)") to whom it is addressed. It may contain
> > information which is privileged and confidential within the meaning of
> > applicable law. If you are not the intended recipient, please contact
> > the sender as soon as possible. The views expressed in this
> > communication may not necessarily be the views held by The Company.
> >
>
--~--~-~--~~~---~--~~
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
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: Which Java book(s) to order
2009/3/16 Paul Stadig : > The 3rd edition of Thinking in Java is available on the author's website for > free. > > http://www.mindview.net/Books/TIJ/ > That's true but beware it is quite old now and doesn't cover Java 5 or 6. The fourth edition (which isn't freely available) is the latest and it includes significant updates for Java 5 and Java 6 including substantial changes and updates to the concurrency chapter and of course coverage of all the additions in Java 5/6 (like generics, enums, etc). Paul. --~--~-~--~~~---~--~~ 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 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: swank-clojure: swank-clojure-init-files not used
On Mon, Mar 16, 2009 at 3:42 AM, Tassilo Horn wrote: > > > When adding ~/.clojure/ to `swank-clojure-extra-classpaths' and starting > SLIME, htop shows that this directory is not in the -cp java option. > Sending a SIGINT kills the clojure process and doesn't interrupt the > current Thread only... > I've noted that you cannot interactively change that variable. If you change it you must restart your emacs session for it to take effect. If you haven't already checked this of course. 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 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: swank-clojure: swank-clojure-init-files not used
David Nolen writes: Hi David, >> When adding ~/.clojure/ to `swank-clojure-extra-classpaths' and >> starting SLIME, htop shows that this directory is not in the -cp java >> option. Sending a SIGINT kills the clojure process and doesn't >> interrupt the current Thread only... > > I've noted that you cannot interactively change that variable. If you > change it you must restart your emacs session for it to take > effect. If you haven't already checked this of course. I've checked that right now to be sure, and still ~/.clojure/ is not added to the classpath option of the java invocation command line. Bye, Tassilo -- Windows: So easy to admin, even a worm can do it. --~--~-~--~~~---~--~~ 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 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: filter1 interesting?
On 16 Mrz., 13:14, Rich Hickey wrote: > On Mar 14, 11:26 am, Stuart Sierra > wrote: > > > I've added a "seek" function to clojure.contrib.seq-utils: > > > (defn seek > > "Returns the first item of coll for which (pred item) returns > > logical true. > > Consumes sequences up to the first match, will consume the entire > > sequence > > and return nil if no match is found." > > [pred coll] > > (first (filter pred coll))) > > Sorry to jump in late, but one problem with seek is that it is a > homophone of seq. > > Did anyone consider ffilter or find-first? In that case I would vote for ffilter. --~--~-~--~~~---~--~~ 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 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: filter1 interesting?
Just to make me more enemies ;-), I would prefer, on the other hand, find-first over ffirst (I'm not that nostalgic of some Common Lisp-like abbreviations :-) No, really, ffirst is just 3 characters shorter than find-first, and looks like a typo at first glance. -- Laurent 2009/3/16 André Thieme > > On 16 Mrz., 13:14, Rich Hickey wrote: > > On Mar 14, 11:26 am, Stuart Sierra > > wrote: > > > > > I've added a "seek" function to clojure.contrib.seq-utils: > > > > > (defn seek > > > "Returns the first item of coll for which (pred item) returns > > > logical true. > > > Consumes sequences up to the first match, will consume the entire > > > sequence > > > and return nil if no match is found." > > > [pred coll] > > > (first (filter pred coll))) > > > > Sorry to jump in late, but one problem with seek is that it is a > > homophone of seq. > > > > Did anyone consider ffilter or find-first? > > In that case I would vote for ffilter. > > > --~--~-~--~~~---~--~~ 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 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: Parallel Game of Life
It would be interesting to throw gridgain (http://www.gridgain.com/)
into the mix and let people register their machines as part of a CA
grid. Not sure the remote overhead would pay for itself but it would
be interesting.
On Mar 16, 3:03 am, bOR_ wrote:
> Nice! A few more days of work and I've time to play with these kind of
> things again. Here are some comments, based on your description.
>
> As game of life is a cellular automata, you do not need any blocking
> at all, so you could use agents, rather than refs. It does become an
> asynchronous CA then, but that fits for game of life :).
>
> Every cell would be an agent. Agents read the state of their
> neighbouring cells and update their own state. If world is a vector of
> agents, then (doseq [a world] (send a update)) (apply await world)
> would update the whole grid once, using all the processors that java
> can find.
>
> On Mar 16, 5:31 am, Scott Fraser wrote:
>
> > I have taken Larry's "Game of Life" example that he originally posted
> > here:
>
> >http://groups.google.com/group/clojure/msg/fdfc88f1ba95bdee
>
> > ...and updated it to use all the CPU's your JVM has access to. My
> > first attempts ran into the classic map -> pmap slowdown. My next
> > attempt had too much dosync, in that there were many threads but they
> > were all waiting for each other.
>
> > I finally rewrote the calc-state routine to batch the units of work
> > into meaty sizes, and to minimize the dosync granularity. It gets the
> > batches of new-state together, then goes and applies these in batches.
> > In both events I use pmap.
>
> > Now it is running really fast on my 4-core Intel i7. You will really
> > notice a difference at larger grid sizes. On my i7 it keeps the 8 (due
> > to hyperthreading) "cpus" busy at about 60% when I run a huge grid.
>
> > I also updated paint-cells with a type hint that greatly reduces
> > reflection in that performance critical code.
>
> > I am very new to clojure and would appreciate feedback. I am concerned
> > I may have overcomplicated things with my usage of the map/pmap form.
> > I am guessing there may be a simpler way to write what I did.
>
> > Note at the start it will automatically select how many "available-
> > procs" you have. Try tweaking this on your hardware to see how it
> > impacts performance. Watching the threads with a profiler is
> > interesting.
>
> > Here is is:
>
> > (def cells (ref {}))
> > (def running (ref false))
> > ;(def x-cells ( * 32 4))
> > ;(def y-cells ( * 48 4))
> > (def x-cells 32)
> > (def y-cells 32)
> > (def range-cells (for [x (range x-cells) y (range y-cells)] [x y]))
> > (def length-range-cells (count range-cells))
> > (def cell-size 10)
> > (def life-delay 0)
> > (def life-initial-prob 3)
> > (def available-procs (.. java.lang.Runtime getRuntime
> > availableProcessors))
>
> > (defn determine-initial-state [x y]
> > (= 0 (rand-int life-initial-prob)))
>
> > (defn determine-new-state [x y]
> > (let [alive (count (for [dx [-1 0 1] dy [-1 0 1]
> > :when (and (not (= 0 dx dy))
> > (cells [ (mod (+ x dx) x-cells)
> > (mod (+ y dy) y-cells)]))]
> > :alive))]
> > (if (cells [x y])
> > (< 1 alive 4)
> > (= alive 3
>
> > (defn update-batch-of-new-cells [new-cells list-of-batches]
> > (dosync
> > (dorun (map #(commute new-cells assoc (first %) (second %))
> > list-of-batches))
> > ))
>
> > (defn calc-batch-of-new-cell-states [cell-state batch-cells]
> > (doall (map
> > #(let [new-cell-state (cell-state (first %) (second %))]
> > [[(first %) (second %)] new-cell-state])
> > batch-cells)))
>
> > (defn calc-state [cell-state]
> > (let [new-cells (ref {})]
> > (dorun (pmap #(update-batch-of-new-cells new-cells %)
> > (pmap #(calc-batch-of-new-cell-states cell-state %)
> > (for [cpu (range available-procs)] (take-nth available-
> > procs (drop cpu range-cells))
> > (dosync (ref-set cells @new-cells
>
> > (defn paint-cells [#^java.awt.Graphics graphics]
> > (doseq [[[x,y] state] @cells]
> > (doto graphics
> > (. setColor (if state Color/RED Color/WHITE))
> > (. fillRect (* cell-size x) (* cell-size y) cell-size cell-
> > size
>
> > (defn toggle-thread [#^JPanel panel button]
> > (if @running
> > (do (dosync (ref-set running false))
> > (. button (setText "Start")))
> > (do (dosync (ref-set running true))
> > (. button (setText "Stop"))
> > (. (Thread.
> > #(loop []
> > (calc-state determine-new-state)
> > (. panel repaint)
> > (if life-delay (Thread/sleep life-delay))
> > (if @running (recur
> > start
>
> > (defn -main[]
>
> > (calc-state determine-initial-state)
>
> > (let [f (JFrame.)
> > b (JButton. "Start")
> > panel (proxy [JPanel] [] (paint
Re: Parallel Game of Life
Hello,
2009/3/16 bOR_
>
> Nice! A few more days of work and I've time to play with these kind of
> things again. Here are some comments, based on your description.
>
> As game of life is a cellular automata, you do not need any blocking
> at all, so you could use agents, rather than refs. It does become an
> asynchronous CA then, but that fits for game of life :).
>
> Every cell would be an agent. Agents read the state of their
> neighbouring cells and update their own state. If world is a vector of
> agents, then (doseq [a world] (send a update)) (apply await world)
> would update the whole grid once, using all the processors that java
> can find.
I'm not very used to concurrent programming, so I have a few questions you
may find naïve, but well, let's just pretend they're interesting ... :
It seems to me that the game of life works in "increments" of its "world".
So I don't see at first what can be gained by using one agent for each cell.
Because then, you'll still have to coordinate the work of the agents in your
code.
I suspect you suggested to use agents because by using agents, you gain an
abstraction for parallel programming for free, and that you are not using
agent for what I think they are for in the first place: asynchronized
computing.
Regards,
--
Laurent
>
> On Mar 16, 5:31 am, Scott Fraser wrote:
> > I have taken Larry's "Game of Life" example that he originally posted
> > here:
> >
> > http://groups.google.com/group/clojure/msg/fdfc88f1ba95bdee
> >
> > ...and updated it to use all the CPU's your JVM has access to. My
> > first attempts ran into the classic map -> pmap slowdown. My next
> > attempt had too much dosync, in that there were many threads but they
> > were all waiting for each other.
> >
> > I finally rewrote the calc-state routine to batch the units of work
> > into meaty sizes, and to minimize the dosync granularity. It gets the
> > batches of new-state together, then goes and applies these in batches.
> > In both events I use pmap.
> >
> > Now it is running really fast on my 4-core Intel i7. You will really
> > notice a difference at larger grid sizes. On my i7 it keeps the 8 (due
> > to hyperthreading) "cpus" busy at about 60% when I run a huge grid.
> >
> > I also updated paint-cells with a type hint that greatly reduces
> > reflection in that performance critical code.
> >
> > I am very new to clojure and would appreciate feedback. I am concerned
> > I may have overcomplicated things with my usage of the map/pmap form.
> > I am guessing there may be a simpler way to write what I did.
> >
> > Note at the start it will automatically select how many "available-
> > procs" you have. Try tweaking this on your hardware to see how it
> > impacts performance. Watching the threads with a profiler is
> > interesting.
> >
> > Here is is:
> >
> > (def cells (ref {}))
> > (def running (ref false))
> > ;(def x-cells ( * 32 4))
> > ;(def y-cells ( * 48 4))
> > (def x-cells 32)
> > (def y-cells 32)
> > (def range-cells (for [x (range x-cells) y (range y-cells)] [x y]))
> > (def length-range-cells (count range-cells))
> > (def cell-size 10)
> > (def life-delay 0)
> > (def life-initial-prob 3)
> > (def available-procs (.. java.lang.Runtime getRuntime
> > availableProcessors))
> >
> > (defn determine-initial-state [x y]
> > (= 0 (rand-int life-initial-prob)))
> >
> > (defn determine-new-state [x y]
> > (let [alive (count (for [dx [-1 0 1] dy [-1 0 1]
> >:when (and (not (= 0 dx dy))
> >(cells [ (mod (+ x dx) x-cells)
> > (mod (+ y dy) y-cells)]))]
> >:alive))]
> > (if (cells [x y])
> > (< 1 alive 4)
> > (= alive 3
> >
> > (defn update-batch-of-new-cells [new-cells list-of-batches]
> > (dosync
> > (dorun (map #(commute new-cells assoc (first %) (second %))
> > list-of-batches))
> > ))
> >
> > (defn calc-batch-of-new-cell-states [cell-state batch-cells]
> > (doall (map
> >#(let [new-cell-state (cell-state (first %) (second %))]
> > [[(first %) (second %)] new-cell-state])
> >batch-cells)))
> >
> > (defn calc-state [cell-state]
> > (let [new-cells (ref {})]
> > (dorun (pmap #(update-batch-of-new-cells new-cells %)
> > (pmap #(calc-batch-of-new-cell-states cell-state %)
> >(for [cpu (range available-procs)] (take-nth available-
> > procs (drop cpu range-cells))
> > (dosync (ref-set cells @new-cells
> >
> > (defn paint-cells [#^java.awt.Graphics graphics]
> > (doseq [[[x,y] state] @cells]
> > (doto graphics
> > (. setColor (if state Color/RED Color/WHITE))
> > (. fillRect (* cell-size x) (* cell-size y) cell-size cell-
> > size
> >
> > (defn toggle-thread [#^JPanel panel button]
> > (if @running
> > (do (dosync (ref-set running false))
> > (. button (setText "Start")))
> > (do (dosync (ref-set running true))
> > (. button (s
Re: Game of Life
Very cool. Thanks for the tip. I didn't know a type hint would make
that much difference.
Another possible speedup would be to use send/actor to take advantage
of multiprocessor machines. Would be curious if the overhead would pay
for itself in this situation.
Thanks, Larry
On Mar 14, 8:03 pm, Scott Fraser wrote:
> Hi Larry
>
> I have a performance tweak, that gives about an order of magnitude
> speedup to paint-cells when running this with a large grid and no or
> little (Thread/sleep life-delay) in toggle-thread. That is how I am
> running it now - 128 x 192 cells with no delay! It is also noticeably
> faster on the more typical size grid.
>
> Type hint is on the graphics param:
>
> (defn paint-cells [#^java.awt.Graphics graphics]
> (time (doseq [[[x,y] state] @cells]
> (doto graphics
> (. setColor (if state Color/RED Color/WHITE))
> (. fillRect (* cell-size x) (* cell-size y) cell-size cell-
> size)
>
> Example, with type hint:
>
> "Elapsed time: 45.871193 msecs"
> "Elapsed time: 39.209662 msecs"
> "Elapsed time: 43.899504 msecs"
>
> Without:
>
> "Elapsed time: 529.635331 msecs"
> "Elapsed time: 438.145769 msecs"
> "Elapsed time: 442.839872 msecs"
>
> I would imagine there may be some other way to get clojure to cache
> the reflected handle to Graphics, but I am still a little new to this
> so don't have any other ideas on how to eliminate the high amount of
> reflection without a type hint.
>
> -Scotthttp://fraser.blogs.com/
>
> On Mar 4, 4:17 pm, Larry Sherrill wrote:
>
> > I've incorporated everyone's suggestions and thought I would post the
> > resulting smaller code. I refactored init-cells away and just pass in
> > an init or new function to calc-state to reuse the for loop. I made
> > determine-next-state a little more verbose than technically necessary
> > to makeconway'srules more obvious to me. The refs "cells" and
> > "running" don't feel very functional but I don't know how to get rid
> > of them.
>
> > (import '(javax.swing JFrame JPanel JButton)
> > '(java.awt BorderLayout Dimension Color)
> > '(java.awt.event ActionListener))
>
> > (def cells (ref {}))
>
> > (def running (ref false))
>
> > (defn determine-initial-state [x y]
> > (= 0 (rand-int 5)))
>
> > (defn determine-new-state [x y]
> > (let [neighbor-count
> > (count (for [dx [-1 0 1] dy [-1 0 1]
> > :when (and (not (= 0 dx dy))
> > (cells [(+ x dx) (+ y dy)]))]
> > :alive))]
> > (if (cells [x y])
> > (< 1 neighbor-count 4)
> > (= neighbor-count 3
>
> > (defn calc-state [cell-state]
> > (dosync
> > (ref-set cells
> > (reduce conj {}
> > (for [x (range 32) y (range 48)]
> > [[x y] (cell-state x y)])
>
> > (defn paint-cells [graphics]
> > (doseq [[[x, y] state] @cells]
> > (doto graphics
> > (. setColor (if state Color/RED Color/WHITE))
> > (. fillRect (* 10 x) (* 10 y) 10 10
>
> > (defn toggle-thread [panel button]
> > (if @running
>
> > (do (dosync (ref-set running false))
> > (. button (setText "Start")))
>
> > (do (dosync (ref-set running true))
> > (. button (setText "Stop"))
> > (. (Thread.
> > #(loop []
> > (calc-state determine-new-state)
> > (. panel repaint)
> > (Thread/sleep 100)
> > (if @running (recur
> > start
>
> > (defn main[]
>
> > (calc-state determine-initial-state)
>
> > (let [f (JFrame.)
> > b (JButton. "Start")
> > panel (proxy [JPanel] [] (paint [graphics] (paint-cells
> > graphics)))]
>
> > (doto f
> > (. setLayout (BorderLayout.))
> > (. setLocation 100 100)
> > (. setPreferredSize (Dimension. 320 540))
> > (. add b BorderLayout/SOUTH)
> > (. add panel BorderLayout/CENTER)
> > (. setDefaultCloseOperation JFrame/EXIT_ON_CLOSE)
> > (. pack)
> > (. setVisible true))
>
> > (. b addActionListener
> > (proxy [ActionListener] []
> > (actionPerformed [evt] (toggle-thread panel b))
>
> > (main)
>
> > Thanks for everyone. Very good learning experience.
> > Larryhttp://lpsherrill.blogspot.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
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: Parallel Game of Life
On Mon, Mar 16, 2009 at 12:31 AM, Scott Fraser wrote: > > I have taken Larry's "Game of Life" example that he originally posted > here: > > http://groups.google.com/group/clojure/msg/fdfc88f1ba95bdee > > ...and updated it to use all the CPU's your JVM has access to... Scott, Your changes indeed make it run significantly faster for me. Thanks! I added a 'reset' button and changed some of the java method calls to be a bit more (I think) idomatic clojure. The full file is here: http://asymmetrical-view.com/personal/code/clojure/life.clj And a patch is attached (you also left off the import statements in you email). FYI: Scott Fraser is giving a talk on clojure at the Philly Emerging Technologies for the Enterprise conference next week: http://phillyemergingtech.com/abstractsTab.php?sessID=39 http://phillyemergingtech.com/speakers.php Regards, Kyle Burton -- -- kyle.bur...@gmail.comhttp://asymmetrical-view.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 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 -~--~~~~--~~--~--~--- life.patch Description: Binary data
Re: Parallel Game of Life
Hi Kyle, I added life-conway.clj to the files section last week. It has rand, clear, and bounded buttons, and the ability to use your mouse to draw the pattern rather than rely on rand. It's a good way to experiment with different automata such as gliders. Larry Sherrill On Mar 16, 9:33 am, "Kyle R. Burton" wrote: > On Mon, Mar 16, 2009 at 12:31 AM, Scott Fraser > wrote: > > > I have taken Larry's "Game of Life" example that he originally posted > > here: > > >http://groups.google.com/group/clojure/msg/fdfc88f1ba95bdee > > > ...and updated it to use all the CPU's your JVM has access to... > > Scott, > > Your changes indeed make it run significantly faster for me. Thanks! > > I added a 'reset' button and changed some of the java method calls to > be a bit more (I think) idomatic clojure. > > The full file is > here:http://asymmetrical-view.com/personal/code/clojure/life.clj > > And a patch is attached (you also left off the import statements in you > email). > > FYI: Scott Fraser is giving a talk on clojure at the Philly Emerging > Technologies for the Enterprise conference next week: > > http://phillyemergingtech.com/abstractsTab.php?sessID=39 > http://phillyemergingtech.com/speakers.php > > Regards, > > Kyle Burton > > -- > --- > --- > kyle.bur...@gmail.com http://asymmetrical-view.com/ > --- > --- > > life.patch > 3KViewDownload --~--~-~--~~~---~--~~ 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 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: Parallel Game of Life
> > I'm not very used to concurrent programming, so I have a few questions you > may find naïve, but well, let's just pretend they're interesting ... : Learning here as well :). > > It seems to me that the game of life works in "increments" of its "world". > So I don't see at first what can be gained by using one agent for each cell. > Because then, you'll still have to coordinate the work of the agents in your > code. > I suspect you suggested to use agents because by using agents, you gain an > abstraction for parallel programming for free, and that you are not using > agent for what I think they are for in the first place: asynchronized > computing. Each cell in a cellular automata (of which game of life is an example) only wants to change itself, based on certain rules and its neighbours.. so there should never be any blocking. You are right that the cellular automata would become asynchronous when using agents, and whether or not you want that depends on what you want to simulate. I'll see if I can write a agent-based version for it when time allows. it will be a good exercise for me as well. --~--~-~--~~~---~--~~ 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 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: filter1 interesting?
Rich didn't chime in about the overload of 'first', which probably means that's out. find-first is better than ffirst, but it's not really accurate, IMO. You don't have to "find" it. it's just the first one for which the predicate is true. (get-first ... ) has one less letter than (find-first ...) but there's probably some other problem with that. (first ...) is the most genius to me if you step back from historical ties ... and newbies like me have the best chance of discovering it. But keep in mind, I'm just casually following the discussions right now -- not working in clojure at the moment. On Mon, Mar 16, 2009 at 10:51 AM, Laurent PETIT wrote: > Just to make me more enemies ;-), I would prefer, on the other hand, > find-first over ffirst (I'm not that nostalgic of some Common Lisp-like > abbreviations :-) > > No, really, ffirst is just 3 characters shorter than find-first, and looks > like a typo at first glance. > > -- > Laurent > > 2009/3/16 André Thieme > > >> On 16 Mrz., 13:14, Rich Hickey wrote: >> > On Mar 14, 11:26 am, Stuart Sierra >> > wrote: >> > >> > > I've added a "seek" function to clojure.contrib.seq-utils: >> > >> > > (defn seek >> > > "Returns the first item of coll for which (pred item) returns >> > > logical true. >> > > Consumes sequences up to the first match, will consume the entire >> > > sequence >> > > and return nil if no match is found." >> > > [pred coll] >> > > (first (filter pred coll))) >> > >> > Sorry to jump in late, but one problem with seek is that it is a >> > homophone of seq. >> > >> > Did anyone consider ffilter or find-first? >> >> In that case I would vote for ffilter. >> >> > > > > > > --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Box
Shawn, Clojure Box works well, I'd like to make a feature request: can you add paredit [1]? Including it in the distribution (perhaps with it disabled) would be great. Thanks for putting it together. Kyle [1] http://www.emacswiki.org/cgi-bin/wiki/ParEdit -- -- kyle.bur...@gmail.comhttp://asymmetrical-view.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 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: Qi's type system
> could be applicable in Clojure. From what I gathered from the tweets > from Qcon, Qi was mentioned again there. Does anyone know if there > was anything more to it than "it would be nice"? (fwiw, Mark T. talked about it a bit on the Qi list. http://groups.google.co.uk/group/Qilang/search?group=Qilang&q=clojure&qt_g=Search+this+group) --~--~-~--~~~---~--~~ 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 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: swank-clojure-extra-classpaths troubles
On Tue, Mar 10, 2009 at 7:21 AM, Tassilo Horn wrote: > user> (require 'examples.introduction) > > I get this exception: > > , > | java.io.FileNotFoundException: Could not locate \ > | examples/introduction__init.class or \ > | examples/introduction.clj on classpath: (NO_SOURCE_FILE:0) > | [Thrown class clojure.lang.Compiler$CompilerException] > ` > > When I use the repl.sh script that comes with the examples and start it > from /home/horn/repos/programming-clojure/ it works (. is in the -cp > argument), but I guess that's exactly what those extra classpaths of > clojure-swank are meant for. > > Is this a bug in swank-clojure? (And if so, is that the right place to > ask for help with clojure tool support anyway?) > > Bye and thanks for any pointers, > Tassilo > Tassilo, I was able to reproduce this on my Windows box when I tried hacking in an extra classpath to an already-running emacs that had already started slime. It turns out the extra classpaths are only checked when swank is first loaded and then the value is cached; I had to manually clear slime-lisp-implementations or restart emacs to fix it. Are you still having this problem? Shawn --~--~-~--~~~---~--~~ 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 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: filter1 interesting?
Anyone for "detect"? (detect odd? primes) --> 3 (detect even? primes) --> 2 (detect even? (rest primes)) --> runs forever (detect even? (rest one-million-primes)) --> nil On Mar 16, 10:51 am, Laurent PETIT wrote: > Just to make me more enemies ;-), I would prefer, on the other hand, > find-first over ffirst (I'm not that nostalgic of some Common Lisp-like > abbreviations :-) > > No, really, ffirst is just 3 characters shorter than find-first, and looks > like a typo at first glance. > > -- > Laurent > > 2009/3/16 André Thieme > > > > > > > On 16 Mrz., 13:14, Rich Hickey wrote: > > > On Mar 14, 11:26 am, Stuart Sierra > > > wrote: > > > > > I've added a "seek" function to clojure.contrib.seq-utils: > > > > > (defn seek > > > > "Returns the first item of coll for which (pred item) returns > > > > logical true. > > > > Consumes sequences up to the first match, will consume the entire > > > > sequence > > > > and return nil if no match is found." > > > > [pred coll] > > > > (first (filter pred coll))) > > > > Sorry to jump in late, but one problem with seek is that it is a > > > homophone of seq. > > > > Did anyone consider ffilter or find-first? > > > In that case I would vote for ffilter. --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
On Mar 16, 10:43 am, Konrad Hinsen wrote: > Yes. Clojure checks that symbols are defined before they are used. > You can put > > (declare check-services) > > before your definition of main to define the symbol and make it clear > to the (human) reader that you indeed to give the real definition later. IMHO, this is a no-no for interactive development. I understand that it helps avoiding undefined symbols, but such code integrity checks could be delayed to a final compilation stage. Having them earlier forces you to develop code in a bottom-up way. --~--~-~--~~~---~--~~ 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 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: filter1 interesting?
One of the nice things about overloading first is you could always just tell people that the one argument version of first is like saying: (first identity coll) even though the actual implementation wouldn't need to bother with it. The problem comes when you consider if we have a predicate-first, then people will start wanting other functions that do the same thing. Is (ffirst even? coll) the same as (first even? (first coll)) or (first (first even? coll)) what about (rest even? coll) ? Despite all these issues, I still like the idea of a predicate-first. On Mon, Mar 16, 2009 at 1:07 PM, e wrote: > Rich didn't chime in about the overload of 'first', which probably means > that's out. find-first is better than ffirst, but it's not really accurate, > IMO. You don't have to "find" it. it's just the first one for which the > predicate is true. (get-first ... ) has one less letter than (find-first > ...) but there's probably some other problem with that. (first ...) is the > most genius to me if you step back from historical ties ... and newbies like > me have the best chance of discovering it. But keep in mind, I'm just > casually following the discussions right now -- not working in clojure at > the moment. > > On Mon, Mar 16, 2009 at 10:51 AM, Laurent PETIT > wrote: >> >> Just to make me more enemies ;-), I would prefer, on the other hand, >> find-first over ffirst (I'm not that nostalgic of some Common Lisp-like >> abbreviations :-) >> >> No, really, ffirst is just 3 characters shorter than find-first, and looks >> like a typo at first glance. >> >> -- >> Laurent >> >> 2009/3/16 André Thieme >>> >>> On 16 Mrz., 13:14, Rich Hickey wrote: >>> > On Mar 14, 11:26 am, Stuart Sierra >>> > wrote: >>> > >>> > > I've added a "seek" function to clojure.contrib.seq-utils: >>> > >>> > > (defn seek >>> > > "Returns the first item of coll for which (pred item) returns >>> > > logical true. >>> > > Consumes sequences up to the first match, will consume the entire >>> > > sequence >>> > > and return nil if no match is found." >>> > > [pred coll] >>> > > (first (filter pred coll))) >>> > >>> > Sorry to jump in late, but one problem with seek is that it is a >>> > homophone of seq. >>> > >>> > Did anyone consider ffilter or find-first? >>> >>> In that case I would vote for ffilter. >>> >> >> >> >> >> > > > > > --~--~-~--~~~---~--~~ 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 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: filter1 interesting?
On Mon, Mar 16, 2009 at 1:38 PM, Daniel Renfer wrote: > > One of the nice things about overloading first is you could always > just tell people that the one argument version of first is like > saying: (first identity coll) even though the actual implementation > wouldn't need to bother with it. I'm afaid not. If a new 'first' were to act like (first (filter pred coll)), then the new 'first' could currently be written: (first (filter identity '(nil 1 2))) ==> 1 You can see where I'm headed: (first '(nil 1 2)) ==> nil Thus for some coll, the new (first coll) would *not* be the same as (first identity coll). --Chouser --~--~-~--~~~---~--~~ 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 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: Promise for absense of side effects
Hi, Am 16.03.2009 um 12:26 schrieb Robert Pfeiffer: Did you mean this: http://wiki.jvmlangsummit.com/pdf/28_Siek_gradual.pdf It was presented at the JVM Summit, so Rich may already have given a thought to this. Argh.. "Gradual Typing" that was term I was missing. Here some more information. The Paper (and a unsurprisingly negative discussion) on LtU: http://lambda-the-ultimate.org/node/1707 And the video of the talk from the above link. http://video.google.com/videoplay?docid=21835070615692553 I don't know, whether this is useful or not, but if we really want an optional type system, we should investigate the possibilities, I think. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: swank-clojure-extra-classpaths troubles
Shawn Hoover writes: Hi Shawn, >> user> (require 'examples.introduction) >> >> I get this exception: >> >> , >> | java.io.FileNotFoundException: Could not locate \ >> | examples/introduction__init.class or \ >> | examples/introduction.clj on classpath: (NO_SOURCE_FILE:0) >> | [Thrown class clojure.lang.Compiler$CompilerException] >> ` >> >> When I use the repl.sh script that comes with the examples and start >> it from /home/horn/repos/programming-clojure/ it works (. is in the >> -cp argument), but I guess that's exactly what those extra classpaths >> of clojure-swank are meant for. >> >> Is this a bug in swank-clojure? (And if so, is that the right place >> to ask for help with clojure tool support anyway?) > > I was able to reproduce this on my Windows box when I tried hacking in > an extra classpath to an already-running emacs that had already > started slime. It turns out the extra classpaths are only checked > when swank is first loaded and then the value is cached; I had to > manually clear slime-lisp-implementations or restart emacs to fix it. > > Are you still having this problem? Yes, for me having directories in `swank-clojure-extra-classpaths' doesn't work at all. Everything except jar files are discarded. So that's the general problem for me, the examples are one specific case which bites me. Bye, Tassilo --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
Hi, Am 16.03.2009 um 18:36 schrieb Elena: IMHO, this is a no-no for interactive development. I understand that it helps avoiding undefined symbols, but such code integrity checks could be delayed to a final compilation stage. Having them earlier forces you to develop code in a bottom-up way. I don't think so. I start with a function. *hackhackhack* Then I realise, that some part should be extracted into a helper function, eg. to share code with third function. Then it is matter of convention of the local project, whether this helper function is place in front or after the other functions combined with a declare. I use a top-down approach all the time and it works pretty well in Clojure. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Symbols evaluated at compile time?
I agree. It doesn't matter what order the compiler reads the definitions: I can scroll up and type. It does effect humans reading the code, however. Often when looking at unfamiliar Clojure code, I find myself scrolling to the bottom first. On Mon, Mar 16, 2009 at 1:58 PM, Meikel Brandmeyer wrote: > Hi, > > Am 16.03.2009 um 18:36 schrieb Elena: > > IMHO, this is a no-no for interactive development. I understand that >> it helps avoiding undefined symbols, but such code integrity checks >> could be delayed to a final compilation stage. Having them earlier >> forces you to develop code in a bottom-up way. >> > > I don't think so. I start with a function. *hackhackhack* > Then I realise, that some part should be extracted into > a helper function, eg. to share code with third function. > > Then it is matter of convention of the local project, whether > this helper function is place in front or after the other functions > combined with a declare. > > I use a top-down approach all the time and it works > pretty well in Clojure. > > 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 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: Symbols evaluated at compile time?
On 16 Mar, 20:14, Jeffrey Straszheim wrote: > It does effect humans reading the code, however. Often when looking at > unfamiliar Clojure code, I find myself scrolling to the bottom first. That's exactly my point: why should I scroll to the bottom? That's not the way I read a written page or report. Can you imagine a report which starts with the details instead of the more general picture? I think sometimes we warp ourselves to compensate for our tools deficiencies, whilst it should be the other way around. It is much easier for the compiler/interpreter to look ahead, isn't it? --~--~-~--~~~---~--~~ 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 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: filter1 interesting?
On Mar 16, 8:14 am, Rich Hickey wrote: > Sorry to jump in late, but one problem with seek is that it is a > homophone of seq. > > Did anyone consider ffilter or find-first? I thought "find-first" was too long, since it's almost as long as (first (filter ...) "ffilter" looks funny, especially in a proportional font. Others I considered: find1, filter1, select1, pick, detect, spot, hit, ... "pick" might be good. -Stuart Sierra --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
This has come up before. You can actually work around this (search the mailing list for declare) I think that when not hacking against the REPL that the default behavior is a good one. Having to use declare bugged me a little at first, but I now consider it a very minor annoyance compared to the advantages I get from programming interactively with Clojure. Should the REPL have an "interactive" mode where it won't fire an exception on undefined symbols and instead issue compiler warnings? If compiler warnings were issued this would be a nice hook for Emacs and other IDEs. David On Mon, Mar 16, 2009 at 3:32 PM, Elena wrote: > > On 16 Mar, 20:14, Jeffrey Straszheim > wrote: > > > It does effect humans reading the code, however. Often when looking at > > unfamiliar Clojure code, I find myself scrolling to the bottom first. > > That's exactly my point: why should I scroll to the bottom? That's not > the way I read a written page or report. Can you imagine a report > which starts with the details instead of the more general picture? I > think sometimes we warp ourselves to compensate for our tools > deficiencies, whilst it should be the other way around. It is much > easier for the compiler/interpreter to look ahead, isn't it? > > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
swank-clojure: init-files / classpath troubles solved (was: swank-clojure: swank-clojure-init-files not used)
Hi all, now I've solved my "swank-clojure doesn't use my extra classpath and init files" problems. This didn't work, cause I had something like this in my .emacs: --8<---cut here---start->8--- (add-to-list 'load-path "~/repos/el/swank-clojure") (setq swank-clojure-jar-path "~/repos/clj/clojure/clojure.jar") (require 'swank-clojure-autoload) (swank-clojure-config (add-to-list 'swank-clojure-extra-classpaths "~/repos/clj/programming-clojure/") (add-to-list 'swank-clojure-init-files (expand-file-name "~/.clojure/user.clj"))) --8<---cut here---end--->8--- The problem was, that in the required autoload file there's --8<---cut here---start->8--- (eval-after-load "slime" '(progn (require 'swank-clojure) (add-to-list 'slime-lisp-implementations `(clojure ,(swank-clojure-cmd) :init swank-clojure-init) t) (add-hook 'slime-indentation-update-hooks 'swank-clojure-update-indentation) (add-hook 'slime-repl-mode-hook 'swank-clojure-slime-repl-modify-syntax t) (add-hook 'clojure-mode-hook 'swank-clojure-slime-mode-hook t))) --8<---cut here---end--->8--- so after loading slime, the clojure command is build by calling `swank-clojure-cmd'. Unfortunately at slime load time the init files and extra classpaths weren't set, cause `swank-clojure-config' is only a wrapper around (eval-after-load "swank-clojure" ...). So for now I use --8<---cut here---start->8--- (add-to-list 'load-path "~/repos/el/swank-clojure") (setq swank-clojure-jar-path "~/repos/clj/clojure/clojure.jar") (eval-after-load 'swank-clojure '(progn (add-to-list 'swank-clojure-extra-classpaths "~/repos/clj/programming-clojure/") (add-to-list 'swank-clojure-init-files (expand-file-name "~/.clojure/user.clj" (require 'swank-clojure-autoload) --8<---cut here---end--->8--- which seems to work. It's absolutely necessary to require the autoload file after the eval-after-load! So I'd vote for removing the `swank-clojure-config' wrapper. It confuses more than it helps. Bye, Tassilo --~--~-~--~~~---~--~~ 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 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: filter1 interesting?
On 16 Mrz., 20:38, Stuart Sierra wrote: > On Mar 16, 8:14 am, Rich Hickey wrote: > > > Sorry to jump in late, but one problem with seek is that it is a > > homophone of seq. > > > Did anyone consider ffilter or find-first? > > I thought "find-first" was too long, since it's almost as long as > (first (filter ...) > > "ffilter" looks funny, especially in a proportional font. > > Others I considered: find1, filter1, select1, pick, detect, spot, > hit, ... > > "pick" might be good. Besides spot I like all of them, but I like pick and filter1 most out of those. pick is nice. Just lets not think for which word it is a homophone. :) --~--~-~--~~~---~--~~ 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 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 about profiling
I was trying to make an application go faster today when I found out that a Java program that does pretty much the same task was 8 times faster. I used the -Xrunhprof:cpu=times profiling flag to know where I should look, and the results are a little puzzling: CPU TIME (ms) BEGIN (total = 3334005) Mon Mar 16 15:26:26 2009 rank self accum count trace method 1 33.09% 33.09% 6 302294 java.lang.ref.ReferenceQueue.remove 2 33.09% 66.17% 3 302283 java.lang.Object.wait 3 1.11% 67.28% 4681282 304233 java.util.concurrent.atomic.AtomicInteger.get 4 1.05% 68.34% 1273366 326814 clojure.lang.Var.deref 5 0.82% 69.15% 162675 326831 starcraft.replay.parse $parse_buffer__65$fn__68.invoke 6 0.75% 69.90% 162710 326175 clojure.lang.APersistentVector.doEquals 7 0.67% 70.58% 1273672 325764 clojure.lang.Var.getThreadBinding 8 0.67% 71.24% 1273366 326815 clojure.lang.Var.get 9 0.54% 71.79% 650700 326818 clojure.core$nth__3505.invoke 10 0.50% 72.29% 650700 326817 clojure.lang.RT.nth 11 0.38% 72.67% 462044 326102 clojure.lang.Var.deref 12 0.37% 73.04% 162718 325793 clojure.lang.APersistentVector.hashCode 13 0.37% 73.40% 153954 326133 starcraft.replay.parse $read_field_aux__32.invoke 14 0.35% 73.75% 659541 312088 clojure.lang.Var.getThreadBinding 15 0.34% 74.09% 650840 326173 clojure.lang.APersistentVector $2.next 16 0.32% 74.41% 385545 312090 clojure.lang.Var.deref 17 0.30% 74.71% 1273672 325765 clojure.lang.Var.hasRoot 18 0.30% 75.01% 19608 327262 starcraft.replay.unpack $decode_command_block__93.invoke 19 0.27% 75.28% 517194 326100 clojure.lang.Var.getThreadBinding 20 0.26% 75.54% 488130 326171 clojure.lang.APersistentVector $2.hasNext Can anyone explain how 9 method calls can be responsible for 66% of my runtime and how I could avoid this overhead? The AtomicInteger.get also intrigues me. My code is available at the following address if you need to see it: http://bitbucket.org/gnuvince/clj-starcraft/src/ Thank you, Vincent. --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
I also agree that I keep going first to the end of the file, searching the real function to launch or to reuse when reading new clojure code ... What I would be happy with is a way to have clojure not complain before the end of a "unit of compiled code". For the REPL, that would be somewhat similar to the current behavior : wait before the end of the expression to complain for undefined symbols. For files, that would be "wait until the end of the file before complaining for undefined symbols, and let me arrange the defs in any order I feel most readable without having to think about placing those (declare) calls". Now, I don't know if this is something easily feasible in the implementation ... -- Laurent 2009/3/16 Elena > > On 16 Mar, 20:14, Jeffrey Straszheim > wrote: > > > It does effect humans reading the code, however. Often when looking at > > unfamiliar Clojure code, I find myself scrolling to the bottom first. > > That's exactly my point: why should I scroll to the bottom? That's not > the way I read a written page or report. Can you imagine a report > which starts with the details instead of the more general picture? I > think sometimes we warp ourselves to compensate for our tools > deficiencies, whilst it should be the other way around. It is much > easier for the compiler/interpreter to look ahead, isn't it? > > > > --~--~-~--~~~---~--~~ 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 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: filter1 interesting?
On Mon, Mar 16, 2009 at 8:38 PM, Stuart Sierra wrote: > > On Mar 16, 8:14 am, Rich Hickey wrote: >> Sorry to jump in late, but one problem with seek is that it is a >> homophone of seq. >> >> Did anyone consider ffilter or find-first? > > I thought "find-first" was too long, since it's almost as long as > (first (filter ...) > > "ffilter" looks funny, especially in a proportional font. > > Others I considered: find1, filter1, select1, pick, detect, spot, > hit, ... While considering suffixed names, what about firstp as inspired by condp? I personally like how the "first" part makes it clear that we are returning a single thing, rather than a collection or seq, and that it is the one closest to the head - the one we are going to, well, find first. That said, as you might imagine, I rather like find-first myself. I don't think it is too much to type. I may be biased here, considering my non-american keyboard layout, but saving a parenthesis for filter is more of a win than a few alphabetic characters. To conclude, I would prefer find-first as I believe the clarity is worth the extra characters. > > "pick" might be good. > > -Stuart Sierra > > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ 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 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: swank-clojure-extra-classpaths troubles
On Mon, Mar 16, 2009 at 2:39 PM, Tassilo Horn wrote: > Yes, for me having directories in `swank-clojure-extra-classpaths' > doesn't work at all. Everything except jar files are discarded. So > that's the general problem for me, the examples are one specific case > which bites me. > > Bye, > Tassilo > Hmm, that is a new one to me. The only other things I can think of: 1. Inspect the value of slime-lisp-implementations (C-h v) and make sure the java command line options look like you expect, including the classpath directories you added and the path separator appropriate for your operating system. 2. Try it with and without the trailing / on your strings that add to swank-clojure-extra-classpaths. Both work on Windows, but I'm not sure if other file systems are picky about that. Shawn --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
I may be missing something, but how does having to (declare) vars fix typos? I don't think anyone is suggesting *creating* a var that is referenced before it is defined. What people are asking for is that the compiler looks-ahead to verify that the var will eventually be defined, and then go on its merry way. Typos would still be discovered, and people wouldn't have to stop and (declare). I'm not saying it's an easy change... Paul On Mon, Mar 16, 2009 at 3:45 PM, David Nolen wrote: > This has come up before. You can actually work around this (search the > mailing list for declare) > I think that when not hacking against the REPL that the default behavior is > a good one. Having to use declare bugged me a little at first, but I now > consider it a very minor annoyance compared to the advantages I get from > programming interactively with Clojure. > Should the REPL have an "interactive" mode where it won't fire an exception > on undefined symbols and instead issue compiler warnings? If compiler > warnings were issued this would be a nice hook for Emacs and other IDEs. > 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 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: mocking in clojure
On Mar 13, 3:35 pm, "Stephen C. Gilardi" wrote: > On Mar 13, 2009, at 4:10 PM, Stuart Sierra wrote: > > > Hi Allen, > > Sorry I haven't kept up with this. I think, though, that it's best to > > have it as a standalone library in clojure-contrib, so that people can > > use it with other testing frameworks if they want to. > > -Stuart > > Allen, > > I see you have a contributor agreement on file. I'll be happy to help > check this in if you like. Please open an issue at: > > http://code.google.com/p/clojure-contrib/issues/list > > and attach a patch to it that creates the new lib. > > Thanks, > > --Steve > > smime.p7s > 3KViewDownload Thanks for the suggestions. I'll set up a separate project soon. One of the reasons I originally wrote this as a patch on test-is was to get integration with the is assert and reporting functionality. I guess than can be separated into a backend part and an interface to the different testing frameworks fairly easily though. Allen --~--~-~--~~~---~--~~ 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 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: suggestion for resultset-seq and duplicate column names
On Mar 12, 1:32 pm, Ron Lusk wrote: > Works for me: I just overwrote my copy of resultset-seq with one that > uses getColumnLabel, and I am now getting the results I expected from > complex queries (in Interbase, at least). > > On Feb 23, 9:33 am, Rich Hickey wrote: > > > Sounds good to me - any drawbacks to this? Does it require that the > > columns be named explicitly? > > > Rich The change to getColumnLabel sounds good. Just one word of warning. The reason the exception is there is that if the columns are still duplicates, the call to struct-map will explode with an exception that is not very obvious. (After writing that sentence, I realize that maybe the better solution is to patch struct-map to complain with an good error message). I wrote the original patch to throw an exception in order to make the failure more obvious. Any change should handle failure gracefully. Allen --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
On Mon, Mar 16, 2009 at 4:08 PM, Paul Stadig wrote: > I may be missing something, but how does having to (declare) vars fix > typos? I don't think anyone is suggesting *creating* a var that is > referenced before it is defined. What people are asking for is that the > compiler looks-ahead to verify that the var will eventually be defined, and > then go on its merry way. Typos would still be discovered, and people > wouldn't have to stop and (declare). > Yeah I wasn't suggesting that vars should be created, sorry if it sounded like I was (I mentioned declare because this came up in another thread about declare and someone had hacked the reader to not bail immediately on undefined symbols). In CL, if you have definitions out of order in the compiler will issue warnings. > > I'm not saying it's an easy change... > > > Paul > > On Mon, Mar 16, 2009 at 3:45 PM, David Nolen wrote: > >> This has come up before. You can actually work around this (search the >> mailing list for declare) >> I think that when not hacking against the REPL that the default behavior >> is a good one. Having to use declare bugged me a little at first, but I now >> consider it a very minor annoyance compared to the advantages I get from >> programming interactively with Clojure. >> Should the REPL have an "interactive" mode where it won't fire an >> exception on undefined symbols and instead issue compiler warnings? If >> compiler warnings were issued this would be a nice hook for Emacs and other >> IDEs. >> 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 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: Symbols evaluated at compile time?
On 16 Mar, 20:45, David Nolen wrote: > This has come up before. You can actually work around this (search the > mailing list for declare) I've searched the mailing list and I've found also an explanation by Rich Hickey (I apologize for not having done it in the first instance) for such a design decision. I agree that allowing undefined symbols would lead to runtime errors. I'm only complaining about applying such sanity checks in the REPL, when I'm drawing a sketch. > Should the REPL have an "interactive" mode where it won't fire an exception > on undefined symbols and instead issue compiler warnings? If compiler > warnings were issued this would be a nice hook for Emacs and other IDEs. I think that would be ideal: if you intended to leave a symbol undefined, that warning would come expected, otherwise you'd know you had just made a typo. --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
On 16 Mar, 20:58, Laurent PETIT wrote: > For files, that would be "wait until the end of the file before complaining > for undefined symbols, and let me arrange the defs in any order I feel most > readable without having to think about placing those (declare) calls". I second your proposal. --~--~-~--~~~---~--~~ 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 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: Which Java book(s) to order
Of course, with respect to Clojure, probably the most important thing is to learn the Java *libraries*. What are good books about that? --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
On Mon, Mar 16, 2009 at 4:18 PM, David Nolen wrote: > On Mon, Mar 16, 2009 at 4:08 PM, Paul Stadig wrote: > >> I may be missing something, but how does having to (declare) vars fix >> typos? I don't think anyone is suggesting *creating* a var that is >> referenced before it is defined. What people are asking for is that the >> compiler looks-ahead to verify that the var will eventually be defined, and >> then go on its merry way. Typos would still be discovered, and people >> wouldn't have to stop and (declare). >> > > Yeah I wasn't suggesting that vars should be created, sorry if it sounded > like I was (I mentioned declare because this came up in another thread about > declare and someone had hacked the reader to not bail immediately on > undefined symbols). > Sorry, my fault. I was just responding in general, not to you specifically. > > In CL, if you have definitions out of order in the compiler will issue > warnings. > > >> >> I'm not saying it's an easy change... >> >> >> Paul >> > Could someone post the link to the previous discussion? I searched the group for declare, but didn't turn up anything. Paul --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
On Mon, Mar 16, 2009 at 9:26 PM, Elena wrote: > > On 16 Mar, 20:58, Laurent PETIT wrote: > >> For files, that would be "wait until the end of the file before complaining >> for undefined symbols, and let me arrange the defs in any order I feel most >> readable without having to think about placing those (declare) calls". > > I second your proposal. Otherwise, for the purpose of bringing a counter argument, I find that functions naturally group together by their level of abstraction, with the lowest level of abstraction at the top and the highest at the bottom. Considering this, I will boldly claim it usually is not that difficult to put these groups in their own lib. We could, perhaps, consider it a sign (for avoiding the word "smell") that a new lib should be defined? Then, as now, we can let "declare" handle the cases where this isn't true. > > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ 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 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: swank-clojure-extra-classpaths troubles
Shawn Hoover writes: > Hmm, that is a new one to me. The only other things I can think of: > >1. Inspect the value of slime-lisp-implementations (C-h v) and make >sure the java command line options look like you expect, including >the classpath directories you added and the path separator >appropriate for your operating system. That helped me, and now the issue is solved, see <87fxhd2qte@thinkpad.tsdh.de>. Bye, Tassilo -- In a fight between Batman and Darth Vader, the winner would be Chuck Norris. --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
Here's the post by Timothy talking about patching the compiler: http://groups.google.com/group/clojure/msg/ef5bae605f4a0730 On Mon, Mar 16, 2009 at 4:36 PM, Paul Stadig wrote: > On Mon, Mar 16, 2009 at 4:18 PM, David Nolen wrote: > >> On Mon, Mar 16, 2009 at 4:08 PM, Paul Stadig wrote: >> >>> I may be missing something, but how does having to (declare) vars fix >>> typos? I don't think anyone is suggesting *creating* a var that is >>> referenced before it is defined. What people are asking for is that the >>> compiler looks-ahead to verify that the var will eventually be defined, and >>> then go on its merry way. Typos would still be discovered, and people >>> wouldn't have to stop and (declare). >>> >> >> Yeah I wasn't suggesting that vars should be created, sorry if it sounded >> like I was (I mentioned declare because this came up in another thread about >> declare and someone had hacked the reader to not bail immediately on >> undefined symbols). >> > > Sorry, my fault. I was just responding in general, not to you specifically. > > >> >> In CL, if you have definitions out of order in the compiler will issue >> warnings. >> >> >>> >>> I'm not saying it's an easy change... >>> >>> >>> Paul >>> >> > Could someone post the link to the previous discussion? I searched the > group for declare, but didn't turn up anything. > > > Paul > > > > > --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
Hello Christian, 2009/3/16 Christian Vest Hansen > > On Mon, Mar 16, 2009 at 9:26 PM, Elena wrote: > > > > On 16 Mar, 20:58, Laurent PETIT wrote: > > > >> For files, that would be "wait until the end of the file before > complaining > >> for undefined symbols, and let me arrange the defs in any order I feel > most > >> readable without having to think about placing those (declare) calls". > > > > I second your proposal. > > Otherwise, for the purpose of bringing a counter argument, I find that > functions naturally group together by their level of abstraction, with > the lowest level of abstraction at the top and the highest at the > bottom. > > Considering this, I will boldly claim it usually is not that difficult > to put these groups in their own lib. We could, perhaps, consider it a > sign (for avoiding the word "smell") that a new lib should be defined? > Then, as now, we can let "declare" handle the cases where this isn't > true. I agree that it's not difficult. But, at least in my own experience, it's not the second step to cleaning up my programs. I generally try to get code that works, even if in a not really good looking shape. Then I refactor if it is really ugly-looking, or when I see the possibility to factorize between several functions. So I end up with more general functions, but still, I'm not sure if they deserve their own lib. And maybe they're just general enough for the purpose of the functions of my current file. It's in a third time, when I want to share code between several namespaces, that libraries in their own namespace show up. So I think there's room for what I suggested, because the step to seperate functions into libs by a criteria of level of abstraction does not appear that fast in my programming cycle. > > > > > > > > > > > -- > Venlig hilsen / Kind regards, > Christian Vest Hansen. > > > > --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Box
On Mon, Mar 16, 2009 at 1:08 PM, Kyle R. Burton wrote: > > Clojure Box works well, I'd like to make a feature request: can you > add paredit [1]? Including it in the distribution (perhaps with it > disabled) would be great. > Good idea. It used to be packaged with clojure-mode automatically, but now it's not, and I haven't added paredit itself. I'll make sure it's in the next release, disabled so people don't freak out when C-d works differently than they expect. I think that and a link to your tumblr post should do the trick. > Thanks for putting it together. > You're welcome! Shawn --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
On 16 Mar, 21:57, Laurent PETIT wrote: > > I agree that it's not difficult. But, at least in my own experience, it's > not the second step to cleaning up my programs. > > I generally try to get code that works, even if in a not really good looking > shape. Then I refactor if it is really ugly-looking, or when I see the > possibility to factorize between several functions. > > So I end up with more general functions, but still, I'm not sure if they > deserve their own lib. And maybe they're just general enough for the purpose > of the functions of my current file. > > It's in a third time, when I want to share code between several namespaces, > that libraries in their own namespace show up. > > So I think there's room for what I suggested, because the step to seperate > functions into libs by a criteria of level of abstraction does not appear > that fast in my programming cycle. You have just described my way of churning out code for fast prototypes and ad-hoc programs. Abstractions and cleaning up come later, once I've understood the task at hand better. --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
2009/3/16 Elena > > > > On 16 Mar, 21:57, Laurent PETIT wrote: > > > > I agree that it's not difficult. But, at least in my own experience, it's > > not the second step to cleaning up my programs. > > > > I generally try to get code that works, even if in a not really good > looking > > shape. Then I refactor if it is really ugly-looking, or when I see the > > possibility to factorize between several functions. > > > > So I end up with more general functions, but still, I'm not sure if they > > deserve their own lib. And maybe they're just general enough for the > purpose > > of the functions of my current file. > > > > It's in a third time, when I want to share code between several > namespaces, > > that libraries in their own namespace show up. > > > > So I think there's room for what I suggested, because the step to > seperate > > functions into libs by a criteria of level of abstraction does not appear > > that fast in my programming cycle. > > You have just described my way of churning out code for fast > prototypes and ad-hoc programs. Abstractions and cleaning up come > later, once I've understood the task at hand better. Exactly. And nowdays, I often realize it's not just "understanding the task at hand" that makes me follow this "unformal process", but also the need/time to first become familiar with the third party lib/framework I'm willing to involve. And generally, those libs/frameworks are hard to grasp at first (at least if I want to not have just "read code" in a day of coding), so I think this notion of "understanding the task at hand" can be generalized not only to the task of "understanding my problem domain", but also to "understanding how to use the libs/frameworks that promise me a clean way of solving my problem domain" :-). > > > > --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
On 16 Mrz., 11:49, Elena wrote: > On Mar 16, 10:40 am, Christophe Grand wrote: > > > > > Yes, it prevents typos to go unnoticed. You can write a forward > > declaration : > > > (declare check-services); equivalent to (def check-services) > > > (defn main [] > > (check-services)) > > > (defn check-services [] > > 1) > > OK, thanks. I was expecting a behavior similar to Scheme (and maybe > Common Lisp). > > Doesn't that hampers interactive development? I mean: you have to > develop the program in a more controlled manner. Didn't you write only yesterday that you want to buy Lispworks? Speaking about it: When you define a gui (either manually or by using the builder), and then you want to add callbacks, you can not just say: :callback #'my-function and then later in that file actually implement my-function. It will complain that the definition is not yet known. So, at least in some cases this is also not possible in CL. Only today I found myself typing (decla...) in Lispworks, as I was thinking in Clojure. The behaviour of Clojure can be seen as a disadvantage, yes, because you either need these forward declarations, or you need to arrange functions different. But it also protects you from typos. And this can be even more important. Imagine you have a complex program and accidently made a typo, and this will go unnoticed for days and days, until the program actually runs your 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 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: Symbols evaluated at compile time?
Hi, Am 16.03.2009 um 22:19 schrieb Elena: On 16 Mar, 21:57, Laurent PETIT wrote: I agree that it's not difficult. But, at least in my own experience, it's not the second step to cleaning up my programs. I generally try to get code that works, even if in a not really good looking shape. Then I refactor if it is really ugly-looking, or when I see the possibility to factorize between several functions. So I end up with more general functions, but still, I'm not sure if they deserve their own lib. And maybe they're just general enough for the purpose of the functions of my current file. It's in a third time, when I want to share code between several namespaces, that libraries in their own namespace show up. So I think there's room for what I suggested, because the step to seperate functions into libs by a criteria of level of abstraction does not appear that fast in my programming cycle. You have just described my way of churning out code for fast prototypes and ad-hoc programs. Abstractions and cleaning up come later, once I've understood the task at hand better. Sometimes, I don't understand you guys. You claim that you have to develop bottom-up, when in fact you do top-down. I really don't see the problem with the current behaviour... Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Symbols evaluated at compile time?
2009/3/16 André Thieme > > On 16 Mrz., 11:49, Elena wrote: > > On Mar 16, 10:40 am, Christophe Grand wrote: > > > > > > > > > Yes, it prevents typos to go unnoticed. You can write a forward > > > declaration : > > > > > (declare check-services); equivalent to (def check-services) > > > > > (defn main [] > > > (check-services)) > > > > > (defn check-services [] > > > 1) > > > > OK, thanks. I was expecting a behavior similar to Scheme (and maybe > > Common Lisp). > > > > Doesn't that hampers interactive development? I mean: you have to > > develop the program in a more controlled manner. > > Didn't you write only yesterday that you want to buy Lispworks? > Speaking about it: > When you define a gui (either manually or by using the builder), > and then you want to add callbacks, you can not just say: > :callback #'my-function and then later in that file actually > implement my-function. It will complain that the definition is not > yet known. So, at least in some cases this is also not possible > in CL. > Only today I found myself typing (decla...) in Lispworks, as I > was thinking in Clojure. > > The behaviour of Clojure can be seen as a disadvantage, yes, because > you either need these forward declarations, or you need to arrange > functions different. > But it also protects you from typos. And this can be even more > important. Imagine you have a complex program and accidently > made a typo, and this will go unnoticed for days and days, until > the program actually runs your code... Hello André, Have you read my suggestion of keeping the fact to throw an exception on undefined symbols, but deferring the conclusion until the end of the currently compiled/loaded "unit of code" (a single expression in the REPL, a whole file in a compilation step ...) ? I'd be interesting to understand what drawbacks this suggestion, if even realized, would have ? > > > > --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
André Thieme writes: > But it also protects you from typos. And this can be even more > important. Imagine you have a complex program and accidently > made a typo, and this will go unnoticed for days and days, until > the program actually runs your code... If you go days and days without actually running your code, then you deserve what you get. A test suite would catch this for you every time; developing without one is irresponsible. -Phil --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Symbols evaluated at compile time?
> If you go days and days without actually running your code, then you > deserve what you get. A test suite would catch this for you every time; > developing without one is irresponsible. geeze people, i'm tired of the "tests are the answer to everything." give it a break. not every test suite will be perfect from day one, and what i wrong with defense in depth? said by a person who likes statically typed, inferred, languages. :-) --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
2009/3/16 Meikel Brandmeyer > Hi, > > Am 16.03.2009 um 22:19 schrieb Elena: > > On 16 Mar, 21:57, Laurent PETIT wrote: >> >>> >>> I agree that it's not difficult. But, at least in my own experience, it's >>> not the second step to cleaning up my programs. >>> >>> I generally try to get code that works, even if in a not really good >>> looking >>> shape. Then I refactor if it is really ugly-looking, or when I see the >>> possibility to factorize between several functions. >>> >>> So I end up with more general functions, but still, I'm not sure if they >>> deserve their own lib. And maybe they're just general enough for the >>> purpose >>> of the functions of my current file. >>> >>> It's in a third time, when I want to share code between several >>> namespaces, >>> that libraries in their own namespace show up. >>> >>> So I think there's room for what I suggested, because the step to >>> seperate >>> functions into libs by a criteria of level of abstraction does not appear >>> that fast in my programming cycle. >>> >> >> You have just described my way of churning out code for fast >> prototypes and ad-hoc programs. Abstractions and cleaning up come >> later, once I've understood the task at hand better. >> > > Sometimes, I don't understand you guys. You claim that you have > to develop bottom-up, when in fact you do top-down. I really don't > see the problem with the current behaviour... Hello Meikel, In french, we have a sentence for that, that would translate literally into "eat the banana by both ends at the same time". I don't think top-down and bottom-up programming are antogonists. I often do both at the same time myself. > > > 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 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: Symbols evaluated at compile time?
Hi, Am 16.03.2009 um 22:44 schrieb Laurent PETIT: In french, we have a sentence for that, that would translate literally into "eat the banana by both ends at the same time". I don't think top-down and bottom-up programming are antogonists. I often do both at the same time myself. According to Paul Graham, this is a one aspect of Lisp: working both ways at the same time. Top-down for the program logic and bottom-up by building small helpers and macros. My remark was pointed at the fact, that before it was claimed, that the one way doesn't work in Clojure and one has to go the other. And then the same person goes on to contradict him(or her?)self. But be it... To say something more constructive for the discussion: here Rich's original answer on the matter: http://groups.google.com/group/clojure/browse_frm/thread/c3418875208d89e1/0f5b80483329c151?lnk=gst&q=declare+rich+hickey#0f5b80483329c151 Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
advice needed converting large files to xml
I've been using Clojure for about 6 months now and really like it. I am somewhat new to multi-threading and using any of the parallel features in Clojure though. I have a situation where I need to convert 7 files from CSV to XML. Each one of these files is about 180MB apiece in size. I have dual core machine with 2GB of RAM and would like some advice on the best strategy for processing these files in a way that really utilizes both cores and my memory to really speed up the processing.I'm sure this isn't the best way, but I've only come up with starting up two threads at first, having each thread open up a file, call line-seq on that file, write out the XML for each line and then go to the next file when it's complete. Any advice would be great. Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Symbols evaluated at compile time?
2009/3/16 Phil Hagelberg > > André Thieme writes: > > > But it also protects you from typos. And this can be even more > > important. Imagine you have a complex program and accidently > > made a typo, and this will go unnoticed for days and days, until > > the program actually runs your code... > > If you go days and days without actually running your code, then you > deserve what you get. A test suite would catch this for you every time; > developing without one is irresponsible. OK, so now is time for another ugly english translation of a french proverb "before saying something, roll your tongue 8 times in your mouth before speaking". I guess this could also be applied for e-mail :-) Seriously, treating a very large audience of people as "irresponsible" (including Rich himself, the author of clojure) does not seem a very "responsible" behavior, does it ? :-) In fact, I'm ok when you say that " deserve what you get". But please, think about it twice before saying people are irresponsible. Unit tests are not the only answer to bug-free and quality programs. Quality and correctness is a discipline in its own right, including tests (unit tests, integration tests, functional tests, performance tests, ...), reviews (code review, peer review, architecture review, ...). Not to say that a lot of bugs are not in the code, but in the specifications (be they formal as in watefall processes, or informal as in agile processes), ..., And please note that when talking about tests, I did not tell if they had to be automatic or not. I think that it's not a natural conclusion to say that tests must be automated. To me, it's rather a cost/benefits balance that must leads to the conclusion that automatic unit tests are good or not for your project. My answer had not the intent to offense you, but I couldn't let you write that without reaction, because I'm myself very interested in automatic unit tests, and I think that such intransigent thoughts deserve the cause. Regards, -- Laurent > > > -Phil > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Symbols evaluated at compile time?
On 16 Mar, 22:31, André Thieme wrote: > The behaviour of Clojure can be seen as a disadvantage, yes, because > you either need these forward declarations, or you need to arrange > functions different. > But it also protects you from typos. And this can be even more > important. Imagine you have a complex program and accidently > made a typo, and this will go unnoticed for days and days, until > the program actually runs your code... I agree that such checks are very useful, but: - why should you wrestle with them also when you are just sketching out some code at the REPL? Much of the code you are writing is going to be trashed, so why should you bother keeping up with declarations dependencies? - why, when you finally save the source file as a module and and compile it, the compiler should not be smart enough to read every definition until the end of the file before complaining? Your needs change when you are sketching a prototype versus when you are finalizing the project. Don't you agree? --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
On 16 Mrz., 20:45, David Nolen wrote: > Should the REPL have an "interactive" mode where it won't fire an exception > on undefined symbols and instead issue compiler warnings? If compiler > warnings were issued this would be a nice hook for Emacs and other IDEs. Yes, I was thinking about this also for a while. What I propose is: Whenever Clojure finds the use of a not known symbol in a code file, it will always look ahead and see if it can find this symbol. If that is not the case an error should be thrown, as it currently happens. If it can find the concrete definition it should emit a warning. The way to silence the warning is to declare that symbol before. This behaviour would not disturb anyone who likes the current system. Typos will not go unnoticed, the dev will see that warning. He/She can add the declare as usual. Others can continue from that point and have to live with that warning, but enjoy the protection from a class of typos and also be able to arrange their code in a different way and spare these declares. --~--~-~--~~~---~--~~ 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 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: advice needed converting large files to xml
If you write your CSV -> XML processing as a function, you could pmap ( http://clojure.org/api#pmap) that function across the list of input files. pmap will transparently create the threads as needed, and it will probably be enough to saturate your disk. Thanks, Stu On Mon, Mar 16, 2009 at 5:56 PM, Brian Doyle wrote: > I've been using Clojure for about 6 months now and really like it. I am > somewhat new to multi-threading > and using any of the parallel features in Clojure though. I have a > situation where I need to convert > 7 files from CSV to XML. Each one of these files is about 180MB apiece in > size. I have dual core machine > with 2GB of RAM and would like some advice on the best strategy for > processing these files in a way that > really utilizes both cores and my memory to really speed up the > processing.I'm sure this isn't the best > way, but I've only come up with starting up two threads at first, having > each thread open up a file, > call line-seq on that file, write out the XML for each line and then go to > the next file when it's complete. Any > advice would be great. Thanks. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Symbols evaluated at compile time?
Just FYI, The actual patch is in the files section: http://groups.google.com/group/clojure/web/auto-def.patch With an example: http://groups.google.com/group/clojure/web/lit-wc.clj >From a longer thread about 'snake' which talked about literate programming: http://groups.google.com/group/clojure/browse_thread/thread/2a23a95bf22938a3 It does not implement existence checking upon completion of compile unit. How exactly should this work? We can keep a set of symbols auto- defined and 'at checkpoint' test if they are still undefined... however what is the 'checkpoint'? For fully compiled code the 'checkpoint' is clear - but Clojure is dynamic... what should happen with this code: (defn myfun [] (another-fun 5)) (myfun) (defn another-fun [x] (inc x)) In a compiled language that would be valid, but in a dynamic language it is a runtime error. I don't see how to overcome this, which makes auto-def quite useless :) It seems you either need to accept top-down or accept undefined symbol runtime errors. There is a third alternative, which is to use Knuth's literate programming technique of actually writing your code in TeX and have it transformed from there to either code or documentation... but again for interactive development that is quite rigorous. Regards, Tim. On Mar 17, 7:54 am, David Nolen wrote: > Here's the post by Timothy talking about patching the compiler: > > http://groups.google.com/group/clojure/msg/ef5bae605f4a0730 > > On Mon, Mar 16, 2009 at 4:36 PM, Paul Stadig wrote: > > On Mon, Mar 16, 2009 at 4:18 PM, David Nolen wrote: > > >> On Mon, Mar 16, 2009 at 4:08 PM, Paul Stadig wrote: > > >>> I may be missing something, but how does having to (declare) vars fix > >>> typos? I don't think anyone is suggesting *creating* a var that is > >>> referenced before it is defined. What people are asking for is that the > >>> compiler looks-ahead to verify that the var will eventually be defined, > >>> and > >>> then go on its merry way. Typos would still be discovered, and people > >>> wouldn't have to stop and (declare). > > >> Yeah I wasn't suggesting that vars should be created, sorry if it sounded > >> like I was (I mentioned declare because this came up in another thread > >> about > >> declare and someone had hacked the reader to not bail immediately on > >> undefined symbols). > > > Sorry, my fault. I was just responding in general, not to you specifically. > > >> In CL, if you have definitions out of order in the compiler will issue > >> warnings. > > >>> I'm not saying it's an easy change... > > >>> Paul > > > Could someone post the link to the previous discussion? I searched the > > group for declare, but didn't turn up anything. > > > Paul --~--~-~--~~~---~--~~ 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 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: advice needed converting large files to xml
On Mon, Mar 16, 2009 at 4:56 PM, Brian Doyle wrote: > I've been using Clojure for about 6 months now and really like it. I am > somewhat new to multi-threading > and using any of the parallel features in Clojure though. I have a > situation where I need to convert > 7 files from CSV to XML. Each one of these files is about 180MB apiece in > size. I have dual core machine > with 2GB of RAM and would like some advice on the best strategy for > processing these files in a way that > really utilizes both cores and my memory to really speed up the > processing. I'm sure this isn't the best > way, but I've only come up with starting up two threads at first, having > each thread open up a file, > call line-seq on that file, write out the XML for each line and then go to > the next file when it's complete. Any > advice would be great. Thanks. Most libraries that write XML build a data structure to represent the XML and then write it out. That doesn't work for writing out large XML documents because you'll run out of memory before you finish building the data structure. I don't know if there is a Clojure library that writes XML as you specify it. If there isn't then you should consider WAX, a Java library I wrote. You can learn more about it at http://ociweb.com/wax/. You could use it from Clojure. Check out the tutorial. It's a really simple library, it's really fast and it's very memory efficient! -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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: Promise for absense of side effects
On 16 Mrz., 19:43, Meikel Brandmeyer wrote: > Am 16.03.2009 um 12:26 schrieb Robert Pfeiffer: > > > Did you mean this: > > >http://wiki.jvmlangsummit.com/pdf/28_Siek_gradual.pdf > > > It was presented at the JVM Summit, so Rich may already have given a > > thought to this. > > Argh.. "Gradual Typing" that was term I was missing. > > Here some more information. > > The Paper (and a unsurprisingly negative discussion) on > LtU:http://lambda-the-ultimate.org/node/1707 > > And the video of the talk from the above > link.http://video.google.com/videoplay?docid=21835070615692553 > > I don't know, whether this is useful or not, but if we really want > an optional type system, we should investigate the possibilities, > I think. Oh, that sounds really useful. This is in principle very close to what I was had in mind in the past years. The paper says: “The type system and semantics should place a minimal implementation burden on language implementors.” And that also sounds like a good thing. What I would love to see is an optional system. With such even hardcore fans of dynamic typing should not have any problem with it, if Clojure is going to have one. A thing that should be easy to add is a on/off switch. Maybe a global one, and a file based one. Perhaps this gradual typing even allows a gradual implementation. Would be a nice productivity boost to have the compiler checking parts of our code during some phases of development. --~--~-~--~~~---~--~~ 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 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: Promise for absense of side effects
please, for those who aren't Erlang nerds, also see Dialyzer. http://www.it.uu.se/research/group/hipe/dialyzer --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
Laurent PETIT writes: > OK, so now is time for another ugly english translation of a french > proverb "before saying something, roll your tongue 8 times in your > mouth before speaking". I guess this could also be applied for e-mail Agreed, it could have been worded better. But keep in mind the context: it was suggested that certain problems would go unnoticed for days because the code was loaded never run. I think this is not a concern; you might as well say these problems could go unnoticed because the code is never loaded. > Seriously, treating a very large audience of people as "irresponsible" > (including Rich himself, the author of clojure) does not seem a very > "responsible" behavior, does it ? :-) Clojure has a test suite. It lives in contrib. Bugs in Clojure have been committed even though they were entirely avoidable, simply because the test suite wasn't being used. This strikes me as an irresponsible development practice. It's not horrible, but it wastes peoples' time. > But please, think about it twice before saying people are > irresponsible. Unit tests are not the only answer to bug-free and > quality programs. Sure, I don't mean that this reflects on peoples' character. I only wish to judge the practice, not the practitioner. But for things like clojure, the alternative is to perform those same tests manually. I don't think it's a good use of humans' time to perform tasks that could be easily done by a machine. > And please note that when talking about tests, I did not tell if they > had to be automatic or not. I think that it's not a natural conclusion > to say that tests must be automated. To me, it's rather a > cost/benefits balance that must leads to the conclusion that automatic > unit tests are good or not for your project. That's true; certain types of programs (particularly GUIs and JS-heavy cross-browser web applications) are extremely difficult to automate tests for. But this is the exception rather than the rule. -Phil --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Symbols evaluated at compile time?
On 16 Mar, 22:55, Meikel Brandmeyer wrote: > My remark was pointed at the fact, that before it was > claimed, that the one way doesn't work in Clojure and > one has to go the other. And then the same person > goes on to contradict him(or her?)self. But be it... > > To say something more constructive for the discussion: > here Rich's original answer on the matter: > > http://groups.google.com/group/clojure/browse_frm/thread/c3418875208d... I bet it's me the "him(or her?)self" :-) I had already read Rich's opinion, after searching about old threads about the subject. I think he made a very reasonable decision, but he was talking about production code. What we are discussing here is the usefulness of such constraints when just playing at the REPL, a very different environment. Among the many answers, a (IMHO) reasonable solution has been proposed, which I repeat here: - the REPL could allow for an option to just warn about missing definitions; - when loading/compiling a file, Clojure could parse all definitions before complaining about missing ones. It seems that such a solution would offer both maximum flexibility when prototyping and maximum sanity checking when finalizing the code. What do you think? --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
2009/3/16 Phil Hagelberg > > Laurent PETIT writes: > > > But please, think about it twice before saying people are > > irresponsible. Unit tests are not the only answer to bug-free and > > quality programs. > > Sure, I don't mean that this reflects on peoples' character. I only wish > to judge the practice, not the practitioner. You're right, I took a judgement on a behaviour for a judgement on persons, sorry for that. I hope you didn't find my own answer too rude, Regards, -- Laurent --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
On 16 Mar, 23:26, Timothy Pratley wrote: > For fully compiled code the > 'checkpoint' is clear - but Clojure is dynamic... what should happen > with this code: > > (defn myfun [] > (another-fun 5)) > (myfun) > (defn another-fun [x] > (inc x)) > > In a compiled language that would be valid, but in a dynamic language > it is a runtime error. I don't see how to overcome this, which makes > auto-def quite useless :) I think this should be a runtime error. What we are discussing here is in: (defn myfun [] (another-fun 5)) (defn another-fun [x] (inc x)) "myfun" definition is rejected, even if "another-fun" is just few lines away. --~--~-~--~~~---~--~~ 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 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: advice needed converting large files to xml
On Mon, Mar 16, 2009 at 4:21 PM, Stu Hood wrote: > If you write your CSV -> XML processing as a function, you could pmap ( > http://clojure.org/api#pmap) that function across the list of input > files. pmap will transparently create the threads as needed, and it will > probably be enough to saturate your disk. > > Thanks, > Stu > Stu, I just want to make sure I understand what you are saying here. Would it look something like this: (pmap (fn [input-file] ; open input for reading ; open output for writing ; read line ; process line ; write line ) ["input-file1", "input-file2", "input-file3", ]) Thanks. > > > On Mon, Mar 16, 2009 at 5:56 PM, Brian Doyle wrote: > >> I've been using Clojure for about 6 months now and really like it. I am >> somewhat new to multi-threading >> and using any of the parallel features in Clojure though. I have a >> situation where I need to convert >> 7 files from CSV to XML. Each one of these files is about 180MB apiece in >> size. I have dual core machine >> with 2GB of RAM and would like some advice on the best strategy for >> processing these files in a way that >> really utilizes both cores and my memory to really speed up the >> processing.I'm sure this isn't the best >> way, but I've only come up with starting up two threads at first, having >> each thread open up a file, >> call line-seq on that file, write out the XML for each line and then go to >> the next file when it's complete. Any >> advice would be great. Thanks. >> >> >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
Behavior of 'empty'
Hello Rich & all! I am digging into behavior of function 'empty': user=> (doc empty) - clojure.core/empty ([coll]) Returns an empty collection of the same category as coll, or nil (empty [1 2]) => [] (empty (seq [1 2])) => nil (empty '(1 2)) => () (empty (seq '(1 2))) => () ; ok because of: (seq '(1 2)) => (1 2) (class (seq '(1 2))) => clojure.lang.PersistentList (class '(1 2)) => clojure.lang.PersistentList One trouble is with nil: (empty nil) => java.lang.NullPointerException (NO_SOURCE_FILE:0) Would it make sense to return nil? (empty nil) => nil Thank you, Frantisek --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
Laurent PETIT writes: > 2009/3/16 Phil Hagelberg > > Laurent PETIT writes: > > > But please, think about it twice before saying people are > > irresponsible. Unit tests are not the only answer to bug-free and > > quality programs. > > Sure, I don't mean that this reflects on peoples' character. I only wish > to judge the practice, not the practitioner. > > You're right, I took a judgement on a behaviour for a judgement on persons, > sorry for that. > > I hope you didn't find my own answer too rude, Not at all. The latter is far more common, especially in online discussions. And to say that people deserve the problems that come upon them, that was harsh of me. I rather should have said that they should expect to have problems like that. -Phil --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Symbols evaluated at compile time?
On 16 Mar, 23:47, Elena wrote: > On 16 Mar, 23:26, Timothy Pratley wrote: > > what should happen > > with this code: > > > (defn myfun [] > > (another-fun 5)) > > (myfun) > > (defn another-fun [x] > > (inc x)) > > > In a compiled language that would be valid, but in a dynamic language > > it is a runtime error. I don't see how to overcome this, which makes > > auto-def quite useless :) > > I think this should be a runtime error. What we are discussing here is > in: > > (defn myfun [] > (another-fun 5)) > > (defn another-fun [x] > (inc x)) > > "myfun" definition is rejected, even if "another-fun" is just few > lines away. Furthermore, if I understand Rich's opinion in that regards, this code: (defn myfun [] (another-fun 5)) should be rejected if definition of "another-fun" is missing (but I'd say: only in code to be released). --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
Hi, Am 16.03.2009 um 23:39 schrieb Elena: - the REPL could allow for an option to just warn about missing definitions; - when loading/compiling a file, Clojure could parse all definitions before complaining about missing ones. It seems that such a solution would offer both maximum flexibility when prototyping and maximum sanity checking when finalizing the code. What do you think? I probably wouldn't notice such a change. I code in the repl only very small snippets. To check my expectations of some return value of a function or the like. (Basically poor man's debugger) Things like a function I write in a file and send them to the clojure server, and only call them in the repl. I almost never write a function like this. (defn foo [] (let [x (bar)] (inc x))) "Hmmm... So how might bar look like?" It's almost always the other way around: (defn foo [] (let [x (long ugly stuff)] (inc x))) "Iek. I should refactor this." Hmm... So maybe I don't do prototyping Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: advice needed converting large files to xml
Yea, that would work. I don't think the (fn) should be defined anonymously though, because I could see it being useful on its own. Give it a name! Thanks, Stu On Mon, Mar 16, 2009 at 6:53 PM, Brian Doyle wrote: > > > On Mon, Mar 16, 2009 at 4:21 PM, Stu Hood wrote: > >> If you write your CSV -> XML processing as a function, you could pmap ( >> http://clojure.org/api#pmap) that function across the list of input >> files. pmap will transparently create the threads as needed, and it will >> probably be enough to saturate your disk. >> >> Thanks, >> Stu >> > > Stu, I just want to make sure I understand what you are saying here. > Would it look something like this: > > (pmap (fn [input-file] >; open input for reading >; open output for writing >; read line >; process line >; write line > ) > ["input-file1", "input-file2", "input-file3", ]) > > Thanks. > > >> >> >> On Mon, Mar 16, 2009 at 5:56 PM, Brian Doyle wrote: >> >>> I've been using Clojure for about 6 months now and really like it. I am >>> somewhat new to multi-threading >>> and using any of the parallel features in Clojure though. I have a >>> situation where I need to convert >>> 7 files from CSV to XML. Each one of these files is about 180MB apiece >>> in size. I have dual core machine >>> with 2GB of RAM and would like some advice on the best strategy for >>> processing these files in a way that >>> really utilizes both cores and my memory to really speed up the >>> processing.I'm sure this isn't the best >>> way, but I've only come up with starting up two threads at first, having >>> each thread open up a file, >>> call line-seq on that file, write out the XML for each line and then go >>> to the next file when it's complete. Any >>> advice would be great. Thanks. >>> >>> >>> >> >> >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Behavior of 'empty'
On Mon, Mar 16, 2009 at 3:54 PM, Frantisek Sodomka wrote: > (empty (seq [1 2])) => nil Now that there is the concept of empty sequences, maybe this should actually return an empty sequence, such as (). --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
Hello Tim, 2009/3/16 Timothy Pratley > > Just FYI, > > The actual patch is in the files section: > http://groups.google.com/group/clojure/web/auto-def.patch > With an example: > http://groups.google.com/group/clojure/web/lit-wc.clj > From a longer thread about 'snake' which talked about literate > programming: > > http://groups.google.com/group/clojure/browse_thread/thread/2a23a95bf22938a3 > > It does not implement existence checking upon completion of compile > unit. How exactly should this work? We can keep a set of symbols auto- > defined and 'at checkpoint' test if they are still undefined... > however what is the 'checkpoint'? For fully compiled code the > 'checkpoint' is clear - but Clojure is dynamic... what should happen > with this code: Yes, I think the checkpoint should be at the end of the Compiler.load(Reader rdr, String sourcePath, String sourceName) method call. > > > (defn myfun [] > (another-fun 5)) > (myfun) > (defn another-fun [x] > (inc x)) > > In a compiled language that would be valid, but in a dynamic language > it is a runtime error. I personally have no problem with that being a runtime error. Indeed, I tend to write functions for everything, not even for bootstraping a ns (bootstrapping a ns at the end of a file does not appeal to me *at all *). > I don't see how to overcome this, which makes > auto-def quite useless :) Not at all, I think. It's just "full" auto-def that is certainly too lazy. "scoped"-autodef does not suffer from the same problem, even, I think, for production code (or please, someone, give me some examples where it could let bugs pass through). > It seems you either need to accept top-down > or accept undefined symbol runtime errors. There is a third > alternative, which is to use Knuth's literate programming technique of > actually writing your code in TeX and have it transformed from there > to either code or documentation... but again for interactive > development that is quite rigorous. > > > Regards, > Tim. > > > > On Mar 17, 7:54 am, David Nolen wrote: > > Here's the post by Timothy talking about patching the compiler: > > > > http://groups.google.com/group/clojure/msg/ef5bae605f4a0730 > > > > On Mon, Mar 16, 2009 at 4:36 PM, Paul Stadig wrote: > > > On Mon, Mar 16, 2009 at 4:18 PM, David Nolen >wrote: > > > > >> On Mon, Mar 16, 2009 at 4:08 PM, Paul Stadig > wrote: > > > > >>> I may be missing something, but how does having to (declare) vars fix > > >>> typos? I don't think anyone is suggesting *creating* a var that is > > >>> referenced before it is defined. What people are asking for is that > the > > >>> compiler looks-ahead to verify that the var will eventually be > defined, and > > >>> then go on its merry way. Typos would still be discovered, and people > > >>> wouldn't have to stop and (declare). > > > > >> Yeah I wasn't suggesting that vars should be created, sorry if it > sounded > > >> like I was (I mentioned declare because this came up in another thread > about > > >> declare and someone had hacked the reader to not bail immediately on > > >> undefined symbols). > > > > > Sorry, my fault. I was just responding in general, not to you > specifically. > > > > >> In CL, if you have definitions out of order in the compiler will issue > > >> warnings. > > > > >>> I'm not saying it's an easy change... > > > > >>> Paul > > > > > Could someone post the link to the previous discussion? I searched the > > > group for declare, but didn't turn up anything. > > > > > Paul > > > --~--~-~--~~~---~--~~ 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 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: advice needed converting large files to xml
On Mon, Mar 16, 2009 at 4:29 PM, Mark Volkmann wrote: > > On Mon, Mar 16, 2009 at 4:56 PM, Brian Doyle > wrote: > > I've been using Clojure for about 6 months now and really like it. I am > > somewhat new to multi-threading > > and using any of the parallel features in Clojure though. I have a > > situation where I need to convert > > 7 files from CSV to XML. Each one of these files is about 180MB apiece > in > > size. I have dual core machine > > with 2GB of RAM and would like some advice on the best strategy for > > processing these files in a way that > > really utilizes both cores and my memory to really speed up the > > processing.I'm sure this isn't the best > > way, but I've only come up with starting up two threads at first, having > > each thread open up a file, > > call line-seq on that file, write out the XML for each line and then go > to > > the next file when it's complete. Any > > advice would be great. Thanks. > > Most libraries that write XML build a data structure to represent the > XML and then write it out. That doesn't work for writing out large XML > documents because you'll run out of memory before you finish building > the data structure. > > I don't know if there is a Clojure library that writes XML as you > specify it. If there isn't then you should consider WAX, a Java > library I wrote. You can learn more about it at > http://ociweb.com/wax/. You could use it from Clojure. Check out the > tutorial. It's a really simple library, it's really fast and it's very > memory efficient! > Mark, WAX looks really nice! I'll look around in Clojure some more about writing XML but if I don't find anything to my linking I'll give WAX a go. Thanks! > > -- > R. Mark Volkmann > Object Computing, Inc. > > > > --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure Web Framework, what I want to add
After many years (decade) of web development, here are the things that I want in a framework, mostly based in clojure: What do you think and what you add. This is ambitious and just a "ideas" of what I would add. What would you want from your ideal framework? 1. Based on Spring Framework for middleware: Reason: there are years and years and years of development spent on spring and there are many things done right. If I were integrating with any other third party libraries, I would use spring. Spring is added to my framework. 2. Based on Hibernate for ORM mapping: Reason: the defacto standard for ORM mapping with Java. And also used by NHibernate. There is a lot of support for most popular databases. 3. Clojure/Lisp based configuration AND default XML configurations. This has become the standard way to configure a J2EE web application including spring and hibernate. But I would like a lisp oriented configuration. 4. Easy mapping to URLs. I like python's approach for URL mapping 5. Clojure based, framework based server pages AND JSPs. I have always hated some aspects of JSP and ASPs, etc, etc. They are just too complicated. I would want to use Clojure code within the framework oriented server page and other predefined tags. 5. Lift like reusable server pages. Lift has an interesting approach for resuing the same page. E.g. you have an if-else statement within the page. If request == GET ...render this if request == POST ...render this. if URL == 'abc.html' .. render this. I want to embed this in my framework. You only touch one page, but you get different outputs depending on the request method or URL, etc, etc. 6. Use of Clojure syntactic sugar -- TO BE DETERMINED. There is the ability to use powerful Clojure constructs with this framework but I haven't figured out how yet. 7. Better integration of CSS, Javascript, HTML. A lot of a web application still resides with the client side. I have yet to see an web framework that addresses client development (besides GWT). Maybe something as simple as server page tags for CSS? Javascript? 8. Additional third party libraries: Lucene, iText, jFreeChart, optional Terracotta integration Other optional/additional thoughts. 9. Clear separation between back-end and front-end layers --~--~-~--~~~---~--~~ 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 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: Qi's type system
I antended a talk on Qi at JavaZone 2008. Qi is a kind of AOP layer that knits together concerns via a bit of configuration and some naming conventions. I'm a bit fuzzy on the details 6 months out. A lot of the AOP solutions for Java are trying to introduce concepts that are more native in a Lisp. I'm sure there's quite a lot of good ideas there, but there's a lot of others that probably don't fit. On Mon, Mar 16, 2009 at 10:11 AM, Raoul Duke wrote: > >> could be applicable in Clojure. From what I gathered from the tweets >> from Qcon, Qi was mentioned again there. Does anyone know if there >> was anything more to it than "it would be nice"? > > (fwiw, Mark T. talked about it a bit on the Qi list. > > http://groups.google.co.uk/group/Qilang/search?group=Qilang&q=clojure&qt_g=Search+this+group) > > > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --~--~-~--~~~---~--~~ 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 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: Qi's type system
there are (at least) 2 Qis: one is java-aop. the other is lisp++. sincerely. On Mon, Mar 16, 2009 at 4:19 PM, Howard Lewis Ship wrote: > > I antended a talk on Qi at JavaZone 2008. > > Qi is a kind of AOP layer that knits together concerns via a bit of > configuration and some naming conventions. I'm a bit fuzzy on the > details 6 months out. > > A lot of the AOP solutions for Java are trying to introduce concepts > that are more native in a Lisp. I'm sure there's quite a lot of good > ideas there, but there's a lot of others that probably don't fit. > > On Mon, Mar 16, 2009 at 10:11 AM, Raoul Duke wrote: >> >>> could be applicable in Clojure. From what I gathered from the tweets >>> from Qcon, Qi was mentioned again there. Does anyone know if there >>> was anything more to it than "it would be nice"? >> >> (fwiw, Mark T. talked about it a bit on the Qi list. >> >> http://groups.google.co.uk/group/Qilang/search?group=Qilang&q=clojure&qt_g=Search+this+group) >> >> > >> > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > > > --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Web Framework, what I want to add
Personally, I've been noodling about what a Tapestry/Clojure hybrid might look like. I'd advise that you take a peek at Lift, a functional web framework built on Scala. I have some ideas about what a component based framework would look like in a function world (note: this would be leaving JSPs and the like far in the dust, and moving toward a higher-order solution more like Tapestry). On the output side, I see the templates being represented as nested DOM structures, and components would operate by transforming the DOM (or a subtree of the DOM) according to their own template and code. I think the request handling side of things would be a bit more traditional and action based, with routing functions that would locate handler functions of some form, via some mix of naming conventions and start-up registrations. I can definitely envision areas where the (binding) construct would be awesome for rewiring the processing of a request for specific needs, things that in Tapestry require active filter objects contributed statically into global pipelines. but I've still got a lot of ideas for T5 to work on first :-) Web frameworks are a tricky beast (I'm eight+ years into writing Tapestry) there are aspects that line up beautifully with stateless functions, but when you introduce the benefits of components, you also bring in a lot that benefits from stateful, mutable, internal state. On Mon, Mar 16, 2009 at 4:17 PM, BerlinBrown wrote: > > After many years (decade) of web development, here are the things that > I want in a framework, mostly based in clojure: > > What do you think and what you add. This is ambitious and just a > "ideas" of what I would add. What would you want from your ideal > framework? > > 1. Based on Spring Framework for middleware: > Reason: there are years and years and years of development spent on > spring and there are many things done right. If I were integrating > with any other third party libraries, I would use spring. Spring is > added to my framework. > > 2. Based on Hibernate for ORM mapping: > Reason: the defacto standard for ORM mapping with Java. And also used > by NHibernate. There is a lot of support for most popular databases. > > 3. Clojure/Lisp based configuration AND default XML configurations. > This has become the standard way to configure a J2EE web application > including spring and hibernate. But I would like a lisp oriented > configuration. > > 4. Easy mapping to URLs. I like python's approach for URL mapping > > 5. Clojure based, framework based server pages AND JSPs. I have > always hated some aspects of JSP and ASPs, etc, etc. They are just > too complicated. I would want to use Clojure code within the > framework oriented server page and other predefined tags. > > 5. Lift like reusable server pages. Lift has an interesting approach > for resuing the same page. E.g. you have an if-else statement within > the page. > > If request == GET > ...render this > if request == POST > ...render this. > if URL == 'abc.html' > .. render this. > > I want to embed this in my framework. You only touch one page, but > you get different outputs depending on the request method or URL, etc, > etc. > > 6. Use of Clojure syntactic sugar -- TO BE DETERMINED. There is the > ability to use powerful Clojure constructs with this framework but I > haven't figured out how yet. > > 7. Better integration of CSS, Javascript, HTML. A lot of a web > application still resides with the client side. I have yet to see an > web framework that addresses client development (besides GWT). Maybe > something as simple as server page tags for CSS? Javascript? > > 8. Additional third party libraries: > > Lucene, iText, jFreeChart, optional Terracotta integration > > > Other optional/additional thoughts. > > 9. Clear separation between back-end and front-end layers > > > > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --~--~-~--~~~---~--~~ 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 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: Symbols evaluated at compile time?
Tim, I see in clojure a var named ALLOW_UNRESOLVED_VARS. Could you explain me how it works compared to the new AUTO_DEF that is introduced ? I think there's a subtlety between resolved var / defined var that I don't understand right now ... Thanks, -- Laurent 2009/3/16 Timothy Pratley > > Just FYI, > > The actual patch is in the files section: > http://groups.google.com/group/clojure/web/auto-def.patch > With an example: > http://groups.google.com/group/clojure/web/lit-wc.clj > From a longer thread about 'snake' which talked about literate > programming: > > http://groups.google.com/group/clojure/browse_thread/thread/2a23a95bf22938a3 > > It does not implement existence checking upon completion of compile > unit. How exactly should this work? We can keep a set of symbols auto- > defined and 'at checkpoint' test if they are still undefined... > however what is the 'checkpoint'? For fully compiled code the > 'checkpoint' is clear - but Clojure is dynamic... what should happen > with this code: > > (defn myfun [] > (another-fun 5)) > (myfun) > (defn another-fun [x] > (inc x)) > > In a compiled language that would be valid, but in a dynamic language > it is a runtime error. I don't see how to overcome this, which makes > auto-def quite useless :) It seems you either need to accept top-down > or accept undefined symbol runtime errors. There is a third > alternative, which is to use Knuth's literate programming technique of > actually writing your code in TeX and have it transformed from there > to either code or documentation... but again for interactive > development that is quite rigorous. > > > Regards, > Tim. > > > > On Mar 17, 7:54 am, David Nolen wrote: > > Here's the post by Timothy talking about patching the compiler: > > > > http://groups.google.com/group/clojure/msg/ef5bae605f4a0730 > > > > On Mon, Mar 16, 2009 at 4:36 PM, Paul Stadig wrote: > > > On Mon, Mar 16, 2009 at 4:18 PM, David Nolen >wrote: > > > > >> On Mon, Mar 16, 2009 at 4:08 PM, Paul Stadig > wrote: > > > > >>> I may be missing something, but how does having to (declare) vars fix > > >>> typos? I don't think anyone is suggesting *creating* a var that is > > >>> referenced before it is defined. What people are asking for is that > the > > >>> compiler looks-ahead to verify that the var will eventually be > defined, and > > >>> then go on its merry way. Typos would still be discovered, and people > > >>> wouldn't have to stop and (declare). > > > > >> Yeah I wasn't suggesting that vars should be created, sorry if it > sounded > > >> like I was (I mentioned declare because this came up in another thread > about > > >> declare and someone had hacked the reader to not bail immediately on > > >> undefined symbols). > > > > > Sorry, my fault. I was just responding in general, not to you > specifically. > > > > >> In CL, if you have definitions out of order in the compiler will issue > > >> warnings. > > > > >>> I'm not saying it's an easy change... > > > > >>> Paul > > > > > Could someone post the link to the previous discussion? I searched the > > > group for declare, but didn't turn up anything. > > > > > Paul > > > --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Web Framework, what I want to add
I'm not sure if some of the design inputs make sense, specifically Spring and Hibernate. Point 1 - I've found the strength of Spring to be making up for the weaknesses of Java. Once you have first class functions, macros, and multi-methods (to name a few), Spring doesn't bring much to the table any more. Add in a few Unix utilities like cron and others, you remove the rest of the features. Point 2 - As for Hibernate, ORM doesn't make much sense with a functional language either. The SQL library in clojure-contrib lets you load a map, and you can create way more interesting queries with clojure than hibernate. S-expressions are that powerful. Point 3 - I'd follow Rails example and use strong defaults, and resort to XML only when necessary. Point 4 - Sounds good. Point 5 - Have you looked into compojure? It does a really good job of turning s-expressions into HTML. Point 5 (the second one) - See compojure again. Point 6 & 7 - This is where a lot of work is to be done. I'm not sure how to respond right now. I'll think about it. Point 8 - This is why clojure is awesome. I'll leave this as an exercise to the user :) Point 9 - Yeah, this would be a great feature. That's my thoughts. On Mar 16, 7:17 pm, BerlinBrown wrote: > After many years (decade) of web development, here are the things that > I want in a framework, mostly based in clojure: > > What do you think and what you add. This is ambitious and just a > "ideas" of what I would add. What would you want from your ideal > framework? > > 1. Based on Spring Framework for middleware: > Reason: there are years and years and years of development spent on > spring and there are many things done right. If I were integrating > with any other third party libraries, I would use spring. Spring is > added to my framework. > > 2. Based on Hibernate for ORM mapping: > Reason: the defacto standard for ORM mapping with Java. And also used > by NHibernate. There is a lot of support for most popular databases. > > 3. Clojure/Lisp based configuration AND default XML configurations. > This has become the standard way to configure a J2EE web application > including spring and hibernate. But I would like a lisp oriented > configuration. > > 4. Easy mapping to URLs. I like python's approach for URL mapping > > 5. Clojure based, framework based server pages AND JSPs. I have > always hated some aspects of JSP and ASPs, etc, etc. They are just > too complicated. I would want to use Clojure code within the > framework oriented server page and other predefined tags. > > 5. Lift like reusable server pages. Lift has an interesting approach > for resuing the same page. E.g. you have an if-else statement within > the page. > > If request == GET > ...render this > if request == POST > ...render this. > if URL == 'abc.html' > .. render this. > > I want to embed this in my framework. You only touch one page, but > you get different outputs depending on the request method or URL, etc, > etc. > > 6. Use of Clojure syntactic sugar -- TO BE DETERMINED. There is the > ability to use powerful Clojure constructs with this framework but I > haven't figured out how yet. > > 7. Better integration of CSS, Javascript, HTML. A lot of a web > application still resides with the client side. I have yet to see an > web framework that addresses client development (besides GWT). Maybe > something as simple as server page tags for CSS? Javascript? > > 8. Additional third party libraries: > > Lucene, iText, jFreeChart, optional Terracotta integration > > > Other optional/additional thoughts. > > 9. Clear separation between back-end and front-end layers --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Web Framework, what I want to add
I'd love to see something built around very-high scalability, using NIO and thread pools and such. On Mon, Mar 16, 2009 at 7:40 PM, Sean wrote: > > I'm not sure if some of the design inputs make sense, specifically > Spring and Hibernate. > > Point 1 - I've found the strength of Spring to be making up for the > weaknesses of Java. Once you have first class functions, macros, and > multi-methods (to name a few), Spring doesn't bring much to the table > any more. Add in a few Unix utilities like cron and others, you > remove the rest of the features. > > Point 2 - As for Hibernate, ORM doesn't make much sense with a > functional language either. The SQL library in clojure-contrib lets > you load a map, and you can create way more interesting queries with > clojure than hibernate. S-expressions are that powerful. > > Point 3 - I'd follow Rails example and use strong defaults, and resort > to XML only when necessary. > > Point 4 - Sounds good. > > Point 5 - Have you looked into compojure? It does a really good job > of turning s-expressions into HTML. > > Point 5 (the second one) - See compojure again. > > Point 6 & 7 - This is where a lot of work is to be done. I'm not sure > how to respond right now. I'll think about it. > > Point 8 - This is why clojure is awesome. I'll leave this as an > exercise to the user :) > > Point 9 - Yeah, this would be a great feature. > > That's my thoughts. > > On Mar 16, 7:17 pm, BerlinBrown wrote: > > After many years (decade) of web development, here are the things that > > I want in a framework, mostly based in clojure: > > > > What do you think and what you add. This is ambitious and just a > > "ideas" of what I would add. What would you want from your ideal > > framework? > > > > 1. Based on Spring Framework for middleware: > > Reason: there are years and years and years of development spent on > > spring and there are many things done right. If I were integrating > > with any other third party libraries, I would use spring. Spring is > > added to my framework. > > > > 2. Based on Hibernate for ORM mapping: > > Reason: the defacto standard for ORM mapping with Java. And also used > > by NHibernate. There is a lot of support for most popular databases. > > > > 3. Clojure/Lisp based configuration AND default XML configurations. > > This has become the standard way to configure a J2EE web application > > including spring and hibernate. But I would like a lisp oriented > > configuration. > > > > 4. Easy mapping to URLs. I like python's approach for URL mapping > > > > 5. Clojure based, framework based server pages AND JSPs. I have > > always hated some aspects of JSP and ASPs, etc, etc. They are just > > too complicated. I would want to use Clojure code within the > > framework oriented server page and other predefined tags. > > > > 5. Lift like reusable server pages. Lift has an interesting approach > > for resuing the same page. E.g. you have an if-else statement within > > the page. > > > > If request == GET > > ...render this > > if request == POST > > ...render this. > > if URL == 'abc.html' > > .. render this. > > > > I want to embed this in my framework. You only touch one page, but > > you get different outputs depending on the request method or URL, etc, > > etc. > > > > 6. Use of Clojure syntactic sugar -- TO BE DETERMINED. There is the > > ability to use powerful Clojure constructs with this framework but I > > haven't figured out how yet. > > > > 7. Better integration of CSS, Javascript, HTML. A lot of a web > > application still resides with the client side. I have yet to see an > > web framework that addresses client development (besides GWT). Maybe > > something as simple as server page tags for CSS? Javascript? > > > > 8. Additional third party libraries: > > > > Lucene, iText, jFreeChart, optional Terracotta integration > > > > > > Other optional/additional thoughts. > > > > 9. Clear separation between back-end and front-end layers > > > --~--~-~--~~~---~--~~ 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 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: Promise for absense of side effects
On 16 Mrz., 23:36, Raoul Duke wrote: > please, for those who aren't Erlang nerds, also see Dialyzer. > > http://www.it.uu.se/research/group/hipe/dialyzer Funny, I just wanted to post exactly that link. It is very impressive what that tool did: "Dialyzer has been applied to large code bases, for example the entire code base of AXD301 consisting of about 2,000,000 lines of Erlang code, and has identified a significant number of software defects that have gone unnoticed after years of extensive testing." In fact, it is this very tool, the Erlang Dialyzer that made me start thinking about this whole thing. The Dialyzer will infer the types from the sources, without hints of the developers. This means that it can not find all bugs. But it uses the information that exists even in a dynamically typed language to spit out warnings about type problems, but also about other discrepancies. If you follow the link, also read the pdfs they put online, such as: http://user.it.uu.se/~kostis/Papers/bugs05.pdf It's just five pages, and written not only for experts of static type systems. If the Dialyzer can do all this without having an optional type system in Erlang, then it should be obvious what would be possible, if Rich agrees and finds the time/resources to add one in Clojure. --~--~-~--~~~---~--~~ 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 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: Promise for absense of side effects
> If the Dialyzer can do all this without having an > optional type system in Erlang, then it should be > obvious what would be possible, if Rich agrees and > finds the time/resources to add one in Clojure. maybe this is a bad/crazy idea, but could one make a pluggable Dialyzer, which could then be customized to work on any dynamic language? that could be pretty awesome. sincerely. --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Web Framework, what I want to add
On Mar 16, 7:52 pm, Jeffrey Straszheim wrote: > I'd love to see something built around very-high scalability, using NIO and > thread pools and such. > > On Mon, Mar 16, 2009 at 7:40 PM, Sean wrote: > > > I'm not sure if some of the design inputs make sense, specifically > > Spring and Hibernate. > > > Point 1 - I've found the strength of Spring to be making up for the > > weaknesses of Java. Once you have first class functions, macros, and > > multi-methods (to name a few), Spring doesn't bring much to the table > > any more. Add in a few Unix utilities like cron and others, you > > remove the rest of the features. > > > Point 2 - As for Hibernate, ORM doesn't make much sense with a > > functional language either. The SQL library in clojure-contrib lets > > you load a map, and you can create way more interesting queries with > > clojure than hibernate. S-expressions are that powerful. > > > Point 3 - I'd follow Rails example and use strong defaults, and resort > > to XML only when necessary. > > > Point 4 - Sounds good. > > > Point 5 - Have you looked into compojure? It does a really good job > > of turning s-expressions into HTML. > > > Point 5 (the second one) - See compojure again. > > > Point 6 & 7 - This is where a lot of work is to be done. I'm not sure > > how to respond right now. I'll think about it. > > > Point 8 - This is why clojure is awesome. I'll leave this as an > > exercise to the user :) > > > Point 9 - Yeah, this would be a great feature. > > > That's my thoughts. > > > On Mar 16, 7:17 pm, BerlinBrown wrote: > > > After many years (decade) of web development, here are the things that > > > I want in a framework, mostly based in clojure: > > > > What do you think and what you add. This is ambitious and just a > > > "ideas" of what I would add. What would you want from your ideal > > > framework? > > > > 1. Based on Spring Framework for middleware: > > > Reason: there are years and years and years of development spent on > > > spring and there are many things done right. If I were integrating > > > with any other third party libraries, I would use spring. Spring is > > > added to my framework. > > > > 2. Based on Hibernate for ORM mapping: > > > Reason: the defacto standard for ORM mapping with Java. And also used > > > by NHibernate. There is a lot of support for most popular databases. > > > > 3. Clojure/Lisp based configuration AND default XML configurations. > > > This has become the standard way to configure a J2EE web application > > > including spring and hibernate. But I would like a lisp oriented > > > configuration. > > > > 4. Easy mapping to URLs. I like python's approach for URL mapping > > > > 5. Clojure based, framework based server pages AND JSPs. I have > > > always hated some aspects of JSP and ASPs, etc, etc. They are just > > > too complicated. I would want to use Clojure code within the > > > framework oriented server page and other predefined tags. > > > > 5. Lift like reusable server pages. Lift has an interesting approach > > > for resuing the same page. E.g. you have an if-else statement within > > > the page. > > > > If request == GET > > > ...render this > > > if request == POST > > > ...render this. > > > if URL == 'abc.html' > > > .. render this. > > > > I want to embed this in my framework. You only touch one page, but > > > you get different outputs depending on the request method or URL, etc, > > > etc. > > > > 6. Use of Clojure syntactic sugar -- TO BE DETERMINED. There is the > > > ability to use powerful Clojure constructs with this framework but I > > > haven't figured out how yet. > > > > 7. Better integration of CSS, Javascript, HTML. A lot of a web > > > application still resides with the client side. I have yet to see an > > > web framework that addresses client development (besides GWT). Maybe > > > something as simple as server page tags for CSS? Javascript? > > > > 8. Additional third party libraries: > > > > Lucene, iText, jFreeChart, optional Terracotta integration > > > > > > > Other optional/additional thoughts. > > > > 9. Clear separation between back-end and front-end layers "Point 1 - I've found the strength of Spring to be making up for the weaknesses of Java. Once you have first class functions, macros, and multi-methods (to name a few), Spring doesn't bring much to the table any more. Add in a few Unix utilities like cron and others, you remove the rest of the features." Assuming a person is able to re-engineer what Spring has already done including the simplistic dependency injection oriented web framework. For me, I just to hate to ignore all that work has been done as well as making it easier for integrating 'this' framework with pre-existing code. "Point 2 - As for Hibernate, ORM doesn't make much sense with a functional language either. The SQL library in clojure-contrib lets you load a map, and you can create way more interesting queries with clojure than hibernate. S-e
