March 2019 - Pharo-dev - lists.pharo.org

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

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

by ducasse

Thanks for the report. We are working on SUnit improvements. 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

Weird SUnit/TestRunner behavior

by Attila Magyar

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

Re: [Pharo-dev] Issue Tracker: enabled Projects (Boards)

by Marcus Denker

> On 18 Mar 2019, at 13:08, Ben Coman <btc(a)openinworld.com> wrote: > > How are issue priorities being assigned? Perhaps there could be a High Priority board? > cheers -ben Yes, that might be a good idea. We did not use priorities that much in the old issue tracker which means that a very simple scheme (like a board) should work, I think. > Poking around the web bumped into a recommendation for this... > https://www.zenhub.com/blog/open-source/ <https://www.zenhub.com/blog/open-source/> We tried to use Trello in the pastâ¦ with mixed success. What I like with the GitHub board is that they are right there, no need to have yet another system, yet another accountâ¦ But it would be definitely interesting to play with it. Marcus

March 18, 2019