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

[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  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 :
> >> > 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

[Pharo-dev] Easy way to browse Hermes packages?

[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

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

[ci-pharo-ci-jenkins2]

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%20and%20branch%20Pipeline/job/development/877/

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

[ci-pharo-ci-jenkins2]

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%20and%20branch%20Pipeline/job/development/876/

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

[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 :

>
>
> > On 11 May 2018, at 09:50, ci-pharo-ci-jenki...@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
>
>
>

[Pharo-dev] [Pharo 7.0-dev] Build #875: 21864-merge-SHTextStylerST80-and-SHRBTextStyler

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #875 was: SUCCESS.

The Pull Request #1330 was integrated: 
"21864-merge-SHTextStylerST80-and-SHRBTextStyler"
Pull request url: https://github.com/pharo-project/pharo/pull/1330

Issue Url: https://pharo.fogbugz.com/f/cases/21864
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/875/

[Pharo-dev] [Pharo 7.0-dev] Build #874: 21881-Add-script-pragma-to-TaskbarMorph-classreset

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #874 was: FAILURE.

The Pull Request #1337 was integrated: 
"21881-Add-script-pragma-to-TaskbarMorph-classreset"
Pull request url: https://github.com/pharo-project/pharo/pull/1337

Issue Url: https://pharo.fogbugz.com/f/cases/21881
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/874/

[Pharo-dev] [Pharo 7.0-dev] Build #873: 21877--removeSelector-can-just-use-removeKeyifAbsent

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #873 was: FAILURE.

The Pull Request #1335 was integrated: 
"21877--removeSelector-can-just-use-removeKeyifAbsent"
Pull request url: https://github.com/pharo-project/pharo/pull/1335

Issue Url: https://pharo.fogbugz.com/f/cases/21877
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/873/

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

[Alistair Grant]

Hi Dave,

On 11 May 2018 at 03:58, David T. Lewis  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 :
>> > 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?

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.

HTH,
Alistair

[Pharo-dev] [Pharo 7.0-dev] Build #872: 21874-We-have-still-users-of-old-Compiler-api-evaluateinto

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #872 was: SUCCESS.

The Pull Request #1333 was integrated: 
"21874-We-have-still-users-of-old-Compiler-api-evaluateinto"
Pull request url: https://github.com/pharo-project/pharo/pull/1333

Issue Url: https://pharo.fogbugz.com/f/cases/21874
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/872/

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

[serge . stinckwich]

Yes this is just a little bit annoying when you use Pillar because you have a 
lot of noise ;-)

Envoyé de mon iPhone

> Le 11 mai 2018 à 17:17, Esteban Lorenzano  a écrit :
> 
> This is a problem since more than one year. 
> Apple changed something on their apis and nobody knows how to fix it. 
> 
> but it is just a warning and you can work normally anyway :)
> 
> cheers, 
> Esteban
> 
>> On 11 May 2018, at 00:14, Sven Van Caekenberghe  wrote:
>> 
>> 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  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
>> 
>> 
> 
> 

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

[Esteban Lorenzano]

This is a problem since more than one year. 
Apple changed something on their apis and nobody knows how to fix it. 

but it is just a warning and you can work normally anyway :)

cheers, 
Esteban

> On 11 May 2018, at 00:14, Sven Van Caekenberghe  wrote:
> 
> 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  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
> 
> 

[Pharo-dev] [Pharo 7.0-dev] Build #871: 21814-ShiftClassBuilder-sharedVariablesFromString-should-support-an-array-of-symbols

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #871 was: FAILURE.

The Pull Request #1283 was integrated: 
"21814-ShiftClassBuilder-sharedVariablesFromString-should-support-an-array-of-symbols"
Pull request url: https://github.com/pharo-project/pharo/pull/1283

Issue Url: https://pharo.fogbugz.com/f/cases/21814
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/871/

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

[Sven Van Caekenberghe]

> On 11 May 2018, at 09:50, ci-pharo-ci-jenki...@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

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

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #870 was: SUCCESS.

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/870/

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

[ci-pharo-ci-jenkins2]

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/

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

[ci-pharo-ci-jenkins2]

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%20and%20branch%20Pipeline/job/development/868/

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

[ci-pharo-ci-jenkins2]

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%20and%20branch%20Pipeline/job/development/867/