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

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

by Ben Coman

Poking around the web bumped into a recommendation for this... https://www.zenhub.com/blog/open-source/ cheers -ben On Mon, 18 Mar 2019 at 20:08, Ben Coman <btc(a)openinworld.com> wrote: > How are issue priorities being assigned? Perhaps there could be a High > Priority board? > cheers -ben > > On Mon, 18 Mar 2019 at 15:28, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> Hi, >> >> We enabled the GitHub âProjectsâ feature for the pharo repo: >> >> https://github.com/pharo-project/pharo/projects >> >> >> The idea is that one can add as many âKanbanâ style boards as one wants. >> issues and pull requests can be added, as well as simple cards that are >> not yet issues. >> >> This is quite nice as an issue tracker gets very confusing and >> overwhelming as soon as there >> are >500 issues. >> >> With these boards, we can create âviewsâ on this sea of issues. >> >> I created for now: >> >> -> some board related to specific parts of the system (e.g. >> Traits or Reflectivity) >> example: >> https://github.com/pharo-project/pharo/projects/11 >> -> "Pharo7 Backportingâ >> >> https://github.com/pharo-project/pharo/projects/12 >> -> "Simple Issues for Beginnersâ >> >> https://github.com/pharo-project/pharo/projects/14 >> Here the feature to be able to put things that are not yet >> issue tracker entries seems very useful >> >> >> I think this can be quite niceâ¦ we should add more Projects as soon as we >> find that they make sense >> and should move issues there. >> >> Marcus >> >

March 18, 2019

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

by Ben Coman

How are issue priorities being assigned? Perhaps there could be a High Priority board? cheers -ben On Mon, 18 Mar 2019 at 15:28, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > We enabled the GitHub âProjectsâ feature for the pharo repo: > > https://github.com/pharo-project/pharo/projects > > > The idea is that one can add as many âKanbanâ style boards as one wants. > issues and pull requests can be added, as well as simple cards that are > not yet issues. > > This is quite nice as an issue tracker gets very confusing and > overwhelming as soon as there > are >500 issues. > > With these boards, we can create âviewsâ on this sea of issues. > > I created for now: > > -> some board related to specific parts of the system (e.g. Traits > or Reflectivity) > example: > https://github.com/pharo-project/pharo/projects/11 > -> "Pharo7 Backportingâ > https://github.com/pharo-project/pharo/projects/12 > -> "Simple Issues for Beginnersâ > > https://github.com/pharo-project/pharo/projects/14 > Here the feature to be able to put things that are not yet > issue tracker entries seems very useful > > > I think this can be quite niceâ¦ we should add more Projects as soon as we > find that they make sense > and should move issues there. > > Marcus >

March 18, 2019

[Pharo 8.0] Build #147: 2858-GRVariableAssignedLiteralRule-raises-exception-on-slots-not-inherited-from-IndexedSlot

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

There is a new Pharo build available! The status of the build #147 was: SUCCESS. The Pull Request #2859 was integrated: "2858-GRVariableAssignedLiteralRule-raises-exception-on-slots-not-inherited-from-IndexedSlot" Pull request url: https://github.com/pharo-project/pharo/pull/2859 Issue Url: https://pharo.fogbugz.com/f/cases/2858 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 18, 2019

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

by Stephan Eggermont

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

March 18, 2019

[Issue Trackker][Help Needed]: Move issues from Fogbugz to GitHub

by Marcus Denker

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 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

Issue Tracker: enabled Projects (Boards)

by Marcus Denker

Hi, We enabled the GitHub âProjectsâ feature for the pharo repo: https://github.com/pharo-project/pharo/projects The idea is that one can add as many âKanbanâ style boards as one wants. issues and pull requests can be added, as well as simple cards that are not yet issues. This is quite nice as an issue tracker gets very confusing and overwhelming as soon as there are >500 issues. With these boards, we can create âviewsâ on this sea of issues. I created for now: -> some board related to specific parts of the system (e.g. Traits or Reflectivity) example: https://github.com/pharo-project/pharo/projects/11 -> "Pharo7 Backportingâ https://github.com/pharo-project/pharo/projects/12 -> "Simple Issues for Beginnersâ https://github.com/pharo-project/pharo/projects/14 Here the feature to be able to put things that are not yet issue tracker entries seems very useful I think this can be quite niceâ¦ we should add more Projects as soon as we find that they make sense and should move issues there. Marcus

March 18, 2019

Esteban's ChangeLog week of 11 March 2019

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 11 March 2019 to 17 March 2019. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=11/3/2019&to=17/3/2019 ChangeLog ========= 14 March 2019: -------------- * I've been working on context menus for Spec 2. This seems like an easy task... until you see how broken it was in the previous version. In fact, in older Spec menus were inexistent. Or better: the abstraction for menus were inexistent, and instead it was just a simple exposition (at Spec level) of the Morphic menu infrastructure (which itself is not very friendly). So... I needed to reimplement everything. ... and a way to test it :( Now, I want to consider the Menu interface more in detail, since today is not very clear. Look how a Menu Bar needs to be made: ---- MenuBarPresenter new addGroup: [ :group | group addItem: [ :item | item name: 'Something 1'; action: [ "doSomething"] ]; addMenu: [ :item | item name: 'Something 2'; action: [ "doSomething"] ] ]; yourself ---- which doesn't seems to be the best approach. (Anyway, I'm not changing that just now... but I'm reflecting on it, certainly) 13 March 2019: -------------- * I made a pause of my Spec 2 current work to make a fix that was pending since some time now and it was needed to easy the migration of some projects (and its usage in windows): This [PR](https://github.com/pharo-vcs/iceberg/pull/1213) will fix [tonel issue 74](https://github.com/pharo-vcs/tonel/issues/74) cheers! Esteban

March 18, 2019

Re: [Pharo-dev] OSProcess for Pharo 7

by Ben Coman

On Mon, 18 Mar 2019 at 10:20, 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. What about this being even more generic, so child native process/threads can be viewed from the Image similar to Process Browser? I'm not entirely sure of the use case, just wild speculation something like that might be useful when Threaded-FFI arrives. cheers -ben

March 18, 2019

Re: [Pharo-dev] OSProcess for Pharo 7

by David T. Lewis

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

Re: [Pharo-dev] OSProcess for Pharo 7

by Mariano Martinez Peck

> > > > > 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 :) 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. Best regards, -- Mariano https://twitter.com/MartinezPeck http://marianopeck.wordpress.com

March 17, 2019