Re: ANN: Emacs auto-complete plugin for slime users
Sorry my message got truncated. Let's try again: Fuzzy completion (ac-source-slime-fuzzy) isn't working for me. It complains that the function slime-fuzzy-completions is not defined. I'm using slime.el version 2010404, which does not define that function, although it does define slime-simple-completions. Not sure if there's a newer version of slime.el out there but I did install fresh about a week or two ago. Not to worry; I'm very happy with ac-source-slime-simple. Steve On Tue, Aug 17, 2010 at 3:17 PM, Steve Molitor wrote: > This is great, thanks! > > Fuzzy completion (ac-source-slime-fuzzy) isn't working for me. It > complains that slime-fuzzy-comp > > On Sat, Aug 14, 2010 at 5:19 AM, Steve Purcell wrote: > >> Hi all, >> >> A while ago I hooked Slime's completion and documentation features into >> the popular Emacs auto-completion framework "auto-complete" ( >> http://www.emacswiki.org/emacs/AutoComplete). >> >> Since it may be of interest to others, I've released the completion plugin >> on github: http://github.com/purcell/ac-slime >> >> Here's a screenshot of the plugin in action in a clojure-mode buffer, >> showing the (very handy) pop-up documentation: >> >> >> >> >> >> >> -Steve >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Emacs auto-complete plugin for slime users
This is great, thanks! Fuzzy completion (ac-source-slime-fuzzy) isn't working for me. It complains that slime-fuzzy-comp On Sat, Aug 14, 2010 at 5:19 AM, Steve Purcell wrote: > Hi all, > > A while ago I hooked Slime's completion and documentation features into the > popular Emacs auto-completion framework "auto-complete" ( > http://www.emacswiki.org/emacs/AutoComplete). > > Since it may be of interest to others, I've released the completion plugin > on github: http://github.com/purcell/ac-slime > > Here's a screenshot of the plugin in action in a clojure-mode buffer, > showing the (very handy) pop-up documentation: > > > > > > > -Steve > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: question on clojure library coding standards
Different topic, but are you talking about fields in a record defined via defrecord? I thought those fields were not hidden (i.e. 'public'). "Encapsulation of information is folly" as it says here: http://clojure.org/datatypes. I agree with your point. Maybe a wee bit of encapsulation of information isn't always folly! Steve On Tue, Aug 17, 2010 at 9:29 AM, Meikel Brandmeyer wrote: > Hi, > > On 17 Aug., 04:40, cageface wrote: > > > I'm not entirely sure how to interpret this. If a function is > > expecting a certain argument structure, isn't it always better to > > document that in a destructuring argument list? I'm finding that > > destructured signatures generally help me track my dataflow better. > > Can somebody elucidate this distinction a bit? > > It can overspecify things. Consider private fields of a record. The > user should not fiddle with these, but you might well access them in > your function. That you do so should be not of interest to the caller. > Specifying it in the argument list would actually expose the caller to > the details. So the details become part of the contract and you cannot > change the internal workings of your library anymore. > > Sincerely > Meikel > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Records can't be treated as functions anymore
Maybe I"m just getting stuck on semantics, but I'm confused. If maps are collections, and records function as maps, aren't records also collections? Steve On Thu, Aug 5, 2010 at 8:52 AM, Stuart Halloway wrote: > If records implemented IFn, you could treat them as collections, which they > are not. There is an asymmetry here: Maps can be used as (impoverished but > easy) records, but the reverse is not true: > > (:foo x) ; x is logically a record (though might be a map for simplicity). > (x :foo) ; x is a collection (not a record, entity, etc.) > > Records not implementing IFn forces you to do what you should do anyway -- > access records with the keyword first. > > Stu > > >> Hi BG, >> It is a common mistake to think that callability, corresponding to the >> clojure.lang.IFn interface, is part of the persistent map contract >> (I've done it myself, as did many others a Conj labs :). It is not. It >> is actually just a feature of clojure.lang.PersistentHashMap (and the >> other clojure map implementations). >> >> > While I get that part, I wonder why records do not implement IFn, it'd be > convenient if they did. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Command line debugging
Sorry if this has already been answered, but what's the best recipe for getting a command line debugger going with clojure 1.2 snapshots? I've read about debug-repl and other solutions but I'm not sure what works with 1.2. Thanks, Steve -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Let's respect CLOJURE_HOME
>> the true launcher will always be the java JVM executable, and I'm >> not sure this is something we should really try and hide. I think it should be hidden, at least for newbies. Maven hides it - I invoke 'mvn' and have no idea how it invokes java. I don't know what jars it puts in the classpath, etc., and I don't need to know. Lein hides it too and I like that. Ideally a clojure installation package would include lein and a launcher that utilized lein for clojure-contrib.jar etc. Steve On Wed, Jun 30, 2010 at 4:17 PM, Rick Moynihan wrote: > On 30 June 2010 21:14, Brian Schlining wrote: > >> > >> > > >> > May I propose as a possible remedy CLOJURE_HOME. CLOJURE_HOME is the > >> > absolute path of a directory containing clojure.jar and possibly > >> > clojure-contrib.jar. Scripts should check if it's defined and use it > instead > >> > of hard-coded paths, as an example, here's my clj script (in newLISP): > >> > >> On the face of it this seems like a good idea, however it doesn't > >> really fit with the models used by tools such as leiningen, mvn or the > >> JVM. At best a CLOJURE_HOME initiative can only expect to work within > >> its own world of clj scripts etc. > > > > I can't speak for leiningen but many (most?) launcher script in the Java > > world use this as a standard convention. If you look through the launcher > > scripts for maven, groovy, scala, ant, etc you will see environment > > variables JAVA_HOME, M2_HOME (for Maven 2), GROOVY_HOME, SCALA_HOME and > > ANT_HOME. > > This is true. And I agree that where scripts are used this technique > can be useful. And in this regard it's a good convention. > > However, I don't see it helping newcomers to Clojure significantly, as > the classpath issues people face are the deeper issue. Also teaching > newcomers that this is the convention isn't really true, as tools like > Lieningen or maven don't really fit with this approach as they treat > the clojure platform as just another library dependency. > > Clojure doesn't yet have a standard launch script. In the past I've > argued that it'd be nice if it had one, though I now feel lein/mvn are > better tools for this job. That said, having a clj launch script can > be useful, and might ease the out of box experience, but again the > true launcher will always be the java JVM executable, and I'm not sure > this is something we should really try and hide. > > R. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Let's respect CLOJURE_HOME
JRuby uses JRUBY_HOME, which contains jruby.jar, a few other other essential jars and gems, and any locally installed gems. (Gems are ruby's packaging mechanism.) It also includes a jruby (jruby.bat on windows) executable script. This script parses command line args, sets up the classpath using JRUBY_HOME, and if the first arg is a ruby file, evaluates that file. It supports options for adding to the 'include path'. I'm not sure but I think groovy does something similar. If something similar were created for clojure, newbie instructions might look like this. 1. Download and unpack clojure-for-newbies.zip 2. Add clojure-for-newbies/bin to your PATH. 3. Create hello_world.clj with the following contents: (println "hello world") 4. Type 'clojure hello_world.clj' to invoke your script The 'clojure' script could also support options for adding jars and .clj files to the class/load path. With this approach a newbie could go a long way without having to worry about lein/maven, projects, packaging, compiling, etc. On the other hand I did find it very easy to get started with lein (can't remember how to spell its full name). I love 'lein repl' (in spite of its current limitations) - very newbie friendly for me as I could start experimenting right away. I have found clojure to be pretty newbie friendly, but I do come from a Java background. Steve On Wed, Jun 30, 2010 at 3:14 PM, Brian Schlining wrote: > >> > >> > May I propose as a possible remedy CLOJURE_HOME. CLOJURE_HOME is the >> absolute path of a directory containing clojure.jar and possibly >> clojure-contrib.jar. Scripts should check if it's defined and use it instead >> of hard-coded paths, as an example, here's my clj script (in newLISP): >> >> On the face of it this seems like a good idea, however it doesn't >> really fit with the models used by tools such as leiningen, mvn or the >> JVM. At best a CLOJURE_HOME initiative can only expect to work within >> its own world of clj scripts etc. >> > > I can't speak for leiningen but many (most?) launcher script in the Java > world use this as a standard convention. If you look through the launcher > scripts for maven, groovy, scala, ant, etc you will see environment > variables JAVA_HOME, M2_HOME (for Maven 2), GROOVY_HOME, SCALA_HOME and > ANT_HOME. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: the joys of lisp
On Tue, Jun 29, 2010 at 8:03 AM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > You might also note that lisp behaves the same way as python - at least > outside of macros. As noted in the last paragraph, the paper isn't about > lisp vs other languages, its about readability vs "power as terseness". > The examples just happened to pick on a feature heavily associated with lisp. Agreed. I'm not defending Common LISP - I've never used it and don't plan to. But Clojure is also a LISP. Comparisons to Clojure are more relevant to me (and this mailing list). I was responding to your remark that LISP "is held up as an example of how badly wrong allowing anyone to create statements can go." I think the paper actually demonstrates that allowing that *in a mutable language* can go badly wrong. I think the paper implicitly (and perhaps unintentionally) makes an argument against hidden side effects in general. If you care about readability you should appreciate a language restricts mutability - call it 'the functional(ish) way'. Steve > "Steve Molitor" wrote: > > >> The Python approach leads to more readable > >>code: http://www.mired.org/home/mwm/papers/readability.html > > > >The two cases he sites do not apply to Clojure: > > More accurately, the problem being analyzed (a variable changing to a bad > value) can't happen in clojure. It has to have been bound with a bad value. > > >The first case is a function that is allowed to change the value of a > >variable passed into it. Variables are immutable in Clojure so you can't > >write the dangerous 'inc' function he describes. You can't change the > value > >of a variable passed to a function in Python either, but you can pass a > >mutable object to a function and have the function modify the object, > which > >is close to the same thing. Clojure is much more readable than Python in > >this regard. > > You might also note that lisp behaves the same way as python - at least > outside of macros. As noted in the last paragraph, the paper isn't about > lisp vs other languages, its about readability vs "power as terseness". The > examples just happened to pick on a feature heavily associated with lisp. > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: the joys of lisp
> The Python approach leads to more readable >code: http://www.mired.org/home/mwm/papers/readability.html The two cases he sites do not apply to Clojure: The first case is a function that is allowed to change the value of a variable passed into it. Variables are immutable in Clojure so you can't write the dangerous 'inc' function he describes. You can't change the value of a variable passed to a function in Python either, but you can pass a mutable object to a function and have the function modify the object, which is close to the same thing. Clojure is much more readable than Python in this regard. The second case is a function that is allowed to change the order of evaluation of its arguments, decide how many times to evaluate its arguments, and even whether or not to evaluate an argument at all. True, in a language that allows side effects this can be confusing. But this doesn't apply to Clojure. (Clojure does allow side effects through STM of course, but this is very explicit and controlled - more readable.) I agree that macros can in some cases lead to less readable code. On the other hand, mutability hurts readability too. Steve On Mon, Jun 28, 2010 at 2:04 PM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > On Mon, 28 Jun 2010 11:21:24 -0700 (PDT) > cageface wrote: > > > On Jun 28, 11:09 am, Daniel Gagnon wrote: > > > That feature would *not* be a simple macro. It isn't simply a call to > .close > > > on whatever object, it's an arbitrary cleanup procedure on any object > that > > > implements the feature. The whole standard library implements it and > objects > > > know how to clean after themselves. So do most third objects like > database > > > connexions and what not. > > > > So in order to make this work in Python the *entire* standard library > > had to be modified to support it? That's worse than I thought. > > No, only those that wanted to take advantage of it. > > > It's an interesting point though. In a certain sense, a macro is > > establishing an interface across a set of objects. In writing a macro > > you are implying that there exists a set of objects for which the > > macro's transformation is logical. The python "with" statement > > required implementation of the implied interface across all valid > > arguments, whereas the macro version takes advantage of the fact that > > most of the applicable objects just happen to have a .close method. In > > both cases you're dealing with "with-able" objects. The difference is > > that the "interface" that objects can expose to macros is much richer > > because arbitrary syntactic fragments are "objects" in this sense. > > You're making a false assumption. Most of the valid library objects > *didn't* have a ".close" method. The decimal library was tweaked to > allow the with statement to create a new context, and automatically > restore the previous one. The various forms of locking things were all > tweaked so that you could use the with statement to acquire a lock > that was released on exit. > > These things could have been done with a simple macro, but would have > required tweaking the library to add a "close" function for the > objects, even if the function name made no semantic sense. Either > that, or use a different name for the function, and then go through > and rewrite "the *entire* standard library" to take advantage of it. > > > The python approach is superior if you believe, as Guido apparently > > does, that the useful set of syntactic constructs is small and well- > > bounded. If you think, as most lispers do, that syntactic manipulation > > is the essence of expressive power then the work it takes to add *one* > > new keyword to a language like python seems farcical. > > The Python approach leads to more readable code: > http://www.mired.org/home/mwm/papers/readability.html > > -- > Mike Meyer > http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Hiring again - need 3 devs before fall 2010
Tim, I just sent my resume to j...@sonian.net. Thanks! Steve Molitor On Wed, Jun 23, 2010 at 12:02 PM, Tim Dysinger wrote: > Sorry I didn't provide enough detail on that last post. Please send > your interest to jobs on sonian.net with "clojure" in the subject. > > On Wed, Jun 23, 2010 at 8:24 AM, Tim Dysinger wrote: > > Hello, > > > > It's that time again. I need to hire some more full-time > > work-from-home pair-programming emacs/unix/math-loving clojure devs. > > Join our team of 7 devs who write clojure full time. We will be > > bringing on a dev a month over the summer. The ideal candidate has > > some unix, jvm & coljure/lisp/fp experience under his/her belt (her! - > > we need more diversity) and is a fun person to work with (no grumpy or > > solo types). > > > > Job comes with a macbook pro & 3g so you can work anywhere (in the > > US). We aren't hiring out-of-country right now. > > > > Tim Dysinger, VP Eng. > > Sonian Networks [ http://sonian.com ] > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Weird problem with lazy seqs and throwing exceptions
That did the trick, thanks. Steve On Thu, Jun 24, 2010 at 9:43 AM, Meikel Brandmeyer wrote: > Hi, > > On Jun 24, 6:34 am, Steve Molitor wrote: > > > user=> (throw (java.lang.Exception. (str "Whoops: " messages))) > > java.lang.Exception: Whoops: clojure.lang.lazy...@13291(NO_SOURCE_FILE:0) > > Wrap messages into a call to seq. > > Sincerely > Meikel > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Weird problem with lazy seqs and throwing exceptions
I'm having trouble throwing an exception with the error message I want from a list of error codes. Here's a simple example of the problem: (def messages (map #(str %) [1 2 3])) (println messages) (throw (java.lang.Exception. (str "Whoops: " messages))) The println prints the messages just fine - I see "1 2 3". However the exception message contains something like 'clojure.lang.lazy...@13291' instead of "1 2 3". Here's a REPL session: user=> (def messages (map #(str %) [1 2 3])) #'user/messages user=> (println messages) (1 2 3) nil user=> (throw (java.lang.Exception. (str "Whoops: " messages))) java.lang.Exception: Whoops: clojure.lang.lazy...@13291 (NO_SOURCE_FILE:0) What am I missing? I want the exception message to display as "Whoops: 1 2 3". This happens with clojure 1.1 and a recent snapshot of 1.2. Thanks. Steve -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why does clojure-http stores cookies in a ref instead of an atom
Thanks for the reply. I wasn't trying to be critical. I have a similar situation where I'm using an atom instead of a ref, and wanted to make sure I wasn't missing anything in my understanding of refs vs. atoms. I am using clojure-http currently and it works quite well, thank you! It's very easy to use. Also I've learned a lot by looking at the code, which is clear and well written. Steve On Mon, Jun 14, 2010 at 4:56 PM, Phil Hagelberg wrote: > On Fri, Jun 11, 2010 at 8:45 AM, Steve Molitor > wrote: > > I'm a clojure newbie trying to understand when to use atoms versus refs. > > In clojure-http.resourcefully, if you use the with-cookies macro stores > the > > cookies in a thread local ref. Why a ref and not an atom? My impression > is > > that refs are for when you need to coordinate changes to more than one > > variable, or maybe if you need triggered validations. > > Actually you're correct; an atom would be better here. I wrote that > code a long time ago and haven't used or looked at it since, but > there's absolutely no reason to pull in the STM for state changes 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 > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Why does clojure-http stores cookies in a ref instead of an atom
I'm a clojure newbie trying to understand when to use atoms versus refs. In clojure-http.resourcefully, if you use the with-cookies macro stores the cookies in a thread local ref. Why a ref and not an atom? My impression is that refs are for when you need to coordinate changes to more than one variable, or maybe if you need triggered validations. Thanks, Steve -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: review the clojure.string code
Whoops should have said: upper-case-ay ower-case-lay eft-trim-lay ight-trim-ray Or something like that. Steve On Thu, Jun 3, 2010 at 9:16 AM, Steve Molitor wrote: > How about: > > pper-case-uay > ower-case-ay > eft-trim-lay > ight-trim-lay > >and so on... > > Steve > > > On Wed, Jun 2, 2010 at 10:49 AM, Tom Hickey wrote: > >> Including a space is correct when changing a string "to upper >> case" (hence Java's toUpperCase), though no space would be fine there >> as well. >> >> As a verb, "uppercase" (no space) is correct. So the function should >> either match java and be called to-upper-case or (preferably, IMO) >> simply be uppercase. >> >> Tom >> >> On May 30, 11:23 pm, Stuart Halloway >> wrote: >> > But they can be separate words, and Java treats them so (.toUpperCase, >> .toLowerCase). >> > >> > Stu >> > >> > >> > >> > > Also, according to Merriam-Webster, uppercase and lowercase don't have >> > > hyphens in them. >> > >> > > RJ >> > >> > > On May 30, 3:49 pm, Stuart Halloway >> wrote: >> > >> I have been working on a branch [1] and haven't updated the ticket >> yet [2]. Given the number of diverse (and sometimes opposite!) opinions >> already expressed on this topic, I thought a little extra community review >> would be in order. David and I organized the work into several fairly small >> commits so you can grab the branch and see the individual decisions being >> made. >> > >> > >> Thanks! >> > >> Stu >> > >> > >> [1]http://github.com/stuarthalloway/clojure/tree/string >> > >> [2] >> https://www.assembla.com/spaces/clojure/tickets/359-promote-contrib-s... >> > >> > > -- >> > > You received this message because you are subscribed to the Google >> > > Groups "Clojure" group. >> > > To post to this group, send email to clojure@googlegroups.com >> > > Note that posts from new members are moderated - please be patient >> with your first post. >> > > To unsubscribe from this group, send email to >> > > clojure+unsubscr...@googlegroups.com >> > > For more options, visit this group at >> > >http://groups.google.com/group/clojure?hl=en >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: review the clojure.string code
How about: pper-case-uay ower-case-ay eft-trim-lay ight-trim-lay and so on... Steve On Wed, Jun 2, 2010 at 10:49 AM, Tom Hickey wrote: > Including a space is correct when changing a string "to upper > case" (hence Java's toUpperCase), though no space would be fine there > as well. > > As a verb, "uppercase" (no space) is correct. So the function should > either match java and be called to-upper-case or (preferably, IMO) > simply be uppercase. > > Tom > > On May 30, 11:23 pm, Stuart Halloway > wrote: > > But they can be separate words, and Java treats them so (.toUpperCase, > .toLowerCase). > > > > Stu > > > > > > > > > Also, according to Merriam-Webster, uppercase and lowercase don't have > > > hyphens in them. > > > > > RJ > > > > > On May 30, 3:49 pm, Stuart Halloway wrote: > > >> I have been working on a branch [1] and haven't updated the ticket yet > [2]. Given the number of diverse (and sometimes opposite!) opinions already > expressed on this topic, I thought a little extra community review would be > in order. David and I organized the work into several fairly small commits > so you can grab the branch and see the individual decisions being made. > > > > >> Thanks! > > >> Stu > > > > >> [1]http://github.com/stuarthalloway/clojure/tree/string > > >> [2] > https://www.assembla.com/spaces/clojure/tickets/359-promote-contrib-s... > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > your first post. > > > To unsubscribe from this group, send email to > > > clojure+unsubscr...@googlegroups.com > > > For more options, visit this group at > > >http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Emacs - Problem with running tests (yes I installed with ELPA)
The version of slime I am using (20100404) doesn't define any
slime-redirect-inferior-output function. Perhaps it has been renamed?
Steve
On Wed, Jun 2, 2010 at 1:06 PM, Karsten Lang wrote:
> I don't suppose
>
> (add-hook 'slime-connected-hook 'slime-redirect-inferior-output)
>
> would work?
>
> On Tue, Jun 1, 2010 at 11:00 PM, Paul Hobbs wrote:
> > I have a similar issue whenever I try to print anything from slime.
> > --
> > Paul Hobbs
> >
> >
> > On Mon, May 31, 2010 at 11:41 PM, Steve Molitor
> > wrote:
> >>
> >> When I run clojure-test-run-tests I can't see the intermediate test
> >> output. Messages like the following flash by as the tests run:
> >>
> >>error in process filter: Elisp destructure-case failed: (:write-
> >> string "Testing my-stuff"))
> >>
> >> I do see the final message: "Ran 3 test. 0 failures, 0 errors". If
> >> there are failures or errors the offending lines are correctly
> >> highlighted in the source, but I can't see the error/failure message
> >> (these would have flashed by very quickly with the 'error in process
> >> filter' messages).
> >>
> >> I think it's a problem with slime evaluation. Clojure-test-mode calls
> >> slime-eval-async when the problem occurs. I can cause the same issue
> >> when I manually run slime-interactive-eval ("C-c C-e") with the
> >> expression (clojure.test/run-tests). The tests run but "error in
> >> process filter: Elisp destructure-case failed" messages fly by.
> >>
> >> I am using the test-is library. I'm using GNU Emacs 23.1.90.1 with
> >> clojure packages that I installed today via ELPA. (I installed
> >> clojure-test-mode, and its dependencies included clojure-mode, slime,
> >> etc.)
> >>
> >> Thanks,
> >>
> >> Steve
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Emacs - Problem with running tests (yes I installed with ELPA)
When I run clojure-test-run-tests I can't see the intermediate test
output. Messages like the following flash by as the tests run:
error in process filter: Elisp destructure-case failed: (:write-
string "Testing my-stuff"))
I do see the final message: "Ran 3 test. 0 failures, 0 errors". If
there are failures or errors the offending lines are correctly
highlighted in the source, but I can't see the error/failure message
(these would have flashed by very quickly with the 'error in process
filter' messages).
I think it's a problem with slime evaluation. Clojure-test-mode calls
slime-eval-async when the problem occurs. I can cause the same issue
when I manually run slime-interactive-eval ("C-c C-e") with the
expression (clojure.test/run-tests). The tests run but "error in
process filter: Elisp destructure-case failed" messages fly by.
I am using the test-is library. I'm using GNU Emacs 23.1.90.1 with
clojure packages that I installed today via ELPA. (I installed
clojure-test-mode, and its dependencies included clojure-mode, slime,
etc.)
Thanks,
Steve
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
