Re: new Getting Started page
The idea that the way to get started is with a fancy editor and a fancy ide is just crazy. The way to get started with Clojure is: write functions, and run them, and be happy. None of that requires any of the mandated complications that come from sophisticated editing environments. Now once you are hooked writing clojure you may want a sophisticated environment and it is great to give people options and help setting that all up. I spent a lot of time on a windows netbook writing solutions to euler project problems notepad++ and just pasting the functions into a repl running in a console. It worked great. I think a great structure for the Getting Started page would be something like: 1. Starting a Basic repl - java -jar clojure.jar - maybe something about jline or rlwrap (it would be great if we could get something like jline into the default repl) 2. Fun stuff to do with the basic repl - some swing stuff - copy and pastable code snippets - some parallel stuff with futures or pmap or something - something with the stm - agents are cool, right? - links to 4clojure and project euler 3. Where to go from here - fancy editing setups with the editor of your choice On Fri, Sep 2, 2011 at 10:18 PM, Sean Corfield seancorfi...@gmail.com wrote: On Fri, Sep 2, 2011 at 5:27 PM, jonathan.watmo...@gmail.com jonathan.watmo...@gmail.com wrote: 1. Download clojure and unzip 2. Move to the folder and type 'java -cp clojure.jar clojure.main' in a terminal Because this is exactly what's wrong with the current getting started process. It's not n00b-friendly, esp. to people coming in from outside the Java space. There's a huge set of advantages to starting in a terminal: If you're not a Windows user? I'm not a Windows user. I've been a Unix developer for many decades, but I deal with a lot of Windows developers and expecting them to do everything on the command line is a complete non-starter. 2. You can easily add jars. This means nothing to people coming from outside the Java world. 3. You can start multiple terminal windows to try different things. Not a good approach for Windows users. 4. You can use your preferred editors This is a valid comment. If you already have a preferred editor, we should guide you to how to do Clojure development with that editor. I think it's interesting that a lot of Clojurians use Emacs but outside of the Clojure community I don't know _anyone_ who uses Emacs. It's probably a good tweak to Nick's page to add a rider that if you have a preferred editor, go read _this_ page.. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: not= counterintuitive?
ax2groin ax2gr...@gmail.com writes: This code doesn't return the value I intuitively expect: user= (not= 1 2 1) true When I write that, I was expecting the equivalent of (and (= 1 2) (= 1 1)), but the macro expansion is essentially (not (= 1 2 1)). If you were expecting (not (and (= 1 2) (= 1 1))) then it would match your expectations. -- Cheers ~vijay -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-based non-blocking webserver like Node.js
Can someone explain please what class threads are?? And whether is threads are expensive depends on the is On Sep 3, 2011 5:09 AM, Raoul Duke rao...@gmail.com wrote: On Fri, Sep 2, 2011 at 11:20 AM, billh2233 bill.har...@gmail.com wrote: I like Node.js's non-blocking IO for performance reasons, though it is built around a single-threaded model whereas clojure is built around a multi-core/concurrency model. I wonder if the two concepts can be combined somehow. * python lets you combine processes, pre-emptive threads, and coroutines. see the greenlet stuff. * class threads are heavy and context switches suck and that is one reason people don't like them vs. the node.js speeds. however, look at Erlang since it has very low context switching overhead, since it doesn't use OS threads. http://thatclevershark.org/benchmarks.html * theoretically, threads and event-driven styles are duals of each other, or maybe the same thing at some level. http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf http://www.bluishcoder.co.nz/2006/04/unifying-events-and-threads-in-haskell.html sincerely. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: new Getting Started page
I think the closer we get to recommending the equivalent of DrRacket for Racket, the better. Clooj has that lightweight feel, like DrRacket. It's not intimidating, and the basics are laid out in front of you. I've never used a command line REPL for Clojure that didn't suck in some way. I'd want to make sure it's awesome before we recommend it as a first choice. I'm thinking of the Haskell cmd line REPL as a model. My 2c. Ambrose -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Eval in future ... Bug or feature?
On Sep 3, 2:35 am, Brian Goslinga quickbasicg...@gmail.com wrote: The future is probably executing in a different thread, so the dynamic binding of *ns* probably isn't the user namespace. Thanks Brian. That's exactly what happens: user (future *ns*) #core$future_call$reify__5496@489a44f1: :pending user (deref *1) #Namespace clojure.core Thus, I have to either re-bind *ns* or use one of the bound-fn forms: user (future (binding [*ns* (the-ns 'user)] (eval '(my-inc 1 #core$future_call$reify__5496@eaa4c7c: :pending user (deref *1) 2 user (pmap (bound-fn* eval) '((my-inc 1) (my-inc 2))) (2 3) Thanks again, Nils -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: not= counterintuitive?
Sounds like you want a function such as: none= On Sep 3, 2011 4:30 AM, Vijay Lakshminarayanan liyer.vi...@gmail.com wrote: ax2groin ax2gr...@gmail.com writes: This code doesn't return the value I intuitively expect: user= (not= 1 2 1) true When I write that, I was expecting the equivalent of (and (= 1 2) (= 1 1)), but the macro expansion is essentially (not (= 1 2 1)). If you were expecting (not (and (= 1 2) (= 1 1))) then it would match your expectations. -- Cheers ~vijay -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Eval in future ... Bug or feature?
Hi,
Am 03.09.2011 um 15:22 schrieb Nils Bertschinger:
Thus, I have to either re-bind *ns* or use one of the bound-fn forms:
Or use syntax-quote (`) instead of normal quote ('). quote is in 95% of the
cases not what you want.
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: not= counterintuitive?
On Sat, Sep 3, 2011 at 10:59 AM, Alex Baranosky
alexander.barano...@gmail.com wrote:
Sounds like you want a function such as:
none=
...which could be written as #(not-any? #{1} [1 2 3])
--Chouser
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: not= counterintuitive?
On Sep 2, 4:48 pm, ax2groin ax2gr...@gmail.com wrote: That's what I get for posting a question while feeding a 1-year-old child and getting ready to leave for lunch. I was trying to put together a (for) construct to output the combinations of a set, and my logic was flawed. Here's what I really wanted [for sets of 3]: (for [m x n x o x :while (and (not= m n) (not= m o) (not= n o))] [m n o]) Maybe not the most efficient, but the smallest construct I've come up with, but it isn't generic enough for me yet. I'll keep working on it. So, you want to make sure each value in the vector is unique? My first thought was to put them into a set, then see if the set was equal to the vector, but clojure's equality doesn't allow for that. And if you put the set back into a vector, you've changed the order. Now I think you might be asking for the permutations. clojure.contrib.combinatorics as a permutations function: user= (clojure.contrib.combinatorics/permutations [1 2 3]) ((1 2 3) (1 3 2) (2 1 3) (2 3 1) (3 1 2) (3 2 1)) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: new Getting Started page
On Fri, Sep 2, 2011 at 11:11 PM, Kevin Downey redc...@gmail.com wrote: I spent a lot of time on a windows netbook writing solutions to euler project problems notepad++ and just pasting the functions into a repl running in a console. It worked great. Yup, and that's just fine _for you_ but you are not the target demographic being discussed :) For folks comfortable with a command line and a simple text editor, the REPL is a very reasonable first step. I come from a Unix background in the 80's and, like you, I'm perfectly happy with a REPL and vim - but these days I live in Eclipse so, for me, CCW is the best choice (with a live REPL open in Eclipse all the time). I guess the question is: how serious are we about catering to the general developer at large? My experience over the years, dealing with a lot of Windows developers, is what makes me push back on this. I've seen a very large number of experienced developers on Windows who don't know how to do anything on the command line - if it doesn't have a GUI, they won't touch it. So, do we want to help those developers learn Clojure? If our consensus answer as a community is no, that's fine but I just want us to be clear about that. The Scala community get flak for a widely perceived attitude that says if you're too dumb to understand the type system, go away and stop bothering us. I hear from a lot of Clojure n00bs who find the focus on the command line (and the focus on Emacs!) to be very off-putting. I'd rather we didn't alienate those folks but I don't know how the Clojure community as a whole feels about that? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: new Getting Started page
Sean, I agree with you, of course 2011/9/3 Sean Corfield seancorfi...@gmail.com On Fri, Sep 2, 2011 at 11:11 PM, Kevin Downey redc...@gmail.com wrote: I spent a lot of time on a windows netbook writing solutions to euler project problems notepad++ and just pasting the functions into a repl running in a console. It worked great. Yup, and that's just fine _for you_ but you are not the target demographic being discussed :) For folks comfortable with a command line and a simple text editor, the REPL is a very reasonable first step. I come from a Unix background in the 80's and, like you, I'm perfectly happy with a REPL and vim - but these days I live in Eclipse so, for me, CCW is the best choice (with a live REPL open in Eclipse all the time). I guess the question is: how serious are we about catering to the general developer at large? My experience over the years, dealing with a lot of Windows developers, is what makes me push back on this. I've seen a very large number of experienced developers on Windows who don't know how to do anything on the command line - if it doesn't have a GUI, they won't touch it. So, do we want to help those developers learn Clojure? If our consensus answer as a community is no, that's fine but I just want us to be clear about that. The Scala community get flak for a widely perceived attitude that says if you're too dumb to understand the type system, go away and stop bothering us. I hear from a lot of Clojure n00bs who find the focus on the command line (and the focus on Emacs!) to be very off-putting. I'd rather we didn't alienate those folks but I don't know how the Clojure community as a whole feels about that? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: new Getting Started page
For me, unlearning 15 years of OO and Java/j2ee makes a trifle thing like a new environment a walk in the park :) My semi-serious point is that as a beginner the question being answered is more like what is it all about and how can I try these samples/examples rather than how do I do 'proper' enterprise development with this. The best answer for the former isn't necessarily the best answer for the later. Getting started should be the smallest set of steps possible; the REPL. There is no beginner solution involving an IDE because they are all full of their own complexity. Clooj seems the simplest but you still need to create projects which is one step too far for getting started Sent from my iPad On 3 Sep 2011, at 19:49, Laurent PETIT laurent.pe...@gmail.com wrote: Sean, I agree with you, of course 2011/9/3 Sean Corfield seancorfi...@gmail.com On Fri, Sep 2, 2011 at 11:11 PM, Kevin Downey redc...@gmail.com wrote: I spent a lot of time on a windows netbook writing solutions to euler project problems notepad++ and just pasting the functions into a repl running in a console. It worked great. Yup, and that's just fine _for you_ but you are not the target demographic being discussed :) For folks comfortable with a command line and a simple text editor, the REPL is a very reasonable first step. I come from a Unix background in the 80's and, like you, I'm perfectly happy with a REPL and vim - but these days I live in Eclipse so, for me, CCW is the best choice (with a live REPL open in Eclipse all the time). I guess the question is: how serious are we about catering to the general developer at large? My experience over the years, dealing with a lot of Windows developers, is what makes me push back on this. I've seen a very large number of experienced developers on Windows who don't know how to do anything on the command line - if it doesn't have a GUI, they won't touch it. So, do we want to help those developers learn Clojure? If our consensus answer as a community is no, that's fine but I just want us to be clear about that. The Scala community get flak for a widely perceived attitude that says if you're too dumb to understand the type system, go away and stop bothering us. I hear from a lot of Clojure n00bs who find the focus on the command line (and the focus on Emacs!) to be very off-putting. I'd rather we didn't alienate those folks but I don't know how the Clojure community as a whole feels about that? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: new Getting Started page
2011/9/3 Colin Yates colin.ya...@gmail.com For me, unlearning 15 years of OO and Java/j2ee makes a trifle thing like a new environment a walk in the park :) My semi-serious point is that as a beginner the question being answered is more like what is it all about and how can I try these samples/examples rather than how do I do 'proper' enterprise development with this. The best answer for the former isn't necessarily the best answer for the later. Getting started should be the smallest set of steps possible; the REPL. There is no beginner solution involving an IDE because they are all full of their own complexity. Clooj seems the simplest but you still need to create projects which is one step too far for getting started I had the same remark last time I checked it, indeed. Sent from my iPad On 3 Sep 2011, at 19:49, Laurent PETIT laurent.pe...@gmail.com wrote: Sean, I agree with you, of course 2011/9/3 Sean Corfield seancorfi...@gmail.comseancorfi...@gmail.com On Fri, Sep 2, 2011 at 11:11 PM, Kevin Downey redc...@gmail.com redc...@gmail.com wrote: I spent a lot of time on a windows netbook writing solutions to euler project problems notepad++ and just pasting the functions into a repl running in a console. It worked great. Yup, and that's just fine _for you_ but you are not the target demographic being discussed :) For folks comfortable with a command line and a simple text editor, the REPL is a very reasonable first step. I come from a Unix background in the 80's and, like you, I'm perfectly happy with a REPL and vim - but these days I live in Eclipse so, for me, CCW is the best choice (with a live REPL open in Eclipse all the time). I guess the question is: how serious are we about catering to the general developer at large? My experience over the years, dealing with a lot of Windows developers, is what makes me push back on this. I've seen a very large number of experienced developers on Windows who don't know how to do anything on the command line - if it doesn't have a GUI, they won't touch it. So, do we want to help those developers learn Clojure? If our consensus answer as a community is no, that's fine but I just want us to be clear about that. The Scala community get flak for a widely perceived attitude that says if you're too dumb to understand the type system, go away and stop bothering us. I hear from a lot of Clojure n00bs who find the focus on the command line (and the focus on Emacs!) to be very off-putting. I'd rather we didn't alienate those folks but I don't know how the Clojure community as a whole feels about that? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure%2bunsubscr...@googlegroups.com clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Documentation For Lisp Programming in Clojure.
I have seen the three current books on Clojure. They are all good general books that describe the whole language. I have not had a chance to see Chas Emerick's new Clojure O'Reilly book, so cannot comment on that. Are there any books available or upcoming that concentrate more on Lisp programming in Clojure's dialect? If not, what is the closest Lisp dialect to Clojure and is the best book on teaching traversing trees, recursion, and so on? Thanks. cmn -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: new Getting Started page
On Sep 3, 2011, at 2:58 PM, Colin Yates wrote: My semi-serious point is that as a beginner the question being answered is more like what is it all about and how can I try these samples/examples rather than how do I do 'proper' enterprise development with this. The best answer for the former isn't necessarily the best answer for the later. Getting started should be the smallest set of steps possible; the REPL. There is no beginner solution involving an IDE because they are all full of their own complexity. Clooj seems the simplest but you still need to create projects which is one step too far for getting started IMO an important getting started target is actually somewhere in between these extremes -- nowhere near how do I do 'proper' enterprise development with this but also not quite just what is it all about, which after all you can learn from reading a blog post or maybe http://www.try-clojure.org/. There's a sweet spot with little or no more complexity than a minimal REPL that allows one to see what it's all about but also to do quite a lot of serious work, and to my mind clooj, like similar environments for other languages (DrRacket was mentioned here and that's also in this category), hits this sweet spot very nicely. Setup for clooj is download and double click -- awesome! -- and you do NOT need to create a project to get a REPL -- it's there right away, although I agree that it could be presented more clearly. There is very little complexity even when you want to do more, since most of the features are easily discoverable through a small set of obvious menus. And Clooj helps you in simple, discoverable ways with bracket matching and proper indentation, without which nobody should ever be asked to write even a single Lisp form -- IMO again of course, but IMO as someone who has taught Lisp to newcomers for 20 years or so. It's trued that most IDEs have a lot of complexity -- I still haven't fully figured out the others that I've used for Clojure -- but Clooj really doesn't and yet it can support real work. Maybe not proper enterprise development (I don't do that), but definitely fairly sophisticated academic projects. The path that I plan to present to my students is start with Clooj, then if you want more features graduate to Clooj+lein, and that may be all you ever need. Or if you love emacs or eclipse or netbeans or… then try these other options…. -Lee -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Differences Between seq? and sequential?
user (map (juxt seq? sequential?) '([1 2] (1 2))) ([false true] [true true]) All seqs are sequential, but not all sequential things are seqs. On Sep 3, 12:14 pm, octopusgrabbus octopusgrab...@gmail.com wrote: I've noticed that solutions to rolling your own Clojure flatten involve the sequential? function rather than the seq? function. What is the difference between these two functions? When I create a sequence is it automatically sequential or does the creation require an overt step? Thanks. cmn -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
An open call to the community: Let's prepare for 1.3
Hey Folks, With the release of 1.3 growing ever nearer, it's time that we as a community do everything we can to make the migration smooth. In general, this means relatively simple changes to the libs under your control, but I also think we should take this opportunity to do some house cleaning. If you maintain a clojure library (even if library just means some random thing up on github that a few people use), please consider doing the following over the next few weeks: - *Try migrating your lib to 1.3* - Create a 1.3 branch - Remove earmuffs around any non-rebound vars - Add earmuffs to any vars that are rebound using thread-level binding - Add ^:dynamic to these vars - If you rely on the built in Numerics, check to see if the new changeshttp://dev.clojure.org/display/doc/Documentation+for+1.3+Numericsin 1.3 affect you. - *Do some house cleaning* - If you are no longer maintaining this library, simply note so at the top of your Readme. If the reason is that a better alternative has spring up, link to it. - Take a look at your dev dependencies and determine if any of them should remain in light of the ability to globally install leiningen plugins. *If you have swank-clojure as a dependency, please remove it*: this has been the source of numerous issues. None of these are complicated or particularly time consuming, and the impact they will have as people try to migrate forward will be tremendous. Also, don't fall into the trap of thinking no one could possibly be using this tiny project - I bet they are and bet they'll want to continue to :) If I've missed some steps, please reply with them. Are there more house cleaning things we should do? Have you run into any other issues migrating to 1.3 (the steps listed here were purely what was necessary for me and the few others I've talked to)? Cheers, 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: not= counterintuitive?
Hi, Am 03.09.2011 um 19:30 schrieb Despite: So, you want to make sure each value in the vector is unique? My first thought was to put them into a set, then see if the set was equal to the vector, but clojure's equality doesn't allow for that. And if you put the set back into a vector, you've changed the order. You can check (= (count v) (count (set v))) whether there are no duplicates. Sincerley Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: An open call to the community: Let's prepare for 1.3
I prefer to use ^{:dynamic true} instead of ^:dynamic, unless you're
recommending intentionally breaking compatibility with 1.2 so as to
encourage people to move to 1.3.
On Sep 3, 12:27 pm, Chris Granger ibdk...@gmail.com wrote:
Hey Folks,
With the release of 1.3 growing ever nearer, it's time that we as a
community do everything we can to make the migration smooth. In general,
this means relatively simple changes to the libs under your control, but I
also think we should take this opportunity to do some house cleaning.
If you maintain a clojure library (even if library just means some random
thing up on github that a few people use), please consider doing the
following over the next few weeks:
- *Try migrating your lib to 1.3*
- Create a 1.3 branch
- Remove earmuffs around any non-rebound vars
- Add earmuffs to any vars that are rebound using thread-level binding
- Add ^:dynamic to these vars
- If you rely on the built in Numerics, check to see if the new
changeshttp://dev.clojure.org/display/doc/Documentation+for+1.3+Numericsin
1.3 affect you.
- *Do some house cleaning*
- If you are no longer maintaining this library, simply note so at the
top of your Readme. If the reason is that a better alternative has
spring
up, link to it.
- Take a look at your dev dependencies and determine if any of them
should remain in light of the ability to globally install
leiningen plugins.
*If you have swank-clojure as a dependency, please remove it*: this
has been the source of numerous issues.
None of these are complicated or particularly time consuming, and the impact
they will have as people try to migrate forward will be tremendous. Also,
don't fall into the trap of thinking no one could possibly be using this
tiny project - I bet they are and bet they'll want to continue to :)
If I've missed some steps, please reply with them. Are there more house
cleaning things we should do? Have you run into any other issues migrating
to 1.3 (the steps listed here were purely what was necessary for me and the
few others I've talked to)?
Cheers,
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
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: not= counterintuitive?
(= (seq v) (distinct v)) will short-circuit as soon as an inequality is found. On Sep 3, 12:47 pm, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 03.09.2011 um 19:30 schrieb Despite: So, you want to make sure each value in the vector is unique? My first thought was to put them into a set, then see if the set was equal to the vector, but clojure's equality doesn't allow for that. And if you put the set back into a vector, you've changed the order. You can check (= (count v) (count (set v))) whether there are no duplicates. Sincerley Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: An open call to the community: Let's prepare for 1.3
I prefer to use ^{:dynamic true} instead of ^:dynamic, unless you're
recommending intentionally breaking compatibility with 1.2 so as to
encourage people to move to 1.3.
What is meant by breaking compatibility? I haven't noticed any
issues using ^:dynamic with 1.2, am I missing something?
Thanks.
On Sat, Sep 3, 2011 at 4:13 PM, Alan Malloy a...@malloys.org wrote:
I prefer to use ^{:dynamic true} instead of ^:dynamic, unless you're
recommending intentionally breaking compatibility with 1.2 so as to
encourage people to move to 1.3.
On Sep 3, 12:27 pm, Chris Granger ibdk...@gmail.com wrote:
Hey Folks,
With the release of 1.3 growing ever nearer, it's time that we as a
community do everything we can to make the migration smooth. In general,
this means relatively simple changes to the libs under your control, but I
also think we should take this opportunity to do some house cleaning.
If you maintain a clojure library (even if library just means some random
thing up on github that a few people use), please consider doing the
following over the next few weeks:
- *Try migrating your lib to 1.3*
- Create a 1.3 branch
- Remove earmuffs around any non-rebound vars
- Add earmuffs to any vars that are rebound using thread-level binding
- Add ^:dynamic to these vars
- If you rely on the built in Numerics, check to see if the new
changeshttp://dev.clojure.org/display/doc/Documentation+for+1.3+Numericsin
1.3 affect you.
- *Do some house cleaning*
- If you are no longer maintaining this library, simply note so at the
top of your Readme. If the reason is that a better alternative has
spring
up, link to it.
- Take a look at your dev dependencies and determine if any of them
should remain in light of the ability to globally install
leiningen plugins.
*If you have swank-clojure as a dependency, please remove it*: this
has been the source of numerous issues.
None of these are complicated or particularly time consuming, and the impact
they will have as people try to migrate forward will be tremendous. Also,
don't fall into the trap of thinking no one could possibly be using this
tiny project - I bet they are and bet they'll want to continue to :)
If I've missed some steps, please reply with them. Are there more house
cleaning things we should do? Have you run into any other issues migrating
to 1.3 (the steps listed here were purely what was necessary for me and the
few others I've talked to)?
Cheers,
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
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: An open call to the community: Let's prepare for 1.3
On Sep 3, 3:13 pm, Alan Malloy a...@malloys.org wrote:
I prefer to use ^{:dynamic true} instead of ^:dynamic, unless you're
recommending intentionally breaking compatibility with 1.2 so as to
encourage people to move to 1.3.
Presumably you would be doing this on a 1.3 branch of your code.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
coming from statically typed oo languages - how do deal with complex objects graphs in clojure?
this might seem like a stupid question, but for me, not knowing the type of something is like being stuck in a dead end for anything non trivial. i've made a few little experiments with clojure (not much, just testing some features) and i see how powerful clojure can be - for small to medium sized problems with simple input and output - a*- pathfinding, for example. but how would i port a complex object graph (let's say 15 different classes with 3-7 fields each - person, contacts, orders, shipping details) to clojure? how would i handle it? the main problems i see are: * do i have to actually remember the complete structure and field names and the exact spelling? using statically types languages like java or scala, the ide autocomplete features really help here. * what about renaming a field or method? * if a function needs an instance of the root class of the complex graph above as a parameter - how do i know this at all? am i lost without good documentation of this function? in java, i just know what a method needs because it has a signature. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-based non-blocking webserver like Node.js
On Sat, Sep 3, 2011 at 3:01 AM, Tal Liron tal.li...@gmail.com wrote: I always ask, though, why people think they need async I/O for a web server. Async might be important if you are streaming video, audio, etc. (And if you are, you're probably better off with a robust CDN.) Async can also be good for chat-like services. Though it is probably overkill for the most other cases. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: new Getting Started page
2. Fun stuff to do with the basic repl - some swing stuff - copy and pastable code snippets - some parallel stuff with futures or pmap or something - something with the stm - agents are cool, right? - links to 4clojure and project euler Kevin I think having a minimal 'tour' like this would be good; do any of the bloggers out there have anything that would be suitable? Mark Volkmann's page is pretty good, but it's comprehensive rather than selective. And try-clojure doesn't really go far enough in. I've edited the page a little bit to make it less prescriptive towards Clooj. http://dev.clojure.org/display/doc/Getting+Started+for+Beginners Note that if people are satisfied with java -cp etc., then they already got those instructions on the clojure.org page. I also put in a little link to that in case people come from somewhere else. I love command-line REPLs as much as the next person. I use Python as my calculator; just fire it up from any directory I happen to be in; it does everything! The problem is Clojure doesn't really \have this. From a select directory coming to a computer near you, java -cp clojure.jar clojure.main (if you can remember to type that) doesn't even give you command history (though if you want that, all you have to do is follow the instructions at http://en.wikibooks.org/wiki/Clojure_Programming/Getting_Started#Enhancing_Clojure_REPL_with_JLine, simple!). There seem to be a variety of options in various stages of completion or abandonment for smoothing all this over (see http://en.wikibooks.org/wiki/Clojure_Programming/Getting_Started#Additional_Installation_Options), but should we recommend any of them as the first choice? I'm not even sure we should put up labrepl, because there are no instructions for running it (not at least anything that would be useful to a newcomer). My final problem with introducing people to java -cp etc. is really an aesthetic one: it makes it look like Clojure was released yesterday and primarily consists of rough edges and incomplete functionality. It's like Lily Tomlin's skit: We're the Phone Company, We Don't Care! It often seems that programmers say to users: We're Programmers, We Don't Care if you Understand! (Fellow programmers are users too.) What does java -cp really mean? Perhaps you would like to type man java and find out what those flags are, along with lots of others? Why do you need to type both the jar file name and .main? Care to spend a half hour on the Java site looking for an explanation? What do you do when you want to run Clojure in your own project directories? You're either supposed to know this or be prepared to dive around the Net and find out. The fact is, knowledge of Clojure has nothing to do with all these implementation details, but these unexplained things are the first thing a new Clojure user sees. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: coming from statically typed oo languages - how do deal with complex objects graphs in clojure?
On Sat, 3 Sep 2011 13:43:42 -0700 (PDT) HamsterofDeath d.haup...@googlemail.com wrote: this might seem like a stupid question, but for me, not knowing the type of something is like being stuck in a dead end for anything non trivial. It's not stupid, it's normal :) In functional programming, most of the time you would like to write functions that do not need to know their arguments too intimately. You would like to work on collections, maps, ... Of course at some point you will need to write functions that will look closer to their arguments. You can pass functions to generic ones and isolate that type knowledge within them. No need to spread this everywhere. i've made a few little experiments with clojure (not much, just testing some features) and i see how powerful clojure can be - for small to medium sized problems with simple input and output - a*- pathfinding, for example. but how would i port a complex object graph (let's say 15 different classes with 3-7 fields each - person, contacts, orders, shipping details) to clojure? how would i handle it? defrecord might help you a bit here. It may feel a bit like home. defrecord fields can be referenced as map entries (:field-name ...). You can also define protocols that associated with defrecord and may ease your pain by implementing familiar functions to navigate in the hierarchy. Not sure if using a library written by someone else to handle these things is the proper thing to do right now. I feel you need to break your teeth a bit :) (It took me three months to get used to immutability :)) the main problems i see are: * do i have to actually remember the complete structure and field names and the exact spelling? using statically types languages like java or scala, the ide autocomplete features really help here. If you use obvious names that match the problem domain this should be easy to overcome. Protocols could help you here by hiding some complex navigation but please refrain implementing getters for all individual fields :)) * what about renaming a field or method? Yep of course you will not have this nice refactoring feature where you type in place the new name and get the IDE to fix this everywhere for you. But on the other hand you should have at least 10 times less code compared to java and less side effects to debug. It should not be too hard to do this using a standard text search. I use Eclipse and the straight file search. I would never exchange Clojure for Java and the automated Refactoring commands. If you encapsulate frequently exposed fields in functions you should be able to reduce the footprint of the code where these things are exposed. Hence the name changes would be easy to implement. You would confine these functions in a specific name space which decrease the like hood of missing a change. * if a function needs an instance of the root class of the complex graph above as a parameter - how do i know this at all? am i lost without good documentation of this function? in java, i just know what a method needs because it has a signature. Use the doc string when defining a fn: (defn blbl Returns the meaningful blblblbl... string. It expects a single parameter, the length of the returned string [length] ...) You can describe the expected inputs and the result, ... Do the same thing with your name space definitions, protocols. ... It's easy, fits with your programming flow and is non-obtrusive. -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: coming from statically typed oo languages - how do deal with complex objects graphs in clojure?
You can also put a commented out example call of the function, like this: (defn some-magic [spells wizards] ...) ; (some-magic 5 [:gendalf :einstein]) Which is also handy for quick evaluation in the REPL. Or you can put these example calls in the (automatic) test code. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: new Getting Started page
On Sat, Sep 3, 2011 at 11:58 AM, Colin Yates colin.ya...@gmail.com wrote: Getting started should be the smallest set of steps possible; the REPL. http://try-clojure.org is probably the very simplest step. Nothing to download or install and it has a built in tutorial. And that is the very first step on Nick's suggested page. The second step Nick suggests is a decent tutorial and 4clojure for learning more about solving problems (again, without installing anything). Mark's tutorial does cover the REPL as a first step (although it refers to the richhickey repo and talks about building Clojure from source as an alternative to just using the downloaded JARs - which really needs to be fixed - but it also mentions Leiningen, which is good). The third step on Nick's page is Clooj, followed by Leiningen. Using Leiningen to hide classpath issues and dependency management is a very good thing for Clojure beginners (esp. if they come from a non-Java background). This seems to be the piece causing all the friction here. Perhaps it just needs some additional wording to point people at Clooj if they want a simple, integrated editor that handles Clojure installation etc, and some wording to point people at Leiningen if they want a simple, command line way to experiment with Clojure? Given what we're trying to address here, I think I'd move Mark's tutorial down below the Clooj / Leiningen suggestions since it suffers from some of the same problems we're already trying to address. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: An open call to the community: Let's prepare for 1.3
I recommend the lein-multi plugin for testing against multiple versions of Clojure: https://github.com/maravillas/lein-multi Makes it easy to make sure you continue to support both 1.2 and 1.3 for a while. On Sep 3, 1:27 pm, Chris Granger ibdk...@gmail.com wrote: Hey Folks, With the release of 1.3 growing ever nearer, it's time that we as a community do everything we can to make the migration smooth. In general, this means relatively simple changes to the libs under your control, but I also think we should take this opportunity to do some house cleaning. If you maintain a clojure library (even if library just means some random thing up on github that a few people use), please consider doing the following over the next few weeks: - *Try migrating your lib to 1.3* - Create a 1.3 branch - Remove earmuffs around any non-rebound vars - Add earmuffs to any vars that are rebound using thread-level binding - Add ^:dynamic to these vars - If you rely on the built in Numerics, check to see if the new changeshttp://dev.clojure.org/display/doc/Documentation+for+1.3+Numericsin 1.3 affect you. - *Do some house cleaning* - If you are no longer maintaining this library, simply note so at the top of your Readme. If the reason is that a better alternative has spring up, link to it. - Take a look at your dev dependencies and determine if any of them should remain in light of the ability to globally install leiningen plugins. *If you have swank-clojure as a dependency, please remove it*: this has been the source of numerous issues. None of these are complicated or particularly time consuming, and the impact they will have as people try to migrate forward will be tremendous. Also, don't fall into the trap of thinking no one could possibly be using this tiny project - I bet they are and bet they'll want to continue to :) If I've missed some steps, please reply with them. Are there more house cleaning things we should do? Have you run into any other issues migrating to 1.3 (the steps listed here were purely what was necessary for me and the few others I've talked to)? Cheers, 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: new Getting Started page
On Sep 3, 2011, at 5:29 PM, nchurch wrote: I've edited the page a little bit to make it less prescriptive towards Clooj. http://dev.clojure.org/display/doc/Getting+Started+for+Beginners I like the revision too. I'm not even sure we should put up labrepl, because there are no instructions for running it (not at least anything that would be useful to a newcomer). A data point FWIW: when I was a newcomer I found labrepl quite confusing. I know that the intentions behind it were admirable but I had problems even making it go and more problems after that. I then taught a course using CCW and the CCW instructions directed people to work with labrepl. I found I had to give explicit instructions to my students to ignore everything that mentioned labrepl so that they didn't go down the same rabbit holes. YMMV, of course, but that's one report from the field. -Lee -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: An open call to the community: Let's prepare for 1.3
On Sat, Sep 3, 2011 at 3:43 PM, Lee Hinman matthew.hin...@gmail.com wrote: I recommend the lein-multi plugin for testing against multiple versions of Clojure: https://github.com/maravillas/lein-multi Makes it easy to make sure you continue to support both 1.2 and 1.3 for a while. Good idea. One thing that folks may not yet be aware of is that Clojure/core now have matrix tests for all the new contrib libraries - across Clojure 1.2.0, 1.2.1 and 1.3.0-beta3 and various JVMs (Sun 1.5, Sun 1.6, Oracle 1.7, IBM 5, OpenJDK 1.6). http://build.clojure.org/ e.g., http://build.clojure.org/job/java.jdbc-test-matrix/ (these were all blue the previous time I looked so I think there's some work in progress going on right now). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: An open call to the community: Let's prepare for 1.3
Being curious I checked references to contrib in our code base. Anyone knows what will happen to clojure.contrib.def and clojure.contrib.trace ? Luc P. On Sat, 3 Sep 2011 15:43:06 -0700 (PDT) Lee Hinman matthew.hin...@gmail.com wrote: I recommend the lein-multi plugin for testing against multiple versions of Clojure: https://github.com/maravillas/lein-multi Makes it easy to make sure you continue to support both 1.2 and 1.3 for a while. On Sep 3, 1:27 pm, Chris Granger ibdk...@gmail.com wrote: Hey Folks, With the release of 1.3 growing ever nearer, it's time that we as a community do everything we can to make the migration smooth. In general, this means relatively simple changes to the libs under your control, but I also think we should take this opportunity to do some house cleaning. If you maintain a clojure library (even if library just means some random thing up on github that a few people use), please consider doing the following over the next few weeks: - *Try migrating your lib to 1.3* - Create a 1.3 branch - Remove earmuffs around any non-rebound vars - Add earmuffs to any vars that are rebound using thread-level binding - Add ^:dynamic to these vars - If you rely on the built in Numerics, check to see if the new changeshttp://dev.clojure.org/display/doc/Documentation+for+1.3+Numericsin 1.3 affect you. - *Do some house cleaning* - If you are no longer maintaining this library, simply note so at the top of your Readme. If the reason is that a better alternative has spring up, link to it. - Take a look at your dev dependencies and determine if any of them should remain in light of the ability to globally install leiningen plugins. *If you have swank-clojure as a dependency, please remove it*: this has been the source of numerous issues. None of these are complicated or particularly time consuming, and the impact they will have as people try to migrate forward will be tremendous. Also, don't fall into the trap of thinking no one could possibly be using this tiny project - I bet they are and bet they'll want to continue to :) If I've missed some steps, please reply with them. Are there more house cleaning things we should do? Have you run into any other issues migrating to 1.3 (the steps listed here were purely what was necessary for me and the few others I've talked to)? Cheers, Chris. -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Stanford AI Class
Good news! The FAQ mentions that any programming language will do. On Mon, Aug 8, 2011 at 2:47 PM, labwor...@gmail.com wrote: As most of you probably already know, Peter Norvig and S. Thrun will offer a free online intro to AI class in the Fall. The problem is that it will probably require Python since the third edition of the book is in Python. I am somewhat upset that this will make Python the de facto language of AI for a very large number of students. I was hoping for Clojure frankly or have some breathing room. Anybody knows anything about that? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: An open call to the community: Let's prepare for 1.3
On Sat, Sep 3, 2011 at 4:40 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Being curious I checked references to contrib in our code base. Anyone knows what will happen to clojure.contrib.def and clojure.contrib.trace ? According to http://dev.clojure.org/display/design/Contrib+Library+Names some of c.c.def went into clojure.core.incubator and c.c.trace has no future home at present. Some namespaces will go away because what was in them exists in another namespace (much as stuff moved from c.c.string to clojure.string). As an example, defnk (from c.c.def) has disappeared in the reorg because map destructuring is built-in now. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: An open call to the community: Let's prepare for 1.3
Thanx I crossed another list in a different page stating the new names and structures but did not find this one. I'll keep the bookmark. So the only thing left on my list is c.c.trace. Any ideas of the future plans ? Need a volunteer ? Is there a bigger plan to regroup dev utilities ? Luc On Sat, 3 Sep 2011 17:29:14 -0700 Sean Corfield seancorfi...@gmail.com wrote: On Sat, Sep 3, 2011 at 4:40 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Being curious I checked references to contrib in our code base. Anyone knows what will happen to clojure.contrib.def and clojure.contrib.trace ? According to http://dev.clojure.org/display/design/Contrib+Library+Names some of c.c.def went into clojure.core.incubator and c.c.trace has no future home at present. Some namespaces will go away because what was in them exists in another namespace (much as stuff moved from c.c.string to clojure.string). As an example, defnk (from c.c.def) has disappeared in the reorg because map destructuring is built-in now. -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: An open call to the community: Let's prepare for 1.3
On Sat, Sep 3, 2011 at 5:37 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: So the only thing left on my list is c.c.trace. Any ideas of the future plans ? Stuart Sierra may chip in since he seems to have been the author of that? It does look useful. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure and emacs
You can set lein repl as your inferior lisp program via: M-x describe-variable inferior-lisp-program And as long as you start emacs somewhere in your lein project directory (or M-x cd to it), you'll have all the libraries loaded in your REPL buffer. On Thursday, September 1, 2011 11:03:13 AM UTC-6, melipone wrote: I do like lein repl on the command line. How can I have that in emacs? Basically, if I have a project in Lein, how can I do a (require 'projectname) and have all the libraries loaded in emacs? I'm just using M-x inferior-lisp at this point. I find swank-clojure too complex for right now. Maybe later. TIA melipone -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure and emacs
Sorry, what I meant to say in the last line is: And as long as you start emacs somewhere in your lein project directory (or M-x cd to it), you'll automatically be dropped into the main namespace (if you have one defined via :main in project.clj), and the other project namespaces will be available to (require ...) in your REPL buffer. On Saturday, September 3, 2011 7:32:28 PM UTC-6, Benny Tsai wrote: You can set lein repl as your inferior lisp program via: M-x describe-variable inferior-lisp-program And as long as you start emacs somewhere in your lein project directory (or M-x cd to it), you'll have all the libraries loaded in your REPL buffer. On Thursday, September 1, 2011 11:03:13 AM UTC-6, melipone wrote: I do like lein repl on the command line. How can I have that in emacs? Basically, if I have a project in Lein, how can I do a (require 'projectname) and have all the libraries loaded in emacs? I'm just using M-x inferior-lisp at this point. I find swank-clojure too complex for right now. Maybe later. TIA melipone -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: An open call to the community: Let's prepare for 1.3
Hi Phil, We use Eclipse/CCW, not much choices here, we have a mixed language app and as I age I have less memory space for different dev tools :) I'll ask Stuart if he has any plans for this. On Sat, 3 Sep 2011 20:37:36 -0700 Phil Hagelberg p...@hagelb.org wrote: On Sat, Sep 3, 2011 at 5:37 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: So the only thing left on my list is c.c.trace. Any ideas of the future plans ? Need a volunteer ? Is there a bigger plan to regroup dev utilities ? Personally I've found Slime's tracing to be a suitable replacement for c.c.trace. It has the advantage that you don't need to modify the source to add the tracing, though of course it only works in Emacs. Just hit C-c C-t to toggle tracing for a given defn. -Phil -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
