Re: Contribs with dependencies
On 15.04.2009, at 23:44, rzeze...@gmail.com wrote: That aside, I agree Contrib is a sandbox, but how big of a sandbox is it? That's the question I pose. I think it's irrational to put every Clojure library/framework that comes along into Contrib, because it becomes a Tower of Babel and ultimately fails. If someone wants to Right. The sandbox approach was useful and sufficient in the early period of Clojure development, with an evolving language and few contributed libraries. In the long run, the sandbox may remain useful, but certainly not sufficient. publish a Clojure library, then it's simple enough to post it up on GitHub, or what have you, and send a link to the Google group. That is true, but having to download a dozen of libraries from various sites with somewhat different conventions and somewhat different installation procedures can be very discouraging for users. Along with the Core incubator idea, I could also picture Contrib as something similar to Haskell with Batteries. A top selection of user contributed libraries that add major value to the core. I feel duck- streams is one such example. Indeed. At the moment, clojure-contrib is part incubator, but much more importantly the starting point of what I would call the Clojure standard library, in the sense of containing functionality of general interest but yet too domain-specific to be part of the core. I think it would be useful to formalize this concept of a standard library that is a single entity from the point of view of users who just want to download a jar file and get going. A standard library would also define certain conventions and APIs and thus prevent future users from having to choose among ten essentially equivalent but yet incompatible libraries for file handling or for XML parsing. Of course there are a couple of open questions: Who decides what goes into the standard library? Who maintains it in the long run? Are external dependencies allowed and if yes, how are they handled? I think the only reasonable answer to the first two questions is a group of competent volunteers, which then raises the question of how that group is defined. Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure production ready?
If you have to ask if a technology is production ready then it isn't. On Apr 15, 10:34 pm, Aaron Feng aaron.f...@gmail.com wrote: Hi, I work for a large financial software company, and we are interested in using Clojure for our new project. Due to the concurrent nature of the project, we are evaluating three possible languages: Erlang, Scala, and Clojure. This project will be a hosted solution, but availability and performance is very important to us. We want to deploy the project within 6 to 12 months, but the project will continue to build out the rest of the functionality for the next 2 to 4 years. We guesstimate that it will receive around 1M hits daily initially, and it will continue to grow on a monthly basis. Due to the nature of the project, I'm only allowed to give high level overview of the project at this time. We have a bias toward Scala and Clojure because they run on top of JVM. The richness of existing 3rd party and open source libraries are also attractive for us. The fundamental question for us is: Is Clojure worth our investment in the current state? What are the possible risks? Also, if anyone has any thoughts on hiring Clojure people, it would be greatly appreciated. Thanks, Aaron --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: howto update with a constant when a function is expected?
Hi, Am 16.04.2009 um 11:30 schrieb bOR_: (map (fn [n] :new) (list :old1 :old2 :old3)) works (map (constantly :new) [:old1 :old2 :old3]) Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Is Clojure production ready?
On Wed, Apr 15, 2009 at 9:34 PM, Aaron Feng aaron.f...@gmail.com wrote: Also, if anyone has any thoughts on hiring Clojure people, it would be greatly appreciated. If I may guess out aloud: In this case, I reckon that pretty much any Java programmer who knows concurrency and has a clue about functional programming will be able to pick up Clojure to a sufficient degree to get started, after a week or two of focused learning and playing. And if you can find one or two guys who already know Clojure to mentor them, then the quality of the first-month code will presumably improve noticably. Thanks, Aaron -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure production ready?
The risk of breaking changes gets smaller all the time. There is always a small chance that something might need to be changed that would break your code. It's certainly production ready. It's a full featured language for sure. Personally I would use it, but at the moment the risk of breaking changes is rather moderate. On Apr 15, 2:34 pm, Aaron Feng aaron.f...@gmail.com wrote: Hi, I work for a large financial software company, and we are interested in using Clojure for our new project. Due to the concurrent nature of the project, we are evaluating three possible languages: Erlang, Scala, and Clojure. This project will be a hosted solution, but availability and performance is very important to us. We want to deploy the project within 6 to 12 months, but the project will continue to build out the rest of the functionality for the next 2 to 4 years. We guesstimate that it will receive around 1M hits daily initially, and it will continue to grow on a monthly basis. Due to the nature of the project, I'm only allowed to give high level overview of the project at this time. We have a bias toward Scala and Clojure because they run on top of JVM. The richness of existing 3rd party and open source libraries are also attractive for us. The fundamental question for us is: Is Clojure worth our investment in the current state? What are the possible risks? Also, if anyone has any thoughts on hiring Clojure people, it would be greatly appreciated. Thanks, Aaron --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: already-discussed vimclojure startup problem - what to do?
Hi Meikel, I have to apologize... I installed MacVim, did the command-line test you recommended and ... still the same error. Then, I reinspected my .vimrc and found a typo in the let vimclojure#NailgunClient=... line. When I read your remark in that old thread, it's mostly user errors, I thought hm... but now it was exactly that :-; Thanks a lot for your help, Sigrid On 15 Apr., 14:13, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 15.04.2009 um 11:37 schrieb Sigrid: I'm just starting with clojure and want to use vimclojure for development. I have an error on startup that has been discussed here in March: Error detected while processing function vimclojure#ExecuteNailWithInput: line 23: E605: Exception not caught: Couldn't execute Nail! Users/hunli/.vim/ng de.kotka.vimclojure.nails.NamespaceOfFile /var/folders/Wi/ WiMZBjsvFC8Qt3WXZ35h7k+++TM/-Tmp-/v788213/0 Error detected while processing /Users/hunli/.vim/ftplugin/ clojure.vim: line 131: E171: Missing :endif Error detected while processing function SNR8_LoadFTPlugin: line 17: E170: Missing :endfor After reading the old thread, I am not sure what to do about this. I have vim 7.2. on Mac OS Leopard and I understand that some people do not have a problem there (so I needn't install another vim). If there is something to do about the namespace, could someone please help with a resume of what to do? People reported problems with the stock vim delivered with OS X. I strongly recommend to use MacVim[1]. That works without problems for me. Otherwise you might want to try to run the command manually to check that the server runs properly. Just try: ng de.kotka.vimclojure.nails.NamespaceOfFile source.clj Check if this answers with some Exception or whether it returns user. Btw in my clojure file no namespace is set, it's just (defn hello [name] (str Hello, name)) so it should be in the user namespace? Yes. Files without ns or in-ns form are considered to be in the user namespace. Sincerely Meikel smime.p7s 5KAnzeigenHerunterladen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: howto update with a constant when a function is expected?
On Apr 15, 2009, at 11:30 PM, bOR_ wrote: Hi all, some functions (like map, or update-in) expect a function to be applied on a value. In the case where the update I want is merely a constant, is there a short way to write it? (map (fn [n] :new) (list :old1 :old2 :old3)) works (map :new (list :old1 :old2 :old3)) unfortunately doesn't work in the way I would hope (gives nil nil nil) There are a number of possible answers here depending on what you're trying to do. The one that corresponds literally to your approach is this: (map (constantly :new) (list :old1 :old2 :old3)) 'constantly' creates a function which simply ignores its arguments and returns the value provided. But if all you are really doing is creating a sequence of a given length containing a constant element, then this is more straightforward: (repeat (count (list :old1 :old2 :old3)) :new) Aloha, David Sletten --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure production ready?
I suggest you to use Clojure. There is no more risk involved than with anything else. Clojure supports in its current version all of Java. It has very nice libs, macros, cuncurrency engine, etc. Those are fully production ready features. My company uses Clojure for production, and it meets our high expectations. The only thing that could happen is that there will be a breaking change. That means: your unit tests will suddenly report errors in many places. In such a case you can decide to either fix them, or just have a policy of not updating Clojure. No one stops you from downloading the newest Clojure and just work with that. That will give you all of what Java can do plus everything that there is in Clojure so far. This is a lot. So yes, I suggest you to go with Clojure. On 15 Apr., 21:34, Aaron Feng aaron.f...@gmail.com wrote: Hi, I work for a large financial software company, and we are interested in using Clojure for our new project. Due to the concurrent nature of the project, we are evaluating three possible languages: Erlang, Scala, and Clojure. This project will be a hosted solution, but availability and performance is very important to us. We want to deploy the project within 6 to 12 months, but the project will continue to build out the rest of the functionality for the next 2 to 4 years. We guesstimate that it will receive around 1M hits daily initially, and it will continue to grow on a monthly basis. Due to the nature of the project, I'm only allowed to give high level overview of the project at this time. We have a bias toward Scala and Clojure because they run on top of JVM. The richness of existing 3rd party and open source libraries are also attractive for us. The fundamental question for us is: Is Clojure worth our investment in the current state? What are the possible risks? Also, if anyone has any thoughts on hiring Clojure people, it would be greatly appreciated. Thanks, Aaron --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Enlive questions
Tom, The redesign is nearly over (at least from a user standpoint), you may want to check it http://github.com/cgrand/enlive/tree/right Christophe Tom Hickey a écrit : Hi Christophe, I keep running into the same problem with elements getting replaced. I'm trying to set the content of an element with raw html (from a snippet) and unable to avoid both 1) the html getting escaped and 2) the element getting replaced. I can avoid one or the other, via escaped or text, just not both. I'm looking forward to see what you've got planned for the redesign, as I'd really like to see this feature go away. Cheers, Tom On Mar 20, 3:59 am, Christophe Grand christo...@cgrand.net wrote: Phil Hagelberg a écrit : But I did notice you have the use test-is line commented out in the implementation; it seems a bit unfortunate to have to uncomment that to run the tests and hope you remember to re-comment it before you commit. The last commit was during the transition to lazy-seq and test-is was broken. I'll fix that. -- Professional:http://cgrand.net/(fr) On Clojure:http://clj-me.blogspot.com/(en) -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.blogspot.com/ (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 To unsubscribe from 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: Possible contrib contribution: clojure.contrib.timing
It should and it does now. Thanks, Chris On Apr 16, 1:16 am, Baishampayan Ghose b.gh...@ocricket.com wrote: Chris wrote: Done: git://github.com/cconstantine/clojure.contrib.git Please feel free to be brutal on the code review. The last thing I want is for clojure to get dirtied up with bad code. Just a minor nit - Shouldn't the function ``creating-timing-map'' be called ``create-timing-map'' ? Regards, BG -- Baishampayan Ghose b.gh...@ocricket.com oCricket.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 To unsubscribe from 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: howto update with a constant when a function is expected?
(fn [n] :new) or (constantly :new) was what I was looking for. Just found out the two are not exactly the same. Hmm. I guess I should have expected this from the docstring. Anyway, thanks all! Clojure= (map (constantly (ref nil)) (range 10)) 50 (#Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690) 51 Clojure= (map (fn [n] (ref nil)) (range 10)) 52 (#Ref clojure.lang@1e32382 #Ref clojure.lang@1304043 #Ref clojure.lang@cb07ef #Ref clojure.lang@176086d #Ref clojure.lang@234265 #Ref clojure.lang@dc1f04 #Ref clojure.lang@1784427 #Ref clojure.lang@c272bc #Ref clojure.lang@1fac852 #Ref clojure.lang.Ref...@1758cd1) On Apr 16, 11:54 am, David Sletten da...@bosatsu.net wrote: On Apr 15, 2009, at 11:30 PM, bOR_ wrote: Hi all, some functions (like map, or update-in) expect a function to be applied on a value. In the case where the update I want is merely a constant, is there a short way to write it? (map (fn [n] :new) (list :old1 :old2 :old3)) works (map :new (list :old1 :old2 :old3)) unfortunately doesn't work in the way I would hope (gives nil nil nil) There are a number of possible answers here depending on what you're trying to do. The one that corresponds literally to your approach is this: (map (constantly :new) (list :old1 :old2 :old3)) 'constantly' creates a function which simply ignores its arguments and returns the value provided. But if all you are really doing is creating a sequence of a given length containing a constant element, then this is more straightforward: (repeat (count (list :old1 :old2 :old3)) :new) Aloha, David Sletten --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: VimClojure 2.1.0 released
Worked with the 2.1.0 version today. Impressions so far are more stable than the developmental version of a week ago (no hanging repls), a feeling intense gratitude for the ,ct command. Furthermore a bit of collision with the default keybindings when I try to browse the history with ctrl-p and ctrl-n. Haven't yet figured out what they do now :). Good work, thanks! On Apr 15, 10:10 pm, Meikel Brandmeyer m...@kotka.de wrote: Dear vimming Clojurians, a word of warning: If you have a file containing syntax errors or which contains a namespace but is not in the Classpath, you probably want let clj_want_gorilla = 0 in your .vimrc. This also applies if you use files which have side-effects when they are loaded. The dynamic parts of VimClojure (formerly known as Gorilla) need the introspection facilities of Clojure, which only work when the namespace is loaded correctly. Sincerely Meikel smime.p7s 5KViewDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure production ready?
If you maintain some discipline in your engineering process, then there's very little risk due to the specific library (and if you don't keep a high level of discipline, then you're finished before you start). - Test the h*ll out of everything. If there are bugs in Clojure that affect you you'll find them just as if they were bugs in your own code. You could look at Clojure as just another Java library with the JVM being the base technology. - Don't let people use arbitrary versions of Clojure and Java (and Contrib, if you'll use it). Pick one, package it with your project, and then leave it alone. If your code works, you don't need the latest version of Clojure. If there's a feature or patch you need that requires an upgrade, do a full regression test. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: howto update with a constant when a function is expected?
On Apr 16, 2009, at 1:57 AM, bOR_ wrote: (fn [n] :new) or (constantly :new) was what I was looking for. Just found out the two are not exactly the same. Hmm. I guess I should have expected this from the docstring. Anyway, thanks all! Clojure= (map (constantly (ref nil)) (range 10)) 50 (#Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690 #Ref clojure.lang@1417690) 51 Clojure= (map (fn [n] (ref nil)) (range 10)) 52 (#Ref clojure.lang@1e32382 #Ref clojure.lang@1304043 #Ref clojure.lang@cb07ef #Ref clojure.lang@176086d #Ref clojure.lang@234265 #Ref clojure.lang@dc1f04 #Ref clojure.lang@1784427 #Ref clojure.lang@c272bc #Ref clojure.lang@1fac852 #Ref clojure.lang.Ref...@1758cd1) In that case, here's something that reads more clearly to me: (take 10 (repeatedly #(ref nil))) = (#r...@66036e: nil #r...@6b6b13: nil #r...@42c747: nil #r...@2943ff: nil #r...@2f4fc5: nil #r...@1e4683: nil #r...@a761ce: nil #r...@622e6: nil #r...@2689a7: nil #r...@173b39: nil) Also, in your second example above, I think it's more idiomatic to write (fn [_] (ref nil)) to demonstrate that you're ignoring the argument. Aloha, David Sletten --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure production ready?
Aaron, we have been in production with Clojure since January 2009. We use it to drive a message bus which is asynchronous by nature and requires high concurrency. It's been very stable. Our app runs 24hrs a day 7 days a week and is fully redundant. As far as getting Clojure resources, we have been mostly a Java company for the last 8 years but we had several projects using other tools (C, ), high level and low level stuff. Aside from getting tuned to the functional approach, there's not been any other impacts on the learning curve except getting used to immutability. Once you pass over this (getting rid of the old assignment habit) the benefits are immense. That aspect of Clojure was the biggest obstacle we faced. All the other stuff in Clojure is easy to pick up along the way If you have Java resources, you can make them Clojure enabled in a couple of months. Creating non-academic code (ie code to be delivered in your project) and then reviewing that against other code practises from the Clojure community should allow your resources to grasp the thing while creating the base for the rest of your project. Hey Mibu, glad to hear that Clojure is not production ready yet, we are probably all dreaming around here :) Luc On Thu, 2009-04-16 at 04:14 -0700, André Thieme wrote: I suggest you to use Clojure. There is no more risk involved than with anything else. Clojure supports in its current version all of Java. It has very nice libs, macros, cuncurrency engine, etc. Those are fully production ready features. My company uses Clojure for production, and it meets our high expectations. The only thing that could happen is that there will be a breaking change. That means: your unit tests will suddenly report errors in many places. In such a case you can decide to either fix them, or just have a policy of not updating Clojure. No one stops you from downloading the newest Clojure and just work with that. That will give you all of what Java can do plus everything that there is in Clojure so far. This is a lot. So yes, I suggest you to go with Clojure. On 15 Apr., 21:34, Aaron Feng aaron.f...@gmail.com wrote: Hi, I work for a large financial software company, and we are interested in using Clojure for our new project. Due to the concurrent nature of the project, we are evaluating three possible languages: Erlang, Scala, and Clojure. This project will be a hosted solution, but availability and performance is very important to us. We want to deploy the project within 6 to 12 months, but the project will continue to build out the rest of the functionality for the next 2 to 4 years. We guesstimate that it will receive around 1M hits daily initially, and it will continue to grow on a monthly basis. Due to the nature of the project, I'm only allowed to give high level overview of the project at this time. We have a bias toward Scala and Clojure because they run on top of JVM. The richness of existing 3rd party and open source libraries are also attractive for us. The fundamental question for us is: Is Clojure worth our investment in the current state? What are the possible risks? Also, if anyone has any thoughts on hiring Clojure people, it would be greatly appreciated. Thanks, Aaron Luc Préfontaine Armageddon was yesterday, today we have a real problem... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure production ready?
Aaron, We followed the same discipline. However we prefer no to wait too long to upgrade the run times when an official release comes out since our code base is growing as time passes by. As far as the missing stuff, well if it's available in Java, do not hesitate, use it from Clojure. There will be time later to revert to a 100% Clojure implementation when available and if the need justifies it. If you really need immutability from Java objects, convert them to Clojure equivalents and vice-versa, we did this on a few occasions just to reap the benefits of immutability. it involved most of the times 20 code lines or less to do that. Luc On Thu, 2009-04-16 at 07:38 -0700, Stuart Sierra wrote: On Apr 16, 10:00 am, Greg Harman ghar...@gmail.com wrote: - Don't let people use arbitrary versions of Clojure and Java (and Contrib, if you'll use it). Pick one, package it with your project, and then leave it alone. If your code works, you don't need the latest version of Clojure. If there's a feature or patch you need that requires an upgrade, do a full regression test. Yes. That's more or less what I do, even though I have the luxury (or hardship) of working alone. My only problems with Clojure were early on, related to obscure edge cases in Java interop. I haven't seen a Clojure bug affect my code in nearly a year. Obviously, it's a young language, so you have to do stuff yourself that is already provided with other languages. I wrote my own test framework, I/O utilities, etc. But that was fairly easy, and the flexibility of Clojure has been a big boon to my pace of work. -Stuart Sierra Luc Préfontaine Armageddon was yesterday, today we have a real problem... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure production ready?
Hi Aaron, On Apr 15, 3:34 pm, Aaron Feng aaron.f...@gmail.com wrote: Hi, I work for a large financial software company, and we are interested in using Clojure for our new project. Due to the concurrent nature of the project, we are evaluating three possible languages: Erlang, Scala, and Clojure. Assuming you don't need distributed concurrency, then Clojure could be considered the concurrency winner as it has both synchronous (refs) and asynchronous (agents) concurrency included. This project will be a hosted solution, but availability and performance is very important to us. We want to deploy the project within 6 to 12 months, but the project will continue to build out the rest of the functionality for the next 2 to 4 years. We guesstimate that it will receive around 1M hits daily initially, and it will continue to grow on a monthly basis. I've used Erlang and Clojure for real-world projects and have dabbled in Scala; Clojure (as well as Lisp in general) has anecdotally provided the largest boost in development speed. There's no reason any of these languages couldn't handle the workload you mention. Due to the nature of the project, I'm only allowed to give high level overview of the project at this time. We have a bias toward Scala and Clojure because they run on top of JVM. The richness of existing 3rd party and open source libraries are also attractive for us. The fundamental question for us is: Is Clojure worth our investment in the current state? What are the possible risks? Rich has done an excellent job balancing backward compatibility and ironing out wrinkles in the language. In other words, the language can be considered stable with a footnote that minor changes are fair game. Also, if anyone has any thoughts on hiring Clojure people, it would be greatly appreciated. There are several people on the list capable and interested in working on a Clojure codebase. Thanks, Aaron -Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Monads tutorial
The sample code is available now. Took a little bit to get it set. It's the code from the tutorial with a little bonus. I implemented an HTTP protocol parser, using the parser-m monad, as an example. Jim On Apr 16, 12:37 am, Baishampayan Ghose b.gh...@ocricket.com wrote: The code pagehttp://intensivesystems.net/tutorials/code/monads_101.clj is giving a 404 :) Regards, BG -- Baishampayan Ghose b.gh...@ocricket.com oCricket.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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
JVM hanging after -main
I have a command line utility that calls (exit 0) at the end of (-main). It looks like this: (defn exit [status] (shutdown-agents) (flush) (System/exit status)) Yet, despite this, the JVM never exits. Here is a snippet of jstack output: --8---cut here---start-8--- DestroyJavaVM prio=10 tid=0x406c7c00 nid=0x445d waiting on condition [0x..0x41e48d10] java.lang.Thread.State: RUNNABLE Locked ownable synchronizers: - None pool-1-thread-10 prio=10 tid=0x7fd9744fac00 nid=0x447c waiting on condition [0x42e58000..0x42e58da0] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x7fd981140198 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) --8---cut here---end---8--- What else can I try to force everything to shut down? Thanks! -Drew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~--- 2009-04-03 12:47:08 Full thread dump Java HotSpot(TM) 64-Bit Server VM (11.2-b01 mixed mode): Attach Listener daemon prio=10 tid=0x7fd974552800 nid=0x4d33 waiting on condition [0x..0x] java.lang.Thread.State: RUNNABLE Locked ownable synchronizers: - None DestroyJavaVM prio=10 tid=0x406c7c00 nid=0x445d waiting on condition [0x..0x41e48d10] java.lang.Thread.State: RUNNABLE Locked ownable synchronizers: - None pool-1-thread-10 prio=10 tid=0x7fd9744fac00 nid=0x447c waiting on condition [0x42e58000..0x42e58da0] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x7fd981140198 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Locked ownable synchronizers: - None pool-1-thread-9 prio=10 tid=0x7fd97444d400 nid=0x447b waiting on condition [0x42d57000..0x42d57a20] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x7fd981140198 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Locked ownable synchronizers: - None pool-1-thread-8 prio=10 tid=0x7fd974323000 nid=0x447a waiting on condition [0x42c56000..0x42c56aa0] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x7fd981140198 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358) at
The Path to 1.0
People (and not just book authors :) often ask - whither 1.0? [Ok, maybe they don't use 'whither']. The fact remains, some people want a 1.0 designation, and I'm not unwilling, providing we as a community can come to an understanding as to what that means, the process it implies, and the work it will require (and who will do it). Here are some of the relevant issues, IMO: - Stability/completeness/robustness This is mostly about - does it work? Is it relatively free of bugs? Is it free of gaping holes in core functionality? I think Clojure is in a pretty good place right now, but am obviously biased. This in no way implies there isn't room for improvement. - API stability With the semantic changes of fully lazy sequences behind us, I think the syntax and semantics of existing functions is largely stable. - Development process stability Currently all new work (fixes and enhancements) occurs in trunk. There's no way to get fixes without also getting enhancements. I think this is the major missing piece in offering stable numbered releases. While I've cut a branch for each of the prior two releases, no one has ever submitted a bugfix patch for either. If people are going to want to work with a particular release version for an extended period of time, someone (other than me) will have to produce patches of (only!) fixes from the trunk for the release branch, and occasionally produce point releases (1.0.x) from that branch. I'd like to continue to do the bulk of my work in trunk, without messing anyone up or forcing everyone to follow along. - Freedom from change Numbered releases are most definitely not about absence of change in general. There are more things I want to add and change, and there will be for some time. That will keep Clojure a living language. 1.0 or any numbered release can't and won't constitute a promise of no further change. But there are different kinds of change, changes that fix bugs and changes that add new capabilities or break existing code. People need to be able to choose the type of change they can tolerate, and when to incur it. - Perception Obviously, a 1.0 designation impacts perception. I am not interested in pursuing it just to influence perception, but rather to (collectively) acknowledge a milestone in usability and stability. However there may be other perceptions, good/bad or simply wrong (e.g. that Clojure is finished). Will the general perception engendered by 1.0 be met in the large, or a mismatch? What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? Feedback welcome, Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure production ready?
We just went through the same evaluation. At first we leaned towards
erlang, but finding erlang developers is hard (well so is finding
_good_ scala clojure devs I imagine).
We ended up picking a mix of erlang and clojure. Both have their
places. Clojure is nice because it gives access to a gazillion
libraries (and as an added benefit can be deployed to existing
infrastructure and doesn't shock your pointy hair boss because you can
just say it's a Java library) Also clojure is nice because we use
Lisp in other places (LFE see below). Clojure is also nice because it
fits well into our mindset with erlang, ruby and other low ceremony
languages.
We also write some of our stuff in LFE (lisp flavored erlang) which
gives the ability to write a lisp compiled to the erlang vm. LFE
looks like this:
(define (start)
(: lists foreach
(lambda (a)
(case (: application start a)
('ok 'ok)
((tuple 'error (tuple 'already_started _)) 'ok)))
'(crypto ssl inets ecouch)))
Erlang is teh awesome - but not for everything. Need an IMAP
library? While JavaMail sits there taunting, you you would have to
write your own by hand in Erlang. Who wants to shave that Yak? not
me. Need a full-text search library in Erlang? same thing. It's bare
metal awesome sauce for the right problem (mostly awesome easy
clustering, messaging and network services) but it doesn't fit
everywhere.
Thankfully, you can mix the two easily with a combination of messaging
(rabbitmq/json) between the two worlds and semi-direct calls with
erlang's port system (where erlang can call out directly to Java -
it's easy). So you can use Erlang for you messaging backbone and call
out to other languages. Engine Yard (Ruby guys) are doing this with
Vertebrae and PowerSet did it with Fuzed.
-Tim
On Apr 15, 9:34 am, Aaron Feng aaron.f...@gmail.com wrote:
Hi,
I work for a large financial software company, and we are interested
in using Clojure for our new project. Due to the concurrent nature of
the project, we are evaluating three possible languages: Erlang,
Scala, and Clojure. This project will be a hosted solution, but
availability and performance is very important to us. We want to
deploy the project within 6 to 12 months, but the project will
continue to build out the rest of the functionality for the next 2 to
4 years. We guesstimate that it will receive around 1M hits daily
initially, and it will continue to grow on a monthly basis.
Due to the nature of the project, I'm only allowed to give high level
overview of the project at this time.
We have a bias toward Scala and Clojure because they run on top of
JVM. The richness of existing 3rd party and open source libraries are
also attractive for us.
The fundamental question for us is: Is Clojure worth our investment
in the current state? What are the possible risks?
Also, if anyone has any thoughts on hiring Clojure people, it would be
greatly appreciated.
Thanks,
Aaron
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: The Path to 1.0
There's no way to get fixes without also getting enhancements unless you use a non-linear source control like Git. (please switch?) :) Ok no flames please - but since we have switched to Git nearly 2 years ago we have been blessed with it's abilities to keep a stable branch master and a RC branch next going with the freedom to try anything in the background (topic branches). Branching is easy, cheap and fun and I create a branch for every new bugfix or feature. It's a thing of beauty and I could never go back to SVN or CVS. I would switch to Hg first (badomp bomp *ching*) :) Just my $0.02 On Apr 16, 6:53 am, Rich Hickey richhic...@gmail.com wrote: - Development process stability Currently all new work (fixes and enhancements) occurs in trunk. There's no way to get fixes without also getting enhancements. I think this is the major missing piece in offering stable numbered releases. While I've cut a branch for each of the prior two releases, no one has ever submitted a bugfix patch for either. If people are going to want to work with a particular release version for an extended period of time, someone (other than me) will have to produce patches of (only!) fixes from the trunk for the release branch, and occasionally produce point releases (1.0.x) from that branch. I'd like to continue to do the bulk of my work in trunk, without messing anyone up or forcing everyone to follow along. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Source Control ( Was: Re: The Path to 1.0 )
Also a benefit of being on Git for contrib would mean I don't have to pull ClojureCLR and other stuff I don't want into my clone. It would make it less kitchen junk drawer. Another benefit of being on Git is people can fork, fix and send you pull requests (which you can accept or not at your discretion). It just encourages easy fork/branch/collaborate. On Apr 16, 7:33 am, dysinger dysin...@gmail.com wrote: There's no way to get fixes without also getting enhancements unless you use a non-linear source control like Git. (please switch?) :) Ok no flames please - but since we have switched to Git nearly 2 years ago we have been blessed with it's abilities to keep a stable branch master and a RC branch next going with the freedom to try anything in the background (topic branches). Branching is easy, cheap and fun and I create a branch for every new bugfix or feature. It's a thing of beauty and I could never go back to SVN or CVS. I would switch to Hg first (badomp bomp *ching*) :) Just my $0.02 On Apr 16, 6:53 am, Rich Hickey richhic...@gmail.com wrote: - Development process stability Currently all new work (fixes and enhancements) occurs in trunk. There's no way to get fixes without also getting enhancements. I think this is the major missing piece in offering stable numbered releases. While I've cut a branch for each of the prior two releases, no one has ever submitted a bugfix patch for either. If people are going to want to work with a particular release version for an extended period of time, someone (other than me) will have to produce patches of (only!) fixes from the trunk for the release branch, and occasionally produce point releases (1.0.x) from that branch. I'd like to continue to do the bulk of my work in trunk, without messing anyone up or forcing everyone to follow along. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote: What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? I would like to see, concurrent with 1.0, some kind of library management system. As noted before, contrib is already getting hairy. We have dozens of little libraries floating around on GitHub. Having you, Rich, maintain the list of libraries on clojure.org is not sustainable. We don't need a fully-realized CPAN/RubyGem but we need something that can scale to a few hundred authors. Dependency management and documentation markup are components of this. -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
It sounds nice, but I experienced massive amounts of pain trying to get the eclipse git plugin to work on mac ... eventually punted back to SVN. To me version control should be well integrated with an editor ... bottom line ... much more important than the given features of the version control system. On Thu, Apr 16, 2009 at 10:33 AM, dysinger dysin...@gmail.com wrote: There's no way to get fixes without also getting enhancements unless you use a non-linear source control like Git. (please switch?) :) Ok no flames please - but since we have switched to Git nearly 2 years ago we have been blessed with it's abilities to keep a stable branch master and a RC branch next going with the freedom to try anything in the background (topic branches). Branching is easy, cheap and fun and I create a branch for every new bugfix or feature. It's a thing of beauty and I could never go back to SVN or CVS. I would switch to Hg first (badomp bomp *ching*) :) Just my $0.02 On Apr 16, 6:53 am, Rich Hickey richhic...@gmail.com wrote: - Development process stability Currently all new work (fixes and enhancements) occurs in trunk. There's no way to get fixes without also getting enhancements. I think this is the major missing piece in offering stable numbered releases. While I've cut a branch for each of the prior two releases, no one has ever submitted a bugfix patch for either. If people are going to want to work with a particular release version for an extended period of time, someone (other than me) will have to produce patches of (only!) fixes from the trunk for the release branch, and occasionally produce point releases (1.0.x) from that branch. I'd like to continue to do the bulk of my work in trunk, without messing anyone up or forcing everyone to follow along. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Source Control ( Was: Re: The Path to 1.0 )
On Thu, Apr 16, 2009 at 10:39 AM, dysinger dysin...@gmail.com wrote: Also a benefit of being on Git for contrib would mean I don't have to pull ClojureCLR and other stuff I don't want into my clone. It would make it less kitchen junk drawer. Another benefit of being on Git is people can fork, fix and send you pull requests (which you can accept or not at your discretion). It just encourages easy fork/branch/collaborate. making the common case easy is important. I like good branching, too, for when you need it, but is it the common case, or does it fly in the face of what we are talking about here? On Apr 16, 7:33 am, dysinger dysin...@gmail.com wrote: There's no way to get fixes without also getting enhancements unless you use a non-linear source control like Git. (please switch?) :) Ok no flames please - but since we have switched to Git nearly 2 years ago we have been blessed with it's abilities to keep a stable branch master and a RC branch next going with the freedom to try anything in the background (topic branches). Branching is easy, cheap and fun and I create a branch for every new bugfix or feature. It's a thing of beauty and I could never go back to SVN or CVS. I would switch to Hg first (badomp bomp *ching*) :) Just my $0.02 On Apr 16, 6:53 am, Rich Hickey richhic...@gmail.com wrote: - Development process stability Currently all new work (fixes and enhancements) occurs in trunk. There's no way to get fixes without also getting enhancements. I think this is the major missing piece in offering stable numbered releases. While I've cut a branch for each of the prior two releases, no one has ever submitted a bugfix patch for either. If people are going to want to work with a particular release version for an extended period of time, someone (other than me) will have to produce patches of (only!) fixes from the trunk for the release branch, and occasionally produce point releases (1.0.x) from that branch. I'd like to continue to do the bulk of my work in trunk, without messing anyone up or forcing everyone to follow along. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? To me, beside what was already said, it means a deprecation policy. I like Python's. First release after deprecated changes are decided, code works as is but produces warning if you run it under warning mode. Second release, warning will come warning mode or not and third release, the feature is cut. Ideally, since backward compatibility is a big selling point of Java, I'd like to be able to tell clojure I require say version 1.0 and get the 1.0 behaviour even if I'm running on a newer version. It would enable the language to grow while providing a nice compatibility layer. Unless that's too hard or there is ramifications I'm not seeing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
Ideally, since backward compatibility is a big selling point of Java. my view of Java's backward compatibility is that it is kind of a bunch of hot air that restricts the ecosystem from being better. i vastly prefer the fact that .net is willing to make real changes to get real benefits. sincerely. $0.02 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Contribs with dependencies
On Thu, Apr 16, 2009 at 2:16 AM, Konrad Hinsen konrad.hin...@laposte.netwrote: [...] I think it would be useful to formalize this concept of a standard library that is a single entity from the point of view of users who just want to download a jar file and get going. A standard library would also define certain conventions and APIs and thus prevent future users from having to choose among ten essentially equivalent but yet incompatible libraries for file handling or for XML parsing. Of course there are a couple of open questions: Who decides what goes into the standard library? Who maintains it in the long run? Are external dependencies allowed and if yes, how are they handled? If contrib is to be viewed as a standard library for Clojure then I think it makes perfect sense to allow external dependencies. I don't know of any language with a serious standard library that depends on nothing else. The trick then however is to provide packages for the various platforms that can install clojure, contrib and all of its dependencies so a user that's not interested in hacking on the clojure or contrib source can just get up and running with minimal fuss. That still leaves open the question of how to decide which third party libraries are OK to include as a dependency. That seems to require a more formal process similar to the PEP's in Python. Maybe it's too early for something like that though. -- Cosmin Stejerean http://offbytwo.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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
java.lang.String cannot be cast to [Ljava.lang.CharSequence;
Hello, I am trying to use a java library ( http://code.google.com/p/webdriver/ ), the method I need to call has signature: sendKeys(java.lang.CharSequence... keysToSend) If I give it a clojure string, the cannot be cast message appears in the stack trace. I have tried explicit (cast java.lang.CharSequence my-string) but the cast does only compare AFAIK. Is there a way to give the library what it wants from Clojure? Kind regards, Vlad --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: JVM hanging after -main
I believe this is an issue related to how the threadpools used by executors are populated by default, i.e. they use non-daemon threads. clojure.lang.Agent uses instances of these default threadpool configurations, which is likely the cause of the delayed shutdown of the JVM (I'll bet that if you let the process linger for a couple minutes, the threadpools' timeouts will trip, the non-daemon threads will die, and the process will exit gracefully). The solution would be for clojure.lang.Agent to create ExecutorServices whose threadpools use a ThreadFactory that only creates daemon threads. I don't really use agents though, so I'm not at all in a position to write or test that patch (or be aware of what other consequences might arise from having agents executing on daemon threads -- I presume there aren't any, but...). - Chas On Apr 16, 12:25 pm, Drew Raines aarai...@gmail.com wrote: I have a command line utility that calls (exit 0) at the end of (-main). It looks like this: (defn exit [status] (shutdown-agents) (flush) (System/exit status)) Yet, despite this, the JVM never exits. Here is a snippet of jstack output: --8---cut here---start-8--- DestroyJavaVM prio=10 tid=0x406c7c00 nid=0x445d waiting on condition [0x..0x41e48d10] java.lang.Thread.State: RUNNABLE Locked ownable synchronizers: - None pool-1-thread-10 prio=10 tid=0x7fd9744fac00 nid=0x447c waiting on condition [0x42e58000..0x42e58da0] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x7fd981140198 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) --8---cut here---end---8--- What else can I try to force everything to shut down? Thanks! -Drew jvm-hang.txt 11KViewDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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.String cannot be cast to [Ljava.lang.CharSequence;
I would be interested in seeing a full stack trace and some pastbined code. there are no clojure strings, just java strings, and java strings are charsequences. On Thu, Apr 16, 2009 at 11:25 AM, prhlava prhl...@googlemail.com wrote: Hello, I am trying to use a java library ( http://code.google.com/p/webdriver/ ), the method I need to call has signature: sendKeys(java.lang.CharSequence... keysToSend) If I give it a clojure string, the cannot be cast message appears in the stack trace. I have tried explicit (cast java.lang.CharSequence my-string) but the cast does only compare AFAIK. Is there a way to give the library what it wants from Clojure? Kind regards, Vlad -- 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 To unsubscribe from 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.String cannot be cast to [Ljava.lang.CharSequence;
Are you trying to give it a string, or an array of strings? sendKeys takes a variable number of arguments. The error you are getting is that it can't cast a java.lang.String into [Ljava.lang.CharSequence, where the '[' at the beginning of the type means an array. It is telling you that it cannot convert a String into an array of CharSequences. Maybe it will work with (into-array [string])? Paul On Thu, Apr 16, 2009 at 2:25 PM, prhlava prhl...@googlemail.com wrote: Hello, I am trying to use a java library ( http://code.google.com/p/webdriver/ ), the method I need to call has signature: sendKeys(java.lang.CharSequence... keysToSend) If I give it a clojure string, the cannot be cast message appears in the stack trace. I have tried explicit (cast java.lang.CharSequence my-string) but the cast does only compare AFAIK. Is there a way to give the library what it wants from Clojure? Kind regards, Vlad --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: JVM hanging after -main
Does it shutdown if you do this before the exit? (shutdown-agents) On Thu, Apr 16, 2009 at 1:29 PM, Chas Emerick cemer...@snowtide.com wrote: I believe this is an issue related to how the threadpools used by executors are populated by default, i.e. they use non-daemon threads. clojure.lang.Agent uses instances of these default threadpool configurations, which is likely the cause of the delayed shutdown of the JVM (I'll bet that if you let the process linger for a couple minutes, the threadpools' timeouts will trip, the non-daemon threads will die, and the process will exit gracefully). The solution would be for clojure.lang.Agent to create ExecutorServices whose threadpools use a ThreadFactory that only creates daemon threads. I don't really use agents though, so I'm not at all in a position to write or test that patch (or be aware of what other consequences might arise from having agents executing on daemon threads -- I presume there aren't any, but...). - Chas On Apr 16, 12:25 pm, Drew Raines aarai...@gmail.com wrote: I have a command line utility that calls (exit 0) at the end of (-main). It looks like this: (defn exit [status] (shutdown-agents) (flush) (System/exit status)) Yet, despite this, the JVM never exits. Here is a snippet of jstack output: --8---cut here---start-8--- DestroyJavaVM prio=10 tid=0x406c7c00 nid=0x445d waiting on condition [0x..0x41e48d10] java.lang.Thread.State: RUNNABLE Locked ownable synchronizers: - None pool-1-thread-10 prio=10 tid=0x7fd9744fac00 nid=0x447c waiting on condition [0x42e58000..0x42e58da0] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x7fd981140198 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) --8---cut here---end---8--- What else can I try to force everything to shut down? Thanks! -Drew jvm-hang.txt 11KViewDownload -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure production ready?
On Apr 15, 2009, at 9:57 PM, mikel wrote: As for hiring people knowledgeable in the language, there aren't going to be a lot of people very knowledgeable in any of these languages right now. Erlang gurus may be easier to find than Scala or Clojure gurus. You might be better served hunting for smart programmers who like to learn languages, and who are interested in functional programming. The nice thing about Clojure is that there are so many paths to it: - Java devs will pick it up quickly enough because of the ties to existing libraries and clojure's fundamental simplicity - Ruby and python devs will also pick it up quickly enough as well, for similar reasons, but also due to similar approaches to literals, their familiarity with functional programming (though not the persistent data structures side of the house), etc - CL and scheme devs will pick it up very quickly because of the obvious lineage Having brought scala codebases to production in the past, I'd say it has a much steeper learning curve for most developers (having more in common with haskell or ML than anything else, IMO). More books and other training materials will go a long way towards helping there, but I'm skeptical about the degree to which they can serve as a foil for the higher degree of general complexity on that side of the fence. Just my 2¢, of course. - 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 To unsubscribe from 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: [solved] java.lang.String cannot be cast to [Ljava.lang.CharSequence;
Hello Paul, Are you trying to give it a string, or an array of strings? Maybe it will work with (into-array [string])? Thank you, this was spot on, the correct call looks like: (. query (sendKeys (into-array [my-string]))) Cheers! Vlad PS: Embarassingly, the hint is also in the FAQ... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 16, 2009, at 1:56 PM, Stuart Sierra wrote: On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote: What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? I would like to see, concurrent with 1.0, some kind of library management system. As noted before, contrib is already getting hairy. We have dozens of little libraries floating around on GitHub. Having you, Rich, maintain the list of libraries on clojure.org is not sustainable. We don't need a fully-realized CPAN/RubyGem but we need something that can scale to a few hundred authors. Dependency management and documentation markup are components of this. +1. I worry about the cpan/gem mention, though. We're still in the java world w.r.t. build and packaging, which generally means using something like ivy/maven/svn:externals/git-submodule/etc ahead of one's build process, rather than using cpan/gem/easy_install/etc at deployment time. That said, I have no concrete suggestion, as we'll always separately pull our projects' dependencies into whatever we happen to be using as a dependency management repo (it's a bummer to not be able to run a build if some third-party repo is down, etc). Regarding documentation, I remember throwing around ideas in irc some months ago about how to fold documentation from gen-class'ed libs into a library's broader javadoc. That would be a huge boon to those using clojure to build libraries that would be transparently usable by Java developers. - 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
I am all for a standard packaging/build system but what ever it is it needs to not ignore the 10s of thousands of libraries tucked away in maven2 repos. Something like Ties w/ compile support would be cool. Git submodules, SVN externals Hg forrest won't work either because everyone uses different source control (and sorry I am not switching off git :P ). On Apr 16, 9:10 am, Chas Emerick cemer...@snowtide.com wrote: On Apr 16, 2009, at 1:56 PM, Stuart Sierra wrote: On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote: What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? I would like to see, concurrent with 1.0, some kind of library management system. As noted before, contrib is already getting hairy. We have dozens of little libraries floating around on GitHub. Having you, Rich, maintain the list of libraries on clojure.org is not sustainable. We don't need a fully-realized CPAN/RubyGem but we need something that can scale to a few hundred authors. Dependency management and documentation markup are components of this. +1. I worry about the cpan/gem mention, though. We're still in the java world w.r.t. build and packaging, which generally means using something like ivy/maven/svn:externals/git-submodule/etc ahead of one's build process, rather than using cpan/gem/easy_install/etc at deployment time. That said, I have no concrete suggestion, as we'll always separately pull our projects' dependencies into whatever we happen to be using as a dependency management repo (it's a bummer to not be able to run a build if some third-party repo is down, etc). Regarding documentation, I remember throwing around ideas in irc some months ago about how to fold documentation from gen-class'ed libs into a library's broader javadoc. That would be a huge boon to those using clojure to build libraries that would be transparently usable by Java developers. - 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
my view of Java's backward compatibility is that it is kind of a bunch of hot air that restricts the ecosystem from being better. i vastly prefer the fact that .net is willing to make real changes to get real benefits. sincerely. $0.02 And that requires shoe-horning new stuff in the old framework like using that $ convention for inner classes for instance, I agree. I did not suggest the language and API should not change and remain forever compatible, only that if possible, instead of doing something like this: (if ( *clojure-version* 1.0) (do-something) (do-something-else)) I could do something like: (ns my-namespace (:clojure-version 1.0)) and expect clojure to reroute through the old code and the old api. Clojure would stay free to evolve. The question is whether or not the cost of maintaining the plumbings to require old APIs is worth the cost. I am not really apt to judge what it involves so I'll wait for others to enlighten me. If it's not worth the cost, I'd be happy with a works-perfectly, warns, gone deprecation policy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Contribs with dependencies
I agree with matt. Why is there so much NIH churn around this dependency management issue? We should leverage maven repos just wrap maven or ivy with clojure - they both have a java api. Maven repos, like them or not, already solved dep management in Java. Why fight it? PS - buildr sucks and is slower than maven even. I'd rather see direct ivy/maven api in clojure w/ convention over configuration dryness. On Apr 14, 5:59 am, Matt Clark matt.clar...@gmail.com wrote: I like Stuart's idea, but I can see those dependency declarations becoming repetitive in any significantly large project. I think there would need to be someway to declare dependencies on a larger scope, perhaps application wide, or some mechanism to describe dependencies for sets of namespaces. I also think it's worth supporting artifact, group and version information for a given dependency so users, or even an automated tool can easily go out to maven repositories and download them as needed. I think there is a case here for a simple automated tool to use maven repositories to satisfy dependencies, but I am far from an expert in this realm. I think buildr does something similar, but someone can correct me if I'm wrong. -Matt On Apr 14, 12:38 pm, Konrad Hinsen konrad.hin...@laposte.net wrote: On Apr 14, 2009, at 17:17, Laurent PETIT wrote: The problem will then be that the next time I checkout clojure- contrib, BLAM I can't compile it because I need to download a jar from somewhere on the web ... That could be avoided by including the Clojure source in clojure- contrib, but not add it to the libraries to be precompiled in build.xml. I suspect that it would even be possible to add specific compilation targets for libraries that have external dependencies, but I don't know ant well enough to be certain. Note that I am not proposing any dependency management, just separate compilation targets for clojure-only libraries and depends-on-XYZ libraries. For a precompiled jar distribution, that would probably imply separate jar files. Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
OSGi is becoming the de facto standard for solving the runtime issues around versioning and classpath management in the standard Java world. As for development versioning issues, Maven is the de facto standard. While I certainly don't think that Clojure 1.0 should have any dependency on OSGi, I'd personally like to see the libraries evolve that direction with some library API support. The API support would likely parallel the OSGi jar manifest declarations. That API could serve both as build time code to generate the static manifest files necessary to play in an OSGi container as well as runtime declarations of services and dynamic dependencies. On Apr 16, 12:28 pm, Dan redalas...@gmail.com wrote: my view of Java's backward compatibility is that it is kind of a bunch of hot air that restricts the ecosystem from being better. i vastly prefer the fact that .net is willing to make real changes to get real benefits. sincerely. $0.02 And that requires shoe-horning new stuff in the old framework like using that $ convention for inner classes for instance, I agree. I did not suggest the language and API should not change and remain forever compatible, only that if possible, instead of doing something like this: (if ( *clojure-version* 1.0) (do-something) (do-something-else)) I could do something like: (ns my-namespace (:clojure-version 1.0)) and expect clojure to reroute through the old code and the old api. Clojure would stay free to evolve. The question is whether or not the cost of maintaining the plumbings to require old APIs is worth the cost. I am not really apt to judge what it involves so I'll wait for others to enlighten me. If it's not worth the cost, I'd be happy with a works-perfectly, warns, gone deprecation policy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Enlive questions
Because predicates in selectors no longer need to be quoted it seems you
can't use Enlive selectors in a first class way with snippets:
(let [aselector [[:div (attr= :tiptree:widget widgetA)]]]
((snippet widget.html aselector
[some-map]
[:div.value] (content foo)) {}))
I believe this might be one of my final big requests :) I personally don't
mind the quoted predicate forms, especially if this would simplify making
selectors first class. This would allow templates to dynamically generate
snippets based on the properties of a particular node.
There's been a wild flurry of updates to Enlive recently and I am extremely
excited about the possibilities. Enlive is an idea which should be ripped
off by every web framework worth talking about! ;) Thanks again for creating
and maintaining it.
On Thu, Apr 16, 2009 at 7:15 AM, Christophe Grand christo...@cgrand.netwrote:
Tom,
The redesign is nearly over (at least from a user standpoint), you may
want to check it http://github.com/cgrand/enlive/tree/right
Christophe
Tom Hickey a écrit :
Hi Christophe,
I keep running into the same problem with elements getting replaced.
I'm trying to set the content of an element with raw html (from a
snippet) and unable to avoid both 1) the html getting escaped and 2)
the element getting replaced. I can avoid one or the other, via
escaped or text, just not both.
I'm looking forward to see what you've got planned for the redesign,
as I'd really like to see this feature go away.
Cheers,
Tom
On Mar 20, 3:59 am, Christophe Grand christo...@cgrand.net wrote:
Phil Hagelberg a écrit :
But I did notice you have the use test-is line commented out in the
implementation; it seems a bit unfortunate to have to uncomment that to
run the tests and hope you remember to re-comment it before you commit.
The last commit was during the transition to lazy-seq and test-is was
broken.
I'll fix that.
--
Professional:http://cgrand.net/(fr)
On Clojure:http://clj-me.blogspot.com/(en)
--
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (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
To unsubscribe from 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: Contribs with dependencies
Hi, Am 16.04.2009 um 21:48 schrieb dysinger: Why is there so much NIH churn around this dependency management issue? We should leverage maven repos just wrap maven or ivy with clojure - they both have a java api. Maven repos, like them or not, already solved dep management in Java. Why fight it? Howard did a lot of work with Maven, I experimented with Ivy. No one commented on this. There were only diffuse fears, but no concrete concerns. I think the arguments are just iterated in different form. What are the problems seen with Maven or Ivy? Concrete problems? PS - buildr sucks and is slower than maven even. I'd rather see direct ivy/maven api in clojure w/ convention over configuration dryness. I'm working on lancet and Ivy. Maybe I can get it up and running more concise than the thousand repetitions with ant. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Help
Nevermind. On Apr 16, 3:28 pm, jim jim.d...@gmail.com wrote: Someone sent me an email about some issues with javascript generator I posted a couple of weeks ago. I have searched all my email locations and can't find any record of those emails or the response I know I sent. It that was you, would you mind emailing me again? Thanks, Jim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Compojure's decorate-with into contrib?
I'm trying to figure out the best way to use clojure.core/memoize while retaining the original function's docstrings, tags, etc. for the memoized function. The best way I've seen to do this is James Reeves' decorate-with function from Compojure, which applies a decorator -- Python's name for a higher-order function, like memoize, that takes a function f returns f' that's a version of f modified in some useful way -- to already-defined functions, like (defn costly-fn [x] (costly-computation x)) (decorate-with memoize costly-fn) The most useful thing about decorate-with is its side-effecting code that redefines the root binding of the costly-fn var while keeping its original metadata. This is done by the redef function, which is (with a few minor differences from the Compojure version): (defmacro redef Redefine an existing value, keeping the metadata intact. [name value] `(let [m# (meta (var ~name)) v# (def ~name ~value)] (alter-meta! v# merge m#) v#)) Question: is there a better way of using decorators than this? If not, is there any interest in including redef decorate-with (see below) in contrib, either, perhaps, in c.c.def or c.c.macros? Thanks, Perry (defmacro decorate-with Wrap functions in a decorator. [decorator funcs] `(do ~@(for [f funcs] `(redef ~f (~decorator ~f) Compojure's compojure.control library: http://bit.ly/17U7m --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Thu, Apr 16, 2009 at 9:53 AM, Rich Hickey richhic...@gmail.com wrote: People (and not just book authors :) often ask - whither 1.0? [Ok, maybe they don't use 'whither']. The fact remains, some people want a 1.0 designation, and I'm not unwilling, providing we as a community can come to an understanding as to what that means, the process it implies, and the work it will require (and who will do it). Here are some of the relevant issues, IMO: - Stability/completeness/robustness This is mostly about - does it work? Is it relatively free of bugs? Is it free of gaping holes in core functionality? I think Clojure is in a pretty good place right now, but am obviously biased. This in no way implies there isn't room for improvement. - API stability With the semantic changes of fully lazy sequences behind us, I think the syntax and semantics of existing functions is largely stable. Version numbering should reflect stability and compatibility. Clojure x.y.z z increments when a release changes functionality but not (public) APIs. y increments when a release adds new public APIs. x increments when public APIs change in a non-compatible way. People should have the expectation that an upgrade from 1.0.2 to 1.0.3 should be painless (and you should be able to back down from 1.0.3 to 1.0.2 without any compilation errors). An upgrade from 1.0.3 to 1.1.0 may not be reversable (if you start using new APIs in 1.1.0, your code won't compile is you revert to 1.0.3). However, this is very hard to achieve in practice (so far we haven't pulled this off for Tapestry); just knowing how a particular change affects the y or z digit takes experience. In addition, there's a drive from end users who want pre-compiled snapshots of versions short of a fully endorsed release. That's one of the reasons I've put some effort into the Clojure nightly builds and Maven repository: to allow people to track the latest without building it themselves, or asking Rich to make more frequent releases. Clojure has an advantage here that functions, rather than objects, are extremely fine grained. In addition, macros and multimethods allow API compatibility to be maintained even as new features are added. Finally, my experience with final releases is that they rarely are. Drawing a line in the sand and saying this is the 1.0 release usually results in a frantic batch of patch releases. Instead, release a candidate, say 1.0.1. If you find bugs, release a new 1.0.2. When bugs stop being deal-busters, announce that 1.0.2 is the GA release. In other words, let a release prove itself before being anointed the final release. Having a fixed release version number is no different than having a fixed release date: those are impositions by marketing, not an engineering decision. I think there is a definite need, however, to ** get tests into clojure-lang **. The tests will be the best way to determine how a change affects compatibility. Regressions are very hard to predict, and I don't trust myself to identify which changes will break client code, and which will not ... short of having a test to represent client code. The lack of tests and the sorry state of Java code documentation are daunting to many, including myself. Rich is obviously brilliant, but any successful project has to scale beyond its creator. The lack of tests and documentation borders on arrogance. - Development process stability Currently all new work (fixes and enhancements) occurs in trunk. There's no way to get fixes without also getting enhancements. I think this is the major missing piece in offering stable numbered releases. While I've cut a branch for each of the prior two releases, no one has ever submitted a bugfix patch for either. If people are going to want to work with a particular release version for an extended period of time, someone (other than me) will have to produce patches of (only!) fixes from the trunk for the release branch, and occasionally produce point releases (1.0.x) from that branch. I'd like to continue to do the bulk of my work in trunk, without messing anyone up or forcing everyone to follow along. - Freedom from change Numbered releases are most definitely not about absence of change in general. There are more things I want to add and change, and there will be for some time. That will keep Clojure a living language. 1.0 or any numbered release can't and won't constitute a promise of no further change. But there are different kinds of change, changes that fix bugs and changes that add new capabilities or break existing code. People need to be able to choose the type of change they can tolerate, and when to incur it. - Perception Obviously, a 1.0 designation impacts perception. I am not interested in pursuing it just to influence perception, but rather to (collectively) acknowledge a milestone in usability and stability. However there may be other perceptions, good/bad or simply wrong (e.g. that
Standard startup script?
I have seen various scripts to start clojure in the net. Everyone seems to have its favourite, even contrib has one. Also, there are a lot of questions what is the bestest way to invoke clojure, how to start REPL, how to run script, compile file, should it be used with server or client VM. Do you think it would be benefitial to have such script included as part of standard clojure? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Thu, Apr 16, 2009 at 9:10 PM, Chas Emerick cemer...@snowtide.com [...] That said, I have no concrete suggestion, as we'll always separately pull our projects' dependencies into whatever we happen to be using as a dependency management repo (it's a bummer to not be able to run a build if some third-party repo is down, etc). Yes, please, I don't want to be forced to work around automated downloaders. e.g. Like OpenWrt's build system that wants to download huge amounts of code if you don't watch it instead of just failing so you can tell it to look *over there* where I've already downloaded 90% of it! Of course, after it happens the first time you learn to be more careful, but I would prefer to be told what the dependencies are so that I can get them myself, or to be asked whether to download them than just automatically downloading them. Regarding documentation, I remember throwing around ideas in irc some months ago about how to fold documentation from gen-class'ed libs into a library's broader javadoc. That would be a huge boon to those using clojure to build libraries that would be transparently usable by Java developers. About documentation: I believe this has been mentioned before, but I haven't been able to find the thread. Some functions are documented like this: assoc[iate]. When applied to a map[...] This makes it difficult if you're looking for some function and don't know the exact name. e.g.: user= (find-doc quotient) nil user= (find-doc quot\\[ient) - clojure.core/quot ([num div]) quot[ient] of dividing numerator by denominator. nil Also, while looking for the thread mentioning the above, I found another unresolved documentation-related thread: http://groups.google.com/group/clojure/browse_thread/thread/9d18bc892ff523d5/b21c03cfb26ea084#b21c03cfb26ea084 This is about the count function being difficult to find if you're trying to find the length or size of something. -- Michael Wood esiot...@gmail.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 To unsubscribe from 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: Contribs with dependencies
sounds like we need at least three things: 1) clojure-sandbox 2) clojure-extensions (for the CLR and javascript and jfreechart) 3) core-candidates for things that seem like they might grow up to be in the core. This would have the intent rzezeski and I were talking about. things here say to the world, this was needed by someone for clojure to be useful. maybe it's universally so, and folks can get a break from typing a long namespace to get the functionality On Wed, Apr 15, 2009 at 2:07 PM, Stuart Sierra the.stuart.sie...@gmail.comwrote: On Apr 15, 2:10 pm, rzeze...@gmail.com rzeze...@gmail.com wrote: P.S. I don't want to get off-track, but I also don't understand why ClojureCLR or clojurescript are included in Contrib. I also don't understand why test files are not under their own top level dir? I think that is a good convention and allows for easier tooling. The answer to all these questions is that: contrib has grown organically, without anyone imposing structure. Rich Hickey has taken a largely hands-off approach, allowing us to use contrib as a sandbox to share useful clojure code. I think it's valuable to have contrib as a sandbox. But this discussion shows it's also valuable to have Clojure libraries with their own external dependencies. Contrib right now is just an SVN repo, so it's pretty limited in terms of what it can do. If we want to handle multiple projects, with different dependencies, we need a more sophisticated system. We can try to piggyback on an existing Java system like Maven or Ivy, or start from scratch. But someone(s) will then have to take responsibility for maintaining that repository. -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Thu, Apr 16, 2009 at 7:56 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote: What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? I would like to see, concurrent with 1.0, some kind of library management system. As noted before, contrib is already getting hairy. We have dozens of little libraries floating around on GitHub. Having you, Rich, maintain the list of libraries on clojure.org is not sustainable. We don't need a fully-realized CPAN/RubyGem but we need something that can scale to a few hundred authors. Dependency management and documentation markup are components of this. Python did very well without a CPAN-alike. Of course it had a pretty good standard library. -- Michael Wood esiot...@gmail.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 To unsubscribe from 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: JVM hanging after -main
Chas Emerick wrote: I believe this is an issue related to how the threadpools used by executors are populated by default, i.e. they use non-daemon threads. clojure.lang.Agent uses instances of these default threadpool configurations, which is likely the cause of the delayed shutdown of the JVM (I'll bet that if you let the process linger for a couple minutes, the threadpools' timeouts will trip, the non-daemon threads will die, and the process will exit gracefully). Oddly enough, this is the behavior I generally see interactively. When spawned via cron(8), however, the java processes linger for weeks and I have to manually kill(1) them. Is there something in that execution environment that would suppress the threadpool timeout? -Drew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
Hi, Am 16.04.2009 um 23:21 schrieb Michael Wood: Yes, please, I don't want to be forced to work around automated downloaders. e.g. Like OpenWrt's build system that wants to download huge amounts of code if you don't watch it instead of just failing so you can tell it to look *over there* where I've already downloaded 90% of it! Of course, after it happens the first time you learn to be more careful, but I would prefer to be told what the dependencies are so that I can get them myself, or to be asked whether to download them than just automatically downloading them. To start collecting some Pros/Cons for the different possibilities at there: From my experiments with Ivy: You can just remove any public repository from the search paths. So any download will fail, telling you which dependencies could not be met. In fact I run such a setup at work, where all external dependencies are mirrored locally. So there is no network access required. Finally, Ivy makes it easy to setup such a mirror by virtue of the ivy:install task. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: The Path to 1.0
On Thu, Apr 16, 2009 at 2:40 PM, chris cnuern...@gmail.com wrote: That is putting it quite strongly, Howard. Instead of stating the problem as a problem of arrogance, it would be better to state it as without X, you can't get Y. Specifically, without better documentation there exists a class of users that will not use clojure and there exists a class of problems that will take a lot longer to solve than they would otherwise take with better documentation. Without more testing it will be impossible to say that any given change in subversion won't break a program. Really, this is an impossible statement anyway although I realize that tests mitigate the problem somewhat. Thus we can't use x.y.z. Every change would be just x (somewhat absurd but at least correct). Your point release theory sounds good if the use cases of your library are very will defined and tested. A programming language doesn't fit the testability coverage scenario very well as it is, well, a turing complete language and thus it would be difficult at best to prove it was working as it was before after *any* non-trivial change (difficult meaning it is unlikely anyone here is a good enough mathematician to do it in the average case). Only a small portion of the code is the language; most of Clojure is the standard library, which can be unit tested. Testability is one of the foundations of functional programming, so its painful to see no actual tests. I agree that more tests would be a good thing; I personally am not going to touch clojure source without more tests that show a little more of the intent of what the code is doing. But clients of clojure *should* have sufficient tests to ensure that upgrading clojure will not present a massive problem; it is impossible for Rich or anyone else to provide this guarantee. There are no guarantees, but there are measures you can take to inspire confidence. So the question is, what level of documentation and what level of test coverage is important for a 1.0 release? What would you like to see documented and tested? I would like to see the datastructures' memory and performance bounds tested, for instance. Chris On Apr 16, 2:58 pm, Howard Lewis Ship hls...@gmail.com wrote: On Thu, Apr 16, 2009 at 9:53 AM, Rich Hickey richhic...@gmail.com wrote: People (and not just book authors :) often ask - whither 1.0? [Ok, maybe they don't use 'whither']. The fact remains, some people want a 1.0 designation, and I'm not unwilling, providing we as a community can come to an understanding as to what that means, the process it implies, and the work it will require (and who will do it). Here are some of the relevant issues, IMO: - Stability/completeness/robustness This is mostly about - does it work? Is it relatively free of bugs? Is it free of gaping holes in core functionality? I think Clojure is in a pretty good place right now, but am obviously biased. This in no way implies there isn't room for improvement. - API stability With the semantic changes of fully lazy sequences behind us, I think the syntax and semantics of existing functions is largely stable. Version numbering should reflect stability and compatibility. Clojure x.y.z z increments when a release changes functionality but not (public) APIs. y increments when a release adds new public APIs. x increments when public APIs change in a non-compatible way. People should have the expectation that an upgrade from 1.0.2 to 1.0.3 should be painless (and you should be able to back down from 1.0.3 to 1.0.2 without any compilation errors). An upgrade from 1.0.3 to 1.1.0 may not be reversable (if you start using new APIs in 1.1.0, your code won't compile is you revert to 1.0.3). However, this is very hard to achieve in practice (so far we haven't pulled this off for Tapestry); just knowing how a particular change affects the y or z digit takes experience. In addition, there's a drive from end users who want pre-compiled snapshots of versions short of a fully endorsed release. That's one of the reasons I've put some effort into the Clojure nightly builds and Maven repository: to allow people to track the latest without building it themselves, or asking Rich to make more frequent releases. Clojure has an advantage here that functions, rather than objects, are extremely fine grained. In addition, macros and multimethods allow API compatibility to be maintained even as new features are added. Finally, my experience with final releases is that they rarely are. Drawing a line in the sand and saying this is the 1.0 release usually results in a frantic batch of patch releases. Instead, release a candidate, say 1.0.1. If you find bugs, release a new 1.0.2. When bugs stop being deal-busters, announce that 1.0.2 is the GA release. In other words, let a release prove itself before being anointed the final release. Having a fixed release version
Re: The Path to 1.0
That is putting it quite strongly, Howard. Instead of stating the problem as a problem of arrogance, it would be better to state it as without X, you can't get Y. Specifically, without better documentation there exists a class of users that will not use clojure and there exists a class of problems that will take a lot longer to solve than they would otherwise take with better documentation. Without more testing it will be impossible to say that any given change in subversion won't break a program. Really, this is an impossible statement anyway although I realize that tests mitigate the problem somewhat. Thus we can't use x.y.z. Every change would be just x (somewhat absurd but at least correct). Your point release theory sounds good if the use cases of your library are very will defined and tested. A programming language doesn't fit the testability coverage scenario very well as it is, well, a turing complete language and thus it would be difficult at best to prove it was working as it was before after *any* non-trivial change (difficult meaning it is unlikely anyone here is a good enough mathematician to do it in the average case). I agree that more tests would be a good thing; I personally am not going to touch clojure source without more tests that show a little more of the intent of what the code is doing. But clients of clojure *should* have sufficient tests to ensure that upgrading clojure will not present a massive problem; it is impossible for Rich or anyone else to provide this guarantee. So the question is, what level of documentation and what level of test coverage is important for a 1.0 release? What would you like to see documented and tested? I would like to see the datastructures' memory and performance bounds tested, for instance. Chris On Apr 16, 2:58 pm, Howard Lewis Ship hls...@gmail.com wrote: On Thu, Apr 16, 2009 at 9:53 AM, Rich Hickey richhic...@gmail.com wrote: People (and not just book authors :) often ask - whither 1.0? [Ok, maybe they don't use 'whither']. The fact remains, some people want a 1.0 designation, and I'm not unwilling, providing we as a community can come to an understanding as to what that means, the process it implies, and the work it will require (and who will do it). Here are some of the relevant issues, IMO: - Stability/completeness/robustness This is mostly about - does it work? Is it relatively free of bugs? Is it free of gaping holes in core functionality? I think Clojure is in a pretty good place right now, but am obviously biased. This in no way implies there isn't room for improvement. - API stability With the semantic changes of fully lazy sequences behind us, I think the syntax and semantics of existing functions is largely stable. Version numbering should reflect stability and compatibility. Clojure x.y.z z increments when a release changes functionality but not (public) APIs. y increments when a release adds new public APIs. x increments when public APIs change in a non-compatible way. People should have the expectation that an upgrade from 1.0.2 to 1.0.3 should be painless (and you should be able to back down from 1.0.3 to 1.0.2 without any compilation errors). An upgrade from 1.0.3 to 1.1.0 may not be reversable (if you start using new APIs in 1.1.0, your code won't compile is you revert to 1.0.3). However, this is very hard to achieve in practice (so far we haven't pulled this off for Tapestry); just knowing how a particular change affects the y or z digit takes experience. In addition, there's a drive from end users who want pre-compiled snapshots of versions short of a fully endorsed release. That's one of the reasons I've put some effort into the Clojure nightly builds and Maven repository: to allow people to track the latest without building it themselves, or asking Rich to make more frequent releases. Clojure has an advantage here that functions, rather than objects, are extremely fine grained. In addition, macros and multimethods allow API compatibility to be maintained even as new features are added. Finally, my experience with final releases is that they rarely are. Drawing a line in the sand and saying this is the 1.0 release usually results in a frantic batch of patch releases. Instead, release a candidate, say 1.0.1. If you find bugs, release a new 1.0.2. When bugs stop being deal-busters, announce that 1.0.2 is the GA release. In other words, let a release prove itself before being anointed the final release. Having a fixed release version number is no different than having a fixed release date: those are impositions by marketing, not an engineering decision. I think there is a definite need, however, to ** get tests into clojure-lang **. The tests will be the best way to determine how a change affects compatibility. Regressions are very hard to predict, and I don't trust myself to identify which changes will break client code, and which
Re: Design advice/patterns for Clojure concurrency
On Apr 15, 4:12 pm, Robert Feldt robert.fe...@gmail.com wrote: Although I understand each of the concurrency primitives/systems (stm, agents, atoms, dynvars) in isolation I find it harder to choose wisely between them when designing/implementing specific algorithms and programs. Do you have any advice/tips for how to choose between Clojure's different concurrency constructs? How do you decide which construct to use for a particular algorithm/ program? I think atom with swap! is just a special case of ref with alter when there is just one field to maintain concurrency on. Thus, in general, you could use ref and alter wherever you use atom and swap! (provided you wrap it in a do-sync statement). However, ref provides commute which does not have a counterpart for atom. And atom provides compare-and-set! which does not have a counterpart for dosync of ref. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Design advice/patterns for Clojure concurrency
How do you decide which construct to use for a particular algorithm/ program? it would be nifty keen nice if there were some cute visual flow charty representation of people's decision tree? maybe something that can get 'crowd sourced' on some wiki page somewhere. some day. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: JVM hanging after -main
On Apr 16, 11:25 am, Drew Raines aarai...@gmail.com wrote: I have a command line utility that calls (exit 0) at the end of (-main). It looks like this: (defn exit [status] (shutdown-agents) (flush) (System/exit status)) Yet, despite this, the JVM never exits. The documentation for shutdown-agents says Initiates a shutdown of the thread pools that back the agent system. Running actions will complete, but no new actions will be accepted. I think you are responsible for ending the currently running agents. The usual method is to set up some field which the agents monitor looking for some value indicating the application is ending. You have a command-line utility, so the following doesn't apply to your case. I have a gui application with multiple windows for each document. When the document window closes, I need to stop the associated agents for that window. Rather than set up some field as I suggested above, I do the following. === (defn bossAgentAction [_ achiGameHandle #^JFrame achiFrame] (when (.isDisplayable achiFrame) (send-off *agent* #'bossAgentAction achiGameHandle achiFrame))) nil) === That is, I use the JFrame itself to indicate when the agent thread should terminate. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Enlive questions
On second thought, this is actually not that critical for what I'm trying to
accomplish, and I'm not sure yet if I'll ever use such a feature. Macros
that define snippets will probably suffice.
(deftemplate my-app6 app2.html
[widgets]
[[:div (attr? :tiptree:replace)]]
(fn [node]
(let [widgetType (:tiptree:replace (:attrs node))]
((snippet widget.html [[:div (attr= :tiptree:widget (str widgetType))]]
[widget]
[:div.value] (content (if widget
(:value widget)
foo)))
((keyword widgetType) widgets)
(apply str
(my-app6 {:widgetA {:value 0},
:widgetB {:value 1}}))
Works for me, and this was in general the use case I was thinking of.
On Thu, Apr 16, 2009 at 4:24 PM, David Nolen dnolen.li...@gmail.com wrote:
Because predicates in selectors no longer need to be quoted it seems you
can't use Enlive selectors in a first class way with snippets:
(let [aselector [[:div (attr= :tiptree:widget widgetA)]]]
((snippet widget.html aselector
[some-map]
[:div.value] (content foo)) {}))
I believe this might be one of my final big requests :) I personally don't
mind the quoted predicate forms, especially if this would simplify making
selectors first class. This would allow templates to dynamically generate
snippets based on the properties of a particular node.
There's been a wild flurry of updates to Enlive recently and I am extremely
excited about the possibilities. Enlive is an idea which should be ripped
off by every web framework worth talking about! ;) Thanks again for creating
and maintaining it.
On Thu, Apr 16, 2009 at 7:15 AM, Christophe Grand
christo...@cgrand.netwrote:
Tom,
The redesign is nearly over (at least from a user standpoint), you may
want to check it http://github.com/cgrand/enlive/tree/right
Christophe
Tom Hickey a écrit :
Hi Christophe,
I keep running into the same problem with elements getting replaced.
I'm trying to set the content of an element with raw html (from a
snippet) and unable to avoid both 1) the html getting escaped and 2)
the element getting replaced. I can avoid one or the other, via
escaped or text, just not both.
I'm looking forward to see what you've got planned for the redesign,
as I'd really like to see this feature go away.
Cheers,
Tom
On Mar 20, 3:59 am, Christophe Grand christo...@cgrand.net wrote:
Phil Hagelberg a écrit :
But I did notice you have the use test-is line commented out in the
implementation; it seems a bit unfortunate to have to uncomment that
to
run the tests and hope you remember to re-comment it before you
commit.
The last commit was during the transition to lazy-seq and test-is was
broken.
I'll fix that.
--
Professional:http://cgrand.net/(fr)
On Clojure:http://clj-me.blogspot.com/(en)
--
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (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
To unsubscribe from 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 Research Papers
I hope you can find some leads from this list: http://en.wikibooks.org/wiki/Clojure_Programming/Further_Reading#Clojure_Specific Hence I'm searching for other papers/essays that I can use as a reference. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: How to compile in AquaMacs without slime? classpath problem for classes
On Apr 12, 10:25 pm, billh04 h...@tulane.edu wrote: I can compile in NetBeans with enclojure and I can compile in AquaMacs with slime. However, I prefer to use AquaMacs without slime. But, I cannot compile my application using the (compile 'my.namespace.main) invocation. The classes are generated except for main__init.class (I believe). I can force it to comile correctly by using the following before I invoke (compile 'my.namespace.main) command: (import 'java.io.File) (import 'java.net.URLClassLoader) (import 'java.net.URL) (import 'java.lang.ClassLoader) (defn classpath-add [path] (let [url (cond (string? path) (.toURL (new java.io.File path)) (instance? java.io.File path) (.toURL path) :else path) addURL (.getDeclaredMethod (identity java.net.URLClassLoader) addURL (into-array [java.net.URL]))] (.setAccessible addURL true) ; scared yet? (.invoke addURL (ClassLoader/getSystemClassLoader) (to-array [url] (classpath-add classes) Thus, I believe the problem is due to classes not being in the classpath. I have looked around and I have seen recommendations to add the classpath for classes to my Aquamacs preference file, but I don't like that if I would be working on several projects in different directories. Is there an easy way for AquaMacs to pick up the directory for classes (which is in the same directory as my program main.clj) when I invoke the compile command from Aquamacs? Thanks for any suggestions. I found a solution that works form the following suggestion at this url: http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_and_Tips I added the following two paths to my bash .profile file: ./ and ./classes. I am not sure if both are needed. The relevant part of my bash profile file looks like: # Setting CLASSPATH for java and clojure CLASSPATH=./classes:./:/Users/myusername/programming/clojurePrograms/:/ Volumes/Work/opt/jars/* export CLASSPATH --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
