Rubric mutability issue in RubTextComposer binary search
Hi, seems like there is a rather rare bug in Rubric. I opened an issue with explanation: https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability-issue-in-RubTextCo... Would be nice to fix it until release. It was caught in Spotter - as it heavily uses multithreading. Any suggestions are welcome if it is known :) Cheers, Alex
Hi Alex, On 17/03/15 22:19, Aliaksei Syrel wrote:
seems like there is a rather rare bug in Rubric. I opened an issue with explanation:
https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability-issue-in-RubTextCo...
Would be nice to fix it until release. It was caught in Spotter - as it heavily uses multithreading. Any suggestions are welcome if it is known :)
Why is that an issue in Rubric? Sounds like you might need a monitor in Spotter? Stephan
I agree with Stephan... I don't think that Rubric is built to be thread safe. Also, making Rubric thread safe will probably be a lot of work... Why do not ensuring in spotter that only one thread at a time can modify the text editor? El mar., 17 de mar. de 2015 a la(s) 11:42 p. m., Stephan Eggermont < stephan@stack.nl> escribió:
Hi Alex,
On 17/03/15 22:19, Aliaksei Syrel wrote:
seems like there is a rather rare bug in Rubric. I opened an issue with explanation:
https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability- issue-in-RubTextComposer-binary-search
Would be nice to fix it until release. It was caught in Spotter - as it heavily uses multithreading. Any suggestions are welcome if it is known :)
Why is that an issue in Rubric? Sounds like you might need a monitor in Spotter?
Stephan
Hi, Why is that an issue in Rubric? Because I can reproduce it only in Rubric :) Rubric is great and it's a pleasure to use it! I'm just curious if there is a possible quick fix. I guess, I have an idea why it could happen (because rubric for styling uses it's own background thread and doesn't absolutely takes care if during styling in its inner threads text changes) but I'm not sure if I can find time in the very nearest future to fix it, or at least try. Why do not ensuring in spotter that only one thread at a time can modify
the text editor?
That is the most interesting part. In spotter I can guarantee that at any time always maximal only one thread have access to UI elements. But I can't guarantee that this thread is UI one. It is important. I build some widgets completely in background and then pass them to UI thread to be added in the World. By convention in Spotter only UI thread can add and modify widgets in the world. If widget not in the world it can be modified by any thread, but only one. I tried to reproduce the issue, so there is a synthetic examples: (huge numbers to increase probability of exception) It works for text edit morph: |morph random|
morph := TextMorphForEditView new. morph openInWindow extent: 400@400. random := Random seed: 1337.
[ 1 to: 1337 do:
[ :i | morph contents: (String loremIpsum: (random nextInt: 1337) + 42) ] ] fork
The same doesn't work for rubric: |rubric random|
rubric := RubScrolledTextMorph new beForSmalltalkCode. rubric openInWindow extent: 400@400. random := Random seed: 1337. [ 1 to: 1337 do: [ :i | rubric updateTextWith: (String loremIpsum: (random nextInt: 1337) + 42) ] ] fork
Why do not ensuring in spotter that only one thread at a time can modify
the text editor?
yes, if no solution is found I will always create rubric morphs in UI thread Thanks for answers Cheers, Alex On Wed, Mar 18, 2015 at 1:45 PM, Guillermo Polito <guillermopolito@gmail.com
wrote:
I agree with Stephan... I don't think that Rubric is built to be thread safe.
Also, making Rubric thread safe will probably be a lot of work... Why do not ensuring in spotter that only one thread at a time can modify the text editor?
El mar., 17 de mar. de 2015 a la(s) 11:42 p. m., Stephan Eggermont < stephan@stack.nl> escribió:
Hi Alex,
On 17/03/15 22:19, Aliaksei Syrel wrote:
seems like there is a rather rare bug in Rubric. I opened an issue with explanation:
https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability- issue-in-RubTextComposer-binary-search
Would be nice to fix it until release. It was caught in Spotter - as it heavily uses multithreading. Any suggestions are welcome if it is known :)
Why is that an issue in Rubric? Sounds like you might need a monitor in Spotter?
Stephan
- When I use Spotter I get a rubric error (subscript ....) Doru did you tell me that it was fixed? or did I got it wrong?
Text highlighting related bug in Spotter is quite popular nowadays. Just to remember that it was already known a year ago and has nothing to do with spotter (see scripts how to localize bug): It works for text edit morph: |morph random|
morph := TextMorphForEditView new. morph openInWindow extent: 400@400. random := Random seed: 1337.
[ 1 to: 1337 do:
[ :i | morph contents: (String loremIpsum: (random nextInt: 1337) + 42) ] ] fork
The same doesn't work for rubric: |rubric random|
rubric := RubScrolledTextMorph new beForSmalltalkCode. rubric openInWindow extent: 400@400. random := Random seed: 1337. [ 1 to: 1337 do: [ :i | rubric updateTextWith: (String loremIpsum: (random nextInt: 1337) + 42) ] ] fork
Cheers, Alex On Wed, Mar 18, 2015 at 2:27 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
Why is that an issue in Rubric?
Because I can reproduce it only in Rubric :) Rubric is great and it's a pleasure to use it! I'm just curious if there is a possible quick fix. I guess, I have an idea why it could happen (because rubric for styling uses it's own background thread and doesn't absolutely takes care if during styling in its inner threads text changes) but I'm not sure if I can find time in the very nearest future to fix it, or at least try.
Why do not ensuring in spotter that only one thread at a time can modify
the text editor?
That is the most interesting part. In spotter I can guarantee that at any time always maximal only one thread have access to UI elements. But I can't guarantee that this thread is UI one. It is important. I build some widgets completely in background and then pass them to UI thread to be added in the World. By convention in Spotter only UI thread can add and modify widgets in the world. If widget not in the world it can be modified by any thread, but only one.
I tried to reproduce the issue, so there is a synthetic examples: (huge numbers to increase probability of exception)
It works for text edit morph:
|morph random|
morph := TextMorphForEditView new. morph openInWindow extent: 400@400. random := Random seed: 1337.
[ 1 to: 1337 do:
[ :i | morph contents: (String loremIpsum: (random nextInt: 1337) + 42) ] ] fork
The same doesn't work for rubric:
|rubric random|
rubric := RubScrolledTextMorph new beForSmalltalkCode. rubric openInWindow extent: 400@400. random := Random seed: 1337. [ 1 to: 1337 do: [ :i | rubric updateTextWith: (String loremIpsum: (random nextInt: 1337) + 42) ] ] fork
Why do not ensuring in spotter that only one thread at a time can modify
the text editor?
yes, if no solution is found I will always create rubric morphs in UI thread
Thanks for answers
Cheers, Alex
On Wed, Mar 18, 2015 at 1:45 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
I agree with Stephan... I don't think that Rubric is built to be thread safe.
Also, making Rubric thread safe will probably be a lot of work... Why do not ensuring in spotter that only one thread at a time can modify the text editor?
El mar., 17 de mar. de 2015 a la(s) 11:42 p. m., Stephan Eggermont < stephan@stack.nl> escribió:
Hi Alex,
On 17/03/15 22:19, Aliaksei Syrel wrote:
seems like there is a rather rare bug in Rubric. I opened an issue with explanation:
https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability- issue-in-RubTextComposer-binary-search
Would be nice to fix it until release. It was caught in Spotter - as it heavily uses multithreading. Any suggestions are welcome if it is known :)
Why is that an issue in Rubric? Sounds like you might need a monitor in Spotter?
Stephan
participants (3)
-
Aliaksei Syrel -
Guillermo Polito -
Stephan Eggermont