January 2019 - Pharo-dev - lists.pharo.org

Fwd: FileSystem and references to FIle
by Reg Krock Jan. 8, 2019

Jan. 8, 2019

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 >

1 0

Iceberg - Merging when there are changes in the working copy
by Andrei Chis Jan. 8, 2019

Jan. 8, 2019

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

1 0

[Issue 19852] Cached settings and moving images
by Guillermo Polito Jan. 8, 2019

Jan. 8, 2019

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? Guille

4 4

Vote for the Pharo mooc :)
by ducasse Jan. 8, 2019

Jan. 8, 2019

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

3 2

[Pharo 7.0] Build #107: 22871-MC-makes-dirty-more-packages-than-expected
by ci-pharo-ci-jenkins2＠inria.fr Jan. 8, 2019

Jan. 8, 2019

There is a new Pharo build available! The status of the build #107 was: FAILURE. The Pull Request #2179 was integrated: "22871-MC-makes-dirty-more-packages-than-expected" Pull request url: https://github.com/pharo-project/pharo/pull/2179 Issue Url: https://pharo.fogbugz.com/f/cases/22871 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #4: FAILURE
by ci-pharo-ci-jenkins2＠inria.fr Jan. 8, 2019

Jan. 8, 2019

There is a new Pharo build available! The status of the build #4 was: FAILURE. Could not extract further issue information from commit message: temporary using 70 vm (since we do not have a 80 vm yet) Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #3: FAILURE
by ci-pharo-ci-jenkins2＠inria.fr Jan. 8, 2019

Jan. 8, 2019

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

1 0

[Pharo 7.0] Build #106: 22669-UFFI-structures-are-not-recalculated-on-system-startup
by ci-pharo-ci-jenkins2＠inria.fr Jan. 8, 2019

Jan. 8, 2019

There is a new Pharo build available! The status of the build #106 was: SUCCESS. The Pull Request #1985 was integrated: "22669-UFFI-structures-are-not-recalculated-on-system-startup" Pull request url: https://github.com/pharo-project/pharo/pull/1985 Issue Url: https://pharo.fogbugz.com/f/cases/22669 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0] Build #105: 22870-Remove-Compiler-packages-from-Pharo
by ci-pharo-ci-jenkins2＠inria.fr Jan. 8, 2019

Jan. 8, 2019

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

1 0

New book: Pharo with Style
by ducasse Jan. 8, 2019

Jan. 8, 2019

Thanks Esteban I saw your feedback and I will go over it soon. Just busy deprecating my google accounts and other job duties. Stef

1 0