December 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

download latest image and follow the steps explained here: https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> Esteban > On 16 Dec 2017, at 09:07, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > esteban > > to try the new way. What should I do? > Just download a new version or reclone? May be I will refork and > reclone to be sure. > > Stef > > On Sat, Dec 16, 2017 at 9:05 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >>> On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> Hi Esteban, >>> >>> I had no problems following the process (Ubuntu 16.04, >>> Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-) >>> >>> I guess that you have already thought of this, but... Is there any >>> reason why we can't just put up a dialog asking for the user's github >>> credentials and fogbugz issue number and then automatically clone the >>> repository, configure the upstream remote and create the issue branch. >>> That would remove most of the remaining manual steps. >>> >>> I realise that it only works for option 1, although where people >>> configure a common pharo-local, it could check for a pre-existing >>> clone and use that one. >> >> "I realiseâ means you tried and it didnât work? >> because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :) >> >> Esteban >> >>> >>> Cheers, >>> Alistair >>> >>> On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> Hi! >>>> >>>> Iâm working on simplifying the contribution process, after collecting >>>> opinions/experiences last couple of months. >>>> As you know, Pharo contribution process is still WIP and we aim to have it >>>> as smooth as possible for Pharo 7.0 release. Now, after observe the idea of >>>> the âsystem repositoriesâ was a bad idea because it introduced extra and non >>>> standard âpathâ to contribution, I managed to remove that to reestablish >>>> âthe regular wayâ: you will now need to add pharo repository just as any >>>> other repository you add, by cloning or adding local repository. >>>> >>>> I took Guilleâs doc and moved it to pharo project (it does not has sense to >>>> have it living in a contributorâs repository when is so important). You can >>>> find it here: >>>> >>>> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >>>> >>>> This document is also updated to reveal this new process, please read it. >>>> >>>> How to update your startup scripts? >>>> Some people has added startup scripts to easy the first part of >>>> contribution. Instead enabling system repositories, etc. you now need to >>>> replace that with this: >>>> >>>> (IceRepositoryCreator new >>>> location: '/path/to/pharo-project/pharo' asFileReference; >>>> subdirectory: 'src'; >>>> createRepository) >>>> register >>>> >>>> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is very >>>> important that document reflects new process and works reliable in different >>>> scenarios (I validated it on macOS and Windows, and assumed it worked fine >>>> on linux but you knowâ¦ bad assumptions is the base of failure ;) ) >>>> >>>> Iâm eager to hear your feedback and continue enhancing the process. >>>> >>>> (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) >>>> >>>> cheers! >>>> Esteban >>> >> >> >

Dec. 16, 2017

Re: [Pharo-dev] Does pharo build not retry anymore?

by Stephane Ducasse

Pavel what was the problem? Stef On Tue, Dec 12, 2017 at 9:34 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > The variable value was reverted to the original value. Thanks. > > -- Pavel > > 2017-12-12 20:13 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> Yes, with Marcus we decreased the retryTimes variable two weeks ago to 1 >> because in that time the validations were in really bad shape and literally >> every validation failed on some random issue and the retries caused >> enormous build times. It was producing more troubles than profit. It >> probably can be reverted now because the main problem of the validation >> instability was suppressed. I will prepare a PR. >> >> -- Pavel >> >> 2017-12-12 18:52 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> I see that we are retrying tests only once, which is causing most (if >>> not all) pull requests to fail sporadically... >>> >>> Maybe it got lost because of a mistake? >>> >>> Also, I'd like that changes in the build process are discussed in the >>> mailing list from time to time... I've put a lot of effort into making it >>> work and if we have regressions I'd like to understand them... >>> >>> Guille >>> >>> -- >>> >>> >>> >>> 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 <+33%206%2052%2070%2066%2013> >>> >> >> >

Dec. 16, 2017

Re: [Pharo-dev] [Pharo6][CI] test runs on submitted slices works again

by Stephane Ducasse

Thanks you guys!!!!! On Wed, Dec 13, 2017 at 1:08 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Pavel fixed the test runner (the monkey) for Pharo6. That means, back ports and fixes now can be checked > as they used to: > > -> submit slice > -> put issue on âfix review neededâ > -> monkey will run all test > > For a while all these tests failed (due to issue 20788). We used a workaround (not run that test). > > Having the monkey-checker for Pharo6 again running is good as this simplifies very much backporting. > > > Marcus > >

Dec. 16, 2017

Re: [Pharo-dev] Do we have this iterator?

by Stephane Ducasse

ouaaahhhhhh ;) My problem was that I had complex lines as elements. and I will not be able to remember and express anything with regex On Tue, Dec 12, 2017 at 4:36 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > If your input was a string instead of a list of lines, you had: > > '[^4]*4|.+' asRegex matchesIn: '1234123123456' >>>> > "an OrderedCollection('1234' '1231234' '56')" > > MartÃn > > On Tue, Dec 12, 2017 at 9:33 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Thanks sean. >> I will build it because for example I had list of lines and I needed >> to split the input depending >> on patterns inside the lines.... and sadly this was not for an advent of >> code. >> >> Rmoders suggested >> aggregateRuns: >> splitOn: >> but this is not the same. >> >> >> Stef >> >> On Tue, Dec 12, 2017 at 2:33 AM, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >> > Stephane Ducasse-3 wrote >> >> #(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4) >> >>>>> {#(1 2 3 4) . #( 1 2 3 5 6 )} >> > >> > The shortest kernel thing I could come up with took two steps: `{ #(1 2 >> > 3 4 >> > 1 2 3 5 6 ) copyUpThrough: 4. >> > #(1 2 3 4 1 2 3 5 6 ) copyAfter: 4 }`. The splitting messages seem to >> > all >> > eat the separator. >> > >> > >> > >> > ----- >> > Cheers, >> > Sean >> > -- >> > Sent from: >> > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > >> >

Dec. 16, 2017

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

esteban to try the new way. What should I do? Just download a new version or reclone? May be I will refork and reclone to be sure. Stef On Sat, Dec 16, 2017 at 9:05 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Esteban, >> >> I had no problems following the process (Ubuntu 16.04, >> Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-) >> >> I guess that you have already thought of this, but... Is there any >> reason why we can't just put up a dialog asking for the user's github >> credentials and fogbugz issue number and then automatically clone the >> repository, configure the upstream remote and create the issue branch. >> That would remove most of the remaining manual steps. >> >> I realise that it only works for option 1, although where people >> configure a common pharo-local, it could check for a pre-existing >> clone and use that one. > > "I realiseâ means you tried and it didnât work? > because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :) > > Esteban > >> >> Cheers, >> Alistair >> >> On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> Hi! >>> >>> Iâm working on simplifying the contribution process, after collecting >>> opinions/experiences last couple of months. >>> As you know, Pharo contribution process is still WIP and we aim to have it >>> as smooth as possible for Pharo 7.0 release. Now, after observe the idea of >>> the âsystem repositoriesâ was a bad idea because it introduced extra and non >>> standard âpathâ to contribution, I managed to remove that to reestablish >>> âthe regular wayâ: you will now need to add pharo repository just as any >>> other repository you add, by cloning or adding local repository. >>> >>> I took Guilleâs doc and moved it to pharo project (it does not has sense to >>> have it living in a contributorâs repository when is so important). You can >>> find it here: >>> >>> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >>> >>> This document is also updated to reveal this new process, please read it. >>> >>> How to update your startup scripts? >>> Some people has added startup scripts to easy the first part of >>> contribution. Instead enabling system repositories, etc. you now need to >>> replace that with this: >>> >>> (IceRepositoryCreator new >>> location: '/path/to/pharo-project/pharo' asFileReference; >>> subdirectory: 'src'; >>> createRepository) >>> register >>> >>> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is very >>> important that document reflects new process and works reliable in different >>> scenarios (I validated it on macOS and Windows, and assumed it worked fine >>> on linux but you knowâ¦ bad assumptions is the base of failure ;) ) >>> >>> Iâm eager to hear your feedback and continue enhancing the process. >>> >>> (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) >>> >>> cheers! >>> Esteban >> > >

Dec. 16, 2017

Re: [Pharo-dev] Moving from mc to tonel?

by Stephane Ducasse

It would be great to be able to sanitize the files. We should get a test about tonel misbehavior. Stef On Thu, Dec 14, 2017 at 3:11 PM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Stephan Eggermont-3 wrote >> On 05-12-17 08:59, Peter UhnÃ¡k wrote: >>> > In my case, it turned out to be a non-UTF8 encoded character in one >>> of the commit messages. >>> >>> I've ran into this problem in a sister project (tonel-migration), and do >>> not have a proper resolution yet. I was forcing everything to be >>> unicode, so I need a better way to read and write encoded strings. :< >> >> To be exact, exactly none of the older commits will be UTF8 encoded. For >> most it doesn't matter as they are ASCII, but if we want to have a >> change of converting older french or german code (or japanese), we need >> support for what was done with WideString. That probably needs a look in >> the squeak mailing list archives. >> >> Stephan > > The mcz reader used to import the .bin file (which contained correctly > serialized WideStrings), only falling back to reading the .st file if .bin > was not present, has this changed? > > Or do these tools explicitly ignore the .bin file and try to read the .st > file directly? > If so, the MCDataStream class used to read .bin format still seems to be in > the image... > > One could also create a tool to check/convert all mcz in a repo as a > preprocess; > if .bin contents decode as WideString, > check that .st starts with utf8 BOM, > if not, convert. > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Dec. 16, 2017

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

> On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Esteban, > > I had no problems following the process (Ubuntu 16.04, > Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-) > > I guess that you have already thought of this, but... Is there any > reason why we can't just put up a dialog asking for the user's github > credentials and fogbugz issue number and then automatically clone the > repository, configure the upstream remote and create the issue branch. > That would remove most of the remaining manual steps. > > I realise that it only works for option 1, although where people > configure a common pharo-local, it could check for a pre-existing > clone and use that one. "I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :) Esteban > > Cheers, > Alistair > > On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi! >> >> Iâm working on simplifying the contribution process, after collecting >> opinions/experiences last couple of months. >> As you know, Pharo contribution process is still WIP and we aim to have it >> as smooth as possible for Pharo 7.0 release. Now, after observe the idea of >> the âsystem repositoriesâ was a bad idea because it introduced extra and non >> standard âpathâ to contribution, I managed to remove that to reestablish >> âthe regular wayâ: you will now need to add pharo repository just as any >> other repository you add, by cloning or adding local repository. >> >> I took Guilleâs doc and moved it to pharo project (it does not has sense to >> have it living in a contributorâs repository when is so important). You can >> find it here: >> >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >> >> This document is also updated to reveal this new process, please read it. >> >> How to update your startup scripts? >> Some people has added startup scripts to easy the first part of >> contribution. Instead enabling system repositories, etc. you now need to >> replace that with this: >> >> (IceRepositoryCreator new >> location: '/path/to/pharo-project/pharo' asFileReference; >> subdirectory: 'src'; >> createRepository) >> register >> >> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is very >> important that document reflects new process and works reliable in different >> scenarios (I validated it on macOS and Windows, and assumed it worked fine >> on linux but you knowâ¦ bad assumptions is the base of failure ;) ) >> >> Iâm eager to hear your feedback and continue enhancing the process. >> >> (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) >> >> cheers! >> Esteban >

Dec. 16, 2017

Re: [Pharo-dev] Epicea feedback - save points

by Stephane Ducasse

I love epicea :) Did you see that now people use my extension to generate docs :) Stef On Sat, Dec 16, 2017 at 9:03 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thanks Martin!!! > > On Wed, Dec 13, 2017 at 1:29 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> Hi >> >> When you "save and close" or "save as..." then next changes will go to a new >> log file. Then, they will have a new item of the left of the browser (as >> Stef said). >> When you just "save", I agree I'd like that. It was there originally but I >> disabled it because of a bug related with the announcement. Apparently now >> it can be re-enabled: >> https://pharo.fogbugz.com/f/cases/18754/Epicea-should-log-image-saving >> >> MartÃn >> >> On Wed, Dec 13, 2017 at 8:52 AM, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >>> >>> Ok so we should check because it should not be complex to add that. >>> The model is quite nice. >>> >>> On Wed, Dec 13, 2017 at 11:47 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> > Hi Stef, >>> > >>> > I think that is incorrect. Its easy to be certain... >>> > 1. Open Epicea >>> > 2. Save and continue >>> > 3. Open Epicea and observe there is no difference >>> > >>> > cheers -ben >>> > >>> > >>> > On 13 December 2017 at 17:59, Stephane Ducasse <stepharo.self(a)gmail.com> >>> > wrote: >>> >> >>> >> I think that epicea save point are the list elements on the left. >>> >> >>> >> >>> >> On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl <norbert(a)hartl.name> >>> >> wrote: >>> >> > Same for me. I thought the last save point would be the last session >>> >> > in >>> >> > the list but I donât think that is really true. So Iâm confused by >>> >> > Epicea, >>> >> > too. >>> >> > >>> >> > Norbert >>> >> > >>> >> >> Am 13.12.2017 um 08:27 schrieb Ben Coman <btc(a)openinworld.com>: >>> >> >> >>> >> >> When I'm in need Epicea, the common scenario is that I've working in >>> >> >> the same session of an Image most of the day, or even days, and I've >>> >> >> done >>> >> >> something stupid to lock up the UI, and its only been an hour since >>> >> >> my last >>> >> >> save point (force of habit). When I review Epicea, "Filter > Show >>> >> >> latest >>> >> >> changes" its still ahrd to determine which changes I'm missing. >>> >> >> What I've >>> >> >> just realised is I miss the visibility of the Save Point in the old >>> >> >> changes >>> >> >> system. I'd find it really useful for the save points to be show in >>> >> >> the >>> >> >> changes list, and also a filter I'd find really useful is "Shows >>> >> >> latest >>> >> >> changes since last save". >>> >> >> >>> >> >> >>> >> >> cheers -ben >>> >> > >>> >> >>> > >>> >>

Dec. 16, 2017

Re: [Pharo-dev] Epicea feedback - save points

by Stephane Ducasse

Thanks Martin!!! On Wed, Dec 13, 2017 at 1:29 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi > > When you "save and close" or "save as..." then next changes will go to a new > log file. Then, they will have a new item of the left of the browser (as > Stef said). > When you just "save", I agree I'd like that. It was there originally but I > disabled it because of a bug related with the announcement. Apparently now > it can be re-enabled: > https://pharo.fogbugz.com/f/cases/18754/Epicea-should-log-image-saving > > MartÃn > > On Wed, Dec 13, 2017 at 8:52 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Ok so we should check because it should not be complex to add that. >> The model is quite nice. >> >> On Wed, Dec 13, 2017 at 11:47 AM, Ben Coman <btc(a)openinworld.com> wrote: >> > Hi Stef, >> > >> > I think that is incorrect. Its easy to be certain... >> > 1. Open Epicea >> > 2. Save and continue >> > 3. Open Epicea and observe there is no difference >> > >> > cheers -ben >> > >> > >> > On 13 December 2017 at 17:59, Stephane Ducasse <stepharo.self(a)gmail.com> >> > wrote: >> >> >> >> I think that epicea save point are the list elements on the left. >> >> >> >> >> >> On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl <norbert(a)hartl.name> >> >> wrote: >> >> > Same for me. I thought the last save point would be the last session >> >> > in >> >> > the list but I donât think that is really true. So Iâm confused by >> >> > Epicea, >> >> > too. >> >> > >> >> > Norbert >> >> > >> >> >> Am 13.12.2017 um 08:27 schrieb Ben Coman <btc(a)openinworld.com>: >> >> >> >> >> >> When I'm in need Epicea, the common scenario is that I've working in >> >> >> the same session of an Image most of the day, or even days, and I've >> >> >> done >> >> >> something stupid to lock up the UI, and its only been an hour since >> >> >> my last >> >> >> save point (force of habit). When I review Epicea, "Filter > Show >> >> >> latest >> >> >> changes" its still ahrd to determine which changes I'm missing. >> >> >> What I've >> >> >> just realised is I miss the visibility of the Save Point in the old >> >> >> changes >> >> >> system. I'd find it really useful for the save points to be show in >> >> >> the >> >> >> changes list, and also a filter I'd find really useful is "Shows >> >> >> latest >> >> >> changes since last save". >> >> >> >> >> >> >> >> >> cheers -ben >> >> > >> >> >> > >> >

Dec. 16, 2017

Re: [Pharo-dev] Implementors of margins in GLMRubScrolledTextBrick

by Stephane Ducasse

Argh! I did not thought about it. So it may means that my changes are breaking the system. Aliaksei DNU is a ship way. The other way is as you expect I'm sure adding a method that just does the delegation. What we can do is to turn the DNU into a DNU compiling methods like that after a while we will have the method compiled and we will able to remove the DNU trick. stef On Thu, Dec 14, 2017 at 6:46 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > GLMRubScrolledTextBrick is a wrapper around RubScrollTextMorph. > I see that it is a common practice in Pharo to implement decorator / wrapper > pattern using doesNotUnderstand:. > > Reference: > - AthensWrappedWorldDisplay > - DictionaryValueHolder > - MorphicTreeAdapter > - RubEditingArea > - RubParagraphDecorator > > - RTShapeBuilder > - RTShowLabel > > Is there a better way to implement a decorator or a wrapper around the > object with many api methods rather then doesNotUnderstand:? > > Cheers, > Alex > > On 9 December 2017 at 17:45, Henrik-Nergaard <draagren(a)outlook.com> wrote: >> >> >>GLMRubScrolledTextBrick>>withoutMargins uses self margins: but I >> cannot find the method. >> This is because it is implemented in RubScrollTextMorph. >> GLMRubScrolledTextBrick implements #doesNotUnderstand: to send it to the >> rubric object. >> see: >> >> https://pharo.fogbugz.com/f/cases/17888/GLMRubScrolledTextBrick-relies-on-d… >> >> Best regards, >> Henrik >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >

Dec. 15, 2017