Color Class has a bug
Locked
 
|
hello there,
i don't know it the problem is still known but the following i figured yesterday: when using the class method Color>>fromString: 'yellow' or also Color>>fromString: 'orange' you will always get the hex-value of black. so i figured the following mistake aString first = $# u see: aColorHex will be aString when there is no '#' within the string. but when the string has just the size of 6 (like it is given with 'yellow' or 'orange' then the statement will also be true. in fact of that you get a wrong hex for the right color :) i just tried the following aString first = $# but in fact i couldn't test it very deeply i don't know if it still serves well when using hex-colors higher then 10 ( e.g. A1 or FF) there is also the problem that asHex is deprecated - so i can't use it instead. thx for your patience :) |
|
|
"Peter Osburg" <[hidden email]> wrote:
> hello there, > > i don't know it the problem is still known but the following i figured > yesterday: > > when using the class method > Color>>fromString: 'yellow' > > or also > Color>>fromString: 'orange' > > > you will always get the hex-value of black. so i figured the following > mistake I'm running Squeak3.8-6665 (admittedly that's quite old, but anyhow). I ran in a Workspace Color fromString: '#orange' which returned a "Color orange", and Color fromString: 'orange' which returned a "Color orange". In short, I can't duplicate your problem (on my system). > aString first = $# > > ifTrue: [aColorHex := aString copyFrom: 2 to: aString size] > > ifFalse: [aColorHex := aString]. > > [aColorHex size = 6 > > ifTrue: > > [aColorHex := aColorHex asUppercase. > > red := ('16r', (aColorHex copyFrom: 1 to: 2)) asNumber/255. > > green := ('16r', (aColorHex copyFrom: 3 to: 4)) asNumber/255. > > blue := ('16r', (aColorHex copyFrom: 5 to: 6)) asNumber/255. > > ^ self r: red g: green b: blue]] > > > u see: aColorHex will be aString when there is no '#' within the string. but > when the string has just the size of 6 (like it is given with 'yellow' or > 'orange' then the statement will also be true. in fact of that you get a > wrong hex for the right color :) This is only part of the version of fromString in my image. The bit immediately after the above snippet says ifError: [:err :rcvr | "not a hex color triplet" ]. If you debug "Color fromString: 'orange'" you'll see the debugger will trace into this (empty) block. Since 'orange' isn't a hex colour triple, nothing's returned, and we continue execution: "try to match aColorHex with known named colors" aColorHex _ aColorHex asLowercase. ^self perform: (ColorNames detect: [:i | i asString asLowercase = aColorHex] ifNone: [#white]) Since 'orange' is an element in ColorNames, the "self perform" bit will execute "Color orange", returning the colour you desired. Does this help? frank |
|
|
In reply to this post by Peter Osburg-2
Le Jeudi 09 Novembre 2006 12:12, Frank Shearar a écrit :
> "Peter Osburg" <[hidden email]> wrote: > > hello there, > > > > i don't know it the problem is still known but the following i figured > > yesterday: > > > > when using the class method > > Color>>fromString: 'yellow' > > > > or also > > Color>>fromString: 'orange' Hello Peter, bug exist in 3.9 image thank you for your report Best procedure is using squeak-dev only for announcing a new bug report, and report the bug on mantis (the squeak bug database) Here is the procedure. Go through step 1-2), or 3) if you have time, and 4) if super good will In advance, thank you Nicolas 1) check if bug already reported 2) if not, create an account, login and report the bug (Project Squeak, category Graphics, summary [BUG] Color fromString: incorrect if 6 letter color symbol) Once created, post a reference and short summary on squeak-dev 3) unless a SUnit test case already exist covering this bug, write one - open a change set sorter and create a new change set (ColorTestFromString) - complete existing test ColorTest>>testFromString in your browser - run it with SUnit test runner - file out the change set from change set sorter, you obtain a file ColorTestFromString.1.cs - upload this file in your mantis bug report 4) unless a patch already exist (Frank seems to say code is working in 3.8 image...), create one - open a change set sorter and create a new change set (ColorPatchFromString) - change ColorTest class>>fromString: in your browser - run it with SUnit test runner: BEWARE you must not break another feature... - file out the change set from change set sorter, you obtain a file ColorPatchFormString.1.cs - upload this file in your mantis bug report That's the golden way for easing harvesters job, also for providing good bug tracking capability and feedback. (harvesting is a teddious work, even with bug database help). ________________________________________________________________________ iFRANCE, exprimez-vous ! http://web.ifrance.com |
|
|
In reply to this post by Peter Osburg-2
Le Jeudi 09 Novembre 2006 13:10, [hidden email] a écrit :
> 1) check if bug already reported forgot to give you the address of mantis is at http://bugs.impara.de/view_all_bug_page.php from there you will find sign up, login and bug report page. Bye ________________________________________________________________________ iFRANCE, exprimez-vous ! http://web.ifrance.com |
|
|
In reply to this post by Peter Osburg-2
I did not concentrate enough on Frank Shearar message.
He got it right. Color>>formString: implementationrely on the fact that an error is generated. '16rYELLOW' asNumber did generate a bug in 3.8, no more in 3.9. Note that this is half lucky, because in many cases, String>>asNumber is very permissive. '' asNumber = 0 '16r' asNumber = 0 '16rX' asNumber ERROR This kind of weirdness motivated the design of SqueakNumberParser in 3.9 (hey, do not blame me, error pre-existed as a change in Integer>>readFrom:base: ). SqueakNumberParser is able to raise an error, but default behavior is rather to answer 0 like previous 3.9 implementation... Shouldn't this change in next version 3.10 or 4.0 ? ________________________________________________________________________ iFRANCE, exprimez-vous ! http://web.ifrance.com |
|
|
[hidden email] wrote:
> This kind of weirdness motivated the design of SqueakNumberParser in 3.9 (hey, do not blame me, error pre-existed as a change in Integer>>readFrom:base: ). > > SqueakNumberParser is able to raise an error, but default behavior is rather to answer 0 like previous 3.9 implementation... > > Shouldn't this change in next version 3.10 or 4.0 ? What I'd be more interested in is why the error-raising condition in 3.8 (which is clearly correct!) got removed in 3.9. Unfortunately (sigh) there is no method history in 3.9 (double-sigh) and neither change set information to find out how this was introduced (triple-sigh). Cheers, - Andreas |
|
|
In reply to this post by Nicolas Cellier-3
<[hidden email]> wrote:
> I did not concentrate enough on Frank Shearar message. > He got it right. > > Color>>formString: implementationrely on the fact that an error is generated. > > '16rYELLOW' asNumber did generate a bug in 3.8, no more in 3.9. > > Note that this is half lucky, because in many cases, String>>asNumber is very permissive. > '' asNumber = 0 > '16r' asNumber = 0 > '16rX' asNumber ERROR Yes, and '16rEX' asNumber = 14. So #fromString: splits 'orange' into 'or' (which is 0, according to #asNumber), 'an' (or 10') and 'ge' (or 0). Perhaps the thing to do is to change the condition to [aColorHex isColorTriple ifTrue: [aColorHex _ aColorHex asUppercase. ... where String>>isColorTriple looks like isColorTriple self do: [c: | c isHex ifFalse: [^ false]]. ^(self size = 6). and Character>>isHex is defined appropriately. frank |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |