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 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 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 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 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 > 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 8_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 -~--~~~~--~~--~--~---
howto update with a constant when a function is expected?
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) --~--~-~--~~~---~--~~ You 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 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 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 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 > 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 (# # # # # # # # # #) 51 Clojure=> (map (fn [n] (ref nil)) (range 10)) 52 (# # # # # # # # # #) On Apr 16, 11:54 am, David Sletten 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 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 (# # > # # # clojure.lang@1417690> # # clojure.lang@1417690> # # clojure.lang@1417690> #) > > 51 Clojure=> (map (fn [n] (ref nil)) (range 10)) > 52 (# # > # # # clojure.lang@234265> # # clojure.lang@1784427> # # clojure.lang@1fac852> #) > > In that case, here's something that reads more clearly to me: (take 10 (repeatedly #(ref 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 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?
On Apr 16, 10:00 am, Greg Harman 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 --~--~-~--~~~---~--~~ You 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 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 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 wrote: > The code pagehttp://intensivesystems.net/tutorials/code/monads_101.clj > is giving a 404 :) > > Regards, > BG > > -- > Baishampayan Ghose > 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 java.util.concurrent.ThreadPoo
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 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 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 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 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 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 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 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 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 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 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 wrote: [...] > > 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 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 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 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 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 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 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 wrote: > On Apr 16, 2009, at 1:56 PM, Stuart Sierra wrote: > > > On Apr 16, 12:53 pm, Rich Hickey 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 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 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 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 wrote:
>
> 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 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
Help
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 -~--~~~~--~~--~--~---
Re: Help
Nevermind. On Apr 16, 3:28 pm, jim 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 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
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 [...] > 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 --~--~-~--~~~---~--~~ You 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 wrote: > > On Apr 15, 2:10 pm, "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 wrote: > > On Apr 16, 12:53 pm, Rich Hickey 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 --~--~-~--~~~---~--~~ You 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 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 wrote: >> On Thu, Apr 16, 2009 at 9:53 AM, Rich Hickey 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
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 wrote: > On Thu, Apr 16, 2009 at 9:53 AM, Rich Hickey 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 ide
Re: Design advice/patterns for Clojure concurrency
On Apr 15, 4:12 pm, Robert Feldt 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 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 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
> wrote:
>
>>
>> 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 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
-~--~~~~--~~--~--~---
Clojure Research Papers
Hi guys I was asked by a professor to write an three page essay about clojure. Not really a scientific paper, more or or less an abstract, what clojure is about and what makes it special. Hence I'm searching for other papers/essays that I can use as a reference. Please let me know if you have any documents that I could use. Right now I only have the official docs + Blip videos. Thanks, Martin --~--~-~--~~~---~--~~ You 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
Stuart Halloway's book Programming Clojure could be a good starting point: http://www.pragprog.com/titles/shcloj/programming-clojure You might find Mark Volkmann's Clojure article useful: http://java.ociweb.com/mark/clojure/ On 4/17/09, magegu wrote: > > Hi guys > I was asked by a professor to write an three page essay about clojure. > Not really a scientific paper, more or or less an abstract, what > clojure is about and what makes it special. > > Hence I'm searching for other papers/essays that I can use as a > reference. > > Please let me know if you have any documents that I could use. Right > now I only have the official docs + Blip videos. > > > Thanks, > Martin > > > > -- Abhishek Reddy http://abhishek.geek.nz --~--~-~--~~~---~--~~ You 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 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 -~--~~~~--~~--~--~---
