On Feb 20, 10:29 am, Laurent PETIT wrote:
> Hello Rich, thanks for answering.
>
> You may not have followed the following of the thread, where I precised my
> mind by saying what I really wanted to do (but did not at first) was using
> with-local-vars, since the value to be mutated is confined
Hello Rich, thanks for answering.
You may not have followed the following of the thread, where I precised my
mind by saying what I really wanted to do (but did not at first) was using
with-local-vars, since the value to be mutated is confined in the function,
and the macro ensures (via the use of
On Feb 20, 2009, at 5:33 AM, Christophe Grand wrote:
>
> Laurent PETIT a écrit :
>> If I'm damn sure that the value will be set once from within the same
>> thread (here we are in the SWT UI Thread), is there a reason to
>> prefer
>> atoms ?
>> (This is a real question, not a disguised affirma
2009/2/20 Christophe Grand
>
> Laurent PETIT a écrit :
> > If I'm damn sure that the value will be set once from within the same
> > thread (here we are in the SWT UI Thread), is there a reason to prefer
> > atoms ?
> > (This is a real question, not a disguised affirmation that I'm doing
> > the
Laurent PETIT a écrit :
> If I'm damn sure that the value will be set once from within the same
> thread (here we are in the SWT UI Thread), is there a reason to prefer
> atoms ?
> (This is a real question, not a disguised affirmation that I'm doing
> the right thing, so please arguments welcom
Well, I had not particularly optimization concerns in mind.
I was just more thinking about what could be the right thing to do.
I feel that atoms are useful to allow atomic operations on a value from
several threads.
If I'm damn sure that the value will be set once from within the same thread
(here
Laurent PETIT a écrit :
> I haven't tried with something simpler that the array-like method, I
> suspect it won't work in clojure, too. And I didn't want to use
> clojure's mutable methods because :
> - we already are in an IO operation, the mutation is local to the
> operation
> - I don't want
Ah, the array was a trick I used in java code : because I want to get a
value from another thread, the reference passed to the Runnable must be
final, and the Runnable can't change it, but it can "act on it". So I could
also have created a little class with a field, and the Runnable would have
chan
On Feb 19, 6:24 pm, Laurent PETIT wrote:
> Yes, thank you, I did the simplification.
>
> I couldn't resist continue to do some work around the problem, and I finally
> got both a working version of :
>
> swt-wrapper/sync-exec : a (debugged) macro that does what the initial thread
> was about
>
Yes, thank you, I did the simplification.
I couldn't resist continue to do some work around the problem, and I finally
got both a working version of :
swt-wrapper/sync-exec : a (debugged) macro that does what the initial thread
was about
swt-wrapper/swt-app : a macro to be called from the -main m
On Feb 19, 2009, at 1:10 PM, Laurent PETIT wrote:
Interesting, but is that an implementation detail, or an exposed
feature ?
It's documented at:
http://clojure.org/special_forms#fn
(at the bottom)
--Steve
smime.p7s
Description: S/MIME cryptographic signature
Interesting, but is that an implementation detail, or an exposed feature ?
2009/2/19 Stephen C. Gilardi
>
> On Feb 19, 2009, at 12:57 PM, Laurent PETIT wrote:
>
> (. *swt-display* syncExec (proxy [Runnable] [] (run [] (aset
>> val-res# 0 (do ~...@body)
>>
>
> A possible simplificati
On Feb 19, 2009, at 12:57 PM, Laurent PETIT wrote:
(. *swt-display* syncExec (proxy [Runnable] [] (run []
(aset val-res# 0 (do ~...@body)
A possible simplification is that Clojure functions implement Runnable
(and Callable) directly. I don't think a proxy is required.
--Stev
Hello,
It sounds a little weird to me that you use a synchronous call to the UI
thread (via syncExec and not asyncExec), but then use an asynchronous call
to an agent ?
I don't have repl here to test it, but could you make something simpler,
like creating a mutable structure in the let - an array
On Feb 19, 11:58 am, BerlinBrown wrote:
> I am working with this SWT application. For most calls with SWT, if
> you want to request data from a widget, then you must do so through
> the syncExec or asynExec. These methods require an implementation of
> runnable as an argument.
>
> This works
I am working with this SWT application. For most calls with SWT, if
you want to request data from a widget, then you must do so through
the syncExec or asynExec. These methods require an implementation of
runnable as an argument.
This works fine for 'setting' a value, but I have trouble when I
16 matches
Mail list logo
