- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] ZnBufferedReadStream and #upToAll:

by Eric Gade

Hi Sven, I am really curious why you need it ? > This came up for me when I was trying to parse out pieces of a PDF file. As you likely know, the PDF format has both text and binary information encoded within it. I had used #upToAll: in the past to find sequences of "magic bytes" that don't occur in the middle of a file. It seems that the buffered read stream is what you get if you send #binaryReadStream to a FileReference. But you're right â I could just convert streams and do it that way (if you have other techniques you use, please send along). #upToAll: would definitely be complicated to implement in the buffered version! On Mon, Mar 18, 2019 at 5:11 AM Stephan Eggermont <stephan(a)stack.nl> wrote: > ducasse <stepharo(a)netcourrier.com> wrote: > > > > I imagine that sven did not add it because on infinite stream it does > not make sense. > > Now it would be good to see how we can have useful extensions. But I let > this to sven. > > That sounds like something that would be useful to make explicit: > isInfinite, with blocking, returning nil, returning null objects, or > returning errors as possible expected behaviors? > > Stephan > > > > > -- Eric

March 18, 2019

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

by ducasse

You can add a ticket in DrTests in JulienDelplanque repo on github. https://github.com/juliendelplanque/DrTests <https://github.com/juliendelplanque/DrTests> Stef > On 18 Mar 2019, at 13:35, Attila Magyar <m.magyar3(a)gmail.com> wrote: > > Hi, > > This was originally reported as a BabyMock bug but it looks like it effects > normal test cases as well. > > Let's say I have a test like this: > > MyTest>>initialize > super initialize. > s := OrderedCollection new. "note that this is initialized here not in > the setUp as we normally do" > > MyTest>>testWhatever > s add: 42. > 1 / 0. > > Open the Test Runner tool, run the test, it'll fail as expected. Now click > on the failed test (in the test runner window) and the debugger will popup > saying that #add: was sent to nil. Instance variables are cleared out after > a test run but initialize is not called before running it again. Is this > expected? The same doesn't cause any problems when I run it from the System > Browser. > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

March 18, 2019