- Pharo-dev - lists.pharo.org

[Pharo 7.0] Build #111: 22877-Update-Iceberg-and-Tonel

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

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

Jan. 9, 2019

[Pharo 7.0] Build #110: 22428-Code-in-TimeProfiler-is-no-longer-highlighted

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

There is a new Pharo build available! The status of the build #110 was: SUCCESS. The Pull Request #2191 was integrated: "22428-Code-in-TimeProfiler-is-no-longer-highlighted" Pull request url: https://github.com/pharo-project/pharo/pull/2191 Issue Url: https://pharo.fogbugz.com/f/cases/22428 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 9, 2019

[Pharo 7.0] Build #109: 22874-System-Settings-package-should-be-removed-since-it-was-splitted

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

There is a new Pharo build available! The status of the build #109 was: FAILURE. The Pull Request #2182 was integrated: "22874-System-Settings-package-should-be-removed-since-it-was-splitted" Pull request url: https://github.com/pharo-project/pharo/pull/2182 Issue Url: https://pharo.fogbugz.com/f/cases/22874 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 9, 2019

[Pharo 7.0] Build #108: 22875-Some-test-packages-are-not-loaded

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

There is a new Pharo build available! The status of the build #108 was: SUCCESS. The Pull Request #2183 was integrated: "22875-Some-test-packages-are-not-loaded" Pull request url: https://github.com/pharo-project/pharo/pull/2183 Issue Url: https://pharo.fogbugz.com/f/cases/22875 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 9, 2019

Fwd: FileSystem and references to FIle

by Reg Krock

Forgot to copy the Pharo dev list. Begin forwarded message: > From: Reg Krock <rkrock3(a)yahoo.ca> > Subject: FileSystem and references to FIle > Date: 8 January, 2019 at 2:05:15 PM EST > To: Guillermo Polito <guillermopolito(a)gmail.com>, Sven Van Caekenberghe <sven(a)stfx.eu> > Cc: Dale Henrichs <dale.henrichs(a)gemtalksystems.com>, Martin McClure <martin.mcclure(a)gemtalksystems.com> > > Guille, > > As I have been working on porting FileStream to Gemstone, I have found that AbstractBinaryStream could be made more generic if the references to File were handled slightly differently. The idea is to delegate the call of File in AbstractBinaryStream to the instance side of File. > > For example: > AbstractBinaryFIleStream >>#flush > File flush: handle > > would be implemented as follows: > > AbstractBinaryFIleStream >>#flush > file flush: handle > > File>>#flush: aHandle > self class flush: aHandle > > From a compatibility perspective, GemStone would then also implement a GsFile>>#flush: and handle the flush as appropriate for GemStone. > > I have looked at the VA Smalltalk code as well and this would also work well with their code base. > > The methods that would need to be changed are: > 1) AbstractBinaryFileStream > atEnd > flush > next:intoBuffer: > next:putAll: > position > position: > readInto:startingAt: > size > sync > 2) BinaryFileStream > close > closed > truncate: > 2) StdioStream > next: > > Other references to File in the FileSystem classes, could the be changed to a FileSystem fileClass which would return the file class for the variation of Smalltalk. > Pharo would return File, GemStone would return GsFile, VA Smalltalk would return CfsFileDescriptor. > > Your thoughts on this are greatly appreciated. > > Regards, > > Reg >

Jan. 8, 2019

Iceberg - Merging when there are changes in the working copy

by Andrei Chis

Hi, IceCommitish>>#validateCanMerge has the warning: ''Experimental Feature: merge when there is a dirty working copy. Could cause a loss of your local changes. Please commit before merge.''. Are there some known situations when code can be lost? I'm asking because in releaser ( https://github.com/feenkcom/gtoolkit-releaser) we want to switch (not checkout) from the `master` branch to the `release` branch and then merge `master` into `release` running into the above warning. Switching to `release` branch, does a checkout at the git level, leaving the image code the same. Hence, the packages that have changed will be marked as dirty. So there aren't manual changes just changes caused by switching to a different branch. Cheers, Andrei

Jan. 8, 2019

Re: [Pharo-dev] [Issue 19852] Cached settings and moving images

by Nicolas Cellier

Le mar. 8 janv. 2019 Ã 17:36, Guillermo Polito <guillermopolito(a)gmail.com> a Ã©crit : > Hi Eliot, > > Thanks for looking into this, see inline. > > On Tue, Jan 8, 2019 at 4:46 PM Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Guille, >> >> On Jan 8, 2019, at 3:19 AM, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> Hi all, >> >> I was checking issue https://pharo.fogbugz.com/f/cases/19852 which is >> about the problems that arise when we move an image of location, and >> moreover when we move it between different platforms (windows to linux or >> mac for example). >> >> The problem are dangling file references pointing to invalid locations. >> >> We have found 4 of them: >> >> >> - SystemResolver localdirectory is cached in a class variable >> - GTPlaybook caches the cache and stash directories in class variables >> - OMSessionStore retrieves at some point during startup an invalid >> file reference from the (wrongly cached) local directory >> - IceLibgitRepository Sharedrepositorieslocation is also cached >> >> >> All these are actually caused by settings, whose behavior is not defined >> when an image is moved. >> There are several strange issues like, if we store settings, the local >> directory is stored, and then all images will (wrongly) use the same >> pharo-local directory of the first image. This is particularly annoying >> when using the launcher for example :). >> >> Now, we can leave this as it is right now and just move it to pharo8. >> A quick fix for Pharo7 would be removing those settings and avoiding >> caching, but that is probably very disruptive too... >> >> Opinions? >> >> >> While a âproperâ fix might involve adding symbolic names that can be >> cross-platform (including using environment variables, etc) >> > > Sure, we have that in FileSystem with file locators. The thing is that > people may be customizing those paths using the preference/settings to a > very-specific directory in their system. > > >> and that would indeed mean waiting for Pharo 8, surely something simple >> can be fine in the mean time. Why not have those classes maintain a >> âcurrent platformâ class var and a current directory on start up flush the >> file names if either the current platform or the current directory has >> changed? One would of course have to test the platform before the >> directory. Or even simpler, if the image name and directory are saved as >> strings (eg in Smalltalk as PreviousImageAndDirectory := { ... } >> > and thereâs an accessor such as imageNameAndOrDirectoryHasChanged) then >> the file names can easily be changed on start up. Getting the startup >> order right might be a little tricky but surely not that hard in this case. >> > > Sure, I've lately done something similar to (re)calculate the offsets of > FFI structures on startup only if the platform has changed, which we > required to have specially windows 64 FFI up and running. > > currentCompilationPlatform := { OSPlatform current family . Smalltalk vm > wordSize }. > LastCompilationPlatform = currentCompilationPlatform > ifTrue: [ ^ self ]. > LastCompilationPlatform := currentCompilationPlatform. > ... > > https://github.com/pharo-project/pharo/pull/1985 > > #me too :) http://source.squeak.org/FFI/FFI-Kernel-nice.49.diff However for this particular issue it's not clear in my mind yet if > comparing platform, image name and location is enough. Because this looks > like a so common issue for many other settings (and global/class variables > too), not only those containing file references! > > >> On a related note I think time boxed releases are a bad idea. A system >> is ready when it is ready, based on proper acceptance criteria, such as >> tests, user experience reports, etc. when it is clearly broken it is >> clearly broken. Releasing a system that is clearly broken helps nobody. >> (I say that as the US prepares to enter the 2020 election cycle...) >> >> >> 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 >

Jan. 8, 2019

Re: [Pharo-dev] Vote for the Pharo mooc :)

by Juan

Done ! Happy new year! El mar., 8 de ene. de 2019 15:05, Jigyasa Grover <grover.jigyasa1(a)gmail.com> escribiÃ³: > Voted, Good Luck ! > > On Mon, Jan 7, 2019 at 12:01 PM ducasse <stepharo(a)netcourrier.com> wrote: > >> Hi >> >> there is a competition for the mooc loved by its users: you can vote for >> the Pharo mooc at >> >> >> https://docs.google.com/forms/d/e/1FAIpQLSfPtKTnyRqJDlJ53A7Ml-nVoKRrz9ijz9L… >> >> Stef >> >> >> >>

Jan. 8, 2019

Re: [Pharo-dev] Vote for the Pharo mooc :)

by Jigyasa Grover

Voted, Good Luck ! On Mon, Jan 7, 2019 at 12:01 PM ducasse <stepharo(a)netcourrier.com> wrote: > Hi > > there is a competition for the mooc loved by its users: you can vote for > the Pharo mooc at > > > https://docs.google.com/forms/d/e/1FAIpQLSfPtKTnyRqJDlJ53A7Ml-nVoKRrz9ijz9L… > > Stef > > > >

Jan. 8, 2019

Re: [Pharo-dev] [Issue 19852] Cached settings and moving images

by Guillermo Polito

Hi Eliot, Thanks for looking into this, see inline. On Tue, Jan 8, 2019 at 4:46 PM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Guille, > > On Jan 8, 2019, at 3:19 AM, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi all, > > I was checking issue https://pharo.fogbugz.com/f/cases/19852 which is > about the problems that arise when we move an image of location, and > moreover when we move it between different platforms (windows to linux or > mac for example). > > The problem are dangling file references pointing to invalid locations. > > We have found 4 of them: > > > - SystemResolver localdirectory is cached in a class variable > - GTPlaybook caches the cache and stash directories in class variables > - OMSessionStore retrieves at some point during startup an invalid > file reference from the (wrongly cached) local directory > - IceLibgitRepository Sharedrepositorieslocation is also cached > > > All these are actually caused by settings, whose behavior is not defined > when an image is moved. > There are several strange issues like, if we store settings, the local > directory is stored, and then all images will (wrongly) use the same > pharo-local directory of the first image. This is particularly annoying > when using the launcher for example :). > > Now, we can leave this as it is right now and just move it to pharo8. > A quick fix for Pharo7 would be removing those settings and avoiding > caching, but that is probably very disruptive too... > > Opinions? > > > While a âproperâ fix might involve adding symbolic names that can be > cross-platform (including using environment variables, etc) > Sure, we have that in FileSystem with file locators. The thing is that people may be customizing those paths using the preference/settings to a very-specific directory in their system. > and that would indeed mean waiting for Pharo 8, surely something simple > can be fine in the mean time. Why not have those classes maintain a > âcurrent platformâ class var and a current directory on start up flush the > file names if either the current platform or the current directory has > changed? One would of course have to test the platform before the > directory. Or even simpler, if the image name and directory are saved as > strings (eg in Smalltalk as PreviousImageAndDirectory := { ... } > and thereâs an accessor such as imageNameAndOrDirectoryHasChanged) then the > file names can easily be changed on start up. Getting the startup order > right might be a little tricky but surely not that hard in this case. > Sure, I've lately done something similar to (re)calculate the offsets of FFI structures on startup only if the platform has changed, which we required to have specially windows 64 FFI up and running. currentCompilationPlatform := { OSPlatform current family . Smalltalk vm wordSize }. LastCompilationPlatform = currentCompilationPlatform ifTrue: [ ^ self ]. LastCompilationPlatform := currentCompilationPlatform. ... https://github.com/pharo-project/pharo/pull/1985 However for this particular issue it's not clear in my mind yet if comparing platform, image name and location is enough. Because this looks like a so common issue for many other settings (and global/class variables too), not only those containing file references! > On a related note I think time boxed releases are a bad idea. A system is > ready when it is ready, based on proper acceptance criteria, such as tests, > user experience reports, etc. when it is clearly broken it is clearly > broken. Releasing a system that is clearly broken helps nobody. (I say > that as the US prepares to enter the 2020 election cycle...) > > > 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

Jan. 8, 2019