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

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

by Ben Coman

On Wed, 16 Jan 2019 at 18:37, 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, ouch. That one point nearly made my retract my comment next paragraph, but is there much more complexity? or just a case of utf8<==>appSpecificEncoding rather than ascii<==>appSpecificEncoding ? Sorry if I'm rehashing past discussion (do you have a link?), but considering... * 92% of web pages are UTF8 encoded[1] such that pragmatically UTF8 *is* the standard for text * Strings so pervasive in a system ...would there be an overall benefit to adopt UTF8 as the encoding for Strings consistently provided across the cross-platform vm interface? (i.e. fixing platforms that don't comply to the standard due to their historical baggage) And I found it interesting Microsoft are making some moves towards UTF8 [2]... "With insider build 17035 and the April 2018 update (nominal build 17134) for Windows 10, a "Beta: Use Unicode UTF-8 for worldwide language support" checkbox appeared for setting the locale code page to UTF-8.[a] This allows for calling "narrow" functions, including fopen and SetWindowTextA, with UTF-8 strings. " The approach vm-side could be similar to Section 10 How to do text on Windows [3] with the philosophy of "performing the [conversions] as close to API calls as possible, and never holding the [converted] data." [1] https://w3techs.com/technologies/history_overview/character_encoding/ms/y [2] https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows [3] http://utf8everywhere.org/ 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. > Big question... Do we currently have primitives of the same name returning different encodings on different platforms? I presume that would be awkward. If the image is handle encoding differences, should separate primitives be used? e.g. utf8GetEnv & utf16getEnv Could I get some feedback on [4] saying... **The Single Most Important Fact About Encodings** If you completely forget everything I just explained, please remember one extremely important fact. It does not make sense to have a string without knowing what encoding it uses. " And so... does our String nowadays require an 'encoding' instance variable such that this is *always* associated? This might remove any need for separate utf8GetEnv & utf16getEnv (if that was even a reasonable idea). cheers -ben [4] https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-softwa… > > 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 > > >

Jan. 18, 2019

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

by Sven Van Caekenberghe

Dave, > On 18 Jan 2019, at 01:54, David T. Lewis via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: "David T. Lewis" <lewis(a)mail.msen.com> > Subject: Re: [Pharo-dev] Better management of encoding of environment variables > Date: 18 January 2019 at 01:54:34 GMT+1 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > On Thu, Jan 17, 2019 at 04:57:18PM +0100, Sven Van Caekenberghe wrote: >> >>> On 16 Jan 2019, at 23:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> On Wed, Jan 16, 2019 at 2:37 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> 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. >> >> OK, I can understand that ENV VAR access is more fundamental than FFI >> (although FFI is already essential for Pharo, also during startup). >> >>> 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. >> >> Right, bytes are always uninterpreted, else they would be something else. >> We got ByteArray>>#decodedWith: and ByteArray>>#utf8Decoded and our ByteArray >> inspector decodes automatically if it can. >> > > Hi Sven, > > I am the author of the getenv primitives, and I am also sadly uninformed > about matters of character sets and strings in a multilingual environment. > > The primitives answer environment variable variable values as ByteString > rather than ByteArray. This made sense to me at the time that I wrote it, > because ByteString is easy to display in an inspector, and because it is > easily converted to ByteArray. > > For an American English speaker this seems like a good choice, but I > wonder now if it is a bad decision. After all, it is also trivially easy > to convert a ByteArray to ByteString for display in the image. > > Would it be helpful to have getenv primitives that answer ByteArray > instead, and to let all conversion (including in OSProcess) be done in > the image? > > Thanks, > Dave Normally, the correct way to represent uninterpreted bytes is with a ByteArray. Decoding these bytes as characters is the specific task of a character encoder/decoder, with a deliberate choice as to which to use. Since the getenv() system call uses simple C strings, it is understandable that this was carried over. It is probably not worth or too risky to change that - as long as the receiver understands that it is a raw OS string that needs more work. Like with file path encoding/decoding, environment variable encoding/decoding is plain messy and complex. IMHO it is better to manage that at the image level where we are more agile and can better handle that complexity. Sven BTW: using funny Unicode chars, like ð [https://www.fileformat.info/info/unicode/char/1f388/index.htm] is something even English speakers do.

Jan. 18, 2019

[Pharo 7.0] Build #130: 22896-Creating-methods-in-a-subclass-with-a-class-using-a-trait

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

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…

Jan. 18, 2019

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

by ducasse

> > So making the primitives return ByteArray instances instead of ByteString should be safe enough :). > But this is in my opinion clearly a hack instead of fixing the real problem, and we have to be careful to guard such patterns with comments everywhere explaining why the bytearray conversion is really needed thereâ¦ Guillermo what is the correct way to do it? > Would it be helpful to have getenv primitives that answer ByteArray > instead, and to let all conversion (including in OSProcess) be done in > the image? > > Well, personally I would like that getenv/setenv and getcwd setcwd support are not in a plugin but as a basic service provided by the vm. > > Cheers, > Guille > > > Thanks, > Dave > > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Jan. 18, 2019

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

by ducasse

> > > > 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. > > +100 > > The VM *is* developed in Smalltalk > https://www.researchgate.net/publication/328509577_Two_Decades_of_Smalltalk… <https://www.researchgate.net/publication/328509577_Two_Decades_of_Smalltalk…> It is not the point of the message of Martin. I imagine that Martin and Sven understand it perfectly that the VM is written in Slang and that there is a simulator. Still many of us agree with their analysis. The VM logic should be on execution and try to delegate to the image most of the rest. Stef

Jan. 18, 2019

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

by Guillermo Polito

On Fri, Jan 18, 2019 at 1:58 AM David T. Lewis via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > On Thu, Jan 17, 2019 at 04:57:18PM +0100, Sven Van Caekenberghe wrote: > > > > > On 16 Jan 2019, at 23:23, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > > > On Wed, Jan 16, 2019 at 2:37 AM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > > 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. +1 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. > Having looked at it not so long ago, I'll add my 2cts. Environment access is a very particular scenario. We have in Pharo many startup actions that directly or indirectly (FileLocator home?) require environment variable access, and thus we have to be really careful and picky to make sure that they all work, dependencies are installed in the right order and so on... In Pharo6 this was specially difficult because FFI was dynamically compiling methods, => which required access to argument names, => which required access to the sources files, => which required access to the env vars (because in Pharo the source/changes files are looked up in other directories than the image/vm ones) => which loops :) In Pharo7 argument names in FFI calls are embedded in the method meta-data so all that is avoided. Still I'd agree that moving this support to a primitive would make it less fragile. I'd apply the same to getting/setting the working directory. > > > OK, I can understand that ENV VAR access is more fundamental than FFI > > (although FFI is already essential for Pharo, also during startup). > > > > > 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. > > > > Right, bytes are always uninterpreted, else they would be something else. > > We got ByteArray>>#decodedWith: and ByteArray>>#utf8Decoded and our > ByteArray > > inspector decodes automatically if it can. > > > > Hi Sven, > > I am the author of the getenv primitives, and I am also sadly uninformed > about matters of character sets and strings in a multilingual environment. > > The primitives answer environment variable variable values as ByteString > rather than ByteArray. This made sense to me at the time that I wrote it, > because ByteString is easy to display in an inspector, and because it is > easily converted to ByteArray. > > For an American English speaker this seems like a good choice, but I > wonder now if it is a bad decision. Well, as soon as you want to manage some internationalisation, indeed it is. But also it is a source of bugs, because assuming ascii is not right for english either. Most platforms will assume utf8 by default, and it's not quite the same for many symbols :). For example, Character allByteCharacters size. => 256 Character allByteCharacters utf8Encoded size. 384 Character allByteCharacters select: [ :c | c asString utf8Encoded size > 1 ]. 'â¬ âÆââ¦â â¡Ëâ°Å â¹Å Å½ âââââ¢ââËâ¢Å¡âºÅ Å¾Å¸ Â¡Â¢Â£Â¤Â¥Â¦Â§Â¨Â©ÂªÂ«Â¬ÂÂ®Â¯Â°Â±Â²Â³Â´ÂµÂ¶Â·Â¸Â¹ÂºÂ»Â¼Â½Â¾Â¿ÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃ Ã¡Ã¢Ã£Ã¤Ã¥Ã¦Ã§Ã¨Ã©ÃªÃ«Ã¬ÃÃ®Ã¯Ã°Ã±Ã²Ã³Ã´ÃµÃ¶Ã·Ã¸Ã¹ÃºÃ»Ã¼Ã½Ã¾Ã¿' Of course, many of those characters may not be used in the day-to-day of many people, but as soon as we find one of those (I'm thinking about the not super strange case of a database storing names :)). Also think about the poor windows users (like myself since 2 weeks ago), that have to think about utf16! BTW, I hope I'm not breaking anybody's mail client by pasting strange characters here :D (and if so, you may want suggest them to review how they manage encoding :)) After all, it is also trivially easy > to convert a ByteArray to ByteString for display in the image. > Yes, but it's sometimes difficult to find such places, as there are many primitives spread in a lot of places doing the wrong thing, which is a source of bugs... I'd like to fix it from the root, the question is how to do it without breaking ^^. In Pharo we are doing at many places, self primitiveXXX asByteArray utf8Decoded So making the primitives return ByteArray instances instead of ByteString should be safe enough :). But this is in my opinion clearly a hack instead of fixing the real problem, and we have to be careful to guard such patterns with comments everywhere explaining why the bytearray conversion is really needed there... > Would it be helpful to have getenv primitives that answer ByteArray > instead, and to let all conversion (including in OSProcess) be done in > the image? > Well, personally I would like that getenv/setenv and getcwd setcwd support are not in a plugin but as a basic service provided by the vm. Cheers, Guille > > Thanks, > Dave > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Jan. 18, 2019

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

by David T. Lewis

On Thu, Jan 17, 2019 at 04:57:18PM +0100, Sven Van Caekenberghe wrote: > > > On 16 Jan 2019, at 23:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Wed, Jan 16, 2019 at 2:37 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > 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. > > OK, I can understand that ENV VAR access is more fundamental than FFI > (although FFI is already essential for Pharo, also during startup). > > > 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. > > Right, bytes are always uninterpreted, else they would be something else. > We got ByteArray>>#decodedWith: and ByteArray>>#utf8Decoded and our ByteArray > inspector decodes automatically if it can. > Hi Sven, I am the author of the getenv primitives, and I am also sadly uninformed about matters of character sets and strings in a multilingual environment. The primitives answer environment variable variable values as ByteString rather than ByteArray. This made sense to me at the time that I wrote it, because ByteString is easy to display in an inspector, and because it is easily converted to ByteArray. For an American English speaker this seems like a good choice, but I wonder now if it is a bad decision. After all, it is also trivially easy to convert a ByteArray to ByteString for display in the image. Would it be helpful to have getenv primitives that answer ByteArray instead, and to let all conversion (including in OSProcess) be done in the image? Thanks, Dave

Jan. 18, 2019

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

by ducasse

So when I read your emails everything looks perfect from your side. So let it be. Stef > On 16 Jan 2019, at 23:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > 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 <mailto:stepharo@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 <mailto:eliot.miranda@gmail.com>> wrote: > > > > Hi Stef, > > > >> On Jan 10, 2019, at 7:59 AM, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@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 <mailto:eliot.miranda@gmail.com>> wrote: > >>> > >>> Hi Thomas, > >>> > >>>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@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. 17, 2019

Re: [Pharo-dev] [ANN] Preparing for release. No more PRs will be accepted on P7.

by Esteban Lorenzano

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

Jan. 17, 2019

Aw: [Pharo-dev] [ANN] Preparing for release. No more PRs will be accepted on P7.

by Torsten Bergmann

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

Jan. 17, 2019