February 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.1] #11194

by Yanni Chiu

StÃ©phane Ducasse wrote: > Low stress :) > > Just publish a slice and it will be fixed. > I like alpha/unstable/cutting edge just because we are allowed to break the system :) Yep, breaking the system is okay for now. I just set up my build to track the updates so I could get a heads-up on possible 1.1 issues, while developing on 1.0.

Feb. 5, 2010

Re: [Pharo-project] [update 1.1] #11194

by Yanni Chiu

Henrik Sperre Johansen wrote: >> i<= 128 ifTrue:[ >> NonAsciiMap at: i put: 0. "valid ascii subset" >> ] ifFalse:[ >> NonAsciiMap at: i put: 1. "extended charset" >> >> ]. >> ]. >> >> Notice the "i<= 128" vs. "i< 128". That fixes it, but now the concept >> of NonAsciiMap is wrong. I'm not sure what the final fix should be. >> >> > No, that's me making an off-by-one error :S > The i <= 128 is correct. Then the comments are misleading, because 128 is in the extended charset.

Feb. 5, 2010

Re: [Pharo-project] [update 1.1] #11194

by StÃ©phane Ducasse

Low stress :) Just publish a slice and it will be fixed. I like alpha/unstable/cutting edge just because we are allowed to break the system :) >>>> >> > For that matter, TextConverter initializeLatin1MapAndEncodings should > probably be reverted as well. > My mind glitched thinking they were the same (which they are for the > case I was looking at, with UTF8), but they're only related. > (I.e. some encodings may or may not have the same mapping as latin1, as > the old initialize method took care to check...) > > Cheers, > Henry > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 5, 2010

Re: [Pharo-project] Diff morphs

by Gary Chambers

Well, it think we'll go with "alternative" then. Still enough space for the, very, long package names (especially with full author names)!. @Doru... I did try with white background colour before posting. Too "in your face" considering it is merely a hint as to what is going on and also not editable. As for divider, there is none... down to border width and layout inset. Needed some, to start with I had none and looked quite bad. Remember, this has to work with all themes too... Regards, Gary ----- Original Message ----- From: "George Herolyants" <george.herolyants(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, February 05, 2010 5:45 PM Subject: Re: [Pharo-project] Diff morphs > Thanks a lot, Gary! I like alternative layout. > > George > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 5, 2010

Re: [Pharo-project] Diff morphs

by George Herolyants

Thanks a lot, Gary! I like alternative layout. George

Feb. 5, 2010

Re: [Pharo-project] [update 1.1] #11194

by Henrik Sperre Johansen

On 05.02.2010 18:19, Henrik Sperre Johansen wrote: > On 05.02.2010 18:05, Yanni Chiu wrote: > >> StÃ©phane Ducasse wrote: >> >> >>> - Issue 1932: UTF8TextConverter ?? >>> Latin1TextConverter initializeLatin1Encodings. >>> MacRomanTextConverter initializeLatin1Encodings. thanks nicolas/henrik >>> >>> >> I still see the same/similar problem. >> >> Try this code in a PharoCore-1.1-11184-UNSTABLE image: >> >> | latin1 utf8 | >> index := 127. >> latin1 := String with: (Character value: index). >> utf8 := latin1 convertToWithConverter: UTF8TextConverter new. >> >> It works. Then try it with the lastest updates loaded. You should get an >> emergency evaluator. >> >> I changed: >> >> ByteString class>>initialize >> "ByteString initialize" >> | latin1 utf8 | >> NonAsciiMap := ByteArray new: 256. >> >> 1 to: 256 do:[:i| >> i<= 128 ifTrue:[ >> NonAsciiMap at: i put: 0. "valid ascii subset" >> ] ifFalse:[ >> NonAsciiMap at: i put: 1. "extended charset" >> >> ]. >> ]. >> >> Notice the "i<= 128" vs. "i< 128". That fixes it, but now the concept >> of NonAsciiMap is wrong. I'm not sure what the final fix should be. >> >> >> > No, that's me making an off-by-one error :S > The i<= 128 is correct. > > > For that matter, TextConverter initializeLatin1MapAndEncodings should probably be reverted as well. My mind glitched thinking they were the same (which they are for the case I was looking at, with UTF8), but they're only related. (I.e. some encodings may or may not have the same mapping as latin1, as the old initialize method took care to check...) Cheers, Henry

Feb. 5, 2010

Re: [Pharo-project] [update 1.1] #11194

by Henrik Sperre Johansen

On 05.02.2010 18:05, Yanni Chiu wrote: > StÃ©phane Ducasse wrote: > >> - Issue 1932: UTF8TextConverter ?? >> Latin1TextConverter initializeLatin1Encodings. >> MacRomanTextConverter initializeLatin1Encodings. thanks nicolas/henrik >> > I still see the same/similar problem. > > Try this code in a PharoCore-1.1-11184-UNSTABLE image: > > | latin1 utf8 | > index := 127. > latin1 := String with: (Character value: index). > utf8 := latin1 convertToWithConverter: UTF8TextConverter new. > > It works. Then try it with the lastest updates loaded. You should get an > emergency evaluator. > > I changed: > > ByteString class>>initialize > "ByteString initialize" > | latin1 utf8 | > NonAsciiMap := ByteArray new: 256. > > 1 to: 256 do:[:i| > i<= 128 ifTrue:[ > NonAsciiMap at: i put: 0. "valid ascii subset" > ] ifFalse:[ > NonAsciiMap at: i put: 1. "extended charset" > > ]. > ]. > > Notice the "i<= 128" vs. "i< 128". That fixes it, but now the concept > of NonAsciiMap is wrong. I'm not sure what the final fix should be. > > No, that's me making an off-by-one error :S The i <= 128 is correct.

Feb. 5, 2010

Re: [Pharo-project] [update 1.1] #11194

by StÃ©phane Ducasse

Thanks for the feedback stef On Feb 5, 2010, at 6:05 PM, Yanni Chiu wrote: > StÃ©phane Ducasse wrote: >> - Issue 1932: UTF8TextConverter ?? >> Latin1TextConverter initializeLatin1Encodings. >> MacRomanTextConverter initializeLatin1Encodings. thanks nicolas/henrik > > I still see the same/similar problem. > > Try this code in a PharoCore-1.1-11184-UNSTABLE image: > > | latin1 utf8 | > index := 127. > latin1 := String with: (Character value: index). > utf8 := latin1 convertToWithConverter: UTF8TextConverter new. > > It works. Then try it with the lastest updates loaded. You should get an > emergency evaluator. > > I changed: > > ByteString class>>initialize > "ByteString initialize" > | latin1 utf8 | > NonAsciiMap := ByteArray new: 256. > > 1 to: 256 do:[:i| > i <= 128 ifTrue:[ > NonAsciiMap at: i put: 0. "valid ascii subset" > ] ifFalse:[ > NonAsciiMap at: i put: 1. "extended charset" > > ]. > ]. > > Notice the "i <= 128" vs. "i < 128". That fixes it, but now the concept > of NonAsciiMap is wrong. I'm not sure what the final fix should be. > > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 5, 2010

Re: [Pharo-project] Morphic cleaning

by Lukas Renggli

> can you find the sender of + (which is inlined). Yes, the refactoring browser takes these into account. > Why this is that slow in the image and not in RB. > because it does it at the AST level and not scanning all the bytecode? No, reading the source is dead slow. As soon as you have to load the source of each method you can go to the kitchen and fetch a coffee. The algorithm in the image goes to every method and asks it for its senders. Asking for the senders is expensive because it has to iterate through each compiled method. Thus the whole search is O(n^2). The refactoring engine first collects all sent messages in the system. Then it checks for the presence of each method selector in this set. Thus the whole search is O(n). Similarly the refactoring engine can quickly find out if a method is sent but nowhere implemented. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 5, 2010

Re: [Pharo-project] [update 1.1] #11194

by Yanni Chiu

StÃ©phane Ducasse wrote: > - Issue 1932: UTF8TextConverter ?? > Latin1TextConverter initializeLatin1Encodings. > MacRomanTextConverter initializeLatin1Encodings. thanks nicolas/henrik I still see the same/similar problem. Try this code in a PharoCore-1.1-11184-UNSTABLE image: | latin1 utf8 | index := 127. latin1 := String with: (Character value: index). utf8 := latin1 convertToWithConverter: UTF8TextConverter new. It works. Then try it with the lastest updates loaded. You should get an emergency evaluator. I changed: ByteString class>>initialize "ByteString initialize" | latin1 utf8 | NonAsciiMap := ByteArray new: 256. 1 to: 256 do:[:i| i <= 128 ifTrue:[ NonAsciiMap at: i put: 0. "valid ascii subset" ] ifFalse:[ NonAsciiMap at: i put: 1. "extended charset" ]. ]. Notice the "i <= 128" vs. "i < 128". That fixes it, but now the concept of NonAsciiMap is wrong. I'm not sure what the final fix should be. -- Yanni

Feb. 5, 2010