Re: where do you put clojure.java.jdbc?????
On Mon, Oct 24, 2011 at 8:36 PM, jayvandal s...@ida.net wrote: I am running Vista. I installed Clojure as c:\clojure. You don't need to install Clojure if you're using Leiningen (and I'd recommend you use Leiningen for managing project dependencies). Where and how do you put the file [org.clojure/java.jdbc 0.0.3-SNAPSHOT]] In project.clj (see Leiningen above) - and 0.1.0 is the current version of c.j.jdbc. -- 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: partial, but instead of args + additional, get additional + args
On Sun, Oct 23, 2011 at 1:04 PM, Ben Smith-Mannschott bsmith.o...@gmail.com wrote: On Sun, Oct 23, 2011 at 21:25, Meikel Brandmeyer m...@kotka.de wrote: The idiomatic solution is #(f % a1 a2 a3). I'm failing to see the issue with “nice” and “expressive”, but that is most likely just me. I find myself reaching for partial when I could be using #() I was using #() and (fn..) extensively in my code until I noticed just how many anonymous classes were being generated (we had a scenario where we were repeatedly reloading the Clojure code - deliberately - and of course ended up with thousands of these classes loaded!). Understood it's fine in load-once-and-run scenarios. When I brought this up on IRC, several folks said they felt the comp / partial approach was nicer because it was point-free - as well as not generating new classes (new instances, yes, new classes, no - right?). Since then, I've almost eliminated the use of #() and (fn..) in our code and, whilst more verbose initially in some cases, I'm actually really liking the point-free style and it's letting me see new opportunities for refactoring and simplification that I hadn't seen previously (often triggered by encouraging me to pay more attention to argument ordering so that my functions are more composable). Given Meikel's 2009 blog post, I can understand why he might not agree, but given that we have both - and -, it does seem like we have a 'hole' - comp/partial and - go together but there's no comp/??? to go with - and we have to resort to #(f % a1 a2 a3)... -- 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: bit-or arity appears limited to 2 items
On Fri, Oct 21, 2011 at 4:12 PM, rugby_road cabjh...@embarqmail.com wrote:
The bit-or arity seems to be limited to 2, rather than more, which
seems to disagree with the documentation. I get Wrong number of args
(3) passed to: core$bit-or for (bit-or 1 1 1). Have I misunderstood
this operation; shouldn't it take any number of values?
Clojure 1.3.0:
user= (doc bit-or)
-
clojure.core/bit-or
([x y] [x y more])
Bitwise or
nil
user= (bit-or 1 1 1)
1
user= *clojure-version*
{:major 1, :minor 3, :incremental 0, :qualifier nil}
Clojure 1.2.1:
user= (doc bit-or)
-
clojure.core/bit-or
([x y])
Bitwise or
nil
user= (bit-or 1 1 1)
java.lang.IllegalArgumentException: Wrong number of args (3) passed
to: core$bit-or (NO_SOURCE_FILE:2)
user= *clojure-version*
{:major 1, :minor 2, :incremental 1, :qualifier }
So it looks like the ability to take more than two arguments was added
in 1.3.0 (and the doc-string agrees).
--
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: Function to generate a SQL IN clause from a list of values
On Fri, Oct 21, 2011 at 10:47 PM, Alan Malloy a...@malloys.org wrote: Can't repeat this strongly enough. Do not, ever, decide you can escape/ sanitize the strings yourself so you don't need a parameterized query. Maybe it works, but one of these days you'll slip up and get something wrong. Just prepare a statement with the right number of ?s in it, and then ask the SQL driver/server to fill in the blanks. They'll never get it wrong, and it will be more efficient to boot if you can reuse a parameterized query later. Which is exactly what I said, yes? (just checking we're on the same page here). -- 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: partial, but instead of args + additional, get additional + args
On Sat, Oct 22, 2011 at 8:31 AM, Tyler Perkins thinks.outs...@gmail.com wrote: Just take an idea from Haskell (as usual!). Function 'flip' returns a function taking its first two arguments in order opposite the given function: That works nicely for functions with two arguments but in this situation I tend to have more than two arguments so #(f % a1 a2 a3) is what I'd need. After this and other threads, I'm beginning to think that need is a smell of some sort and it signals that the order of the arguments (to f) is wrong (to make it more amenable to partial application). I'm starting to think there's a nice, idiomatic solution lurking somewhere that wouldn't require an extra function... -- 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: Is Clojure Simple?
On Sat, Oct 22, 2011 at 10:35 AM, Tim Robinson tim.blacks...@gmail.com wrote: (is 'complected' even a word? - lol) . OED: http://photo.pds.org:5004/view/Entry/37640?redirectedFrom=complect#eid Do the Clojure language designers plan to make changes to Clojure to make it simpler? And if so, how so? This reminds me of the discussions on the C++ Standards Committee about compatibility with C wherein Andrew Koenig coined the phrase As close as possible to C - but no closer... perhaps Rich feels Clojure is as close as possible to simple - but no closer? :) -- 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 1.3 treatment of integers and longs
On Fri, Oct 21, 2011 at 12:52 AM, nathanmarz nathan.m...@gmail.com wrote: user= (class (Integer/parseInt 1)) java.lang.Long (Integer/parseInt 1) returns an int - which Clojure promotes to long (since it only has 64-bit primitives) and class takes an Object so long is boxed to Long. user= (class (Integer/valueOf 1)) java.lang.Integer (Integer/valueOf 1) returns an Integer - which is already an Object so (class Integer-value) returns Integer. You're only going to get 32-bit ints if you are calling into Java and that API expects an int - and you coerce the (64-bit primitive long) Clojure primitive to a 32-bit int (again, as I understand the 1.3 numerics). If Java gives Clojure an int, it will be treated as a 64-bit long. If Java gives Clojure an Integer, it will be treated as an Object. I rather like the simplicity of 1.3's numeric handling: there are only longs and doubles - but you can coerce them to whatever you need for interop. It's performant by default, it's simple and consistent (in my eyes) and yet still flexible. -- 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 1.3 treatment of integers and longs
On Thu, Oct 20, 2011 at 1:11 PM, nathanmarz nathan.m...@gmail.com wrote: of contention is what Clojure does when it has to box a primitive int. My understanding is that Clojure 1.3 has 64-bit primitives, i.e., longs and double. You only have a primitive int if you coerce the value to int (for an interop call that expects an int) - based on what I've understood of the numerics discussions. Similarly, you only have a primitive float if you coerce the value. So Clojure boxes a long as Long. If you want to box a long as Integer, you have to explicitly say so: (Integer. 42) - and Clojure will give you an Integer and not do anything to it. (Is my understanding correct? I'm finding the discussion interesting but not 100% sure whether I fully understand Clojure 1.3's primitive numerics) -- 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: partial, but instead of args + additional, get additional + args
On Thu, Oct 20, 2011 at 8:15 PM, Wilker wilkerlu...@gmail.com wrote: In the case of it's ok because they are reverse of each other, but in some circustances there is no reverse function, and you finish can't be using partial, instead you do like: (take-while #( % 2000) primes) I mean, there is no such function on default that works as reversed arguments partial (appending partial arguments at end instead of beginning)? I was expressing a need for exactly this function the other day on IRC. I jokingly called it 'impartial' :) -- 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: Digest for clojure@googlegroups.com - 13 Messages in 5 Topics
On Sun, Oct 16, 2011 at 9:26 PM, Jay Vyas jayunit...@gmail.com wrote: Hi guys : Ive posted a question about looking for a DSL in clojure that replaces a good oo solution to an easily understandable, domain oriented problem (like the jpetstore application), on stackoverflow. Still now answers though --- thought maybe one of you would have some thoughts ? I think your question is a bit too generic to get a good answer. You want a DSL but you don't provide a specific domain (which DSL implies). Take a look at this code which provides an OO gloss - is this what you're looking for? https://github.com/seancorfield/macro-day/blob/master/src/day/clos.clj (credit to Amit Rathore since this comes from his Day of Clojure Macros course which is based on his book Clojure in Action). Hope that helps? -- 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: Pipe function
On Fri, Oct 14, 2011 at 5:50 PM, Alan Malloy a...@malloys.org wrote: I really liked this one too, though my first draft of it was more like (defn pipe [test f] (fn [value] (...))) ... fix is basically your pipe, except it takes a series of test/f pairs, and to-fix is my original version, returning a function of x instead of computing on x immediately (this is handy as you can map (to-fix string? read-string) over a collection, for example). Out of curiosity, why wouldn't you define pipe to take [test f value] and then you can map (partial pipe string? read-string) over a collection? Given accepts only one clause and is shaped right for use in - thread chains, like: (- x inc (given even? / 2)) So it's given [value test f args] yes? I'm finding quite often I want a function that's a bit like partial but puts the deferred arguments at the beginning of the argument list, let's call it impartial (j/k) so you could do: ((comp (impartial given even? / 2) inc) x) I know that's contrived but I'm finding #(f % args) common enough that something like impartial (with a better name, please!) would be useful in some sort of contrib library of higher-order functions. If nothing else, I recommend you change the argument order to your pipe function: (defn pipe [value test f]) is clearly the correct signature, since it means that (like fix) you can use it in update-in/ alter/swap!/- chains. Ah, that answers my question above. Interesting point. Argument order choices are still something I'm learning new things about all the time! -- 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: The Website / Wikispaces
On Thu, Oct 13, 2011 at 1:28 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: You can see the redirect with: wget http://clojure.org/ Ah, session.wikispaces.com .. thanx. -- 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: ANN: clojure.java.jdbc 0.0.7
On Thu, Oct 13, 2011 at 1:35 AM, Marko Kocić marko.ko...@gmail.com wrote: Looking at the log seems like MS Access doesn't support prepared statements. Ah, so there was a path in c.c.sql that didn't use PreparedStatement which meant it supported MS Access? (by accident, I'm sure :) If someone with a Windows system can figure out a patch for c.j.jdbc that would re-enable that behavior without breaking any other behaviors, I'd be happy to entertain it in a JIRA ticket. Unfortunately, I don't have access to MS Access to do any such testing... -- 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: Pipe function
On Sat, Oct 15, 2011 at 12:59 AM, Alan Malloy a...@malloys.org wrote: As you notice lower, I like this argument-order so that I can chain operations on values better Yes. But, that map is handy, so we have (to-fix), which is basically a partial setting all *but* the first arg (tying nicely into what you ask for in the next paragraph). Could you explain the name: to-fix? Yeah, I've heard this from a few people. Myself, I don't think I run into this need very often, but maybe I just have a blind spot for it. And maybe I'm just seeing this as an issue because I haven't internalized Clojure idioms yet... -- 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: Faster clojure.data.json
On Fri, Oct 14, 2011 at 11:21 AM, Stuart Sierra the.stuart.sie...@gmail.com wrote: I spent some time this morning on performance enhancements to clojure.data.json, including a fix for DJSON-1. I just pushed release 0.1.2 to Sonatype; it will reach Maven Central in a few hours. I updated CongoMongo to depend on 0.1.2 - thank you! (but haven't pushed a new build of that yet) I've also updated to 0.1.2 at World Singles and we're enjoying the performance improvements - and the lack of reflection warnings :) -- 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: Sum on a list of maps
On Fri, Oct 14, 2011 at 10:25 AM, der derealme.derea...@gmail.com wrote:
Given a list of maps of the followign format: ({Type A, Value
5} {Type B, Value 4} {Type A, Value 7.2} {Type
A, Value 25.4} {Type B, Value 2.982})
Folks are posting solutions but I wondered why your map keys are
strings and why the values are also strings instead of numbers?
If the keys were keywords, you could just use :type instead of #(%
Type) or #(get % Type) which would make for cleaner code. Just a
thought.
--
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: ANN: clojure.java.jdbc 0.0.7
On Wed, Oct 12, 2011 at 1:42 AM, keeds akee...@gmail.com wrote: I'm having problems with MS Access ODBC driver with JDBC ODBC bridge and parameterised statements. Given how flawed MS Access is, I'm not sure it's an appropriate target for clojure.java.jdbc but if you can provide more detail about exactly what query you tried (that failed) and whether it ever worked with clojure.contrib.sql, I can try to take a look at it. -- 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.contrib.except's future?
On Thu, Oct 13, 2011 at 11:19 AM, ffailla ffai...@gmail.com wrote: Does anyone now if clojure.contrib.except being ported to the new contrib? Thanks. So far no one has volunteered to maintain it so the question hadn't come up... -- 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: tools.logging vs clojure.contrib.logging
On Wed, Oct 12, 2011 at 8:06 AM, jingguo yaojing...@gmail.com wrote: Is tools.logging is a replacement of clojure.contrib.logging? Which one should I use? If these pages could be more clear on answering your question, please let me know and I'll update them: http://dev.clojure.org/display/doc/Clojure+Contrib http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go My intent is that these two pages should be able to address any and all such questions about clojure.contrib and its successors. The former is linked from clojure.org (top-right pod) and it links to the latter. If we can make these pages more visible, suggestions welcome! -- 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: The Website / Wikispaces
Just to swim against the flow: I've never seen confusion between clojure.org and wikispaces so I've been watching this thread with interest and bewilderment. Can someone provide a tried and true navigation path that shows this problem? If it's as common as this thread would suggest, I'm really surprised I haven't run into it since I browse both sites a lot... Sean On Wed, Oct 12, 2011 at 7:30 AM, Chas Emerick cemer...@snowtide.com wrote: Wikispaces does some strange https redirects through its own domain for session handling. If your agent doesn't react as it expects, you can end up in all sorts of strange places (including having no way to get to clojure.org at all if your internet connection disallows https entirely, i.e. some less reputable free mobile phone tethering apps). - Chas -- 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: Faster JSON library
Nice! This will let me remove some workarounds for reflection warnings I was getting and probably give me better performance too :) I'll try to run tests against 1.4.0-master-SNAPSHOT today (that'll have this change, right?). Sean On Fri, Oct 7, 2011 at 1:20 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: This reflection warning can be fixed with an enhancement on the Clojure side, which I have just pushed to master [1]. I would like to create 1.4 alpha 1 with the code changes that have gone in today. It would be super-great if anybody has time to build your own project against master and let us know if you see any issues. Thanks, Stu [1] https://github.com/clojure/clojure/commit/405d24dd49d649c01b7881f1394fc90924c54ef0 -- 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: Exception handling changes in Clojure 1.3.0
Would a good solution to this be for try/catch to _automatically_ unroll RTE if there's no matching Exception class specified? I understand _why_ the change to wrap exceptions was made but without the equivalent unwrapping in try/catch this just moves the pain from the library/language out to the users, yes? Sean On Sat, Oct 8, 2011 at 11:10 PM, Constantine Vetoshev gepar...@gmail.com wrote: I finally came up with a simple example which shows the broken exception handling behavior I described in my earlier post on this thread. (defn broken-catch [filename] (try (java.io.FileReader. filename) (catch java.io.FileNotFoundException fnfe FileNotFoundException caught) (catch RuntimeException ioe (str RuntimeException caught; cause: (.getCause ioe) user= (broken-catch /etc/passwdXYZ) RuntimeException caught; cause: java.io.FileNotFoundException: /etc/ passwdXYZ (No such file or directory) The FileReader constructor throws a FileNotFoundException when the file specified by the argument does not exist: http://download.oracle.com/javase/6/docs/api/java/io/FileReader.html#FileReader(java.lang.String) — and as you can see here, Clojure 1.3.0 wrapped it in a RuntimeException, so the expected typed catch does not work. However, if invoked in a way which bypasses reflection, the exception is properly typed: user= (try (java.io.FileReader. /etc/passwdXYZ) (catch java.io.FileNotFoundException fnfe FileNotFoundException caught) (catch RuntimeException ioe (str RuntimeException caught; cause: (.getCause ioe FileNotFoundException caught -- 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: Faster JSON library
On Tue, Oct 11, 2011 at 8:47 AM, Sean Corfield seancorfi...@gmail.com wrote: I'll try to run tests against 1.4.0-master-SNAPSHOT today (that'll have this change, right?). I get a NPE from the 1.4 compiler on Congomongo. Details reported on clojure-dev. -- 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
ANN: clojure.java.jdbc 0.0.7
Changes in 0.0.7:
* Fix JDBC-9 by renaming duplicate columns instead of throwing an exception.
- thanx to Peter Siewert!
* Fix JDBC-16 by ensuring do-prepared works with no param-groups provided.
* Fix JDBC-17 by adding type hints to remove more reflection warnings.
- thanx to Stuart Sierra!
Documentation:
* Address JDBC-4 by documenting how to do connection pooling.
Plans:
Once JDBC-3 / JDBC-15 have been addressed (use of deprecated
struct-map stuff), I'll declare 0.1.0 and ask Clojure/core what would
be needed for a 1.0.0 release. Feel free to provide feedback for
future development here:
http://dev.clojure.org/display/design/java.jdbc
Earlier changes...
Changes in 0.0.6:
* Move former tests to test-utilities namespace - these do not touch a database
* Convert old test examples into real tests against real databases
- tested locally against MySQL, Apache Derby, HSQLDB
- build system should run against Apache Derby, HSQLSB
- will add additional databases later
* Fix JDBC-12 by removing batch when doing a single update
* Remove wrapping of exceptions in transactions to make it easier to
work with SQLExceptions
Changes in 0.0.5:
* Add prepare-statement function to ease creation of PreparedStatement
with common options:
- see docstring for details
* with-query-results now allows the SQL/params vector to be:
- a PreparedStatement object, followed by any parameters the SQL needs
- a SQL query string, followed by any parameters it needs
- options (for prepareStatement), a SQL query string, followed by
any parameters it needs
* Add support for databases that cannot return generated keys (e.g., HSQLDB)
- insert operations silently return the insert counts instead of
generated keys
- it is the user's responsibility to handle this if you're using
such a database!
Changes in 0.0.4:
* Fix JDBC-2 by allowing :table-spec {string} at the end of
create-table arguments:
(sql/create-table :foo [:col1 int] [col2 :int] :table-spec
ENGINE=MyISAM)
* Fix JDBC-8 by removing all reflection warnings
* Fix JDBC-11 by no longer committing the transaction when an Error occurs
* Clean up as-... functions to reduce use of (binding)
* Refactor do-prepared*, separating out return keys logic and
parameter setting logic
- in preparation for exposing more hooks in PreparedStatement
creation / manipulation
Changes in 0.0.3:
* Fix JDBC-10 by using .executeUpdate when generating keys (MS SQL
Server, PostgreSQL compatibility issue)
Changes in 0.0.2:
* Fix JDBC-7 Clojure 1.2 compatibility (thanx to Aaron Bedra!)
Changes in 0.0.1 (compared to clojure.contrib.sql):
* Exposed print-... functions for exception printing; no longer writes
exceptions to *out*
* Add clojure.java.jdbc/resultset-seq (to replace
clojure.core/resultset-seq which should be deprecated)
* Add support for naming and quoting strategies - see
http://clojure.github.com/java.jdbc/doc/clojure/java/jdbc/NameMapping.html
- The formatting is a bit borked, Tom F knows about this and is
working on an enhancement to auto-doc to improve it
* Add ability to return generated keys from single insert operations,
add insert-record function
* Clojure 1.3 compatibility
--
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: metadata on function objects
On Tue, Oct 11, 2011 at 5:13 PM, Brian Marick mar...@exampler.com wrote:
In 1.3, this metadata is missing:
user= (meta odd?)
nil
user= (meta #'clojure.core/odd?)
{:ns #Namespace clojure.core, :name odd?, :arglists ([n]), :added
1.0, :static true, :doc Returns true if n is odd, throws an
exception if n is not an integer, :line 1323, :file
clojure/core.clj}
--
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: metadata on function objects
On Tue, Oct 11, 2011 at 5:22 PM, Brian Marick mar...@exampler.com wrote: I understand that. Useful code is sometimes given a function object to work with, not a Var. Ah, I get your point now... What about: (meta (var odd?)) (meta (resolve 'odd?)) -- 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: ANN: clojure.java.jdbc 0.0.7
On Tue, Oct 11, 2011 at 6:58 PM, jaime xiejianm...@gmail.com wrote: will the 1.0.0 be included in core or contrib package? The Clojure/core team have indicated they are considering a batteries included distribution that will bundle new contrib libraries but the exact form (and version numbers) have not been discussed in any detail. -- 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: Faster JSON library
That would be http://dev.clojure.org/jira/browse/DJSON-1 which I opened at the end of July... On Fri, Oct 7, 2011 at 11:10 AM, Lars Nilsson chamael...@gmail.com wrote: Trying to be a little bit constructive here, in case I come across as complaining, I took the source for c.d.json and put it into a leiningen project, enabled warn on reflection, and found that several cases of (... (let [c (char i] ... (= c \x) ...) results in Clojure deciding it needs to perform reflection in order to call equals in the comparison with a fixed character. I'm not really sure what the proper solution for this is, but I changed the let to (let [c (Character/valueOf (char i)] ...) and the time for my 217KB JSON file dropped from 107 seconds to 2 seconds, or only a little more than twice as slow as clj-json (which clocked in a little under one second for my file). -- 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: docs for 1.3
On Tue, Oct 4, 2011 at 5:22 AM, Fogus mefo...@gmail.com wrote: Good catch. That was my fault. It's now nested under the Core page in the same space. Thanx for the swift update - appreciated! -- 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: How to flatten a nested sequence?
On Tue, Oct 4, 2011 at 2:25 PM, Shoeb Bhinderwala shoeb.bhinderw...@gmail.com wrote: Thanks. Didn't think it would exist in clojure.core. I highly recommend trying out Chas Emerick's Clojure Atlas: http://clojureatlas.com - it makes searching for functions AND concepts really easy and provides a great way to see the relationships between different parts of the Clojure core and ecosystem. Caveat: I'm a big enough fan of the atlas to be a paying customer but the free version is full-featured (it just has an occasional 'nag' reminder). -- 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: Exception handling changes in Clojure 1.3.0
On Mon, Oct 3, 2011 at 12:03 PM, Constantine Vetoshev gepar...@gmail.com wrote: This stopped working in 1.3.0. The caught exception does not match EntityNotFoundException; it is now a RuntimeException with the original typed exception chained to it. This caused me some pain in clojure.java.jdbc and I actually catch RuntimeException inside the library and unwrap it and throw the underlying SQLException (for transactions): ;; This ugliness makes it easier to catch SQLException objects ;; rather than something wrapped in a RuntimeException which ;; can really obscure your code when working with JDBC from ;; Clojure... :( (letfn [(throw-non-rte [ex] (cond (instance? java.sql.SQLException ex) (throw ex) (and (instance? RuntimeException ex) (.getCause ex)) (throw-non-rte (.getCause ex)) :else (throw ex)))] (throw-non-rte e))) I've had to do similar things in my own code to get at the underlying exceptions... It would be much, much friendlier to have (try .. (catch ..)) automatically unroll RuntimeException on demand so the obvious code works. -- 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: docs for 1.3
On Mon, Oct 3, 2011 at 2:05 PM, Sergey Didenko sergey.dide...@gmail.com wrote: Clearly (the main) clojure.org is not the main documentation source for 1.3. To prove it - try to find the mention of Factory function taking a map, e.g. map-MyRecord there. The defrecord improvements seem to be covered here. http://dev.clojure.org/display/design/defrecord+improvements (it doesn't help that this is now a child page of Release.Next Planning which now refers to Clojure 1.4!) The API documentation is auto-generated from the source code so it's up-to-date (as I understand it): http://clojure.github.com/clojure/clojure.core-api.html But the API documentation isn't comprehensive (hard to be since it's essentially the docstrings in the code). Improving documentation looks to be a focus of Clojure 1.4: http://dev.clojure.org/display/design/Release.Next+Planning -- 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: suggestion for clojure development
On Sat, Oct 1, 2011 at 10:16 PM, Tal Liron tal.li...@gmail.com wrote:
And the issue for me now is concern about what will happen to all
these contribs in the future if a core language feature changes, such as the
dynamic Var issue in 1.3. If these contribs are not being built and shipped
as part of Clojure, it seems risky to rely on them. Some might get upgraded,
others might languish. What's lacking is any kind of statement of
commitment. Instead, if I understand it correctly, we see the core Clojure
project moving back from a commitment model to a more community-management
model.
Actually I think you're in a better position now. The new contrib
libraries are all actively maintained and are expected to be
compatible with both Clojure 1.2.x and 1.3.0. I'm also hearing a
possibility that a ready-to-go download of updated contrib libraries
will be provided. That seems to address both of your concerns.
I'm not necessarily arguing for a move back to the monolith that existed up
to Clojure 1.2, but for a standard lib *distribution* with a test suite and
a Clojure stamp of approval.
That's pretty much what new contrib is: they have active
maintainers, they have automated builds - with matrix tests against
Clojure 1.2.0, 1.2.1 and 1.3.0 on a variety of JDKs - they have
specific JIRA projects for logging bugs and requesting enhancements,
they have a documented process for maintenance. To become a new
contrib library, the project actually does need some level of
Clojure/core approval and involvement.
example, the new dynamic Var breakage in Clojure could have been solved with
an optional switch per namespace, requiring explicit enabling for now, and
But it can be solved by adding ^{:dynamic true} which makes it
compatible with both Clojure 1.2.x and 1.3.0. That's how 3rd party
libraries are solving this problem and being compatible with both
versions.
will try to find time to go back to some of my old code, gather the
workarounds I found for bugs -- a few in the JSON and in SQL-now-called-JDBC
contribs -- and find a way to turn them into patches.
That would be cool - thank you. Have a read over the
http://clojure.org/contributing guidelines and the
http://clojure.org/patches process.
--
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: Equality comparison in 1.3
On Sat, Oct 1, 2011 at 9:52 PM, Daniel doubleagen...@gmail.com wrote: user= (= 23.0 23) false With every language I've ever worked in, I've always been told that comparing floating point numbers for equality is a bad idea so I'm actually glad to see that the above comparison is false... -- 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: suggestion for clojure development
On Sat, Oct 1, 2011 at 11:24 PM, Tal Liron tal.li...@gmail.com wrote:
You're right, it sounds in line with my hopes!
Great!
Would it be possible to think of a better name for this sister project than
new contrib? Something that implies its tight relationship with Clojure? I
suggest Clojure Core.
Given the existence of the Clojure/core team, that might be a little
confusing :)
On the other hand, going to clojure.org, I simply see a
download link to the new Clojure 1.3.0, with no information on these
organizational changes. It's an old complaint, I know, but clojure.org is
... not the most useful web site on the Internet.
Well, we did get the Getting Started page stripped down and linked to
the dev wiki so that the community could keep it updated. I agree that
clojure.org has a long way to go when you compare it to the home site
of several other languages but I think we'll all get there :)
True, but the default behavior was changed to dynamic false meaning the
libraries *must* be refactored for 1.3.0 in order to even run properly
there, which I think was an unfortunate decision.
You missed ^{:dynamic true} on *must* :)
I got the impression *earmuffed* variables were always intended to be
dynamic - and there was a good long period of builds where it was just
a warning when an *earmuffed* variable was not annotated with dynamic
metadata. Maybe it should have been a whole point version with that
warning? My feeling is we got enough notice but I know not everyone
will agree.
Again, as Arthur suggested, I would have preferred a per-namespace or
per-library flag saying language version 1.3.0 which would have set the
default Var behavior to dynamic false. Unmarked namespaces would have
fallen back to the pre-1.3 default of dynamic true, and a large pain point
would have been avoided. Users would have been able to migrate code one
namespace at a time, if at all.
I suspect there are valid reasons why that might not have been
possible but perhaps a longer period of warnings might have helped
here.
--
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: strangeloop presentations
On Fri, Sep 30, 2011 at 6:17 PM, Alex Miller a...@puredanger.com wrote: Yes, we are working on getting them published. Rich Hickey's keynote is in the first batch and has already been edited, just waiting to be synced to slides and scheduled at InfoQ. You know that you should have saved the best to last and made everyone wait for that one? :) - Zach Tellman - Event-Driven Programming in Clojure - Nate Young - Parser Combinators: How to Parse (nearly) Anything - Nathan Marz - Storm: Twitter's scalable realtime computation system All three were great presentations! -- 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: suggestion for clojure development
On Sat, Oct 1, 2011 at 8:10 PM, Tal Liron tal.li...@gmail.com wrote: I did realize pretty early on that the contribs were not all of prime quality, but what other choice did I have? Fall back to standard JVM API? I'm curious, what parts of contrib are you relying on that haven't found active maintainers? Perhaps we can figure out how to address that, to reduce your pain? What I would want to see is a coherent standard library that is centrally maintained. Not everything deserves to be there, of course, but there are obvious candidates for essentials. I think it's worth discussing what's essential in contrib. If there are unmaintained modules that folks think are essential, let's figure out how to get those maintained again and moved into new contrib. -- 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: strangeloop presentations
It was stated at the conference that InfoQ was videoing everything and will post it over the next six months as they get time to edit/produce each session. Sean On Fri, Sep 30, 2011 at 10:41 AM, Scott Jaderholm jaderh...@gmail.com wrote: In the past they've been posted on infoq.com several months later. Scott On Fri, Sep 30, 2011 at 1:24 PM, Felix Filozov ffilo...@gmail.com wrote: Do you know if videos will be available? -- 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: how do I use data.priority-map
On Thu, Sep 29, 2011 at 12:11 AM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: answering my own question ... aah .. I can just go to the sonatype repository and findout .. thanks If something isn't listed on Maven Central here http://search.maven.org/#search%7Cga%7C1%7Corg.clojure then you'll have to dig around in Sonatype. data.finger-tree 0.0.1 is on Maven Central tho'... I'll shake the tree to encourage releases to Maven for the rest of the contrib libraries. I could/should make a release of data.priority-map... I helped Mark get his three contrib libraries migrated and setup and the only reason I haven't made Maven releases is because math.numeric-tower currently only runs on Clojure 1.3.0 due to a reference to BigInt. -- 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: how do I use data.priority-map
On Thu, Sep 29, 2011 at 2:39 AM, Sean Corfield seancorfi...@gmail.com wrote: I'll shake the tree to encourage releases to Maven for the rest of the contrib libraries. I could/should make a release of data.priority-map... I helped Mark get his three contrib libraries migrated and setup and the only reason I haven't made Maven releases is because math.numeric-tower currently only runs on Clojure 1.3.0 due to a reference to BigInt. I just cut 0.0.1 releases of data.priority-map and math.combinatorics so those should appear on Maven Central soon (within 24 hours, possibly sooner). I'll do math.numeric-tower once it passes Clojure 1.2.x tests. -- 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: Shameless self promotion - JavaOne
On Thu, Sep 29, 2011 at 11:35 AM, Felix Filozov ffilo...@gmail.com wrote: Is the location of the meetup anywhere close to the conference? The group alternates between San Francisco and Mountain View but we're considering meeting every month in San Francisco and running the Mountain View meetings less frequently in addition, going forward. Because of Java One, we'll almost certainly meet up in San Francisco this coming week. Sean On Wednesday, September 28, 2011, Sean Corfield seancorfi...@gmail.com wrote: http://www.meetup.com/The-Bay-Area-Clojure-User-Group/ -- 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: producing Blub code and vv.
On Thu, Sep 29, 2011 at 3:39 AM, Hank h...@123mail.org wrote: I'd like to check the interest in the community for a comprehensive Clojure library/framework/whathaveyou that helps produce Java/Python/ Ruby/... a.k.a. Blub (http://www.paulgraham.com/avg.html) code, i.e. instead of writing a Clojure program that e.g. produces web pages, writing a Clojure program that produces a Blub program that produces web pages. A Blub program in idiomatic, maintainable, efficient Blub code that is. I think the major obstacle is likely to be the difference in idioms. Any substantial idiomatic piece of Clojure is going to be almost impossible to automatically translate to _idiomatic_ code in another high-level language that uses different idioms. You'd also probably have to introduce a number of coding conventions to constrain your Clojure code in order to avoid holes in the translation. Some questions: * How do you translate Clojure functions in namespaces spread across multiple files into a Java class? * Would it even be idiomatic Java to always have classes full of only static methods? * What about Clojure's vast library of functions (esp. higher-order)? * What would something like (map (juxt :id identity) (filter (comp not nil? :data) some-lazy-data-stream)) look like in Blub, if Blub doesn't have keywords, composition, higher-order functions, lazy data structures? * How would code that uses STM translate to a Blub without it? * How idiomatic would Blub code be when Clojure uses immutable data by default? I think it's a fascinating problem to try to solve for any given target Blub but I'm not sure how practical it would be, i.e., how readable the generated Blub code would be to an average Blub programmer...? -- 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: producing Blub code and vv.
On Thu, Sep 29, 2011 at 10:48 PM, Hank h...@123mail.org wrote: A good source for this is the O'Reilly book Functional Programming in Java. There you can see how idioms from one language can be applied to another. Oh yes, I know about that book but the question is: how idiomatic is that code in Java? You can write imperative, stateful code in Clojure but it wouldn't be idiomatic. You weren't going to the Conj by any chance, were you? Yup. Looking forward to it! -- 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: producing Blub code and vv.
On Thu, Sep 29, 2011 at 11:24 PM, Hank h...@123mail.org wrote: Would it even be idiomatic Java to always have classes full of only static methods? ... the Java-ists have an idiom (design pattern) called singleton. They're not static methods but once-instance classes. Doesn't that kind of prove my point? :) And, after all, isn't the Singleton design pattern only a workaround for the fact that languages like Java don't have a built-in construct for creating a memoized global variable? :) See you at the Conj... -- 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: Shameless self promotion - JavaOne
The Bay Area Clojure User Group is scheduled to meet on Thursday October 6th. Any out of town Clojurians who would be around for that meetup and might be persuaded to come and talk about what they're doing with Clojure? http://www.meetup.com/The-Bay-Area-Clojure-User-Group/ Sean On Tue, Sep 27, 2011 at 8:50 AM, Dennis shr3ks...@gmail.com wrote: I will be giving a talk at JavaOne (it is Clojure related). Here is the information. Title: Monitoring a Large-Scale Infrastructure with Clojure Time Tuesday, 07:30 PM, Parc 55 - Embarcadero Length 45 Minutes Abstract: Monitoring a large infrastructure brings unique challenges that require blending development and operations concepts. This session discusses how Dell Inc. used Clojure to develop a data-flow-based monitoring system that stores, evaluates, and acts on hundreds of thousands of metrics. It covers • Real-world applications of Clojure's parallel programming constructs to take advantage of multiple cores available in today's systems • Using Clojure's homoiconic nature to create DSLs • Taking advantage of Clojure running on the JVM to use the Java ecosystem • How DevOps takes advantage of the JVM dynamic languages to develop new monitoring tools Track Emerging Languages, Tools, and Techniques Optional Track The Java Frontier -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] Clojure 1.3 Released
On Tue, Sep 27, 2011 at 9:21 PM, Sidharth Kshatriya sid.kshatr...@gmail.com wrote: Can you tell me why Clojure scored over Scala for you. For my Scala / Clojure anecdote, see: http://groups.google.com/group/clojure/browse_thread/thread/b18f9006c068f0a0/ We like CFML for View templating and Controllers but we expect to migrate most of our Model to Clojure over time... -- 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: how do I use data.priority-map
No builds have yet been released to Maven.
You can, however, use the snapshot from Sonatype. Add the following to
project.clj:
:repositories {sonatype-oss-public
https://oss.sonatype.org/content/groups/public/}
That causes Leiningen to search the Sonatype repository.
Then add this dependency:
[org.clojure/data.priority-map 0.0.1-SNAPSHOT]
That should get you going.
Sean
On Wed, Sep 28, 2011 at 3:21 PM, Sunil S Nandihalli
sunil.nandiha...@gmail.com wrote:
after I posted the question .. I found this discussion . So, I guess it is
not ready for prime-time yet .. (may be I am wrong)
--
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: help understanding how map works
On Wed, Sep 28, 2011 at 6:32 PM, Cluj alex.sant...@gmail.com wrote: Thank you! Obvious once someone explains it :) You could also do: (map vector '(A B C)) -- 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: [ANN] Clojure 1.3 Released
On Fri, Sep 23, 2011 at 2:44 PM, Christopher Redinger redin...@gmail.com wrote: We are pleased to announce today the release of Clojure 1.3: We took Clojure 1.3 into production today, along with a lot more Clojure code compared to our previous production release. We've converted all of our profile publishing and searching code to Clojure now (from Scala and CFML respectively) and we're liking the initial results we're seeing (improved stability and performance). The number of Clojure contributors continues to grow. Thanks to all the people whose code is included in this release: Great work folks - thank you! -- 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: [ANN] Clojure 1.3 Released
On Tue, Sep 27, 2011 at 12:22 PM, Bruce Durling b...@otfrom.com wrote: That is great to hear. So happy to see someone use a lot of clojure in production. Congrats on the release. Thanx. You can get a lot done with just a little Clojure. We stand at 1,829 lines of production Clojure code and 448 lines of unit tests so far (and a lot of non-Clojure code - but that is slowly migrating to Clojure as we do any substantial work on the backend of our system). -- 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: suggestion for clojure development
On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein arthuredelst...@gmail.com wrote: raises the question of what happens to all of the many existing Clojure 1.2-based libraries in Clojars and on github. Many of these are very useful, but not necessarily actively maintained. A lot of Are therein lies the problem: if they are not actively maintained, you're not going to get bug fixes even on Clojure 1.2. This was true of a large number of contrib modules as well and as we can see from http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go a lot of the Clojure Contrib 1.2.0 modules are unmaintained and some won't work with Clojure 1.3.0 :( So my request for Clojure's future development, is that backwards compatibility not be broken. I don't think that it's reasonable to expect Clojure to be always beholden to unmaintained third party libraries. What I've been doing is approaching the author(s) of a library where I needed Clojure 1.3.0 compatibility and offered to help them update the code so it works on Clojure 1.2.x and 1.3.0. This clearly helps me - and requires surprisingly little time investment - and it also helps every other user of those libraries. If a library truly has no maintainer, relying on it - especially for production code - is a little risky in my opinion. I love that Clojure is being constantly improved and developed, and I thank everyone who has been working so hard on it. In my opinion, though, third-party libraries are as important as the core language. Clojure 1.3 interoperates with java libraries very well -- so why not with Clojure 1.2 libraries? I think the better approach is to ensure third party libraries are updated and available to all Clojure users - instead of placing the burden on the Clojure/core team, for a bunch of libraries over which they have no control. -- 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: suggestion for clojure development
On Tue, Sep 27, 2011 at 4:28 PM, Brian Marick mar...@exampler.com wrote: I think is it actively maintained? is not a particularly interesting question for a community. The question is: is this a useful library? Then: is the original author maintaining it? And then, if not: who will pick it up? Well, I'd hope that we can find (active) maintainers for libraries that are actually useful :) I got an email off-list asking what to do about code that relies on clojure.contrib.str-utils2 with a link to documentation on the richhickey.github.com repo. That namespace isn't even in the list of contrib modules in https://github.com/clojure/clojure-contrib/tree/master/modules so I can only assume it was migrated to clojure.string as part of Clojure 1.2.0 (along with c.c.string and c.c.str-utils). For me, that's pre-history. As Clojure continues to grow in popularity, that will be pre-history for the vast majority of Clojure users too - for anyone who picks up Clojure first via 1.3.0. Anything we can do to clean up outdated documentation, web pages, blogs and so on will help all those who come along from this point on. The pain of migrating from Contrib 1.2.0 (or earlier) to the New Contrib Libraries (whether you stay on Clojure 1.2.x or move to Clojure 1.3.0) is a one-time tax for early adopters and, as unpleasant as that may be, I expect future migrations to be easier even if Clojure introduces breaking changes because the libraries that make this jump are more likely to continue to be actively maintained (as long as they remain 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: suggestion for clojure development
On Tue, Sep 27, 2011 at 7:33 PM, Arthur Edelstein arthuredelst...@gmail.com wrote: I hope so, too, but very often this doesn't happen in practice. Much useful code is not maintained. My position on free open source software is that if it's that useful to someone, then that someone has at least some obligation to contribute back to the community somehow. In the case of useful software with no active maintainer, that contribution can sometimes be the path to becoming the new maintainer :) If I add a dependency from Clojars or maven central to my project.clj file, I don't want to pay the tax of deciding what Clojure version it is and whether it is actively maintained With all due respect, I think that's an unreasonable expectation: this is free open source software we're talking about, created and maintained by the community at large. Figuring out those things is the tax you generally have to pay with free open source software. When you're selecting a library to solve a particular problem, you normally have to do some research and evaluate more than one library so, for me, the activity of the project and software versions supported are part of that necessary research. I can't imagine just using some random library without doing some legwork...? Phil's suggestion of adding metadata to Clojars might help - but of course for libraries not being actively maintained, there will be no metadata because there will be no one to update it and for libraries that are actively maintained, they'll likely support both Clojure 1.2.x and Clojure 1.3.0 fairly soon anyway... -- 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: suggestion for clojure development
On Wed, Sep 28, 2011 at 12:03 AM, Arthur Edelstein arthuredelst...@gmail.com wrote: You may think I'm doing it wrong, but I don't think I'm alone at all. I don't think you're doing anything wrong - and I'm sure many people only do minimal research on tools they use. I just think your expectations of Clojure the language are unrealistic, in terms of maintaining total compatibility with the myriad third party (and sometimes unmaintained) libraries. For comparison, Scala went thru a lot of binary compatibility issues in the transition from 2.7 to 2.8, to the point that even milestone builds were not always compatible with each other. This meant the entire tool chain had to be rebuilt on almost every milestone build. Apparently there were a few similar bumps on the transition to 2.9 (I don't know for sure: I lived thru the 2.7 to 2.8 debacle and chose not to go to 2.9). I hear similar stories for other fast-evolving languages. I think it's just a fact of life with new technologies - and we pay that price for being early adopters. Yes, I think it will be very helpful to mark which jars are compatible with 1.2 or 1.3 -- I suppose this can be extracted from the dependencies vector in the project.clj file. Unlikely. Some libraries that depend on contrib 1.2.0 run on Clojure 1.3.0 just fine, some libraries that depend on new contrib modules are not yet compatible with 1.3.0 (no dynamic metadata on earmuffed variables is the most common issue I think but the numeric improvements may also cause incompatibilities). As I said, even with metadata in Clojars, unmaintained libraries won't get updates to show what version they're compatible with and actively maintained libraries should quickly transition to supporting both Clojure 1.2.x and 1.3.0 so it may be moot anyway... -- 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: tools.trace (was Re: trace-forms macro on the clojure mailing list)
Thank you Luc! On Tue, Sep 27, 2011 at 11:44 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: First shot of tools.trace is now available on github: http://github.com/clojure/tools.trace As for the traceforms macro, you will notice that when an exception is trapped, I recompose an new exception with the necessary form traceback information instead of using print. The main reason is that I want the form traceback to stay close to the exception message. Otherwise if you run several threads writing to stdout, you may end up with split outputs on standard output (the exception message in one spot and the form traceback elsewhere) Comments/suggestions are welcomed. The README.MD is on its way and I still need to review the code to see if they are remaining rough edges. Nothing beats a paper output and a coffee... I expect to work on the build process next week-end and get the first version out next week. Time to go to bed, my eyes are now useless ... Luc P. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure.contrib.io, clojure.contrib.http.agent and clojure.contrib.http.connection for Clojure 1.3
On Mon, Sep 26, 2011 at 6:45 AM, Stuart Sierra the.stuart.sie...@gmail.com wrote: Most of clojure.contrib.io was moved into Clojure itself, as clojure.java.io. When I created http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go I did it based on the modules folder here https://github.com/clojure/clojure-contrib/tree/master/modules I don't see io or http there - were those migrated in 1.2.0? Or were they just dropped when monolithic contrib was broken into modules? Should I update that wiki page to show more/older modules and where they went? -- 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: Fund raising's goal has been reached !
Excellent! See you at the Conj! On Mon, Sep 19, 2011 at 6:49 AM, Laurent PETIT laurent.pe...@gmail.com wrote: I'm happy to inform you that the appeal I've started previous week, for sending me to the conj, has been a success! I'm very grateful to all the donors who've contributed to make this dream possible! -- 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: advantage of dynamic typing
On Mon, Sep 19, 2011 at 4:19 PM, Dennis Haupt d.haup...@googlemail.com wrote: an advantage i see is very, very concise code since you have no type annotations at all. the downside is that exactly this code might be unreadable - because you just have no idea what it uses and what it does without tests or documentation. I find Clojure code more readable because it is generic. Instead of some algorithm specialized by type, Clojure often deals with simpler generic algorithms that are applicable to a broader class of data structures which can also mean more reuse. Writing truly generic code in the presence of a strong type system is often harder word and tends to produce much more dense, more annotated code that I find harder to understand. Take a look at the documentation for the Scala collection library, for example (I'm not dissing Scala - I like Scala, but I don't think anyone will disagree that the auto-generated documentation based on the library type signatures is very hard to read, at least for the average developer). -- 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 embedded in a Java Application
On Sun, Sep 18, 2011 at 3:40 AM, Meikel Brandmeyer m...@kotka.de wrote:
Var keyword = RT.var(clojure.core, keyword);
Var hashMap = RT.var(clojure.core, hash-map);
hashMap.invoke(keyword.invoke(foo), 1, keyword.invoke(bar), x);
This one is more simple. This is clojure code.
Since I've ended up discussing it with a few people here at The
Strange Loop, I thought it opportune to provide an example of interop
into CFML (another dynamic scripting language on the JVM), using a
little bridge library I created:
// assumes x is declared with some value...
// variables.clj contains the root Clojure binding:
var core = variables.clj.clojure.core;
var result = variables.clj.myns.foo( core.hash_map( core.keyword( a
), 1, core.keyword( bar ), x ) );
The bridge injects a specified set of namespaces into the root binding
so they can be accessed as a nested structure with a method missing
style mechanism used to sugar-coat the calls to invoke(). _ is
automatically translated to - in symbols.
We use a convention that namespace._sym() returns a reference to
namespace/sym whereas namespace.sym() calls (namespace/sym) - with
namespace._(sym) for symbols that aren't valid CFML identifiers.
That allows us to do stuff like:
var data = [ 1, 2, 3, 4, 5 ]; // native CFML array
var result = core.map( core.partial( core._(*), 3 ), data );
for (var elem in result) {
// realizes result of map as each elem value is obtained
writeOutput( elem br / );
}
Whilst not as clean as pure Clojure, it allows for great interop as
well as exposing a lot of the power of Clojure directly into our CFML
code (and, yes, for anyone who thought CFML was all tags there is a
full JavaScript-like scripting language in there too!). We run all
our CFML code on the JBoss community project, Railo.
Behind the scenes it uses clojure.lang.RT and RT.var() and .invoke() /
.deref() for everything.
--
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 vs Scala - anecdote
On Wed, Sep 14, 2011 at 11:15 PM, cig clifford.goldb...@gmail.com wrote: Impressive, wonder if they were running this on a single node or more widespread? We run an instance of the process on multiple nodes, configured slightly differently. We needed some parallelization to improve throughput but didn't need a massive net of processes. And we needed JVM interop so Erlang is out (and Erjang isn't yet mature enough - at least, not last time I looked). But clojure is an awesome combination Indeed. -- 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: autoboxing in 1.3 RC-0
On Thu, Sep 15, 2011 at 7:50 AM, David Nolen dnolen.li...@gmail.com wrote: Loop itself will return boxed values I think. Looks that way. The following code has no reflection warning: (loop [x 1 changed 0] (if (= x 10) changed (recur (inc x) (long (loop [y 1 changed-y changed] changed-y) -- 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: run clj file get user/counter-app error?
On Tue, Sep 13, 2011 at 10:42 PM, jayvandal s...@ida.net wrote: I am running a swing tutorial clojure program file and when I run the result is ++ user= (load-file c:/clojure-1.2.1/counter-app.clj) #'user/counter-app user= ++ What does this line mean? #'user/counter-app In the REPL, you loaded the file into the user namespace and, since your file doesn't specify a namespace, that causes counter-app to be defined in the user namespace, hence: #'user/counter-app -- 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: debugging
On Wed, Sep 14, 2011 at 12:05 AM, Sergey Didenko sergey.dide...@gmail.com wrote: Also bear in mind that due to the functional nature of Clojure you can debug a lot of problems using tracing, like clojure.contrib.trace (for 1.3) Coming soon to 1.3! Luc Prefontaine has volunteered to maintain this library as clojure.tools.cli going forward (which will work with 1.2 and 1.3 BTW). -- 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: Neighbors function from The Joy of Clojure
On Wed, Sep 14, 2011 at 5:58 AM, Leonardo Borges
leonardoborges...@gmail.com wrote:
(defn neighbors
([size yx] (neighbors [[-1 0] [1 0] [0 -1] [0 1]] size yx))
([deltas size yx]
(filter (fn [new-yx]
(every? #( -1 % size) new-yx))
(map #(map + yx %) deltas
This syntax made me scratch my head since I believe it was the first
time I saw it.
In case it wasn't clear from Chouser's response, the key difference is
that this declares two versions of neighbors, one that takes three
arguments and one that takes four - essentially overloading on arity.
Here's an example from some of our code at World Singles:
(defn save-row
Given a table name (string), a record and an optional
key-gen function, either insert it after applying the
key-gen function (if no pk) or update it. In both
cases, return the pk. The default key-gen function
is a no-op (identity).
When operating on a MongoDB collection, the logic is
much simpler because the pk is always :_id and key
generation is always handled by MongoDB. Also, we
always return the entire updated record (since we
can run functions against the database).
([table record](save-row table record identity :id 0))
([table record key-gen](save-row table record key-gen :id 0))
([table record key-gen pk] (save-row table record key-gen pk 0))
([table record key-gen pk retry]
...))
Mostly we call this as (save-row :table-name {:some record}) but we
can also supply a key generation function (save-row :table-name {:some
record} add-uuid), for tables that don't have a generated PK column,
and we can specify the PK name if it isn't :id (save-row :table-row
{:some record} identity :email).
Ignore retry - we need to refactor that into a private helper function
:) It's part of the machinery that let's automatically retry
operations on MongoDB if the replica set has no active primary node
since it can take a while to failover...
Hope that helps?
--
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: [ANN] Clojure 1.3 RC0
On Wed, Sep 14, 2011 at 8:45 AM, Paul Stadig p...@stadig.name wrote: This compiles fine in 1.2.1, but fails in 1.3.0-RC0 Intentional removal: https://github.com/clojure/clojure/blob/master/changes.txt 1.3 Disallow recur across try -- 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: Problem with insert-values (clojure.contrib.sql)
On Wed, Sep 14, 2011 at 12:51 AM, finbeu info_pe...@t-online.de wrote: Yes, if I understand it correctly, instead of db, I just use the pooled-db It would be good to have an example that connects the pooled db stuff with the normal db stuff. Ah, that would make it clearer.. (defn db-update-or-insert Updates or inserts a fruit [record] (sql/with-connection pooled-db It would be (sql/with-connection @pooled-db .. or (sql/with-connection (db-connection) .. I like the function wrapper because it's easy to forget the deref (@). -- 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: [ANN] Clojure 1.3 RC0
On Wed, Sep 14, 2011 at 9:43 AM, Aaron Bedra aaron.be...@gmail.com wrote: And the supporting ticket in JIRA http://dev.clojure.org/jira/browse/CLJ-31 Nice. Now I understand better why this was disabled. -- 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: Problem with insert-values (clojure.contrib.sql)
On Tue, Sep 13, 2011 at 6:49 AM, finbeu info_pe...@t-online.de wrote: BTW: Does someone know how I can keep the connection always open? If I understand it right, with-connection does a connect and login to the db each time it gets called. Isn't this quite inefficient? Take a look at https://github.com/clojure/java.jdbc/blob/master/doc/clojure/java/jdbc/ConnectionPooling.md That's pretty much what we use at World Singles. -- 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: [ANN] Clojure 1.3 RC0
On Tue, Sep 13, 2011 at 6:02 AM, Christopher Redinger redin...@gmail.com wrote: Clojure 1.3 RC0 is now available at http://clojure.org/downloads Changes since Beta 3: * Optimization should not demote BigInts (CLJ-836) * Added Intrinsics Could someone speak to this change since it didn't have an attached JIRA ticket? It looks like an optimization to use direct bytecodes rather than static method calls for a certain set of operations in some contexts? * fix nary-inline so *unchecked-math* works again Please download it and let us know how it works for you. 1.3 is getting close. We'll be running tests today on dev, CI and probably QA. We're looking to take a new build of our platform into production this week, which has a LOT more Clojure in it and, if RC0 works out, that'll be in our production build too. -- 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 vs Scala - anecdote
On Tue, Sep 13, 2011 at 9:48 AM, Nathan Sorenson n...@sfu.ca wrote: I adore Clojure as well, but could this success not be partially due to the reimplementing for the second time phenomenon? i.e. if you re- wrote the entire thing in Scala again, perhaps you would see similar gains in brevity etc? Well, the Scala world has moved on quite a bit since 2009 so I could certainly make it somewhat more concise (I'd use the parallel collections in 2.9 instead of actors and I hope there's a better SQL abstraction by now so I could drop the ResultSet collection wrapper I wrote). I doubt I could reduce it by a factor of three which is what it would take to get close to the Clojure code. I don't know who posted it on HN but I see it's also on DZone and so it's generated a lot of noise out there and now I'm probably going to do a more detailed comparison and analysis to post on my blog, to answer some of the critical voices on HN... It was intended to be purely anecdotal but that doesn't seem to satisfy anyone! :) -- 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: Problem with insert-values (clojure.contrib.sql)
On Tue, Sep 13, 2011 at 10:43 PM, finbeu info_pe...@t-online.de wrote: But how do I use the connectionpool now from clojure.java.jdbc? Did you read that documentation? Does it not provide enough information? Let me know so I can make it better. -- 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: How to compose futures?
On Sun, Sep 11, 2011 at 1:29 AM, Laurent PETIT laurent.pe...@gmail.com wrote: now that I've stepped back a little bit and acknowledged my ignorance (while working on it : currently reading Java concurrency in practice :-) ) Kevin pulled me up on this too (in IRC) and pointed me at the Java solution. As it happened I decided to avoid an async solution in the end (the speed up wasn't worth the complexity of adding concurrency in my situation - which I didn't know for sure until I'd tried both approaches). This remains me of the viscosity smell : if it's way easier to do the wrong thing than it is to do the right thing, expect people to do the wrong one. Yes, it seems that this is a common enough need that it would be nice to have an idiomatic Clojure library to implement this, perhaps as part of new contrib? Kevin, I'd be particularly interested in your thoughts on that since I understand you feel the Java solution is already pretty clean and simple? -- 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: Migration to 1.3 for mortals
On Sat, Sep 10, 2011 at 2:59 AM, Jan Rychter jrych...@gmail.com wrote: Thanks for the explanations. I'll summarize: clojure-contrib is being reorganized. There is no clear migration path for applications that use the monolithic 1.2 contrib. Not all of 1.2 contrib code made its way into new modules yet. There is no migration guide for existing applications. I'm working on this page: http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go I need input from contrib library authors past and present. One thing I discovered while ploughing through old contrib is that there is duplication of functions across namespaces (sometimes two namespaces are almost identical) and there's clearly a lot of unused cruft in many old contrib modules! I see no point in dragging all that baggage forward from release to release when it isn't being maintained (or used). As each release of Clojure itself appears and introduces backward compatibility issues, no matter how small, trying to maintain the huge blog of legacy code that is the 1.2 monolithic contrib makes absolutely no sense. I'd much rather see an announcement of production-ready Clojure 1.3 than an announcement of very cool core code that can't really be used in production systems. World Singles is using Clojure 1.3 in production today - without monolithic contrib. We're using several new contrib libraries and the 3rd party libraries we use have all been made 1.3 compatible (sometimes that's taken me becoming a committer on those librares, sometimes the author is only too happy to make the changes once they've been pointed out). -- 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: Migration to 1.3 for mortals
On Fri, Sep 9, 2011 at 11:04 AM, Sean Corfield seancorfi...@gmail.com wrote: On Fri, Sep 9, 2011 at 1:09 AM, Jan Rychter jrych...@gmail.com wrote: Take an example -- even in the relatively simple case of clojure.contrib.combinatorics: note that it is NOT listed on http://dev.clojure.org/display/doc/Clojure+Contrib, and if I follow the github repos I'll end up in https://github.com/clojure/math.combinatorics which tells me nothing about what I should add to project.clj (what is the latest released version, for instance). That contrib has not been fully migrated yet. There is no build for it (on build.clojure.org) and therefore it is not getting any Maven releases yet. FWIW, I've just worked with Mark Engelberg to Mavenize his three contrib libraries (math.combinatorics, math.numeric-tower, data.priority-map) and as soon as the Clojure/core folks get time to do, there should be automated builds and the ability to release 0.0.1 versions to Maven Central. If a contrib library you need has not been migrated to the new contrib system, please contact the author and see if they're willing to migrate and maintain the library. If they no longer care / support the code, there's no point to it being in new contrib. The whole point of new contrib is to ensure that Clojure's libraries are actually being maintained and updated to work which each new version of Clojure. But also look at what you're actually depending on and see whether there's a better solution (an example: defnk in c.c.def has not been migrated to clojure.core.incubator because Clojure supports keyword arguments natively now thru map destructuring). -- 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: Migration to 1.3 for mortals
On Sat, Sep 10, 2011 at 9:46 AM, Jan Rychter jrych...@gmail.com wrote: If you use Clojure to build an application that you subsequently launch and maintain, it is pretty much a given that you use contrib. Lots of it, in fact. I think that depends on when you started building stuff with Clojure. I get the impression quite a bit of old contrib grew up to provide functionality not in Clojure's core and I see quite a few pieces of old contrib that are explicitly deprecated because functions moved to Clojure 1.2 (c.c.string, for example, mostly moved to clojure.string long before Clojure 1.3 got under way). I suspect that folks who started with Clojure long ago and are relying heavily on old contrib, are probably relying on those old deprecated namespaces and functions and have simply avoided updating their code to use the newer, supported namespaces. I think the break in contrib coming with 1.3 will be good for the Clojure ecosystem overall because it will force a lot of folks to clean up their code :) As noted in another one of my comments in this thread, World Singles started with Clojure 1.2 but switched to Clojure 1.3 early on and so we've essentially not been allowed to depend on that old, unsupported contrib code which I view as a big positive for us (as well as getting the performance boost of the updated numerics in Clojure 1.3). One of the things World Singles needed early on was clojure.contrib.sql so I pushed for that to be migrated and have ended up being the maintainer now. If you can't find an author to migrate and maintain an old contrib library, another option is for you to volunteer to do that work and then you have the added benefit of being able to enhance the library to better suit your needs (e.g., I added the ability to return generated keys from insert operations in clojure.java.jdbc). importantly, I worry that I won't be able to take advantage of Clojure 1.3 in any of my applications anytime soon. A definite possibility - but changing your code to not rely on outdated, unsupported libraries would have benefit to you in the long run, yes? I think contrib modularization should either be carried all the way in time for 1.3, or stopped altogether (meaning I could continue to use the same old monolithic contrib code with Clojure 1.3). Sorry, that ship done sailed a while back. I don't know how much work it would be to make the modular contrib work on Clojure 1.3 (work stopped on contrib around 1.3.0 Alpha 4) and given the number of library authors who've stepped up to modernize and maintain new contrib versions of old library modules, I can't imagine who'd put in that work (to make old, unsupported code run on Clojure 1.3). -- 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: Migration to 1.3 for mortals
On Sat, Sep 10, 2011 at 2:52 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: We were in production in Jan 2009 before Clojure 1.0 came out. We face the issue of un-rooting ourselves from the old contrib stuff. After analysis, 97% of the stuff we need from the old contrib is now available in 1.3 as separate libs. The only thing we would like to keep is the trace module by Stuart Sierra and we volunteer to move it to 1.3 and maintain it. Excellent! I'm looking forward to trying that module once you have an updated version of it! -- 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: Migration to 1.3 for mortals
On Fri, Sep 9, 2011 at 1:09 AM, Jan Rychter jrych...@gmail.com wrote: Take an example -- even in the relatively simple case of clojure.contrib.combinatorics: note that it is NOT listed on http://dev.clojure.org/display/doc/Clojure+Contrib, and if I follow the github repos I'll end up in https://github.com/clojure/math.combinatorics which tells me nothing about what I should add to project.clj (what is the latest released version, for instance). That contrib has not been fully migrated yet. There is no build for it (on build.clojure.org) and therefore it is not getting any Maven releases yet. I have to say that from the point of view of application developers the current state of contrib likely means I won't be migrating to 1.3 anytime soon. What's worse, I'll be left in a situation where there are bugs in 1.2 contrib which only get fixed in the 1.3 version, which I won't be able to use. The new contrib modules are usable with Clojure 1.2 code by design (and by mandate - the matrix tests are being run automatically against Clojure 1.2, Clojure 1.2.1 and Clojure 1.3.0). See, for example, this matrix for clojure.java.jdbc : http://build.clojure.org/job/java.jdbc-test-matrix/ I already have one such bug that I reported (and provided a fix) for clojure.contrib.json. It never made it into any contrib release, which means we have to use a locally-modified version. If it hasn't been fixed in clojure.data.json, please create an issue here : http://dev.clojure.org/jira/browse/DJSON There should be a JIRA project for every active new contrib - http://dev.clojure.org/jira There should also be automated builds (both regular and matrix tests) on build.clojure.org I think issues like that are fundamentally important if Clojure is to be adopted for production work. I agree - which is why I'm pushing on clojure-dev for some serious attention to be paid to the contrib migration issue. -- 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: Migration to 1.3 for mortals
On Wed, Sep 7, 2011 at 5:44 AM, Jan Rychter jrych...@gmail.com wrote: How do we mere mortals (that develop and maintain large apps) migrate to 1.3? It's a good question - and it's being discussed right now on the clojure-dev list because the biggest obstacle to folks moving to Clojure 1.3 is what to do about contrib... A quick grep through our code shows we depend on: A lot of those libraries have no active maintainer - although I suspect many of the things you're relying on in several of them have already migrated into Clojure's core namespaces? clojure.contrib.command-line clojure.tools.cli - although it's actually a completely different library now (based on clargon). clojure.contrib.core Mostly moved to clojure.core.incubator. clojure.contrib.def Mostly moved to clojure.core.incubator. clojure.contrib.except Still under discussion: http://dev.clojure.org/display/design/Contrib+Library+Names clojure.contrib.io Some of this moved to clojure.java.io I believe? clojure.contrib.java-utils ?? clojure.contrib.json clojure.data.json clojure.contrib.logging clojure.tools.logging clojure.contrib.map-utils ?? clojure.contrib.mmap ?? clojure.contrib.seq Looks like most of this was already promoted to clojure.core. clojure.contrib.seq-utils (ClojureDocs shows the same contents for this as c.c.seq?) clojure.contrib.str-utils clojure.contrib.str-utils2 clojure.contrib.string Didn't most of those three get promoted to clojure.string a while back? clojure.contrib.trace That just came up in discussion on clojure-dev but no volunteer has stepped forward to maintain it yet I believe. clojure.contrib.zip-filter Looks like it moved to clojure.data.zip? clojure.contrib.zip-filter.xml Looks like it moved to clojure.data.zip.xml? I got some version numbers from github repo READMEs, some from manually listing directories under https://oss.sonatype.org/content/groups/public/org/clojure/ search.maven.org for org.clojure is probably the definitive word on released versions: http://search.maven.org/#search%7Cga%7C1%7Corg.clojure There must surely be a better way — any hints would be very much appreciated. Also, a suggestion for documentation maintainers: please think about people who have code based on 1.2 and haven't followed Clojure closely for the past 2 years or so — we lack a lot of context information that might be obvious to you. As an example, I managed to list lots of clojure.contrib modules before realizing that this particular modularization is obsolete and has already been abandoned in one of the alphas. Definitely a big problem (lack of clear communication) and it seems that Clojure/core has this on their radar now so hopefully things will improve over the next few months. -- 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 vs Scala - anecdote
On Wed, Sep 7, 2011 at 10:17 AM, Dennis Haupt d.haup...@googlemail.com wrote: so the scala actors add much more overhead than the clojure equivalent? The main problem is that the current implementation of actors in Scala suffers from known memory leaks and performance problems - problems that are completely addressed by Akka, which is why they're going to incorporate it and replace the current implementation. Our choices at World Singles were: migrate to Akka, wait for Scala 2.10 (which is when I think Akka will be folded in). Neither were appealing solutions. Migrating to Clojure was less work and more timely (for us). -- 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 1.3 Beta 3
On Sun, Sep 4, 2011 at 7:15 AM, cri chuck.irvine...@gmail.com wrote: Is there a list of everything new in 1.3? Thanks Looks like four commits since beta2: https://github.com/clojure/clojure/commits/master load resources when baseLoader() is null, refs #673 CLJ-815 de-alpha docstring for juxt CLJ-736 docfix add equiv overload for primitive booleans The overall change list is here: https://github.com/clojure/clojure/blob/master/changes.txt but that doesn't quite list *everything* - it's a very good summary tho'... Bear in mind the biggest changes for 1.3 (c.f. 1.2) are in the contrib libraries: http://dev.clojure.org/display/design/Contrib+Library+Names -- 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: No such var while calling a (:require) 'd function
On Sun, Sep 4, 2011 at 11:37 AM, Timothy Washington twash...@gmail.com wrote: (ns bkell (:import java.io.FileReader) (:require commands.add) (:require commands.update) (:require commands.get) (:require commands.remove) (:require commands.authenticate) (:require domain) (:require util) ) These are requiring namespaces so I would expect you'd have a namespace commands.remove and it would contain functions...? (defn remove [akey etal] (let [ logged-in-user (commands/logged-in-user)] (if (- logged-in-user nil?) ;; we want to see a logged-in-user (util/generate-error-response User is not authenticated) (eval `(commands/remove ~akey ~@etal)) ;; this is line 61 ) ) ) I would expect to see (commands.remove/some-func ..) here... so I'm a little puzzled when you say it works for invoking functions in other require'd commands.* namespaces. Can you share a bit more of your code? -- 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: coming from statically typed oo languages - how do deal with complex objects graphs in clojure?
On Sun, Sep 4, 2011 at 11:40 AM, Dennis Haupt d.haup...@googlemail.com wrote:
- Nested defns are not good.
why? imo, nested function/method definitions are a tool to fine-tune
accessibility. just like public/private, but much more powerful. why
Right, but defn binds function names at the top-level (which is why
it's considered poor form to nest them - it doesn't create nested
functions). So those functions are actually all public in that
namespace:
user= (defn foo[a] (defn bar[b] (* a b)))
#'user/foo
user= (foo 2)
#'user/bar
user= (bar 3)
6
user= (meta #'user/bar)
{:ns #Namespace user, :name bar, :file NO_SOURCE_PATH, :line 1,
:arglists ([b])}
See how bar is defined when foo is called but it is callable directly
in the user namespace?
Using let or letfn creates locally scoped functions, which is what you want.
again, why? the functions belong there, and nowhere else. they do not
make sense outside the winner-function. they use parameters which are
in scope there. factoring them out would actually make them more
complex since i would have to add more parameters to their signatures.
You can define functions private to your namespace with defn- and you
can define them locally to other forms with let/letfn.
--
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
On Sun, Sep 4, 2011 at 12:59 AM, Alan Malloy a...@malloys.org wrote:
Well, ^something still is equivalent to ^{:tag something}, which as I
understand it is useful for compiler typehinting.
It's probably also worth noting that metadata combines in 1.3.0:
(defn ^:foo ^:bar fubar [] )
In 1.2.1, this gives:
user= (meta #'user/fubar)
{:ns #Namespace user, :name fubar, :file NO_SOURCE_PATH, :line 7,
:arglists ([]), :tag :foo}
In 1.3.0, this gives:
user= (meta #'user/fubar)
{:arglists ([]), :foo true, :bar true, :ns #Namespace user, :name
fubar, :line 1, :file NO_SOURCE_PATH}
--
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: No such var while calling a (:require) 'd function
On Sun, Sep 4, 2011 at 1:20 PM, Timothy Washington twash...@gmail.com wrote: I was hacking away at this at the meantime. I defined 'remove' functions in 2 other places - bkell , commands. I ended up renaming commands/remove to commands/removek, and now all invocations are working. But I'm pretty sure I'm using namespace and require erroneously. Currently, I have a source file structure like below: src/ bkell.clj src/commands/ add.clj remove.clj etc... But each of the 'src/commands/' clojure files, uses the '(ns command ...)' namespace, not '(ns command.remove ...)', etc. I wanted to do it this way, so that client code could just call command/remove, not command.remove/remove. But I'm realising that I should instead define (ns commands) once, and use (in-ns) in other locations. You can see the source here. Looks like 'get' can be redefined in two other namespaces: bkell , commands. But when I try to do that for 'remove', the repl seizes up, and I'm curious to know why. The require should be: (ns bkell (:require commands)) and then you'll reference the functions as (commands/add ...) (commands/remove ...) etc. I'm not sure why (:require commands.remove) doesn't give you an error... perhaps it was pulling in commands/remove.clj anyway? Is there any reason why you have the commands split across multiple files? (I'm not saying it's bad, just curious) I suspect you're somehow calling remove recursively (but it's hard to tell without seeing more of your code). Sounds like you're gradually getting a handle on namespaces... -- 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: No such var while calling a (:require) 'd function
On Sun, Sep 4, 2011 at 2:06 PM, Timothy Washington twash...@gmail.com wrote: That's interesting. When I try that require A), I get the error in B). Seems that it's trying to find the commands.clj file. Yes. If you look at how various projects work with multiple files in a single namespace, I think they have a file for the namespace that then loads the others (which are part of that namespace). See this SO QA for an example: http://stackoverflow.com/questions/4690758/splitting-a-clojure-namespace-over-multiple-files -- 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
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
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
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
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
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: new Getting Started page
I think this is a much better on ramp for folks new to Clojure and the bullet list of the current Getting Started page really should be the next page not the first one. On Fri, Sep 2, 2011 at 3:13 PM, nchurch nchubr...@gmail.com wrote: There was some discussion about the Getting Started page last night at the Bay Area meetup. I've put together an (I think) improved version at http://dev.clojure.org/display/doc/Getting+Started+for+Beginners Any suggestions/additions/deletions? If this overall looks good, may I replace the current page at http://dev.clojure.org/display/doc/Getting+Started with this one? I'd put the current page under other options, because it gives a lot of choices. My hope was to give a relatively clean path for beginners (who are the audience for Getting Started), instead of just throwing everything there is at them without comment. Someone who has been around Clojure for a while knows that Lein is much more standard than Gradle, but to a reader of the current Getting Started page they look the same. -- 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?
Looks like it doesn't work in 1.2.1 but does work in 1.3.0: (! 516)- lein repl REPL started; server listening on localhost port 61980 user= (clojure-version) 1.2.1 user= (defn my-inc [x] (+ x 1)) #'user/my-inc user= (eval '(my-inc 1)) 2 user= (future (eval '(my-inc 1))) java.lang.Exception: Unable to resolve symbol: my-inc in this context user= ^D Fri Sep 02 15:37:24 (sean)-(jobs:0)-(~/clojure/stable) (! 517)- cd ../beta1/ Fri Sep 02 15:37:30 (sean)-(jobs:0)-(~/clojure/beta1) (! 518)- lein repl REPL started; server listening on localhost port 48094 user= (clojure-version) 1.3.0-beta1 user= (defn my-inc [x] (+ x 1)) #'user/my-inc user= (eval '(my-inc 1)) 2 user= (future (eval '(my-inc 1))) #core$future_call$reify__5733@739abd2b: 2 user= (deref *1) 2 user= -- 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
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
Re: Top secret clojure project names
On Thu, Sep 1, 2011 at 2:31 PM, JAX jayunit...@gmail.com wrote: Hi guys: I assume some of you have secret Clojure projects at work, that your bosses don't know about. LOL! That would be hard for me - every commit and every ticket update / comment is emailed to the whole project team which includes management :) It does pose an interesting question tho': how many folks are using skunkwork projects to introduce Clojure vs opening getting buy in up front? -- 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: a question about using the delay macro
I was trying to construct a simple example of what I actually have in
my apps that use pooling on top of java.jdbc. My actual code *does*
work to create a singleton but you're right, I've contracted my code
too far in trying to create a simple example of it... I'll have
another attempt!
Sean
On Aug 22, 3:04 am, Meikel Brandmeyer (kotarak) m...@kotka.de
wrote:
Am Montag, 22. August 2011 11:53:32 UTC+2 schrieb faenvie:
yesterday i came across the following use of
the delay-macro:
(defn pooled-data-source
[db-connection-settings]
; this Fn creates and returns object of type PooledDataSource
)
(defn pooled-data-source-as-singleton
[db-connection-settings]
(let [datasource (delay (pooled-data-source db-connection-
settings))]
@datasource))
i am not sure, what the exact semantic of this is and if
it's safe in a multithreaded context.
What is the difference to using def/defonce ?
Someone who can explain ?
This snippet does not work as the original author intended. You can remove
the whole delay incantations and everything will work as before. That's
because each call of pooled-data-source-as-singleton creates a new delay,
forces it and throws it away immediately. What probably was intended, is the
use of memoize:
(def ^{:arglists ([db-connection-settings])} pooled-data-source-as-singleton
(memoize pooled-data-source))
The intention is to delay the creation of the datapool instance until
runtime and not do it on load time. This is also nice if you have your db
connection configurable in some non-code form. If you have only one db
connection, which is hardwired in some Var at load time, you can go with the
following:
(let [db-connection-pool (delay (pooled-data-source
db-connection-settings))]
(defn pooled-data-source-as-singleton
[]
@db-connection-pool))
This is maybe, what the original author had in mind.
Hope, I'm not too far off.
--
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.java.jdbc: mapping BigDecimal to double
No, you'd have to do it yourself. Since not all BigDecimal values would fit correctly in double, it would be dangerous for resultset-seq to do it. I expect there are all sorts of JDBC data types that don't quite match Clojure types but I don't think automatically mapping them would be a good idea... Sean On Tue, Aug 23, 2011 at 6:16 PM, HiHeelHottie hiheelhot...@gmail.com wrote: It looks like Oracle NUMBER types get mapped to BigDecimal in a result seq from clojure.java.jdbc. Is there an easy way to configure clojure.java.jdbc/ResultSet to map Oracle NUMBERS to doubles? -- 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.java.jdbc: mapping BigDecimal to double
On Tue, Aug 23, 2011 at 6:54 PM, HiHeelHottie hiheelhot...@gmail.com wrote:
Completely agree with you that it shouldn't automatically map out of
the box. As a newbie to clojure and jdbc, do you have any advice on
how I can get into resultset-seq* to do the mapping? I think it would
be better not to have to map a BigDecimal to double after resultset-
seq* returns a row.
Apply something like this to the result?
(map (fn [row] (into {} (map (fn [[k v]] [k (some-mapping v)]) row))) results)
Are there any future plans to add a mapping api to resultset-seq or is
the pattern just to chain any custom mappings after resultset-seq?
Currently no plans. I don't want to add the overhead of map-over-map
for all users when I suspect only a few would want / need such a
mapping.
--
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: try catch and finally
On Tue, Aug 16, 2011 at 12:36 PM, rakesh rakesh.pulip...@gmail.com wrote: In java the finally block is executed after the catch block. But in clojure, I observed that the finally block is executed before catch block. Is this behavior right. Are you sure? user= (try (println in try) (throw (Exception. oops!)) (catch Exception e (println caught it!)) (finally (println ...and finally))) in try caught it! ...and finally nil -- 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: Small bug in clojure.core/bases?
On Sun, Aug 14, 2011 at 9:04 PM, Stephen Compall stephen.comp...@gmail.com wrote: I personally favor seqable? as the test for plural return values. sequential? almost qualifies, but excludes sets. seq? fails on account of rejecting even vectors, but you may feel differently. And just to do my usual pitch for the new contrib libraries so folks can get used to them and start switching from old monolithic contrib to the new modular contribs... seqable? now lives in [org.clojure/core.incubator 0.1.0] -- 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: is my understanding correct for function identity?
On Sat, Aug 13, 2011 at 9:45 AM, jaime xiejianm...@gmail.com wrote:
The only reason that I can imagine is this: because we often use
higher-order functions, these higher-order functions will accept
functions as its parameters, in such a situation, when we want to use
a higher-order function but don't want to pass any real functions to
it, then we can use function like identity and identity here is
just to fill the role of parameter of higher-order function.
Guys, is my guess correct or not?
Yup. As an example, in clojure.java.jdbc, there are naming strategies that
determine how to map between entity names in the database (strings) and
keywords in the Clojure maps that represent those entities. The default
behavior from keyword to string is do nothing (other than call 'name' to
convert the keyword to a string) so the code uses the identity function as
the default strategy when the user doesn't override it.
In my own code I have a data mapper that wraps c.j.jdbc and it takes an
optional key-gen function that can calculate and assoc in the primary key
for a record. Again, the default behavior is to do nothing and let the
database had the key generation:
(defn save-row
Given a table name (string), a row (struct) and an
optional key-gen function, either insert it (if no
:id) or update it. In both cases, return the :id.
If no key-gen function is provided the database
must auto-generate the :id.
([table r] (save-row table r identity))
([table r key-gen] ...))
If you call (save-row :user {:name Sean}) it calls itself as (save-row
:user {:name Sean} identity).
I could call it like this to generate the primary key as the hash of the
name column: (save-row :user {:name Sean} (fn [m] (assoc m :id (.hashCode
(:name m)
--
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
