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

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