September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] XMLPullParser hex bug

by HernÃ¡n Morales Durand

I reviewed your changes and they are ok, so I have uploaded a new ConfigurationOfXMLPullParser with your changes as stable with version 1.4 and development as 1.5. All test pass in 3.0 loading from ConfigurationBrowser. Thanks for the fix Tommaso, HernÃ¡n 2014-09-08 19:46 GMT-03:00 Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com>: > I uploaded the changes. > > I did not notice the development package, so i uploaded the changes again > to integrate your last changes (sorry for the garbage in the commit > history). > Since there was a package that was not in stable, I did not change the > ConfigurationOf, is it safe to push it to stable? > > Thanks, > Tommaso > > P.s.: of course I also added the test cases ;-) > > > > On 08/09/14 16:51, HernÃ¡n Morales Durand wrote: > >> Done. >> >> Cheers, >> >> HernÃ¡n >> >> 2014-09-08 10:18 GMT-03:00 Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com >> <mailto:tommaso.dalsasso@gmail.com>>: >> >> >> On 08/09/14 15:16, HernÃ¡n Morales Durand wrote: >> >> Tommaso I can give you access to the repository if you send me >> your SmalltalkHub user name. >> Cheers, >> >> HernÃ¡n >> >> Sure, it is dalsat >> Thanks, >> >> Tommaso >> >> 2014-09-08 6:28 GMT-03:00 Tommaso Dal Sasso >> <tommaso.dalsasso(a)gmail.com >> <mailto:tommaso.dalsasso@gmail.com> >> <mailto:tommaso.dalsasso@gmail.com >> >> <mailto:tommaso.dalsasso@gmail.com>>>: >> >> >> Hello everybody, >> >> I found a bug while playing with the XMLPullParser: >> >> When using XML entities encoded in hexadecimal the parser >> throws >> an exception. >> For example: 
 is the hexadecimal encoding of 
 >> which is >> the line feed. >> If you try to parse: '<tag contents="one&#xAtwo" />' you get a >> "Expected Number" error. >> >> >> I investigated the problem, and found that it is caused by the >> method XMLPullParser>>readNumberBase: >> >> If the base of the parsed number is not 10, it executes the >> following lines: >> numberString := self nextUpTo: $;. >> self stream skip: -1. >> [...] >> >> However, the method nextUpTo: does not exist. A MNU is >> then raised >> and handled in nextCharReference: by a greedy >> "on: Error do: [:ex | self errorExpected: 'Number.']." >> thus causing the exception. >> >> The solution is either to implement nextUpTo: or to change >> it in >> one of the two existing methods: nextUpToAll: or >> nextTrimmedBlanksUpTo: >> Example: numberString := self nextUpToAll: ';'. >> >> Also, in the following line, it calls the accessor >> "stream", which >> does not exist and causes the same problem. >> The solution here is to change >> self stream skip: -1. >> into >> stream skip: -1. >> >> The following two test cases show the problem. The first >> one shows >> the correct behavior: >> >> XMLPullParserTest>>testASCIIEntity >> | parser | >> >> parser := XMLPullParser parse: ' >> <tag contents="one
two" />'. >> >> self assert: (parser next at: #contents) equals: >> (Character lf >> join: #(one two)) >> >> >> The second one shows the error: >> >> XMLPullParserTest>>testUnicodeEntity >> | parser | >> >> parser := XMLPullParser parse: ' >> <tag contents="one
two" />'. >> >> self assert: (parser next at: #contents) equals: >> (Character lf >> join: #(one two)) >> >> >> I hope it is clear enough. I can also commit the fix >> myself, if >> you give me write access. >> >> Thanks, >> Tommaso >> >> >> >> >> >> > >

Sept. 8, 2014

Re: [Pharo-dev] XMLPullParser hex bug

by Tommaso Dal Sasso

I uploaded the changes. I did not notice the development package, so i uploaded the changes again to integrate your last changes (sorry for the garbage in the commit history). Since there was a package that was not in stable, I did not change the ConfigurationOf, is it safe to push it to stable? Thanks, Tommaso P.s.: of course I also added the test cases ;-) On 08/09/14 16:51, HernÃ¡n Morales Durand wrote: > Done. > > Cheers, > > HernÃ¡n > > 2014-09-08 10:18 GMT-03:00 Tommaso Dal Sasso > <tommaso.dalsasso(a)gmail.com <mailto:tommaso.dalsasso@gmail.com>>: > > > On 08/09/14 15:16, HernÃ¡n Morales Durand wrote: > > Tommaso I can give you access to the repository if you send me > your SmalltalkHub user name. > Cheers, > > HernÃ¡n > > Sure, it is dalsat > Thanks, > > Tommaso > > 2014-09-08 6:28 GMT-03:00 Tommaso Dal Sasso > <tommaso.dalsasso(a)gmail.com > <mailto:tommaso.dalsasso@gmail.com> > <mailto:tommaso.dalsasso@gmail.com > <mailto:tommaso.dalsasso@gmail.com>>>: > > > Hello everybody, > > I found a bug while playing with the XMLPullParser: > > When using XML entities encoded in hexadecimal the parser > throws > an exception. > For example: 
 is the hexadecimal encoding of 
 > which is > the line feed. > If you try to parse: '<tag contents="one&#xAtwo" />' you get a > "Expected Number" error. > > > I investigated the problem, and found that it is caused by the > method XMLPullParser>>readNumberBase: > > If the base of the parsed number is not 10, it executes the > following lines: > numberString := self nextUpTo: $;. > self stream skip: -1. > [...] > > However, the method nextUpTo: does not exist. A MNU is > then raised > and handled in nextCharReference: by a greedy > "on: Error do: [:ex | self errorExpected: 'Number.']." > thus causing the exception. > > The solution is either to implement nextUpTo: or to change > it in > one of the two existing methods: nextUpToAll: or > nextTrimmedBlanksUpTo: > Example: numberString := self nextUpToAll: ';'. > > Also, in the following line, it calls the accessor > "stream", which > does not exist and causes the same problem. > The solution here is to change > self stream skip: -1. > into > stream skip: -1. > > The following two test cases show the problem. The first > one shows > the correct behavior: > > XMLPullParserTest>>testASCIIEntity > | parser | > > parser := XMLPullParser parse: ' > <tag contents="one
two" />'. > > self assert: (parser next at: #contents) equals: > (Character lf > join: #(one two)) > > > The second one shows the error: > > XMLPullParserTest>>testUnicodeEntity > | parser | > > parser := XMLPullParser parse: ' > <tag contents="one
two" />'. > > self assert: (parser next at: #contents) equals: > (Character lf > join: #(one two)) > > > I hope it is clear enough. I can also commit the fix > myself, if > you give me write access. > > Thanks, > Tommaso > > > > >

Sept. 8, 2014

TxText-Athens can not load into pharo4

by Nicolai Hess

TxHorizontalSlider>>#extent: writes to method argument extent: newExtent newExtent := newExtent x @ self defaultWidth. super extent: newExtent This can not be loaded in Pharo4.0 anymore. We should have made a compiler setting for this too :) nicolai

Sept. 8, 2014

Re: [Pharo-dev] XMLPullParser hex bug

by stepharo

Ciao tommaso add a test :) On 8/9/14 15:18, Tommaso Dal Sasso wrote: > > On 08/09/14 15:16, HernÃ¡n Morales Durand wrote: >> Tommaso I can give you access to the repository if you send me your >> SmalltalkHub user name. >> Cheers, >> >> HernÃ¡n >> > Sure, it is dalsat > Thanks, > > Tommaso > >> 2014-09-08 6:28 GMT-03:00 Tommaso Dal Sasso >> <tommaso.dalsasso(a)gmail.com <mailto:tommaso.dalsasso@gmail.com>>: >> >> Hello everybody, >> >> I found a bug while playing with the XMLPullParser: >> >> When using XML entities encoded in hexadecimal the parser throws >> an exception. >> For example: 
 is the hexadecimal encoding of 
 which is >> the line feed. >> If you try to parse: '<tag contents="one&#xAtwo" />' you get a >> "Expected Number" error. >> >> >> I investigated the problem, and found that it is caused by the >> method XMLPullParser>>readNumberBase: >> >> If the base of the parsed number is not 10, it executes the >> following lines: >> numberString := self nextUpTo: $;. >> self stream skip: -1. >> [...] >> >> However, the method nextUpTo: does not exist. A MNU is then raised >> and handled in nextCharReference: by a greedy >> "on: Error do: [:ex | self errorExpected: 'Number.']." >> thus causing the exception. >> >> The solution is either to implement nextUpTo: or to change it in >> one of the two existing methods: nextUpToAll: or >> nextTrimmedBlanksUpTo: >> Example: numberString := self nextUpToAll: ';'. >> >> Also, in the following line, it calls the accessor "stream", which >> does not exist and causes the same problem. >> The solution here is to change >> self stream skip: -1. >> into >> stream skip: -1. >> >> The following two test cases show the problem. The first one shows >> the correct behavior: >> >> XMLPullParserTest>>testASCIIEntity >> | parser | >> >> parser := XMLPullParser parse: ' >> <tag contents="one
two" />'. >> >> self assert: (parser next at: #contents) equals: (Character lf >> join: #(one two)) >> >> >> The second one shows the error: >> >> XMLPullParserTest>>testUnicodeEntity >> | parser | >> >> parser := XMLPullParser parse: ' >> <tag contents="one
two" />'. >> >> self assert: (parser next at: #contents) equals: (Character lf >> join: #(one two)) >> >> >> I hope it is clear enough. I can also commit the fix myself, if >> you give me write access. >> >> Thanks, >> Tommaso >> >> > > >

Sept. 8, 2014

Re: [Pharo-dev] XMLPullParser hex bug

by HernÃ¡n Morales Durand

Done. Cheers, HernÃ¡n 2014-09-08 10:18 GMT-03:00 Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com>: > > On 08/09/14 15:16, HernÃ¡n Morales Durand wrote: > >> Tommaso I can give you access to the repository if you send me your >> SmalltalkHub user name. >> Cheers, >> >> HernÃ¡n >> >> Sure, it is dalsat > Thanks, > > Tommaso > > 2014-09-08 6:28 GMT-03:00 Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com >> <mailto:tommaso.dalsasso@gmail.com>>: >> >> >> Hello everybody, >> >> I found a bug while playing with the XMLPullParser: >> >> When using XML entities encoded in hexadecimal the parser throws >> an exception. >> For example: 
 is the hexadecimal encoding of 
 which is >> the line feed. >> If you try to parse: '<tag contents="one&#xAtwo" />' you get a >> "Expected Number" error. >> >> >> I investigated the problem, and found that it is caused by the >> method XMLPullParser>>readNumberBase: >> >> If the base of the parsed number is not 10, it executes the >> following lines: >> numberString := self nextUpTo: $;. >> self stream skip: -1. >> [...] >> >> However, the method nextUpTo: does not exist. A MNU is then raised >> and handled in nextCharReference: by a greedy >> "on: Error do: [:ex | self errorExpected: 'Number.']." >> thus causing the exception. >> >> The solution is either to implement nextUpTo: or to change it in >> one of the two existing methods: nextUpToAll: or >> nextTrimmedBlanksUpTo: >> Example: numberString := self nextUpToAll: ';'. >> >> Also, in the following line, it calls the accessor "stream", which >> does not exist and causes the same problem. >> The solution here is to change >> self stream skip: -1. >> into >> stream skip: -1. >> >> The following two test cases show the problem. The first one shows >> the correct behavior: >> >> XMLPullParserTest>>testASCIIEntity >> | parser | >> >> parser := XMLPullParser parse: ' >> <tag contents="one
two" />'. >> >> self assert: (parser next at: #contents) equals: (Character lf >> join: #(one two)) >> >> >> The second one shows the error: >> >> XMLPullParserTest>>testUnicodeEntity >> | parser | >> >> parser := XMLPullParser parse: ' >> <tag contents="one
two" />'. >> >> self assert: (parser next at: #contents) equals: (Character lf >> join: #(one two)) >> >> >> I hope it is clear enough. I can also commit the fix myself, if >> you give me write access. >> >> Thanks, >> Tommaso >> >> >> > >

Sept. 8, 2014

Re: [Pharo-dev] XMLPullParser hex bug

by Tommaso Dal Sasso

On 08/09/14 15:16, HernÃ¡n Morales Durand wrote: > Tommaso I can give you access to the repository if you send me your > SmalltalkHub user name. > Cheers, > > HernÃ¡n > Sure, it is dalsat Thanks, Tommaso > 2014-09-08 6:28 GMT-03:00 Tommaso Dal Sasso > <tommaso.dalsasso(a)gmail.com <mailto:tommaso.dalsasso@gmail.com>>: > > Hello everybody, > > I found a bug while playing with the XMLPullParser: > > When using XML entities encoded in hexadecimal the parser throws > an exception. > For example: 
 is the hexadecimal encoding of 
 which is > the line feed. > If you try to parse: '<tag contents="one&#xAtwo" />' you get a > "Expected Number" error. > > > I investigated the problem, and found that it is caused by the > method XMLPullParser>>readNumberBase: > > If the base of the parsed number is not 10, it executes the > following lines: > numberString := self nextUpTo: $;. > self stream skip: -1. > [...] > > However, the method nextUpTo: does not exist. A MNU is then raised > and handled in nextCharReference: by a greedy > "on: Error do: [:ex | self errorExpected: 'Number.']." > thus causing the exception. > > The solution is either to implement nextUpTo: or to change it in > one of the two existing methods: nextUpToAll: or > nextTrimmedBlanksUpTo: > Example: numberString := self nextUpToAll: ';'. > > Also, in the following line, it calls the accessor "stream", which > does not exist and causes the same problem. > The solution here is to change > self stream skip: -1. > into > stream skip: -1. > > The following two test cases show the problem. The first one shows > the correct behavior: > > XMLPullParserTest>>testASCIIEntity > | parser | > > parser := XMLPullParser parse: ' > <tag contents="one
two" />'. > > self assert: (parser next at: #contents) equals: (Character lf > join: #(one two)) > > > The second one shows the error: > > XMLPullParserTest>>testUnicodeEntity > | parser | > > parser := XMLPullParser parse: ' > <tag contents="one
two" />'. > > self assert: (parser next at: #contents) equals: (Character lf > join: #(one two)) > > > I hope it is clear enough. I can also commit the fix myself, if > you give me write access. > > Thanks, > Tommaso > >

Sept. 8, 2014

Re: [Pharo-dev] XMLPullParser hex bug

by HernÃ¡n Morales Durand

Tommaso I can give you access to the repository if you send me your SmalltalkHub user name. Cheers, HernÃ¡n 2014-09-08 6:28 GMT-03:00 Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com>: > Hello everybody, > > I found a bug while playing with the XMLPullParser: > > When using XML entities encoded in hexadecimal the parser throws an > exception. > For example: 
 is the hexadecimal encoding of 
 which is the line > feed. > If you try to parse: '<tag contents="one&#xAtwo" />' you get a "Expected > Number" error. > > > I investigated the problem, and found that it is caused by the method > XMLPullParser>>readNumberBase: > > If the base of the parsed number is not 10, it executes the following > lines: > numberString := self nextUpTo: $;. > self stream skip: -1. > [...] > > However, the method nextUpTo: does not exist. A MNU is then raised and > handled in nextCharReference: by a greedy > "on: Error do: [:ex | self errorExpected: 'Number.']." > thus causing the exception. > > The solution is either to implement nextUpTo: or to change it in one of > the two existing methods: nextUpToAll: or nextTrimmedBlanksUpTo: > Example: numberString := self nextUpToAll: ';'. > > Also, in the following line, it calls the accessor "stream", which does > not exist and causes the same problem. > The solution here is to change > self stream skip: -1. > into > stream skip: -1. > > The following two test cases show the problem. The first one shows the > correct behavior: > > XMLPullParserTest>>testASCIIEntity > | parser | > > parser := XMLPullParser parse: ' > <tag contents="one
two" />'. > > self assert: (parser next at: #contents) equals: (Character lf join: > #(one two)) > > > The second one shows the error: > > XMLPullParserTest>>testUnicodeEntity > | parser | > > parser := XMLPullParser parse: ' > <tag contents="one
two" />'. > > self assert: (parser next at: #contents) equals: (Character lf join: > #(one two)) > > > I hope it is clear enough. I can also commit the fix myself, if you give > me write access. > > Thanks, > Tommaso > >

Sept. 8, 2014

Re: [Pharo-dev] Trying to scale and reposition the progress bar for PharoLauncher

by Ben Coman

Sept. 8, 2014

Re: [Pharo-dev] Trying to scale and reposition the progress bar for PharoLauncher

by kilon alios

no you raised a valid point with preferences . I took a look at the method and preferences and found there is positions options for horizontal and vertical position. But even when both set to middle the progress go a bit to the right i assume the origin is in the middle and it does not take into account the width of the progress bar. That means I will have to hack the progress bar to make positioning in the middle better. I would also like to add a preference setting for progress bar size. "This is nice but I think that there should be an option." Yuiry as i said my code does not currently affect any other image than the actual PharoLauncher image. All images downloaded with PharoLauncher are unaffected. About the forking option in that case it would be better to reposition the progress bar yourself or go to preferences and change it back to default. I completely agree with you that this should added to Pharo as a preference option and that's my plan if people want me to add this new feature to Pharo. So what I did for now was to commit my code to PharoLauncher with my new progress bar and leave Pharo as it is. Try it yourselves and if you like it I can do the work and implement properly for pharo with system settings and options to locate anywhere you want , to make everyone happy. On Mon, Sep 8, 2014 at 2:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, the blocking nature of the progress bars is an argument for putting > it central. I just wanted to bring the preference to your attention. Now, > doing away with unused preferences is a powerful way to simplify the system. > > Maybe the best strategy is to start using your new code in the launcher > and see how it goes. If all goes well, people will start requesting that > progress bar for the main image ;-) > > On 08 Sep 2014, at 13:37, kilon alios <kilon.alios(a)gmail.com> wrote: > > > It should not be a problem because it affects only the PharoLauncher > image and not the images you download with PharoLauncher so the old > progress bar will remain in those images. > > > > Its personal taste of course but let remember here that a common > complain about smalltalk is that it looks weird and for some people ugly. > How many progress bars you have seen up left ? What advantage is there for > a progress bar to be up left ? > > > > Also because when performing such jobs pharo freezes and does not allow > for further interactions with the user until the job ends it makes more > sense for the progress bar to be in the middle , bigger size so its very > visible even from distance if the user decides to leave the screen to grab > some coffee or fight with his light saber and if possible even display a > "Please wait..." message so the user / beginner Pharoers knows this is not > a bug or he /she did not brake Pharo. > > > > I am not saying Pharo should be an exact copy of the GUIs out there but > at least we should respect the user habits and broke those habits only if > it is necessary. Or else you will have more and more people looking at the > GUI and going "Eeeewwww". > > > > On Mon, Sep 8, 2014 at 2:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Nice, but did you see SystemProgressMorph class>>#settingsOn: ? In other > words, there are preferences for the location of the progress bar, these > should probably be honoured. A big or a small bar also depends a bit on > taste I would say. > > > > On 08 Sep 2014, at 13:00, kilon alios <kilon.alios(a)gmail.com> wrote: > > > > > ok with a bit of help I was able to figure things out, it turns out > that it was simple to do difficult to understand :D so here is my answer > > > > > > > http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… > > > > > > I also attached the new progress bar i customised and the old for > comparison as attached images > > > > > > <newProgressBar.JPG> > > > > > > <oldProgressBar.JPG> > > > â > > > Personally I would make my code the default Progress Bar for entire > Pharo including all operations because its annoying to be that small and up > there. This should work well even if there are multiple Progress Bars > displayed. But for not its PharoLauncher only progress bar. > > > > > > How I add this code to PharoLauncher ? do I use just the development > mode of PharoLauncher and Commit ? I dont want to mess anything up. > > > > > > Next step would be to add an info box for each image so people know > what they download before downloading it. > > > > > > On Sun, Sep 7, 2014 at 8:52 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > > > yeah yeah I see it now, there actually many announcers (3 of them ) > all seem to signal SystemProgressMorph , oh boy this will be a tricky one . > Thanks for the pointer, now I have to find how to capture the instance of > that SystemProgressMorph. If I find the instance sending a width: message > should do the trick. Looks like I will need to investigate further but at > least you are pointed me to the right direction so I no longer feel lost in > space. > > > > > > > > > On Sun, Sep 7, 2014 at 7:22 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > > > Le 07/09/2014 11:53, kilon alios a Ã©crit : > > > > > > Hello pharoers it has been almost a year since the last time I > commited to PharoLauncher so I decided to go for it once again. The first > time I added a progress bar for people to see the progress of the download > of the image . Now I want to scale and reposition the progress bar as I am > not happy at all in the way it looks , its too small and hard to read. > > > > > > So I created a question at stackoverflow with all the details of my > problem > > > > > > > http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… > > > > > > I would not mind also some extra details on how I can fetch the Morphs > used by UIManager or to even further customise UIManager. I tried to find > the answer myself but after an hour of staring at the Pharo system browser > I gave up. > > > Hi Kilon, > > > > > > I don't have a stackoverflow account, so here is what I found. > > > > > > From displayProgress: , asJob brings you to Job, which has no morph at > all. But, on the class side of Job, you have a job announcer (instance > class variable jobAnnouncer). Inspect that variable, search among the > subscriptions of the announcer, and you'll find SystemProgressMorph. > > > > > > A good use case of a fairly good design which is a lot harder to > unravel than it should be, due to the lack of tools to explore announcer / > subscription relations. > > > > > > Thierry > > > > > > > > > > > > > > > > > >

Sept. 8, 2014

Re: [Pharo-dev] Trying to scale and reposition the progress bar for PharoLauncher

by Yuriy Tymchuk

This is nice but I think that there should be an option. Because if you #fork, you want to be able to interact with UI and just keep small bar in the corner. But when you donât fork it really makes sense to put it in the middle as you canât do anything anyway. Uko On 08 Sep 2014, at 13:00, kilon alios <kilon.alios(a)gmail.com> wrote: > ok with a bit of help I was able to figure things out, it turns out that it was simple to do difficult to understand :D so here is my answer > > http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… > > I also attached the new progress bar i customised and the old for comparison as attached images > > <newProgressBar.JPG> > > <oldProgressBar.JPG> > â > Personally I would make my code the default Progress Bar for entire Pharo including all operations because its annoying to be that small and up there. This should work well even if there are multiple Progress Bars displayed. But for not its PharoLauncher only progress bar. > > How I add this code to PharoLauncher ? do I use just the development mode of PharoLauncher and Commit ? I dont want to mess anything up. > > Next step would be to add an info box for each image so people know what they download before downloading it. > > On Sun, Sep 7, 2014 at 8:52 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > yeah yeah I see it now, there actually many announcers (3 of them ) all seem to signal SystemProgressMorph , oh boy this will be a tricky one . Thanks for the pointer, now I have to find how to capture the instance of that SystemProgressMorph. If I find the instance sending a width: message should do the trick. Looks like I will need to investigate further but at least you are pointed me to the right direction so I no longer feel lost in space. > > > On Sun, Sep 7, 2014 at 7:22 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 07/09/2014 11:53, kilon alios a Ã©crit : > > Hello pharoers it has been almost a year since the last time I commited to PharoLauncher so I decided to go for it once again. The first time I added a progress bar for people to see the progress of the download of the image . Now I want to scale and reposition the progress bar as I am not happy at all in the way it looks , its too small and hard to read. > > So I created a question at stackoverflow with all the details of my problem > > http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… > > I would not mind also some extra details on how I can fetch the Morphs used by UIManager or to even further customise UIManager. I tried to find the answer myself but after an hour of staring at the Pharo system browser I gave up. > Hi Kilon, > > I don't have a stackoverflow account, so here is what I found. > > From displayProgress: , asJob brings you to Job, which has no morph at all. But, on the class side of Job, you have a job announcer (instance class variable jobAnnouncer). Inspect that variable, search among the subscriptions of the announcer, and you'll find SystemProgressMorph. > > A good use case of a fairly good design which is a lot harder to unravel than it should be, due to the lack of tools to explore announcer / subscription relations. > > Thierry > > >

Sept. 8, 2014