Re: Project fails to compile on different machines
The makefile is not ran in parallel -- the Makefile is being explicit for non-Clojure users. Read above -- the issue is solved, there's an issue with the profiles and AOT. On Wed, 11 Mar 2015 at 16:21 Tassilo Horn t...@gnu.org wrote: Aaron France aaron.l.fra...@gmail.com writes: Hi Aaron, The makefile calls compile then uberjar, which is why things are compiled twice, so it seems my problem lies *just* with uberjar. So why do you compile and then let uberjar compile again? And there's also no need to call the deps target explicitly. Leiningen does that automatically. (Or all in all, I don't see any reason why you use a Makefile at all.) Any idea why compile would succeed but then uberjar would fail? A shot in the blue: GNU make builds receipes in parallel if they don't depend on each other and MAKEFLAGS contains the -jN flag where N denotes the max number of parallel makes. Your receipes don't depend on each other thus could be executed in parallel. But then there's a chance that two compilations (one from lein compile, one from lein uberjar) run in parallel and overwrite each other's files, or a file gets loaded which is currently being written to. So my guess is, on system 1 MAKEFLAGS is -j1 or unset, on system 2 MAKEFLAGS contains at least -j2. 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/d/optout.
Re: Project fails to compile on different machines
Hi, The relevant parts of the Makefile are here: https://gist.github.com/AeroNotix/f65a846781357db59ced On Wednesday, 11 March 2015 14:01:20 UTC+1, Tassilo Horn wrote: Aaron France aaron.l...@gmail.com javascript: writes: Here is output compiling on the different machines: https://gist.github.com/AeroNotix/70a2d10bbb050aa0542a What does your Makefile look like? Does it just call lein uberjar or what? I think it's strange that even on the machine where it builds successfully every namespace seems to get compiled twice. 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/d/optout.
Re: Project fails to compile on different machines
The makefile calls compile then uberjar, which is why things are compiled twice, so it seems my problem lies *just* with uberjar. Any idea why compile would succeed but then uberjar would fail? On Wednesday, 11 March 2015 14:22:17 UTC+1, Aaron France wrote: Hi, The relevant parts of the Makefile are here: https://gist.github.com/AeroNotix/f65a846781357db59ced On Wednesday, 11 March 2015 14:01:20 UTC+1, Tassilo Horn wrote: Aaron France aaron.l...@gmail.com writes: Here is output compiling on the different machines: https://gist.github.com/AeroNotix/70a2d10bbb050aa0542a What does your Makefile look like? Does it just call lein uberjar or what? I think it's strange that even on the machine where it builds successfully every namespace seems to get compiled twice. 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/d/optout.
Project fails to compile on different machines
Hi, I have a project (unfortunately private) that uses a lot of java interop to provide Java with a seemless java-like API. On one of my development machines I can compile the project fine, but the other not. Both are set up (what I think) in the same relevant ways. Here is output compiling on the different machines: https://gist.github.com/AeroNotix/70a2d10bbb050aa0542a The lein version is 2.5.0 on both machines (I'm using the lein.sh script) Aaron -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Project fails to compile on different machines
prred correctly? I've cleaned the maven cache on both machines completely. On Wed, 11 Mar 2015 at 00:26 Ivan L ivan.laza...@gmail.com wrote: seems like a clear classnotfound error to me. make sure both environments are building from a clean state (no build caches) and that your classes are being prred correctly. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/ topic/clojure/UtnchSngQAY/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] cqrs-server - An opinionated CQRS/ES implementation using Onyx, Datomic, DynamoDB, Kafka and Zookeeper.
Hi, What are your opinions on Onyx? What are your opinions on Onyx compared to Storm? What are your opinions on Onyx deployment? Aaron On Thursday, 12 February 2015 10:15:44 UTC+1, Deon Moolman wrote: Hi everyone, I spent some time putting together an implementation of the CQRS pattern in Clojure and wrote an article on it: http://yuppiechef.github.io/cqrs-server/ It mostly boils down to an Onyx ( http://www.github.com/MichaelDrogalis/onyx) configuration, but it's been an interesting journey that I felt is worthwhile sharing. Feedback really appreciated! Cheers, - Deon -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Possible additions to tools.trace
Hi all, I've proposed some changed to tools.trace and created an initial implementation (linked in the JIRA ticket). http://dev.clojure.org/jira/browse/TTRACE-10 Thanks, Aaron -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Possible additions to tools.trace
Hi, Roger! Aaron On Tuesday, 3 February 2015 16:25:23 UTC+1, Luc wrote: Hi, Got your ticket notification, it's a busy week, beeing on the road most of it. I will look at it by next Sunday after crossing the Atlantic :) Luc P. Hi all, I've proposed some changed to tools.trace and created an initial implementation (linked in the JIRA ticket). http://dev.clojure.org/jira/browse/TTRACE-10 Thanks, Aaron -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Luc Prefontainelprefo...@softaddicts.ca javascript: sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [jobs] for newbie in europe
Hi, We're primarily an Erlang shop but we have small applications in Clojure. Would you like to have a chat with my manager about positions available here? On Mon, Jul 21, 2014 at 10:13 AM, Krzysztof Władyka krzysz...@wladyka.eu wrote: I live in Poznań (Poland). On Sunday, July 20, 2014 5:35:19 PM UTC+2, Aaron France wrote: Where are you based? On Sun, Jul 20, 2014 at 4:29 PM, Krzysztof Władyka krzy...@wladyka.eu wrote: Hello, I am living in Poland and i have a little problem there... totally 0 jobs for Clojure Programmers. I am also beginner in Clojure. More about my IT skills you can read on site http://wladyka.eu/ . Do you know any option to get a job in Europe or remotely if i don't have any seriously experience with Clojure? But i see it's good and i want use that more then others languages. I can start with less salary but in my area is big trouble to find any job with Clojure... If you know somebody who need fresh blood tell him about me :) Best regards, Krzysztof Władyka -- 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/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [jobs] for newbie in europe
Where are you based? On Sun, Jul 20, 2014 at 4:29 PM, Krzysztof Władyka krzysz...@wladyka.eu wrote: Hello, I am living in Poland and i have a little problem there... totally 0 jobs for Clojure Programmers. I am also beginner in Clojure. More about my IT skills you can read on site http://wladyka.eu/ . Do you know any option to get a job in Europe or remotely if i don't have any seriously experience with Clojure? But i see it's good and i want use that more then others languages. I can start with less salary but in my area is big trouble to find any job with Clojure... If you know somebody who need fresh blood tell him about me :) Best regards, Krzysztof Władyka -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure on iOS devices - Swift as a host?
@Timothy, you mention speed a lot, but I'm not sure where in the OP it mentioned wanting to do this for speed at all. I think the intention is to be able to Clojure on a different platform, is all. On Wed, Jun 4, 2014 at 4:58 PM, Mike Fikes mikefi...@me.com wrote: I have been experimenting writing an iOS app using ClojureScript embedded in JavaScriptCore, where the ClojureScript essentially implements the logic of my view controllers which drive native UI. So far, this approach seems like a reasonable one to “writing iOS apps using Clojure.” You essentially trade off direct tooling support and gain the ease of developing using ClojureScript (this is important to me, as my server is in Clojure and I can effectively master one language.) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why can I not parse the command line arguments in this way
One hates to be rude but: I've read all your questions over the past couple of weeks and it seems it would behoove you to pick up a book. There are plenty of recommendations on Google and archived threads. Good day. On 22 Apr 2014 16:48, Cecil Westerhof cldwester...@gmail.com wrote: Obvious not very neat, but I tried as a first hack to do something with the command line parameters with: (doseq [type args] This does not work. Why not? -- Cecil Westerhof -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Kibit output
`lein kibit file` On Wed, Mar 19, 2014 at 03:26:17AM -0700, Tim Terry wrote: Hi, is it possible to output kibit code analysis results into a file? My aim is to publish this file with a CI tool such as teamcity/ jenkins. Thanks, Tim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. pgpBPqIQhzpQS.pgp Description: PGP signature
Lapse - a JSON property test generator
Hi, https://github.com/AeroNotix/lapse I've started work on a little project which intends to generate property tests (using core.test.check) from JSON schemas. The idea is that you supply it a schema and it would output a generator for that schema. This is a very, very young project but I'm using it in a professional setting so I should hope it will continue to grow. The README hopefully has everything you would need to start on this application. Thanks, Aaron pgpZhJMjfgmoR.pgp Description: PGP signature
Re: Is there a function to determine if code is run as script or library ?
Hi, You can implement https://github.com/clojure-cookbook/my-daemon for your application. I've had great success with this. Aaron On Wed, Feb 26, 2014 at 01:50:43AM -0800, macdevign mac wrote: Hi, is there a function to determine if the clojure code is running as library or as script ? In ruby, there is if __FILE__==$0 # this will only run if the script was the main, not load'd or require'd end In Java, we could include main method in class, and choose to run it, How about clojure ? Is there any function/macro like the following ? (run-main (code ..)) so that it can be run standalone, or it can be ignored running as library. I find this useful for quick experimenting. thank -- 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. pgppAIwuaJSxV.pgp Description: PGP signature
Re: How would I write it with concurrency
Hi, Ignoring your question for a second to recommend using simple-check[0] to generate test data. [0] https://github.com/reiddraper/simple-check Aaron On Mon, Feb 10, 2014 at 08:46:59PM +0200, Haim Ashkenazi wrote: Hi I have a simple code that generates a list of maps: (defn test-data [nsamples] (loop [acc []] (if (= (count acc) nsamples) acc (recur (concat acc (session)) The session function returns a list of one to five generated maps. The idea is to get a list of (not much more then) nsamples generated maps. This code runs fairly fast for my needs but out of curiosity I was wondering how would I make it run concurrently? Thanks in advance -- Haim -- 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. pgpy2bxIJLopx.pgp Description: PGP signature
Using Apache Daemon with Clojure
Hi, I'm following the Clojure Cookbook blogpost[1] in order to Daemonize a clojure application. Yet the provided code[2] does not work on my system. When running the incantation to get JSVC to run, firstly I needed to change it to use the full path to the JSVC binary. This is fine. However, when it tries to run, it complains with: Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader Yet I am following their instructions *to the letter*. Any ideas guys/gals? Aaron [1] http://www.rkn.io/2014/02/06/clojure-cookbook-daemons/ [2] https://github.com/clojure-cookbook/my-daemon pgp20d1id1jmr.pgp Description: PGP signature
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 which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. Aaron On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: 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-to-identify 'impact analysis' you get in OO systems when you change state. In other words, coverage is necessary because we want to feel safe that all combinations of our code are extensively tested. Why don't we feel safe? Because the system is hard to reason about. Functional programming on the other hand is full of much smaller discrete and independent chunks of functionality. Ideally these small focused 'bricks' are pure/referentially transparent so the *only* context you need when reasoning about them is their parameters and the logic inside. Assembling these bricks introduces interactions that need to be tested, sure, but there are very few 'call this and watch the change cascade'/'this code is sensitive (i.e. coupled) to that data over there'. My ramblings are to say, maybe the root cause of coverage tools is to solve a problem (hard to reason about systems) which shouldn't be much less of a problem in FP when FP is done right. OO + mutable state = hard to reason about. FP + immutable state + pure/referentially transparent functions = much easier to reason about. Or not. Just my 2 pence :). On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote: Hi, I'm looking for coverage reporting in Clojure. I've been using Cloverage[1] but I'm just wondering if there are any other coverage tools? Aaron [1] https://github.com/lshift/cloverage -- 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. pgpVKilgv_syW.pgp Description: PGP signature
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't actually do anything right? :) I genuinely don't want to offend. People allow themselves to become vested in their viewpoint. If that has happened to you, I'm sorry. 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. I agree, but who is saying that? I certainly didn't cover how much testing is necessary. I thoroughly test my Clojure systems using midje, which regularly rocks my world. My point is that the coverage is much *much* easier to reason about in FP than in OO (for the reasons I gave). I'm not following how you translate this into information which explains how your system is being tested. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. And why are those logical errors which cause the branches to not be hit not immediately obvious? Why do you need a tool to tell you that? I know my Clojure code has around 100% coverage using white box testing for the functions and mocking the interactions. And what's the harm in getting this information from an automated tool? With your 20 years industry knowledge you should know that you cannot rely on humans to think and act reliably. It's just not a good way to plan systems. *Especially* when it comes to asking someone how correct their system is. I would challenge you to put ego/emotion to one side, stop finding non-existent points to argue against and re-read my post. By all means come back and justify why all the points I raised which reduce the need for coverage are invalid. Don't attribute stupid statements (like 'FP doesn't need testing') to me - I can come up with my own stupid statements thank you. You hand waved the need to use tools such as coverage reports simply on the virtue of some hard to quantify statements. I find that unscientific. If it helps, my stand point is from 20 years of building non-trivial Enterprise applications (primarily Java) using the current best of breed technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed process (agile, TDD, DBC, BDD, most otherTLAs etc.). Arguments from authority mean nothing on the internet. Using Clojure for the past year or so has opened my eyes to exactly how many problems we solve, and infrastructure we use is to pamper to complexity introduced by the tool-chain not the problem domain. I am suggesting maybe coverage tools are one of those. Coverage helps nothing on its own. It's a tool to aid in knowing which aspects of your system remain untested. It's fine to *believe* you're testing 100% of your system, but how do you actually know this? If you wander into a codebase you're not familiar with, what's the coverage? How do you know you're hitting all codepaths? You just cannot know this without reading all the code and the tests. Coverage helps to discover this information. My point isn't to eschew all other forms of testing in favour of coverage reports but to use them in tandem with the others to aid me in *knowing* which parts of the system are being tested and which are not. Aaron Aaron On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: 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-to-identify 'impact analysis' you get in OO systems when you change state. In other words, coverage is necessary because we want to feel safe that all combinations of our code are extensively tested. Why don't we feel safe? Because the system is hard to reason about. Functional programming on the other hand is full of much smaller discrete and independent chunks of functionality. Ideally these small focused 'bricks' are pure/referentially transparent so the *only* context you need when reasoning about them is their parameters and the logic inside. Assembling these bricks introduces interactions that need to be tested, sure, but there are very few 'call this and watch the change cascade'/'this code is sensitive (i.e. coupled) to that data over there'. My ramblings are to say, maybe the root cause of coverage tools is to solve a problem (hard to reason about systems) which shouldn't be much less
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 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 points: - I think you would find value in watching Rick Hickey's videos on Simple Made Easy and also the one where he talks about Hammock Driven Development. - when I started using Clojure I immediately looked for equivalents of all the supporting infrastructure I used in good old Java land. I have no idea of your situation, but if you are there you have a wonderful opportunity to re-examine and build up a whole new toolchain/approach to development that IME is significantly lighter and more powerful. Peace. On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote: 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't actually do anything right? :) I genuinely don't want to offend. People allow themselves to become vested in their viewpoint. If that has happened to you, I'm sorry. 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. I agree, but who is saying that? I certainly didn't cover how much testing is necessary. I thoroughly test my Clojure systems using midje, which regularly rocks my world. My point is that the coverage is much *much* easier to reason about in FP than in OO (for the reasons I gave). I'm not following how you translate this into information which explains how your system is being tested. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. And why are those logical errors which cause the branches to not be hit not immediately obvious? Why do you need a tool to tell you that? I know my Clojure code has around 100% coverage using white box testing for the functions and mocking the interactions. And what's the harm in getting this information from an automated tool? With your 20 years industry knowledge you should know that you cannot rely on humans to think and act reliably. It's just not a good way to plan systems. *Especially* when it comes to asking someone how correct their system is. I would challenge you to put ego/emotion to one side, stop finding non-existent points to argue against and re-read my post. By all means come back and justify why all the points I raised which reduce the need for coverage are invalid. Don't attribute stupid statements (like 'FP doesn't need testing') to me - I can come up with my own stupid statements thank you. You hand waved the need to use tools such as coverage reports simply on the virtue of some hard to quantify statements. I find that unscientific. If it helps, my stand point is from 20 years of building non-trivial Enterprise applications (primarily Java) using the current best of breed technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed process (agile, TDD, DBC, BDD, most otherTLAs etc.). Arguments from authority mean nothing on the internet. Using Clojure for the past year or so has opened my eyes to exactly how many problems we solve, and infrastructure we use is to pamper to complexity introduced by the tool-chain not the problem domain. I am suggesting maybe coverage tools are one of those. Coverage helps nothing on its own. It's a tool to aid in knowing which aspects of your system remain untested. It's fine to *believe* you're testing 100% of your system, but how do you actually know this? If you wander into a codebase you're not familiar with, what's the coverage? How do you know you're hitting all codepaths? You just cannot know this without reading all the code and the tests. Coverage helps to discover this information. My point isn't to eschew all other forms of testing in favour of coverage reports but to use them in tandem with the others to aid me in *knowing* which parts of the system are being tested and which are not. Aaron Aaron
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 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 'gushing' and not bother to read it correctly then fine. However, what is your objective in posting your statement to a public forum if not to start an argument? If you insist on sending more flame bait/trying to get a rise then let's take this offline and keep this list low noise. My email address is colin full stop yates @ Google's mailing servers.com. On Tuesday, 4 February 2014 14:17:25 UTC, Aaron France wrote: 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 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 points: - I think you would find value in watching Rick Hickey's videos on Simple Made Easy and also the one where he talks about Hammock Driven Development. - when I started using Clojure I immediately looked for equivalents of all the supporting infrastructure I used in good old Java land. I have no idea of your situation, but if you are there you have a wonderful opportunity to re-examine and build up a whole new toolchain/approach to development that IME is significantly lighter and more powerful. Peace. On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote: 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't actually do anything right? :) I genuinely don't want to offend. People allow themselves to become vested in their viewpoint. If that has happened to you, I'm sorry. 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. I agree, but who is saying that? I certainly didn't cover how much testing is necessary. I thoroughly test my Clojure systems using midje, which regularly rocks my world. My point is that the coverage is much *much* easier to reason about in FP than in OO (for the reasons I gave). I'm not following how you translate this into information which explains how your system is being tested. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. And why are those logical errors which cause the branches to not be hit not immediately obvious? Why do you need a tool to tell you that? I know my Clojure code has around 100% coverage using white box testing for the functions and mocking the interactions. And what's the harm in getting this information from an automated tool? With your 20 years industry knowledge you should know that you cannot rely on humans to think and act reliably. It's just not a good way to plan systems. *Especially* when it comes to asking someone how correct their system is. I would challenge you to put ego/emotion to one side, stop finding non-existent points to argue against and re-read my post. By all means come back and justify why all the points I raised which reduce the need for coverage are invalid. Don't attribute stupid statements (like 'FP doesn't need testing') to me - I can come up with my own stupid statements thank you. You hand waved the need to use tools such as coverage reports simply on the virtue of some hard to quantify statements. I find that unscientific. If it helps, my stand point is from 20 years of building non-trivial Enterprise applications (primarily Java
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 equate test coverage and safety (which is often a flawed inference). I certainly don't connotate high coverage with a safe system. No-one said that. I use coverage to answer two questions: * Which lines of code are being hit during testing? * Which lines of code are not being hit during testing? You'll be surprised at how many times I've discovered dead code, needless checks, error handling etc just simply looking at what code was used when. A functional programming language allows you to write code which isn't used. In some environments there is so much incidental complexity that these metrics are hard to calculate by hand (mutating state, deep object hierarchies etc.). FP has a number of different design decisions which can significantly reduce that incidental complexity, so if a tool is still needed maybe the cause is somewhere else - too much coupling/not enough ignorance etc. I think we fundamentally come from different places as I do think you can trust people and I would choose a couple of decent engineers (although they are as rare as hen's teeth) without any tools over all the tools in the world. You present a false dichotomy here. You can have both. Good engineers aren't afraid to use tools where they make sense. To be clear, I am not saying I don't see the need for code coverage, I am saying it should be much easier to keep track of code coverage in an FP system done well primarily due to the wonderfully low level of influence referential transparency gives you (for example). On the other hand I absolutely see the need for an automated tool in other environments because of the implicit complexity. You used the words should be, therefore I will assume you haven't conducted any scientific studies to show these facts. May we ignore this point? These kinds of things are hard to quantify. 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 metrics? There are various methods you need to employ before you can even beging to feel comfortable about saying you have 'thoroughly' tested code. Coverage is one method amongst many. Again, note I am talking only about calculating test coverage and not about testing or how much there should be. Not sure how many ways I can say the same thing, but let's try one more; I never said it was Clojure automatically doing anything, I said it is possible for a good engineer to know the coverage and safety of their systems themselves in a well designed and implemented system. Some environments are full of complexity which make it heard, hence the need for a tool. I am not categorically saying I can't imagine a world where I would need said tool in a FP system, but my first question would be am I using a tool to solve a symptom of poor design. You ask me to disprove things like this? Are you kidding? This is just hand-wavey and pulled out of the air. To say a good engineer can calculate complexity themselves is just asking for trouble. The less you rely on human behaviour the closer you get to doing science. In terms of analysing a new system? When I was a consultant reviewing other's work the best tool I used was a whiteboard, a pen and their architect. And what happens to this data? Did you store it? Did you write it down? Could you pass that data onto other people easily? It seems that institutional knowledge such as this is a bigger cause for concern than simply using coverage tools. I found that if their system *needed* a coverage tool the tests were probably so poorly written as to add very little value. At this point I'm beginning to suspect you've never really used a coverage tool properly. Coverage is used in conjunction with other methods to gain knowledge about your system, if you rely on coverage alone (and don't act on the results so long that you *continually* need it) then you have bigger problems than poor tests. I would genuinely like you/others to prove/disprove these points as this is an area I am still thinking/learning about (as evidenced by my first and last sentence in the original post) and would love to have a useful discussion. You haven't bought anything to the table other than little jibes and emotive statements unfortunately. Let's agree to disagree, and if you can resist having a dig on a public forum (feel free to continue over personal email) let's draw this to a close. On Tuesday, 4 February 2014 14:30:29 UTC, Aaron France wrote: I took issue with you
Coverage tools in Clojure
Hi, I'm looking for coverage reporting in Clojure. I've been using Cloverage[1] but I'm just wondering if there are any other coverage tools? Aaron [1] https://github.com/lshift/cloverage pgpMaXQ__7lWz.pgp Description: PGP signature
Re: Why does Clojure at times use Java classes as their base type?
Hi, What's the benefit of hiding/abstracting the underlying platform away? There are reams of documentation about the Java classes and simply renaming them to say they are Clojure classes would seem to reduce the discoverability of those docs. JMTC Aaron On Sun, Feb 02, 2014 at 02:50:01PM -0800, Mark Gandolfo wrote: I tried asking this on twitter and wasn't getting my question across in 140 characters so I decided to post here. I'm curious as to why Clojure as a language hasn't abstracted/hidden all of Java's classes and created their own in the Clojure. namespace. For example Big Ints are of type and class Clojure.lang.BigInt. user= (type 1N) clojure.lang.BigInt user= (class 1N) clojure.lang.BigInt Although a Long is a java.lang.Long both in type and class user= (class 1) java.lang.Long user= (type 1) java.lang.Long Similarly a character is of type java.long.Character user= (type \a) java.lang.Character user= (class \a) java.lang.Character Again with Java strings user= (class string) java.lang.String user= (type string) java.lang.String Although a Strings have a few functions in the clojure.strings namespace which can be accessed. Why wouldn't clojure.lang.string be the type? And somehow inherit/remap all of the java string functions? Was this design decision made during the languages conception to clean up the clojure namespaces? Or is there another reason that I'm not seeing? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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. pgpSXTVybmKJF.pgp Description: PGP signature
Re: [ANN] clj-refactor.el 0.10.0
Wow! This looks really cool.
+1
On Thu, Jan 30, 2014 at 05:13:36AM -0800, Magnar Sveen wrote:
clj-refactor.el
Since the last update, there's been lots of activity for
clj-refactor.elhttps://github.com/magnars/clj-refactor.el
. Alex Baranosky https://github.com/AlexBaranosky and Lars
Andersenhttps://github.com/expez have
joined the team, and here are the new features:
More let refactorings
Starting with:
(defn handle-request
(let [body (find-body abc)]
{:status 200
:body body}))
With the cursor in front of 200, I do cljr-move-to-let:
(defn handle-request
(let [body (find-body abc)
X 200]
{:status X
:body body}))
Again I have two cursors where the Xes are, so I type out the name, and
press enter:
(defn handle-request
(let [body (find-body abc)
status 200]
{:status status
:body body}))
Pretty handy. And it works with if-let and when-let too.
*Thread first all, thread last all, unwind all*
Convenience functions to thread all the way down, or unwind the entire
threading macro.
Cycling Privacy
Given this function:
(defn add [a b]
(+ a b))
I do cljr-cycle-privacy:
(defn- add [a b]
(+ a b))
I do cljr-cycle-privacy again to return to the original:
(defn add [a b]
(+ a b))
Given this def:
(def config
docs
{:env staging})
I do cljr-cycle-privacy:
(def ^:private config
docs
{:env staging})
I do cljr-cycle-privacy again to return to the original:
(def config
docs
{:env staging})
https://github.com/magnars/clj-refactor.el#cycling-collection-typeCycling
Collection Type
Given this collection:
(:a 1 :b 2)
I do cljr-cycle-coll to return:
{:a 1 :b 2}
... and then 3 more times:
[:a 1 :b 2]#{:a 1 :b 2}(:a 1 :b 2)
https://github.com/magnars/clj-refactor.el#cycling-between-strings-and-keywordsCycling
Between Strings and Keywords
Given this string:
refactor
I do cljr-cycle-stringlike to return:
:refactor
... and then 3 more times:
refactor:refactorrefactor
Thanks to Jay Fields https://github.com/jaycfields and
emacs-livehttps://github.com/overtone/emacs-live for
these cycling features. Good idea!
Destructuring keys
Given this:
(defn- render-recommendation [rec]
(list [:h3 (:title rec)]
[:p (:by rec)]
[:p (:blurb rec)
(render-link (:link rec))]))
I place the cursor on rec inside [rec] and do cljr-destructure-keys:
(defn- render-recommendation [{:keys [title by blurb link]}]
(list [:h3 title]
[:p by]
[:p blurb
(render-link link)]))
If rec had still been in use, it would have added an :as clause.
For now this feature is limited to top-level symbols in a let form. PR
welcome.
https://github.com/magnars/clj-refactor.el#stop-referringStop referring
Given this:
(ns cljr.core
(:require [my.lib :as lib :refer [a b]]))
(+ (a 1) (b 2))
I place cursor on my.lib and do cljr-stop-referring:
(ns cljr.core
(:require [my.lib :as lib]))
(+ (lib/a 1) (lib/b 2))
https://github.com/magnars/clj-refactor.el#optional-setupEven more
There's also
- cljr-sort-ns to sort the namespace
- cljr-replace-use to replace old :use statements with new :refer :all
statements.
- cljr-add-declaration to declare the defn you're in.
So, clj-refactor.el still knows nothing about your code. At some point we
want to piggyback on an nrepl-connection to do the tricky parts of
refactoring, but for now we're happy to make life a little easier.
Hope you enjoy!
--
--
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.
pgpnEutW8rSxB.pgp
Description: PGP signature
Re: core.async count in a channel
Hi, Whilst I am pretty new to clojure. I am not to Go. The counting of items in a channel is usually regarded as an error and a race condition causing idea. Since channels yield nil when they are devoid of items, surely this is enough to know when the channel is empty? Aaron -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: core.async count in a channel
On 21/01/14 14:09, Moritz Ulrich wrote: On Tue, Jan 21, 2014 at 9:43 AM, Aaron France aaron.l.fra...@gmail.com wrote: Since channels yield nil when they are devoid of items, surely this is enough to know when the channel is empty? That's not correct. Take-Operations block on empty channels. They yield nil when they're closed. You could add a timeout to the take operation to see if no item arrived in a specific time. Much appreciated for the clarification. It's the same in Go. I can imagine this pattern (take on a possibly closed channel being useful) being useful but I'm not convinced knowing the count of channel is a safe thing to know/care about. My $0.02, perhaps Clojure does this differently. -- -- 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.
