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

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

by Marcus Denker

> 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 <mailto:nicolaihess@web.de>>: > > > 2015-03-21 15:51 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@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 <mailto:alex.syrel@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

Basic inspect not working

by Nicolai Hess

Did we miss the postload for issue 15182? Basic Inspect gives PharoCommonTools(Object)>>doesNotUnderstand: #basicInspector

March 22, 2015

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

by Nicolai Hess

No wait, multiplication and division aren't supposed to work with colors , only aNumberOrArray. And this is working now. 2015-03-22 13:35 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 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. > > > > >> >> >> >> >> >>> >>> >>> On Sat, Mar 21, 2015 at 3:41 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> Do we need to do something for Pharo 4? And what is the >>>> simplest/quickest thing that would work - even if it needs revisiting in >>>> Pharo 5? >>> >>> >>> The most simple that works is to at least set alpha to any value. >>> >>> - Multiplication - alpha doesn't change >>> - Division - alpha doesn't change >>> - Addition - (color1 apha + color2 alpha) min: 1.0 - simple addition >>> and check to not allow alpha to overcome max value >>> - Subtraction - if two colors are the same alpha becomes 0, >>> otherwise we take alpha of message receiver (minuend) >>> >>> Slice is in inbox (15188) >>> >>> Cheers, >>> Alex >>> >>> >> >

March 22, 2015

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

by Nicolai Hess

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. > > > > > >> >> >> On Sat, Mar 21, 2015 at 3:41 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> Do we need to do something for Pharo 4? And what is the >>> simplest/quickest thing that would work - even if it needs revisiting in >>> Pharo 5? >> >> >> The most simple that works is to at least set alpha to any value. >> >> - Multiplication - alpha doesn't change >> - Division - alpha doesn't change >> - Addition - (color1 apha + color2 alpha) min: 1.0 - simple addition >> and check to not allow alpha to overcome max value >> - Subtraction - if two colors are the same alpha becomes 0, otherwise >> we take alpha of message receiver (minuend) >> >> Slice is in inbox (15188) >> >> Cheers, >> Alex >> >> >

March 22, 2015

Re: [Pharo-dev] TextMorph scrolling the text on edit or selection operations

by Ben Coman

Can't say that I noticed it. There is no information on that issue on how to reproduce it. Sounds like you've got two use cases. Can you provide some specific examples of these so I can observe the behaviour. cheers -ben On Sun, Mar 22, 2015 at 3:19 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > Hi all, > > I am assuming that I am not the only one that gets very annoyed when a > TextMorph scrolls the text when typing, such that the line I am typing is > always at the bottom, or scrolls the debugger when I am stepping over > instructions. I looked into this (bug > > https://pharo.fogbugz.com/f/cases/12569/TextModel-should-not-move-scroll-wh… > actually) and I found a fix. > > But first I want to understand why the code is as it is. Anybody have any > idea why PluggableTextMorph>>setTextBasic: starts with scrollBar setValue: > 0.0. ?? If I remove this line the very annoying behavior is gone, and as > far as I can see there are no negative consequences on text handling (and > scrolling) in general. So I am wondering why it is there at all. > > A slice with my fix is in the inbox if you want to play a bit with it: > SLICE-Issue-12569-TextModel-should-not-move-scroll-when-accepting-text-johanfabry.1 > > Please have a look, this behavior has been getting on my nerves for quite > some time now â¦ > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > >

March 22, 2015

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

by Nicolai Hess

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 > > > On Sat, Mar 21, 2015 at 3:41 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> Do we need to do something for Pharo 4? And what is the simplest/quickest >> thing that would work - even if it needs revisiting in Pharo 5? > > > The most simple that works is to at least set alpha to any value. > > - Multiplication - alpha doesn't change > - Division - alpha doesn't change > - Addition - (color1 apha + color2 alpha) min: 1.0 - simple addition > and check to not allow alpha to overcome max value > - Subtraction - if two colors are the same alpha becomes 0, otherwise > we take alpha of message receiver (minuend) > > Slice is in inbox (15188) > > Cheers, > Alex > >

March 22, 2015

Re: [Pharo-dev] PharoLauncher: Great Tool, Confusing Name

by Sean P. DeNigris

> I agree, I like PharoLauncher. It works very well. Sean, you didn't add > a "deploy this image on Digital Ocean" command yet? I know, Iâm such a slacker ;) Shouldnât be too hard, thoughâ¦ ----- Cheers, Sean -- View this message in context: http://forum.world.st/PharoLauncher-Great-Tool-Confusing-Name-tp4813698p481… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 22, 2015

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

by Marcus Denker

> On 22 Mar 2015, at 11:33, Ben Coman <btc(a)openInWorld.com> wrote: > > That is very cool. But I need to ask the tough question - given that the feature freeze was three weeks ago, what do we gain by adding this in Pharo 4? > > * Is it needed for demonstrations that won't be based off latest features in Pharo 5 ? > > * Are third party libraries expected to be based only off Pharo 4 MetaLink features, rather than additional MetaLink features it sounds like Pharo 5 will get ? > > > which means this slice should not impact anything > > Because "should" being the operative word... is a slippery slope. If we have a philosophy of freezing features before a Release, then we should have the discipline to hold to that - at least in last 7 days before Release. > Yes, maybe we should postpone itâ¦ releasing is boring, I have to admit :-) Marcus

March 22, 2015

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

by Ben Coman

That is very cool. But I need to ask the tough question - given that the feature freeze was three weeks ago, what do we gain by adding this in Pharo 4? * Is it needed for demonstrations that won't be based off latest features in Pharo 5 ? * Are third party libraries expected to be based only off Pharo 4 MetaLink features, rather than additional MetaLink features it sounds like Pharo 5 will get ? > which means this slice should not impact anything Because "should" being the operative word... is a slippery slope. If we have a philosophy of freezing features before a Release, then we should have the discipline to hold to that - at least in last 7 days before Release. cheers -ben On Sat, Mar 21, 2015 at 11:56 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > After loading this: > > > https://pharo.fogbugz.com/f/cases/15196/Simple-before-and-after-links-with-… > > Simple after and before MetaLinks are taken into account, with just one > check in #visitNode of the ASTTranslator that is > false when no links are there. (which means this slice should not impact > anything) > > For now this is for very simple MetaLinks: no parameters, no condition, no > reification, no #instead/around, > no meta-level modelling. > > Here is a trivial example: > > 1) get a AST node from our example method: > > sendNode := (ReflectivityExamples>>#exampleMethod) ast body statements > first value. > > 2) then we define a link that is just #halt: > > link := MetaLink new > metaObject: Halt; > selector: #now. > > 3) we set it: > > sendNode link: link. > > 4) when we now execute the method, we get a halt: > > ReflectivityExamples new exampleMethod > > 5) to get rid of it, uninstall the link: > > link uninstall. > > If you look at the byte code, you see that it compiles the link to the > code: > > 25 <20> pushConstant: Halt > 26 <D1> send: now > > Marcus > >

March 22, 2015

[pharo-project/pharo-core]

by GitHub

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

March 22, 2015