Re: Past and future of data.generators

I do agree that the name data.generators is not where to look for a controllable random source. A more specific name for these functions should be considered. The java.util.Random has been an issue for me in stress-testing random read and writes to a huge memory-area by several threads. If I was t

Re: Is it the right Clojure group for a newbie

There are also a few other lisp/scheme books (including the little schemer) that people have worked through and posted their Clojure code which you might find instructive. On 5 June 2014 05:10, Mars0i wrote: > > > On Tuesday, June 3, 2014 8:41:33 AM UTC-5, Gregg Reynolds wrote: >> >> I know you

Re: Are zippers the right choice for "sequence-like" trees?

Thanks Jason - that’s helpful. -- paul.butcher->msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher Skype: paulrabutcher Author of Seven Concurrency Models in Seven Weeks: When Thr

Re: Past and future of data.generators

One of the challenges with random number generation is that there are quite a few specialised requirements. I don't believe a generic approach can meet all needs. I think we actually need a few things: 1. Better implementation for clojure.core/rand etc. I think conditional usage of j.u.c.Thread

Re: What's clojure killer app? I don't see any.

found Atl-g in snap-shop -thankyou again -doug On Thursday, June 5, 2014 12:03:59 AM UTC-4, douglas smith wrote: > > Jony, Hey thanks > > Just finish watching and reading about Gorilla-Repl (will be digging > deeper) and WOW really clean and simple UI -Nice. > Much Much easier to install than I

Re: Past and future of data.generators

Hi, I have used http://maths.uncommons.org/ in a few of my projects, so that could be used in data.random. I have also played with the random.org API in the past as a source of random numbers. Thomas ps. in one of my use cases I also care about the performance of the random generator as I pot

Integrating clojurescript and clojure in one library

Hi, While working on the admin interface of friend-ui (https://groups.google.com/forum/#!searchin/clojure/friend-ui/clojure/QoJHPFXjDuc/IbBsHmOLNdIJ) I got the idea to add some cljs (om / kioo) to my library and then provide both, the compiled js and the compiled java code in one jar. Now, it

Re: Eval-ing a map expression in Emacs Live doesn't seem to work

On 05/06/2014 00:57, J Irving wrote: Your cursor was probably on the closing paren at the end - you eval'd the previous expression, which was the vector. Check out the key bindings here: https://github.com/clojure-emacs/cider#cider-mode If your cursor is anywhere on that expression, you probab

Re: Effective Clojure book?

On Jun 4, 2014, at 6:30 PM, Mike Fikes wrote: > Are there any books yet that prescribe best practices for Clojure, à la > Meyers or Bloch? Not a book, but there is the Clojure Style Guide at https://github.com/bbatsov/clojure-style-guide -- Charlie Griefer http://charlie.griefer.com "Give l

[ANN] Avi 0.1.4

This is the "it lives!" version. It's still not pleasant to use, but you can use it to code! Since last we met: i,o,O,a,A,:w,:wq,:q! avi A lively vi. Vision We love vim. We want more! Test coverage. Flexibilty. Live REPLs!

Re: non-lazy clojure?

A followup on these issues, after experimenting a bit with reducers, just for anyone who may be interested: - Naive use of reducers in place of seq functions, throughout my program, got messy and led to some new problems with memory management, I think (or at least to jerkier execution over ti

Re: non-lazy clojure?

Oops -- something was wrong with my benchmarks, and my "improvements on the order of 1/3" was wrong. I still see improvements with r/fold as compared to my agent-based approach, but the difference now appears to be only something like 1/20. -Lee On Jun 5, 2014, at 7:19 PM, Lee Spector wrote

arguments passed to a macro

Is there a trick for "pre-expanding" some of the arguments passed to a macro? Say you wanted to do this code: (def swing-imports '(javax.swing JFrame JButton ImageIcon JPanel)) (ns example.myprogram (:import swing-imports)) ... ns will complain that it can't find the "swing

Re: [ANN] core.async (and more) video tutorials

Thanks for doing these Tim! Very good stuff. Would like to echo the above results for code. Can you put what you're working from on github for all the videos? I found myself wanting to use some of your pipeline stuff today and I'd rather not watch 20 minutes of video again to type it out -

Re: [ANN] core.async (and more) video tutorials

> > Thanks for doing these Tim! Very good stuff. > > Would like to echo the above requests for source code. Can you put what > you're working from on github for all the videos? I found myself wanting to > use some of your pipeline stuff today and I'd rather not watch 20 minutes > of video again

Re: non-lazy clojure?

Fair enough. Fortunately, Clojure provides so many different tools to select from in creating you perfect recipe. ;-) I'm glad to hear that reducers ultimately provided you with some benefits over your previous concurrency approach. The one thing that seems rather odd to me though is that your g

Re: arguments passed to a macro

Well, the easiest option is to just use the import function: (ns example.myprogram) (import swing-imports) There is a reader macro, #=, that might work, but I wouldn't recommend it: (ns example.myprogram (:import #=swing-imports)) - James On 6 June 2014 01:12, Christopher Howard wrote: >

Re: [ANN] core.async (and more) video tutorials

Code is here: https://github.com/halgari/clojure-tutorial-source I'll try to get a forum setup soon, or at least some sort of mailing list Timothy Baldridge On Thu, Jun 5, 2014 at 6:15 PM, Dylan Butman wrote: > Thanks for doing these Tim! Very good stuff. >> >> Would like to echo the above r

Re: non-lazy clojure?

On Jun 5, 2014, at 8:51 PM, Gary Johnson wrote: > Fair enough. Fortunately, Clojure provides so many different tools to select > from in creating you perfect recipe. ;-) > > I'm glad to hear that reducers ultimately provided you with some benefits > over your previous concurrency approach. >