Re: Release.Next Version Number
2011/2/24 Brian Marick > > On Feb 23, 2011, at 3:06 PM, David Jacobs wrote: > > > Thanks for the suggestions. I should say that I was only giving you my > impression of using Clojure re: it's version number. I'm not saying any of > the things I listed are not doable, just that they feel very ad-hoc and not > quite ready for a "2.0". > > > I agree. My gut tells me "2.0" implies promises about the ecosystem and > ease-of-adoption. Clojure 2.0 would be overpromising. Better to underpromise > and overdeliver, as they say. > Well, day after day, I'm leaning more towards semantics versioning. Because, heh, given the dilemnas that everybody spotted in each solution, why not just choose the pragmatic and "semantic-full" versioning scheme ? Do people really relate the numbers in Windows 7 and MacOS 10, for example ? C'mon ... -- You 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 Toolbox (Early Beta)
On Wed, Feb 23, 2011 at 6:17 PM, James Reeves wrote: > I'm sure I've covered only a very small proportion of Clojure > libraries out there, so if you'd like to suggest a project that's not > on there, please do so in this thread, or in an email to me. I'll try > and update the site as quickly as possible. > Some that I like: slice scriptjure clojurejs cssgen gaka -- You 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 namespace conventions
My goodness.. Seems like a can of worms. :p I think I'll pick something at least two levels deep like "pauldoo.someproject", complete with ".core" and ".tools" as sub namespaces.. On 23 February 2011 20:35, Mark Rathwell wrote: > > This discussion has been had multiple times on this list, not sure how much > new information you will get. See the following for a couple examples: > http://groups.google.com/group/clojure/browse_thread/thread/968e9066223c3a2b/fbce84869dbf4ce6?lnk=gst# > http://groups.google.com/group/clojure/browse_thread/thread/78a32eeaacd659e/89304aeec4d00f7d?lnk=gst# > > > > On Wed, Feb 23, 2011 at 3:19 PM, Paul Richards > wrote: >> >> Hi, >> Is there a guide to the conventions for naming and structuring >> namespaces in a Clojure project? >> >> I see for example that the ".core" namespace is fairly common in >> different projects. Is this also where the "-main" entry point should >> live? >> >> Also is it typical to have code living in "someproject" as well as >> "someproject.tools", or should the former be promoted to >> "someproject.core"? >> >> >> -- >> Paul Richards >> @pauldoo >> >> -- >> You 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 -- Paul Richards @pauldoo -- You 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
noob question: pallet, crane, which criteria to choose which one ?
Hello, I need to automatise some current "manual" delivery process. We have a fixed server (not -yet- the kind of "created on-demand" servers, just a plain old server already configured), but for which there still needs to be some manual delivery process. Example : * deliver to pre-production: * input = git commit hash, maven version of some "tooling" artifacts which are java artifacts, invoked via an mvn java execute target once the right git revision has been checked out * output = publish the "app state" (created locally from the derived git content) to a directory in the server, run a shell script on the server which finishes the install, and, if everything went well, tag the commit, and push the tag to the reference repo from which the content had been initially pulled from Note that this is not specifically centered around traditional "java webapp deployment". Would trying to use pallet or crane seem overkill ? Any open suggestion ? Cheers, -- Laurent -- You 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: Release.Next Version Number
Another vote for semantic versioning. I agree that the "claim to 2.0" comes with some expectations about environment and overall development experience, but I think that *backwards incompatible changes* deserve a major version bump, to keep heads straight and make it clear to newcomers where the lines are drawn. If we don't make the switch now, at which future set of breaking changes will we decide it's time to call it 2.0? We'd basically have to create our own criteria and have the "Clojure flavored" semantic versioning scheme, which I think would be more arbitrary and harder for folks to follow. -- You 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 Toolbox (Early Beta)
Awesome work! On 23 fev, 20:17, James Reeves wrote: > I've put together a small, static site inspired by The Ruby Toolbox > (ruby-toolbox.com), called (of course) The Clojure Toolbox. > > It's currently just a series of categorized links to Clojure projects, > but I'll be gradually adding more functionality to it over the coming > weeks. If you've been to the Ruby Toolbox site you'll likely know what > to expect (project descriptions, links to Clojars, GitHub watchers and > forks, etc.) > > The URL to the site is: > > http://www.clojure-toolbox.com > > I'm sure I've covered only a very small proportion of Clojure > libraries out there, so if you'd like to suggest a project that's not > on there, please do so in this thread, or in an email to me. I'll try > and update the site as quickly as possible. > > - James -- You 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: Release.Next Version Number
The choice boils down to whether or not you want to follow Semantic Versioning [1]. Apache (APR) [2], Eclipse [3], and OSGi [4] all seem to have equivalent policies. Personally, I think it's a perfectly logical approach to increment the major version number for any backwards incompatible change. Python officially has a more relaxed interpretation [5]. My understanding is that in practice the Python community was very concerned about backwards compatibility among the late 2.x releases because 3.0 was going to introduce big changes. > Python versions are numbered A.B.C or A.B. A is the major version number – it > is only incremented for really major changes in the language. B is the minor > version number, incremented for less earth-shattering changes. C is the > micro-level – it is incremented for each bugfix release. The Wikipedia article on software versioning [6] covers some other concerns such as marketing. I guess that takes into account the idea that "2.0" should be a major improvement. As I said, I personally like the concept of semantic versioning. If Rich wants to do something else, I can live with an incompatible 1.3. In any case, it would be useful for the Clojure Core team to document the Clojure version policy. [1] http://semver.org [2] http://apr.apache.org/versioning.html [3] http://wiki.eclipse.org/index.php/Version_Numbering [4] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf [5] http://docs.python.org/faq/general.html#how-does-the-python-version-numbering-scheme-work [6] http://en.wikipedia.org/wiki/Software_versioning -- You 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 Toolbox (Early Beta)
I'd like to see some graphics libraries. Penumbra would be a great addition. Timothy On Thu, Feb 24, 2011 at 9:22 AM, Fernando Pazin wrote: > Awesome work! > > On 23 fev, 20:17, James Reeves wrote: >> I've put together a small, static site inspired by The Ruby Toolbox >> (ruby-toolbox.com), called (of course) The Clojure Toolbox. > -- You 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: Release.Next Version Number
I have noticed some projects go to an x.5 release when they are half- ready to move to (inc x).0 -- in this case which would be 1.5 instead of 1.3 or 2.0 version. Just a thought. Regards, Shantanu On Feb 24, 7:56 pm, semperos wrote: > Another vote for semantic versioning. I agree that the "claim to 2.0" comes > with some expectations about environment and overall development experience, > but I think that *backwards incompatible changes* deserve a major version > bump, to keep heads straight and make it clear to newcomers where the lines > are drawn. > > If we don't make the switch now, at which future set of breaking changes > will we decide it's time to call it 2.0? We'd basically have to create our > own criteria and have the "Clojure flavored" semantic versioning scheme, > which I think would be more arbitrary and harder for folks to follow. -- You 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: Release.Next Version Number
On Thu, 2011-02-24 at 11:33 -0500, Steve Miner wrote: > The choice boils down to whether or not you want to follow Semantic > Versioning [1]. Apache (APR) [2], Eclipse [3], and OSGi [4] all seem to have > equivalent policies. Personally, I think it's a perfectly logical approach > to increment the major version number for any backwards incompatible change. > > Python officially has a more relaxed interpretation [5]. My understanding is > that in practice the Python community was very concerned about backwards > compatibility among the late 2.x releases because 3.0 was going to introduce > big changes. > > > Python versions are numbered A.B.C or A.B. A is the major version number – > > it is only incremented for really major changes in the language. B is the > > minor version number, incremented for less earth-shattering changes. C is > > the micro-level – it is incremented for each bugfix release. > > The Wikipedia article on software versioning [6] covers some other concerns > such as marketing. I guess that takes into account the idea that "2.0" > should be a major improvement. > > As I said, I personally like the concept of semantic versioning. If Rich > wants to do something else, I can live with an incompatible 1.3. In any > case, it would be useful for the Clojure Core team to document the Clojure > version policy. > > > > [1] http://semver.org > > [2] http://apr.apache.org/versioning.html > > [3] http://wiki.eclipse.org/index.php/Version_Numbering > > [4] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf > > [5] > http://docs.python.org/faq/general.html#how-does-the-python-version-numbering-scheme-work > > [6] http://en.wikipedia.org/wiki/Software_versioning > I agree. One thing we should keep in mind is that if we're going to follow semantic versioning, we should not plan *any* backwards-incompatible changes in the near future. In other words, after 2.0, we should be done changing the language for a while, or we'll risk bumping major versions on every release. -- You 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: Release.Next Version Number
What makes an ecosystem '1.x' vs '2.x' etc. needs to be quantifiable to make a standard out of it. To quote Peter Drucker, "What gets measured gets managed." Are there any solid examples of languages that would constitute a good canonical spectrum for ecosystem versions and why? It seems like if the ecosystem surrounding a language is another concern in the semantic versioning equation that can't be sufficiently be expressed by the existing scheme, there should be a another digit(s) or a whole other semantic version system for it (e.g. 1.2.0.0 or perhaps 0.1.0_2.0.0 for Clojure 2.0 with a basic, whatever that may mean, ecosystem surrounding it.) My points may also be a moot point, since it seems to make this SemVer compatible we might have to call it SemVer 1.1.0, or 2.0 depending on how people thought the extra digit(s) would affect the compatibility with the SemVer spec as it stands. (Is it SemVer 1.0.0 right now?) All this being said, I like the idea of semantic versioning and I wish more languages/software at least attempted some sort of version number scheme transparency. #(+ 1 %) to semantic versioning. TL;DR Can an ecosystem be properly versioned? Can that version be cleanly expressed by the current SemVer scheme? -- You 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: Release.Next Version Number
Part of my underlying concern is one of branding and not directly based on concerns about measuring and/or quantifying the quality of an ecosystem. I fully recognize that we could call the next iteration of Clojure "2.0" and would be well within our rights. My point has been that calling it 2.0 may give people the impression that developing in the language is seamless and well-polished. When they find out that it's not, Clojure may experience some backlash. (What's more, if Clojure wants to continue adding backwards-incompatible features at the same rate that it is now, it would not be advisable to bump the major version just yet.) That said, I don't have a real problem saying the language itself is 2.0-worthy. David On Thu, 2011-02-24 at 11:45 -0500, Dennis Crenshaw wrote: > What makes an ecosystem '1.x' vs '2.x' etc. needs to be quantifiable > to make a standard out of it. To quote Peter Drucker, "What gets > measured gets managed." Are there any solid examples of languages that > would constitute a good canonical spectrum for ecosystem versions and > why? > > It seems like if the ecosystem surrounding a language is another > concern in the semantic versioning equation that can't be sufficiently > be expressed by the existing scheme, there should be a another > digit(s) or a whole other semantic version system for it (e.g. 1.2.0.0 > or perhaps 0.1.0_2.0.0 for Clojure 2.0 with a basic, whatever that may > mean, ecosystem surrounding it.) > > My points may also be a moot point, since it seems to make this SemVer > compatible we might have to call it SemVer 1.1.0, or 2.0 depending on > how people thought the extra digit(s) would affect the compatibility > with the SemVer spec as it stands. (Is it SemVer 1.0.0 right now?) > > All this being said, I like the idea of semantic versioning and I wish > more languages/software at least attempted some sort of version number > scheme transparency. #(+ 1 %) to semantic versioning. > > TL;DR Can an ecosystem be properly versioned? Can that version be > cleanly expressed by the current SemVer scheme? > -- You 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: Release.Next Version Number
you mean inc On Thu, Feb 24, 2011 at 8:45 AM, Dennis Crenshaw wrote: > What makes an ecosystem '1.x' vs '2.x' etc. needs to be quantifiable > to make a standard out of it. To quote Peter Drucker, "What gets > measured gets managed." Are there any solid examples of languages that > would constitute a good canonical spectrum for ecosystem versions and > why? > > It seems like if the ecosystem surrounding a language is another > concern in the semantic versioning equation that can't be sufficiently > be expressed by the existing scheme, there should be a another > digit(s) or a whole other semantic version system for it (e.g. 1.2.0.0 > or perhaps 0.1.0_2.0.0 for Clojure 2.0 with a basic, whatever that may > mean, ecosystem surrounding it.) > > My points may also be a moot point, since it seems to make this SemVer > compatible we might have to call it SemVer 1.1.0, or 2.0 depending on > how people thought the extra digit(s) would affect the compatibility > with the SemVer spec as it stands. (Is it SemVer 1.0.0 right now?) > > All this being said, I like the idea of semantic versioning and I wish > more languages/software at least attempted some sort of version number > scheme transparency. #(+ 1 %) to semantic versioning. > > TL;DR Can an ecosystem be properly versioned? Can that version be > cleanly expressed by the current SemVer scheme? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
removing primitive support 4 or less restriction?
I know that this has come up - but when will the restriction of "fns taking primitives support only 4 or fewer args" be removed? -- You 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: Release.Next Version Number
Inc is probably a better way to say that, yeah. I also agree with David that 2.0 has a popular connotation of shiny-ness that came with the whole infamous Web 2.0 branding phenomenon. I am now at conflict internally, because I'd like to see Clojure widely adopted, but I like the idea of the language having the agility to do radical things to make itself better in a way that Java no longer posses. So 1.3 still has its advantages. Clojure always has the choice to stay the transition to semantic versioning until Rich feels that it's at a place that semantic versioning makes sense. I believe I've thought myself in a circle and need some hammock time on this. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Release.Next Version Number
I think we can all agree that the world would be a better place if every project strictly followed semantic versioning and if people interpreted version numbers accordingly. It would be a triumph of science over mysticism. But we know that people don't do this and that is why we are having this conversation. For some languages, taking into account what people are used to doing is an important concern (Java, C++). But I don't think that is Clojure's philosophy. Come on people, it's a Lisp. It would have never been a Lisp if Rich cared what the gut reaction of the masses would be. The core philosophy of Clojure is to do it right (even if that is not popular) and then convince people as to why this is the right way to do things. Clojure isn't a Trojan horse, it's a beacon of hope. Let's continue that tradition and not do something based on gut reactions. Let's do it right and call it the backward incompatible version 2.0 that it is. Maybe it will inspire other projects to do the same. Brenton On Feb 22, 6:27 pm, Christopher Redinger wrote: > As you can see on the Release.Next Planning page [1], there is an open > question about whether or not the next version of Clojure should be 1.3 or > 2.0. The issue at hand is that we are introducing backwards incompatible API > changes. Not looking to start a debate at this point, but just taking a > temperature reading from the community. If you care about what the next > version number of Clojure is - could you please cast a vote in the poll here: > > https://spreadsheets.google.com/a/thinkrelevance.com/viewform?hl=en&f... > > Thanks! > > [1]http://dev.clojure.org/display/design/Release.Next+Planning > > -- > Christopher Redingerhttp://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
Anyone using the sdb library?
Is anyone using the sdb (AWS SimpleDB) client library, originally written by Rich Hickey in 2009, and then tweaked in various ways by a couple of others since? Github repo network here: https://github.com/richhickey/sdb/network I ask because I have some ideas for some changes and enhancements to the library, some of which would be breaking (potentially from both an API and data format standpoint). It seems like having a dialogue with anyone that is actively using it would be productive, if only to ensure that I'm not headed towards the weeds. Beyond that, a collective attempt to coordinate the direction of the project would be good (rather than simply letting off-by-one forks of it proliferate on github). Cheers, - 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: ANN: Clojure Toolbox (Early Beta)
On 24 February 2011 09:46, Scott Jaderholm wrote: > Some that I like: > slice > scriptjure > clojurejs > cssgen > gaka Added. I wasn't quite sure how to classify slice, so I've put it under "Template Languages" for the time being. - James -- You 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 Toolbox (Early Beta)
On 24 February 2011 16:37, Timothy Baldridge wrote: > I'd like to see some graphics libraries. Penumbra would be a great addition. It's already there, under "Graphics" :) - James -- You 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: Release.Next Version Number
On Feb 24, 2011, at 3:09 PM, David wrote: > I fully recognize that we could call the next iteration of Clojure "2.0" > and would be well within our rights. My point has been that calling it > 2.0 may give people the impression that developing in the language is > seamless and well-polished. When they find out that it's not, Clojure > may experience some backlash. Without commenting on the validity of the above at all, I seem to recall that the application of the "1.0" version label prompted the same sort of concerns. - 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: Clojure namespace conventions
FWIW, I've settled on cemerick.project-name as my default. I think the project-name.core convention cropped up because of hesitancy of some to use their name at the top level. - Chas On Feb 24, 2011, at 5:48 AM, Paul Richards wrote: > My goodness.. Seems like a can of worms. :p > > I think I'll pick something at least two levels deep like > "pauldoo.someproject", complete with ".core" and ".tools" as sub > namespaces.. > > > > On 23 February 2011 20:35, Mark Rathwell wrote: >> >> This discussion has been had multiple times on this list, not sure how much >> new information you will get. See the following for a couple examples: >> http://groups.google.com/group/clojure/browse_thread/thread/968e9066223c3a2b/fbce84869dbf4ce6?lnk=gst# >> http://groups.google.com/group/clojure/browse_thread/thread/78a32eeaacd659e/89304aeec4d00f7d?lnk=gst# >> >> >> >> On Wed, Feb 23, 2011 at 3:19 PM, Paul Richards >> wrote: >>> >>> Hi, >>> Is there a guide to the conventions for naming and structuring >>> namespaces in a Clojure project? >>> >>> I see for example that the ".core" namespace is fairly common in >>> different projects. Is this also where the "-main" entry point should >>> live? >>> >>> Also is it typical to have code living in "someproject" as well as >>> "someproject.tools", or should the former be promoted to >>> "someproject.core"? >>> >>> >>> -- >>> Paul Richards >>> @pauldoo >>> >>> -- >>> You 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 > > > > -- > Paul Richards > @pauldoo > > -- > You 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: noob question: pallet, crane, which criteria to choose which one ?
On Thu, 24 Feb 2011 06:29:13 -0500, Laurent PETIT
wrote:
* deliver to pre-production:
* input = git commit hash, maven version of some "tooling" artifacts
which are java artifacts, invoked via an mvn java execute target once the
right git revision has been checked out
* output = publish the "app state" (created locally from the derived
git
content) to a directory in the server, run a shell script on the server
which finishes the install, and, if everything went well, tag the commit,
and push the tag to the reference repo from which the content had been
initially pulled from
Would trying to use pallet or crane seem overkill ?
Laurent,
Pallet would certainly be capable of automating the workflow you
describe. From what you describe a shell script invoked by an ssh command
could probably do the job too. In pallet it might look something like
this (unchecked):
(def release-dir "/usr/local/myapp")
(defn push-preproduction*
"Crate function to publish a specific commit"
[request tag version artifacts]
(exec-script/exec-checked-script
request
(format "Checkout version %s" version) ; message for logging, etc
(cd src)
(git checkout ~version)
(mvn exec:java something ~@artifacts)
(cp app-state ~release-dir)
(finish-install)
(git tag ~tag)
(git push --tags)))
(def push-production
"Crate function to extract data from the environment,
and publish it"
[request]
(push-preproduction*
request
(environment/get-for request [:userdata :tag])
(environment/get-for request [:userdata :version])
(environment/get-for request [:userdata :artifacts])
;; define phases on a "Server" group, linking the
;; publish phase to the push-production crate function
(def server (make-node "server" {}
:publish push-preproduction))
;; Function to publish a specific version. Uses the node definitions
;; from config.clj
(def publish
[request tag version & artifacts]
(let [service (compute/compute-service-from-config-file :nl)]
(core/lift server
:phase publish
:compute service
:environment {:userdata {:tag tag
:version version
:artifacts artifacts}})
Set up ~/.pallet/config.clj, specifying details of the existing machine,
and that it should be in the "server" group
(defpallet
:providers
{:nl {:provider "node-list"
:node-list [["server" "server" "192.168.2.37"
:ubuntu :os-version "10.04"]]
:environment {:user {:username "user" :no-sudo true)
and invoked via
(publish "tag" "commitish" "artifact1" "artifact2")
Whether pallet is overkill or not, I think, is dependent on whether you
think your requirements will grow. Using this as an exercise to learn
pallet would be time well spent if you think you will want to automate
more in the future.
But, I'm biased.
--
Hugo Duncan
--
You 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: noob question: pallet, crane, which criteria to choose which one ?
Hugo, thanks for the detailed answer, which I'll take the time to analyse
in-depth ASAP.
Indeed, I can envision a day, maybe coming sooner than later, where we'd
like to use cloud services for some clients. Especially those who could
predict activity "peaks" due to their business plans, marketings, etc.
That's why I'm balancing the idea of jumping in something like pallet now,
when we're still not in the rush, or postpone it until the real problem, in
its real shape, occurs.
Cheers,
--
Laurent
2011/2/24 Hugo Duncan
> On Thu, 24 Feb 2011 06:29:13 -0500, Laurent PETIT
> wrote:
>
> * deliver to pre-production:
>> * input = git commit hash, maven version of some "tooling" artifacts
>> which are java artifacts, invoked via an mvn java execute target once the
>> right git revision has been checked out
>> * output = publish the "app state" (created locally from the derived git
>> content) to a directory in the server, run a shell script on the server
>> which finishes the install, and, if everything went well, tag the commit,
>> and push the tag to the reference repo from which the content had been
>> initially pulled from
>>
>
> Would trying to use pallet or crane seem overkill ?
>>
>
> Laurent,
>
> Pallet would certainly be capable of automating the workflow you describe.
> From what you describe a shell script invoked by an ssh command could
> probably do the job too. In pallet it might look something like this
> (unchecked):
>
> (def release-dir "/usr/local/myapp")
>
> (defn push-preproduction*
> "Crate function to publish a specific commit"
> [request tag version artifacts]
> (exec-script/exec-checked-script
>request
>(format "Checkout version %s" version) ; message for logging, etc
>(cd src)
>(git checkout ~version)
>(mvn exec:java something ~@artifacts)
>(cp app-state ~release-dir)
>(finish-install)
>(git tag ~tag)
>(git push --tags)))
>
> (def push-production
> "Crate function to extract data from the environment,
> and publish it"
> [request]
> (push-preproduction*
> request
> (environment/get-for request [:userdata :tag])
> (environment/get-for request [:userdata :version])
> (environment/get-for request [:userdata :artifacts])
>
> ;; define phases on a "Server" group, linking the
> ;; publish phase to the push-production crate function
> (def server (make-node "server" {}
> :publish push-preproduction))
>
> ;; Function to publish a specific version. Uses the node definitions
> ;; from config.clj
> (def publish
> [request tag version & artifacts]
> (let [service (compute/compute-service-from-config-file :nl)]
> (core/lift server
> :phase publish
> :compute service
> :environment {:userdata {:tag tag
> :version version
> :artifacts artifacts}})
>
> Set up ~/.pallet/config.clj, specifying details of the existing machine,
> and that it should be in the "server" group
>
> (defpallet
>:providers
> {:nl {:provider "node-list"
> :node-list [["server" "server" "192.168.2.37"
>:ubuntu :os-version "10.04"]]
> :environment {:user {:username "user" :no-sudo true)
>
> and invoked via
>
> (publish "tag" "commitish" "artifact1" "artifact2")
>
>
> Whether pallet is overkill or not, I think, is dependent on whether you
> think your requirements will grow. Using this as an exercise to learn
> pallet would be time well spent if you think you will want to automate more
> in the future.
>
> But, I'm biased.
>
> --
> Hugo Duncan
>
--
You 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: ElephantDB, a distributed database written in Clojure
We (BackType) recently released our database ElephantDB as open source. I thought that the Clojure community at large would find this project interesting as it's written in Clojure. ElephantDB is a specialized database for exporting key/value data from Hadoop and serving it in a read-only fashion. It has seemless integration with Cascalog through the elephantdb-cascalog project. ElephantDB makes use of Hadoop, Thrift, and BerkeleyDB Java Edition. Writing this database in Clojure was a great experience. The place where Clojure really shined was for writing the unit tests. Clojure's dynamic capabilities made it really easy to do things like mock out remote servers or mock out pieces that weren't deterministic so that they could be tested. There were a few key macros I wrote for testing purposes that made it a lot easier to write and understand the tests. If you'd like to know more about the project, check out our introductory blog post and the GitHub repos. http://tech.backtype.com/introducing-elephantdb-a-distributed-database https://github.com/nathanmarz/elephantdb https://github.com/nathanmarz/elephantdb-cascalog -- You 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: Release.Next Version Number
> Without commenting on the validity of the above at all, I seem to recall that > the > application of the "1.0" version label prompted the same sort of concerns. You're right. No point in commenting on this whole silly thread. -- You 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: noob question: pallet, crane, which criteria to choose which one ?
2011/2/24 Hugo Duncan
> On Thu, 24 Feb 2011 06:29:13 -0500, Laurent PETIT
> wrote:
>
> * deliver to pre-production:
>> * input = git commit hash, maven version of some "tooling" artifacts
>> which are java artifacts, invoked via an mvn java execute target once the
>> right git revision has been checked out
>> * output = publish the "app state" (created locally from the derived git
>> content) to a directory in the server, run a shell script on the server
>> which finishes the install, and, if everything went well, tag the commit,
>> and push the tag to the reference repo from which the content had been
>> initially pulled from
>>
>
> Would trying to use pallet or crane seem overkill ?
>>
>
> Laurent,
>
> Pallet would certainly be capable of automating the workflow you describe.
> From what you describe a shell script invoked by an ssh command could
> probably do the job too. In pallet it might look something like this
> (unchecked):
>
> (def release-dir "/usr/local/myapp")
>
> (defn push-preproduction*
> "Crate function to publish a specific commit"
> [request tag version artifacts]
> (exec-script/exec-checked-script
>request
>(format "Checkout version %s" version) ; message for logging, etc
>(cd src)
>(git checkout ~version)
>(mvn exec:java something ~@artifacts)
>(cp app-state ~release-dir)
>(finish-install)
>(git tag ~tag)
>(git push --tags)))
>
> (def push-production
> "Crate function to extract data from the environment,
> and publish it"
> [request]
> (push-preproduction*
> request
> (environment/get-for request [:userdata :tag])
> (environment/get-for request [:userdata :version])
> (environment/get-for request [:userdata :artifacts])
>
> ;; define phases on a "Server" group, linking the
> ;; publish phase to the push-production crate function
> (def server (make-node "server" {}
> :publish push-preproduction))
>
> ;; Function to publish a specific version. Uses the node definitions
> ;; from config.clj
> (def publish
> [request tag version & artifacts]
> (let [service (compute/compute-service-from-config-file :nl)]
> (core/lift server
> :phase publish
> :compute service
> :environment {:userdata {:tag tag
> :version version
> :artifacts artifacts}})
>
> Set up ~/.pallet/config.clj, specifying details of the existing machine,
> and that it should be in the "server" group
>
> (defpallet
>:providers
> {:nl {:provider "node-list"
> :node-list [["server" "server" "192.168.2.37"
>:ubuntu :os-version "10.04"]]
> :environment {:user {:username "user" :no-sudo true)
>
> and invoked via
>
> (publish "tag" "commitish" "artifact1" "artifact2")
>
>
Wow, I looked at the above scripts, and it seems that you've captured the
essence of the problem quite well!
Given the above starter-code, I think I'll probably give it a try, for sure
!
>
> Whether pallet is overkill or not, I think, is dependent on whether you
> think your requirements will grow. Using this as an exercise to learn
> pallet would be time well spent if you think you will want to automate more
> in the future.
>
> But, I'm biased.
>
> --
> Hugo Duncan
>
--
You 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: java.lang.Exception: transaction rolled back: java.lang.InterruptedException
That didn't solve the problem. I've tried smaller row numbers and it still throws the same error: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.InterruptedException at clojure.lang.LazySeq.sval(LazySeq.java:47) at clojure.lang.LazySeq.seq(LazySeq.java:56) at clojure.lang.Cons.next(Cons.java:39) at clojure.lang.RT.next(RT.java:560) at clojure.core$next.invoke(core.clj:61) On Feb 23, 12:59 pm, Saul Hazledine wrote: > On Feb 23, 9:54 pm, clj123 wrote: > > > I'm getting the following exception trying to insert large batch data > > in the database. > > I'd try to write less data at one time to the database. Start with, > say, 20 rows at a time. > > Saul -- You 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: Release.Next Version Number
On Feb 23, 2011, at 8:36 PM, Ken Wesson wrote: > But "1.3" may overpromise and underdeliver backward compatibility. It depends, I suppose, on whether people who are already using Clojure 1.2 will blindly upgrade to 1.3/2.0 without having read anything that will warn them what to expect. I like semantic versioning myself, but I think considerations are different for peripheral libraries like mine than they are for the foundational core of the whole shebang. - Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Author of /Ring/ (forthcoming; sample: http://exampler.com/tmp/ring.pdf) www.exampler.com, www.exampler.com/blog, www.twitter.com/marick -- You 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: java.lang.Exception: transaction rolled back: java.lang.InterruptedException
On Thu, Feb 24, 2011 at 14:36, clj123 wrote: > That didn't solve the problem. I've tried smaller row numbers and it > still throws the same error: > > java.lang.RuntimeException: java.lang.RuntimeException: > java.lang.RuntimeException: java.lang.InterruptedException >at clojure.lang.LazySeq.sval(LazySeq.java:47) >at clojure.lang.LazySeq.seq(LazySeq.java:56) >at clojure.lang.Cons.next(Cons.java:39) >at clojure.lang.RT.next(RT.java:560) >at clojure.core$next.invoke(core.clj:61) What is the DB saying in its logs? -- You 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
logos on clojars .. workflow for using things that r present only on github but not on clojars..
Hello everybody, I was wondering if there is a reason as to why logos was not put on clojars.. If it was intended to be that way by the author.. what is a good work flow to use some that is available only on github but not on clojars.. A description of the workflow with cake/leiningen would be perfect. Sunil. -- You 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 using the sdb library?
I don't know, but if you introduce breaking changes, you'd better name it version 2.0. -- You 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: logos on clojars .. workflow for using things that r present only on github but not on clojars..
On Thu, Feb 24, 2011 at 5:52 PM, Sunil S Nandihalli < sunil.nandiha...@gmail.com> wrote: > Hello everybody, > I was wondering if there is a reason as to why logos was not put on > clojars.. If it was intended to be that way by the author.. what is a good > work flow to use some that is available only on github but not on clojars.. > A description of the workflow with cake/leiningen would be perfect. > > Sunil. > Don't have anything to say about the best way to use it from git, but it's not on Clojars yet because it doesn't have the feature set required to be useful for everyday use. Before putting it out there for consumption, I'd like it to have: 1) pattern matcher 2) tabling 3) convenient syntax for dealing with facts defined as sets of Clojure data structures. David -- You 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: java.lang.Exception: transaction rolled back: java.lang.InterruptedException
I've also noticed that I can cause this InterruptedException to be thrown if I add (. Thread (sleep 1000)) instead of saving to database. It looks like when a thread is waiting for a long time this exception is being thrown. By the way I'm running only one thread in my code. Here's the rest of my stack trace: java.lang.InterruptedException: sleep interrupted at java.lang.Thread.sleep(Native Method) at my-code$my-method$fn__2822.invoke(my-code.clj:203) at my-code$my-method.invoke(my-code.clj:201) at clojure.lang.Compiler.eval(Compiler.java:5424) at clojure.lang.Compiler.eval(Compiler.java:5391) at clojure.core$eval.invoke(core.clj:2382) at clojure.main$repl$read_eval_print__5624.invoke(main.clj:183) at clojure.main$repl$fn__5629.invoke(main.clj:204) at clojure.main$repl.doInvoke(main.clj:204) at clojure.lang.RestFn.invoke(RestFn.java:702) at clojure.tools.nrepl$handle_request.invoke(nrepl.clj:272) at clojure.lang.Var.invoke(Var.java:373) at clojure.tools.nrepl$message_dispatch $fn__199$fn__202.invoke(nrepl.clj:336) at clojure.lang.AFn.call(AFn.java:18) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) -- You 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 using the sdb library?
I used it as a starting point for an sdb lib a while back, moved that project to GAE though. One note, it uses an outdated version of the AWS java libraries, you should probably update that if you're in there. On Thu, Feb 24, 2011 at 3:36 PM, Chas Emerick wrote: > Is anyone using the sdb (AWS SimpleDB) client library, originally written > by Rich Hickey in 2009, and then tweaked in various ways by a couple of > others since? > > Github repo network here: https://github.com/richhickey/sdb/network > > I ask because I have some ideas for some changes and enhancements to the > library, some of which would be breaking (potentially from both an API and > data format standpoint). It seems like having a dialogue with anyone that > is actively using it would be productive, if only to ensure that I'm not > headed towards the weeds. Beyond that, a collective attempt to coordinate > the direction of the project would be good (rather than simply letting > off-by-one forks of it proliferate on github). > > Cheers, > > - 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 -- You 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 using the sdb library?
On Feb 24, 2011, at 5:58 PM, .Bill Smith wrote: > I don't know, but if you introduce breaking changes, you'd better name it > version 2.0. ;-) It'd actually be nice to establish a stable groupId and artifactId for the project (rather than the constantly-shifting `org.clojars.github-username-here`), which in conjunction with breaking changes, would warrant dropping back to v0.x.y until those changes have proven themselves. - 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: transaction rolled back: java.lang.InterruptedException
I've tried saving a much smaller number of rows and I'm still getting this exception. I also tried processing the rows (without saving to database) and put a Thread sleep. That also generated this exception. On Feb 23, 12:55 pm, Saul Hazledine wrote: > On Feb 23, 9:42 pm, clj123 wrote: > > > I have been getting this exception: > > java.lang.Exception: transaction rolled back: > > java.lang.InterruptedException > > at clojure.contrib.sql.internal$throw_rollback.invoke(internal.clj: > > 142) > > I can only take some wild guesses I'm afraid. The rollback occurs > because clojure.contrib.sql tends to wrap operations in transactions. > It appears that an InteruptedException occured during an operation and > this called the rollback. > > Wild guesses: > 1. The app is trying to write lots of data and a timeout has occured. > 2. The database is busy and a timeout has occured. > > Saul -- You 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: logos on clojars .. workflow for using things that r present only on github but not on clojars..
Thanks David for such a quick response. that would be nice David.. I think we r in for a treat with logos being a better prolog in clojure.. :) > 1) pattern matcher > like matchure?? what exactly would this be? > 2) tabling > I don't know what this means.. r u hinting at memoization? > 3) convenient syntax for dealing with facts defined as sets of Clojure data > structures. > in fact convenient syntax for various basic data structures is one of the key reasons I love clojure so much .. :) > > David > eagerly waiting for your stuff on clojars. I was considering porting some code I had written with Jim Duey mini-kanren implementation. Would I be right in assuming Logos is a superset of his stuff already .. Would I have to watch out for something in particular when do this porting? Sunil > -- > You 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: logos on clojars .. workflow for using things that r present only on github but not on clojars..
On Feb 24, 2:52 pm, Sunil S Nandihalli wrote: > I was wondering if there is a reason as to why logos was not put on > clojars.. If it was intended to be that way by the author.. what is a good > work flow to use some that is available only on github but not on clojars.. > A description of the workflow with cake/leiningen would be perfect. You can set up a private repository using Nexus or Archiva, and then use the lein deploy task to put logos out there. Then add your private repo under :repositories in project.clj of the project with which you want to use logos. This requires Leiningen 1.5 from git and is not thoroughly documented yet. Another alternative would be to deploy it as org.clojars.YOURNAME/ logos on clojars. -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: Clojure namespace conventions
On Feb 24, 2:48 am, Paul Richards wrote: > My goodness.. Seems like a can of worms. :p > > I think I'll pick something at least two levels deep like > "pauldoo.someproject", complete with ".core" and ".tools" as sub > namespaces.. IMO adding ".core" indicates it's a "filler" segment that's only there to get around the fact that you shouldn't have single-segment namespaces. If you've already got two levels, there's no need for a .core segment. -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: logos on clojars .. workflow for using things that r present only on github but not on clojars..
On Thu, Feb 24, 2011 at 6:38 PM, Sunil S Nandihalli < sunil.nandiha...@gmail.com> wrote: > Thanks David for such a quick response. > that would be nice David.. I think we r in for a treat with logos being a > better prolog in clojure.. :) > >> 1) pattern matcher >> > like matchure?? what exactly would this be? > Conceptually similar to matchure but it would create logic vars and perform unification as needed. > 2) tabling >> > I don't know what this means.. r u hinting at memoization? > Memoization generalized for logic programs. You get a few of the benefits of Datalog w/ tabling. > 3) convenient syntax for dealing with facts defined as sets of Clojure data >> structures. >> > in fact convenient syntax for various basic data structures is one of the > key reasons I love clojure so much .. :) > Definitely. > eagerly waiting for your stuff on clojars. I was considering porting some > code I had written with Jim Duey mini-kanren implementation. Would I be > right in assuming Logos is a superset of his stuff already .. Would I have > to watch out for something in particular when do this porting? > Sunil > The differences are minor. * Sequences that end with logic vars are constructed like so: (lcons 1 (lvar 'x)) * You need to replace fresh with exist. * Interleaving search is the default instead of the depth-first search of Prolog. David -- You 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: ElephantDB, a distributed database written in Clojure
How was clojure speed-wise for you? Was it blazingly fast? Just good enough? -r -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
easier exit
Hello all. A bit new to clojure here. Anyway I found it a bit difficult to exit from a REPL. Would a patch to make it give instructions (like Python's C:\>c:\installs\Python26\python.exe >>> exit Use exit() or Ctrl-Z plus Return to exit >>> ) like that have a chance to be accepted? Also is there any way to contribute patches to the clojure website itself? (maybe put it up on github too?) Cheers! -r -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: java.lang.Exception: transaction rolled back: java.lang.InterruptedException
If it is about Thread/sleep, you can perhaps use something like this: (defn sleep [n] (try (Thread/sleep n) (catch InterruptedException e (.interrupt (Thread/currentThread) There might be other situations where the underlying API throws InterruptedException - deal with them accordingly. http://www.ibm.com/developerworks/java/library/j-jtp05236.html HTH Regards, Shantanu On Feb 25, 4:12 am, clj123 wrote: > I've also noticed that I can cause this InterruptedException to be > thrown if I add > > (. Thread (sleep 1000)) instead of saving to database. > > It looks like when a thread is waiting for a long time this exception > is being thrown. By the way I'm running only one thread in my code. > > Here's the rest of my stack trace: > > java.lang.InterruptedException: sleep interrupted > at java.lang.Thread.sleep(Native Method) > at my-code$my-method$fn__2822.invoke(my-code.clj:203) > at my-code$my-method.invoke(my-code.clj:201) > at clojure.lang.Compiler.eval(Compiler.java:5424) > at clojure.lang.Compiler.eval(Compiler.java:5391) > at clojure.core$eval.invoke(core.clj:2382) > at clojure.main$repl$read_eval_print__5624.invoke(main.clj:183) > at clojure.main$repl$fn__5629.invoke(main.clj:204) > at clojure.main$repl.doInvoke(main.clj:204) > at clojure.lang.RestFn.invoke(RestFn.java:702) > at clojure.tools.nrepl$handle_request.invoke(nrepl.clj:272) > at clojure.lang.Var.invoke(Var.java:373) > at clojure.tools.nrepl$message_dispatch > $fn__199$fn__202.invoke(nrepl.clj:336) > at clojure.lang.AFn.call(AFn.java:18) > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) > at java.util.concurrent.FutureTask.run(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown > Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) -- You 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: Transforming map entries
I have a couple utility functions I use a lot for creating maps from
sequences and transforming one map to another. These are (poorly)
named mapmap and mapmapmap. (Yes I know the names are awful but I
have lived with them long enough that they've stuck.)
mapmap takes a key production function (optional - uses identity by
default), a value production function, and a source sequence.
(def c (range 5))
(mapmap #(+ 1 %) #(* 2 %) c)
-> {5 8, 4 6, 3 4, 2 2, 1 0}
More here:
http://tech.puredanger.com/2010/09/24/meet-my-little-friend-mapmap/
mapmapmap is similar but takes a map, not a sequence. It applies the
key function to transform the keys and the value function to transform
the values. So your request would be:
(mapmapmap #(if (string? %) (upper-case %) %) mymap)
Here's a gist with the definition of both:
https://gist.github.com/843292
Hope you find it useful...
Alex
On Feb 21, 9:08 pm, yair wrote:
> I'm hoping this is a dumb question and I've missed something obvious.
> I have a map with various key-value pairs and I want to transform some
> of the values, e.g.
>
> (def mymap {:first "john" :last "smith" :age 25}) and say I want to
> change the strings to be upper case.
> Right now all I can think of doing is using reduce and passing in an
> empty map and the re-associating each key with the (possibly)
> transformed value. Is there something like the map function that
> takes two parameters, one a function that receives a pair and returns
> a new pair, and the other a map, and returns a map that's
> reconstituted from those pairs?
>
> 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: ANN: ElephantDB, a distributed database written in Clojure
Clojure's not even close to being a bottleneck in this database. The performance is limited by the underlying storage engine which is currently Berkeley DB Java Edition. On Feb 24, 4:21 pm, rogerdpack wrote: > How was clojure speed-wise for you? Was it blazingly fast? Just good > enough? > -r -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 namespace conventions
2011/2/25 Phil Hagelberg > On Feb 24, 2:48 am, Paul Richards wrote: > > My goodness.. Seems like a can of worms. :p > > > > I think I'll pick something at least two levels deep like > > "pauldoo.someproject", complete with ".core" and ".tools" as sub > > namespaces.. > > IMO adding ".core" indicates it's a "filler" segment that's only there > to get around the fact that you shouldn't have single-segment > namespaces. If you've already got two levels, there's no need for > a .core segment. > One element to take into consideration : if you want your library to sometimes play well with e.g. OSGi, it would be better to have all of it into its own java package, since OSGi places "visibility directives" at the package level. Indeed, imagine that in the future you have created 2 useful libraries : pauldoo.project1, and pauldoo.project2. If both are independently released in their artifact (which would also happen to be OSGi bundle), there are 2 possibilities : if pauldoo.project1 is a namespace, and pauldoo.project2 is a namespace, then both artifacts will have content in the package pauldoo, and thus both artifacts will be seen by OSGi as (potentially) "exporting" the package pauldoo. I'm not an OSGi expert, but this may or may not be embarrassing. To the contrary, if you take care of having each library to not share content in a same package, eg. pauldoo.project1.core et al, then their (potential) export directive will not conflict with each other. Cheers, -- Laurent -- You 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
