Hi, it's a long time that this question was posted, but I have found it
interesting in the implementation of token refreshes.
First of all, for service invocation, given a `revise-oauth-token` method,
I think this is good client code:
(http/request
{:method :get
:url
On Thursday, June 11, 2020 at 6:20:19 AM UTC+2, Sean Corfield wrote:
>
> If you provide an error handler on the agent -- or just specify the error
> mode as :continue -- it does not hang.
>
Thanks for pointing out those solutions.
> That makes me think that what you're seeing is "expected
Hey, thanks for the suggestions. ClojureVerse seems to be the most active
forum?
On Thursday, June 11, 2020 at 5:52:29 AM UTC+2, Sam Griffith wrote:
>
> You may want to ask this on ClojureVerse or on the official Q/A site at
> https://ask.clojure.org/index.php/
--
You received this message
I have discovered that, in the case of an agent action exception, the
behavior of agent await depends on timing:
- If your await happens to execute after the action is completed, it will
happily throw an exception that the agent is in a failed state.
- If your await happens to execute before the
In my humble opinion, main benefits of Clojure:
- Development cycle: modifying and experimenting on a running program.
- Treating data as maps. Direct and efficient immutability.
- Macros: Though used very scarcely, it's good to know that you'll be able
to extend the language from within if
Thanks Alex!
Correct, the channel implementation takes care that "transduced" channels
always pass elements through the transducer and the buffer. Also, a
FixedBuffer allows running out of limit for those cases, see this example
with a FixedBuffer of size 1 making space for 4 elements:
(def c
I see. Bufferless channels are meant to be used within the core.async
threading architecture, where there will be a limited number of blocked
puts and takes. At the boundaries, channels with dropping or sliding
windows can be used for limiting work.
So, my original question actually turns
On Thursday, July 4, 2019 at 4:24:33 PM UTC+2, Matching Socks wrote:
>
> Ernesto, you may be interested in the informative response to this
> enhancement request, https://clojure.atlassian.net/browse/ASYNC-23
>
gt;
> On Wednesday, July 3, 2019 at 7:14:46 AM UTC-4, Ernesto Garcia wrote:
>>
>> You can create a unbound channel with (chan), but not if you use a
>> transducer; (chan nil (filter odd?)) will raise an error that no buffer
>> is provided. Why is this the case?
>>
You can create a unbound channel with (chan), but not if you use a
transducer; (chan nil (filter odd?)) will raise an error that no buffer is
provided. Why is this the case?
Why the enforcement of all channels to be bound? In a program, there will
be channels that propagate to other channels,
>
> Right, except each thread gets its own binding. So it's not necessarily
> that you'll get the value of the last binding up the call stack. This will
> only be true if you are in the same thread also.
The last binding up in the call stack implies that you are in the same
thread, but I
Thanks for your response Didier.
On Friday, March 10, 2017 at 7:05:19 PM UTC+1, Didier wrote:
>
> But just to clarify, Java's ThreadLocal is an implementation of dynamic
> scoping.
>
This is how I see it:
A ThreadLocal is an object instance. It ensures a different object for each
different
Thank you Alex!
--
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,
et *threadId* 2) (printVar
> *threadId*)
>
> I have a function printVar that takes a Var and prints it. Then I create a
> new Var called *threadId* and I set it to two different values, one for
> each Thread. I pass the Var to my Var printing function, and as you can see
> if
On Sunday, February 26, 2017 at 6:23:28 AM UTC+1, Didier wrote:
>
> Dynamic scoping and Java ThreadLocals gives you equal functionality, so
> I'd use them equally. This is because Clojure supports thread bound dynamic
> scope.
>
I wouldn't say that. While dynamically scoped Vars are meant to be
On Thursday, March 2, 2017 at 3:36:53 AM UTC+1, William la Forge wrote:
>
> Alternative implementations for clojure maps are hard. You tend to use AOT
> a lot, which is non-idiomatic. But a number of people have done this,
> including myself. In retrospect, it isn't worth it. At least not most
On Wednesday, March 1, 2017 at 3:21:51 AM UTC+1, Mikera wrote:
>
> You might want to try implementing a small wrapper class that implements
> ILookup.
>
> Then you can do something like:
>
> (:keyword (MyWrapper. my-obj))
>
Yeah, but to be more convenient, it would need to return a wrapper in
On Tuesday, February 28, 2017 at 9:40:12 PM UTC+1, Alex Miller wrote:
>
> If it follows Java bean semantics, you can use the `bean` function to view
> it as a map with properties as keys.
>
The class is not actually a bean. It contains a map, with a
.getPropertyValue method, but it doesn't
Hi all,
I am using Java class that acts as a map, but doesn't implement Map. (It's
not in my hands to modify it).
I would like to do the usual lookup code:
(:keyword my-obj)
I can't make the class extend ILookup, as ILookup is an interface, not a
protocol.
Do you know of any other way to
Hi Alex, thanks for your thorough response.
It seems to me that Clojure vars are just not intended to be used as
thread-locals in general. They happen to use thread-local storage in order
to implement dynamic scoping, which is the original intent.
That is why vars are either global (interned
https://clojure.org/reference/vars says
Clojure is a practical language that recognizes the occasional need to
> maintain a persistent reference to a changing value and provides 4 distinct
> mechanisms for doing so in a controlled manner - Vars, Refs, Agents and
> Atoms. Vars provide a
21 matches
Mail list logo
