The thing to remember is map is lazy, so you are lazily (on demand)
creating a bunch of futures. Then doseq walks through those futures,
demanding one at a time. You deref the future immediately after doseq
requested it from the lazy-seq and are blocking on its completion then
doseq can move on to
Spoiler alert: I'm really really new to this language so don't expect
quality code
In an attempt to see how futures work I'm trying to make code that does the
following:
1. Take a list of sites
2. Loop through the sites and retrieve the HEAD content via a future for
each individual si
Hard to say, the class cast exception will have more information in it
that could cast light on the issue. You also are using :id in one
variation, and :db/id in the other.
On 04/08/2016 05:46 PM, Daniel Ziltener wrote:
> Hi clj,
>
> I'm trying to do some simple core.logic stuff. My input is a ve
This is *way* better than my suggestion... thanks Zach!
Alan
On Thursday, April 7, 2016 at 9:20:16 PM UTC-7, Zach Tellman wrote:
>
> This is considerably simpler than the suggestions in this thread, but I've
> written a very basic statsd client and server in the literate examples:
> http://alep
Hi Sven,
When you're sure the project depending your library does also has a
dependency on a third library, it's best to use the ":provided" profile,
rather than declaring it in the :dev profile. In your case there are two
possible solutions:
1. the dependency higher up wins. So if you declare
Hi clj,
I'm trying to do some simple core.logic stuff. My input is a vector of
maps, which I turn into a source for core.logic using
(defn make-datamap-rel [datapile]
(fn [q]
(fn [a]
(to-stream
(map #(unify a % q) (flatten datapile))
Now I have written two variants for so
Include it as a dependency.
Maven dependency resolution is rather strange, and Leiningen inherits this
strangeness. Effectively what matters is how "close" the dependency is. So
dependencies in your project file take precedence over the dependencies of
your dependencies, and so forth.
Maven does
Hi,
I have a library A that I use in project B. Now, library A makes use of
plumatics schema, as well as project B. I wonder what the best practice is
here.
Include schema in library A's dependencies? Or only declare a
dev-dependency on schema in library A?
If I declare a dev-dependency I req
>> This is also something that wouldn't be possible with Mount as this
library seems to promote global state.
As a recent switcher from Component to Mount, and without trying to change
the thread's topic into a this vs. that -- I'll simply say that I don't
believe any of these tools promote gl
Hello everybody !
I just start learning Clojure and I am a complete newbie !
I have tried to solve this classical small puzzle with Clojure.
Assign one digit from {0, 1, 2, 3, 4, 5, 6, 7, 8, 9} to each letter {o n e
t h r l v w y} so that
one + one + one + three + three + eleven = twenty
Here i
That's described here:
https://github.com/clojure/core.match/wiki/Basic-usage#sequential-types
Use: [([1] :seq)]
On Friday, April 8, 2016 at 2:37:37 PM UTC+2, Russell Wallace wrote:
>
> How do you do pattern matching on lists in Clojure? I've tried using
> core.match but the examples all deal
I found the introductory talk on Claypoole pretty informative with regards
to parallelism in Clojure in general:
https://www.youtube.com/watch?v=BzKjIk0vgzE
On Thursday, April 7, 2016 at 5:09:39 PM UTC+2, Mars0i wrote:
>
> Niels-- Ah, interesting. My uses of pmap haven't been I/O bound. I
> d
How do you do pattern matching on lists in Clojure? I've tried using
core.match but the examples all deal with vectors, and trying to specify a
list in the apparently obvious ways gets an error message about invalid
list syntax.
--
You received this message because you are subscribed to the Go
13 matches
Mail list logo
