Re: constructing maps
(into {} (apply map vector
'((cars bmw chevrolet ford peugeot)
(genres adventure horror mystery
{ford mystery, chevrolet horror, bmw adventure, cars genres}
On Mon, May 4, 2009 at 4:03 PM, Michel S. wrote:
>
>
>
> On May 4, 5:07 pm, Christophe Grand wrote:
>> Michel S. a écrit :
>>
>> >> (apply conj {} (map split-kv (split-pairs test-str)))
>>
>> > The last can be simplified by using into:
>> > (into {} (map split-kv (split-pairs test-str)))
>>
>> It should be noted that into (and conj) is somewhat tricky with maps:
>> user=> (into {} '({1 2} {3 4}))
>> {3 4, 1 2}
>> user=> (into {} '([1 2] [3 4]))
>> {3 4, 1 2}
>> user=> (into {} '((1 2) (3 4)))
>> java.lang.ClassCastException: java.lang.Integer cannot be cast to
>> java.util.Map$Entry (NO_SOURCE_FILE:0)
>>
>> It bit me before.
>>
> Yes, me too. The design is a bit unfortunate, as I cannot convert a
> Scheme-style association list to a map easily:
>
> user=> (into {} '((cars bmw chevrolet ford peugeot)
> (genres adventure horror mystery)))
>
> java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to
> java.util.Map$Entry (NO_SOURCE_FILE:0)
>
> --
> Michel
> >
>
--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure 1.0
On May 4, 5:58 pm, Rich Hickey wrote: > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip Thanks a lot and congrats to you and the Clojure community. Finally I think I have found a practical Lisp I can devote myself to. Hoping for great times ahead. Thanks again for the release. Regards, Santanu Chatterjee --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
Bravo to Rich and all contributors! Kev On May 5, 2:04 am, tmountain wrote: > Congrats! I'm loving Clojure more all the time. Thank you for making > the Lisp I've been waiting for all these years. > > Travis > > On May 4, 8:58 am, Rich Hickey wrote: > > > After a sustained period of API stability and minimal bugs reports, > > I'm happy to announce the release of Clojure 1.0! > > >http://clojure.googlecode.com/files/clojure_1.0.0.zip > > > Numbered releases will enable people to consume a stable version of > > Clojure and move to bugfix-only incremental versions while preserving > > API stability, and to consume libraries designed to work with specific > > versions. Providing the bugfix-only revisions depends upon the > > community to submit patches for the release branch as well as the > > trunk. > > > Clojure represents several years of effort on my part, but has also > > been shaped profoundly by the community in the 18 months since its > > release to the public. I can't thank everyone enough for your > > contributions of ideas, bug reports, suggestions, tests, tools, > > documentation and code - patches and enhancements. Clojure wouldn't be > > where it is today without its community and all of your efforts. > > > Of course, there is more to do. Many good ideas have been suggested in > > the discussions preceding this release that were best put off for 1.1. > > Now with the release we can pursue them, and many others: > > >http://clojure.org/todo > > > I want to give special thanks to those who have made donations - they > > really help! I did the core work on Clojure during a self-funded > > sabbatical that has run its course (i.e. through my savings :) - > > donations help fund the future. > > > Clojure 1.0 is a milestone of achievement, but it also represents a > > beginning. With 1.0, Stuart's book, the burgeoning set of libraries in > > and outside of contrib, and the large, friendly community, Clojure is > > poised to enter a period of increased adoption and application in many > > domains. > > > Here's to the future! > > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: expanding a collection within an argument list
On May 4, 2009, at 10:33 PM, Mark Volkmann wrote: I have a collection I need to pass to foo after the first arg like this: (foo "some value" my-collection) What I need is a way to expand my-collection into individual arguments that are passed to foo so that they will be collected back into other-args as a sequence. I could create a new sequence containing "some value" and the items in my-collection and then use apply on foo and the new sequence. Is there a better way? Apply takes any number of individual elements before the final collection: (apply foo "some value" my-collection) Here's a concrete example: user=> (apply + 3 4 [5 6 7]) 25 --Steve smime.p7s Description: S/MIME cryptographic signature
expanding a collection within an argument list
Suppose I have a function like this: (defn foo [arg1 & other-args] ...) I have a collection I need to pass to foo after the first arg like this: (foo "some value" my-collection) What I need is a way to expand my-collection into individual arguments that are passed to foo so that they will be collected back into other-args as a sequence. I could create a new sequence containing "some value" and the items in my-collection and then use apply on foo and the new sequence. Is there a better way? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
Congrats! I'm loving Clojure more all the time. Thank you for making the Lisp I've been waiting for all these years. Travis On May 4, 8:58 am, Rich Hickey wrote: > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip > > Numbered releases will enable people to consume a stable version of > Clojure and move to bugfix-only incremental versions while preserving > API stability, and to consume libraries designed to work with specific > versions. Providing the bugfix-only revisions depends upon the > community to submit patches for the release branch as well as the > trunk. > > Clojure represents several years of effort on my part, but has also > been shaped profoundly by the community in the 18 months since its > release to the public. I can't thank everyone enough for your > contributions of ideas, bug reports, suggestions, tests, tools, > documentation and code - patches and enhancements. Clojure wouldn't be > where it is today without its community and all of your efforts. > > Of course, there is more to do. Many good ideas have been suggested in > the discussions preceding this release that were best put off for 1.1. > Now with the release we can pursue them, and many others: > > http://clojure.org/todo > > I want to give special thanks to those who have made donations - they > really help! I did the core work on Clojure during a self-funded > sabbatical that has run its course (i.e. through my savings :) - > donations help fund the future. > > Clojure 1.0 is a milestone of achievement, but it also represents a > beginning. With 1.0, Stuart's book, the burgeoning set of libraries in > and outside of contrib, and the large, friendly community, Clojure is > poised to enter a period of increased adoption and application in many > domains. > > Here's to the future! > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Contrib 1.0?
2009/5/5 e : > From one perspective I was surprised to see the 1.0 mark before figuring out > which things from contrib belonged in core. (From the other it seemed like > if you are ready to ask the question about 1.0, then that could be a > definition of 1.0 in itself). > > All I am really saying is that I agree that this is an excellent question. > For new users it would simplify things greatly to get more of the contrib > functionality without requiring a special namespace (that has to be > downloaded separately, to boot!) Some folks had talked about splitting up > contrib. I forget all the names people came up with, but one role people > had in mind (and it made sense to me) is to have a staging area-like > contrib. Is there a plan along these lines? Are things like the > duck-streams pretty much always included in people's code? Yes, I'd seen some of these discussions. I'm still _VERY_ much a n00b when it comes to clojure, so I'd urge people not to take my comments too seriously; but I think you're right. At least from my perspective it doesn't much matter what's in or out of the 1.0 contrib release, it's just more a matter of saying "Contrib 1.0 works with clojure 1.0" and will receive bug fixes etc... alongside it. Hopefully the 1.0 release will see a lot more people adopting clojure. It would be nice for these newcomers to easily see what each project's commitment to clojure 1.0 and clojure trunk is. Initially I'd guess this applies in particular to the various projects providing editor/IDE support and the clojure web frameworks. > On Mon, May 4, 2009 at 7:36 PM, Rick Moynihan > wrote: >> >> r 1.1) but It'd be great to see releases of these libraries that >> specifically target the 1.0 release of clojure. >> >> Does this mean a changing role for Contrib? How will it meet the >> needs of the groups 2 that > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Got a Clojure library?
Name: Incanter URL: http://github.com/liebke/incanter/tree/master Author: David Edgar Liebke Tags: statistics, numerical computing, plotting License: EPL Dependencies: Parallel Colt, JFreeChart, OpenCSV Description: Incanter is a collection statistical computing and plotting libraries with R-like semantics. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
(dosync (alter congrats conj (System/getProperty "user.name"))) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Contrib 1.0?
>From one perspective I was surprised to see the 1.0 mark before figuring out which things from contrib belonged in core. (From the other it seemed like if you are ready to ask the question about 1.0, then that could be a definition of 1.0 in itself). All I am really saying is that I agree that this is an excellent question. For new users it would simplify things greatly to get more of the contrib functionality without requiring a special namespace (that has to be downloaded separately, to boot!) Some folks had talked about splitting up contrib. I forget all the names people came up with, but one role people had in mind (and it made sense to me) is to have a staging area-like contrib. Is there a plan along these lines? Are things like the duck-streams pretty much always included in people's code? Thanks. On Mon, May 4, 2009 at 7:36 PM, Rick Moynihan wrote: > r 1.1) but It'd be great to see releases of these libraries that > specifically target the 1.0 release of clojure. > > Does this mean a changing role for Contrib? How will it meet the > needs of the groups 2 that > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: ANN: Full, continuously updated documentation for clojure.contrib
Tom, This is a really helpful service. Thank you very much! It's already helped me find stuff in the clojure.contrib.sql package that I didn't have the smarts to originally search. Kev On May 4, 4:30 pm, Tom Faulhaber wrote: > By the way, source of the robot is available on GitHub, for those who > appreciate fine masochism: > > http://github.com/tomfaulhaber/contrib-autodoc/ > > Really, nothing to see there, but we like to be open. > > Enjoy! > > On May 3, 11:41 pm, Tom Faulhaber wrote: > > > Hello everybody, > > > As many of you know, I have been working on a "contrib autodoc robot" > > for the last little while. > > > It is now up and running and you can use the results here: > > >http://code.google.com/p/clojure-contrib/wiki/OverviewOfContrib > > > It includes: > > * An overview of each namespace in contrib (including the author and > > shortcut links to documentation for each of the functions). > > * An API page for each name space that includes the doc string for > > each function or variable in the namespace and a direct link to the > > source for that function or variable. > > * An index of all the documented functions and variables so that you > > can find them by name. > > * A JSON file that allows other tools to build off this information > > (athttp://clojure-contrib.googlecode.com/svn/wiki/ApiDocIndex.json- > > still very much under development). > > > Each page has a sidebar to allow for quick access from place to place. > > > All the pages are stored in the wiki on the google code home for > > clojure-contrib. This is both a blessing and a curse, since the google > > code wiki is a little brain-dead. As a result, the formatting is not > > as awesome as I would like. > > > The goal of this project is to make contrib a more open and accessible > > resource for the community. Please take advantage of this to see and > > understand the great stuff that folks have added to contrib for your > > programming pleasure. I will be making sure it is kept up-to-date > > (eventually that will be automated, but for now I have to type "ant" > > once in a while). > > > To contrib authors: I have added metadata to your namespaces. Please > > update and correct it as you would like. The updates will be > > propagated to the site. Also, please review the doc for your > > contributions to make sure it is complete and correct in general. Let > > me know if anything doesn't seem to be going through the wringer > > correctly. > > > Happy perusing! > > > Tom --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure Contrib 1.0?
Now that Clojure has hit it's 1.0 milestone, I was wondering what this means for Clojure Contrib and the various other clojure libraries (compojure etc...) I've seen that post 1.0 Rich is planning some new features (presumably for 1.1) but It'd be great to see releases of these libraries that specifically target the 1.0 release of clojure. Does this mean a changing role for Contrib? How will it meet the needs of the groups 2 that a) want to target 1.0 and b) want to add next-gen features to contrib that require clojure trunk. Thanks again, 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 To unsubscribe from 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: constructing maps
On May 4, 5:07 pm, Christophe Grand wrote:
> Michel S. a écrit :
>
> >> (apply conj {} (map split-kv (split-pairs test-str)))
>
> > The last can be simplified by using into:
> > (into {} (map split-kv (split-pairs test-str)))
>
> It should be noted that into (and conj) is somewhat tricky with maps:
> user=> (into {} '({1 2} {3 4}))
> {3 4, 1 2}
> user=> (into {} '([1 2] [3 4]))
> {3 4, 1 2}
> user=> (into {} '((1 2) (3 4)))
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.util.Map$Entry (NO_SOURCE_FILE:0)
>
> It bit me before.
>
Yes, me too. The design is a bit unfortunate, as I cannot convert a
Scheme-style association list to a map easily:
user=> (into {} '((cars bmw chevrolet ford peugeot)
(genres adventure horror mystery)))
java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to
java.util.Map$Entry (NO_SOURCE_FILE:0)
--
Michel
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure on Wikipedia
I second this notion. On May 4, 9:21 am, Mibu wrote: > Congratulations Rich and everyone for 1.0! > > Clojure really is remarkable, and people start to notice. > > Today, when people want to know something new they first go to > Wikipedia before they even visit the homepage. There will be a lot of > new interest in Clojure now that it has reached 1.0. > > Please help beef up Clojure's Wikipedia entry (but keep it neutral, > not marketing-speak). > > If you are not an expert on Clojure, like me, help with the little > stuff: typos, phrasing, citations, cleanup, entries in other > language's Wikis, amending entries surveying or comparing programming > languages and PL concepts, or adding things in the discussion page for > later integration. Little by little -- it's the wiki way. > > To add Clojure code examples in Wikipedia use tag > like here:http://en.wikipedia.org/wiki/List_comprehension#Clojure > > Also promote Clojure 1.0 on > reddit:http://www.reddit.com/r/programming/comments/8hov0/clojure_10_released/ > > Again, congrats and thanks Rich and everyone for this amazing and > inspiring language! --~--~-~--~~~---~--~~ You 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: constructing maps
Michel S. a écrit :
>> (apply conj {} (map split-kv (split-pairs test-str)))
>>
>>
> The last can be simplified by using into:
> (into {} (map split-kv (split-pairs test-str)))
>
It should be noted that into (and conj) is somewhat tricky with maps:
user=> (into {} '({1 2} {3 4}))
{3 4, 1 2}
user=> (into {} '([1 2] [3 4]))
{3 4, 1 2}
user=> (into {} '((1 2) (3 4)))
java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.util.Map$Entry (NO_SOURCE_FILE:0)
It bit me before.
Christophe
--
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (en)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure, SAP and JCo
Not yet but I've been wanting to start working on this as well. I'd love to hear if anybody has experience with this. William On Mon, May 4, 2009 at 12:27 PM, Sean Devlin wrote: > > Hi, > Has anyone else here been using Clojure to interact with SAP? Or, are > there any JCo experts in the house? > > Sean > > > --~--~-~--~~~---~--~~ You 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: constructing maps
On May 4, 9:03 am, Konrad Hinsen wrote:
> On May 4, 2009, at 14:23, Nathan Hawkins wrote:
>
> > This seems a little bit more like what I expected:
>
> > (map-assoc split-kv (split-pairs test-str))
>
> > -> {"baz" "3", "bar" "2", "foo" "1"}
>
> > Am I overlooking some already existing function hidden away someplace
> > that does this?
>
> Here's one way to do what you want:
>
> (ns test (:use clojure.contrib.str-utils))
>
> (def test-str "foo=1;bar=2;baz=3")
>
> (defn split-kv [text]
> (vec (re-split #"=" text)))
>
> (defn split-pairs [text]
> (re-split #";" text))
>
> (apply conj {} (map split-kv (split-pairs test-str)))
>
The last can be simplified by using into:
(into {} (map split-kv (split-pairs test-str)))
--
Michel
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Clojure, SAP and JCo
Hi, Has anyone else here been using Clojure to interact with SAP? Or, are there any JCo experts in the house? Sean --~--~-~--~~~---~--~~ You 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: Slime integration
Ok, I finally has some free time to look at this and think I found out what is happening. For instance when compiling this (defn v[] an-undefined-symbol) via C-c C-k: I get the following message: (:compilation-result ((:message "java.lang.Exception: Unable to resolve symbol: a in this context (test.clj:2)" :severity :error )) This causes the regex in swank clojure (defined as #"^clojure\\.lang\ \.Compiler\\$CompilerException: ([^:]+):([^:]+):")) to fail for two reasons: 1) Ir searches for CompilerException while the message string is actually contains java.lang.Exception (even if the exception really is an instance of CompilerException) 2) It will get confused by the colon after symbol I replaced the regex with the following (def *compiler-exception-location-re* #"^*Exception: [^\(]+ \(([^:]+): ([^:]+)\)" ) and now Slime seems to work fine. A better solution however would be to avoid regex parsing all together and make clojure store the information in the CompilerException so that swank-clojure can later retrieve it without flaky regex parsing. I have made a trivial 4 line patch for this, and it works fine. If people are interested I will send the patch to ML. Cheers, V. Segui On 26 mar, 23:08, Tassilo Horn wrote: > vseguip writes: > > Hi I tried your code but still no luck with errors. > > Then I don't know. I use ut-to-date versions of swank-clojure, > clojure-mode, SLIME and clojure all from their version control systems. > Maybe that makes the difference. > > Bye, > Tassilo --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Got a Clojure library?
Name: clj-contURL: http://github.com/swannodette/clj-cont/ Author: David Nolen Tags: continuations License: MIT Dependencies: clojure-contrib (error-kit) Description: Port of Common Lisp cl-cont library. Adds support for delimited continuations by transforming regular Clojure code into continuation passing style. On Thu, Jan 29, 2009 at 11:04 AM, Rich Hickey wrote: > > People regularly post here about Clojure libraries they are working > on, and it is great to see the explosion of new libs for Clojure! > > I'd like to try to get a directory of Clojure libs together and up on > the Clojure site. Towards that end, I'd appreciate it, if you are the > author of a Clojure library (including contrib authors!), you reply in > this thread with: > > The name of your library > Library home page URL > Your name > Category (db, web, UI, parsing etc) > License > A one-paragraph description. Include 3rd party dependencies if any. > > (did I miss anything important?) > > Thanks! > > Rich > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/5/4 Phil Hagelberg : > > On May 2, 1:02 am, Laurent PETIT wrote: >> > > Note: I strongly suggest that the clojure.version.interim property >> > > remains true in svn, so that it's not possible to inadvertently >> > > release a version "too early". >> >> > Just to clarify - are you suggesting I should just change >> > version.properties by hand, build and release the result, but never >> > check in with clojure.version.interim=false? >> >> Yes. I think this is correct to check-in with other version attributes >> correctly set for the upcoming release, but keep the interim attribute to >> false in the svn repository, so that nobody can create an official release >> inadvertently. > > This is a fine idea for trunk, but it would be wise to check in > interim=false on the revision that gets tagged as 1.0 in SVN. Yes, sure, this would be fine for a tag .. if there were one ;-) > > Congrats on the release btw; I'm very excited. > > -Phil > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
Congrats Rich and contributors! You all have made a great tool and a great community as well! mfh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Heise wrote its first news article about Clojure today
German readers might be interested to see that Heise published its first news article about Clojure today: http://www.heise.de/developer/Clojure-1-0-funktionale-Programmiersprache-fuer-die-Java-Virtual-Machine--/news/meldung/137231 So, I guess they will keep it on their radar. Let's work together to produce many good news :-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
Congrats exciting times! On Mon, May 4, 2009 at 8:58 AM, Rich Hickey wrote: > > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip > > Numbered releases will enable people to consume a stable version of > Clojure and move to bugfix-only incremental versions while preserving > API stability, and to consume libraries designed to work with specific > versions. Providing the bugfix-only revisions depends upon the > community to submit patches for the release branch as well as the > trunk. > > Clojure represents several years of effort on my part, but has also > been shaped profoundly by the community in the 18 months since its > release to the public. I can't thank everyone enough for your > contributions of ideas, bug reports, suggestions, tests, tools, > documentation and code - patches and enhancements. Clojure wouldn't be > where it is today without its community and all of your efforts. > > Of course, there is more to do. Many good ideas have been suggested in > the discussions preceding this release that were best put off for 1.1. > Now with the release we can pursue them, and many others: > > http://clojure.org/todo > > I want to give special thanks to those who have made donations - they > really help! I did the core work on Clojure during a self-funded > sabbatical that has run its course (i.e. through my savings :) - > donations help fund the future. > > Clojure 1.0 is a milestone of achievement, but it also represents a > beginning. With 1.0, Stuart's book, the burgeoning set of libraries in > and outside of contrib, and the large, friendly community, Clojure is > poised to enter a period of increased adoption and application in many > domains. > > Here's to the future! > > Rich > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Waterfront
Hello All,
I was playing with Waterfront editor and I found the below a little
difficult to figure out.
(defstruct aount :h1 :h2 :h3 :h4)
;;(def rowi8 (struct aount "x" "x" "x" "x"))
(def sande (ref rowi8))
@sande
{:h1 x , :h2 x, :h3 x, :h4 x} It appears it did not understand that I
commented out rowi8. Could somebody try this out in his/her system in order
for me to confirm this issue?
Regards,
Emeka
--~--~-~--~~~---~--~~
You 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
-~--~~~~--~~--~--~---
Ivy for Clojure 1.0
Hi, I updated the Ivy repo for Clojure 1.0.0 and Contrib 757. Feel free to use (example in the attached patches). If you use the repo please mirror it locally. Thank you. Sincerely Meikel contrib-ivy2.diff Description: Binary data clojure-ivy2.diff Description: Binary data smime.p7s Description: S/MIME cryptographic signature
Re: Clojure 1.0
> > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip > > Congratulations! I made a promise to myself long ago to really learn a Lisp. I've dabbled on and off but now Clojure is really motivating me to really learn - sane concurrency model and on the JVM so I have all sorts of libraries at my disposal and availability "everyone" what's not to love? --Robert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
Congratulations! Keep up the good work, /Olov --~--~-~--~~~---~--~~ You 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: constructing maps
On Mon, 04 May 2009 16:31:21 +0200
Christophe Grand wrote:
>
> Nathan Hawkins a écrit :
> > Ok, my example seems to have misled. You're missing the point a
> > little bit:
> >
> > 1. I was trying to avoid the (reduce conj {} ...), by having the map
> > function do it. Why even build a list that's only going to get
> > thrown away when I want a hash-map at the end?
> >
> > 2. The functions used to split the strings were not important, only
> > an example. It could just as easily be a function to extract fields
> > from a java object.
> >
> >
> > To some extent, I guess I'm thinking in terms of Common Lisp, where
> > I'd build an a-list with mapcar and cons.
> >
>
> With f a function that return a [key value] pair (or a (key value)
> pair but not a {key value} pair):
> (reduce #(apply assoc %1 (f %2)) {} coll)
>
> if you want to have f return a map you can
> (reduce #(merge %1 (f %2)) {} coll)
>
This is exactly what I was trying to, but I hadn't thought of using
reduce.
Thank you.
Nathan
--~--~-~--~~~---~--~~
You 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 May 2, 1:02 am, Laurent PETIT wrote: > > > Note: I strongly suggest that the clojure.version.interim property > > > remains true in svn, so that it's not possible to inadvertently > > > release a version "too early". > > > Just to clarify - are you suggesting I should just change > > version.properties by hand, build and release the result, but never > > check in with clojure.version.interim=false? > > Yes. I think this is correct to check-in with other version attributes > correctly set for the upcoming release, but keep the interim attribute to > false in the svn repository, so that nobody can create an official release > inadvertently. This is a fine idea for trunk, but it would be wise to check in interim=false on the revision that gets tagged as 1.0 in SVN. Congrats on the release btw; I'm very excited. -Phil --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
Wow, I really didn't expected this one! I also came to realize that I've been using Clojure for a year now, the longest period of time I've devoted to a single non-mainstream language. A million thanks! Congratulations to Rich and all contributors. On May 4, 8:58 am, Rich Hickey wrote: > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip > > Numbered releases will enable people to consume a stable version of > Clojure and move to bugfix-only incremental versions while preserving > API stability, and to consume libraries designed to work with specific > versions. Providing the bugfix-only revisions depends upon the > community to submit patches for the release branch as well as the > trunk. > > Clojure represents several years of effort on my part, but has also > been shaped profoundly by the community in the 18 months since its > release to the public. I can't thank everyone enough for your > contributions of ideas, bug reports, suggestions, tests, tools, > documentation and code - patches and enhancements. Clojure wouldn't be > where it is today without its community and all of your efforts. > > Of course, there is more to do. Many good ideas have been suggested in > the discussions preceding this release that were best put off for 1.1. > Now with the release we can pursue them, and many others: > > http://clojure.org/todo > > I want to give special thanks to those who have made donations - they > really help! I did the core work on Clojure during a self-funded > sabbatical that has run its course (i.e. through my savings :) - > donations help fund the future. > > Clojure 1.0 is a milestone of achievement, but it also represents a > beginning. With 1.0, Stuart's book, the burgeoning set of libraries in > and outside of contrib, and the large, friendly community, Clojure is > poised to enter a period of increased adoption and application in many > domains. > > Here's to the future! > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: ANN: Full, continuously updated documentation for clojure.contrib
By the way, source of the robot is available on GitHub, for those who appreciate fine masochism: http://github.com/tomfaulhaber/contrib-autodoc/ Really, nothing to see there, but we like to be open. Enjoy! On May 3, 11:41 pm, Tom Faulhaber wrote: > Hello everybody, > > As many of you know, I have been working on a "contrib autodoc robot" > for the last little while. > > It is now up and running and you can use the results here: > > http://code.google.com/p/clojure-contrib/wiki/OverviewOfContrib > > It includes: > * An overview of each namespace in contrib (including the author and > shortcut links to documentation for each of the functions). > * An API page for each name space that includes the doc string for > each function or variable in the namespace and a direct link to the > source for that function or variable. > * An index of all the documented functions and variables so that you > can find them by name. > * A JSON file that allows other tools to build off this information > (athttp://clojure-contrib.googlecode.com/svn/wiki/ApiDocIndex.json- > still very much under development). > > Each page has a sidebar to allow for quick access from place to place. > > All the pages are stored in the wiki on the google code home for > clojure-contrib. This is both a blessing and a curse, since the google > code wiki is a little brain-dead. As a result, the formatting is not > as awesome as I would like. > > The goal of this project is to make contrib a more open and accessible > resource for the community. Please take advantage of this to see and > understand the great stuff that folks have added to contrib for your > programming pleasure. I will be making sure it is kept up-to-date > (eventually that will be automated, but for now I have to type "ant" > once in a while). > > To contrib authors: I have added metadata to your namespaces. Please > update and correct it as you would like. The updates will be > propagated to the site. Also, please review the doc for your > contributions to make sure it is complete and correct in general. Let > me know if anything doesn't seem to be going through the wringer > correctly. > > Happy perusing! > > Tom --~--~-~--~~~---~--~~ You 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: ANN: Full, continuously updated documentation for clojure.contrib
Glad to hear everyone likes it. Here's my responses to the various comments here: Chris: Rich added a link on the landing page while I was writing this note. Thanks, Rich! Mark: I hoping that the visibility of this page will spur the contributors (myself included!) to ever higher levels of documentation. Don't hide your light under a bushel, guys! e: Hmm, I think comments should work fine even though I'm regenerating the pages (I haven't tested it). However the google group might be a better place for questions because people watch it pretty closely. I would think that the wiki pages would be better for various elucidations of subtleties of the interface. YMMV, of course. Antony: There is a way for authors to add links either to other pages in the wiki or externally. See DataLog and Monad for examples of how this works. One of the issues here is that doc strings are repurposed in a lot of ways and authors generally only want to write docs once so we need to keep the formatting very simple and not assume that folks will be reading the docs on the wiki. Tom --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
On May 4, 5:58 pm, Rich Hickey wrote: > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip Congratulations! martin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
Big congrats. Fantastic work Rich and all contributors. Thanks for making this happen. /Jonas 2009/5/4 Rich Hickey : > > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip > > Numbered releases will enable people to consume a stable version of > Clojure and move to bugfix-only incremental versions while preserving > API stability, and to consume libraries designed to work with specific > versions. Providing the bugfix-only revisions depends upon the > community to submit patches for the release branch as well as the > trunk. > > Clojure represents several years of effort on my part, but has also > been shaped profoundly by the community in the 18 months since its > release to the public. I can't thank everyone enough for your > contributions of ideas, bug reports, suggestions, tests, tools, > documentation and code - patches and enhancements. Clojure wouldn't be > where it is today without its community and all of your efforts. > > Of course, there is more to do. Many good ideas have been suggested in > the discussions preceding this release that were best put off for 1.1. > Now with the release we can pursue them, and many others: > > http://clojure.org/todo > > I want to give special thanks to those who have made donations - they > really help! I did the core work on Clojure during a self-funded > sabbatical that has run its course (i.e. through my savings :) - > donations help fund the future. > > Clojure 1.0 is a milestone of achievement, but it also represents a > beginning. With 1.0, Stuart's book, the burgeoning set of libraries in > and outside of contrib, and the large, friendly community, Clojure is > poised to enter a period of increased adoption and application in many > domains. > > Here's to the future! > > Rich > > > > -- Jonas Bonér | Crisp AB http://jonasboner.com http://crisp.se --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure's handling of numbers with a trailing decimal point
On May 4, 2009, at 9:51 AM, Rich Hickey wrote: May I please enter an issue to track it and provide a patch? Sure, thanks! Thanks. Entered as issue 113: http://code.google.com/p/clojure/issues/detail?id=113 --Steve smime.p7s Description: S/MIME cryptographic signature
Using Map
Hello All, I want to arrange objects in rows and also being able to manipulate them. By manipulation I meant, I could move one object from one row and use it to replace another object in another. Should I use Map or something else? I need your opinions here Regards, Emeka --~--~-~--~~~---~--~~ You 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: constructing maps
Nathan Hawkins a écrit :
> Ok, my example seems to have misled. You're missing the point a little
> bit:
>
> 1. I was trying to avoid the (reduce conj {} ...), by having the map
> function do it. Why even build a list that's only going to get thrown
> away when I want a hash-map at the end?
>
> 2. The functions used to split the strings were not important, only an
> example. It could just as easily be a function to extract fields from a
> java object.
>
>
> To some extent, I guess I'm thinking in terms of Common Lisp, where I'd
> build an a-list with mapcar and cons.
>
With f a function that return a [key value] pair (or a (key value) pair
but not a {key value} pair):
(reduce #(apply assoc %1 (f %2)) {} coll)
if you want to have f return a map you can
(reduce #(merge %1 (f %2)) {} coll)
--
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (en)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: constructing maps
On Mon, 4 May 2009 16:07:06 +0200
Christopher Taylor wrote:
>
> Hi Nathan,
>
> On 04.05.2009, at 15:47, Nathan Hawkins wrote:
>
> >
> > On Mon, 4 May 2009 06:16:14 -0700 (PDT)
> > Drew Raines wrote:
> >>
> >> Whoops, that (seq) is a debugging artifact. You can remove that:
> >>
> >> (let [test-str "foo=1;bar=2;baz=3"]
> >> (reduce conj {}
> >> (map #(apply hash-map (.split % "="))
> >> (.split test-str ";"
> >
> > Ok, my example seems to have misled. You're missing the point a
> > little bit:
> >
> > 1. I was trying to avoid the (reduce conj {} ...), by having the map
> > function do it. Why even build a list that's only going to get
> > thrown away when I want a hash-map at the end?
>
> you're not actually building a list. The function map returns a
> (lazy) *sequence*, which is an instance of ISeq. This just means
> you're getting something that supports the operations first and rest.
> So, since map returns a sequence and you want a Map (i.e. key/value
> data structure), you'll have to turn it into one by using (conj
> {} ...) or (into {} ...).
There's the source of my misunderstanding. I knew map returned a
sequence, but hadn't quite connected "lazy" to the problem at hand.
I had stumbled on a couple different ways of converting the sequence to
a hash-map (I found (into {} ...), (apply hash-map ...) and (reduce conj
{} ...)), but I was thinking in terms of how I'd solve the problem in
Common Lisp so I thought that running map and then converting the
result to a hash-map was going to iterate the list twice, as well as
cons the results twice.
Thanks for clearing that up.
Nathan
--~--~-~--~~~---~--~~
You 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: constructing maps
On May 4, 8:05 am, Drew Raines wrote:
> user> (let [test-str "foo=1;bar=2;baz=3"]
> (reduce conj {}
> (map #(apply hash-map (seq (.split % "=")))
> (.split test-str ";"
Whoops, that (seq) is a debugging artifact. You can remove that:
(let [test-str "foo=1;bar=2;baz=3"]
(reduce conj {}
(map #(apply hash-map (.split % "="))
(.split test-str ";"
-Drew
--~--~-~--~~~---~--~~
You 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: constructing maps
On May 4, 7:23 am, Nathan Hawkins wrote:
> Possibly I'm going about this wrong. I'm trying to understand how best
> to construct maps from sequences, by applying a function which returns a
> key / value pair.
>
> Something like this:
>
> (ns test (:use clojure.contrib.str-utils))
>
> (def test-str "foo=1;bar=2;baz=3")
>
> (defn split-kv [text]
> (let [[k v] (re-split #"=" text )]
> {k v}))
>
> (defn split-pairs [text]
> (re-split #";" text))
>
> (map split-kv (split-pairs test-str))
>
> -> ({"foo" "1"} {"bar" "2"} {"baz" "3"})
>
> Doesn't really do what I had in mind. And yeah, I figured out that I can
> convert that to a hash-map in various ways, but I had expected map to be
> able to do this. So I wrote this:
>
> (defn map-assoc
> "Returns a map consisting of f applied to coll, where f is a function
> returning a key and value. f can return either a sequence with two
> values or a single item map."
> [f coll]
> (loop [map {}
> s (seq coll)]
> (if s
> (let [item (f (first s))]
> (recur (if (associative? item)
> (conj map item)
> (assoc map (first item) (second item)))
> (next s)))
> map)))
>
> This seems a little bit more like what I expected:
>
> (map-assoc split-kv (split-pairs test-str))
>
> -> {"baz" "3", "bar" "2", "foo" "1"}
>
> Am I overlooking some already existing function hidden away someplace
> that does this?
user> (apply hash-map (clojure.contrib.str-utils/re-split #"[=;]"
"foo=1;bar=2;baz=3"))
{"foo" "1", "bar" "2", "baz" "3"}
This solution makes a lot of assumptions about the input data, of
course.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure 1.0
Congratulations Rich! I'm happy to be a part of the Clojure community. On May 4, 7:58 am, Rich Hickey wrote: > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip > > Numbered releases will enable people to consume a stable version of > Clojure and move to bugfix-only incremental versions while preserving > API stability, and to consume libraries designed to work with specific > versions. Providing the bugfix-only revisions depends upon the > community to submit patches for the release branch as well as the > trunk. > > Clojure represents several years of effort on my part, but has also > been shaped profoundly by the community in the 18 months since its > release to the public. I can't thank everyone enough for your > contributions of ideas, bug reports, suggestions, tests, tools, > documentation and code - patches and enhancements. Clojure wouldn't be > where it is today without its community and all of your efforts. > > Of course, there is more to do. Many good ideas have been suggested in > the discussions preceding this release that were best put off for 1.1. > Now with the release we can pursue them, and many others: > > http://clojure.org/todo > > I want to give special thanks to those who have made donations - they > really help! I did the core work on Clojure during a self-funded > sabbatical that has run its course (i.e. through my savings :) - > donations help fund the future. > > Clojure 1.0 is a milestone of achievement, but it also represents a > beginning. With 1.0, Stuart's book, the burgeoning set of libraries in > and outside of contrib, and the large, friendly community, Clojure is > poised to enter a period of increased adoption and application in many > domains. > > Here's to the future! > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure on Wikipedia
Congratulations Rich and everyone for 1.0! Clojure really is remarkable, and people start to notice. Today, when people want to know something new they first go to Wikipedia before they even visit the homepage. There will be a lot of new interest in Clojure now that it has reached 1.0. Please help beef up Clojure's Wikipedia entry (but keep it neutral, not marketing-speak). If you are not an expert on Clojure, like me, help with the little stuff: typos, phrasing, citations, cleanup, entries in other language's Wikis, amending entries surveying or comparing programming languages and PL concepts, or adding things in the discussion page for later integration. Little by little -- it's the wiki way. To add Clojure code examples in Wikipedia use tag like here: http://en.wikipedia.org/wiki/List_comprehension#Clojure Also promote Clojure 1.0 on reddit: http://www.reddit.com/r/programming/comments/8hov0/clojure_10_released/ Again, congrats and thanks Rich and everyone for this amazing and inspiring language! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
This is great news that'll hopefully help propel clojure into more mainstream uses! Many thanks to Rich and everyone else for helping create what I'd consider to be the first real-world practical lisp! I'm certainly looking forward to spending some more quality time with the language! R. On May 4, 1:58 pm, Rich Hickey wrote: > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip > > Numbered releases will enable people to consume a stable version of > Clojure and move to bugfix-only incremental versions while preserving > API stability, and to consume libraries designed to work with specific > versions. Providing the bugfix-only revisions depends upon the > community to submit patches for the release branch as well as the > trunk. > > Clojure represents several years of effort on my part, but has also > been shaped profoundly by the community in the 18 months since its > release to the public. I can't thank everyone enough for your > contributions of ideas, bug reports, suggestions, tests, tools, > documentation and code - patches and enhancements. Clojure wouldn't be > where it is today without its community and all of your efforts. > > Of course, there is more to do. Many good ideas have been suggested in > the discussions preceding this release that were best put off for 1.1. > Now with the release we can pursue them, and many others: > > http://clojure.org/todo > > I want to give special thanks to those who have made donations - they > really help! I did the core work on Clojure during a self-funded > sabbatical that has run its course (i.e. through my savings :) - > donations help fund the future. > > Clojure 1.0 is a milestone of achievement, but it also represents a > beginning. With 1.0, Stuart's book, the burgeoning set of libraries in > and outside of contrib, and the large, friendly community, Clojure is > poised to enter a period of increased adoption and application in many > domains. > > Here's to the future! > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
Congrats!!! On 5月4日, 下午8时58分, Rich Hickey wrote: > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip > > Numbered releases will enable people to consume a stable version of > Clojure and move to bugfix-only incremental versions while preserving > API stability, and to consume libraries designed to work with specific > versions. Providing the bugfix-only revisions depends upon the > community to submit patches for the release branch as well as the > trunk. > > Clojure represents several years of effort on my part, but has also > been shaped profoundly by the community in the 18 months since its > release to the public. I can't thank everyone enough for your > contributions of ideas, bug reports, suggestions, tests, tools, > documentation and code - patches and enhancements. Clojure wouldn't be > where it is today without its community and all of your efforts. > > Of course, there is more to do. Many good ideas have been suggested in > the discussions preceding this release that were best put off for 1.1. > Now with the release we can pursue them, and many others: > > http://clojure.org/todo > > I want to give special thanks to those who have made donations - they > really help! I did the core work on Clojure during a self-funded > sabbatical that has run its course (i.e. through my savings :) - > donations help fund the future. > > Clojure 1.0 is a milestone of achievement, but it also represents a > beginning. With 1.0, Stuart's book, the burgeoning set of libraries in > and outside of contrib, and the large, friendly community, Clojure is > poised to enter a period of increased adoption and application in many > domains. > > Here's to the future! > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
On May 4, 9:51 am, "mchan...@uiuc.edu" wrote: > This is a very cool! I have one suggestion: maybe we should update the > clojure website and add the announcement of 1.0 release. I know that > Rich has announce the news in the blog. However, most of the people > will just go tohttp://clojure.org/. Therefore, I think that it is very > important to > put the announcement on the main website. Any comment? > I've added a note to the front page, thanks. Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: constructing maps
Hi Nathan,
On 04.05.2009, at 15:47, Nathan Hawkins wrote:
>
> On Mon, 4 May 2009 06:16:14 -0700 (PDT)
> Drew Raines wrote:
>>
>> Whoops, that (seq) is a debugging artifact. You can remove that:
>>
>> (let [test-str "foo=1;bar=2;baz=3"]
>> (reduce conj {}
>> (map #(apply hash-map (.split % "="))
>> (.split test-str ";"
>
> Ok, my example seems to have misled. You're missing the point a little
> bit:
>
> 1. I was trying to avoid the (reduce conj {} ...), by having the map
> function do it. Why even build a list that's only going to get thrown
> away when I want a hash-map at the end?
you're not actually building a list. The function map returns a (lazy)
*sequence*, which is an instance of ISeq. This just means you're
getting something that supports the operations first and rest. So,
since map returns a sequence and you want a Map (i.e. key/value data
structure), you'll have to turn it into one by using (conj {} ...) or
(into {} ...).
hth,
--Chris
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure 1.0
Congratulations, Rich! And thanks for all your hard work. Having a 1.0 release out to help adoption in the workplace environments that we need to get into. --~--~-~--~~~---~--~~ You 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: constructing maps
On Mon, 4 May 2009 06:16:14 -0700 (PDT)
Drew Raines wrote:
>
> On May 4, 8:05 am, Drew Raines wrote:
>
> > user> (let [test-str "foo=1;bar=2;baz=3"]
> > (reduce conj {}
> > (map #(apply hash-map (seq (.split % "=")))
> > (.split test-str ";"
>
> Whoops, that (seq) is a debugging artifact. You can remove that:
>
> (let [test-str "foo=1;bar=2;baz=3"]
> (reduce conj {}
> (map #(apply hash-map (.split % "="))
>(.split test-str ";"
Ok, my example seems to have misled. You're missing the point a little
bit:
1. I was trying to avoid the (reduce conj {} ...), by having the map
function do it. Why even build a list that's only going to get thrown
away when I want a hash-map at the end?
2. The functions used to split the strings were not important, only an
example. It could just as easily be a function to extract fields from a
java object.
To some extent, I guess I'm thinking in terms of Common Lisp, where I'd
build an a-list with mapcar and cons.
Nathan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure 1.0
Congratulations, Rich! And thanks for all your hard work. Having a 1.0 release ought to help adoption in the workplace environments that we need to get into. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
This is a very cool! I have one suggestion: maybe we should update the clojure website and add the announcement of 1.0 release. I know that Rich has announce the news in the blog. However, most of the people will just go to http://clojure.org/. Therefore, I think that it is very important to put the announcement on the main website. Any comment? On May 4, 7:58 am, Rich Hickey wrote: > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip > > Numbered releases will enable people to consume a stable version of > Clojure and move to bugfix-only incremental versions while preserving > API stability, and to consume libraries designed to work with specific > versions. Providing the bugfix-only revisions depends upon the > community to submit patches for the release branch as well as the > trunk. > > Clojure represents several years of effort on my part, but has also > been shaped profoundly by the community in the 18 months since its > release to the public. I can't thank everyone enough for your > contributions of ideas, bug reports, suggestions, tests, tools, > documentation and code - patches and enhancements. Clojure wouldn't be > where it is today without its community and all of your efforts. > > Of course, there is more to do. Many good ideas have been suggested in > the discussions preceding this release that were best put off for 1.1. > Now with the release we can pursue them, and many others: > > http://clojure.org/todo > > I want to give special thanks to those who have made donations - they > really help! I did the core work on Clojure during a self-funded > sabbatical that has run its course (i.e. through my savings :) - > donations help fund the future. > > Clojure 1.0 is a milestone of achievement, but it also represents a > beginning. With 1.0, Stuart's book, the burgeoning set of libraries in > and outside of contrib, and the large, friendly community, Clojure is > poised to enter a period of increased adoption and application in many > domains. > > Here's to the future! > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure 1.0
Thank you and congrats! On May 4, 9:46 am, AlamedaMike wrote: |> Congratulations, Rich! And thanks for all your hard work. Having a 1.0 |> release out to help adoption in the workplace environments that we |> need to get into. Indeed, this is the case where I work. Having a stable version to target will make it possible for me to develop projects on the clock. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure's handling of numbers with a trailing decimal point
On May 4, 8:11 am, "Stephen C. Gilardi" wrote: > Clojure's number syntax is documented athttp://clojure.org/readerto > be: > > Numbers - as per Java, plus indefinitely long integers are supported, > as well as ratios, e.g. 22/7. Floating point numbers with an M suffix > are read as BigDecimals. > > The enclosed posting reports an unnecessary divergence from "as per > Java" that I'd like to fix. > > May I please enter an issue to track it and provide a patch? > Sure, thanks! Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: constructing maps
2009/5/4 Nathan Hawkins :
>
> Possibly I'm going about this wrong. I'm trying to understand how best
> to construct maps from sequences, by applying a function which returns a
> key / value pair.
>
> Something like this:
>
> (ns test (:use clojure.contrib.str-utils))
>
> (def test-str "foo=1;bar=2;baz=3")
>
> (defn split-kv [text]
> (let [[k v] (re-split #"=" text )]
> {k v}))
>
> (defn split-pairs [text]
> (re-split #";" text))
>
> (map split-kv (split-pairs test-str))
>
> -> ({"foo" "1"} {"bar" "2"} {"baz" "3"})
>
>
> Doesn't really do what I had in mind. And yeah, I figured out that I can
> convert that to a hash-map in various ways, but I had expected map to be
> able to do this.
Hi, no, maybe you make a confusion with the word "map" as in
"hash-map" and as in "mapping". The latter is the meaning for the map
function: mapping a sequence to another sequence (and the result will
always be a sequence).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure 1.0
Rich Hickey wrote: > After a sustained period of API stability and minimal bugs reports, > I'm happy to announce the release of Clojure 1.0! > > http://clojure.googlecode.com/files/clojure_1.0.0.zip This is fantastic! Congratulations to Rich and the Clojure community. Cheers! BG -- Baishampayan Ghose oCricket.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: constructing maps
Nathan Hawkins wrote:
> Possibly I'm going about this wrong. I'm trying to understand how
> best to construct maps from sequences, by applying a function which
> returns a key / value pair.
[...]
> Am I overlooking some already existing function hidden away someplace
> that does this?
Here's a more succinct way:
user> (let [test-str "foo=1;bar=2;baz=3"]
(reduce conj {}
(map #(apply hash-map (seq (.split % "=")))
(.split test-str ";"
{"baz" "3", "bar" "2", "foo" "1"}
-Drew
--~--~-~--~~~---~--~~
You 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: constructing maps
On May 4, 2009, at 14:23, Nathan Hawkins wrote:
> This seems a little bit more like what I expected:
>
> (map-assoc split-kv (split-pairs test-str))
>
> -> {"baz" "3", "bar" "2", "foo" "1"}
>
>
> Am I overlooking some already existing function hidden away someplace
> that does this?
Here's one way to do what you want:
(ns test (:use clojure.contrib.str-utils))
(def test-str "foo=1;bar=2;baz=3")
(defn split-kv [text]
(vec (re-split #"=" text)))
(defn split-pairs [text]
(re-split #";" text))
(apply conj {} (map split-kv (split-pairs test-str)))
Konrad.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Clojure 1.0
After a sustained period of API stability and minimal bugs reports, I'm happy to announce the release of Clojure 1.0! http://clojure.googlecode.com/files/clojure_1.0.0.zip Numbered releases will enable people to consume a stable version of Clojure and move to bugfix-only incremental versions while preserving API stability, and to consume libraries designed to work with specific versions. Providing the bugfix-only revisions depends upon the community to submit patches for the release branch as well as the trunk. Clojure represents several years of effort on my part, but has also been shaped profoundly by the community in the 18 months since its release to the public. I can't thank everyone enough for your contributions of ideas, bug reports, suggestions, tests, tools, documentation and code - patches and enhancements. Clojure wouldn't be where it is today without its community and all of your efforts. Of course, there is more to do. Many good ideas have been suggested in the discussions preceding this release that were best put off for 1.1. Now with the release we can pursue them, and many others: http://clojure.org/todo I want to give special thanks to those who have made donations - they really help! I did the core work on Clojure during a self-funded sabbatical that has run its course (i.e. through my savings :) - donations help fund the future. Clojure 1.0 is a milestone of achievement, but it also represents a beginning. With 1.0, Stuart's book, the burgeoning set of libraries in and outside of contrib, and the large, friendly community, Clojure is poised to enter a period of increased adoption and application in many domains. Here's to the future! Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Unexpected behavior of 'if' with Boolean objects
2009/5/4 Rich Hickey : > > > > On May 4, 7:14 am, Laurent PETIT wrote: >> Hi, >> >> 2009/5/4 Rich Hickey >> >> >> >> >> >> > On May 4, 1:53 am, Laurent PETIT wrote: >> > > 2009/5/4 Christophe Grand >> >> > > > Janico Greifenberg a écrit : >> > > > > Hi, >> >> > > > > I encountered unexpected behavior of the 'if' form in clojure when >> > > > > using >> > > > > instances of java.lang.Boolean as the condition. I wanted to convert >> > > > > input strings to booleans and used the constructor of the Boolean >> > > > > class >> > > > > with the string parameter. However, when I pass these values as a >> > > > > condition to if, the true-branch always gets executed. For example: >> >> > > > > > (if (Boolean. "true") 1 2) >> > > > > 1 >> > > > > > (if (Boolean. "false") 1 2) >> > > > > 1 >> >> > > > > It seems to me that this has to do with the identity of the objects, >> > > > > as >> > > > > (Boolean. "false") is not identical (although equal) to the clojure >> > > > > literal false. Is this behavior intentional or a bug? >> >> > > > > The problem does not occur when I use Boolean/parseBoolean which >> > > > > returns >> > > > > a lower case boolean. >> >> > > > It's intentional, Rich said "for efficiency only canonic false is >> > > > logical false in >> > > > Clojure." inhttp://groups.google.com/group/clojure/msg/81ba3175da9a877c >> >> > > > Workaround: >> > > > > (if (boolean (Boolean. "false")) 1 2) >> > > > 2 >> >> > > At the cost of a lesser experience concerning java interoperability, >> > > then ? >> >> > > Isn't that "premature optimization" ? ;-) >> >> > Not at all. The cost would apply to all usage of 'if' (i.e. all >> > conditionals). >> >> I don't know whether the impact would be that big, it was just a question. >> >> But whatever, shouldn't this be clearly stated in the documentation of >> the 'if' special form (http://clojure.org/special_forms#toc2) ? >> > > Yes, I've enhanced the documentation here: > > http://clojure.org/special_forms#if > > Is that better? Not just better: almost perfect ! :-) --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
constructing maps
Possibly I'm going about this wrong. I'm trying to understand how best
to construct maps from sequences, by applying a function which returns a
key / value pair.
Something like this:
(ns test (:use clojure.contrib.str-utils))
(def test-str "foo=1;bar=2;baz=3")
(defn split-kv [text]
(let [[k v] (re-split #"=" text )]
{k v}))
(defn split-pairs [text]
(re-split #";" text))
(map split-kv (split-pairs test-str))
-> ({"foo" "1"} {"bar" "2"} {"baz" "3"})
Doesn't really do what I had in mind. And yeah, I figured out that I can
convert that to a hash-map in various ways, but I had expected map to be
able to do this. So I wrote this:
(defn map-assoc
"Returns a map consisting of f applied to coll, where f is a function
returning a key and value. f can return either a sequence with two
values or a single item map."
[f coll]
(loop [map {}
s (seq coll)]
(if s
(let [item (f (first s))]
(recur (if (associative? item)
(conj map item)
(assoc map (first item) (second item)))
(next s)))
map)))
This seems a little bit more like what I expected:
(map-assoc split-kv (split-pairs test-str))
-> {"baz" "3", "bar" "2", "foo" "1"}
Am I overlooking some already existing function hidden away someplace
that does this?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Unexpected behavior of 'if' with Boolean objects
On May 4, 7:14 am, Laurent PETIT wrote: > Hi, > > 2009/5/4 Rich Hickey > > > > > > > On May 4, 1:53 am, Laurent PETIT wrote: > > > 2009/5/4 Christophe Grand > > > > > Janico Greifenberg a écrit : > > > > > Hi, > > > > > > I encountered unexpected behavior of the 'if' form in clojure when > > > > > using > > > > > instances of java.lang.Boolean as the condition. I wanted to convert > > > > > input strings to booleans and used the constructor of the Boolean > > > > > class > > > > > with the string parameter. However, when I pass these values as a > > > > > condition to if, the true-branch always gets executed. For example: > > > > > > > (if (Boolean. "true") 1 2) > > > > > 1 > > > > > > (if (Boolean. "false") 1 2) > > > > > 1 > > > > > > It seems to me that this has to do with the identity of the objects, > > > > > as > > > > > (Boolean. "false") is not identical (although equal) to the clojure > > > > > literal false. Is this behavior intentional or a bug? > > > > > > The problem does not occur when I use Boolean/parseBoolean which > > > > > returns > > > > > a lower case boolean. > > > > > It's intentional, Rich said "for efficiency only canonic false is > > > > logical false in > > > > Clojure." inhttp://groups.google.com/group/clojure/msg/81ba3175da9a877c > > > > > Workaround: > > > > > (if (boolean (Boolean. "false")) 1 2) > > > > 2 > > > > At the cost of a lesser experience concerning java interoperability, then > > > ? > > > > Isn't that "premature optimization" ? ;-) > > > Not at all. The cost would apply to all usage of 'if' (i.e. all > > conditionals). > > I don't know whether the impact would be that big, it was just a question. > > But whatever, shouldn't this be clearly stated in the documentation of > the 'if' special form (http://clojure.org/special_forms#toc2) ? > Yes, I've enhanced the documentation here: http://clojure.org/special_forms#if Is that better? Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure's handling of numbers with a trailing decimal point
Clojure's number syntax is documented at http://clojure.org/reader to be: Numbers - as per Java, plus indefinitely long integers are supported, as well as ratios, e.g. 22/7. Floating point numbers with an M suffix are read as BigDecimals. The enclosed posting reports an unnecessary divergence from "as per Java" that I'd like to fix. May I please enter an issue to track it and provide a patch? --Steve On Apr 24, 2009, at 6:07 PM, Stephen C. Gilardi wrote: I noticed today that a series of digits with a trailing decimal point are read by Clojure as an Integer. user=> (class 123.) java.lang.Integer In contrast, Java reads such a number as a double. % javac Foo.java Foo.java:5: possible loss of precision found : double required: int int a = 123.; ^ 1 error Another place this comes up is with a number formatted as 123.e4. Currently that's an invalid number in Clojure: user=> (class 123.e4) java.lang.NumberFormatException: Invalid number: 123.e4 java.lang.Exception: Unmatched delimiter: ) user=> Java reads it as 123.0 To bring Clojure in line with Java for numbers formatted this way, I propose changing the reader to match Java's behavior for these cases. I have a patch which I'll attach to an issue if one is approved. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: ANN: Full, continuously updated documentation for clojure.contrib
Absolutely brilliant. Exactly what clojure-contrib and the clojure community needed. Thank you! On Mon, May 4, 2009 at 2:41 AM, Tom Faulhaber wrote: > > Hello everybody, > > As many of you know, I have been working on a "contrib autodoc robot" > for the last little while. > > It is now up and running and you can use the results here: > > http://code.google.com/p/clojure-contrib/wiki/OverviewOfContrib > > It includes: > * An overview of each namespace in contrib (including the author and > shortcut links to documentation for each of the functions). > * An API page for each name space that includes the doc string for > each function or variable in the namespace and a direct link to the > source for that function or variable. > * An index of all the documented functions and variables so that you > can find them by name. > * A JSON file that allows other tools to build off this information > (at http://clojure-contrib.googlecode.com/svn/wiki/ApiDocIndex.json - > still very much under development). > > Each page has a sidebar to allow for quick access from place to place. > > All the pages are stored in the wiki on the google code home for > clojure-contrib. This is both a blessing and a curse, since the google > code wiki is a little brain-dead. As a result, the formatting is not > as awesome as I would like. > > The goal of this project is to make contrib a more open and accessible > resource for the community. Please take advantage of this to see and > understand the great stuff that folks have added to contrib for your > programming pleasure. I will be making sure it is kept up-to-date > (eventually that will be automated, but for now I have to type "ant" > once in a while). > > To contrib authors: I have added metadata to your namespaces. Please > update and correct it as you would like. The updates will be > propagated to the site. Also, please review the doc for your > contributions to make sure it is complete and correct in general. Let > me know if anything doesn't seem to be going through the wringer > correctly. > > Happy perusing! > > Tom > > > > --~--~-~--~~~---~--~~ You 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: ANN: Full, continuously updated documentation for clojure.contrib
This is really good. Have you considered a mechanism for including richer documentation per contribution/namespace, ala javadocs package document e.g. html files with images etc ? On 04/05/2009, at 4:11 PM, Tom Faulhaber wrote: > > Hello everybody, > > As many of you know, I have been working on a "contrib autodoc robot" > for the last little while. > > It is now up and running and you can use the results here: > > http://code.google.com/p/clojure-contrib/wiki/OverviewOfContrib > > It includes: > * An overview of each namespace in contrib (including the author and > shortcut links to documentation for each of the functions). > * An API page for each name space that includes the doc string for > each function or variable in the namespace and a direct link to the > source for that function or variable. > * An index of all the documented functions and variables so that you > can find them by name. > * A JSON file that allows other tools to build off this information > (at http://clojure-contrib.googlecode.com/svn/wiki/ApiDocIndex.json - > still very much under development). > > Each page has a sidebar to allow for quick access from place to place. > > All the pages are stored in the wiki on the google code home for > clojure-contrib. This is both a blessing and a curse, since the google > code wiki is a little brain-dead. As a result, the formatting is not > as awesome as I would like. > > The goal of this project is to make contrib a more open and accessible > resource for the community. Please take advantage of this to see and > understand the great stuff that folks have added to contrib for your > programming pleasure. I will be making sure it is kept up-to-date > (eventually that will be automated, but for now I have to type "ant" > once in a while). > > To contrib authors: I have added metadata to your namespaces. Please > update and correct it as you would like. The updates will be > propagated to the site. Also, please review the doc for your > contributions to make sure it is complete and correct in general. Let > me know if anything doesn't seem to be going through the wringer > correctly. > > Happy perusing! > > Tom > > > Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. -- Antoine de Saint-Exupery --~--~-~--~~~---~--~~ You 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: Unexpected behavior of 'if' with Boolean objects
Hi, 2009/5/4 Rich Hickey > > > > On May 4, 1:53 am, Laurent PETIT wrote: > > 2009/5/4 Christophe Grand > > > > > > > > > > > > > Janico Greifenberg a écrit : > > > > Hi, > > > > > > I encountered unexpected behavior of the 'if' form in clojure when using > > > > instances of java.lang.Boolean as the condition. I wanted to convert > > > > input strings to booleans and used the constructor of the Boolean class > > > > with the string parameter. However, when I pass these values as a > > > > condition to if, the true-branch always gets executed. For example: > > > > > > > (if (Boolean. "true") 1 2) > > > > 1 > > > > > (if (Boolean. "false") 1 2) > > > > 1 > > > > > > It seems to me that this has to do with the identity of the objects, as > > > > (Boolean. "false") is not identical (although equal) to the clojure > > > > literal false. Is this behavior intentional or a bug? > > > > > > The problem does not occur when I use Boolean/parseBoolean which returns > > > > a lower case boolean. > > > > > It's intentional, Rich said "for efficiency only canonic false is > > > logical false in > > > Clojure." inhttp://groups.google.com/group/clojure/msg/81ba3175da9a877c > > > > > Workaround: > > > > (if (boolean (Boolean. "false")) 1 2) > > > 2 > > > > At the cost of a lesser experience concerning java interoperability, then ? > > > > Isn't that "premature optimization" ? ;-) > > Not at all. The cost would apply to all usage of 'if' (i.e. all > conditionals). I don't know whether the impact would be that big, it was just a question. But whatever, shouldn't this be clearly stated in the documentation of the 'if' special form ( http://clojure.org/special_forms#toc2 ) ? "For performance reasons, 'if performs java instance comparison, so only Boolean instances that are equal to Boolean.FALSE will be matched as false (so one should only use Boolean/valueOf for creating Boolean instances)". (of course, I agree with the fact that Boolean should be used via the static valueOf method rather than the constructor) > > The Boolean ctor is documented as a 'do not use' item: > > http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Boolean.html#Boolean(boolean) The Boolean ctor is not documented as 'do not use', but 'it is rarely appropriate to use'. Doesn't that make a difference ? --~--~-~--~~~---~--~~ You 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: ANN: Full, continuously updated documentation for clojure.contrib
is it encouraged for people to post questions to that wiki? and do they end up near what the question is referring to? For example, I was just looking at the docs there for "cond/cond-let" and thought a discussion could help make the docs more immediately penetrable. On Mon, May 4, 2009 at 2:41 AM, Tom Faulhaber wrote: > > Hello everybody, > > As many of you know, I have been working on a "contrib autodoc robot" > for the last little while. > > It is now up and running and you can use the results here: > > http://code.google.com/p/clojure-contrib/wiki/OverviewOfContrib > > It includes: > * An overview of each namespace in contrib (including the author and > shortcut links to documentation for each of the functions). > * An API page for each name space that includes the doc string for > each function or variable in the namespace and a direct link to the > source for that function or variable. > * An index of all the documented functions and variables so that you > can find them by name. > * A JSON file that allows other tools to build off this information > (at http://clojure-contrib.googlecode.com/svn/wiki/ApiDocIndex.json - > still very much under development). > > Each page has a sidebar to allow for quick access from place to place. > > All the pages are stored in the wiki on the google code home for > clojure-contrib. This is both a blessing and a curse, since the google > code wiki is a little brain-dead. As a result, the formatting is not > as awesome as I would like. > > The goal of this project is to make contrib a more open and accessible > resource for the community. Please take advantage of this to see and > understand the great stuff that folks have added to contrib for your > programming pleasure. I will be making sure it is kept up-to-date > (eventually that will be automated, but for now I have to type "ant" > once in a while). > > To contrib authors: I have added metadata to your namespaces. Please > update and correct it as you would like. The updates will be > propagated to the site. Also, please review the doc for your > contributions to make sure it is complete and correct in general. Let > me know if anything doesn't seem to be going through the wringer > correctly. > > Happy perusing! > > Tom > > > > --~--~-~--~~~---~--~~ You 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: ANN: Full, continuously updated documentation for clojure.contrib
This is great! I hope the contrib authors will take the time to improve their documentation where needed and add some examples for functions and macros whose use isn't obvious. On Mon, May 4, 2009 at 1:41 AM, Tom Faulhaber wrote: > > Hello everybody, > > As many of you know, I have been working on a "contrib autodoc robot" > for the last little while. > > It is now up and running and you can use the results here: > > http://code.google.com/p/clojure-contrib/wiki/OverviewOfContrib > > It includes: > * An overview of each namespace in contrib (including the author and > shortcut links to documentation for each of the functions). > * An API page for each name space that includes the doc string for > each function or variable in the namespace and a direct link to the > source for that function or variable. > * An index of all the documented functions and variables so that you > can find them by name. > * A JSON file that allows other tools to build off this information > (at http://clojure-contrib.googlecode.com/svn/wiki/ApiDocIndex.json - > still very much under development). > > Each page has a sidebar to allow for quick access from place to place. > > All the pages are stored in the wiki on the google code home for > clojure-contrib. This is both a blessing and a curse, since the google > code wiki is a little brain-dead. As a result, the formatting is not > as awesome as I would like. > > The goal of this project is to make contrib a more open and accessible > resource for the community. Please take advantage of this to see and > understand the great stuff that folks have added to contrib for your > programming pleasure. I will be making sure it is kept up-to-date > (eventually that will be automated, but for now I have to type "ant" > once in a while). > > To contrib authors: I have added metadata to your namespaces. Please > update and correct it as you would like. The updates will be > propagated to the site. Also, please review the doc for your > contributions to make sure it is complete and correct in general. Let > me know if anything doesn't seem to be going through the wringer > correctly. > > Happy perusing! > > Tom > > > > -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Problem using emacs - slime - clojure
On Mon, May 4, 2009 at 12:28 PM, Arie van Wingerden wrote: > Hi, > in the first place i should say i am not knowledgeable on emacs / slime / > swank ;-) > I set up the emacs environment as described here: > > http://dc.clj.fogus.me/index.php?title=Installing_Clojure_and_Slime_on_Windows > Simple evaluation of e.g. (+ 2 3) goes fine. > However, when i try to evaluate this piece of swing code (listed here: > http://clojure.org/jvm_hosted ) > the window is correctly shown, but is not responsive; > that is: i cannot even enter a value to be converted or click on > "convert" button. > I tried this code in the Clojure console and there it works fine. > Any ideas? TIA. This sounds like something that's come up on the list before. Try pressing Enter in the REPL (or is that the inferior lisp buffer? I don't use Emacs) after the window is displayed. At least, I think that was something that worked around the problem. I can't remember if there was an actual solution, though. Perhaps searching through the archives will turn up something. -- Michael Wood --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
Problem using emacs - slime - clojure
Hi, in the first place i should say i am not knowledgeable on emacs / slime / swank ;-) I set up the emacs environment as described here: http://dc.clj.fogus.me/index.php?title=Installing_Clojure_and_Slime_on_Windows Simple evaluation of e.g. (+ 2 3) goes fine. However, when i try to evaluate this piece of swing code (listed here: http://clojure.org/jvm_hosted ) the window is correctly shown, but is not responsive; that is:i cannot even enter a value to be converted or click on "convert" button. I tried this code in the Clojure console and there it works fine. Any ideas? TIA. --~--~-~--~~~---~--~~ You 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: Unexpected behavior of 'if' with Boolean objects
On May 4, 1:53 am, Laurent PETIT wrote: > 2009/5/4 Christophe Grand > > > > > > > Janico Greifenberg a écrit : > > > Hi, > > > > I encountered unexpected behavior of the 'if' form in clojure when using > > > instances of java.lang.Boolean as the condition. I wanted to convert > > > input strings to booleans and used the constructor of the Boolean class > > > with the string parameter. However, when I pass these values as a > > > condition to if, the true-branch always gets executed. For example: > > > > > (if (Boolean. "true") 1 2) > > > 1 > > > > (if (Boolean. "false") 1 2) > > > 1 > > > > It seems to me that this has to do with the identity of the objects, as > > > (Boolean. "false") is not identical (although equal) to the clojure > > > literal false. Is this behavior intentional or a bug? > > > > The problem does not occur when I use Boolean/parseBoolean which returns > > > a lower case boolean. > > > It's intentional, Rich said "for efficiency only canonic false is > > logical false in > > Clojure." inhttp://groups.google.com/group/clojure/msg/81ba3175da9a877c > > > Workaround: > > > (if (boolean (Boolean. "false")) 1 2) > > 2 > > At the cost of a lesser experience concerning java interoperability, then ? > > Isn't that "premature optimization" ? ;-) Not at all. The cost would apply to all usage of 'if' (i.e. all conditionals). The Boolean ctor is documented as a 'do not use' item: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Boolean.html#Boolean(boolean) I'm not going to make all of Clojure slower in order to support people using something they are supposed to avoid. The right thing is to use valueOf, as Nick suggested: user=> (if (Boolean/valueOf "false") 1 2) 2 Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: difference between vimclojure and slime
Hi Boris, Am 03.05.2009 um 22:57 schrieb bOR_: Slime would do fine. I could start a (simulation) of 1 years, and see the output that (simulation) generated every 100 years scroll by in the mean time. Vimclojure seems to store all that output and spit it out at the end. Is this something I can change with a toggle? Most likely: no. SLIME really has a server connection it writes to and reads from. Vim on the other hand cannot do this. It just starts the command, waits for it exiting and then reads the output from a temporary file. There is no way, I know, to read incrementally the output of a program. So most likely there will be no way to run such long running commands. The only workaround I can offer is to start a usual Repl in a shell. From there start the nailgun server directly in its own thread. Now you can connect as usual via Vim for development and can fire off long running computations from the shell Repl. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
