April 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo freezing ...

by StÃ©phane Ducasse

Do the inverse :) - send us a description vm number image number and step list once we ack add it as report. Else I will be flooded by bug item that we should close because with not enough info. On Apr 19, 2009, at 11:25 AM, Damien Cassou wrote: > On Sun, Apr 19, 2009 at 12:06 AM, stepken <stepken(a)web.de> wrote: >> >> http://code.google.com/p/pharo/wiki/SmallLintPharoFixing >> >> While filtering with SmallLint Pharo freezes (Windows version). >> >> I think, there is elementary something going wrong there ... design >> problem? >> >> Maybe that's the same bug, that made Seaside suddenly freeze? > > Could you please open an issue and report the exact steps to reproduce > the problem? > > Thank you > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2009

Re: [Pharo-project] Some visual artifacts in buttons (Watery 2 theme)

by StÃ©phane Ducasse

for UI glitch also put gazzaguru in the cc box. :) stef On Apr 19, 2009, at 3:39 PM, Igor Stasenko wrote: > 2009/4/19 Damien Cassou <damien.cassou(a)gmail.com>: >> Please report an issue on the issue tracker. >> > #755 > >> 2009/4/19 Igor Stasenko <siguctua(a)gmail.com>: >>> Hello, >>> just in case if you not already seen it.. >>> These artifacts (a button labels blended with background) is appear >>> only, when you draggin a morph in hand. >>> If you just place morph over background - no visible artifacts >>> appear. >>> >>> On screenshot, the button label is blended with Pharo logo, placed >>> on >>> background. It seems like somewhere, it not sets an opacity values >>> correctly for button labels, which allows you to see through the >>> cached form (which used when you dragging morph in hand). >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2009

Re: [Pharo-project] SqueakMap Package Loader?

by StÃ©phane Ducasse

yes so this is still interesting to know whether it is broken as an external package. On Apr 19, 2009, at 2:25 PM, Adrian Lienhard wrote: > > On Apr 18, 2009, at 20:18 , Markus Fritsche wrote: > >> I just tried to start a SM Package loader which issued a dnu. Is it >> my image >> or is ImageSegment broken? >> >> Is SM deprecated? It seems so in the official squeak distribution... > > Our plan is to remove SM from Pharo core and treat it as an external > package (IIRC Keith already provided means to load it). > > Adrian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2009

Re: [Pharo-project] Nile and pharo?

by StÃ©phane Ducasse

Thanks. too bad. May be damien will have a look at nile. I just drove 10 hours today and I'm dead :) On Apr 19, 2009, at 3:05 AM, Markus Fritsche wrote: > StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Thanks markus. It is probably related to the point alex raised. >> Since now >> traits do not share their methods it may happen that a conflict >> arise when >> it should not. Could you do me a favor and load the fixes proposed >> by alex >> that he published in the Traits project on squeaksource. And redo >> your >> experiment this way we may learn something. > > The two methods from 04/15? I did, but that didn't change the test > status... > > regards, Markus > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2009

Re: [Pharo-project] Lots of characters lost while typing in Unix

by StÃ©phane Ducasse

Yes may be the event cleaning of mike cleaned too much. So I hope that mike will provide a fix soon :) Stef On Apr 19, 2009, at 5:01 PM, Nicolas Cellier wrote: > Since latest 10284 Pharo update, i experience lost of keystroke > vanishing. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2009

[Pharo-project] Lots of characters lost while typing in Unix

by Nicolas Cellier

Since latest 10284 Pharo update, i experience lost of keystroke vanishing.

April 19, 2009

Re: [Pharo-project] [squeak-dev] Fwd: A little font rendering speedup

by Igor Stasenko

A more deeper analysis shows, that it looks like things around characterToGlyphMap is either incomplete, or over-engineered. By looking through all characterToGlyphMap uses, most methods simply assigns nil to it. The only method which would assign something different is HostFont>>#fontName:size:emphasis:rangesArray: in [ characterToGlyphMap := self isoToSqueakMap ] but what a surprise! it implemented as following: isoToSqueakMap ^nil IMO character to glyph mapping for strike fonts is redundant, because you can simply remap the xTable to achieve same effect. Also, since Pharo fully supports FreeType, doesn't it makes a HostFont a candidate to wipe out? If so, then i would really recomment to ignore characterToGlyphMap for displaying ByteString(s) and use single class var which holds an identity mapping for ascii chars. This is, of course just to make a primitiveDisplayString happy. A more aggressive way would be to rewrite this primitive and remove the characterToGlyphMap argument from use. 2009/4/19 Adrian Lienhard <adi(a)netstyle.ch>: > Thanks, Igor, > > I created an entry in the Pharo tracker with a link to the Mantis > entry to allow us to keep track of its integration into Pharo. > > http://code.google.com/p/pharo/issues/detail?id=758 > > Cheers, > Adrian > > > http://code.google.com/p/pharo/issues/detail?id=758 > On Apr 19, 2009, at 15:36 , Igor Stasenko wrote: > >> I put this on mantis, since i'm sure this applies to squeak3.10 and >> Pharo both. >> >> http://bugs.squeak.org/view.php?id=7338 >> >> >> ---------- Forwarded message ---------- >> From: Igor Stasenko <siguctua(a)gmail.com> >> Date: 2009/4/19 >> Subject: A little font rendering speedup >> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >> >> >> This is an image-side change, which makes a primitiveDisplayString to >> not fail because StrikeFontSet returns nil for (font >> characterToGlyphMap). >> >> Since the code, which using fast primitive looks like following: >> >> Â Â Â Â self primDisplayString: aString from: startIndex to: stopIndex >> Â Â Â Â Â Â Â Â Â Â Â Â map: font characterToGlyphMap xTable: font >> xTable >> Â Â Â Â Â Â Â Â Â Â Â Â kern: kernDelta >> >> I thought, why one would return nil in ( font characterToGlyphMap ). >> Since #xTable in StrikeFontSet implemented as following: >> >> xTable >> Â Â Â Â "Answer an Array of the left x-coordinate of characters in >> glyphs." >> >> Â Â Â Â ^ (fontArray Â at: 1) xTable. >> >> i think it is safe to do similar in characterToGlyphMap , >> this allows the primitive to work w/o failure, because otherwise, if >> you look at implementation of >> >> primDisplayString: aString from: startIndex to: stopIndex map: >> glyphMap xTable: xTable kern: kernDelta >> >> in fallback code it does same thing again (and ignoring glyphMap at >> all, btw). >> >> >> To bench a difference, leave a couple of windows with text in world >> and then do: >> >> [10 timesRepeat: [World fullDrawOn: World assuredCanvas] ] timeToRun >> >> before change: >> >> Â 645 >> >> after change: >> >> Â 545 >> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> <StrikeFontSet-characterToGlyphMap.st> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 19, 2009

[Pharo-project] Infinite loop in Monticello MCWorkingCopy needsSavings

by Nicolas Cellier

Did anyone experimented an Infinite loop in Monticello MCWorkingCopy needsSavings ? I had a SLICE previously saved. I added a new required pakage dependency to this SLICE. I tried to save again -> InfiniteLoop...

April 19, 2009

Re: [Pharo-project] Pharo freezing ...

by Lukas Renggli

Is this a closure image you observe these freezes? Cheers, Lukas On Sun, Apr 19, 2009 at 11:25 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Sun, Apr 19, 2009 at 12:06 AM, stepken <stepken(a)web.de> wrote: >> >> http://code.google.com/p/pharo/wiki/SmallLintPharoFixing >> >> While filtering with SmallLint Pharo freezes (Windows version). >> >> I think, there is elementary something going wrong there ... design problem? >> >> Maybe that's the same bug, that made Seaside suddenly freeze? > > Could you please open an issue and report the exact steps to reproduce > the problem? > > Thank you > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

April 19, 2009

Re: [Pharo-project] [squeak-dev] Fwd: A little font rendering speedup

by Adrian Lienhard

Thanks, Igor, I created an entry in the Pharo tracker with a link to the Mantis entry to allow us to keep track of its integration into Pharo. http://code.google.com/p/pharo/issues/detail?id=758 Cheers, Adrian http://code.google.com/p/pharo/issues/detail?id=758 On Apr 19, 2009, at 15:36 , Igor Stasenko wrote: > I put this on mantis, since i'm sure this applies to squeak3.10 and > Pharo both. > > http://bugs.squeak.org/view.php?id=7338 > > > ---------- Forwarded message ---------- > From: Igor Stasenko <siguctua(a)gmail.com> > Date: 2009/4/19 > Subject: A little font rendering speedup > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > > > This is an image-side change, which makes a primitiveDisplayString to > not fail because StrikeFontSet returns nil for (font > characterToGlyphMap). > > Since the code, which using fast primitive looks like following: > > self primDisplayString: aString from: startIndex to: stopIndex > map: font characterToGlyphMap xTable: font > xTable > kern: kernDelta > > I thought, why one would return nil in ( font characterToGlyphMap ). > Since #xTable in StrikeFontSet implemented as following: > > xTable > "Answer an Array of the left x-coordinate of characters in > glyphs." > > ^ (fontArray at: 1) xTable. > > i think it is safe to do similar in characterToGlyphMap , > this allows the primitive to work w/o failure, because otherwise, if > you look at implementation of > > primDisplayString: aString from: startIndex to: stopIndex map: > glyphMap xTable: xTable kern: kernDelta > > in fallback code it does same thing again (and ignoring glyphMap at > all, btw). > > > To bench a difference, leave a couple of windows with text in world > and then do: > > [10 timesRepeat: [World fullDrawOn: World assuredCanvas] ] timeToRun > > before change: > > 645 > > after change: > > 545 > > > > > -- > Best regards, > Igor Stasenko AKA sig. > <StrikeFontSet-characterToGlyphMap.st>

April 19, 2009