May 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] who redefined the #balloonBackgroundColor for dark theme?

by Hilaire

Hi Torsten, This will not work. Because some morphs in the system will mix use of theme's balloonColor and textColor, so these morphs will render as unreadable as soon as I change (Esteban screenshot). Anyway, I give up on that. Your lighter balloon background is good enough. Thanks Hilaire Le 09/05/2018 Ã 16:17, Torsten Bergmann a Ã©critÂ : > why not make a custom "DrGeoDarkTheme" as > > - a subclass of "PharoDarkTheme" (in Pharo 7) > - or "Pharo3DarkTheme" (when still in Pharo 6, note this class is deprecated in Pharo 7) > -- Dr. Geo http://drgeo.eu

May 9, 2018

[Pharo 7.0-dev] Build #854: 21860-remove-all-senders-of-compiler--translate

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

There is a new Pharo build available! The status of the build #854 was: SUCCESS. The Pull Request #1324 was integrated: "21860-remove-all-senders-of-compiler--translate" Pull request url: https://github.com/pharo-project/pharo/pull/1324 Issue Url: https://pharo.fogbugz.com/f/cases/21860 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 9, 2018

[Pharo 7.0-dev] Build #853: 21836 Improve FileSystem-Disk

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

There is a new Pharo build available! The status of the build #853 was: SUCCESS. The Pull Request #1303 was integrated: "21836 Improve FileSystem-Disk" Pull request url: https://github.com/pharo-project/pharo/pull/1303 Issue Url: https://pharo.fogbugz.com/f/cases/21836 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 9, 2018

[Pharo 7.0-dev] Build #852: 21834 Cleanups in FileSystem-Tests-Core

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

There is a new Pharo build available! The status of the build #852 was: FAILURE. The Pull Request #1301 was integrated: "21834 Cleanups in FileSystem-Tests-Core" Pull request url: https://github.com/pharo-project/pharo/pull/1301 Issue Url: https://pharo.fogbugz.com/f/cases/21834 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 9, 2018

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

by Thierry Goubier

Hi Alistair, 2018-05-09 16:06 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > > On Wed., 9 May 2018, 13:49 Sven Van Caekenberghe, <sven(a)stfx.eu> wrote: >> >> >> >> > On 9 May 2018, at 13:41, Thierry Goubier <thierry.goubier(a)gmail.com> >> > 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. >> >> Yes, they will have to be ported. >> >> If it were me (but I haven't looked at the code) I would not inherit from >> those classes, but from a simpler Stream class, possibly even none. The >> stream API is actually quite small (or it should be). >> >> Inheritance is an implementation technique, inheriting from a complex >> class can be hard, unless the superclass was really designed with that >> purpose. >> >> All this, IMHO. > > > > I agree that these classes will need to be ported, just a little food > for thought: > > I believe OSProcess is currently common between Squeak and Pharo - this > porting will require that OSProcess is forked for Pharo, so the two > implementations will start to diverge unless someone actively keeps them > in sync. (Please don't read this as a negative judgement, it is > just a statement of my understanding of the situation). I agree with your statement. Since I need OSProcess, I will probably undertake this, even if I don't see exactly how this would be done in the context of the development process of OSProcess today. The easiest would be to have a compatibility package loaded for OSProcess on Pharo > 70XXX; the hard part will be whether that XXX will be clearly known. > There are a number of plugin primitives that Dave added to OSProcess > because FilePlugin didn't meet his requirements. Some of the recent > changes made to FilePlugin reduce the need for additional primitives (it > is possible to connect to an existing file or file descriptor, #atEnd > works for pipes), and I think there are additional enhancements that can > be made which would reduce the number even further (mark files as > non-blocking) (but I haven't looked in to it properly and would want to > get Dave's input first). Agreed, and, yes, I've been loosely following what you were doing in this area. Anything that can improve Pharo robustness in that area will be appreciated, I had far too many lockups in the past to be happy with it. I'm a bit worried about VM changes now; I've played a bit too much with downloading my own VM from bintray for compensate for stability issues of the blessed VMs, so I'm not sure to be able to track custom OSProcess configurations depending on the presence of specific primitives in the VM... sort of like running a configure script for compiling a C library. Regards, Thierry > > Cheers, > Alistair >

May 9, 2018

Re: [Pharo-dev] who redefined the #balloonBackgroundColor for dark theme?

by Torsten Bergmann

Hi Hilaire, why not make a custom "DrGeoDarkTheme" as - a subclass of "PharoDarkTheme" (in Pharo 7) - or "Pharo3DarkTheme" (when still in Pharo 6, note this class is deprecated in Pharo 7) there you can overwrite the appropriate methods for your personal styled colors. I guess this was the idea for the theming class hierarchy and to my knowledge custom theming is used by Moose and others. Attached is an example and you can easily switch to it using DrGeoDarkTheme beCurrent in your playground, startup.st, the settings or other to get the yellow tooltip back. You can add new custom colors for Dr.Geo to this class, ... - so no dictionary needed. Or if you like the dictionary approach you can provide it in your subclass for Dr. Geo. Bye T.

May 9, 2018

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

by Sven Van Caekenberghe

> On 9 May 2018, at 16:06, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > On Wed., 9 May 2018, 13:49 Sven Van Caekenberghe, <sven(a)stfx.eu> wrote: > > > > On 9 May 2018, at 13:41, Thierry Goubier <thierry.goubier(a)gmail.com> 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. > > Yes, they will have to be ported. > > If it were me (but I haven't looked at the code) I would not inherit from those classes, but from a simpler Stream class, possibly even none. The stream API is actually quite small (or it should be). > > Inheritance is an implementation technique, inheriting from a complex class can be hard, unless the superclass was really designed with that purpose. > > All this, IMHO. > > > I agree that these classes will need to be ported, just a little food > for thought: > > I believe OSProcess is currently common between Squeak and Pharo - this > porting will require that OSProcess is forked for Pharo, so the two > implementations will start to diverge unless someone actively keeps them > in sync. (Please don't read this as a negative judgement, it is > just a statement of my understanding of the situation). > > > There are a number of plugin primitives that Dave added to OSProcess > because FilePlugin didn't meet his requirements. Some of the recent > changes made to FilePlugin reduce the need for additional primitives (it > is possible to connect to an existing file or file descriptor, #atEnd > works for pipes), and I think there are additional enhancements that can > be made which would reduce the number even further (mark files as > non-blocking) (but I haven't looked in to it properly and would want to > get Dave's input first). > > > Cheers, > Alistair Of course we should keep the good stuff and help in maintaining OSProcess. That will probably mean that OSProcess will need dialect specific sub packages for some of its implementation. And Alistair, you did a lot of good work in this area already, we/I need you to help along. Sven

May 9, 2018

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

by Alistair Grant

On Wed., 9 May 2018, 13:49 Sven Van Caekenberghe, <sven(a)stfx.eu> wrote: > > > > On 9 May 2018, at 13:41, Thierry Goubier <thierry.goubier(a)gmail.com> > 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. > > Yes, they will have to be ported. > > If it were me (but I haven't looked at the code) I would not inherit from > those classes, but from a simpler Stream class, possibly even none. The > stream API is actually quite small (or it should be). > > Inheritance is an implementation technique, inheriting from a complex > class can be hard, unless the superclass was really designed with that > purpose. > > All this, IMHO. > I agree that these classes will need to be ported, just a little food for thought: I believe OSProcess is currently common between Squeak and Pharo - this porting will require that OSProcess is forked for Pharo, so the two implementations will start to diverge unless someone actively keeps them in sync. (Please don't read this as a negative judgement, it is just a statement of my understanding of the situation). There are a number of plugin primitives that Dave added to OSProcess because FilePlugin didn't meet his requirements. Some of the recent changes made to FilePlugin reduce the need for additional primitives (it is possible to connect to an existing file or file descriptor, #atEnd works for pipes), and I think there are additional enhancements that can be made which would reduce the number even further (mark files as non-blocking) (but I haven't looked in to it properly and would want to get Dave's input first). Cheers, Alistair

May 9, 2018

[Pharo 7.0-dev] Build #851: 28135 Improve FileSystem-Core

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

There is a new Pharo build available! The status of the build #851 was: SUCCESS. The Pull Request #1302 was integrated: "28135 Improve FileSystem-Core" Pull request url: https://github.com/pharo-project/pharo/pull/1302 Issue Url: https://pharo.fogbugz.com/f/cases/21835 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 9, 2018

[ANN] VM stable promoted to 334be97 (from 09/05/2018)

by Esteban Lorenzano

Hi, So, I just give it another try to stable VM. Everything seems to be working fine but Iâm waiting any report that may cancel this move (I hope there are not, but who knows). this should fix a lot of bugs from older stable version, but I do not have a list of them, you will have to trust me :) cheers! Esteban ps: I will wait a week or so to declare a new stable for 6.1 too

May 9, 2018