Re: suggestion for clojure development
On 10/02/2011 01:05 AM, Sean Corfield wrote:
Actually I think you're in a better position now. The
"new contrib"
libraries are all actively maintained and are expected to be
compatible with both Clojure 1.2.x and 1.3.0. I'm also hearing a
possibility that a "ready-to-go" download of updated contrib
libraries
will be provided. That seems to address both of your concerns.
You're right, it sounds in line with my hopes!
Would it be possible to think of a better name for this sister
project than "new contrib"? Something that implies its tight
relationship with Clojure? I suggest "Clojure Core". It would then
be nice to have, perhaps, a less-well-maintained "Clojure Extras"
that would be made available for easy use, but without the more
stringent guarantees of Core. A library might live in "Clojure
Extras" for a while before becoming important enough and achieving
the quality standards for moving to Core.
So, perhaps a few of us were overreacting to the changes, or the
changes were not communicated clearly, or UFOs garbled the
transmissions. By the way, the new dev.clojure.org site looks
terrific, and is a few orders of magnitude better than the
clojure.org site. I can actually get a sense of what's happening in
Clojure without joining the Google Group. It's informative. On the
other hand, going to clojure.org, I simply see a download link to
the new Clojure 1.3.0, with no information on these organizational
changes. It's an old complaint, I know, but clojure.org is ... not
the most useful web site on the Internet. The UFOs seem to love it,
though.
But it can be solved by adding ^{:dynamic true} which makes it
compatible with both Clojure 1.2.x and 1.3.0. That's how 3rd party
libraries are solving this problem and being compatible with both
versions.
True, but the default behavior was changed to "dynamic false"
meaning the libraries *must* be refactored for 1.3.0 in order to
even run properly there, which I think was an unfortunate decision.
Again, as Arthur suggested, I would have preferred a per-namespace
or per-library flag saying "language version 1.3.0" which would have
set the default Var behavior to "dynamic false". Unmarked namespaces
would have fallen back to the pre-1.3 default of "dynamic true", and
a large pain point would have been avoided. Users would have been
able to migrate code one namespace at a time, if at all.
Water under the bridge at this point, except for when we get to the
next bridge. I hope the points raised in this discussion will be
taken under consideration.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Equality comparison in 1.3
On Sat, Oct 1, 2011 at 9:52 PM, Daniel wrote: > user=> (= 23.0 23) > false With every language I've ever worked in, I've always been told that comparing floating point numbers for equality is a bad idea so I'm actually glad to see that the above comparison is false... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: suggestion for clojure development
On Sat, Oct 1, 2011 at 10:16 PM, Tal Liron wrote:
> And the issue for me now is concern about what will happen to all
> these contribs in the future if a core language feature changes, such as the
> dynamic Var issue in 1.3. If these contribs are not being built and shipped
> as part of Clojure, it seems risky to rely on them. Some might get upgraded,
> others might languish. What's lacking is any kind of statement of
> commitment. Instead, if I understand it correctly, we see the core Clojure
> project moving back from a commitment model to a more community-management
> model.
Actually I think you're in a better position now. The "new contrib"
libraries are all actively maintained and are expected to be
compatible with both Clojure 1.2.x and 1.3.0. I'm also hearing a
possibility that a "ready-to-go" download of updated contrib libraries
will be provided. That seems to address both of your concerns.
> I'm not necessarily arguing for a move back to the monolith that existed up
> to Clojure 1.2, but for a standard lib *distribution* with a test suite and
> a Clojure stamp of approval.
That's pretty much what "new contrib" is: they have active
maintainers, they have automated builds - with matrix tests against
Clojure 1.2.0, 1.2.1 and 1.3.0 on a variety of JDKs - they have
specific JIRA projects for logging bugs and requesting enhancements,
they have a documented process for maintenance. To become a "new
contrib" library, the project actually does need some level of
Clojure/core approval and involvement.
> example, the new dynamic Var breakage in Clojure could have been solved with
> an optional switch per namespace, requiring explicit enabling for now, and
But it can be solved by adding ^{:dynamic true} which makes it
compatible with both Clojure 1.2.x and 1.3.0. That's how 3rd party
libraries are solving this problem and being compatible with both
versions.
> will try to find time to go back to some of my old code, gather the
> workarounds I found for bugs -- a few in the JSON and in SQL-now-called-JDBC
> contribs -- and find a way to turn them into patches.
That would be cool - thank you. Have a read over the
http://clojure.org/contributing guidelines and the
http://clojure.org/patches process.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Problems logging reliably
Sorry, posted the wrong data describing the problem. Here it is. https://gist.github.com/1257122 On Oct 2, 12:39 am, Daniel wrote: > This might be an issue with my log4j properties file, Cake, or > tools.logging, Here's my log4j.properties file: > https://gist.github.com/1257086 > > It should back up the current log file into an old, dated version at > midnight, and use a new, undated log file. Instead it appears to halt > program execution without giving me any error output so long as the > test has already ran. https://gist.github.com/1257100 > > That's one problem. The other problem is that it's not rolling. > > Code:https://gist.github.com/1257108 -- You 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
[tools.logging] Problems logging reliably
This might be an issue with my log4j properties file, Cake, or tools.logging, Here's my log4j.properties file: https://gist.github.com/1257086 It should back up the current log file into an old, dated version at midnight, and use a new, undated log file. Instead it appears to halt program execution without giving me any error output so long as the test has already ran. https://gist.github.com/1257100 That's one problem. The other problem is that it's not rolling. Code: https://gist.github.com/1257108 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: suggestion for clojure development
On 10/01/2011 11:49 PM, Sean Corfield wrote: I'm curious, what parts of contrib are you relying on that haven't found active maintainers? Perhaps we can figure out how to address that, to reduce your pain? It's not that they weren't maintained. Well, I actually don't know which was maintained and which wasn't, I'm mostly relying on the information on the mailing list, and also on your handy page, which mentions partial migration of some contribs: http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go The issue for me (in the past) was quality, not whether they were maintained or not. And the issue for me now is concern about what will happen to all these contribs in the future if a core language feature changes, such as the dynamic Var issue in 1.3. If these contribs are not being built and shipped as part of Clojure, it seems risky to rely on them. Some might get upgraded, others might languish. What's lacking is any kind of statement of commitment. Instead, if I understand it correctly, we see the core Clojure project moving back from a commitment model to a more community-management model. You know, it doesn't have to be that contribs would be shipped with Clojure core. There could be an essential "standard library", a selection of important contribs that is maintained as a sister project to Clojure. So, I'm not necessarily arguing for a move back to the monolith that existed up to Clojure 1.2, but for a standard lib *distribution* with a test suite and a Clojure stamp of approval. That way, when a new version of Clojure comes out, I can take a look and see if standard lib is up to date with all the libraries I use, and maybe point-check the other libs that are not in the standard. As it stands right now, I have to point check every single library -- as well as its trail of dependencies -- in order to evaluate the cost of migration. It's worth taking a look at the how migration has happens in the Python world. Python 3.0 indeed represented a major break, but then there's "from __future__ import" that has existed for a while in the 2.0 branch (*which is still being actively being maintained even though 3.0 has been around for a while*) allowing for old 2.X code to slowly migrate to 3.0 futures. For example, the new dynamic Var breakage in Clojure could have been solved with an optional switch per namespace, requiring explicit enabling for now, and thus allowing legacy code (for example, from contribs!) to continue working for a few more versions in deprecated mode instead of being just borked. (Note: I'm realizing now that I'm sounding whiny about the quality issue. I will try to find time to go back to some of my old code, gather the workarounds I found for bugs -- a few in the JSON and in SQL-now-called-JDBC contribs -- and find a way to turn them into patches. Part of the problem is that my work is not always in an open source environment, so getting approval to extract these things ends up more time-consuming than the dev work.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Help/Example needed for using Cake's Context feature
Resolved in the Cake forum. Apparently 'cake test' implies use of the
'test' context, so you can layer specific details onto it with
defcontext with no problems.
Excellent way, by the way, to test projects with different
datasources. I seem to recall somebody else having problems with this
issue and midje being suggested.
Aside from midje not yet supporting 1.3, I think this is a better
solution. Just my 0.02.
On Oct 1, 2:17 pm, Daniel wrote:
> https://github.com/flatland/cake/wiki/Contexts
>
> I can't get 'cake test @testing' to work. Here's a really simple
> example
>
> https://gist.github.com/1256509
>
> cake repl @testing works just fine though
>
> $ cake repl @testing
> user=> cake/*project*
> {:dependencies {clojure {:version "1.3.0"}, org.neo4j/neo4j {:version
> "1.5.M01"}, borneo {:version "0.3.0"}, midje {:version "1.3-
> alpha2"}}, :db-path "playground", :group-id "neo4j-
> playground", :context testing, :dev-dependencies {vimclojure/server
> {:version "2.2.0"}}, :name "neo4j-playground", :bake true, :version
> "0.0.1-SNAPSHOT", :ext-dependencies {}, :aot nil, :war-name "neo4j-
> playground-0.0.1-SNAPSHOT", :artifact-id "neo4j-playground", :uberjar-
> name "neo4j-playground-0.0.1-SNAPSHOT-standalone", :description "TODO:
> add summary of your project", :jar-name "neo4j-playground-0.0.1-
> SNAPSHOT"}
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Equality comparison in 1.3
user=> (= 23.0 23)
false
user=> (= 23 23)
true
"compares numbers and collections in a type-independent manner"
This kind of breakage was probably to be expected with the numerics
changes in 1.3. I am also interested in this.
On Oct 1, 4:34 pm, Chris Perkins wrote:
> I am trying to upgrade some code to 1.3, and I'm not sure how to do the
> equivalent of a 1.2-style equality comparison.
>
> user> (= {:foo 23} {:foo 23.0})
> false
>
> This used to be true. I see that = is now documented to compare same-type
> numbers only, but == can be used for 1.2-compatible comparisons. However:
>
> user> (== {:foo 23} {:foo 23.0})
> ; Evaluation aborted.
>
> == only seems to work on numbers.
>
> How can I upgrade code that expects 1.2-compatible equality comparisons? Or
> do I need to change my expectations of what is considered equal in clojure?
>
> - Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: suggestion for clojure development
On Sat, Oct 1, 2011 at 8:10 PM, Tal Liron wrote: > I did realize pretty early on that the contribs were not all of prime > quality, but what other choice did I have? Fall back to standard JVM API? I'm curious, what parts of contrib are you relying on that haven't found active maintainers? Perhaps we can figure out how to address that, to reduce your pain? > What I would want to see is a coherent standard library that is centrally > maintained. Not everything deserves to be there, of course, but there are > obvious candidates for essentials. I think it's worth discussing what's "essential" in contrib. If there are unmaintained modules that folks think are essential, let's figure out how to get those maintained again and moved into new contrib. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[Clojuresphere] How do I filter out past dependents?
Say I want to get a full list of _current_ dependents for clojure-1.2 or contrib, for upgrade purposes ... is there currently a way to do that on Clojuresphere? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: suggestion for clojure development
Let's talk about another context here, we have been in prod since Jan. 2009. With a pre V1.0 version of Clojure and we used contrib in the state it was in these early days. Staying away from contrib in production was never a concern to us. We just made the commitment to live with it and wait for it to evolve. Following upgrades was something we expected. We had to make a choice in 2008, laying down 60,000+ of java code or 10 times less in Clojure. We now have over 14,000 lines of Clojure code. We went through two upgrades, 1.0, 1.2 still carrying contrib as it matured. Upgrades never involved a significant effort. Most of this was carried on with the normal dev. flow. Once the new contrib split is in place and stabilized, we expect to spend at most 30 man days to upgrade to it and 1.3, testing included. I cannot state any louder the economy of time of using Clojure vs Java, even Ruby (which was considered before crossing Clojure's path). This encompasses writing new code, getting it prod and living to incremental changes (java 5, 6 and now 7 around the corner). The new modular contribs are tested against 1.2, 1.2.1 and 1.3. Once that bridge is crossed in our code, we do not expect more pain in the future than we are "experimenting" now. The notion of pain seems very relative after reading this thread. Given the pace at which other languages evolve, I can understand that the upgrade path seems abrupt but you have to compare apples with apples. Having a huge pile of non expressive code with very small incremental changes looks reassuring but it's not a way to leapfrog the competition. On the other hand, having ten times less code means you can live with a more steep upgrade path and do more in less time. Choose your hell/paradise accordingly :) Luc P. On Sat, 1 Oct 2011 20:10:47 -0700 (PDT) Tal Liron wrote: > On Saturday, October 1, 2011 9:34:46 PM UTC-5, David Nolen wrote: > > > > To give some context: > > > > I appreciate the context, David, and I agree that the change needed > to happen. It's likely my fault for not being enough in the loop to > realize what the 1.3 change would mean for me. I expected some > breakage, but I think I was taken by surprise by how far-reaching it > was. > > The fact that such important changes needed to happen underscores my > point -- which I doubt anybody would disagree with -- about the > maturity of the project. I'm sorry if this offends the people who > have worked hard to get 1.3 to where it is -- I appreciate all the > effort, which is in the right direction. But, somebody has to be that > nagging voice of legacy, so I'll let it be me and Arthur. :) Almost > no thought at all was given to legacy: the most I saw was a few tips > on migrating in the changelog. (Again, could be my fault for not > looking hard enough.) > > I did realize pretty early on that the contribs were not all of prime > quality, but what other choice did I have? Fall back to standard JVM > API? I did do that in some occasions, but it's awkward. Patch the > contribs? I just didn't have the time (nor patience) to reinvent such > essential wheels. (I almost did submit a patch for contrib.json... > it's somewhere on my todo list from a year ago...) Again, the fact > that Clojure didn't and still doesn't have a good standard library > (beyond the rock-solid foundation of the JVM) with a full test suite > is a sign of the vast amount of work Clojure still has ahead in order > to become as widely adopted as it deserves. > > Stu's comment actually worries me in this respect: the fact that each > contrib has its own version may make it easier to evaluate them > separately, but it would appear to me as a defeatist goal for Clojure > moving forward. What I would want to see is a coherent standard > library that is centrally maintained. Not everything deserves to be > there, of course, but there are obvious candidates for essentials. > Contrarily, it seems that effort is being put into cleaning up the > core and jettisoning anything merely suspected of being superfluous. > So, what's going to happen to all that stuff outside? Will it be > maintained by "the community"? The same "community" that made the 1.2 > contrib? Or maybe Clojure 1.5 will bring some of them into the fold? > (I'm not being sarcastic; these are honest questions about the > possibilities and vision.) > > Being a hardcore JVMer, I am used to APIs in java.* and javax.* > namespaces as a sign of how close to the center and dependable they > are. Could something like that be feasible for the Clojure project? > > Someone on this thread mentioned that it's all as expected, and that > Clojure is just for a bunch of geeks, anyway, so breakage is no big > deal (I'm paraphrasing). I hope for a strong official position > against that: many of us believe Clojure should not be a niche > language. It's the first Lisp in decades with broad practical > potential and could pave the way for Clojure or other Lisps in more
Re: suggestion for clojure development
On Saturday, October 1, 2011 9:34:46 PM UTC-5, David Nolen wrote: > > To give some context: > I appreciate the context, David, and I agree that the change needed to happen. It's likely my fault for not being enough in the loop to realize what the 1.3 change would mean for me. I expected some breakage, but I think I was taken by surprise by how far-reaching it was. The fact that such important changes needed to happen underscores my point -- which I doubt anybody would disagree with -- about the maturity of the project. I'm sorry if this offends the people who have worked hard to get 1.3 to where it is -- I appreciate all the effort, which is in the right direction. But, somebody has to be that nagging voice of legacy, so I'll let it be me and Arthur. :) Almost no thought at all was given to legacy: the most I saw was a few tips on migrating in the changelog. (Again, could be my fault for not looking hard enough.) I did realize pretty early on that the contribs were not all of prime quality, but what other choice did I have? Fall back to standard JVM API? I did do that in some occasions, but it's awkward. Patch the contribs? I just didn't have the time (nor patience) to reinvent such essential wheels. (I almost did submit a patch for contrib.json... it's somewhere on my todo list from a year ago...) Again, the fact that Clojure didn't and still doesn't have a good standard library (beyond the rock-solid foundation of the JVM) with a full test suite is a sign of the vast amount of work Clojure still has ahead in order to become as widely adopted as it deserves. Stu's comment actually worries me in this respect: the fact that each contrib has its own version may make it easier to evaluate them separately, but it would appear to me as a defeatist goal for Clojure moving forward. What I would want to see is a coherent standard library that is centrally maintained. Not everything deserves to be there, of course, but there are obvious candidates for essentials. Contrarily, it seems that effort is being put into cleaning up the core and jettisoning anything merely suspected of being superfluous. So, what's going to happen to all that stuff outside? Will it be maintained by "the community"? The same "community" that made the 1.2 contrib? Or maybe Clojure 1.5 will bring some of them into the fold? (I'm not being sarcastic; these are honest questions about the possibilities and vision.) Being a hardcore JVMer, I am used to APIs in java.* and javax.* namespaces as a sign of how close to the center and dependable they are. Could something like that be feasible for the Clojure project? Someone on this thread mentioned that it's all as expected, and that Clojure is just for a bunch of geeks, anyway, so breakage is no big deal (I'm paraphrasing). I hope for a strong official position against that: many of us believe Clojure should not be a niche language. It's the first Lisp in decades with broad practical potential and could pave the way for Clojure or other Lisps in more specific niches. The stakes are high: if Clojure is widely adopted and trusted, the quality of software everywhere and for everyone will improve. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: suggestion for clojure development
On Sat, Oct 1, 2011 at 9:49 PM, Tal Liron wrote: > On Saturday, October 1, 2011 8:25:21 PM UTC-5, Andy Fingerhut wrote: >> >> Tal, did you consider the possibility of staying with Clojure 1.2.1 and >> its libraries? Or was that not under consideration for some reason? >> > > It was a consideration, but the cons seemed to outweigh the pros. > > Staying with 1.2 meant not only staying with the Clojure core, which worked > fine, but also losing any progress on any of the contribs, which was frankly > more important to me than core language changes. Perhaps part of the really > big issue here is not Clojure per se, but the contribs. In one fell swoop, > the entire contrib universe for 1.2 was being deprecated. I saw no > commitment anywhere that bug fixes would be backported to the 1.2 contrib > library. (I'm not making a principled stand here: the clojure contrib > library as of 1.2 was very spotty in quality, and required many workarounds > for bugs in my code. I very much look forward to fixes there.) > To give some context: Contrib is not nor ever was a standard library. It was never maintained by the core team beyond providing the jar. It was simply a way to encourage community involvement in a young language. Given the near total lack of maintenance / improvement activity on any library packaged in monolithic Contrib in over a *year* is a big adoption warning signal. People involved in Clojure from the early days I think knew to stay clear of it for production code. It's unfortunate that you and Arthur have had to learn this the hard way catching Clojure at a transition. But the new system makes making an informed judgement about adopting a particular contrib library easier (separate activity, not tied to core release cycle, JIRA, etc). A PITA but Clojure adoption continues to grow quickly regardless of the opinions of various pundits and this change needs to happen now not later in order to scale community contributions w/o bogging down the activities of core. 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: suggestion for clojure development
> Staying with 1.2 meant not only staying with the Clojure core, which worked > fine, but also losing any progress on any of the contribs, which was frankly > more important to me than core language changes. Perhaps part of the really > big issue here is not Clojure per se, but the contribs. In one fell swoop, > the entire contrib universe for 1.2 was being deprecated. I saw no commitment > anywhere that bug fixes would be backported to the 1.2 contrib library. (I'm > not making a principled stand here: the clojure contrib library as of 1.2 was > very spotty in quality, and required many workarounds for bugs in my code. I > very much look forward to fixes there.) Agreed, this is really all about the contribs. And now that they are independently versioned, there should never be a big bump like the move to 1.3 again. Stu -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: suggestion for clojure development
On Saturday, October 1, 2011 8:25:21 PM UTC-5, Andy Fingerhut wrote: > > Tal, did you consider the possibility of staying with Clojure 1.2.1 and its > libraries? Or was that not under consideration for some reason? > It was a consideration, but the cons seemed to outweigh the pros. Staying with 1.2 meant not only staying with the Clojure core, which worked fine, but also losing any progress on any of the contribs, which was frankly more important to me than core language changes. Perhaps part of the really big issue here is not Clojure per se, but the contribs. In one fell swoop, the entire contrib universe for 1.2 was being deprecated. I saw no commitment anywhere that bug fixes would be backported to the 1.2 contrib library. (I'm not making a principled stand here: the clojure contrib library as of 1.2 was very spotty in quality, and required many workarounds for bugs in my code. I very much look forward to fixes there.) I should also mention that I'm a maintainer of two open source projects in the Clojure ecosystem. As such, I had some responsibility to keep them up to date with 1.3. It's been a bumpy ride there, too, but I knew what I was signing up for. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: suggestion for clojure development
Tal, did you consider the possibility of staying with Clojure 1.2.1 and its libraries? Or was that not under consideration for some reason? Andy On Sat, Oct 1, 2011 at 6:03 PM, Tal Liron wrote: > On Tuesday, September 27, 2011 1:57:03 PM UTC-5, Arthur Edelstein wrote: >> >> So my request for Clojure's future development, is that backwards >> compatibility not be broken. This means that Clojure code needs a way >> of designating what Clojure version it is targeted for. >> > > I'm with you, Arthur. Beyond the work that 1.3.0 has caused in the > immediate sense (about a week of my labor) it has affected my ability to > invest in Clojure. I pay my rent as a consultant, and I cannot in full > consciousness advise clients that Clojure is a good idea right now for > long-term projects. Who knows what breakage 1.4.0 will bring? The thought > really makes me pause. > > Carrying around a legacy is obviously very painful for project maintainers, > but doing so responsibly is a sign of project maturity. Clojure is not quite > there. At this point, for many potential users l can only advise that they > keep an eye on Clojure and wait and see, and for now choose more dependable > platforms. Obviously, I represent only a certain segment of Clojure users. > Others do not care as much about long-term investment. I'm afraid, though, > that my segment wasn't heard at all in this case in the march to improve the > language. > > A related point: the amount of breakage that 1.3.0 has caused -- > particularly the rearranging of the entire contrib universe -- would have > warranted, in my opinion, a "2.0" designation for the release. The "0" after > the "2" tells people that this is a fresh start, and is not intended to be > mature. The wary would then know to wait until a "2.1" before migrating. > > -- > You 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: suggestion for clojure development
On Tuesday, September 27, 2011 1:57:03 PM UTC-5, Arthur Edelstein wrote: > > So my request for Clojure's future development, is that backwards > compatibility not be broken. This means that Clojure code needs a way > of designating what Clojure version it is targeted for. > I'm with you, Arthur. Beyond the work that 1.3.0 has caused in the immediate sense (about a week of my labor) it has affected my ability to invest in Clojure. I pay my rent as a consultant, and I cannot in full consciousness advise clients that Clojure is a good idea right now for long-term projects. Who knows what breakage 1.4.0 will bring? The thought really makes me pause. Carrying around a legacy is obviously very painful for project maintainers, but doing so responsibly is a sign of project maturity. Clojure is not quite there. At this point, for many potential users l can only advise that they keep an eye on Clojure and wait and see, and for now choose more dependable platforms. Obviously, I represent only a certain segment of Clojure users. Others do not care as much about long-term investment. I'm afraid, though, that my segment wasn't heard at all in this case in the march to improve the language. A related point: the amount of breakage that 1.3.0 has caused -- particularly the rearranging of the entire contrib universe -- would have warranted, in my opinion, a "2.0" designation for the release. The "0" after the "2" tells people that this is a fresh start, and is not intended to be mature. The wary would then know to wait until a "2.1" before migrating. -- You 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
Leiningen Local Repositories
Hi,
I run Artifactory as a local repository manager. Currently, I am adding
:omit-default-repositories true
:repositories {"releases" "http://artifactory/artifactory/libs-release";
"snapshots"
"http://artifactory/artifactory/libs-snapshot";
"local-release"
"http://artifactory/artifactory/libs-release-local"}
To all my project.clj files.
Does anyone know if you can add this as a default for lein? If so, how?
Thanks
Dave
--
You 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
Equality comparison in 1.3
I am trying to upgrade some code to 1.3, and I'm not sure how to do the
equivalent of a 1.2-style equality comparison.
user> (= {:foo 23} {:foo 23.0})
false
This used to be true. I see that = is now documented to compare same-type
numbers only, but == can be used for 1.2-compatible comparisons. However:
user> (== {:foo 23} {:foo 23.0})
; Evaluation aborted.
== only seems to work on numbers.
How can I upgrade code that expects 1.2-compatible equality comparisons? Or
do I need to change my expectations of what is considered equal in clojure?
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Help/Example needed for using Cake's Context feature
https://github.com/flatland/cake/wiki/Contexts
I can't get 'cake test @testing' to work. Here's a really simple
example
https://gist.github.com/1256509
cake repl @testing works just fine though
$ cake repl @testing
user=> cake/*project*
{:dependencies {clojure {:version "1.3.0"}, org.neo4j/neo4j {:version
"1.5.M01"}, borneo {:version "0.3.0"}, midje {:version "1.3-
alpha2"}}, :db-path "playground", :group-id "neo4j-
playground", :context testing, :dev-dependencies {vimclojure/server
{:version "2.2.0"}}, :name "neo4j-playground", :bake true, :version
"0.0.1-SNAPSHOT", :ext-dependencies {}, :aot nil, :war-name "neo4j-
playground-0.0.1-SNAPSHOT", :artifact-id "neo4j-playground", :uberjar-
name "neo4j-playground-0.0.1-SNAPSHOT-standalone", :description "TODO:
add summary of your project", :jar-name "neo4j-playground-0.0.1-
SNAPSHOT"}
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Problem Running ClojureScript on OpenJDK
There's a good chance ClojureScript will be using a newer version of Rhino - which will address this problem. Should get rolled into master in the next few days.Thanks for your patience! David On Sat, Oct 1, 2011 at 11:23 AM, Volker Schlecht wrote: > Has anyone succeeded in solving this issue for OpenJDK yet? > So far all solutions I've seen discussed boiled down to using Oracle's > JDK ... > > On Aug 14, 6:44 pm, Tzach wrote: > > I have a similar problem, but I could not solve it like you did: > > running on Ubuntu 11.04, > > $JAVA_HOME set to /usr/lib/jvm/default-java, and default-java soft > > link to java-6-sun > > > > Still when I run script/repl, and > > (require '[cljs.compiler :as comp]) > > (def jse (comp/repl-env)) > > (comp/repl jse) > > CompilerException java.lang.RuntimeException: > > java.lang.ClassNotFoundException: > > sun.org.mozilla.javascript.internal.Context, compiling:(cljs/ > > compiler.clj:971) > > user=> CompilerException java.lang.RuntimeException: No such > > namespace: comp, compiling:(NO_SOURCE_PATH:2) > > user=> CompilerException java.lang.RuntimeException: No such > > namespace: comp, compiling:(NO_SOURCE_PATH:3) > > > > Any idea? > > > > Thanks > > Tzach > > > > On Jul 23, 9:38 am, Sean Corfield wrote: > > > > > > > > > > > > > > > > > On Fri, Jul 22, 2011 at 7:34 PM, Sean Corfield > wrote: > > > > I may just switch to the Sun, er, Oracle JVM since I've a feeling one > > > > of my other projects (not yet migrated to my netbook) will require > > > > that JVM anyway... > > > > > Just an update: I installed Oracle'sJDKand everything is working > > > perfectly on myUbuntunetbook :) > > > -- > > > Sean A Corfield -- (904) 302-SEAN > > > An Architect's View --http://corfield.org/ > > > World Singles, LLC. --http://worldsingles.com/ > > > Railo Technologies, Inc. --http://www.getrailo.com/ > > > > > "Perfection is the enemy of the good." > > > -- Gustave Flaubert, French realist novelist (1821-1880) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Problem Running ClojureScript on OpenJDK
Has anyone succeeded in solving this issue for OpenJDK yet? So far all solutions I've seen discussed boiled down to using Oracle's JDK ... On Aug 14, 6:44 pm, Tzach wrote: > I have a similar problem, but I could not solve it like you did: > running on Ubuntu 11.04, > $JAVA_HOME set to /usr/lib/jvm/default-java, and default-java soft > link to java-6-sun > > Still when I run script/repl, and > (require '[cljs.compiler :as comp]) > (def jse (comp/repl-env)) > (comp/repl jse) > CompilerException java.lang.RuntimeException: > java.lang.ClassNotFoundException: > sun.org.mozilla.javascript.internal.Context, compiling:(cljs/ > compiler.clj:971) > user=> CompilerException java.lang.RuntimeException: No such > namespace: comp, compiling:(NO_SOURCE_PATH:2) > user=> CompilerException java.lang.RuntimeException: No such > namespace: comp, compiling:(NO_SOURCE_PATH:3) > > Any idea? > > Thanks > Tzach > > On Jul 23, 9:38 am, Sean Corfield wrote: > > > > > > > > > On Fri, Jul 22, 2011 at 7:34 PM, Sean Corfield > > wrote: > > > I may just switch to the Sun, er, Oracle JVM since I've a feeling one > > > of my other projects (not yet migrated to my netbook) will require > > > that JVM anyway... > > > Just an update: I installed Oracle'sJDKand everything is working > > perfectly on myUbuntunetbook :) > > -- > > Sean A Corfield -- (904) 302-SEAN > > An Architect's View --http://corfield.org/ > > World Singles, LLC. --http://worldsingles.com/ > > Railo Technologies, Inc. --http://www.getrailo.com/ > > > "Perfection is the enemy of the good." > > -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: metadata for records
Razvan Rotaru wrote:
> Is there a way to attach metadata to defrecord ?
Is this what you are looking for?
(defrecord MyRecord [a b])
(let [r (with-meta (MyRecord. 1 2) {:extra 100})]
(meta r))
;;-> {:extra 100}
-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
metadata for records
Hi, Is there a way to attach metadata to defrecord ? Razvan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: strangeloop presentations
On Fri, Sep 30, 2011 at 6:17 PM, Alex Miller wrote: > Yes, we are working on getting them published. Rich Hickey's keynote > is in the first batch and has already been edited, just waiting to be > synced to slides and scheduled at InfoQ. You know that you should have saved the best to last and made everyone wait for that one? :) > - Zach Tellman - Event-Driven Programming in Clojure > - Nate Young - Parser Combinators: How to Parse (nearly) Anything > - Nathan Marz - Storm: Twitter's scalable realtime computation system All three were great presentations! -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
