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

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

by Adrian Lienhard

ok, I uploaded a new image, created starting at 10164 and updated to 10204. https://gforge.inria.fr/frs/download.php/14204/Pharo0.1Core-10204.zip Adrian On Jan 11, 2009, at 22:49 , Adrian Lienhard wrote: > I created a new 10203 image starting from 10164. > As expected, it does not have the Monticello setting enabled. > > Stef, how can I upload that image to gforge? > > Adrian > > On Jan 9, 2009, at 17:20 , Adrian Lienhard wrote: > >> Yes, I can do it on the weekend. >> Adrian >> >> On Jan 9, 2009, at 17:07 , StÃ©phane Ducasse wrote: >> >>> >>> On Jan 9, 2009, at 4:26 PM, Adrian Lienhard wrote: >>> >>>> No I didn't. >>>> >>>> But maybe we better recreate an image from the last version that >>>> didn't have this setting? I don't think it was introduced by a >>>> change >>>> because in my images that I updated myself the setting was not >>>> changed. >>> >>> Ok so may be we should redo a new core starting from the version you >>> mentioned was >>> not having such behavior. Do you do it? >>> >>> Stef >>> >>>> >>>> >>>> Adrian >>>> >>>> On Jan 9, 2009, at 16:15 , StÃ©phane Ducasse wrote: >>>> >>>>> adrian >>>>> >>>>> did you use the cleaning expression of alex in your release? >>>>> >>>>> Stef >>>>> >>>>> On Jan 7, 2009, at 3:08 PM, Alexandre Bergel wrote: >>>>> >>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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

Jan. 12, 2009

[Pharo-project] Xtreams?

by Michael Rueger

Hi all, does anybody have any experience or opinion about the Xtreams framework? Haven't looked at it yet, saw it mentioned here http://www.cincomsmalltalk.com/userblogs/mls/blogView?showComments=true&pri… and it seems to have a Java impementation as well. Michael

Jan. 12, 2009

Re: [Pharo-project] new look / monticello UI

by StÃ©phane Ducasse

thanks. I hope that I will find some time this evening to produce a new version. stef On Jan 12, 2009, at 3:27 PM, Gary Chambers wrote: > There is a newer version of Polymorph-Tools-Diff on SqueakSource > that tidies > some things up (including not merging when window closed if no > conflicts. > This was original MC behaviour that was replicated). > > As for modality... since MC uses a notification to spawn conflict > resolution > the window must be modal in some way. The original behaviour was to > effecively run a local Morphic event loop at the point of spawning. > Multiple > merge/conflict windows could be opened though the merge order would > always > be last-first. IMHO it is not a good idea to be merging multiple > things at > once since the basis for a merge may have changed due to later merges, > leading to potentially odd results. I'll stand by the modality, > though I may > be convinced to make it window modal rather than system modal, > allowing > those who want to invite chaos to do so ;-) Since Polymorph utilises > ToolBuilder>>runModal: this would be effectively the same behaviour > (local > event loop). > > The (work-in-progress) arrows/tick/crosss on the splitter are now > disabled > if anything other than a conflict is selected. Note that only > conflicts > allow selection of keeping-current/using-incoming anyway. > > Still digging away at working out what can be achieved with MC. > Looks like > it may be possible to have alternate source either typed or > composited from > individual differences in the case of a conflict that is also a > modification. Going to try stuffing new source in the > "remote" (incoming) > definition and see what happens! > > Sadly I don't think I can do anything for removals/additions (when a > method > changes package it comes up as a removal). > > I'm going to add titles to each source pane showing the package/ > version for > each to help clarify things. I may also, for removals, be able to > show the > package/source of the in-image version if people think that would be > helpful. > > Regards, Gary. > > ----- Original Message ----- > From: "Damien Cassou" <damien.cassou(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, December 22, 2008 9:25 AM > Subject: Re: [Pharo-project] new look / monticello UI > > >> On Sat, Dec 20, 2008 at 4:39 PM, Michael Roberts <mike(a)mjr104.co.uk> >> wrote: >>> guys, I'm liking the new UI in Pharo. I've noticed in the >>> Monticello >>> browser that the buttons now don't have an enabled/disabled >>> state. Is >>> this intentional or noticed? >> >> It's already in the issue tracker system. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> _______________________________________________ >> 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. 12, 2009

Re: [Pharo-project] new look / monticello UI

by Gary Chambers

There is a newer version of Polymorph-Tools-Diff on SqueakSource that tidies some things up (including not merging when window closed if no conflicts. This was original MC behaviour that was replicated). As for modality... since MC uses a notification to spawn conflict resolution the window must be modal in some way. The original behaviour was to effecively run a local Morphic event loop at the point of spawning. Multiple merge/conflict windows could be opened though the merge order would always be last-first. IMHO it is not a good idea to be merging multiple things at once since the basis for a merge may have changed due to later merges, leading to potentially odd results. I'll stand by the modality, though I may be convinced to make it window modal rather than system modal, allowing those who want to invite chaos to do so ;-) Since Polymorph utilises ToolBuilder>>runModal: this would be effectively the same behaviour (local event loop). The (work-in-progress) arrows/tick/crosss on the splitter are now disabled if anything other than a conflict is selected. Note that only conflicts allow selection of keeping-current/using-incoming anyway. Still digging away at working out what can be achieved with MC. Looks like it may be possible to have alternate source either typed or composited from individual differences in the case of a conflict that is also a modification. Going to try stuffing new source in the "remote" (incoming) definition and see what happens! Sadly I don't think I can do anything for removals/additions (when a method changes package it comes up as a removal). I'm going to add titles to each source pane showing the package/version for each to help clarify things. I may also, for removals, be able to show the package/source of the in-image version if people think that would be helpful. Regards, Gary. ----- Original Message ----- From: "Damien Cassou" <damien.cassou(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, December 22, 2008 9:25 AM Subject: Re: [Pharo-project] new look / monticello UI > On Sat, Dec 20, 2008 at 4:39 PM, Michael Roberts <mike(a)mjr104.co.uk> > wrote: >> guys, I'm liking the new UI in Pharo. I've noticed in the Monticello >> browser that the buttons now don't have an enabled/disabled state. Is >> this intentional or noticed? > > It's already in the issue tracker system. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 12, 2009

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

by StÃ©phane Ducasse

but update first :) Stef On Jan 12, 2009, at 12:52 PM, StÃ©phane Ducasse wrote: > just log you are admin > and click on files + create a release. > > Stef > > On Jan 11, 2009, at 10:49 PM, Adrian Lienhard wrote: > >> I created a new 10203 image starting from 10164. >> As expected, it does not have the Monticello setting enabled. >> >> Stef, how can I upload that image to gforge? >> >> Adrian >> >> On Jan 9, 2009, at 17:20 , Adrian Lienhard wrote: >> >>> Yes, I can do it on the weekend. >>> Adrian >>> >>> On Jan 9, 2009, at 17:07 , StÃ©phane Ducasse wrote: >>> >>>> >>>> On Jan 9, 2009, at 4:26 PM, Adrian Lienhard wrote: >>>> >>>>> No I didn't. >>>>> >>>>> But maybe we better recreate an image from the last version that >>>>> didn't have this setting? I don't think it was introduced by a >>>>> change >>>>> because in my images that I updated myself the setting was not >>>>> changed. >>>> >>>> Ok so may be we should redo a new core starting from the version >>>> you >>>> mentioned was >>>> not having such behavior. Do you do it? >>>> >>>> Stef >>>> >>>>> >>>>> >>>>> Adrian >>>>> >>>>> On Jan 9, 2009, at 16:15 , StÃ©phane Ducasse wrote: >>>>> >>>>>> adrian >>>>>> >>>>>> did you use the cleaning expression of alex in your release? >>>>>> >>>>>> Stef >>>>>> >>>>>> On Jan 7, 2009, at 3:08 PM, Alexandre Bergel wrote: >>>>>> >>>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 12, 2009

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

by StÃ©phane Ducasse

just log you are admin and click on files + create a release. Stef On Jan 11, 2009, at 10:49 PM, Adrian Lienhard wrote: > I created a new 10203 image starting from 10164. > As expected, it does not have the Monticello setting enabled. > > Stef, how can I upload that image to gforge? > > Adrian > > On Jan 9, 2009, at 17:20 , Adrian Lienhard wrote: > >> Yes, I can do it on the weekend. >> Adrian >> >> On Jan 9, 2009, at 17:07 , StÃ©phane Ducasse wrote: >> >>> >>> On Jan 9, 2009, at 4:26 PM, Adrian Lienhard wrote: >>> >>>> No I didn't. >>>> >>>> But maybe we better recreate an image from the last version that >>>> didn't have this setting? I don't think it was introduced by a >>>> change >>>> because in my images that I updated myself the setting was not >>>> changed. >>> >>> Ok so may be we should redo a new core starting from the version you >>> mentioned was >>> not having such behavior. Do you do it? >>> >>> Stef >>> >>>> >>>> >>>> Adrian >>>> >>>> On Jan 9, 2009, at 16:15 , StÃ©phane Ducasse wrote: >>>> >>>>> adrian >>>>> >>>>> did you use the cleaning expression of alex in your release? >>>>> >>>>> Stef >>>>> >>>>> On Jan 7, 2009, at 3:08 PM, Alexandre Bergel wrote: >>>>> >>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >

Jan. 12, 2009

Re: [Pharo-project] [squeak-dev] [ANN] WatchIt

by Mariano Martinez Peck

HernÃ¡n: What little but very useful thing! I hope this to be in standard squeak and pharo images. Thanks for it! Mariano On Sun, Jan 11, 2009 at 1:03 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Dear all, > You can use again the "Watch It" debugging functionality written by Ned > Konz back in 2002. This is the description: > > "This adds a 'watch it' choice to the context menus in text editors. This > will take the selection, make a BlockContext out of it, and give you a Morph > that will display the value of that block every half second. It can be used, > for instance, from the Debugger to display an instance variable as your > program runs." > > Test 1: > Paint and select "watch it" from the menu: > > World currentHand cursorPoint > > Test 2: > "debug it" the following lines, once inside the debugger, paint the > "collection", select "watch it" and voilÃ ! > > | collection | > collection := #(1 2 3 4) asOrderedCollection. > collection add: 88. > collection add: 99. > collection > > Tested under: > -Squeak3.9 > -Squeak3.10.2 > -Pharo0.1Core-10201 > > Cheers > > HernÃ¡n > > > >

Jan. 11, 2009

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

by Adrian Lienhard

I created a new 10203 image starting from 10164. As expected, it does not have the Monticello setting enabled. Stef, how can I upload that image to gforge? Adrian On Jan 9, 2009, at 17:20 , Adrian Lienhard wrote: > Yes, I can do it on the weekend. > Adrian > > On Jan 9, 2009, at 17:07 , StÃ©phane Ducasse wrote: > >> >> On Jan 9, 2009, at 4:26 PM, Adrian Lienhard wrote: >> >>> No I didn't. >>> >>> But maybe we better recreate an image from the last version that >>> didn't have this setting? I don't think it was introduced by a >>> change >>> because in my images that I updated myself the setting was not >>> changed. >> >> Ok so may be we should redo a new core starting from the version you >> mentioned was >> not having such behavior. Do you do it? >> >> Stef >> >>> >>> >>> Adrian >>> >>> On Jan 9, 2009, at 16:15 , StÃ©phane Ducasse wrote: >>> >>>> adrian >>>> >>>> did you use the cleaning expression of alex in your release? >>>> >>>> Stef >>>> >>>> On Jan 7, 2009, at 3:08 PM, Alexandre Bergel wrote: >>>> >>>>> 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 >>> >>> >>> _______________________________________________ >>> 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

Jan. 11, 2009

[Pharo-project] [ANN] 10204: fixing inbox and more tests

by StÃ©phane Ducasse

Hi I published a fix for the inbox empty mcz behavior and more collectionTests. I will have a look soon at Mike's changes, but we have a deadline for thursday. Stef

Jan. 11, 2009

Re: [Pharo-project] [ANN] WatchIt

by Rob Rothwell

Thanks! I just tried this in a Pharo0.1Core-10201 updated to 10203 and it worked fine. Very nice when you just want to keep an eye on some things. Rob On Sun, Jan 11, 2009 at 10:54 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Thanks HernÃ¡n > > I created http://code.google.com/p/pharo/issues/detail?id=440 > > Cheers, > Adrian > > On Jan 11, 2009, at 16:04 , HernÃ¡n Morales Durand wrote: > > > And of course, the download link is: > > http://www.squeaksource.com/WatchIt.html > > > > 2009/1/11 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > > > >> Dear all, > >> You can use again the "Watch It" debugging functionality written > >> by Ned > >> Konz back in 2002. This is the description: > >> > >> "This adds a 'watch it' choice to the context menus in text > >> editors. This > >> will take the selection, make a BlockContext out of it, and give > >> you a Morph > >> that will display the value of that block every half second. It can > >> be used, > >> for instance, from the Debugger to display an instance variable as > >> your > >> program runs." > >> > >> Test 1: > >> Paint and select "watch it" from the menu: > >> > >> World currentHand cursorPoint > >> > >> Test 2: > >> "debug it" the following lines, once inside the debugger, paint the > >> "collection", select "watch it" and voilÃ ! > >> > >> | collection | > >> collection := #(1 2 3 4) asOrderedCollection. > >> collection add: 88. > >> collection add: 99. > >> collection > >> > >> Tested under: > >> -Squeak3.9 > >> -Squeak3.10.2 > >> -Pharo0.1Core-10201 > >> > >> Cheers > >> > >> HernÃ¡n > >> > > _______________________________________________ > > 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. 11, 2009