Re: Coverage tools in Clojure

My 2c - on my last project it would have been handy to have some test coverage tools, they can be useful to sanity check your testing. However, it's worth noting that compared to a java project, we had far fewer lines of code, so manually reviewing code for tests was a lot easier. And there were

Re: Coverage tools in Clojure

Comments in line. On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: > > > I don't want to seem rude but I think you've drank a bit too much > kool-aid. > You know the phrase "I don't want to seem rude" doesn't actually do anything right? :) > To say that functional programming an

Re: Lessons Learned from Adopting Clojure

Is there going to be online access during/after the event? I would greatly value seeing this, but probably not enough to travel from the UK to Chicago :). On Tuesday, 4 February 2014 12:06:06 UTC, Jay Fields wrote: > > tl; dr: I'm presenting "Lessons Learned from Adopting Clojure" in > Chicago

Re: Coverage tools in Clojure

In clojure, generally I've found Unit-tests are often significantly harder to write than the corresponding implementing code, idiomatic code rarely has silly problems, and integration tests are enough to shake out bad behavior. So, the end result is constraining our codebase at API boundaries wit

Re: ANN: Reagent 0.3.0 - now with async rendering

On Tuesday, February 4, 2014 11:24:16 AM UTC+1, Robin Heggelund Hansen wrote: > Gotta ask, what's the difference between Om and Reagent? > Well, I'd say that the basic functionality of the two is quite similar: it's all about efficiently transforming some application state into a UI descripti

Re: Coverage tools in Clojure

+1 I still force myself to write those tests simply for the confidence they give me in replacing my hack with idiomatic code as I/colleagues get more familiar down the road. I can absolutely see dramatically reducing the number of 'safety rails' type tests pretty soon; most of the code uses th

Re: Lessons Learned from Adopting Clojure

Interesting! A question: did you abandon TDD? why? IMO, TDD is a workflow that pushes for simplicity On Tue, Feb 4, 2014 at 9:22 AM, Colin Yates wrote: > Is there going to be online access during/after the event? I would > greatly value seeing this, but probably not enough to travel from the

Re: Lessons Learned from Adopting Clojure

+1 from Melbourne :) On 4 February 2014 23:22, Colin Yates wrote: > Is there going to be online access during/after the event? I would > greatly value seeing this, but probably not enough to travel from the UK to > Chicago :). > > > On Tuesday, 4 February 2014 12:06:06 UTC, Jay Fields wrote: >

Re: Lessons Learned from Adopting Clojure

On Feb 4, 2014, at 1:06 PM, Jay Fields wrote: Hi Jay, thanks for the report. I only have few doubts about REPL making TDD to shame. I'm not a TDD practitioner, but I would not be so "tranchant" with it. The REPL is great, that's for sure, but IMHO it does not relegate TDD feedback/loop in a

Re: GSoC 2014: org applications now open

Daniel, I'd be happy to help as an administrator, particularly if you can provide some guidance from previous years. I can also help re getting students to conferences. Alex On Monday, February 3, 2014 1:59:24 PM UTC-6, Daniel Solano Gómez wrote: > > Hello, all, > > Apparently, it's already t

Re: Coverage tools in Clojure

On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: > Comments in line. > On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: > > > > > > I don't want to seem rude but I think you've drank a bit too much > > kool-aid. > > > You know the phrase "I don't want to seem rude" doesn'

Re: Coverage tools in Clojure

This has turned into an unconstructive argument and for whatever reason we don't seem to be communicating clearly. Shame as I (and probably most people on here) only want to help. You seem to be reacting quite strongly to my thoughts - not sure why. If I may, I will just make/rephrase two poi

Re: Coverage tools in Clojure

I don't come from 'Java-land'. I'm primarily an Erlang developer, which already is a very similar language to Clojure. Perhaps this is why I'm not gushing about functional programming's panacea? Aaron On Tue, Feb 04, 2014 at 06:12:18AM -0800, Colin Yates wrote: > This has turned into an unconstru

Re: Coverage tools in Clojure

I have no idea why you aren't gushing. I'm not gushing, and haven't gushed about anything technical for years because everything is a trade off and has its own compromises/ceremony. I can see (and highly value) the benefits of Clojure, sure. If you want to write of my point of view as 'gushin

Re: Coverage tools in Clojure

I took issue with you maintaining that Clojure automatically somehow gives you insight into the coverage of your tests. Which it does not. You still maintain this. On Tue, Feb 04, 2014 at 06:28:51AM -0800, Colin Yates wrote: > I have no idea why you aren't gushing. I'm not gushing, and haven't g

Re: Coverage tools in Clojure

I said that coverage tools answer a specific question; 'how much of my code is executed when I do this', where 'this' is typically running a set of tests. People use that answer to infer how 'safe' their system is because they equate test coverage and safety (which is often a flawed inference).

Re: lispy.el - a vi-like Paredit. Some Clojure features added.

OK, I've added a second screencast as both video and gif: https://raw.github.com/abo-abo/lispy/master/doc/screencast-2.ogv https://raw.github.com/abo-abo/lispy/master/doc/screencast-2.gif Oleh On Tuesday, February 4, 2014 7:41:15 AM UTC+1, Benjamin Peter wrote: > > Thanks but it is playing way to

Re: lispy.el - a vi-like Paredit. Some Clojure features added.

This looks excellent! Desperately trying to suppress the whole emacs/vi battle raging inside which has is now rising up again :). On Sunday, 2 February 2014 13:44:12 UTC, Oleh wrote: > > Hi all, > > I've recently added some Clojure support to > https://github.com/abo-abo/lispy. > > A short descr

Re: Lessons Learned from Adopting Clojure

On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote: > thanks for the report. I only have few doubts about REPL making TDD to > shame. > In this blog entry - http://blog.jayfields.com/2014/01/repl-driven-development.html - I demonstrate (very briefly, by design) my workflow. I als

Re: Lessons Learned from Adopting Clojure

Jay - in your demo I can't determine whether the (+ 2 2) expression is evaluated and the results pasted inline or whether you have manually pasted them? I see you are using emacs, can you detail how you have configured emacs? On Tuesday, 4 February 2014 16:33:44 UTC, Jay Fields wrote: > > On Tu

Re: Lessons Learned from Adopting Clojure

On Feb 4, 2014, at 5:33 PM, Jay Fields wrote: > On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote: > thanks for the report. I only have few doubts about REPL making TDD to > shame. > > In this blog entry - > http://blog.jayfields.com/2014/01/repl-driven-development.html - I > d

Re: Lessons Learned from Adopting Clojure

Colin, I'm using emacs-live: http://overtone.github.io/emacs-live/ To evaluate (+ 2 2) and spit the results I'm using C-u C-x C-e It's definitely an evaluation, not a copy paste of the results. Cheers, Jay On Tue, Feb 4, 2014 at 11:43 AM, Colin Yates wrote: > Jay - in your demo I can't determi

Re: Lessons Learned from Adopting Clojure

Discussions around TDD / RDD (REPL-Driven-Development) probably need a separate thread but... On Feb 4, 2014, at 5:17 AM, Mimmo Cosenza wrote: > thanks for the report. I only have few doubts about REPL making TDD to shame. I'm a strong advocate of TDD (well, BDD specifically) and I agree with

Re: Should predicates always have one argument?

Thank you all for your answers, they helped me a lot :) Cheers On Saturday, February 1, 2014 12:10:42 AM UTC+2, Ivan L wrote: > > I typically wrap stuff with (partial) for easier reading. In your example > you might use something like following. > > (defn are-valid > [maps validator] > (let

Re: Lessons Learned from Adopting Clojure

On Feb 4, 2014, at 6:13 PM, Sean Corfield wrote: > >> The REPL is great, that's for sure, but IMHO it does not relegate TDD >> feedback/loop in a niche, because you can complement one with the other. > > Indeed you can - and Jay does - and so do I. And me too. So we are all in the same boat

Re: Why do I get stackoverflow error?

Another option is: ((fn pascal ([n] (pascal n [1M])) ([n row] (if (= n 1) row (recur (dec n) (mapv (partial reduce +) (partition 2 1 (cons 0 (conj row 0 500) Because row is a vector you can conj 0 to the end (quickly) and cons 0 to the front (quickly) and then mapv makes sure you get a

Re: Coverage tools in Clojure

On Tue, Feb 04, 2014 at 07:01:31AM -0800, Colin Yates wrote: > I said that coverage tools answer a specific question; 'how much of my code > is executed when I do this', where 'this' is typically running a set of > tests. People use that answer to infer how 'safe' their system is because > they

Live coding with Clojure and Emacs

A blog post meant to demonstrate the symbiosis between powerful interactive programming environments such as Clojure and Emacs. http://danielsz.github.io/2014/01/20/Live-coding-with-Clojure-and-Emacs/ -- You received this message because you are subscribed to the Google Groups "Clojure" group.

jvm.tools.analyzer 0.6.1

Hi, jvm.tools.analyzer 0.6.1 now supports ClojureScript 0.0-2138. [org.clojure/jvm.tools.analyzer "0.6.1"] README CHANGELOG Thanks, Ambrose -- You rece

Re: Lessons Learned from Adopting Clojure

Without starting a flame war - how are you finding LightTable for production? Moving away from emacs and paredit would be quite hard and every time I look at LightTable I get really excited until I actually download and try it... That is almost certainly because I don't have the time to inves

Re: Lessons Learned from Adopting Clojure

Colin Yates writes: AFAIK LightTable has paredit or sth. similar. Also, a great deal of customisation is available via ClojureScript. I am personally favouring Emacs as I am a polyglot programmer and do not only use Emacs as an editor, but the programming and computing environment: This post is

Re: Why does Clojure at times use Java classes as their base type?

On Sunday, February 2, 2014 3:07:27 PM UTC-8, Aaron France wrote: > > What's the benefit of hiding/abstracting the underlying platform away? > > The obvious answer to this is it limits exposure to the complexity of the underlying platform, and provides a stable platform. That's usually why peo

how does source work?

Hi, user> (source source) (defmacro source "Prints the source code for the given symbol, if it can find it. This requires that the symbol resolve to a Var defined in a namespace for which the .clj is in the classpath. Example: (source filter)" [n] `(println (or (source-fn '~n) (str "S

How to transform one data structure to another data structure?

Hi all, I was wondering how I can convert the following data structure to the one below: from: [[:a 123] [:b 124] [:a 125] [:c 126] [:b 127] [:a 100]] to {:a [123 125 100] :b [124 127] :c [126]} All the names here are arbitrary, but there are potentially a lot more keys and certainly a

Re: how does source work?

source-fn is a private Var in the clojure.repl namespace; you can still use source to display its definition, but you'll have to use the fully qualified name: user=> (source clojure.repl/source-fn) (defn source-fn "Returns a string of the source code for the given symbol, if it can find it. T

Re: How to transform one data structure to another data structure?

One way: user> (reduce (fn [s [k v]] (merge-with concat s {k [v]})) {} [[:a 123] [:b 124] [:a 125] [:c 126] [:b 127] [:a 100]]) => {:c [126], :b (124 127), :a (123 125 100)} O

Re: How to transform one data structure to another data structure?

You can start here http://clojuredocs.org/clojure_core/clojure.core/group-by it should be pretty easy to get it working from there. On Tuesday, February 4, 2014 4:06:14 PM UTC-5, Thomas wrote: > > Hi all, > > I was wondering how I can convert the following data structure to the one > below: > >

LightTable (for the Emacs guy) was: Lessons Learned from Adopting Clojure

On Feb 4, 2014, at 10:21 AM, Colin Yates wrote: > Without starting a flame war - how are you finding LightTable for production? > Moving away from emacs and paredit would be quite hard and every time I look > at LightTable I get really excited until I actually download and try it... > That is

Re: LightTable (for the Emacs guy) was: Lessons Learned from Adopting Clojure

On Tue, Feb 4, 2014 at 5:20 PM, Sean Corfield wrote: > On Feb 4, 2014, at 10:21 AM, Colin Yates wrote: > > Without starting a flame war - how are you finding LightTable for > production? Moving away from emacs and paredit would be quite hard and > every time I look at LightTable I get really ex

[ANN] hiccup-watch

*hiccup-watch * is just a leiningen watcher plugin that monitors for changes in your Hiccup source files. While building some web apps, I found that I like to treat my *hiccup.edn*forms as separate files. So this is akin to something like guard-haml

Re: GSoC 2014: org applications now open

Thanks, Alex and Ambrose, I really appreciate the help. On Tue Feb 4 05:41 2014, Alex Miller wrote: > Daniel, I'd be happy to help as an administrator, particularly if you can > provide some guidance from previous years. I can also help re getting > students to conferences. This would be a bi

Re: how does source work?

Issue resolved. Thanks! On Tue, Feb 4, 2014 at 1:09 PM, Michał Marczyk wrote: > source-fn is a private Var in the clojure.repl namespace; you can > still use source to display its definition, but you'll have to use the > fully qualified name: > > user=> (source clojure.repl/source-fn) > (defn sou

Re: Coverage tools in Clojure

On Feb 4, 2014, at 11:20 AM, Aaron France wrote: >> If you thoroughly test all your code when you write it why do you need a >> tool to tell you you missed something? > > This is just so brain-dead stupid. > > How do you *know* that you thoroughly tested your code? Where do you > get these me

[ANN] garden-watch

*garden-watch* is very similar to hiccup-watch (previous ann). But this time, we're compiling down to CSS, using the Garden

Re: Lessons Learned from Adopting Clojure

On Feb 4, 2014, at 6:06 AM, Jay Fields wrote: > - REPL driven development, putting TDD's 'rapid feedback' to shame. Pity I'll miss this, but I only come up to Chicago W-F. What I've found is that having autotest in the REPL dissolves most conflict between TDD and REPL-driven development. Or

Code re-use in Speclj

"context" might be what you're looking for. -- You 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 unsu

Code re-use in Speclj

You can also use let instead of with. If you have multiple tests inside let wrap them in a context call. -- You 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 a

ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects

Looks cool. I'll be sure to check it 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 unsubs

Re: Coverage tools in Clojure

This is a very specific "coverage" tool which I think lots of Clojure libraries could benefit from. https://github.com/ztellman/collection-check -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups

Re: Lessons Learned from Adopting Clojure

On Tue, Feb 4, 2014 at 6:07 PM, Brian Marick wrote: > I always grate at the need to then "immortalize" the core of what I did in > the REPL in repeatable tests. That's actually one of the things that bothered me in the Emacs REPL world: working in the REPL was separate from working in my product

Re: [ANN] garden-watch

FYI, I think lein garden does this already. is there a particular difference? On Wednesday, 5 February 2014 13:03:55 UTC+11, frye wrote: > > *garden-watch* is very similar > to hiccup-watch (previous > ann

Re: ANN: Reagent 0.3.0 - now with async rendering

Cheers, Dan! I'm doing experiments with both Reagent and Om at the moment, and I'm very excited about this way of rendering changes to a webpage. I particularly enjoy how easy it is to work with Reagent's API, and appreciate the time you are putting into this project. One of the major wins i

Caribou: Unable to create a model that has a self reference!

Hey! i hope this is the right place to ask this question! Here it goes: I want to create a simple model with cariou that references itself to generate a tree-structure. Like this: (defn category [] (model/create :model {:name "category" :fields [{:name "Label" :type

Re: Caribou: Unable to create a model that has a self reference!

... one step closer: (defn category [] ((model/create :model {:name "category" :fields [{:name "Label" :type "string"} {:name "keywords" :type "string"} {:name "parent-id" :type "integer"}]}) (db/add-refe

Re: Caribou: Unable to create a model that has a self reference!

Well, source-code is the best documentation: (defn category [] ((model/create :model {:name "category" :fields [{:name "Label" :type "string"}]}) (let [category-model-id (model/models :category :id)] (model/update :model category-model-id {:name "category"

Re: ANN: Reagent 0.3.0 - now with async rendering

Gotta ask, what's the difference between Om and Reagent? -- You 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

Re: ANN: Another binary parser combinator - this time for java's streams

Thanks, header seems very useful and relevant to what I was doing, but I ended up doing something slightly different because I needed to include the information retrieved using the chunk header codec in the final result (specifically, the type of the chunk). Here is some code: https://gist.gith

Re: Why do I get stackoverflow error?

Ok thanks, thats really helpful. The second link suggests using doall, which seems to do the trick : ((fn pascal ([n] (pascal n [1M])) ([n row] (if (= n 1) row (recur (dec n) (map (partial reduce +) (doall (partition 2 1 (concat [0] row [0] 500) However you do lose the laziness, but he

Re: Why do I get stackoverflow error?

Similarly this works for my non-recursive effort, which I think is more concise : (fn [n] (nth (iterate (fn [r] (map (partial reduce +) (doall (partition 2 1 (concat [0N] r [0]) [1]) (dec n))) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To

Re: How to organize clojure functions? A clojure newbie here...

I think the "right" (or maybe idiomatic is a better word) organisation is an effect of a very important cause - changing the way you think about a software system. Simplistically, OO promises to be a world full of chunks of knowledge and behaviour that politely ask other chunks to behave in a

Re: Coverage tools in Clojure

I don't know. But maybe the lack of coverage tools is itself interesting? My (not quite formed/making this up as I go) view is that maybe coverage tools are there to address the implicit complexity in other mainstream languages and/or to help mitigate the risk of the potentially large and hard

Re: Coverage tools in Clojure

I don't want to seem rude but I think you've drank a bit too much kool-aid. To say that functional programming and war against state means that your application doesn't need to be tested thoroughly is a joke. And a very bad one. Coverage doesn't just aid you in seeing which parts of state caused

Re: [ClojureScript] ANN: Reagent 0.3.0 - now with async rendering

Thanks, I enjoy writing it! ClojureScript is such a delight to use (except, of course, when Closure's advanced compilation bites you where it hurts). :) /dan On 4 feb 2014, at 09:09, Henrik Eneroth wrote: > Cheers, Dan! > > > I'm doing experiments with both Reagent and Om at the moment, and

Lessons Learned from Adopting Clojure

tl; dr: I'm presenting "Lessons Learned from Adopting Clojure" in Chicago on Feb 11th: http://www.eventbrite.com/e/goto-night-with-jay-fields-tickets-10366768283?aff=eorgf Five years ago DRW Trading was primarily a Java shop, and I was primarily developing in Ruby. Needless to say, it wasn't a mat