- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Issue Trackker][Help Needed]: Move issues from Fogbugz to GitHub

by Tim Mackinnon

Marcus - do we just manually copy over the title and description (and any relevant comments) - or is there some tool to do this with? Tim > On 18 Mar 2019, at 07:38, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > We should all look at the old issues: > > https://pharo.fogbugz.com/f/filters/57/All-newest-first <https://pharo.fogbugz.com/f/filters/57/All-newest-first> > > and move them to the new one: > > https://github.com/pharo-project/pharo/issues <https://github.com/pharo-project/pharo/issues> > > instead of moving them automatically, we should take the chance to > clean up. > > Please check, first for the issues that *you* added: > > -> is it still relevant? > ->if yes: add a new issue on GitHub > ->close this issue, there is now an explicit âmoved to GitHubâ state. > > > Marcus

March 18, 2019

Is String withUnixLineEnding mutation behavior a bug?

by Ronie Salgado

Hi, I just noticed that String >> withUnixLineEndings modifies the the original string, at least when the string only has cr, and not crlf. For example, try the following (in Pharo 7) in a Playground: original :='asa' , String cr , 'asa'. newString := original withUnixLineEndings. original at: 4. Best regards, Ronie

March 18, 2019

[Pharo 8.0] Build #150: 2877-whichSelectorsAccess-and-slots

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

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

March 18, 2019

Re: [Pharo-dev] Esteban's ChangeLog week of 11 March 2019

by Esteban Lorenzano

Hi Sean, This is how the menus are done ultimately, not âthe wayâ of doing it. In general, you will do menus using something like Commander: you define commands, then you dynamically build the menus based on a context given (this is how Pharo itself will doit). - Or you build your own command library and build menus your way (see this experiment: https://github.com/estebanlm/Lieutenant/tree/try-superlight-version and its clases LtMenuBarBuilder, LtContextMenuBuilder). - Or you collect the items (MenuItemPresenter) from a pragma and you sort them some way. You are free to do as you want, but at the end, it has to have the structure described in the log :) One important things I didnât remarked, is that in Spec, all menu accessors are âvaluablesâ. Means that for example ListPresenter>>contextMenu: will receive anything that understands value and it will be executed on demand: self newList contextMenu: [ self collectMyContextMenu ]; etcâ¦. Will work as expected. (I hope this helps to understand the design better). Cheers! Esteban > On 18 Mar 2019, at 17:06, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > EstebanLM wrote >> addGroup: [ :group | >> group >> addItem: [ :item | item name: 'Something 1'; action: [ >> "doSomething"] ]; > > How would one extend a menu with this approach e.g. add an item to the group > from elsewhere (outside the block)? Is it even possible? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

March 18, 2019

[Pharo 8.0] Build #149: 2847-Implement-method-to-remove-class-side-slot

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

There is a new Pharo build available! The status of the build #149 was: FAILURE. The Pull Request #2875 was integrated: "2847-Implement-method-to-remove-class-side-slot" Pull request url: https://github.com/pharo-project/pharo/pull/2875 Issue Url: https://pharo.fogbugz.com/f/cases/2847 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 18, 2019

Re: [Pharo-dev] Esteban's ChangeLog week of 11 March 2019

by Sean P. DeNigris

EstebanLM wrote > addGroup: [ :group | > group > addItem: [ :item | item name: 'Something 1'; action: [ > "doSomething"] ]; How would one extend a menu with this approach e.g. add an item to the group from elsewhere (outside the block)? Is it even possible? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 18, 2019

Re: [Pharo-dev] OSProcess for Pharo 7

by ducasse

Thanks Dave! Guille was taking care of OSSubprocess recently. I fixed bugs and issues last year. I do not think that mariano is looking at it. Stef > On 18 Mar 2019, at 03:19, David T. Lewis <lewis(a)mail.msen.com> wrote: > > Hi Mariano, > > On Sun, Mar 17, 2019 at 08:29:59PM -0300, Mariano Martinez Peck wrote: >>> >>> ducasse wrote >>>> this is not because we do not care of Pharo that we will fix it >>>> immediately. >>> >>> Yes of course, just want to keep it on the radar (and maybe Mariano will >>> read he he) >>> >>> >> I always do :) > > Me too :-) > > >> But honestly, I don't have enough time to carry on that myself. As you >> could see with latest Guillermo pass, I reviewed every PR and tried to give >> my advice and support as much as possible. > > I saw Sean's earlier email (see below) which reminded me of your ideas about > having a child process listener that could provide child exit notifications > to both OSSubprocess and OSProcess. This seems to me to be the right thing > to do, but it would take some work by somebody (not by me, but it could > be done). > > Meanwhile, prompted by Sean's <bump>, I think maybe I see another way that > we could handle the problem, at least in the near term. > > > On Fri, Mar 15, 2019 at 01:42:26PM -0500, Sean P. DeNigris wrote: >> Max Leske wrote >>>> I was talking about OSSubProcess >>> Well, I'm not working with that at the moment ;) >> >> [OT] Just want to bump the problem that OSProcess and OSSubProcess can't >> currently be used in the same image. This is an important problem because >> users can't control which library dependencies use. Mariano hinted at a >> solution. It didn't seem like a ton of work, but it's beyond my >> understanding. >> > > I think I see another way that this can be handled for an image that > contains both OSSubprocess and OSProcess. I loaded both into a Pharo 7 > image, then added this: > > OSSVMProcess>>update: aParameter > "If subscribed to events from the OSProcess child watcher, the > changed/update: mechanism will dispatch child exit notification > here. To subscribe to notification from OSProcess add the singleton > OSSVMProcess as a dependent of the OSProcess accessor singleton. > When any child process exits, this method will be called with > parameter #childProcessStatus" > > "OSProcess accessor addDependent: OSSVMProcess vmProcess" > > (aParameter == #childProcessStatus) ifTrue: > [^ self updateActiveChildrenAndNotifyDead]. > > > I stopped the child watcher in OSSVMProcess (by commenting out the last > two lines in OSSVMProcess>>initialize just to see if this would work), > then added the changed/update: dependency with > "OSProcess accessor addDependent: OSSVMProcess vmProcess" > > After restarting the image, it appears to be working, at least so far > has having both OSP and OSSP handle their child process exits properly > in the same image. > > I don't have time to play with this any more right now, but it does > look like it might be a workable approach. It should be possible to > have the initializer for OSSVMProcess use its normal child exit handler, > but hook into the OSP handler instead if that happens to be present > in the image. > > Dave > > >

March 18, 2019

[Pharo 8.0] Build #148: 2836-removeUnreferencedKeys-is-only-there-for-the-Undeclared-mechanism-no-need-to-implement-on-other-Disctionaries

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

There is a new Pharo build available! The status of the build #148 was: FAILURE. The Pull Request #2837 was integrated: "2836-removeUnreferencedKeys-is-only-there-for-the-Undeclared-mechanism-no-need-to-implement-on-other-Disctionaries" Pull request url: https://github.com/pharo-project/pharo/pull/2837 Issue Url: https://pharo.fogbugz.com/f/cases/2836 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 18, 2019

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

by Max Leske

To answer your question: yes that has been the case for a long time. The same is true for #runCase BTW. Only #setUp is sent after #tearDown (see #prepareToRunAgain). Max On 18 Mar 2019, at 14:05, Attila Magyar wrote: > Thanks, I added the ticket. > > > > -- > Sent from: > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 18, 2019

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

by Attila Magyar

Thanks, I added the ticket. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 18, 2019