- Pharo-dev - lists.pharo.org

[Pharo 7.0] Build #130: 22896-Creating-methods-in-a-subclass-with-a-class-using-a-trait
by ci-pharo-ci-jenkins2＠inria.fr Jan. 18, 2019

Jan. 18, 2019

There is a new Pharo build available! The status of the build #130 was: FAILURE. The Pull Request #2266 was integrated: "22896-Creating-methods-in-a-subclass-with-a-class-using-a-trait" Pull request url: https://github.com/pharo-project/pharo/pull/2266 Issue Url: https://pharo.fogbugz.com/f/cases/22896 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Some clarifications (was DebugSession>>activePC:)
by ducasse Jan. 17, 2019

Jan. 17, 2019

Hi Eliot I would like to make some clarifications. Preamble: -------------- I was thinking that I should not reply but I think that I have the right to clarify a bit because I do not like several points. I reply as Stef "the guy that had the vision of Pharo and that spent 10 years pushing and building Pharo.â So I think that it makes me credible enough. My points: ------------- - With you this is always the same: Iâm too emotional and it ends everything. Stephane is emotional so we cannot communicate with him. You often place yourself as a professional and that Iâm emotional. Could you stop this little game because to me it starts to be a bit boring? Or I will just put a filter and trash systematically your emails. - Last week you told us that time bombing our process was a bad idea in an answer about settings keeping references instead of releasing them. First this had nothing to do with the problem. You see P7 was delayed because we considered that the system was not ready but P7 should be released. May I make the remark that the world is using time-based delivery? - About CMake, you may be right that makefile is better than CMake but a part of the world is using CMake and the net result is that we lost our effort and infrastructure just to follow you. Ronie uses CMake. Igor which I consider as a talented developer used CMake because he thought it was the best tool he should use. - About infrastructure and process. I wanted to check the REplugin this week end because we should use it since the world is using Perl reg-expression and I could not find the code of the plugin on github. I saw that some plugin code is not even versioned and only available on a strange ftp and it was surprising to me. Iâm still surprised that after 3 years (when esteban requested that all plugin code are grouped together in a single place, this is still not the case). - Did it not look strange to you that Esteban left the VM list in the past? Esteban looks like a reasonable and stable person to me. - You are systematically telling to me that Iâm offended when people criticized us. Iâm not offended by critics. We are not offended by critics. We have internal emails that are much more violent about our own process. We are not blind and we reflect on our own process and we invite people to REPORT problems. Now we ask people to be credible when they do it because we are busy - report situation - step by step reproducibility - proportionality of the voice versus the problem - and not been offensive We did not see any official reports about problems that we may have introduced. - You are vocal about âinstability". And you report that one method changed. Seriously? Are you not exagerating a bit? Let us talk about instability: - When we talk about instability we talk about the fact that we cannot use for real ephemerons because they corrupt the memory and that we get random crash. - We had instability when we have memory leaks that randomly slows down Pharo. - We had instability which delays our release with a bug in FFI that made cairo crash on windows 64 bits. If you want to interact with us (and not only me, because Iâm the tip of the iceberg and many people are frustrated by your attitude), let us start with positive communication and attitude: - You express your problems and we see how we (together) can fix them. - You can contribute by writing tests and by entering bug entries in the bug tracker. About Pharo: ââââââââ We understand that some people do not like it but we do not force anybody use and make business with it. Now I want to make something super clear: Pharo will not sacrifice agility and improvements on the altar of compatibility with Squeak. Pharo will change because Pharo is agile and because many things should be improved. We pay real attention about backwards compatibility. Much more than people think. Because we have many external projects and libraries that we support. Now if Pharo is used to build the VM then we will have to find a way to pay attention. And we will reinvest in building a process that checks this. Our problem is that integration time cannot take hours and right now validating Pharo is a bit too long. We will work on it. We strongly advocate to invest in tests. Tests are a good mechanisms to support evolution. If you have tests we can automatically rewrite deprecated methods and we will use this more often. We finally start to have: - a better compiler and not an ancient one which reported error as Morph. - a better architecture, more modular - a real bootstrap (we should improve it and build tools to support it - we are working on it) - strong libraries (File, Stream, HTTP) more documented and tested - better tools (Iceberg and Calypso are definitively steps in the right direction) And we will continue to improve. We will iterate on all these to make Pharo even better. We are writing more tests to support those changes. I repeat it: I think that we are doing a pretty good job about the quality that we deliver. Stef > On 11 Jan 2019, at 18:54, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Stef, > >> On Jan 10, 2019, at 7:59 AM, ducasse <stepharo(a)netcourrier.com> wrote: >> >> Eliot I would like also two points to this. >> >> - First we asked thomas to write tests about the debugger model and you see if they would be tests about methods we could understand >> that they are used and control what they do. So we should all thank thomas for his energy in this not so easy task. >> >> - Second it would be nice if you could refrain to be systematically negative about what we are doing. I think that our development process >> is much better than many others :) It is not perfect because this does not exist. >> I think that we are doing a great job make Smalltalk cool. And yes it may happen that one untested, undocumented method >> get lost. I think that we are doing pretty good given the resources we have. > > Even more serious an issue for the Pharo community than a development process which fails to support the Nedâs of users is a defensive attitude that does not want to discuss serious issues maturely. I bring up the stability and backward-portability issue because it is *important*; it has affected ClÃ©mentâs ability to deliver Sista and my and feenkâs efforts to support VM development on Pharo. If your response to my trying to discuss seriously and objectively a problem that needs discussion is always to say âplease donât be negativeâ I have even less confidence that Pharo can be a realistic platform for my work and the work of others. > > >> Stef >> >>> On 10 Jan 2019, at 15:11, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> Hi Thomas, >>> >>>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >>>> >>>> <mime-attachment> >>> >>> in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc. >>> >>> Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al. >>> >>> So the distinction is important and the utility method is probably useful. >>> >>> Do you want to remove the method simply because there are no senders in the image? >>> >>> If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed. >>> >>> Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable. >> >> >>

3 3

Re: [Pharo-dev] [ANN] Preparing for release. No more PRs will be accepted on P7.
by Esteban Lorenzano Jan. 17, 2019

Jan. 17, 2019

Hi, > On 17 Jan 2019, at 20:19, Torsten Bergmann via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: "Torsten Bergmann" <astares(a)gmx.de> > Subject: Aw: [Pharo-dev] [ANN] Preparing for release. No more PRs will be accepted on P7. > Date: 17 January 2019 at 20:19:28 CET > To: pharo-dev(a)lists.pharo.org > Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > > Hi Esteban, > > Good news that we get closer to a release. :) > > What is still the most annoying problem is that inbetween the build number had a hard reset during the switch to an "RC1" candidate > or after - so build numbers are currently at around "129" as you can see on the mails to the list. Yes, but we do not have a solution for this. Each branch has a different build number and is not possible to tweak it. > > The last shown by Pharo Launcher is 1436 builds with a Pharo 701436. > > This is not only confusing - but still breaks the launcher download. Or did I miss something? The download is broken not for that. Christophe is working in a new version of PL with that problem fixed. Cheers! Esteban > > Thanks > Torsten > >> Gesendet: Donnerstag, 17. Januar 2019 um 16:18 Uhr >> Von: "Esteban Lorenzano" <estebanlm(a)gmail.com> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: [Pharo-dev] [ANN] Preparing for release. No more PRs will be accepted on P7. >> >> Unless is a show stopper, of course! >> >> Please redirect your PRs to the branch Pharo8.0. >> >> Esteban >> >> > > >

1 0

[ANN] Preparing for release. No more PRs will be accepted on P7.
by Esteban Lorenzano Jan. 17, 2019

Jan. 17, 2019

Unless is a show stopper, of course! Please redirect your PRs to the branch Pharo8.0. Esteban

2 1

[Pharo 8.0] Build #13: 2259-INVALID-ISSUE
by ci-pharo-ci-jenkins2＠inria.fr Jan. 17, 2019

Jan. 17, 2019

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

1 0

[Pharo 8.0] Build #12: 2193-SystemNavigation-should-use-Smalltalk-globals-but-environment-since-it-has-such-instance-variable
by ci-pharo-ci-jenkins2＠inria.fr Jan. 17, 2019

Jan. 17, 2019

There is a new Pharo build available! The status of the build #12 was: FAILURE. The Pull Request #2265 was integrated: "2193-SystemNavigation-should-use-Smalltalk-globals-but-environment-since-it-has-such-instance-variable" Pull request url: https://github.com/pharo-project/pharo/pull/2265 Issue Url: https://pharo.fogbugz.com/f/cases/2193 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0] Build #129: Fixes Issue #2256 Recover parameter names, remove unneeded temps in Character
by ci-pharo-ci-jenkins2＠inria.fr Jan. 17, 2019

Jan. 17, 2019

There is a new Pharo build available! The status of the build #129 was: SUCCESS. The Pull Request #2257 was integrated: "Fixes Issue #2256 Recover parameter names, remove unneeded temps in Character" Pull request url: https://github.com/pharo-project/pharo/pull/2257 Issue Url: https://pharo.fogbugz.com/f/cases/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0] Build #128: 2254 leftover halts
by ci-pharo-ci-jenkins2＠inria.fr Jan. 17, 2019

Jan. 17, 2019

There is a new Pharo build available! The status of the build #128 was: FAILURE. The Pull Request #2255 was integrated: "2254 leftover halts" Pull request url: https://github.com/pharo-project/pharo/pull/2255 Issue Url: https://pharo.fogbugz.com/f/cases/2254 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] CMake
by Esteban Lorenzano Jan. 17, 2019

Jan. 17, 2019

Hi, Yes, when we had the CMake files, I used to generate an Xcode project to work on macOS. This was very good for work/debug. > On 17 Jan 2019, at 03:21, Ben Coman via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Ben Coman <btc(a)openinworld.com> > Subject: CMake > Date: 17 January 2019 at 03:21:18 CET > To: Pharo Development List <pharo-dev(a)lists.pharo.org>, Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > > On Thu, 17 Jan 2019 at 06:17, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > - About CMake, you may be right that makefile is better than CMake but a part of the world is using > CMake and the net result is that we lost our effort and infrastructure just to follow you. Ronie uses CMake. > Igor which I consider as a talented developer used CMake because he thought it was the best tool > he should use. > > Yes, and I disagree about the way that they use it, and for good reason. I have defended my use of Makefiles for a long time, for objective reasons. > > These reasons may be technically correct, but in terms of *community* consider it similar to premature optimization. > For yourself, the priority is a faster build. Others may prioritize a faster coding workflow using an IDE like Visual Studio. > Indeed, back when I trialed building minheadless on Windows a *primary* consideration was that it looked easy to > use Visual Studio because minheadless had a CMake build. That led to me contributing a couple of small fixes for win64, > but without the enticement of CMake I might never have opened that box. > > Consider then the possibility that a portion of our Windows using community remains untapped > because their skill set is Visual Studio and they don't see an easy path to using it with plain makefiles**. > So it depends on what is better for the *community* to optimize for: > * faster build-time for incumbents (important because thats where the majority of contributions come from) > * broader community involvement with a workflow accelerating IDE (important because growing the vm community is important, from which additional core devs may arise) > > ** I do understand that plain makefiles can be used with VS, but I'm not clear on the setup and > unsure if all the fancy intellisense tools work. > > I have also proposed good ways for using CMake (to derive a platform-specific header file defining available platform-specific features). > > I presume its the additional multi-build-system features that people want CMake for, not just the using it in name only. > I can't remember the trade-off between Automake-configure and CMake-configure. Make using CMake-configure > would make it easier to co-ordinate parallel CMake and GnuMake systems. I think I've noticed several large > code-bases providing both (but I'd have to check) > > > But my objection to Igor's process was that he generated sources on each build. > > > And my objections to Ronie's use of CMake for the minheadless build are that a) it is slow and > > I'd like to quantify that. > @esteban, I remember you converted minheadless from CMake to Gnumake, but I'm not sure if I've got that right. > Can both be run off the current HEAD for minheadless? Or I could compare HEAD with a previous commit that had CMake. I do not understand you question :) What is now in head should be the result of my(our, with Ronie) work. Esteban > > > b) explicit feature sets are much better than the implicit feature sets that arise when using CMake. > > I'd like to understand this better. Could you expand? > > cheers -ben > >

2 1

[Pharo 7.0] Build #127: 22897-Restore-getEnv-with-a-deprecation
by ci-pharo-ci-jenkins2＠inria.fr Jan. 17, 2019

Jan. 17, 2019

There is a new Pharo build available! The status of the build #127 was: FAILURE. The Pull Request #2252 was integrated: "22897-Restore-getEnv-with-a-deprecation" Pull request url: https://github.com/pharo-project/pharo/pull/2252 Issue Url: https://pharo.fogbugz.com/f/cases/22897 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0