Re: Clojure performance question
On Mon, Mar 3, 2014 at 3:06 AM, Mikera mike.r.anderson...@gmail.com wrote: ISeq itself isn't too bad (it's just an interface, as above), but some of the implementations are a bit expensive. ISeq is inherently not suited for performance critical code, as next() requires creation of a new object. Even if JVM handles such ephermal instances quite well, it still cannot compete with simple iterations or mutable iterators. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clojure.test.check (previously, simple-check)
Nooo :-(. Now it gets behind the CA + Jira impenetrable wall. El jueves, 27 de febrero de 2014 11:22:44 UTC-6, Reid Draper escribió: I'm happy to announce the first release of the newest Clojure contrib library: test.check [1]. Previously named simple-check [1], test.check is a property-based testing library, based on QuickCheck. The README has a guide for migrating from simple-check, as well as some getting-started documentation. I'm happy to answer any questions here as well. Or, stop by my Clojure/West talk in March. [1] https://github.com/clojure/test.check [2] https://github.com/reiddraper/simple-check -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Google Summer of Code 2014 proposal
Hello everybody, I’m Matteo Ceccarello, a PhD student in Computer Engineering from university of Padova, Italy. Recently, I’ve started working with Clojure, a language that I find both powerful and fun. I’ve participated to GSoC 2013 and 2012 with JPF http://babelfish.arc.nasa.gov/trac/jpf/wiki. I’m interested in participating to GSoC 2014 with Clojure, in order to gain confidence with clojure under the guidance of a mentor while contributing to the community. I’ll describe what I’d like to do below. Motivation Currently, alongside my research on parallel graph algorithms, I’ve started writing a web crawler in Clojure. The reasons I want to do this in clojure are many: - The web crawling software we are using (Heritrix https://crawler.archive.org) performs blocking IO. I think that in big crawls this is a showstopper, since to achieve a good throughput one must use many Java threads (in the order of 500) that end up spending most of their time performing blocking waits. - Clojure has the wonderful core.async library, with all the magic that go blocks and channels bring. - The http-kit library makes possible to perform async requests to web servers in a very simple way. - Clojure has an awesome support for concurrency. What I want to achieve eventually is a concurrent asynchronous web crawler, without a single blocking call. Since I’m new to the language, before starting to get some real work done, I’ve worked on a few small projects, to get a feel of the language. What I learned is that everything you put in a ref or atom must be immutable. A fundamental component of a web crawler is a data structure that tells you if you have already visited a URL. Bloom filters are a common choice for the implementation of this component. Since this bloom filter will be put in a ref, I want it to be immutable and, for efficiency reasons, persistent. After some research on the web, I found out that an immutable persistent implementation of the bloom filter is still missing from the Clojure ecosystem. Since it seems that Clojure is missing a persistent implementation of many probabilistic data structures, I came up with the following idea. Persistent probabilistic data structures for Clojure Clojure seems to miss persistent implementations of many useful probabilistic data structures, in particular: - Bloom filters http://webhdd.ru/library/files/10.1.1.127.9672.pdf - Counting Bloom filtershttp://webhdd.ru/library/files/10.1.1.127.9672.pdf - Compact approximators http://arxiv.org/pdf/cs.DS/0306046.pdf - HyperLogLog countershttp://www.dmtcs.org/dmtcs-ojs/index.php/proceedings/article/viewPDFInterstitial/dmAH0110/2100 - Count-min sketcheshttp://twiki.di.uniroma1.it/pub/Ing_algo/WebHome/p14_Cormode_JAl_05.pdf Of course one can use one of the various implementations of these data structures for Java, however, being these implementations mutable, they cannot be used in idiomatic concurrent clojure code (as for my understanding of idiomatic concurrent clojure code). What I propose to realize is an optimized persistent implementation of these libraries. Hence I plan to explore different paths using benchmarks https://github.com/hugoduncan/criterium as a guide, for instance to decide whether it’s more convenient to use standard clojure vectors to represent bit vectors or to provide a custom persistent bit vector implementation. Since I like the feeling of having a static type checker that prevents common errors, the library will be annotated with Typed Clojure http://typedclojure.org/. Moreover I find interesting the idea of using tests as machine checkable documentation, and midje-doc http://docs.caudate.me/lein-midje-doc/ seems the right tool for the job. Is there someone interested in mentoring me with this project? Yours sincerely Matteo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure performance question
On Monday, 3 March 2014 18:24:48 UTC+8, Jozef Wagner wrote: On Mon, Mar 3, 2014 at 3:06 AM, Mikera mike.r.an...@gmail.comjavascript: wrote: ISeq itself isn't too bad (it's just an interface, as above), but some of the implementations are a bit expensive. ISeq is inherently not suited for performance critical code, as next() requires creation of a new object. Even if JVM handles such ephermal instances quite well, it still cannot compete with simple iterations or mutable iterators. That isn't true in general: cons cells for example already have the next object recorded so don't cause an allocation on next(). And lazy seqs only cause an allocation on the first invocation next(). Given this, ISeq is a perfectly decent way to traverse singly linked links, which is in turn a good data structure for many use cases. It's probably even optimal in many tree-like cases where a lot of structural sharing is possible. Obviously, there are cases where allocating a sequence will be slower than iterative techniques. But that's easy enough to fix by just using iterations in those cases use the right tool for the job and all that. Overall - I think ISeq is perfectly decent for what it does. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure performance question
On 3/2/14, 7:06 PM, Mikera wrote: Some perspectives (as someone who has been tuning this stuff a lot, from a core.matrix standpoint in particular) On Saturday, 1 March 2014 13:02:26 UTC+8, bob wrote: Hi, Can I ask a newbie question about clojure performance? What make clojure performance slow than java?, it seems clojure has the 1/4 performance compared to java in general, according to tests, some cases it might be 1/10. the reasons I can think out are - the byte code is not efficient sometimes - the byte code might not enjoy the jvm optimization Sometimes a problem, though Clojure is not too bad at bytecode generation and the JIT will do most of the obvious optimisations for you. - the reflection This is extremely bad for performance, but luckily it is easy to avoid: - Always use *warn-on-reflection* - Eliminate every single reflection warning with type hints - the immutable data structure This is often a performance *advantage*, especially when you start dealing with concurrency and data-driven snapshot. In the few cases where it is a problem, you can always drop back to using mutable Java data structures or arrays - so this isn't ever really an issue. - the abstract interface design This doesn't actually cost that much. Interfaces on the JVM are extremely fast and very well optimised. In many cases, JIT optimisations make them just as fast as a static method call. The abstract interface like seq offers its power, but it is easy to drop in the performance trap. ISeq itself isn't too bad (it's just an interface, as above), but some of the implementations are a bit expensive. Lazy seqs for example are not so fast... and often you don't need the laziness. However most clojure.core functions produce lazy seqs by default. I wrote an eager-map replacement for map in my clojure-utils library to get around this problem Is this any different than core's mapv fn? mapv uses transient vectors and reduce to eagerly map into a vector. -Ben -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure performance question
I was not trying to generalize. I think that ISeq is not the right tool in case where processing of large collection is a performance bottleneck. It is perfectly OK for other purposes though. Cons cell has its next object 'recorded', however this next object does not have to be Cons, in which case calling next on it will create a new object. LazySeq (a type) is just a delay with fancy interface, and it just emphasizes ISeq's perf issues. Moreover, the fact that you usually do not want to hold onto the head in a lazy seq (a virtual collection [1]) indicates that the caching of 'next' is not what you want when iterating over large data. The performance issues in ISeq led to the design of chunked seqs [2] and reducers, both of which try to eliminate this per-step allocation overhead [3]. An expensive collection crunching should not be based just on the ISeq abstraction. Best, Jozef [1] http://clojure.org/lazy [2] https://www.assembla.com/spaces/clojure/wiki/Chunked_Seqs [3] http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html On Mon, Mar 3, 2014 at 5:35 PM, Mikera mike.r.anderson...@gmail.com wrote: On Monday, 3 March 2014 18:24:48 UTC+8, Jozef Wagner wrote: On Mon, Mar 3, 2014 at 3:06 AM, Mikera mike.r.an...@gmail.com wrote: ISeq itself isn't too bad (it's just an interface, as above), but some of the implementations are a bit expensive. ISeq is inherently not suited for performance critical code, as next() requires creation of a new object. Even if JVM handles such ephermal instances quite well, it still cannot compete with simple iterations or mutable iterators. That isn't true in general: cons cells for example already have the next object recorded so don't cause an allocation on next(). And lazy seqs only cause an allocation on the first invocation next(). Given this, ISeq is a perfectly decent way to traverse singly linked links, which is in turn a good data structure for many use cases. It's probably even optimal in many tree-like cases where a lot of structural sharing is possible. Obviously, there are cases where allocating a sequence will be slower than iterative techniques. But that's easy enough to fix by just using iterations in those cases use the right tool for the job and all that. Overall - I think ISeq is perfectly decent for what it does. -- 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/groEven for linked lists, as they are swiftly transformed into something more sinister after few map/filter/reduce operations.up/clojure?hl=en http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] avi: A lively vi. 0.1.0
Hi! @Gaofeng, I've started working on Linux support and should have it finished soon. @Ambrose, will do soon. Thanks! On Sun, Mar 2, 2014 at 12:50 AM, Gaofeng Zeng ndtm.i...@gmail.com wrote: Hi Jason, Angela It is cool, but it not support linux. I modify the avi.install to make it support linux. On Sunday, March 2, 2014 12:25:50 PM UTC+8, Jason Felice wrote: From https://github.com/maitria/avi Avi is a vi written in Clojure. It's currently very basic and read-only, but has solved the hardest problems first (JNI terminal writing, installation, booting the JVM). It currently supports h,j,k,l,^E,^Y,$,^,0,G,:q and command repeat counts. *Vision* A lively vi with support for incremental compilation, deep language integration and source navigation, realtime shells and REPLs, and plugins, written so *it* can be a plugin in other IDEs. *Guiding Principles* - Test driven. All functionality covered by tests. - Don't defeat vim muscle memory. - Code is for people. Be expressive as hell. - Be friendly. Especially to noobs. Thanks! We'd love to hear any and all feedback. -Jason Angela -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
paredit+regex question
Hi this is not a clojure question but I'm sure some one on this list can help me. I'm trying to write a regex using paredit and it looks like I cannot write something like this #mypattern \d whenever I type the character \ I see the text Escaping character... in the minibuffer. It is waiting for another character and then it uses the two characters as a single one, so I cannot delete only one, they are together. I see how this can be useful for strings, but for regex this is not helping. I end up writing my regex like (re-pattern mypattern \\d) instead of using the short syntax. Any idea how can I write the short syntax using paredit? Thanks, Erlis -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Stasis - not another static site framework
Just a heads up that Stasis 1.0.0 has been released. The API has been
stable for two months now. I've built three sites with it, and I know of
two other sites built with Stasis too:
- The docs for SinonJS: http://sinonjs.org/
- J David Smith's blog at http://atlanis.net/blog/
He even wrote a blog post about it
here: http://atlanis.net/blog/posts/new-site-stasis.html
So if you were on the fence because of the 0.x release, worry no more. :)
Building a static site is an excellent way to have fun with Clojure, and
get a lightning fast web site that can handle any amount of traffic.
- Magnar
On Thursday, January 23, 2014 11:16:48 AM UTC+1, Magnar Sveen wrote:
Stasis
A Clojure library of tools for developing static web sites.
https://gist.github.com/magnars/32dbca91bdb0987ea4ba#another-static-site-framework-whyAnother
static site framework? Why?
Well, that's exactly it. I didn't want to use a framework. I don't like
the restrained feeling I get when using them. I prefer coding things over
messing around with configuration files.
I want to
- code my own pages
- set up my own configuration
- choose my own templating library
- create my own damn stylesheets
*Statis offers a few functions that are pretty useful when creating static
web sites.*
No more. There are no batteries included.
If you want a framework that makes it really quick and easy to create a
blog, you should take a look at these:
- misaki https://github.com/liquidz/misaki is a Jekyll inspired
static site generator in Clojure.
- Madness http://algernon.github.io/madness/ is a static site
generator, based on Enlive and Bootstrap.
- Static http://nakkaya.com/static.html is a simple static site
generator written in Clojure.
- Ecstatic http://samrat.me/ecstatic/ creates static web pages and
blog posts from Hiccup templates and Markdown.
- incise https://github.com/RyanMcG/incise is an extensible static
site generator written in Clojure.
They generally come with a folder where you put your blog posts in some
templating language, and a set of configuration options about how to set up
your blog. They often generate code for you to tweak.
https://gist.github.com/magnars/32dbca91bdb0987ea4ba#usageUsage
The core of Stasis is two functions: serve-pages and export-pages. Both
take a map from path to contents:
(def pages {/index.html h1Welcome!/h1})
The basic use case is to serve these live on a local server while
developing - and then exporting them as static pages to deploy on some
server.
https://gist.github.com/magnars/32dbca91bdb0987ea4ba#serving-live-pages-locallyServing
live pages locally
Stasis can create a Ring handler to serve your pages.
(ns example
(:require [stasis.core :as stasis]))
(def app (stasis/serve-pages pages))
Like with any Ring app, you point to your app in project.clj:
:ring {:handler example/app}
and start it with lein ring server-headless.
https://gist.github.com/magnars/32dbca91bdb0987ea4ba#exporting-the-pagesExporting
the pages
To export, just give Stasis some pages and a target directory:
(defn export []
(stasis/export-pages pages target-dir))
When you've got this function, you can create an alias for leiningen:
:aliases {build-site [run -m example/export]}
and run lein build-site on the command line. No need for a lein plugin.
https://gist.github.com/magnars/32dbca91bdb0987ea4ba#example-appsExample
apps?
The static page that prompted me to write Stasis is currently closed
source, but I'm in the process of turning my 4 other static sites over. The
simplest, and first to be done, is:
-
whattheemacsd.com (source) https://github.com/magnars/what-the-emacsd
Uses Enlive https://github.com/cgrand/enlive for templating, and
Optimus https://github.com/magnars/optimus for frontend optimization.
I'm also working on the Emacs Rocks! http://emacsrocks.com/ webpage,
where I'll use hiccup instead of Enlive.
https://gist.github.com/magnars/32dbca91bdb0987ea4ba#is-it-stableIs it
stable?
It's still on a 0.x release, but I feel the API has jelled enough now to
open source it. I don't expect any major changes at this point. I'll likely
push it to 1.0 at the end of the month.
https://gist.github.com/magnars/32dbca91bdb0987ea4ba#again-why-not-use-one-of-the-existing-frameworksAgain,
why not use one of the existing frameworks?
I think the existing frameworks are great if they fit your style. Stasis
imposes no styles. There are very few decisions made for you - no markdown
vs asciidoc, no enlive vs hiccup. No configuration options. You have to
make them.
So, yeah ... I think Stasis would be a great starting point if you want to
create the 6th static site framework to go in that list at the top. :-)
- Magnar
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this
Re: paredit+regex question
I found this particularly annoying myself, and turned it off. You can see the code in my emacs confighttps://github.com/magnars/.emacs.d/blob/master/setup-paredit.el#L62-L63 . If you don't want to mess around with how paredit works, you can always insert any character with C-q - Magnar On Monday, March 3, 2014 10:09:47 PM UTC+1, Erlis Vidal wrote: Hi this is not a clojure question but I'm sure some one on this list can help me. I'm trying to write a regex using paredit and it looks like I cannot write something like this #mypattern \d whenever I type the character \ I see the text Escaping character... in the minibuffer. It is waiting for another character and then it uses the two characters as a single one, so I cannot delete only one, they are together. I see how this can be useful for strings, but for regex this is not helping. I end up writing my regex like (re-pattern mypattern \\d) instead of using the short syntax. Any idea how can I write the short syntax using paredit? Thanks, Erlis -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.cache strange behaviour for short ttl
In case anyone was wondering I worked out what was going on and it makes
perfect sense. I was being stupid :)
If you ask for a value via 'lookup' expired values will not be returned at
this point as 'has?' is called internally.
I made a quick and dirty library to reflect the behaviour I want for my
particular use case: https://github.com/danstone/clj-refresh-cache
On Friday, February 28, 2014 9:47:14 PM UTC, dan.sto...@gmail.com wrote:
Taking the code below, if I repeatedly read from a cache I will
occasionally get nil back from the cache. This seems to happen on my
machine for ttl's under 5 ms.
Although I'm sure I would never use such a short TTL in the wild, I would
like to know why I am seeing this... Has anybody else noticed this issue?
(ns cache-test.core
(:require [clojure.core.cache :as cache]))
(def data (atom foo))
(def ttl
(atom (cache/ttl-cache-factory {} :ttl 1)))
(defn get-data
[]
(let [c @ttl
nc (if (cache/has? c {})
(cache/hit c {})
(cache/miss c {} @data))]
(reset! ttl nc)
(cache/lookup nc {})))
(def results (atom '()))
;; there will *sometimes* be
;; nil elements in the seq, seems dependent on cpu speed, which would make
sense due to side effect of taking system/currentTimeMillis internally.
(set (map (fn [_] (get-data)) (range 1)))
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: core.cache strange behaviour for short ttl
It's definitely one of the less intuitive aspects of dealing with core.cache
but it bites you once (or twice!) and you internalize it and kinda move on :)
Sean
On Mar 3, 2014, at 1:57 PM, dan.stone16...@gmail.com wrote:
In case anyone was wondering I worked out what was going on and it makes
perfect sense. I was being stupid :)
If you ask for a value via 'lookup' expired values will not be returned at
this point as 'has?' is called internally.
I made a quick and dirty library to reflect the behaviour I want for my
particular use case: https://github.com/danstone/clj-refresh-cache
On Friday, February 28, 2014 9:47:14 PM UTC, dan.sto...@gmail.com wrote:
Taking the code below, if I repeatedly read from a cache I will occasionally
get nil back from the cache. This seems to happen on my machine for ttl's
under 5 ms.
Although I'm sure I would never use such a short TTL in the wild, I would
like to know why I am seeing this... Has anybody else noticed this issue?
(ns cache-test.core
(:require [clojure.core.cache :as cache]))
(def data (atom foo))
(def ttl
(atom (cache/ttl-cache-factory {} :ttl 1)))
(defn get-data
[]
(let [c @ttl
nc (if (cache/has? c {})
(cache/hit c {})
(cache/miss c {} @data))]
(reset! ttl nc)
(cache/lookup nc {})))
(def results (atom '()))
;; there will *sometimes* be
;; nil elements in the seq, seems dependent on cpu speed, which would make
sense due to side effect of taking system/currentTimeMillis internally.
(set (map (fn [_] (get-data)) (range 1)))
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [ANN] clojure.test.check (previously, simple-check)
On Mar 1, 2014, at 11:30 AM, César Bolaños Portilla cesar.bolanosporti...@gmail.com wrote: Nooo :-(. Now it gets behind the CA + Jira impenetrable wall. Please let's not have this debate again. Hundreds of people clearly find it less than impenetrable and the process is _necessary_ from a legal point of view: http://clojure.org/contributing 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) signature.asc Description: Message signed with OpenPGP using GPGMail
