Re: Effects of diving into Clojure
+1 here. I'm afraid the only solution I've found is to stop writing Ruby. ¯\_(ツ)_/¯ On Tue, Jan 14, 2014 at 2:39 PM, Mark markaddle...@gmail.com wrote: I misread the critical piece of your post :) You are, indeed, a step ahead of me On Tuesday, January 14, 2014 11:30:13 AM UTC-8, g vim wrote: It's been the other way round for me. I always felt Ruby was doing too much under the hood. So much so that I bought Ruby Under A Microscope just to find out what was going on. I found it very easy to switch to Clojure because everything is so much more transparent. Now Ruby just feels awkward though I still need to use it due to its mindshare in the web development domain. gvim On 14/01/2014 19:18, Mark wrote: I have felt your pain. I started life with Smalltalk and more or less spent the last 15 years in Java. When I started Clojure, it was very hard to break my thinking habits. Particularly, I was lost without manifest typing. I didn't realize how much types documented my system and allowed very lazy thinking on my part. I had less trouble with immutability as I had developed the habit of coding immutable objects in Java. I started dabbling in Clojure about a year ago and started coding a serious project about 3 months ago. Only recently have I gotten used to thinking about mapping functions over data as opposed to looping through a collection although I still find myself coding loop/recur and then realizing I could use map. I've also developed very different work habits due to the REPL. In my own case, the particular changes in my thinking that have really aided me are: 1. Being able to visualize the data structure that a function is operating on 2. I find that my code falls into two categories: computing new data or transforming data structures 3. Never try to compute new data and transform data at the same time 4. Much of the time computing new data is either map or reduce. Understanding these two (especially the flexibility of reduce) is huge 5. 80% of the time that I want to transform data, postwalk is the answer I'm sure that as I get to know the Clojure libraries better, the specifics around #4 and #5 will change but I bet the first three are pretty constant. -- -- You 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: How to handle configuration in Clojure?
Another option is to use leiningen profiles to change the classpath, loading different versions of a (eg) config.clj file in different environments. This lets you `require` the config namespace and refer to config parameters like `config/the-configured-value` Travis On Mon, Jan 13, 2014 at 11:05 AM, Andrey Antukh n...@niwi.be wrote: https://github.com/james-henderson/nomad can be one option for manage/store a configuration ;) (it uses edn...) Andrey 2014/1/13 Joachim De Beule joachim.de.be...@gmail.com There's also this: https://github.com/clojure-cookbook/clojure-cookbook/blob/master/local-io/edn-config/edn-config.asciidoc Joachim -- -- You 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. -- Andrey Antukh - Андрей Антух - andrei.anto...@kaleidos.net / n...@niwi.be http://www.niwi.be https://github.com/niwibe -- -- You 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.
[ANN] progressbar: easy progress bars in clojure
progressbar transparently wraps any map-able object to print feedback to standard out as items in the seq are processed: user (require '[progressbar.core :refer [progressbar]]) user (doall (map identity (progressbar (range 10) :print-every 2))) [) # this is animated from [) to [) using \r (0 1 2 3 4 5 6 7 8 9) It is designed to make getting feedback about a long running seq-based computation trivial. More information, and the source, here: http://eng.copious.com/blog/2013/08/05/progressbar/ https://github.com/travis/progressbar Enjoy! Travis -- -- You 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 in production
We've used Clojure at Copious (http://copious.com) to build our activity feed (http://www.youtube.com/watch?v=0l7Va3-wXeI) and a number of backend services. We're definitely looking to use it even more in the future: it's the cat's pajamas. On Thu, Jun 13, 2013 at 2:07 PM, Deepak Giridharagopal dee...@puppetlabs.com wrote: On Monday, June 10, 2013 3:47:25 PM UTC-6, Plinio Balduino wrote: Hi there I'm writing a talk about Clojure in the real world and I would like to know, if possible, which companies are using Clojure for production or to make internal tools. Puppet Labs (http://puppetlabs.com) uses Clojure in some of our internal tools, commercial projects, and open source stuff. I gave a talk on PuppetDB (https://github.com/puppetlabs/puppetdb) at Clojure/West a few months ago. It's currently in production at ~10k installations across the planet. Thank you Plínio Balduino -- -- You 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: user math expression evaluation
Incanter has some stuff that does this: http://data-sorcery.org/2010/05/14/infix-math/ this looks even closer to what you're looking for: https://github.com/tristan/clojure-infix On Tue, May 28, 2013 at 2:19 PM, Brian Craft craft.br...@gmail.com wrote: Are there any existing libs for the evaluation of math expressions? For example, if the user enters x + sin(y), parse and evaluate the expression, given vectors of floats for x and y. -- -- You 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: binding funkiness
Hi Daniel map is creating a lazy seq, which isn't evaluated until the REPL's forces it to be printed, which is outside the scope of the binding. This: (binding [*funkybind* true] (doall (map (fn [_] *funkybind*) [1 2]))) forces evaluation inside the binding, and does what you want. This is something I've been bitten by a few times, but the power that lazyness brings ends up being worth it, IMHO. Good luck! Travis On Mon, Apr 22, 2013 at 9:41 PM, Daniel Higginbotham nonrecurs...@gmail.com wrote: I've encountered a situation where the binding function doesn't work as I expect it: user (def ^:dynamic *funkybind* false) ;; expected user (binding [*funkybind* true] *funkybind*) true ;;expected (binding [*funkybind* true] ((fn [] *funkybind*))) true ;;... huh? (binding [*funkybind* true] (map (fn [_] *funkybind*) [1 2])) (false false) In the last example, why is the value of *funkybind* false instead of true? Thanks! Daniel -- -- You 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: Namespaces, APIs, protocols and records
For what it's worth, I've been refactoring big namespaces out into small, focused namespaces lately. A rough heuristic I've found useful is that when I require a namespace I should be able to assign it a name that aids with readability. So for example: (ns foo.book) (defn search [book term] ;;search the book ) -- (ns foo.stacks) (defn search [stacks title] ;; search stacks ) -- (ns foo.library (require [foo.book :as book] [foo.stacks :as stacks])) (defn find-passage [stacks passage title] (- stacks (stacks/search title) (books/search passage))) - This is all pretty contrived, but it seems to work out in the wild pretty well. YMMV, and I'm still not settled on this myself, but hopefully that helps. Travis On Sun, Apr 14, 2013 at 2:16 PM, Simon Katz nomisk...@gmail.com wrote: Whoops — when I said with an extra [namespace] for each protocol, I meant with an extra [namespace] for each protocol implementation. On Sunday, 14 April 2013 18:21:19 UTC+1, Simon Katz wrote: I'm in the process of trying to work out how I want to use namespaces when implementing libraries or subsystems. I'm aware of several approaches: Use a single namespace, making only the API public (either with everything in a single file or breaking things into multiple files and using `load`). Use implementation namespaces and create an API in a separate namespace (perhaps using Potemkin to simplify the creation of the API). Have lots of smaller namespaces and have the client need to know which of the smaller namespaces to use for what. (And some variations.) I'm fairly happy with large namespaces, so I'm leaning towards using a single namespace. There's one thing I've come across that doesn't fit nicely with putting everything into a single namespace, though. A Google search for Clojure in the Large led me to a nice talk by Stuart Sierra (http://vimeo.com/46163090) in which he suggests putting protocols and their implementations in separate namespaces, because, during development reloading a protocol breaks existing instances. (I know Stuart gave a similarly presentation at Clojure West recently, but I don't think the video of that is available yet.) Having the separate namespaces would be fine if I was heading down the route of having the client know about multiple namespaces, but I don't really want to do that. With the single namespace approach (with an extra one for each protocol I define), I end up wanting circular dependencies — a namespace containing a protocol implementation needs to refer to the main namespace in order to mention the protocol, and the main namespace needs to refer to the namespaces containing protocol implementations in order to invoke constructors. Maybe I'll just put everything in a single namespace and be careful about reloading the whole thing when I care about existing instances of protocols. Any other suggestions? Simon -- -- You 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: Namespaces, APIs, protocols and records
I definitely like that it keeps things simpler for me (the implementer), but clients have to know about multiple namespaces rather than a single namespace and I don't like that. Ah, right - I've mostly been working in application code, not libraries. That said, I think the heuristic still works - I'd definitely try writing some code that consumes your library, either in tests or in a dummy project, and apply the same rule: can you give the namespace a name that makes function calls clearer? Given a single name, are there pieces that feel out of place? This is a topic that comes up a lot, and I think that's at least partially because different domains and library styles call for different strategies. An ideal library that does one thing really well might indeed be a good candidate for one big public namespace, but of course internally it might make a lot of sense to break the implementation up into focused modules. You might check out the clojurewerks libraries for some insight from a group that has written quite a few libraries: http://clojurewerkz.org/ Travis On Mon, Apr 15, 2013 at 11:23 AM, Simon Katz nomisk...@gmail.com wrote: I'm considering going this way. I definitely like that it keeps things simpler for me (the implementer), but clients have to know about multiple namespaces rather than a single namespace and I don't like that. I must say I'm finding it hard to decide which way to go. On Monday, 15 April 2013 15:31:49 UTC+1, travis vachon wrote: For what it's worth, I've been refactoring big namespaces out into small, focused namespaces lately. A rough heuristic I've found useful is that when I require a namespace I should be able to assign it a name that aids with readability. So for example: (ns foo.book) (defn search [book term] ;;search the book ) -- (ns foo.stacks) (defn search [stacks title] ;; search stacks ) -- (ns foo.library (require [foo.book :as book] [foo.stacks :as stacks])) (defn find-passage [stacks passage title] (- stacks (stacks/search title) (books/search passage))) - This is all pretty contrived, but it seems to work out in the wild pretty well. YMMV, and I'm still not settled on this myself, but hopefully that helps. Travis On Sun, Apr 14, 2013 at 2:16 PM, Simon Katz nomi...@gmail.com wrote: Whoops — when I said with an extra [namespace] for each protocol, I meant with an extra [namespace] for each protocol implementation. On Sunday, 14 April 2013 18:21:19 UTC+1, Simon Katz wrote: I'm in the process of trying to work out how I want to use namespaces when implementing libraries or subsystems. I'm aware of several approaches: Use a single namespace, making only the API public (either with everything in a single file or breaking things into multiple files and using `load`). Use implementation namespaces and create an API in a separate namespace (perhaps using Potemkin to simplify the creation of the API). Have lots of smaller namespaces and have the client need to know which of the smaller namespaces to use for what. (And some variations.) I'm fairly happy with large namespaces, so I'm leaning towards using a single namespace. There's one thing I've come across that doesn't fit nicely with putting everything into a single namespace, though. A Google search for Clojure in the Large led me to a nice talk by Stuart Sierra (http://vimeo.com/46163090) in which he suggests putting protocols and their implementations in separate namespaces, because, during development reloading a protocol breaks existing instances. (I know Stuart gave a similarly presentation at Clojure West recently, but I don't think the video of that is available yet.) Having the separate namespaces would be fine if I was heading down the route of having the client know about multiple namespaces, but I don't really want to do that. With the single namespace approach (with an extra one for each protocol I define), I end up wanting circular dependencies — a namespace containing a protocol implementation needs to refer to the main namespace in order to mention the protocol, and the main namespace needs to refer to the namespaces containing protocol implementations in order to invoke constructors. Maybe I'll just put everything in a single namespace and be careful about reloading the whole thing when I care about existing instances of protocols. Any other suggestions? Simon -- -- 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 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 For more options, visit this group at http://groups.google.com/group
Re: What's the point of - ?
- can also be used in conjunction with a well designed DSL to construct values in a very readable fashion. clj-time has some great examples of this: http://seancorfield.github.com/clj-time/doc/clj-time.core.html#var-from-now (- 30 minutes from-now) http://seancorfield.github.com/clj-time/doc/clj-time.core.html#var-ago : (- 5 years ago) Note that this takes advantage of the fact that (- 30 minutes from-now) is equivalent to (- 30 (minutes) (from-now)) t On Mon, Mar 11, 2013 at 12:29 PM, Fogus mefo...@gmail.com wrote: I wrote a post about - and - a few years ago that might be helpful. http://blog.fogus.me/2009/09/04/understanding-the-clojure-macro/ -- -- You 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: :use an entire namespace full of protocols or stick with :require?
Speaking strictly for myself, but as someone who spends about half his professional day writing Clojure: :use is dead, long live :require. I've found using :require [foo :refer :all] rather than :use foo has lead to cleaner, more consistent ns statements in my own code, and I've made it a policy to convert old :use statements to :refer :all whenever possible. Travis On Sat, Mar 9, 2013 at 6:00 PM, Korny Sietsma ko...@sietsma.com wrote: [reviving a slightly old thread] Note that as of clojure 1.4 you can also do: (:require foo.bar :refer :all) in fact from comments I've seen elsewhere there is a general intention to remove :use entirely? It'd be good to have some clarity on this. The vast majority of code samples use :use, some with :only. The docstring for ns doesn't even mention :refer! The clojure cheatsheet points to http://clojuredocs.org/clojure_core/clojure.core/ns which _does_ have the new syntax, in the last couple of examples; and it links to the tutorial at http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html which uses 'use' throughout, except for an easily missable update half way through that says to use :refer. So, to what extent are people actually deprecating :use ? I'm introducing a new team to clojure and trying to suggest that :refer is the way to go, but it's tricky when every code sample out there uses :use. Especially for the situation where you actually want to import a whole namespace - should we be using: (:use midje.sweet) or: (:require midje.sweet :refer :all) ? - Korny On 15 February 2013 00:26, Jim foo.bar jimpil1...@gmail.com wrote: I know that using a bare :use in the ns macro is generally frowned upon as it provides no hints about what is actually being used... However, I 've got 2 namespaces 'abstractions.clj' and 'concretions.clj'...concretions.clj will eventually use all the protocols defined in abstractions.clj...at the moment it doesn't but as I work through it I want to provide concrete records for all the protocols... Should I just go and :use the entire thing or should I stick with :require and keep typing 'pro/XXX' a million times? That specific namespace is very central to my work... Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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. -- Kornelis Sietsma korny at my surname dot com http://korny.info We do not quit playing because we grow old, we grow old because we quit playing - O.W. Holmes -- -- You 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: Maps, keywords, and functions
Having both options available also allows you to make NullPointerException-averse decisions as appropriate. That is, in this function: (defn foo [a-map] (a-map :foo)) I'm potentially exposed to an NPE if the given map is nil. By rewriting it: (defn foo [a-map] (:foo a-map)) I avoid this possibility, and the function returns nil even when a-map is nil. The reverse is also frequently useful. On Thursday, December 20, 2012 6:13:23 PM UTC-5, Jonathon McKitrick wrote: I thought it was pretty interesting to treat maps as functions, and even more intrigued at treating keywords as functions as well. What does this gain from a language design perspective, that you cannot get with (get map keyword) or ever (map keyword)? Why the additional option of (keyword map) ? -- You 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: ANN: lein-cdt 1.0.0 - a leiningen plugin for the Clojure Debugging Toolkit
Unfortunately I haven't used cake at all, sorry! Travis On Tue, Jan 11, 2011 at 12:15 AM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hi, Thanks Travis. This is something I have wanted for a long time .. Have you tried using it with cake? would it work with Cake? Sunil. On Mon, Jan 10, 2011 at 9:34 PM, Travis Vachon travis.vac...@gmail.com wrote: Hi folks I'd like to announce the first stable release of lein-cdt, a leiningen plugin that makes running George Jahad's excellent Clojure Debugging Toolkit a little easier. George has been polishing CDT over the past couple weeks and we both hope that this plugin will help others start to use and provide feedback on this tool: https://github.com/travis/lein-cdt http://clojars.org/lein-cdt This release includes: lein cdt - a leiningen task to start a CDT REPL that will automatically connect to a running debug JVM lein cdt-emacs - a leiningen task that will download necessary binary and source dependencies to a central location and print instructions for setting up emacs integration with CDT Nota bene: * The 1.0.0 status of lein-cdt implies that lein-cdt's API is relatively stable - easy to do because it's not a lot of code. It does not imply anything with regards to CDT itself. * Some important limitations are noted on the GitHub page - please be sure to read through these before reporting issues. Comments, questions and contributions welcome! Travis -- You 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
ANN: lein-cdt 1.0.0 - a leiningen plugin for the Clojure Debugging Toolkit
Hi folks I'd like to announce the first stable release of lein-cdt, a leiningen plugin that makes running George Jahad's excellent Clojure Debugging Toolkit a little easier. George has been polishing CDT over the past couple weeks and we both hope that this plugin will help others start to use and provide feedback on this tool: https://github.com/travis/lein-cdt http://clojars.org/lein-cdt This release includes: lein cdt - a leiningen task to start a CDT REPL that will automatically connect to a running debug JVM lein cdt-emacs - a leiningen task that will download necessary binary and source dependencies to a central location and print instructions for setting up emacs integration with CDT Nota bene: * The 1.0.0 status of lein-cdt implies that lein-cdt's API is relatively stable - easy to do because it's not a lot of code. It does not imply anything with regards to CDT itself. * Some important limitations are noted on the GitHub page - please be sure to read through these before reporting issues. Comments, questions and contributions welcome! Travis -- You 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
