June 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

by Peter UhnÃ¡k

> > Commands are responsible to build menu items for themselves. By default > they build single item. But you can override method and generate multiple > items. > Look for example at ClySwitchQueryScopeCommand>>#fillContextMenu:using: > It would be nice to have a complete 1:1 example to a more-complex world menu. I see the value of using Commander, but it is (imho) order of magnitude more complex. E.g., for a trivial method that creates a parent and a child entry (aBuilder item: #Parent) icon: #plus asIcon; label: 'Parent'; parent: #MostUsedTools; keyText: 'o, p'; action: [ self doParentStuff ]. (aBuilder item: #Child) parent: #Parent; label: 'Child'; icon: #minus asIcon; keyText: 'o, c'; action: [ self doChildStuff ]. * I would need two classes, one for each command * For each line of the builder a I need a separate method (shortcut, name, icon, ...) * I need another class to represent the "parent" context (similar to CmdWorldMenuContext) * I need to know to know how Commander work to even know what I am doing -- with the current setup it is obvious and people can just copy paste and be done. I don't really think that it can be any simpler than is the current state, so any change would inevitably increase complexity. And with commander it feels like a lot of incidental complexity here. Would it be possible to somehow generate commands on the fly? Some sort of "CmdPluggableCommand" that would be populated based on the current builder? Peter

June 3, 2018

Re: [Pharo-dev] Updated syntax postcard

by Ben Coman

On 2 June 2018 at 23:26, Ben Coman <btc(a)openinworld.com> wrote: > On 1 June 2018 at 18:56, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> Hi, >> >> for the Wikipedia article I prepared an updated version of Phar syntax >> postcard: >> >> https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_sy >> ntax_postcard.svg >> > > Looks cool. I thought all the offtake lines made it a bit busy, > so I thought I'd see what it looked like without them. > Please review the result attached. > > Along the way, I ended up making a few other changes.. > > a. Rather than using #'I''m' as the symbol-string, > the similarity of #'a' to #a better highlights the differences. > 'I''m' is better as the string example since its not mixing in the > concept symbols. > > b. The word "generated" associates strongly with code generation > "runtime created array" seemed better, or just "runtime array". > > c. The description "boolean literal" and "nil literal" contain redundant > information. > > > btw, a few questions... > > d. Is a symbol a literal? > > e. Are scaled decimals, floating points, strings and characters all > literals? > Their color is different from boolean, nil and integer literals. > > cheers -ben > > I had a go at Phil's suggestions to add #select:thenCollect and #and: , which stimulated a few other changes - see attached. but I screwed up some of the line weights, and not yet sure the best way to fix them. cheers -ben

June 3, 2018

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

by Denis Kudriashov

Hi Peter. 2018-06-02 19:17 GMT+03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > > I believe we should move to Commander with first class commands. > > How would that work when menu entries can be generated dynamically? > Commands are responsible to build menu items for themselves. By default they build single item. But you can override method and generate multiple items. Look for example at ClySwitchQueryScopeCommand>>#fillContextMenu:using: > > Peter > > On Sat, Jun 2, 2018 at 1:32 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > >> On 6/1/18, Torsten Bergmann <astares(a)gmx.de> wrote: >> > >> >>Guille & Cyril wrote> >> >> > Since some decades now the default way to display a menu in >> >> > applications >> >> > is to have a bar at the top of the windows. >> > >> > >> > Alistair wrote >> >>> Instead of a menu bar at the top, which takes quite a bit of space, >> >>> and as mentioned may not fit on a small screen how about a "Start" >> >>button in the task-bar that pops up the menu a-la Windows >> > >> > >> > So this basically reduces to the two UI options: >> > >> > 1. Should Pharo look like an application (and have the menu at the top) >> > >> > 2. Should Pharo look like an OS itself (with a primary "Start" menu in >> the >> > taskbar as on Windows) >> > >> > Maybe we should support both styles using a setting. >> > >> > Bye >> > T. >> +1 >> > >> >> >

June 3, 2018

[Pharo 7.0-dev] Build #1003: 22035-Delete-PNGReadWriter-classcreateAFormFrom

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

There is a new Pharo build available! The status of the build #1003 was: SUCCESS. The Pull Request #1472 was integrated: "22035-Delete-PNGReadWriter-classcreateAFormFrom" Pull request url: https://github.com/pharo-project/pharo/pull/1472 Issue Url: https://pharo.fogbugz.com/f/cases/22035 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 3, 2018

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

by Peter UhnÃ¡k

> I believe we should move to Commander with first class commands. How would that work when menu entries can be generated dynamically? Peter On Sat, Jun 2, 2018 at 1:32 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > On 6/1/18, Torsten Bergmann <astares(a)gmx.de> wrote: > > > >>Guille & Cyril wrote> > >> > Since some decades now the default way to display a menu in > >> > applications > >> > is to have a bar at the top of the windows. > > > > > > Alistair wrote > >>> Instead of a menu bar at the top, which takes quite a bit of space, > >>> and as mentioned may not fit on a small screen how about a "Start" > >>button in the task-bar that pops up the menu a-la Windows > > > > > > So this basically reduces to the two UI options: > > > > 1. Should Pharo look like an application (and have the menu at the top) > > > > 2. Should Pharo look like an OS itself (with a primary "Start" menu in > the > > taskbar as on Windows) > > > > Maybe we should support both styles using a setting. > > > > Bye > > T. > +1 > > > >

June 2, 2018

memory leak

by John Brant

On 05/26/2018 05:21 AM, Tudor Girba wrote: > Yes, Glamour is stable since years. Yes, we did have some leak issues that appeared along the way. Last year, we discovered that a memory leak came from Rubric (specifically there was a global variable in it). People saw inspectors laying around, so naturally, the issue was seen as being due to GT. And now there is another one, which is still under investigation. For me, the main issue is not the memory leak, but the fact that we have no tool to reason about them. I found a memory leak in GLMHintableActionButtonBrick. It has an asyncTask class instance variable that holds a GLMAsyncTask. After running for a while -- opening and closing inspectors and other tools, I closed several windows, did a GC and expected to not have any AST nodes hanging around. However, I found several, so I used my ReferenceFinder tool to find a reference path. That path went through the GLMHintableActionButtonBrick to a GLMAsyncTask to a block that holds a reference to a GLMHintableActionButtonBrick instance. Following references out of the GLMHintableActionButtonBrick instance eventually leads to a NodeMorph which has a NodeModel that contained my AST node. I'm running a Pharo 7 build from a few weeks ago (Pharo-7.0+alpha.build.843.sha.edceb623c1a3ac3358f7e46ca1048d455657e10c) so this may have been fixed. John Brant

June 2, 2018

Re: [Pharo-dev] Updated syntax postcard

by Ben Coman

On 1 June 2018 at 18:56, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > for the Wikipedia article I prepared an updated version of Phar syntax > postcard: > > https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_ > syntax_postcard.svg > Looks cool. I thought all the offtake lines made it a bit busy, so I thought I'd see what it looked like without them. Please review the result attached. Along the way, I ended up making a few other changes.. a. Rather than using #'I''m' as the symbol-string, the similarity of #'a' to #a better highlights the differences. 'I''m' is better as the string example since its not mixing in the concept symbols. b. The word "generated" associates strongly with code generation "runtime created array" seemed better, or just "runtime array". c. The description "boolean literal" and "nil literal" contain redundant information. btw, a few questions... d. Is a symbol a literal? e. Are scaled decimals, floating points, strings and characters all literals? Their color is different from boolean, nil and integer literals. cheers -ben

June 2, 2018

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

by H. Hirzel

On 6/1/18, Torsten Bergmann <astares(a)gmx.de> wrote: > >>Guille & Cyril wrote> >> > Since some decades now the default way to display a menu in >> > applications >> > is to have a bar at the top of the windows. > > > Alistair wrote >>> Instead of a menu bar at the top, which takes quite a bit of space, >>> and as mentioned may not fit on a small screen how about a "Start" >>button in the task-bar that pops up the menu a-la Windows > > > So this basically reduces to the two UI options: > > 1. Should Pharo look like an application (and have the menu at the top) > > 2. Should Pharo look like an OS itself (with a primary "Start" menu in the > taskbar as on Windows) > > Maybe we should support both styles using a setting. > > Bye > T. +1 >

June 2, 2018

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

by phil＠highoctane.be

Yes, Commander should drive a lot of these things. Very useful for scripting things as well and add new macros. Phil On Fri, Jun 1, 2018, 21:06 Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Looks like Pharo 7 will be the most impressive release in all aspects of > system:). > > About pragmas: > I believe we should move to Commander with first class commands. > It requires to create command classes for all menu items. For example > "Save image": > > SaveImageCommand>>execute > > Smalltalk > snapshot: true > andQuit: false. > > SaveImageCommand class>>worldMenuActivation > <classAnnotation> > ^CmdContextMenuCommandActivation byRootGroupItemFor: > *CmdWorldMenuContext * > > SaveImageCommand class>>globalShortcutActivation > > <classAnnotation> > ^CmdShortcutCommandActivation by: $s meta shift for: > *CmdWorldMenuContext * > > It will bring reusable commands which activation can be extended > > > 2018-06-01 20:23 GMT+03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> On Fri, Jun 1, 2018 at 6:46 PM, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >> >>> Peter UhnÃ¡k wrote >>> > Pharo adds 25px margin on all sides of a full-screen window. >>> >>> Good point. I wonder why that's the case! >> >> >> According to the github issue discussion, this is the case. >> >> >>> Peter UhnÃ¡k wrote >>> > it provides the most important/common options that user needs >>> >>> Ah! Good to know and interesting, but presumably very subjective. >> >> >> For sure. But for an end-user application it is my responsibility to >> figure out the UI/UX. >> >> >>> Although it is currently flexible, I don't think we have that now. >>> >> >> The pragma collection can be filtered, but it is not used by the code, so >> it is all-or-nothing, not very flexible. I think this is for future >> iterations. >> >> Peter UhnÃ¡k wrote >>> > very often I find myself having to move windows, just so I can expose a >>> > piece of desktop to click on. >>> >>> Why don't you use the 25px margin?! ha ha j/k >>> >> >> This applies to fullscreen only. It doesn't apply when you manually move >> a window to this space. >> And for fullscreen, I often have the margin disabled. So that's why. :) >> >> Peter >> > >

June 2, 2018

Re: [Pharo-dev] Updated syntax postcard

by phil＠highoctane.be

I see & but not aBool and: [ ...] The latter is more in line with the actual usage, no? Phil On Fri, Jun 1, 2018, 12:57 Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > for the Wikipedia article I prepared an updated version of Phar syntax > postcard: > > > https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_syntax_postcard.s… > > Cheers, > -- Pavel >

June 2, 2018