Re: heaps in clojure vs SML
Also remember to give the JVM some warm up time, as the JVM depends heavily on JIT style optimizations, and measuring performance without it might not represent real world behavior, -- Ashton On Saturday, January 31, 2015 at 11:39:05 PM UTC-7, Mars0i wrote: You also might want to use Criterium https://github.com/hugoduncan/criterium rather than *time *for accurate benchmarking*.* On Friday, January 30, 2015 at 6:54:52 AM UTC-6, Maris wrote: yes, it helped :-) type hints make non-trivial difference thank you On Friday, 30 January 2015 12:43:40 UTC, Nicola Mometto wrote: If you set! *warn-on-reflection* to true, you'd see a lot of reflection warnings from your code. Type-hinting the code like this: http://sprunge.us/ATiV makes your example execute in 120ms on my machine. Maris writes: I implemented leftist heap (from Purely Functional Data Structures book) in clojure. https://gist.github.com/maruks/135fef92455578b61de2 It takes 32 seconds to insert 10 elements in heap: (time (peek (reduce conj (empty-heap) (range 1000 2000 100) ))) Elapsed time: 32649.71438 msecs 1000 Why is it so much slower than SML NJ? Something wrong with my code? Here is SML version: https://gist.github.com/maruks/c863eac9cf057a071307 And function that inserts 10 elements in *54* milliseconds ! fun test(n:int) : int = let val r = List.tabulate(n, fn x = 1000 + 100 * x) val h = foldl ( fn (e, h) = IntHeap.insert(e , h) ) IntHeap.empty r in IntHeap.findMin(h) end -- -- 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: Architectural doubts
Because of the way that Datomic stores it's data (5 tuples: entity, attribute, value, transaction, and operation) it has some pretty simple indexes that allow for powerful queries. EAVT allows for rapidly searching by entity, VAET allows for quick reverse look ups, etc. The only index that you get to choose on is the AVET index, that allows for searching across an attribute (column level search in the relational world), and that's toggled by the :db/index attribute on the schema. Which index a query uses depends on what you're trying to do with datalog, it's pretty much out of the users hands unless if you start using the raw index API. The current word from the Datomic team is that they highly recommend leaving the index on for all attributes, as it consumes small enough amounts of data in most scenarios. Datomic is also pretty good at keeping only useful indexes in memory, so you should probably be fine. -- Ashton On Sunday, February 1, 2015 at 5:31:37 AM UTC-7, Milton Silva wrote: For now I'm hand coding a big loop with transients and a bytebuffer. It is an incredibly ugly imperative mess but, it is fast enough and so far it fits nicely into ram. It takes 2s (at this point gloss was taking upwards of 5 minutes) to decode 200MB all the way to tcp and uses 500MB of heap. This is faster than wireshark(10s) but a bit more memory hungry. Will see how it responds when decoding diameter, so far that part is stored as byte-arrays. Thank you for the pointers with datomic. Are the indexes created automatically or do I need to specify them on the schema? -- 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: Clojurescript to target JVM?
A lot of the slowness in Clojure comes down to how slow it is to load the main namespaces that are needed, especially clojure.core (see this post http://nicholaskariniemi.github.io/2014/02/25/clojure-bootstrapping.html ). You should also look into the Clojure fastload branch, which apparently helped out a few Android programmers according to the clojure-android google list. On Friday, November 21, 2014 at 2:48:20 PM UTC-7, Alan Moore wrote: On Friday, November 21, 2014 9:50:58 AM UTC-8, Uday Verma wrote: Hello Everyone, Basically the approach is this: cljs - js - rhino [3] - bytecode. Provides java interop through rhino. By the time things get to rhino, google closure has already thrown away most of the runtime away since we didn't use it, and we end up with manageable amount of JS which is compiled to manageable amount of byte code. All of jvm is still available. Sounds like the clojure compiler could benefit from dead code elimination. I'm not sure if that is possible or not but it does sound like it might work. Compiles would probably take longer so the gains might be offset by longer compile times. If this is the case then it wouldn't help development workflows but could provide deployment/runtime gains. I'm wondering if the availability of eval in clojure and the lack of it in clojurescript makes a difference - it might lead to some code that can't be properly analyzed. Alan -- 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: TDD and lein
I've had good luck with lein prism to cut out any annoying lein startup time. Mixed in with cider when I want to run one test works nicely for me. https://github.com/aphyr/prism/ --Ashton Sent from my iPhone On Jan 8, 2015, at 7:32 AM, Malcolm Sparks malc...@juxt.pro wrote: LISP systems work better when they are continually up-and-running. Take Emacs for example. Clojure systems aren't much different. I prefer to think of lein more as a launch tool than a build tool. I don't think anyone has mentioned it on this thread yet, but lots of people are using Stuart Sierra's component workflow for precisely this reason - you can make changes and see the effects very quickly simply by typing (reset) into the REPL. See https://github.com/stuartsierra/component For a working example of incremental compilation, see http://modularity.org/templates/dashboard.html - it will recompile your ClojureScript and Less css files incrementally, and can do so because it can keep context between resets. It's possible to add 'test' components which will run your tests after every reset. I don't have any templates demonstrating that yet, but I have seen people do it. On Thursday, 8 January 2015 14:20:56 UTC, Andrea Crotti wrote: Ah great that's what I wanted, I'll try later. Does it give some feedback on what it's compiling and what is going on? I would use just cider in theory but I had some errors with namespaces (probably my fault) and more importantly it seemed that it didn't always recompiled things that were changed (again probably my fault). So in short only changing dependencies should require a new lein test or lein deps? And this useful plugins do you normally put them in your ./lein/profiles.clj or in every project you have? thanks a lot 2015-01-08 11:41 GMT+00:00 Robin Heggelund Hansen skinn...@gmail.com: The reason lein is initially slow, has to do with Clojures bootstrapping process, which is slow. People tend to avoid starting clojure programs repeatedly, and thus do alot of work from the repl, or using leiningen plugins which keeps running and listens for changes. Take a look at lein-test-refresh for tdd: https://github.com/jakemcc/lein-test-refresh It detects when you change your code, incrementally compiles and re-runs the tests. It runs your tests everytime you save a file :) kl. 12:32:44 UTC+1 torsdag 8. januar 2015 skrev Andrea Crotti følgende: Hi guys, I'm starting to use Clojure a bit more seriously, I knew already Lisp a bit and Haskell, in plus I've been using Emacs for a long time so luckily it's not as hard, and it's a lot of fun. I'm using Emacs + Cider for development and it works wonderfully, however I have a few problems/questions trying to do TDD. 1. Isn't it possible to make Lein more verbose? It's often quite slow and it would be nice to know what is going on, I can stand the slowness but at least tell me something :D 2. When is exactly that I need to run again lein test (which is painfully slow) and when just rerunning the tests from the same REPL suffice? I thought only when changing dependencies, but I had different experiences so I'm not too sure about the rule. And what command exactly is Cider triggering when I run the tests? It would be nice to be able to see somewhere more information like: - compiling file x - running tests for y with command z 3. Does incremental compilation work well/make sense for Clojure? I found something but the fact that it's not done straight away in Leiningen makes me think it's maybe not much used? Thanks a lot, and congratulations to all the developers for the great language! -- 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
Re: is there a shorter way to do this in core.logic ?
I'm no expert, but I think no, at least not in any way you'd want to maintain.
Also, if that's all of your core.logic code, that's pretty damned short and
clear. I can read and understand that right away.
--Ashton
Sent from my iPhone
On Jan 4, 2015, at 2:43 AM, rogergl ro...@gilliar.de wrote:
The following snippet works
(fresh [?row ?col]
(fd/+ row 1 ?row)
(fd/+ col 1 ?col)
(membero {:row ?row :col ?col} data)))] ; check
existence of {:row (?row + 1) :col (?col + 1)}
But I'm not sure if this isn't to verbose.
The question is: Is it really neccessary to bind to row and col or ist there
a shorter way ?
Regards
Roger
--
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: How to handle refactoring with TDD and mocking/stubbing
I've always done the full database setup and tear down thing, but that's made sufficiently performant with datomics in memory store. Consider using transactions to isolate tests, or use Midje, which is more designed for this kind of usage. --Ashton Sent from my iPhone On Dec 31, 2014, at 9:48 AM, Jonathon McKitrick jmckitr...@gmail.com wrote: I use TDD and mocking/stubbing (conjure) to test each layer of my code. The problem is when I change the function signature and the tests do not break, because the mocks/stubs do not know when their argument lists no longer agree with the underlying function they are mocking. Is there a way to catch this? Short of a test suite that eschews stubbing in favor of full setup/teardown of DB data for each test? -- 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: lazy-seq performance
I was going to say that testing JVM programs is notoriously tricky due to JIT warm up. Did you run that function enough to warm it before taking your timings? This is why micro benchmark frameworks are popular. --Ashton Sent from my iPhone On Dec 31, 2014, at 7:04 PM, Daniel doubleagen...@gmail.com wrote: The first thing that jumps out at me are the boxed numbers: 0N and 1N. I'm guessing the Clojure implementation can produce a much larger result than the python implementation can - so, apples to oranges. Probably unbox the numbers and you get much more comparable speed. Also, you should definitely do two things when running speed comparisons: 1. Make sure the JVM flag -server is configured. 2. Test with Criterium. (https://github.com/hugoduncan/criterium) On Wednesday, December 31, 2014 2:03:03 PM UTC-6, Sakis K wrote: Hi, Clojure newbie here :) I'm reading Programming Clojure by Halloway and Bedra. In the book there is a lazy-seq example of the Fibonacci sequence: (defn lazy-seq-fibo ([] (concat [0 1] (lazy-seq-fibo 0N 1N))) ([a b] (let [n (+ a b)] (lazy-seq (cons n (lazy-seq-fibo b n)) I like the flexibility of this implementation but I am a bit sceptical about its performance: user= (time (rem (nth (lazy-seq-fibo) 100) 1000)) Elapsed time: 53552.014713 msecs 875N Here's a Python implementation taken from http://en.literateprograms.org/Fibonacci_numbers_%28Python%29 def fib(n): a, b = 0, 1 for i in range(n): a, b = b, a + b return a if __name__ == '__main__': print(fib(100) % 1000) time python fib.py 875 real0m16.609s user0m16.475s sys 0m0.115s 53 vs 17 seconds is a big gap. Is there a way to achieve better performance in Clojure? Maybe the fact that I executed the code in the REPL or the Java version that I'm using matters: java -version java version 1.7.0_65 OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu1) OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) -- 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: Finding ClojureScript Libraries
Seems like we need a Clojurescript toolbox like website. --Ashton Sent from my iPhone On Dec 29, 2014, at 11:14 AM, Raju Bitter rajubit...@gmail.com wrote: I agree, that would be really helpful. And cool to see ClojureScript taking off like this! - Raju On Mon, Dec 29, 2014 at 4:49 PM, David Nolen dnolen.li...@gmail.com wrote: There's been an explosion of ClojureScript libraries over the past year. It would be nice to begin tracking them on the wiki so that newcomers can more easily get their bearings: If you have a ClojureScript library please add it to the following growing list: https://github.com/clojure/clojurescript/wiki#useful-libraries If your library works with both Clojure ClojureScript please note that. Thanks! David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: how do you name your protocols?
Changing old protocol names should trigger a major revision change in the minimum because it breaks backwards compatibility. --Ashton Sent from my iPhone On Dec 27, 2014, at 11:18 AM, Michael Klishin michael.s.klis...@gmail.com wrote: On 27 December 2014 at 19:10:38, Jozef Wagner (jozef.wag...@gmail.com) wrote: clj-time seems to be naming protocols inconsistently. It uses ISomething, Something and SomethingProtocol naming. I suspect it is because it has 60 contributors and most users never have to extend the protocols. Feel free to submit a PR that standardises all names on Something. -- @michaelklishin, github.com/michaelklishin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/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: How to get a list of changes in Datomic
I think this conj video covered that. http://m.youtube.com/watch?v=7lm3K8zVOdY --Ashton Sent from my iPhone On Dec 27, 2014, at 1:57 PM, rogergl ro...@gilliar.de wrote: I would like to replay all changes since a specific timestamp. It seems as if I can get all transactions with (q '[:find ?t :where [_ :db/txInstant ?t] ] (db conn)) Using as-of would allow me to replay the state at a given point in time. But that would replay the complete state and not just the changes. Is it possbile to get just the changes for a specific transaction ? I tried (q '[:find ?c ?n :where [?tx :db/txInstant g] [?c :db/txInstant ?n ?tx]] (db conn)) to test if I can get back a result for a specific transaction. That did not work although g was a value from the first query. Regards Roger -- 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: Basic usage of namespaces
(use 'myapp.other) is the same as require with a :refer all from a users perspective, but it's fallen out of favor for :as and :referring individual names. --Ashton Sent from my iPhone On Dec 24, 2014, at 7:37 AM, Fluid Dynamics a2093...@trbvm.com wrote: On Wednesday, December 24, 2014 5:14:01 AM UTC-5, Michael Klishin wrote: On 24 December 2014 at 12:59:11, Eric Le Goff (ele...@gmail.com) wrote: Now my newbie question : Is there a simpler way to avoid the redundant 2 lines (require 'myapp.other) (refer 'myapp.other) (require '[myapp.other :refer [foo]]) See http://clojure-doc.org/articles/language/namespaces.html You can also give it a shorter prefix: (require '[myapp.other :as ot]) (ot/foo 42) = 84 -- 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: [lein] compile sass?
Your best bet is probably to ask for the lein-haml-sass plugin to be updated with the latest and greatest. A simple update is no reason for a fork or rewrite unless if the plugin is simply missing features you need (and that can't be added). --Ashton Sent from my iPhone On Dec 23, 2014, at 4:41 PM, stephanos stephan.beh...@gmail.com wrote: Hey there, I would love to use the SASS library bourbon.io for my project. Is there any way I can use leiningen to compile the scss files to css? PS: I tried lein-haml-sass but there is no bundled version of the sass gem after 3.2.x and bourbon requires at least 3.3. Stephan -- 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 Style Guide
You can put the docstring after the args, but the tooling won't pick it up. --Ashton Sent from my iPhone On Dec 20, 2014, at 10:01 AM, Eli Naeher enae...@gmail.com wrote: On Sat, Dec 20, 2014 at 8:30 AM, Timothy Baldridge tbaldri...@gmail.com wrote: And on a client project recently, it was decided (when I wasn't around) that the arguments to a function should always be on a newline: (defn foo [x] (+ x x)) Instead of: (defn foo [x] (+ x x)) Like you I prefer the arguments on the same line as the defn. Of course, when a docstring is present (and IMO there should nearly always be a docstring), this is not possible. Does anyone here know why in Clojure it was decided to move the docstring from its traditional-in-Lisp location after the argument list? Perhaps it's just a question of what I'm used to, but it feels very awkward to me. I like to be able to see the arglist while I'm reading the docstring so that I can understand to which arguments it's referring, but in Clojure with a long docstring often times the arglist is not even visible on the screen. -Eli -- 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 Style Guide
That's true. I'm just saying I've accidentally done that before in single arity functions with no penalty. But if you count on cider or similar picking up docstrings from your own functions you'll want to do it the official way. --Ashton Sent from my iPhone On Dec 20, 2014, at 10:53 AM, J Irving j...@lollyshouse.ca wrote: It's not a docstring then, just the first expression in the body. On Sat, Dec 20, 2014 at 12:05 PM, Ashton Kemerling ashtonkemerl...@gmail.com wrote: You can put the docstring after the args, but the tooling won't pick it up. --Ashton Sent from my iPhone On Dec 20, 2014, at 10:01 AM, Eli Naeher enae...@gmail.com wrote: On Sat, Dec 20, 2014 at 8:30 AM, Timothy Baldridge tbaldri...@gmail.com wrote: And on a client project recently, it was decided (when I wasn't around) that the arguments to a function should always be on a newline: (defn foo [x] (+ x x)) Instead of: (defn foo [x] (+ x x)) Like you I prefer the arguments on the same line as the defn. Of course, when a docstring is present (and IMO there should nearly always be a docstring), this is not possible. Does anyone here know why in Clojure it was decided to move the docstring from its traditional-in-Lisp location after the argument list? Perhaps it's just a question of what I'm used to, but it feels very awkward to me. I like to be able to see the arglist while I'm reading the docstring so that I can understand to which arguments it's referring, but in Clojure with a long docstring often times the arglist is not even visible on the screen. -Eli -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Core Banking And The Mechanics Of Money Creation
I'm sure successful releases will go a long way on the clojure tolerance front. --Ashton Sent from my iPhone On Dec 18, 2014, at 7:23 AM, Timothy Washington twash...@gmail.com wrote: That's awesome. I'm glad you and your clients are seeing the benefits. Much success :) Tim Washington Interruptsoftware.com 416.843.9060 On Wed, Dec 17, 2014 at 8:04 PM, Matt Dean m...@trabian.com wrote: Tim, I enjoyed reading your post. Having recently launched an online banking user interface for a credit union using the same principles you mentioned (and React), I agree that this represents the path forward for financial institutions, and a surprising number of credit union execs seem to feel the same. It's an intimidating idea for most but they're seeing the opportunity. To bring this back around to the mailing list topic, we've recently started a new banking front end using clojurescript, with a liberator-based mock API for development. The experience has been fantastic and we're looking forward to using Clojure as much as our clients can tolerate. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Handling increasingly-intensive processes
Apologies on the email flood, my email client decided to do the most useless of all possible actions. On Sun, Dec 14, 2014 at 11:53 PM, Ashton Kemerling ashtonkemerl...@gmail.com wrote: Honestly, it sounds like you'll either need to move the indexing into memor On Sun, Dec 14, 2014 at 8:54 PM, Sam Raker sam.ra...@gmail.com wrote: I'm (still) pulling tweets from twitter, processing them, and storing them in CouchDB with hashtags as doc ids, such that if a tweet contains 3 hashtags, that tweet will be indexed under each of those 3 hashtags. My application hits CouchDB for the relevant document and uses Cheshire to convert the resulting string to a map. The map's values consist of a few string values and an array that consists of all the tweets that contain that hashtag. The problem is thus with common hashtags: the more tweets contain a given hashtag, the long that hashtag's tweets array will be, and, additionally, the more often that document will be retrieved from CouchDB. The likelihood and magnitude of performance hits on my app are therefore correlated, which is Bad. I'm reaching out to you all for suggestions about how best to deal with this situation. Some way of caching something, somehow? I'm at a loss, but I want to believe there's a solution. Thanks, -sam -- 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: Handling increasingly-intensive processes
Sam, It sounds like you need to either find a caching strategy that works for your application's needs, or you'll need to adjust how your data is stored (model or data store). Without knowing more about your performance and business needs I can't really speculate with any confidence. -- Ashton On Sunday, December 14, 2014 8:54:04 PM UTC-7, Sam Raker wrote: I'm (still) pulling tweets from twitter, processing them, and storing them in CouchDB with hashtags as doc ids, such that if a tweet contains 3 hashtags, that tweet will be indexed under each of those 3 hashtags. My application hits CouchDB for the relevant document and uses Cheshire to convert the resulting string to a map. The map's values consist of a few string values and an array that consists of all the tweets that contain that hashtag. The problem is thus with common hashtags: the more tweets contain a given hashtag, the long that hashtag's tweets array will be, and, additionally, the more often that document will be retrieved from CouchDB. The likelihood and magnitude of performance hits on my app are therefore correlated, which is Bad. I'm reaching out to you all for suggestions about how best to deal with this situation. Some way of caching something, somehow? I'm at a loss, but I want to believe there's a solution. Thanks, -sam -- 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.edn won't accept clojure.java.io/reader? How to work around this and why isn't this documented anywhere?
Nothing in the Java.io namespace was made by the clojure team, so it's not their fault that reader and pushbackreader aren't cross compatible. I'm assuming that they need something from pushbackreader for performance reasons, but that's just a guess. Clojurescript and ClojureCLR must have different solutions because they're just different platforms. Abstracting the whole high performance IO api from each of these platforms is silly and probably unwise. --Ashton Sent from my iPhone On Dec 8, 2014, at 1:12 AM, Fluid Dynamics a2093...@trbvm.com wrote: On Monday, December 8, 2014 2:26:42 AM UTC-5, Andy Fingerhut wrote: In regards to your question Why isn't this documented anywhere?, it is documented somewhere -- in the documentation string for clojure.edn/read, the very function you were attempting to use: user= (doc clojure.edn/read) - clojure.edn/read ([] [stream] [opts stream]) Reads the next object from stream, which must be an instance of java.io.PushbackReader or some derivee. stream defaults to the current value of *in*. What's *not* documented is that io/reader doesn't output something that edn/read can use directly, nor is there documented an officially recommended workaround for this. AFAICT just wrapping the reader output in (java.io.PushbackReader. ...) works. Still, this is awkward, verbose, and prevents the (nontrivial) use of edn in a platform-neutral way by referring only to Clojure functions without direct interop. Well, except for the even more awkward workaround of slurp and read-string, with the accompanying need to hold the entire file in memory *twice* for a short time. As far as why it requires a PushbackReader, I didn't design the API. Yes, some things in Clojure require using Java interop, and in many (but not all) cases, file I/O requires it. Perhaps io/reader should output a PushbackReader, if only for convenience's sake. Also, how does this work on ClojureCLR or ClojureScript? Neither of those platforms has a java.io.PushbackReader, and I'm not even sure what the equivalent of the clojure.java.io namespace is for them, unless the java in that name is misleading. -- 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: Is there a tool to display all the references to a symbol in a project?
I would recommend the silver searcher (ag) if the project is large, as it is much faster. --Ashton Sent from my iPhone On Dec 3, 2014, at 8:34 AM, Gary Trakhman gary.trakh...@gmail.com wrote: I use grep or ack. It's not exact, but it works. On Wednesday, December 3, 2014, Yehonathan Sharvit vie...@gmail.com wrote: Is there a tool to display all the references to a symbol in a project? Preferably without using emacs. Thanks. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this 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: [ANN] stateful-check 0.1.0 - test stateful systems with test.check
I'm glad my talk got someone working on things! I'm going to see if that library would be a better match for our integration tests than test.check alone. --Ashton Sent from my iPhone On Nov 28, 2014, at 9:50 AM, Carlo Zancanaro carlozancan...@gmail.com wrote: Hey Jan! On Fri, Nov 28, 2014 at 06:37:06AM -0800, Jan Stępień wrote: Thanks for sharing! I see that generative testing of statful computations is a popular topic in the Clojure world these days; Yeah, it certainly seems to be that way. I was re-invigorated to work on stateful-check after watching a talk from the conj about generative integration tests. I think we've started working on our libraries nearly the same day :) https://github.com/jstepien/states I've actually seen your library since writing stateful-check. When I experimented with it, though, I found its shrinking to be a bit lacking. With stateful-check I've actually implemented my own shrinking of commands to try to improve the shrinking results (it essentially tries to prune irrelevant commands before trying to shrink individual commands). I was quite interested in your approach of using a single function per specification property (precondition/postcondition/next-state). I thought that would be a bit constricting when it comes to actually writing test cases, though, so I've opted instead to have each of those defined per-command. How have you found that to be in practice? Thanks! Carlo -- 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: snubbed on clojurescript one
I thought the pedestal frontend is not being developed. I would recommend om, reagent, or dommy depending on what your goals are. --Ashton Sent from my iPhone On Nov 18, 2014, at 11:56 AM, atucker agjf.tuc...@gmail.com wrote: Pedestal is a continuation of ClojureScript One. https://groups.google.com/d/msg/clojure/XQ4wuUc0bCk/JuUmUj6cSwUJ On Tuesday, 18 November 2014 06:39:40 UTC, Kevin Banjo wrote: Really excited to use clojurescript one but got shot down right out of the gate. Anyone here have the answer? https://github.com/brentonashworth/one/issues/145 -- 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: Mutable local variables
Mutation is not a bad performance optimization, and is super useful when the
algorithm in question just works better with it.
--Ashton
Sent from my iPhone
On Nov 10, 2014, at 11:11 AM, Jacob Goodson submissionfight...@gmx.com
wrote:
I like the map suggestion but there are still those times when mutation makes
for a cleaner hack(imo of course).
On Monday, November 10, 2014 5:44:25 AM UTC-5, Thomas Heller wrote:
@Jacob: If you get too many arguments in a loop I found it best to use a map.
(loop [{:keys [a b c] :as state} a-map]
(cond
(and (= a 1) (= b 2))
(recur (update state :a inc)) ;; 1.7+ only, otherwise use update-in
...))
Working with named arguments (vs. positional) is a lot more user-friendly
since you don't have to repeat everything all the time.
HTH,
/thomas
On Monday, November 10, 2014 8:21:57 AM UTC+1, Jacob Goodson wrote:
Sometimes, when writing code that loops with a good bit of branching, it
can be quite annoying to stay immutable.
(loop [way 1
too 2
many 3
args 4
makes 5
things 6
annoying 7]
(cond (and (= way 3) (= too 4)) (recur (inc way) you get the point.
Imagine about 14 different conditions under cond and this thing starts
looking like crap. I got around this with macros and pattern matching,
however, I do not think that this happens too often for many clojurians.
On Saturday, November 8, 2014 11:49:42 PM UTC-5, Fluid Dynamics wrote:
I wonder if the OP is aware that you can rebind the same name multiple
times in a let. For instance
(let [x something
y otherthing
x (if (pred? x y) x (some-func x y))
x (further (complex (calculations x)))
...]
(do-something-with x))
No actual mutability, but most of the times that suffices for whatever you
might use a mutable local for in another language.
Then there's loop/recur. I'd consider let rebinding and loop/recur long
before resorting to any sort of mutable. The most significant pain point
in my experience has been wanting to smuggle a side calculation out of
some closure that has to return something else. The most recent case I ran
into like that involved (swap! some-atom conj thingy) where the atom held
a vector, I also wanted to know the new length of the vector, I didn't
want any race conditions (following up with a (count @some-atom) allowed
the possibility of the vector changing again in between the swap and the
deref, but I wanted to know the position of the item just conjed on), and
dosync/ref seemed like overkill (only the one isolated mutable). I *could*
have done something like
(let [c (int-array 1)]
(swap! some-atom (fn [x] (let [x (conj x thingy)] (aset c 0 (count x))
x)))
(let [c (aget c 0)]
; work with c
...))
but it was unnecessary to use this kluge, for swap! returns not the atom
itself but the new value that was returned by the passed-in function. So
all I actually needed was
(let [c (count (swap! some-atom conj thingy))]
...)
with no mutability besides the atom itself (and in particular no local
mutability). I've since needed swap!'s return value on another occasion,
when it was a map, resulting in (get-in (swap! m update-in [k1 k2] f arg1
arg2) [k1 k2]) to both update the map and have the exact value for the
sub-key that was updated, as of that update. With maps, it may also be
possible to store some extra information in the map with a
::module-local-keyword without this interfering with anything else, which
can be pulled out of swap!'s return value, and with several kinds of
objects you can smuggle extra information out of a closure by adding a
::module-local-keyword to the object's *metadata* (in particular, this
won't perturb the equality semantics of the object, as well as working
with vectors and several other non-map-like things as well as with records
and maps. And if you're wanting to return extra information out of an
ordinary function or a loop where you control how the return value is
interpreted, you can bind and destructure the return value after making
that a short vector or a map with several thingys in it.
Lately I hardly ever find myself feeling the need for any kind of local
mutables, and only small amounts of global state (often nothing, or just
one atom wrapping a map handled with nesting, update-in, assoc-in, and
get-in, though refs and dosync will put in an appearance if a high degree
of concurrency is required).
--
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
Re: better way to group consecutive numbers in a vector?
Consider using partition-by. I can't type clojure on my phone, but the following link might help. https://clojuredocs.org/clojure.core/partition-by --Ashton Sent from my iPhone On Nov 6, 2014, at 3:22 PM, John Gabriele jmg3...@gmail.com wrote: Hi all, I've got this: `[1 3 4 5 7 9 10 11 12]` and I'd like to turn it into this: `[[1] [3 4 5] [7] [9 10 11 12]]`. That is, I'd like to group consecutive numbers together (the final goal being to produce something like `[1 3-5 7 9-12]`, but that's the easy part). I haven't found an easy way to do this. Here's what I've come up with in Clojure: ~~~clojure #!/usr/bin/env lein-exec (def v [1 3 4 5 7 9 10 11 12]) (defn congeal-consecutives [coll] (reduce (fn [accum x] (if (= x (inc (last (last accum (concat (butlast accum) [(conj (last accum) x)]) (concat accum [[x]]))) [[(first coll)]] (rest coll))) (prn (congeal-consecutives v)) ~~~ and here's it done in Python: ~~~python #!/usr/bin/python3 v = [1, 3, 4, 5, 7, 9, 10, 11, 12] def congeal_consecutives(coll): accum = [[ coll[0] ]] more = coll[1:] for x in more: if x == accum[-1][-1] + 1: accum[-1].append(x) else: accum.append([x]) return accum print(congeal_consecutives(v)) ~~~ Can anyone suggest a better / simpler / more easily-understandable way to do this in Clojure? Thanks, -- John -- 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.test.check with fixtures
You can use fixtures from Clojure.test, but each spec from the perspective of clojure.test includes multiple runs. So I use fixtures :once to do any global setup, and then farm out to a setup function for anything that needs to be done before each test run. --Ashton Sent from my iPhone On Nov 5, 2014, at 3:27 PM, Sven Richter sver...@googlemail.com wrote: Hi, Is there a way to use clojure.test.check's defspec with fixtures? Like (use-fixtures :each (partial wrap-setup setup teardown)) in clojures test library? How do other people execute setup and teardowns with clojure.test.check? Best Regards, Sven -- 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 usage in production - survey on Hacker News (Nov 2014)
I'm really entertained that pivotal labs made that list, as I wrote that code (and that blog post) and production is stretching definitions pretty far sadly. On Mon, Nov 3, 2014 at 4:55 PM, viksit vik...@gmail.com wrote: Hello all, I was curious about the state of Clojure in production, and put up this thread on Hacker News asking for insight, since all the other threads are quite dated. https://news.ycombinator.com/item?id=8549823 Given the large amount of feedback that's already on it, I thought I'd cross post here and get the list's feedback on this as well. I think it would be great to have this resource updated with the latest state of Clojure in production around the world, especially so in helping answer queries in people's minds as they try to figure out who else uses it before they do. Cheers, Viksit -- 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 usage in production - survey on Hacker News (Nov 2014)
We aren't secretive about our usage of it, but it's used for testing only. It doesn't get shipped to any server, hence why production is a stretch. On Mon, Nov 3, 2014 at 5:57 PM, Alex Miller a...@puredanger.com wrote: I was mostly trying to include interesting companies using it for something. Sorry if I overstepped! :) On Monday, November 3, 2014 6:27:41 PM UTC-6, viksit wrote: Ashton - perhaps you should elucidate on matters on that thread :) And why do you say stretching definitions? On Monday, November 3, 2014 4:03:36 PM UTC-8, Ashton Kemerling wrote: I'm really entertained that pivotal labs made that list, as I wrote that code (and that blog post) and production is stretching definitions pretty far sadly. On Mon, Nov 3, 2014 at 4:55 PM, viksit vik...@gmail.com wrote: Hello all, I was curious about the state of Clojure in production, and put up this thread on Hacker News asking for insight, since all the other threads are quite dated. https://news.ycombinator.com/item?id=8549823 Given the large amount of feedback that's already on it, I thought I'd cross post here and get the list's feedback on this as well. I think it would be great to have this resource updated with the latest state of Clojure in production around the world, especially so in helping answer queries in people's minds as they try to figure out who else uses it before they do. Cheers, Viksit -- 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: On Testing
I can say for certain that at a minimum better indentation of data structures to the console would be a must, a vector with 4+ hash maps in it are currently unreadable and I have to copy to an editor to indent and analyze. Beyond that, I can imagine the need for a structural diff that tells me in a human readable form how things are different. Different types (plain sequence vs hash map), different positions or keys in structures, etc. On Sat, Nov 1, 2014 at 12:58 PM, Alex Miller a...@puredanger.com wrote: It would be great if someone could enumerate more explicitly what better test output means. What are the specific problems in the current test output reporting? Similar problem list for test runner might be useful. Discussion here is fine but ultimately needs to land on a design wiki page. I am happy to do what I can to move this through a process toward inclusion in a release. -- 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.
On Testing
I tweeted recently that I thought that Clojure is super testable, and I was genuinely surprised about the number of people who disagreed with me. There's been a lively discussion about what the best testing frameworks in clojure currently are, and what the built in solutions (clojure.test and test.check) are lacking. While a lot of people recommend midje or expectations, I generally prefer the built in options (no offense to contributors of either of those libraries) and usually recommend people stick with clojure.test for its lack of magic. It's my opinion that these two libraries are largely complete aside from some human interface improvements (quality of output for example), but clearly not everyone agrees with me. So let's talk about what we could add to make the clojure testing experience superior compared to other languages. -- 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: On Testing
I don't want to speak for others, I notified everyone involved on Twitter that I made this thread so they can voice their own complaints. On Fri, Oct 31, 2014 at 9:02 AM, László Török ltoro...@gmail.com wrote: I tweeted recently that I thought that Clojure is super testable, and I was genuinely surprised about the number of people who disagreed with me. My 2c. Without explicitly citing those complaints, it will be difficult to conduct a meaningful debate. 2014-10-31 14:52 GMT+00:00 Ashton Kemerling ashtonkemerl...@gmail.com: I tweeted recently that I thought that Clojure is super testable, and I was genuinely surprised about the number of people who disagreed with me. There's been a lively discussion about what the best testing frameworks in clojure currently are, and what the built in solutions (clojure.test and test.check) are lacking. While a lot of people recommend midje or expectations, I generally prefer the built in options (no offense to contributors of either of those libraries) and usually recommend people stick with clojure.test for its lack of magic. It's my opinion that these two libraries are largely complete aside from some human interface improvements (quality of output for example), but clearly not everyone agrees with me. So let's talk about what we could add to make the clojure testing experience superior compared to other languages. -- 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. -- László Török Checkout justonemorepoint.com - Know your true value -- 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: On Testing
That's an excellent idea, currently at least test.check hacks on top of clojure.test by using macros that emit clojure.test tests. Beyond that it seems that the #1 wish is better output. I don't think that ought to be very hard for us to pull off as a community. On Fri, Oct 31, 2014 at 6:56 PM, Andrew Rosa andre...@me.com wrote: +1 to something like humane-test-output being part of core library. There is value for the community to have some foundation library share across our test frameworks? Something like `test.runners`, to encapsulate error reporting and organization? Bit crazy, I know, but the idea come after seeing Haskell's https://github.com/feuerbach/tasty. OK, I don't do Haskell, but I kind of like the way of composing a single integrated suite of different flavors of test. Andrew On Friday, October 31, 2014 10:41:09 PM UTC-2, John Louis Del Rosario wrote: Would be great if humane-test-output was part of clojure.test. Would make it easier for beginners to find it. On Friday, October 31, 2014 11:19:11 PM UTC+8, Eli Naeher wrote: On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling ashtonk...@gmail.com wrote: It's my opinion that these two libraries are largely complete aside from some human interface improvements (quality of output for example), but clearly not everyone agrees with me. Hi Ashton, Check out https://github.com/pjstadig/humane-test-output if you haven't already seen it, it's a nice improvement over the default output--in particular seeing the specific diffs between expected and actual values is really useful when you are dealing with collections. -Eli -- 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: Starting a project the right way - tips?
Consider how your database will be setup and handled. My project uses Datomic (also a SPA), but it was a little painful learning how to get the tests to run cleanly with the database being setup and torn down between runs. Also, consider using Secretary on the frontend early. I’m using Om and thought I could get away without it by using component state to control what is displayed, and boy was I wrong. — Ashton On Mon, Oct 27, 2014 at 6:54 AM, Joshua Ballanco jball...@gmail.com wrote: Just in case you hadn’t already come across it in your Google-ing, I thought you should know about http://clojure-doc.org . This site is more than just API documentation, it also contains a number of useful guides covering various topics in Clojure. It’s not exactly a collection of prescriptions, but it might help you figure out what direction to head in more than just reading the API docs would. Cheers, Josh On October 27, 2014 at 13:08:42, Colin Yates (colin.ya...@gmail.com) wrote: About to embark on a new project and interested in wish I knew this/wish I had used this type sentiments. An extension of this splendid article: http://blog.mattgauger.com/blog/2014/09/15/clojure-code-quality-tools/. Any others? For context, this is going to be a non-trivial SPA using clojurescript supported by a Clojure backend (https://groups.google.com/d/topic/clojurescript/9cDFfAGsDE4/discussion) In addition to the tips I found in the article I am also planning on using core.typed, primarily to address the anyone remember what this data structure looked like? 12 month maintenance risk. I did look at schematic but I like the extra enforcement core.typed gives. On a side note, answering this question from google alone is non-trivial. We, as a community have reached that point where there are so many (good, but overlapping and sometimes contradictory) good next steps it is easy to be paralysed by choice. A few more authorized (whatever that means) prescriptions wouldn't go amiss. Not sure what the answer is, merely raising the flag. So, what tips/techniques/XYZ do you wish you had started with? Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this 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: Starting a project the right way - tips?
I ham-fistedly kill and reset the DB before every test using clojure.test fixtures. Passing the conn never occurred to me, and I kind of wish I did it that way. Currently I have any reading database functions accept the db (which makes testing using “with” very fast and easy), and any writing functions return the tx-data rather than executing it directly. This also makes testing easier, as I can assert on the exact tx-data expected, or again use with in my tests to check the side-effects. As a result the only tests I have that actually touch db state are anything that check my actual routing code. — Ashton On Mon, Oct 27, 2014 at 7:52 AM, Sven Richter sver...@googlemail.com wrote: Hi Ashton, After some discussion in the datomic and clojure irc channel I decided to go the route to pass in the datomic connection or datomic value to every function. This way it is really easy to do integration tests of these functions by setting up an in memory datomic database for every single one of my tests. Mixing in some fixtures and I was done. I am curious, how did you solve this finally? Best Regards, Sven Am Montag, 27. Oktober 2014 14:25:12 UTC+1 schrieb Ashton Kemerling: Consider how your database will be setup and handled. My project uses Datomic (also a SPA), but it was a little painful learning how to get the tests to run cleanly with the database being setup and torn down between runs. Also, consider using Secretary on the frontend early. I’m using Om and thought I could get away without it by using component state to control what is displayed, and boy was I wrong. — Ashton On Mon, Oct 27, 2014 at 6:54 AM, Joshua Ballanco jbal...@gmail.com javascript: wrote: Just in case you hadn’t already come across it in your Google-ing, I thought you should know about http://clojure-doc.org . This site is more than just API documentation, it also contains a number of useful guides covering various topics in Clojure. It’s not exactly a collection of prescriptions, but it might help you figure out what direction to head in more than just reading the API docs would. Cheers, Josh On October 27, 2014 at 13:08:42, Colin Yates (colin...@gmail.com javascript:) wrote: About to embark on a new project and interested in wish I knew this/wish I had used this type sentiments. An extension of this splendid article: http://blog.mattgauger.com/blog/2014/09/15/clojure-code-quality-tools/. Any others? For context, this is going to be a non-trivial SPA using clojurescript supported by a Clojure backend ( https://groups.google.com/d/topic/clojurescript/9cDFfAGsDE4/discussion) In addition to the tips I found in the article I am also planning on using core.typed, primarily to address the anyone remember what this data structure looked like? 12 month maintenance risk. I did look at schematic but I like the extra enforcement core.typed gives. On a side note, answering this question from google alone is non-trivial. We, as a community have reached that point where there are so many (good, but overlapping and sometimes contradictory) good next steps it is easy to be paralysed by choice. A few more authorized (whatever that means) prescriptions wouldn't go amiss. Not sure what the answer is, merely raising the flag. So, what tips/techniques/XYZ do you wish you had started with? Thanks! -- 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. signature.asc -- 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
Re: Cannot understand why I get this output.
The hash map you posted has the value of [octavia] under the key :authors, and
that's what printed out. The repl doesnt inline the variable name, instead it
prints out the literal value.
On Mon, Oct 27, 2014 at 9:22 AM, Roelof Wobben rwob...@hotmail.com
wrote:
Op maandag 27 oktober 2014 16:07:15 UTC+1 schreef Gary Verhaegen:
On Monday, 27 October 2014, Roelof Wobben rwo...@hotmail.com
javascript: wrote:
Now Im complete confused. I never succeed in reading the value of authors
so I can do the set command.
Roelof
And now you're kind of confusing me. What makes you think you do not read
the value of authors? What did you expect instead of what you got?
I expected the outcome : *octavia*
but I see the output : [{:death-year 2006, :name
Octavia E. Butler, :birth-year 1947}]
Roelof
--
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: Cannot understand why I get this output.
I think you're confused on the terminal output. Try typing [octavia] in the
repl, and compare the output you get to the above code.
Clojure prints out the raw values of any computation, not variable names.
On Mon, Oct 27, 2014 at 9:45 AM, Roelof Wobben rwob...@hotmail.com
wrote:
Op maandag 27 oktober 2014 16:37:49 UTC+1 schreef James Reeves:
On 27 October 2014 13:45, Roelof Wobben rwo...@hotmail.com javascript:
wrote:
Hello,
I have this facts.
(def octavia {:name Octavia E. Butler
:birth-year 1947
:death-year 2006})
So you've assigned the var octavia to the data structure:
{:death-year 2006, :name Octavia E. Butler, :birth-year 1947}
(def wild-seed {:title Wild Seed, :authors [octavia]})
Here you've assigned the var wild-seed to:
{:title Wild Seed, :authors [octavia]}
Which is the same as:
{:title Wild Seed, :authors [{:death-year 2006, :name Octavia E. Butler,
:birth-year 1947}]}
So I thought when I do this :
(defn old-book-new-book [book]
(get book :authors))
(old-book-new-book {:title Wild Seed, :authors [octavia]})
Okay, so work through your code. You start with:
(old-book-new-book {:title Wild Seed, :authors [octavia]})
Resolving this gets:
(get {:title Wild Seed, :authors [octavia]} :authors)
Resolving this gets:
[octavia]
Which resolves to:
[{:death-year 2006, :name Octavia E. Butler, :birth-year 1947}]
I'm not sure why you'd expect anything else. Did you not expect octavia
to resolve?
- James
I think I do not fully understand how clojure works as a beginner.
As far as I see it I have to find a way to stop with [octavia] so I can
make a set of it.
Roelof
--
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: Question about test.check, and knossos
Oh thank goodness, I've been directing people towards the source for test.check, which is obviously sub-optimal. Thanks for adding that! On Fri, Oct 24, 2014 at 11:43 AM, Reid Draper reiddra...@gmail.com wrote: Hey Andy, I've added a link to the API documentation [1]. And I'll update Codox for the next version of test.check, hopefully to be released shortly. [1] https://github.com/clojure/test.check/commit/200b77bbf24b67d2904dab4d4f5722badbe8b223 Reid On Thursday, October 23, 2014 11:44:54 PM UTC-5, Andy Chambers wrote: On Thursday, October 23, 2014 11:21:44 PM UTC-4, Andy Chambers wrote: On Thursday, October 23, 2014 9:23:36 PM UTC-4, tcrayford wrote: Hi Andy, All, I wrote a tool like this: https://github.com/tcrayford/laundromat it's super hacky, and the api is definitely in beta. I asked some folk about reviewing this api, got little feedback, and figured it wasn't that much of a wanted thing after all. I still use it internally, but it's pretty bad at what it does right now. I'd love to hear if more folk are interested or if anybody's interested in contributing. Hi Tom, Your project looks interesting and I definitely think it has value. Where were you expecting feedback? When I have questions about a project like this, I'm never sure where to ask them. Stackoverflow? A github issue? Google groups? Anyway it looks pretty cool to my untrained eye but I'd be interested in hearing what Reid Draper or Kyle Kingsbury has to say about it. Do you mind me asking what made you decide to diverge from the original Erlang implementation? Also what makes it bad? I'd be interested in helping out if I can. Also, while I'm here talking about test.check, there's a couple of bugs I'd like to report. * There's no link to the API docs in the README * I did manage to find some docs here ( http://clojure.github.io/test.check/) but there is no link to the source like there is in the compojure codox documentation I tried to use JIRA after signing the CA but the secure signing page doesn't seem to be working at the moment (screenshot attached). Cheers, Andy -- 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: ANN: State of Clojure 2014 Survey - please contribute!!
I would rather not say is a common and valid response in these scenarios. On Wed, Oct 15, 2014 at 12:19 PM, Sean Corfield s...@corfield.org wrote: Asking questions about race and/or gender can be a very sensitive issue and a lot of people would refuse to complete those sections, or may even refuse to complete the survey at all if such questions were included - for a variety of very valid reasons. Sean On Oct 14, 2014, at 9:23 PM, Zack Maril thewitzb...@gmail.com wrote: ClojureBridge and conj grants are excellent ways to encourage all types of folks to join Clojure and I'm stoked that these programs have emerged from the community. These are Good Things and should be continued and improved upon wherever possible. I'd personally like to know how much good these efforts do and tracking demographics of the Clojure community, whether it is through the State of Clojure survey or other means, would allow us to measure the distance between our ideals and reality. I'm proud of the attempts and efforts undertaken to increase diversity within the community and, beyond the specifics of this current conversation, I'm confident that Clojure will make strides towards a more diverse user base. For the issue at hand, I believe that by including demographics within the State of the Clojure survey the Clojure leadership would be making a strong statement indicating their desire for a more desire community. The survey measures that which has been deemed important to know and understand in terms of the stewardship and development of Clojure. Including demographic questions in the survey, along with the context of why they were included, would indicate that there is a strong desire to understand and improve the diversity of the community by those who lead the community. Inclusion of such questions on the survey would be another opportunity for Clojure to be more than just not unwelcoming to atypical folks and allow us to purposefully invite more people to this relative paradise we inhabit. For a relatively small effort* it would show atypical folks that we care to know that they exist in the context of Clojure usage and that we are interested in understanding and improving their situation. -Zack *If I've misgauged the difficultly of adding such questions to the survey, please say so. My impression is that this would be straightforward technologically and, by perhaps copying questions from similar surveys, straightforward in terms of survey design. I don't mean to ask you to drop everything and try to solve all the problems of sexism all at once but only to do something which seems, from an outside perspective, fairly economical with low costs and high benefits. -- 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: State of Clojure 2014 Survey - please contribute!!
I'm curious if there's any empirical evidence that significant numbers of people will do that. On Wed, Oct 15, 2014 at 6:23 PM, Mars0i marsh...@logical.net wrote: I don't really get it. I don't see a legitimate reason why anyone would refuse to participate in the survey because it included demographic questions. The survey is anonymous. The combination of questions is not such that it would be at all plausible that anyone could be identified by their responses. At worst, answering a few additional questions--or simply skipping those questions--would be a very minor annoyance. Is it that some people object to the idea that there are disparities due to systemic factors in our society? If someone wants to disagree about that, OK, but I still don't see how boycotting a survey because it offers respondents the opportunity to provide demographic information is reasonable. On Wednesday, October 15, 2014 2:06:29 PM UTC-5, Sean Corfield wrote: On Oct 15, 2014, at 11:29 AM, Ashton Kemerling ashtonk...@gmail.com javascript: wrote: I would rather not say is a common and valid response in these scenarios. Yes, although that doesn't address that there are people who will not complete a survey that even asks such questions (on a philosophical objection to collecting such demographic information). As I said, it's a sensitive issue. As Bridget noted, they'll consider the approach for 2015. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: ANN: State of Clojure 2014 Survey - please contribute!!
I wasn't prepared to make moral statements about the survey, I'm just interested in what helps the community the most. If such questions would exclude people from the survey and/or the community then obviously that seems problematic, although I'm curious (but not doubtful) as to why that would happen. But I am not in a position of authority or experience in this area, if others more experienced than I believe that's a bad idea, I'm happy to defer to their wiser judgement. -- Ashton On Wed, Oct 15, 2014 at 7:49 PM, Sean Corfield s...@corfield.org wrote: I'm replying to Ashton and Mars0i off-list - and I'm happy to continue discussing the issue off-list, with anyone who wants to, but I think it's getting off-topic and close to inappropriate for this (technical) list. And, for what it's worth, Atamert, I'm on your side on this. Sean On Oct 15, 2014, at 6:44 PM, Atamert Ölçgen mu...@muhuk.com wrote: On Thu, Oct 16, 2014 at 8:30 AM, Ashton Kemerling ashtonkemerl...@gmail.com wrote: I'm curious if there's any empirical evidence that significant numbers of people will do that. Suppose I have provided reliable data that shows only 0.1% would refuse to answer such a Survey. A programming related survey with questions about demographics and a stated mission of being inclusive. What would be your moral reasoning for not being inclusive for this group of people? -- 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: State of Clojure 2014 Survey - please contribute!!
I also just realized that I'm accidentally continuing this conversation despite Sean's best efforts. Please disregard my last message. On Wed, Oct 15, 2014 at 8:31 PM, Ashton Kemerling ashtonkemerl...@gmail.com wrote: I wasn't prepared to make moral statements about the survey, I'm just interested in what helps the community the most. If such questions would exclude people from the survey and/or the community then obviously that seems problematic, although I'm curious (but not doubtful) as to why that would happen. But I am not in a position of authority or experience in this area, if others more experienced than I believe that's a bad idea, I'm happy to defer to their wiser judgement. -- Ashton On Wed, Oct 15, 2014 at 7:49 PM, Sean Corfield s...@corfield.org wrote: I'm replying to Ashton and Mars0i off-list - and I'm happy to continue discussing the issue off-list, with anyone who wants to, but I think it's getting off-topic and close to inappropriate for this (technical) list. And, for what it's worth, Atamert, I'm on your side on this. Sean On Oct 15, 2014, at 6:44 PM, Atamert Ölçgen mu...@muhuk.com wrote: On Thu, Oct 16, 2014 at 8:30 AM, Ashton Kemerling ashtonkemerl...@gmail.com wrote: I'm curious if there's any empirical evidence that significant numbers of people will do that. Suppose I have provided reliable data that shows only 0.1% would refuse to answer such a Survey. A programming related survey with questions about demographics and a stated mission of being inclusive. What would be your moral reasoning for not being inclusive for this group of people? -- 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: State of Clojure 2014 Survey - please contribute!!
It would've been nice to have back-stats to tell if efforts like Clojure bridge are having a statistical impact on the communities makeup. That being said, I'm sure the clojure bridge folk have their own internal metrics to guide their actions and measure outcomes, but it would've been nice to see overall. On Mon, Oct 13, 2014 at 5:10 PM, Mars0i marsh...@logical.net wrote: On Monday, October 13, 2014 1:50:13 PM UTC-5, Zack Maril wrote: Next year, I would appreciate questions that measure the demographics of Clojure users be included. Out of the hundreds of people I've heard and seen talking about using Clojure, the vast majority of them have been white men. I've thought about it for a few days now and I can only think of three or four women who I know use Clojure and only a few non white men. I'd like to know if selecting Clojure as my default/main programming language means that I'll be forced to select from a fairly homogeneous group of potential coworkers and miss out on the benefits of a diverse working environment. -Zack I agree that including demographic questions would be a nice addition. In the U.S., the distribution of sexes and racial/ethnic groups among IT people http://dpeaflcio.org/professionals/professionals-in-the-workplace/the-professional-computer-work-force/ is pretty skewed toward white males, as I'm sure you would imagine. Even if the percentages of groups among Clojure programmers were the same as they are for, say, Java programmers, there would in theory be a lot more women and non-white Java programmers to choose from if you wanted to build a diverse shop. That is, in general if you're in a smaller community (Clojure), your flexibility is more limited. (Also, although I think the State of Clojure survey is valuable, no one would claim that it uses a reliable sampling method. That's not a criticism at all. Coming up with a reliable sample would be difficult, in practice, The point is that sampling problems can be worse when you're dealing with small numbers. So for example, if one group of people is a small but significant minority of all programmers, survey on their percentages in a relatively small community, such as the Clojure could be wildly inaccurate, even if their percentages were higher among Clojure programmers than in the general programming community. -- 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: Diversity (was: State of Clojure 2014 Survey - please contribute!!
I'm always very proud to tell other people how much effort the clojure community is putting into this, especially compared to its size. Keep up the good work! -- Ashton On Mon, Oct 13, 2014 at 5:41 PM, Sean Corfield s...@corfield.org wrote: On Oct 13, 2014, at 11:50 AM, Zack Maril thewitzb...@gmail.com wrote: I'd like to know if selecting Clojure as my default/main programming language means that I'll be forced to select from a fairly homogeneous group of potential coworkers and miss out on the benefits of a diverse working environment. One of the reasons I started ClojureBridge - http://clojurebridge.org - was because of the lack of diversity in the visible Clojure community and I wanted to see if we could do for Clojure what RailsBridge did for the Ruby on Rails community. We have been running workshops successfully around the globe now for over six months. I've been very pleased with the amount of support ClojureBridge has received from the community, and that a strong team has emerged to run the organization (so my involvement is now fairly minimal). It will take time but I believe we can change the demographics of our community if we all want to do so. In particular, the demographics of your work environment depend almost entirely on your hiring process and willingness to train your employees so that's definitely an area where you can effect change if you have the will. Sean Corfield -- http://clojurebridge.org ClojureBridge aims to increase diversity within the Clojure community by offering free, beginner-friendly Clojure programming workshops for women. -- 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 is my function faster with eval?
Did you run it enough times to fully warm up the JVM?
On Fri, Oct 10, 2014 at 4:21 PM, Michael Blume blume.m...@gmail.com
wrote:
https://github.com/MichaelBlume/eval-speed
eval-speed.core= (time-fn read-to-maps)
Elapsed time: 5551.011069 msecs
nil
eval-speed.core= (time-fn read-to-maps-fn)
Elapsed time: 5587.256991 msecs
nil
eval-speed.core= (time-fn read-to-maps-partial)
Elapsed time: 5606.649172 msecs
nil
eval-speed.core= (time-fn read-to-maps-eval)
Elapsed time: 2627.521592 msecs
nil
Ben, I'd still like to understand exactly what work the CPU is doing in the
uneval'd version that it's skipping in the eval'd version. It seems like in
the generated bytecode there's going to be *some* concept of iterating
through the row in either case, if only as part of the destructuring
process.
On Friday, October 10, 2014 1:07:08 PM UTC-7, Ben wrote:
I believe it's because the `mapper` function is just creating and
returning a map literal. The mapper function in the evaled version is
something like this:
user (def names '[n1 n2 n3 n4])
#'user/names
user (def headers '[h1 h2 h3 h4])
#'user/headers
user `(fn [[~@names]] ~(zipmap headers names))
(clojure.core/fn [[n1 n2 n3 n4]] {h4 n4, h3 n3, h2 n2, h1 n1}) ;; just a
map literal, whose keys are already known.
Whereas in the first version, zipmap has to be called, iterating over
headers and names each time.
On Fri, Oct 10, 2014 at 1:04 PM, Sean Corfield se...@corfield.org
javascript: wrote:
It may be more to do with the difference between `for` and `map`. How do
these versions compare in your benchmark:
(defn read-to-maps-partial [rows]
(let [headers (-
rows
first
(take-while (complement #{}))
(map keyword))]
(map (partial zipmap headers) (rest rows
(defn read-to-maps-fn [rows]
(let [headers (-
rows
first
(take-while (complement #{}))
(map keyword))
mapper (fn [row] (zipmap headers row))]
(map mapper (rest rows
Sean
On Oct 10, 2014, at 11:42 AM, Michael Blume blume...@gmail.com
javascript: wrote:
So I'm reading a bunch of rows from a huge csv file and marshalling
those rows into maps using the first row as keys. I wrote the function two
ways: https://gist.github.com/MichaelBlume/c67d22df0ff9c225d956 and the
version with eval is twice as fast and I'm kind of curious about why.
Presumably the eval'd function still implicitly contains a list of keys,
it's still implicitly treating each row as a seq and walking it, so I'm
wondering what the seq-destructuring and the map literal are doing under
the hood that's faster.
--
Ben Wolfson
Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure.
[Larousse, Drink entry]
--
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: Variadic argument function call to another v.a.f.
That makes plenty of sense, you passed 1 argument to va1, and it was a list (from args). If you wish to unwrap that list, use apply: (apply va1 '(1 2 3)) On Sun, Oct 5, 2014 at 12:01 PM, Mate Varga m...@matevarga.net wrote: Hi, there's a closed old bug on the CLJS JIRA from 2012: http://dev.clojure.org/jira/browse/CLJS-383 Empty variadic argument initialised with (nil) when using arity overloading http://dev.clojure.org/jira/browse/CLJS-383 I am experiencing completely similar behavior in the latest CLJ 1.6: (defn va1 [ args] args) = (var syn-ws.core/va1) (defn va2 [ args] (va1 args)) = (var syn-ws.core/va2) (va2 1 2 3) = ((1 2 3)) (va2) = (nil) I.e. variadic arguments are passed as lists, and when they're passed to another function with variadic arguments then the list is wrapped in another list. It this the correct behavior? Thanks, Mate -- 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: Profiling in Counterclockwise
The profiling and logging tool might be Java specific. On Sun, Oct 5, 2014 at 2:38 PM, Fluid Dynamics a2093...@trbvm.com wrote: On Sunday, October 5, 2014 3:57:37 PM UTC-4, Gary Verhaegen wrote: When I need to profile (which is asmittedly quite rare), I use VisualVM, which should have been installed along with the JDK. I'd recommend editing the default settings to remove clojure.** and add your own namespaces as starting points for the profiling. For more lightweight approaches, I'd suggest checking out Timbre and Criterium, though I have very little experience with both. None of this is Eclipse specific or runs in Eclipse. So, what you're saying is that I'd have to 1) Package everything up 2) Deploy to somewhere 3) Learn how to use insert new, complicated tool here that requires classpath configuration and stuff 4) Identify hot spots 5) Make improvement of some sort 6) Back to step 1? Because that seems to *completely eliminate* the benefit of having a REPL and fast development/try things/edit cycle. :( Meanwhile, why did I get google results for a supposed Profiling and Logging perspective in Eclipse if no such thing exists? -- 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: [ANN] Monroe 0.1.0 - nrepl client for Emacs
The transition to cider was tough for some, I remember it being broken for me for a version or two. Perhaps they added that for the transition? On Fri, Oct 3, 2014 at 6:40 AM, Daniel Szmulewicz daniel.szmulew...@gmail.com wrote: You're right. I got confused because in ob-clojure.el, both cider and nrepl.el are considered back-ends, so I thought they were separate things. So in fact, nrepl.el is just an old incarnation of Cider? Ob-clojure.el needs a fixing, I believe. Oops, I meant nrepl.el: https://github.com/technomancy/nrepl.el/blob/master/nrepl.el On Friday, October 3, 2014 3:34:26 PM UTC+3, Bozhidar Batsov wrote: On October 3, 2014 at 3:06:08 PM, Daniel Szmulewicz (daniel.s...@gmail.com javascript:) wrote: Hi Sanel and thanks for Monroe. I think the use case is clear: lightweight alternative to Cider. So the question is what is the use case pertaining to nrepl.el, which is also lightweight. This question is a bit confusing as nrepl.el is cider’s old name. You can't really compare something with itself, but you can compare an old version of a project with its current version. On Wednesday, September 24, 2014 7:50:52 PM UTC+3, Sanel Zukan wrote: Hi everyone, Here https://github.com/sanel/monroe is initial release for Monroe, a new Clojure nREPL client for Emacs. The main idea behind Monroe is to be simple, easy to install (just put it in your *load-path*) and to work like inferior modes (inferior-lisp or inferior-scheme), providing common keybindings in REPL, including color and history support. You will also need clojure-mode.el for code syntax highlighting, but this is optional. This initial release is ready for consumption (I'm using it on a bit larger project) and feel free to drop me a line if you find some issues. Again, the url is https://github.com/sanel/monroe Best, Sanel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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: What is the best setup to program Clojurescript IF...
If I recall vim has good tools. On Thu, Oct 2, 2014 at 1:13 PM, Peter Mancini pe...@cicayda.com wrote: What is the best setup to program Clojurescript IF: - you hate EMACS - use linux or windows Any suggestions? -- 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: Acceptance testing with Clojure
Possibly, I don't know off the top of my head though. On Mon, Sep 29, 2014 at 2:13 AM, Adrian Mowat adrian.mo...@gmail.com wrote: Thanks for pointing out prism - it's just what I needed. Is there any way to add colours to the output so I can easily see if a test failed? On Sunday, 28 September 2014 15:34:39 UTC+1, Ashton Kemerling wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can answer this in two ways: 1. Acceptance testing Clojure code. 2. Acceptance testing other code with Clojure. I have significantly more experience with the latter than the former. All in all, I prefer the built in clojure.test library over more opinionated libraries like Midje. In particular I recommend adding in Aphyr's excellent Prism plugin to your profiles.clj to do auto testing, and pjstadig`s similarly excellent humane-test-output for readability. My dislike of midje stems from how awkward I found it to share setup code between tests. I feel that clojure.test nests more, allowing me to save more code up front. I also haven't used Midje in a while, so Brian might've upgraded it without me noticing. You also cannot go wrong with test.check. I really enjoy using it for both correctness and simple profiling (e.g. print to console and see if anything gets too slow). On the latter front, test.check + JDBC/Selenium/HTTP appears to be one of the most fruitful ways of hunting down bugs in single-page applications that I've ever seen. I think at this point the bug count for our testing code is close to 5 for an average of 3 hours per bug. Most of these bugs were either concurrency, caching, or SQL based, and some were close to 4 years old. I'll be giving a talk on this subject at the Conj this year, and the video will be posted later if you aren't attending. For more info on test.check, you should check out Reid Draper's Cognicast episode ( http://thinkrelevance.com/blog/2013/11/11/reid-draper-cognicast-episode-045) and my Cognicast episode (http://blog.cognitect.com/cognicast/ashton-kemerling-064) On 09/28/2014 08:24 AM, Ruslan Prokopchuk wrote: I've googled around a little bit, but didn't found any relevant info about subject. Please, share your experience about acceptance testing with Clojure! - -- Ashton -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUKBxtAAoJEIkUqIW02x05kBMQALUcIDvGO+ohCVUJw2xC2HMT UPBK3eFHVhrgp84EqFx00A/+/sFmXM6wKWzcbTuEeG4YEuiea2UiZjqs7bFvqg3w L2j3CwGpG+eENSP4CQ4L2qB0n4ljuWSqHgH1eWYIGC98f6hKfMC2Itb7SEKWdm1M iYTQdFKhULbsmahwL1Z+dKuxe9Q6Vv20HahQan5T7JY8jE8QJI5d/icXI8xel6OV 3wlsW1AfBec1d7r/67R0MRnWqD2swE3WFbh+SlNQz/orSNvHvOLufhS5s0Xamtji xo59pX7xrAMkyf/a40HopHTcWD1Qkp9T0VBO0X43dfdbTH5gMdc7iOFmpHXj5EAi wbRRAtXp75F6tdYHf4n6I9y+N2auRz1SF1KOPb69mjkjx8Pujy8EwZdfpwABqLtu 4D06KlRrVmCiduvc0eVBcUVOa0o2lait2y0cMLa1M2Tt3rwNZb23nrJ3T9xXhrIY GKW/N+uQ2uC028Wqh3oFcOrjN6S6XU6rahhojCSSXsfMddmzsgz6qPdy3voAa68j e4Z/aP5Q9fPViW3j/E9FGmrQU89eOUdPVabbrJNu2J3DqGu3eaRLpAJP9oa5v7Q+ iEOGU38ZbLwMXhvw8VvMOnF9MKn9JAsoDZOPFOfuftZWmP1q0HqmBxxxg4WBW3hC 2EldloS4hNyaSJ4tIlex =djIk -END PGP SIGNATURE- -- 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: Acceptance testing with Clojure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can answer this in two ways: 1. Acceptance testing Clojure code. 2. Acceptance testing other code with Clojure. I have significantly more experience with the latter than the former. All in all, I prefer the built in clojure.test library over more opinionated libraries like Midje. In particular I recommend adding in Aphyr's excellent Prism plugin to your profiles.clj to do auto testing, and pjstadig`s similarly excellent humane-test-output for readability. My dislike of midje stems from how awkward I found it to share setup code between tests. I feel that clojure.test nests more, allowing me to save more code up front. I also haven't used Midje in a while, so Brian might've upgraded it without me noticing. You also cannot go wrong with test.check. I really enjoy using it for both correctness and simple profiling (e.g. print to console and see if anything gets too slow). On the latter front, test.check + JDBC/Selenium/HTTP appears to be one of the most fruitful ways of hunting down bugs in single-page applications that I've ever seen. I think at this point the bug count for our testing code is close to 5 for an average of 3 hours per bug. Most of these bugs were either concurrency, caching, or SQL based, and some were close to 4 years old. I'll be giving a talk on this subject at the Conj this year, and the video will be posted later if you aren't attending. For more info on test.check, you should check out Reid Draper's Cognicast episode (http://thinkrelevance.com/blog/2013/11/11/reid-draper-cognicast-episode-045) and my Cognicast episode (http://blog.cognitect.com/cognicast/ashton-kemerling-064) On 09/28/2014 08:24 AM, Ruslan Prokopchuk wrote: I've googled around a little bit, but didn't found any relevant info about subject. Please, share your experience about acceptance testing with Clojure! - -- Ashton -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUKBxtAAoJEIkUqIW02x05kBMQALUcIDvGO+ohCVUJw2xC2HMT UPBK3eFHVhrgp84EqFx00A/+/sFmXM6wKWzcbTuEeG4YEuiea2UiZjqs7bFvqg3w L2j3CwGpG+eENSP4CQ4L2qB0n4ljuWSqHgH1eWYIGC98f6hKfMC2Itb7SEKWdm1M iYTQdFKhULbsmahwL1Z+dKuxe9Q6Vv20HahQan5T7JY8jE8QJI5d/icXI8xel6OV 3wlsW1AfBec1d7r/67R0MRnWqD2swE3WFbh+SlNQz/orSNvHvOLufhS5s0Xamtji xo59pX7xrAMkyf/a40HopHTcWD1Qkp9T0VBO0X43dfdbTH5gMdc7iOFmpHXj5EAi wbRRAtXp75F6tdYHf4n6I9y+N2auRz1SF1KOPb69mjkjx8Pujy8EwZdfpwABqLtu 4D06KlRrVmCiduvc0eVBcUVOa0o2lait2y0cMLa1M2Tt3rwNZb23nrJ3T9xXhrIY GKW/N+uQ2uC028Wqh3oFcOrjN6S6XU6rahhojCSSXsfMddmzsgz6qPdy3voAa68j e4Z/aP5Q9fPViW3j/E9FGmrQU89eOUdPVabbrJNu2J3DqGu3eaRLpAJP9oa5v7Q+ iEOGU38ZbLwMXhvw8VvMOnF9MKn9JAsoDZOPFOfuftZWmP1q0HqmBxxxg4WBW3hC 2EldloS4hNyaSJ4tIlex =djIk -END PGP SIGNATURE- -- 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: How to read a transit string from client side (transit-cljs) on server side (tansit-clj)
I think you should take a look at the transit-Clj README, it has docs and
examples.
https://github.com/cognitect/transit-clj/blob/master/README.md
On Thu, Sep 25, 2014 at 6:56 AM, Bin Li leebin1...@gmail.com wrote:
Hi Guys,
I was playing around the transit library recently , that is what I did:
On client side , which using tansit-cljs (*clojrescript*) :
(def w (t/writer :json))
(.send xhr
url
POST
(transit/write w *{:test :test-value}*)
#js {Content-Type application/transit+json})
And from server side , using *clojure *:
I got the string like: *[^ ,~:test,~:test-value]*
The question is how can I read this transit'ed string back to a map ?
Thanks in advance!
--
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: [ANN] lein-shorthand - a leiningen plugin to create namespaces with short names for use in the REPL
That's super helpful, thank you!
On Wed, Sep 24, 2014 at 6:17 AM, Hugo Duncan h...@hugoduncan.org wrote:
In the REPL, there are functions that you always want to have handy, no
matter which namespace you are in. One way of achieving this is to put
these functions into a namespace with a short name, like `.`, so you can
refer to them easily. The original idea came from Gary Fredericks, who
also wrote dot-slash[1], which I discovered after writing this.
The `lein-shorthand` plugin[2] lets you declare such a namespace in your
leiningen profiles.
e.g.
{:user
{:dependencies [[alembic 0.3.2]]
:plugins [[com.palletops/lein-shorthand 0.4.0]]
:shorthand {. [alembic.still/distill alembic.still/lein]}}}
This would allow you to use `(./lein deps :tree)` to run the lein deps
task from any namespace, using alembic[3].
See the README for full details, including how to make the shorthand
functions load the required namespaces lazily, on first use.
Hugo
[1] https://github.com/gfredericks/dot-slash
[2] https://github.com/palletops/lein-shorthand
[3] https://github.com/pallet/alembic
--
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] www.core-async.info: a new web resource for core.async
That looks really nice! My only feedback is that it doesn't load at all on my iPhone. On Thu, Sep 18, 2014 at 1:01 PM, Daniel Solano Gómez cloj...@sattvik.com wrote: Hello, all, Over the past few months I have been working on creating some resources to help people learn to use core.async. My goal is make this the best resource available to help people get started with core.async and to document best practices for composing applications with core.async. It is still a work in progress, but it currently includes the following: 1. An introduction to channels, buffers, and basic channel operations 2. A tutorial/workshop that introduces core.async using both Clojure and ClojureScript 3. A reference section of the core.async API, including both the Clojure and ClojureScript sources Please check it out at www.core-async.info. I will continue to add more reference and tutorial material in the future. Please let me know if there is anything you would think would be useful to add. 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/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: it's possible to query for optional parts on many relations?
Couldn't you just retrieve users and use entity to get their photos? On Thu, Sep 18, 2014 at 4:43 PM, Wilker wilkerlu...@gmail.com wrote: Forgot to mention, I tried the (get-else) but it raises an error about cardinality many not supported, so I guessed it doesn't works here... --- Wilker Lúcio http://about.me/wilkerlucio/bio Woboinc Consultant +55 81 82556600 On Thu, Sep 18, 2014 at 7:41 PM, Wilker wilkerlu...@gmail.com wrote: Hi I'm trying to figure if I can make some parts of my query results to be optional, for example, given the following query: [:find ?name ?age :where [?m :person/name ?name] [?m :person/age ?age]] This will return all entities that has a :person/name and :person/age. Ok, so, if I want to make the name mandatory and the age optional, I can do: [:find ?name ?age :in $ :where [?m :person/name ?name] [(get-else $ ?m :person/age 0) ?age]] Ok, so, for single values that works great, but what about this: [:find ?m ?name (vec ?url) :in $ :where [?m :person/name ?name] [?m :photos ?p] [?p :file/url ?url]] On the previous query, it fetch every person that has at least 1 photo, but not those that has no photos. How do I make to the query to return all entities that has name, having photos or not (ideally the value would be a blank list for those without photos)? Best regards. --- Wilker Lúcio http://about.me/wilkerlucio/bio Woboinc Consultant +55 81 82556600 -- 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.
Assigning Values in Core.Logic
I can't tell if I'm being silly, but I'm having issues figuring out how to
record the results of my computation in Core.Logic.
The basic idea is that I'm trying to determine if a schedule a user has
requested is solvable or not. I'm trying to find out how to assign to each
hash-map what resource I determined can be used for it. The following case
is simplistic, but I need to get this code working before attempting to
generalize what the user has requested.
(defn solve [types reservations]
(let [reservations (map #(assoc % :assigned-resource (l/lvar))
reservations)
resources (flatten (map :resources types))
vars (repeatedly (count reservations) l/lvar)
resource-vars (take (count by-resource) vars)
]
(l/run 1 [q]
(l/== q vars)
;;
(l/everyg #(l/membero % reservations) resource-vars)
(l/everyg #(l/fresh [resource]
(l/membero resource resources)
(l/== % (l/partial-map {:resource resource}))
;; Somehow assign resource to
:assigned-resource here.
)
resource-vars)
(l/distincto resource-vars)
)))
--
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: Assigning Values in Core.Logic
Aha, I believe the is method has solved my dilemma.
--
Ashton Kemerling
On Thu, Sep 18, 2014 at 7:56 PM, Ashton Kemerling ashtonkemerl...@gmail.com
wrote:
I can't tell if I'm being silly, but I'm having issues figuring out how to
record the results of my computation in Core.Logic.
The basic idea is that I'm trying to determine if a schedule a user has
requested is solvable or not. I'm trying to find out how to assign to each
hash-map what resource I determined can be used for it. The following case
is simplistic, but I need to get this code working before attempting to
generalize what the user has requested.
(defn solve [types reservations]
(let [reservations (map #(assoc % :assigned-resource (l/lvar))
reservations)
resources (flatten (map :resources types))
vars (repeatedly (count reservations) l/lvar)
resource-vars (take (count by-resource) vars)
]
(l/run 1 [q]
(l/== q vars)
;;
(l/everyg #(l/membero % reservations) resource-vars)
(l/everyg #(l/fresh [resource]
(l/membero resource resources)
(l/== % (l/partial-map {:resource
resource}))
;; Somehow assign resource to
:assigned-resource here.
)
resource-vars)
(l/distincto resource-vars)
)))
--
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 ( 2) returns true
I wouldn't be surprised if the 1 arg form is to help people who use along with apply, just in case the list is only 1 element long. On Wed, Sep 17, 2014 at 7:40 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: Herwig Hochleitner hhochleit...@gmail.com writes: 2014-09-17 11:51 GMT+02:00 Phillip Lord phillip.l...@newcastle.ac.uk: So, why not special case 1 arg as well, and have that except? It's a reasonable question. I would submit a bug report and see if anyone else agrees. Something is wrong for sure. Either ( x) should throw arity, or () should return true, or the docstring should be changed to note the special case for (). Totally agree, please post ticket number, so that we can favorite! http://dev.clojure.org/jira/browse/CLJ-1526 -- 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: ECHELON: Wrangling messy political data
That's really neat. Planning on giving a talk? On Tue, Sep 16, 2014 at 12:08 PM, kovas boguta kovas.bog...@gmail.com wrote: Thats very cool!! On Tue, Sep 16, 2014 at 1:48 PM, Zack Maril thewitzb...@gmail.com wrote: This might be of interest to the Clojure/Datomic community: http://sunlightfoundation.com/blog/2014/09/16/wrangling-messy-political-data-into-usable-information/ https://github.com/sunlightlabs/echelon I'm part of the Influence Explorer team at the Sunlight Foundation. We're building a system with Datomic and Instaparse to disentangle and analyze the web of relationships between lobbyists, special interest groups, and legislators. It's been surprisingly successful so far, as in it works as well as we hoped it would when we first started building it. Datomic has been a pleasure to use and Instaparse has been excellent so far. The above link is a results oriented blog post about what we did and why we did it. We haven't written up the technical details yet as they are still evolving (we're attempting to move from the current static batch processing system to hopefully a streaming approach in the near future). But, if you have any questions about the project I'd be happy to answer them. -Zack -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha2
Perhaps me means dangerous as in it shouldn't be done causually, and that it could become a problematic habit if formed. On Wed, Sep 10, 2014 at 8:55 PM, Brent Millare brent.mill...@gmail.com wrote: I understand usage of volatiles are dangerous via vswap! but what about creation? Again relating to what you said, 'I asked Rich and he said making a volatile is as dangerous as any ! op.' On Wednesday, September 10, 2014 10:19:33 AM UTC-4, Alex Miller wrote: Usually that's called visibility. Atoms are *not* subject to race conditions if swap! is called from multiple threads (the state of the atom will not change while the update function is being applied). The atom is thus safe to be used from multiple threads. Volatiles *are* subject to race conditions with vswap! is called from multiple threads (the state of the volatile may change while the update function is being applied). The volatile is thus dangerous and safety is derived from how it's used. On Wednesday, September 10, 2014 8:44:27 AM UTC-5, Brent Millare wrote: When I say synchronization, I specifically mean writes are guaranteed to be seen by subsequent reads on any thread* *as Alex said. On Wednesday, September 10, 2014 9:37:09 AM UTC-4, Brent Millare wrote: So to summarize, Clojure's volatile provides synchronization across threads but does not provide atomaticity with vswap!. So, as a follow up question, then why would the creation of a volatile be dangerous but creating an atom isn't? (Hence the exclamation point in the name volatile!) -- 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: core.async take behaviour
IIRC they are coming out in clojure 1.7. I don't see any indication of when it will be declared as stable, but there are alpha builds available if you need them. -- Ashton On Thu, Sep 4, 2014 at 1:29 AM, cig clifford.goldb...@gmail.com wrote: Thanks Alex. Feel silly not to have noticed the partition function. When will transduces be available to use? On Wednesday, 3 September 2014 22:48:20 UTC+2, Alex Miller wrote: I think that's just a partition transducer on the channel? On Wednesday, September 3, 2014 2:24:28 AM UTC-5, Gary Verhaegen wrote: I'd use another channel on which I put vectors of the correct length, with an intermediate loop that takes from the first channel, accumulates until the vector has the right size, and then put the vector on the second channel. There might be a better solution with transducers, though. (Or without.) On Wednesday, 3 September 2014, cig clifford...@gmail.com wrote: Thanks Timothy, that makes sense. A follow on question if you don't mind. I would like to 'take' n items off of a channel, but wait until n items are available rather than eagerly returning the way take does. Do you have any ideas on how I could achieve this? On Tuesday, 2 September 2014 22:23:10 UTC+2, tbc++ wrote: It's because into is pulling items as fast as it can from take. Sure the buffer might get full but then into takes another value allowing take to continue. Timothy On Tue, Sep 2, 2014 at 1:48 PM, cig clifford...@gmail.com wrote: Hi I was expecting the following example to park, waiting for the 'out' channel to be cleared. Could anybody explain why 'take' does not park when the output buffer size is smaller than the number of entries being taken from the input channel? (def from (to-chan [1 2 3 4 5 6 7])) (!! (into [] (take 4 from *2*))) ;; note: the output channel buffer size is 2 (less than 4 items being taken off of the 'from' channel) ;; = [1 2 3 4] -- 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. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: StackOverflow TV Opportunity to Promote Clojure
I tried to email t...@stackoverflow.com and got delivery failure messages. On Wed, Sep 3, 2014 at 1:55 PM, A. Webb a.webb@gmail.com wrote: StackOverflow just announced an experimental project to produce videos in its New York City office. This could be a great opportunity to polish up one of your presentations and promote Clojure to a wide audience. No speaker fees, but reasonable travel costs covered. Post: http://meta.stackoverflow.com/q/270574/1756702 Email: t...@stackoverflow.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to 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: GSoC: Congratulations Aleksandr and Prasant!
Very Nice! I'd be particularly interested to see some benchmarks to show off the improvements. -- Ashton Kemerling On Mon, Aug 25, 2014 at 12:57 PM, Mars0i marsh...@logical.net wrote: Thank you! to Prasant and Aleksandr. -- 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: Resolve function or object by name in ClojureScript
To be fair, calling from outside of Clojurescript is probably the only use-case for this behavior that I can imagine, which is exactly what ^:export was designed (and named) for. -- Ashton Kemerling On Mon, Aug 25, 2014 at 12:18 PM, Thomas Heller th.hel...@gmail.com wrote: It is possible, the question is WHEN? You can make a function callable by name if you export it. (ns myns) (def ^:export testfn [] :foo) can be called like so, must be careful with name munging though: (let [the-fn (aget js/window myns testfn)] (the-fn)) which also works with advanced compilation. I wouldn't recommend exporting all functions, but I do it for functions I want to use from HTML/JS. HTH, /thomas On Monday, August 25, 2014 6:09:29 PM UTC+2, David Nolen wrote: Any such facility is at odds with Google Closure Compiler's advanced compilation. David On Mon, Aug 25, 2014 at 11:59 AM, Timur timur...@gmail.com wrote: Hi everybody, Is there a way to resolve a function or object using its string name in ClojureScript? I found this however it is old: http://stackoverflow.com/questions/12020576/resolve- function-throws-an-error-in-clojurescript-but-not-clojure/ 12020663#12020663 Thanks in advance. -- 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: CLISP books any good to learn Clojure
Just remember that Clisp 1) not entirely immutable 2) not a hosted language I worked in CL professionally for a year (SBCL in particular) and while clojure is closer to SBCL than it is to python, it is a different beast. CL is a more complicated language, with a long past and odd specs containing holdovers from decades gone by, and CL has pretty much absorbed every paradigm that has come out since it's inception. So I would recommend staying away from sections covering the Common Lisp object system (clos) or the meta object protocol (mop), as they have no real parallels in clojure. On Sun, Aug 24, 2014 at 4:49 AM, Cecil Westerhof cldwester...@gmail.com wrote: There are a lot of good (or so I am told) CLISP books. For example: “Paradigms Of Artificial Intelligence Programming Case Studies In Common Lisp”. Would they be useful for learning Clojure, or is the difference to big? I should at least have http://clojure.org/lisps handy. ;-) -- 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: How is this code evaluated (question about transdurcers)
If you are referring to the new transducer comp, if I recall correctly it works
in the opposite direction from the comp in clojure.core. I can't find any docs
at hand that prove that, so I would check the docstring of comp.
On Sun, Aug 24, 2014 at 11:04 AM, rogergl ro...@gilliar.de wrote:
I have problems to understand how the following code evaluates. I
understand what the code does but not how this result is computed:
BTW: This is an example from the async webinar:
(chan 1 (comp (map #(.-keyCode %))
(filter #{37 39})
(map {37 :previous 39 :next})
For example: comp evaluates from right to left. But this code looks more
like it is evaluated from left to right ?
Regards
Roger
--
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: Presentation about Clojure
Whenever I try and sell Clojure, I sell four things: 1. JVM based deploy and performance. 2. A complete state model for safe and easy concurrency 3. Macros to eliminate boilerplate and add features otherwise impossible 4. An ecosystem of decoupled libraries that take a no magic approach, meaning fewer nasty surprises at update time. Beyond that I would point out how leiningen just works, and do some examples. -- Ashton Kemerling On Thu, Aug 21, 2014 at 6:32 AM, Serzh Nechyporchuk nechyporc...@gmail.com wrote: Good idea, I am always a more technical person, but your way will be more productive. It is a two day event. I could ask if it would be possible to give it on the first day and have the option to give a hands-on the second day if there is interest for that. I also had a second talk too. In it I show production examples of using clojure and repl-driven development. So it will be very nice if you have time for a second talk too. You are welcome :) Четвер, 21 серпня 2014 р. 14:56:00 UTC+3 користувач Cecil Westerhof написав: 2014-08-21 13:43 GMT+02:00 Serzh Nechyporchuk nechyp...@gmail.com: You can use this presentation as your own :) I probably will change some things (but reading the rest of your email less as I expected), but will certainly at least mention it is inspired on your presentation. Credit where credit is due. I want to show the REPL (I find that a very big plus) and maybe something about the ease to develop for the Android. I have not tried it yet, but as I was told it is a breeze. If that is true, it is certainly something to mention. The auditory I was talked to consists of: - several java - one clojure :) - rest python developers. In this presentation I intentionally don't focus on syntax and other getting started features. I think that this is less important and it is really easy to get in. The goal of this talk was not to teach write hello world programs. What I really focused on in this talk is power that clojure gives you. Good idea, I am always a more technical person, but your way will be more productive. It is a two day event. I could ask if it would be possible to give it on the first day and have the option to give a hands-on the second day if there is interest for that. The presentation took about 45 minutes. But with questions it took about one hour. Should be doable then. Thanks again. I am flabbergasted how useful this newsgroup is. :-D 2014-08-21 14:26 GMT+03:00 Cecil Westerhof cldwes...@gmail.com: 2014-08-21 12:49 GMT+02:00 Serzh Nechyporchuk nechyp...@gmail.com: In most programming languages cool features are provided as core functionality and you can't extend it manually. But in lisp you can do it just as library. For example: - Go channels - core.async - logic programming - core.logic Link to presentation https://docs.google.com/presentation/d/ 1ewQYugwi9mBdogWMLGQM74uadrI-jw4Kf3Tasxve_bs/edit?usp=sharing Thank you very much. You have almost done all the work for me. ;-) I suppose that the people you gave this presentation to already knew something? How much time did your presentation take? 2014-08-21 13:39 GMT+03:00 Cecil Westerhof cldwes...@gmail.com: 2014-08-21 12:33 GMT+02:00 Serzh Nechyporchuk nechyp...@gmail.com: I can give you my presentation about Clojure. I have several questions: - (classic) parenthesis - How do you model your domain without objects? - About dsl. If clojure is good for dsl, does it mean that when you get new librarty with its own dsl, you have to learn new language? - How does new people adopts in your command? - What is production use of Clojure? That's all I remember. Thanks: that is very useful. -- 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
Re: Is Clojure a language for growth?
I personally snuck it into my company in a limited fashion by selling its libraries, test.check in particular. This has gone quite well. On Wed, Aug 20, 2014 at 1:28 PM, Quzanti quza...@googlemail.com wrote: Whenever there is an external institutional stakeholder it is almost guaranteed to happen. Someone in that external institution has a bonus or promotion depending on the outcome, and will demand results. They will also have penalty clauses in the contract which can be anything from non-payment, to seizing control of a start up, or even shutting it down. I have seen it happen myself in England and Germany, and there are plenty of well documented cases from the States so I don't think it is culturally dependent in the sense of national culture. If you live in a blame free society let us know where as it would be an excellent place for a start up! On Wednesday, August 20, 2014 7:16:55 PM UTC+1, Henrik Eneroth wrote: … as soon as anything goes wrong whether it has anything to do with the technology choice or not you become mr fall guy, to be blamed and fired so that other people can keep their jobs. Seen it happen so many times. Good lord, truly? Perhaps this is a good time to ask what culture OP lives in. This wouldn't happen where I live/work. -- 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: [ANN] lein-plz 0.1.1 - Add dependencies quickly
Ahh, I just had a coworker who is used to NPM complain about leiningen not
having this, thank you!
--
Ashton
On Saturday, August 16, 2014 6:19:42 PM UTC-6, john walker wrote:
Hello everyone.
This is a lein plugin that helps you add dependencies to projects pretty
quickly. The git repo is here: https://github.com/johnwalker/lein-plz
Basically, you write something like this:
lein new foo
cd foo
lein plz add cljs async match jdbc
and get this:
(defproject foo 0.1.0-SNAPSHOT
:description FIXME: write description
:url http://example.com/FIXME;
:license {:name Eclipse Public License
:url http://www.eclipse.org/legal/epl-v10.html}
:dependencies [[org.clojure/clojure 1.6.0]
[org.clojure/clojurescript 0.0-2311]
[org.clojure/core.async 0.1.319.0-6b1aca-alpha]
[org.clojure/core.match 0.2.2]
[org.clojure/java.jdbc 0.3.5]])
I hope it's useful.
-- John
--
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: Transit Idea
I went ahead and wrote it. I'm sure there are some bugs to work out, but for now it works in the basic cases. The pullrequest for this feature can be located on Solr's github here: https://github.com/apache/lucene-solr/pull/85. -- Ashton On Wednesday, August 13, 2014 6:50:34 PM UTC-6, Alex Miller wrote: Sounds good to me. :) On Wednesday, August 13, 2014 1:59:54 PM UTC-4, Ashton Kemerling wrote: I realized that Solr currently provides a lot of language-specific serializer options. Currently Ruby, Python, PHP, and javabin(?) are options, along with the normal json and xml. Wouldn't it make a lot of sense for us to add a transit-json and transit-messagepack options to Solr? -- Ashton -- 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.
Transit Idea
I realized that Solr currently provides a lot of language-specific serializer options. Currently Ruby, Python, PHP, and javabin(?) are options, along with the normal json and xml. Wouldn't it make a lot of sense for us to add a transit-json and transit-messagepack options to Solr? -- Ashton -- 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.
