On Fri, May 20, 2016 at 12:50 PM, Kevin Downey wrote:
> This is a difference in the type function. The clojurescript type
> function ignores metadata.
Thanks! That was my second guess, but I looked and did not see that
documented on the differences page.
I already had an ia-type? function enca
This is a difference in the type function. The clojurescript type
function ignores metadata. So the clojurescript type function is like
the clojure class function, and clojurescript doesn't have a class function.
On 05/20/2016 09:22 AM, hiskennyness wrote:
> I see here
> https://github.com/clojure
Thank you :)
Extremely clear !
On Friday, August 7, 2015 at 3:48:14 PM UTC+2, Stuart Sierra wrote:
>
> Hi Simone,
>
> The stack overflow here is caused by the REPL trying to print a circular
> reference. `swap!` always returns the new value of the Atom, and the REPL
> tries to print it.
>
> If
Hi Simone,
The stack overflow here is caused by the REPL trying to print a circular
reference. `swap!` always returns the new value of the Atom, and the REPL
tries to print it.
If you don't print the Atom, this self-reference can still work:
user=> (def a (atom {}))
#'user/a
user=> (do (swap!
Hi,
Thanks for all suggestions. It all encouraged me to deep dive into atom-s
code which turns out to be a simple wrapper over Java
java.util.concurrent.atomic.AtomicReference which essentially is a
spinlock. Knowing how it works under the hood makes so easier
to use it ...
Below piece (hopefully
On 8 December 2014 at 21:46, Fluid Dynamics wrote:
> [...]
> Which means it's locking or bust. You just get to either do the locking
> yourself or delegate :)
Sure, but isn't it nice when somebody else does your locking for you? :-)
Incidentally, there is a trade-off here between lockless reads
Oh, and as for how to use it here, you could for example say
(.putIfAbsent concurrent-hash-map :foo (delay (foo)))
Then the first thread to @(get concurrent-hash-map :foo (delay
:not-found)) (or similar) would actually compute the value.
With a map in an atom, you could swap! using a function
On Monday, December 8, 2014 3:34:05 PM UTC-5, Michał Marczyk wrote:
>
> On 8 December 2014 at 17:54, Andy L >
> wrote:
> >> But I'd personally just use a delay rather than "locking" for this
> >> purpose.
> >
> >
> > It is not that I like locking at all. However I still fail to see, how
> in
On 8 December 2014 at 17:54, Andy L wrote:
>> But I'd personally just use a delay rather than "locking" for this
>> purpose.
>
>
> It is not that I like locking at all. However I still fail to see, how in a
> multithreaded context memoize/cache prevents executing a given function more
> than once
>
>
> Most of the cache implementations in core.cache have no side-effects. They
> simply return a new cache rather than overwriting the old one. The memoize
> library places the cache in an atom, so it's guaranteed to change
> atomically.
>
I tried to read the cache code (btw an excellent exerci
On 7 December 2014 at 05:13, Andy L wrote:
>
>
>
>> The SoftCache uses a ConcurrentHashMap, but that caching option isn't
>> used in core.memoize. Are you building a custom memoizer?
>>
>>
> WRT ConcurrentHashMap, it was an incorrect conclusion on my part. In any
> case, I fail to see "thread saf
or even better (using future themselves as a "marker" in the atom):
(defmacro map-future-swap! [a k f]
`(locking ~a
(when (not (contains? @~a ~k))
(swap! ~a assoc ~k (future (swap! ~a assoc ~k (~f ~k
)
)
)
--
You received this message because you are subscribed t
> The SoftCache uses a ConcurrentHashMap, but that caching option isn't used
> in core.memoize. Are you building a custom memoizer?
>
>
WRT ConcurrentHashMap, it was an incorrect conclusion on my part. In any
case, I fail to see "thread safety" in the cache implementation, but again
I could be wron
On 7 December 2014 at 01:13, Andy L wrote:
>
> Thanks for looking into that. This indeed would solve a "semantics"
> problem of memoize, as it returns a value now. However, it seems that
> clojure.core.memoize,
> or rather clojure.core.cache memoize is based of, is not thread safe.
>
> It uses C
> (defn memoized [f]
> (comp deref (memoize (fn [& args] (delay (apply f args)
>
>
Thanks for looking into that. This indeed would solve a "semantics" problem
of memoize, as it returns a value now. However, it seems that
clojure.core.memoize,
or rather clojure.core.cache memoize is based of,
It sounds like you want a delay. Delays are guaranteed to execute their
body only once, so we can combine a delay with an atom:
(defn memoized [f]
(comp deref (memoize (fn [& args] (delay (apply f args)
In theory that should produce a memoize that executes the function only
once for each se
Thanks for your replies - Meikel and Alex,
I considered using refs, but perhaps wrongly, came to the conclusion
that they were for coordinating multiple changes atomically within an
STM ? I figured that I only had one shared piece of state - current-
state (input and output are both effectively th
If you are not concerned about coordination, then why not just grab
the value beforehand and use compare-and-set:
(let [old @my-atom
new (my-fn arg)]
(compare-and-set! my-atom old new)
(do-stuff old new))
On the other hand, if you are concerned about coordination between
multiple thread
Hi,
On Mon, May 17, 2010 at 08:49:35AM -0700, Jules wrote:
> The problem occurs in stateful objects when you receive an input and
> need to both modify your state and generate and deliver some output.
>
> I store my internal state in an atom and use swap! to update it,
> passing in the input and
"if the new value differs from the current value, it calls
notifyWatches."
I noticed that the 'changed' bool has been removed in favor of only
notifying when different. Should this logic also be applied to reset()
which currently does not check for delta?
Regards,
Tim.
--~--~-~--~
On Feb 22, 2009, at 3:48 PM, Mark Volkmann wrote:
>
> I'm not sure, but I may have found a bug in Atom.java. The swap method
> calls compareAndSet. After that, if the new value differs from the
> current value, it calls notifyWatches. However, at that point
> compareAndSet would have already cal
On Fri, Dec 5, 2008 at 11:07 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> I'm working on that. It has utility even outside traditional reactive
> contexts, in moving the imperative part of your logic outside of your state
> transformation function. I think it's a good model.
>
> Chouser recentl
So, earlier, I asked how atoms differ from using commute on refs.
It sounds like the answer is that if you use atoms in a larger
transaction, then as soon as the atom set is encountered, it actually
changes instantly, so if you rollback, and do the transaction again,
it's already been set, and wi
On Fri, Dec 5, 2008 at 11:01 AM, Stuart Sierra
<[EMAIL PROTECTED]>wrote:
>
> On Dec 4, 8:02 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> > I've added a new reference type - atom.
> > Feedback welcome,
>
> A request, if it's possible: allow watchers to be set on atoms and
> refs in addition to agen
On Dec 4, 8:02 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> I've added a new reference type - atom.
> Feedback welcome,
A request, if it's possible: allow watchers to be set on atoms and
refs in addition to agents.
I'd like to experiment with "reactive" programming using the different
transactio
On Dec 4, 8:02 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> I've added a new reference type - atom.
I like it; it greatly simplifies a common use for Refs.
"Clojure. Sometimes you just need to mutate."
"Clojure. Mutate safely."
-Stuart Sierra
--~--~-~--~~~---~--~-
On Friday 05 December 2008 06:33, Rich Hickey wrote:
> On Dec 5, 9:09 am, Randall R Schulz <[EMAIL PROTECTED]> wrote:
> > ...
> >
> > Are you ever going to get out to the Silicon Valley area to give a
> > talk?
>
> I hope to get a slot at Java One in SF this spring.
Anything less pricey?
Maybe y
On Dec 5, 9:09 am, Randall R Schulz <[EMAIL PROTECTED]> wrote:
> On Friday 05 December 2008 05:24, Rich Hickey wrote:
>
> > On Dec 5, 5:51 am, bOR_ <[EMAIL PROTECTED]> wrote:
> > > Are there any screencasts planned which will feature atoms? (I
> > > found that the screencasts are an excellent wa
On Friday 05 December 2008 05:24, Rich Hickey wrote:
> On Dec 5, 5:51 am, bOR_ <[EMAIL PROTECTED]> wrote:
> > Are there any screencasts planned which will feature atoms? (I
> > found that the screencasts are an excellent way of learning
> > clojure).
>
> Screencasts are generally a side-effect of
On Dec 5, 8:24 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Dec 5, 5:51 am, bOR_ <[EMAIL PROTECTED]> wrote:
>
> > Are there any screencasts planned which will feature atoms? (I found
> > that the screencasts are an excellent way of learning clojure).
>
> Screencasts are generally a side-effec
On Dec 5, 8:50 am, Julian Morrison <[EMAIL PROTECTED]> wrote:
> It seems like a pure efficiency optimization - used alone it doesn't
> change semantics from dosync and alter over one ref.
>
> It makes me feel wary. What if I changed my design and wanted to do
> more in the same transaction? What
It seems like a pure efficiency optimization - used alone it doesn't
change semantics from dosync and alter over one ref.
It makes me feel wary. What if I changed my design and wanted to do
more in the same transaction? What if I later wanted to call a
function that uses it in the scope of a wide
Thanks for taking to time for such a detailed explanation Rich.
This makes things much clear. And thanks Chouser for the
pictorial representation.
Parth
On Dec 5, 6:24 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Dec 5, 5:51 am, bOR_ <[EMAIL PROTECTED]> wrote:
>
> > Are there any screencasts
On Dec 5, 5:51 am, bOR_ <[EMAIL PROTECTED]> wrote:
> Are there any screencasts planned which will feature atoms? (I found
> that the screencasts are an excellent way of learning clojure).
Screencasts are generally a side-effect of a speaking engagement. I
imagine next time I give a talk, I'll t
On Dec 5, 6:02 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> I've added a new reference type - atom.
>
> Docs here:
>
> http://clojure.org/atoms
>
> Feedback welcome,
>
> Rich
Are the following equivalent or is one recommended over
the other? The first (using atoms) is definitely more convenient
Are there any screencasts planned which will feature atoms? (I found
that the screencasts are an excellent way of learning clojure).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this gr
On Dec 5, 7:51 am, Krukow <[EMAIL PROTECTED]> wrote:
> Looks useful as a kind of high-level interface to
> java.util.concurrent.AtomicReference. Am I correct
to think of this as being (semantically) equivalent to combining send-
off and await with agents?
E.g.,
(defn memoize [f]
(let [mem (a
On Dec 5, 2:02 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> I've added a new reference type - atom.
Looks useful as a kind of high-level interface to
java.util.concurrent.AtomicReference. Am I correct
--~--~-~--~~~---~--~~
You received this message because you are
One difference would be if a ref is already inside of a bigger transaction
that failed to commit for other reasons. With atoms it seems like the
"transaction" is implicitly isolated to the atom (instead of explicitly
wrapping around a ref.)
On Thu, Dec 4, 2008 at 9:26 PM, Mark Engelberg <[EMAIL PR
Didn't commute essentially give this behavior for refs? How is this
different?
On Thu, Dec 4, 2008 at 5:02 PM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> I've added a new reference type - atom.
>
>
--~--~-~--~~~---~--~~
You received this message because you are s
40 matches
Mail list logo
