- Pharo-dev - lists.pharo.org

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

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

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%2…

May 11, 2018

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

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

There is a new Pharo build available! The status of the build #868 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%2…

May 11, 2018

[Pharo 7.0-dev] Build #867: 21870-Fix-Base64-madness-for-good

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

There is a new Pharo build available! The status of the build #867 was: FAILURE. The Pull Request #1331 was integrated: "21870-Fix-Base64-madness-for-good" Pull request url: https://github.com/pharo-project/pharo/pull/1331 Issue Url: https://pharo.fogbugz.com/f/cases/21870 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 11, 2018

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

by David T. Lewis

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. Apologies once again for not keeping up with this, but I am glad to see the discussion. Dave

May 11, 2018

Re: [Pharo-dev] Recent Pharo 6.1 OSX shows lots of "Error: unsupported compressor 8 on command line"

by Sven Van Caekenberghe

Yeah, I saw that for a while too, but my 64bit P7 VMs from the last couple of days don't do this anymore. I don't know why. > On 10 May 2018, at 23:53, Tim Mackinnon <tim(a)testit.works> wrote: > > I noticed that recent Pharo 6.1 zero conf downloads show lots of these errors when you run the image in the terminal. Previous versions didnât do this - is this something to do with the latest vm upgrade? > > ./pharo-ui PagerDuty.image > /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8 > /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist' > /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8 > /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist' > > > Tim

May 10, 2018

Recent Pharo 6.1 OSX shows lots of "Error: unsupported compressor 8 on command line"

by Tim Mackinnon

I noticed that recent Pharo 6.1 zero conf downloads show lots of these errors when you run the image in the terminal. Previous versions didnât do this - is this something to do with the latest vm upgrade? ./pharo-ui PagerDuty.image /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8 /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist' /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8 /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist' Tim

May 10, 2018

Re: [Pharo-dev] File, FileHandle and FileReference

by Guillermo Polito

Even before the refactoring, FileHandle was just using opening a file using a MultiByteFileStream. Probably FileHandle was originally thought as a clean replacement/faÃ§ade of the old streams? I don't know. On Thu, May 10, 2018 at 10:16 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > In a separate email I suggested deprecating > FileReference>>openWritable: (I'm still planning to submit a PR), but on > further inspection... > > Does anyone know the history and plans for File and FileHandle? > > The comments for FileHandle to me suggest it is a layer between a stream > and the primitives (FilePlugin). But as far as I can tell, it is never > used. The stream creation methods in FileReference (readStream, > writeStream, binaryReadStream, binaryWriteStream) use FileHandle during > the stream creation, but the end result doesn't actually include a > FileHandle. The main method called (in the case of the write variants) > is: > > > -- > FileHandle>>binaryWriteStream > ^ (File named: reference fullName) writeStream > -- > > > which obviously doesn't actually need FileHandle at all. > > Streams have a handle, but it is a ByteArray, which is the associated > SQFile structure used by the VM. > > Presumably the intention was that the streams would hold on to a > FileHandle, which would keep the ByteArray. This makes sense since it > gives us an object that can take responsibility for some operations (as > opposed to using a ByteArray as the handle). > > > On the other side, the class comment for File says: > > > -- > I represent a sequential binary File. I provide the minimum operations to: > > - move the cursor fo the file > - reading > - writing > > ... > -- > > > And then goes on to mention several methods that aren't actually > implemented, e.g. seekAbsolute:, seekRelative:, nextPutAll:, next:, etc. > > It ends up just being a set of utility methods to facilitate the > creation of streams. > > It would be great if someone is able to fill in the gaps. If not, I can > think of two paths we can take (apart from leaving things as they are, > which seems a bit messy): > > > 1. Remove (deprecate) both File and FileHandle and move the > responsibility of creating the BinaryFileStream to the FileSystemStore. > > > 2. Make FileHandle really responsible for representing an open file and > modify streams, etc., to use FileHandle. > > I prefer the second approach as it provides more granular responsibility > and a natural place to put functionality that is not directly stream > related (as an example, I'm planning to extend the file attributes > functionality so we can stat() an open file to find out the mode, etc.). > But I'd want to think about the performance implications of adding a > layer between streams and FilePluginPrims. > > > > What am I missing? > > > > 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

May 10, 2018

Re: [Pharo-dev] Fix Base64 madness for good

by Guillermo Polito

YESS! On Thu, May 10, 2018 at 10:33 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 10.05.2018 um 21:42 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > Hi, > > > > I propose the following: > > > > https://pharo.manuscript.com/f/cases/21870/Fix-Base64-madness-for-good > > https://github.com/pharo-project/pharo/pull/1331 > > > > This is a much needed cleanup, IMHO. It is a breaking change however, > since it changes the signature (return type) of an existing method. > > > > #base64Decoded used to wrongly return a String, while that should be a > ByteArray since Base64 encoding is a way to encode bytes as ASCII text, > hence decoding it should give you back the original bytes. > > > Please do. It is obviously the right move. The times where strings > contained bytes and it makes sense is over for a long time. > > Norbert > > -- 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

May 10, 2018

Re: [Pharo-dev] Fix Base64 madness for good

by Norbert Hartl

> Am 10.05.2018 um 21:42 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi, > > I propose the following: > > https://pharo.manuscript.com/f/cases/21870/Fix-Base64-madness-for-good > https://github.com/pharo-project/pharo/pull/1331 > > This is a much needed cleanup, IMHO. It is a breaking change however, since it changes the signature (return type) of an existing method. > > #base64Decoded used to wrongly return a String, while that should be a ByteArray since Base64 encoding is a way to encode bytes as ASCII text, hence decoding it should give you back the original bytes. > Please do. It is obviously the right move. The times where strings contained bytes and it makes sense is over for a long time. Norbert

May 10, 2018

Re: [Pharo-dev] Fix Base64 madness for good

by Esteban A. Maringolo

10/05/2018 16:42, Sven Van Caekenberghe wrote: > Hi, > > I propose the following: > > https://pharo.manuscript.com/f/cases/21870/Fix-Base64-madness-for-good > https://github.com/pharo-project/pharo/pull/1331 > > This is a much needed cleanup, IMHO. It is a breaking change however, since it changes the signature (return type) of an existing method. > > #base64Decoded used to wrongly return a String, while that should be a ByteArray since Base64 encoding is a way to encode bytes as ASCII text, hence decoding it should give you back the original bytes. Those who were using these methods expecting a string can send #asString to the returned bytarray. Of course that would be wrong, but it would be "as wrong as before", and hence, compatible. So please go ahead and change it. Also, having a "proper" implementation in a live environment serves a teaching vehicle for those learning how stuff works. Regards, -- Esteban A. Maringolo

May 10, 2018