March 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Polymorph fixes

by Gary Chambers

A few fixes on SqueakSource. Polymorph-Widgets-gvc.24 Polymorph-Tools-Diff-gvc.24 Notably: Table layout of submorphs with #shrinkWrap attributes. Themeing of menu item text colours to help Hilaire in his Sugar theme efforts. ThemeSettings integration left for another time... Wrong "sides" for "compare to current" when using diff tools in change sets (versions browser etc.). Prevention of window dragging from submorphs promoted from StandardWindow to SystemWindow (deals with oddities when click-dragging from submorphs... offset would be wrong and window "jumps"). Wrong colours for faded background windows in Watery themes. Fix colours in W2K theme (requires class-side reinitialisation of defaultSettings. Do "UIThemeW2K defaultSettings: nil" before changing theme). Toolbars now Panel-based to adapt to pane colour. DockingBar based menus now deal with mouseFocus correctly. Regards, Gary

March 1, 2010

Re: [Pharo-project] about code formatting in pharo

by Schwab,Wilhelm K

Lukas, File in the attached and then reformat it. I have to admit there has been improvement; at least the comments remain within the cascade of which they were originally a part. Still, they end up out of order with respect to the reformatted code, which is devastating to what I am trying to accomplish. These are directly analogous to the types of comments that sat (in longer cascades) for several years only to save my back side last year. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] Sent: Monday, March 01, 2010 7:47 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo > I'm not complaining; it's simply a fact, and I'm not the only one observing it. Links were given here some time back. Sorry, but this is only a fact if you provide unit tests (or at least a couple of examples) that fail in the latest code base. Otherwise simply nobody cares. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2010

Re: [Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.411.mcz]

by StÃ©phane Ducasse

On Mar 1, 2010, at 9:57 AM, Mariano Martinez Peck wrote: > I saw the issue closed but the message compactAllInstances is not being sent in cleanUnForProduction or cleanUpForRelease. > > should it be ? yes I imagine that I will integrate also all the cleanUp: methods and adapt them to pharo. Stef > > On Sat, Feb 27, 2010 at 4:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I updated it > Thanks anyway because this is good to see people pushing some changes from sqeuak to pharo. > I'm reimplementing my package class right now. > See you later :) > > Stef > > On Feb 27, 2010, at 3:17 PM, Miguel Enrique CobÃ¡ Martinez wrote: > > > El sÃ¡b, 27-02-2010 a las 09:44 +0100, StÃ©phane Ducasse escribiÃ³: > >> :) > >> > >> http://code.google.com/p/pharo/issues/detail?id=2087 > >> > >> :) > > > > :), yes, I was in a hurry and I didn't create a issue, thanks for > > creating it. > > > > Cheers > >> > >> On Feb 27, 2010, at 8:29 AM, Miguel Enrique CobÃ¡ Martinez wrote: > >> > >>> Maybe we can add this to the cleanUpForRelease script. > >>> > >>> Cheers > >>> -- > >>> Miguel CobÃ¡ > >>> http://miguel.leugim.com.mx > >>> > >>> From: commits(a)source.squeak.org > >>> Date: February 26, 2010 6:38:01 PM GMT+01:00 > >>> To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org > >>> Subject: [squeak-dev] The Trunk: Kernel-ar.411.mcz > >>> Reply-To: squeak-dev(a)lists.squeakfoundation.org > >>> > >>> > >>> Andreas Raab uploaded a new version of Kernel to project The Trunk: > >>> http://source.squeak.org/trunk/Kernel-ar.411.mcz > >>> > >>> ==================== Summary ==================== > >>> > >>> Name: Kernel-ar.411 > >>> Author: ar > >>> Time: 26 February 2010, 7:36:40.257 pm > >>> UUID: b69a28db-8475-bc4b-89ed-285ccf3841cd > >>> Ancestors: Kernel-ul.410 > >>> > >>> Add MethodDictionary class>>compactAllInstances to save space in releases. Compacting all MDs in my images saves 600k in image size which isn't bad at all. > >>> > >>> =============== Diff against Kernel-ul.410 =============== > >>> > >>> Item was added: > >>> + ----- Method: MethodDictionary class>>compactAllInstances (in category 'initialization') ----- > >>> + compactAllInstances "MethodDictionary compactAllInstances" > >>> + "Compacts all MethodDictionaries to save space" > >>> + > >>> + | oldInstances newInstances | > >>> + oldInstances := self allInstances. > >>> + newInstances := oldInstances collect:[:md| > >>> + (self new: md size) > >>> + compactCopyFrom: md; > >>> + yourself]. > >>> + oldInstances elementsForwardIdentityTo: newInstances. > >>> + ! > >>> > >>> Item was added: > >>> + ----- Method: MethodDictionary>>compactCopyFrom: (in category 'private') ----- > >>> + compactCopyFrom: sourceMD > >>> + "Copy the contents of source dictionary without growing" > >>> + > >>> + sourceMD keysAndValuesDo:[:key :value| | index | > >>> + index := self scanFor: key. > >>> + (self basicAt: index) ifNotNil:[self error: 'Something is horribly broken']. > >>> + self basicAt: index put: key. > >>> + array at: index put: value. > >>> + tally := tally + 1. > >>> + ]. > >>> + self size = self capacity ifTrue:[self grow]. "grow only if we reach capacity" > >>> + ! > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > 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

March 1, 2010

Re: [Pharo-project] about code formatting in pharo

by Lukas Renggli

> I'm not complaining; it's simply a fact, and I'm not the only one observing it. Â Links were given here some time back. Sorry, but this is only a fact if you provide unit tests (or at least a couple of examples) that fail in the latest code base. Otherwise simply nobody cares. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 1, 2010

Re: [Pharo-project] about code formatting in pharo

by StÃ©phane Ducasse

send some evidence based on tests so that lukas can give a try to improve the situation. This is what lukas is saying. [Stef] On Mar 1, 2010, at 1:36 PM, Schwab,Wilhelm K wrote: > I'm not complaining; it's simply a fact, and I'm not the only one observing it. Links were given here some time back. > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli > Sent: Monday, March 01, 2010 7:28 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] about code formatting in pharo > >> Another approach would be to have a Seaside app that accepts uploads of .mcz files, loads, formats, and re-saves them into an in-box. I still recommend getting the RB's house in order with respect to comments, but it would work as well as RB users have come to expect. It would also make it part of the release process for a package vs. putting it in the image and affecting "the little guy." > > Instead of complaining all the time about the handling of comments in RB you could provide some tests that demonstrate why you think it is broken. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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

March 1, 2010

Re: [Pharo-project] about code formatting in pharo

by StÃ©phane Ducasse

On Mar 1, 2010, at 1:23 PM, Lukas Renggli wrote: >> Cool. If we can tweak the formatter to fit our needs, I think this is an interesting idea because we would then have really consistent formatting. > > It has dozens of settings that you can configure. It is already > integrated with the settings framework in Pharo 1.1. cool! > >> How does one use this formatter? > > aClass compile: (aClass parseTreeFor: aSelector) formattedCode > >> Something else to consider is that we would need to run the formatter in PharoCore, but it does not contain RB. We could write a small web service that takes some method source as input and returns the formatted code ;) > > You only need AST-Core. You can load it in one image, format the code, > commit the changes and load the changes into a fresh Pharo image. Also > you could unload AST-Core, it has no overrides. gorgeous :) I feel lucky to have a guy like you around :)

March 1, 2010

Re: [Pharo-project] about code formatting in pharo

by StÃ©phane Ducasse

would be nice :) scripting the core from external services Stef On Mar 1, 2010, at 12:52 PM, Adrian Lienhard wrote: > Cool. If we can tweak the formatter to fit our needs, I think this is an interesting idea because we would then have really consistent formatting. How does one use this formatter? Something else to consider is that we would need to run the formatter in PharoCore, but it does not contain RB. We could write a small web service that takes some method source as input and returns the formatted code ;) > > Adrian > > On Feb 28, 2010, at 22:31 , Lukas Renggli wrote: > >> The configurable formatter can be told from how many keyword messages >> on it should put them on multiple lines. Also you can give exceptions >> of messages that you always/never want to put on multiple lines. >> >> Lukas >> >> On 28 February 2010 22:29, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>> >>> On Feb 28, 2010, at 22:12 , StÃ©phane Ducasse wrote: >>>>> --------------- >>>>> 1 >>>>> to: (mine size min: his size) >>>>> do: [ :index | >>>>> (mine at: index) = (his at: index) ifTrue: [ >>>>> self >>>>> instVarAt: index >>>>> put: (anotherObject instVarAt: index) ] ]. >>>>> --------------- >>>>> >>>>> Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. >>>> >>>> :) >>>> >>>> why not like that? >>>>> 1 >>>>> to: (mine size min: his size) >>>>> do: [ :index | >>>>> (mine at: index) = (his at: index) >>>>> ifTrue: [ self >>>>> instVarAt: index >>>>> put: (anotherObject instVarAt: index) ] ]. >>> >>> The difference is not big, but I prefer the first version because you get one indentation less (and you don't break the rule that an indentation always has only one tab, which is not the case above). >>> >>> Also it makes formatting of conditionals consistent with the formatting of other messages, e.g., >>> >>> receiver foo: x >>> >>> instead of >>> >>> receiver >>> foo: x >>> >>> >>> The rule for ifTrue:ifFalse: follows the same rule, i.e., that keyword messages with more than one argument are put on separate lines: >>> >>> receiver >>> foo: x >>> bar: y >>> >>> >>> Adrian >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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

March 1, 2010

Re: [Pharo-project] Call for fixing the network problem

by Adrian Lienhard

I've updated the issue with an error report and comments posted to the mailing list. Adrian On Mar 1, 2010, at 13:26 , Schwab,Wilhelm K wrote: > Do the comments in the tracker reflect "everything" that has been tried and not worked? That would seem to be an important list. I'll take a look at it later today. I saw mention that all is well in the core; is that true? > > When I last looked into this, there were still paths to ipv6 primitives not protected by a check on #useOldNetwork - given how the old network flag was set at the time, that was a sure sign of trouble. Gotta run. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard > Sent: Monday, March 01, 2010 7:22 AM > To: Pharo-project Development > Subject: [Pharo-project] Call for fixing the network problem > > To release Pharo 1.0, we need to fix the network problem: > > http://code.google.com/p/pharo/issues/detail?id=1884 > > Anyone volunteers to help? I can allocate some time but would welcome if somebody would team up to get rid of this issue. > > Cheers, > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > 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

March 1, 2010

Re: [Pharo-project] about code formatting in pharo

by Schwab,Wilhelm K

I'm not complaining; it's simply a fact, and I'm not the only one observing it. Links were given here some time back. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Monday, March 01, 2010 7:28 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo > Another approach would be to have a Seaside app that accepts uploads of .mcz files, loads, formats, and re-saves them into an in-box. Â I still recommend getting the RB's house in order with respect to comments, but it would work as well as RB users have come to expect. Â It would also make it part of the release process for a package vs. putting it in the image and affecting "the little guy." Instead of complaining all the time about the handling of comments in RB you could provide some tests that demonstrate why you think it is broken. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2010

Re: [Pharo-project] about code formatting in pharo

by Lukas Renggli

> Another approach would be to have a Seaside app that accepts uploads of .mcz files, loads, formats, and re-saves them into an in-box. Â I still recommend getting the RB's house in order with respect to comments, but it would work as well as RB users have come to expect. Â It would also make it part of the release process for a package vs. putting it in the image and affecting "the little guy." Instead of complaining all the time about the handling of comments in RB you could provide some tests that demonstrate why you think it is broken. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 1, 2010