March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo4] 203 issues tagged tagged for Pharo4

by Tudor Girba

Hey, please slow down. In this rhythm we will be done way before the release date :)) Doru On Sun, Mar 22, 2015 at 7:29 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 44! > > > On 20 Mar 2015, at 20:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > 52. Much better! > > > > some are even already fixed (but not integrated) so we will be below 50 > soon. > > > >> On 20 Mar 2015, at 10:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> 68 > >> > >>> On 19 Mar 2015, at 08:50, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >>> > >>> 88. > >>> > >>> https://pharo.fogbugz.com/f/filters/103/4-0-All > >>> > >> > >> > > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 22, 2015

Re: [Pharo-dev] [Pharo4] 203 issues tagged tagged for Pharo4

by Marcus Denker

44! > On 20 Mar 2015, at 20:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 52. Much better! > > some are even already fixed (but not integrated) so we will be below 50 soon. > >> On 20 Mar 2015, at 10:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> 68 >> >>> On 19 Mar 2015, at 08:50, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> 88. >>> >>> https://pharo.fogbugz.com/f/filters/103/4-0-All >>> >> >> >

March 22, 2015

[pharo-project/pharo-core] 099b5e: 40575

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 099b5e013de5b9a4e684df472a49ff5be8b13f68 https://github.com/pharo-project/pharo-core/commit/099b5e013de5b9a4e684df47… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-03-22 (Sun, 22 Mar 2015) Changed paths: M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertSelectedCompiledMethod.st M ReleaseTests.package/ObsoleteTest.class/instance/tests/testClassObsolete.st M ReleaseTests.package/ObsoleteTest.class/instance/tests/testFixObsoleteSharedPools.st M ReleaseTests.package/ObsoleteTest.class/instance/tests/testTraitObsolete.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script574.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script575.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40574.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40575.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40575 15206 PostScript was not executed for issue 15182? https://pharo.fogbugz.com/f/cases/15206 15203 Failing test: PackageTreeNautilusTest>>#testFullBrowseOnClass https://pharo.fogbugz.com/f/cases/15203 14470 ReleaseTes>>#testObsoleteClasses failiing due to AnObsoleteClassForObsoleteTest https://pharo.fogbugz.com/f/cases/14470 http://files.pharo.org/image/40/40575.zip

March 22, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40575 Home: https://github.com/pharo-project/pharo-core

March 22, 2015

Re: [Pharo-dev] Basic inspect not working

by stepharo

Yes I missed it. Le 22/3/15 13:55, Marcus Denker a Ã©crit : >> On 22 Mar 2015, at 13:41, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> Did we miss the postload for issue 15182? >> Basic Inspect gives >> PharoCommonTools(Object)>>doesNotUnderstand: #basicInspector >> >> > Yes. > >

March 22, 2015

Re: [Pharo-dev] Color arithmetical operations are broken

by kilon alios

"I personally assume to get Color transparent when subtract two absolutely equal colors." why ? that makes no sense to me. I guess we reason about things differently. In art black and white are not colors, they are called "neutrals" and they have the meaning of the existence of light (white) and non existence of light (black) as such black has the meaning of zero. Transparency does not affect colors its a characteristic of materials by allowing some of the light to pass through. In my view for arithmetical operation transparency should be ignored and operate only on the color itself.

March 22, 2015

15097 thx Re: [pharo-project/pharo-core] 93eb5c: 40571

by Ben Coman

On Sat, Mar 21, 2015 at 1:02 AM, GitHub <noreply(a)github.com> wrote: > Branch: refs/heads/4.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 93eb5ced08fb721a2448d25cdb6264468e083569 > > https://github.com/pharo-project/pharo-core/commit/93eb5ced08fb721a2448d25c… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2015-03-20 (Fri, 20 Mar 2015) > > Log Message: > ----------- > 40571 > 15097 Monticello repository UI not bolding unloaded packages after Lazy > MCVersionInfo integrated > https://pharo.fogbugz.com/f/cases/15097 > > I did not get a chance to review 15097 before it was integrated, but it was just what I was looking for. Thanks Thierry and Marcus. cheers -ben

March 22, 2015

Re: [Pharo-dev] Color arithmetical operations are broken

by Aliaksei Syrel

On Sun, Mar 22, 2015 at 3:31 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Color white - (Color white alpha:1.0) = Color black. > again reasonable No, it's not really reasonable ;) > (Color white alpha: 1.0) = Color white => true I personally assume to get Color transparent when subtract two absolutely equal colors. And by the way there is no way in pharo to detect that they could be not equal: (Color white alpha: 1.0) != Color white Color white - (Color white alpha:1.0) The same as > Color white - Color white Cheers, Alex

March 22, 2015

Re: [Pharo-dev] [Reflectivity] simple #before and #after links working...

by Tudor Girba

Indeed, it is an amazing piece of work :). Doru On Sun, Mar 22, 2015 at 2:58 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> I will revert the change in the visitorâ¦ this way we are sure that we do >> not get any problems. >> >> >> https://pharo.fogbugz.com/f/cases/15207/Undo-compiler-change-from-case-15196 >> >> I am really looking forward to that in Pharo5â¦ it is (one of my) largest >> mistakes that after my PhD I did not focus on >> getting Reflectivity into Pharoâ¦ it is still amazing, even 5 years later, >> I think. (but I am biased ;-) >> >> Marcus >> >> > Thanks Marcus. It sets a good example for everyone (including me). > Anyway, its a nice bit of honey to draw more people to follow the Pharo 5 > trunk ;) > cheers -ben > > > I will be so great that nobody will use Pharo4 everâ¦ ;-) > > Marcus > -- www.tudorgirba.com "Every thing has its own flow"

March 22, 2015

Re: [Pharo-dev] Color arithmetical operations are broken

by kilon alios

wait a sec why Alpha affects the Color ? o_O Color white - (Color white alpha:0.5) = Color gray. What ? No ! This make no sense Color white - (Color white alpha:0) = Color white Ok reasonable Color white - (Color white alpha:1.0) = Color black. again reasonable On Sun, Mar 22, 2015 at 4:06 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Color white - (Color white alpha:0) = Color white >> Color white - (Color white alpha:0.5) = Color gray. >> Color white - (Color white alpha:1.0) = Color black. >> For what do you need the color arithmetic ? >> Maybe there are already other operations defined on Color that you can >> used instead. > > > That is too complicated :) > The idea was to have one-line fix that just leaves the behaviour as it was > before, simply makes it not produce garbage. > Basically there should be a long discussion after pharo 4 is released. > > How it is now: > (Color white alpha: 0) = Color transparent => false > Color white - (Color white alpha: 0) = Color black => true > > From logical point of view is should not be black. But from mathematical > point of view Color is just a vector and operations with it should be the > same or almost the same as with vectors. > > For what do you need the color arithmetic ? > > I wanted to get linear discrete transformation from one color to another > to use it in animation > > Cheers, > Alex > > On Sun, Mar 22, 2015 at 1:54 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> >> On 22 Mar 2015, at 13:35, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> >> >> 2015-03-22 12:43 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> >>> >>> 2015-03-21 15:51 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>>> Why not take the average of alpha in all cases? >>>> >>>> Eliot (phone) >>>> >>>> On Mar 21, 2015, at 6:32 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> >>>> wrote: >>>> >>> >>> >>> Or weight the argument by its alpha and don't change the alpha of the >>> receiver: >>> Color white - (Color white alpha:0) = Color white >>> Color white - (Color white alpha:0.5) = Color gray. >>> Color white - (Color white alpha:1.0) = Color black. >>> >>> For what do you need the color arithmetic ? >>> Maybe there are already other operations defined on Color that you can >>> used instead. >>> >>> As the arithmetic operations on Color doesn't work (for years?), maybe >>> we should remove >>> the operation now, and replace them with a more verbose api >>> addRGB/ addRGBA/ subRGBA .... >>> >>> nicolai >>> >>> >> Ah, this issue is already closed. That was a rather short discussion. And >> #/ and #* still don't work >> for colors. >> >> >> Yesâ¦ I think we have a problem that there is no âthis is ready for >> integrationâ check. >> >> We need to get more carefulâ¦ >> >> Marcus >> > >

March 22, 2015