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