- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec menu extensibility (epicea)

by Stephane Ducasse

Tx eliot for sharing your experience with us. I will keep that in mind (I decided that I should not start something new before finishing something) So frustrating to have many not finished items. Stef On Thu, Aug 10, 2017 at 7:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Peter, > > On Thu, Aug 10, 2017 at 12:48 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >> Hi Stef, >> >> I use both a variant with an argument and without, however I have slightly >> modified PragmaMenuBuilder to support this. >> >> e.g. I have >> >> <opEditorToolbarMenu> which always adds entries to a particular menu. >> <opEditorToolbarMenu: #OPUmlClassEditorPlugin> which adds entries only >> when some particular context is active (here it would mean that the items >> are added only when ClassEditor plugin is active) >> >> (The second case can be done with a local if condition, but I found this >> to be more practical.) >> >> I don't see a benefit in having 'order' as part of the pragma, because you >> can specify the order for the menu items themselves. >> >> What I am still wondering is whether it is better to have a different >> pragma for each menu, or have the menu name as an argument. The same goes >> for differentiating pragmas between different tools. >> >> e.g. >> >> <opEditorToolBarMenu: #OPUmlClassEditorPlugin> vs <menu: #EditorToolbar >> tool: #OP context: #OPUmlClassEditorPlugin> > > > I very strongly recommend the latter. Why? If designed appropriately the > second form is used as a selector in *building* the menu. So the idea is to > have the menu builder perform the pragma to add that item to it. Then there > are many menu items in the system that use the same pragma and one can see > both senders of the pragma (which are examples of menu extensions) /and/ the > implementor(s) (which is an example of how to actually extend a menu). > > With the former one has to have somewhere that relates a specific menu to > the pragma that extends only that menu, a way of extracting that information > form that pragma, and finally a way of extending the menu. With the latter > there needs be only one version of the code that collects the pragmas for > any menu and extends that menu. It becomes a standard library feature. > > >> >> the latter seems like it's adding more complexity. > > > But when used in a real system it actually reduces complexity, and provides > examples to the user of how to define menu extensions and to implementors of > how to extend menus. VisualWorks works like this and has since 1998 when > Steve Dahl and I designed the pragma system for just this case. > > We /did/ add a grouping facility based on floating point numbers, a hack, > but a reasonable one. If you look at, say, the standard programming text > menu, which at its simplest might be > > again > undo > ----------- > cut > copy > paste > ----------- > do it > print it > debug it > ----------- > accept > cancel > ----------- > format > spawn > explain > > the grouping of related items is quite important in the menu being easy to > navigate. But if we want to extend it we wan to be able to add groups to > it. In VW we number the groups in the base menu in tens, so again/undo is > 10.0, cut/copy/paste is 20.0, etc. Then anyone can define a new group > relative to the base groups by providing a group number such as 35.0 to add > between do it/print it/debug it and accept/cancel > > > >> >> Peter >> >> >> On Wed, Aug 09, 2017 at 09:58:54PM +0200, Stephane Ducasse wrote: >> > Hi Peter >> > >> > Yes I was thinking about it. >> > Now from your experience what kind of pragma should we provide? >> > >> > <group: 'name' order: 10> >> > >> > Not sure that we need the argument to the group. >> > >> > <menusForGroup: 'name'> >> > >> > <menuForGroup: 'name' order: 10> >> > >> > Stef >> > >> > >> > >> > >> > On Sun, Aug 6, 2017 at 12:09 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> > > Hi Stef, >> > > >> > > I faced similar issue and then I've found out that PragmaMenuBuilder >> > > is compatible with Spec. >> > > >> > > Something like... >> > > >> > > builder := PragmaMenuBuilder pragmaKeyword: 'myPragma' model: self. >> > > menu := MenuModel new. >> > > menu fromSpec: builder menuSpec. >> > > >> > > Peter >> > > >> > > >> > > On Sat, Aug 05, 2017 at 06:26:45PM +0200, Stephane Ducasse wrote: >> > >> Hi guys >> > >> >> > >> I would like to know if there is a pattern to build extensible menu >> > >> in Spec. >> > >> For example, I extending Epicea to support pillar fileout so that I >> > >> can turn a coding section into a pillar steps of action. >> > >> >> > >> I wanted to extend the epicea browser to get my menu in: >> > >> But the code is like that: >> > >> >> > >> EPLogBrowserModel >> addMenuItemsForSelectedItemsIn: aMenu >> > >> >> > >> aMenu addGroup: [ :aGroup | >> > >> self menuActionsForSelectedItems do: [ :oldStyleMenuItemArray | >> > >> aGroup addItem: [ :anItem | >> > >> anItem >> > >> name: oldStyleMenuItemArray first; >> > >> description: oldStyleMenuItemArray third; >> > >> icon: (self iconNamed: oldStyleMenuItemArray fourth); >> > >> action: [ self perform: oldStyleMenuItemArray second ] >> > >> ] ] ]. >> > >> >> > >> aMenu addGroup: [ :aGroup | >> > >> aGroup addItem: [ :anItem | >> > >> anItem >> > >> name: 'Filters'; >> > >> icon: (self iconNamed: #smallFindIcon); >> > >> subMenu: self filtersSubMenu ] ]. >> > >> >> > >> aMenu addGroup: [ :aGroup | >> > >> aGroup addItem: [ :anItem | >> > >> anItem >> > >> name: 'File Out'; >> > >> description: 'Write selected entries to an Ombu file'; >> > >> icon: (self iconNamed: #smallSaveAsIcon); >> > >> action: [ self fileOutSelection ] ] ]. >> > >> >> > >> >> > >> EPLogBrowserModel >> menuMorphForSelectedItems >> > >> >> > >> | aMenu | >> > >> aMenu := MenuModel new. >> > >> showEntryItemMenu ifTrue: [ self >> > >> addMenuItemsForSelectedItemsIn: aMenu ]. >> > >> ^ aMenu buildWithSpecAsPopup >> > >> >> > >> >> > >> So I would like to improve Epicea but I face the problem of the >> > >> limits >> > >> of Spec (presumably). >> > >> I'm thinking to add a <specMenu: 10> pragma to handle this case. >> > >> Any thought. >> > >> >> > >> Stef >> > >> >> > > >> > >> > > > > -- > _,,,^..^,,,_ > best, Eliot

Aug. 10, 2017

Re: [Pharo-dev] Spec menu extensibility (epicea)

by Eliot Miranda

Hi Peter, On Thu, Aug 10, 2017 at 12:48 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi Stef, > > I use both a variant with an argument and without, however I have slightly > modified PragmaMenuBuilder to support this. > > e.g. I have > > <opEditorToolbarMenu> which always adds entries to a particular menu. > <opEditorToolbarMenu: #OPUmlClassEditorPlugin> which adds entries only > when some particular context is active (here it would mean that the items > are added only when ClassEditor plugin is active) > > (The second case can be done with a local if condition, but I found this > to be more practical.) > > I don't see a benefit in having 'order' as part of the pragma, because you > can specify the order for the menu items themselves. > > What I am still wondering is whether it is better to have a different > pragma for each menu, or have the menu name as an argument. The same goes > for differentiating pragmas between different tools. > > e.g. > > <opEditorToolBarMenu: #OPUmlClassEditorPlugin> vs <menu: #EditorToolbar > tool: #OP context: #OPUmlClassEditorPlugin> > I very strongly recommend the latter. Why? If designed appropriately the second form is used as a selector in *building* the menu. So the idea is to have the menu builder perform the pragma to add that item to it. Then there are many menu items in the system that use the same pragma and one can see both senders of the pragma (which are examples of menu extensions) /and/ the implementor(s) (which is an example of how to actually extend a menu). With the former one has to have somewhere that relates a specific menu to the pragma that extends only that menu, a way of extracting that information form that pragma, and finally a way of extending the menu. With the latter there needs be only one version of the code that collects the pragmas for any menu and extends that menu. It becomes a standard library feature. > the latter seems like it's adding more complexity. > But when used in a real system it actually reduces complexity, and provides examples to the user of how to define menu extensions and to implementors of how to extend menus. VisualWorks works like this and has since 1998 when Steve Dahl and I designed the pragma system for just this case. We /did/ add a grouping facility based on floating point numbers, a hack, but a reasonable one. If you look at, say, the standard programming text menu, which at its simplest might be again undo ----------- cut copy paste ----------- do it print it debug it ----------- accept cancel ----------- format spawn explain the grouping of related items is quite important in the menu being easy to navigate. But if we want to extend it we wan to be able to add groups to it. In VW we number the groups in the base menu in tens, so again/undo is 10.0, cut/copy/paste is 20.0, etc. Then anyone can define a new group relative to the base groups by providing a group number such as 35.0 to add between do it/print it/debug it and accept/cancel > Peter > > > On Wed, Aug 09, 2017 at 09:58:54PM +0200, Stephane Ducasse wrote: > > Hi Peter > > > > Yes I was thinking about it. > > Now from your experience what kind of pragma should we provide? > > > > <group: 'name' order: 10> > > > > Not sure that we need the argument to the group. > > > > <menusForGroup: 'name'> > > > > <menuForGroup: 'name' order: 10> > > > > Stef > > > > > > > > > > On Sun, Aug 6, 2017 at 12:09 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > Hi Stef, > > > > > > I faced similar issue and then I've found out that PragmaMenuBuilder > is compatible with Spec. > > > > > > Something like... > > > > > > builder := PragmaMenuBuilder pragmaKeyword: 'myPragma' model: self. > > > menu := MenuModel new. > > > menu fromSpec: builder menuSpec. > > > > > > Peter > > > > > > > > > On Sat, Aug 05, 2017 at 06:26:45PM +0200, Stephane Ducasse wrote: > > >> Hi guys > > >> > > >> I would like to know if there is a pattern to build extensible menu > in Spec. > > >> For example, I extending Epicea to support pillar fileout so that I > > >> can turn a coding section into a pillar steps of action. > > >> > > >> I wanted to extend the epicea browser to get my menu in: > > >> But the code is like that: > > >> > > >> EPLogBrowserModel >> addMenuItemsForSelectedItemsIn: aMenu > > >> > > >> aMenu addGroup: [ :aGroup | > > >> self menuActionsForSelectedItems do: [ :oldStyleMenuItemArray | > > >> aGroup addItem: [ :anItem | > > >> anItem > > >> name: oldStyleMenuItemArray first; > > >> description: oldStyleMenuItemArray third; > > >> icon: (self iconNamed: oldStyleMenuItemArray fourth); > > >> action: [ self perform: oldStyleMenuItemArray second ] > ] ] ]. > > >> > > >> aMenu addGroup: [ :aGroup | > > >> aGroup addItem: [ :anItem | > > >> anItem > > >> name: 'Filters'; > > >> icon: (self iconNamed: #smallFindIcon); > > >> subMenu: self filtersSubMenu ] ]. > > >> > > >> aMenu addGroup: [ :aGroup | > > >> aGroup addItem: [ :anItem | > > >> anItem > > >> name: 'File Out'; > > >> description: 'Write selected entries to an Ombu file'; > > >> icon: (self iconNamed: #smallSaveAsIcon); > > >> action: [ self fileOutSelection ] ] ]. > > >> > > >> > > >> EPLogBrowserModel >> menuMorphForSelectedItems > > >> > > >> | aMenu | > > >> aMenu := MenuModel new. > > >> showEntryItemMenu ifTrue: [ self > > >> addMenuItemsForSelectedItemsIn: aMenu ]. > > >> ^ aMenu buildWithSpecAsPopup > > >> > > >> > > >> So I would like to improve Epicea but I face the problem of the limits > > >> of Spec (presumably). > > >> I'm thinking to add a <specMenu: 10> pragma to handle this case. > > >> Any thought. > > >> > > >> Stef > > >> > > > > > > > -- _,,,^..^,,,_ best, Eliot

Aug. 10, 2017

Re: [Pharo-dev] Updating the CI

by Guillermo Polito

This is done. Everything is working well. I closed the issue. https://pharo.fogbugz.com/f/cases/edit/20299/ On Thu, Aug 10, 2017 at 11:56 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hi all, > > I'm updating some CI plugins right now. Will notify as soon as everything > is smooth again. The issue related to the update is here: > > https://pharo.fogbugz.com/f/cases/20299/Update-CI-plugins- > to-latest-git-plugins > > (yes, we have an issue so we can keep track of the plugins we have) > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 10, 2017

Writeup: how to contribute to Pharo

by Guillermo Polito

Hi, I've made some write up for the pharo part (not metacello or external projects) https://github.com/guillep/PharoIntegrationProcess/wiki/ Contribute-a-fix-to-Pharo Of course, expect bugs on it :) Not everything is smooth. If you have comments, they are welcome. Guille -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 10, 2017

Re: [Pharo-dev] Impediment to contributing

by Guillermo Polito

Hi, I've made some write up for the pharo part (not metacello or external projects) https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… Of course, expect bugs on it :) Not everything is smooth. If you have comments, they are welcome. Guille On Thu, Aug 10, 2017 at 4:01 PM, stephan <stephan(a)stack.nl> wrote: > I feel frustrated, and blocked in contributing. > I miss up to date information on how to cleanly > install Pharo so that I can use Iceberg with > Metacello, and the process to use to contribute > to both Pharo itself and to the different > projects on github. > Every time I try to do something that comes > close to using git, I run into issues. > > Stephan > > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 10, 2017

Impediment to contributing

by stephan

I feel frustrated, and blocked in contributing. I miss up to date information on how to cleanly install Pharo so that I can use Iceberg with Metacello, and the process to use to contribute to both Pharo itself and to the different projects on github. Every time I try to do something that comes close to using git, I run into issues. Stephan

Aug. 10, 2017

[Pharo 70] build 25 / PR 182

by Pavel Krivanek

Hi, next Pharo 7 build is available: https://pharo.fogbugz.com/f/cases/20286/Bootstrap- packages-are-dirty-in-a-fresh-image https://github.com/pharo-project/pharo/pull/182 -- Pavel

Aug. 10, 2017

vm crash when using rairedTo: with fractions

by Andrei Chis

Hi, I was executing this code '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10. Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash. Cheers, Andrei 0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger 0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger 0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger 0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger 0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger 0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger 0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009 0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction 0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction 0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction 0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject 0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler 0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor 0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor 0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri enderer 0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm 0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm 0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState 0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState 0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState 0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph 0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState 0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState 0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph 0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class 0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager 0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure

Aug. 10, 2017

Re: [Pharo-dev] post-download preparation of Pharo 7 image

by Guillermo Polito

On Thu, Aug 10, 2017 at 11:55 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > currently we are fighting with several issues that make contributions to > Pharo 7 much more complicated than we would like. Even in case you have no > troubles with long paths (on Windows) nor SSH keys, it is now not easy now > to start to contribute or review pull requests. > > Let's say you already have: > - a Github fork of pharo-project/pharo repository > - a local clone of pharo-project/pharo repository on your disk > - this repository has a 'remote' pointing to your fork that is named by > your GitHub user name > > During bootstrap the Iceberg registers a repository from which the image > was bootstrapped and binds Monticello working copies history to it. This > repository is hidden by default, to see it in the repositories list you > need to enable Iceberg setting named 'Include system repositories by > default'. If you will do it, you will see that this repository is red. You > need to manually set the real path to you local clone (Edit). > > Then you should set your fork as default push target (in Iceberg: select > 'pharo' repository - 'Remotes' tab - context menu on your fork remote - > Make default push remote). > > It is good to synchronize your fork with the origin so it will contain > recent commits on the development branch. You can do it by doing PULL from > the origin (pharo-project/pharo) and PUSH to your fork. The alternative is > to create a pull request from the original repository to your fork in the > GitHub web interface and then let merge it) > > The next optional step is to checkout the particular commit hash from > which the image was bootstrapped. It is optional because the Iceberg now > supports cherry picking so you can avoid of committing changes you do not > want. But to start your branches from a state when the image working copy > is in sync with the git working copy is of course cleaner. > > Currently the bootstrapped image has some packages that are marked as > dirty and it will make mess if you will try to commit your changes. You can > avoid it by reloading of these dirty packages. This will be not needed in > future. > > All these steps you can automatized by the following code. You need to at > least customize your repository clone path and GitHub user name. It is > supposed to be run only once on freshly downloaded Pharo 7 image. > > | location userName pharoRepository fork | > > location := '/path/to/your/pharo/repository'. > userName := 'github-user-name'. > > Iceberg showSystemRepositories: true. > pharoRepository := IceRepository registry detect: [ :each | each name = > 'No name' ]. > pharoRepository location: location asFileReference. > fork := pharoRepository remotes detect: [ :remote | remote remoteName = > userName ]. > pharoRepository pushRemote: fork. > pharoRepository pullRemote: pharoRepository origin. > > pharoRepository checkoutBranch: 'development'. > pharoRepository backend pullFrom: pharoRepository origin. > Take into account this particular two lines can break your working copy if you have uncommited changes. > pharoRepository push. > pharoRepository checkoutBranch: (SystemVersion current commitHash). > > [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded > and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning do: > [ :warning | warning resume: true ] > And this is a patch because bootstrapped images have 3 dirty packages. We should just fix the issue instead of patching it. In any case, I vote to put this in the Pharo plugin in iceberg. > > > As the result you should get a clean image based on the latest code that > is ready to to create or review pull requests. > > Cheers, > -- Pavel > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 10, 2017

Updating the CI

by Guillermo Polito

Hi all, I'm updating some CI plugins right now. Will notify as soon as everything is smooth again. The issue related to the update is here: https://pharo.fogbugz.com/f/cases/20299/Update-CI-plugins-to-latest-git-plu… (yes, we have an issue so we can keep track of the plugins we have) -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 10, 2017