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

[Pharo-project] About super initialize
by StÃ©phane Ducasse June 9, 2009

June 9, 2009

Hi in http://code.google.com/p/pharo/issues/detail?id=135 may be stupidly I was thinking that it would be nice to check all the initialize methods that are not doing a super call, and fix them. Alain did this crazy and boring tasks and I was reviewing his code. Now I was wondering if it makes sense to add super initialize to the direct subclasses of Object. I have the impression that it is good for uniformity but we are calling an empty so we could do the following only fix the caller that are not subclasses of Object. What is your point of view, stef

6 12

[Pharo-project] Fwd: Issue 584 in pharo: SqueakPageCache generateURL -> DNU because pathForFile is not defined on ServerFile
by StÃ©phane Ducasse June 9, 2009

June 9, 2009

I would be inclined to say that we should remove SqueakPageCache but what the other think? SqueakPageCache is a cache for Morph sved on disc and that can be reloaded Begin forwarded message: > From: codesite-noreply(a)google.com > Date: June 5, 2009 10:53:23 PM CEDT > To: stephane.ducasse(a)gmail.com > Subject: Issue 584 in pharo: SqueakPageCache generateURL -> DNU > because pathForFile is not defined on ServerFile > > > Comment #2 on issue 584 by alain.pl...(a)free.fr: SqueakPageCache > generateURL -> DNU because pathForFile is not defined on ServerFile > http://code.google.com/p/pharo/issues/detail?id=584 > > so do we remove SqueakPage (#issue 477) or not ? > > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings

4 8

[Pharo-project] [ANN] Morph dirty methods rewrite
by Gabriel Cotelli June 9, 2009

June 9, 2009

Name: Morphic-GabrielOmarCotelli.326 Author: GabrielOmarCotelli Time: 9 June 2009, 10:31:46 am UUID: dc1de612-41c5-b942-ac37-d4841ac4917d Ancestors: Morphic-GabrielOmarCotelli.325 Rewrite of: TransformMorph >> numberOfItemsPotentiallyInViewWith: PluggableListMorph >> numSelectionsInView WorldState class >> deferredExecutionTimeLimit WorldState >> runStepMethodsIn: Please review... Thanks, Gabriel

1 0

[Pharo-project] what happened to pretty-print?
by Oscar Nierstrasz June 9, 2009

June 9, 2009

The pretty-print function seems to have disappeared. This is a real nuisance, since copying and pasting code from outside to inside an image usually messes it up (on Mac OSX anyway). Is there a way to reactive pretty printing? Or is there a way to get copy-paste to do the right thing whether they contain linefeeds or carriage returns? - on

3 10

[Pharo-project] Logging package does not compile
by FranÃ§ois Tanguy June 9, 2009

June 9, 2009

Hello, did anyone ever tried to load the "Logging" package from Keith Hodges ? http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-December/132923… In pharo, the following method does not compile. testFilter: aMessage | lowerString | lowerString := aMessage value value asLowercase. ^(self searchString asString substrings allSatisfy: [:sub | sub := (sub asLowercase) replaceAll: $_ with: (Character space). ((sub first = $-) and: [(lowerString includesSubString: sub allButFirst) not]) or: [(sub first = $+) and: [lowerString includesSubString: sub allButFirst]] or: [lowerString includesSubString: sub]]) It is easy to fix by using an extra variable. My question, should we ask Keith to fix this method so that this package would be "pharo loadable" ? FranÃ§ois

3 3

[Pharo-project] Pharo Inbox Conflict
by Gabriel Cotelli June 9, 2009

June 9, 2009

Hi, I rewrite the following Morph methods: TransformMorph >> numberOfItemsPotentiallyInViewWith: PluggableListMorph >> numSelectionsInView WorldState class >> deferredExecutionTimeLimit WorldState >> runStepMethodsIn: but when I try to upload to Pharo Inbox I get the attached warning.. (see attached file) Should I proceed with the saving? My version is also numbered 325 but with different author Thanks, Gabriel

2 1

[Pharo-project] swapMouseButtons doesn't work
by Mariano Martinez Peck June 9, 2009

June 9, 2009

Hi folks: I had an Pharo 10318 and then updat to 10328 in Linux and swapMouseButtons seems to be wrong. For the "right button" I have to press the mouse wheel button. I tried this things: Preferences setPreference: #swapMouseButtons toValue: true. Preferences setPreference: #swapMouseButtons toValue: false. Preferences enable: #swapMouseButtons. Preferences disable: #swapMouseButtons. InputSensor swapMouseButtons: false. InputSensor swapMouseButtons: true. No one do nothing. I saw http://code.google.com/p/pharo/issues/detail?id=838 and seems to be changed in 10319 However, this is not working well in Linux. What I had to do to make it work is this: Rewrite Preferences>>swapMouseButtons to this: swapMouseButtons ^ self valueOfFlag: #swapMouseButtons ifAbsent: [self break. OSPlatform current platformFamily = #Windows ifTrue: [false]. OSPlatform current platformFamily = #Unix ifTrue: [false] ] And then do: InputEventSensor swapMouseButtons: false In addition 10324 dev seems to work ok for me out of the box. Can be a problem of updating from an older version ? What can be the problem? Thanks Mariano

4 7

June 8, 2009

TTGlyph subclass: #TTCompositeGlyph instanceVariableNames: 'glyphs' classVariableNames: '' poolDictionaries: '' category: 'TrueType-Fonts' This class represents a composite TrueType glyph, e.g.one which contains many simple TTGlyphs. Does a TTCompositeGlyph needs all the state from its superclass? Alain I'm going over the super initialize cs now. TTGlyph>>initialize bounds := 0@0 corner: 0@0. contours := #(). advanceWidth := 0. leftSideBearing := 0. rightSideBearing := 0. but in the subclass TTCompositeGlyph>>contours ^contours ifNil:[contours := self computeContours] so if we change the initialize of the subclass then the countours will be never computed.... Stef

2 2

[Pharo-project] Graphs Javascript
by Francois Stephany June 8, 2009

June 8, 2009

3 3

[Pharo-project] Streams - #nextLine
by Schwab,Wilhelm K June 8, 2009

June 8, 2009

Hello all, You might recall my advocating breaking changes to #next, #next: and company: these methods do not behave as advertised, answering nil vs. raising an exception when reading off the back of a stream. It was fairly clear that the will did not exist to make he required changes, so I have put myself on a strict diet of #nextOne, #nextMany:, #nextAvailable: that *do* work as expected. I plan to make code for these methods available to all, and strongly recommend using them. My initial efforts with Citezen have convinced me that I am correct to demand that code function as advertised/expected. I lost a couple of hours trying to sort out whether I was faced with a debugger defect, but ended up finding a source of inconsistency among like-named methods. Look at implementors of #nextLine. First, this is perhaps ambiguous given Pharo's cross-platform nature - it might be wise to always specify CrLf or simply Lf??? Beyond that, some implementations answer nil (why is beyond me, as it leaves callers with two things to check when #notEmpty would otherwise almost always suffice). Any thoughts? If nothing else, I think the various #nextLine methods should behave alike, and as you can tell, I strongly favor answering empty vs. nil. Bill

4 9