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

Re: [Pharo-dev] endless number of call to initializePresenter when opening a debugger!!!

by Pharo4Stef

Indeed this is normal because initializeAutoRefresh does not exist! So a nice endless loop. On 03 Apr 2014, at 21:21, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Can one of you do the following experience to let me know if Iâm totally mad or not? > > 1 - Add Transcript show:'initializePresenter'; cr. > in the SpecDebugger>>initializePresenter > as below: > > initializePresenter > super initializePresenter. > Transcript show:'initializePresenter'; cr. > self flag: 'some of this logic could be moved to the stack widget'. > self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'. > self stack whenListChanged: [ :aList | > aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ]. > "Updating the toolbar will result in changing the button widgets. > If the widget hasn't been opened, there will be no spec, which leads to an error." > self spec ifNotNil: [ > self updateToolbar ] ]. > > self stack whenSelectedItemChanged: [:aContext | > self updateCodeFromContext: aContext. > self updateInspectorsFromContext: aContext. > self stack updateForSelectionChanged ]. > > self contextInspector initializeAutoRefresh. > > 2- open a transcript > > 3- open a workspace and execute 1 halt. > > I get a really large number of initializePresenter in the transcript > > >

April 3, 2014

endless number of call to initializePresenter when opening a debugger!!!

by Pharo4Stef

Can one of you do the following experience to let me know if Iâm totally mad or not? 1 - Add Transcript show:'initializePresenter'; cr. in the SpecDebugger>>initializePresenter as below: initializePresenter super initializePresenter. Transcript show:'initializePresenter'; cr. self flag: 'some of this logic could be moved to the stack widget'. self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'. self stack whenListChanged: [ :aList | aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ]. "Updating the toolbar will result in changing the button widgets. If the widget hasn't been opened, there will be no spec, which leads to an error." self spec ifNotNil: [ self updateToolbar ] ]. self stack whenSelectedItemChanged: [:aContext | self updateCodeFromContext: aContext. self updateInspectorsFromContext: aContext. self stack updateForSelectionChanged ]. self contextInspector initializeAutoRefresh. 2- open a transcript 3- open a workspace and execute 1 halt. I get a really large number of initializePresenter in the transcript

April 3, 2014

Re: [Pharo-dev] Don't do this X(

by Sebastian Sastre

On Apr 2, 2014, at 12:10 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > MCWorkingCopyBrowser>>basicSaveVersionIn: > basicSaveVersionIn: aRepository > | newVersion waitForVersion | > waitForVersion := Semaphore new. > > UIManager default defer: [ > newVersion := workingCopy newVersionIn: aRepository. > waitForVersion signal ]. > > Processor activeProcess == UIManager default uiProcess > ifFalse: [ waitForVersion wait ]. > newVersion ifNil: [ ^ self ]. > > Cursor wait showWhile: [[ > self > storeVersion: newVersion in: aRepository; > storeDependencies: newVersion in: aRepository.] > ensure: [ (MCVersionInspector new version: newVersion) show ]] > > It seems asynchronous, but I'm unsure of what it is doing. Progress bar is only displayed when doing newVersionIn:, but this is sent to the UIManager. And this is done in a fork (see saveVersion), so it's probably allways possible to interrupt the thing half-way (or save). > > Anybody to explain what is the objective when writing code like that? > Good question Thierry. Iâm sure the cursor was normal during this episode. Suggesting that either it wasnât storing the version or it was but not displaying the wait cursor as the code suggests. Functionally, what sounds to me it should be doing, is overwriting the files which is reasonable to take a little. It takes reasonable time, thatâs not the problem. Lack of feedback is the problem. So one solution would be to provide a progress bar for that file writing process or whatever is doing. Having one progress bar for the whole process would be the best solution. Plan B would be having 2 progress bars, ending when it really finishes. BTW, note that not giving control to the user while is saving would also prevent this kind of accidents.

April 3, 2014

Re: [Pharo-dev] Puzzled

by Pharo4Stef

| context process debugger | context := [ 20 factorial ] asContext. process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. Transcript show: debugger stack class ; cr ] ensure: [ process terminate] When I look at some of the stuck processes SpecDebugger>>initializePresenter super initializePresenter. self flag: 'some of this logic could be moved to the stack widget'. self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'. self stack whenListChanged: [ :aList | aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ]. "Updating the toolbar will result in changing the button widgets. If the widget hasn't been opened, there will be no spec, which leads to an error." self spec ifNotNil: [ self updateToolbar ] ]. self stack whenSelectedItemChanged: [:aContext | self updateCodeFromContext: aContext. self updateInspectorsFromContext: aContext. self stack updateForSelectionChanged ]. self contextInspector initializeAutoRefresh. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ And initializeAutoRefresh does not exist in the latest image. I have no idea why the debugger may work may be this method is not used at all. Can somebody else confirm because I have the impression to fall into a rat nest. stef

April 3, 2014

Re: [Pharo-dev] Puzzled

by Pharo4Stef

When I use | context process | context := [ 20 factorial ] asContext. process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand. ] ifCurtailed: [ process terminate] I do not get any extra process hanging around. now if I do | context process | context := [ 20 factorial ] asContext. process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand. Transcript show: debugger stack selectedIndex ] ifCurtailed: [ process terminate] But then when I do | context process debuggerg | context := [ 20 factorial ] asContext. process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand. Transcript show: debugger stack selectedIndex; cr. ] ensure: [ process terminate] I get processes stuck trying to open the log fiel ro something like that. Now I do not understand because when I ask the setter to stack (to get what is set in this variable) the system tells me that there is no store. Stef On 03 Apr 2014, at 20:49, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > even using ensure: to make sure that the process is terminated it is not really working. > I have the impression that there is a problem and that the tests does not really finishes but this is really difficult to debug. > >> Hi guys >> >> I need your brain cells. >> >> When I execute the test >> >> testBasic >> | context process debugger printedString | >> context := [ 20 factorial ] asContext. >> >> process := Process >> forContext: context >> priority: Processor userInterruptPriority. >> >> debugger := Smalltalk tools debugger new >> process: process >> controller: nil >> context: context. >> debugger stack expand. >> >> self assert: debugger stack selectedIndex = 1. >> printedString := OpalCompiler isActive >> ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] >> ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. >> self assert: debugger stack selectedItem printString = printedString. >> >> debugger send. >> debugger send. >> self assert: debugger code getText = (Integer>>#factorial) sourceCode. >> self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'. >> >> two times my image (latest get totally unusable). >> I thought that may be the process should be terminated >> so I added >> >> process terminate >> >> But nothing changes. I tried to debug the code but not chance. >> I tried self halt after [ 20 factorial ] asContext. >> >> I tried to execute the beginning in a workspace and not as a test to eliminate problem. >> But again no chance. >> >> >> So did I miss something obvious? >> >> Stef >> >> >> >> >> > >

April 3, 2014

Re: [Pharo-dev] Puzzled

by Pharo4Stef

even using ensure: to make sure that the process is terminated it is not really working. I have the impression that there is a problem and that the tests does not really finishes but this is really difficult to debug. > Hi guys > > I need your brain cells. > > When I execute the test > > testBasic > | context process debugger printedString | > context := [ 20 factorial ] asContext. > > process := Process > forContext: context > priority: Processor userInterruptPriority. > > debugger := Smalltalk tools debugger new > process: process > controller: nil > context: context. > debugger stack expand. > > self assert: debugger stack selectedIndex = 1. > printedString := OpalCompiler isActive > ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] > ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. > self assert: debugger stack selectedItem printString = printedString. > > debugger send. > debugger send. > self assert: debugger code getText = (Integer>>#factorial) sourceCode. > self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'. > > two times my image (latest get totally unusable). > I thought that may be the process should be terminated > so I added > > process terminate > > But nothing changes. I tried to debug the code but not chance. > I tried self halt after [ 20 factorial ] asContext. > > I tried to execute the beginning in a workspace and not as a test to eliminate problem. > But again no chance. > > > So did I miss something obvious? > > Stef > > > > >

April 3, 2014

Re: [Pharo-dev] left over when resizing window

by Sergi Reyner

2014-04-03 17:33 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Can all those with the problem report their graphics card? My System > > System Reporter > GFX Hardware Details are... > NVIDIA Geforce 630 here.

April 3, 2014

Puzzled

by Pharo4Stef

Hi guys I need your brain cells. When I execute the test testBasic | context process debugger printedString | context := [ 20 factorial ] asContext. process := Process forContext: context priority: Processor userInterruptPriority. debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand. self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString. debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'. two times my image (latest get totally unusable). I thought that may be the process should be terminated so I added process terminate But nothing changes. I tried to debug the code but not chance. I tried self halt after [ 20 factorial ] asContext. I tried to execute the beginning in a workspace and not as a test to eliminate problem. But again no chance. So did I miss something obvious? Stef

April 3, 2014

Re: [Pharo-dev] left over when resizing window

by Ben Coman

April 3, 2014

Re: [Pharo-dev] left over when resizing window

by Pharo4Stef

On 03 Apr 2014, at 16:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > that happens in retina displays. > Iâm awareâ¦ no time yet to fix it :( esteban do you think that this is related to the VM? I would find that strange. > > Esteban, still on holidays > > On 03 Apr 2014, at 11:32, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > >> This is this kind of glitches (see screenshot) ? >> I already talk about that some months ago in the mailing-list. >> >> On Thu, Apr 3, 2014 at 3:11 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Funny that you do not see the same issues. >>> >>> I reproduce it consistently like this: >>> - On 10.9.2 on a MacBook Pro with Retina display >>> - Download the latest Pharo 3 and the latest VM and run it: >>> curl -L get.pharo.org/30+vmLatest | sh >>> - Open a workspace or any other window and drag it around >>> >>> >>> Doru >>> >>> >>> Doru >>> >>> >>> On Thu, Apr 3, 2014 at 3:04 PM, Camille Teruel <camille.teruel(a)gmail.com> >>> wrote: >>>> >>>> >>>> On 3 avr. 2014, at 14:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Hi, >>>> >>>> Here it is on the very latest of Pharo 3: >>>> >>>> https://www.dropbox.com/s/hfi5j64e9kyim14/Screenshot%202014-04-03%2014.56.3… >>>> >>>> >>>> Ok, now I remember that I had that once several months ago, but I don't >>>> remember under which setting. >>>> I solved it with 'start drawing/stepping again' as Sergi said. >>>> We should find a way to reproduce it. >>>> >>>> >>>> Pharo3.0 Latest update: #30811 >>>> 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >>>> acc98e51-2fba-4841-a965-2975997bba66 Mar 20 2014 >>>> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >>>> acc98e51-2fba-4841-a965-2975997bba66 Mar 20 2014 >>>> https://github.com/pharo-project/pharo-vm.git Commit: >>>> 6e08ad296c0df6c1a4215a5dada5380c897dc2fe Date: 2014-03-17 14:45:12 +0100 By: >>>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14812' >>>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> >>>> On Thu, Apr 3, 2014 at 2:33 PM, Camille Teruel <camille.teruel(a)gmail.com> >>>> wrote: >>>>> >>>>> >>>>> On 3 avr. 2014, at 14:21, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> >>>>> It happens all the time on Mac. It is not so obvious in the default Pharo >>>>> image because of the background. In the Moose image, the background is white >>>>> and you see it immediately when resizing or dragging a window. >>>>> >>>>> >>>>> I tried with many windows in the latest Moose image and I still see >>>>> nothing. >>>>> I'm on mavericks. >>>>> >>>>> Smalltalk vm version --> >>>>> >>>>> 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >>>>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >>>>> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >>>>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >>>>> git://gitorious.org/cogvm/blessed.git Commit: >>>>> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: >>>>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 >>>>> ' >>>>> >>>>> >>>>> Doru >>>>> >>>>> >>>>> On Thu, Apr 3, 2014 at 2:16 PM, Camille Teruel <camille.teruel(a)gmail.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> On 3 avr. 2014, at 13:54, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >>>>>> >>>>>>> Hi all >>>>>>> >>>>>>> do you see a glitch when I resize a window? >>>>>>> Because it is not really nice. >>>>>> >>>>>> Nope, nothing in latest image at least. >>>>>> Does it happen in a fresh image? >>>>>> >>>>>>> Stef >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> >> >> -- >> Serge Stinckwich >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ >> <Screen Shot 2014-04-03 at 16.30.05.png> > >

April 3, 2014