- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #494: 21232-BenchmarkResultprintFrequencyOn-can-be-confusing

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #494 was: SUCCESS. The Pull Request #794 was integrated: "21232-BenchmarkResultprintFrequencyOn-can-be-confusing" Pull request url: https://github.com/pharo-project/pharo/pull/794 Issue Url: https://pharo.fogbugz.com/f/cases/21232 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 3, 2018

Re: [Pharo-dev] Change Pharo window icon

by Stephane Ducasse

Tx we should have a class to do it for us. On Fri, Feb 2, 2018 at 11:42 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Stef, > > On Fri, Feb 2, 2018 at 11:32 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Would it be possible to change the icon without having to compile a new >> VM? > > > Through an AppleScript: > > e.g. https://www.sethvargo.com/replace-icons-osx/ > >> >> To me the current setup looks so monolithic and dated. >> I would expect that somebody can deploy a application with its own >> logo by just providing some new resources. > > > And that's indeed possible. Take the .app bundle and change the .icns file > as described above. > >> >> >> Stef >> >> On Wed, Jan 31, 2018 at 11:17 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> > Hi Vincent, >> > >> > On Wed, Jan 31, 2018 at 12:07 PM, <Vincent.Blondeau(a)lamresearch.com> >> > wrote: >> >> >> >> Hi, >> >> >> >> I would like to know how to change the main Pharo window icon. I saw >> >> that >> >> there is a primitive for the title: >> >> DisplayScreen class >> primitiveWindowTitle:string: ; primitive: >> >> 'primitiveHostWindowTitle' module:'HostWindowPlugin' >> >> but I cannot find one for the icon. >> >> Should another primitive need to be implemented? >> > >> > >> > The icon is baked into the VM executable. So to change it one has to >> > build >> > a VM with a different icon. >> > >> > On Windows it is in >> > {build.win32x86,build.win64x64}/pharo.cog.spur/Pharo.ico >> > and the file that specifies to use Pharo.ico is >> > {build.win32x86,build.win64x64}/pharo.cog.spur/Pharo.rc >> > >> > On Mac OS X it is in >> > platforms/iOS/vm/OSX/Pharo.icns >> > (alongside three others such as PharoImage.icns) >> > and the file that specifies to use Pharo.icns is >> > {build.macos32x86,build.macos64x64}/pharo.cog.spur/Makefile >> > in setting the VM variable. The file that associates the other icons >> > with >> > specific file types is >> > platforms/iOS//vm/OSX/Pharo-Info.plist >> > >> > If you're changing the Pharo icon let me suggest you update the icon >> > files >> > themselves in the opensmalltalk-vm source tree. >> > >> > If you're creating a new variant of the VM for some new purpose (say a >> > special Lam VM) then let me suggest you add the icons to the >> > opensmalltalk-vm source tree, creating special build directories for >> > these >> > VMs, such as {build.macos32x86,build.macos64x64}/lam.pharo.cog.spur/ >> > >> > If you want to do this privately, then take either of the approaches >> > above >> > and simply don't publish the edits. You can write a script that takes >> > an >> > updated checked-out opensmalltalk-vm source tree and edits it with files >> > from a specific repository. I have such scripts and can help you with >> > them. >> > Hint, pax is a very convenient directory hierarchy copying tool >> > available at >> > least on Mac OS X. pax -rwlk will copy the trees under a sequence of >> > directories into their corresponding places in a target tree. >> > >> >> >> >> Thanks! >> >> >> >> Vincent >> >> >> >> >> > >> > >> > >> > -- >> > _,,,^..^,,,_ >> > best, Eliot >> > > > > -- > _,,,^..^,,,_ > best, Eliot

Feb. 3, 2018

Re: [Pharo-dev] Disabling a MenuGroupModel

by Stephane Ducasse

Tx! On Sat, Feb 3, 2018 at 12:25 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > https://pharo.fogbugz.com/f/cases/21233/Disabling-a-MenuGroupModel-bug > > > 2018-02-02 10:10 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> Hi guys, >> >> If you develop an application window with multiple grouped menu items, >> you will certainly be able to enable/disable menu groups at once. >> Currently it is not possible with MenuGroupModel (Morphic). >> >> - A menu (item or group) model manages its state using enabledHolder >> instance variable (the enabledHolder is configured in its superclass' >> initialize) >> -- Being a value holder, one might think there is a propagation of >> state (enabled/disabled) changes to subwidgets, but it does not happen >> currently. >> --- Longer explanation: On static menu building, MenuGroupModel does >> not propagate #enable: state changes to its widget because "widget" >> i.v. is nil. The reason is a MenuGroupModel #enabled: is evaluated >> BEFORE its widget is built. >> >> How to reproduce: >> | mm | >> mm := MenuModel new >> addGroup: [ :group | >> group >> addItem: [ :item | >> item >> name: 'File'; >> icon: #openIcon asIcon; >> subMenu: (MenuModel new >> addGroup: [ : gp | >> gp >> disable; " <------ HERE we >> disable the group " >> addItem: [ : it | >> it >> name: 'Open'; >> icon: #openIcon asIcon; >> shortcut: $o meta; >> action: [ self inform: 'Open' ] ]; >> addItem: [ : it | >> it >> name: 'Save'; >> icon: #smallSaveIcon asIcon; >> shortcut: $s meta; >> action: [ self inform: 'Save' ] ] ]) ] ]; >> yourself. >> mm extent: 200 @ 100. >> mm openWithSpec. >> mm inspect. >> >> (it doesn't matter if #disable is sent after the #addItem: block evaluation) >> >> - Even after all MenuGroupModel widgets were built, if you try to >> disable a menu group dinamically: >> >> mm menuGroups anyOne menuItems anyOne subMenu menuGroups anyOne disable. >> >> you would get "Instance of OrderedCollection did not understand >> #enabled:" (the widget of a MenuGroupModel is an OrderedCollection!!). >> >> - However disabling/enabling MenuItemModel works: >> >> mm menuGroups anyOne menuItems anyOne subMenu menuGroups anyOne >> menuItems first disable. >> >> - MenuItemModel gets actually disabled in the >> ToggleMenuItemMorph/UpdatingMenuMorph (#isEnabled:) when the Canvas >> draws it. >> >> - Incredibly, all disabled groups are re-enabled from several places >> in the image. >> >> -- When the menu is clicked, a ToolDockingBarMorph triggers >> re-enablement of the MenuMorph in >> #removeMatchString/#displayFiltered:. This is presumably the code >> triggered when a menu is displayed and you type to filter the menu >> items. Something like this: "As initially there is no matchString in >> the activeSubMenu, then enable all menu items". Obviously it cleans >> disabled items. >> >> The message flow is: >> >> DockingBarMorph>>activeSubmenu: -> MenuMorph>>removeMatchString -> >> MenuMorph>>displayFiltered: --> m isEnabled: isMatch >> >> - Another place where menu items are automatically disabled is this flow: >> >> FormCanvas>>draw: -> ToggleMenuItemMorph>>drawOn: --> >> ToggleMenuItemMorph>>isEnabled --> ToggleMenuItemMorph>>isEnabled: !!! >> --> MorphicMenuItemAdapter>>enabled (This actually CHANGES the >> enabled state on the Model, disconnecting enabled state between the >> morph and the model adapter) >> >> This seem to have multiple paths of resolution. I'm going to propose a >> fix that I tested in Pharo 6.1 and Pharo 7. >> I don't know yet how to fix the menu search auto-enable on key-press >> but would be glad to read a solution to distinguish between both uses. >> My idea for now is to have a Morphic property which sets >> #doNotAutoReEnableItems. >> >> However I will open an issue and let people check. >> >> You can test it with >> >> " Disable the group " >> mm menuGroups anyOne menuItems anyOne subMenu menuGroups anyOne disable. >> >> " Enable the group " >> mm menuGroups anyOne menuItems anyOne subMenu menuGroups anyOne enable. >> >> Cheers, >> >> HernÃ¡n >

Feb. 3, 2018

FileSystem copyTo:

by Stephane Ducasse

I have two folders: a/ and d/ and I want to copy file c in a but keeping its path. i.e. a/b/c copyTo: d and I want to get a/b/c and d/b/c It looks like I have to do all the logic to create intermediary folders (b) under d/ :( Stef

Feb. 3, 2018

Re: [Pharo-dev] printString of fileReference sucks!

by Stephane Ducasse

Tx I will reread the threads! On Sat, Feb 3, 2018 at 4:07 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Stephane Ducasse-3 wrote >> What do you think? > > If it helps, here is some background materialâ¦ > > - The original issue where we (I) created this behavior, along with the > rationale: > https://pharo.fogbugz.com/f/cases/7366/FileReferences-have-a-confusing-wron… > - A subsequent ML thread where we discussed this fairly extensively: > http://forum.world.st/Why-aFileReference-asString-aFileReference-fullName-i… > > FTR I am not attached to the current solution and defer to the majorityâ¦ > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Feb. 3, 2018

Re: [Pharo-dev] printString of fileReference sucks!

by Sean P. DeNigris

Stephane Ducasse-3 wrote > What do you think? If it helps, here is some background materialâ¦ - The original issue where we (I) created this behavior, along with the rationale: https://pharo.fogbugz.com/f/cases/7366/FileReferences-have-a-confusing-wron… - A subsequent ML thread where we discussed this fairly extensively: http://forum.world.st/Why-aFileReference-asString-aFileReference-fullName-i… FTR I am not attached to the current solution and defer to the majorityâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 3, 2018

Re: [Pharo-dev] MCGitlabRepository Missing

by Sean P. DeNigris

Pavel Krivanek-3 wrote > The PR was against a wrong branch. The fixed one is being validated. The class has appeared in the latest built image! The only thing left for this to work is to update Iceberg (dev-0.6 branch) where the other half of the patch lives :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 3, 2018

Re: [Pharo-dev] Disabling a MenuGroupModel

by HernÃ¡n Morales Durand

https://pharo.fogbugz.com/f/cases/21233/Disabling-a-MenuGroupModel-bug 2018-02-02 10:10 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Hi guys, > > If you develop an application window with multiple grouped menu items, > you will certainly be able to enable/disable menu groups at once. > Currently it is not possible with MenuGroupModel (Morphic). > > - A menu (item or group) model manages its state using enabledHolder > instance variable (the enabledHolder is configured in its superclass' > initialize) > -- Being a value holder, one might think there is a propagation of > state (enabled/disabled) changes to subwidgets, but it does not happen > currently. > --- Longer explanation: On static menu building, MenuGroupModel does > not propagate #enable: state changes to its widget because "widget" > i.v. is nil. The reason is a MenuGroupModel #enabled: is evaluated > BEFORE its widget is built. > > How to reproduce: > | mm | > mm := MenuModel new > addGroup: [ :group | > group > addItem: [ :item | > item > name: 'File'; > icon: #openIcon asIcon; > subMenu: (MenuModel new > addGroup: [ : gp | > gp > disable; " <------ HERE we > disable the group " > addItem: [ : it | > it > name: 'Open'; > icon: #openIcon asIcon; > shortcut: $o meta; > action: [ self inform: 'Open' ] ]; > addItem: [ : it | > it > name: 'Save'; > icon: #smallSaveIcon asIcon; > shortcut: $s meta; > action: [ self inform: 'Save' ] ] ]) ] ]; > yourself. > mm extent: 200 @ 100. > mm openWithSpec. > mm inspect. > > (it doesn't matter if #disable is sent after the #addItem: block evaluation) > > - Even after all MenuGroupModel widgets were built, if you try to > disable a menu group dinamically: > > mm menuGroups anyOne menuItems anyOne subMenu menuGroups anyOne disable. > > you would get "Instance of OrderedCollection did not understand > #enabled:" (the widget of a MenuGroupModel is an OrderedCollection!!). > > - However disabling/enabling MenuItemModel works: > > mm menuGroups anyOne menuItems anyOne subMenu menuGroups anyOne > menuItems first disable. > > - MenuItemModel gets actually disabled in the > ToggleMenuItemMorph/UpdatingMenuMorph (#isEnabled:) when the Canvas > draws it. > > - Incredibly, all disabled groups are re-enabled from several places > in the image. > > -- When the menu is clicked, a ToolDockingBarMorph triggers > re-enablement of the MenuMorph in > #removeMatchString/#displayFiltered:. This is presumably the code > triggered when a menu is displayed and you type to filter the menu > items. Something like this: "As initially there is no matchString in > the activeSubMenu, then enable all menu items". Obviously it cleans > disabled items. > > The message flow is: > > DockingBarMorph>>activeSubmenu: -> MenuMorph>>removeMatchString -> > MenuMorph>>displayFiltered: --> m isEnabled: isMatch > > - Another place where menu items are automatically disabled is this flow: > > FormCanvas>>draw: -> ToggleMenuItemMorph>>drawOn: --> > ToggleMenuItemMorph>>isEnabled --> ToggleMenuItemMorph>>isEnabled: !!! > --> MorphicMenuItemAdapter>>enabled (This actually CHANGES the > enabled state on the Model, disconnecting enabled state between the > morph and the model adapter) > > This seem to have multiple paths of resolution. I'm going to propose a > fix that I tested in Pharo 6.1 and Pharo 7. > I don't know yet how to fix the menu search auto-enable on key-press > but would be glad to read a solution to distinguish between both uses. > My idea for now is to have a Morphic property which sets > #doNotAutoReEnableItems. > > However I will open an issue and let people check. > > You can test it with > > " Disable the group " > mm menuGroups anyOne menuItems anyOne subMenu menuGroups anyOne disable. > > " Enable the group " > mm menuGroups anyOne menuItems anyOne subMenu menuGroups anyOne enable. > > Cheers, > > HernÃ¡n

Feb. 2, 2018

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Sven Van Caekenberghe

https://pharo.fogbugz.com/f/cases/21232/BenchmarkResult-printFrequencyOn-ca… https://github.com/pharo-project/pharo/pull/794 > On 12 Dec 2017, at 07:22, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > sven did you submit a fix to get a clearer printout? > > Stef > > > On Sun, Dec 10, 2017 at 7:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> @ Henrik >> >> Arg, arg, arg, yes of course. >> I actually did think about that, but still did not look carefully enough !! >> Really stupid of me. >> >> It is even worse because I wrote that code ... >> >> Now, the #printOn: of BenchmarkResult is much clearer, less confusing: >> >> ZnClient new in: [ :client | >> [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. >> >> a BenchmarkResult(14,732 iterations in 5 seconds. 2,946 per second) >> >> vs >> >> ZnClient new in: [ :client | >> client loggingOff. >> [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. >> >> a BenchmarkResult(42 iterations in 5 seconds 88 milliseconds. 8.255 per second) >> >> Still the same issue with $, and $. in frequency, but the iteration count is crystal clear. >> >> The reason #bench works like that is backwards compatibility at the time we introduced that. >> >> @ Ben >> >> Yes, I should have looked at the other side as well, to confirm things actually happened as I imagined them (the did not). >> >> Thx and sorry for the noise. >> >> Sven >> >>> On 10 Dec 2017, at 18:00, Henrik-Nergaard <draagren(a)outlook.com> wrote: >>> >>> Hi Sven, >>> >>> What you are seeing is most likely a $, vs $. issue. >>> See BenchmarkResult >>#printFrequenceOn: it uses both decimal and thousand >>> separators. >>> >>> If i run this code: >>> ----------------------------------------- >>> | counter | >>> counter := >>> ZnClient new in: [ :client | >>> client loggingOff. >>> [ client get: 'http://localhost:8080'. counter ] bench >>> ]. >>> counter. >>> ----------------------------------------- >>> >>> Then i get 9035 ('1,773 per second') when no inspector is open, and only 22 >>> ('5.995 per second') when inspecting the logs. >>> >>> Best regards, >>> Henrik >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> >> >> >

Feb. 2, 2018

Re: [Pharo-dev] Change Pharo window icon

by Eliot Miranda

Hi Stef, On Fri, Feb 2, 2018 at 11:32 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Would it be possible to change the icon without having to compile a new VM? > Through an AppleScript: e.g. https://www.sethvargo.com/replace-icons-osx/ > To me the current setup looks so monolithic and dated. > I would expect that somebody can deploy a application with its own > logo by just providing some new resources. > And that's indeed possible. Take the .app bundle and change the .icns file as described above. > > Stef > > On Wed, Jan 31, 2018 at 11:17 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Hi Vincent, > > > > On Wed, Jan 31, 2018 at 12:07 PM, <Vincent.Blondeau(a)lamresearch.com> > wrote: > >> > >> Hi, > >> > >> I would like to know how to change the main Pharo window icon. I saw > that > >> there is a primitive for the title: > >> DisplayScreen class >> primitiveWindowTitle:string: ; primitive: > >> 'primitiveHostWindowTitle' module:'HostWindowPlugin' > >> but I cannot find one for the icon. > >> Should another primitive need to be implemented? > > > > > > The icon is baked into the VM executable. So to change it one has to > build > > a VM with a different icon. > > > > On Windows it is in > > {build.win32x86,build.win64x64}/pharo.cog.spur/Pharo.ico > > and the file that specifies to use Pharo.ico is > > {build.win32x86,build.win64x64}/pharo.cog.spur/Pharo.rc > > > > On Mac OS X it is in > > platforms/iOS/vm/OSX/Pharo.icns > > (alongside three others such as PharoImage.icns) > > and the file that specifies to use Pharo.icns is > > {build.macos32x86,build.macos64x64}/pharo.cog.spur/Makefile > > in setting the VM variable. The file that associates the other icons > with > > specific file types is > > platforms/iOS//vm/OSX/Pharo-Info.plist > > > > If you're changing the Pharo icon let me suggest you update the icon > files > > themselves in the opensmalltalk-vm source tree. > > > > If you're creating a new variant of the VM for some new purpose (say a > > special Lam VM) then let me suggest you add the icons to the > > opensmalltalk-vm source tree, creating special build directories for > these > > VMs, such as {build.macos32x86,build.macos64x64}/lam.pharo.cog.spur/ > > > > If you want to do this privately, then take either of the approaches > above > > and simply don't publish the edits. You can write a script that takes an > > updated checked-out opensmalltalk-vm source tree and edits it with files > > from a specific repository. I have such scripts and can help you with > them. > > Hint, pax is a very convenient directory hierarchy copying tool > available at > > least on Mac OS X. pax -rwlk will copy the trees under a sequence of > > directories into their corresponding places in a target tree. > > > >> > >> Thanks! > >> > >> Vincent > >> > >> > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > -- _,,,^..^,,,_ best, Eliot

Feb. 2, 2018