Hi Sam,
I am working on a book for Pragmatic Programmers with Ben Vandgrift called
"Clojure Applied" that is target specifically at people like yourself. Our
goal is to bridge the gap between knowing the syntax and basics of the
language to knowing how to apply it in building applications. The
Eventually you'll have to come around to reading implementations. The Joy
of Clojure is a very thoughtful book, but lib authors aren't going to go
through the same amount of trouble.
Reading code gets easier and rewards faster the more you do it.
On Saturday, August 30, 2014, Christopher Small
+1 for JOC. It's a fantastic book.
Chris
On Friday, August 29, 2014 6:28:25 PM UTC-7, Paul L. Snyder wrote:
>
> On Fri, 29 Aug 2014, Sam Raker wrote:
>
> > I'm just not sure what to do at this point in my Clojure learning
> > experience. I've probably written a few thousand lines of Clojure at
`->` inserts its first argument into the second position of the next
argument, and so on, so
(-> []
(conj 1)
(conj 2))
Turns into
(conj (conj [] 1) 2)
`->>` inserts its first argument into the LAST position of the next
argument, and so on, so
(->> 1
(conj [2])
(conj [3]))
Turns into
(co
How would another Lisp avoid giving you an error when referring to a symbol
that has no value?
If you just want your entire program in a single namespace, and don't want
to use any libraries in other namespaces, then simply don't use the "/"
character in your symbol names.
If you want to use the
How about something like this? You can still keep your cache as an atom
that you can pass around, and you avoid unnecessary recomputation through
memoize:
(def cache (atom {}))
(def lookup
(let [calc-value* (memoize calc-value)]
(fn [cache k]
(when-not (contains? @cache k)
(
I must be missing something, because this is too simple?
(defn get-maybe-cached [cache key]
(dosync
(if-let [v (get @cache key)]
v
(do
(reset! cache (assoc @cache key (calculate key)))
(get @cache key)
On Saturday, August 30, 2014
On 30/08/2014 17:04, Alexey Kachayev wrote:
Thread-first macro ->will insert list-of-listsas first argument for map,
which is definitely not what you expect. Use threading-last ->>instead.
I've never quite understood the distinction other than -> does
everything top to bottom and ->> does the
Thread-first macro -> will insert list-of-lists as first argument for map,
which is definitely not what you expect. Use threading-last ->> instead.
2014-08-30 18:48 GMT+03:00 gvim :
> On 30/08/2014 15:07, Alexey Kachayev wrote:
>
>> for macro expects each pair to be either binding-form/collectio
On 30/08/2014 15:07, Alexey Kachayev wrote:
for macro expects each pair to be either binding-form/collection-expr or
one of known modifiers (:let, :when, :while).
Here:
plan (keyword (first l))
you give a pair of binding-form and keyword (which is really impossible
to iterate over).
If you me
On 30/08/2014 15:07, Alexey Kachayev wrote:
for macro expects each pair to be either binding-form/collection-expr or
one of known modifiers (:let, :when, :while).
Here:
plan (keyword (first l))
you give a pair of binding-form and keyword (which is really impossible
to iterate over).
If you me
for macro expects each pair to be either binding-form/collection-expr or
one of known modifiers (:let, :when, :while).
Here:
plan (keyword (first l))
you give a pair of binding-form and keyword (which is really impossible to
iterate over).
If you meant let-binding for plan, dec, min and long, u
I have a long function which produces `list-of-lists` :
(("Sun" "21" "li" "13" "201.2139410")
("Moon" "11" "le" "21" "131.3457459")
..)
before entering a list comprehension (simplified for brevity):
(defn calc ...
(let [ .
...
list-of-lists (map #(res
Can you monkey-patch the meta function itself to draw from a map of object
to meta?
On Saturday, August 30, 2014, Francis Avila wrote:
> It would probably help if you said more about the source of this
> atom-holding object. Is it a plain Java class? A deftype/defrecord? Is it
> final?
>
>
> If
You are absolutely right. Sorry, for distraction. Deleted my message
immediately after I realized that, but it turns out it managed to go
already.
суббота, 30 августа 2014 г., 16:25:21 UTC+4 пользователь Colin Fleming
написал:
>
> I'm not sure I understand - the contention will be the same whe
I'm not sure I understand - the contention will be the same whether or not
the value is calculated in the swap! call, right? And if I calculate the
value and then pass the calculated value to swap!, that value will be
thrown away every time the cache contains an existing value for my key.
On 30
On Saturday, August 30, 2014 12:34:24 AM UTC+5:30, Ashton Kemerling wrote:
>
> Bar/baz refers to the symbol baz in the namespace bar. If you haven't
> created and imported bar, that's an error.
>
>
This feels too java-ish for a lisp.
Can I avoid this by some form of declaration ?
--
You rece
It would probably help if you said more about the source of this
atom-holding object. Is it a plain Java class? A deftype/defrecord? Is it
final?
If you can control the construction of this object and its class is not
final, you can subclass it and add an IObj implementation. (Note that most,
I see...
Just in case, I'd like to point out one possible deficiency in your
original snippet. Generally, it should be better move value calculation
outside of swap call, thus
reducing a chance of contention, especially when you have many threads
asking for different keys.
суббота, 30 август
In my case I can't use memoize because I need to supply the cache map -
that in turn is stored on another object so it can be invalidated by events
outside my control.
On 30 August 2014 20:00, Ray Miller wrote:
> On 30 August 2014 06:26, Colin Fleming
> wrote:
> >
> > I want to use a map to ca
Yes, in my case the update is atomic but doesn't strictly avoid
recomputation (since the Atom can call the calculation function many
times). I've given this some hammock time and I don't think that's a
problem. However on further investigation I do have to ensure that for each
of my keys the value
The only way to do this is to wrap the object in something that implements
IObj. But at that point you might as well wrap it in a regular hashmap and
just wrap it in real data.
On Sat, Aug 30, 2014 at 1:54 AM, Atamert Ölçgen wrote:
> Hi François,
>
> Thanks for the links.
>
> I can't really pas
Hi François,
Thanks for the links.
I can't really pass a list since the first function is expecting the object
I am passing, then it calls some other functions that were supposed to
extract the meta. The problem is, functions that are called later can be
executed in a different thread.
On Sat,
On 30/08/14 05:15, Atamert Ölçgen wrote:
Obviously I can't.
But I need to add this capability to an object. During testing I
attach meta to this object that contains an atom. Then I pass this
object to other functions, known in runtime. I can't use a dynamic var
because all this happens withi
Oh, forget to wait for value in unwrap. Here is a better version
(defn unwrap [v]
(if-let [p (get v ::promise)]
@p
v))
(defn compute [cache k]
(let [p {::promise (promise)}
c (swap! cache assoc k p)
val (get c k)]
(when (identical? val p)
(let [result (calc
On 30 August 2014 06:26, Colin Fleming wrote:
>
> I want to use a map to cache values based on a key. I'm planning to use an
> atom for this. My basic operation is "give me the value for this key" - if
> the value exists in the map then that value should be returned, otherwise a
> new value should
Snippet you showed before is also not an atomic. If you want strictly to
avoid recomputations you need something more elaborate.
May be this
(def cache (atom {}))
(defn unwrap [v]
(if-let [a (get v ::atom)]
@a
v))
(defn compute [cache k]
(let [p {::atom (atom nil)}
c (swap
True, but only if you don't mind possibly calculating the value more than
once since the update is not atomic.
On 30 August 2014 18:31, Eldar Gabdullin wrote:
> Something like the following would be fine for me
>
> (def cache (atom {}))
>
> (defn lookup [cache k]
> (let [v (get @cache k ::nil
28 matches
Mail list logo
