Re: Swank, ELPA and Emacs version do you use?
On Sat, Mar 20, 2010 at 2:46 PM, alux alu...@googlemail.com wrote: Sorry to have so many questions. I lookes at swank at github, it says it supports Emacs 23 and up; and I should use ELPA to install it. The ELPA install page, explains how to install stuff for Emacs 21 and 22. As far as I understand, the Emacs init files dont support the usage of different EMacs versions. So which Emacs version do you use? I've used swank with Emacs 22 without any problems so far. Emacs 22 is installed by default on my Mac and I haven't bothered upgrading to 23 yet. If you have a choice you should probably start with 23. -- Cosmin Stejerean http://offbytwo.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
On Sun, Mar 21, 2010 at 5:05 PM, Stuart Sierra the.stuart.sie...@gmail.comwrote: I agree that the Clojure first-run experience is too rough. Both Scala and JRuby, for example, are complete packages that you can download, unzip, install, and run -- on any platform -- without knowing anything about Java. Clojure needs to provide the same experience, even if it only matters for first-time users. I have a project on github that I think comes pretty close. I created it so I can have separate clojure environments for different projects without having to muck with lein or maven (not to mention neither lein or clojure-mavne-plugin were available at the time AFAIK). I still find this the quickest way to get Clojure working on a new machine.I would appreciate any feedback. http://github.com/offbytwo/cljenv -- Cosmin Stejerean http://offbytwo.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
On Sun, Mar 21, 2010 at 6:55 PM, Mike K mbk.li...@gmail.com wrote: I would appreciate any feedback. According to the readme it requires bash or zsh. Any plans to support windows (without cygwin or other unix emulation)? I agree with Stuart that the user experience should be friendly on all supported platforms. I don't have a Windows machine so I can't easily add Windows support. I'm assuming that what I'm doing with Bash should be possible to accomplish in Windows, perhaps using BATCH scripts. Patches/pull requests are welcome :) -- Cosmin Stejerean http://offbytwo.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
On Sun, Mar 21, 2010 at 10:20 PM, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Yes we could have a complete package to run Clojure from the shell command line but how far could someone go with this to build a workable system without an IDE ? [...] Comments anyone ? I can get pretty far writing an application in Python with nothing more than good command line support and syntax highlighting in any text editor. Anything extra like completions, refactoring, etc, are just nice-to-haves. I don't see why an IDE is required for writing workable Clojure apps. -- Cosmin Stejerean http://offbytwo.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: ClojureCLR status?
On Fri, Feb 26, 2010 at 6:44 AM, dmiller dmiller2...@gmail.com wrote: Two factors: (1) I'm working on deftype/protocols/reify and related things. This requires some non-trivial re-engineering of the compiler (based on non- trivial reverse-engineering of all the changes made to Clojure JVM). (2) I'm up to my nostrils on a little pro bono web site development I foolishly agreed to do. Say the phrases crunch time and flop sweat over and over again, and you'll have an idea where I am on that. It's definitely slowed me down. I'm trying to keep a small flow of work going on ClojureCLR during this time. Unfortunately, since I'm working on such big chunks, it looks like nothing is happening. Reify is about 90% done, and I've already made a few changes in support of deftype. If I get a little ahead on the other project, I should be able to get reify done in the next week. After that, deftype and protocols. Right after I commit the reify changes, I may take a day to run through all the small commits on the 1.2 branch. That usually doesn't take long. Should I make heartbeat commits once a week so people will know there's still life in the body? :) I vote for checking in once in a while, perhaps on a separate development branch. -- Cosmin Stejerean http://offbytwo.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-contrib on build.clojure.org
On Fri, Feb 26, 2010 at 12:34 PM, Wilson MacGyver wmacgy...@gmail.com wrote: Hi, Does build.clojure.org have the release version of the clojure-contrib? I only see the release version of clojure itself at http://build.clojure.org/snapshots/org/clojure/clojure/1.1.0/ but for clojure-contrib I only see snapshots at http://build.clojure.org/snapshots/org/clojure/clojure-contrib/ The release jars are at http://build.clojure.org/releases/org/clojure/clojure-contrib/ -- Cosmin Stejerean http://offbytwo.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Sweeping Networks with Clojure
On Wed, Jul 22, 2009 at 9:56 PM, tmountain tinymount...@gmail.com wrote: I've written a short blog post on using Clojure to search for available ssh servers on my companies VPN. It starts with a single- threaded example and then adds concurrency. The performance difference in this case was pretty extreme. Sweeping 254 hosts in a serial single- threaded fashion took twelve minutes with a network timeout of five seconds per host. Adding concurrency resulted in a full sweep in six seconds. If nothing else, I guess this is a good illustration of what a huge win concurrency can performance wise. I initially tried to use pmap to parallelize the connections, but it didn't provide any improvement (maybe I did it wrong?). pmap will only use 1 thread per CPU/core, and therefore is only useful for computationally intensive functions. send-off definitely sounds like the right solution for this type of problem. -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: EY map reduce contest
On Wed, Jul 15, 2009 at 3:53 AM, hosia...@gmail.com hosia...@gmail.comwrote: http://www.engineyard.com/blog/2009/programming-contest-win-iphone-3gs-2k-cloud-credit/ Has anyone got access to hundreds of thousands of machines that I could borrow for 30 hours ? ;) Interesting idea, not sure if anything but a brute force method is possible ? Given the time constraints I don't think even a brute force solution is feasible (for less than the $2000 prize). Looks more like a lottery, but I guess I'll have to wait until after the contest to see if anyone came up with anything clever. -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Confusion on Clojure 1.0, compatible clojure-contrib, git-hub, svn, ...
On Mon, Jul 6, 2009 at 2:59 PM, Laurent PETIT laurent.pe...@gmail.comwrote: I think there could be a way to make both parts happy : rather than just adding the info that it is an old repo in some README file in the root directory of the svn repo, committing also an svn delete command on all the contents of trunk could help clarify this : by default, users checking (or updating !) trunk would have an empty working copy as a result (and also just the informative README file). But tags would still be there, and also the entire repository history, as a svn delete is just deleting files in the commited revision, not deleting the history (one could retrieve a working copy by just emitting svn up -r N-1 where N would be the deletion commit. +1 on a comitting a delete of everything and adding a README file saying the repo has moved. We've had plenty of confusion when switching from SF with people running old code, and now that there are 2 repos around that are no longer maintained I suspect the confusion will only increase. -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Recursive function that does not terminate!
On Wed, Jun 24, 2009 at 6:42 AM, Rich Hickey richhic...@gmail.com wrote:
On Tue, Jun 23, 2009 at 8:02 PM, Stephen C. Gilardisquee...@mac.com
wrote:
On Jun 23, 2009, at 6:22 PM, pupsik wrote:
The following recursive function does not
terminate if I exexute it in my REPL.
What is wrong?
(This example is from the official Clojure-website).
(defn my-zipmap [keys vals]
(loop [my-map {}
my-keys (seq keys)
my-vals (seq vals)]
(if (and my-keys my-vals)
(recur (assoc my-map (first my-keys) (first my-vals))
(rest my-keys)
(rest my-vals))
my-map)))
(my-zipmap [:a :b :c] [1 2 3])
The example needs to be updated for the lazier seqs that were implemented
before the Clojure 1.0 release. As part of that change, we lost nil
punning. rest no longer returns nil if there are no more items. A new
function next does though:
user= (source zipmap)
(defn zipmap
Returns a map with the keys mapped to the corresponding vals.
[keys vals]
(loop [map {}
ks (seq keys)
vs (seq vals)]
(if (and ks vs)
(recur (assoc map (first ks) (first vs))
(next ks)
(next vs))
map)))
nil
Yes, this (Steve's) version, using next and testing directly with (and
ks vs) is the idiomatic way when you are not in turn producing a lazy
seq.
(if-not (or (empty? ks) (empty? vs))
is to be avoided. (No offense Cosmin :)
None taken. As I was writing that code I was wondering why it had to look so
ugly. I completely forgot about next.
--
Cosmin Stejerean
http://offbytwo.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: I must be blind. No matching method found?
On Wed, Jun 24, 2009 at 8:59 PM, CuppoJava patrickli_2...@hotmail.comwrote: Hi guys, I'm having the hardest time figuring out why this won't run. I've been staring at it for the last half hour, and it's only a single line. Another pair of eyes would be beneficial I think. (.substring (StringBuilder. i must be blind) 4) (.substring (StringBuilder. i must be blind) (int 4)) Both give me: java.lang.IllegalArgumentException: No matching method found: substring for class java.lang.StringBuilder Odd, I get the same error running against Clojure 1.0 Clojure 1.0.0- user= (.substring (StringBuilder. i must be blind) 4) java.lang.IllegalArgumentException: No matching method found: substring for class java.lang.StringBuilder (NO_SOURCE_FILE:0) user= (.substring (StringBuilder. i must be blind) (int 4)) java.lang.IllegalArgumentException: No matching method found: substring for class java.lang.StringBuilder (NO_SOURCE_FILE:0) -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Small question: Best way to create a map with vector vals
On Tue, Jun 23, 2009 at 5:09 PM, samppi rbysam...@gmail.com wrote:
The idiom (into {} coll-of-entries) is often used to create a map from
a collection of entries or two-sized vectors. But what if I want to do
something like this:
(mystery-fn [[:a 1] [:b 3] [:b 5] [:c 1]]) ; returns {:a [1], :b [3
5], :c [1]})
(defn mystery-fn [coll] (reduce (fn [map [k v]] (assoc map k (conj (get map
k []) v))) {} coll))
user= (mystery-fn [[:a 1] [:b 3] [:b 5] [:c 1]])
{:c [1], :b [3 5], :a [1]}
--
Cosmin Stejerean
http://offbytwo.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Recursive function that does not terminate!
On Tue, Jun 23, 2009 at 5:22 PM, pupsik an_niko...@yahoo.de wrote:
(defn my-zipmap [keys vals]
(loop [my-map {}
my-keys (seq keys)
my-vals (seq vals)]
(if (and my-keys my-vals)
(recur (assoc my-map (first my-keys) (first my-vals))
(rest my-keys)
(rest my-vals))
my-map)))
Well, it seems like the for loop never terminates. (rest ()) = () and as
far as I can tell an empty sequence is logically true, not false. (if (rest
()) 1 2) = 1 so your if will never hit the else clause.
Here's a version that will do what you expect.
(defn my-zipmap [keys vals]
(loop [my-map {}
my-keys (seq keys)
my-vals (seq vals)]
(if-not (or (empty? my-keys) (empty? my-vals))
(recur (assoc my-map (first my-keys) (first my-vals))
(rest my-keys)
(rest my-vals))
my-map)))
user= (my-zipmap [:a :b :c] [1 2 3])
{:c 3, :b 2, :a 1}
--
Cosmin Stejerean
http://offbytwo.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: accum
On Wed, Jun 17, 2009 at 12:51 PM, Wrexsoul d2387...@bsnow.net wrote: Even though clojure.contrib hasn't been released as 1.0 or anything official-sounding, I reckon it still beats the heck out of me reinventing the wheel, especially with the calibre of folks who've contributed to clojure.contrib. If you don't feel comfortable with the offerings in clojure.contrib, that's fine also. The two concerns I have are: 1. Lack of a source release, at least in a form that you can just download from Firefox, unzip with Winzip, and compile with ant. By the way, there is a Download button on http://github.com/richhickey/clojure/tree/master and http://github.com/richhickey/clojure-contrib/tree/master that allows you to download a snapshot in zip or tgz formats. -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Status of Clojure on .NET?
On Tue, Jun 9, 2009 at 8:31 PM, John Z-Bo Zabroski johnzabro...@gmail.com wrote: I am basically in love with Clojure. It fixes everything I ever found annoying about Lisp dialects, except for type safety (which I can live without for many scenarios). But I feel like my love is unrequited: Clojure is a JVM language, and all my core libraries at .NET. The rest of this post discusses what options exist today for running Clojure on the CLR. Options: - IKVM.NET is a JVM implementation on top of .NET; it can therefore load clojure and its libraries - David Miller's ClojureCLR; Last Updated May 31st, 2009; http://github.com/dmiller/ClojureCLR/tree/master - Stefan Rusek's Xronos; Last Updated ~4 months ago; http://bitbucket.org/stefanrusek/xronos/wiki/Home David Miller's ClojureCLR is, as the name suggests, CLR-based. Stefan Rusek's Xronos is DLR-based. David last posted about the project on the Clojure Google Group on April 27th, 2009: http://groups.google.com/groups/profile?enc_user=uoL2hhUAAABdPRgdaaO0krQLTeyusdD29h3i3SmjGmAJbX05nZ-8fQ There was an updated post to the list from David on May 31st, although it seems to be pretty hard to find using search on the google group. I finally tracked a link to it down by going backwards through the archive and looking at all the threads from May 31st. http://groups.google.com/group/clojure/browse_thread/thread/f3a3cfca94debbac# -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: possible bug?
On Thu, May 21, 2009 at 3:35 AM, Michael Wood esiot...@gmail.com wrote:
On Thu, May 21, 2009 at 9:15 AM, Christophe Grand christo...@cgrand.net
wrote:
Cosmin Stejerean a écrit :
On Wed, May 20, 2009 at 7:04 PM, George Jahad
andr...@blackbirdsystems.net mailto:andr...@blackbirdsystems.net
wrote:
(def s1 (Symbol/create (.intern (first (.split user/n1 /)
will fix your problem.
That makes a lot of sense and I guess I should have paid attention to
the function definition for Symbol/create. Thanks!
You should also use Symbol/intern instead of Symbol/create.
Is Symbol/create or Symbol/intern necessary? This seems to work:
user= (def s1 (symbol (first (.split user/n1 /
#'user/s1
user= (def s2 (symbol user))
#'user/s2
user= (= s1 s2)
true
user= (class s1)
clojure.lang.Symbol
user= (class s2)
clojure.lang.Symbol
user= (ns-publics s1)
{s2 #'user/s2, s1 #'user/s1}
user= (ns-publics s2)
{s2 #'user/s2, s1 #'user/s1}
user=
I don't know how I missed the symbol function in the API. Thanks.
--
Cosmin Stejerean
http://offbytwo.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
-~--~~~~--~~--~--~---
possible bug?
I have a feeling I'm doing something wrong bug I can't figure it out and I
can't rule out that it's not some kind of bug. I am trying to get the public
vars exposed by a namespace from a string. I am creating a symbol from the
string using Symbol/create and then calling ns-publics. This works just fine
if I create the symbol directly from a string, but it doesn't appear to work
when I create the symbol from the result of String.split(). I tried to
narrow this down to some problem in my code but I just can't figure it out.
Some help would be appreciated.
Example of reproducing this:
user= (import 'clojure.lang.Symbol)
nil
user= (def s1 (Symbol/create (first (.split user/n1 /
#'user/s1
user= (def s2 (Symbol/create user))
#'user/s2
user= (= (first (.split user/n1 /)) user)
true
user= (class (first (.split user/n1 /)))
java.lang.String
user= (ns-publics s1)
java.lang.Exception: No namespace: user found (NO_SOURCE_FILE:0)
user= (ns-publics s2)
{s2 #'user/s2, s1 #'user/s1}
--
Cosmin Stejerean
http://offbytwo.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: possible bug?
On Wed, May 20, 2009 at 7:04 PM, George Jahad andr...@blackbirdsystems.netwrote: Using cljdb I was able to step through the code and see that the problem is that symbol create is expecting an interned string. Changing this: (def s1 (Symbol/create (first (.split user/n1 / to this: (def s1 (Symbol/create (.intern (first (.split user/n1 /) will fix your problem. That makes a lot of sense and I guess I should have paid attention to the function definition for Symbol/create. Thanks! -- Cosmin Stejerean http://offbytwo.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 -~--~~~~--~~--~--~---
Chicago Clojure May meeting at Sully's House on May 20th (tomorrow)
The second Chicago Clojure meetup will focus on a in-depth introduction to Clojure concepts and syntax, presented by Frederick Polgardy. You definitely don’t want to miss this meeting if you’re just getting started with Clojure. If you’re a Clojure expert please come and help us get everyone else up to speed. When: May 20th @7pm Where: Sully’s House at 1501 N Dayton Street (near North Clybourn) There is no need to RSVP for this meeting. We will be meeting in the private area upstairs. No food will be provided this time, but since we’re meeting in a bar there will be plenty of options for food and drinks during the meeting. -- Cosmin Stejerean http://offbytwo.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: Chicago Clojure May meeting at Sully's House on May 20th (tomorrow)
On Tue, May 19, 2009 at 12:58 PM, Michel S. michel.syl...@gmail.com wrote: On May 19, 12:45 pm, Cosmin Stejerean cstejer...@gmail.com wrote: The second Chicago Clojure meetup will focus on a in-depth introduction to Clojure concepts and syntax, presented by Frederick Polgardy. You definitely don’t want to miss this meeting if you’re just getting started with Clojure. If you’re a Clojure expert please come and help us get everyone else up to speed. When: May 20th @7pm Where: Sully’s House at 1501 N Dayton Street (near North Clybourn) Is there a website where archives of past meetings are kept? I'd love to attend if it's not 300 miles away, and would like to see the slides, for pedagogical reasons. Not yet, but that's a great idea. There's a good chance we will start recording most (if not all) future meetings. I'll start encouraging presenters to upload materials to the Google group. Time permitting I'd like to post a write-up of the meeting and links to any relevant materials (and the video once it's up) to onclojure.com. -- Cosmin Stejerean http://offbytwo.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: Git with Google Code
On Wed, Apr 29, 2009 at 3:57 PM, Kevin O'Neill ke...@oneill.id.au wrote: no you have that the wrong way around. windows sucks :) if you dont want to (or can't) use git-svn i maintain a mirror on git hub (http://github.com/kevinoneill/clojure/tree/master). Thanks for maintaining that, it's what I always use to check out Clojure. I'm curious, how frequently is that updated from SVN? (Meaning, what is the longest amount of time a commit can exist in SVN but not in your mirror?) I've never had a problem, but I'd like to know for future reference. -- Cosmin Stejerean http://offbytwo.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: Recursively delete files
On Wed, Apr 22, 2009 at 6:30 PM, Phil Hagelberg p...@hagelb.org wrote: Yeah, I had originally put this in the clojure.contrib.java-utils namespace, which defines file. Not sure if that's the best place for it, but I don't see anything else that would be a better fit. This kind of functionality reminds me of the os module in Python. I propose a similarly sounding namespace under contrib. -- Cosmin Stejerean http://offbytwo.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: The Path to 1.0
On Thu, Apr 16, 2009 at 11:53 AM, Rich Hickey richhic...@gmail.com wrote: [...] - Development process stability Currently all new work (fixes and enhancements) occurs in trunk. There's no way to get fixes without also getting enhancements. I think this is the major missing piece in offering stable numbered releases. While I've cut a branch for each of the prior two releases, no one has ever submitted a bugfix patch for either. If people are going to want to work with a particular release version for an extended period of time, someone (other than me) will have to produce patches of (only!) fixes from the trunk for the release branch, and occasionally produce point releases (1.0.x) from that branch. This is actually something that I am interested in doing (porting fixes from trunk to 1.0) so I would love to help with that process once we get to 1.0 -- Cosmin Stejerean http://offbytwo.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: Contribs with dependencies
On Thu, Apr 16, 2009 at 2:16 AM, Konrad Hinsen konrad.hin...@laposte.netwrote: [...] I think it would be useful to formalize this concept of a standard library that is a single entity from the point of view of users who just want to download a jar file and get going. A standard library would also define certain conventions and APIs and thus prevent future users from having to choose among ten essentially equivalent but yet incompatible libraries for file handling or for XML parsing. Of course there are a couple of open questions: Who decides what goes into the standard library? Who maintains it in the long run? Are external dependencies allowed and if yes, how are they handled? If contrib is to be viewed as a standard library for Clojure then I think it makes perfect sense to allow external dependencies. I don't know of any language with a serious standard library that depends on nothing else. The trick then however is to provide packages for the various platforms that can install clojure, contrib and all of its dependencies so a user that's not interested in hacking on the clojure or contrib source can just get up and running with minimal fuss. That still leaves open the question of how to decide which third party libraries are OK to include as a dependency. That seems to require a more formal process similar to the PEP's in Python. Maybe it's too early for something like that though. -- Cosmin Stejerean http://offbytwo.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: How to compile in AquaMacs without slime? classpath problem for classes
On Mon, Apr 13, 2009 at 12:53 AM, chris cnuern...@gmail.com wrote: If you could set up emacs to be a little bit more project based it would really make things easier. For instance, I like to have jars required for just my project in a lib dir. Right now I add them to the global CLASSPATH and have emacs parse that and set its internal classpath from the environment variable. If you could specify a project (which wouldn't be very difficult at all) meaning a base directory and have emacs auto-setup everthing based on a couple find operations that would really, really be useful. Especially if it responded automatically such that when you dropped new jars you could kill slime and restart and you would be good (although emacs insta-starts on my mac so it isn't a big deal). None of that is hard to do, this is emacs after all. -- Cosmin Stejerean http://offbytwo.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: Got a Clojure user group?
On Thu, Apr 9, 2009 at 2:00 PM, Rich Hickey richhic...@gmail.com wrote: Got a Clojure user group, meetup etc? Reply to this message and let me know, I'll add them to the Clojure site. Chicago http://onclojure.com/chicago/ -- Cosmin Stejerean http://offbytwo.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: Generic functions again
On Tue, Mar 24, 2009 at 5:37 PM, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 24.03.2009 um 22:36 schrieb mikel: CLOS says that if two matches are otherwise equally specific, the one on the left wins. Similarly, it says that if two classes define slots with the same name, the one farthest from the root of the class heterarchy (as defined by a standard traversal algorithm) wins. You can make a theoretical argument that these choices are arbitrary, and that the programmer should control those decisions. In practice, the CLOS approach is not a problem because: Thank you for the long explanation. Please allow me to be sceptical (fatigued and after all long day of work). CLOS is certainly a powerful system, but reading these rules makes me headaches. Interestingly enough the rules described above seem to be exactly how multiple inheritance works in Python, and they seem to me pretty easy to understand. Imagine that you specify interfaces left to right in order of importance, and therefore when a generic function is defined for two of them the leftmost one wins. Should you happen not to remember though you can quickly try out an example at the REPL. I do that all the time in Python when I want to verify that what I remember is in fact correct. -- Cosmin Stejerean http://offbytwo.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: file io
On Tue, Mar 24, 2009 at 10:19 PM, e evier...@gmail.com wrote: I'm interested to know what the process/priority is on bubbling things up from contrib into the core. Is a discussion under way about going through it all? I also think it's good to have cross-language conventions sometimes unless there are compelling reasons. For example, slurp is, perhaps, marginally better than read because it may help express that it reads the whole file. Whereas, in Python, one only knows that read reads the whole file when they compare it to the fact that there is readline(). BUT, basing it on python, yet IMPROVING, I'd advocate for read-all and read-line. Totally consistent AND unambiguous. There's a reason Python's read is called read and not read-all, because it takes an argument for how many bytes to read. This argument just happens to be optional, in which case it will read everything. This is particularly useful when reading data from a binary file where you have to read the data in chunks (and you obviously can't rely on readline). Given that I don't see the need for also having a read-all function. -- Cosmin Stejerean http://offbytwo.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: STM and useful concurrency
On Sun, Mar 22, 2009 at 9:12 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote: I'm trying to understand the degree to which Clojure's STM provides more concurrency than Java's blocking approach. I know it's difficult to make generalizations and that specific applications need to be measured, but I'll give it a go anyway. Clearly using STM (dosync with Refs) makes code easier to write than using Java synchronization because you don't have to determine up front which objects need to be locked. In the Clojure approach, nothing is locked. Changes in the transaction happen to in-transaction values and there is only a small amount of blocking that occurs at the end of the transaction when changes are being committed. Score one for Clojure! What concerns me though is how often the work done in two transactions running in separate threads turns out to be useful work. It seems that it will typically be the case that when two concurrent transactions access the same Refs, one of them will commit and the other will retry. The retry will discard the in-transaction changes that were made to the Refs, essentially rendering the work it did of no value. So there was increased concurrency, but not useful concurrency. In the case where two transactions need to modify the same Ref they definitely to be serialized, either by explicitly using locks in Java, or by letting Clojure automatically retry one of them. In either case it about the same thing happens. Transaction A starts and finishes, then Transaction B starts and finishes. Of course there is a chance that the transaction contains some conditional logic that makes it so the Refs to be accessed aren't always the same, but my speculation is that that's are rare occurrence. It's probably more typical that a transaction always accesses the same set of Refs every time it executes. Which Refs your transactions modify will depend heavily based on the specific application you are working on. For example I can imagine that an application dealing with bank accounts and transferring money between them the probability of two transactions concurrently hitting the same account is pretty low. In other applications where a lot of transactions modify the same global state the chances of conflicts are much higher. This makes it seem that Java's locking approach isn't so bad. Well, it's bad that I have to identify the objects to lock, but it's good that it doesn't waste cycles doing work that will just be thrown away. There's a reason concurrent programming is notoriously hard in most languages, because it takes a lot of effort and skill to get right. Between having to correctly identify which objects need to be locked and trying to avoid deadlocks dealing with explicit locks can be pretty messy and dangerous. That doesn't mean Java's approach is bad, after all the internals of Clojure are implemented using Java locks. But explicit management of locks is often too low level and unnecessarily complex, and Clojure provides a higher level way of dealing with concurrency that makes it easier and safer to work with most of the time. -- Cosmin Stejerean http://offbytwo.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: STM and useful concurrency
On Mon, Mar 23, 2009 at 2:36 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote: In the case where two transactions need to modify the same Ref they definitely to be serialized, either by explicitly using locks in Java, or by letting Clojure automatically retry one of them. In either case it about the same thing happens. Transaction A starts and finishes, then Transaction B starts and finishes. I don't think the same thing happens. In the case of Clojure, both transaction A and B start. Suppose A finishes first and commits. Then transaction B retries, finishes and commits. That's what I was referring to as non-useful work. I'm not saying it's the wrong approach, but it is different. The fact that B is tried once concurrently with A, and is then aborted and retried is in my opinion the same as transaction B being stuck waiting on a lock while A is being processed, but I can see how trying B concurrently with A the first time might waste more resources, and that perhaps for certain applications it locks might have better performance. I agree that Clojure makes the programming much easier, but is there a downside? Maybe the downside is performance. If I found out that a particular transaction was commonly being retried many times, is that a sign that I need to write the code differently? How would I find out that was happening? I know I could insert my own code to track that, but it seems like this may be a commonly needed tool for Clojure to detect excessive conflicts/retries in transactions. Maybe we could set a special variable like *track-retries* that would cause Clojure to produce a text file that describes all the transaction retries that occurred in a particular run of an application. If such a tool isn't needed or wouldn't be useful, I'd like to understand why. I can imagine how in certain situations a profile mode where Clojure keeps track of transaction retries, and maybe even the reason why they happened might be useful. -- Cosmin Stejerean http://offbytwo.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 -~--~~~~--~~--~--~---
Chicago Clojure meetup
If you're in or around Chicago I'd like to invite you to come out for the first meeting of the Chicago Clojure User Group on April 15th. Full details are at http://onclojure.com/chicago/ -- Cosmin Stejerean http://offbytwo.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: swank-clojure: swank-clojure-init-files not used
On Sun, Mar 15, 2009 at 1:41 PM, Tassilo Horn tass...@member.fsf.orgwrote: Hi, I'd like that slime loads ~/.clojure/user.clj when starting the clojure REPL. Therefore I added that file to `swank-clojure-init-files'. This variable is used in `swank-clojure-cmd' to build the java invocation command line. But that didn't work. So I wanted to debug `swank-clojure-cmd' to see what's wrong, but it seems that whole function is never called when I do `M-x slime'. I use the current HEAD versions of both swank-clojure and slime from their respective version control systems. As a workaround you can try adding ~/.clojure to the classpath, Clojure will automatically load user.clj if found on the classpath. -- Cosmin Stejerean http://offbytwo.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: Static type guy trying to convert
On Tue, Mar 10, 2009 at 9:31 PM, Jon Harrop j...@ffconsultancy.com wrote: [...] 2. The whole thing does not need to be complete or even functional for you to start unit testing. Apples and oranges: unit tests are not the same between dynamic and static code bases because dynamic code bases rely upon a huge number of additional unit tests to serve as a poor man's substitute for static type checking. I'd love to see some evidence to support this claim of huge number of additional unit tests. Unit tests are there to check that a small part of a program behaves correctly under expected conditions. Static type checking only guards against a small set of errors in program correctness, primarily the accidental use of a wrong type. In a dynamically typed language there are two ways to deal with this: a) add explicit type checks at runtime to guard against an invalid type b) add unit tests to verify that the explicit type checks work as expected. The increase in unit testing therefore is directly related to number of areas where I am concerned about receiving an improper type that must be explicitly guarded against. For example in Python strings are iterable, but in a lot of functions that expect an iterable object receiving a string is often a sign of a mistake, so I have a few of those functions explicitly check that they are not dealing with strings. Situations like these are rare however so I've never seen a significant increase in unit testing to compensate for lack of static type checking. [...] 4. Not having the static type system means that if it's ever needed, it will be possible for you to do what you know is right instead of what the compiler wants. You are assuming that what you know is right and what the compiler wants are different. IME, that is virtually unheard of in real code. Actually it happens a lot in real code and in many non-trivial programs in static typed languages you end up with a proliferation of types that are simply there to make the compiler happy. To me it happens very often where I know what I want: to pass an object of type B into a function f that expects type A, because I know that B is sufficiently A-like to allow function f to work. Most of the reasons given in this thread were red herrings and many of static typing's real issues were not even touched upon: . Implementing modern static type systems correctly is really hard. Consequently, the vast majority of new languages are dynamically typed because that is much easier to implement. I agree that implementing static type systems correctly is hard, and that dynamic type checking is easier, but I'm not willing to just agree that many languages use dynamic typing simply because it is easier. For example I prefer writing code in dynamically typed languages most of the time, so if I was to write a new language I would make it dynamically typed because that is my preference, not because it is easier. I can imagine that there is some subset of language designers that really would prefer to use a statically typed language but end up not implementing it because of the difficulty, but I'm not willing to just accept that they are the vast majority. -- Cosmin Stejerean http://offbytwo.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: On the importance of recognizing and using maps
On Wed, Mar 11, 2009 at 12:00 PM, Konrad Hinsen konrad.hin...@laposte.netwrote: On Mar 8, 2009, at 18:53, Rich Hickey wrote: I know people usually think of collections when they see vector/map/ set, and they think classes and types define something else. However, the vast majority of class and type instances in various languages are actually maps, and what the class/type defines is a specification of what should be in the map. Many of the languages don't expose the instances as maps as such and in failing to do so greatly deprive the users of the language from writing generic interoperable code. My own experience is mostly with Python. Python objects are indeed essentially maps (Python calls them dictionaries). But even though it is easy to obtain the map equivalent of any object (object.__dict__), I hardly see this being done. Python programmers tend to use maps and objects in very different ways, and that includes experienced programmers who are very well aware that objects are just maps plus a type tag plus a set of methods. IMHO a big reason Python programmers don't typically treat objects like is maps/dictionaries is that the set of things found in the map (dictionary) for that object (__dict__) are just a small subset of the interesting attributes of the object. In Python things like class level attributes, properties, descriptors and multiple inheritance all add a lot of flexibility to defining and using objects that would take a some effort to replicate on top of simple maps. The flexibility of Python however does allow you to treat even complex objects as dictionaries (by implementing __getitem__) or dictionaries as objects (by overriding __getattr__ or __getattribute___). I've used these techniques in places where I need to treat an object like a dictionary for interop, or places where I wanted to use a dictionary but with the nicer syntax for attribute access on objects ( a.foo instead of a['foo'] saves 3 keystrokes). -- Cosmin Stejerean http://offbytwo.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: Static type guy trying to convert
On Wed, Mar 11, 2009 at 1:03 PM, Jon Harrop j...@ffconsultancy.com wrote: On Wednesday 11 March 2009 15:30:01 Cosmin Stejerean wrote: Actually it happens a lot in real code and in many non-trivial programs in static typed languages you end up with a proliferation of types that are simply there to make the compiler happy. To me it happens very often where I know what I want: to pass an object of type B into a function f that expects type A, because I know that B is sufficiently A-like to allow function f to work. Another red herring: you are describing a disadvantage of nominal over structural typing. Not dynamic vs static typing. You are correct, my apologies. I was trying to show an example of situations where what I know and what the compiler wants is different, but as you pointed out my example is only valid in the case of a nominal type system. -- Cosmin Stejerean http://offbytwo.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: On the importance of recognizing and using maps
On Wed, Mar 11, 2009 at 5:34 PM, Chouser chou...@gmail.com wrote: [...] Defining a instance method for a Python class allows you to connect some code to your data, which internally uses a type pointer from the instance to the class. In Clojure you can put functions directly in the metadata (as clojure.zip does), or put a type tag in the map or in the metadata, and use a multimethod dispatching on that to connect code to your data. Similarly, any inheritance in Clojure would normally be defined on a keyword (or symbol or collection of either) that is in the map or the map's metadata. In Python, the object knows its class, and the class knows about the hierarchy. I don't know if that leads to any particular conclusion. I suppose it does suggests a trivial program (or a trivial part of a program) in Clojure will likely have less code for setting up classes than the Python equivalent -- you start with the data you actually need, and can add methods, polymorphism, etc. if needed later. I think it's largely possible to abuse Python to achieve some of the possibilities you mentioned. At runtime you can add new methods to a class, you can add new methods directly to an object (hint: use new.instancemethod), you can change the __bases__ of a given class to inject behavior, and you can change the class of an object by assigning to __class__. I included a small example of using the above techniques that makes it easy (I think) to separate code and data in Python by composing instances that provide data with classes that provide behavior at runtime. http://gist.github.com/77848 -- Cosmin Stejerean http://offbytwo.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: Proposal: remove auto-load of user.clj
On Mon, Mar 9, 2009 at 2:16 PM, MikeM michael.messini...@invista.comwrote: On Mar 9, 2:18 pm, Raffael Cavallaro raffaelcavall...@gmail.com wrote: On Mar 9, 10:58 am, MikeM michael.messini...@invista.com wrote: Could you share what benefits you get by the auto-load of user.clj early in the launch process? It allows the automatic loading of development utilities with each repl launch. It gets tiresome having to always do: (load my-uils) (or, equivalently, (load user)) every time you launch the repl. From the original post: A command line option for loading user.clj could be added for repl usage. I would prefer the default remain to load user.clj for the REPL, cases where you want a REPL without user.clj being loaded should be the exception IMHO. I don't fully understand the reaons for loading user.clj at all outside of the REPL, could someone explain the benefits of the current approach? -- Cosmin Stejerean http://offbytwo.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: How do I setup Clojure REPL to automattically use some libraries?
On Fri, Mar 6, 2009 at 4:33 PM, Christopher vth...@gmail.com wrote: Does anyone know if there is a way to setup your Clojure REPL with an initialization file like how SBCL works with a .sbclrc file? I'd like to have my REPL automattically use some of the libraries in clojure.contrib such as the repl-utils and the stacktrace libraries whenever it first loads. Thanks for your in advance. IIRC Clojure will automatically load user.clj if found in CLASSPATH, so I think it would be a good place to put any kind of customizations. -- Cosmin Stejerean http://offbytwo.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: Monad tutorial, part 1
On Thu, Mar 5, 2009 at 12:21 PM, Konrad Hinsen konrad.hin...@laposte.netwrote: For those who are interested in monads but don't want to learn Haskell first to understand the Haskell-based monad tutorials, I have started to write a Clojure monad tutorial. Part 1 is now available: http://onclojure.com/2009/03/05/a-monad-tutorial-for-clojure- programmers-part-1/ Feel free to post comments! Here's a shorter URL if you'd like, the longer link got broken up for me http://bit.ly/E81zf -- Cosmin Stejerean http://offbytwo.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: Chrono date library
On Thu, Mar 5, 2009 at 5:08 PM, Phil Hagelberg p...@hagelb.org wrote: The code is available in either mine or Phil's github forks of clojure- contrib: http://github.com/cooldude127/clojure-contrib/ http://github.com/technomancy/clojure-contrib/ We'd like to hear opinions and whether people are willing to admit this into clojure-contrib. Phil has already done his CA, I should submit mine soon. I've attached a copy of the implementation as well as the tests so you don't need to poke through our github repositories to find them. The tests are relatively thorough and provide a good example of how the library is meant to be used. Date processing is a common enough task that I think support for it should be included in contrib, especially considering how awkward the java.util.Date API is to use directly. If it's agreed that this is a good fit for contrib, we can create a Google Code issue and attach a patch there. I like the API so far, although I'll probably have to wait for timezone support before I can start using this. If anyone else is interested here is a link to github for chrono.cljhttp://bit.ly/d8sYf (syntax highlighting). For some reason I couldn't locate test-chrono.clj in the repo. -- Cosmin Stejerean http://offbytwo.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: Mathy operations on non-numerics (was Adding strings)
On Thu, Feb 26, 2009 at 1:18 PM, Phil Hagelberg p...@hagelb.org wrote: Peter Wolf opus...@gmail.com writes: Is there a good reason that + can't do the right thing as with other Java and scripting languages? I think this would be popular with non-LISPers. Putting a type check in + would slow down basic math, and there is a class of user who will complain loudly if basic math slows down. However, this also means that and also don't work on strings, which is pretty lousy. One approach that's been proposed in #clojure is to make these functions more capable by default, but then provide a fast-math library that could redefine them in terms of numerics-only. I'm a big fan of functions doing the most helpful thing by default but being able to offer better speed when you need it. Convenience vs speed is always a trade-off, but I think convenience should win in the default case. What do others think about this? I would much rather have a fast-math library that redefined common operators for numeric types only, and had the default +, , be multimethods. -- Cosmin Stejerean http://offbytwo.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: Privacy problems with clojure-contrib mirrors
On Tue, Feb 24, 2009 at 11:21 AM, Konrad Hinsen konrad.hin...@laposte.netwrote: On Feb 24, 2009, at 17:55, Cosmin Stejerean wrote: But more importantly you can't expect that people go ahead and change all (any really) of the existing git or mercurial clones of the repository. You can probably trying filing bug requests with github or bitbucket to not show email addresses (or better yet not show full usernames in the cases where the username is an email address). I do consider it resonable that tools for making information available over the Web protect e-mail addresses. Google does it, Yahoo does it, and probably many more do. In many countries, for example here in France, there is a legal obligation for Web publishers not to make anyone's personal information public without the person's explicit consent. Any decent Web tool needs to provide support for this. I'm not going to argue about whether or not an email address that you make part of a public subversion repository is personal information that should be protected. What you seem to want appears to have little to do with making the email address private. That would involve not showing it to anyone and I'm pretty sure neither Google nor Yahoo keeps your email address private. It simply displays it in a form that is harder to harvest (ie. requiring a Captcha before showing you the address). Like I said earlier, if you want this fixed I highly recommend you start by contacting the respective websites (github and bitbucket) instead of asking the people hosting the mirrors to change it. They're not in charge of the web interface and I really doubt anyone is going to in and retroactively change usernames in the entire repo (and completely break everything for anyone that has clones from those repos). -- Cosmin Stejerean http://offbytwo.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: alternate syntax
On Mon, Feb 23, 2009 at 11:10 AM, Mark Volkmann r.mark.volkm...@gmail.comwrote: On Mon, Feb 23, 2009 at 10:55 AM, Christian Vest Hansen karmazi...@gmail.com wrote: On Mon, Feb 23, 2009 at 4:42 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Do you by any chance mean custom reader when you say preprocessor? :) No. This would be a translation step before the code is fed to the current Clojure reader. This sounds to me like a better fit for an editor plugin (that would add parentheses as you type based on indentation, and optionally hide them as well when editing the source). -- Cosmin Stejerean http://offbytwo.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: *features*-var
On Mon, Feb 23, 2009 at 11:16 AM, pmf phil.fr...@gmx.de wrote: Some (most, if not all) CL variants have a *features*-var available that contains information about what the implementation supports and what not. Seeing that the issue of determining the Clojure-version in use come up from time to time, maybe it would be useful to introduce something like this for Clojure. For example, identifying whether one is using the lazy (lazier) version would then be possible by checking for the presence of a flag :lazy (in this particular case, checking for the presence of lazy-seq would be enough, but other feature-sets might be harder to detect). I don't think something like *features* makes sense in Clojure. Unlike CL there isn't an incomplete standard with many slightly different implementations. Requiring a specific version (or range of versions) of Clojure should be sufficient to ensure that the code is run against a compatible version of Clojure. For now I assume that means SVN revision numbers until we get to 1.0 -- Cosmin Stejerean http://offbytwo.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: :use feature requests
On Mon, Feb 23, 2009 at 2:29 PM, James Reeves weavejes...@googlemail.comwrote: On Feb 23, 6:54 pm, Chouser chou...@gmail.com wrote: (ns n01se.net.graph.issues (:import (java.text SimpleDateFormat ParsePosition) (java.util GregorianCalendar Calendar) (org.jfree.chart ChartFrame)) (:use [clojure.zip:only (xml-zip node)] [clojure.contrib.zip-filter :as zf :only ()] [clojure.contrib.zip-filter.xml :only (xml- attr text)] [clojure.contrib.lazy-xml :only (parse-trim)] [clojure.contrib.seq-utils :only (reductions)] [com.markmfredrickson.dejcartes :as chart :only ()])) Whilst we're throwing out ideas, I almost wonder if it wouldn't be worth allowing for this case in addition: (ns foo.bar (:use clojure.zip :only (xml-zip node)) (:use clojure.contrib.zip-filter :as zf)) +1 I think :as should be mutually exclusive with :only (and friends). -- Cosmin Stejerean http://offbytwo.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: alternate syntax
On Mon, Feb 23, 2009 at 2:38 PM, Dan redalas...@gmail.com wrote: [...] The problem is (+ 1 2) which is unlike how you normally do maths Removing parens doesn't solve the problem with (+ 1 2). For writing out math formulas a macro that allows infix notation would be useful (and I'm pretty sure I've seen at least one). -- Cosmin Stejerean http://offbytwo.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: :use feature requests
On Mon, Feb 23, 2009 at 3:52 PM, Perry Trolard trol...@gmail.com wrote: +1 from me, too. As to an :all shortcut that's synonymous with :exclude (), I think convenience at the REPL is a good argument for :all. (I'm assuming that the `require` macro would disappear, too.) For Cosmin's thought (:as mutually exclusive with :exclude, :only, :rename), it does seem to me that when one is aliasing a namespace, one wouldn't have a need to exclude or rename any functions (because there's no chance of conflict or namespace pollution). Does anyone disagree? The only reason I could see for using both :as and something :only is to bring certain vars from that namespace into the current one AND refer to that namespace by a shortname so you can access other parts of it. That can in fact happen sometimes but in those cases my recommendation would be to use to :use statements :use foo.bar :only [eggs, spam] :use foo.bar :as fb -- Cosmin Stejerean http://offbytwo.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: Alternatives to contains?
On Thu, Jan 29, 2009 at 1:06 PM, Paul Mooser taron...@gmail.com wrote: I know this has been discussed on the list before to some extent, but does clojure by default have any operations which actually do what contains? sounds like it would do, for all collections? I know that you can easily write something similar using some, but often times you just want to find if something is in a list of items. I've seen Rich say that contains? is for associative things, but I think it is an unfortunate name - if the idea is to express that the collection has a value for that key, I think the name would ideally express that, like: contains-key? has-key? maps? I would prefer has-key? for checking if a key is in a map and contains? for checking if an element is in a collection. -- Cosmin Stejerean http://offbytwo.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: Alternatives to contains?
On Thu, Jan 29, 2009 at 3:56 PM, Dan Larkin d...@danlarkin.org wrote: On Jan 29, 2009, at 2:55 PM, Cosmin Stejerean wrote: On Thu, Jan 29, 2009 at 1:06 PM, Paul Mooser taron...@gmail.com wrote: I know this has been discussed on the list before to some extent, but does clojure by default have any operations which actually do what contains? sounds like it would do, for all collections? I know that you can easily write something similar using some, but often times you just want to find if something is in a list of items. I've seen Rich say that contains? is for associative things, but I think it is an unfortunate name - if the idea is to express that the collection has a value for that key, I think the name would ideally express that, like: contains-key? has-key? maps? I would prefer has-key? for checking if a key is in a map and contains? for checking if an element is in a collection. What about leaving contains? as is and adding in? which would work like in in python. (contains? [1 2 50] 50) = false (in? [1 2 50] 50) = true If in? was to be added how would it behave when given a map as the first argument? I would rather have contains? do the right thing for list/vectors/sets and keep its current behavior for maps. If we do actually need a function like contains that ONLY accepts a map as the first argument I think a name like has-key? is the most intuitive. -- Cosmin Stejerean http://offbytwo.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: New functions and possible bugs
On Wed, Jan 28, 2009 at 11:13 AM, Frantisek Sodomka fsodo...@gmail.comwrote:
[...]
Since this is correct:
user= (= () [])
true
Shouldn't these be also 'true'?
user= (= {} [])
false
user= (= {} #{})
false
user= (= {} ())
false
user= (= #{} [])
false
user= (= #{} ())
false
Well, I'm not yet sure if I like it but lists and vectors that have
identical elements in them appear to be equal, not just empty ones.
user= (= [1, 2] '(1, 2))
true
Since any list can be represented as an equivalent vector (and any vector as
an equivalent list) I can imagine this making sense.
user= (apply list [1 2 1])
(1 2 1)
user= (apply vector '(1 2 1))
[1 2 1]
But I don't see how this would ever apply to sets or maps so I don't see why
empty sets and maps should be an exception.
--
Cosmin Stejerean
http://offbytwo.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: dispatch macros that are new to me
On Tue, Jan 27, 2009 at 5:21 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote: Yes, but it's specifically meant to be used as the first line of a file, to allow Clojure script to use unix shebang format. What should follow it? Something like this? #!/Users/Mark/bin/clj That's the path to where my clj script is located. I created a script named shebang.clj that contains that line and (println Hello). Then I tried to run it with ./shebang.clj, but it tried to run it with bash instead of my clj script and didn't understand println. #!/path/to/an/executable/but/not/a/shell/script You can't have your #! line point to another file with a #! line in it. (Well, you can but it won't do what you want). -- Cosmin Stejerean http://offbytwo.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: Support for disabling forms (reader macro similar to CL's #-(and))
On Mon, Jan 26, 2009 at 6:34 AM, Rich Hickey richhic...@gmail.com wrote: On Jan 25, 4:10 pm, Laurent PETIT laurent.pe...@gmail.com wrote: #- makes sense (CL didn't always make things the wrong way :-) And indeed, #; *could* break a lot of already existing editors for a while Yes, the issues are: #; is bad for editors #- would be incompatible with CL's #-, and couldn't be upgraded to compatibility without breakage. I'm not sure the latter is a big deal, as #-test ... in CL is just an alternative for #+(not test) ... Is ## an option? -- Cosmin Stejerean http://offbytwo.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: immigrate function for namespaces
On Mon, Jan 26, 2009 at 4:20 PM, James Reeves weavejes...@googlemail.comwrote: Hi folks, I've recently found myself having to choose between dividing functionality between many specific namespaces, or having a few very generic namespaces. In theory, being specific is the better choice, as it allows users to more accurately pick what they want to use. But if most of the time you import library X, you'd also like W, Y and Z, you start to end up with a lot of lines of code just loading libraries. Because I like to have my cake and eat it too, I wanted to keep my specific namespaces, but also group them up in more generic ones. To this end, I've created an immigrate function that interns every public symbol in a namespace into the current namespace: (defn- merge-meta! Destructively merge metadata from a source object into a target. [source target] (.setMeta target (merge (meta source) (select-keys (meta target) [:name :ns] (defn immigrate Add all the public vars in a list of namespaces to the current namespace. [ namespaces] (doseq [ns namespaces] (require ns) (doseq [[sym v] (ns-publics (find-ns ns))] (merge-meta! v (if (.isBound v) (intern *ns* sym (var-get v)) (intern *ns* sym)) The idea is that you can bundle up a set of specific libraries into a more general package, so your users don't have to type so much if they just want the defaults. - James Can you help me understand the difference between this and use (or :use in ns)? -- Cosmin Stejerean http://offbytwo.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: Proposal: smarter set operations that take size into account for speed
On Fri, Jan 23, 2009 at 2:52 PM, Mark Engelberg mark.engelb...@gmail.comwrote: On Fri, Jan 23, 2009 at 12:23 PM, Jason Wolfe jawo...@berkeley.edu wrote: OK, if these are not wanted in core right now, will anyone sign off for adding them to clojure.contrib? Well, *I* want these changes you've proposed in the core, but of course, I'm not in charge. I guess the real question is, what is the process to ensure that Rich sees and considers a potential core improvement like this? I think the main mechanism for this is to post it as an issue on google code, but I'm not certain whether you're supposed to post an issue unless he's seen the newsgroup thread and says, Yes, that sounds good, please post it as an issue. But if he misses the thread for some reason, that will never happen. So it's a bit of a catch-22. Anyway, maybe someone can clarify the procedure. In a previous thread Rich suggested that additions to clojure-contrib be discussed here and lacking any objections they should be posted as issues with attached patches on the clojure-contrib project. From what I've seen in the past clojure-contrib is the place for functions like the fast set operations discussed here. This gives people a chance to use them and identify any problems, etc before being considered for a move into clojure core. -- Cosmin Stejerean http://offbytwo.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: doall vs. dorun
On Tue, Jan 20, 2009 at 4:32 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote: On Tue, Jan 20, 2009 at 3:14 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Jan 20, 3:32 pm, Mark Volkmann r.mark.volkm...@gmail.com wrote: Can someone describe a situation where it is preferable to use doall instead of dorun? Here's one: (defn read-my-file [] (with-open [reader (BufferedReader. (FileReader. my-file.txt))] (doall (line-seq reader line-seq returns a lazy sequence, but you have to consume that sequence before with-open closes the file. How is it different if you change doall to dorun? According to their doc strings, they both can be used to force any effects. Walks through the successive rests of the seq Use dorun when you want to do something purely for the side effects. If you don't need what doall would return then you can use dorun instead to clearly indicate your intent. -- Cosmin Stejerean http://offbytwo.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: Can't get clojure or clojure.contrib via SVN over https
On Wed, Jan 14, 2009 at 8:16 AM, Paul Drummond paul.drumm...@iode.co.ukwrote: 2009/1/14 Rich Hickey richhic...@gmail.com I think the salient difference is http, not https, for non-members. Hi Rich, The point is that I could use https on Sourceforge to get around the proxy issue. I've had the same problem before when using SVN for Clojure (sourceforge) and assembla (a personal repos). When I tried checking out using http I got the error (see first post) so I used https and it worked on sourceforge and assembla without me needing to specify a username/password (as far as I remember). But the same trick doesn't work on google-code. Oh well :( I guess I will have to find some other way of keeping clojure and clojure-contrib up-to-date on my work box :( You could try moving to something like git and checking out the source code from one of the unofficial mirrors, like http://*github*.com/kevinoneill/* clojure* -- Cosmin Stejerean http://offbytwo.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: Very noob file reading and printing question
On Tue, Jan 6, 2009 at 5:26 PM, Tom Ayerst tom.aye...@gmail.com wrote: Hi, How do I read and print a text file? I can read it, its the printing that is the problem, I feel it should be obvious but I keep tripping myself up. (The context is I need to extract data line by line, translate the line format and save it for a legacy app) Well, if you just want to print to standard out you could use print or println. Apparently there's also with-out-file which I'm assuming temporarily binds *out* so all output goes to a file. That might be the simplest way to do what you need. -- Cosmin Stejerean http://offbytwo.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: quote on side effects
On Mon, Jan 5, 2009 at 2:48 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote: I'm trying to recall where I heard a quote that goes something like this. If none of your functions have side effects then all you're doing is heating up the processor. Of course you should avoid side effects in most of your functions, but at least one of them needs to have a side effect for most applications. Does anyone recall who said something like that? I remember reading something very similar, most likely on Hacker News http://news.ycombinator.com but I can't seem to dig it up on Google. -- Cosmin Stejerean http://offbytwo.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: Circular Require Change?
On Fri, Dec 19, 2008 at 10:30 AM, Kevin Martin martink...@gmail.com wrote: Thanks Rich! I'll keep an eye on the defect(shame there isn't a watch feature on google code). Other than this little minor annoyance, the new AOT changes are working great. Thanks for all the work, I'm really enjoying Clojure. I think starring an issue in Google Code is the equivalent of 'watch'. You'll get emailed when there are changes or comments on that issue. - Cosmin --~--~-~--~~~---~--~~ You 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: python style triple-double-quotes
On Sat, Dec 13, 2008 at 7:06 PM, Dan Larkin d...@danlarkin.org wrote: Yes, I'd like the feature because it's a pain in the neck to go through and escape strings when I know there's a better way. Also sometimes it doesn't feel right to escape strings... for instance in function doc strings I'd like to give an example return value. But if the value has to be escaped to play nice with the docstring it can get confusing confusing... for me at least. I'd like to put *exactly* what will be returned. Docstrings are definitely a perfect use-case for triple quoted strings. +1 on including something similar in Clojure. -- Cosmin Stejerean http://www.offbytwo.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: Learning Clojure
On Wed, Dec 10, 2008 at 2:10 PM, Randall R Schulz [EMAIL PROTECTED] wrote: On Wednesday 10 December 2008 10:27, Brian W wrote: I've created a new Clojure intro at http://en.wikibooks.org/wiki/Learning_Clojure. ... ... Another issue I had is we don't have a good blanket term for Vars, Refs, Agents, and Atoms. Speaking of these, your article mentions and describes only Var, Ref and Agent in your Reference Types section. The text is also a bit out of date already, e.g. I don't mention AOT or Atoms. Sounds like a known bug. -- Cosmin Stejerean http://www.offbytwo.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: quit
On Sun, Nov 30, 2008 at 3:05 PM, Mon Key [EMAIL PROTECTED] wrote: Maybe (quit-clojure) instead of (quit)? This would save vanilla `quit' just in case it's needed later/elsewhere. Might also be nice to have (exit-clojure). Ditto saving vanilla `exit' for other purposes When first configuring Clojure on both linux box and windows from the command line (e.g. pre-slime, sans Jline ); the (quit) form was one of the first things I evaluated at the REPL :P When I first started (quit) and (exit) are the first two things I've tried for getting out of the Repl. Having either of those work for terminating the REPL would be great. Using exit-clojure or quit-clojure instead will continue to require the user the look up how to terminate the REPL somewhere, at which point they might as well read about C-d. For example, here's what happens when someone new to Python tries to exit the interactive console. quit Use quit() or Ctrl-D (i.e. EOF) to exit quit() -- Cosmin Stejerean http://www.offbytwo.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: i'm having a lot of trouble dealing with events.
On Thu, Nov 20, 2008 at 9:21 AM, Mark Volkmann [EMAIL PROTECTED]wrote: On Thu, Nov 20, 2008 at 12:00 AM, notallama [EMAIL PROTECTED] wrote: (keyTyped [#^KeyEvent e] nil) I'm not familiar with the syntax above. What does the #^ part do? See http://clojure.org/java_interop#toc34 -- Cosmin Stejerean http://www.offbytwo.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Back on max again...
On Tue, Nov 4, 2008 at 6:45 AM, Rich Hickey [EMAIL PROTECTED] wrote: On Nov 4, 2:56 am, Christian Vest Hansen [EMAIL PROTECTED] wrote: On Tue, Nov 4, 2008 at 6:23 AM, Mark H. [EMAIL PROTECTED] wrote: On Nov 3, 6:48 pm, Cosmin Stejerean [EMAIL PROTECTED] wrote: I think clearly spelling out how objects of a type should be sorted is the point of the Comparable interface. Ah, yes, this is true, I hadn't realized that String and Date both implement Comparable. Comparable is supposed to impose a total ordering on a set, so in a finite set of objects of the same type, the max is always well defined. +1 on (min) and (max) operating on Comparables. Hmm... Do you want: (max 1 2.1 4/5) to work? If so, you can't base it on Comparable, which generally only supports homogenous types. max, like , is a numeric operation as it stands, for the above and speed reasons. If you want a general greatest/least based on Comparable (or better yet Clojure's compare), I'm not opposed, but it should probably be a different thing. Rich Clojure's compare seems to already do the right thing, or at least it can compare strings, haven't tried using dates. Are there performance implications to having max use compare? Personally I like having functions like max be generic and if needed create a separate fast max function for cases where I have to go through and apply performance optimizations to my code, although I'm hoping there is a way to have max be fast that doesn't involve having to use two different functions. -- Cosmin Stejerean http://www.offbytwo.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
