November 2013 - Pharo-dev - lists.pharo.org

How to get menu popping up

by StÃ©phane Ducasse

We are trying to fix the ChangeSorter because the menu are broken. So we did ChangeSorterApplication>>changeSetMenu1: aMenu shifted: isShifted "Set up aMenu to hold commands for the change-set-list pane. This could be for a single or double changeSorter" aMenu title: 'Change Set'. self changeSetMenu1NewGeneration: aMenu. ChangeSorterApplication>>changeSetMenu1NewGeneration: aMenuModel | group1 menuItem | menuItem := MenuItemModel new name: [ TimeStamp now asString ]; enabled: [ TimeStamp now seconds even ]; yourself. group1 := MenuGroupModel new. group1 autoRefresh: true. aMenuModel addMenuGroup: group1. self classesListModel menu: aMenuModel. but the menu does not pop up. We tried to understand NewListModel but we could not understand how the new menu supposed to work The example exampleWithMenu "self exampleWithMenu" â¦. model := NewListModel new. model menu: menu. model openWithSpec but this is not how it works with a list. So how do we use the new menu? Stef

Nov. 11, 2013

Re: [Pharo-dev] about addMenuGroup:

by Benjamin

I do confirm :) Ben On 11 Nov 2013, at 19:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi ben > > addMenuGroup: is categorized in private but the examples uses it so I imagine that the category should be changed. > Can you confirm it? > > Stef

Nov. 11, 2013

About MenuModel

by StÃ©phane Ducasse

Hi Ben We do not understand MenuModel in the example we have menu := MenuModel new. â¦ group1 := MenuGroupModel new. item11 := MenuItemModel new name: [ TimeStamp now asString ]; enabled: [ TimeStamp now seconds even ]; yourself. ... model := NewListModel new. model menu: menu then on the NewListModel NewListModel >> menu: aBlock <api: #block getter: #menu registration: #whenMenuChanged:> "Set the block used to defined the menu" menuHolder value: aBlock so it is a block? or a MenuModel? I'm totally confused. Stef

Nov. 11, 2013

to integrate :-)

by Alexandre Bergel

hi! Here are some resutls of the Pharo sprint: https://pharo.fogbugz.com/f/cases/12139/Navigating-in-menus https://pharo.fogbugz.com/f/cases/12137/Temporary-variables-are-not-added-p… Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 11, 2013

Re: [Pharo-dev] How to test UI staff?

by Camillo Bruni

On 2013-11-11, at 18:41, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > Hi! > > I am trying to fix bug 12138 (https://pharo.fogbugz.com/f/cases/12138/Finding-a-class-is-kind-of-broken) > > And I would like to write test like that: > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > testSearchSelectAndOK > |classes | > waitSemaphore := Semaphore new. > classes := { Object . BlockClosure. Class }. > listDialogWindow := SearchFacade classSearchIn: classes. > "listDialogWindow open." > listDialogWindow addDependent: self. > listDialogWindow searchUpdate: 'BlockClosure'. > waitSemaphore wait. > listDialogWindow listIndex: 1. > waitSemaphore wait. > listDialogWindow ok. > self assert: listDialogWindow answer notNil. > self assert: (listDialogWindow answer = BlockClosure). > > handleUpdate: aMorphChanged > waitSemaphore signal. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > If I run the test from debugger â context menu on test method and select debug tests â and then I do proceed, it works. If I press the green button in Nautilus which run the test, it is frozen and I have to kill it by Cmd+. The same happens if the test it run from Test Runner. > > It waits for testSemaphoreForMethod semaphore in method PackageTreeNautilusUI(NautilusUI)>>runTestForAMethod:notifying:priority: Hi, Note that the Debugger uses a separate UI Thread to avoid side-effects. However if you run the test directly from nautilus this is not the case. Instead the tests are directly run in the UIThread. If you do `waitSemaphore wait` you will instantaneously block the UI thread, which in return means that #handleUpdate: will never be called (since the UI thread execution halted). I just propose an outline for a solution (not well thought through.. :P): Somehow you have to run the test in a separate thread ([...] fork) to make sure `waitSemaphore wait` does not block the UI Thread. At the same time you do not want to wait forever, so #valueWithin:onTimeout: is your friend :)

Nov. 11, 2013

about addMenuGroup:

by StÃ©phane Ducasse

Hi ben addMenuGroup: is categorized in private but the examples uses it so I imagine that the category should be changed. Can you confirm it? Stef

Nov. 11, 2013

Re: [Pharo-dev] About MenuItemModel

by Camillo Bruni

#action is most probably a ValueHolder, no? On 2013-11-11, at 19:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi ben > > do I get it correctly that we pass a block to a block for action > > action: aBlock > > action value: aBlock > > are you sure that you want a block as argument of a block. > > I would prefer that action is simply a block. > > Stef >

Nov. 11, 2013

About MenuItemModel

by StÃ©phane Ducasse

Hi ben do I get it correctly that we pass a block to a block for action action: aBlock action value: aBlock are you sure that you want a block as argument of a block. I would prefer that action is simply a block. Stef

Nov. 11, 2013

How to test UI staff?

by Juraj Kubelka

Hi! I am trying to fix bug 12138 (https://pharo.fogbugz.com/f/cases/12138/Finding-a-class-is-kind-of-broken) And I would like to write test like that: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- testSearchSelectAndOK |classes | waitSemaphore := Semaphore new. classes := { Object . BlockClosure. Class }. listDialogWindow := SearchFacade classSearchIn: classes. "listDialogWindow open." listDialogWindow addDependent: self. listDialogWindow searchUpdate: 'BlockClosure'. waitSemaphore wait. listDialogWindow listIndex: 1. waitSemaphore wait. listDialogWindow ok. self assert: listDialogWindow answer notNil. self assert: (listDialogWindow answer = BlockClosure). handleUpdate: aMorphChanged waitSemaphore signal. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- If I run the test from debugger â context menu on test method and select debug tests â and then I do proceed, it works. If I press the green button in Nautilus which run the test, it is frozen and I have to kill it by Cmd+. The same happens if the test it run from Test Runner. It waits for testSemaphoreForMethod semaphore in method PackageTreeNautilusUI(NautilusUI)>>runTestForAMethod:notifying:priority: Apparently there are problems with process priorities. But I do not know what to change. Thank you for any help, Jura

Nov. 11, 2013

Re: [Pharo-dev] Large difference in image size when loading configuration

by Camillo Bruni

I think so, for each method view there is an SHTextStyler / SHTextStylerST80 which computes the colors for styling in a background process. At least that part of your problem is coherent. Though I still have no idea why the styler would fail and hang the process, so far I never experienced that. I suspect some "strange" mehtod / source code must trigger some bugs in the styler? On 2013-11-11, at 18:15, phil(a)highoctane.be wrote: > I then signalled the semaphores (Alt-S in the process browser and the processes went away). > > Size of SHRange is now: SHRange allInstances size. 217381 (After a couple GCs). > > Are these things created when one views methods in the browser ? > > Phil > > > > On Mon, Nov 11, 2013 at 6:09 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I had a look at the process browser and found this strange set of processes with semaphores and style in background. > How comes? > There is no browser open even. > > See screenshot attached. > > Phil > > > > On Mon, Nov 11, 2013 at 5:10 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Yeah, that's a tad weird. > > I am quite concerned about that image ballooning effect. > > I've got a dev image and it is now 185.515.948 > > I did the flush thing > > MCFileBasedRepository flushAllCaches. > 3 timesRepeat: [Smalltalk garbageCollect]. > > and now, it is 158.740.484 > > SpaceTally new printSpaceAnalysis > > shows: > > Class code space # instances inst space percent inst average size > Array 3712 817192 31395576 19.30 38.42 > Float 13047 1313593 15763116 9.70 12.00 > ByteString 2785 378125 13078821 8.00 34.59 > MorphExtension 3097 157557 10713876 6.60 68.00 > Bitmap 3653 1975 10198648 6.30 5163.87 > TextMethodLink 419 392396 9417504 5.80 24.00 > Point 7105 711444 8537328 5.30 12.00 > CompiledMethod 22467 82802 5215856 3.20 62.99 > SHRange 1919 217316 4346320 2.70 20.00 > Rectangle 8795 325385 3904620 2.40 12.00 > TableLayoutProperties 1169 49629 3573288 2.20 72.00 > Semaphore 949 149195 2983900 1.80 20.00 > > A ton of MorphExtensions (which is a know problem). > > but also quite some TextMethodLinks, which I do not understand. > SHRange, from styling things I guess, lots of remnants. > > And quite a bunch of Semaphores, too much I think. > > Tons of Arrays and floats. I do a lot of NeoCSV loads in the image. > > > Phil > > > > > > > On Mon, Nov 11, 2013 at 4:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 11 Nov 2013, at 15:51, phil(a)highoctane.be wrote: > > > Image size goes back to: > > > > 29.068.612 > > > > Looks like all package contents are cached in the imageâ¦ > > But by a factor 3 ?? > > > Phil > > > > > > > > On Mon, Nov 11, 2013 at 1:32 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Phil, what happens if you evaluate (and save after) to the big image: > > > > MCFileBasedRepository flushAllCaches. > > 3 timesRepeat: [Smalltalk garbageCollect]. > > > > > > On Mon, Nov 11, 2013 at 8:30 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > [User.Techlab] â du -hs package-cache > > 5.3M package-cache > > > > Phil > > > > On Mon, Nov 11, 2013 at 11:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > What is the total size of the package-cache, like du -hs ? > > Could it be the same size of the difference in image size ? > > That would mean that the contents of the packages themselves is cached in the image... > > > > On 11 Nov 2013, at 10:39, phil(a)highoctane.be wrote: > > > > > I am experiencing the following while loading my configuration. > > > > > > REPO=http://www.smalltalkhub.com/mc/philippeback/HOWebStack/main > > > ./pharo Pharo.image config $REPO ConfigurationOfHOWebStack --install=0.4 > > > > > > Everything loads fine. > > > > > > But: > > > > > > with a package-cache/ empty, the final image is: 44.452.060 with a changes file of: 10.831.877 > > > > > > with a primed package-cache (meaning, letting the mczs in place and starting with a fresh image), the final image is: 29.480.912 with a changes file of: 10.830.899 > > > > > > That's quite a huge difference. > > > > > > I tried again to be sure (fresh image and empty package-cache, then fresh image only) and, weirdly enough, even if the difference in size was the same, the sizes themselves weren't.the same... > > > > > > 44.446.152 - 10.830.899 > > > 29.986.284 - 10.831.543 > > > > > > Maybe that's due to a GC occurring differently between the two. > > > > > > But this gives the impression that one cannot load a base image, apply a configuration, and end up with the same image twice. Weird. > > > > > > Why is this difference so large in the first place ? > > > > > > Phil > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > >

Nov. 11, 2013