- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] 10203

by Adrian Lienhard

- Issue 363: fix some traits issues (introduced by changes in Metaclass and TestCase) - Traits conflict marker methods stored in wrong cache - Remove duplicated method in trait and class that uses it (in collection tests) - Issue 315: darker colors in diff dialog (thanks to Damien Pollet) - Issue 342: Removing beginning capital letter of instance variables (Alexandre Bergel) - Make MC always display dependencies of a version in its summary text - Issue: 101: fasterDayOfYear-brp.1 (Mantis 7156) - Issue 102: better testPrintShowingDecimalPlaces Adrian ___________________ http://www.adrian-lienhard.ch/

Jan. 7, 2009

Re: [Pharo-project] Collection extensions

by Brian Brown

On Jan 5, 2009, at 7:56 AM, Lukas Renggli wrote: >> I published to the inbox some cool collection extension methods that >> we use all the time in Moose. >> flatCollect:, collectAsSet:, and groupedBy: > > I think Squeak already has far too many of these methods. I would > rather like to see them all removed, than new ones added. As an author > and maintainer of many Smalltalk framework I experience daily the pain > such methods cause, as they are inherently non-portable not only > between smalltalk dialects but even between users of exactly the same > image. > (This rambles a bit, so bear with me... ) I agree with Lukas as far as what is the core system; I also used many of the unique and helpful methods available in Squeak and not in other Smalltalk implementations *as long as I know I'm not porting it another system*. With the ever improving Installer/Universes/SM system, can we not easily keep the core small and add collection extensions and other extensions as dependencies for a given package? Another option would be to change/rename the categories to denote ansi compliant methods, but since the categories metaphor is flat, methods can't be in more that one at a time. Could the OB smart filters be used in this way? Or would we have to implement some sort of tagging framework to be able to arbitrarily tag methods and classes, so methods can reside in appropriate categories and still be flagged as ANSI (among other things). I also agree with the sentiment (to a point) in the thread that ANSI is old and outdated, and why does Pharo have to be hobbled by that. From a practical matter, regardless of how old the ANSI standard is, it is the only standard we have, and when you are doing a framework like Seaside, or any number of others, compatibility with other Smalltalks where possible is extremely important. My 2 bits... - Brian

Jan. 7, 2009

Re: [Pharo-project] Very strange behavior with MC

by Adrian Lienhard

The setting to diff in the PharoInbox repository first appears in the uploaded image Pharo0.1Core-10172.zip Thanks, Alex, for tracking this down. I've never used this feature. Adrian On Jan 7, 2009, at 15:37 , StÃ©phane Ducasse wrote: > Excellent > I have no idea how pharoInbox got diffy > > Stef > > > >> Dear List, >> >> I dug in the Monticello melting-pot to find where the strange >> behavior >> some of you are encountering comes from. >> >> **The problem** >> The bug come from the "diffy versions". MC tries to save in >> PharoInbox >> a "diffy" version of your package. As far as I understood, a "diffy" >> version is a version of your package that contains just a delta from >> an ancestor. In theory this looks nice, but for some reasons it >> behaves incorrectly (the zip file is not probably created, it cannot >> be decompressed) >> >> **How to solve it** >> Recently (since 10183), the http repository for PharoInbox is set to >> store version in a diffy mode. You can identity http repository that >> are set that way: >> MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs] >> >> The problem I mentioned in my previous email disappear symply by >> doing >> (MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs]) >> do: [:mc | mc doNotAlwaysStoreDiffs] >> >> After having executed the last snippet, storing packages in >> PharoInbox >> will not appear empty. >> >> What is left to be done, is why this diffy mechanism does not work as >> expected. But I feel that we should not use it anyway since the >> ancestor link is not alway kept and is incorrectly handled (e.g., >> cross-repository ancestors) and MC2 is now in the pipeline. >> >> Cheers, >> Alexandre >> >> >> On 6 Jan 2009, at 15:26, Alexandre Bergel wrote: >> >>> Dear all, >>> >>> I just save a new version in PharoInbox, but this version appears to >>> be empty. I checked on squeaksource [*]. >>> In Pharo, it seems that two files are being saved (.143(142).mcd >>> and .143.mcz) [**]. >>> when I browse .143(142).mcd I see all the content (probably because >>> it is local to my machine). >>> When I browse .143.mcz it is empty. >>> >>> What this .mcd file is about? >>> I am not the only one to experience this. Anyone had an idea what's >>> going on? >>> I haven't closely followed the list of changes that were included in >>> Pharo. >>> >>> Alexandre >>> >>> [*] http://bergel.eu/EmptyVersion.png >>> [**] http://bergel.eu/TwoSavedVersions.png >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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

Jan. 7, 2009

Re: [Pharo-project] Very strange behavior with MC

by StÃ©phane Ducasse

Excellent I have no idea how pharoInbox got diffy Stef > Dear List, > > I dug in the Monticello melting-pot to find where the strange behavior > some of you are encountering comes from. > > **The problem** > The bug come from the "diffy versions". MC tries to save in PharoInbox > a "diffy" version of your package. As far as I understood, a "diffy" > version is a version of your package that contains just a delta from > an ancestor. In theory this looks nice, but for some reasons it > behaves incorrectly (the zip file is not probably created, it cannot > be decompressed) > > **How to solve it** > Recently (since 10183), the http repository for PharoInbox is set to > store version in a diffy mode. You can identity http repository that > are set that way: > MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs] > > The problem I mentioned in my previous email disappear symply by doing > (MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs]) > do: [:mc | mc doNotAlwaysStoreDiffs] > > After having executed the last snippet, storing packages in PharoInbox > will not appear empty. > > What is left to be done, is why this diffy mechanism does not work as > expected. But I feel that we should not use it anyway since the > ancestor link is not alway kept and is incorrectly handled (e.g., > cross-repository ancestors) and MC2 is now in the pipeline. > > Cheers, > Alexandre > > > On 6 Jan 2009, at 15:26, Alexandre Bergel wrote: > >> Dear all, >> >> I just save a new version in PharoInbox, but this version appears to >> be empty. I checked on squeaksource [*]. >> In Pharo, it seems that two files are being saved (.143(142).mcd >> and .143.mcz) [**]. >> when I browse .143(142).mcd I see all the content (probably because >> it is local to my machine). >> When I browse .143.mcz it is empty. >> >> What this .mcd file is about? >> I am not the only one to experience this. Anyone had an idea what's >> going on? >> I haven't closely followed the list of changes that were included in >> Pharo. >> >> Alexandre >> >> [*] http://bergel.eu/EmptyVersion.png >> [**] http://bergel.eu/TwoSavedVersions.png >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 7, 2009

Re: [Pharo-project] Very strange behavior with MC

by Alexandre Bergel

Dear List, I dug in the Monticello melting-pot to find where the strange behavior some of you are encountering comes from. **The problem** The bug come from the "diffy versions". MC tries to save in PharoInbox a "diffy" version of your package. As far as I understood, a "diffy" version is a version of your package that contains just a delta from an ancestor. In theory this looks nice, but for some reasons it behaves incorrectly (the zip file is not probably created, it cannot be decompressed) **How to solve it** Recently (since 10183), the http repository for PharoInbox is set to store version in a diffy mode. You can identity http repository that are set that way: MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs] The problem I mentioned in my previous email disappear symply by doing (MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs]) do: [:mc | mc doNotAlwaysStoreDiffs] After having executed the last snippet, storing packages in PharoInbox will not appear empty. What is left to be done, is why this diffy mechanism does not work as expected. But I feel that we should not use it anyway since the ancestor link is not alway kept and is incorrectly handled (e.g., cross-repository ancestors) and MC2 is now in the pipeline. Cheers, Alexandre On 6 Jan 2009, at 15:26, Alexandre Bergel wrote: > Dear all, > > I just save a new version in PharoInbox, but this version appears to > be empty. I checked on squeaksource [*]. > In Pharo, it seems that two files are being saved (.143(142).mcd > and .143.mcz) [**]. > when I browse .143(142).mcd I see all the content (probably because > it is local to my machine). > When I browse .143.mcz it is empty. > > What this .mcd file is about? > I am not the only one to experience this. Anyone had an idea what's > going on? > I haven't closely followed the list of changes that were included in > Pharo. > > Alexandre > > [*] http://bergel.eu/EmptyVersion.png > [**] http://bergel.eu/TwoSavedVersions.png > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 7, 2009

[Pharo-project] DictionaryTest

by Alexandre Bergel

Dear List, A new version of CollectionsTests is waiting in PharoInbox. Here is the comments: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= **This version includes the content of version 142** The most important methods in Dictionary are covered by DictionaryTest. Some implementation methods in Set are also covered by the testing class. One trait TDictionaryAddingTest has been added. More traits will be added soon. DictionaryTest coverageAsString ==> 'DictionaryTest covers 77% of Dictionary' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 7, 2009

Re: [Pharo-project] pharo is... ?

by StÃ©phane Ducasse

>> > Is the plan for it to end up as a fork of squeak that runs on the > squeak vm? probably. what is the other solution? > Is the underlying vm going to change? Probably too. if we want to clean up event and other parts there is no other way. After our changes are MIT so > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 7, 2009

Re: [Pharo-project] pharo is... ?

by Sean Allen

On Jan 4, 2009, at 4:10 AM, StÃ©phane Ducasse wrote: > Hello Sean > > >> I started using Squeak a few months ago, mostly in a time permitting >> fashion.. 2-3 weeks ago, I saw a Pharo related message come across >> that list and joined here to see what Pharo is. I'm still not >> entirely >> sure, so I'm asking... >> >> Pharo is... ? >> >> The little bit of marketing on the website makes it sound appealing >> and I'm sure if I had more experience with Squeak then downloading >> the >> one click and running it and poking around would have answered a ton >> of questions but, I don't have the Squeak background to have that be >> meaningful. > > Pharo's goal is to be a clean free-open source Smalltalk. Is the plan for it to end up as a fork of squeak that runs on the squeak vm? Is the underlying vm going to change?

Jan. 7, 2009

Re: [Pharo-project] Buggy HTTPSocket in dev-image

by StÃ©phane Ducasse

Thanks andreas! Stef On Jan 6, 2009, at 9:42 PM, Andreas Wacknitz wrote: > Hi folks, > > the dev images seem to have a (probably older version) of HTTPSocket. > There are some undefined globals > (like HTTPProxyServer, HTTPProxySocket, CrLf and CR) which lead to > problems when I try to load Magma. > The pharo-core image seem to have a correct version of this class. > > Cheers, > Andreas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 6, 2009

[Pharo-project] Buggy HTTPSocket in dev-image

by Andreas Wacknitz

Hi folks, the dev images seem to have a (probably older version) of HTTPSocket. There are some undefined globals (like HTTPProxyServer, HTTPProxySocket, CrLf and CR) which lead to problems when I try to load Magma. The pharo-core image seem to have a correct version of this class. Cheers, Andreas

Jan. 6, 2009