[Pharo-dev] [Pharo 7.0-dev] Build #858: 21837 Improve FileSystem-Memory

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #858 was: FAILURE.

The Pull Request #1304 was integrated: "21837 Improve FileSystem-Memory"
Pull request url: https://github.com/pharo-project/pharo/pull/1304

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

[Pharo-dev] [Pharo 7.0-dev] Build #857: 21853 Several cleanups and fixes in Tool-Finder package

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #857 was: SUCCESS.

The Pull Request #1319 was integrated: "21853 Several cleanups and fixes in 
Tool-Finder package"
Pull request url: https://github.com/pharo-project/pharo/pull/1319

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

[Pharo-dev] [Pharo 7.0-dev] Build #856: 21851-Unify-OCSourceCodeChanged-and-ReparseAfterSourceEditing

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #856 was: SUCCESS.

The Pull Request #1317 was integrated: 
"21851-Unify-OCSourceCodeChanged-and-ReparseAfterSourceEditing"
Pull request url: https://github.com/pharo-project/pharo/pull/1317

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

[Pharo-dev] [Pharo 7.0-dev] Build #855: 21842 Cleanup Network-UUID

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #855 was: SUCCESS.

The Pull Request #1309 was integrated: "21842 Cleanup Network-UUID"
Pull request url: https://github.com/pharo-project/pharo/pull/1309

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

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

[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

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

[ci-pharo-ci-jenkins2]

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

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

[ci-pharo-ci-jenkins2]

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

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

[ci-pharo-ci-jenkins2]

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

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

[Thierry Goubier]

Hi Alistair,

2018-05-09 16:06 GMT+02:00 Alistair Grant :
>
>
> On Wed., 9 May 2018, 13:49 Sven Van Caekenberghe,  wrote:
>>
>>
>>
>> > On 9 May 2018, at 13:41, 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.
>>
>> 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
>

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

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




DrGeoTheme.cs
Description: Binary data

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

[Sven Van Caekenberghe]

> On 9 May 2018, at 16:06, Alistair Grant  wrote:
> 
> 
> 
> On Wed., 9 May 2018, 13:49 Sven Van Caekenberghe,  wrote:
> 
> 
> > On 9 May 2018, at 13:41, 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.
> 
> 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

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

[Alistair Grant]

On Wed., 9 May 2018, 13:49 Sven Van Caekenberghe,  wrote:

>
>
> > On 9 May 2018, at 13:41, 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.
>
> 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

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

[ci-pharo-ci-jenkins2]

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

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

[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

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

[Cyril Ferlicot D.]

On 09/05/2018 14:32, Hilaire wrote:
> well... For me the hight contrast makes it very visible, as should be a
> tooltip, and helpfull to discover feature in drgeo.
> 
> 

Maybe themes could use a dictionary storing all the colors for the theme.

Like that each theme should only define the default set of colors and
applications can easily customize the themes by updating this dictonary.

-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-dev] Is #openFileStream:writable: used ?

[Alistair Grant]

On Wed., 9 May 2018, 12:03 Sven Van Caekenberghe,  wrote:

> Hi,
>
> Both FileSystem and FileSystemStore (and its subclasses DiskStore and
> MemoryStore) implement #openFileStream:writable:
>
> However, there are no users and putting a breakpoint there does not
> trigger when reading/writing files.
>
> Candidate for removal or not ?
>
> Sven
>


I think so (well, deprecate at least).

I'd also suggest deprecating FileReference>>openWritable: which is
currently broken - it returns an unopened FileHandle.


Cheers,
Alistair
(on phone)

>
>

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

[Hilaire]

It looks like the scenario is worst than imagined. Some morph pick up 
the tooltips background color, then some other morph paint some text on 
the former one, without knowing their are painting on a kind of 
background tooltips.


Not even sure there is easy fix... bad.


Le 09/05/2018 à 13:17, Hilaire a écrit :
What changed is the UITheme receive a balloonTextColor method (the fix 
I proposed), BUT some morphs in Pharo use the theme 
balloonBackgroundColor BUT NOT the assorted balloonTextColor 
(obviously as this method was just introduced).


The right fix will be to makes these morphs using 
balloonBackgroundColor to use
balloonTextColor too. I took a look but get lost again in morph 
classes. Someone with the appropriate knowledge could fix it in a breeze.


--
Dr. Geo
http://drgeo.eu

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

[Hilaire]

well... For me the hight contrast makes it very visible, as should be a 
tooltip, and helpfull to discover feature in drgeo.



Le 09/05/2018 à 13:41, Esteban Lorenzano a écrit :

thanks Hilaire,

in any case yellow background for dark theme was bad:)

cheers,
Esteban


--
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] ASK FOR TEST: latest vm

[Pavel Krivanek]

Tested on 32-bit and 64-bit Linux. Everything seems to work well.

-- Pavel

2018-05-09 13:36 GMT+02:00 Esteban Lorenzano :

> hi,
>
> I will try to promote new stables.
> Can you people try the latest vm and report issues? (linux32 libgit2
> problem should be fixed)
>
> thanks!
> Esteban
>

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

[Sven Van Caekenberghe]

> On 9 May 2018, at 13:41, 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.

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.

> Regards,
> 
> Thierry
> 
>>> On 9 May 2018, at 13:12, Thierry Goubier  wrote:
>>> 
>>> Hi Sven,
>>> 
>>> in that process, how does one rewrite StandardFilestream subclasses?
>>> 
>>> Regards,
>>> 
>>> Thierry
>>> 
>>> 2018-05-09 11:51 GMT+02:00 Sven Van Caekenberghe :
 Hi,
 
 I created the following:
 
 
 https://pharo.manuscript.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSystem-users
 
 This is an umbrella issue, please create sub issues for each set of 
 changes. It is better to work step by step.
 
 The package DeprecatedFileSystem contains classes that should no longer be 
 used, the most important being
 
 FileStream, StandardFileStream and MultiByteFileStream
 MultiByteBinaryOrTextStream and RWBinaryOrTextStream
 
 Alternatives exist by using FileSystem's FileReference as well as File and 
 various new (Zn) streams.
 
 
 Let's all work together to make this real. It is important that the image 
 itself makes correct use of ongoing refactoring efforts. We already took 
 great steps, but there is more work to do. Note that in many cases, using 
 code can and should be simplified, removing ugly hacks where possible.
 
 Feel free to discuss any issues on the ML.
 
 Sven
>>> 
>> 
>> 
> 

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

[Thierry Goubier]

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.

Regards,

Thierry

>> On 9 May 2018, at 13:12, Thierry Goubier  wrote:
>>
>> Hi Sven,
>>
>> in that process, how does one rewrite StandardFilestream subclasses?
>>
>> Regards,
>>
>> Thierry
>>
>> 2018-05-09 11:51 GMT+02:00 Sven Van Caekenberghe :
>>> Hi,
>>>
>>> I created the following:
>>>
>>>
>>> https://pharo.manuscript.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSystem-users
>>>
>>> This is an umbrella issue, please create sub issues for each set of 
>>> changes. It is better to work step by step.
>>>
>>> The package DeprecatedFileSystem contains classes that should no longer be 
>>> used, the most important being
>>>
>>> FileStream, StandardFileStream and MultiByteFileStream
>>> MultiByteBinaryOrTextStream and RWBinaryOrTextStream
>>>
>>> Alternatives exist by using FileSystem's FileReference as well as File and 
>>> various new (Zn) streams.
>>>
>>>
>>> Let's all work together to make this real. It is important that the image 
>>> itself makes correct use of ongoing refactoring efforts. We already took 
>>> great steps, but there is more work to do. Note that in many cases, using 
>>> code can and should be simplified, removing ugly hacks where possible.
>>>
>>> Feel free to discuss any issues on the ML.
>>>
>>> Sven
>>
>
>

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

[Esteban Lorenzano]

thanks Hilaire,

in any case yellow background for dark theme was bad :)

cheers, 
Esteban

> On 9 May 2018, at 13:17, Hilaire  wrote:
> 
> What changed is the UITheme receive a balloonTextColor method (the fix I 
> proposed), BUT some morphs in Pharo use the theme balloonBackgroundColor BUT 
> NOT the assorted balloonTextColor (obviously as this method was just 
> introduced).
> 
> The right fix will be to makes these morphs using balloonBackgroundColor to 
> use
> balloonTextColor too. I took a look but get lost again in morph classes. 
> Someone with the appropriate knowledge could fix it in a breeze.
> 
> Hilaire
> 
> Le 08/05/2018 à 15:30, Esteban Lorenzano a écrit :
>> git says guilty was Torsten :P
>> anyway… that’s an awful color for background on dark.
>> Why nobody realised it before? I’m using a variant of the dark theme myself 
>> and I just realised now… what changed?
>> 
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

[Pharo-dev] ASK FOR TEST: latest vm

[Esteban Lorenzano]

hi, 

I will try to promote new stables. 
Can you people try the latest vm and report issues? (linux32 libgit2 problem 
should be fixed)

thanks!
Esteban

[Pharo-dev] [Pharo 7.0-dev] Build #850: 21816-use--for-become-and-becomeForward

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #850 was: FAILURE.

The Pull Request #1313 was integrated: "21816-use--for-become-and-becomeForward"
Pull request url: https://github.com/pharo-project/pharo/pull/1313

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

Re: [Pharo-dev] GT Playground Print It Popup unreadeable

[Hilaire]

Indeed. The use of colors seems to be a mess.


Le 09/05/2018 à 09:41, p...@highoctane.be a 
écrit :
ThemePalette would be a great addition. Color entries should be 
separated from the semantic meaning (e.g. background, tooltip, ...). 
There is some semantic meaning in the Theme but it is not backed by a 
ThemePalette which makes us create additional ThemeClasses for what is 
basically the same thing, only the palette changing.




--
Dr. Geo
http://drgeo.eu

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

[Hilaire]

What changed is the UITheme receive a balloonTextColor method (the fix I 
proposed), BUT some morphs in Pharo use the theme balloonBackgroundColor 
BUT NOT the assorted balloonTextColor (obviously as this method was just 
introduced).


The right fix will be to makes these morphs using balloonBackgroundColor 
to use
balloonTextColor too. I took a look but get lost again in morph classes. 
Someone with the appropriate knowledge could fix it in a breeze.


Hilaire

Le 08/05/2018 à 15:30, Esteban Lorenzano a écrit :

git says guilty was Torsten :P
anyway… that’s an awful color for background on dark.
Why nobody realised it before? I’m using a variant of the dark theme 
myself and I just realised now… what changed?




--
Dr. Geo
http://drgeo.eu

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

[Sven Van Caekenberghe]

You mean you made a subclass of StandardFilestream yourself ?

If yes, can you describe briefly why you did so ?

> On 9 May 2018, at 13:12, Thierry Goubier  wrote:
> 
> Hi Sven,
> 
> in that process, how does one rewrite StandardFilestream subclasses?
> 
> Regards,
> 
> Thierry
> 
> 2018-05-09 11:51 GMT+02:00 Sven Van Caekenberghe :
>> Hi,
>> 
>> I created the following:
>> 
>> 
>> https://pharo.manuscript.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSystem-users
>> 
>> This is an umbrella issue, please create sub issues for each set of changes. 
>> It is better to work step by step.
>> 
>> The package DeprecatedFileSystem contains classes that should no longer be 
>> used, the most important being
>> 
>> FileStream, StandardFileStream and MultiByteFileStream
>> MultiByteBinaryOrTextStream and RWBinaryOrTextStream
>> 
>> Alternatives exist by using FileSystem's FileReference as well as File and 
>> various new (Zn) streams.
>> 
>> 
>> Let's all work together to make this real. It is important that the image 
>> itself makes correct use of ongoing refactoring efforts. We already took 
>> great steps, but there is more work to do. Note that in many cases, using 
>> code can and should be simplified, removing ugly hacks where possible.
>> 
>> Feel free to discuss any issues on the ML.
>> 
>> Sven
> 

[Pharo-dev] [Pharo 7.0-dev] Build #849: 21848-Set-add-newObject-withOccurrences-anInteger--sams-as-superclass

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #849 was: SUCCESS.

The Pull Request #1314 was integrated: 
"21848-Set-add-newObject-withOccurrences-anInteger--sams-as-superclass"
Pull request url: https://github.com/pharo-project/pharo/pull/1314

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

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

[Thierry Goubier]

Hi Sven,

in that process, how does one rewrite StandardFilestream subclasses?

Regards,

Thierry

2018-05-09 11:51 GMT+02:00 Sven Van Caekenberghe :
> Hi,
>
> I created the following:
>
>
> https://pharo.manuscript.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSystem-users
>
> This is an umbrella issue, please create sub issues for each set of changes. 
> It is better to work step by step.
>
> The package DeprecatedFileSystem contains classes that should no longer be 
> used, the most important being
>
> FileStream, StandardFileStream and MultiByteFileStream
> MultiByteBinaryOrTextStream and RWBinaryOrTextStream
>
> Alternatives exist by using FileSystem's FileReference as well as File and 
> various new (Zn) streams.
>
>
> Let's all work together to make this real. It is important that the image 
> itself makes correct use of ongoing refactoring efforts. We already took 
> great steps, but there is more work to do. Note that in many cases, using 
> code can and should be simplified, removing ugly hacks where possible.
>
> Feel free to discuss any issues on the ML.
>
> Sven

Re: [Pharo-dev] GT Playground Print It Popup unreadeable

[Hilaire]

Problem is this GLPPrinterPopper morph is using the balloon color but 
not it assorted text color!


Replace:
        textColor: self theme textColor;

with
    textColor: self theme balloonTextColor;

It should be fixed.


GLPPrinterPopper>>initializeTextMorph
    textMorph := RubScrolledTextMorph new.
    textMorph
        beReadOnly;
        beWrapped;
        textFont: self theme textFont;
        textColor: self theme textColor;
        backgroundColor: BalloonMorph balloonColor.


Le 09/05/2018 à 12:08, Hilaire a écrit :
Part of the the problem here is using a tooltip to do something else! 
Printing the result of of printit as tooltips but it should be another 
widget, eventually subclassed.


Hilaire


--
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] GT Playground Print It Popup unreadeable

[Hilaire]

Part of the the problem here is using a tooltip to do something else! 
Printing the result of of printit as tooltips but it should be another 
widget, eventually subclassed.


Hilaire


Le 08/05/2018 à 16:09, Sven Van Caekenberghe a écrit :
In the very latest Pharo 7 using the Dark Theme (with the recent 
changed Tooltip), the intermediate Popup shown when doing Print It in 
a GT Playground is unreadable:


--
Dr. Geo
http://drgeo.eu

[Pharo-dev] Is #openFileStream:writable: used ?

[Sven Van Caekenberghe]

Hi,

Both FileSystem and FileSystemStore (and its subclasses DiskStore and 
MemoryStore) implement #openFileStream:writable:

However, there are no users and putting a breakpoint there does not trigger 
when reading/writing files.

Candidate for removal or not ?

Sven

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

[Sven Van Caekenberghe]

Hi,

I created the following:


https://pharo.manuscript.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSystem-users

This is an umbrella issue, please create sub issues for each set of changes. It 
is better to work step by step.

The package DeprecatedFileSystem contains classes that should no longer be 
used, the most important being

FileStream, StandardFileStream and MultiByteFileStream
MultiByteBinaryOrTextStream and RWBinaryOrTextStream

Alternatives exist by using FileSystem's FileReference as well as File and 
various new (Zn) streams.


Let's all work together to make this real. It is important that the image 
itself makes correct use of ongoing refactoring efforts. We already took great 
steps, but there is more work to do. Note that in many cases, using code can 
and should be simplified, removing ugly hacks where possible.

Feel free to discuss any issues on the ML.

Sven

[Pharo-dev] [Pharo 7.0-dev] Build #848: 21856 Balloon and playground printIt colors for DarkTheme should be fixed

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #848 was: SUCCESS.

The Pull Request #1320 was integrated: "21856 Balloon and playground printIt 
colors for DarkTheme should be fixed"
Pull request url: https://github.com/pharo-project/pharo/pull/1320

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

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

[Sven Van Caekenberghe]

Tested manually. OK from this Dark Theme user, Thx !

> On 9 May 2018, at 08:59, Torsten Bergmann  wrote:
> 
> Peter wrote:
>> Finally, consider the following test: In a dark room, only monitor with 
>> pharo and dark theme is producing light. Now a large popup with yellow 
>> background appears... did your eyes squint? can you suddenly see >the other 
>> side of the room? :)
> 
> Instead of hypothetical tests I tend to code in a light room and rather use 
> the practical approach of
> fixing an issue when it appears or when I get blamed for it :P
> 
> All details and a proposed solution are summarized in new issue: 
> https://pharo.fogbugz.com/f/cases/21856/
> which 
> - will not hardcode the balloon background color (as it was before the 
> introduction of #21809)
>   by using a lighter version of the darkBaseColor for balloonBackgroundColor 
> in DarkTheme
> - nonetheless exactly restores the actual color values of the dark theme as 
> before the introduction of issue #21809
> - still allows to define a tooltips text color on the graphics theme as it 
> was the goal in #21809
> 
> Also a new PR is awaiting a review: 
> https://github.com/pharo-project/pharo/pull/1320
> 
> Thx
> T.
> 

Re: [Pharo-dev] fun with announcers

[Denis Kudriashov]

I checked on my few days image. And I have >2000 announcers.
Cleaning Calypso cache does not help. And in fact after closing all
browsers and collecting garbage the cache became empty.

I found that most of subscriptions are related to rubric announcements.

2018-05-08 18:36 GMT+03:00 Henrik-Nergaard :

> Hi,
>
> >Announcer allInstances size. “7124"
> Remember that GT implements a lot of Announcer subclasses so to gain a
> better picture you should use:
> Announcer allSubInstances size.
>
> >clearly, that’s not good.
> >a symptom there is something leaking badly in our current development
> version.
> There has been leaking Announcements back from Pharo 5. Most of them is
> tangled into Rubric, and some GT tools.
> In the past many of the leaks has been from mixing weak and non weak
> subscriptions in the same announcer, IIRC.
>
> Here is a script you can run.
>
> ===
> | bag dct |
>
> bag := Bag new.
> dct := IdentityDictionary new.
>
> Smalltalk garbageCollect.
> Announcer allSubInstancesDo: [ :instance | | subs |
> subs := instance subscriptions subscriptions.
> subs do: [ :each | | cls |
> cls := each announcementClass.
> bag add: cls.
> dct at: cls
> ifPresent: [ :set | set add: each class ]
> ifAbsentPut: [ IdentitySet with: each class ]
> ]
> ].
>
> "{ bag . dct } inspect."
>
> "String streamContents: [ :ss |
> bag sortedCounts do: [ :assoc |
> ss
> << (assoc key asString padRightTo: 7);
> << assoc value printString;
> cr
> ]
> ]"
>
> dct associations select: [ :assoc | assoc value size > 1 ]
>
> ===
>
> Best regards,
> Henrik
>
>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] GT Playground Print It Popup unreadeable

[Esteban Lorenzano]

> On 9 May 2018, at 09:41, p...@highoctane.be wrote:
> 
> Hi All,
> 
> On Wed, May 9, 2018 at 9:02 AM, Torsten Bergmann  > wrote:
> H Sven
> 
> 
> Sven Van Caekenberghe wrote:
> >In the very latest Pharo 7 using the Dark Theme (with the recent changed 
> >Tooltip), the intermediate Popup shown when doing Print It in a GT 
> >Playground is unreadable:
> 
> see my reply in 
> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-May/271654.html
>  
> 
> which also will fix this issue.
> 
> Can't we all agree to introduce a proper palette system so that tools can be 
> based on them?

yes, we can agree and in fact, this is some kind “planned”. Now, real problem 
is “who puts the bell to the cat?” :)


> 
> There are all kind of weird tricks to darken/lighten/whatever on the colors 
> of the theme but there is no single place one can go to switch to another 
> palette without having to spend hours in getting things right. I worked on 
> the Sublimish theme to align GTSpotter with it and it was quite full of 
> interesting surprises.
> 
> Check https://terminal.sexy/  for example.
> 
> We have a live environment and we have to fiddle so much? Come on!
> 
> ThemePalette would be a great addition. Color entries should be separated 
> from the semantic meaning (e.g. background, tooltip, ...). There is some 
> semantic meaning in the Theme but it is not backed by a ThemePalette which 
> makes us create additional ThemeClasses for what is basically the same thing, 
> only the palette changing.

yes, please :)

Esteban

> 
> What do you think? Also, is there anything like this foreseen in Brick/Block?
> 
> Phil
> 
>  
> 
> Thx
> T.
>  
>  
> 
> 

Re: [Pharo-dev] GT Playground Print It Popup unreadeable

[p...@highoctane.be]

Hi All,

On Wed, May 9, 2018 at 9:02 AM, Torsten Bergmann  wrote:

> H Sven
>
>
> Sven Van Caekenberghe wrote:
> >In the very latest Pharo 7 using the Dark Theme (with the recent changed
> Tooltip), the intermediate Popup shown when doing Print It in a GT
> Playground is unreadable:
>
> see my reply in http://lists.pharo.org/pipermail/pharo-dev_lists.
> pharo.org/2018-May/271654.html
> which also will fix this issue.
>

Can't we all agree to introduce a proper palette system so that tools can
be based on them?

There are all kind of weird tricks to darken/lighten/whatever on the colors
of the theme but there is no single place one can go to switch to another
palette without having to spend hours in getting things right. I worked on
the Sublimish theme to align GTSpotter with it and it was quite full of
interesting surprises.

Check https://terminal.sexy/ for example.

We have a live environment and we have to fiddle so much? Come on!

ThemePalette would be a great addition. Color entries should be separated
from the semantic meaning (e.g. background, tooltip, ...). There is some
semantic meaning in the Theme but it is not backed by a ThemePalette which
makes us create additional ThemeClasses for what is basically the same
thing, only the palette changing.

What do you think? Also, is there anything like this foreseen in
Brick/Block?

Phil



>
> Thx
> T.
>
>
>
>

[Pharo-dev] [Pharo 7.0-dev] Build #847: 21849-add-isReferenced-for-Class

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #847 was: SUCCESS.

The Pull Request #1315 was integrated: "21849-add-isReferenced-for-Class"
Pull request url: https://github.com/pharo-project/pharo/pull/1315

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

Re: [Pharo-dev] GT Playground Print It Popup unreadeable

[Torsten Bergmann]

H Sven


Sven Van Caekenberghe wrote:
>In the very latest Pharo 7 using the Dark Theme (with the recent changed 
>Tooltip), the intermediate Popup shown when doing Print It in a GT Playground 
>is unreadable:

see my reply in 
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-May/271654.html
which also will fix this issue.

Thx
T.
 
 

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

[Torsten Bergmann]

Peter wrote:
>Finally, consider the following test: In a dark room, only monitor with pharo 
>and dark theme is producing light. Now a large popup with yellow background 
>appears... did your eyes squint? can you suddenly see >the other side of the 
>room? :)

Instead of hypothetical tests I tend to code in a light room and rather use the 
practical approach of
fixing an issue when it appears or when I get blamed for it :P

All details and a proposed solution are summarized in new issue: 
https://pharo.fogbugz.com/f/cases/21856/
which 
 - will not hardcode the balloon background color (as it was before the 
introduction of #21809)
   by using a lighter version of the darkBaseColor for balloonBackgroundColor 
in DarkTheme
 - nonetheless exactly restores the actual color values of the dark theme as 
before the introduction of issue #21809
 - still allows to define a tooltips text color on the graphics theme as it was 
the goal in #21809

Also a new PR is awaiting a review: 
https://github.com/pharo-project/pharo/pull/1320

Thx
T.