December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] ConfigurationOfPetitParser has broken #'common' section

by Nicolas Cellier

Oh, I see a minimal Petit... But isn't that going to be too small? Alternatively why not a ConfigurationOfGrosParser ? Nicolas 2012/12/4 Camillo Bruni <camillobruni(a)gmail.com>: > just load the minimal group and you're fine. That's what we do in 2.0 as well... > > > On 2012-12-04, at 18:32, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> By "broken" I mean "it might work fine in Pharo but it doesn't in Squeak". >> >> That's because PetitParser now uses Glamour, which pulls in a whole >> host of things that probably don't work in Squeak. (I don't know, I >> haven't tried, but these are all UI things, and the UI is where Pharo >> and Squeak are least compatible.) >> >> I'm being a bit rude in that I don't yet have a fix for the issue. >> Ideally, a ConfigurationOf would have Pharo specific stuff and Squeak >> specific stuff in separate sections, with only the shared things >> (right now, not Glamour, nor its dependents) in the #'common' section. >> >> However, if someone doesn't beat me to it, I'll submit a fix soon, >> once Squeak 4.4 is out the door. >> >> frank >> > >

Dec. 4, 2012

Re: [Pharo-project] ConfigurationOfPetitParser has broken #'common' section

by Camillo Bruni

just load the minimal group and you're fine. That's what we do in 2.0 as well... On 2012-12-04, at 18:32, Frank Shearar <frank.shearar(a)gmail.com> wrote: > By "broken" I mean "it might work fine in Pharo but it doesn't in Squeak". > > That's because PetitParser now uses Glamour, which pulls in a whole > host of things that probably don't work in Squeak. (I don't know, I > haven't tried, but these are all UI things, and the UI is where Pharo > and Squeak are least compatible.) > > I'm being a bit rude in that I don't yet have a fix for the issue. > Ideally, a ConfigurationOf would have Pharo specific stuff and Squeak > specific stuff in separate sections, with only the shared things > (right now, not Glamour, nor its dependents) in the #'common' section. > > However, if someone doesn't beat me to it, I'll submit a fix soon, > once Squeak 4.4 is out the door. > > frank >

Dec. 4, 2012

[Pharo-project] ConfigurationOfPetitParser has broken #'common' section

by Frank Shearar

By "broken" I mean "it might work fine in Pharo but it doesn't in Squeak". That's because PetitParser now uses Glamour, which pulls in a whole host of things that probably don't work in Squeak. (I don't know, I haven't tried, but these are all UI things, and the UI is where Pharo and Squeak are least compatible.) I'm being a bit rude in that I don't yet have a fix for the issue. Ideally, a ConfigurationOf would have Pharo specific stuff and Squeak specific stuff in separate sections, with only the shared things (right now, not Glamour, nor its dependents) in the #'common' section. However, if someone doesn't beat me to it, I'll submit a fix soon, once Squeak 4.4 is out the door. frank

Dec. 4, 2012

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

by Marcus Denker

On Dec 4, 2012, at 7:45 PM, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > On Tue, Dec 4, 2012 at 6:30 AM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > 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. > True, to a point. As long as later coders that alter the method/class/package either adhear to the original comments, or update the comments when they change the behaviour/intent of the code, or at the very least, delete the comment when they make significant changes that would invalidate the comment, this is true. If, on the other hand, the comments are left as is while potentially drastic changes are made, then the comments become seriously misleading. > > Not to say comments are bad - but we must all work to make sure the comments that exist stay relevant. > And of course it is important to actually change comments when someone finds a problem. "How can you change the world if you can't even change a typo in a comment?" Marcus

Dec. 4, 2012

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

by Chris Cunningham

On Tue, Dec 4, 2012 at 6:30 AM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > 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. > True, to a point. As long as later coders that alter the method/class/package either adhear to the original comments, or update the comments when they change the behaviour/intent of the code, or at the very least, delete the comment when they make significant changes that would invalidate the comment, this is true. If, on the other hand, the comments are left as is while potentially drastic changes are made, then the comments become seriously misleading. Not to say comments are bad - but we must all work to make sure the comments that exist stay relevant. -Chris

Dec. 4, 2012

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