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

Re: [Pharo-project] Call for suggestions: Morph has 997 methods

by StÃ©phane Ducasse

On Jun 7, 2009, at 10:02 PM, Schwab,Wilhelm K wrote: > Stef, > > One interesting idea that I saw mentioned a long time ago was to > create a new set of classes that use DNU as a prompt to grab the > missing method from the corresponding morph class. After a while, > it should converge on a minimal set of methods, at least as written. I did it :) But it crashed. I did the same with mw and I got 600 methods when opening and closing methods. > Another thing: the Guzdial and Rose book contains "Back to the > Future Once More" that contains a statement of intent to replace > morphic with something better. I further recall some mention of > replacing morphic's use of global coordinates with morph-local > coordinates, though I do not recall where I read that. yes but we need a good soul to implement it: lessphic But first cleaning unused or not useful would be also good. stef

June 7, 2009

Re: [Pharo-project] Call for suggestions: Morph has 997 methods

by Schwab,Wilhelm K

Stef, One interesting idea that I saw mentioned a long time ago was to create a new set of classes that use DNU as a prompt to grab the missing method from the corresponding morph class. After a while, it should converge on a minimal set of methods, at least as written. Another thing: the Guzdial and Rose book contains "Back to the Future Once More" that contains a statement of intent to replace morphic with something better. I further recall some mention of replacing morphic's use of global coordinates with morph-local coordinates, though I do not recall where I read that. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Sunday, June 07, 2009 2:44 PM To: Pharo Development Subject: [Pharo-project] Call for suggestions: Morph has 997 methods Hi guys It would be great if we could assess Morphic fat. I think that with 997 methods not counting the MorphExtension class, we should be able to clean Morph and friend. So if you see passing unused, useless, broken Morph code please report it Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 7, 2009

Re: [Pharo-project] an odd bug

by StÃ©phane Ducasse

so is there a fix? Stef On Jun 4, 2009, at 11:07 PM, Hernan Wilkinson wrote: > yes, but not only that... I also create "complete objects" from its > very first time. For example, instead of: > Date new day:1; moth:1; year: 2009. > I do: > Date newDay: 1 moth: 1 year: 2009. > > That way you will never have an invalid Date > > 2009/6/4 Steve Wirts <stevewirts(a)gmail.com> > That's the Null Object Pattern! > > http://en.wikipedia.org/wiki/Null_Object_pattern > > > 2009/6/4 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > > I was going to suggest exactly that. > As a rule, I never use nil because if you do it you will have to > check for it somewhere... nil is the root of most of the problems! > if not, look at all the errors I fixed in the other mail, most of > them are because nil is being used. > So, instead of nil, another object has to be use, and like you said > in this case an empty collection I think will work. I'm just > changing that... I'll send the changes today (I hope). > > Hernan. > > > On Thu, Jun 4, 2009 at 11:32 AM, Michael Rueger <m.rueger(a)acm.org> > wrote: > Sean Allen wrote: > > > Just as a bit more info. I used squeak for several months without > ever > > seeing this error. > > I used pharo for 3 months without seeing this error. I've only > gotten > > this error in the latest images > > with the latest vm and get it constantly. Not occassionally, I can > get > > this to happen at least > > once every 120 seconds or so, sometimes more often. It would seem > to be > > as an outsider, > > that something must have changed. > > it definitely sounds like it. > Would be good to investigate what might have changed in the call path > that *sets* the variable to check why it is ending up being nil. Maybe > it shouldn't be set or initialized to nil but to an empty collection > in > those cases? > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 7, 2009

[Pharo-project] Call for suggestions: Morph has 997 methods

by StÃ©phane Ducasse

Hi guys It would be great if we could assess Morphic fat. I think that with 997 methods not counting the MorphExtension class, we should be able to clean Morph and friend. So if you see passing unused, useless, broken Morph code please report it Stef

June 7, 2009

Re: [Pharo-project] swapMouseButtons doesn't work

by Adrian Lienhard

In issue #838 I changed the implementation to be platform specific as follows: swapMouseButtons ^ self valueOfFlag: #swapMouseButtons ifAbsent: [ OSPlatform current platformFamily ~= #Windows ] which means that for Unix swapping is enabled (returns true). If I understand you correctly, however, for Unix it should be disabled. Is this correct? So the correct implementation would be to test for OSPlatform current platformFamily = #Mac (or similar) Adrian On Jun 7, 2009, at 19:08 , Mariano Martinez Peck wrote: > 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 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 7, 2009

[Pharo-project] swapMouseButtons doesn't work

by Mariano Martinez Peck

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

June 7, 2009

Re: [Pharo-project] Citezen loading (Rio-Kernel defect)

by Damien Pollet

On Sun, Jun 7, 2009 at 15:20, Lukas Renggli<renggli(a)gmail.com> wrote: > that it doesn't matter much speed-wise what kind of parser you pick. > LR parser are probably not that much of a hype anymore ;-) Well, at least parsing scg.bib should be acceptably quick. Currently it's slow enough that a progress bar would make sense :) I quickly went through the code in Helvetia when you announced it. I'll have a look for Citezen, but unfortunately I'm going to be quite busy until July. So in the meantime, if anyone has ideas, please go for it, the repository is open. I will probably re-enter Citezen for the ESUG awards, and try to actually get something to show this time. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

June 7, 2009

Re: [Pharo-project] Citezen loading (Rio-Kernel defect)

by Lukas Renggli

>> But a more robust and forgiving parser is needed. > > Well at least it would be nice if it could report errors, but that's a > pain to do with LR parsers. SmaCC can report errors. I guess for Citezen something that can silently parse across errors is needed. Something that builds an as complete as possible model from input that is not necessarily entirely valid. I suggest that you have a look at the PetitParser PEG framework (http://source.lukas-renggli.ch/petit.html) It uses an object-oriented approach, pure Smalltalk syntax, and comes with an extensive test suite that covers 100% of the code. Ambiguous grammars are supported and you can speed them up using memoization if you want to. > I think I have an OMeta attempt somewhere but it will probably be > slower than SmaCC. Parsing all methods of Object and Morph (1390 methods in total) takes: 688ms with the hand written RBParser, 806ms with the hand written Squeak parser, 2518ms with the pre-compiled and heavy optimized SmaCC parser, 3700ms with the not optimized PetitParser Smalltalk parser I don't know where OMeta would be in this comparison, unfortunately it does only include a parser for Smalltalk expressions. A probably less accurate comparison with just a single expression parser (the factorial function) parsed 1000 times gives: 560ms with the hand written RBParser, 602ms with the hand written Squeak parser, 2564ms with the pre-compiled and heavy optimized SmaCC parser, 4867ms with the not optimized PetitParser Smalltalk parser, 25098ms with the OMeta Smalltalk expression parser I have no idea why OMeta is so slow? Otherwise however, I conclude that it doesn't matter much speed-wise what kind of parser you pick. LR parser are probably not that much of a hype anymore ;-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

June 7, 2009

Re: [Pharo-project] can we remove TabbedPalette

by StÃ©phane Ducasse

I should get some time later today (right now painting painting painting the kitchen :), cutting our garden edge...). so read and write some stuff too. Stef On Jun 6, 2009, at 10:51 PM, Alain Plantec wrote: > in pharoInbox: SLICE-TabbedPaletteRemoval-alain_plantec.4 > > alain > > StÃ©phane Ducasse a Ã©crit : >> >> On Jun 5, 2009, at 10:17 PM, Alain Plantec wrote: >> >>> Hi all, >>> I know it is used by the Smacc GUI. >>> I can provide a new Smacc GUI implementation (old one is really >>> messy) >>> any other good reason to keep TabbedPalette ? >> >> no >> Lukas already proposed a new UI for Smacc I believe. >> >> Stef >>> >>> thanks >>> Alain >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 7, 2009

Re: [Pharo-project] ObjectFinder

by Frederic Pluquet

> > > Not at first look but when you play with the finder, it becomes clear :) > Great work, very neat tool. > Thank you :) > > One minor improvment: > Let's say I have two panes A and B. In pane A, I have a list of > CompiledMethod and I select Object#= > Then the code for Object#= is displayed in the bottom pane, and pane B is > filled with field values of the CompiledMethod instance. > > Then if I play with the buttons in pane B to get the > senders/implementors/messages for Object#=, the bottom pane is cleared. > I feel like it should still displayed the current selection (in pane A) > until I make another selection. > Good idea. I will try to implement it. FrÃ©d

June 7, 2009