Re: (pprint template) gives me an exception
larry google groups lawrencecloj...@gmail.com writes: (println (pp/pprint template)) Aside from the original problem: pprint already prints to *out* and only returns nil, so the code above first prints template, and then the println will also print the nil returned from pprint. Bye, Tassilo -- -- You 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/groups/opt_out.
Hacker News, Clojure, and GSOC
At least 2 of the people on this mailing list read Hacker News. One thing that really annoys me is the Link Expired message. If you wait more than a minute or two on a page, the NEXT button will fail to get the next news item. It seems to me that the Hacker News people need an education in using immutable data structures and a lesson or two in Hickey's notion of state and time. If Hacker News kept their news chains as immutable data structures they could update the pages without expiring links. You get a fresh head of the pages but I'm 3 pages further along on an old path yet we're both walking the same immutable structure. This is painfully obvious to a Clojure user like myself. Does anyone know anyone associated with Hacker News? Can we clue them into immutable data structures? Better yet, does ClojureScript fully support a method of walking immutable host data structures so they could code the pages with ClojureScript? That would be a very visible win in a widespread community. How would Datomic play in this game? Would the global immutable data structure living in Datomic? Or would you simply architect multiple machines that push/pull git-like updates among themselves? A clone of Hacker News in Clojure would be a good GSOC project as it is well defined and small enough for a single person effort. Tim Daly -- -- You 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/groups/opt_out.
Re: Warning: *retry-limit* not declared dynamic and thus is not dynamically rebindable
Seems like old leiningen + new Clojure. You should upgrade to the latest leiningen, which is 2.1.3. On Wednesday, April 17, 2013 3:04:18 AM UTC+2, ljcp...@gmail.com wrote: Dear all, When I installed leiningen and clojure, I run command lein repl, then prompt some message like such --- C:\leinlein repl Warning: *default-javac-options* not declared dynamic and thus is not dynamicall y rebindable, but its name suggests otherwise. Please either indicate ^:dynamic *default-javac-options* or change the name. Warning: *silently* not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic *silently* or change the name. Warning: *skip-auto-compile* not declared dynamic and thus is not dynamically re bindable, but its name suggests otherwise. Please either indicate ^:dynamic *ski p-auto-compile* or change the name. Warning: *retry-limit* not declared dynamic and thus is not dynamically rebindab le, but its name suggests otherwise. Please either indicate ^:dynamic *retry-lim it* or change the name. REPL started; server listening on localhost:53849. I think some thing is wrong, and I spent a lot of time and can't solve these problem, so ask help for me, thanks very much! -- -- You 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/groups/opt_out.
Re: Hacker News, Clojure, and GSOC
On Wednesday, April 17, 2013 3:27:59 AM UTC-4, da...@axiom-developer.org wrote: Does anyone know anyone associated with Hacker News? Can we clue them into immutable data structures? I know that Hacker News is mostly written by Paul Graham in Arc [1], his personal dialect of Lisp. As such, it's unlikely anyone will be able to convince him to switch to Clojure. :) P.G. recently wrote an article [2] about how he broke the site when manipulating the production database from the REPL. -S [1]: http://paulgraham.com/arc.html [2]: https://news.ycombinator.com/item?id=5239673 -- -- You 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/groups/opt_out.
Re: - operator and monads
Yes, I said that it's *like *function composition in reverse order. And only if you apply the function returned by comp, as I did in my example. It's not to be taken too literally, but it is perhaps helpful for people coming from language that have function composition but no analogue to -. On Sunday, 14 April 2013 21:03:20 UTC+1, Marko Topolnik wrote: On Sunday, April 14, 2013 7:51:10 PM UTC+2, Matthew Hill wrote: Function composition is done via comp. Using - and - is like function composition in reverse order (though there's a difference between how the two thread return values), and often it reads more naturally. - applies the functions immediately whereas comp returns a new function that is the composition of its arguments. - works with functions of any arity; comp only with unary functions. As pointed out above, - merely combines the unevaluated forms it is given, and only if they happen to be function application forms will the result be similar to function composition. -marko -- -- You 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/groups/opt_out.
Re: Head retention example
Great QA on this, thanks Marko! On Sunday, 14 April 2013 19:13:51 UTC+1, Marko Topolnik wrote: On Sunday, April 14, 2013 2:58:55 AM UTC+2, tyaakow wrote: I'm reading Clojure Programming book by O'Reilly.. I came over an example of head retention. First example retains reference to d (I presume), so it doesnt get garbage collected: (let [[t d] (split-with #( % 12) (range 1e8))] [(count d) (count t)]);= #OutOfMemoryError java.lang.OutOfMemoryError: Java heap space *split-with* gives you two windows into the same original sequence, which is *(range 1e8)*. You are first realizing the tail part *d*, then the head part *t*. So you are retaining the head while realizing most of the sequence. While second example doesnt retain it, so it goes with no problem: (let [[t d] (split-with #( % 12) (range 1e8))] [(count t) (count d)]);= [12 9988] Here the computation happens in the opposite order and you do not retain the head while realizing *d*. If I try to return just [(count d)], like this: (let [[t d] (split-with #( % 12) (range 1e8))] [(count d)]) - it seems to create same memory problem. Why is that? This happens because *t* is bound to the head of the sequence, even if you are not using it. This is probably a bug because the compiler should realize that *t* is not used and not bind it at all, or at least unbind it before evaluating *(count d)*. Further, I recall reading that count in every case realizes/evaluates a sequence. So, i need that clarified. As *count* realizes one element after another, it doesn't on its own retain a reference to the past elements. However, if you have another reference to the head of the sequence, then you'll transitively hold a reference to each and every member of the sequence, causing the complete sequence to stay in memory at the same time. This is what the lose your head maxim is about. -marko -- -- You 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/groups/opt_out.
Re: LambdaNext Clojure Workshop - London May 20-22 2013
Signed up for the 3 days with a colleague. Looking forward to it... On Monday, 15 April 2013 11:24:06 UTC+1, Sam Aaron wrote: Are you interested in becoming a professional Clojure programmer? Want to jumpstart your knowledge or simply take things to the next level? The LambdaNext team is holding a Clojure workshop in London, May 20-22 2013. Come join us! http://lambdanext.eu * An intensive learning experience The workshop is 3 days in total, the first two introduce the basics of the language and gear up to the last day which covers advanced concepts and techniques. You can opt for any combination of the the 2 and 1 day workshops. We'll be training from The Hub, Westminster (http://westminster.the-hub.net/) in Central London. The workshop will have at most 20 attendees, to 4 trainers. * Our world-class Clojure team We are a team of 4 long time professional and deeply enthusiastic Clojurists. We've deployed Clojure in a wide variety of interesting domains from atom splitting to live music making. Check out www.lambdanext.com for links to our blogs, projects and other details. Between us, we've have more experience teaching Clojure in Europe than anybody. You'll know you're in expert hands. * Our proven teaching method Our teaching method involves carefully sowing and then nurturing the seeds of Clojure's core concepts in an iterative manner. Our sowing phase of each concept takes place through an unplugged session which will scaffold and demonstrate the concept through the use of a variety of illustrative props and audience participation. This allows us to collectively get direct into the core of each individual idea. We will then fertilise and nurture these new concepts through an increasingly sophisticated set of mini-projects where you write code in groups with our guidance. This allows the ideas to be tested in a real context with chance for rapid and continuous feedback to accelerate the learning process. This is a truly intensive format and so we have all four of our trainers in the room to help, unblock and encourage. With a ratio of 20 attendees to 4 trainers you can guarantee you'll make rapid progress. * Caring for you We'll lay on a nutritious breakfast and lunch, and all the tea, coffee, juice and biscuits you can consume during the day. * Questions ? If you'd like to know more, or have any questions please drop us an email (in...@lambdanext.eu javascript:) or tweet (@LambdaNext). Sam, Edmund, Christophe and Meikel, The LambdaNext Team http://lambdanext.eu -- -- You 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/groups/opt_out.
ClojureWerkz now accepts donations
On behalf of the ClojureWerkz [1] team I'm happy to announced that ClojureWerkz now accepts donations. More at http://blog.clojurewerkz.org/blog/2013/04/17/clojurewerkz-now-accepts-donations/ . If you use Monger, Langohr, Elastisch, Neocons or any other of our libraries and feel they saved you time, please consider donating. Thanks. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You 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/groups/opt_out.
Re: invokedynamic instructions in Clojure
Brandon, Not really, but I don't want to deter anyone from exploration as its own goal. There are a lot of interesting ways that Clojure can leverage indy, this was an experiment. I'm going to try to put it in more high value places, and let the ideas marinate. This modification does nothing but actually use the instruction and pass all the tests. Obviously a lot of the really useful call sites for indy require much rework (and will break ABI and JVM compatibility, ick). The microarchitecture of how a language runtime can interact with its host platform is fascinating to explore. Btw, Attila Szegedi wrote the dynalink [1] library that has some abstractions over a lot of the machinery inside java.lang.invoke, definitely worth a look through. I think that performance is something exciting for developers, and I think indy will help with that...eventually. This needs hammock time, Clojure is definitely not slow today. [1] https://github.com/szegedi/dynalink/wiki/User-Guide-0.5 Ghadi @smashthepast On Tuesday, April 16, 2013 10:58:50 PM UTC-4, Brandon Bloom wrote: Do you have any measurements, results, or conclusions to report? On Tuesday, April 16, 2013 12:12:15 PM UTC-4, Ghadi Shayban wrote: I've added a very minimal usage of invokedynamic to the compiler. Basically the smallest delta without having to change internals of ObjExpr or break ABI compatibility. This is minimal and raw. There are many many usages of indy that will really help the Clojure runtime, this ain't one of them. No benchmarks here, it's probably slower. In current Clojure mainline, a Fn has reference slots to any vars it needs in its constant pool, like a cache. Anytime a non-dynamic Var's value needs to be accessed, the Var goes from the constant pool to the stack, and getRawRoot() is invoked on it. With this change, an invokedynamic instruction instead creates a ConstantCallSite, which closes over a looked-up Var, and then binds the call site to invoke getRawRoot() on it directly. This is only for non-dynamic Vars. Simple todos: cache the CallSite as a member on the Var itself so that all identical indy lookup instructions have fast bootstrapping. emit a similar call for dynamic vars remove the emission of Vars into the constant pool of a class Lots of really interesting use cases for invokedynamic and all the associated combinators in java.lang.invoke: Better protocol callsite caching CallSite middleware for things like CLJ specific instrumentation equality could be a special instruction KeywordCallSite could be its own instruction as well (apply) argument spreading/varargs array collection (through the combinators) potentially removing IFn.invoke(*) and using MethodHandle invocation instead (fat chance) You can pull down the changes at github.com/ghadishayban/clojure. mvn clean package, tested on OpenJDK 1.7 -- -- You 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/groups/opt_out.
Re: ClojureWerkz now accepts donations
What about Gittip? It'd be easier for me to just pass some of my donations along to you! On Apr 17, 2013 1:11 PM, Michael Klishin michael.s.klis...@gmail.com wrote: On behalf of the ClojureWerkz [1] team I'm happy to announced that ClojureWerkz now accepts donations. More at http://blog.clojurewerkz.org/blog/2013/04/17/clojurewerkz-now-accepts-donations/ . If you use Monger, Langohr, Elastisch, Neocons or any other of our libraries and feel they saved you time, please consider donating. Thanks. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You 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/groups/opt_out. -- -- You 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/groups/opt_out.
Re: ClojureWerkz now accepts donations
2013/4/17 Jason Lewis jasonlewi...@gmail.com What about Gittip? It'd be easier for me to just pass some of my donations along to you! See in FAQ: http://clojurewerkz.org/articles/donate.html -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You 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/groups/opt_out.
Re: ClojureWerkz now accepts donations
Ah... I missed the why only these limited options section. Sorry! Jason Lewis Email jasonlewi...@gmail.com Twitter@canweriotnow http://twitter.com/canweriotnow Blog http://decomplecting.org About http://about.me/jason.lewis On Wed, Apr 17, 2013 at 2:40 PM, Michael Klishin michael.s.klis...@gmail.com wrote: 2013/4/17 Jason Lewis jasonlewi...@gmail.com What about Gittip? It'd be easier for me to just pass some of my donations along to you! See in FAQ: http://clojurewerkz.org/articles/donate.html -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You 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/groups/opt_out. -- -- You 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/groups/opt_out.
Re: [ANN] Linode compromise possibly affecting Clojars
Update: thanks to an older backup from Ivan Kozik, we've been able to verify the integrity of all but 45 jars. It's likely these were legitimate redeployments by the maintainers, but I'm going to be reviewing the diffs by hand. I've attached a list of jars which haven't been verified. If your dependency tree (visible with `lein deps :tree` under Leiningen 2) does not include any of these then you should be completely clear. If it does you're probably still safe; I hope to have these cleared by the end of the day. From what we know from Linode, the exposed data could not have resulted in a compromise of the box without a reboot in order to reset passwords or use the rescue image, and we've confirmed that a reboot did not occur. So checking the jar diffs is probably not necessary, but we'd rather be extra-careful. thanks, Phil pgp2VesHkL5mX.pgp Description: PGP signature amazonica/amazonica/0.1.3/amazonica-0.1.3.jar amazonica/amazonica/0.1.4/amazonica-0.1.4.jar amazonica/amazonica/0.1.5/amazonica-0.1.5.jar antler/caribou-admin/0.10.0/caribou-admin-0.10.0.jar bwo/monads/0.1.0/monads-0.1.0.jar cc/qbits/alia/1.0.0-beta7/alia-1.0.0-beta7.jar chlorine/chlorine/1.5.2.1/chlorine-1.5.2.1.jar chlorine/chlorine/1.5.2.2/chlorine-1.5.2.2.jar chlorine/chlorine/1.5.3/chlorine-1.5.3.jar clj-diffmatchpatch/clj-diffmatchpatch/0.0.9.1/clj-diffmatchpatch-0.0.9.1.jar clj-diffmatchpatch/clj-diffmatchpatch/0.0.9.3/clj-diffmatchpatch-0.0.9.3.jar clj-diffmatchpatch/clj-diffmatchpatch/0.0.9/clj-diffmatchpatch-0.0.9.jar clojurewerkz/archimedes/1.0.0-alpha3/archimedes-1.0.0-alpha3.jar com/akolov/xelery/0.3.0/xelery-0.3.0.jar com/narkisr/carmine/1.6.0/carmine-1.6.0.jar com/narkisr/gelfino-client/0.4.0/gelfino-client-0.4.0.jar conveyor-coffeescript/conveyor-coffeescript/0.1.4/conveyor-coffeescript-0.1.4.jar core-cl2/core-cl2/0.7.0/core-cl2-0.7.0.jar core-cl2/core-cl2/0.7.1/core-cl2-0.7.1.jar docopt/docopt/0.6.1/docopt-0.6.1.jar factual/c4/0.0.11/c4-0.0.11.jar homestake-server/homestake-server/0.1/homestake-server-0.1.jar info/yasuhisay/clj-utils/0.1.1/clj-utils-0.1.1.jar info/yasuhisay/liblinear/0.0.1/liblinear-0.0.1.jar lamina/lamina/0.5.0-beta15/lamina-0.5.0-beta15.jar lein-haml-sass/lein-haml-sass/0.2.5/lein-haml-sass-0.2.5.jar lein-package/lein-package/0.1.2/lein-package-0.1.2.jar lib-noir/lib-noir/0.5.0/lib-noir-0.5.0.jar luminus/lein-template/0.5.3/lein-template-0.5.3.jar luminus/lein-template/0.5.5/lein-template-0.5.5.jar me/arrdem/imprecise/me.arrdem.imprecise/0.1.0/me.arrdem.imprecise-0.1.0.jar net/clojure/monads/1.0.1/monads-1.0.1.jar nsfw/lein-template/0.5.2/lein-template-0.5.2.jar org/flatland/phonograph/0.1.4/phonograph-0.1.4.jar org/trpr/integration-rabbitmq/1.2.2/integration-rabbitmq-1.2.2.jar org/trpr/platform-core/1.2.2/platform-core-1.2.2.jar org/trpr/platform-integration/1.2.2/platform-integration-1.2.2.jar rojat/rojat-arrows/0.0.6/rojat-arrows-0.0.6.jar rojat/rojat-math/0.0.2/rojat-math-0.0.2.jar rojat/rojat-math/0.0.3/rojat-math-0.0.3.jar rst-format-parser/rst-format-parser/0.0.1/rst-format-parser-0.0.1.jar service-hub/service-hub/1.0.3/service-hub-1.0.3.jar stereotype/stereotype/0.2.1/stereotype-0.2.1.jar stereotype/stereotype/0.2.2/stereotype-0.2.2.jar thebusby/clj-aws-ec2/0.2.2/clj-aws-ec2-0.2.2.jar
Re: [ANN] Linode compromise possibly affecting Clojars
Just wanted to say, awesome job with this. I appreciate your diligence! On Wed, Apr 17, 2013 at 2:50 PM, Phil Hagelberg p...@hagelb.org wrote: Update: thanks to an older backup from Ivan Kozik, we've been able to verify the integrity of all but 45 jars. It's likely these were legitimate redeployments by the maintainers, but I'm going to be reviewing the diffs by hand. I've attached a list of jars which haven't been verified. If your dependency tree (visible with `lein deps :tree` under Leiningen 2) does not include any of these then you should be completely clear. If it does you're probably still safe; I hope to have these cleared by the end of the day. From what we know from Linode, the exposed data could not have resulted in a compromise of the box without a reboot in order to reset passwords or use the rescue image, and we've confirmed that a reboot did not occur. So checking the jar diffs is probably not necessary, but we'd rather be extra-careful. thanks, Phil amazonica/amazonica/0.1.3/amazonica-0.1.3.jar amazonica/amazonica/0.1.4/amazonica-0.1.4.jar amazonica/amazonica/0.1.5/amazonica-0.1.5.jar antler/caribou-admin/0.10.0/caribou-admin-0.10.0.jar bwo/monads/0.1.0/monads-0.1.0.jar cc/qbits/alia/1.0.0-beta7/alia-1.0.0-beta7.jar chlorine/chlorine/1.5.2.1/chlorine-1.5.2.1.jar chlorine/chlorine/1.5.2.2/chlorine-1.5.2.2.jar chlorine/chlorine/1.5.3/chlorine-1.5.3.jar clj-diffmatchpatch/clj-diffmatchpatch/ 0.0.9.1/clj-diffmatchpatch-0.0.9.1.jar clj-diffmatchpatch/clj-diffmatchpatch/0.0.9.3/clj-diffmatchpatch-0.0.9.3.jar clj-diffmatchpatch/clj-diffmatchpatch/0.0.9/clj-diffmatchpatch-0.0.9.jar clojurewerkz/archimedes/1.0.0-alpha3/archimedes-1.0.0-alpha3.jar com/akolov/xelery/0.3.0/xelery-0.3.0.jar com/narkisr/carmine/1.6.0/carmine-1.6.0.jar com/narkisr/gelfino-client/0.4.0/gelfino-client-0.4.0.jar conveyor-coffeescript/conveyor-coffeescript/0.1.4/conveyor-coffeescript-0.1.4.jar core-cl2/core-cl2/0.7.0/core-cl2-0.7.0.jar core-cl2/core-cl2/0.7.1/core-cl2-0.7.1.jar docopt/docopt/0.6.1/docopt-0.6.1.jar factual/c4/0.0.11/c4-0.0.11.jar homestake-server/homestake-server/0.1/homestake-server-0.1.jar info/yasuhisay/clj-utils/0.1.1/clj-utils-0.1.1.jar info/yasuhisay/liblinear/0.0.1/liblinear-0.0.1.jar lamina/lamina/0.5.0-beta15/lamina-0.5.0-beta15.jar lein-haml-sass/lein-haml-sass/0.2.5/lein-haml-sass-0.2.5.jar lein-package/lein-package/0.1.2/lein-package-0.1.2.jar lib-noir/lib-noir/0.5.0/lib-noir-0.5.0.jar luminus/lein-template/0.5.3/lein-template-0.5.3.jar luminus/lein-template/0.5.5/lein-template-0.5.5.jar me/arrdem/imprecise/me.arrdem.imprecise/0.1.0/me.arrdem.imprecise-0.1.0.jar net/clojure/monads/1.0.1/monads-1.0.1.jar nsfw/lein-template/0.5.2/lein-template-0.5.2.jar org/flatland/phonograph/0.1.4/phonograph-0.1.4.jar org/trpr/integration-rabbitmq/1.2.2/integration-rabbitmq-1.2.2.jar org/trpr/platform-core/1.2.2/platform-core-1.2.2.jar org/trpr/platform-integration/1.2.2/platform-integration-1.2.2.jar rojat/rojat-arrows/0.0.6/rojat-arrows-0.0.6.jar rojat/rojat-math/0.0.2/rojat-math-0.0.2.jar rojat/rojat-math/0.0.3/rojat-math-0.0.3.jar rst-format-parser/rst-format-parser/0.0.1/rst-format-parser-0.0.1.jar service-hub/service-hub/1.0.3/service-hub-1.0.3.jar stereotype/stereotype/0.2.1/stereotype-0.2.1.jar stereotype/stereotype/0.2.2/stereotype-0.2.2.jar thebusby/clj-aws-ec2/0.2.2/clj-aws-ec2-0.2.2.jar -- -- You 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/groups/opt_out.
Re: Surprising behaviour related to records, protocols and AOT
I guess you have to import defrecord generated class before you want to use it, check the sample from clojuredocs about defrecord ; If you define a defrecord in one namespace and want to use it ; from another, first require the namespace and then import ; the record as a regular class. ; The require+import order makes sense if you consider that first ; the namespace has to be compiled--which generates a class for ; the record--and then the generated class must be imported. ; (Thanks to raek in #clojure for the explanations!) ; Namespace 1 in my/data.clj, where a defrecord is declared (ns my.data) (defrecord Employee [name surname]) ; Namescape 2 in my/queries.clj, where a defrecord is used (ns my.queries (:require my.data) (:import [my.data Employee])) (println Employees named Albert: (filter #(= Albert (.name %)) [(Employee. Albert Smith) (Employee. John Maynard) (Employee. Albert Cheng)])) -- -- You 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/groups/opt_out.
Clojure question
Hello, I'm doing a school paper on Clojure but there are two questions that i just can't find answers to anywhere they are: Are data types bound to variables and parameters at compile-time? run-time? a combination? and also, How are parameters passed? (Pass by value? Pass by reference? Pass by value-result? etc.) If anybody knows the answers to these two questions I would greatly appreciate it! -Matt -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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/groups/opt_out.
Re: Head retention example
On Monday, April 15, 2013 1:50:37 AM UTC+2, tyaakow wrote: Thank you for your response, Marko. I want to clarify one more thing: (let [[t d] (split-with #( % 12) (range 1e8))] [(count d) (count t)]) does this mean that while (count d) is realizing (range 1e8) seq, it becomes (also) realized within t, therefore it doubles (range 1e8) in memory causing OOME while (count d) is still not finished? There is no doubling: *t* and *d* share the same underlying lazy sequence and will refer to the same objects. The trouble is only that you force the evaluation of *(count d)* while *(count t)* still waits to be evaluated, so *t* must definitely stay bound to the head of the shared sequence. Also, you say As *count* realizes one element after another, it doesn't on its own retain a reference to the past elements. Does this mean that, eg. in repl, when I do some (count xyz) and it realizes xyz, It will later need to be reevaluated (realized again) if I require xyz within repl (I presume that if I require xyz later within file, it wont be GC due to it and clojure will know it shouldnt be GC) Be careful to observe that I say doesn't *on its own* retain a reference to the past elements. If you have *xyz* bound to the head of your sequence, it will force the entire sequence to stay in memory for as long as *xyz* is within scope (if it's a local) or indefinitely (if it's a global def'd var). Generally, a lazy sequence never gets un-realized once it got realized---the only option is for it to disappear entirely (turn into garbage). -marko -- -- You 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/groups/opt_out.
Re: Clojure question
Are data types bound to variables and parameters at compile-time? run-time? a combination? Clojure, like LISPs in general, is primarily a dynamically-typed language, so variables/parameters don't have a type assigned to them. However, on JVM Clojure there are optional type hints, which constrain the type at compile time. How are parameters passed? (Pass by value? Pass by reference? Pass by value-result? etc.) Clojure inherits the argument-passing semantics from Java. So it is pass-by-value, where the value passed is an object reference. In addition there are optimization facilities that enable the passing of primitive-typed values. -marko -- -- You 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/groups/opt_out.
Re: Surprising behaviour related to records, protocols and AOT
Changing 3) to also import the record class: (ns defrecordissue.aot1 (:require [defrecordissue.aprotocol] [defrecordissue.arecord]) (:import [defrecordissue.arecord ARecord])) makes no difference. Compilation still fails with the same exception. This is obviously a contrived example. When I encountered this in the wild, the consumer of the equivalent of the defrecord.aprotocol namespace did not construct a record instance directly. It has no awareness of the record type, and should not need to have so. On Wednesday, 17 April 2013 20:13:36 UTC+1, Andrew Sernyak wrote: I guess you have to import defrecord generated class before you want to use it, check the sample from clojuredocs about defrecord ; If you define a defrecord in one namespace and want to use it ; from another, first require the namespace and then import ; the record as a regular class. ; The require+import order makes sense if you consider that first ; the namespace has to be compiled--which generates a class for ; the record--and then the generated class must be imported. ; (Thanks to raek in #clojure for the explanations!) ; Namespace 1 in my/data.clj, where a defrecord is declared (ns my.data) (defrecord Employee [name surname]) ; Namescape 2 in my/queries.clj, where a defrecord is used (ns my.queries (:require my.data) (:import [my.data Employee])) (println Employees named Albert: (filter #(= Albert (.name %)) [(Employee. Albert Smith) (Employee. John Maynard) (Employee. Albert Cheng)])) -- -- You 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/groups/opt_out.
Re: [ANN] Linode compromise possibly affecting Clojars
Update: I've manually reviewed a diff[1] of all changes to jars published since the intrusion. I found nothing suspicious in the diff, but I did see a couple instances of bytecode in it. Two of them were just bytecode being removed, but in one of them the bytecode changed when the new copy was redeployed. So the current status is that we've verified everything except rst-format-parser. This seems to be a fairly obscure jar with only 21 downloads listed. But I've contacted the maintainer to ask him to either verify the checksum or redeploy a known-good jar. Unless you're one of the few people using this jar, you should be safe[2]. Happy hacking, Phil [1] - http://p.hagelb.org/clojars-republished.diff.html [2] - By safe here, I mean as safe as you were before the intrusion. You're probably still trusting unsigned jars. We're working on making it easier to have good reason to trust your dependencies, but it's slow going. -- -- You 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/groups/opt_out.
Re: Head retention example
Note that the problem is not that t needs to hang around; it's that t holds a lazy sequence which hangs around in unrealized state. That lazy sequence internally holds a thunk -- a nullary function -- capable of producing the actual sequence elements on request. It is this thunk that holds a reference to the underlying huge sequence. Once t is realized, the actual sequence gets cached and the thunk becomes eligible for GC (the field holding it is set to null). If it then needs to stay around for some other purpose, that is no problem: user= (let [[t d] (split-with #( % 12) (range 1e8))] [(count t) (count d) (count t)]) [12 9988 12] (Or I suppose you could return [(count d) (count t)], but (dorun t) before that.) Also, just to be explicit about this, calling (let [x (produce-huge-seq)] (count x)) is not a problem, because x gets cleared prior to control being handed off to count. I've also discussed the details of what's going on on SO, which is where I first noticed this question: http://stackoverflow.com/questions/15994316/clojure-head-retention Cheers, Michał On 17 April 2013 22:53, Marko Topolnik marko.topol...@gmail.com wrote: On Monday, April 15, 2013 1:50:37 AM UTC+2, tyaakow wrote: Thank you for your response, Marko. I want to clarify one more thing: (let [[t d] (split-with #( % 12) (range 1e8))] [(count d) (count t)]) does this mean that while (count d) is realizing (range 1e8) seq, it becomes (also) realized within t, therefore it doubles (range 1e8) in memory causing OOME while (count d) is still not finished? There is no doubling: t and d share the same underlying lazy sequence and will refer to the same objects. The trouble is only that you force the evaluation of (count d) while (count t) still waits to be evaluated, so t must definitely stay bound to the head of the shared sequence. Also, you say As count realizes one element after another, it doesn't on its own retain a reference to the past elements. Does this mean that, eg. in repl, when I do some (count xyz) and it realizes xyz, It will later need to be reevaluated (realized again) if I require xyz within repl (I presume that if I require xyz later within file, it wont be GC due to it and clojure will know it shouldnt be GC) Be careful to observe that I say doesn't on its own retain a reference to the past elements. If you have xyz bound to the head of your sequence, it will force the entire sequence to stay in memory for as long as xyz is within scope (if it's a local) or indefinitely (if it's a global def'd var). Generally, a lazy sequence never gets un-realized once it got realized---the only option is for it to disappear entirely (turn into garbage). -marko -- -- You 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/groups/opt_out. -- -- You 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/groups/opt_out.
monkey patch
I suspect I've hit a problem where korma and h2 don't like each other. Korma likes to group join clauses with parentheses (via korma.sql.utils/left-assoc), but the parentheses appear to prevent h2 from picking appropriate indexes, so the performance is unusable. Removing the parentheses fixes the query. I'm not very excited about manipulating raw sql strings, or patching rebuilding korma for this case. Are there any good ways to work around this? Or good alternatives to korma? If there are no good options, can I monkey patch it? And if so, how would I do that? I.e. can I replace a function in korma.sql.engine such that when I invoke korma it will use the new function? -- -- You 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/groups/opt_out.
Re: [ANN] Linode compromise possibly affecting Clojars
Andrew Wagner writes: Just wanted to say, awesome job with this. I appreciate your diligence! Thanks! Luckily part of my job at Heroku is to keep an eye out for this kind of thing, so that's why I'm able to spend more cycles on it when issues do arise. But Alex Osborne, Ivan Kozik, and Nelson Morris also helped a lot. -Phil pgp7_5gke3ryI.pgp Description: PGP signature
Re: monkey patch
2013/4/18 Brian Craft craft.br...@gmail.com If there are no good options, can I monkey patch it? And if so, how would I do that? I.e. can I replace a function in korma.sql.engine such that when I invoke korma it will use the new function? (in-ns 'korma.sql.engine (defn ...)) Use it at your own peril. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You 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/groups/opt_out.
Re: Some docs on comparators, including mistakes to avoid, Clojure extended doc strings
A document that may perhaps contain more than most people want to know about Clojure = and == https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/equality.md Andy On Thu, Apr 4, 2013 at 12:49 PM, Andy Fingerhut andy.finger...@gmail.comwrote: The document on comparator functions alone might be of interest to a few people. You can read it here: https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/comparators.md It has a few examples of good comparators, and mistakes to avoid when writing them that I have seen asked about here. I take some inspiration from what I consider to be pretty good documentation for a programming language: Perl. Type man perlfunc in a Linux or Mac OS X shell and you'll see what I mean. Useful examples, corner cases, pitfalls, etc. I like, use, and promote ClojureDocs.org, but I also like the idea of something a bit more curated. -- -- You 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/groups/opt_out.
Re: [ANN] Linode compromise possibly affecting Clojars
For the sake of completeness I've included Alex Osborne's analysis of the situation below. (Alex runs Clojars.) -Phil The really annoying thing about security is it's impossible to conclusively prove at any time anything is secure if you assume a sufficiently sophisticated attacker. All we can do is best effort. Check my logic here. There are four categories of files to verify. The obvious jar overwrite: When a file is overwritten such that it's mtime or size changed Ivan's backups move the original version into a ./overwritten/ directory for that timestamp. This means that any files that were obviosuly overwritten after April 1 are in this subset: https://gist.github.com/ato/459ee535125e6a5b5489[1] We could try to verify these with jar diffs. The sneaky jar overwrite: However if a file was overwritten such that the mtime and size didn't change, then Ivan would never have fetched the new version. We can verify these by testings against Ivan's current sha1s. I have done this and found no discrepancies. The only files that didn't match were the expected, those updated today after Ivan had calculated his hashes: ./nsfw/lein-template/0.5.2/lein-template-0.5.2.jar ./antler/lein-caribou/2.1.2/lein-caribou-2.1.2.jar The obvious new jar: The attacker may not have overwritten an existing jar but added a new one (new version of a popular library say). I don't see how we can verify these (as being legit or not). This would have a lower value to the attacker compared to overwriting a popular existing version. The sneaky new jar: If a new file was created but backdated (with an mtime in the past) Ivan will have downloaded it but the -a option to rsync will mean his timestamps are also backdated. This might be detectable by diffing Ivan's copies of the all-jars metadata file I guess. -- Now rather than modifying the repository immediately the attacker could have installed a mechanism for uploading a malicious file at a later date: * change passwords, ssh keys, groups or email addresses in clojars db * steal the SSL private key (for later use in MITM attacks) * backdoor the VM db: I don't have an offsite db backup recently predating the attack. The closest thing I have is a backup taken with Linode's own backup infrastructure on April 7 which is too late to conclude much from. I compared the April 7 db with todays and there were a number of password changes since then, including some of the people that contacted us for support about it. ssl: If the attacker can perform MITM attacks against them most users will be screwed anyway as they will be accessing other repositories like Maven Central over unprotected HTTP. However if we do discover any evidence of the VM being comprised I'll request it be revoked. vm backdoor: I've checked the obvious things (shadow entries, authorized_keys files, running processes). But there's no way to verify this with high confidence. We could do a fresh OS install I suppose, I was intending to upgrade to Ubuntu 12.04 sometime this year anyway. -- Finally if we take Linode's statements at face value I think it's very unlikely Clojars was compromised. They state that the attackers gained access only to the web server not the VM hosts. The evidence presented by ryan (who claimed to be one of the attackers) also only referred to the web server and database. The most straightforward ways for the web server to compromise a customer VM: * There is a form to reset the root password of a target VM, this requires rebooting the VM as it modifies the filesystem offline. * You can use the LISH password (cleartext in db) to get to the VM's serial console. This doesn't directly get you in as the getty still prompts you to login. * You can reboot the VM against a rescue disk image which you control through the console. The clojars VM hasn't been rebooted in the last few months. If Linode is wrong and the VM host was rooted a (somewhat sophisticated) online attack would be possible via memory modification. pgpwOufQwNng5.pgp Description: PGP signature
Re: [ANN] Linode compromise possibly affecting Clojars
+1 On Thursday, 18 April 2013 05:04:47 UTC+10, Andrew Wagner wrote: Just wanted to say, awesome job with this. I appreciate your diligence! On Wed, Apr 17, 2013 at 2:50 PM, Phil Hagelberg ph...@hagelb.orgjavascript: wrote: Update: thanks to an older backup from Ivan Kozik, we've been able to verify the integrity of all but 45 jars. It's likely these were legitimate redeployments by the maintainers, but I'm going to be reviewing the diffs by hand. I've attached a list of jars which haven't been verified. If your dependency tree (visible with `lein deps :tree` under Leiningen 2) does not include any of these then you should be completely clear. If it does you're probably still safe; I hope to have these cleared by the end of the day. From what we know from Linode, the exposed data could not have resulted in a compromise of the box without a reboot in order to reset passwords or use the rescue image, and we've confirmed that a reboot did not occur. So checking the jar diffs is probably not necessary, but we'd rather be extra-careful. thanks, Phil amazonica/amazonica/0.1.3/amazonica-0.1.3.jar amazonica/amazonica/0.1.4/amazonica-0.1.4.jar amazonica/amazonica/0.1.5/amazonica-0.1.5.jar antler/caribou-admin/0.10.0/caribou-admin-0.10.0.jar bwo/monads/0.1.0/monads-0.1.0.jar cc/qbits/alia/1.0.0-beta7/alia-1.0.0-beta7.jar chlorine/chlorine/1.5.2.1/chlorine-1.5.2.1.jar chlorine/chlorine/1.5.2.2/chlorine-1.5.2.2.jar chlorine/chlorine/1.5.3/chlorine-1.5.3.jarhttp://1.5.2.2/chlorine-1.5.2.2.jarchlorine/chlorine/1.5.3/chlorine-1.5.3.jar clj-diffmatchpatch/clj-diffmatchpatch/ 0.0.9.1/clj-diffmatchpatch-0.0.9.1.jar clj-diffmatchpatch/clj-diffmatchpatch/0.0.9.3/clj-diffmatchpatch-0.0.9.3.jar clj-diffmatchpatch/clj-diffmatchpatch/0.0.9/clj-diffmatchpatch-0.0.9.jar clojurewerkz/archimedes/1.0.0-alpha3/archimedes-1.0.0-alpha3.jar com/akolov/xelery/0.3.0/xelery-0.3.0.jarhttp://0.0.9.1/clj-diffmatchpatch-0.0.9.1.jarclj-diffmatchpatch/clj-diffmatchpatch/0.0.9.3/clj-diffmatchpatch-0.0.9.3.jarclj-diffmatchpatch/clj-diffmatchpatch/0.0.9/clj-diffmatchpatch-0.0.9.jarclojurewerkz/archimedes/1.0.0-alpha3/archimedes-1.0.0-alpha3.jarcom/akolov/xelery/0.3.0/xelery-0.3.0.jar com/narkisr/carmine/1.6.0/carmine-1.6.0.jar com/narkisr/gelfino-client/0.4.0/gelfino-client-0.4.0.jar conveyor-coffeescript/conveyor-coffeescript/0.1.4/conveyor-coffeescript-0.1.4.jar core-cl2/core-cl2/0.7.0/core-cl2-0.7.0.jar core-cl2/core-cl2/0.7.1/core-cl2-0.7.1.jar docopt/docopt/0.6.1/docopt-0.6.1.jar factual/c4/0.0.11/c4-0.0.11.jar homestake-server/homestake-server/0.1/homestake-server-0.1.jar info/yasuhisay/clj-utils/0.1.1/clj-utils-0.1.1.jar info/yasuhisay/liblinear/0.0.1/liblinear-0.0.1.jar lamina/lamina/0.5.0-beta15/lamina-0.5.0-beta15.jar lein-haml-sass/lein-haml-sass/0.2.5/lein-haml-sass-0.2.5.jar lein-package/lein-package/0.1.2/lein-package-0.1.2.jar lib-noir/lib-noir/0.5.0/lib-noir-0.5.0.jar luminus/lein-template/0.5.3/lein-template-0.5.3.jar luminus/lein-template/0.5.5/lein-template-0.5.5.jar me/arrdem/imprecise/me.arrdem.imprecise/0.1.0/me.arrdem.imprecise-0.1.0.jar net/clojure/monads/1.0.1/monads-1.0.1.jar nsfw/lein-template/0.5.2/lein-template-0.5.2.jar org/flatland/phonograph/0.1.4/phonograph-0.1.4.jar org/trpr/integration-rabbitmq/1.2.2/integration-rabbitmq-1.2.2.jar org/trpr/platform-core/1.2.2/platform-core-1.2.2.jar org/trpr/platform-integration/1.2.2/platform-integration-1.2.2.jar rojat/rojat-arrows/0.0.6/rojat-arrows-0.0.6.jar rojat/rojat-math/0.0.2/rojat-math-0.0.2.jar rojat/rojat-math/0.0.3/rojat-math-0.0.3.jar rst-format-parser/rst-format-parser/0.0.1/rst-format-parser-0.0.1.jar service-hub/service-hub/1.0.3/service-hub-1.0.3.jar stereotype/stereotype/0.2.1/stereotype-0.2.1.jar stereotype/stereotype/0.2.2/stereotype-0.2.2.jar thebusby/clj-aws-ec2/0.2.2/clj-aws-ec2-0.2.2.jar -- -- You 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/groups/opt_out.
