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

Re: [Pharo-dev] [ANN] Pharo TechTalk Dec 19: Contributing to Pharo7

by Marcus Denker

Hi, Due to complete pre-holiday stress we sadly have to postpone this. > On 1 Dec 2017, at 09:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Pharo TechTalk December 19: > > - 19 Dec 2017 5:00 PM - 7:00 PM (UTC+01:00) > - Where? Discord / Youtube live > > Topic: Contributing. How to report bugs, submit code change. > > This will be a hands-on session where we show how to > > â¢ report bugs > â¢ create pull requests > â¢ help reviewing issues and pull requests > > > https://association.pharo.org/event-2642666

Dec. 19, 2017

Re: [Pharo-dev] Failing tests in #development

by Esteban Lorenzano

but this is because we still need to stabilise the CI: what happens now is that we know some tests are failing randomly then we do not trust the CI to tell us everything is ok. Then we accept PRs in red state. Of course, this will fail eventually, and thatâs what we are seeing. Most important thing, IMO is to fix the CI: those tests that fails randomly (I think most of them are networking problems) needs to be fixed or removed. You would say âyou cannot remove a test of Xâ but in fact, a test that fails because of non controllable reasons is a bad test. Then, we need to have a âno red integrationâ policy. This will fix this problems, but of course, we need to work to make this happen ;) Esteban > On 18 Dec 2017, at 09:21, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > The same for https://github.com/pharo-project/pharo/pull/514 <https://github.com/pharo-project/pharo/pull/514> > > :-( > > 2017-12-18 9:12 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>>: > it was a bad idea to integrate PR 606 [1] about the world menu tooltips before it was green. Now we have failing tests in the development branch and validations of new pull requests will fail immediately. > > Btw. I do not think this test should be in the ReleaseTest because these tests should be valid for the minimal image too. > > [1] https://github.com/pharo-project/pharo/pull/606 <https://github.com/pharo-project/pharo/pull/606> > > -- Pavel > >

Dec. 19, 2017

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

by Denis Kudriashov

Hi. I try to start from scratch. I made changes and then after synchronisation I close the window without committing. And now pharo repo is not dirty anymore and I do not see any changes with new sync request. Full sync helps but now there are other changes which I did not do. 2017-12-16 21:50 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > BTW I do not understand why I have changes that I do not do in my image > it displays the changes with a dot and the end. > > And also I do not get why the class comment get changed when I do not > do anything. > Do you experience the same? > > > BTW I did the pull from pharo and push to my fork by hand to synchronise. > So I will try the synchronise menu item. I saw it but did not dare to use > it. > > On Sat, Dec 16, 2017 at 9:48 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > Sure I need because I stage my work. So I need something to be > > integrated to use it. > > > > On Sat, Dec 16, 2017 at 6:53 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> > >> > >>> On 16 Dec 2017, at 17:55, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >>> > >>> Hi Esteban > >>> > >>> Now how can I maintain my fork up to date? > >> > >> there is a âsynchronise repositoriesâ option there, at the side of > âcreate branch from fogbugzâ. > >> > >>> This is not in the tutorial and to me it was a major problem and a big > >>> source of pain. > >> > >> it is not there because you do not need it. > >> when you âcreate branch from fogbugzâ, it will take your image version > and branch from there. Then, when you push to your remote, you will push > correctly. There is no need to have syncd the forks to contributeâ¦ > >> > >> Now, if you do âsynchronise repositoriesâ, it will take what is in > pharo-project/pharo/development branch and it will sync that with your > pharo/development branch. But againâ¦ there is no need to do this to > contribute. > >> > >> Esteban > >> > >>> Stef > >>> > >>> On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse > >>> <stepharo.self(a)gmail.com> wrote: > >>>> I committed my code for issue 20861 and I do not understand what I see > >>>> > >>>> I do not understand why I get local changes with empty packages. :( > >>>> > >>>> Stef > >>>> > >>>> On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse > >>>> <stepharo.self(a)gmail.com> wrote: > >>>>> I did a little pass on the wiki to make the flow clearer > >>>>> > >>>>> > >>>>> On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse > >>>>> <stepharo.self(a)gmail.com> wrote: > >>>>>> In the tutorial: > >>>>>> > >>>>>> - Put a little heading before > >>>>>> > >>>>>> "You need to add pharo repository as a remote > >>>>>> (git@github.com:pharo-project/pharo.git)." > >>>>>> > >>>>>> On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse > >>>>>> <stepharo.self(a)gmail.com> wrote: > >>>>>>> I double clicked and it did a massive amount of stuff and finally > told > >>>>>>> me that it is up to date. > >>>>>>> > >>>>>>> > >>>>>>> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse > >>>>>>> <stepharo.self(a)gmail.com> wrote: > >>>>>>>> OK so I restarted everything from scratch: > >>>>>>>> - deleted my fork > >>>>>>>> - reforked > >>>>>>>> - clone pharo again > >>>>>>>> - here is some feedback > >>>>>>>> > >>>>>>>> In the tutorial add /pharo + src in the screenshot > >>>>>>>> > >>>>>>>> > >>>>>>>> Then when I add the local repository I get uncommited changes and > I do > >>>>>>>> not understand why? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano < > estebanlm(a)gmail.com> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >>>>>>>>> > >>>>>>>>> Hi Esteban, > >>>>>>>>> > >>>>>>>>> On 16 December 2017 at 09:05, 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 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The contribution process works fine (even on linux :-)). > >>>>>>>>> > >>>>>>>>> The "I realise" paragraph is a comment on my suggestion to try > and > >>>>>>>>> reduce the number of manual steps required (and is actually > wrong). > >>>>>>>>> Just to rephrase (and extend) the suggestion, I think we could > create > >>>>>>>>> a single dialog that currently covers the following steps (from > your > >>>>>>>>> instructions): > >>>>>>>>> > >>>>>>>>> 1. Clone a fresh repository, or point to an existing repository. > >>>>>>>>> 2. Tell Iceberg about pharo-project > >>>>>>>>> 3. Create a new branch from the fogbugz issue > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ah, I got lost in translation ;) > >>>>>>>>> > >>>>>>>>> Esteban > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> Alistair > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> 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. 19, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference

by Alistair Grant

On 18 December 2017 at 11:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Sun, Dec 17, 2017 at 7:00 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Yes I check the code and since a collection already has readStream and >> writeStream. >> This is ok. >> >> I did not like the idea that we introduced this change just for the >> sake of having strings polymorphic to fileReference. > > > Yes, I don't see that it is bad in itself. Actually, I think the name of the > issue is misleading :). I don't think about this issue as "make strings and > files polymorphic" but "make streamable things polymorphic". If you know you > receive a container with some contents (may be a string, a file, a socket, a > zipfile...), you don't care about what the container is but if it is > streamable. You want the contents! > > #readStreamDo: allows you to interface with such a streamable object without > caring about its source. It is the source responsibility to close itself or > not after the stream was used. +1 Cheers, Alistair >> For the record readStreamDo: on collection does not close the stream. >> >> Stef >> >> On Sat, Dec 16, 2017 at 5:15 PM, Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >> > Hi Stef, >> > >> > On 16 December 2017 at 16:58, Stephane Ducasse <stepharo.self(a)gmail.com> >> > wrote: >> >> So I would like to understand (sincerly) what was the problem and what >> >> is the gain? >> >> I learned that we can ask a collection a readStream and writeStream >> >> already. >> >> And now we can do anyCollection readStreamDo: and writeStreamDo: >> >> Why not? >> > >> > Cyril proposed this, so may chime in with more information, but... >> > >> > Take a look at >> > http://forum.world.st/Polymorphism-between-Strings-and-FileReference-tt5059… >> > >> > The advantages are: >> > >> > - provides polymorphism with FileReference >> > - you don't need to know whether the stream needs to be closed or not >> > as read/writeStreamDo: takes care of it for you. >> > >> > >> > >> >> On Sat, Dec 16, 2017 at 4:42 PM, Stephane Ducasse >> >> <stepharo.self(a)gmail.com> wrote: >> >>> Hi >> >>> >> >>> Do we really want this? >> >>> I do not understand why a string is a fileReference? >> >>> String has far too many methods and we are even adding more and I do >> >>> not understand why. >> > >> > Can you clarify what you're asking (about "why a string is a >> > fileReference")? >> > >> > To be clear, SequencableCollection>>read/writeStreamDo: open a stream >> > on the receiver (typically a string) and then pass it to the supplied >> > block. Nothing to do with a fileReference (apart from the >> > polymorphism). >> > >> > Cheers, >> > Alistair >> > >> > > > > -- > > > > 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

Dec. 18, 2017

Re: [Pharo-dev] [Ann] New Calypso version 0.8

by Denis Kudriashov

2017-12-18 10:31 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > > On Mon, Dec 18, 2017 at 9:56 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> And I made new release v0.8.4 which solves performance problem. >> I found very nice solution to ensures single Calypso UI update after >> multiple changes from single UI command. >> For example implementors window updates only once when you rename >> implementor message. Before number of updates was equals to number of >> implementors because every rename triggers method remove. Same problem is >> relevant to current MessageBrowser. Now in Calypso there is general >> solution to the problem. >> > > Can you explain it? > Approach is quite simple but with little trick. Data source of table is responsible to update it when underlying query result is changed. And when it happens data source just marks itself as dirty and defer actual update to the next UI iteration using "UIManager default defer: [self runUpdate]". In case when data source is already dirty it just ignores the event. It means that current UI command will continue required system modifications without actual UI update. And only when it will complete the deferred update will be executed. Also update is forced in case when user manually interact with dirty data source. In that case following deferred update will be ignored. So I guess trick with dirty flag and deferring update can be reused by other applications. > > I think most UI apps will benefit from that :) > > >> >> Also in this version there is context menu item to switch order of class >> hierarchy in variables view and method visibility view. So people who >> prefer classic order for hierarchy should be satisfied. >> >> Best regards, >> Denis >> >> 2017-12-14 18:45 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> I found some performance problem with this version. >>> I know the reason. It will be fixed soon. >>> Now you can try disable critiques plugin with github instructions. >>> >>> 2017-12-12 13:52 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>>> >>>> >>>> 2017-12-12 13:25 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com >>>> >: >>>> >>>>> Hi Denis, >>>>> >>>>> Congratulations on the new release! Two quick question: >>>>> >>>> >>>> >>>>> 1) does this work on latest Pharo 6.1 ; >>>>> >>>> >>>> Yes >>>> >>>> >>>>> 2) Is it safe to update images with Calypso already installed by doing >>>>> the same baseline loading as the original installation ? >>>>> >>>> >>>> I think not. But I not try. I just have impression that complex updates >>>> are not properly work in Pharo. All package structure is changed and it can >>>> be a problem for such update. >>>> >>>> >>>>> >>>>> Thanks >>>>> >>>>> On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov < >>>>> dionisiydk(a)gmail.com> wrote: >>>>> >>>>>> Hello. >>>>>> >>>>>> I glad announce new Calypso version. It is a big refactoring on >>>>>> navigation model and browser pluggability. >>>>>> >>>>>> Look for details in my blog http://dionisiydk.blogspot.fr/ >>>>>> 2017/12/new-calypso-version-08-is-out.html. >>>>>> >>>>>> Now I start document new design and will post progress on it. >>>>>> >>>>>> Notice: this version is not adopted for TelePharo and Cargo. It will >>>>>> be done soon. >>>>>> >>>>>> Best regards, >>>>>> Denis >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>>> >>> >> > > > -- > > > > 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. 18, 2017

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

by Guillermo Polito

Hi, just to not mistake my intentions :) I don't care WHO removed the retry or WHO fixed it. I care about the WHY. If the WHY is not clear nor documented, we risk to make the mistake again. Please, let all of us be strict on the issue reports we do, and even stricter on ourselves. We need to raise the quality bar, not move it down! And regarding this particular issue, I'd like to raise a warning. Let's not fix symptoms, fix causes. If we fix the symptom, the problem is still there. And moreover, if we fix the symptom and we lose track of it, we may forget unless somebody realizes weeks afterwards and it is too late (not this case fortunately). On Sat, Dec 16, 2017 at 9:47 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > tx them too. > This is great to be surrounded by all you guys! > > > On Sat, Dec 16, 2017 at 8:22 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> The UI Manager problem was fixed by Pablo and Guille >> >> -- Pavel >> >> 2017-12-16 13:06 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> tx pavel >>> >>> On Sat, Dec 16, 2017 at 9:25 AM, Pavel Krivanek < >>> pavel.krivanek(a)gmail.com> wrote: >>> >>>> The problems were related UIManager initialization and consequences of >>>> the opening of the Welcome window. >>>> >>>> -- Pavel >>>> >>>> 2017-12-16 9:12 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>> >>>>> 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> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- 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

Dec. 18, 2017

Re: [Pharo-dev] Dictionary newFromKeys: andValues:

by Guillermo Polito

Yes I think this is good. On Fri, Dec 15, 2017 at 8:32 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > I was looking at the Dictionary instance creation API and I would like to > add > newFromKeys:andValues: > Because I do not see why I have to create associations when I have > already the two collections. > What do you think? > > Stef > > -- 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

Dec. 18, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference

by Guillermo Polito

On Sun, Dec 17, 2017 at 7:00 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Yes I check the code and since a collection already has readStream and > writeStream. > This is ok. I did not like the idea that we introduced this change just for the > sake of having strings polymorphic to fileReference. > Yes, I don't see that it is bad in itself. Actually, I think the name of the issue is misleading :). I don't think about this issue as "make strings and files polymorphic" but "make streamable things polymorphic". If you know you receive a container with some contents (may be a string, a file, a socket, a zipfile...), you don't care about what the container is but if it is streamable. You want the contents! #readStreamDo: allows you to interface with such a streamable object without caring about its source. It is the source responsibility to close itself or not after the stream was used. > > For the record readStreamDo: on collection does not close the stream. > > Stef > > On Sat, Dec 16, 2017 at 5:15 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > Hi Stef, > > > > On 16 December 2017 at 16:58, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> So I would like to understand (sincerly) what was the problem and what > >> is the gain? > >> I learned that we can ask a collection a readStream and writeStream > already. > >> And now we can do anyCollection readStreamDo: and writeStreamDo: > >> Why not? > > > > Cyril proposed this, so may chime in with more information, but... > > > > Take a look at http://forum.world.st/Polymorphism-between-Strings- > and-FileReference-tt5059220.html > > > > The advantages are: > > > > - provides polymorphism with FileReference > > - you don't need to know whether the stream needs to be closed or not > > as read/writeStreamDo: takes care of it for you. > > > > > > > >> On Sat, Dec 16, 2017 at 4:42 PM, Stephane Ducasse > >> <stepharo.self(a)gmail.com> wrote: > >>> Hi > >>> > >>> Do we really want this? > >>> I do not understand why a string is a fileReference? > >>> String has far too many methods and we are even adding more and I do > >>> not understand why. > > > > Can you clarify what you're asking (about "why a string is a > fileReference")? > > > > To be clear, SequencableCollection>>read/writeStreamDo: open a stream > > on the receiver (typically a string) and then pass it to the supplied > > block. Nothing to do with a fileReference (apart from the > > polymorphism). > > > > Cheers, > > Alistair > > > > -- 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

Dec. 18, 2017

Re: [Pharo-dev] [Ann] New Calypso version 0.8

by Guillermo Polito

On Mon, Dec 18, 2017 at 9:56 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > And I made new release v0.8.4 which solves performance problem. > I found very nice solution to ensures single Calypso UI update after > multiple changes from single UI command. > For example implementors window updates only once when you rename > implementor message. Before number of updates was equals to number of > implementors because every rename triggers method remove. Same problem is > relevant to current MessageBrowser. Now in Calypso there is general > solution to the problem. > Can you explain it? I think most UI apps will benefit from that :) > > Also in this version there is context menu item to switch order of class > hierarchy in variables view and method visibility view. So people who > prefer classic order for hierarchy should be satisfied. > > Best regards, > Denis > > 2017-12-14 18:45 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> I found some performance problem with this version. >> I know the reason. It will be fixed soon. >> Now you can try disable critiques plugin with github instructions. >> >> 2017-12-12 13:52 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> >>> >>> 2017-12-12 13:25 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> : >>> >>>> Hi Denis, >>>> >>>> Congratulations on the new release! Two quick question: >>>> >>> >>> >>>> 1) does this work on latest Pharo 6.1 ; >>>> >>> >>> Yes >>> >>> >>>> 2) Is it safe to update images with Calypso already installed by doing >>>> the same baseline loading as the original installation ? >>>> >>> >>> I think not. But I not try. I just have impression that complex updates >>> are not properly work in Pharo. All package structure is changed and it can >>> be a problem for such update. >>> >>> >>>> >>>> Thanks >>>> >>>> On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com >>>> > wrote: >>>> >>>>> Hello. >>>>> >>>>> I glad announce new Calypso version. It is a big refactoring on >>>>> navigation model and browser pluggability. >>>>> >>>>> Look for details in my blog http://dionisiydk.blogspot.fr/ >>>>> 2017/12/new-calypso-version-08-is-out.html. >>>>> >>>>> Now I start document new design and will post progress on it. >>>>> >>>>> Notice: this version is not adopted for TelePharo and Cargo. It will >>>>> be done soon. >>>>> >>>>> Best regards, >>>>> Denis >>>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >> > -- 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

Dec. 18, 2017

Re: [Pharo-dev] [Ann] New Calypso version 0.8

by Denis Kudriashov

Hi Juraj 2017-12-14 19:36 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: > Hi Denis, > > I use it without critiques and it works fine. > > I have some observations: > - test cases in an abstract class can be executed, it might be disabled as > it does not make sense to execute them > - test cases defined in a superclass cannot be executed separately (only > as all test cases by clicking on the class icon) > - it might be a good option to be able to execute failing test cases > (there is a dedicated method group that appears in such situations) > - and maybe also when browsing âinherited methodsâ > It is in my todo. For abstract test cases I do not think it should be disabled. It should run all hierarchy tests. It works like that in other IDE's and it is very suitable. > > Thanks for the great job! > Juraj > > On Dec 14, 2017, at 14:45, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > I found some performance problem with this version. > I know the reason. It will be fixed soon. > Now you can try disable critiques plugin with github instructions. > > 2017-12-12 13:52 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> >> 2017-12-12 13:25 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> Hi Denis, >>> >>> Congratulations on the new release! Two quick question: >>> >> >> >>> 1) does this work on latest Pharo 6.1 ; >>> >> >> Yes >> >> >>> 2) Is it safe to update images with Calypso already installed by doing >>> the same baseline loading as the original installation ? >>> >> >> I think not. But I not try. I just have impression that complex updates >> are not properly work in Pharo. All package structure is changed and it can >> be a problem for such update. >> >> >>> >>> Thanks >>> >>> On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> >>>> Hello. >>>> >>>> I glad announce new Calypso version. It is a big refactoring on >>>> navigation model and browser pluggability. >>>> >>>> Look for details in my blog http://dionisiydk.blogspot.fr/ >>>> 2017/12/new-calypso-version-08-is-out.html. >>>> >>>> Now I start document new design and will post progress on it. >>>> >>>> Notice: this version is not adopted for TelePharo and Cargo. It will be >>>> done soon. >>>> >>>> Best regards, >>>> Denis >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> > >

Dec. 18, 2017

Re: [Pharo-dev] [Ann] New Calypso version 0.8

by Denis Kudriashov

And I made new release v0.8.4 which solves performance problem. I found very nice solution to ensures single Calypso UI update after multiple changes from single UI command. For example implementors window updates only once when you rename implementor message. Before number of updates was equals to number of implementors because every rename triggers method remove. Same problem is relevant to current MessageBrowser. Now in Calypso there is general solution to the problem. Also in this version there is context menu item to switch order of class hierarchy in variables view and method visibility view. So people who prefer classic order for hierarchy should be satisfied. Best regards, Denis 2017-12-14 18:45 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I found some performance problem with this version. > I know the reason. It will be fixed soon. > Now you can try disable critiques plugin with github instructions. > > 2017-12-12 13:52 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> >> 2017-12-12 13:25 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> Hi Denis, >>> >>> Congratulations on the new release! Two quick question: >>> >> >> >>> 1) does this work on latest Pharo 6.1 ; >>> >> >> Yes >> >> >>> 2) Is it safe to update images with Calypso already installed by doing >>> the same baseline loading as the original installation ? >>> >> >> I think not. But I not try. I just have impression that complex updates >> are not properly work in Pharo. All package structure is changed and it can >> be a problem for such update. >> >> >>> >>> Thanks >>> >>> On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> >>>> Hello. >>>> >>>> I glad announce new Calypso version. It is a big refactoring on >>>> navigation model and browser pluggability. >>>> >>>> Look for details in my blog http://dionisiydk.blogspot.fr/ >>>> 2017/12/new-calypso-version-08-is-out.html. >>>> >>>> Now I start document new design and will post progress on it. >>>> >>>> Notice: this version is not adopted for TelePharo and Cargo. It will be >>>> done soon. >>>> >>>> Best regards, >>>> Denis >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >

Dec. 18, 2017

Re: [Pharo-dev] Failing tests in #development

by Pavel Krivanek

The same for https://github.com/pharo-project/pharo/pull/514 :-( 2017-12-18 9:12 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > it was a bad idea to integrate PR 606 [1] about the world menu tooltips > before it was green. Now we have failing tests in the development branch > and validations of new pull requests will fail immediately. > > Btw. I do not think this test should be in the ReleaseTest because these > tests should be valid for the minimal image too. > > [1] https://github.com/pharo-project/pharo/pull/606 > > -- Pavel > >

Dec. 18, 2017

Failing tests in #development

by Pavel Krivanek

it was a bad idea to integrate PR 606 [1] about the world menu tooltips before it was green. Now we have failing tests in the development branch and validations of new pull requests will fail immediately. Btw. I do not think this test should be in the ReleaseTest because these tests should be valid for the minimal image too. [1] https://github.com/pharo-project/pharo/pull/606 -- Pavel

Dec. 18, 2017

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

by Stephane Ducasse

This is my bookHelpers on SmalltalkHub. I extended Epicea and we can fileout changes into pillar or mardown. On Sat, Dec 16, 2017 at 4:40 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > El 16 dic. 2017 5:04 AM, "Stephane Ducasse" <stepharo.self(a)gmail.com> > escribiÃ³: > > I love epicea :) > Did you see that now people use my extension to generate docs :) > > > no i didnt! how could i see that? > > > 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. 17, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference

by Stephane Ducasse

Yes I check the code and since a collection already has readStream and writeStream. This is ok. I did not like the idea that we introduced this change just for the sake of having strings polymorphic to fileReference. For the record readStreamDo: on collection does not close the stream. Stef On Sat, Dec 16, 2017 at 5:15 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > On 16 December 2017 at 16:58, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> So I would like to understand (sincerly) what was the problem and what >> is the gain? >> I learned that we can ask a collection a readStream and writeStream already. >> And now we can do anyCollection readStreamDo: and writeStreamDo: >> Why not? > > Cyril proposed this, so may chime in with more information, but... > > Take a look at http://forum.world.st/Polymorphism-between-Strings-and-FileReference-tt5059… > > The advantages are: > > - provides polymorphism with FileReference > - you don't need to know whether the stream needs to be closed or not > as read/writeStreamDo: takes care of it for you. > > > >> On Sat, Dec 16, 2017 at 4:42 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> Hi >>> >>> Do we really want this? >>> I do not understand why a string is a fileReference? >>> String has far too many methods and we are even adding more and I do >>> not understand why. > > Can you clarify what you're asking (about "why a string is a fileReference")? > > To be clear, SequencableCollection>>read/writeStreamDo: open a stream > on the receiver (typically a string) and then pass it to the supplied > block. Nothing to do with a fileReference (apart from the > polymorphism). > > Cheers, > Alistair >

Dec. 17, 2017

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

by Stephane Ducasse

BTW I do not understand why I have changes that I do not do in my image it displays the changes with a dot and the end. And also I do not get why the class comment get changed when I do not do anything. Do you experience the same? BTW I did the pull from pharo and push to my fork by hand to synchronise. So I will try the synchronise menu item. I saw it but did not dare to use it. On Sat, Dec 16, 2017 at 9:48 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Sure I need because I stage my work. So I need something to be > integrated to use it. > > On Sat, Dec 16, 2017 at 6:53 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >>> On 16 Dec 2017, at 17:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Hi Esteban >>> >>> Now how can I maintain my fork up to date? >> >> there is a âsynchronise repositoriesâ option there, at the side of âcreate branch from fogbugzâ. >> >>> This is not in the tutorial and to me it was a major problem and a big >>> source of pain. >> >> it is not there because you do not need it. >> when you âcreate branch from fogbugzâ, it will take your image version and branch from there. Then, when you push to your remote, you will push correctly. There is no need to have syncd the forks to contributeâ¦ >> >> Now, if you do âsynchronise repositoriesâ, it will take what is in pharo-project/pharo/development branch and it will sync that with your pharo/development branch. But againâ¦ there is no need to do this to contribute. >> >> Esteban >> >>> Stef >>> >>> On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>> I committed my code for issue 20861 and I do not understand what I see >>>> >>>> I do not understand why I get local changes with empty packages. :( >>>> >>>> Stef >>>> >>>> On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse >>>> <stepharo.self(a)gmail.com> wrote: >>>>> I did a little pass on the wiki to make the flow clearer >>>>> >>>>> >>>>> On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse >>>>> <stepharo.self(a)gmail.com> wrote: >>>>>> In the tutorial: >>>>>> >>>>>> - Put a little heading before >>>>>> >>>>>> "You need to add pharo repository as a remote >>>>>> (git@github.com:pharo-project/pharo.git)." >>>>>> >>>>>> On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse >>>>>> <stepharo.self(a)gmail.com> wrote: >>>>>>> I double clicked and it did a massive amount of stuff and finally told >>>>>>> me that it is up to date. >>>>>>> >>>>>>> >>>>>>> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse >>>>>>> <stepharo.self(a)gmail.com> wrote: >>>>>>>> OK so I restarted everything from scratch: >>>>>>>> - deleted my fork >>>>>>>> - reforked >>>>>>>> - clone pharo again >>>>>>>> - here is some feedback >>>>>>>> >>>>>>>> In the tutorial add /pharo + src in the screenshot >>>>>>>> >>>>>>>> >>>>>>>> Then when I add the local repository I get uncommited changes and I do >>>>>>>> not understand why? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>> Hi Esteban, >>>>>>>>> >>>>>>>>> On 16 December 2017 at 09:05, 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> The contribution process works fine (even on linux :-)). >>>>>>>>> >>>>>>>>> The "I realise" paragraph is a comment on my suggestion to try and >>>>>>>>> reduce the number of manual steps required (and is actually wrong). >>>>>>>>> Just to rephrase (and extend) the suggestion, I think we could create >>>>>>>>> a single dialog that currently covers the following steps (from your >>>>>>>>> instructions): >>>>>>>>> >>>>>>>>> 1. Clone a fresh repository, or point to an existing repository. >>>>>>>>> 2. Tell Iceberg about pharo-project >>>>>>>>> 3. Create a new branch from the fogbugz issue >>>>>>>>> >>>>>>>>> >>>>>>>>> ah, I got lost in translation ;) >>>>>>>>> >>>>>>>>> Esteban >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Alistair >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

Sure I need because I stage my work. So I need something to be integrated to use it. On Sat, Dec 16, 2017 at 6:53 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 16 Dec 2017, at 17:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi Esteban >> >> Now how can I maintain my fork up to date? > > there is a âsynchronise repositoriesâ option there, at the side of âcreate branch from fogbugzâ. > >> This is not in the tutorial and to me it was a major problem and a big >> source of pain. > > it is not there because you do not need it. > when you âcreate branch from fogbugzâ, it will take your image version and branch from there. Then, when you push to your remote, you will push correctly. There is no need to have syncd the forks to contributeâ¦ > > Now, if you do âsynchronise repositoriesâ, it will take what is in pharo-project/pharo/development branch and it will sync that with your pharo/development branch. But againâ¦ there is no need to do this to contribute. > > Esteban > >> Stef >> >> On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> I committed my code for issue 20861 and I do not understand what I see >>> >>> I do not understand why I get local changes with empty packages. :( >>> >>> Stef >>> >>> On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>> I did a little pass on the wiki to make the flow clearer >>>> >>>> >>>> On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse >>>> <stepharo.self(a)gmail.com> wrote: >>>>> In the tutorial: >>>>> >>>>> - Put a little heading before >>>>> >>>>> "You need to add pharo repository as a remote >>>>> (git@github.com:pharo-project/pharo.git)." >>>>> >>>>> On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse >>>>> <stepharo.self(a)gmail.com> wrote: >>>>>> I double clicked and it did a massive amount of stuff and finally told >>>>>> me that it is up to date. >>>>>> >>>>>> >>>>>> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse >>>>>> <stepharo.self(a)gmail.com> wrote: >>>>>>> OK so I restarted everything from scratch: >>>>>>> - deleted my fork >>>>>>> - reforked >>>>>>> - clone pharo again >>>>>>> - here is some feedback >>>>>>> >>>>>>> In the tutorial add /pharo + src in the screenshot >>>>>>> >>>>>>> >>>>>>> Then when I add the local repository I get uncommited changes and I do >>>>>>> not understand why? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>>>>> >>>>>>>> Hi Esteban, >>>>>>>> >>>>>>>> On 16 December 2017 at 09:05, 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 >>>>>>>> >>>>>>>> >>>>>>>> The contribution process works fine (even on linux :-)). >>>>>>>> >>>>>>>> The "I realise" paragraph is a comment on my suggestion to try and >>>>>>>> reduce the number of manual steps required (and is actually wrong). >>>>>>>> Just to rephrase (and extend) the suggestion, I think we could create >>>>>>>> a single dialog that currently covers the following steps (from your >>>>>>>> instructions): >>>>>>>> >>>>>>>> 1. Clone a fresh repository, or point to an existing repository. >>>>>>>> 2. Tell Iceberg about pharo-project >>>>>>>> 3. Create a new branch from the fogbugz issue >>>>>>>> >>>>>>>> >>>>>>>> ah, I got lost in translation ;) >>>>>>>> >>>>>>>> Esteban >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Alistair >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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

tx them too. This is great to be surrounded by all you guys! On Sat, Dec 16, 2017 at 8:22 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > The UI Manager problem was fixed by Pablo and Guille > > -- Pavel > > 2017-12-16 13:06 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> tx pavel >> >> On Sat, Dec 16, 2017 at 9:25 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com >> > wrote: >> >>> The problems were related UIManager initialization and consequences of >>> the opening of the Welcome window. >>> >>> -- Pavel >>> >>> 2017-12-16 9:12 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>>> 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] Drag and drop of methods

by Stephane Ducasse

Thanks cyril. This is strange. May be this is due to the change of denis to improve spec. On Sat, Dec 16, 2017 at 7:37 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Hi, > > In the latest Pharo 7 I cannot drag and drop methods anymore in Nautilus. > > Pharo version: > Pharo-7.0+alpha.build.389.sha.e642e96a93951b2765dc808a512b81dc3d52e150 > (32 Bit) > > Stack: > > TransferMorph(Object)>>doesNotUnderstand: #buildWithSpec > FTPluggableIconListMorphAdaptorDataSource>>transferFor:from: > FTPluggableIconListMorphAdaptor(FTTableMorph)>>startDrag: > MouseClickState>>drag: > MouseClickState>>handleEvent:from: > HandMorph>>handleEvent: > HandMorph>>processEventsFromQueue: > HandMorph>>processEvents > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Dec. 16, 2017

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

by Pavel Krivanek

The UI Manager problem was fixed by Pablo and Guille -- Pavel 2017-12-16 13:06 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > tx pavel > > On Sat, Dec 16, 2017 at 9:25 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> The problems were related UIManager initialization and consequences of >> the opening of the Welcome window. >> >> -- Pavel >> >> 2017-12-16 9:12 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> 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

Drag and drop of methods

by Cyril Ferlicot D.

Hi, In the latest Pharo 7 I cannot drag and drop methods anymore in Nautilus. Pharo version: Pharo-7.0+alpha.build.389.sha.e642e96a93951b2765dc808a512b81dc3d52e150 (32 Bit) Stack: TransferMorph(Object)>>doesNotUnderstand: #buildWithSpec FTPluggableIconListMorphAdaptorDataSource>>transferFor:from: FTPluggableIconListMorphAdaptor(FTTableMorph)>>startDrag: MouseClickState>>drag: MouseClickState>>handleEvent:from: HandMorph>>handleEvent: HandMorph>>processEventsFromQueue: HandMorph>>processEvents -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 16, 2017

[Pharo 7.0-dev] Build #389: SUCCESS

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

There is a new Pharo build available! The status of the build #389 was: SUCCESS. Could not extract further issue information from commit message: Tx. Indeed it is better that way Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2017

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

by Esteban Lorenzano

> On 16 Dec 2017, at 17:24, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > OK so I restarted everything from scratch: > - deleted my fork > - reforked > - clone pharo again > - here is some feedback > > In the tutorial add /pharo + src in the screenshot > > > Then when I add the local repository I get uncommited changes and I do > not understand why? this is also a bug (or something I still do not fully understand why it happens). This needs to be corrected with the new UI Esteban > > > > > > On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Esteban, >> >> On 16 December 2017 at 09:05, 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 >> >> >> The contribution process works fine (even on linux :-)). >> >> The "I realise" paragraph is a comment on my suggestion to try and >> reduce the number of manual steps required (and is actually wrong). >> Just to rephrase (and extend) the suggestion, I think we could create >> a single dialog that currently covers the following steps (from your >> instructions): >> >> 1. Clone a fresh repository, or point to an existing repository. >> 2. Tell Iceberg about pharo-project >> 3. Create a new branch from the fogbugz issue >> >> >> ah, I got lost in translation ;) >> >> Esteban >> >> >> Cheers, >> Alistair >> >> >> >> >> 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 >> >> > <Screen Shot 2017-12-16 at 17.23.53.png>

Dec. 16, 2017

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

by Esteban Lorenzano

> On 16 Dec 2017, at 17:32, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I did a little pass on the wiki to make the flow clearer cool! :) > > > On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> In the tutorial: >> >> - Put a little heading before >> >> "You need to add pharo repository as a remote >> (git@github.com:pharo-project/pharo.git)." >> >> On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> I double clicked and it did a massive amount of stuff and finally told >>> me that it is up to date. >>> >>> >>> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>> OK so I restarted everything from scratch: >>>> - deleted my fork >>>> - reforked >>>> - clone pharo again >>>> - here is some feedback >>>> >>>> In the tutorial add /pharo + src in the screenshot >>>> >>>> >>>> Then when I add the local repository I get uncommited changes and I do >>>> not understand why? >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>> >>>>> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>> >>>>> Hi Esteban, >>>>> >>>>> On 16 December 2017 at 09:05, 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 >>>>> >>>>> >>>>> The contribution process works fine (even on linux :-)). >>>>> >>>>> The "I realise" paragraph is a comment on my suggestion to try and >>>>> reduce the number of manual steps required (and is actually wrong). >>>>> Just to rephrase (and extend) the suggestion, I think we could create >>>>> a single dialog that currently covers the following steps (from your >>>>> instructions): >>>>> >>>>> 1. Clone a fresh repository, or point to an existing repository. >>>>> 2. Tell Iceberg about pharo-project >>>>> 3. Create a new branch from the fogbugz issue >>>>> >>>>> >>>>> ah, I got lost in translation ;) >>>>> >>>>> Esteban >>>>> >>>>> >>>>> Cheers, >>>>> Alistair >>>>> >>>>> >>>>> >>>>> >>>>> 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] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

> On 16 Dec 2017, at 17:39, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I committed my code for issue 20861 and I do not understand what I see > > I do not understand why I get local changes with empty packages. :( thatâs a bug: there are no changes to commit (which is correct), but the refresh lets there the original packages. It is in the todo to correct this :) > > Stef > > On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> I did a little pass on the wiki to make the flow clearer >> >> >> On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> In the tutorial: >>> >>> - Put a little heading before >>> >>> "You need to add pharo repository as a remote >>> (git@github.com:pharo-project/pharo.git)." >>> >>> On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>> I double clicked and it did a massive amount of stuff and finally told >>>> me that it is up to date. >>>> >>>> >>>> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse >>>> <stepharo.self(a)gmail.com> wrote: >>>>> OK so I restarted everything from scratch: >>>>> - deleted my fork >>>>> - reforked >>>>> - clone pharo again >>>>> - here is some feedback >>>>> >>>>> In the tutorial add /pharo + src in the screenshot >>>>> >>>>> >>>>> Then when I add the local repository I get uncommited changes and I do >>>>> not understand why? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>> >>>>>> >>>>>> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>>> >>>>>> Hi Esteban, >>>>>> >>>>>> On 16 December 2017 at 09:05, 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 >>>>>> >>>>>> >>>>>> The contribution process works fine (even on linux :-)). >>>>>> >>>>>> The "I realise" paragraph is a comment on my suggestion to try and >>>>>> reduce the number of manual steps required (and is actually wrong). >>>>>> Just to rephrase (and extend) the suggestion, I think we could create >>>>>> a single dialog that currently covers the following steps (from your >>>>>> instructions): >>>>>> >>>>>> 1. Clone a fresh repository, or point to an existing repository. >>>>>> 2. Tell Iceberg about pharo-project >>>>>> 3. Create a new branch from the fogbugz issue >>>>>> >>>>>> >>>>>> ah, I got lost in translation ;) >>>>>> >>>>>> Esteban >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Alistair >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> > <Screen Shot 2017-12-16 at 17.37.50.png>

Dec. 16, 2017

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

by Esteban Lorenzano

> On 16 Dec 2017, at 17:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi Esteban > > Now how can I maintain my fork up to date? there is a âsynchronise repositoriesâ option there, at the side of âcreate branch from fogbugzâ. > This is not in the tutorial and to me it was a major problem and a big > source of pain. it is not there because you do not need it. when you âcreate branch from fogbugzâ, it will take your image version and branch from there. Then, when you push to your remote, you will push correctly. There is no need to have syncd the forks to contributeâ¦ Now, if you do âsynchronise repositoriesâ, it will take what is in pharo-project/pharo/development branch and it will sync that with your pharo/development branch. But againâ¦ there is no need to do this to contribute. Esteban > Stef > > On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> I committed my code for issue 20861 and I do not understand what I see >> >> I do not understand why I get local changes with empty packages. :( >> >> Stef >> >> On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> I did a little pass on the wiki to make the flow clearer >>> >>> >>> On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>> In the tutorial: >>>> >>>> - Put a little heading before >>>> >>>> "You need to add pharo repository as a remote >>>> (git@github.com:pharo-project/pharo.git)." >>>> >>>> On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse >>>> <stepharo.self(a)gmail.com> wrote: >>>>> I double clicked and it did a massive amount of stuff and finally told >>>>> me that it is up to date. >>>>> >>>>> >>>>> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse >>>>> <stepharo.self(a)gmail.com> wrote: >>>>>> OK so I restarted everything from scratch: >>>>>> - deleted my fork >>>>>> - reforked >>>>>> - clone pharo again >>>>>> - here is some feedback >>>>>> >>>>>> In the tutorial add /pharo + src in the screenshot >>>>>> >>>>>> >>>>>> Then when I add the local repository I get uncommited changes and I do >>>>>> not understand why? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi Esteban, >>>>>>> >>>>>>> On 16 December 2017 at 09:05, 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 >>>>>>> >>>>>>> >>>>>>> The contribution process works fine (even on linux :-)). >>>>>>> >>>>>>> The "I realise" paragraph is a comment on my suggestion to try and >>>>>>> reduce the number of manual steps required (and is actually wrong). >>>>>>> Just to rephrase (and extend) the suggestion, I think we could create >>>>>>> a single dialog that currently covers the following steps (from your >>>>>>> instructions): >>>>>>> >>>>>>> 1. Clone a fresh repository, or point to an existing repository. >>>>>>> 2. Tell Iceberg about pharo-project >>>>>>> 3. Create a new branch from the fogbugz issue >>>>>>> >>>>>>> >>>>>>> ah, I got lost in translation ;) >>>>>>> >>>>>>> Esteban >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Alistair >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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

[Pharo 7.0-dev] Build #388: SUCCESS

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

There is a new Pharo build available! The status of the build #388 was: SUCCESS. Could not extract further issue information from commit message: Look nicer. And tx! Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2017

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

by Stephane Ducasse

I clicked on pharo-project remote and I did fetch. thinking stupidly that it will update my local repo. And I get the following .... and I do not understand whay I get 1965 not published. and I do not Then I siwtched branch and went back to development. and I should be able to now push to my remote. So I tried but I'm totally unsure if this is correct. On Sat, Dec 16, 2017 at 5:55 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi Esteban > > Now how can I maintain my fork up to date? > This is not in the tutorial and to me it was a major problem and a big > source of pain. > Stef > > On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> I committed my code for issue 20861 and I do not understand what I see >> >> I do not understand why I get local changes with empty packages. :( >> >> Stef >> >> On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> I did a little pass on the wiki to make the flow clearer >>> >>> >>> On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>> In the tutorial: >>>> >>>> - Put a little heading before >>>> >>>> "You need to add pharo repository as a remote >>>> (git@github.com:pharo-project/pharo.git)." >>>> >>>> On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse >>>> <stepharo.self(a)gmail.com> wrote: >>>>> I double clicked and it did a massive amount of stuff and finally told >>>>> me that it is up to date. >>>>> >>>>> >>>>> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse >>>>> <stepharo.self(a)gmail.com> wrote: >>>>>> OK so I restarted everything from scratch: >>>>>> - deleted my fork >>>>>> - reforked >>>>>> - clone pharo again >>>>>> - here is some feedback >>>>>> >>>>>> In the tutorial add /pharo + src in the screenshot >>>>>> >>>>>> >>>>>> Then when I add the local repository I get uncommited changes and I do >>>>>> not understand why? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi Esteban, >>>>>>> >>>>>>> On 16 December 2017 at 09:05, 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 >>>>>>> >>>>>>> >>>>>>> The contribution process works fine (even on linux :-)). >>>>>>> >>>>>>> The "I realise" paragraph is a comment on my suggestion to try and >>>>>>> reduce the number of manual steps required (and is actually wrong). >>>>>>> Just to rephrase (and extend) the suggestion, I think we could create >>>>>>> a single dialog that currently covers the following steps (from your >>>>>>> instructions): >>>>>>> >>>>>>> 1. Clone a fresh repository, or point to an existing repository. >>>>>>> 2. Tell Iceberg about pharo-project >>>>>>> 3. Create a new branch from the fogbugz issue >>>>>>> >>>>>>> >>>>>>> ah, I got lost in translation ;) >>>>>>> >>>>>>> Esteban >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Alistair >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

Hi Esteban Now how can I maintain my fork up to date? This is not in the tutorial and to me it was a major problem and a big source of pain. Stef On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I committed my code for issue 20861 and I do not understand what I see > > I do not understand why I get local changes with empty packages. :( > > Stef > > On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> I did a little pass on the wiki to make the flow clearer >> >> >> On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> In the tutorial: >>> >>> - Put a little heading before >>> >>> "You need to add pharo repository as a remote >>> (git@github.com:pharo-project/pharo.git)." >>> >>> On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>> I double clicked and it did a massive amount of stuff and finally told >>>> me that it is up to date. >>>> >>>> >>>> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse >>>> <stepharo.self(a)gmail.com> wrote: >>>>> OK so I restarted everything from scratch: >>>>> - deleted my fork >>>>> - reforked >>>>> - clone pharo again >>>>> - here is some feedback >>>>> >>>>> In the tutorial add /pharo + src in the screenshot >>>>> >>>>> >>>>> Then when I add the local repository I get uncommited changes and I do >>>>> not understand why? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>> >>>>>> >>>>>> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>>> >>>>>> Hi Esteban, >>>>>> >>>>>> On 16 December 2017 at 09:05, 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 >>>>>> >>>>>> >>>>>> The contribution process works fine (even on linux :-)). >>>>>> >>>>>> The "I realise" paragraph is a comment on my suggestion to try and >>>>>> reduce the number of manual steps required (and is actually wrong). >>>>>> Just to rephrase (and extend) the suggestion, I think we could create >>>>>> a single dialog that currently covers the following steps (from your >>>>>> instructions): >>>>>> >>>>>> 1. Clone a fresh repository, or point to an existing repository. >>>>>> 2. Tell Iceberg about pharo-project >>>>>> 3. Create a new branch from the fogbugz issue >>>>>> >>>>>> >>>>>> ah, I got lost in translation ;) >>>>>> >>>>>> Esteban >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Alistair >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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] Implementors of margins in GLMRubScrolledTextBrick

by Stephane Ducasse

Ok so since I paid attention and rewrote all the margins: invocations I think that my changes will not break On Fri, Dec 15, 2017 at 9:32 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > 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. 16, 2017

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

by Stephane Ducasse

I committed my code for issue 20861 and I do not understand what I see I do not understand why I get local changes with empty packages. :( Stef On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I did a little pass on the wiki to make the flow clearer > > > On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> In the tutorial: >> >> - Put a little heading before >> >> "You need to add pharo repository as a remote >> (git@github.com:pharo-project/pharo.git)." >> >> On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> I double clicked and it did a massive amount of stuff and finally told >>> me that it is up to date. >>> >>> >>> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>> OK so I restarted everything from scratch: >>>> - deleted my fork >>>> - reforked >>>> - clone pharo again >>>> - here is some feedback >>>> >>>> In the tutorial add /pharo + src in the screenshot >>>> >>>> >>>> Then when I add the local repository I get uncommited changes and I do >>>> not understand why? >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>> >>>>> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>> >>>>> Hi Esteban, >>>>> >>>>> On 16 December 2017 at 09:05, 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 >>>>> >>>>> >>>>> The contribution process works fine (even on linux :-)). >>>>> >>>>> The "I realise" paragraph is a comment on my suggestion to try and >>>>> reduce the number of manual steps required (and is actually wrong). >>>>> Just to rephrase (and extend) the suggestion, I think we could create >>>>> a single dialog that currently covers the following steps (from your >>>>> instructions): >>>>> >>>>> 1. Clone a fresh repository, or point to an existing repository. >>>>> 2. Tell Iceberg about pharo-project >>>>> 3. Create a new branch from the fogbugz issue >>>>> >>>>> >>>>> ah, I got lost in translation ;) >>>>> >>>>> Esteban >>>>> >>>>> >>>>> Cheers, >>>>> Alistair >>>>> >>>>> >>>>> >>>>> >>>>> 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] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

I did a little pass on the wiki to make the flow clearer On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > In the tutorial: > > - Put a little heading before > > "You need to add pharo repository as a remote > (git@github.com:pharo-project/pharo.git)." > > On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> I double clicked and it did a massive amount of stuff and finally told >> me that it is up to date. >> >> >> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> OK so I restarted everything from scratch: >>> - deleted my fork >>> - reforked >>> - clone pharo again >>> - here is some feedback >>> >>> In the tutorial add /pharo + src in the screenshot >>> >>> >>> Then when I add the local repository I get uncommited changes and I do >>> not understand why? >>> >>> >>> >>> >>> >>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> >>>> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>> >>>> Hi Esteban, >>>> >>>> On 16 December 2017 at 09:05, 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 >>>> >>>> >>>> The contribution process works fine (even on linux :-)). >>>> >>>> The "I realise" paragraph is a comment on my suggestion to try and >>>> reduce the number of manual steps required (and is actually wrong). >>>> Just to rephrase (and extend) the suggestion, I think we could create >>>> a single dialog that currently covers the following steps (from your >>>> instructions): >>>> >>>> 1. Clone a fresh repository, or point to an existing repository. >>>> 2. Tell Iceberg about pharo-project >>>> 3. Create a new branch from the fogbugz issue >>>> >>>> >>>> ah, I got lost in translation ;) >>>> >>>> Esteban >>>> >>>> >>>> Cheers, >>>> Alistair >>>> >>>> >>>> >>>> >>>> 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] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

In the tutorial: - Put a little heading before "You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)." On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I double clicked and it did a massive amount of stuff and finally told > me that it is up to date. > > > On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> OK so I restarted everything from scratch: >> - deleted my fork >> - reforked >> - clone pharo again >> - here is some feedback >> >> In the tutorial add /pharo + src in the screenshot >> >> >> Then when I add the local repository I get uncommited changes and I do >> not understand why? >> >> >> >> >> >> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> Hi Esteban, >>> >>> On 16 December 2017 at 09:05, 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 >>> >>> >>> The contribution process works fine (even on linux :-)). >>> >>> The "I realise" paragraph is a comment on my suggestion to try and >>> reduce the number of manual steps required (and is actually wrong). >>> Just to rephrase (and extend) the suggestion, I think we could create >>> a single dialog that currently covers the following steps (from your >>> instructions): >>> >>> 1. Clone a fresh repository, or point to an existing repository. >>> 2. Tell Iceberg about pharo-project >>> 3. Create a new branch from the fogbugz issue >>> >>> >>> ah, I got lost in translation ;) >>> >>> Esteban >>> >>> >>> Cheers, >>> Alistair >>> >>> >>> >>> >>> 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] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

I double clicked and it did a massive amount of stuff and finally told me that it is up to date. On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > OK so I restarted everything from scratch: > - deleted my fork > - reforked > - clone pharo again > - here is some feedback > > In the tutorial add /pharo + src in the screenshot > > > Then when I add the local repository I get uncommited changes and I do > not understand why? > > > > > > On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Esteban, >> >> On 16 December 2017 at 09:05, 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 >> >> >> The contribution process works fine (even on linux :-)). >> >> The "I realise" paragraph is a comment on my suggestion to try and >> reduce the number of manual steps required (and is actually wrong). >> Just to rephrase (and extend) the suggestion, I think we could create >> a single dialog that currently covers the following steps (from your >> instructions): >> >> 1. Clone a fresh repository, or point to an existing repository. >> 2. Tell Iceberg about pharo-project >> 3. Create a new branch from the fogbugz issue >> >> >> ah, I got lost in translation ;) >> >> Esteban >> >> >> Cheers, >> Alistair >> >> >> >> >> 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] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback In the tutorial add /pharo + src in the screenshot Then when I add the local repository I get uncommited changes and I do not understand why? On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Esteban, > > On 16 December 2017 at 09:05, 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 > > > The contribution process works fine (even on linux :-)). > > The "I realise" paragraph is a comment on my suggestion to try and > reduce the number of manual steps required (and is actually wrong). > Just to rephrase (and extend) the suggestion, I think we could create > a single dialog that currently covers the following steps (from your > instructions): > > 1. Clone a fresh repository, or point to an existing repository. > 2. Tell Iceberg about pharo-project > 3. Create a new branch from the fogbugz issue > > > ah, I got lost in translation ;) > > Esteban > > > Cheers, > Alistair > > > > > 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] [Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference

by Alistair Grant

Hi Stef, On 16 December 2017 at 16:58, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > So I would like to understand (sincerly) what was the problem and what > is the gain? > I learned that we can ask a collection a readStream and writeStream already. > And now we can do anyCollection readStreamDo: and writeStreamDo: > Why not? Cyril proposed this, so may chime in with more information, but... Take a look at http://forum.world.st/Polymorphism-between-Strings-and-FileReference-tt5059… The advantages are: - provides polymorphism with FileReference - you don't need to know whether the stream needs to be closed or not as read/writeStreamDo: takes care of it for you. > On Sat, Dec 16, 2017 at 4:42 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Hi >> >> Do we really want this? >> I do not understand why a string is a fileReference? >> String has far too many methods and we are even adding more and I do >> not understand why. Can you clarify what you're asking (about "why a string is a fileReference")? To be clear, SequencableCollection>>read/writeStreamDo: open a stream on the receiver (typically a string) and then pass it to the supplied block. Nothing to do with a fileReference (apart from the polymorphism). Cheers, Alistair

Dec. 16, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference

by Stephane Ducasse

So I would like to understand (sincerly) what was the problem and what is the gain? I learned that we can ask a collection a readStream and writeStream already. And now we can do anyCollection readStreamDo: and writeStreamDo: Why not? On Sat, Dec 16, 2017 at 4:42 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > Do we really want this? > I do not understand why a string is a fileReference? > String has far too many methods and we are even adding more and I do > not understand why. > > Stef > > > On Thu, Dec 14, 2017 at 12:01 PM, <ci-pharo-ci-jenkins2(a)inria.fr> wrote: >> There is a new Pharo build available! >> >> The status of the build #381 was: SUCCESS. >> >> The Pull Request #605 was integrated: "20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference" >> Pull request url: https://github.com/pharo-project/pharo/pull/605 >> >> Issue Url: https://pharo.fogbugz.com/f/cases/20796 >> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference

by Stephane Ducasse

Hi Do we really want this? I do not understand why a string is a fileReference? String has far too many methods and we are even adding more and I do not understand why. Stef On Thu, Dec 14, 2017 at 12:01 PM, <ci-pharo-ci-jenkins2(a)inria.fr> wrote: > There is a new Pharo build available! > > The status of the build #381 was: SUCCESS. > > The Pull Request #605 was integrated: "20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference" > Pull request url: https://github.com/pharo-project/pharo/pull/605 > > Issue Url: https://pharo.fogbugz.com/f/cases/20796 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2017

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

by Martin Dias

El 16 dic. 2017 5:04 AM, "Stephane Ducasse" <stepharo.self(a)gmail.com> escribiÃ³: I love epicea :) Did you see that now people use my extension to generate docs :) no i didnt! how could i see that? 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

[Pharo 7.0-dev] Build #387: 20870-Spec-FastTable-badly-support-drag-and-drop

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

There is a new Pharo build available! The status of the build #387 was: FAILURE. The Pull Request #608 was integrated: "20870-Spec-FastTable-badly-support-drag-and-drop" Pull request url: https://github.com/pharo-project/pharo/pull/608 Issue Url: https://pharo.fogbugz.com/f/cases/20870 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2017

[Pharo 7.0-dev] Build #386: 20872-WidgetExamples-classexampleDialogs-is-broken-in-Pharo-7

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

There is a new Pharo build available! The status of the build #386 was: SUCCESS. The Pull Request #610 was integrated: "20872-WidgetExamples-classexampleDialogs-is-broken-in-Pharo-7" Pull request url: https://github.com/pharo-project/pharo/pull/610 Issue Url: https://pharo.fogbugz.com/f/cases/20872 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2017

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

by Stephane Ducasse

tx pavel On Sat, Dec 16, 2017 at 9:25 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > The problems were related UIManager initialization and consequences of > the opening of the Welcome window. > > -- Pavel > > 2017-12-16 9:12 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> 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] Do we have this iterator?

by Stephane Ducasse

So true :) Stef On Sat, Dec 16, 2017 at 12:12 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 16 December 2017 at 17:28, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> Never try to read regexp, it's write only > > > its highly susceptible to Kernighan's Lever to shoot yourself in the foot... > "You separate the bullet from the gun with a hyperoptimized regexp, > and then you transport it to your foot using several typeglobs. > However, the program fails to run and you can't correct it since > you don't understand what the hell it is you've written." > http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html > > cheers -ben > > >> >> >> 2017-12-16 9:09 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>> 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] Do we have this iterator?

by Ben Coman

On 16 December 2017 at 17:28, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Never try to read regexp, it's write only > its highly susceptible to Kernighan's Lever to shoot yourself in the foot... "You separate the bullet from the gun with a hyperoptimized regexp, and then you transport it to your foot using several typeglobs. However, the program fails to run and you can't correct it since you don't understand what the hell it is you've written." http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html cheers -ben > > 2017-12-16 9:09 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> 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] Do we have this iterator?

by Nicolas Cellier

Never try to read regexp, it's write only 2017-12-16 9:09 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > 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 Esteban Lorenzano

> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Esteban, > > On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@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 > > The contribution process works fine (even on linux :-)). > > The "I realise" paragraph is a comment on my suggestion to try and > reduce the number of manual steps required (and is actually wrong). > Just to rephrase (and extend) the suggestion, I think we could create > a single dialog that currently covers the following steps (from your > instructions): > > 1. Clone a fresh repository, or point to an existing repository. > 2. Tell Iceberg about pharo-project > 3. Create a new branch from the fogbugz issue ah, I got lost in translation ;) Esteban > > Cheers, > Alistair > > > >>> >>> 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] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Alistair Grant

Hi Esteban, On 16 December 2017 at 09:05, 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 The contribution process works fine (even on linux :-)). The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions): 1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue Cheers, Alistair >> >> 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 Pavel Krivanek

The problems were related UIManager initialization and consequences of the opening of the Welcome window. -- Pavel 2017-12-16 9:12 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > 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] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

Yes now I have some pending commits that I do not want to lose so I will fileout them and publish them. Stef On Sat, Dec 16, 2017 at 9:19 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 16 Dec 2017, at 09:15, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > download latest image and follow the steps explained here: > > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > > side note: please do not try to adapt this steps to what you already know. > is better if you try this steps âblindlyâ and later you do a synthesis > between what you learned and what you know :) > > Esteban > > > 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] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

> On 16 Dec 2017, at 09:15, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > 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> side note: please do not try to adapt this steps to what you already know. is better if you try this steps âblindlyâ and later you do a synthesis between what you learned and what you know :) Esteban > > Esteban > >> On 16 Dec 2017, at 09:07, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@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 <mailto:estebanlm@gmail.com>> wrote: >>> >>> >>>> On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710(a)gmail.com <mailto:akgrant0710@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 <mailto:estebanlm@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 <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] [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

Dictionary newFromKeys: andValues:

by Stephane Ducasse

Hi I was looking at the Dictionary instance creation API and I would like to add newFromKeys:andValues: Because I do not see why I have to create associations when I have already the two collections. What do you think? Stef

Dec. 15, 2017

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

by Stephane Ducasse

On Thu, Dec 14, 2017 at 2:34 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Works for me :-) > > This update will simplify things a lot because as soon as you create a > branch from FogBugz issue, the Iceberg does following [1]: > - fetches the pharo-project repository > - checkouts to the particular commit from which the image was bootstrapped > - creates a new branch > > That means that: > - you do not need to keep your fork up-to-date manually > - things should be cleaner Ahhhhhh it looks like a huge improvement. Because keeping manually our fork was a pain. I will use my super nasty powers and try because I have some pending fixes :) > So as soon as your local repository is created as clone of your fork > repository (your fork is origin), you do not need to set push and pull > target nor synchronize your fork with pharo-project repository. > > Esteban will fix me if I'm wrong ;-) > > [1] see IcePharoCreateBranchFromIssue>>#createBranchNamed: > > -- Pavel > > > 2017-12-14 13:19 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> 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. 15, 2017

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

by Stephane Ducasse

Cumbersome was not the first adjective that came to me mind :) but you know it :) On Thu, Dec 14, 2017 at 1:19 PM, 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. 15, 2017

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

by Alistair Grant

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. 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. 15, 2017

Re: [Pharo-dev] 60528-64 OpalCompiler recompileAll ==> GLM trait conflict

by Ben Coman

On 15 December 2017 at 19:28, Ben Coman <btc(a)openinworld.com> wrote: > > > On 13 December 2017 at 19:41, Ben Coman <btc(a)openinworld.com> wrote: > >> In a fresh 60528-64 image download with PharoLauncher on Ubuntu 16.04... >> 1. Open Playground >> 2. Evaluate... OpalCompler recompileAll >> 3. Try opening Iceberg, Playground or Spotter. >> ==> Error: A class or trait does not properly resolve a conflict between >> multiple traits it uses. >> >> System Browser, Test Runner and Monticello are okay. >> >> 60528 (32bit) is okay (what is different between 32bit and 64bit?) >> >> 60521-64 is broken >> 60520-64 is okay >> >> https://pharo.manuscript.com/f/cases/20867/OpalCompiler-reco >> mpileAll-GLM-trait-conflict >> >> cheers -ben >> >> > I've got to the limit of where I can go with this one, so I'm seeking > help. Copied from issue... > > Having isolated the build where the issue was introduced, > normally I'd search the mail list for "60521" to find reports like > these... > 60519 http://forum.world.st/update-6-0-60519-td5007498.html > 60522 http://forum.world.st/update-6-0-60522-td5056051.html > > and try applying the modifications to 60521 > manually to 60520 to see if I can break it. > But 60520 and 60521 reports are missing. > > Comparing file dates (http://files.pharo.org/image/60/) > 2017.11.07 60520 > 2017.11.29 60521 > 2017.11.29 60522 > > to Fogbuz... https://pharo.fogbugz.com/f/filters/?closedInLast=4& > fClosedBugs=true&ixFixFor=22&sColumns=Category-Favorite- > Case-TitleComment-Status-Priority-DateClosed-Milestone& > sSorts=DateClosed.descending-LastUpdated.descending&sView=grid-flat > > Issue Closed Note > 18760 2017.11.29 merged in 60522 > 20339 2017.11.29 resolved Fix To Include - Monkey was failing - removed > the testRenameClassUsingClass > 20250 2017.11.28 closed Fixed Upstream > 20260 2017.11.28 reopened, originally merged 2017.08.22 > 20586 2017.11.23 closed Wont Fix > 20709 2017.11.18 merged in ???? (and there is no such Slice in > Pharo6Inbox) > 20119 2017.11.07 merged in 60520 (pull/492 ??) > > applying Slice-20339 on top of 60520 doesn't break "OpalCompiler > recompileAll". > So I'm at a loss how to continue. > Maybe it was just a momentary glitch :( > and builds > 60520 need to be thrown out and their integrations re-run > with either same or newer build numbers. > > So we don't create additional rework, there should be no further > integrations to Pharo6, > so I've tentatively moved priority to "Show. Stopper" (not that that will > necessarily have any great effect with development moved to Pharo 7). > > ============================================ > > Putting a halt in CompiledMethod class >> conflictMarker > prior to running "OpalCompiler recompileAll" > stops in... > GLMBrick(Behaviour)>>#updateMethodDictionarySelector: #innerBounds > > where it calls... > methodDescription effectiveMethod > > which is... > TraitDescription>>#effectiveMethod > "Return the effective compiled method of this method description." > | method | > method := self providedMethod. > method isNil ifFalse: [^ method]. > method := self conflictMethod. "<<<<<<<<<" > method isNil ifFalse: [^ method]. > ^ self requiredMethod. > > with ivar... > .locatedMethods={GLMBrickGeometryTrait>>#innerBounds . > GLMBrickLayoutTrait>>#innerBounds} > > and evaluting "self providedMethod"... > TraitMethodDescription>>#providedLocatedMethod > | locatedMethod aLocatedMethod refOrigin | > locatedMethod := nil. > self locatedMethods ifEmpty: [ ^ nil]. > self locatedMethods size > 1 > ifTrue: [ > aLocatedMethod := self locatedMethods anyOne. > refOrigin := (aLocatedMethod methodClass >> aLocatedMethod > selector) origin. > (self locatedMethods allSatisfy: [:each | each origin == > refOrigin]) > ifTrue: [^ aLocatedMethod]. > ]. > self locatedMethods do: [:each | > each isProvided ifTrue: [ > locatedMethod isNil ifFalse: [^nil]. > locatedMethod := each] > ]. > ^locatedMethod > > shows... > * all locatedMethods don't have the same origin > i.e. self locatedMethods collect: [:e|e origin] > ==> {GLMBrickGeometryTrait, GLMBrickLayoutTrait} > > * all locatedMethods are provided > i.e. self asOrderedCollection collect: [:e|e isProvided] > ==> {true.true} > > Now System Browser shows these definitions... > 1. (T)GLMBrickGeometeryTrait>>#innerBounds > ^ self wrappedBounds innerBounds > > 2. (T)GLMBrickLayoutTrait>>#innerBounds > ^ self explicitRequirement > > 3. GLMBrickedMorph subclass: #GLMBrick > uses: GLMBrickPropertiesTrait > + GLMBrickLayoutTrait > + GLMBrickStructureTrait > + (GLMBrickGeometryTrait - {#privateBounds:}) > instanceVariableNames: 'brickBounds brickApi' > classVariableNames: '' > package: 'Glamour-Morphic-Brick-Widgets-Core' > > which from my limited understanding of Traits seems to have been > correctly flagged as a conflict. > But image 60520-64 similarly has... > > 1. (T)GLMBrickGeometeryTrait>>#innerBounds > ^ self wrappedBounds innerBounds > > 2. (T)GLMBrickLayoutTrait>>#innerBounds > ^ self explicitRequirement > > 3. GLMBrickedMorph subclass: #GLMBrick > uses: GLMBrickPropertiesTrait > + GLMBrickLayoutTrait > + GLMBrickStructureTrait > + (GLMBrickGeometryTrait - {#privateBounds:}) > instanceVariableNames: 'brickBounds brickApi' > classVariableNames: '' > package: 'Glamour-Morphic-Brick-Widgets-Core' > > so is the question really why 60520 doesn't flag a conflict? > > > Also my meta question... why did I need to debug deep into the compiler > to tune in on definitions [1.], [2.] & [3.] ? i.e why have... > > TraitMethodDescription>>#conflictMethod > | binary numberOfArguments | > self isConflict ifFalse: [^nil]. > binary := self isBinarySelector. > numberOfArguments := self numberOfArguments. > ^self > generateMethod: self selector > withMarker: CompiledMethod conflictMarker > forArgs: numberOfArguments > binary: binary > > and not... > > TraitMethodDescription>>#conflictMethod > self isConflict ifFalse: [^nil]. > self raise: CompileTimeTraitErrorReportWithGUI > > =================== > > P.S. Maybe not related, at various times stepping through "self > providedMethod" > for ivar "locatedMethod" the pane inspector showed "error obtaining field > value" > (in the 60521 image) > > > Here's hoping some guru can pick it up from there. > cheers -ben > So I noticed System Browser show GLMBrick is using the #innerBounds method from GLMBrickGeometryTrait. So guessing part of solving this is probably to redefine (in a fresh image)... GLMBrickedMorph subclass: #GLMBrick uses: GLMBrickPropertiesTrait + (GLMBrickLayoutTrait - {#innerBounds}) + GLMBrickStructureTrait + (GLMBrickGeometryTrait - {#privateBounds:}) instanceVariableNames: 'brickBounds brickApi' classVariableNames: '' package: 'Glamour-Morphic-Brick-Widgets-Core' but saving this produces error "Instance of GLMPrivacyAgreementBrick did not understand #onRemovedFrom:" and the Quality Assistant Nautilius Plugin dies. Trying to bypass this in another fresh image, opening System Browser then clicking on Settings in the QA area error when the Settings display. cheers -ben

Dec. 15, 2017

Re: [Pharo-dev] 60528-64 OpalCompiler recompileAll ==> GLM trait conflict

by Ben Coman

On 13 December 2017 at 19:41, Ben Coman <btc(a)openinworld.com> wrote: > In a fresh 60528-64 image download with PharoLauncher on Ubuntu 16.04... > 1. Open Playground > 2. Evaluate... OpalCompler recompileAll > 3. Try opening Iceberg, Playground or Spotter. > ==> Error: A class or trait does not properly resolve a conflict between > multiple traits it uses. > > System Browser, Test Runner and Monticello are okay. > > 60528 (32bit) is okay (what is different between 32bit and 64bit?) > > 60521-64 is broken > 60520-64 is okay > > https://pharo.manuscript.com/f/cases/20867/OpalCompiler- > recompileAll-GLM-trait-conflict > > cheers -ben > > I've got to the limit of where I can go with this one, so I'm seeking help. Copied from issue... Having isolated the build where the issue was introduced, normally I'd search the mail list for "60521" to find reports like these... 60519 http://forum.world.st/update-6-0-60519-td5007498.html 60522 http://forum.world.st/update-6-0-60522-td5056051.html and try applying the modifications to 60521 manually to 60520 to see if I can break it. But 60520 and 60521 reports are missing. Comparing file dates (http://files.pharo.org/image/60/) 2017.11.07 60520 2017.11.29 60521 2017.11.29 60522 to Fogbuz... https://pharo.fogbugz.com/f/filters/?closedInLast=4&fClosedBugs=true&ixFixF… Issue Closed Note 18760 2017.11.29 merged in 60522 20339 2017.11.29 resolved Fix To Include - Monkey was failing - removed the testRenameClassUsingClass 20250 2017.11.28 closed Fixed Upstream 20260 2017.11.28 reopened, originally merged 2017.08.22 20586 2017.11.23 closed Wont Fix 20709 2017.11.18 merged in ???? (and there is no such Slice in Pharo6Inbox) 20119 2017.11.07 merged in 60520 (pull/492 ??) applying Slice-20339 on top of 60520 doesn't break "OpalCompiler recompileAll". So I'm at a loss how to continue. Maybe it was just a momentary glitch :( and builds > 60520 need to be thrown out and their integrations re-run with either same or newer build numbers. So we don't create additional rework, there should be no further integrations to Pharo6, so I've tentatively moved priority to "Show. Stopper" (not that that will necessarily have any great effect with development moved to Pharo 7). ============================================ Putting a halt in CompiledMethod class >> conflictMarker prior to running "OpalCompiler recompileAll" stops in... GLMBrick(Behaviour)>>#updateMethodDictionarySelector: #innerBounds where it calls... methodDescription effectiveMethod which is... TraitDescription>>#effectiveMethod "Return the effective compiled method of this method description." | method | method := self providedMethod. method isNil ifFalse: [^ method]. method := self conflictMethod. "<<<<<<<<<" method isNil ifFalse: [^ method]. ^ self requiredMethod. with ivar... .locatedMethods={GLMBrickGeometryTrait>>#innerBounds . GLMBrickLayoutTrait>>#innerBounds} and evaluting "self providedMethod"... TraitMethodDescription>>#providedLocatedMethod | locatedMethod aLocatedMethod refOrigin | locatedMethod := nil. self locatedMethods ifEmpty: [ ^ nil]. self locatedMethods size > 1 ifTrue: [ aLocatedMethod := self locatedMethods anyOne. refOrigin := (aLocatedMethod methodClass >> aLocatedMethod selector) origin. (self locatedMethods allSatisfy: [:each | each origin == refOrigin]) ifTrue: [^ aLocatedMethod]. ]. self locatedMethods do: [:each | each isProvided ifTrue: [ locatedMethod isNil ifFalse: [^nil]. locatedMethod := each] ]. ^locatedMethod shows... * all locatedMethods don't have the same origin i.e. self locatedMethods collect: [:e|e origin] ==> {GLMBrickGeometryTrait, GLMBrickLayoutTrait} * all locatedMethods are provided i.e. self asOrderedCollection collect: [:e|e isProvided] ==> {true.true} Now System Browser shows these definitions... 1. (T)GLMBrickGeometeryTrait>>#innerBounds ^ self wrappedBounds innerBounds 2. (T)GLMBrickLayoutTrait>>#innerBounds ^ self explicitRequirement 3. GLMBrickedMorph subclass: #GLMBrick uses: GLMBrickPropertiesTrait + GLMBrickLayoutTrait + GLMBrickStructureTrait + (GLMBrickGeometryTrait - {#privateBounds:}) instanceVariableNames: 'brickBounds brickApi' classVariableNames: '' package: 'Glamour-Morphic-Brick-Widgets-Core' which from my limited understanding of Traits seems to have been correctly flagged as a conflict. But image 60520-64 similarly has... 1. (T)GLMBrickGeometeryTrait>>#innerBounds ^ self wrappedBounds innerBounds 2. (T)GLMBrickLayoutTrait>>#innerBounds ^ self explicitRequirement 3. GLMBrickedMorph subclass: #GLMBrick uses: GLMBrickPropertiesTrait + GLMBrickLayoutTrait + GLMBrickStructureTrait + (GLMBrickGeometryTrait - {#privateBounds:}) instanceVariableNames: 'brickBounds brickApi' classVariableNames: '' package: 'Glamour-Morphic-Brick-Widgets-Core' so is the question really why 60520 doesn't flag a conflict? Also my meta question... why did I need to debug deep into the compiler to tune in on definitions [1.], [2.] & [3.] ? i.e why have... TraitMethodDescription>>#conflictMethod | binary numberOfArguments | self isConflict ifFalse: [^nil]. binary := self isBinarySelector. numberOfArguments := self numberOfArguments. ^self generateMethod: self selector withMarker: CompiledMethod conflictMarker forArgs: numberOfArguments binary: binary and not... TraitMethodDescription>>#conflictMethod self isConflict ifFalse: [^nil]. self raise: CompileTimeTraitErrorReportWithGUI =================== P.S. Maybe not related, at various times stepping through "self providedMethod" for ivar "locatedMethod" the pane inspector showed "error obtaining field value" (in the 60521 image) Here's hoping some guru can pick it up from there. cheers -ben

Dec. 15, 2017

[Pharo 7.0-dev] Build #385: 20859-Update-Hermes-to-detect-new-Undeclared-and-overwritten-methods-and-classes

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

There is a new Pharo build available! The status of the build #385 was: SUCCESS. The Pull Request #597 was integrated: "20859-Update-Hermes-to-detect-new-Undeclared-and-overwritten-methods-and-classes" Pull request url: https://github.com/pharo-project/pharo/pull/597 Issue Url: https://pharo.fogbugz.com/f/cases/20859 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 15, 2017

Re: [Pharo-dev] [Ann] New Calypso version 0.8

by Juraj Kubelka

Hi Denis, I use it without critiques and it works fine. I have some observations: - test cases in an abstract class can be executed, it might be disabled as it does not make sense to execute them - test cases defined in a superclass cannot be executed separately (only as all test cases by clicking on the class icon) - it might be a good option to be able to execute failing test cases (there is a dedicated method group that appears in such situations) - and maybe also when browsing âinherited methodsâ Thanks for the great job! Juraj > On Dec 14, 2017, at 14:45, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > I found some performance problem with this version. > I know the reason. It will be fixed soon. > Now you can try disable critiques plugin with github instructions. > > 2017-12-12 13:52 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > > > 2017-12-12 13:25 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>>: > Hi Denis, > > Congratulations on the new release! Two quick question: > > 1) does this work on latest Pharo 6.1 ; > > Yes > > 2) Is it safe to update images with Calypso already installed by doing the same baseline loading as the original installation ? > > I think not. But I not try. I just have impression that complex updates are not properly work in Pharo. All package structure is changed and it can be a problem for such update. > > > Thanks > > On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > Hello. > > I glad announce new Calypso version. It is a big refactoring on navigation model and browser pluggability. > > Look for details in my blog http://dionisiydk.blogspot.fr/2017/12/new-calypso-version-08-is-out.html <http://dionisiydk.blogspot.fr/2017/12/new-calypso-version-08-is-out.html>. > > Now I start document new design and will post progress on it. > > Notice: this version is not adopted for TelePharo and Cargo. It will be done soon. > > Best regards, > Denis > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > >

Dec. 14, 2017

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

by Aliaksei Syrel

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/GLMRubScrolledTextBr > ick-relies-on-dnu-delegation > > Best regards, > Henrik > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Dec. 14, 2017

Re: [Pharo-dev] [Ann] New Calypso version 0.8

by Denis Kudriashov

I found some performance problem with this version. I know the reason. It will be fixed soon. Now you can try disable critiques plugin with github instructions. 2017-12-12 13:52 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > > 2017-12-12 13:25 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Hi Denis, >> >> Congratulations on the new release! Two quick question: >> > > >> 1) does this work on latest Pharo 6.1 ; >> > > Yes > > >> 2) Is it safe to update images with Calypso already installed by doing >> the same baseline loading as the original installation ? >> > > I think not. But I not try. I just have impression that complex updates > are not properly work in Pharo. All package structure is changed and it can > be a problem for such update. > > >> >> Thanks >> >> On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> Hello. >>> >>> I glad announce new Calypso version. It is a big refactoring on >>> navigation model and browser pluggability. >>> >>> Look for details in my blog http://dionisiydk.blogspot.fr/ >>> 2017/12/new-calypso-version-08-is-out.html. >>> >>> Now I start document new design and will post progress on it. >>> >>> Notice: this version is not adopted for TelePharo and Cargo. It will be >>> done soon. >>> >>> Best regards, >>> Denis >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Dec. 14, 2017

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

by Henrik Sperre Johansen

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. 14, 2017

[Pharo 7.0-dev] Build #384: 20836-Cleaning-comments

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

There is a new Pharo build available! The status of the build #384 was: SUCCESS. The Pull Request #595 was integrated: "20836-Cleaning-comments" Pull request url: https://github.com/pharo-project/pharo/pull/595 Issue Url: https://pharo.fogbugz.com/f/cases/20836 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2017

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

by Pavel Krivanek

Works for me :-) This update will simplify things a lot because as soon as you create a branch from FogBugz issue, the Iceberg does following [1]: - fetches the pharo-project repository - checkouts to the particular commit from which the image was bootstrapped - creates a new branch That means that: - you do not need to keep your fork up-to-date manually - things should be cleaner So as soon as your local repository is created as clone of your fork repository (your fork is origin), you do not need to set push and pull target nor synchronize your fork with pharo-project repository. Esteban will fix me if I'm wrong ;-) [1] see IcePharoCreateBranchFromIssue>>#createBranchNamed: -- Pavel 2017-12-14 13:19 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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. 14, 2017

[Pharo 7.0-dev] Build #383: 20832-boostrap-process-should-use-IceProxyMCVersionInfo-instead-system-repositories

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

There is a new Pharo build available! The status of the build #383 was: SUCCESS. The Pull Request #584 was integrated: "20832-boostrap-process-should-use-IceProxyMCVersionInfo-instead-system-repositories" Pull request url: https://github.com/pharo-project/pharo/pull/584 Issue Url: https://pharo.fogbugz.com/f/cases/20832 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2017

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

by Marcus Denker

> On 14 Dec 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 <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> > I updated http://pharo.org/contribute-propose-fix <http://pharo.org/contribute-propose-fix> to point to this link. Marcus

Dec. 14, 2017

[Pharo 7.0-dev] Build #382: 20680-Add-comments-to-FileSystem-packages

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

There is a new Pharo build available! The status of the build #382 was: SUCCESS. The Pull Request #603 was integrated: "20680-Add-comments-to-FileSystem-packages" Pull request url: https://github.com/pharo-project/pharo/pull/603 Issue Url: https://pharo.fogbugz.com/f/cases/20680 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2017

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

by Esteban Lorenzano

ah yesâ¦ this will be starting next build. Esteban > On 14 Dec 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 <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. 14, 2017

[IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

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 <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. 14, 2017

[Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference

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

There is a new Pharo build available! The status of the build #381 was: SUCCESS. The Pull Request #605 was integrated: "20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference" Pull request url: https://github.com/pharo-project/pharo/pull/605 Issue Url: https://pharo.fogbugz.com/f/cases/20796 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2017

[Pharo 7.0-dev] Build #380: 20684-Categorizer-should-categorize-reset-methods-in-initialization-protocol

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

There is a new Pharo build available! The status of the build #380 was: SUCCESS. The Pull Request #604 was integrated: "20684-Categorizer-should-categorize-reset-methods-in-initialization-protocol" Pull request url: https://github.com/pharo-project/pharo/pull/604 Issue Url: https://pharo.fogbugz.com/f/cases/20684 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2017

Re: [Pharo-dev] [Website] Updated Linux download instructions

by Marcus Denker

> On 13 Dec 2017, at 16:43, stephan <stephan(a)stack.nl> wrote: > > On 13-12-17 16:32, Sean P. DeNigris wrote: >> Marcus Denker-4 wrote >>> I have updated the download instructionâ¦ >> Thanks!! This seems to have been a common pain point, for new users >> especially. > > And then a newer 32 bit Linux VM needs to be build and promoted to stable as next point? > Are any of these packages automatically build after we e.g. release a new Pharo6.1 image? Marcus

Dec. 14, 2017

Re: [Pharo-dev] [Website] Updated Linux download instructions

by Marcus Denker

> On 13 Dec 2017, at 16:32, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Marcus Denker-4 wrote >> I have updated the download instructionâ¦ > > Thanks!! This seems to have been a common pain point, for new users > especially. > > Yes. What is missing is an action item for what to do to start Pharo after installing it. It does not get clear in the description where it is installed with the package manager. Marcus

Dec. 14, 2017

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

by Nicolas Cellier

2017-12-13 11:09 GMT+01:00 stephan <stephan(a)stack.nl>: > 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 thread would be"MC should really write snaphsot/source.st in UTF8" end of may 2013. I've made the switch in Squeak short after (june 2013). I've propsed a fix for Pharo (issues 10801 and 10811) that has been integrated in 3.0 end of june 2013. So the .mcz created before this might be problematic... As I've just reported here, I think there are problems in tonel (like if it was reading and writing with different encoding...)

Dec. 13, 2017

[Pharo 7.0-dev] Build #379: 20865-update-iceberg-to-065

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

There is a new Pharo build available! The status of the build #379 was: SUCCESS. The Pull Request #599 was integrated: "20865-update-iceberg-to-065" Pull request url: https://github.com/pharo-project/pharo/pull/599 Issue Url: https://pharo.fogbugz.com/f/cases/20865 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 13, 2017

Re: [Pharo-dev] [Website] Updated Linux download instructions

by stephan

On 13-12-17 16:32, Sean P. DeNigris wrote: > Marcus Denker-4 wrote >> I have updated the download instructionâ¦ > > Thanks!! This seems to have been a common pain point, for new users > especially. And then a newer 32 bit Linux VM needs to be build and promoted to stable as next point? Stephan

Dec. 13, 2017

Re: [Pharo-dev] [Website] Updated Linux download instructions

by Sean P. DeNigris

Marcus Denker-4 wrote > I have updated the download instructionâ¦ Thanks!! This seems to have been a common pain point, for new users especially. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 13, 2017

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

by Martin Dias

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. 13, 2017

Re: [Pharo-dev] I love the launcher!!!!

by Stephane Ducasse

:) For me it helps me controlling my mess euh natural entropy On Tue, Dec 12, 2017 at 8:13 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Your email made me try Pharo Launcher. I love it too! > > It replaces all my scripts to download the VM and the last images. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Nov 23, 2017, at 5:51 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi >> >> I love the PharoLauncher. >> It helps me to manage my parallel development and projects. >> >> We should put a link on the Pharo web site because >> >> http://files.pharo.org/platform/launcher/ >> >> is arcane. >> >> Stef >> > >

Dec. 13, 2017

[Pharo6][CI] test runs on submitted slices works again

by Marcus Denker

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. 13, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Stephane Ducasse

groupByRuns: looks good to me. On Tue, Dec 12, 2017 at 9:48 PM, Todd Blanchard <tblanchard(a)mac.com> wrote: > I'm kind of trying to figure out when I'd want that operation. > > groupsWithSeparatorsWhereSeparatatorsMatch: feels like it says what it does > > On Dec 12, 2017, at 10:19 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On 12 December 2017 at 20:03, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> >> 2017-12-12 13:01 GMT+01:00 Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no>: >>> >>> Ben Coman wrote >>> > >>> > But after pondering a while for a better name, I wonder what is wrong >>> > with >>> > the existing? >>> > Googling "define aggregate" provides... >>> > aggregate (noun) = a whole formed by combining several separate >>> > elements. >>> > aggregate (verb) = form or group into a class or cluster. >>> > >>> > The separate elements are runs defined by the block. >>> > The existing name seems quite precise to me. >>> > >>> > cheers -ben >>> >>> When I read aggregateRuns:, I think the opposite; something combining >>> different runs into a single entity, not something that splits a single >>> collection into constituent runs... > > > okay. I can understand that perspective. > >>> >>> >>> Something like (split/collect)runsAccordingTo: sounds more descriptive to >>> my >>> ears, at least. >>> >>> Cheers, >>> Henry >>> >>> >> >> I like groupBy: but in Squeak groupBy: produces a dictionary with unique >> keys ignoring the multiple sequences... >> split already carries the meaning of preserving the sequences, but we have >> to tell to split at a change of value.... >> Run is also quite explicit... >> >> groupByRuns: / splitRuns: > > > +1 > groupByRuns: is good. > > cheers -ben > >

Dec. 13, 2017

Re: [Pharo-dev] [Website] Updated Linux download instructions

by Marcus Denker

> On 13 Dec 2017, at 12:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Tx marcus. > It looks to me like a github project with small actionable todos :) > I do not understand. > On Wed, Dec 13, 2017 at 11:22 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> I have updated the download instruction with the infos from >> >> https://pharo.fogbugz.com/f/cases/20799/Update-Linux-Download-instructions >> >> Here are the two pages: >> >> https://pharo.org/gnu-linux-installation-64 >> https://pharo.org/gnu-linux-installation >> >> for the 32 bit version I opted to list the package based installation first >> as the zip file is quite >> complex (requiring manual setup). >> >> TODO >> - add a pointe to get.pharo.org >> - add two to actually start Pharo for all cases. >> - Check https://pharo.fogbugz.com/f/cases/20147/ >> - Check if some linux infos from http://pharo.org/download should not be >> better moved >> to the linux page. >> >> >> Marcus >

Dec. 13, 2017

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

by Stephane Ducasse

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. 13, 2017

Re: [Pharo-dev] [Website] Updated Linux download instructions

by Stephane Ducasse

Tx marcus. It looks to me like a github project with small actionable todos :) On Wed, Dec 13, 2017 at 11:22 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > I have updated the download instruction with the infos from > > https://pharo.fogbugz.com/f/cases/20799/Update-Linux-Download-instructions > > Here are the two pages: > > https://pharo.org/gnu-linux-installation-64 > https://pharo.org/gnu-linux-installation > > for the 32 bit version I opted to list the package based installation first > as the zip file is quite > complex (requiring manual setup). > > TODO > - add a pointe to get.pharo.org > - add two to actually start Pharo for all cases. > - Check https://pharo.fogbugz.com/f/cases/20147/ > - Check if some linux infos from http://pharo.org/download should not be > better moved > to the linux page. > > > Marcus

Dec. 13, 2017

Re: [Pharo-dev] Did the selection in Playground or rubric change?

by Stephane Ducasse

Tx marcus! Tim send a fileout! because this is too painful. Stef On Wed, Dec 13, 2017 at 12:33 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Actually I played around with all of that stuff and got it working well - but I got scared off with how to contribute with the new process etc. > > I can look again when the Xmas holidays kick in, and see if my small changes work in a 7.x image - I found that I could get the AST to work, but I had to add a little heuristic to it and if I found nothing and there was a selection then it worked the old way. > > Tim > >> On 12 Dec 2017, at 13:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Yes, I have it already on my list of things to fixâ¦ (not issue tracker entry yet, will add one). >> >> Marcus >> >>> On 12 Dec 2017, at 13:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> just type >>> >>> margins: Put the cursor here and press command + M or command + N >>> in the past >>> margins: was selected and used. >>> >>> What you see is that we cannot rely on the AST. >>> Now selecting items is boring. >>> >>> Stef >>> >>> On Tue, Dec 12, 2017 at 1:47 PM, Pavel Krivanek >>> <pavel.krivanek(a)gmail.com> wrote: >>>> Hi, >>>> >>>> Andrew improved that so it now works on AST and provides better results. If >>>> you have some code where it does not work, please try to describe the >>>> particular case so we can fix it. >>>> >>>> -- Pavel >>>> >>>> 2017-12-12 13:31 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>>> >>>>> Hi >>>>> >>>>> usually in previous version we could put the cursor on the line and >>>>> get senders and implementors without having to select the code. >>>>> Now this super cool features does not work anymore. >>>>> >>>>> Is it only my image? >>>>> >>>>> Stef >>>>> >>>> >>> >> >> > >

Dec. 13, 2017

Re: [Pharo-dev] [Website] Updated Linux download instructions

by Marcus Denker

> On 13 Dec 2017, at 11:22, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > I have updated the download instruction with the infos from > > https://pharo.fogbugz.com/f/cases/20799/Update-Linux-Download-instructions <https://pharo.fogbugz.com/f/cases/20799/Update-Linux-Download-instructions> > > Here are the two pages: > > https://pharo.org/gnu-linux-installation-64 <https://pharo.org/gnu-linux-installation-64> > https://pharo.org/gnu-linux-installation <https://pharo.org/gnu-linux-installation> > > > for the 32 bit version I opted to list the package based installation first as the zip file is quite > complex (requiring manual setup). > > TODO > - add a pointe to get.pharo.org <http://get.pharo.org/> > I added a section about zeroconf. Marcus

Dec. 13, 2017

Re: [Pharo-dev] 60528-64 OpalCompiler recompileAll ==> GLM trait conflict

by Stephane Ducasse

Sorry I'm lame.... On Wed, Dec 13, 2017 at 12:49 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > 32 bits :) > > On Wed, Dec 13, 2017 at 12:41 PM, Ben Coman <btc(a)openinworld.com> wrote: >> In a fresh 60528-64 image download with PharoLauncher on Ubuntu 16.04... >> 1. Open Playground >> 2. Evaluate... OpalCompler recompileAll >> 3. Try opening Iceberg, Playground or Spotter. >> ==> Error: A class or trait does not properly resolve a conflict between >> multiple traits it uses. >> >> System Browser, Test Runner and Monticello are okay. >> >> 60528 (32bit) is okay (what is different between 32bit and 64bit?) >> >> 60521-64 is broken >> 60520-64 is okay >> >> https://pharo.manuscript.com/f/cases/20867/OpalCompiler-recompileAll-GLM-tr… >> >> cheers -ben >>

Dec. 13, 2017

Re: [Pharo-dev] 60528-64 OpalCompiler recompileAll ==> GLM trait conflict

by Stephane Ducasse

32 bits :) On Wed, Dec 13, 2017 at 12:41 PM, Ben Coman <btc(a)openinworld.com> wrote: > In a fresh 60528-64 image download with PharoLauncher on Ubuntu 16.04... > 1. Open Playground > 2. Evaluate... OpalCompler recompileAll > 3. Try opening Iceberg, Playground or Spotter. > ==> Error: A class or trait does not properly resolve a conflict between > multiple traits it uses. > > System Browser, Test Runner and Monticello are okay. > > 60528 (32bit) is okay (what is different between 32bit and 64bit?) > > 60521-64 is broken > 60520-64 is okay > > https://pharo.manuscript.com/f/cases/20867/OpalCompiler-recompileAll-GLM-tr… > > cheers -ben >

Dec. 13, 2017

Re: [Pharo-dev] About a shared trello board

by Stephane Ducasse

;) Yes So Esteban proposed to use the github project and we started a set of focus projects On Wed, Dec 13, 2017 at 12:45 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 13.12.2017 um 10:58 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi >> >> I'm thinking that we are not good at communicating and coordinating effort >> I would like start a (read only) and welcome contributions on demand >> trello board >> so that we know each others on what parts of pharo we are currently working >> and what are the next steps. >> >> Does it make sense for you guys? >> > Yes, from time to time would like at it to see what has been done and what is in the pipe. Later on this would be a nice project for an image bloc-based client for the board ;) > > Norbert >

Dec. 13, 2017

Re: [Pharo-dev] About a shared trello board

by Norbert Hartl

> Am 13.12.2017 um 10:58 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi > > I'm thinking that we are not good at communicating and coordinating effort > I would like start a (read only) and welcome contributions on demand > trello board > so that we know each others on what parts of pharo we are currently working > and what are the next steps. > > Does it make sense for you guys? > Yes, from time to time would like at it to see what has been done and what is in the pipe. Later on this would be a nice project for an image bloc-based client for the board ;) Norbert

Dec. 13, 2017

60528-64 OpalCompiler recompileAll ==> GLM trait conflict

by Ben Coman

In a fresh 60528-64 image download with PharoLauncher on Ubuntu 16.04... 1. Open Playground 2. Evaluate... OpalCompler recompileAll 3. Try opening Iceberg, Playground or Spotter. ==> Error: A class or trait does not properly resolve a conflict between multiple traits it uses. System Browser, Test Runner and Monticello are okay. 60528 (32bit) is okay (what is different between 32bit and 64bit?) 60521-64 is broken 60520-64 is okay https://pharo.manuscript.com/f/cases/20867/OpalCompiler-recompileAll-GLM-tr… cheers -ben

Dec. 13, 2017