Hi,
I have a recipe to get a very strange and not easily debuggable : - Get a new image - Load the RBCodeHighliiighting parcel and StoreForPostegreSql - Load Smallbrother from Cincom public store - Open a new brother, select a class and a method - Press CTRL+N and you get a debugger UndefinedObject doesNotUnderstand #windowProcess But if you have a look at which object #windowProcess is sent to, it is not nil. Even worse, the debugger is unusable, buttons are all disabled. Can somebody have a look at this please ? Thanks Damien |
Damien
I cannot reproduce the problem in 7.4. You can get a stack dump by going to the DebuggerService and modifying DebuggerService class>>logErrorFor:label: Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Damien Cassou [mailto:[hidden email]] > Sent: Monday, July 03, 2006 9:18 AM > To: [hidden email]; Roel Wuyts > Subject: Incompatiblity between SmallBrother and RBCodeHighlighting > > Hi, > > I have a recipe to get a very strange and not easily debuggable : > > - Get a new image > - Load the RBCodeHighliiighting parcel and StoreForPostegreSql > - Load Smallbrother from Cincom public store > - Open a new brother, select a class and a method > - Press CTRL+N and you get a debugger > > UndefinedObject doesNotUnderstand #windowProcess > > But if you have a look at which object #windowProcess is sent to, it is > not nil. > > Even worse, the debugger is unusable, buttons are all disabled. > > > Can somebody have a look at this please ? > > > Thanks > > > Damien |
Hi Terry,
I could reproduce the error with both 7.4 and 7.4.1. I loaded both packages, SmallBrother (1.134) and RBCodeHighlighting (1.48), from the public repository. The bug only appears if a method is selected, and the texteditor uses RBCodeHighlighting, so you may have to open a new browser after you loaded the RBCodeHighlighting package. Kind Regards Karsten Terry Raymond schrieb: > Damien > > I cannot reproduce the problem in 7.4. > > You can get a stack dump by going to the DebuggerService > and modifying DebuggerService class>>logErrorFor:label: > > Terry > > =========================================================== > Terry Raymond Smalltalk Professional Debug Package > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== >> -----Original Message----- >> From: Damien Cassou [mailto:[hidden email]] >> Sent: Monday, July 03, 2006 9:18 AM >> To: [hidden email]; Roel Wuyts >> Subject: Incompatiblity between SmallBrother and RBCodeHighlighting >> >> Hi, >> >> I have a recipe to get a very strange and not easily debuggable : >> >> - Get a new image >> - Load the RBCodeHighliiighting parcel and StoreForPostegreSql >> - Load Smallbrother from Cincom public store >> - Open a new brother, select a class and a method >> - Press CTRL+N and you get a debugger >> >> UndefinedObject doesNotUnderstand #windowProcess >> >> But if you have a look at which object #windowProcess is sent to, it is >> not nil. >> >> Even worse, the debugger is unusable, buttons are all disabled. >> >> >> Can somebody have a look at this please ? >> >> >> Thanks >> >> >> Damien > > > |
There is a bug in the rb highlighter.
change (win notNil and: [win isInvalid not]) ifTrue: [event uiEventFor: win]] to (win notNil and: [win isInvalid not and: [win isOpen]]) ifTrue: [event uiEventFor: win]] Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Karsten [mailto:[hidden email]] > Sent: Monday, July 03, 2006 10:32 AM > To: [hidden email] > Subject: Re: Incompatiblity between SmallBrother and RBCodeHighlighting > > Hi Terry, > > I could reproduce the error with both 7.4 and 7.4.1. I loaded both > packages, SmallBrother (1.134) and RBCodeHighlighting (1.48), from the > public repository. > The bug only appears if a method is selected, and the texteditor uses > RBCodeHighlighting, so you may have to open a new browser after you > loaded the RBCodeHighlighting package. > > Kind Regards > Karsten > > > > Terry Raymond schrieb: > > Damien > > > > I cannot reproduce the problem in 7.4. > > > > You can get a stack dump by going to the DebuggerService > > and modifying DebuggerService class>>logErrorFor:label: > > > > Terry > > > > =========================================================== > > Terry Raymond Smalltalk Professional Debug Package > > Crafted Smalltalk > > 80 Lazywood Ln. > > Tiverton, RI 02878 > > (401) 624-4517 [hidden email] > > <http://www.craftedsmalltalk.com> > > =========================================================== > >> -----Original Message----- > >> From: Damien Cassou [mailto:[hidden email]] > >> Sent: Monday, July 03, 2006 9:18 AM > >> To: [hidden email]; Roel Wuyts > >> Subject: Incompatiblity between SmallBrother and RBCodeHighlighting > >> > >> Hi, > >> > >> I have a recipe to get a very strange and not easily debuggable : > >> > >> - Get a new image > >> - Load the RBCodeHighliiighting parcel and StoreForPostegreSql > >> - Load Smallbrother from Cincom public store > >> - Open a new brother, select a class and a method > >> - Press CTRL+N and you get a debugger > >> > >> UndefinedObject doesNotUnderstand #windowProcess > >> > >> But if you have a look at which object #windowProcess is sent to, it is > >> not nil. > >> > >> Even worse, the debugger is unusable, buttons are all disabled. > >> > >> > >> Can somebody have a look at this please ? > >> > >> > >> Thanks > >> > >> > >> Damien > > > > > > |
In reply to this post by Damien Cassou-3-2
Damien
The debugger was unusable because the process had been terminated. Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Damien Cassou [mailto:[hidden email]] > Sent: Monday, July 03, 2006 9:18 AM > To: [hidden email]; Roel Wuyts > Subject: Incompatiblity between SmallBrother and RBCodeHighlighting > > Hi, > > I have a recipe to get a very strange and not easily debuggable : > > - Get a new image > - Load the RBCodeHighliiighting parcel and StoreForPostegreSql > - Load Smallbrother from Cincom public store > - Open a new brother, select a class and a method > - Press CTRL+N and you get a debugger > > UndefinedObject doesNotUnderstand #windowProcess > > But if you have a look at which object #windowProcess is sent to, it is > not nil. > > Even worse, the debugger is unusable, buttons are all disabled. > > > Can somebody have a look at this please ? > > > Thanks > > > Damien |
In reply to this post by Terry Raymond
Terry,
Thank you, your fix has been published in version 1.49 in the public repository. Georg -----Ursprüngliche Nachricht----- Von: Terry Raymond [mailto:[hidden email]] Gesendet: Montag, 3. Juli 2006 18:55 An: 'Karsten'; [hidden email] Betreff: RE: Incompatiblity between SmallBrother and RBCodeHighlighting There is a bug in the rb highlighter. change (win notNil and: [win isInvalid not]) ifTrue: [event uiEventFor: win]] to (win notNil and: [win isInvalid not and: [win isOpen]]) ifTrue: [event uiEventFor: win]] Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Karsten [mailto:[hidden email]] > Sent: Monday, July 03, 2006 10:32 AM > To: [hidden email] > Subject: Re: Incompatiblity between SmallBrother and RBCodeHighlighting > > Hi Terry, > > I could reproduce the error with both 7.4 and 7.4.1. I loaded both > packages, SmallBrother (1.134) and RBCodeHighlighting (1.48), from the > public repository. > The bug only appears if a method is selected, and the texteditor uses > RBCodeHighlighting, so you may have to open a new browser after you > loaded the RBCodeHighlighting package. > > Kind Regards > Karsten > > > > Terry Raymond schrieb: > > Damien > > > > I cannot reproduce the problem in 7.4. > > > > You can get a stack dump by going to the DebuggerService > > and modifying DebuggerService class>>logErrorFor:label: > > > > Terry > > > > =========================================================== > > Terry Raymond Smalltalk Professional Debug Package > > Crafted Smalltalk > > 80 Lazywood Ln. > > Tiverton, RI 02878 > > (401) 624-4517 [hidden email] > > <http://www.craftedsmalltalk.com> > > =========================================================== > >> -----Original Message----- > >> From: Damien Cassou [mailto:[hidden email]] > >> Sent: Monday, July 03, 2006 9:18 AM > >> To: [hidden email]; Roel Wuyts > >> Subject: Incompatiblity between SmallBrother and RBCodeHighlighting > >> > >> Hi, > >> > >> I have a recipe to get a very strange and not easily debuggable : > >> > >> - Get a new image > >> - Load the RBCodeHighliiighting parcel and StoreForPostegreSql > >> - Load Smallbrother from Cincom public store > >> - Open a new brother, select a class and a method > >> - Press CTRL+N and you get a debugger > >> > >> UndefinedObject doesNotUnderstand #windowProcess > >> > >> But if you have a look at which object #windowProcess is sent to, it is > >> not nil. > >> > >> Even worse, the debugger is unusable, buttons are all disabled. > >> > >> > >> Can somebody have a look at this please ? > >> > >> > >> Thanks > >> > >> > >> Damien > > > > > > |
Le Lundi 03 Juillet 2006 22:32, Georg Heeg a écrit :
> Terry, > > Thank you, your fix has been published in version 1.49 in the public > repository. > > Georg > > -----Ursprüngliche Nachricht----- > Von: Terry Raymond [mailto:[hidden email]] > Gesendet: Montag, 3. Juli 2006 18:55 > An: 'Karsten'; [hidden email] > Betreff: RE: Incompatiblity between SmallBrother and RBCodeHighlighting > > There is a bug in the rb highlighter. > > change > (win notNil and: [win isInvalid not]) ifTrue: [event uiEventFor: win]] > to > (win notNil and: [win isInvalid not and: [win isOpen]]) ifTrue: [event > uiEventFor: win]] > > Terry > Sorry to interfer, but when i see this kind of protection i just wonder: is this thread safe ? I mean, is there a chance than another thread of execution close the window just between the isOpen test and the next uiEventFor: message? Or can you guaranty that all actions changing win state will occur in the same thread of execution? Yesterday's polling interface was so simple, with forked UI, i'am not sure anymore. Nicolas |
Nicolas,
if you read just the next line in HighlightingTextController>startHighlighting: you read: ] valueAtPriority: uiPriority "so window cannot be closed during this block"] Thus I interfere that the original author has spent some time on thinking about the problem you mention. Georg -----Ursprüngliche Nachricht----- Von: nicolas cellier [mailto:[hidden email]] Gesendet: Montag, 3. Juli 2006 23:18 An: VW NC Betreff: Re: AW: Incompatiblity between SmallBrother and RBCodeHighlighting Le Lundi 03 Juillet 2006 22:32, Georg Heeg a écrit : > Terry, > > Thank you, your fix has been published in version 1.49 in the public > repository. > > Georg > > -----Ursprüngliche Nachricht----- > Von: Terry Raymond [mailto:[hidden email]] > Gesendet: Montag, 3. Juli 2006 18:55 > An: 'Karsten'; [hidden email] > Betreff: RE: Incompatiblity between SmallBrother and RBCodeHighlighting > > There is a bug in the rb highlighter. > > change > (win notNil and: [win isInvalid not]) ifTrue: [event uiEventFor: win]] > to > (win notNil and: [win isInvalid not and: [win isOpen]]) ifTrue: [event > uiEventFor: win]] > > Terry > Sorry to interfer, but when i see this kind of protection i just wonder: is this thread safe ? I mean, is there a chance than another thread of execution close the window just between the isOpen test and the next uiEventFor: message? Or can you guaranty that all actions changing win state will occur in the same thread of execution? Yesterday's polling interface was so simple, with forked UI, i'am not sure anymore. Nicolas |
In reply to this post by Nicolas Cellier-3
Nicolas
In this case the error occurs when the window is opening and it does not have a windowManager. Generally speaking, it would probably be a good idea to review the MPUI code for thread-safety. With regards to ForkedUI the MPUI is a lot more capable than ForkedUI. However, it seems that many developers don't understand that you simply cannot spawn a process and have that process mess with a window's components or model. Conceptually speaking, the MPUI is the right way to go, however that does not mean that it is bug free. Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: nicolas cellier [mailto:[hidden email]] > Sent: Monday, July 03, 2006 5:18 PM > To: VW NC > Subject: Re: AW: Incompatiblity between SmallBrother and > RBCodeHighlighting > > Le Lundi 03 Juillet 2006 22:32, Georg Heeg a écrit : > > Terry, > > > > Thank you, your fix has been published in version 1.49 in the public > > repository. > > > > Georg > > > > -----Ursprüngliche Nachricht----- > > Von: Terry Raymond [mailto:[hidden email]] > > Gesendet: Montag, 3. Juli 2006 18:55 > > An: 'Karsten'; [hidden email] > > Betreff: RE: Incompatiblity between SmallBrother and RBCodeHighlighting > > > > There is a bug in the rb highlighter. > > > > change > > (win notNil and: [win isInvalid not]) ifTrue: [event uiEventFor: win]] > > to > > (win notNil and: [win isInvalid not and: [win isOpen]]) ifTrue: [event > > uiEventFor: win]] > > > > Terry > > > > Sorry to interfer, but when i see this kind of protection i just wonder: > is this thread safe ? > > I mean, is there a chance than another thread of execution close the > window > just between the isOpen test and the next uiEventFor: message? > > Or can you guaranty that all actions changing win state will occur in the > same > thread of execution? > > Yesterday's polling interface was so simple, with forked UI, i'am not sure > anymore. > > Nicolas |
In reply to this post by Georg Heeg
>>> change
>>> (win notNil and: [win isInvalid not]) ifTrue: [event uiEventFor: win]] >>> to >>> (win notNil and: [win isInvalid not and: [win isOpen]]) ifTrue: [event >>> uiEventFor: win]] >>> >>> Terry >>> >> >> Sorry to interfer, but when i see this kind of protection i just wonder: >> is this thread safe ? >> >> I mean, is there a chance than another thread of execution close the window >> just between the isOpen test and the next uiEventFor: message? >> >> Or can you guaranty that all actions changing win state will occur in the >> same >> thread of execution? > if you read just the next line in > HighlightingTextController>startHighlighting: you read: > > ] valueAtPriority: uiPriority "so window cannot be closed during this > block"] > > Thus I interfere that the original author has spent some time on thinking > about the problem you mention. Usually these tests are written without the valueAtPriority: protection, this relies on the assumption that all window managers are running at the same priority. Another assumption is that such tests will not block (e.g. for io). Taken together this ensures that a thread switch will not occur under the VW threading/priority model. Note that the first assumption is not always true, for example the splash screen of BottomFeeder runs at elevated priority so it can show progress and repair damage while the 'main' process fully loads the CPU doing its initialization work at the normal UI priority. In the case of #startHighlighting the CPU intensive work is forked off *below* UI priority so you can continue typing, selecting etc without loosing visual feedback. The window validity test in that forked code has to be elevated back to UI priority as mentioned above. This particular method has been publicly reviewed to shake out such multithreading issues, see here if you are interested: http://www.parcplace.net/list/vwnc-archive/0511/msg00202.html Cheers, Reinout ------- |
In reply to this post by Georg Heeg
Le Lundi 03 Juillet 2006 23:31, Georg Heeg a écrit :
> Nicolas, > > if you read just the next line in > HighlightingTextController>startHighlighting: you read: > > ] valueAtPriority: uiPriority "so window cannot be closed during this > block"] > > Thus I interfere that the original author has spent some time on thinking > about the problem you mention. > > Georg > Yes, I should have read a little further than just the mail, however this seems a general question and your answers can give usefull guidelines to anybody writing such UI. So many thanks to Georg, Reinout and Terry for your enlightments Nicolas |
Free forum by Nabble | Edit this page |