Re: (doc more-examples)
Or an option for more extended doc when launching REPL for those who need the extra documentation more than performance during development, or maybe a searchable dictionary panel at the left hand side of REPL, ala some versions of Ruby's irb. Meanwhile, thanks for the pointer to the clojure quickref at clojuredocs.org. Good enough. Tuba On Sat, Jul 16, 2011 at 9:11 PM, Stuart Halloway stuart.hallo...@gmail.comwrote: On Sat, Jul 16, 2011 at 2:23 AM, Tuba Lambanog tuba.lamba...@gmail.com wrote: More examples in how to use a form in the (doc ...) facility within REPL would be very useful to newbies. Thanks. That would mean the docstrings need to provide more detail in the source code. Not sure how practical that is since the docstrings would substantially outweigh the code - maybe Clojure/core could comment? I wouldn't use docstrings for this, as they increase runtime footprint. That said, an alternate doc macro could look other places besides docstrings. It shouldn't be difficult to write an examples macro that calls out to e.g. clojuredocs.org. Stu Stuart Halloway Clojure/core http://clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Questions About Assoc-in, Dissoc-in, etc.
On Sat, Jul 16, 2011 at 9:16 PM, Alan Malloy a...@malloys.org wrote: On Jul 16, 7:11 pm, Asim Jalis asimja...@gmail.com wrote: I've been using assoc-in and dissoc-in to navigate through nested associative structures (HTTP requests). Had some questions: 1. Why doesn't dissoc-in take multiple key-sequences? For example: (dissoc-in m [:a :b :c] [:a :b :d]) I can do this using a series of dissoc-in calls, but it might be easier to just have this naturally there. (update-in m [:a :b] dissoc :c :d) 2. Why isn't there a select-in? Even dissoc-in is in contrib instead of in core. Is there an easier way to do these things that I am missing? What is select-in supposed to do? It's either get-in+select-keys, or update-in+select-keys, depending on what you intend. 3. Similar to #1, why doesn't assoc-in take a sequence of key-sequences and values? For example: (assoc-in m [:a :b :c] 1 [:a :b :d] 2) Again this is possible by doing a sequence of assoc-in calls. Now is the reason these are not provided to hint that this might not be the most efficient way to do this kind of surgery? (update-in m [:a :b] assoc :c 1 :d 2) Very nice. Thanks. -- You 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: FleetDB or other NoSQL store for Clojure?
Ad hoc transactions are possible in MongoDB, they are just not provided out-of-the-box and (I guess) impose performance penalty. http://www.mongodb.org/display/DOCS/two-phase+commit -- You 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
Odp: Re: FleetDB or other NoSQL store for Clojure?
As far as I know, the only NoSQL DB supporting transactions right now is Redis. It also satisfies the rest of your points (well, I'm not sure if Redis run on windows...). +1 for Redis -- we are using it in production, in fact it's a central piece of our architecture, and so far it's been working out splendidly. There are some wrappers for Cojure around, for example this one: https://github.com/ragnard/redis-clojure That one seems to be no longer maintained. We have encountered problems with it, so I have a couple of unofficial patches at https://github.com/nathell/redis-clojure Be sure to use the clojure-1.2 branch unless you are working with an ancient version of Clojure; there are also unofficial releases at Clojars: http://clojars.org/org.clojars.nathell/redis-clojure Another option is clj-redis by Mark McGranaghan. It's currently a bit lacking in functionality (at least it was a couple of months ago), it uses Jedis whereas redis-clojure is 'pure' Clojure; definitely worth checking out. Best, - Daniel -- You 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
how to preserve the natural reading order in clojure program?
Hello,
Usually, when I write a program, I tend to organize the function to
keep with higher abstraction on the top and the details implementation
in the end of the file like this:
start() {
doGenericThing1();
doGenericThing2();
}
doGenericThing1() {
doSpecific();
}
doGenericThing2() {
doSpecific()
}
doSpecific() {..}
The idea is that when I open the file I want to see the most important
stuff, not the implementation details. This is also a more natural way
of reading the code. In Clojure, however, I am forced to place more
specific functions on top of the file or I will get Unable to resolve
symbol. Yes, it is possible to overcome by using declare call on
the top, but this requires manual work. Is there something more
automated which I am not aware of?
Wbr,
Jevgeni Holodkov
--
You 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 preserve the natural reading order in clojure program?
On Sun, Jul 17, 2011 at 7:33 AM, Jevgeni Holodkov
jevgeni.holod...@gmail.com wrote:
Hello,
Usually, when I write a program, I tend to organize the function to
keep with higher abstraction on the top and the details implementation
in the end of the file like this:
start() {
doGenericThing1();
doGenericThing2();
}
doGenericThing1() {
doSpecific();
}
doGenericThing2() {
doSpecific()
}
doSpecific() {..}
The idea is that when I open the file I want to see the most important
stuff, not the implementation details. This is also a more natural way
of reading the code. In Clojure, however, I am forced to place more
specific functions on top of the file or I will get Unable to resolve
symbol. Yes, it is possible to overcome by using declare call on
the top, but this requires manual work. Is there something more
automated which I am not aware of?
Sort of.
You can use two namespaces to achieve this, one with the
implementation-detail functions and then another, which (ns foo (:use
...))s the first, with the public API.
People might also differ as to natural reading order. Actually, with
factual work usually one puts the motivation first, then develops the
little things needed to eventually draw the big conclusion, and then
develops the argument and conclusion -- but also puts the
bibliography, which has the references to further sources, last.
Code generally turns that last on its head; Java also wants import
declarations at the top of the file, rather than the bibliography
being at the bottom. To put the motivation above the argument and
eventual conclusion you might want to use a comment.
--
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.
--
You 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: Odp: Re: FleetDB or other NoSQL store for Clojure?
For redis, aleph's lib is worth trying too. I've had good luck with it. http://ztellman.github.com/aleph/aleph.redis-api.html I believe it's used in production at runa. Zachary Tellman has done a great job with aleph/lamina and friends. -- You 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: leiningen 1.6.1 not compatible with lein-nailgun 1.1.0
On Sat, Jul 16, 2011 at 7:09 PM, Wei yayits...@gmail.com wrote: I tracked the issue down to lein-nailgun (I believe it requires some dependencies incompatible with the new version of lein), but I'm unsure how to fix it. The lein-nailgun plugin has lots of problems: * It depends upon an ancient version of Leiningen. (c. December of 09) * It declares its dependency upon Leiningen when this should be implicit. * It starts a background thread without blocking the main thread. (interferes with Leiningen's workaround to this Clojure bug: http://dev.clojure.org/jira/browse/CLJ-124) * It appears to have separate lines development a number of forks without coordination. The first three problems may be addressed in one of the forks; I did not try them all. The two problems can be solved by :exclusions in your project.clj: :dev-deps [[lein-nailgun 0.1.0 :exclusions [leiningen]]] The third problem just needs a @(promise) added at the end of the form that starts the background nailgun thread. A more general question: how do you find the latest version number of a library? $ lein search lein-nailgun == Results from clojars - Showing page 1 / 4 total [lein-nailgun 0.1.0] leiningen plugin to run nailgun server [org.clojars.brandonw/lein-nailgun 1.0.0] A leiningen plugin to launch a vimclojure nailgun server. [org.clojars.brandonw/lein-nailgun 1.0.0-SNAPSHOT] A leiningen plugin to launch a vimclojure nailgun server. [org.clojars.gfodor/lein-nailgun 1.1.0] A leiningen plugin to launch a vimclojure nailgun server. Here you can see that the canonical version of lein-nailgun is way behind and the forks have continued development independently. Either the maintainer disappeared without finding a suitable replacement or the forkers just haven't bothered to try to get their work back upstream. Either one is bad news. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: FleetDB or other NoSQL store for Clojure?
- it should support transactions I love the word *should* :) Question: Do you really need transactions? or is that you just need conflict resolution? I ask because many No-SQL datastores support the later which often is good enough (or even better in my opinion). For example look at the description for RIAKs model: Riak’s approach ensures that the datastore is always write-available, and that writes always succeed, even in the face of a network split or hardware failure, so long as the client can reach at least one node in the cluster. The tradeoff is that the client performing the read must do a little extra work to resolve the conflict, or can optionally choose to take the latest version of the object (this is the default setting.) Where... take the latest version of the object (this is the default setting.) is all I really ever need. MongoDB is similar, in that it supports conflict resolution, only I believe you only have the option for the last write wins. MongoDB is better suited to an embedded db model, that doesn't have to support large datasets... so if you're OK with the last write wins model - go for mongo. https://github.com/aboekhoff/congomongo Also there's a few other no-sql database connectors I list out in my blog (with links to the libraries): http://blackstag.com/blog.posting?id=23#subsection8 On Jul 15, 1:17 am, Marko Kocić marko.ko...@gmail.com wrote: Hi all, I would like to try out some of those no-sql datastores for my next project, and need an advice which one, since I never used the one before. It needs to fulfill at least some of those following criteria, in order of importance: - is nicelly supported by Clojure (by this I mean idiomatic clojure driver, not java plain java wrapper) - it should be schemaless - it should support transactions - it's good if it can be used as embedded db - it doesn't have to support large datasets (in-memmory is ok) - it has to run on both Windows and Linux My first choice would be FleetDB, since it was written in Clojure and examples look nice, but I'm not sure if it is abandonware or not, and I havent heard that people are actually using it in production. What are my other options? Regards, Marko -- You 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 preserve the natural reading order in clojure program?
Use (declare ...) to declare vars not yet defined (vars include fns).
You will be able to preserve the presentation order you want.
This will also make it clear which implementation details are
defined in the same source file versus stuff imported from another
name space.
Luc P.
On Sun, 17 Jul 2011 04:33:19 -0700 (PDT)
Jevgeni Holodkov jevgeni.holod...@gmail.com wrote:
Hello,
Usually, when I write a program, I tend to organize the function to
keep with higher abstraction on the top and the details implementation
in the end of the file like this:
start() {
doGenericThing1();
doGenericThing2();
}
doGenericThing1() {
doSpecific();
}
doGenericThing2() {
doSpecific()
}
doSpecific() {..}
The idea is that when I open the file I want to see the most important
stuff, not the implementation details. This is also a more natural way
of reading the code. In Clojure, however, I am forced to place more
specific functions on top of the file or I will get Unable to resolve
symbol. Yes, it is possible to overcome by using declare call on
the top, but this requires manual work. Is there something more
automated which I am not aware of?
Wbr,
Jevgeni Holodkov
--
Luc P.
The rabid Muppet
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: how to preserve the natural reading order in clojure program?
Oops, missed the part you wrote about declare...
There is no real solution to your problem except declare.
Evaluation is done for each form submitted one by one. There is no file scope
in this context.
I still think that declare is the way to go except. Splitting things in
different name spaces is even more work.
Luc P.
On Sun, 17 Jul 2011 04:33:19 -0700 (PDT)
Jevgeni Holodkov jevgeni.holod...@gmail.com wrote:
Hello,
Usually, when I write a program, I tend to organize the function to
keep with higher abstraction on the top and the details implementation
in the end of the file like this:
start() {
doGenericThing1();
doGenericThing2();
}
doGenericThing1() {
doSpecific();
}
doGenericThing2() {
doSpecific()
}
doSpecific() {..}
The idea is that when I open the file I want to see the most important
stuff, not the implementation details. This is also a more natural way
of reading the code. In Clojure, however, I am forced to place more
specific functions on top of the file or I will get Unable to resolve
symbol. Yes, it is possible to overcome by using declare call on
the top, but this requires manual work. Is there something more
automated which I am not aware of?
Wbr,
Jevgeni Holodkov
--
Luc P.
The rabid Muppet
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: FleetDB or other NoSQL store for Clojure?
Tim, I think you mean CouchDB, which indeed is master-master. MongoDB is extended master-slave. On Sun, Jul 17, 2011 at 6:45 PM, Tim Robinson tim.blacks...@gmail.comwrote: MongoDB is similar, in that it supports conflict resolution, only I believe you only have the option for the last write wins. MongoDB is better suited to an embedded db model, that doesn't have to support large datasets... so if you're OK with the last write wins model - go for mongo. -- You 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 preserve the natural reading order in clojure program?
I might suggest looking at literate programming.
A literate program will allow you to structure your
program in any natural way that facilitates understanding.
The extracted code that Clojure sees can be arranged
in the order required by the REPL.
Tim Daly
d...@literatesoftware.com
On Sun, 2011-07-17 at 12:42 -0400, Luc Prefontaine wrote:
Oops, missed the part you wrote about declare...
There is no real solution to your problem except declare.
Evaluation is done for each form submitted one by one. There is no file
scope
in this context.
I still think that declare is the way to go except. Splitting things in
different name spaces is even more work.
Luc P.
On Sun, 17 Jul 2011 04:33:19 -0700 (PDT)
Jevgeni Holodkov jevgeni.holod...@gmail.com wrote:
Hello,
Usually, when I write a program, I tend to organize the function to
keep with higher abstraction on the top and the details implementation
in the end of the file like this:
start() {
doGenericThing1();
doGenericThing2();
}
doGenericThing1() {
doSpecific();
}
doGenericThing2() {
doSpecific()
}
doSpecific() {..}
The idea is that when I open the file I want to see the most important
stuff, not the implementation details. This is also a more natural way
of reading the code. In Clojure, however, I am forced to place more
specific functions on top of the file or I will get Unable to resolve
symbol. Yes, it is possible to overcome by using declare call on
the top, but this requires manual work. Is there something more
automated which I am not aware of?
Wbr,
Jevgeni Holodkov
--
Luc P.
The rabid Muppet
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: how to preserve the natural reading order in clojure program?
There are programming languages that support forward references without any additional work on your part, but Clojure is not one of them. If you are accustomed to working in one of these languages, it is understandable that you have come to associate a top-down organization with being a natural code organization. It is hard to give up old habits. My personal experience, coming from a Java background, is that if you are willing to let go of that association for a time (e.g. a month), you will begin to find that a bottom-up organization feels natural. -- You 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: Please stand firm against Steve Yegge's yes language push
Are Steve Yegge's comments blogged/written anywhere? The last post I could find on his blog http://steve-yegge.blogspot.com/ was about Haskel and written 12/1/2010. Thanks. cmn On Jul 1, 3:59 pm, James Keats james.w.ke...@gmail.com wrote: Hi all. I've been looking at Clojure for the past month, having had a previous look at it a couple of years ago and then moved on to other things only to return to it now. Over the past decade I have looked at many languages and many ways of doing things. People may say this language or that language is general purpose, but the fact remains that languages have their niches in which they excel and beyond which it'd be foolish to venture. Clojure should not attempt be a mass success language or worry about its Tiobe index ranking. Clojure, the way I see it, is most suitable for the advanced independent developer. It is a language in the image of its creator, Rich Hickey. It's not a language for the factory hen. It won't become the next Java. Java already fills that niche, and despite what some may say, I don't see it going away anytime soon. I don't feel Clojure needs to grow - in terms of size of language. In fact it would worry me enormously if Clojure's path is to grow in size. It is fundamentally unsuited for that. If anything I wish for it to shrink even further and further. A Rich Hickey's quote comes to mind: • (paraphrased) Most Clojure programmers go through an arc. First they think “eww, Java” and try to hide all the Java. Then they think “ooh, Java” and realize that Clojure is a powerful way to write Java code and As I've said in my talks, most Clojure users go from eww, Java libs to ooh, Java libs, leveraging the fact there there is already a lib for almost anything they need to do. And using the lib is completely transparent, idiomatic and wrapper free. - Google verbatim for sources. Whereas when Steve Yegge writes: which means that everyone (including me!) who is porting Java code to Clojure (which, by golly, is a good way to get a lot of people using Clojure) is stuck having to rework the code semantically rather than just doing the simplest possible straight port. The more they have to do this, the more you're going to shake users off the tree. all I could think on reading this is horror, horror, oh God, horror!!!; he really doesn't get it. First, he shouldn't be porting Java code to clojure, Second, Clojure IS fundamentally different from Java, and third, such said users who don't want to touch Java should not touch Clojure. Clojure shouldn't worry about growing; java already has innumerable libs. Clojure, imho, should continue its - what I would dub - middleware begone! path, in which it'd provide an end-to-end, down- to-the-metal comprehensible system that an individual developer can get his head round and know exactly what's happening with his code and its environment here and everywhere. I could write more, but I have to run. Regards. J. -- You 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: Anyone on Google+ yet?
http://gplus.to/weissjeffm -- You 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: Anyone on Google+ yet?
This does bring up an interesting flaw in G+. If I add Clojure people who I don't know personally, how will they know to add me to a Clojure circle? G+ (rightfully) doesn't automatically tell them what circle I added them to. It doesn't appear to be optional to tell them, either. On Jul 14, 7:56 pm, Kyle Root k...@kylert.com wrote: gplus.to/Kylert On Thu, Jul 14, 2011 at 7:00 PM, ianp ian.phill...@gmail.com wrote: Ian Looks like G+ is pretty popular with the Clojure crowd :-) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: FleetDB or other NoSQL store for Clojure?
I wasn't saying that MongoDB was similar in terms of master-master vs. master-slave, I was saying MongoDB was similar in that it implements conflict resolution rather that transactions. http://www.mongodb.org/display/DOCS/Atomic+Operations MongoDB supports atomic operations on single documents. MongoDB does not support traditional locking and complex transactions for a number of reasons:... And that MongoDB implements a currency check (Update if Current) to resolve conflicts. On Jul 17, 11:04 am, Sergey Didenko sergey.dide...@gmail.com wrote: Tim, I think you mean CouchDB, which indeed is master-master. MongoDB is extended master-slave. On Sun, Jul 17, 2011 at 6:45 PM, Tim Robinson tim.blacks...@gmail.comwrote: MongoDB is similar, in that it supports conflict resolution, only I believe you only have the option for the last write wins. MongoDB is better suited to an embedded db model, that doesn't have to support large datasets... so if you're OK with the last write wins model - go for mongo. -- You 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: FleetDB or other NoSQL store for Clojure?
Could be that I am using the wrong wording with conflict resolution. Tim On Jul 17, 1:53 pm, Tim Robinson tim.blacks...@gmail.com wrote: I wasn't saying that MongoDB was similar in terms of master-master vs. master-slave, I was saying MongoDB was similar in that it implements conflict resolution rather that transactions. http://www.mongodb.org/display/DOCS/Atomic+Operations MongoDB supports atomic operations on single documents. MongoDB does not support traditional locking and complex transactions for a number of reasons:... And that MongoDB implements a currency check (Update if Current) to resolve conflicts. On Jul 17, 11:04 am, Sergey Didenko sergey.dide...@gmail.com wrote: Tim, I think you mean CouchDB, which indeed is master-master. MongoDB is extended master-slave. On Sun, Jul 17, 2011 at 6:45 PM, Tim Robinson tim.blacks...@gmail.comwrote: MongoDB is similar, in that it supports conflict resolution, only I believe you only have the option for the last write wins. MongoDB is better suited to an embedded db model, that doesn't have to support large datasets... so if you're OK with the last write wins model - go for mongo. -- You 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: FleetDB or other NoSQL store for Clojure?
On Sun, Jul 17, 2011 at 3:53 PM, Tim Robinson tim.blacks...@gmail.com wrote: I wasn't saying that MongoDB was similar in terms of master-master vs. master-slave, I was saying MongoDB was similar in that it implements conflict resolution rather that transactions. http://www.mongodb.org/display/DOCS/Atomic+Operations MongoDB supports atomic operations on single documents. MongoDB does not support traditional locking and complex transactions for a number of reasons:... And that MongoDB implements a currency check (Update if Current) to resolve conflicts. That's interesting. Basically, it's like compare and set -- so, a MongoDB is like a disk-persistent collection of atoms, whereas most databases are like a disk-persistent collection of refs. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You 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: Anyone on Google+ yet?
I just check if the people in the people you have both in a circle match up with my clojure-circle ;) easy enough :D 2011/7/17 jweiss jeffrey.m.we...@gmail.com This does bring up an interesting flaw in G+. If I add Clojure people who I don't know personally, how will they know to add me to a Clojure circle? G+ (rightfully) doesn't automatically tell them what circle I added them to. It doesn't appear to be optional to tell them, either. On Jul 14, 7:56 pm, Kyle Root k...@kylert.com wrote: gplus.to/Kylert On Thu, Jul 14, 2011 at 7:00 PM, ianp ian.phill...@gmail.com wrote: Ian Looks like G+ is pretty popular with the Clojure crowd :-) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[ANN] clojure.java.jdbc 0.0.4 available on Maven Central
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
* Add initial test cases
* 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: Please stand firm against Steve Yegge's yes language push
On Sun, Jul 17, 2011 at 10:59 AM, octopusgrabbus octopusgrab...@gmail.com wrote: Are Steve Yegge's comments blogged/written anywhere? Googling is your friend -- search for: steve yegge clojure yes language and it turns up the original thread as the second result: http://groups.google.com/group/seajure/browse_thread/thread/18baa18ffdbdd790 This thread in which we are participating is the #1 result for that query on Google, 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: Please stand firm against Steve Yegge's yes language push
On Jul 8, 8:37 pm, Christian Marks 9fv...@gmail.com wrote: The moral of this story is: don't let anyone clip your wings. Well said. That is my take away too. It is surprising how to me how much weight people give to the assertions of others, famous or not. In truth, this human endeavor of programming (as all else) is really just a series of experiments, some grander than others, some will succeed, some fail, (and sometimes oscillate between success and failure over time :) The best thing someone can do, rather than opine loudly about the outcome of an experiment, is to either a) help to define and execute the experiment or b) if you don't like the idea, help to define and execute a different experiment. When the results are in, *then* you can opine loudly. :) So that, Chris, is why out of 125 posts (or so) I wanted to respond to yours, because you have done the experiment. Frankly, I'm not really sure if it's a good idea or not to reimplement Java libraries like Swing in Clojure, but I do know that we won't know unless someone gives it a shot. -- Josh -- You 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: Please stand firm against Steve Yegge's yes language push
Thanks. On Jul 17, 5:52 pm, Sean Corfield seancorfi...@gmail.com wrote: On Sun, Jul 17, 2011 at 10:59 AM, octopusgrabbus octopusgrab...@gmail.com wrote: Are Steve Yegge's comments blogged/written anywhere? Googling is your friend -- search for: steve yegge clojure yes language and it turns up the original thread as the second result: http://groups.google.com/group/seajure/browse_thread/thread/18baa18ff... This thread in which we are participating is the #1 result for that query on Google, 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
First Clojure Conj Rich Hickey Talk Not About Hammock
I heard that Rich Hickey gave another talk about Clojure at the first Clojure Conj besides the Hammock one. In it he talked about dynamic vars. Does anyone know if this was videoed or if there are any notes about this? I am interested in knowing more about dynamic vars. Does anyone know of any detailed explanation of it? -- You 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: Please stand firm against Steve Yegge's yes language push
On Jul 17, 6:43 pm, javajosh javaj...@gmail.com wrote: On Jul 8, 8:37 pm, Christian Marks 9fv...@gmail.com wrote: The moral of this story is: don't let anyone clip your wings. Well said. That is my take away too. It is surprising how to me how much weight people give to the assertions of others, famous or not. In truth, this human endeavor of programming (as all else) is really just a series of experiments, some grander than others, some will succeed, some fail, (and sometimes oscillate between success and failure over time :) I was responding to the idea that one should play around with Java for a few months before getting involved with Clojure. Spending months with a language whose idea of a type system is one in which the only operation on types is sub-classing sounds like a recipe for instantaneous profound boredom. Perhaps Java has improved its type system, but whatever it is, it isn't homotopy type theory (cf. http://homotopytypetheory.org/ ). ... So that, Chris, is why out of 125 posts (or so) I wanted to respond to yours, because you have done the experiment. Frankly, I'm not really sure if it's a good idea or not to reimplement Java libraries like Swing in Clojure, but I do know that we won't know unless someone gives it a shot. -- Josh I didn't re-implement Swing--it was just a translation of a demo from a language I didn't know into another I didn't know, using a build system I didn't know. I did manage to learn more by doing several things at once, instead of plodding through one language at a time; e.g., I saw how to handle resources in Clojure in conjunction with Leiningen (cute name: the author seems to have been bitten by Ant). What I posted was a second iteration--I wasn't making use of doto, for or if-let at first, incidentally. CM -- You 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: Please stand firm against Steve Yegge's yes language push
On Jul 2, 10:30 am, James Keats james.w.ke...@gmail.com wrote: What is actually there in his posts in that thread?! blatherings and generalities about community and attitude and language economics and marketing that any kid high on weed who'd read a post too many on reddit's /r/programming could've wrote, and what little specific technical detail shows a clear lack of knowledge about clojure and its take on functional programming and java interop and unwillingness to learn. I see I've been gratuitously harsh. I agree with this, having narrowly escaped the evangelists for the Information Technology Indoctrination Library at my former place of employment. Since I've posted some working code, I'm going to indulge in my own journalistic, sociological gloss. I am reminded of the anthropological finding that the human brain decreased in volume by 10% — about the size of a tennis ball — around the dawn of civilization 20,000 years ago. It is believed that the decrease in volume coincided with the emergence of cooperative, prosocial behavior, which enabled the members of reduced-cranium groups to solve some problems that eluded their more amply brained relatives. The larger brains were adapted to more independent modes of survival. But the question for me--speaking of weed-addled advocacy of community and attitude--is how far are we willing to decrease the volume of our brain cases in the name of cooperation? I have now vastly exceeded my OT limit. :) -- You 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: What's the best way to test private functions?
A good pattern to follow would be to have your exposed functions in one clj file and any dependent functions (your private ones in this case) in a separate ns (i.e. separate clj file). This hides the implementation to the caller as well as gives them a good idea of the functions they're able to use. -- You 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: Tail Calls and Continuations in Clojure
On Fri, 15 Jul 2011, Joel Dice wrote: On Fri, 15 Jul 2011, George Jahad wrote: very cool Joel! I'd also be interested in start up time of avian vs. hotspot, i.e. does avian make it viable to use clojure for short, quick scripts? Possibly. By default, Avian is noticeably slower to start up than Hotspot, at least when using OpenJDK's class library. The boot process for that library touches a lot of code in a lot of classes, and Hotspot has several performance advantages to make quick work of it. On the other hand, Avian can also be built to use its own class library, which allows much faster startup. Unfortunately, it doesn't currently have all the classes needed to support Clojure, and I haven't checked to see how much would need to be added to make it work. Avian also supports ahead-of-time compilation from Java bytecode to native machine code, so it would be possible to create an executable with all the OpenJDK and Clojure classes precompiled, thereby bypassing the need for JIT compilation at runtime except for dynamically-loaded classes. That would be faster, but I'm not sure by how much. The ideal approach in terms of startup time would be to add whatever classes needed to Avian's class library to support Clojure, use ProGuard to shrink and optimize the combination of clojure.jar and the system class library, and precompile the result into native code. I might take a stab at that if I have time. I went ahead and pursued this. The upshot is that I can get Avian to run a minimal Clojure script (containing just (println hello, world!)) over twice as fast as Hotspot by precompiling clojure.jar to native code. These are the results on my 2.2GHz Xeon: $ time java -jar ~/p/clojure-1.2.1/clojure.jar hello.clj hello, world! real0m0.858s user0m1.004s sys 0m0.040s $ time ./build/clojure hello.clj hello, world! real0m0.303s user0m0.264s sys 0m0.036s It turned out using OpenJDK's class library was not really the bottleneck, which is good because Avian's built-in library would need to be augmented significantly to run Clojure itself. The main challenge is that Clojure touches a lot of code on startup, which works the JIT compiler hard. Hotspot is better at this because it uses a high-performance interpreter by default and doesn't JIT compile methods until/unless it's deemed a win. Avian's not so smart; it has to compile each method before it can be run. This makes Clojure a good test case for profiling Avian's compiler, though, and I was able to cut startup time for the JIT build by about 60% with a few judicious optimizations. Then I moved on to an ahead-of-time (AOT) compiled build, which further reduced startup time to to result above. Ultimately, though, I don't think this is enough of an improvement to make Clojure viable for short, quick scripts. 300ms is a long time for printing hello, world. I wonder how feasible it would be to make Clojure rely more heavily on lazy initialization so there isn't as much code to be run at startup for simple scripts. That's what I suspect needs to be done to improve startup time on any VM. -- You 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: Tail Calls and Continuations in Clojure
On Sun, Jul 17, 2011 at 7:24 PM, Joel Dice joel.d...@gmail.com wrote: I went ahead and pursued this. The upshot is that I can get Avian to run a minimal Clojure script (containing just (println hello, world!)) over twice as fast as Hotspot by precompiling clojure.jar to native code. These are the results on my 2.2GHz Xeon: This is fascinating. I never would have guessed that a JVM capable of running Clojure could be implemented in 50kLOC. Ultimately, though, I don't think this is enough of an improvement to make Clojure viable for short, quick scripts. 300ms is a long time for printing hello, world. I wonder how feasible it would be to make Clojure rely more heavily on lazy initialization so there isn't as much code to be run at startup for simple scripts. For what it's worth, I believe work in this direction has been done in 1.3 with the goal of improving Android performance, though it's unclear how thorough it was and if there's much remaining that could be done. I tried Leiningen on Avian and it caused Maven's dependency injection framework to choke, which is not terribly surprising. Perhaps once we've ported it over to Aether it will fare better. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Tail Calls and Continuations in Clojure
On Sun, 17 Jul 2011, Phil Hagelberg wrote: I tried Leiningen on Avian and it caused Maven's dependency injection framework to choke, which is not terribly surprising. Perhaps once we've ported it over to Aether it will fare better. My goal is for Avian to be able to run anything HotSpot can when using OpenJDK's class library, so I'll investigate this and fix it if I can. FWIW, it handles Spring's dependency injection just fine, at least as far as I've tested it. -- You 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: Tail Calls and Continuations in Clojure
On Sun, Jul 17, 2011 at 9:10 PM, Joel Dice joel.d...@gmail.com wrote: My goal is for Avian to be able to run anything HotSpot can when using OpenJDK's class library, so I'll investigate this and fix it if I can. FWIW, it handles Spring's dependency injection just fine, at least as far as I've tested it. If you need any help getting it going I can point you in the right direction, but for what it's worth the problem seems to be orthogonal to Clojure. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: leiningen 1.6.1 not compatible with lein-nailgun 1.1.0
On Sun, Jul 17, 2011 at 8:37 AM, Phil Hagelberg p...@hagelb.org wrote: * It starts a background thread without blocking the main thread. (interferes with Leiningen's workaround to this Clojure bug: http://dev.clojure.org/jira/browse/CLJ-124) I've documented the issue with threading in Leiningen's plugin documentation: https://github.com/technomancy/leiningen/blob/master/doc/PLUGINS.md Anyone writing a plugin that uses threads would do well to read the Threads section of that document. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
