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

Re: [Pharo-dev] Puzzled

by Pharo4Stef

Iâm sorry but I will stop working on this issue since I do not have time for pharo anymore this week and the next one. Apparently Iâm the only one to care about this bogus logic so let it be but be prepared to have too many hanging process around. Stef > Hey, > > I remembered removing the initializeAutoRefresh code from the debugger. Perhaps I didn't commit that package. Or I forgot this one. > > > 2014-04-03 12:34 GMT-07:00 Pharo4Stef <pharo4Stef(a)free.fr>: > ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement > because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh). > > Stef > On 03 Apr 2014, at 21:13, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > > > > | 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 4, 2014

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by David T. Lewis

On Fri, Apr 04, 2014 at 02:55:01AM +0200, Igor Stasenko wrote: > > there is one caveat, that if you really want to see exactly , say 16 points > sized font on your screen, > it is not possible without knowing the display resolution - how many pixels > in one inch (hence > #pixelsPerInch ). > Unfortunately, our VMs don't give us a way to determine DPI of display.. > and so, it is always 96 :/ > > pheww.... I don't think there is any way for the VM to know the #pixelsPerInch of the display, regardless of the display resolution. Maybe that implies that some calibration would be needed in the image to relate font points to the physical display. Dave

April 4, 2014

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by Igor Stasenko

Okay, i think i got it.. Here is what happens: - the font size is usually specified in points, not x@y points, but typographical points, which is 1/72 inch TextStyle pointsToPixels: 14 TextStyle pointsToPixels: 14 => 18.666666666666668 pointsToPixels: points ^points * self pixelsPerInch / 72.0 but in Athens, i , stupid idiot, completely forgot about that, and use point size directly, to scale up font .. but the point is that this scaling performed in font units (EMs). so, to actually scale font correctly, i must use same TextStyle pointsToPixels: .. as Freetype package using.. there is one caveat, that if you really want to see exactly , say 16 points sized font on your screen, it is not possible without knowing the display resolution - how many pixels in one inch (hence #pixelsPerInch ). Unfortunately, our VMs don't give us a way to determine DPI of display.. and so, it is always 96 :/ pheww.... fromFreetypeFont: aFont cairoFace: face ..... - fontMatrix scaleBy: aFont pointSize. + fontMatrix scaleBy: (TextStyle pointsToPixels: aFont pointSize). problem solved ... (i hope) :) -- Best regards, Igor Stasenko.

April 4, 2014

Re: [Pharo-dev] Puzzled

by ClÃ©ment Bera

Hey, I remembered removing the initializeAutoRefresh code from the debugger. Perhaps I didn't commit that package. Or I forgot this one. 2014-04-03 12:34 GMT-07:00 Pharo4Stef <pharo4Stef(a)free.fr>: > ok now I understand: an endless loop inside the debugger creation. I do > not understand why we did not address it with clement > because we open the debugger and other when we fixed the logic of the > inspector (to avoid polling refresh). > > Stef > On 03 Apr 2014, at 21:13, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > > > > | 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] left over when resizing window

by Igor Stasenko

On 3 April 2014 16:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > that happens in retina displays. > Iâm awareâ¦ no time yet to fix it :( > > Esteban, still on holidays > btw, again and again i forgetting ask you to show me what i should change to disable "half resolution" mode while on retina displays.. i wanna use full resolution, for aestetical testing of font rendering without subpixel(s).. by athens/cairo :) > > 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> > > > -- Best regards, Igor Stasenko.

April 3, 2014

Re: [Pharo-dev] where is the jenkins monkey job?

by Pharo4Stef

https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/ On 03 Apr 2014, at 22:02, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Hi > > I would like to know if the monkey is currently running and not stalled but I cannot find the jenkins job doing it. > > Stef

April 3, 2014

where is the jenkins monkey job?

by Pharo4Stef

Hi I would like to know if the monkey is currently running and not stalled but I cannot find the jenkins job doing it. Stef

April 3, 2014

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

by Chris Cunningham

Could it be that one of the processes called from this code is specifically setting the cursor back to normal? That would defeat the whole Cursor wait showWhile: process. Progress bars or other non-shared state do seem safer to utilize for core activities like this. -cbc On Thu, Apr 3, 2014 at 12:18 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > > 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

ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh). Stef On 03 Apr 2014, at 21:13, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > | 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] endless number of call to initializePresenter when opening a debugger!!!

by Pharo4Stef

And now I understand because we forgot to remove this message sent when removing the polling behavior of inspector. On 03 Apr 2014, at 21:23, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > 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