Re: swank-clojure license
Yes, this is what I remember from LGPL. But anyway, swank-clojure is not LGPL, it's GPL. I re-read my original post, and it seems clear to me : I stated I wish to embed swank-clojure files into clojure-dev plugin. Anyway, I'll rephrase my question differently : Given that : - Clojure-dev's (an eclipse plugin I'm a contributor of) license is EPL. - swank-clojure's license is GPL Can the following be possible without breaking the GPL ? : - Embed swank-clojure source code in clojure-dev's source management system (svn) - Release clojure-dev as an eclipse plugin (that is a jar with clojure- dev classes, swank-clojure files) Precisions : - There will be no compile-time linkage between clojure-dev code and swank-clojure code. - Clojure-dev will have a new functionality given the user the ability to start (from its eclipse environment) a new java/clojure environment (in a fresh JVM) that will load swank-clojure (from the files distributed with clojure-dev plugin) at startup - Then clojure-dev will be able to communicate with the clojure environment running in the fresh JVM via swank-clojure remote calls Maybe this is a no problem. Thanks in advance to anybody that will demonstrate it's feasible or it's not feasible, -- Laurent On 30 déc, 23:55, "Mark H." wrote: > On Dec 30, 10:26 am, Phil Hagelberg wrote: > > > lpetit writes: > > > I'm not sure. From what I remember, what you describe is more related > > > to LGPL ? > > > No, the LGPL allows using the code in another program that is Free but > > not GPL-licensed. > > Actually the LGPL allows linking to the library (somewhat different > than "using the code") from any program, even one which is not under > an open-source license. "L" used to stand for "library" and the > canonical example of a LGPL library is GNU's libc: any program can > link to it, and such linkage doesn't make the program have the same > license as libc. > > mfh --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Update for Gorilla available
Dear vimming Clojurians, the latest SVN versions of Clojure and Clojure Contrib broke Gorilla. So now a compatibility release is available to bring Gorilla back up-to-date. Note: this release is only necessary if you use Clojure >= SVN rev1192 and Contrib >= SVN rev331. Revisions before those mentioned still work with the release v1.1.0 of Gorilla. The release may be found at the usual spot: http://kotka.de/projects/clojure/gorilla.html Thanks go to durka on #clojure for reporting the issue. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Parallel words frequency ranking
On 30.12.2008, at 22:24, Mark H. wrote: > On Dec 30, 9:18 am, Mibu wrote: >> In an ideal world, standard functions like map, sort, reduce, filter, >> etc. would know when to parallelize on their own, or even better, the >> compiler will do it for them. > > The former is easier than the latter ;-) Even the smartest > autoparallelizing compilers rely on manual annotations to expose lack > of sequential dependencies in loops, but a function's API can > guarantee that parallelism and let the function's implementation do > the heavy lifting. Manual intervention is required not only for the identification of dependencies, but also for telling the compiler where parallelization makes sense for gaining efficiency. It is often said that pure functional programs have the advantage of being autoparallelizable because there are no hidden dependencies, but there still isn't any decent autoparallelizing compiler for any functional language at the moment. One of the reasons is that performance analysis is still very difficult. Perhaps one day we will have parallel JIT compilers for this, but that's not for tomorrow. > incredibly frustrating for users (trust me). This means it's better > to have simpler compilers and smarter libraries. Definitely! 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: swank-clojure license
OOps, I'm losing memory, I answered twice to the e-mail ;-) On 31 déc, 11:16, lpetit wrote: > Yes, this is what I remember from LGPL. But anyway, swank-clojure is > not LGPL, it's GPL. > > I re-read my original post, and it seems clear to me : I stated I wish > to embed swank-clojure files into clojure-dev plugin. > > Anyway, I'll rephrase my question differently : > > Given that : > - Clojure-dev's (an eclipse plugin I'm a contributor of) license is > EPL. > - swank-clojure's license is GPL > > Can the following be possible without breaking the GPL ? : > - Embed swank-clojure source code in clojure-dev's source management > system (svn) > - Release clojure-dev as an eclipse plugin (that is a jar with clojure- > dev classes, swank-clojure files) > Precisions : > - There will be no compile-time linkage between clojure-dev code and > swank-clojure code. > - Clojure-dev will have a new functionality given the user the ability > to start (from its eclipse environment) a new java/clojure environment > (in a fresh JVM) that will load swank-clojure (from the files > distributed with clojure-dev plugin) at startup > - Then clojure-dev will be able to communicate with the clojure > environment running in the fresh JVM via swank-clojure remote calls > > Maybe this is a no problem. > > Thanks in advance to anybody that will demonstrate it's feasible or > it's not feasible, > > -- > Laurent > > On 30 déc, 23:55, "Mark H." wrote: > > > On Dec 30, 10:26 am, Phil Hagelberg wrote: > > > > lpetit writes: > > > > I'm not sure. From what I remember, what you describe is more related > > > > to LGPL ? > > > > No, the LGPL allows using the code in another program that is Free but > > > not GPL-licensed. > > > Actually the LGPL allows linking to the library (somewhat different > > than "using the code") from any program, even one which is not under > > an open-source license. "L" used to stand for "library" and the > > canonical example of a LGPL library is GNU's libc: any program can > > link to it, and such linkage doesn't make the program have the same > > license as libc. > > > mfh --~--~-~--~~~---~--~~ 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: How to encapsulate local state in closures
On Dec 31, 2008, at 12:30 AM, Mark Engelberg wrote: > > On Tue, Dec 30, 2008 at 8:38 PM, Rich Hickey > wrote: >> There's simply no value for Clojure to add to a simple mutable box. >> Clojure does provide the tools for low-level mutation - access to >> Java. You can wrap that in whatever functions/macros you like. >> > > There's no way to use the @ dereferencing syntax for a custom mutable > box, right? Not true. Just implement clojure.lang.IRef and deref/@ will work. > The sample I gave would be considerably harder to read if > you had to use (box-ref u) instead of @u everywhere. > >> OTOH, atom-set just invites the read-modify-write race conditions >> swap! was meant to avoid. > > Yes, but not every write to an atom is going to be a read-modify-write > kind of change, which is why it feels odd to always be limited to > swap!. > It doesn't matter that it's not a read-modify-write change, it matters that you think about other consumers of the atom. swap! makes you do that. > Since my examples emphasized the "simple mutable box" benefits of > having atom-set, and you didn't find that compelling, let's go back to > the discussion earlier in this thread about using an atom to maintain > a counter that increments to generate unique IDs. You've already > stated that this is one of the uses that is a good fit for atom. > > It would be entirely reasonable to want to, under certain conditions, > to reset the counter to 0. When you reset to 0, that's just a > straight write. Having to say (swap! counter (constantly 0)) feels > convoluted, and somewhat obscures the fact that this change is not > dependent on the previous state of the atom. Furthermore, by having > to represent this reset as a swap, the counter reset might not happen > as quickly as one would like. If there is a lot of contention and > other threads are in the process of incrementing the counter, the > reset might fail to go through for a while, because the value is > frequently changed by other threads between the unnecessary read and > the write of 0. An atom-set would not only reflect the intentions of > the code better, but would provide better performance for the times > where a read is irrelevant to the value being written. > This is a theoretical argument again, and remains unconvincing. (swap! counter (constantly 0)) may feel bad, but it should - you're trashing a shared reference with no regard for its contents. And if you have code where the counter is so hot a one-time swapping reset is a perf issue, you have bigger problems. One thing is certain, right now code like this is unlikely: (let [val (inc @a)] (swap! a (constantly val))) Whereas with atom-set in the API, code like this is likely: (atom-set a (inc @a)) ;broken - race condition after all, it looks just like its (correct) ref counterpart: (ref-set r (inc @r)) > Yes, atom-set invites a certain potential for misuse, but atoms > already require a certain degree of care. > This is not the kind of criteria I want to use when designing. With that logic Clojure could just be a free-for-all like Java, which also requires a 'certain degree of care'. That said, I think a big part of the problem here lies in the name. If it was e.g. reinitialize-atom or reset-atom I might feel differently. I also think that your use cases for atoms for local mutation are a mismatch. atoms are about sharing. You really want something else for private/local mutable references, and I have some ideas for that. 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: making code readable
On Dec 29, 3:15 am, Rich Hickey wrote: > On Dec 28, 8:13 pm, "Mark Volkmann" wrote: > > I'll not argue for making code harder to read, but I have to object to > most of your example. > > Making something 4x longer does not make it easier to read. > > Redundant comments are useless. This is the excuse continually trotted out by people too lazy to comment, or who think themselves superior to merely mortal programmers who have to work in teams and actually communicate with people. Redundancy in communication is almost never redundant; think of it as a checksum. When you listen to someone talking naturally and explaining something, you'll almost always find they express the same idea multiple times in different forms of words. Why? It makes certain that it is clear. I'm not denying there are occasions where comments add nothing to the reader's understanding of the code. But they are usually not cases where the comment repeats (in English or some other natural language) what is being expressed in Lisp or Java or XSLT or whatever. Repetition is not in itself bad. On the contrary, it can be explicitly good, because places where what's written in the comment describes something different from what's described in the code are probably places for bugs. I've never, in my life, worked with another programmer who commented too much. I've once in my life worked with another programmer who commented enough. In my experience, if you take over someone else's code either to maintain it or to integrate it or to reuse components from it, you're normally in for a huge learning process which would have been obviated simply by adequate commenting. 'Redundant comments are useless' is the mantra of the dilettante, the amateur, and the cowboy. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Compiling Clojure code with Maven
I'm working on a project that has both Java and Clojure sources. We use Maven as our build system, and I'd like to use it to compile the Clojure sources. Has anyone done that before? I can think of a few ways to do it, such as using maven to run an ant task or writing a plugin, but I'm not sure what's best. Any advice? Thanks, Mike --~--~-~--~~~---~--~~ 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: making code readable
On Dec 31, 9:42 am, Simon Brooke wrote: > On Dec 29, 3:15 am, Rich Hickey wrote: > > > On Dec 28, 8:13 pm, "Mark Volkmann" wrote: > > > I'll not argue for making code harder to read, but I have to object to > > most of your example. > > > Making something 4x longer does not make it easier to read. > > > Redundant comments are useless. > > This is the excuse continually trotted out by people too lazy to > comment, or who think themselves superior to merely mortal programmers > who have to work in teams and actually communicate with people. > 'Redundant comments are useless' is the mantra of the dilettante, the > amateur, and the cowboy. You're free to hold whatever opinions you like, but on this list please spare us the pejoratives. Thanks, 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: making code readable
"'Redundant comments are useless' is the mantra of the dilettante, the amateur, and the cowboy."dilettante, the amateur, and the cowboy"", ouch. Redundant comments are... redundant (hence the name), and a support overhead and a source of misunderstanding if they are not updated in line with the code. If you are writing code that will be read by people familiar with the language and idioms and using meaningful names then a small number well targeted comments are usually enough (Personally I do like a comment on each function saying what it is for, doc strings look like the right solution for this). Having said that; redundancy is a matter of context and I could use more comments and meaningful variables in example code, I am acquainted with Scheme so I can work my way through, but it is easy to get lost in the homogeneous syntax and unfamiliar constructs and idioms. When trying something new the fewer gumption traps the better and it is important to make sure information is to hand, this could be done through repetition or by the application of a little more indirection; earlier in the thread Mark asked if people would be aware of how to set up a clj script, good question and a link to the place that explains how, when you need it, would be very useful. Personally I don't think we need standards and stuff, what we need is some more "code with training wheels" (lots comments and links taking you through it very gently). That is not really Rich's job, he is to busy inventing the thing, I think Mark's evolving example is great and a few more like it covering other areas would be fine things and I hope to add to them myself when I am a bit more familiar with Clojure. That was a bit more rambling than planned. Happy New Year Tom 2008/12/31 Simon Brooke > > On Dec 29, 3:15 am, Rich Hickey wrote: > > On Dec 28, 8:13 pm, "Mark Volkmann" wrote: > > > > > I'll not argue for making code harder to read, but I have to object to > > most of your example. > > > > Making something 4x longer does not make it easier to read. > > > > Redundant comments are useless. > > This is the excuse continually trotted out by people too lazy to > comment, or who think themselves superior to merely mortal programmers > who have to work in teams and actually communicate with people. > Redundancy in communication is almost never redundant; think of it as > a checksum. > > ... > > 'Redundant comments are useless' is the mantra of the dilettante, the > amateur, and the cowboy. > > --~--~-~--~~~---~--~~ 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: making code readable
Simon Brooke wrote: > On Dec 29, 3:15 am, Rich Hickey wrote: >> On Dec 28, 8:13 pm, "Mark Volkmann" wrote: >> > >> I'll not argue for making code harder to read, but I have to object to >> most of your example. >> >> Making something 4x longer does not make it easier to read. >> >> Redundant comments are useless. > > This is the excuse continually trotted out by people too lazy to > comment, or who think themselves superior to merely mortal programmers > who have to work in teams and actually communicate with people. I used to subscribe to this thought. Now I don't. I used to put useless comments in my code. Now I don't. Comments should be appropriate to the persons who will read it. Copious comments are appropriate in tutorials and SDK examples, etc. But for production code, I'll comment only if I feel that *I* will need it when I come back to the code later. I do not think I'm superior to anybody else. But a certain level of competence is assumed in any project. My assumption is that after I'm gone from a project, whoever replaces me should be at least as competent as I am. If not, that's not my problem. > Redundancy in communication is almost never redundant; think of it as > a checksum. When you listen to someone talking naturally and > explaining something, you'll almost always find they express the same > idea multiple times in different forms of words. Why? It makes certain > that it is clear. There is a difference between code and other forms of communication. If the code is not clear, sure, add comments. But why write code that's not clear? > I'm not denying there are occasions where comments add nothing to the > reader's understanding of the code. But they are usually not cases > where the comment repeats (in English or some other natural language) > what is being expressed in Lisp or Java or XSLT or whatever. > Repetition is not in itself bad. On the contrary, it can be explicitly > good, because places where what's written in the comment describes > something different from what's described in the code are probably > places for bugs. It's a bug for sure. The wrong comment should simply be deleted. > I've never, in my life, worked with another programmer who commented > too much. I myself commented too much when I was less experienced. My comments were ridiculous and harmed the understanding of the actual code. > I've once in my life worked with another programmer who > commented enough. In my experience, if you take over someone else's > code either to maintain it or to integrate it or to reuse components > from it, you're normally in for a huge learning process which would > have been obviated simply by adequate commenting. If you don't understand a piece of code, with comments or without comments, you should not touch it. There's a learning curve when you take over a piece of code, comments or no comments, period. > 'Redundant comments are useless' is the mantra of the dilettante, the > amateur, and the cowboy. ... and the true professional. Telling which is which is the job of the hiring manager. I guess if you are the hiring manager, you wouldn't hire me. I'll work for your competitor, where codes are strong, comments are lean, and every one is above average. :) [For the humor impaired, the last sentence is meant to be a joke. A joke is something that is supposed to be funny. Funny things should make you laugh. And laugh is the act where your facial muscles move in a certain way as to effect a configuration of your face where the corner of your mouth rises above the center of your mouth. This paragraph is also an example of over-the-board commenting.] -- Weiqi Gao weiqi...@gmail.com http://www.weiqigao.com/blog/ --~--~-~--~~~---~--~~ 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: making code readable
I'd like to focus the attention back to a specific example. See the first code snippet at http://clojure.org/concurrent_programming. (import '(java.util.concurrent Executors)) (defn test-stm [nitems nthreads niters] (let [refs (map ref (replicate nitems 0)) pool (. Executors (newFixedThreadPool nthreads)) tasks (map (fn [t] (fn [] (dotimes [n niters] (dosync (doseq [r refs] (alter r + 1 t)) (range nthreads))] (doseq [future (. pool (invokeAll tasks))] (. future (get))) (. pool (shutdown)) (map deref refs))) Many people new to Clojure will be attracted to this page because they will have heard that one of the strengths of Clojure is how good it is for concurrent programming. I believe the purpose of this example is to demonstrate how much easier it is to program with Clojure refs instead of Java locks. Certainly this code is much shorter than similar Java code. There is a paragraph before the code that explains what the code does and there are no comments within the code. Suppose you had been studying Clojure for one week before coming across this code. Would you know what was going on here? Let's see ... we've got an anonymous function that uses an anonymous function which iterates some number of times calling dosync on a doseq ... alter changes the value of a ref ... it uses a future ... My fear is that many developers will become discouraged and stop trying to learn Clojure, fearing that it's just too hard. I think we need to work to minimize those kinds of reactions to sample code. Adding some comments to non-obvious code is one way to do that. I don't mean to single out this one example. Many examples of Clojure code seem equally daunting to me and most Clojure code seems to contain no comments at all. -- 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: Some code review for clj-record?
Hi Brian, On Tue, Dec 30, 2008 at 11:41 AM, Brian Doyle wrote: > (ns com.example.user) > (clj-record.core/init-model) > > but when I do that I get the error: > > java.lang.ClassNotFoundException: clj-record.core ... > (first (reverse (re-split #"\." (name (ns-name *ns*) > > and could be changed to: > > (last (re-split #"\." (name (ns-name *ns* Those changes have been incorporated, along with stuff in the README about validation. I'm confused as to how I ended up with (first (reverse ...)) since I remember looking at the doc for (last seq), but anyway, it's there now. -hume. -- http://elhumidor.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: making code readable
> This is the excuse continually trotted out by people too lazy to > comment, or who think themselves superior to merely mortal programmers > who have to work in teams and actually communicate with people. > Redundancy in communication is almost never redundant; think of it as > a checksum. A checksum should be trusted. Comments sometimes cannot. Since you brought up the issue with working in teams, I will submit my decade and a half of experience coding in 'enterprise' team environments (my chosen hell). I have built upon and maintained Java code that has grown through accretion of various consulting organizations, and I never trust comments. Even with third party (supposedly stable) APIs, I have had (more than once) to open up the code to discover that the javadocs are out of date and incorrect. I do my bit; I try to maintain my comments, but I never trust. The code IS the answer, always. > 'Redundant comments are useless' is the mantra of the dilettante, the > amateur, and the cowboy. I believe the मन्त्र 'comments are useless' is more cowboy-like, not 'redundant comments are useless'. If not, what about the phrase 'useless comments are useless'? --~--~-~--~~~---~--~~ 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: Stumped - Java hangs when using Swing in Slime
On Dec 30, 10:38 pm, CuppoJava wrote: > I would like to add that nope... installing SLIME didn't seem to help. > > I'm on Clojure rev. 1160, and the latest SLIME and Swank sources as of > December 30 2008. I experience a similar issue on windows, but not linux. The first time I create a JFrame in the lifetime of a JVM, it hangs and the frame does not appear until I go to the inferior lisp buffer and hit the enter key. After I do this once it behaves normally when creating subsequent JFrames. I connected jconsole to see what was going on, and at the point it is hung the awt event queue thread is in a native method sun.awt.windows.WDesktopProperties.init Not sure what that method is doing or why swank would cause it to hang. I may look into it more when I have some time. Name: AWT-EventQueue-0 State: RUNNABLE Total blocked: 0 Total waited: 0 Stack trace: sun.awt.windows.WDesktopProperties.init(Native Method) sun.awt.windows.WDesktopProperties.(WDesktopProperties.java:58) sun.awt.windows.WToolkit.initializeDesktopProperties(WToolkit.java: 934) java.awt.Toolkit.getDesktopProperty(Toolkit.java:1734) - locked sun.awt.windows.wtool...@13835b4 javax.swing.UIManager.(UIManager.java:384) javax.swing.JPanel.updateUI(JPanel.java:109) javax.swing.JPanel.(JPanel.java:69) javax.swing.JPanel.(JPanel.java:92) javax.swing.JPanel.(JPanel.java:100) javax.swing.JRootPane.createGlassPane(JRootPane.java:527) javax.swing.JRootPane.(JRootPane.java:347) javax.swing.JFrame.createRootPane(JFrame.java:260) javax.swing.JFrame.frameInit(JFrame.java:241) javax.swing.JFrame.(JFrame.java:164) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Constant expression optimization
Suppose I write (defn foo [x] (let [f (. Math log 0.5)] (* f x))) Does the Clojure compiler calculate the constant expression (. Math log 0.5) once, or at every function call? Can I check this somehow, i.e. look at the generated code, with reasonable effort? If it doesn't optimize it, I'd have to write (let [f (. Math log 0.5)] (defn foo [x] (* f x))) which is fine as well for this minimal example, but less clear in real-life code. I'd then rather write a small macro to evaluate the constant expression, but before doing so I'd like to know if I really have to. 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: Constant expression optimization
On Dec 31, 11:49 am, Konrad Hinsen wrote: > Suppose I write > > (defn foo [x] >(let [f (. Math log 0.5)] > (* f x))) > > Does the Clojure compiler calculate the constant expression (. Math > log 0.5) once, or at every function call? Every call. Clojure does not know that Math/log is a pure function. > Can I check this somehow, > i.e. look at the generated code, with reasonable effort? Currently there is no bytecode dump facility, but Java bytecode tools should work on AOT compiled class files. 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: Constant expression optimization
Note, however, that your JVM may very well know that java.lang.Math.log (0.5) is a constant, and optimize the calculation out of the JIT compiled code. This wouldn't show up in the bytecode, and is extremely difficult to actually check. Whether or not any JVM actually does this probably depends on whether such a call occurs any any popular floating-point benchmark suites. --~--~-~--~~~---~--~~ 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: Constant expression optimization
On Wednesday 31 December 2008 09:03, Dave Griffith wrote: > Note, however, that your JVM may very well know that > java.lang.Math.log (0.5) is a constant, and optimize the calculation > out of the JIT compiled code. This wouldn't show up in the > bytecode, and is extremely difficult to actually check. Whether or > not any JVM actually does this probably depends on whether such a > call occurs any any popular floating-point benchmark suites. How would the JVM know that? Are there annotations to that effect? Randall Schulz --~--~-~--~~~---~--~~ 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: Constant expression optimization
No, but the semantics of java.lang classes are fully specified in the Java spec, and JVM implementers are allowed to rely on them. It's entirely possible that there are special case optimizations for java.lang.Math calls. --~--~-~--~~~---~--~~ 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: Constant expression optimization
On Wednesday 31 December 2008 09:10, Dave Griffith wrote: > No, but the semantics of java.lang classes are fully specified in the > Java spec, and JVM implementers are allowed to rely on them. It's > entirely possible that there are special case optimizations for > java.lang.Math calls. Beyond the arguable possibility of such optimizations, do you know of any JVM that actually implements such things? Randall Schulz --~--~-~--~~~---~--~~ 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: Constant expression optimization
On Wednesday 31 December 2008 09:10, Dave Griffith wrote: > No, but the semantics of java.lang classes are fully specified in the > Java spec, Can you quote chapter and verse to this effect? I'm not finding it, at least not in "The Java™ Language Specification, Third Edition." There's an index entry that seems germane: "J -> Java -> java.lang package -> public types defined in, list of, 165" but there seems to be nothing on page 165 that corresponds to that index entry. > and JVM implementers are allowed to rely on them. It's > entirely possible that there are special case optimizations for > java.lang.Math calls. Randall Schulz --~--~-~--~~~---~--~~ 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: Constant expression optimization
Can't find the chapter and verse, but a bit of googling shows that GCJ does this optimization http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02312.html --~--~-~--~~~---~--~~ 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: Constant expression optimization
On Wednesday 31 December 2008 09:56, Dave Griffith wrote: > Can't find the chapter and verse, but a bit of googling shows that > GCJ does this optimization > http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02312.html Yes, but you claim that this guarantee is in the language specification and that it is available to JVM implementors. Anyway, I can't say I think of GCJ as something to point to as a state-of-the-art Java implementation. RRS --~--~-~--~~~---~--~~ 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: How to encapsulate local state in closures
On Wed, Dec 31, 2008 at 6:27 AM, Rich Hickey wrote: > I also think that your use cases for atoms for local mutation are a > mismatch. atoms are about sharing. You really want something else for > private/local mutable references, and I have some ideas for that. You're right that I'm basically asking for something that works well for private/local mutable references. It's possible right now to use with-local-vars, or atoms, or refs, but none of them quite fill that need perfectly (by design). My impression so far of atoms is that they are "underpowered", and suitable for a very small set of use cases, most of which you could have already done with refs and commute (albeit with a slight performance penalty). Since atoms are side-effecting, their composability with other transaction-based Clojure code is limited. Yes, my feelings about this are entirely theoretical, and maybe in practice, as more and more Clojure code is written, I'll get to see more good uses for atoms. That's part of the fun of working with a new and vibrant language that is full of possibilities. But this perception I have is why I like the idea of extending atom's capabilities to cover the local mutable reference use cases. I like the idea of thinking of an atom as a simple box, with a cool bonus feature of being able to atomically swap its contents, providing a step up in safety without going as far as a ref. Anyway, it's great to hear you have some more ideas on the subject, and I look forward to seeing what you come up with. --~--~-~--~~~---~--~~ 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: Stumped - Java hangs when using Swing in Slime
After some more tinkering, I think the problem lies somewhere in the way Emacs handles IO from the buffers. 1) The System command prompt works perfectly. 2) Inferior-Lisp mode hangs 3) Slime hangs 4) Running a windows shell from within Emacs, and running Java from within the shell also hangs. Symptom 4 leads to me think that the problem doesn't lie in Slime or clojure-mode or Java. --~--~-~--~~~---~--~~ 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: Stumped - Java hangs when using Swing in Slime
And Xemacs has the same problem... so it might be a problem with Windows then =( --~--~-~--~~~---~--~~ 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: How to encapsulate local state in closures
On Dec 31, 1:20 pm, "Mark Engelberg" wrote: > On Wed, Dec 31, 2008 at 6:27 AM, Rich Hickey wrote: > > I also think that your use cases for atoms for local mutation are a > > mismatch. atoms are about sharing. You really want something else for > > private/local mutable references, and I have some ideas for that. > > My impression so far of atoms is that they are "underpowered", and > suitable for a very small set of use cases, most of which you could > have already done with refs and commute (albeit with a slight > performance penalty). Since atoms are side-effecting, their > composability with other transaction-based Clojure code is limited. I wish you would stop repeating that. I've give you concrete use cases where atoms might be essential to good scalability in a transactional context, lest every transaction that uses a memoized function or ID generator have to serialize on it. Their compatibility with transactions can be completely irrelevant for non-transactional subsystems where atoms can form a useful substrate for lock-free synchronous state. And, in subsystems using transactions, all effort must be applied to keeping transactions small, and most code out of them. Using atoms can help enable that where refs are not necessary. 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: Constant expression optimization
On Dec 31, 8:49 am, Konrad Hinsen wrote: > Suppose I write > > (defn foo [x] > (let [f (. Math log 0.5)] > (* f x))) > > Does the Clojure compiler calculate the constant expression (. Math > log 0.5) once, or at every function call? Folding constants in nontrivial floating-point expressions is an aggressive optimization that can break some subtle code. For example, when building LAPACK, the file that tries to determine parameters of the floating-point units generally has to be compiled with no optimization. I'd much rather keep that part of the optimization turned off, or be very selective about when it gets turned on. Furthermore, in some cases (FFTs on the Cell processor is the modern example, if I recall correctly), it's better to recompute constants on the fly then to look them up in a table. mfh --~--~-~--~~~---~--~~ 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: making code readable
On Dec 31, 8:13 am, "Mark Volkmann" wrote: > Suppose you had been studying Clojure for one week before coming > across this code. Would you know what was going on here? Let's see ... > we've got an anonymous function that uses an anonymous function which > iterates some number of times calling dosync on a doseq ... alter > changes the value of a ref ... it uses a future ... My fear is that > many developers will become discouraged and stop trying to learn > Clojure, fearing that it's just too hard. I think we need to work to > minimize those kinds of reactions to sample code. Adding some comments > to non-obvious code is one way to do that. The misfortune is that a code which is pretty much just an academic example is having that effect. Maybe the right thing to do is to point to the "ants" demo or some demo which accomplishes an interesting task? The trouble is, it's hard to come up with meaningful concurrent code that fits on a single web page ;-) > I don't mean to single out this one example. Many examples of Clojure > code seem equally daunting to me and most Clojure code seems to > contain no comments at all. Just wait until you see mine ;-P (It's practically an essay.) mfh --~--~-~--~~~---~--~~ 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: How to encapsulate local state in closures
I have not yet written thousands of line of parallel code in Clojure (I am in this learning curve as of now while experimenting with Terracotta). However I can compare with other frameworks I've used in the past: ASTs, Event Flags,... on VMS, semaphores, condition variables, mutexes, ... in libthread on various platforms, Java with its simplistic approach,...) and I fully agree with Rich. There are always "simple shareable states" in any parallel system and you need an economical way to share these without requiring the full blown thing (taking a mutex before accessing/changing stuff, ). Semaphores are a good example of state that can be shared and changed atomically with simple calls. Dig a bit and you will find them in many places. Having worked with a lot of real time systems I can guarantee that there are many spots where such mechanisms are a necessity. In java it's worse than in other language because many of these things have been hidden with "nice" keywords (synchronized, wait, ...). Other features have been dropped because people were killing their apps by lack of knowledge. Other features were not considered because they were not seen as required... yet. The implementation details in Java are so hidden to most people that there is seldom a discussion about the cost of using a specific feature and the impacts it has on parallelism. Parallel code is not mainstream yet in businesses aside from Swing code (:)), I hope Clojure will change that a lot), most coders do not deal with these issues very often or in a very superficial way. I expect this will have to change when parallel designs will become common. I would rather have more options than less to tune up my design and increase throughput... so atoms are welcomed. Luc >From a guy who's been doing a lot of multi threaded apps for more than twenty years (for those too young to remember, that was BEFORE libthread came to life :))) and yes I have grey hairs :))) On Wed, 2008-12-31 at 10:56 -0800, Rich Hickey wrote: > > > On Dec 31, 1:20 pm, "Mark Engelberg" wrote: > > On Wed, Dec 31, 2008 at 6:27 AM, Rich Hickey wrote: > > > I also think that your use cases for atoms for local mutation are a > > > mismatch. atoms are about sharing. You really want something else for > > > private/local mutable references, and I have some ideas for that. > > > > My impression so far of atoms is that they are "underpowered", and > > suitable for a very small set of use cases, most of which you could > > have already done with refs and commute (albeit with a slight > > performance penalty). Since atoms are side-effecting, their > > composability with other transaction-based Clojure code is limited. > > I wish you would stop repeating that. I've give you concrete use cases > where atoms might be essential to good scalability in a transactional > context, lest every transaction that uses a memoized function or ID > generator have to serialize on it. > > Their compatibility with transactions can be completely irrelevant for > non-transactional subsystems where atoms can form a useful substrate > for lock-free synchronous state. > > And, in subsystems using transactions, all effort must be applied to > keeping transactions small, and most code out of them. Using atoms can > help enable that where refs are not necessary. > > 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: making code readable
My two cents... Comments are worse since Javadoc came to life, up to date or not. Most of the time they do not describe the behaviour of the class in depth and you have to get the source code on your screen. We replaced quality by quantity. If I want to find the signature of a function I can always read the code, assuming I have access to it of course. I would expect much more from Javadoc than class fields and member function signatures but this would require discipline from dev people to add significant and useful comments in their code. Javadoc is an evil tool, it gives the impression that your system is documented because it easily spits out garbage... but it's only garbage, not worth anything when you're trying to fix a problem that requires a broader knowledge than the 25 code lines scope on your screen. In the mid 80's I and others in a Fortran dev. team created a super javadoc. This beast was spitting out a FULL document in the editor used by office people. You would write comments in the code that were extracted and you would get a readable well formatted document after running the tool. Without the comments, the document looked ... empty and ugly. Missing items were as obvious as a nose in a face. Easier for code reviewer to control that, no need to read the code, read the document. If it does not make sense then go back to the coder. Coders had to add decent comments since the conventions were not only based on what you extract from the code (like javadoc) but also what is expected in comments so the document text content gets filled with decent content. When you force the coder to enter comments to fil a chapter introduction, well he/she has no choice. Of course it looks like if creating code is twice as complex but in fact you saved time when you need a system to be described very precisely. It also insured that comments were meaningful and in synch. with the code. If no decent comments are added in the code, then were is the knowledge and how can it be shared ? After 20 years of dev, I dropped javadoc entirely, comments are now minimal (function description, oddities in the code) and I COMPENSATE with external doc (a real document). Why should I bother to get clear documentation in the code since most of the world out there does not care about it ? Best proof, almost nobody does it these days. External doc at least gives an explanation of the design and structure. It does not even have to be fully in synch with the code. Even outdated it is a better starting point for someone to learn how to navigate in application internals. You get a sense of what the designers wanted to achieve and how. Then when you get to code, it's much more easier because you have a broader picture and can make sense of what you are reading. You can review it once every year and that's enough. Most of the time you already have some basic material about the things that changed or were added. It's just a matter of reorganizing it. I fully agree ultimately code is the thing that runs... not your comments or your documentation. Many people still speculate about system behaviour from the comments they read and eventually derive plans from this. Bad mistake... go to the code for your own sake. Luc On Wed, 2008-12-31 at 08:41 -0800, Daniel Eklund wrote: > > This is the excuse continually trotted out by people too lazy to > > comment, or who think themselves superior to merely mortal programmers > > who have to work in teams and actually communicate with people. > > Redundancy in communication is almost never redundant; think of it as > > a checksum. > > A checksum should be trusted. Comments sometimes cannot. > > Since you brought up the issue with working in teams, I will submit my > decade and a half of experience coding in 'enterprise' team > environments (my chosen hell). I have built upon and maintained Java > code that has grown through accretion of various consulting > organizations, and I never trust comments. Even with third party > (supposedly stable) APIs, I have had (more than once) to open up the > code to discover that the javadocs are out of date and incorrect. I > do my bit; I try to maintain my comments, but I never trust. The code > IS the answer, always. > > > > 'Redundant comments are useless' is the mantra of the dilettante, the > > amateur, and the cowboy. > > I believe the मन्त्र 'comments are useless' is more cowboy-like, not > 'redundant comments are useless'. If not, what about the phrase > 'useless comments are useless'? > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Exponentiation (expt / pow)
As I posted a couple weeks ago, I've been finding it awkward that Clojure doesn't have too many math functions that know how to "do the right thing" with the various numeric types it uses. The one that's been bothering me the most is the lack of an expt function. Calling Math/pow automatically coerces everything to doubles, which isn't necessarily the desired behavior. So I took this as an opportunity to learn how Clojure's multimethods work, and coded up a sample expt implementation, which I've attached and pasted below. I'd like to hear some comments on whether I'm utilizing multimethods correctly, and whether functions like this would be beneficial for inclusion in the clojure contribs. If people find this useful, there are a few other math functions which would benefit from this sort of conversion as well. (derive java.lang.Integer ::exact) (derive java.lang.Integer ::integer) (derive java.math.BigInteger ::exact) (derive java.math.BigInteger ::integer) (derive java.lang.Long ::exact) (derive java.lang.Long ::integer) (derive java.math.BigDecimal ::exact) (derive clojure.lang.Ratio ::exact) (derive java.lang.Double ::inexact) (defmulti expt (fn [x y] [(class x) (class y)])) (defn- expt-int [base pow] (loop [n pow, y 1, z base] (let [t (bit-and n 1), n (bit-shift-right n 1)] (cond (zero? t) (recur n y (* z z)) (zero? n) (* z y) :else (recur n (* z y) (* z z)) (defmethod expt [::exact ::integer] [base pow] (cond (pos? pow) (expt-int base pow) (zero? pow) 1 :else (/ 1 (expt-int base (- pow) (defmethod expt :default [base pow] (Math/pow base pow)) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- expt.clj Description: Binary data
Emacs+SLIME+Clojure troubles
I've been having trouble with Emacs + SLIME + Clojure. I've been using Bill Clementson's setup, and it was working when I fetched all the required projects via his clj-build script. However, when I fetched new versions using this script yesterday, Emacs gave me the following error when I ran "run-clojure": error in process filter: Symbol's function definition is void: slime-redirect-inferior-output I get an *inferior-lisp* buffer that works (is hooked to Clojure), and I can evaluate Clojure buffers, but I don't get a SLIME REPL buffer, nor does syntax highlighting work (I made sure that font-lock-mode is set). All of those things worked before. I'm attaching a file containing the relevant part of my .emacs file. The trouble seems to be near the end, where the hook after slime connects calls "slime-redirect-inferior-output". I can't find this function anywhere in SLIME or in clojure-swank. If I comment out this call, I get another error saying that error in process filter: Symbol's value as variable is void: slime-repl-mode-map and the troubles stay. Anybody know how I could work around the problem or even fix it altogether? mfh --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- emacs.clojure Description: Binary data
Re: making code readable
On Dec 31, 2008, at 1:29 PM, Luc Prefontaine wrote: > In the mid 80's I and others in a Fortran dev. team created a super > javadoc. This beast was spitting out a FULL > document in the editor used by office people. > > You would write comments in the code that were extracted and you > would get a readable well formatted > document after running the tool. Without the comments, the document > looked ... empty and ugly. > Missing items were as obvious as a nose in a face. > > Easier for code reviewer to control that, no need to read the code, > read the document. If it does not make sense > then go back to the coder. > > Coders had to add decent comments since the conventions were not > only based on what you extract from the code > (like javadoc) but also what is expected in comments so the document > text content gets filled with decent content. > When you force the coder to enter comments to fil a chapter > introduction, well he/she has no choice. > > Of course it looks like if creating code is twice as complex but in > fact you saved time when you need a system to be > described very precisely. It also insured that comments were > meaningful and in synch. with the code. > That sounds a LOT like Knuth's Literate Programming. Was there influence from that or was this wholly based non your own? joe --~--~-~--~~~---~--~~ 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: Emacs+SLIME+Clojure troubles
Hi Mark, On Wed, Dec 31, 2008 at 4:44 PM, Mark Hoemmen wrote: > I've been having trouble with Emacs + SLIME + Clojure. I've been > using Bill Clementson's setup, and it was working when I fetched all > the required projects via his clj-build script. However, when I > fetched new versions using this script yesterday, Emacs gave me the > following error when I ran "run-clojure": > > error in process filter: Symbol's function definition is void: > slime-redirect-inferior-output > > I get an *inferior-lisp* buffer that works (is hooked to Clojure), and > I can evaluate Clojure buffers, but I don't get a SLIME REPL buffer, > nor does syntax highlighting work (I made sure that font-lock-mode is > set). All of those things worked before. I'm attaching a file > containing the relevant part of my .emacs file. The trouble seems to > be near the end, where the hook after slime connects calls > "slime-redirect-inferior-output". I can't find this function anywhere > in SLIME or in clojure-swank. If I comment out this call, I get > another error saying that > > error in process filter: Symbol's value as variable is void: > slime-repl-mode-map > > and the troubles stay. Anybody know how I could work around the > problem or even fix it altogether? There are currently some "breaking" refactorings that are being done to slime. The slime repl has been moved out to the contribs directory and has to now be explicitly specified when you startup slime. However, the necessary changes to swank-clojure haven't been made yet. Therefore, you can do one of a number of things: 1. Don't upgrade to any slime later than December 22. This is your easiest option at the moment. Jeffrey Chou usually updates swank-clojure pretty quickly when there are bugs or slime changes, so it shouldn't be too long before you can start using the latest cvs slime once again. 2. Use an alternative repl with slime. There are actually 3 different repl's that you can potentially use with slime: a. The inferior-lisp repl that starts up when you launch slime (before Dec 23, it would launch the slime-repl automatically after establishing communications with the underlying Lisp implementation (Clojure in your case). However, post-Dec 23, it will only optionally launch the slime-repl). b. An enhanced inferior-lisp repl that has most of the key bindings that are available in the "normal" slime repl. To enable this, modify your startup to use this line: (slime-setup '(inferior-slime)) instead of the: (slime-setup) line that was in my setup instructions. c. The "normal" slime-repl that has all the bells & whistles (you can't use this one at the moment with the latest slime cvs code) 3. Use an alternative to slime for the time being. I suggested one emacs alternative in a weblog post: http://bc.tech.coop/blog/081118.html If you go with #1, then you don't have to change your setup. If you go with #3, then you lose much of the functionality which you may have grown accustomed to having with slime. If you go with #2a or #2b, you will have to comment out (or remove) any mods that directly reference the slime-repl mode (which is created when 2.c is started up and which is the one that is started automatically by pre-Dec23 versions of slime). In your specific case, you will have to comment out lines in your setup as follows: (add-hook 'slime-connected-hook (lambda () ;(slime-redirect-inferior-output) (define-key slime-mode-map (kbd "") 'newline-and-indent) (define-key slime-mode-map (kbd "C-j") 'newline) (define-key slime-mode-map (kbd "C-c b") 'slime-browse-local-javadoc) ;(define-key slime-repl-mode-map (kbd "C-c b") 'slime-browse-local-javadoc) (define-key slime-mode-map (kbd "C-c d") 'slime-java-describe) ;(define-key slime-repl-mode-map (kbd "C-c d") 'slime-java-describe) (define-key slime-mode-map (kbd "C-c D") 'slime-javadoc) ;(define-key slime-repl-mode-map (kbd "C-c D") 'slime-javadoc) )) You could change the slime-repl-mode-map entries to instead refer to the equivalent inferior-lisp repl mode map; however, you'll just have to change them back again when slime-repl becomes available again. So, I recommend you stick with #1 until swank-clojure is updated as necessary. The slime-repl has more features/functionality than the inferior-lisp repl alternatives. Hope that helps and that my explanation wasn't more information than you really wanted. ;-) -- Bill Clementson --~--~-~--~~~---~--~~ 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 ema
Re: How to encapsulate local state in closures
> On Dec 30, 2008, at 6:29 PM, Mark Engelberg wrote: > Use Case #1: Implementing classic imperative algorithm (GDC) I replaced your (atoms) using (with-local-vars) and the function runs perfectly fine. The local vars are not closed over, so they cannot leak, and the code is cleaner. So this example isn't a case for atom- set in my opinion. > Use Case #2: setting up mutually referential data structures The visible choices are ref and atom. Atoms are non transactional/coordinated. Atoms can only be set by providing a modifying function. Lets look at an imaginary example if you were able to set them: (atom-set a (+ @a (* @a @a))) The value of @a can actually change halfway through evaluating (+ @a (* @a @a)) giving a misleading result. Consistency is maintained but the semantics are deceptive. The atom could be set to any combination of old value and new value run through that function. atom-set encourages transactional style statements without their guarantees. Instead there is swap! which reads the current value, applies the function to it, and will only commit the result if the atom has not changed. If another thread has changed the value, it will retry until successful. (swap! a + (* @a @a)) is just as deceptive. Because swap! is a function, (* @a @a) is evaluated before swap! is called, resulting in the exact same race condition described with atom-set. It is unnecessary to use @a with swap! because the correct value of the atom to use is passed in to the function you provide to swap! The correct way to write this particular example would be: (swap! a #(+ %1 (* %1 %1))) It is very easy to define an efficient atom-set: (defn atom-set [a val] (.set a val) val) But there is no way to prevent users doing things like (atom-set a (inc @)) which is incorrect. Neither can swap! prevent users from dereferencing the target atom, however there is a clear distinction in the access method which reminds and encourages correct usage. > It would be entirely reasonable to want to, under certain conditions, > to reset the counter to 0. When you reset to 0, that's just a > straight write. Having to say (swap! counter (constantly 0)) feels > convoluted, and somewhat obscures the fact that this change is not > dependent on the previous state of the atom. Furthermore, by having > to represent this reset as a swap, the counter reset might not happen > as quickly as one would like. If there is a lot of contention and > other threads are in the process of incrementing the counter, the > reset might fail to go through for a while, because the value is > frequently changed by other threads between the unnecessary read and > the write of 0. An atom-set would not only reflect the intentions of > the code better, but would provide better performance for the times > where a read is irrelevant to the value being written. (.set a 0) Provides precisely the behavior you describe. Unfortunately It is not obvious that this is the case unless you look up the java docs. http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.html Perhaps the swap! doc string should explicitly describe the danger: "The function passed to swap should not enclose the current atom value as this may create a race condition, instead it should always take the atom value as an argument. There is no ref-set as it would likely promote such usage. You can set atoms by calling the java .set method, but remember that the current atom value should not be used to set a new value." On Dec 31 2008, 2:19 pm, Pinocchio wrote: > 1) It is possible to get "internally" mutable state using > with-local-vars and var-set. The problem here is that the "internal" > state cannot be operated on my multiple threads concurrently. Thus > functions defined this way will not automatically scale on multi-cores. > One may have to be careful while wrapping such state in a closure and > accessing it from multiple threads. However, they *will* allow to > "naturally" write certain algorithms containing local mutation. (with-local-vars) has no multi-threading issues, as they are not shared in any way. To make this true they are not retained in closures: user=> (def f (with-local-vars [a 2] #(+ 1 (var-get a #=(var user/f) user=> (f) java.lang.IllegalStateException: Var null is unbound. (NO_SOURCE_FILE: 0) > 2) It is possible to get "internally" mutable state using clojure arrays > and recur style re-binding. The problem here is that recur style > rebinding may not be expressive enough to "naturally" encode certain > algorithms. Clojure does require you to be explicit about state mutation, but in my view that does not diminish the expressiveness. I'm yet to come across a case where an algorithm can not be directly translated retaining imperative style. > 3) It is possible to get "internally" mutable state using atoms (along > with atom-set for better readability and convenience)... which seems > like a nice suggestion. The problem h
what's the new syntax for (dotimes _ (apply f [i]) (print "*")) ?
Hi all, what's the new syntax for this? It is part of the code below which was translation by Stu. ; using dotimes instead of repeat from cl (defn plot [f min max step] (doseq i (range min max step) (dotimes _ (apply f [i]) (print "*")) (println))) Thanks, Sun --~--~-~--~~~---~--~~ 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: what's the new syntax for (dotimes _ (apply f [i]) (print "*")) ?
On Wed, Dec 31, 2008 at 11:41 PM, wubbie wrote: > > Hi all, > > what's the new syntax for this? > It is part of the code below which was translation by Stu. That's a nifty little function. This just fixes the syntax: (defn plot [f min max step] (doseq [i (range min max step)] (dotimes [_ (apply f [i])] (print "*")) (println))) But we can add features and tightens up the implementation a bit: (defn plot [f & range-args] (doseq [i (apply range range-args)] (println (apply str (replicate (f i) "*") This gets rid of the distracting _ and the extra 'println', and also allows us to use the optional args for 'range': (plot #(* % %) 8) --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: making code readable
It was our own initiative. 4 of us integrated an existing team of developers and they were required to spit out detailed specs at every release. This was a real-time redundant system to control production and transportation of electricity in the province of Quebec. That system had to show up 99.% availability. We have a vast network here, a single utility and the production sites (up north in the James Bay area ) are far from the consumers (mostly south near the St-Lawrence river). The software to control this as to be resilient otherwise the whole network can come down even if the network control is distributed in several centres. The idea of "duplicating" the content of the code in a document seemed to us a waste of time and money. So we came out with this tool. We had a significant number of modules to add to the existing system and many modifications to existing modules. Saved us many hours of document editing, reviewing and so on. It proved very efficient. Of course the requirement of having detailed documentation is not always present in most systems. But this one being critical, that requirement was unavoidable. Maybe I should look back at this and see how I could revive it. I used to comment heavily my code in my first ten years or so. I wrote a number of systems in assembly languages (20,000 to 40,000 lines) and it's quite natural to add comments when programming systems of that magnitude. I kept this habit for a long time even in high level languages or not so high level (C). Maybe I should experiment again and see if it's worthwhile. I was rather pissed off by the lacklustre of javadoc, especially when you need to add html tags to get some decent output. Our tools did not need any formatting hints. That was handled when calling the tool. The tags we used were there to indicate the sections forming the document, not the way they were to be presented. They were simple tags inserted at the beginning of a comment line. You could change the rendering of the document when calling the tool. That idea came from SGML that we were using at the time, WYSIWYG was just around the corner but we still had to typeset our documents using SGML tags. With SGML you postpone the presentation issues were they belong, when rendering the document on your laser printer or other rendering device. I may dedicate some time to this. Of course it has to be adapted to the languages used today and coders have to show some willingness to add significant comments to their code. If people are reluctant to do this then such a tool does not have any future : Luc On Wed, 2008-12-31 at 17:23 -0800, Joseph Jones wrote: > > On Dec 31, 2008, at 1:29 PM, Luc Prefontaine wrote: > > > In the mid 80's I and others in a Fortran dev. team created a super > > javadoc. This beast was spitting out a FULL > > document in the editor used by office people. > > > > You would write comments in the code that were extracted and you > > would get a readable well formatted > > document after running the tool. Without the comments, the document > > looked ... empty and ugly. > > Missing items were as obvious as a nose in a face. > > > > Easier for code reviewer to control that, no need to read the code, > > read the document. If it does not make sense > > then go back to the coder. > > > > Coders had to add decent comments since the conventions were not > > only based on what you extract from the code > > (like javadoc) but also what is expected in comments so the document > > text content gets filled with decent content. > > When you force the coder to enter comments to fil a chapter > > introduction, well he/she has no choice. > > > > Of course it looks like if creating code is twice as complex but in > > fact you saved time when you need a system to be > > described very precisely. It also insured that comments were > > meaningful and in synch. with the code. > > > > > That sounds a LOT like Knuth's Literate Programming. Was there > influence from that or was this wholly based non your own? > > joe > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
