These are chat archives for CRESS-Surrey/eXtraWidgets

5th
May 2015
Bryan Head
@qiemem
May 05 2015 15:09
@nicolaspayette you around?
Nicolas Payette
@nicolaspayette
May 05 2015 15:53
I am now! Just saw your PR...
Bryan Head
@qiemem
May 05 2015 15:53
ya ok cool
Wasn't sure of the best way to fix
the bit in Writer can probably be improved. Wasn't sure of the most idiomatic way to do it
Nicolas Payette
@nicolaspayette
May 05 2015 15:54
I was wondering if you could have unsubscribed the listeners...
Nicolas Payette
@nicolaspayette
May 05 2015 16:01
Re: the bit in Writer, you could have used try { val propertyMap = widgetMap(widgetKey) ... } catch { case e: NoSuchElementException => if (!fromUI) throw ... } but I'm not sure it would have been more idiomatic. I like the way you did it.
Bryan Head
@qiemem
May 05 2015 16:01
great!
re listeners: I do
Nicolas Payette
@nicolaspayette
May 05 2015 16:02
Did I miss that? Give me a sec...
Bryan Head
@qiemem
May 05 2015 16:02
but the problem is the SetProperty event arrives before the RemoveWidget event
Even though the widget has already been destroyed
Nicolas Payette
@nicolaspayette
May 05 2015 16:03
Oh, that's not in the PR. It was already in there.
Bryan Head
@qiemem
May 05 2015 16:03
right
Nicolas Payette
@nicolaspayette
May 05 2015 16:03
Makes sense.
Bryan Head
@qiemem
May 05 2015 16:03
Oh, sorry, I should say. Because these fire async, the SetProperty one can occur before the RemoveWidget one
Nicolas Payette
@nicolaspayette
May 05 2015 16:03
Yes.
Nicolas Payette
@nicolaspayette
May 05 2015 16:15
Crazy idea: All these problems stem from the fact that the widget models (i.e., Reader/Writer) can be accessed from both the job thread and the awt event thread. I didn't think of that before, but what if every call to reader/writer was blocking and ran: on the job thread if running headless; on the event thread otherwise. Since the job thread is allowed to wait on the event thread and that the opposite would never happen, would wouldn't get locking. And we'd have the garantee that everything always happens in the right order.
That's not a trivial change, however...
Bryan Head
@qiemem
May 05 2015 16:16
the job thread isn't allowed to wait on event thread, is it?
Nicolas Payette
@nicolaspayette
May 05 2015 16:16
It is.
Bryan Head
@qiemem
May 05 2015 16:16
the event thread locks the world
Nicolas Payette
@nicolaspayette
May 05 2015 16:16
All GUI prims wait on the event thread.
Bryan Head
@qiemem
May 05 2015 16:18
oh right
ok ya you're right
Nicolas Payette
@nicolaspayette
May 05 2015 16:21
I think your fix is good enough for now. But if we find other problems of the same sort, I think it would be worth exploring the idea further - maybe we'd have a chance to fix everything in one swoop.
Bryan Head
@qiemem
May 05 2015 16:22
ya sounds good
Hmm it would be really nice
We've been running into all sorts of nasty timing effects. Oh! One benefit would be that change listeners always have the current value of the widget
oh I guess that's not quite true
Nicolas Payette
@nicolaspayette
May 05 2015 16:23
Yep!
No?
Bryan Head
@qiemem
May 05 2015 16:23
just be slightly more true
if you click a checkbox really fast :P
Nicolas Payette
@nicolaspayette
May 05 2015 16:23
Hum, well, yeah. The change code still needs to run on the job thread...
Bryan Head
@qiemem
May 05 2015 16:23
right