- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #882: 21886-Unload-Compiler-Tests-package

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

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

May 12, 2018

[Pharo 7.0-dev] Build #881: 21878-deprecate-isTranslucentColor-using-deprecated-transformWith

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

There is a new Pharo build available! The status of the build #881 was: SUCCESS. The Pull Request #1340 was integrated: "21878-deprecate-isTranslucentColor-using-deprecated-transformWith" Pull request url: https://github.com/pharo-project/pharo/pull/1340 Issue Url: https://pharo.fogbugz.com/f/cases/21878 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 12, 2018

Re: [Pharo-dev] [ Umbrella Issue ] Cleanup remaining DeprecatedFileSystem users

by Alistair Grant

Hi Dave, On 12 May 2018 at 01:28, David T. Lewis <lewis(a)mail.msen.com> wrote: > Hi Alistair, > > On Fri, May 11, 2018 at 03:09:20PM +0200, Alistair Grant wrote: >> Hi Dave, >> >> ... >> >> Are the two primitives that were added to the VM a couple of months >> ago (primitiveConnectToFileDescriptor & primitiveConnectToFile) enough >> to allow AttachableFileStream to be removed? > > No, I was referring only to the actual file stream hierarchy. Long ago, > I tapped into StandardFileStream with some subclasses that do useful things > for OSProcess. That is clearly a hack, and I'm sure we could do better. > Having said that, I have not looked at Pharo 7 yet so maybe I don't know > what I'm talking about ;-) The two primitives aren't Pharo specific - although I don't think the primitive methods have been added to Squeak yet: primitiveConnectToFileDescriptor takes a posix file descriptor (integer) and returns a file handle (SQFile byte array). primitiveConnectToFile takes a posix FILE* pointer (byte array size FILE*) and returns a file handle (SQFile byte array). I suspect that AttachableFileStream does something else since it looks like #name:attachTo:writable: takes a SQFile byte array (I have to admit to not looking very carefully). Cheers, Alistair

May 12, 2018

[Pharo 7.0-dev] Build #880: 21812-Trait-slots-are-ignored-when-added-to-an-existing-trait

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

There is a new Pharo build available! The status of the build #880 was: FAILURE. The Pull Request #1282 was integrated: "21812-Trait-slots-are-ignored-when-added-to-an-existing-trait" Pull request url: https://github.com/pharo-project/pharo/pull/1282 Issue Url: https://pharo.fogbugz.com/f/cases/21812 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 12, 2018

[Pharo 7.0-dev] Build #879: 21840 Cleanup pass on PharoDocComment necessary

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

There is a new Pharo build available! The status of the build #879 was: SUCCESS. The Pull Request #1307 was integrated: "21840 Cleanup pass on PharoDocComment necessary" Pull request url: https://github.com/pharo-project/pharo/pull/1307 Issue Url: https://pharo.fogbugz.com/f/cases/21840 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 12, 2018

Re: [Pharo-dev] [ Umbrella Issue ] Cleanup remaining DeprecatedFileSystem users

by David T. Lewis

Hi Alistair, On Fri, May 11, 2018 at 03:09:20PM +0200, Alistair Grant wrote: > Hi Dave, > > On 11 May 2018 at 03:58, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Wed, May 09, 2018 at 01:41:47PM +0200, Thierry Goubier wrote: > >> 2018-05-09 13:14 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> > You mean you made a subclass of StandardFilestream yourself ? > >> > >> There are a few subclasses of StandardFileStream in OSProcess: > >> AttachableFileStream, AsyncFileReadStream and > >> BufferedAsyncFileReadStream. They will need to be ported. > >> > >> > If yes, can you describe briefly why you did so ? > >> > >> As far as my analysis go, AttachableFileStream refers to and > >> manipulates the underlying ioHandle of a unix pipe stream, > >> AsyncFileReadStream interacts with the asynchronous io extensions of > >> the vm to observe that io handle, and a BufferedAsyncFileReadStream > >> add a thread-safe, buffered, blocking API for smalltalk processe on > >> top. > > > > That's right. > > > > I'm sorry I have not been keeping up with this discussion, but one thought > > that comes to mind - the AttachableFileStream hierarchy is something that > > would better be replaced by some kind of delegation. It was a hack that I > > did a long time ago to allow OSProcess to work without modifying the base > > image. But since then, we have added multibyte characters and streams, and > > we have different file and stream models in Squeak/Pharo/Cuis (Cuis is an > > important target platform from my POV). > > > > I don't have a solution in mind, my sense is that if we find a way to make > > AttachableFileStream go away, then that solution would very likely make > > it unnecessary to develop and maintain separate Squeak/Pharo/Cuis forks > > moving forward. > > > > Note that the only fundamental thing that AttachableFileStream does is this: > > > > AttachableFileStream class>>name: aSymbolOrString attachTo: anIOHandle writable: readWriteFlag > > "Create a new instance attached to anIOHandle, where anIOHandle > > represents an open IO channel. For write streams, this represents two > > Smalltalk streams which write to the same OS file or output stream, > > presumably with interleaved output. The purpose of this method is to > > permit a FileStream to be attached to an existing IOHandle, such as > > the IOHandle for standard input, standard output, and standard error." > > > > ^ (super basicNew > > name: aSymbolOrString > > attachTo: anIOHandle > > writable: readWriteFlag) initialize > > > > > > The method comment refers to "IOHandle" which was another old project I was > > doing, but IOHandle basically means the #fileID field of a file stream. > > > > If it was just AttachableFileStream that needed to be refactored out of existence, > > it would be easy. But I later added quite a bit a behavior to BufferedAsyncFileReadStream > > and I'm not sure what might be needed to make this work properly. > > > > Sven, I suspect that you are the most knowledgeable in this area, so any > > suggestions would be welcome. > > Are the two primitives that were added to the VM a couple of months > ago (primitiveConnectToFileDescriptor & primitiveConnectToFile) enough > to allow AttachableFileStream to be removed? No, I was referring only to the actual file stream hierarchy. Long ago, I tapped into StandardFileStream with some subclasses that do useful things for OSProcess. That is clearly a hack, and I'm sure we could do better. Having said that, I have not looked at Pharo 7 yet so maybe I don't know what I'm talking about ;-) > > Also, borrowing primitiveSQFileSetNonBlocking from OSProcess I was > able to open a named pipe and read from it in a non-blocking way using > the standard Pharo 7 file stream (BinaryFileStream). I'd like to look > at getting AsyncFile working with it, but that's a long way down the > ToDo list. Good, primitiveSQFileSetNonBlocking certainly should work for that, and I'm glad to hear that it does. Dave > > HTH, > Alistair

May 11, 2018

Easy way to browse Hermes packages?

by Alistair Grant

Hi Everyone, Is there an easy way to browse the contents of .hermes files (from the Pharo 7 bootstrap process)? Or at least list the packages, classes and methods defined within? Thanks! Alistair

May 11, 2018

[Pharo 7.0-dev] Build #877: 21872-Some-Tools-do-not-use-proper-File-classes

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

There is a new Pharo build available! The status of the build #877 was: SUCCESS. The Pull Request #1332 was integrated: "21872-Some-Tools-do-not-use-proper-File-classes" Pull request url: https://github.com/pharo-project/pharo/pull/1332 Issue Url: https://pharo.fogbugz.com/f/cases/21872 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 11, 2018

[Pharo 7.0-dev] Build #876: 21882-UITheme-set-some-values-multiple-time-while-creating-new-buttons

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

There is a new Pharo build available! The status of the build #876 was: FAILURE. The Pull Request #1338 was integrated: "21882-UITheme-set-some-values-multiple-time-while-creating-new-buttons" Pull request url: https://github.com/pharo-project/pharo/pull/1338 Issue Url: https://pharo.fogbugz.com/f/cases/21882 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 11, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #869: 21863-Integrate-Calypso-v0113

by Denis Kudriashov

Thanks Sven. But still there are a lot to improve in Calypso design and code. 2018-05-11 12:04 GMT+03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 11 May 2018, at 09:50, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > > > There is a new Pharo build available! > > > > The status of the build #869 was: FAILURE. > > > > The Pull Request #1327 was integrated: "21863-Integrate-Calypso-v0113" > > Pull request url: https://github.com/pharo-project/pharo/pull/1327 > > > > Issue Url: https://pharo.fogbugz.com/f/cases/21863 > > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending% > 20pull%20request%20and%20branch%20Pipeline/job/development/869/ > > I want to take this opportunity to thank Denis for his excellent work on > Calypso. It is no small feat (in fact it is a heroic effort) to build a new > browser that is accepted by other developers as their main tool. Denis not > only built Calypso, but he patiently and professionally kept on improving > it, offering support and always quickly integrated constructive feedback, > while guarding his design objectives. > > Denis, really, you are a rock star developer ! > > Thank you. > > Sven > > >

May 11, 2018