October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Input problems

by Damien Cassou

2009/10/17 Michael Rueger <m.rueger(a)acm.org>: > after looking at the different input problems again it seems to me that they > might all go back to problems with SharedQueue. > Attached is a small change file for all who regularly experience problems > with loosing characters while typing or double pastes. > > Please let me know if after filing in the change set the issues are fixed, > less often or unchanged. http://code.google.com/p/pharo/issues/detail?id=1323 -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Oct. 18, 2009

Re: [Pharo-project] ReleaseTest>>testUndeclared

by Adrian Lienhard

we will remove the method... Adrian On Oct 17, 2009, at 14:35 , Michael Roberts wrote: > this test fails because of this method > > UndefinedObject>>requestHostAndDisplay: version from Damien. Is > there a reason why 1) this method is on nil class and 2) it has no > senders, is it sent in another package? > > thanks > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 18, 2009

[Pharo-project] [ANN] prebuilt Core #10477

by Marcus Denker

Core #10477 ----------- http://gforge.inria.fr/frs/download.php/24356/PharoCore-1.0-10477-BETA.zip Marcus -- Marcus Denker -- marcus(a)2denker.de http://www.2denker.de

Oct. 18, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Strange behavior of ContextVariableInspector

by StÃ©phane Ducasse

Excellent! I like this music :) Stef On Oct 18, 2009, at 12:18 AM, Henrik Johansen wrote: > That was issue 987 from the bugtracker, which you closed earlier > today after integrating the fix made as per Eliot's pointers. ;) > > Cheers, > Henry > On Oct 17, 2009, at 7:30 18PM, StÃ©phane Ducasse wrote: > >> >> >> Begin forwarded message: >> >>> From: Eliot Miranda <eliot.miranda(a)gmail.com> >>> Date: October 16, 2009 12:10:14 AM GMT+02:00 >>> To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >>> > >>> Subject: Re: [squeak-dev] Strange behavior of >>> ContextVariableInspector >>> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >>> > >>> >>> >>> >>> On Thu, Oct 15, 2009 at 1:02 PM, Igor Stasenko >>> <siguctua(a)gmail.com> wrote: >>> I suspect this is due to latest updates to debugger & compiler etc, >>> brought by Eliot. >>> >>> To display a context variable 'contents', a message #contents is >>> sent >>> to ContextVariableInspector. >>> The problem is, that in TextMorphForEditView>>newContents: >>> which sends this message to model (which is a >>> ContextVariableInspector) expects that returned value is text, or >>> string at least. >>> While at some point, this is not always true, and inspection of >>> different context slots in debugger could lead to interesting >>> results, >>> where >>> #contents returns an actual object, which does not implements >>> #asText >>> , and as result i often get an >>> DNU: SmallInteger>>asText >>> or similar. >>> >>> The root of evil, i think, is in >>> ContextVariableInspector>>toggleIndex: method, in following code: >>> >>> self contentsIsString >>> ifTrue: [contents := self selection] >>> ifFalse: [contents := self selectionPrintString]]. >>> >>> which sometimes returns an actual object (self selection) instead of >>> (self selectionPrintString). >>> >>> I don't really understand, what exactly tests the >>> #contentsIsString method: >>> >>> contentsIsString >>> "Hacked so contents empty when deselected" >>> >>> ^ #(0 2 3) includes: selectionIndex >>> >>> This defines which indices in the context inspector answer meta- >>> values rather than actual slot contents. Open up a debugger on >>> the activation of a method with args and/or temps and you'll see >>> thisContext >>> stack top >>> all temp vars >>> textOrStream >>> aContext >>> receiver >>> aRequestor >>> failBlock >>> logFlag >>> methodNode >>> method >>> value >>> toLog >>> itsSelection >>> itsSelectionString >>> thisContext is an object, but "stack top" and "all temp vars" are >>> strings computed by ContextvariablesInspector>>selection. i.e. >>> >>> selection >>> "Refer to the comment in Inspector|selection." >>> selectionIndex = 0 ifTrue:[^'']. >>> selectionIndex = 1 ifTrue: [^object]. >>> selectionIndex = 2 ifTrue: [^object stackPtr > 0 ifTrue: [object >>> top]]. >>> selectionIndex = 3 ifTrue: [^object tempsAndValues]. >>> ^object debuggerMap namedTempAt: selectionIndex - 3 in: object >>> >>> So the meta values at index 0 (unselected null string), 2 & 3 >>> shouldn't be sent printString, otherwise e.g. an unselected CVI >>> would show '' (the printString of ByteString new) instead of >>> nothing. >>> >>> >>> maybe a proper fix would be to test additionally, that selection is >>> string, and if not, then return false, so >>> caller will use #selectionPrintString later. >>> >>> The right thing is to ensure thatContextvariablesInspector >>> contentsIsString fieldList replaceSelectionValue: & selection all >>> agree. I think I added "stack top" to the list. I may have >>> forgotten to integrate the changes for one or more of these which >>> in my image are (also attached): >>> >>> !ContextVariablesInspector methodsFor: 'accessing' stamp: 'eem >>> 5/21/2008 12:31'! >>> fieldList >>> "Refer to the comment in Inspector|fieldList." >>> >>> object == nil ifTrue: [^Array with: 'thisContext']. >>> ^fieldList ifNil:[fieldList := (Array with: 'thisContext' with: >>> 'stack top' with: 'all temp vars') , object tempNames]! ! >>> >>> !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem >>> 3/6/2009 10:05'! >>> contentsIsString >>> ^ #(0 3) includes: selectionIndex! ! >>> >>> !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem >>> 7/18/2008 11:18'! >>> replaceSelectionValue: anObject >>> "Refer to the comment in Inspector|replaceSelectionValue:." >>> >>> ^selectionIndex = 1 >>> ifTrue: [object] >>> ifFalse: [object namedTempAt: selectionIndex - 3 put: anObject]! ! >>> >>> !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem >>> 6/10/2008 09:37'! >>> selection >>> "Refer to the comment in Inspector|selection." >>> selectionIndex = 0 ifTrue:[^'']. >>> selectionIndex = 1 ifTrue: [^object]. >>> selectionIndex = 2 ifTrue: [^object stackPtr > 0 ifTrue: [object >>> top]]. >>> selectionIndex = 3 ifTrue: [^object tempsAndValues]. >>> ^object debuggerMap namedTempAt: selectionIndex - 3 in: object! ! >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> <ContextVariablesInspector.st> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 18, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Strange behavior of ContextVariableInspector

by Henrik Johansen

That was issue 987 from the bugtracker, which you closed earlier today after integrating the fix made as per Eliot's pointers. ;) Cheers, Henry On Oct 17, 2009, at 7:30 18PM, StÃ©phane Ducasse wrote: > > > Begin forwarded message: > >> From: Eliot Miranda <eliot.miranda(a)gmail.com> >> Date: October 16, 2009 12:10:14 AM GMT+02:00 >> To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >> > >> Subject: Re: [squeak-dev] Strange behavior of >> ContextVariableInspector >> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >> > >> >> >> >> On Thu, Oct 15, 2009 at 1:02 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> I suspect this is due to latest updates to debugger & compiler etc, >> brought by Eliot. >> >> To display a context variable 'contents', a message #contents is sent >> to ContextVariableInspector. >> The problem is, that in TextMorphForEditView>>newContents: >> which sends this message to model (which is a >> ContextVariableInspector) expects that returned value is text, or >> string at least. >> While at some point, this is not always true, and inspection of >> different context slots in debugger could lead to interesting >> results, >> where >> #contents returns an actual object, which does not implements #asText >> , and as result i often get an >> DNU: SmallInteger>>asText >> or similar. >> >> The root of evil, i think, is in >> ContextVariableInspector>>toggleIndex: method, in following code: >> >> self contentsIsString >> ifTrue: [contents := self selection] >> ifFalse: [contents := self selectionPrintString]]. >> >> which sometimes returns an actual object (self selection) instead of >> (self selectionPrintString). >> >> I don't really understand, what exactly tests the #contentsIsString >> method: >> >> contentsIsString >> "Hacked so contents empty when deselected" >> >> ^ #(0 2 3) includes: selectionIndex >> >> This defines which indices in the context inspector answer meta- >> values rather than actual slot contents. Open up a debugger on the >> activation of a method with args and/or temps and you'll see >> thisContext >> stack top >> all temp vars >> textOrStream >> aContext >> receiver >> aRequestor >> failBlock >> logFlag >> methodNode >> method >> value >> toLog >> itsSelection >> itsSelectionString >> thisContext is an object, but "stack top" and "all temp vars" are >> strings computed by ContextvariablesInspector>>selection. i.e. >> >> selection >> "Refer to the comment in Inspector|selection." >> selectionIndex = 0 ifTrue:[^'']. >> selectionIndex = 1 ifTrue: [^object]. >> selectionIndex = 2 ifTrue: [^object stackPtr > 0 ifTrue: [object >> top]]. >> selectionIndex = 3 ifTrue: [^object tempsAndValues]. >> ^object debuggerMap namedTempAt: selectionIndex - 3 in: object >> >> So the meta values at index 0 (unselected null string), 2 & 3 >> shouldn't be sent printString, otherwise e.g. an unselected CVI >> would show '' (the printString of ByteString new) instead of nothing. >> >> >> maybe a proper fix would be to test additionally, that selection is >> string, and if not, then return false, so >> caller will use #selectionPrintString later. >> >> The right thing is to ensure thatContextvariablesInspector >> contentsIsString fieldList replaceSelectionValue: & selection all >> agree. I think I added "stack top" to the list. I may have >> forgotten to integrate the changes for one or more of these which >> in my image are (also attached): >> >> !ContextVariablesInspector methodsFor: 'accessing' stamp: 'eem >> 5/21/2008 12:31'! >> fieldList >> "Refer to the comment in Inspector|fieldList." >> >> object == nil ifTrue: [^Array with: 'thisContext']. >> ^fieldList ifNil:[fieldList := (Array with: 'thisContext' with: >> 'stack top' with: 'all temp vars') , object tempNames]! ! >> >> !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem >> 3/6/2009 10:05'! >> contentsIsString >> ^ #(0 3) includes: selectionIndex! ! >> >> !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem >> 7/18/2008 11:18'! >> replaceSelectionValue: anObject >> "Refer to the comment in Inspector|replaceSelectionValue:." >> >> ^selectionIndex = 1 >> ifTrue: [object] >> ifFalse: [object namedTempAt: selectionIndex - 3 put: anObject]! ! >> >> !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem >> 6/10/2008 09:37'! >> selection >> "Refer to the comment in Inspector|selection." >> selectionIndex = 0 ifTrue:[^'']. >> selectionIndex = 1 ifTrue: [^object]. >> selectionIndex = 2 ifTrue: [^object stackPtr > 0 ifTrue: [object >> top]]. >> selectionIndex = 3 ifTrue: [^object tempsAndValues]. >> ^object debuggerMap namedTempAt: selectionIndex - 3 in: object! ! >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > <ContextVariablesInspector.st> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 17, 2009

Re: [Pharo-project] VNC (RFB) problem (2nd attempt)

by Miguel Enrique CobÃ¡ Martinez

El sÃ¡b, 17-10-2009 a las 22:26 +0400, Dennis Schetinin escribiÃ³: > > > 2009/10/17 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > > Thank you for your help very much. > > > Using pharo1.0-10466-BETAweb09.10.1 + > RFB-DamienCassou.28 > > (still the latest): the image stops to respond after > closing > > connection remotely. Stopping the server leaves > image ok. > > > > I can't reproduce it on a PharoCore 10470 image. > ... > > I can't reproduce it on PharoCore or > pharo1.0-10466-BETAweb09.10.1 > > And I have the same problem with this image too. So, the problem can > be in my VNC client or perhaps in VM... I'll try to check both > variants. Will be thankful for more ideas. Yes, try other clients. I have very distinct results (in video quality) by using different clients. right now I am using ii gvncviewer 0.3.9-1 VNC viewer using gtk-vnc on Debian Squeeze and haven't had any problems. Also, check with Ctrl + . or Cmd + . which process is freezing the image. Check if there is a PharoDebug.log in the folder/directory where you have the image for some hints. Cheers > > > -- > Dennis Schetinin > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 17, 2009

Re: [Pharo-project] VNC (RFB) problem (2nd attempt)

by Dennis Schetinin

2009/10/17 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> Thank you for your help very much. > Using pharo1.0-10466-BETAweb09.10.1 + RFB-DamienCassou.28 > > (still the latest): the image stops to respond after closing > > connection remotely. Stopping the server leaves image ok. > > > I can't reproduce it on a PharoCore 10470 image. > ... > I can't reproduce it on PharoCore or pharo1.0-10466-BETAweb09.10.1 > And I have the same problem with this image too. So, the problem can be in my VNC client or perhaps in VM... I'll try to check both variants. Will be thankful for more ideas. -- Dennis Schetinin

Oct. 17, 2009

Re: [Pharo-project] VNC (RFB) problem (2nd attempt)

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 14-10-2009 a las 11:51 +0400, Dennis Schetinin escribiÃ³: > I've asked this some time ago, and got no reply. Another attempt: > > Using pharo1.0-10466-BETAweb09.10.1 + RFB-DamienCassou.28 > (still the latest): the image stops to respond after closing > connection remotely. Stopping the server leaves image ok. > > Can anybody reproduce this? > > I'm working on Russian Smalltalk User Group web server currently. This > package has shown itself as a very helpful tool during my last web > project, and it will be great if I can use it... > > If I get no reply because this is not the correct list, please give me > an advice about where to send the report. :) Hi Dennis, I can't reproduce it on a PharoCore 10470 image. I download the PharoCore image. Loaded RFB with ScriptLoader loadLatestPackage: 'Installer-Core' fromSqueaksource: 'Installer'. Installer lukas project: 'unsorted'; install: 'RFB'. And start it on display 0 with: RFBServer start: 0 then, with the image open, I opened a connection in Debian with gvncviewer localhost everything worked. I closed the remote connection and the image responded without problems. So, maybe this is specific to the web image or the packages Can you try with a pharo core image or a newer. Now to test with the refered image. I downloaded pharo1.0-10466-BETAweb09.10.1.zip and started it. I opened a workspace and executed: RFBServer start: 0 then launched the vnc viewer and closed it. the image works ok after that. I can't reproduce it on PharoCore or pharo1.0-10466-BETAweb09.10.1 Cheers > > -- > Dennis Schetinin > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 17, 2009

[Pharo-project] Fwd: [squeak-dev] Strange behavior of ContextVariableInspector

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: October 16, 2009 12:10:14 AM GMT+02:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Subject: Re: [squeak-dev] Strange behavior of ContextVariableInspector > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > > > On Thu, Oct 15, 2009 at 1:02 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > I suspect this is due to latest updates to debugger & compiler etc, > brought by Eliot. > > To display a context variable 'contents', a message #contents is sent > to ContextVariableInspector. > The problem is, that in TextMorphForEditView>>newContents: > which sends this message to model (which is a > ContextVariableInspector) expects that returned value is text, or > string at least. > While at some point, this is not always true, and inspection of > different context slots in debugger could lead to interesting results, > where > #contents returns an actual object, which does not implements #asText > , and as result i often get an > DNU: SmallInteger>>asText > or similar. > > The root of evil, i think, is in > ContextVariableInspector>>toggleIndex: method, in following code: > > self contentsIsString > ifTrue: [contents := self selection] > ifFalse: [contents := self selectionPrintString]]. > > which sometimes returns an actual object (self selection) instead of > (self selectionPrintString). > > I don't really understand, what exactly tests the #contentsIsString > method: > > contentsIsString > "Hacked so contents empty when deselected" > > ^ #(0 2 3) includes: selectionIndex > > This defines which indices in the context inspector answer meta- > values rather than actual slot contents. Open up a debugger on the > activation of a method with args and/or temps and you'll see > thisContext > stack top > all temp vars > textOrStream > aContext > receiver > aRequestor > failBlock > logFlag > methodNode > method > value > toLog > itsSelection > itsSelectionString > thisContext is an object, but "stack top" and "all temp vars" are > strings computed by ContextvariablesInspector>>selection. i.e. > > selection > "Refer to the comment in Inspector|selection." > selectionIndex = 0 ifTrue:[^'']. > selectionIndex = 1 ifTrue: [^object]. > selectionIndex = 2 ifTrue: [^object stackPtr > 0 ifTrue: [object > top]]. > selectionIndex = 3 ifTrue: [^object tempsAndValues]. > ^object debuggerMap namedTempAt: selectionIndex - 3 in: object > > So the meta values at index 0 (unselected null string), 2 & 3 > shouldn't be sent printString, otherwise e.g. an unselected CVI > would show '' (the printString of ByteString new) instead of nothing. > > > maybe a proper fix would be to test additionally, that selection is > string, and if not, then return false, so > caller will use #selectionPrintString later. > > The right thing is to ensure thatContextvariablesInspector > contentsIsString fieldList replaceSelectionValue: & selection all > agree. I think I added "stack top" to the list. I may have > forgotten to integrate the changes for one or more of these which in > my image are (also attached): > > !ContextVariablesInspector methodsFor: 'accessing' stamp: 'eem > 5/21/2008 12:31'! > fieldList > "Refer to the comment in Inspector|fieldList." > > object == nil ifTrue: [^Array with: 'thisContext']. > ^fieldList ifNil:[fieldList := (Array with: 'thisContext' with: > 'stack top' with: 'all temp vars') , object tempNames]! ! > > !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem > 3/6/2009 10:05'! > contentsIsString > ^ #(0 3) includes: selectionIndex! ! > > !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem > 7/18/2008 11:18'! > replaceSelectionValue: anObject > "Refer to the comment in Inspector|replaceSelectionValue:." > > ^selectionIndex = 1 > ifTrue: [object] > ifFalse: [object namedTempAt: selectionIndex - 3 put: anObject]! ! > > !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem > 6/10/2008 09:37'! > selection > "Refer to the comment in Inspector|selection." > selectionIndex = 0 ifTrue:[^'']. > selectionIndex = 1 ifTrue: [^object]. > selectionIndex = 2 ifTrue: [^object stackPtr > 0 ifTrue: [object > top]]. > selectionIndex = 3 ifTrue: [^object tempsAndValues]. > ^object debuggerMap namedTempAt: selectionIndex - 3 in: object! ! > > -- > Best regards, > Igor Stasenko AKA sig. > > >

Oct. 17, 2009

Re: [Pharo-project] Input problems

by Lukas Renggli

This looks looks cool. As far as I could test this seems to fix the problems I reported. Thank you. Lukas 2009/10/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > thanks mike > > stef > > On Oct 17, 2009, at 12:54 PM, Michael Rueger wrote: > >> Hi all, >> >> after looking at the different input problems again it seems to me >> that they might all go back to problems with SharedQueue. >> Attached is a small change file for all who regularly experience >> problems with loosing characters while typing or double pastes. >> >> Please let me know if after filing in the change set the issues are >> fixed, less often or unchanged. >> >> Thanks >> >> Michael >> >> <inputSensor- >> fix.cs.st.gz>_______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 17, 2009