- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] contribution workflow

by Ben Coman

On Tue, 22 Jan 2019 at 17:28, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Ben, > > I'll just expand a bit on what Pavel said. > > On Mon, Jan 21, 2019 at 4:59 PM Ben Coman <btc(a)openinworld.com> wrote: > >> I'm not sure how closely my contribution workflow matches the standard >> advertised, so just wanted to share it for feedback. I may remember >> wrongly, but my understanding of the advertised process was forking the >> "pharo-project/pharo" repo, then cloning from my fork. However I found it >> awkward to keep the "master" branch of my fork synchronised with upstream. >> > > It's important to understand that you don't need to keep any branch in > your fork synchronized ^^. > Pull requests bind two branches, not two repositories. > Your repository may have 30 branches, all outdated, and the only one that > needs to be "up to date" is the one participating in a pull request. > > Even, I'd say it's not really required to have the branch of the PR up to > date either, as git will just make a merge with it, calculating correctly > the point of divergence between the two branches. However, making a branch > that started too far away in the history (too old) will just increase the > possibility of a merge conflict. > > Actually, the easiest is that you start working on a branch whose tip > points to the same commit the image was created from. > This is to make sure that: > - you will have correct diffs > - your PR does not introduce commits that you did not intend to > Sure, I often do the same to avoid feeling lost when I don't understanding where extra changes are coming from. However right now I have a PR from November that didn't make it into Pharo 7 and I'm now trying bring forward for Pharo 8. Could work with me to reproduce this to see where I'm going wrong... My image is up to date with Pharo 8, 2019-01-31 19:23, commit 2c0b5d0. I repaired the "pharo" repo such that remotes after repairing are... * origin = git@github.com:bencoman/pharo.git * pharo-project = git@github.com:pharo-project/pharo.git though if you use https the rest of this workflow should go the same for you. Double-checked I was up to date by again checking out "pharo-project/Pharo8.0". Now I want to bring forward my changes from "origin/22637-Minor-cleanup-of-Delay" Right-clicking on it I only the choice to "Checkout branch", but I don't want to do that since I feel its likely to break something. A checkout doesn't focus on the package my changes are in but reverts months of changes through the whole live system. The <Merge> button is another option, choosing "origin" then "22637-Minor-cleanup-of-Delay" In the preview window is a massive amount of changes that have nothing to do with me. I guess its again months of every else's changes to Pharo that would be risky and confusing to proceed. I feel what I need is something like "origin/22637-Minor-cleanup-of-Delay" right-click > Rebase to HEAD which would determine the common ancestor f2078b5 and integrate just my changes since then. I can't see any other options. How would you handle it? cheers -ben P.S. Side info on conflict if you bump into it. DelaySpinScheduler was removed from Pharo 7 after I submitted that PR for issue 22637. >

Feb. 1, 2019

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

by Sven Van Caekenberghe

https://github.com/pharo-project/pharo/pull/2433 > On 29 Jan 2019, at 15:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > https://github.com/pharo-project/pharo/issues/2395 > >> On 27 Jan 2019, at 17:03, Sven Van Caekenberghe <sven(a)stfx.eu> 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 >> >> >> >> >> >> >

Feb. 1, 2019

Re: [Pharo-dev] Contribute to pharo8.0 ?

by Sven Van Caekenberghe

OK, I think I did it ;-) https://github.com/pharo-project/pharo/pull/2433 > On 1 Feb 2019, at 16:35, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > You need to select pharo-project remote (because issues are listed there). > > Esteban > >> On 1 Feb 2019, at 16:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> I am still stuck. >> >> I did >> >> $ curl -L get.pharo.org/64/80+vm | bash >> >> Repaired by specifying my local clone >> >> Repaired by fetching >> >> Not in detached state, cannot make branch from issue, screenshot: >> >> <Screenshot 2019-02-01 at 16.01.17.png> >> >> What am I doing wrong ? >> >> How do other people do it ? >> >>> On 31 Jan 2019, at 08:18, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> >>> It is working now again as expected. >>> >>> The only difference is that you need to use "Github-Create new branch for issue..." instead of "Pharo-Create new branch for issue..." for the new issues reported on GitHub. >>> >>> -- Pavel >>> >>> st 30. 1. 2019 v 9:42 odesÃlatel Guillermo Polito <guillermopolito(a)gmail.com> napsal: >>> Hi, >>> >>> there is an issue for this problem, >>> >>> https://github.com/pharo-project/pharo/issues/2379 >>> >>> We have identified the cause, I'll propose a fix now >>> >>> On Wed, Jan 30, 2019 at 8:44 AM ducasse <stepharo(a)netcourrier.com> wrote: >>> > >>> > There is currently a bug eating one character of the commit hash. So >>> > Iceberg does not find the hash and thinks we need a fetch. So currently >>> > we need to checkout Pharo8.0 in order to be in a good state :( >>> >>> OOPs is there a bug entry? >>> > >>> >> I also don't understand how to make an issue branch for >>> >> >>> >> https://github.com/pharo-project/pharo/issues/2395 >>> >> >>> >> Is it Iceberg > Pharo > Create new branch for issue or Iceberg > Github > Create new branch for issue ? >>> > >>> > Just create a branch and choose the option to create a branch from a >>> > Github option. >>> > >>> > The other one was for Manuscript and is now useless for Pharo 8. I >>> > opened an issue in Iceberg to remove it but I did not got the time to >>> > contribute the change. >>> > >>> >> What is the difference ? >>> >> What about the Remote ? >>> >> Can I work with only an issue on GitHub ? >>> >> >>> > >>> > Yes! >>> > >>> > What I am doing currently: >>> > >>> > - Open an issue XX >>> > - Sync my fork Pharo8.0 branch via command line (This is optional and >>> > can also be done in Pharo. I just do it via command line because I like >>> > it better that way) >>> >>> how do you do it? Pull? >>> >>> > - Download a Pharo 8 image >>> > - Checkout the Pharo8.0 branch to get in a clean state because of the >>> > hash eating bug I mentioned earlier >>> > - Create a new branch from a github issue of the pharo remote >>> > - Do the changes and commit. I add `Fixes #XX` in the commit message to >>> > close automatically the issue when the PR is merged. >>> > - Push to my remote >>> > - Open a PR against Pharo8.0 through Iceberg > GitHub > Create new pull >>> > request >>> >>> and checkout the pharo 8 branch to fix the next one. >>> > >>> >> Is the documentation >>> >> >>> >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >>> >> >>> >> really up to date ? >>> >> >>> > >>> > No >>> > >>> > We should correct the hash eating bug before updating it I think. >>> > >>> >> Sven >>> >> >>> >> >>> > >>> > >>> > -- >>> > Cyril Ferlicot >>> > https://ferlicot.fr >>> > >>> >>> >>> >>> >>> >>> -- >>> >>> 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 >>> >>> Web: http://guillep.github.io >>> Phone: +33 06 52 70 66 13 >> >

Feb. 1, 2019

Re: [Pharo-dev] Contribute to pharo8.0 ?

by Esteban Lorenzano

You need to select pharo-project remote (because issues are listed there). Esteban > On 1 Feb 2019, at 16:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I am still stuck. > > I did > > $ curl -L get.pharo.org/64/80+vm <http://get.pharo.org/64/80+vm> | bash > > Repaired by specifying my local clone > > Repaired by fetching > > Not in detached state, cannot make branch from issue, screenshot: > > <Screenshot 2019-02-01 at 16.01.17.png> > > What am I doing wrong ? > > How do other people do it ? > >> On 31 Jan 2019, at 08:18, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> >> It is working now again as expected. >> >> The only difference is that you need to use "Github-Create new branch for issue..." instead of "Pharo-Create new branch for issue..." for the new issues reported on GitHub. >> >> -- Pavel >> >> st 30. 1. 2019 v 9:42 odesÃlatel Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> napsal: >> Hi, >> >> there is an issue for this problem, >> >> https://github.com/pharo-project/pharo/issues/2379 >> >> We have identified the cause, I'll propose a fix now >> >> On Wed, Jan 30, 2019 at 8:44 AM ducasse <stepharo(a)netcourrier.com> wrote: >> > >> > There is currently a bug eating one character of the commit hash. So >> > Iceberg does not find the hash and thinks we need a fetch. So currently >> > we need to checkout Pharo8.0 in order to be in a good state :( >> >> OOPs is there a bug entry? >> > >> >> I also don't understand how to make an issue branch for >> >> >> >> https://github.com/pharo-project/pharo/issues/2395 >> >> >> >> Is it Iceberg > Pharo > Create new branch for issue or Iceberg > Github > Create new branch for issue ? >> > >> > Just create a branch and choose the option to create a branch from a >> > Github option. >> > >> > The other one was for Manuscript and is now useless for Pharo 8. I >> > opened an issue in Iceberg to remove it but I did not got the time to >> > contribute the change. >> > >> >> What is the difference ? >> >> What about the Remote ? >> >> Can I work with only an issue on GitHub ? >> >> >> > >> > Yes! >> > >> > What I am doing currently: >> > >> > - Open an issue XX >> > - Sync my fork Pharo8.0 branch via command line (This is optional and >> > can also be done in Pharo. I just do it via command line because I like >> > it better that way) >> >> how do you do it? Pull? >> >> > - Download a Pharo 8 image >> > - Checkout the Pharo8.0 branch to get in a clean state because of the >> > hash eating bug I mentioned earlier >> > - Create a new branch from a github issue of the pharo remote >> > - Do the changes and commit. I add `Fixes #XX` in the commit message to >> > close automatically the issue when the PR is merged. >> > - Push to my remote >> > - Open a PR against Pharo8.0 through Iceberg > GitHub > Create new pull >> > request >> >> and checkout the pharo 8 branch to fix the next one. >> > >> >> Is the documentation >> >> >> >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >> >> >> >> really up to date ? >> >> >> > >> > No >> > >> > We should correct the hash eating bug before updating it I think. >> > >> >> Sven >> >> >> >> >> > >> > >> > -- >> > Cyril Ferlicot >> > https://ferlicot.fr >> > >> >> >> >> >> >> -- >> >> 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 >> >> Web: http://guillep.github.io >> Phone: +33 06 52 70 66 13 >

Feb. 1, 2019

Re: [Pharo-dev] Contribute to pharo8.0 ?

by Sven Van Caekenberghe

I am still stuck. I did $ curl -L get.pharo.org/64/80+vm | bash Repaired by specifying my local clone Repaired by fetching Not in detached state, cannot make branch from issue, screenshot: What am I doing wrong ? How do other people do it ? > On 31 Jan 2019, at 08:18, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > It is working now again as expected. > > The only difference is that you need to use "Github-Create new branch for issue..." instead of "Pharo-Create new branch for issue..." for the new issues reported on GitHub. > > -- Pavel > > st 30. 1. 2019 v 9:42 odesÃlatel Guillermo Polito <guillermopolito(a)gmail.com> napsal: > Hi, > > there is an issue for this problem, > > https://github.com/pharo-project/pharo/issues/2379 > > We have identified the cause, I'll propose a fix now > > On Wed, Jan 30, 2019 at 8:44 AM ducasse <stepharo(a)netcourrier.com> wrote: > > > > There is currently a bug eating one character of the commit hash. So > > Iceberg does not find the hash and thinks we need a fetch. So currently > > we need to checkout Pharo8.0 in order to be in a good state :( > > OOPs is there a bug entry? > > > >> I also don't understand how to make an issue branch for > >> > >> https://github.com/pharo-project/pharo/issues/2395 > >> > >> Is it Iceberg > Pharo > Create new branch for issue or Iceberg > Github > Create new branch for issue ? > > > > Just create a branch and choose the option to create a branch from a > > Github option. > > > > The other one was for Manuscript and is now useless for Pharo 8. I > > opened an issue in Iceberg to remove it but I did not got the time to > > contribute the change. > > > >> What is the difference ? > >> What about the Remote ? > >> Can I work with only an issue on GitHub ? > >> > > > > Yes! > > > > What I am doing currently: > > > > - Open an issue XX > > - Sync my fork Pharo8.0 branch via command line (This is optional and > > can also be done in Pharo. I just do it via command line because I like > > it better that way) > > how do you do it? Pull? > > > - Download a Pharo 8 image > > - Checkout the Pharo8.0 branch to get in a clean state because of the > > hash eating bug I mentioned earlier > > - Create a new branch from a github issue of the pharo remote > > - Do the changes and commit. I add `Fixes #XX` in the commit message to > > close automatically the issue when the PR is merged. > > - Push to my remote > > - Open a PR against Pharo8.0 through Iceberg > GitHub > Create new pull > > request > > and checkout the pharo 8 branch to fix the next one. > > > >> Is the documentation > >> > >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > >> > >> really up to date ? > >> > > > > No > > > > We should correct the hash eating bug before updating it I think. > > > >> Sven > >> > >> > > > > > > -- > > Cyril Ferlicot > > https://ferlicot.fr > > > > > > > > -- > > 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 > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

Feb. 1, 2019

Re: [Pharo-dev] Why RBComment is not RBCommentNode?

by ducasse

> On 31 Jan 2019, at 20:59, Manuel Leuenberger <leuenberger(a)inf.unibe.ch> wrote: > > +1 > > This would also help with the auto-formatter. This guy seems to put comments wherever it likes to put it. Iâm slowly working on tests and a new formatter but I got distracted. If someone wants to help let me know. The code is in mybecher/BlueInk on my github account. https://github.com/Ducasse/mybecher I would like to be able to really use it to reformat all Pharo But it will take time because Iâm eaten by admin. Stef >> On 31 Jan 2019, at 20:57, ducasse <stepharo(a)netcourrier.com> wrote: >> >> >> Hi >> >> In my journey in Pharo AST node I found RBComment and it is not a Node and I wonder why. >> To me RBComment should be a subclass of RBProgramNode and renamed RBCommentNode. >> >> Stef >> > >

Jan. 31, 2019

Re: [Pharo-dev] Why RBComment is not RBCommentNode?

by Manuel Leuenberger

+1 This would also help with the auto-formatter. This guy seems to put comments wherever it likes to put it. > On 31 Jan 2019, at 20:57, ducasse <stepharo(a)netcourrier.com> wrote: > > > Hi > > In my journey in Pharo AST node I found RBComment and it is not a Node and I wonder why. > To me RBComment should be a subclass of RBProgramNode and renamed RBCommentNode. > > Stef >

Jan. 31, 2019

Why RBComment is not RBCommentNode?

by ducasse

Hi In my journey in Pharo AST node I found RBComment and it is not a Node and I wonder why. To me RBComment should be a subclass of RBProgramNode and renamed RBCommentNode. Stef

Jan. 31, 2019

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Torsten Bergmann

[ Pharo current ] fork

Jan. 31, 2019

DuplicatedSlotName empty pre-debugger

by HernÃ¡n Morales Durand

Hi, When loading OpenPonk in Pharo 7, I have a duplicated slot name entry pre-debugger window but is empty (see attachment). Is this behavior well-known or on purpose? Cheers, HernÃ¡n

Jan. 31, 2019