- Pharo-dev - lists.pharo.org

[Pharo 7.0] Build #129: Fixes Issue #2256 Recover parameter names, remove unneeded temps in Character

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

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…

Jan. 17, 2019

[Pharo 7.0] Build #128: 2254 leftover halts

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

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…

Jan. 17, 2019

Re: [Pharo-dev] CMake

by Ben Coman

On Thu, 17 Jan 2019 at 17:20, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 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> > 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. > When Ronnie first announced minheadless it was pure Cmake. I thought subsequently added Gnumake files to align with the current build system, but I wasn't clear if the CMake build was still working, so a timing comparison could be done between them. cheers -ben

Jan. 17, 2019

Re: [Pharo-dev] Purpose of VM [was: Re: Better management of encoding of environment variables]

by Nicolas Cellier

To be clear, I do not militate for putting everything in the VM. I prefer a lean VM. I'm cleaning what already exist in the VM. If something is in the VM, then it should behave as we expect from a VM: uniformely. A small fix in existing code base is more efficient than a full rewrite. But if a full rewrite is wanted for other reasons, no problem. Le jeu. 17 janv. 2019 Ã 02:00, Martin McClure <martin(a)hand2mouse.com> a Ã©crit : > On 1/16/19 1:24 AM, Nicolas Cellier wrote: > > IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion > > because the purpose of a VM is to provide an OS independant faÃ§ade. > > I have not looked at this particular problem in detail, so I have no > opinion on whether the VM is the right place for this particular > functionality. > > It is not in the VM currently, only in OSProcessPlugin (and Windows variant). If some other plugins would depend on environment variables, then it might be interesting to provide this feature as a VM service. I don't know if it is the case. Also, some platform could have other strategies like querying the Registry in windows, a configuration file, etc... So we might provide a service for the basic or multi-level policy. However, I feel that in general trying to put everything that might be > OS-specific into the VM is not the best design. To me, the purpose of a > Smalltalk VM is to present an object-oriented abstraction of the > underlying machine. > Thinking that way leads me to believe that the following are examples of > things that are good for a VM to do: > > * Memory is garbage-collected objects, not bytes. > > * Instructions are bytecodes, not underlying machine instructions. > > This works well to hide the differences between machine instruction > sets, memory access, and other low-level things. However, no Smalltalk > implementation that I know of has been able to use the VM to iron out > all differences between different OSes. > > Files? Sockets? Until the threaded FFI is consolidated, there is a category of async algorithms that we cannot easily program at image side. I do believe that it is a good idea to have cleanly-designed layers of > the system, and that there should be an OS-independent layer and an > OS-dependent layer with clean separation. But I think it might be better > to put most of the OS-dependent layer in the image rather than in the > VM. For one thing, the image is easier to change if there is a bug, or a > lacking feature, or you're trying to support a new OS. > > For supporting a new OS, I'm not sure. Having an "edit on known platform-save-resume on new platform-crash" cycles is not a pleasure. Well for certain persons, the pleasure can be proportional to the hurdle height ;) You must have the bare minimum services (GUI) running before pleasure comes back. A Smalltalk without an IDE is not superior to C with a good IDE. Trial and error is not superior to a good debugger. And if it's in the image you get to do the programming in Smalltalk > rather than C or Slang, which is more fun for most of us. And, let's > face it, fun is an important metric in an open-source project -- things > that are fun are much more likely to get done. > > Regards, > > -Martin > > For example, the first time I wrote something like Smallapack, there was no choice: it was thru user defined primitives (st80 or Objectworks). So I had to write a wrapper in C code for each function exposed, with all the marshalling of arguments in C! When came DLLCC it became more fun. But this does not apply to every library. If the library depends on tons of preprocessors definitions, macros, then we currently lack tools for performing an efficient job at image side. Some possible tools have been sketched in those mailing list, but so far, they are virtual.

Jan. 17, 2019

Re: [Pharo-dev] CMake

by Esteban Lorenzano

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

Jan. 17, 2019

[Pharo 7.0] Build #127: 22897-Restore-getEnv-with-a-deprecation

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

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…

Jan. 17, 2019

CMake

by Ben Coman

On Thu, 17 Jan 2019 at 06:17, Eliot Miranda <eliot.miranda(a)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. 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

Jan. 17, 2019

Purpose of VM [was: Re: Better management of encoding of environment variables]

by Martin McClure

On 1/16/19 1:24 AM, Nicolas Cellier wrote: > IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion > because the purpose of a VM is to provide an OS independant faÃ§ade. I have not looked at this particular problem in detail, so I have no opinion on whether the VM is the right place for this particular functionality. However, I feel that in general trying to put everything that might be OS-specific into the VM is not the best design. To me, the purpose of a Smalltalk VM is to present an object-oriented abstraction of the underlying machine. Thinking that way leads me to believe that the following are examples of things that are good for a VM to do: * Memory is garbage-collected objects, not bytes. * Instructions are bytecodes, not underlying machine instructions. This works well to hide the differences between machine instruction sets, memory access, and other low-level things. However, no Smalltalk implementation that I know of has been able to use the VM to iron out all differences between different OSes. I do believe that it is a good idea to have cleanly-designed layers of the system, and that there should be an OS-independent layer and an OS-dependent layer with clean separation. But I think it might be better to put most of the OS-dependent layer in the image rather than in the VM. For one thing, the image is easier to change if there is a bug, or a lacking feature, or you're trying to support a new OS. And if it's in the image you get to do the programming in Smalltalk rather than C or Slang, which is more fun for most of us. And, let's face it, fun is an important metric in an open-source project -- things that are fun are much more likely to get done. Regards, -Martin

Jan. 17, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Eliot Miranda

Hi Sven, On Wed, Jan 16, 2019 at 2:37 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Still, one of the conclusions of previous discussions about the encoding > of environment variables was/is that there is no single correct solution. > OS's are not consistent in how the encoding is done in all (historical) > contexts (like sometimes, 1 env var defines the encoding to use for others, > different applications do different things, and other such nice stuff), and > certainly not across platforms. > > So this is really complex. > > Do we want to hide this in some obscure VM C code that very few people can > see, read, let alone help with ? > > The image side is perfectly capable of dealing with platform differences > in a clean/clear way, and at least we can then use the full power of our > language and our tools. > Agreed. At the same time I think it is very important that we don't reply on the FFI for environment variable access. This is a basic cross-platform facility. So I would like to see the environment accessed through primitives, but have the image place interpretation on the result of the primitive(s), and have the primitive(s) answer a raw result, just a sequence of uninterpreted bytes. VisualWorks takes this approach and provides a class UninterpretedBytes that the VM is aware of. That's always seemed like an ugly name and overkill to me. I would just use ByteArray and provide image level conversion from ByteArray to String, which is what I believe we have anyway. > > On 16 Jan 2019, at 10:59, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > Hi Nicolas, > > > > On Wed, Jan 16, 2019 at 10:25 AM Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion > because the purpose of a VM is to provide an OS independant faÃ§ade. > > I made progress recently in this area, but we should finish the > job/test/consolidate. > > > > I'm following your changes for windows from the shadows and I think they > are awesome :). > > > > If someone bypass the VM and use direct windows API thru FFI, then he > takes the responsibility, but uniformity doesn't hurt. > > > > So far we are using FFI for this, as you say we create first > Win32WideStrings from utf8 strings and then we use ffi calls to the *W > functions. > > I don't think we can make it for Pharo7.0.0. The cycle to build, do some > acceptance tests, and then bless a new VM as stable is far too long for our > inminent release :). > > > > But this could be for a 7.1.0, and if you like I can surely give a hand > on this. > > > > Guille > > > -- _,,,^..^,,,_ best, Eliot

Jan. 16, 2019

Re: [Pharo-dev] Some clarifications (was DebugSession>>activePC:)

by Eliot Miranda

Hi Stef, thanks for taking the time to respond so thoughtfully. On Mon, Jan 14, 2019 at 12:20 AM ducasse <stepharo(a)netcourrier.com> wrote: > 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. > You do not have to defend your credentials. The community is aware of your contributions. > > 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. > I do not say "Stephane is emotional so we cannot communicate with him.". I do think you let your emotions show too much and that it makes communication with you difficult. But more importantly, a leader is more effective if they can reign in their emotions and not criticize people in public, and so on. I mention your emotionality not to denigrate you but to hope that communication in the community can improve. You have as much to gain as anyone, arguably more, from not taking things so personally and being less emotional. If we analyze the above statement we see that it is coercive: stop criticizing my emotionality or I will stop reading your emails. One could instead be open: "Why is it that you criticize me as being emotional?", "Can you give me evidence of me being emotional?" etc. Instead you open with a defensive position, and with a threat. If, later on, having started filtering out my emails, you found you had to respond again, because we have common interests and those interests cause us to need to interact, you will put yourself in a weak position having to back track on your filtering. - 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. > No. I said that my opinion is that time boxing releases is a bad idea. This is not about settings, it is about the content of releases. For me, a release is done when it satisfactorily meets objective release criteria: tests pass, a subset of new features planned for the release are functional, etc. That releasing something that is incomplete or broken does not help. I base this on long experience with VisualWorks, Qwaq and Squeak. 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? > May I make the remark that what others choose to do does not make it right? > - 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. I have also proposed good ways for using CMake (to derive a platform-specific header file defining available platform-specific features). 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 b) explicit feature sets are much better than the implicit feature sets that arise when using CMake. > - 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). > Esteban is free to move the code into VMMaker.oscog. VMMaker.oscog below to the community. It is wrong to expect me, a member of that community, to do all the leg work. The VM is called opensmalltalk-vm for a reason. > - 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. > Would you like to expand on this? I find your sentence vague. If you have specifics you would like to address I am open to hearing them. > - 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. > Wow, that does not sound good. Surely a discussion over process does not have to be violent. > We are not blind and we reflect on our own process and we invite > people to REPORT problems. > Do you invite them to discuss problems also? Is the only avenue by which a problem can be raised through a bug tracker? What is the bug that covers this discussion? > 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? > My comment comes from the frustration of having prepared a functional system in Pharo 6 only to find that it no longer works in Pharo 7. Am I wrong to feel frustrated? Would you not also feel frustrated? Would you not also want to discuss this? Would you not also, as the maintainer of a package upon which Pharo depends, want to have that package well-supported and n to be one that is frequently broken? 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. > Um, I have reached out on numerous occasions for test cases. I haven't received a test case or complaint on ephemeris for many months, perhaps over a year (I will check). I am very motivated to fix these problems. Please bring them to my attention on vm-dev. They will receive prompt attention. I love working on this part of the system, ads does ClÃ©ment. I am eager to see ephemeris deployed in Squeak, Pharo and Cuis, especially to improve file handling, specifically arranging that files are flushed on close, and that we do not have two copies (one inevitably out of date) of each file, simply to arrange that file handles are closed on finalization. > - We had instability when we have memory leaks that > randomly slows down Pharo. > Indeed, and memory leaks are not necessarily caused by the GC, but by handles to external memory, something that affects Pharo deeply because its graphics model uses external libraries, and hence requires more careful interfacing with external libraries, something that would be improved by having reliable ephemeron support. I am quite confident that there are no memory leaks in the Spur GC; but I'm happy to be proved wrong and, along with ClÃ©ment, who is currently doing great work on the GC, work that we hope to show a string publication for very soon, I will be happy to attempt to fix any memory leaks that are the fault of the GC, and not thin the FFI. > - We had instability which delays our release with a bug > in FFI that made cairo crash on windows 64 bits. > Yes, there are bugs in the VM. And what's your point? > 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. > That's what I'm trying to do. > > - You can contribute by writing tests and by entering bug entries > in the bug tracker. > I write tests in VMMaker and elsewhere. Being able to load VMMaker into Pharo and run the simulator, generate sources, do in-image compilation, and run its test suites is a significant number of tests. I work principally in Squeak. I interact with lots of people in the Pharo community. I am here, interacting now. > 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. > I am not asking that the Pharo community do that. I am asking that the VMMaker package continue to work from releases to release. From Pharo 6 to Pharo 7 that did not happen. Pharo will change because Pharo is agile and because many things should be > improved. > and because it has a high-quality VM beneath it that has improved performance exponentially in the move from interpreter, stack interpreter, cog v1 and spur, and should continue to do so through Sista. We are all working hard to make things better. 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. > Good; thank you. > > 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. > Glad to hear it. And I'm very much aware of this work and support it wholeheartedly. And in the VM we are doing similar things. > I repeat it: I think that we are doing a pretty good job about the quality > that we deliver. > I agree. > Stef > Thank you. Eliot > > > > 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. > >> > >> > >> > > > > -- _,,,^..^,,,_ best, Eliot

Jan. 16, 2019