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

Re: [Pharo-users] Class name with diacritic character and Pharo

by Benoit St-Jean

While we're at it, a similar problem arises when the author name (in my case BenoÃ®tStJean) contains a French diacritic. Just tested it with Pharo 7 (64 bit on Windows 10)... Fileout works fine.Â But filing in crashes! On 2019-01-27 11:03, Sven Van Caekenberghe wrote: > Hi Dominique, > >> On 27 Jan 2019, at 11:40, Dominique Dartois <dom(a)dartois.org> wrote: >> >> Hello all. >> If a use french diacritic character in a class name, the code runs but I canât fileout the package nor save it with Monticello. >> For example, the C cedilla in the class name drive me to an âZnInvalidUTF8:Illegal byte for utf-8 encoding' when filing out. >> >> Is it a bug or a feature? >> Thank you >> >> <image.png>--- >> Dominique Dartois > Thanks for reporting this. This is most definitely a bug, I can confirm its occurrence. > > I'm CC pharo-dev as this is quite important. This will be a long mail. > > > This is one manifestation of a problem that has been present for quite a while. > > I'll start by describing what I did, what went well and where/how this fails, some generic points, and two conceptual solutions (that need further verification). > > Like you, I created a new subclass: > > Object subclass: #ClasseFranÃ§aise > instanceVariableNames: '' > classVariableNames: '' > package: '_UnpackagedPackage' > > With comment: > > I am ClasseFranÃ§aise. > > Try: > > ClasseFranÃ§aise new Ã©lÃ¨ve. > ClasseFranÃ§aise new euro. > > And two methods (in the 'test' protocol): > > Ã©lÃ¨ve > ^ 'Ã©lÃ¨ve' > > euro > ^ 'â¬' > > I added the euro sign (because that is encoded in UTF-8 with 3 bytes, not 2 like Ã§). > Like you said, the system can cope with such class and method names and seems to function fine. > > Looking at the .changes file, the correct source code was appended: > > ----SNAPSHOT----2019-01-26T23:36:18.548555+01:00 work.image priorSource: 339848! > > Object subclass: #ClasseFranÃ§aise > instanceVariableNames: '' > classVariableNames: '' > package: '_UnpackagedPackage'! > !ClasseFranÃ§aise commentStamp: 'SvenVanCaekenberghe 1/27/2019 12:25' prior: 0! > I am ClasseFranÃ§aise.! > !ClasseFranÃ§aise methodsFor: 'test' stamp: 'SvenVanCaekenberghe 1/27/2019 12:26'! > Ã©lÃ¨ve > ^ 'Ã©lÃ¨ve'! ! > !ClasseFranÃ§aise commentStamp: 'SvenVanCaekenberghe 1/27/2019 12:27' prior: 33898360! > I am ClasseFranÃ§aise. > > Try: > > ClasseFranÃ§aise new Ã©lÃ¨ve. > ClasseFranÃ§aise new euro. > ! > !ClasseFranÃ§aise methodsFor: 'test' stamp: 'SvenVanCaekenberghe 1/27/2019 12:27'! > euro > ^ 'â¬'! ! > > > Doing a file out (or otherwise saving the source code) fails. The reason is an incorrect manipulation of this source file while looking for what is called the method preamble, in SourcFileArray>>#getPreambleFrom:at: position > > An programmatic way to invoke the same error is by doing > > (ClasseFranÃ§aise>>#Ã©lÃ¨ve) timeStamp. > (ClasseFranÃ§aise>>#Ã©lÃ¨ve) author. > > Both fail with the same error. > > > The source code of methods is (currently) stored in a .sources or .changes file. CompiledMethods know their source pointer, an offset in one of these files. Right before the place where the source starts is a preamble that contains some meta information (including the author and timestamp). To access that preamble, the source code pointer is moved backwards to the beginning of the preamble (which begins and ends with a !). > > > The current approach fails in the presence of non-ASCII characters. More specifically because of a mixup between the concept of byte position and character position when using UTF-8, a variable length encoding (both the .changes and the .sources are UTF-8 encoded). > > For example, consider > > 'Ã partir de 10 â¬' size. "16" > 'Ã partir de 10 â¬' utf8Encoded size. "19" > > So although the string contains 16 characters, it is encoded as 19 bytes, Ã using 2 bytes and â¬ using 3 bytes. In general, moving backwards or forwards in UTF-8 encoded bytes cannot be done without understanding UTF-8 itself. > > ZnUTF8Encoder can do both (moving forward is #nextFromStream: while moving backwards is #backOnStream:). However, ZnUTF8Encoder is also strict: it will signal an error when forced to operate in between encoded characters, which is what happens here. > > It is thus not possible to move to arbitrary bytes positions and assume/hope to always arrive on the correct character boundaries and it is also wrong to take the difference between two byte positions as the count of characters present (since their encoding is of variable length). > > SourcFileArray>>#getPreambleFrom:at: is doing both of these wrong (but gets away with it in 99.99% of all cases since very few people name their classes like that). > > There are two solutions: operate mostly on the byte level or operate correctly on the character level. Here are two conceptual solutions (you must execute either solution 1 or 2, not both), with two different inputs. > > > src := '!ClasseFranÃ§aise methodsFor: ''test'' stamp: ''SvenVanCaekenberghe 1/27/2019 12:27''! > euro > ^ ''â¬''! !'. > > "startPosition := 83" > > str := ZnCharacterReadStream on: (src utf8Encoded readStream). > str position: 83. "at start of euro, the methods source string" > str upToEnd. > > str position: (83 - 3). "before ! before euro" > > "find the previous ! before position" > position := str position. > binary := str wrappedStream. > encoder := str encoder. > > "solution 1" > [ position >= 0 and: [ binary position: position. binary next ~= 33 ] ] whileTrue: [ position := position - 1 ]. > position. > encoder decodeBytes: (binary next: 80 - position). > > "solution 2" > count := 0. > [ str position >= 0 and: [ str next ~= $! ] ] whileTrue: [ > encoder backOnStream: binary; backOnStream: binary. count := count + 1 ]. > str position. > str next: count. > > > Same code, different input (and starting position): > > > src := '!ABC!ClasseFranÃ§aise methodsFor: ''test'' stamp: ''SvenVanCaekenberghe 1/27/2019 12:27''! > euro > ^ ''â¬''! !'. > > "startPosition := 87" > > str := ZnCharacterReadStream on: (src utf8Encoded readStream). > str position: 87. "at start of euro, the methods source string" > str upToEnd. > > str position: (87 - 3). "before ! before euro" > > "find the previous ! before position" > position := str position. > binary := str wrappedStream. > encoder := str encoder. > > "solution 1" > [ position >= 0 and: [ binary position: position. binary next ~= 33 ] ] whileTrue: [ position := position - 1 ]. > position. > encoder decodeBytes: (binary next: 80 - position). > > "solution 2" > count := 0. > [ str position >= 0 and: [ str next ~= $! ] ] whileTrue: [ > encoder backOnStream: binary; backOnStream: binary. count := count + 1 ]. > str position. > str next: count. > > > Solution 1 (at the byte level) works because $! (ASCII code 33) is also encoded as such in UTF-8 and this byte pattern cannot be part of a 2, 3 or 4 byte UTF-8 encoded character. The final byte segment must then be given to the proper encoder to turn it into characters. > > Solution 2 (at the character level) works because it essentially counts characters while moving backwards correctly (it moves back 2 steps each time because #next moves 1 step forward, while #peek would not help). > > Note that in Solution 1 the moving position is held in an external variable, while in Solution 2 it is held inside the stream. > > > Implementing either solution requires more internal access of the streams (#wrappedStream), so SourcFileArray>>#getPreambleFrom:at: should at least be moved to SourceFile, IMHO. > > Obviously this is a sensitive/critical area to touch. > > We will also need a regression unit test. > > On a higher design level, I think that CompiledMethod>>#timeStamp and CompiledMethod>>#author should be cached at the instance level (a unix timestamp and a symbol would cost very little). > > Sven > > > > > > > -- ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Jan. 28, 2019

Build problems

by ducasse

Jan. 27, 2019

[Pharo 8.0] Build #27: Issue 2345 envversion.sh causes out-of-repository bootstrap to fail

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

There is a new Pharo build available! The status of the build #27 was: FAILURE. The Pull Request #2346 was integrated: "Issue 2345 envversion.sh causes out-of-repository bootstrap to fail" Pull request url: https://github.com/pharo-project/pharo/pull/2346 Issue Url: https://pharo.fogbugz.com/f/cases/Issue2345 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 27, 2019

[Pharo 8.0] Build #26: 2347 BaselineOfIDE references non-existant Iceberg 1.5.5

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

There is a new Pharo build available! The status of the build #26 was: SUCCESS. The Pull Request #2348 was integrated: "2347 BaselineOfIDE references non-existant Iceberg 1.5.5" Pull request url: https://github.com/pharo-project/pharo/pull/2348 Issue Url: https://pharo.fogbugz.com/f/cases/Issue2347 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 27, 2019

Re: [Pharo-dev] [Pharo-users] Class name with diacritic character and Pharo

by Sven Van Caekenberghe

Hi Dominique, > On 27 Jan 2019, at 11:40, Dominique Dartois <dom(a)dartois.org> wrote: > > Hello all. > If a use french diacritic character in a class name, the code runs but I canât fileout the package nor save it with Monticello. > For example, the C cedilla in the class name drive me to an âZnInvalidUTF8:Illegal byte for utf-8 encoding' when filing out. > > Is it a bug or a feature? > Thank you > > <image.png>--- > Dominique Dartois Thanks for reporting this. This is most definitely a bug, I can confirm its occurrence. I'm CC pharo-dev as this is quite important. This will be a long mail. This is one manifestation of a problem that has been present for quite a while. I'll start by describing what I did, what went well and where/how this fails, some generic points, and two conceptual solutions (that need further verification). Like you, I created a new subclass: Object subclass: #ClasseFranÃ§aise instanceVariableNames: '' classVariableNames: '' package: '_UnpackagedPackage' With comment: I am ClasseFranÃ§aise. Try: ClasseFranÃ§aise new Ã©lÃ¨ve. ClasseFranÃ§aise new euro. And two methods (in the 'test' protocol): Ã©lÃ¨ve ^ 'Ã©lÃ¨ve' euro ^ 'â¬' I added the euro sign (because that is encoded in UTF-8 with 3 bytes, not 2 like Ã§). Like you said, the system can cope with such class and method names and seems to function fine. Looking at the .changes file, the correct source code was appended: ----SNAPSHOT----2019-01-26T23:36:18.548555+01:00 work.image priorSource: 339848! Object subclass: #ClasseFranÃ§aise instanceVariableNames: '' classVariableNames: '' package: '_UnpackagedPackage'! !ClasseFranÃ§aise commentStamp: 'SvenVanCaekenberghe 1/27/2019 12:25' prior: 0! I am ClasseFranÃ§aise.! !ClasseFranÃ§aise methodsFor: 'test' stamp: 'SvenVanCaekenberghe 1/27/2019 12:26'! Ã©lÃ¨ve ^ 'Ã©lÃ¨ve'! ! !ClasseFranÃ§aise commentStamp: 'SvenVanCaekenberghe 1/27/2019 12:27' prior: 33898360! I am ClasseFranÃ§aise. Try: ClasseFranÃ§aise new Ã©lÃ¨ve. ClasseFranÃ§aise new euro. ! !ClasseFranÃ§aise methodsFor: 'test' stamp: 'SvenVanCaekenberghe 1/27/2019 12:27'! euro ^ 'â¬'! ! Doing a file out (or otherwise saving the source code) fails. The reason is an incorrect manipulation of this source file while looking for what is called the method preamble, in SourcFileArray>>#getPreambleFrom:at: position An programmatic way to invoke the same error is by doing (ClasseFranÃ§aise>>#Ã©lÃ¨ve) timeStamp. (ClasseFranÃ§aise>>#Ã©lÃ¨ve) author. Both fail with the same error. The source code of methods is (currently) stored in a .sources or .changes file. CompiledMethods know their source pointer, an offset in one of these files. Right before the place where the source starts is a preamble that contains some meta information (including the author and timestamp). To access that preamble, the source code pointer is moved backwards to the beginning of the preamble (which begins and ends with a !). The current approach fails in the presence of non-ASCII characters. More specifically because of a mixup between the concept of byte position and character position when using UTF-8, a variable length encoding (both the .changes and the .sources are UTF-8 encoded). For example, consider 'Ã partir de 10 â¬' size. "16" 'Ã partir de 10 â¬' utf8Encoded size. "19" So although the string contains 16 characters, it is encoded as 19 bytes, Ã using 2 bytes and â¬ using 3 bytes. In general, moving backwards or forwards in UTF-8 encoded bytes cannot be done without understanding UTF-8 itself. ZnUTF8Encoder can do both (moving forward is #nextFromStream: while moving backwards is #backOnStream:). However, ZnUTF8Encoder is also strict: it will signal an error when forced to operate in between encoded characters, which is what happens here. It is thus not possible to move to arbitrary bytes positions and assume/hope to always arrive on the correct character boundaries and it is also wrong to take the difference between two byte positions as the count of characters present (since their encoding is of variable length). SourcFileArray>>#getPreambleFrom:at: is doing both of these wrong (but gets away with it in 99.99% of all cases since very few people name their classes like that). There are two solutions: operate mostly on the byte level or operate correctly on the character level. Here are two conceptual solutions (you must execute either solution 1 or 2, not both), with two different inputs. src := '!ClasseFranÃ§aise methodsFor: ''test'' stamp: ''SvenVanCaekenberghe 1/27/2019 12:27''! euro ^ ''â¬''! !'. "startPosition := 83" str := ZnCharacterReadStream on: (src utf8Encoded readStream). str position: 83. "at start of euro, the methods source string" str upToEnd. str position: (83 - 3). "before ! before euro" "find the previous ! before position" position := str position. binary := str wrappedStream. encoder := str encoder. "solution 1" [ position >= 0 and: [ binary position: position. binary next ~= 33 ] ] whileTrue: [ position := position - 1 ]. position. encoder decodeBytes: (binary next: 80 - position). "solution 2" count := 0. [ str position >= 0 and: [ str next ~= $! ] ] whileTrue: [ encoder backOnStream: binary; backOnStream: binary. count := count + 1 ]. str position. str next: count. Same code, different input (and starting position): src := '!ABC!ClasseFranÃ§aise methodsFor: ''test'' stamp: ''SvenVanCaekenberghe 1/27/2019 12:27''! euro ^ ''â¬''! !'. "startPosition := 87" str := ZnCharacterReadStream on: (src utf8Encoded readStream). str position: 87. "at start of euro, the methods source string" str upToEnd. str position: (87 - 3). "before ! before euro" "find the previous ! before position" position := str position. binary := str wrappedStream. encoder := str encoder. "solution 1" [ position >= 0 and: [ binary position: position. binary next ~= 33 ] ] whileTrue: [ position := position - 1 ]. position. encoder decodeBytes: (binary next: 80 - position). "solution 2" count := 0. [ str position >= 0 and: [ str next ~= $! ] ] whileTrue: [ encoder backOnStream: binary; backOnStream: binary. count := count + 1 ]. str position. str next: count. Solution 1 (at the byte level) works because $! (ASCII code 33) is also encoded as such in UTF-8 and this byte pattern cannot be part of a 2, 3 or 4 byte UTF-8 encoded character. The final byte segment must then be given to the proper encoder to turn it into characters. Solution 2 (at the character level) works because it essentially counts characters while moving backwards correctly (it moves back 2 steps each time because #next moves 1 step forward, while #peek would not help). Note that in Solution 1 the moving position is held in an external variable, while in Solution 2 it is held inside the stream. Implementing either solution requires more internal access of the streams (#wrappedStream), so SourcFileArray>>#getPreambleFrom:at: should at least be moved to SourceFile, IMHO. Obviously this is a sensitive/critical area to touch. We will also need a regression unit test. On a higher design level, I think that CompiledMethod>>#timeStamp and CompiledMethod>>#author should be cached at the instance level (a unix timestamp and a symbol would cost very little). Sven

Jan. 27, 2019

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

by David T. Lewis

On Fri, Jan 18, 2019 at 08:58:07AM -0500, David T. Lewis wrote: > On Fri, Jan 18, 2019 at 01:40:26PM +0100, Sven Van Caekenberghe wrote: > > > > > On 18 Jan 2019, at 01:54, 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: > > >> > > >> 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. > > > > Thanks Sven, that makes perfect sense to me. > I added some new primitives to OSProcessPlugin that answer ByteArray instead of ByteString. For Unix (Linux, OS X): <primitive: 'primitiveGetCurrentWorkingDirectoryAsBytes' module: 'UnixOSProcessPlugin'> <primitive: 'primitiveArgumentAtAsBytes' module: 'UnixOSProcessPlugin'> <primitive: 'primitiveEnvironmentAtAsBytes' module: 'UnixOSProcessPlugin'> <primitive: 'primitiveEnvironmentAtSymbolAsBytes' module: 'UnixOSProcessPlugin'> <primitive: 'primitiveRealpathAsBytes' module: 'UnixOSProcessPlugin'> For Windows: <primitive: 'primitiveGetCurrentWorkingDirectoryAsBytes' module: 'Win32OSProcessPlugin'> <primitive: 'primitiveGetEnvironmentStringsAsBytes' module: 'Win32OSProcessPlugin'> These should be in the latest VM builds now. If you are using OSProcess, update it to the latest version to get accessor methods for the new primitives. For example, OSProcess accessor primGetCurrentWorkingDirectory calls the original primitive that answers a ByteString, and to get raw bytes you can use OSProcess accessor primGetCurrentWorkingDirectoryAsBytes instead. Dave

Jan. 27, 2019

Re: [Pharo-dev] [ANN] Pharo 7.0 released!

by ducasse

Hi everybody > On 24 Jan 2019, at 20:36, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > it's a nice release yes - and the best we ever provided indeed. I'm really happy too that P7 image is an > official release now. > > > But still: > ========== > > In a post [1] in November 2017 I brought up the topic again to "increase the quality level in Pharo 7 and onwards". > > With 762 commits [2] for Pharo 7 I devoted a lot of time in fixing often simple and trivial things just to clean up > comments, code, typos, packages, manifests, tests and so on. Thanks for it. > > Many others did the same and supported these cleaning efforts. This helped adding a few more release tests to keep the > quality bar on the level reached. Special thanks to Marcus, Esteban, and many others who helped reviewing, fighting a > shaky CI server, integrating quickly and so on â¦ Yes. I think that with Iceberg and git we can now be a lot faster to integrate simple fixes. > Still THIS IS NOT FINISHED ... and it would be really help if more people would participate in the cleaning or fixing bugs. > Also many external packages now need some love to work with Pharo 7. Definitively. What is important is that when we have to deal with little issues this is difficult to work on larger ones. Iâm resurrecting the code of the classParser and UndefinedClasses right now (checking/adding tests). > We have a large community with many, many users - but still only a few contribute to the core system. > > I wonder why and would like to know: > - Is it due to the switch to git ? > - Is is due to the new contribution process? > - Is it for other reasons? > > Remember: Pharo is yours and even small steps could make a difference. So please join! Thanks this is a good message. We will produce a video during the next techTalk showing how easy it is to contribute. > Thanks > T. > > > [1] http://forum.world.st/Pharo-Quality-raising-the-quality-level-in-Pharo-7-an… > [2] https://github.com/pharo-project/pharo/graphs/contributors > >

Jan. 26, 2019

Re: [Pharo-dev] [Off Topic] Michel Bauwens on the history and immediate future of work

by ducasse

Thanks we will watch it > On 25 Jan 2019, at 17:41, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > Hi All, > > I find this talk profound and key to making functional open source communities as we try and survive. > > Iâve skipped an introduction in Portuguese and some slide control issues. > https://youtu.be/vDjazcMm-eE?t=4m40s <https://youtu.be/vDjazcMm-eE?t=4m40s> > _,,,^..^,,,_ (phone)

Jan. 26, 2019

Re: [Pharo-dev] [ANN] Pharo 7.0 released!

by ducasse

Hello > > Torsten Bergmann wrote >> We have a large community with many, many users - but still only a few >> contribute to the core system. >> >> I wonder why and would like to know: >> - Is it due to the switch to git ? >> - Is is due to the new contribution process? >> - Is it for other reasons? > > For me; a combination of 1 and 2. > I've done work in Pharo 6.1 during the Pharo7 process, but had no idea how > to easily forward-port any base fixes to Pharo 7. The times I tried (after a > good old-fashioned file-out), I failed to get Iceberg check out Pharo7 on > Windows. > IIRC, I believe I resorted to posting an .st in the issues (which then timed > out after a year of being stuck in for review status with no automatical > validation) > As such, I'm absent from the contributor list for the first time since... > Pharo 1.1? ;) > > I hope switching to Pharo8 branch and commiting fixes while working in > Pharo7 will be easier? I can tell you. It is a **lot** easier can you tell us if the following is understandable for you https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Jan. 26, 2019

Re: [Pharo-dev] [ANN] Pharo 7.0 released!

by ducasse

Now github. Stef > On 24 Jan 2019, at 20:44, Eric Gade <eric.gade(a)gmail.com> wrote: > > Which is now the canonical place to seek out these issues/bugs: manuscript or GitHub? > > On Thu, Jan 24, 2019, 14:37 Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de> wrote: > Hi, > > it's a nice release yes - and the best we ever provided indeed. I'm really happy too that P7 image is an > official release now. > > > But still: > ========== > > In a post [1] in November 2017 I brought up the topic again to "increase the quality level in Pharo 7 and onwards". > > With 762 commits [2] for Pharo 7 I devoted a lot of time in fixing often simple and trivial things just to clean up > comments, code, typos, packages, manifests, tests and so on. > > Many others did the same and supported these cleaning efforts. This helped adding a few more release tests to keep the > quality bar on the level reached. Special thanks to Marcus, Esteban, and many others who helped reviewing, fighting a > shaky CI server, integrating quickly and so on ... > > Still THIS IS NOT FINISHED ... and it would be really help if more people would participate in the cleaning or fixing bugs. > Also many external packages now need some love to work with Pharo 7. > > We have a large community with many, many users - but still only a few contribute to the core system. > > I wonder why and would like to know: > - Is it due to the switch to git ? > - Is is due to the new contribution process? > - Is it for other reasons? > > Remember: Pharo is yours and even small steps could make a difference. So please join! > > Thanks > T. > > > [1] http://forum.world.st/Pharo-Quality-raising-the-quality-level-in-Pharo-7-an… <http://forum.world.st/Pharo-Quality-raising-the-quality-level-in-Pharo-7-an…> > [2] https://github.com/pharo-project/pharo/graphs/contributors <https://github.com/pharo-project/pharo/graphs/contributors> > >

Jan. 26, 2019