Hi Doru,
> On Jan 11, 2019, at 4:53 AM, Tudor Girba <[email protected]> wrote: > > Hi, > > @Eliot: Thanks for the clarifying answer. > > I believe you might have jumped to conclusion about the intention of the > question. Thomas asked a legitimate question. Without users of a method it is > hard to understand its use. It does not necessarily imply that the intention > is to remove it, but it does show that someone wants to understand. Indeed. I am responding because of the recent experience we had, that you are intimately aware of, of moving the somewhat functional Pharo 6 VMMaker port forward to Pharo 7, which is frustrating because enough things changes that it was broken. And that is far from an isolated experience. I want very, very much for Pharo to succeed. It is the most important user of the opensmalltalk-vm by far. If Pharo fails, opensmalltalk-vm will very likely become entirely irrelevant and uninteresting. So my career and financial security are wedded to Pharo’s success. At the same time I do not feel positive about Pharo, as I have said, in its stability and in the community’s difficulty in discussing problems (primarily the stability and development model issues). I am therefore very much interested in solving these problems. So if I jump to conclusions it is because I am concerned and want to change how I feel about Pharo as a viable platform for my work, and that means being able to talk about difficult issues and not be shushed. I want there to be constructive discussion, not defensiveness or blithe positivity. Progress depends on truth and ingenuity, not positive thinking. > > As far as I know, Thomas actually wants to write a test to cover that usage. > I am sure that you appreciate and encourage that :). Indeed I do! > > @Thomas: Thanks for this effort! > > Cheers, > Doru > > >> On Jan 10, 2019, at 3:11 PM, Eliot Miranda <[email protected]> wrote: >> >> Hi Thomas, >> >>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev >>> <[email protected]> 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. > > -- > www.feenk.com > > “The smaller and more pervasive the hardware becomes, the more physical the > software gets." > >
