- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Some Object methods that could be removed ?

by Sven Van Caekenberghe

On 04 Dec 2012, at 17:48, Marcus Denker <marcus.denker(a)inria.fr> wrote: > On Dec 4, 2012, at 5:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi Guys, >> >> Here are 4 Object methods that could maybe be removed, right ? >> >> Object>>#xxxClass >> >> no real senders except MethodFinder >> > this is not needed anymore as #class now is always send (no special byte code). > >> Object>>#identityHashPrintString >> >> 1 senders except MethodFinder >> can easily be moved to caller, not generally useful >> we have no #hashPrintString either >> > remove > >> Object>>#mouseUpBalk >> >> a does nothing hook, no other implementors >> only two senders, looks like being related to debugging >> > yes, should be removed. > >> Object>>#windowReqNewLabel: >> >> a hook that returns true, no other implementors >> only one sender (SystemWindow>>#relabel), looks like seeing any object as model >> > yes. > >> The last two could be changed to a conditional perform if we want to keep the hooks. > If in doubt, just remove :-) > >> If there are no objections, I could produce a slice (or slices). >> > > yes! http://code.google.com/p/pharo/issues/detail?id=7094

Dec. 4, 2012

Re: [Pharo-project] [[ false ] whileFalse: [ ]] in workspace

by Guillermo Polito

Done :) On Tue, Dec 4, 2012 at 8:46 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > can you just put in in the issue tracker? I have no time right nowâ¦ but > mails are such bad TODO trackersâ¦ > > On Dec 2, 2012, at 10:42 PM, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi! > > I've hacked a fix, but I don't know if it is correct... can somebody check > it so I make a Slice? > > Guille > > On Sun, Dec 2, 2012 at 8:56 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Ok, I've found the cause :). >> >> From update 20043: >> >> Issue 5744: Clean up Temp Embedding 2): DoIts >> http://code.google.com/p/pharo/issues/detail?id=5744 >> >> >> - Doits are now compiled with source embedded >> - embedding sources for doits pretty prints from AST as doits are >> compiled specially (with a return added) >> >> CompiledMethod: >> >> - remove blockExtendsToTempsMap: Not needed anymore, all calls go the >> MethodNode >> - remove #copyWitTempsFromMethodNode: All senders use #copyWithSource >> - remove #holdsTempNames. Temp name embedding not needed >> - add isDoit >> - schematicTempNamesString always returns the schematic string >> representation of all temps >> - tempNames forwards to methodNode >> - remove tempNamesString. Concatenate yourself if you need that. >> >> Debugger>>selectedMessage asks the selectedContext directly for the >> source. No need for the methodMap. >> >> DebuggerMethodMap >> >> - no special handling of methods that encode temps. Just as for >> methodNode always. >> >> MethodNode >> >> - generateWithSource. embedd pretty printed code in case of doit >> - remove generateWithTempNames >> >> In general: rewrite code to use #generateWithSource >> >> >> On Sat, Dec 1, 2012 at 6:24 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Sebastian >>> >>> I can tell you that what you did is **useful** because we are all >>> working like mad >>> and such kind of help is really welcome. >>> >>> Stef >>> >>> On Dec 1, 2012, at 3:24 PM, Sebastian Nozzi wrote: >>> >>> > It's the #7076. >>> > >>> > 2012/11/29 Camillo Bruni <camillobruni(a)gmail.com>: >>> >> perfect! can you open a bug report with this information? :) >>> > >>> >>> >>> >> > <MessageNode.GuillermoPolito.cs> > > >

Dec. 4, 2012

Re: [Pharo-project] Some Object methods that could be removed ?

by Camillo Bruni

On the same topic. Do we have a VM that marks methods as they are executed? We should really do a cleaning session by running an image for a week or so and remove all methods that are unused!

Dec. 4, 2012

Re: [Pharo-project] Some Object methods that could be removed ?

by Marcus Denker

On Dec 4, 2012, at 5:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Guys, > > Here are 4 Object methods that could maybe be removed, right ? > > Object>>#xxxClass > > no real senders except MethodFinder > this is not needed anymore as #class now is always send (no special byte code). > Object>>#identityHashPrintString > > 1 senders except MethodFinder > can easily be moved to caller, not generally useful > we have no #hashPrintString either > remove > Object>>#mouseUpBalk > > a does nothing hook, no other implementors > only two senders, looks like being related to debugging > yes, should be removed. > Object>>#windowReqNewLabel: > > a hook that returns true, no other implementors > only one sender (SystemWindow>>#relabel), looks like seeing any object as model > yes. > > The last two could be changed to a conditional perform if we want to keep the hooks. > If in doubt, just remove :-) > If there are no objections, I could produce a slice (or slices). > yes! > Sven > > BTW, What did Nautilus eat recently ? Browsing Object now opens immediatlely ;-) > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Dec. 4, 2012

Re: [Pharo-project] Some Object methods that could be removed ?

by Camillo Bruni

Go for it!! :) (though I am not a reliable source to represent the users of these methods) On 2012-12-04, at 12:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Guys, > > Here are 4 Object methods that could maybe be removed, right ? > > Object>>#xxxClass > > no real senders except MethodFinder > > Object>>#identityHashPrintString > > 1 senders except MethodFinder > can easily be moved to caller, not generally useful > we have no #hashPrintString either > > Object>>#mouseUpBalk > > a does nothing hook, no other implementors > only two senders, looks like being related to debugging > > Object>>#windowReqNewLabel: > > a hook that returns true, no other implementors > only one sender (SystemWindow>>#relabel), looks like seeing any object as model > > > The last two could be changed to a conditional perform if we want to keep the hooks. > > If there are no objections, I could produce a slice (or slices). > > Sven > > BTW, What did Nautilus eat recently ? Browsing Object now opens immediatlely ;-) I think this was my hack to not show the "all" category :P so technically it is not faster :P but I tricked you in believing so..

Dec. 4, 2012

[Pharo-project] Some Object methods that could be removed ?

by Sven Van Caekenberghe

Hi Guys, Here are 4 Object methods that could maybe be removed, right ? Object>>#xxxClass no real senders except MethodFinder Object>>#identityHashPrintString 1 senders except MethodFinder can easily be moved to caller, not generally useful we have no #hashPrintString either Object>>#mouseUpBalk a does nothing hook, no other implementors only two senders, looks like being related to debugging Object>>#windowReqNewLabel: a hook that returns true, no other implementors only one sender (SystemWindow>>#relabel), looks like seeing any object as model The last two could be changed to a conditional perform if we want to keep the hooks. If there are no objections, I could produce a slice (or slices). Sven BTW, What did Nautilus eat recently ? Browsing Object now opens immediatlely ;-) -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 4, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by Henrik Sperre Johansen

On 04.12.2012 12:49, StÃ©phane Ducasse wrote: > Comments are ***REEEAALLLLY*** important because they help a guy reading the code to say yes you are smart and you got it right > I will explain you why. > > Even writing comment in test is cool. > > Stef I would go so far as to say comments in tests are *especially* important. It's sometimes hard to tell whether a failure is due to a faulty test, or an actual bug, when you have no idea (even when looking at the code) what case the test was actually written to cover. With a comment of what the test was intended to do, you have a better feel for how to handle it. TL;DR: Intent, while obvious to whoever is writing the test, may not be so clear to whoever is around when it starts failing. Cheers, Henry

Dec. 4, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by Sebastian Nozzi

2012/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Comments are ***REEEAALLLLY*** important because they help a guy > reading the code to say "yes, you are smart and you got it right" +1 Never thought about it that way... documentation as a confirmation of what is intuitive...

Dec. 4, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by Sebastian Nozzi

I am fully for automating whatever can be automated. In this sense tests are a good combination of: * automated quality-control * sample-code Often there is no good way, for somebody new to a codebase, to distinguish between these two kinds of tests. There are tests that can be looked at like "runnable specifications" or "sample usage code". And there are tests that more about the nuts and bolts of a framework. Relevant to developers/maintainers of a package, but not for a potential user (yet). Solutions for this? Maybe categorizing tests accordingly... ? Either through packages/method-categories, or pragmas? I am also glad whenever I find an "example" method-category for a core class in a package. My 2 cents. 2012/12/4 Sven Van Caekenberghe <sven(a)stfx.eu>: > What makes me value tests a bit above documentation (but not so much > that I am saying that documentation is not important), are two things: > > - tests are machine enforceable/controllable > - you can find them exactly using senders or references

Dec. 4, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by Sven Van Caekenberghe

But I think we do agree ;-) What makes me value tests a bit above documentation (but not so much that I am saying that documentation is not important), are two things: - tests are machine enforceable/controllable - you can find them exactly using senders or references On 04 Dec 2012, at 12:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Comments are ***REEEAALLLLY*** important because they help a guy reading the code to say yes you are smart and you got it right > I will explain you why. > > Even writing comment in test is cool. > > Stef > >> Well written: >> >> http://kennethreitz.org/open-source-and-constraints.html >> >> I also find that writing documentation (minimal method/class comments or longer standalone documents) improves coding, because you take another perspective. I wouldn't value it above tests though. >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >

Dec. 4, 2012