- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] FileSystem fix integration

by Guillermo Polito

Hi Stef, On Tue, Aug 8, 2017 at 7:00 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi Alistair > > I'm going over the green build first. > > - Can you tell me what you think about the PR 92 05723 Default Working > Directory > https://pharo.fogbugz.com/f/cases/5723/ This cannot be integrated yet. We have to review dependencies in the bootstrap, because it introduces a (correct) definition of a working directory but using FFI. And FFI is not in the kernel. > > - Then also https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file- > doesn-t-exist-but-still-exists > I read it but do you suggest to drop it and close it? > > TX > > On Tue, Aug 8, 2017 at 6:44 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > For the moment I'm trying to understand the process and this is not that > simple > > because in flux. > > > > stef > > > > On Tue, Aug 8, 2017 at 3:24 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> Hi Stef, > >> > >> Great, thanks! > >> > >> If you've got any questions or concerns, please let me know, I'm more > >> than happy to discuss them. > >> > >> I've also got one more change that I haven't submitted yet. I > >> originally developed a patch that modified FileReference>>/ to accept > >> paths. However this directly conflicts with the change proposed in > >> https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file- > doesn-t-exist-but-still-exists. > >> Opinion seems to be split on which way we should go, so I'll defer to > >> higher authority on this particular issue. My patch also separated > >> path canonicalisation, as discussed in > >> http://forum.world.st/FileReference-gt-gt-and-path- > canonicalisation-td4952575.html, > >> so I might separate that out and make it a separate patch. > >> > >> > >> Cheers, > >> Alistair > >> > >> On 8 August 2017 at 10:27, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >>> Hi alistair > >>> > >>> I will go over all the FS changes and push them in Pharo 70. > >>> I'm learning the process to integrate fixes and I attract bugs :) > >>> > >>> Stef > >>> > >> > > -- Guille Polito Research Engineer 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

Aug. 8, 2017

Re: [Pharo-dev] FileSystem fix integration

by Stephane Ducasse

Hi Alistair I'm going over the green build first. - Can you tell me what you think about the PR 92 05723 Default Working Directory https://pharo.fogbugz.com/f/cases/5723/ - Then also https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-doesn-t-exist-but… I read it but do you suggest to drop it and close it? TX On Tue, Aug 8, 2017 at 6:44 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > For the moment I'm trying to understand the process and this is not that simple > because in flux. > > stef > > On Tue, Aug 8, 2017 at 3:24 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> Hi Stef, >> >> Great, thanks! >> >> If you've got any questions or concerns, please let me know, I'm more >> than happy to discuss them. >> >> I've also got one more change that I haven't submitted yet. I >> originally developed a patch that modified FileReference>>/ to accept >> paths. However this directly conflicts with the change proposed in >> https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-doesn-t-exist-but…. >> Opinion seems to be split on which way we should go, so I'll defer to >> higher authority on this particular issue. My patch also separated >> path canonicalisation, as discussed in >> http://forum.world.st/FileReference-gt-gt-and-path-canonicalisation-td49525…, >> so I might separate that out and make it a separate patch. >> >> >> Cheers, >> Alistair >> >> On 8 August 2017 at 10:27, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> Hi alistair >>> >>> I will go over all the FS changes and push them in Pharo 70. >>> I'm learning the process to integrate fixes and I attract bugs :) >>> >>> Stef >>> >>

Aug. 8, 2017

Re: [Pharo-dev] FileSystem fix integration

by Stephane Ducasse

For the moment I'm trying to understand the process and this is not that simple because in flux. stef On Tue, Aug 8, 2017 at 3:24 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > Great, thanks! > > If you've got any questions or concerns, please let me know, I'm more > than happy to discuss them. > > I've also got one more change that I haven't submitted yet. I > originally developed a patch that modified FileReference>>/ to accept > paths. However this directly conflicts with the change proposed in > https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-doesn-t-exist-but…. > Opinion seems to be split on which way we should go, so I'll defer to > higher authority on this particular issue. My patch also separated > path canonicalisation, as discussed in > http://forum.world.st/FileReference-gt-gt-and-path-canonicalisation-td49525…, > so I might separate that out and make it a separate patch. > > > Cheers, > Alistair > > On 8 August 2017 at 10:27, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Hi alistair >> >> I will go over all the FS changes and push them in Pharo 70. >> I'm learning the process to integrate fixes and I attract bugs :) >> >> Stef >> >

Aug. 8, 2017

Re: [Pharo-dev] FileSystem fix integration

by Alistair Grant

Hi Stef, Great, thanks! If you've got any questions or concerns, please let me know, I'm more than happy to discuss them. I've also got one more change that I haven't submitted yet. I originally developed a patch that modified FileReference>>/ to accept paths. However this directly conflicts with the change proposed in https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-doesn-t-exist-but…. Opinion seems to be split on which way we should go, so I'll defer to higher authority on this particular issue. My patch also separated path canonicalisation, as discussed in http://forum.world.st/FileReference-gt-gt-and-path-canonicalisation-td49525…, so I might separate that out and make it a separate patch. Cheers, Alistair On 8 August 2017 at 10:27, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi alistair > > I will go over all the FS changes and push them in Pharo 70. > I'm learning the process to integrate fixes and I attract bugs :) > > Stef >

Aug. 8, 2017

Re: [Pharo-dev] fixing the tab morph

by Pavel Krivanek

[image: VloÅ¾enÃ½ obrÃ¡zek 1] 2017-08-08 15:01 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > I personally think that the tabs in TabGroupMorph look more like tabs :-) > > -- Pavel > > 2017-08-07 17:47 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> Hi, >> >> Soâ¦ summer project (to do when there is too much hot to go outside): fix >> some minor things that are inside the image that annoys me since some time. >> >> First issue: the tab morph we have is horrible (and makes horrible >> anything with it). >> Iâve been working on it to fix that âchromish-but-badâ style we had and >> to fix some (a lot) hardcoded colors there. >> Now, for example, Calypso looks like this: >> >> >> >> >> which is IMHO a lot better :) >> >> some remarks: >> >> 1) I find TabManagerMorph an ugly name. Do you think we should change it? >> (I tend to think anything called *Manager, *Controller, etc. as a bad >> naming chose and probably the mark of a smell). >> 2) much more important: we should deprecate TabGroupMorph and >> LazyTabGroupMorph familyâ¦ there should not be more than one widget to do >> the same in the system. >> >> So well, as usual with old things: you fix a little thing and you uncover >> a lot of new problems :) >> >> Esteban >> >> >> >

Aug. 8, 2017

Re: [Pharo-dev] fixing the tab morph

by Pavel Krivanek

I personally think that the tabs in TabGroupMorph look more like tabs :-) -- Pavel 2017-08-07 17:47 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > Soâ¦ summer project (to do when there is too much hot to go outside): fix > some minor things that are inside the image that annoys me since some time. > > First issue: the tab morph we have is horrible (and makes horrible > anything with it). > Iâve been working on it to fix that âchromish-but-badâ style we had and to > fix some (a lot) hardcoded colors there. > Now, for example, Calypso looks like this: > > > > > which is IMHO a lot better :) > > some remarks: > > 1) I find TabManagerMorph an ugly name. Do you think we should change it? > (I tend to think anything called *Manager, *Controller, etc. as a bad > naming chose and probably the mark of a smell). > 2) much more important: we should deprecate TabGroupMorph and > LazyTabGroupMorph familyâ¦ there should not be more than one widget to do > the same in the system. > > So well, as usual with old things: you fix a little thing and you uncover > a lot of new problems :) > > Esteban > > >

Aug. 8, 2017

FileSystem fix integration

by Stephane Ducasse

Hi alistair I will go over all the FS changes and push them in Pharo 70. I'm learning the process to integrate fixes and I attract bugs :) Stef

Aug. 8, 2017

Re: [Pharo-dev] Having green builds

by Stephane Ducasse

Yes this is great. Now I will be rerunning the pending fix and integrate the green ones. On Sun, Aug 6, 2017 at 11:00 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi all, > > As you all know, we are now building from github. Integrations are made > through pull requests. And pull requests are validated using jenkins (that > is back again, Yay!). > > In this scenario, pull requests validations in github differentiate only > between three states: Pased (green) and not passed (red). This of course > conflicts with the three-state jobs of jenkins. By default jenkins > transforms failing tests (yellow) to a red state. This means that we lose > the extra information provided by the intermediate state. > > Now, because of this, in order to really differentiate good builds from > bad builds, we need to have green builds :). Always. > > Yesterday we worked with Pablo on that and now we have a PR that fixes all > tests and is green :) > > https://github.com/pharo-project/pharo/pull/184 > > You can follow up all the things we did in the issue also: > > https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70 > > As a summary, we could fix most tests by just touching some code here and > there. Some of them were portability issues, some other encoding in the > build slaves and so on. The only one we could not fix was a problem cause > by a side effect of QualityAssistant-Tests, so we skipped it. Those two > tests should be rewritten to not have side effects on other tests (In this > case, Epicea). > > Enjoy, > Guille and Pablo > > -- > > > > Guille Polito > > > Research Engineer > > 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> >

Aug. 8, 2017

Re: [Pharo-dev] Having green builds

by Tudor Girba

Excellent work! This is the kind of work that does not get much praise, but that provides the solid foundation we all need. Thanks! Doru -- www.tudorgirba.com "Every thing has its own flow" > On 6 Aug 2017, at 13:46, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > Great guys, this is the way to go. > >> On Sun, Aug 6, 2017 at 6:00 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> Hi all, >> >> As you all know, we are now building from github. Integrations are made through pull requests. And pull requests are validated using jenkins (that is back again, Yay!). >> >> In this scenario, pull requests validations in github differentiate only between three states: Pased (green) and not passed (red). This of course conflicts with the three-state jobs of jenkins. By default jenkins transforms failing tests (yellow) to a red state. This means that we lose the extra information provided by the intermediate state. >> >> Now, because of this, in order to really differentiate good builds from bad builds, we need to have green builds :). Always. >> >> Yesterday we worked with Pablo on that and now we have a PR that fixes all tests and is green :) >> >> https://github.com/pharo-project/pharo/pull/184 >> >> You can follow up all the things we did in the issue also: >> >> https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70 >> >> As a summary, we could fix most tests by just touching some code here and there. Some of them were portability issues, some other encoding in the build slaves and so on. The only one we could not fix was a problem cause by a side effect of QualityAssistant-Tests, so we skipped it. Those two tests should be rewritten to not have side effects on other tests (In this case, Epicea). >> >> Enjoy, >> Guille and Pablo >> >> -- >> >> Guille Polito >> >> Research Engineer >> French National Center for Scientific Research - http://www.cnrs.fr >> >> >> Web: http://guillep.github.io >> Phone: +33 06 52 70 66 13 >

Aug. 8, 2017

Re: [Pharo-dev] Two tables that share the same data source!?

by Elhamer

Hi Alex and thank you for your reply :)) Good to know that bloc already supports that, I am definitely moving to work on/with it after that :)) I've never encounter that scenario on a a Pharo package too, but since i was working on improving FTs, i thought why not!, besides, in apps with multiple tables, it might be handy to define a single large data source and assign columns to each table instead of defining a ds for each table, something like that: ```` |pane table1 table2 ds| ds:=FTCellSampleDataSource new:10. table1 := FTTableMorph new extent: 500@500; selectionMode: #column; addColumn: (FTColumn id: 'column1'); addColumn: (FTColumn id: 'column2'); addColumn: (FTColumn id: 'column6'); dataSource: ds; selectRowIndex: 1; showFirstRowSelection; beMultipleSelection; yourself. table2 := FTTableMorph new extent: 500@500; selectionMode: #column; addColumn: (FTColumn id: 'column3'); addColumn: (FTColumn id: 'column4'); addColumn: (FTColumn id: 'column5'); dataSource: ds; selectRowIndex: 1; showFirstRowSelection; beMultipleSelection; layoutInset: 10; yourself. pane := Morph new. pane layoutPolicy: TableLayout new. pane listDirection: #leftToRight. pane listCentering: #center. pane wrapCentering: #center. pane hResizing: #spaceFill. pane layoutInset: 10@10. pane cellInset:10@10. pane color: Color red. pane addMorph: table1. pane addMorph: table2. pane openInWindow . ``` <http://forum.world.st/file/n4959160/two_tables_single_ds.png> -- View this message in context: http://forum.world.st/Two-tables-that-share-the-same-data-source-tp4959153p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 8, 2017