Re: #{:rant} Questions about contribution policy and clojure compiler source.
Prioritizing the 'good' form over the substance is the first step toward political correctness and lobotomy. Civility is more about form than substance and has various meaning depending on the people involved. You can say horrendous things using a civil tone. It's as unbearable as a crude statement with a lot of bad words. As far as aspiring to be not as rude as Linus, yeah, he's kind of extreme. But becoming a care bear is not on my list of todos. Dying by civilicide either. As far as I know, I did not used obscene words or used bird names toward people. If my kind of humor is not your taste it's a legit critic and I can take it. If you have specific complaints about my tone we can pursue this off list if needed. That's channel is opened for anyone that may need to let steam out. If there's enough interest, I can even start a blog and publish emailed comments/complaints as is and anonymously if asked for. Some are stamp collectors, I could start an original collection of my own. Sent from my iPad On Jul 19, 2015, at 09:36, Colin Fleming colin.mailingl...@gmail.com wrote: On 18 July 2015 at 19:54, Luc Préfontaine lprefonta...@softaddicts.ca wrote: My tone does not please you ? It could be worse and I reserve my right to free speech. Have a look at some Linus rants. I am far from that level. I think everyone in this community should aspire to more than I'm not as rude as Linus. There's nothing that makes me shiver more than political correctness. Political correctness has nothing to do with remaining civil in a discussion. On Jul 18, 2015, at 13:32, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my
Re: #{:rant} Questions about contribution policy and clojure compiler source.
wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontaine SoftAddicts inc. Québec, Canada Mobil: +1 (514) 993-0320 Fax: +1 (514) 800-2017 Rabat, Maroc Mobil: +1 212 6 98 00 64 47 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post
Re: #{:rant} Questions about contribution policy and clojure compiler source.
, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontaine SoftAddicts inc. Québec, Canada Mobil: +1 (514) 993-0320 Fax: +1 (514) 800-2017 Rabat, Maroc Mobil: +1 212 6 98 00 64 47 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure don't support .clj source code file by utf-8.
I cannot remember the details but in 2010 I had similar problem in a cross-platform project using Clojure. And problems earlier in another cross-platform/cross-language project. So it's the reverse way, no BOM at all... Can't believe we are in 2015 still struggling with character set issues. Having to to think about this when saving a file in notepad...That's depressing. No wonder why I now stay away from Windows as much as possible. I can't understand why we cannot get some transparent behavior from the Java runtime. These are human readable text files. Not some unreadable binary format. Googled a bit about this and numerous people face this problem reading windows generated files. They all ended up having to skip the BOM if present when reading the file. So much for portability. Beurk. On Mon, Jul 13, 2015 at 2:52 PM, Luc Préfontaine lprefonta...@softaddicts.ca wrote: BG is right on it. I hit this problem a decade ago (roughly :)). UTF-8 files with no BOM are not handled properly on windows. It assumes that they are ASCII coded. That works partially (both character sets have the same encoding for many characters) but eventually fails. Make sure that the files have a BOM. You can do this on a per file basis using an IDE (Eclipse, ...) or if you can use bash scripts to do this if you have access to a u*x environment. I did not find an equivalent native windows tool but they might be some to do this in batch. Luc P. Clojure source files are expected to be in UTF-8 and Clojure on Windows doesn't require a BOM. In fact, Clojure files must not contain a BOM because it isn't considered to be whitespace by the clojure parser and will cause the error Unable to resolve symbol: ? in this context. Some software, such as Windows notepad uses the presence of a BOM to detect UTF-8, but that can be overridden in the File | Open dialog. Other than that, the behaviour of the BOM on Clojure between Linux and Windows should be the same - this stuff is all handled by Java code in the JDK - not by the Windows platform. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure don't support .clj source code file by utf-8.
BG is right on it. I hit this problem a decade ago (roughly :)). UTF-8 files with no BOM are not handled properly on windows. It assumes that they are ASCII coded. That works partially (both character sets have the same encoding for many characters) but eventually fails. Make sure that the files have a BOM. You can do this on a per file basis using an IDE (Eclipse, ...) or if you can use bash scripts to do this if you have access to a u*x environment. I did not find an equivalent native windows tool but they might be some to do this in batch. Luc P. Of course not. My files do not have BOM. So the problem lies in the BOM thingy? On Mon, Jul 13, 2015 at 10:07 AM Baishampayan Ghose b.gh...@gmail.com wrote: Hi, IIRC Windows requires UTF-8 encoded files to have the BOM (Byte Order Mark). Can you verify that your file has the BOM? Regards, BG On Thu, Jul 9, 2015 at 8:03 AM, Alex Woods linpc...@gmail.com wrote: clojure don't support .clj source code file by utf-8. it's ok when the .clj source code files by ascii env: windows7,jdk1.8u45,lein2.5.0 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Baishampayan Ghose b.ghose at gmail.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/Rk5JGhq-IJY/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Counterclockwise's Plugin Shortcuts for OS X
Create an external tool command (lein eastwood) perhaps ? Sorry, could not resist :) Luc P. Sent from my iPad On Jul 7, 2015, at 15:21, JPatrick Davenport virmu...@gmail.com wrote: Hello, I want to use the linter within Eclipse. I followed the instructions for both the plugin manager as well as the linter. Unfortunately I don't know the shortcut keys to run them with Eclipse in OS X. I can't find any menu options to activate these. Perhaps I'm overlooking something. What should I do? Thanks, JPD -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: let vs. let*
I had to query it myself not knowing what this site was all about, nice tutorial, I think I understood it :) Luc P. raould, I find lmgtfy links to be a condescending way to answer a question and I would prefer that we not use them on this list. If you have an answer or a link to one, then respond with this, otherwise I do not see a reason to post this. Thanks, Alex On Thursday, June 18, 2015 at 3:35:53 PM UTC-5, raould wrote: http://lmgtfy.com/?q=clojure+%22let+vs.+let*%22 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: 1.7.0b2, lein, cljc and tests
I encountered a couple of glitches around cljc support through figwheel. Updating a .cljc file was triggering a recompilation in some circumstances. I did not investigate further, it kind of disappeared from my horizon but I do not why exactly. Can't relate this to a change in my project yet. Luc P. Hi Gary, lein does appear to support it as lein test some-test-in-cljc works, just not if I do ‘lein test’. Is this expected? I am running 2.5.1 On 19 Jun 2015, at 14:46, Gary Trakhman gary.trakh...@gmail.com wrote: Leiningen needs to support cljc, right now only the compiler does, and clojure-maven-plugin since a few days ago. https://github.com/technomancy/leiningen/issues/1827 https://github.com/technomancy/leiningen/issues/1827 On Fri, Jun 19, 2015 at 9:41 AM Colin Yates colin.ya...@gmail.com mailto:colin.ya...@gmail.com wrote: First - cljc is (for me) a huge upgrade over cljx, which was a great solution. Not having to run lein clix auto every time I do a clean is far more useful than I realised. The problem I am having is that cljc test files don't seem to be picked up. I have test/clj and test/cljc, my test-paths in project.clj are [test/clj test/cljc] but 'lein test', and 'lein test-refresh' don't see them. If I do a 'lein test some-namespace-in-cljc' then the tests are run. Has anyone else experienced this and if so, any pointers on moving forward? Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com mailto:clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com mailto:clojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Multimethod or protocol or...? Clojure design feedback
I regroup these name spaces in an api name space and require this name space where it makes sense. You can cut out your APIs as you wish around one or more mutli methods and add whatever stuff needs to be part of it. Still manually managed but not scattered everywhere. Never thought of a different way to manage this however. Luc P. Thanks for the feedback guys. Another related Q: The user needs to require the namespace that those defmethods are defined in for the multi to know about it. Presumably each defmethods will be in individual files, meaning the user has to require all those files for the migration tool to work. Is there a cleaner way of make sure that the defmulti knows about those methods? On Thursday, May 14, 2015 at 7:56:12 PM UTC-4, Jason Marmon wrote: I'm working on a tool to orchestrate the migration from mongodb to datomic, and i'm looking for a bit of design feedback as i'm new to clojure. The user needs to provide functions that transform mongodb documents into datomic txes. Do y'all prefer the top or bottom style, or think there's a different way to implement this design that might be better? 12345678910111213141516171819 ;; Multimethod for transforming data based on the name of the source mongodb collection (defmulti transform identity) (defmethod transform events [data] ;; do something with data ) (defmethod transform users [data] ;; do something with data ) ;; (defprotocol Collection-Transformer (transform [mongo-db document])) (def user-transformer (reify Collection-Transformer (transform [m d] do stuff))) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure.lang.LazySeq cannot be cast to clojure.lang.IFn
Dunno riemann but I would say that you need a closure here,
not an immediate call to notify. The closure will be called when expiration is
reached.
So use #(notify ...) instead.
In your current code notify gets called, return a lazy seq (for) and then
the lazy seq is called as a function when the service expires. Oups...
Second thing, use doseq, not for if you want the side effects do be done in
your notify fn. for will not get your side effects done, it only returns a lazy
seq.
Luc P.
Sent from my iPad
On May 8, 2015, at 08:01, Alexey Astafyev av.astaf...@gmail.com wrote:
I'm new to Riemann and Clojure. All I want to do is to send email
notifications to three email groups when some service's TTL is expired. I
created some sort of config file where I store a list of emails:
{
:email_group_1 (
fi...@example.com
sec...@example.ru
)
:email_group_2 (
th...@example.com
)
}
My riemann config looks like this:
(logging/init {:console true})
(import org.apache.log4j.Level)
(logging/set-level Level/DEBUG)
(require '[clojure.java.io :as io])
(import '[java.io PushbackReader])
(let [host 0.0.0.0]
(tcp-server {:host host :port 60001})
(udp-server {:host host})
(ws-server {:host host :port 60003}))
(repl-server {:host 127.0.0.1})
(def cwd (System/getProperty user.dir))
(def emails
(with-open [r (io/reader (str cwd /etc/emails.clj))]
(read (PushbackReader. r
(periodically-expire 5)
(def email (mailer))
(defn notify [ egroups]
(for [egroup egroups]
(rollup 1 60 (apply email (emails egroup)
(let [index (index)]
(streams
(default :ttl 60
index
(expired
(where (service service_connect_active)
#(info expired %)
(notify :email_group_1 :email_group_2))
Code looks good (for me), but when this service is expired I get the
following error:
09:45:39 riemann.1 | INFO [2015-05-08 10:45:39,313] Thread-5 -
riemann.config - expired {:ttl 60, :time 357766884827/250, :state expired,
:service service_connect_active, :host ava.local}
09:45:39 riemann.1 | WARN [2015-05-08 10:45:39,319] Thread-5 -
riemann.config - clojure.lang.LazySeq@841649b8 threw
09:45:39 riemann.1 | java.lang.ClassCastException: clojure.lang.LazySeq
cannot be cast to clojure.lang.IFn
09:45:39 riemann.1 | at
riemann.config$eval66$stream__70$fn__75.invoke(riemann.development.config:34)
09:45:39 riemann.1 | at
riemann.config$eval66$stream__70.invoke(riemann.development.config:45)
09:45:39 riemann.1 | at
riemann.streams$match$stream__3514$fn__3525.invoke(streams.clj:1209)
09:45:39 riemann.1 | at
riemann.streams$match$stream__3514.invoke(streams.clj:1209)
09:45:39 riemann.1 | at
riemann.streams$default$stream__3731$fn__3742.invoke(streams.clj:1328)
09:45:39 riemann.1 | at
riemann.streams$default$stream__3731.invoke(streams.clj:1328)
09:45:39 riemann.1 | at
riemann.core$stream_BANG_$fn__4415.invoke(core.clj:19)
09:45:39 riemann.1 | at riemann.core$stream_BANG_.invoke(core.clj:18)
09:45:39 riemann.1 | at
riemann.core$reaper$worker__4529$fn__4539.invoke(core.clj:303)
09:45:39 riemann.1 | at
riemann.core$reaper$worker__4529.invoke(core.clj:297)
09:45:39 riemann.1 | at
riemann.service.ThreadService$thread_service_runner__1973$fn__1974.invoke(service.clj:71)
09:45:39 riemann.1 | at
riemann.service.ThreadService$thread_service_runner__1973.invoke(service.clj:70)
09:45:39 riemann.1 | at clojure.lang.AFn.run(AFn.java:22)
09:45:39 riemann.1 | at java.lang.Thread.run(Thread.java:745)
Could someone please help me? Thanks.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this
Re: Why is Caribou unmaintained ?
There's been no activity since a year ago. This may give the impression that it's dead and maybe it still quite alive. If people want a framework this one looks to be very complete. It would be a shame not to reuse all that brain power. More feedback ? On Monday, May 4, 2015 at 10:51:35 AM UTC-4, Luc wrote: Spawned from the other thread about web frameworks. Can any of the original maintainers answer this one ? According to that same other thread, it has 2 developers on it, not 0. If it's feature-complete 2 might easily be sufficient to field the occasional bug report. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure needs a web framework with more momentum
I certainly have some personality disorders, but I am not bipolar :) What am I ? Help ! :) Luc P. And never has this author proven that programmers with bipolar personality are programming more LISP then other languages. It's a metaphor. The author is not actually diagnosing Lisp programmers with bipolar disorder. The metaphor offers an image of a particular kind of student who starts stuff but doesn't finish stuff. On Sunday, May 3, 2015 at 2:52:22 PM UTC-4, Leon Grapenthin wrote: No, it isn't. And never has this author proven that programmers with bipolar personality are programming more LISP then other languages. Many larger libraries in the Clojure community are well documented and finished-off properly. Web frameworks have been tried and not been picked up. Users have chosen the modular compose it yourself approach. Framework authors have simply stopped maintaining what nobody wanted anyway or split them up into smaller pieces. On Sunday, May 3, 2015 at 8:25:22 PM UTC+2, larry google groups wrote: The web development industry as reflected in job postings at Indeed.co.uk is still dominated by the likes of Rails, Django, Laravel, Zend, Symfony Spring so I'm not sure how you've concluded that there's been a 15-year trend towards composition. That is a good point, though I would also point out that, according to Indeed.com, the use of Clojure is also growing. To me, what's important is the growth of the Clojure community, rather than the growth of some sub-community focused on a particular niche. However, I acknowledge you may have a point about the failure of any of the Clojure frameworks to take off. It's possible this is another manifestation of the Bipolar Programmer problem: http://www.lambdassociates.org/blog/bipolar.htm Brilliance and failure are so often mixed together and our initial reaction is it shouldn't be. But it happens and it happens a lot. Why? ...But brilliance is not enough. You need application too, because the material is harder at university. So pretty soon our man is getting B+, then Bs and then Cs for his assignments. He experiences alternating feelings of failure cutting through his usual self assurance. He can still stay up to 5.00AM and hand in his assignment before the 9.00AM deadline, but what he hands in is not so great. ...So BBMs love Lisp. And the stunning originality of Lisp is reflective of the creativity of the BBM; so we have a long list of ideas that originated with Lispers - garbage collection, list handling, personal computing, windowing and areas in which Lisp people were amongst the earliest pioneers. So we would think, off the cuff, that Lisp should be well established, the premiere programming language because hey - its great and we were the first guys to do this stuff. But it isn't and the reasons why not are not in the language, but in the community itself, which contains not just the strengths but also the weaknesses of the BBM. One of these is the inability to finish things off properly. The phrase 'throw-away design' is absolutely made for the BBM and it comes from the Lisp community. Lisp allows you to just chuck things off so easily, and it is easy to take this for granted. I saw this 10 years ago when looking for a GUI to my Lisp (Garnet had just gone West then). No problem, there were 9 different offerings. The trouble was that none of the 9 were properly documented and none were bug free. Basically each person had implemented his own solution and it worked for him so that was fine. This is a BBM attitude; it works for me and I understand it. It is also the product of not needing or wanting anybody else's help to do something. On Sunday, May 3, 2015 at 9:51:15 AM UTC-4, g vim wrote: On 03/05/2015 14:39, larry google groups wrote: The industry has been moving against frameworks for 15 years now. The peak of the monolithic framework craze was Struts, back in 2000. After that, people started craving something less bloated. That's why the whole industry was so excited when Rails emerged in 2004. Bruce Eckel summed up the sudden change of mood in his essay The departure of the hyper-enthusiasts: http://www.artima.com/weblogs/viewpost.jsp?thread=141312 But after awhile, people began to feel that even Rails was bloated, which lead to the emergence of micro-frameworks like Sinatra. And then, continuing with the trend, we've seen the emergence of eco-systems, such as Clojure, that allow the trend to go further: Clojure supports such high levels composition that frameworks are no longer needed. And this is the direction the industry has been moving for the last 15 years. Clojure is simply out in front. Most languages don't allow this level of
Re: Clojure needs a web framework with more momentum
Here in Morocco, the dominant web technology is... PHP. Tadaaa ! The're not even considering Raills or anything more 'advanced' for that matter. It's really an evolution ladder. People got on the 'framework' 'one fit for all band after trying things like PHP, JSP, ... and now realizing that it does not solve the issues they just leave. It will certainly happened with PHP and Rails. These solutions are geared toward some specific problem scopes. As soon as the business needs outrun what they can easily solve you are short of something else. The industry has been searching for a silver bullet solution for decades. In the early 80s, late 70s, CASE tools were suppose to be that bullet, (basic stuff in today's world, git, ant, ). Open systems then picked up, blabla, None of that fully delivered their promises. Ever. They helped climb the ladder however. In small steps... And now we have these frameworks that supposedly can ease the pain in any circumstances. They do fill the role up to a certain glass ceiling, the unforeseen business needs that make them blow in pieces because they can't be easily stretched, twisted, bended, ... Each of these initiatives were motivated by software creation automating and supposedly shrinking the costs while trying to downplay the need for an essential ingredient... Us. Wetware. I think it's a mirage. Maybe the solution has been there for decades under our eyes. Human beings. Capable of assembling solutions grater than the sum of their parts. Capable of bending the software as needed to do new stuff instead of having to fully rewrite stuff because shoes are becoming to tight. In one word adapt. This assumes that you have components to build from and people that can compose them as needed. Not some kind of frozen approach in time to software development were roles are pre-assigned and any change outside of this limited scope becomes a challenge by itself. The 'structure' needed here has nothing to do with walls and concrete. We need brain power to tear down/recompose things and stop thinking that processes, normalization, herd tagging, etc can lead us to work more efficiently. Processes, conventions, ... may help but at a low scale. Not pushed by at the scale of the whole software industry like these days Variety is the key. Luc P. On 03/05/2015 14:39, larry google groups wrote: The industry has been moving against frameworks for 15 years now. The peak of the monolithic framework craze was Struts, back in 2000. After that, people started craving something less bloated. That's why the whole industry was so excited when Rails emerged in 2004. Bruce Eckel summed up the sudden change of mood in his essay The departure of the hyper-enthusiasts: http://www.artima.com/weblogs/viewpost.jsp?thread=141312 But after awhile, people began to feel that even Rails was bloated, which lead to the emergence of micro-frameworks like Sinatra. And then, continuing with the trend, we've seen the emergence of eco-systems, such as Clojure, that allow the trend to go further: Clojure supports such high levels composition that frameworks are no longer needed. And this is the direction the industry has been moving for the last 15 years. Clojure is simply out in front. Most languages don't allow this level of composition. The web development industry as reflected in job postings at Indeed.co.uk is still dominated by the likes of Rails, Django, Laravel, Zend, Symfony Spring so I'm not sure how you've concluded that there's been a 15-year trend towards composition. Ruby and Python have had lightweight composable alternatives for many years but Rails and Django still dominate. I'm not against the composition at all. I just think we need more structured alternatives that we can at least brand and market as well as teach to Clojure beginners. gvim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to
Re: What is current best practice regarding exceptions?
1) no 2) no 3) yes at all cost 4) both, exceptions are logged with context (current bindings, etc) 5) undecided, under close examination however 6) never have to restart, we check what cause the error and correct it externally if required most errors are reported immediately, may depend on the failed process being critical or not. Up times above 250 days, restarts only required when upgrading stuff. Luc P. I'm curious, how are people in the Clojure community currently dealing with exceptions? I have a diverse set of questions on this topic. 1.) How many have adopted an Erlang die fast and restart strategy? 2.) How many use something like Supervisor to spin up new JVMs? If not Supervisor, then what? 3.) How many try to catch all exceptions and therefore try to keep the app running under all circumstances? 4.) If you use something like Kafka to log events, do you use the same log to track exceptions, or do you track exceptions separately? 5.) How many use a catch/restart library such as Ribol? 6.) In general, how bad do you expect things to be before you allow the software to die, have Nagios send a pager alert to your sysadmin, drag them out of bed at 3 AM, and have a human examine the issue and restart things manually? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Newbie question about filtrering defrecord
You mean the a1 record no ? Hi! I'm new to clojure, and have problem understanding how to filter a list of defrecords. I have tried different variations on the following: (defrecord Ape [fname lname]) (def a1 (-Ape test1 test2)) (def a2 (-Ape test3 test4)) (def alist '(a1 a2)) (filter #(= test1 (:fname %)) alist) I expect the filter to match the a2 record, but I obviously do something wrong and would appreciate any suggestion. Kind regards Magnus Jäverberg -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure, not the go to for data science
It's fun to see that vintage tools are so much appreciated these days :) Luc P. Batsov, CIDER is the best Clojure IDE. ;) -- @solussd On Mar 29, 2015, at 9:14 AM, Bozhidar Batsov bozhi...@batsov.com wrote: And CIDER isn't, right? I find this pretty insulting... On 29 March 2015 at 13:47, Colin Yates colin.ya...@gmail.com wrote: Cursive Clojure, LightTable and CounterClockwise are all good Clojure IDEs. On 29 March 2015 at 09:54, Sayth Renshaw flebber.c...@gmail.com wrote: Hi I last learned clojure in 1.2. Just curious why Clojure hasn't developed as a go to for data science? It never seems to get a mention R,Python and now Julia get the attention. By design it would appear that Clojure would be a good fit. Is it a lack of libraries, ease of install, no good default environment (R Rstudio, IPython ) where as you would need to use emacs with clojure, or is there just a better default use of Clojure? Sayth -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN][book] Clojure Reactive Programming
The 'attack' word is again a manifestation of extreme political correctness. I will argue that these technologies with their inherent complexity are creating huge bureaucracies to attract and hide unqualified/unskilled/uncommited/... aka 'stupid' people from scrutiny. These environments have the perverse effect of encouraging people not to think too much at least not publicly because of that political correctness pushed to the limit. 'You are not a team player, blablablalbla...'. 'Stupidity' is not off topic here, not at all. It's been a plague for two decades in this industry as soon as demand increased for sotfware. It started to attract people mid 80s because of the promise to get a well paid job. Not because they had above average skills or had a keen interest in it. 'I do not need to understand technology, I'll be a manager in three years'. This a real quote from a colleague when I was quite green. Meanwhile HR replaced know-how by worthless tags (add water to this pouch and you will get a Java/Ruby/... asset) and processes hoping to use a Taylor approach to creativity like if we were building cars on an assembly line. Some would argue that without this enterprise mass market, we would not have the technology we have at hand these days. True. The industry has been recycling old concepts for 30 years branding them as new. Huge costs with incremental changes. This mitigated success is limited by this assembly line model. And unlike a car plant, it cannot be robotized. You need to change wetware... Hence the 'stupidity' factor discussion. Now if the anonymity thing bugs you, I can bring forward explicit names in this thread with the failing projects, budget, ..., just let me pull my notes here... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN][book] Clojure Reactive Programming
I support your statement.
I am fed up by this extreme political correctness era.
This leads directly to auto censorship.
I met numerous 'anarchitects' who never had to bring an app from inception to
real life use but nonetheless where issuing 'profound' statements about the
last buzz word they
read from the news stand.
With unnecessary software complexity comes huge teams, dilution of
responsibilities and
expertise, aside from the one picked up through some headlines.
This leads to a lack of accountability overall.
No one is responsible, 'we followed best practices/processes according to {put
your favorite methodology name here}'
I saw 'anarchitects' fly out before integrated or acceptance tests because
they had realize that the monster they helped created could not lift from the
ground.
Human induced complexity killed it well before it started to breathe.
A kind of Frankenstein aborted experiments.
After spending zillions of customer $ of course...
If it swims like a duck, squeaks like a duck, walks like a duck, well it's a
duck.
Not some kind of abstract apparatus.
Nothing forces people to buy/listen to a book/news report/tv show/... if they
find it rude
or inappropriate to their taste.
They just have to zap like most of them are doing over any serious thinking
about
how they work, what's the purpose of it and what responsibilities comes with it.
It's already a miracle that some people are actually saying publicly what they
really think,
let's not try to cut their wings...
Pleasing the majority is the path to mediocrity.
Luc P.
Trust me I have been using Scala + Akka + Play for past three years in
production, and had to deal with tons of incidental complexity plus a lot
of noise they introduce as my daily job (in my code as well as other
developer's code). Now I am in the best position to judge and compare them
with Clojure code that does similar job but ten times simpler (and I don't
only mean 10 time less verbose).
I am sorry but I need to confess that within past 15 years that I have been
working with numerous architects most of them choose technologies only
based on 1/2 hour googling or reading reviews (and I don't mean all
architects are like this). In particular the one I rightly called ignorant
did not even write a simple poc to use AKKA and java8 to see how code looks
like.
By pathetic technology (and I didn't mean java8) I mean a technology that
you need to fish out less than 10 lines of business logic from 50 or more
lines of noise introduced by Scala futures (in AKKA), Play promise redeems,
matching classes (case classes in Scala)...
Remember when first time Spring was introduced, the original goal was to
take out all the noise and put them in XML file so the developer remain
focused on business logic. Here we are 10 or so years later: lots of noise
and complexity added to the code to do orchestration. This is work of
intelligent fool... (look at Erlang which AKKA tried to copy, it does a
powerful orchestration without introducing much complexity, this is touch
of genius)
These are the pain points in our field. I have deeply felt it and try to
point out that the life does not need to be that hard.
Clojure is the first real try in opposite direction (touch of genius)
Thanks a lot
Best regards
Shahrdad
On Wed, Mar 25, 2015 at 8:06 AM, Colin Yates colin.ya...@gmail.com wrote:
No - he is right, we just don't say it! Obviously I am kidding :).
On 25 March 2015 at 11:51, Hildeberto Mendonça m...@hildeberto.com wrote:
On Wed, Mar 25, 2015 at 12:14 PM, Colin Yates colin.ya...@gmail.com
wrote:
Hi Shahrdad, just a point of etiquette, inferring that an architect is
ignorant because they chose Java8, Akka and play is full of assumptions.
Calling those technologies pathetic is very bad poor.
As I like to quote Any intelligent fool can make things bigger and more
complex... It takes rude manners, assumptions and a whole bunch of
numptiness to claim 'bigger and more complex' means the author is a
fool.
That's why I love this community. Mutual respect is part of the
philosophy.
:-)
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups
Re: [ClojureScript] Re: ANN: ClojureScript 0.0-3115
It's up the maintainers down the food chain to keep up with changes and yes there are timing issues, not all changes/fixes can be applied synchronously. That's the idea of having libraries instead of a monolithic soup of code. Applying your statement to technology in general we would still be using horse driven carts... I appreciate the life style of Amish communities and would certainly switch to it if I could. But that's not how my world is wired presently. Luc P. On Monday, March 16, 2015 at 11:23:14 AM UTC-4, David Nolen wrote: Need more information. But that warning is most certainly not something emitted by the ClojureScript compiler. Make sure you can reproduce without whatever downstream tooling you may be using: https://github.com/clojure/clojurescript/wiki/Reporting-Issues There's a good chance it's purely downstream and needs to be reported elsewhere. The only thing the OP changed was the version of cljs he was using, and his project went from working to broken. This means that one of the changes in the new cljs broke something. Whether it directly broke the OP's code, or broke a library that the OP's project depends on, is immaterial; the location of the breaking change was in cljs itself. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Let bindings and immutability
Think about values first, symbols after. Symbols are accessory, not values, values are the only things that exist at runtime. Symbols are only there for you poor human (I include myself in this statement) to grasp roughly what is going on by tracking intermediate values with names. The names you choose are irrelevant except for your own comprehension. There are no containers per se that you can alter transparently. Some special constructs (atoms, ...) allow you to persist other values, obviously you need to name these constructs but they are not symbols, they are a special kind of value. Your code will need the value they persist, not the construct itself. (swap! is of limited interest if you never refer to the atom value). Top level vars are like the universe of values where your code will operate, a frame. Once set vars do not change. (Ok, some may use alter root but it should be reserved to specific occasions). It's all about values. This is the semantic shift compared to most languages. I do not even think about the underlying objects supporting values in Clojure unless I need to (extending with protocols, type hints, weird stack traces, ...). Implementation details :) As for interop, you enter the mutable world and the familiar rules apply here. The above 'cosmology' sums up how I think when I dive into some Clojure code and it works 99.5% of the time. There's no confusion. Luc P. On 12/02/2015 01:53, Ben Wolfson wrote: The multiple-binding form of let can be recursively transformed into nested lets: (let [name1 value1 name2 value2 ... name value] body) (let [name1 value1] (let [name2 value2] ... (let [name value] body))) All you're doing with your let form is shadowing the name; there's no mutation. If you had something like this: (let [x 1] (let [x (inc x)] (println x)) ;; prints 2 (println x)) ;; prints 1 it would be more obvious; it's less apparent in your case because there's no room for the extra forms. That explains it but I think Clojure's syntax is misleading here. Without knowledge of this magic the mind doesn't readily translate: (let [x 1 x (inc x) x (inc x) x (inc x)] x) into: (let [x 1] (let [x (inc x)] (let [x (inc x)] (let [x (inc x)] x The single bracket pair in the original leads the unwitting newcomer to assume all the x'es are in the same scope. gvim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Set equality bug?
Well if it breaks elsewhere than in your code because you mix representations
and leak
them to some library in Java that you do not control I see my comments as
absolutely relevant.
It's not technical, it's failsafe. But that might not be of any interest to
your problem scope.
However it does interest me. Hiding odd behaviors when consistency can be
guaranteed,
I have no problem with that. Here to me its very clear that there is no
failsafe approach.
Clojure is hosted on a platform that does not provide the kind if consistency
you want.
Anything you can build to hide this in Clojure is like building a tower on
moving sand.
Mark has a valid point about type safety which helps a bit in Java but you can
dig
with google and you will find people that got bitten in Java by float/double
mixing
even with type 'safety'. So long for type systems, it cannot help you with
values that
'look' the same superficially but are internally different.
For some values, floats and doubles are equal because their internal
representations are the
same. For many other values it's not working.
I suggest some readings;
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
http://floating-point-gui.de/errors/comparison/
Then maybe we can bring this thread to an end.
If there's a technical reason why Clojure can't return false for all =
comparisons between floats and doubles, I'd like to hear it. Otherwise, I
don't see how your response is relevant.
On Jan 23, 2015, at 3:10 AM, Luc Prefontaine lprefonta...@softaddicts.ca
wrote:
Agree, it's broken... in java...
Has it has been broken in the past in several architectures...
I understand your frustration but this is not something new. It's been a
problem for at least 30 years.
It is kind of a basic programming issue:
- Never compare floats with different representations.
- Never mix different representations in computations
- Convert representations as early as possible to a common format
These are the rules to follow to avoid running into trouble.
Now if you think you can overcome this persistent (ah ! ah !) problem with
some David Copperfield trick, fine.
But that's a trick nothing else. The problem will resurface in some form in
another. Better cope with reality...
Luc P.
On Jan 23, 2015, at 1:33 AM, Immo Heikkinen immo.heikki...@gmail.com
wrote:
I actually ran into this while comparing nested data structures from two
different sources and spent a good part of my day figuring out what's
happening. While it is a good advice to avoid mixing floats and doubles,
it is inevitable that Clojure users will get bitten by this once in a
while and hours will be wasted.
It is also very disturbing to realise that (= a b) doesn't always imply
(= (hash a) (hash b)) or (= #{a} #{b}) as you would think.
(inc)
This is fundamentally broken behavior. Telling people to just learn to
avoid it is not good, IMO. If the hashes must be unequal, then = should
return false.
As for backwards compatibility, note that if such a change were made to =,
it wouldn't affect anyone who was already following Andy's advice to avoid
mixing doubles and floats. IOW, it should only affect those who are doing
something you're not supposed to do anyway.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group,
Re: [ANN] dformat 0.1.0
Euuh ? I was expecting to find %5 and above and a bunch of embedded forms -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha5 now available
So far so good, will go in prod with it next Wednesday. Will run some heavy integrated tests in the next 48 hours. Will report if anything shows up. Thank you, Luc P. For my projects swapping 1.7.0-alpha4 - alpha5 has not culminated in any abnormalities. So... looking good thus far on my end. On Sunday, January 11, 2015 at 11:45:50 AM UTC-5, Plinio Balduino wrote: Hi there, Alex and Clojure team Is there a planned date for the stable version release? Regards Plínio On Sun, Jan 11, 2015 at 12:34 PM, Alex Miller al...@puredanger.com javascript: wrote: I would greatly appreciate hearing any feedback about this (or any other) alpha, even if it's just: everything looks ok. We've had a couple of regressions reported and that is hugely helpful as we can quickly turn around fixes for the next one. Interested particularly in: regressions, performance +/-, and for this alpha, AOT. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure Style Guide
Defaults only please. There are more pressing needs from dev tools than this sort of thing. Diversity is what makes us well... different. Our minds are not formatted the same either. What may look readable to someone may look like garbage to someone else, the context may also influence comprehension. If a business wants a more or less strict code style fine. It may well be a decent requirement given their domain. If they need to tweak 50 variables it's also fine, it's an investment they are willing to make. At various times in the past, focus has been on 'standardizing' how code is written, up to choosing variable names, presentation, ... While this may have been valuable in some contexts, no unique agreement has been ever adopted and the impact on software quality is nil. It may help a given team to agree on some conventions but in the large it's not worth the energy it sucks. I suggest reading a 'Brave New World' for those who think that a stronger initiative than defaults is required :) Or punch out a few thousand cards of Cobol code lines to get the feeling... Luc P. Sent from my iPad On Dec 20, 2014, at 09:57, Colin Fleming colin.mailingl...@gmail.com wrote: Yes, perhaps just agreeing on sane defaults is a more achievable goal. Cursive currently does not indent everything exactly according to the guide by default. I would also not like to see tools' ability to implement more sophisticated formatting hampered by an overly restrictive guide either, since a lot of users have requested that Cursive do different things with particular forms, but having agreed defaults doesn't conflict with this. On 20 December 2014 at 22:51, Laurent PETIT laurent.pe...@gmail.com wrote: I agree that if all tools could agree on sale out of the box defaults, this would be very valuable to users and clojure in general. Maybe a less ambitious goal than getting the whole community agree on standards could be tool authors to agree on shared defaults. Which of course doesn't prevent the tools to offer additional options, but activating those would require users to explicitly customize the tools settings. Le samedi 20 décembre 2014, Lars Andersen ex...@expez.com a écrit : My view on this is very much along the line of discussions about whitespace. While I have opinions about these matters, for the most part I don't want to think about it--I have more pressing concerns. What's important to me is consistency within a code base. Just like with whitespace, I don't want to introduce spurious changes into all my diffs when working with other people. I also don't want to customize 50 editor variables to get sane defaults which I have to tweak for various environments (work, home, contributing to open source projects). Supporting different styles is a laudable goal, but I hope we can agree that the defaults should be similar in all editors to reduce friction when working with others. Using a style guide maintained by the community for those defaults make a lot of sense to me. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Laurent Petit -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are
Re: clojure.edn won't accept clojure.java.io/reader? How to work around this and why isn't this documented anywhere?
Dunno the answer but I know how many buddhist monks are needed, exactly three: a) the first one readies itself for the bulb swap! by repeating a mantra b) the second meditates to make the first monk levitate toward the fixture c) the third one immolates itself to provide light for the entire duration of the operation Sorry for all the buddhist monks that may be offended by the above :) I like black humor very much and this is probably the only joke that I can write on this list that will not qualify me hopefully for eternal damnation... Euh moderation... Luc P. Sent from my iPad On Dec 8, 2014, at 20:11, Matching Socks phill.w...@gmail.com wrote: How many programmers does it take to change a light bulb?! http://dev.clojure.org/jira/browse/CLJ-1611 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Thnx for clojureconj videos !!
+1, could not make it to Washington, my agenda was tossed upside down last week but with these at least I am not missing all of it. Thank you, Luc P. Thank you very much for clojureconj videos !! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha3 now available
Encrypted fs have a file path limit around 140 bytes vs 255 w/o encryption. I hit this problem a couple of months ago with a library and AOT. The library had pretty long fn signatures, some generating class file names around 110 bytes long. The author tweaked these a bit to shorten the class file name. If I recall most of these where anonymous fns. With 140 (143 in my case) bytes you have to shorten the folder path as much as you can if you expect compilation to succeed and avoid fns with complex signatures. Luc P. I hit this error when moving to a new box that had an encrypted FS. Might be related to your case as well. Good luck. On Wednesday, October 29, 2014 1:34:28 AM UTC+11, Stefan Kamphausen wrote: Hi, have there been any changes how fns with a name and recursion are compiled? One of my projects has a function which does not compile with 1.7.0-alpha3 anymore, but did fine with 1.6.0. I tried to create a minimal example at https://github.com/ska2342/nested-fn-breaks-clojure-17 (I know the function itself is probably stupid, I just wanted to demonstrate the case. I don't know if it even runs.) Compilation breaks with a java.io.IOException: File name too long The problem seems to be the combination of * using a long function name (not a bad thing per se), * using a rather long name for a local binding (not common in Clojure-land, used in my case for documentation of the intent of the anon fn), * and using a name for the anonymous function (needed for recursion and usually a good idea because it improves stacktraces, but maybe you added the local binding to the name for exactly that reason). Regarding the second (long var binding name), my original function uses shorter names, but has some nested constructs (for, cond, ...) which seem to make the name larger, too. There is really nothing unusually long there. Of course, I can work around this by using different names, factoring an inner anon function out to a defn and probably in other ways. I just wanted to make sure, that you are aware that problems like this may show up and made the change on purpose. Thanks, stefan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: CCW bug [SEVERE]
Just curious, how can you expect a fix if you do not provide any information that could support a serious investigation ? I read the eclipse log file from time to time and guessing which error is relevant or not is an educated guess at best except if you are deep in Eclipse plugins coding. Creating an issue in the ccw project page takes under a minute including attaching the log file. If you expect the developer to find the root cause from thin air, you will wait for eternity. Laurent is very proactive in investigating problems but w/o any grounds, he's better having a glass of wine than trying to guess what happened here. I would do the same... Luc P. On Friday, October 31, 2014 2:24:04 PM UTC-4, Laurent PETIT wrote: Also, if you can attach the workspace's .metadata/.log file, I can take a look at it. I have no idea how to reproduce it, which is part of the problem: I don't know what to avoid doing, in order to ensure it doesn't happen again until an update to CCW fixes it for good. As for that log file, I had a look and there's nothing that identifies the problem. The log entry immediately prior to the hang is a complaint that some map literal has an odd number of forms, which I must have left incomplete when I went to make that other edit. There are lots of other similar entries, probably from other times I saved while there was a half-written map literal on my to-do stack, and it didn't hang on any of those other saves. The log entry immediately following that one is a session start message. So whatever was different that one time does not show up in the log, unfortunately, rendering the log unhelpful in this instance. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Demoralising experience trying to install on Win 7
Microsoft not wanting to confuse the end user ?!?!?!? I am baffled :))) Luc P. I'll take a wild guess and say the flashing properly is a console with a message Microsoft don't want to confuse you with. That said, the message i get here, is that wget is missing. Leiningen ships with curl.exe. Not knowing any bat syntax at all, i was enable to get lein.bat downloading by uncommenting the wget part out. One could try to move the curl part above wget also. Your lein.bat file might be in \Users\name\.lein\bin\lein.bat I'll create an issue on github. Thanks for noticing, good luck. /Kevin (mobile) On Oct 25, 2014 6:34 AM, Geoff Caplan ghcap...@gmail.com wrote: Hi Wanting to get Clojure running on a Win 7 machine with no diskspace for dual boot. It's been a demoralising experience. I tried the Win installer linked from the Leiningen website. It failed to download the Leiningen 1 jar - the shell simply flashed open and crashed. Dug around the git site and found a recent .bat file that's supposed to work with the latest Leiningen 2. Again, the shell flashed and crashed. Then manually downloaded the latest Leiningen 2 preview. Again running lein simply flashes and crashes the shell. There's been a recent open issue on Windows installation but it's supposed to be fixed. The lein.bat file is on my path and has exec permissions. I have Java 8 SDK installed and healthy. Not sure where I go from here - any advice much appreciated. I'm dithering between Clojure and Haskell for my next project. The Haskell community provide a well-maintained batteries-included Windows install for GHCi - I was in the Repl 60 seconds after visiting their site. I've been struggling with Leiningen for an hour and getting nowhere. It seems a great pity that the Clojure community seem to be ignoring those of us who are stuck with Windows - it must be having a negative effect on the uptake of the language. I see that this has been an issue for years, but hasn't been addressed. I'm more drawn to Clojure than to Haskell, but if I can't get it running I'll be forced to go elsewhere. Please help -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
+1. Two years ago we went all data driven here. We stripped the code size and complexity by a huge factor. All data encapsulation code was sent to the trash can. Our processing is driven by data more than by code. We ended up with a significant increase in generic code not linked to the business domain and the rest is made up mostly of DSLs. What a relief Luc P. On 18 October 2014 08:28, Mark Engelberg mark.engelb...@gmail.com wrote: Yeah, it's hard to deny the convenience of Clojure's keyword lookups and standard assoc mechanism for getting and setting stored values, but I think Bertrand Meyer's Uniform Access Principle reflects some pretty deep thinking about the kinds of complications that arise in maintaining large programs. Although the Clojure community mostly rejects the Uniform Access Principle right now, as people start writing larger programs in Clojure, and need to maintain them for longer periods of time, it will be interesting to see if the pendulum swings back in favor of uniform access. You make it sound as if structuring an application around data, rather than APIs, is untested at scale. I'd argue the opposite: the only architecture we know works at scale is data driven. The largest systems we've developed, including the web itself, are data driven. Above a certain size, they have to be, due to latency and consistency concerns. Structuring a large system into isolated services that communicate with data is a tried and tested architecture. There may be a place for the Uniform Access Principle at the medium scale, where an application is large, but not so large it can't be hosted on one machine. I don't think the relative merits of data-driven vs. api-driven approaches has been proven at this scale. That said, I think there are reasons for betting on Clojure's approach. Ultimately it comes down to whether we try to *manage* complexity or *remove* complexity. The Uniform Access Principle falls in the former camp, along with OOP and encapsulation. They're tools to manage connections between components of a codebase. Clojure takes the more aggressive stance, and suggests that rather than managing complexity, we should be focused on getting rid of it wherever possible. For instance, where OOP languages try to manage state change though encapsulation, Clojure just removes mutable state entirely, or at least places it in confinement. Where complexity *can't* be removed, then we start to get Clojure code that begins to look similar to OO designs. Stuart Sierra's components, for instance, look somewhat similar to stripped-down objects. The difference in Clojure's approach is that these constructs are a last resort, rather than the norm. - James -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
Hi Phil, At some point in time after a prolonged exposure to Clojure, my mind shifted, I now think about my program flow as values, not containers being passed along. I take the problem the reverse way to find out if there's a need for a var vs a fn and state lifecyle. Here's a short summary of my reasonning: a) I just find out how long a value need to 'survive' to decide how to implement it's access and its scope. Most of the time values are ephemeral so the answer is obvious, a local binding is enough if there's a need to name it. b) If a value is required during the lifespan of the process then his scope is probably global and a var is an obvious choice. c) If a value reflects a state (as understood by clojure) that will change in time then an atom or ref can be used. Then its scope determines if it will end up in a var or not. I try to wrap a state lifecycle in a API. Most of the time leaking to the outside world involves too much refactoring, it may look simple at the beginning but you get caught in a forest fire at some point. d) I try to stay away from dynamic bindings except in rare cases (syntactic sugar for DSLs, ...). e) I do not consider Java objects as values. Their internal mutation disqualifies them to me. They seldom make it in a var in my world except when there's no other choice (database connection pool, ...). I try to confine them at the edge of the code and wrap their access in a function. If possible I try to avoid leaking them to the outside world. I try to shorten their lifespan even if it means that they will get reallocated more often. The main reason being that I want to avoid having to think about things like are they multithread safe ? To they have a finite lifecycle which prevents reuse ? They will get buried in a value as we know it in Clojure if they have to leak out. Makes it a bit harder to access them directly. If a Java object lifecycle has to leak, I wrap it in a API that relates to the application state, not to the object itself. The net result is that my code has few vars aside from the functions themselves and less state concerns. I agree that it requires some brain cells rewiring. I went along that path the first year I worked non-stop with Clojure. Luc P. Actually, I think that this is a real problem with Clojure, and with data access. It is very hard to change between accessing a var as a value and through calling a value. I can give two concrete examples of this. First, in my library I used a var to store a factory object from a Java API. So I created one and stored it in a var. This worked well, in general, but when I integrated my library into an application, I realised that I need to get this factory object from elsewhere -- in short I needed a function call. So I had to change all of my `data-factory` calls to `(data-factory)`. Another time the same issue hit me was with Clojure's :doc metadata. This is stored as a string, but I wanted to be able to subvert this by calculating the string from the object containing in the var. As far as I can tell, this is impossible in Clojure without changing all the client code that accesses the :doc metadata. Java does not have this problem by common design patterns -- fields are declared private and always accessed through a function. If I understand things correctly, Scala avoids the problem in the same way, although it autocodes the accessors for you, so avoids the boilerplate. In Clojure, it seems the only way to avoid this would to wrap up values in `constantly` and access everything as a function. Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving
Re: ClojureDocs.org
We use Rails for all our GUIs, we need simple CRUD most of the time and we ActiveScaffold. Most of our controllers are less than 70 lines and we seldom write forms. We use the ActiveScaffold partial forms almost every were sometimes custpmizing them. Clojure Web Frameworks are not there yet. We monitor the situation however and will change our mind as soon as it looks promiding... Zack, keep the focus on the problem to solve :))) Luc P. Sent from my iPod On 2010-07-11, at 19:31, zkim zachary@gmail.com wrote: Rich- It sounded to me like he was only saying that he's more familiar with Ruby/Rails than he is with Clojure. Correct. I think it was a fair question, and I'm happy to provide insights into my decision making process. -Zack On Jul 11, 12:37 pm, Richard Lyman richard.ly...@gmail.com wrote: On Sun, Jul 11, 2010 at 8:14 AM, Phil Hagelberg p...@hagelb.org wrote: On Sat, Jul 10, 2010 at 11:23 PM, zkim zachary@gmail.com wrote: but what do you think about using Justin's codebase, or an Aleph- based server to host the thing instead of Ruby/Rails? (see the link above for more details) I'm inclined to move forward with the Ruby / Rails for now. The reason I went with rails is that (in my experience) none of the clojure web libraries are mature enough to do something like clojuredocs as quickly and easily as I personally would be able to do in rails. Could you provide details about what it was specifically that you found was lacking? -Phil It sounded to me like he was only saying that he's more familiar with Ruby/Rails than he is with Clojure. It seemed like it was a question of 'time to finish and tweak' that's shortest for him if he wrote it in Ruby/Rails. Maybe this is a good opportunity to be able to compare two implementations side-by-side. His excellent solution with one written in Clojure that produces the same-ish website. -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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureDocs.org
Zack if you need help with this Rail app let us now. We can give you a hand, the wish list keeps growing :))) Luc P. Sent from my iPod On 2010-07-09, at 15:07, zkim zachary@gmail.com wrote: Hi Justin, thanks again for the go-ahead to pull examples from http://clojure-examples.appspot.com. Zack, you had mentioned you planned to keep the source of your site proprietary -- is that set in stone? Definitely not set in stone. As far as the site goes there's not much Clojure going on there (rails / mysql), and I'd rather keep that part closed for now so I can concentrate on moving from alpha to beta, adding features, and fixing bugs. The analyzer, which pulls metadata / source from libraries, and inserts it into the database is a different story. Other than the fact that it's extremely hackish, nothing's really stopping me from EPLing it in the near future. You also mentioned an API / export process, which I think is a great idea. This would allow examples to be easily exported to prevent vendor lock-in. -Zack On Jul 9, 12:44 pm, Justin Kramer jkkra...@gmail.com wrote: I've told Zack that he is free to pull any examples from the wiki for use on his site. I don't know about collaboration beyond that. The wiki is open source and written in Clojure; anyone is free to contribute/fork. At least one person has expressed interest in making code contributions. Zack, you had mentioned you planned to keep the source of your site proprietary -- is that set in stone? Justin On Jul 9, 12:21 pm, David Nolen dnolen.li...@gmail.com wrote: On Fri, Jul 9, 2010 at 4:32 AM, zkim zachary@gmail.com wrote: Questions / thoughts? -Zack This is great. I think the main thing is not duplicating effort. This and clojure-examples.appspot.com should really join forces. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure for NSF grant funding
Here in Canada we have a number of programs for RD and the bureaucratic burden is not worth the $$$ you get back for it except if you a budget in the 6 digits range. And if you want to get the paper done by a consultant, he/she will charge 20% of the expected refund. I looked at the NSF documentation and I am not convinced that the red tape is minimal. You certainly loose some flexibilty by having to get scope changes approved by them. Anyone got involved with them ? Luc P Sent from my iPod On 2010-07-07, at 14:49, David Blubaugh davidblubaugh2...@gmail.com wrote: To All, I am extremely interested in LISP and Clojure. I was wondering if it would be possible to obtain NSF grant funding for further development of Clojure ?? thanks, David Blubaugh -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Let's respect CLOJURE_HOME
We use a HOME reference in our quite complex software and I think we do not qualify as n00bs... Any root symbol that can help derive locations is just common sense to us. It's not used internaly in our code (Clojure/Java/Ruby) but it's obviously a simple way to bootstrap our apps and establish a common ground in the supporting scripts we use. It helps structuring the file space were all our components reside in dev test and prod. Honestly, by the time this thread ends on that simple and obvious matter, Clojure 1.5 will be released... Luc P. Sent from my iPod On 2010-06-30, at 17:48, Greg g...@kinostudios.com wrote: However, I don't see it helping newcomers to Clojure significantly With respect, I'm a newcomer to Clojure, and the CLOJURE_HOME convention would help me significantly. :-) I think something that needs to be acknowledged is that newcomers and n00bs are not necessarily idiots, they're just new to the platform, and they're coming from places where, as Brian pointed, they're used to there being a central location for things (PYTHON_HOME, ANT_HOME, etc.). Lieningen or maven don't really fit with this approach as they treat the clojure platform as just another library dependency. Yet Maven has a MAVEN_HOME. :-) Even if Leiningen/Maven ignore CLOJURE_HOME, that's fine, it certainly doesn't hurt to adopt CLOJURE_HOME as a convention for scripts that currently hard-code clojure.jar's location, or download it themselves, wasting space and adding confusion. When that happens it's hard to know what version of Clojure these scripts are running, and it makes it unwieldy then to interface it with your own code. A problem, I think, that doesn't just affect newcomers to Clojure. and I'm not sure this is something we should really try and hide. CLOJURE_HOME doesn't hide anything, it's set by the user after all. Cheers, Greg On Jun 30, 2010, at 5:17 PM, Rick Moynihan wrote: On 30 June 2010 21:14, Brian Schlining bschlin...@gmail.com wrote: May I propose as a possible remedy CLOJURE_HOME. CLOJURE_HOME is the absolute path of a directory containing clojure.jar and possibly clojure-contrib.jar. Scripts should check if it's defined and use it instead of hard-coded paths, as an example, here's my clj script (in newLISP): On the face of it this seems like a good idea, however it doesn't really fit with the models used by tools such as leiningen, mvn or the JVM. At best a CLOJURE_HOME initiative can only expect to work within its own world of clj scripts etc. I can't speak for leiningen but many (most?) launcher script in the Java world use this as a standard convention. If you look through the launcher scripts for maven, groovy, scala, ant, etc you will see environment variables JAVA_HOME, M2_HOME (for Maven 2), GROOVY_HOME, SCALA_HOME and ANT_HOME. This is true. And I agree that where scripts are used this technique can be useful. And in this regard it's a good convention. However, I don't see it helping newcomers to Clojure significantly, as the classpath issues people face are the deeper issue. Also teaching newcomers that this is the convention isn't really true, as tools like Lieningen or maven don't really fit with this approach as they treat the clojure platform as just another library dependency. Clojure doesn't yet have a standard launch script. In the past I've argued that it'd be nice if it had one, though I now feel lein/mvn are better tools for this job. That said, having a clj launch script can be useful, and might ease the out of box experience, but again the true launcher will always be the java JVM executable, and I'm not sure this is something we should really try and hide. R. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Managing the classpath
Yep, we have been using this for a year or so and this solves the classpath/jar file location issue nicely. Hence the usefulness of CLOJURE_HOME and alikes to locate this single folder from a very simple wrapper script... Luc P. Sent from my iPod On 2010-07-01, at 10:29, Laurent PETIT laurent.pe...@gmail.com wrote: Hello, note that with java 6 you can specify at once to add all the jars located in a directory: java -cp libs/* clojure.main and you can place any jar you want in directory libs. and this is composable: java -cp clojure.jar:libs/* clojure.main My 0.02€, just in case you didn't know this (rather recent) possibil ity. 2010/7/1 Paul Moore p.f.mo...@gmail.com: First, a disclaimer - I don't have any problem with the idea of the classpath in Java. In principle, it's pretty similar to Python's sys.path. And jar files are much like Python having zip files on sys.path. So I'm familiar with the idea. Where I struggle is with the practicalities of managing the classpath. From what I can tell, there is no way of modifying the classpath from a running Java/Clojure program (barring use of a custom classloader which sounds like deep magic). So, assuming that is right, I need to list my dependencies in advance, when I start the JVM (either by setting the CLASSPATH environment variable, or with the -classpath argument). Generally, I avoid using global environment variables like CLASSPATH (except if they are locally set in a wrapper script), so I guess that I have the following options for my Clojure applications: * Use something like lein uberjar to wrap all my dependencies up in one file * Create an application-specific wrapper, which sets CLASSPATH (or uses -cp) and runs my application I have personal reservations about both of these options (I won't elaborate, to avoid boring people with my prejudices - ask if you really want to know) so I guess my question would be - is there another option I have missed? Python doesn't have these issues because (a) conventionally, dependencies are installed into the site-packages directory which is on the standard sys.path - it appears to me that the JVM doesn't have such an always available install location, and (b) for special cases sys.path can be manipulated at runtime (as noted above, the JVM doesn't really have this option). One further question - does having a lot of entries on CLASSPATH slow down JVM code (either at startup time, or in terms of slowing down runtime class loading)? Essentially, is there a cost to including things like clojure-contrib just in case? (I don't imagine that the cost would be significant for just one such case, but I could imagine that if the practice were to become common, it wouldn't be long before there were many extra entries, not just one). I appreciate that this question is only tangentially Clojure-related. If there is a better forum to discuss this type of question, please feel free to direct me there. Thanks, Paul. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Managing the classpath
We have over 130 jar dependencies on our classpath and performance is not an issue. After the classes you are using are loaded at least once, there are no significant impacts. Each app refers to the same shared lib folder so we update a single jar and get every app gets the update after a restart. Very different from a uberjar. Every uberjar would have to be repackaged to include the updated jar. We use uberjars to deliver desktop apps. We do not update these as often as the back end and avoid dealing with the desktop environment as much as possible. Back end stuff use the shared jar folder. Luc P Sent from my iPod On 2010-07-01, at 10:49, Paul Moore p.f.mo...@gmail.com wrote: On 1 July 2010 15:29, Laurent PETIT laurent.pe...@gmail.com wrote: Hello, note that with java 6 you can specify at once to add all the jars located in a directory: java -cp libs/* clojure.main and you can place any jar you want in directory libs. and this is composable: java -cp clojure.jar:libs/* clojure.main My 0.02€, just in case you didn't know this (rather recent) possib ility. Thanks. I had actually just discovered this possibility in the last few days. In fact, it is what raised in my mind the question of whether having too many jars on the classpath would hurt performance. I've not yet fully integrated the idea into my thinking. I guess it allows the possibility of bundling all application dependencies into a lib directory, then doing something like java -cp clojure.jar;lib/* clojure.main myapp.clj But in practical terms, I guess that's the equivalent of an uberjar. (My biggest concern about an uberjar is that I end up with each app having a separate bundled copy of all its dependencies. That makes version management a huge pain - imagine a bugfix release of clojure.jar - but is otherwise not an unreasonable option). Paul. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Newb Question
(apply str (repeat 3 code)) should start you up :)) Iteration is implicit in Clojure, you work on collections (maps, vectors, ...) and you avoid explicit loop controls most of the time at least for mundane tasks. You will get used to it, we all did and no one wants to return to java iterators now :))) Luc P. Sent from my iPod On 2010-06-27, at 14:22, José Luis Romero tangu...@gmail.com wrote: Hi! I am learning the core of clojure, and so far, I am loving it. But I am not a lisp programmer (python, java, among others), but never functional programming. I am practicing with codingbat.com, coding the exercises on clojure. I am stuck with loops. I want to concatenate n times a string. For example, given the parameters 3 and code the output will be codecodecode. How can I do a loop in order to get this output. I know that this is a very newb question, any help will be appreciated. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: State of Clojure web development
Were not using Clojure yet for our Web based GUIs. The main reason being that we jumped on Rails last year. Most of our needs are to display/edit database data and the ActiveScaffold plugin allows us to write a controller in 20 lines. We do not need to write forms, it's all done through partial renderings provided by the plugin. We just provide layouts and customize CSS stuf. We will give a closer look to Compojure this year and see if can achieve the same code ratio somehow. Luc P Sent from my iPod On 2010-06-24, at 12:27, Daniel Gagnon redalas...@gmail.com wrote: I don't use Clojure for web development and I thought sharing why could be useful too. For web development, my favourite tool is Django. It comes as a fullstack framework which means I have everything I need out of the box. Templates, caching, ORM, a kick-ass autogenerated admin section, cross-domain request forgery protection etc. and the documentation is really top notch. I'd rather have Clojure than Python but all the goodness that Django provides is such a time saver that I feel I'd lose too much time with Clojure. If I had a full-stack, well-documented clojure framework, I'd jump to that. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
++1 for auto promotion, average code is complex enough, lets not add more incertainty with overflow exceptions. Data changes overtime and discovering it in production with an overflow exception is less than elegant. Degraded performance is much more acceptable in production than a crash over an unhandled exception Again, if performance is critical for a library or an application then it's up to its designer to take action. For the other folks, they will get the best implementation according to the number size they crunch in their data. No need for them to pay the price for control they do not need yet. Luc P Sent from my iPod On 2010-06-22, at 12:44 AM, Mark Engelberg mark.engelb...@gmail.com wrote: The new uber-loop is fantastic. So I guess the main point still to be finalized is whether the default arithmetic ops will auto-promote or error when long addition overflows. Playing around with the latest equals branch: user= (def n 9223372036854775810) #'user/n user= (* (/ n 3) 3) 9223372036854775810N user= (* (/ n 2) 2) java.lang.ArithmeticException: integer overflow user= (def x (/ n 4)) #'user/x user= (+ x x x x) 9223372036854775810N user= (+ (+ x x) (+ x x)) java.lang.ArithmeticException: integer overflow user= (range (- n 2) n) (9223372036854775808N 9223372036854775809N) user= (range (- n 3) n) java.lang.ArithmeticException: integer overflow I understand exactly why some of these work and some of these don't. My main point here is to illustrate that without the full numeric tower supported by the default ops, there can certainly be some surprises. There is a pathway with the standard ops from longs to rational numbers to bigints, but you can't cross directly from longs to bigints. Similarly, you can roundtrip from bigints to rationals and back, but can't roundtrip from bigints to longs and back. So the results of computations depends on the path you follow. Maybe we can live with these idiosyncrasies for the speed benefits, but this is worth being aware of. The range example is something that is easily enough fixed. Probably if this branch becomes the standard, range should be modified so that if the *upper bound* is a bigint, inc' is used rather than inc to generate the range. But I think this illustrates the kinds of issues we're headed towards, regardless of which default is chosen -- people who write libraries will be choosing between overflow and auto-boxing primitives, and it might not always be clear from documentation what the consequences are. In the current implementation of range, it works perfectly fine with longs, and it works perfectly fine with bigints, but it breaks when your lower and upper bounds cross the boundary. This is exactly the kind of thing that might not be thought of when making test cases, so errors like this could lurk for quite a while without being spotted. The people on the side of overflow-error-as-default feel that these sorts of runtime errors are no more problematic than the many other sorts of runtime errors that can result in Clojure, such as an out-of-bounds exception when accessing a vector. But I see these types of errors as very different. An out-of-bounds exception is easy enough to prevent -- there is a simple test you can include in your code to make sure your index is in bounds before you access your vector. But I think it's much harder to determine in advance whether a sequence of computations will cross the long boundary for all the possible inputs. This is probably the main reason I continue to advocate for auto-promoting ops as the default. Error-upon-overflow adds an element of run-time risk, and requires careful thought and additional testing to achieve the same level of reliability. I *want* error-upon-overflow operations to be slightly harder to use so that library writers will use them judiciously and consciously, and be very aware of the extra effort they need to go to test their functions for all numbers, clearly documenting any restrictions on the kinds of numbers that are permitted. Like I said before, Clojure's built-in range can easily be adjusted to work well for speed *and* handle both longs and bigints gracefully. But it serves as a good example of how the two defaults will affect library writers. If auto-promotion is the default, most library writers will just use the +,*,-,inc,dec operators and it would work for all numbers right out of the box. A library writer who wants to optimize for speed would have to go to a bit of extra effort to add the apostrophes, and would hopefully at that point give some careful thought as to what the consequences will be, catching the fact that this will break ranges that span from longs to bigints, and adjusting the code accordingly. On the other hand, if overflow-on-error is the default, this is what most people will use, and we'll end up with a lot of code that breaks when crossing the long boundary. I don't use any bigints, or anything even close to
Re: Enhanced Primitive Support
If the maintenance cost of keeping both options in the Clojure run time is reasonnable it's fine with me. Rich is the best person to answer this. Otherwise, auto promotion should be the winner... And the default ... The vast majority of apps these days are not gravitating around high performance numeric computations. Forcing people to deal with this in mundane code would be insane in the long run. Reminds me of C in the early days when we needed to keep and eye on what was a byte, a short, an int or a long on the different hardware platforms... If we want Clojure to remain a viable option lets keep some usage simplicity a primary goal. When I want to scratch every bit of performance, I expect to kick my butt out to get it but after I have some working code running, not while I scratch my head about getting it done. Proposals up to know regarding specific operators for various implementations provide plenty of options to attain the nirvana of high performance. That's good. Lets just make things easy for the average guy.., Luc P Sent from my iPod On 2010-06-22, at 7:53 AM, Nicolas Oury nicolas.o...@gmail.com wrote: On Tue, Jun 22, 2010 at 12:45 PM, Luc Préfontaine lprefonta...@softaddicts.c a wrote: Data changes overtime and discovering it in production with an overflow exception is less than elegant. Degraded performance is much more acceptable in production than a crash over an unhandled exception Depends in which production. That's why I defend a way to choose default. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
As the implementor Rich, it's your call as I said :)) If auto promotion brings in chaos then lets drop it entirely. If people want to eat elephants they can still choose to use directly big number implementations. Luc P Sent from my iPod On 2010-06-22, at 10:46 AM, Rich Hickey richhic...@gmail.com wrote: --- The claim that this primitive stuff is just for numeric-intensive applications is outrageous and false, and ignores the implementation of Clojure itself to an embarrassing degree. I've worked my tail off to reduce the number of allocations inside things like sequences etc to the absolute minimum. Now down to 1 per step, and with chunks 1/32 per step. Moving from 1 to 2 or 3 per step would result in a 2x to 3x slowdown for every consumer of these fns. Everyone has to realize the math you are advocating for the default, on non-tagged architectures like the JVM and CLR, *must* do an allocation on every +/-/* etc operation. And such ops are littered throughout non-numeric data structure code, for indexes, offsets, bounds etc. Allocating on every math op in something like the persistent vector would make it completely unusably slow. The languages being pointed to (Ruby, Python, Mathematica) write their hard bits in C, or, for the J versions, Java. Well, guess what, all of the things I've written in my career have been hard bits. Those languages were unusable for any of my production work, for performance reasons. I wrote Clojure so I could stop writing Java and C#, not Ruby, because I couldn't have used Ruby in the first place. And, I think some people are considering moving from Ruby to Clojure, for the hard bits of their systems, in part *because* Clojure has a better performance profile, their alternatives being Java or Scala, not Python or Groovy. Now you're all sitting on the end of the food chain, eating gazelles and saying, 'who needs photosynthesis to be easy'? ;-) I do. And so do you if you appreciate fast gazelles. You wouldn't be able to use a Clojure written in the default Clojure you are advocating. 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
I find these compromises quite acceptable. Tuning code has always been a last step in most dev. projects I worked on except a few and I worked on many resource constraint platforms. All languages I encountered had a default integer/float implementation and getting away from it rarely occured but was doable if needed either through some coding trickery or compilation flags. The mass majority need a simple approach/implementation and this proposal meets this requirement. Having to care about the number sizes is not the first design concern. As for callers using the default implementation, some API trickery could allow them to call a library using a different implementation and get return values in a compatible way if it makes sense. Specialized libraries could still force callers to use the same implementation if you really need the same performance or precision in you own code. For specialized arithmetic implementations, I find the namespace approach interesting. It may prove valuable since at a glance the implemtation chosen by any piece of code would be pretty obvious. Changing from one implementation to another one could possibly be easier to do with this approach. Swapping the name space or adding one to overload the default one is quite practical. The line by line annotation is a painful approach to such changes and should be only required in rare cases (mixed operand computations ?) Luc P. Sent from my iPod On 2010-06-20, at 6:39 AM, Nicolas Oury nicolas.o...@gmail.com wrote: It seems to me that there is mainly 2 categories in this thread: - people that are worried about the difficulty to understand and to code with the throw-on-overflow semantic. They worry about untested cases showing in production code and the steeper learning curve of the language. (I am not of this side, so please forgive me if I don't understand the argument well enough) - people that are annoyed to lose some speed everywhere in programs, in a way that can't be easily profiled or solved without annotating every lines. People that also believe it is rare and predictable to overflow a long. I think both arguments are valid, and that most people won't change their mind on this subject. In consequence, I would like to advocate a proposal along the lines of: - A set of operations per return size, labelled by their size. +- long, +-boxed, +-float,+-double ... (I am not good with name, so I am sure other people can come with better names) . They are overloaded on their arguments, but indicate return size (I think that's what the last branch does, but then again I might be totally wrong). - A set of operation without annotations : +, - ,... By default, these operators map to +-boxed, --boxed,... This solves the worries about the steep learning curve, because for beginners the story stops here. There is a flag allowing to change the default value, (or a namespace trickery, but it make it harder to apply to library code). That should come with some coding convention: - use +-boxed when you write a function that creates int exponentially bigger that its argument. (fact is in this category) - use +-long when you write code abound integers bound to a resource (indices, counters and the like...) - use the untagged operators in the other situations, +-boxed when in doubt. I would also advocate that there should be a +-small family that is either +-long or +-int depending on the platform. (+-long on modern computers, but open the way to +-int on phones, or +-double on Javascript platform where there is no integer, if I am no wrong.) For those worrying about a semantic-changing flag, I would like to note that it is not semantic-changing, it is only resource-size changing. You answer the question : what is the size of an integer? It is not different than choosing your heap size. If you don't have enough resource there is an exception (not a silent failure, so this is safe) and you can add more resources. I like this because: - it gives a clear story for beginners - it gives an easy way for people having very important production code (like a server), that does not need very high performance - it gives an easy solution for people having some code that need higher performance - it paves the way for other platforms - it is a pay-as-you-go approach, you don't have to understand any of that before you need it. What do you think? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send
Re: Enhanced Primitive Support
I would expect a library to internaly work with whatever is the best implementation and provide an API to allow callers using another implementation to use it. I also expect a library to complain about a potential overflow and maybe some precision loss. That's not different from what you can see on many platforms over the last 20 years. Multiple float implementations existed on the same platforms for years and you had to choose one considering performance and precision. Of course this requires some discipline by the library provider but the performance requirements may dictate that choice depending on its purpose. Luc P. Sent from my iPod On 2010-06-20, at 8:35 AM, Paul Moore p.f.mo...@gmail.com wrote: On 19 June 2010 15:26, cageface milese...@gmail.com wrote: Maybe it's only because I'm coming from Ruby, in which number promotion is automatic and everything is slow, but if I have to choose between correctness and performance as a *default*, I'll choose correctness every time. I think there's a good reason that GCC, for instance, makes you push the compiler harder with compiler flags if you want to squeeze extra performance out of a program and accept the corresponding brittleness that it often brings. I also always thought that the transparent promotion of arithmetic was one of the strongest selling points of Common Lisp. My impression has always been that performance of numerics is rarely the bottleneck in typical code (web stuff, text processing, network code etc), but that unexpected exceptions in such code are the source of a lot of programmer heartache. On the other hand, I think 99% of the cases in which I've had a number exceed a 64 bit value were also examples of errors that might as well have been exceptions because they indicated a flaw in the code. s/Ruby/Python/ and this is pretty much precisely my view. I haven't yet hit this situation in Clojure, but a common type of program I write is to collect and summarise database stats for a range of systems we support. Here, tablespace sizes range from a few hundreds of MB, to the half-terabyte mark. To handle these types of figure, big integers are a necessity - but common test cases don't need big integers. I understand that, by judiciously scattering annotations around in my code, I can ensure that I don't hit primitive integer size limits. I'm not sure that I'll have enough understanding of numeric limits and promotion behaviour to know *where* to put annotations, so I'll likely just scatter them round until I stop hitting bugs (I would assume here that people for whom numeric performance is crucial will be a lot more expert in numeric behaviour and so will be better able to annotate precisely, but I accept that's nothing more than an assumption). But suppose I want to use some library code - for example, something like clojure.contrib.accumulators, to summarise my data. It's not clear to me from the things I've read whether I can expect it to work with the big numbers I'm giving it. The documentation says nothing, as it was written before this change. So do I have to read and understand the code? If library code *won't* just work by adapting to the types given to it, will we end up with a split between bignum and primitive libraries? It seems to me that many of these libraries would be just as good for people wanting fast math as for people like me slinging about big numbers like disk file sizes. The it's only about which is default argument is fine (I contend that people wanting performance are likely to be the more numerically expert and hence the better capable to enable non-default behaviour, but that's just my view). But if libraries get split into bignum-supporting vs fastnum-supporting, that seems to me to be a far more significant issue. Paul. Paul -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to use clojure-contrib library
I checked and yes it's a 1.2 feature in contrib. So check out the master branch of both projects (clojure and clojure-contrib) and build them to get the latest snapshots. Beware that the jar file names will not be the same so change your class path accordingly. Luc On Tue, 2010-05-11 at 22:57 -0700, Mat wrote: Looking at the source in the master branch on Github, string.clj is present, but if I look into the 1.1.x branch, it's not. I will try to checkout the source from Github and compile it directly. Matteo On May 12, 7:51 am, Mat matteo.manferd...@gmail.com wrote: Luc, I'm using the latest one, v1.1.0. I downloaded it here:http://code.google.com/p/clojure-contrib/downloads/list I'm using the same version for clojure.jar. The strange thing is that when I inspect the content of the jar, there is no clojure/contrib/string, but only clojure/contrib/str_utils and clojure/contrib/str_utils2. Also looking into the source folder, I can't find sting.clj, but only the two I mentioned. This leaves me puzzeled. Maybe in the last version of the contrib libraries the string class was stripped? Thank you. Matteo On May 12, 4:18 am, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Matteo, which version of clojure-contrib are you using ? The latest has the String class but an earlier version may not have it. To see the content: jar -tf clojure-contrib.jar You should see a string.clj in the list of components in the library and some string$xxx.class files. If not you are using an older snapshot. Make sure the versions of Clojure and contrib are compatible (either all 1.0, all 1.1 or latest 1.2 snapshots) otherwise you will end up with strange behaviors. Luc On Tue, 2010-05-11 at 14:15 -0700, Mat wrote: On May 11, 7:41 am, Mat matteo.manferd...@gmail.com wrote: Thank you very much, this time it worked perfectly. I knew it was very easy, but I could not figure it out not having all that java/shell experience. I'm sorry to bother you again with this silly question, but on the contrary of what I said I'm still not able to use the library (it was a quick test on starting the REPL). Now I'm able to start the REPL using: java -cp clojure.jar:clojure-contrib.jar -server clojure.main (I forgot to mention that I'm on a OS X 10.6 machine). Inside of it I'm still unable to use the library. If I load a file with load-file or I try to type the following: (ns mynamespace (:use clojure.contrib.string)) as written onhttp://richhickey.github.com/clojure-contrib/string-api.html, I still get the following error: java.io.FileNotFoundException: Could not locate clojure/contrib/ string__init.class or clojure/contrib/string.clj on classpath: (NO_SOURCE_FILE:2) Could be a problem in the file placement? As I understood all I need are the jars (clojure.jar and clojure-contrib.jar). Thank you very much. Matteo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to use clojure-contrib library
Oups, I stopped using windows for so long that I forgot about the semi-colon thing :))) That frees a lot of memory for other stuff... Luc On Tue, 2010-05-11 at 08:38 +0200, Michael Wood wrote: On 11 May 2010 03:30, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Hi, The trick is to get contrib on the class path of java so it can find the content of the library. The class path defines were Java will search for the components (classes in Java) to load while running. Clojure code is compiled on the fly and ends up as a being loaded as a Java class and may be present in libraries either as .clj files or as pre-compiled Java classes (.class files). So: java -cp clojure.jar:clojure-contrib.jar -server clojure.main clojure.main being the main program called (in this case it starts a REPL) and -cp (ClassPath) being the list of librairies you want to use. The libraries are colon delimited and I think it's the same on both Windows and u*x. No, on Windows you have to use the semi-colon (;) because the paths can include colons (e.g. C:\path\to\something.jar). Other than that everything's the same. -- Michael Wood esiot...@gmail.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to use clojure-contrib library
Matteo, which version of clojure-contrib are you using ? The latest has the String class but an earlier version may not have it. To see the content: jar -tf clojure-contrib.jar You should see a string.clj in the list of components in the library and some string$xxx.class files. If not you are using an older snapshot. Make sure the versions of Clojure and contrib are compatible (either all 1.0, all 1.1 or latest 1.2 snapshots) otherwise you will end up with strange behaviors. Luc On Tue, 2010-05-11 at 14:15 -0700, Mat wrote: On May 11, 7:41 am, Mat matteo.manferd...@gmail.com wrote: Thank you very much, this time it worked perfectly. I knew it was very easy, but I could not figure it out not having all that java/shell experience. I'm sorry to bother you again with this silly question, but on the contrary of what I said I'm still not able to use the library (it was a quick test on starting the REPL). Now I'm able to start the REPL using: java -cp clojure.jar:clojure-contrib.jar -server clojure.main (I forgot to mention that I'm on a OS X 10.6 machine). Inside of it I'm still unable to use the library. If I load a file with load-file or I try to type the following: (ns mynamespace (:use clojure.contrib.string)) as written on http://richhickey.github.com/clojure-contrib/string-api.html, I still get the following error: java.io.FileNotFoundException: Could not locate clojure/contrib/ string__init.class or clojure/contrib/string.clj on classpath: (NO_SOURCE_FILE:2) Could be a problem in the file placement? As I understood all I need are the jars (clojure.jar and clojure-contrib.jar). Thank you very much. Matteo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to use clojure-contrib library
Hi, The trick is to get contrib on the class path of java so it can find the content of the library. The class path defines were Java will search for the components (classes in Java) to load while running. Clojure code is compiled on the fly and ends up as a being loaded as a Java class and may be present in libraries either as .clj files or as pre-compiled Java classes (.class files). So: java -cp clojure.jar:clojure-contrib.jar -server clojure.main clojure.main being the main program called (in this case it starts a REPL) and -cp (ClassPath) being the list of librairies you want to use. The libraries are colon delimited and I think it's the same on both Windows and u*x. -server is used for performance reasons. It modifies the behavior of the Java virtual machine and makes it run faster for our purpose. This should get you started. Luc On Mon, 2010-05-10 at 14:48 -0700, Mat wrote: Hi all, I am totally new to clojure and this is a very simple question, but I spent the last two hours trying to figure this out and I need help. I'm not able to use the clojure-contrib library and I am not able to find instructions here on this group and anywhere on the web. Maybe because this should be easy, but for me it isn't. I downloaded the clojure-contrib.jar but I can't find anywhere instruction on the set-up (where to put the file, if some else is needed, ecc) to begin with. Actually I have the clojure-contrib.jar file in the same directory as the clojure.jar, but I don't know how to run it. I've tried running the REPL normally, but when try using (ns mynamespace (:use clojure.contrib.string)) in my code file (or using :require in place of :use) i get this error: java.io.FileNotFoundException: Could not locate clojure/contrib/ string__init.class or clojure/contrib/string.clj on classpath: (NO_SOURCE_FILE:2) I thought then that the library must be loaded in the same command with clojure.jar. I tried to look on the web and found some script and I tried to figure out what to do from them. What I tried last is java -cp clojure.jar clojure.main clojure-contrib.jar and I get this error Exception in thread main java.lang.Exception: Unable to resolve symbol: PK in this context (clojure-contrib.jar:0) I'm not sure that what I'm doing is correct, but it's all I was able to figure out in two hours of trial and error. I don't know anything about running java from the command line. Every page I find on the internet on clojure-contrib just assumes that everything works and just uses the library. I hope that someone can help me. Thank you very much. Matteo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: 1.2 release ?
My previous post got lost in a black hole somewhere... so lets type a shorter version: Yeppee ! That's a perfect match with my schedule for the next 6 months. We will launch our new projects under 1.2 and port the existing code to it in the following weeks. Our next major deployment toward fall will use 1.2 and by then we should have tripped over most of the problems in our code. Good occasion to do some code reviews... Thank you, Luc P. On Tue, 2010-05-04 at 09:28 -0400, Rich Hickey wrote: On May 3, 2010, at 10:26 PM, lprefonta...@softaddicts.ca wrote: Hi all, it's not that I want to put pressure on anyone here but there has been a number of discussions about the 1.2 release and I was wondering what's the horizon for a first release ? We are still in prod with 1.0 but some are salivating about some of the features of 1.2. We did not move to 1.1 and are expecting to directly jump to 1.2. I just wonder when I can release the gate and let people here code with 1.2 for a future deployment in production... I am juggling with the dev schedule tonight. No need to post answers à la Orson Wells, we will not release 1.2 before its time, if no answers get posted I'll send people on an ice bank somewhere to cool off during summer vacations :))) We are hoping to go code complete on the features listed for milestone 1.2 within a week or so: https://www.assembla.com/spaces/clojure/tickets/custom_report/2729 That will be followed by a bug-fix-only beta period (insert Wellesian comment here), then an RC, followed by release. I'd like everyone to get on the beta as soon as it is available so it gets a thorough workout, as several things have shifted around. If nothing serious comes up during beta, we could be 4-6 weeks away. 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Slides for short (45 minutes) presentation of clojure for java devs
Is there a Dutch version of Clojure ?!?!?! I want one in French then : (Laurent you just said you like to be bashed didn't you ? :))) Luc On Thu, 2010-04-22 at 15:09 +0200, Laurent PETIT wrote: Could I still take a look at it, to see the kind of examples you provided (are the source code examples in english ?) 2010/4/22 Laurent PETIT laurent.pe...@gmail.com: 2010/4/22 Joop Kiefte iko...@gmail.com: I made one simple and short one for beginners, I think to your liking, but in Dutch... too bad I don't speak Dutch :-( 2010/4/22 Laurent PETIT laurent.pe...@gmail.com Oh, really no answer ? :'( 2010/4/21 Laurent PETIT laurent.pe...@gmail.com: Hello, I've consulted a lot of already made presentations of clojure. They are great, but I guess they may not suit my needs because it seems to me that either: * they are more 1 1/2 to 2 hours talks than 45 minutes * they assume the public will not be relunctant to some terms like Lisp, Functional Programming and directly present these as advantages My goal is to raise interest into clojure in the mind of a public of people having used java for a long time. They may have Scala already in their radar, but not clojure, or may have seen it and immediately dismissed it for what seemed to them good reasons (mainly aversion for lisp syntax), though we all know this is not true after the normal adaptation period. Say this presentation could be the presentation that leads people, at its end, asking you for giving all those great other presentations already available that I mentioned before ... Any references I missed that already solve my problem ? :-) Thanks in advance, -- Laurent -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Communication is essential. So we need decent tools when communication is lacking, when language capability is hard to acquire... - http://esperanto.net - http://esperanto-jongeren.nl Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Execute a string containing a form?
We store routing rules in a database as Clojure code and get these to be loaded dynamically and run according to some variable configuration. Of course we make sure the code forms are stringent in the database and we wrap execution of these things with proper error handling code :))) That's one of the features we needed to get that message bus thing to lift up as a generic product and avoid specific code implementation. Luc P. On Thu, 2010-04-22 at 16:12 +0200, Heinz N. Gies wrote: On Apr 22, 2010, at 14:28 , Douglas Philips wrote: eval can be a dangerous thing to use, you have to be very careful about where the source has come from, in terms of trusting that the code your programs 'eval's will not be malicious or dangerous in some way. There are no absolute rules for this, it depends on your application. To do a bit advertising here, for this case there is clj-sandbox I claim it does a pretty good job to give a basic hassle free safety for evaluated code. Also if it is a string you read from you can skip the read-string part and just pass it the string directly. If you want to have a look: http://github.com/Licenser/clj-sandbox or for lein: [clj-sandbox 0.3.1] -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
clojure.set index not handling large sets...
Hi all,
I tripped over something strange yesterday. I work on a tool to create
reports in the REPL from data in an SQL database.
Instead of building SQL statements with complex where clauses, the user
can defined which tables/fields he wants to fetch
and then he can work on these locally.
I implemented local joins and a number of other related operations to
marshal the data.
While doing this, I worked with clojure.set and used the index function
to regroup records matching the same
keys. I then found out that I was not getting the same # of record from
my local join compared to the equivalent
SQL statement. The input data was the same however (I compared SQL
statement outputs with my local fetch outputs.
I was losing records, instead of getting 18000 something records, I
was down to 14000 something.
In fact some keys where missing in the output of index. I did not find a
pattern in the missing entries.
While digging, I started to question the index function sanity from
clojure.set. I cloned it and after a few hours of tossing it around,
decided
to recode it using a mutable Java HashMap.
It then worked... I got the same number of records as in the equivalent
SQL statement output.
The index function in clojure.set goes like this:
(defn index
Returns a map of the distinct values of ks in the xrel mapped to a
set of the maps in xrel with the corresponding values of ks.
[xrel ks]
(reduce
(fn [m x]
(let [ik (select-keys x ks)]
(assoc m ik (conj (get m ik #{}) x
{} xrel))
It looks great and I suspect that the problem is deeper in the core.
Anyone has encountered something similar ? The problem can be replicated
in 1.0 and 1.1.
I did not have the time now to test it again using the master branch.
I will investigate this in the runtime later but maybe someone has
crossed over this problem in the past.
Luc
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Choosing a Clojure build tool
Fully agree, reinventing the wheel is not a good time investment. Ant has been there for years, why not reuse it ? Why reinvent Ant (or Maven) in Clojure ? The fact that they may look ugly and cumbersome to use has to be separated from the benefits they provide. We switched to Leiningen here and created an internal Maven repository with Archiva for our own components. Leiningen implements in Clojure a simplified build interface, this is where the niceties are for users. It take cares of the house keeping for you and this is where we want a tool to save us time. Aside from resolving our dependencies in Maven repositories on the net and loading a few unknowns to our internal repository, we did not have anything else to do build wise. We have around 100 dependencies here and were looking for a way to simplify this management. Leiningen does it. If Ant or Maven changes, most of these impacts will most probably be hidden in Leiningen. We could not care less about the internal details... that's not where we see the added value of a build/deployment tool, it's in the day to day use by normal developers (non-Maven/Ant experts). Leiningen can handle simple projects as well as complex ones, why create yet another tool/tool-set ? For the sake of having it written 100% in Clojure ? Efforts should be focused on improving Leiningen when needed, not on creating another gizmo. As for the obsessive desire to get an integrated build/deployment tool, picture this, we need to manage all the above dependencies plus our own components AND multiple costumer site configurations. Having some simple automation here is an absolute requirement. We will add a deployment plugin to Leiningen this year to manage our deployments at customer sites. A Rails/Ruby one is also on the table. I do not call this hilarious (or obsessive), it's called common sense. Humans could still be reinventing fire every century but there's no added value to this process. Luc P. On Fri, 2010-03-26 at 16:49 +1030, Antony Blakey wrote: On 26/03/2010, at 4:37 PM, Rayne wrote: I don't think I've ever seen a language in which part of the community shunned build tools written in the language itself. It's quite hilarious. I've seen many examples where an overwhelming Not-Invented-Here attitude lead to failure. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Isn't it enough to see that a garden is beautiful without having to believe that there are fairies at the bottom of it too? -- Douglas Adams -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
An IDE becomes a necessity as the complexity of your software is increasing. Now what's a complex piece of software ? Presently we have 12 components in production some being several thousand lines covering three languages (Java, Ruby and Clojure). 4 others components are in progress. Add to this that we use Spring and a number of other frameworks for which plug ins are available to ease the pain. Refactoring, code searching, configuration validation, ... are significant features we need otherwise we would spend a lot of time to keep things in sync, We started to work with Clojure in command line mode. However at a certain moment it became clear that keeping Clojure separate from the rest of the core was not the way to go. Today we are mixing components from different languages/frameworks in common Jars. Deployment is much more easier this way and using a common IDE makes that possible. If the consensus is that we need to package installers to get simple Clojure REPLs running on Windows and Linux in a command line window then let's do it. I think that all the infrastructure is ready (maven like repo, ...). Luc On Sun, 2010-03-21 at 22:52 -0500, Cosmin Stejerean wrote: On Sun, Mar 21, 2010 at 10:20 PM, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Yes we could have a complete package to run Clojure from the shell command line but how far could someone go with this to build a workable system without an IDE ? [...] Comments anyone ? I can get pretty far writing an application in Python with nothing more than good command line support and syntax highlighting in any text editor. Anything extra like completions, refactoring, etc, are just nice-to-haves. I don't see why an IDE is required for writing workable Clojure apps. -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
Is my first impression right or wrong ? Is Clojure harder to setup from Windows for beginners ? Would an installer (.msi) help by hiding Java related details and providing some basic scripts to run it ? Luc P. On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote: On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg joel.westerb...@gmail.com wrote: Every time I've started up with a clojure project I've had to spend a few hours fiddling with the environment, not that I don't do that with other languages, but it would be nice with an officially sanctioned solution for setting up a sane environment. Even better, an officially sanctioned solution expressed both as documentation, and as a collection of shell scripts for all the major platforms. (As another non-java-familiar clojure adoptee, classpaths were definitely a hurdle) 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
Don't twist my post away from it's purpose... I am not making an IDE a pre-requisite for learning purposes. The original poster was talking about getting Clojure usable by corporations... he was not talking about academic learning. Too bad he was not aware that there are other IDEs available other than the M..ft thing. Not even looking at the documented alternatives before saying anything is unprofessional at best in this regard. You can still code 3 lines+ systems without an IDE (IDE can be as simple as VIM or this other popular text editor on MacOSX) but this approach has definitively limits. Just in case you have doubts I did a lot of these in the past before even VIM like editors became the norm. I would not revert back to these times. If some are saying they can do a lot without an IDE, fine, but that's pointless here, it seems that the main problem is the first contact with Clojure. It looks like it's rough and there's a need for some smoothness there. The main goal being to hide the Java gears as much as possible. This is the feedback I was trying to get. If .NET gears where not hidden on first contact, it would appear has bad as the JVM. With .NET, it's later in the learning process that this strikes you :)) At first it looks great (all these windows, ). I was asking for some requirements... can we start here ? a) A need for a Windows based installer b) Startup scripts to hide java machinery, probably pre-tuned to hide all these horrible Java flags c) Update mode to keep the Clojure run time up to date with whatever version you may want (1.0, 1.1, 1.2, nightly build, ...) d) a) and c) Use available public repositories to get components. e) A need for installers on other platforms ? U*X, MacOs X ? Any value there ? Starting Clojure from command line on Windows is this satisfactory for everyone ? Maybe a helper to start CMD in a folder from a context menu would be of some help ? Anything else ? Luc P. On Mon, 2010-03-22 at 00:33 -0400, Douglas Philips wrote: On 2010 Mar 21, at 11:52 PM, Cosmin Stejerean wrote: On Sun, Mar 21, 2010 at 10:20 PM, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Yes we could have a complete package to run Clojure from the shell command line but how far could someone go with this to build a workable system without an IDE ? [...] Comments anyone ? I can get pretty far writing an application in Python with nothing more than good command line support and syntax highlighting in any text editor. Anything extra like completions, refactoring, etc, are just nice-to-haves. I don't see why an IDE is required for writing workable Clojure apps. +1 I use a Mac with MacPorts. Pulled down clojure and clojure-contrib ports. Only thing I had to do (and this was -not- easy to figure out), was create a .clojure file that pointed to the contrib jar. But that is how the clj wrapper in the clojure port works. I suppose I could also muck around with my class path, or do other things... There is a high Java tax on using clojure for those of us coming from non-Java languages. I'm willing to accept that I need to read the Java docs on how strings, or, whatever, work. But getting clojure itself set up? Please, do -not- make pre-existing familiarity with an IDE a prerequisite. There are enough learning curves as it is. -Doug P.S. I used Emacs back when Gosling was writing his version of it at CMU, before Java even existed, and now I use (g)vim. It's nice that there are other IDEs working with clojure, but not so nice to assume non-Java users are using some VisualStudio or other heavy-weight IDE. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
I looked at these videos and they are a very good starting point. Then do we have a communication problem getting these things known ? Are these videos listed on the Getting started page ? What about using contrib ? That would be the first classpath problem a newcomer would face. It looks to me that we have all the answers but not in a single spot. Luc P. On Mon, 2010-03-22 at 06:44 -0700, Sean Devlin wrote: Luc, Windows users should be good to go. Clojurebox, Enclojure CCW are ready for use for any Java dev with some experience. As for the installation process, pick you poison: http://vimeo.com/tag:install_clojure Sorry to self-post, Sean On Mar 22, 7:31 am, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Is my first impression right or wrong ? Is Clojure harder to setup from Windows for beginners ? Would an installer (.msi) help by hiding Java related details and providing some basic scripts to run it ? Luc P. On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote: On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg joel.westerb...@gmail.com wrote: Every time I've started up with a clojure project I've had to spend a few hours fiddling with the environment, not that I don't do that with other languages, but it would be nice with an officially sanctioned solution for setting up a sane environment. Even better, an officially sanctioned solution expressed both as documentation, and as a collection of shell scripts for all the major platforms. (As another non-java-familiar clojure adoptee, classpaths were definitely a hurdle) 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
He's illiterate about Java, he's older than me and has less experience so finding how to run a jar file is probably as remote as traveling to Alpha Centauri :))) (Don't we have something like Google to find these answers ?) Most of his recent experience seems to be in Visual Basic and mainstream web centric languages. I suspect he's more a by-product of using too few commercial language centric IDEs. If it does not work out of the box without a 1-800 number to call, he's lost. Let's not spend more time about this guy's comments. I think we can assume a Java programmer knows about class path issues and is able to run java and add librairies to the class path. As for non Java programmers yes it can be a bit daunting but I bet you can't do much in C# or F# if you do not have the slightest idea on how to use VisualStudio : You are far away from a three steps installation process here. Agree, many people may already be familiar with VisualStudio, it's been around for along time. But do you like it ? :))) Getting started with Clojure is rather simple from the command line, mastering a foreign IDE is a different story. If you are not familiar with Eclipse, IntelliJ or Emacs and you want to use something more flexible than command line mode then you have a learning curve investment to do. The alternatives are documented from the Getting started page of the Clojure web site and it's pretty clear to follow. The best choice may not be clear upfront (we all have our tastes) but there is some solid ground to help people decide on an alternative. Yes we could have a complete package to run Clojure from the shell command line but how far could someone go with this to build a workable system without an IDE ? It might have some sex appeal to help learn the language but how different is it from the three steps described by Marek ? Do we really need to release a Clojure SDK with an IDE etc ? What other language does that ? Ruby ? Scala ? Groovy ? From time to time we have comments about how difficult/easy it is to get acquainted with Clojure but I wonder if we all understand the same things about this issue. Do we need to gather requirements somehow ? (!?!?!) Comments anyone ? Luc P. On Sun, 2010-03-21 at 22:08 +0100, Marek Kubica wrote: On Sun, 21 Mar 2010 10:42:12 -0800 Tim Johnson t...@johnsons-web.com wrote: Here's how I installed the flash player on my system. 1)Downloaded install_flash_player_10_linux.tar.gz 2)Unzipped libflashplayer.so 3)Copied to /usr/lib/firefox-3.5.2/plugins/ Here's how I installed the Clojure REPL on my system. 1) Downloaded clojure-1.1.0.zip 2) Unzipped clojure.jar 3) Ran java -jar clojure.jar Hardly any different. FWIW, posting on a list and declaring immediately that one will unsubscribe afterwards, not even reading replies is near-flamebait quality. regards, Marek -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: using counterclockwise with 1.2 snapshots?
Hi Stuart, we do exactly the same thing here. We want to insure that we always use the same Clojure/Contrib run times as we have currently in production. Luc On Thu, 2010-03-11 at 12:18 -0500, Stuart Halloway wrote: What is the preferred way of using counterclockwise with 1.2 snapshots. Here is how I retrofitted an existing project: (1) Create a Clojure project on top of the exiting source dir (2) Under Run Configurations add user entries for lib/**.jar, ahead of the 1.1 bits installed by the project wizard This seems to work, but if there is a preferred way I would love to know about it. Stu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Conference Poll
Where's the reference to the booze then ? :))) Since this thread started, everyone has been saying that bars in their neighbourhood are the best. Still wondering if this conference is only a motive to get drunk for a few days :))) Luc On Thu, 2010-01-28 at 14:02 -0800, Paul Nakata wrote: Or Conjference On Jan 28, 11:24 am, ataggart alex.tagg...@gmail.com wrote: I'm partial to naming it Expojure. On Jan 27, 9:59 am, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Then lets call it ClojureFest Luc On Wed, 2010-01-27 at 08:37 -0800, eyeris wrote: Exotic? You got it! Madison, WI! Seriously, we have the best bars. See you guys in the fall! :) I would prefer it during the week. On Jan 22, 3:15 pm, Wilson MacGyver wmacgy...@gmail.com wrote: I vote let's turn this into a clojure vacation, and hold it in an exotic location. Otherwise, hey, Columbus Ohio is as good as any other city. :) On Fri, Jan 22, 2010 at 3:50 PM, Sean Devlin francoisdev...@gmail.com wrote: Clearly you haven't taken into account that Philadelphia is more central wrt the big cities :) On Jan 22, 3:32 pm, Fogus mefo...@gmail.com wrote: Since Clojure is clearly an East-Coast language, I suggest DC as the most logical locale. (hopes someone buys this line of reasoning) -m -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Conference Poll
Then lets call it ClojureFest Luc On Wed, 2010-01-27 at 08:37 -0800, eyeris wrote: Exotic? You got it! Madison, WI! Seriously, we have the best bars. See you guys in the fall! :) I would prefer it during the week. On Jan 22, 3:15 pm, Wilson MacGyver wmacgy...@gmail.com wrote: I vote let's turn this into a clojure vacation, and hold it in an exotic location. Otherwise, hey, Columbus Ohio is as good as any other city. :) On Fri, Jan 22, 2010 at 3:50 PM, Sean Devlin francoisdev...@gmail.com wrote: Clearly you haven't taken into account that Philadelphia is more central wrt the big cities :) On Jan 22, 3:32 pm, Fogus mefo...@gmail.com wrote: Since Clojure is clearly an East-Coast language, I suggest DC as the most logical locale. (hopes someone buys this line of reasoning) -m -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Conference Poll
Hic ! On Wed, 2010-01-27 at 12:59 -0500, Luc Préfontaine wrote: Then lets call it ClojureFest Luc On Wed, 2010-01-27 at 08:37 -0800, eyeris wrote: Exotic? You got it! Madison, WI! Seriously, we have the best bars. See you guys in the fall! :) I would prefer it during the week. On Jan 22, 3:15 pm, Wilson MacGyver wmacgy...@gmail.com wrote: I vote let's turn this into a clojure vacation, and hold it in an exotic location. Otherwise, hey, Columbus Ohio is as good as any other city. :) On Fri, Jan 22, 2010 at 3:50 PM, Sean Devlin francoisdev...@gmail.com wrote: Clearly you haven't taken into account that Philadelphia is more central wrt the big cities :) On Jan 22, 3:32 pm, Fogus mefo...@gmail.com wrote: Since Clojure is clearly an East-Coast language, I suggest DC as the most logical locale. (hopes someone buys this line of reasoning) -m -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Log4j not detected when using recent jars
We have been using 1.2.14 for more than a year without any glitches yet. Luc On Tue, 2010-01-12 at 23:22 +0530, Baishampayan Ghose wrote: On Tuesday 12 January 2010 07:30 PM, Shantanu Kumar wrote: This behaviour might occur due to an old Apache Commons-Logging JAR, several of which have had classpath / class-loading issues. Just a thought. Which is the recommended latest version of log4j? As I can see, 2.0 is too experimental and 1.3 has been made obsolete. I tried using 1.2.14 because 1.2.15 was bringing in a truck load of dependencies. Regards, BG -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
That's a concise and clear way to summarize the issue. If you compare the IDE support required for different languages, the support required to write syntactically correct Clojure code is pretty small compared to others. I do not get it, it's longer and much more painful to write Java code with all these required delimiters (parenthesis required in a if/while/for condition, semi-colons to split for loop expressions, statements, curly braces to create compound statements...). These are different requirements depending where you are in your code. Without hefty IDE support, you would be left nude on the ice bank. When HP introduced their pocket calculator with Postfix notation, people had to get used to it but it did not prevent HP calculators to become popular ones in the engineering/scientific/accountants community. Ok you would not expect your grocery store owner to use one but he's not building bridges or a creating a new cancer cure either. People bought HP calculators not for the Postfix notation but for all the others things it offered at the time... Luc On Fri, 2009-12-18 at 17:58 -0800, Vagif Verdi wrote: Welcome to the big club of people who in last 50 years came up with a brilliant idea to fix lisp. As for Ten parentheses, i do not see a single one. Noone notices starting parens because they are markers saying this is a function. And of course noone notices ending parens because they are for your IDE, not for the human. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
:)) Luc On Sun, 2009-12-20 at 15:00 -0800, David Brown wrote: On Sun, Dec 20, 2009 at 02:30:58PM -0500, Luc Préfontaine wrote: People bought HP calculators not for the Postfix notation but for all the others things it offered at the time... Some of us _still_ only buy HP calculators because of the postfix notation. Oh, the other things are nice, too. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
I do have one but it still has some grey in it :) On Sun, 2009-12-20 at 19:41 -0500, Wilson MacGyver wrote: John McCarthy the creator of lisp does have beard. :) http://www-formal.stanford.edu/jmc/personal.html On Sun, Dec 20, 2009 at 7:37 PM, David Nolen dnolen.li...@gmail.com wrote: On Sun, Dec 20, 2009 at 5:48 PM, Luc Préfontaine lprefonta...@softaddicts.ca wrote: :)) The Lisp Beard? Luc On Sun, 2009-12-20 at 15:00 -0800, David Brown wrote: On Sun, Dec 20, 2009 at 02:30:58PM -0500, Luc Préfontaine wrote: People bought HP calculators not for the Postfix notation but for all the others things it offered at the time... Some of us _still_ only buy HP calculators because of the postfix notation. Oh, the other things are nice, too. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure analysis
Mike, I think that the whole issue about Lisp creates a big cloud about Clojure. Choosing a Lisp like syntax for a new language is a good choice because of the expressiveness, it requires less code lines, yields a better design, easier to test, ... That's a choice between a number of options. If it was the only sane one then we would all be coding using Lisp like syntax. That's not the case obviously. Talk to Ruby people, they made different choices... If you sum up Clojure as being a Lisp because of what it look likes and use only this to compare it to other languages then you are missing the forest and looking at a single tree. If you code in a Lisp like language using setq or set! or alike then you can get very far away from functional programming and end up writing procedural code with parenthesis. You will eventually face the issues that Clojure avoids. Clojure takes a brutal approach, forget the left-right assignment that almost every language eventually supports, forget variable mutations visible to everyone, forget procedural code... Oups these are the real show stoppers independently of the syntax used. There's no escapes in Clojure while in other languages you can still cheat (setq/set! and similar). What I found non-trivial in Clojure were these restrictions, no the syntax. As soon as I understood the decisions behind these choices, my mental blockage vanished. Immutable data structures, transparent iterations over a variety of structures, lazy sequences, a workable STM implementation, parallel processing capabilities ridiculously simple to use, huge set of Java librairies available, easy to use, ... These are the real features that make Clojure distinct from other languages. All the choices made are sound and the sum of these decisions is coherent. Nothing looks like it's been added late to fill a gap like a nose in a face. Syntax by itself is nothing, it never made a good language implementation. I have a few years of Lisp behind me, I started to use Lisp in the 1980s.I used to prototype software in Lisp that I had to deliver in a more classical language. The main reason of this being the lack of basic librairies and incompatible Lisp implementations plus the maintenance issue. After my Clojure learning curve, I removed LispWorks from my desktop. I do not see the use for it anymore. My 25 years of experience is not the same as 5 years of Scheme, I experimented more stuff in software in various environments than the majority of today's average developer. I adhere to justified critics when a rationale has been exposed otherwise I call it (repeat blablabla). To expose some rationale it implies that you understand the subject you are talking about. If you don't then you should be cautious about what you state or you state it conditionally. The above does not mean that I will not ever critic Rich's bad decisions in the future. I do not see this likely to happen however given its present score... Luc On Thu, 2009-12-17 at 19:02 -0500, Mike Meyer wrote: On Thu, 17 Dec 2009 10:26:03 -0800 (PST) Santhosh G R kusim...@gmail.com wrote: You warn that you learn languages just for the fun of it. I would be curious to know how much time you spent learning Clojure... I have been working with Scheme for the past 5 years. I think this is a critical element! Yep, I don't have 20+ years in development; neither 12+ months in Clojure. My learning of Clojure has been for the past 2-3 months. I expect that 5 years with Scheme is worth more than 20+ years with C/C++/Java when it comes to learning Clojure. Clojure is, after all, a LISP dialect. Once you've gotten your mind around the proper way to write programs in LISPy languages - which is a non-trivial thing - adopting to another one is fairly easy. I feel that mind-set coming back after my absence from the language as I read through the examples. The other unique features of Clojure should be relatively straightforward to deal with once you've gotten past this. So either you are a genius and went through Clojure faster than we could, learning all the features it offers, or you just skimmed the surface. Neither a genius, nor did I skim through. Right. Just someone who was already familiar with programming in a LISPy environment. I completely miss this. As I said I am not a clojure developer. I am a programming language enthusiast and have learnt multiple languages with different programming paradigms; just for the fun of it. Programming languages which I know are Java, Python, Scheme, okie- dokie PERL, C# which for me is Java with a different library and idiom, C, C++ including the (in)famous STL, COBOL FORTRAN purely because it was in my syllabus, Javascript both in its prototype and functional forms. I have tried to be unbiased; if it exists it might be due to my stronger background in Java, Python, Scheme. Given that list of languages, I'd suggest taking a look at
Re: Clojure analysis
I agree with Sean, the STM is a big feature also are parallelism and data immutability. These features are working now and they make things a lot simpler. I agree also that the lack of documentation is a barrier but even with documentation the learning curve would not be much shorter again because the language departs from concepts carried on in most programming languages, not because of it's syntax. Stuart has written a smart book and that as a starting point is more than enough. Hands-on is required to learn a new language and not just for academic purposes. Having a real problem to solve is better. You say that Clojure is a better Java... totally wrong. Java sits where it needs to be, at the bottom of the stack like assemblers in the 70s/80s. Getting interop with Java is as obvious as being able to call an assembly routine from a higher level language or an external library. No one would question this ability in other languages. No one wants to rewrite mundane tasks if they are already programmed. If this makes you think that Clojure is a better Java well that relates to my comments later in this post. Your statement that Clojure should stand apart from others is deeply wrong. It is already a breed of its own. Borrowing best ideas from other languages does not mean that the end result is a Babel tower. If you think that Clojure is not well articulated and does not have it's own personality that also relates to my comments following this paragraph. You warn that you learn languages just for the fun of it. I would be curious to know how much time you spent learning Clojure... I personally worked with Fortran, Cobol, PL/1, Lisp, C/C++, VB, Java, JS and so many other languages to deliver working systems in production not counting half a dozen assemblers (with systems above 20,000 code lines). Many of these were multi threaded apps before libthread even existed. Dynamic languages were far more common 20 years ago than now btwy. We have been working with Clojure for more than a 16 months with a message bus software in production for 11 months. Not a simple HelloWorld app Just to get up to write decent production code with Clojure it took me a good 4 months. I'm a 25 years exp. guy and I have been writing code and designing systems for that life span. I am not an educated manager with grey hairs. My colleagues are younger and did not do better. The changes that Clojure brings in the old ways we used to program are significantly important to make learning a steep curve before you can write code that you can read again without shame. So either you are a genius and went through Clojure faster than we could, learning all the features it offers, or you just skimmed the surface. I think the later applies and that you have some toupet to compare a language with others without any extensive field use of most of them. Get a few millions lines of code behind you, then you may eventually write decent critics. Meanwhile be humble... Luc On Fri, 2009-12-11 at 13:04 -0800, kusi wrote: http://kusimari.blogspot.com/2009/12/analysing-clojure-programming-language.html -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure newbie question regarding compile time type checking.
If Clojure type checking becomes a frequent request/complaint, please build a lint type tool, not some twisted logic embedded in the compiler :))) C did not have any decent type checking when it came out and we had to use lint to find bad parameter on fn calls and other similar errors. They were no function prototypes at the time so passing a pointer address instead of the pointer value did not bother the compiler at all. In fact you could pass crap in most places and end up at run time with a bad pointer address or corrupted stack. You cannot call C a dynamic language, a semi-assembler that evolved to a higher status over time, however it lacked basic type checking in it's early incarnations... Quite a challenge for a typed language (byte, short, int, long, 8? 16? 32 bits ?). Debugging stack corruptions daily is not really an efficient way to program so rules where added to the compiler to eventually flag data type improper uses. I never saw a dynamically typed language that had type checking at compile time :))) In my mind it's mutually exclusive... Lisp compilers came out in the 1970s if I recall. To compile Lisp you needed special declarations to define unbound variables and other similar things to get the compiler to create a runnable file. Symbols where not bound to lexical scope so the compiler needed some hints from time to time telling it that these things would eventually be available at run time. This did not apply to symbols within a function, they could appear without an explicit declaration. It was assumed they were somewhere on the stack at run time. That's even more dynamic that what Clojure allows... maybe a bit too much. The Clojure compiler is in the same vein, it checks for undeclared stuff BUT mandates that everything used be visible in the lexical scope. No run time bindings not lexically visible are allowed, that's a very good compromise, debugging for missing dynamic bindings on the stack at run time is not very funny. This compiler has nothing to do with a data typed compiler that validates that the proper typed variables are used in an acceptable manner... These are two unrelated things. We call them both compilers but its not required for a compiler to do data type checking. The only thing they may have in common is that they both generate code. Luc On Tue, 2009-12-15 at 06:20 -0800, Tayssir John Gabbour wrote: On Dec 15, 1:23 pm, Baishampayan Ghose b.gh...@ocricket.com wrote: PS - If you are worried about compile time type checking, I think it's prudent to mention now that Clojure is a dynamically typed programming language where types are checked at run-time and not compile time. Actually, there are Common Lisp compilers (like SBCL) which signal a warning if they infer a type error. I think it's handy, and doesn't do anything drastic like refuse to compile your program because of it. All the best, Tayssir On Dec 15, 1:23 pm, Baishampayan Ghose b.gh...@ocricket.com wrote: Ajay, It tried the following in REPL and got no error. Personally, I feel that I should get an error because calling square on strings is wrong in both cases. Is there a way out of this in Clojure? |(defn square[n] (* n n)) (if (= 0 0) (printlnhello) (map square[a b])) What did you expect from Clojure? In the above form the `map` is a part of the else form and that's why it's not executed. If you don't know already, the syntax for `if` in Clojure is like this - (if expression (then form) (else form)) If you have multiple then or else forms, you can wrap them inside a `do` form like this - (if expression (do (then form) (more then form)) (else form)) The following gives error (because it gets evaluated): |(defn square[n] (* n n)) (if (= 0 1) (printlnhello) (map square[a b])) In the above form, the map is a part of the else form and since 1 is not equal to 0, the `map` is executed. I hope your confusion is cleared. PS - If you are worried about compile time type checking, I think it's prudent to mention now that Clojure is a dynamically typed programming language where types are checked at run-time and not compile time. Regards, BG -- Baishampayan Ghose b.gh...@ocricket.com oCricket.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: roll call of production use?
On Nov 23, 5:00 pm, Raoul Duke rao...@gmail.com wrote: i'd be interested to hear who has successfully used clojure in production. i know of some, as some folks have been vocal; any other interesting-but-so-far-silent uses people'd be willing to fess up about? Our real-world use reported here: http://groups.google.com/group/clojure/browse_thread/thread/ffcd4bc722852b4/d07a1ca449e83a8b Summary: Moderate-scale data processing. Millions of records. Timeseries and regressions. Works great. Based on this pilot, we're expanding our use of Clojure. It's surprising to me just how solid this innovative platform is. Outstanding work. Thanks again to Rich and the other contributors. --Jamie -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: roll call of production use?
On Nov 23, 5:00 pm, Raoul Duke rao...@gmail.com wrote: i'd be interested to hear who has successfully used clojure in production. i know of some, as some folks have been vocal; any other interesting-but-so-far-silent uses people'd be willing to fess up about? http://www.infoq.com/news/2009/01/clojure_production The bus has been up for months now and down times have been related to either some hardware changes (system is fully redundant so most of the time no downtime occurred) and network stability issues over which we have little control (managed by the customer's IT group). We are adding more functions tapping on the information flowing on the bus, of course these are now written in Clojure... Census tracking, decentralized service request management, ... This year the bus will also extend to interconnect other hospital services. The bus is also a way to convince users to move to a paperless environment and focus on data entry completeness to achieve that goal. We have also in the works a Clojure/Terracotta/Java messaging layer to improve parallelism. This should be rolled out in summer time. Transitioning to Clojure V1.0 was not a problem and we do not expect that moving 1.1 will prove difficult. The bus is still running on a cluster of small foot print computers but we moved to Atom 330 motherboards to boost processing power. This thing will celebrate it's first year in production very soon without significant pain and this a proof to me that Clojure is mature. Luc -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: roll call of production use?
We picked one that met our minimal requirements... our prototype was in Java however and that probably biased the choice a bit. But for us it's an intermediate step. We need a more flexible solution. We will keep ActiveMQ in the picture to link different clusters (or an alternative) but for intra cluster processing we want something more in line with the contraints we need to meet especially regarding event serialization. We think that custom fit message serialization is not easily managed using a message bus generic layer. We need a more specific solution and some management hooks to deal with this in day to day operations. Luc On Tue, 2009-12-01 at 10:02 -0800, Daniel Werner wrote: On Dec 1, 5:20 pm, Luc Préfontaine lprefonta...@softaddicts.ca wrote: http://www.infoq.com/news/2009/01/clojure_production Slightly off-topic: What prompted you to choose ActiveMQ over other popular message bus systems like RabbitMQ? Was it the ease of operability with Clojure/ Java, or are there other strong factors? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
