- Pharo-dev - lists.pharo.org

[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

[Pharo-project] Why TTComposite is a subclass of TTGlyph
by StÃ©phane Ducasse June 8, 2009

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

Ce truc pourrait t'intÃ©resser pour tracer tes arbres de gÃ©nÃ©alogie: http://thejit.org/

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

Re: [Pharo-project] About super initialize
by Christian Haider June 8, 2009

June 8, 2009

I would get rid of these #initialize methods and use lazy initialization instead. Simple redefinitions in subclasses, no worries. Cheers, Christian > -----UrsprÃ¼ngliche Nachricht----- > Von: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] Im > Auftrag von StÃ©phane Ducasse > Gesendet: Montag, 8. Juni 2009 18:15 > An: Pharo Development > Betreff: [Pharo-project] About super initialize > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

2 1

June 8, 2009

Hi mike when we copy and paste from other environment we get a problem: we get a box instead of the correct CR. Do you know what should be done? Stef

2 2