- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 2.0] #20276

by Alexandre Bergel

You rock!! That's cool to see it moving so fast... Alexandre On Sep 5, 2012, at 12:50 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 20276 > ----- > > Issue 6560: [Cleanup]: SystemVersion > http://code.google.com/p/pharo/issues/detail?id=6560 > > Issue 6576: Some MC enh from Squeak > http://code.google.com/p/pharo/issues/detail?id=6576 > > Issue 6629: Update FileSystem comments > http://code.google.com/p/pharo/issues/detail?id=6629 > > Issue 6631: Order of classes and traits in fileOut are wrong > http://code.google.com/p/pharo/issues/detail?id=6631 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 5, 2012

[Pharo-project] [update 2.0] #20277

by Esteban Lorenzano

20277 ----- Issue 6638: Gofer merge WorkingCopy not found http://code.google.com/p/pharo/issues/detail?id=6638

Sept. 5, 2012

[Pharo-project] [update 2.0] #20276

by Esteban Lorenzano

20276 ----- Issue 6560: [Cleanup]: SystemVersion http://code.google.com/p/pharo/issues/detail?id=6560 Issue 6576: Some MC enh from Squeak http://code.google.com/p/pharo/issues/detail?id=6576 Issue 6629: Update FileSystem comments http://code.google.com/p/pharo/issues/detail?id=6629 Issue 6631: Order of classes and traits in fileOut are wrong http://code.google.com/p/pharo/issues/detail?id=6631

Sept. 5, 2012

[Pharo-project] ss3.gemstone.com

by Alexandre Bergel

Hi! On http://ss3.gemstone.com one can read: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Important Announcement (September 7, 2011): The contents of this repository WILL survive beyond the lifetime of the public Alpha. >From this point onward, all packages stored in the repository will be preserved. As of today, the site is backed up on a daily basis. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Is this important announcement really important today? Why not to simply say "The site is backed up on a daily basis." Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 5, 2012

[Pharo-project] [update 2.0] #20275

by Esteban Lorenzano

20275 ----- Issue 6635: Removing class does not remove class tag http://code.google.com/p/pharo/issues/detail?id=6635 Issue 6636: Review over RPackage system integration tests http://code.google.com/p/pharo/issues/detail?id=6636 Issue 6461: [BUG]: Bogus package creation http://code.google.com/p/pharo/issues/detail?id=6461

Sept. 5, 2012

[Pharo-project] [update 2.0] #20274

by Esteban Lorenzano

20274 ----- Issue 6634: Diff is broken http://code.google.com/p/pharo/issues/detail?id=6634

Sept. 5, 2012

Re: [Pharo-project] morphic help needed

by Mariano Martinez Peck

Ok, thanks guys. We finally solve it :) http://code.google.com/p/pharo/issues/detail?id=6634 On Wed, Sep 5, 2012 at 1:48 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Wed, Sep 5, 2012 at 1:43 PM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > >> Le 05/09/2012 13:31, Mariano Martinez Peck a Ã©crit : >> >>> >>> >>> On Wed, Sep 5, 2012 at 1:31 PM, Goubier Thierry <thierry.goubier(a)cea.fr >>> <mailto:thierry.goubier@cea.fr**>> wrote: >>> >>> Le 05/09/2012 13:20, Esteban Lorenzano a Ã©crit : >>> >>> Hi, >>> >>> Me and Mariano are trying to fix the DiffMorph in 2.0 (if you >>> noticed, >>> it is broken), and we noticed that the difference between 1.4 >>> and 2.0 is >>> that now the PluggableTextMorph inside is wrapping the text (non >>> respecting the endline, but arranging them to be shown in the >>> morph), >>> instead showing an horizontal scroll bar to move around. >>> We are lost in the obscure mist of morphic world... and we don't >>> know >>> how to restore that behavior. >>> >>> Can someone help? >>> >>> of course, this is important... not just because, also because I >>> need to >>> make integrations and I cannot because I don't know what changed >>> :) >>> >>> >>> I told you Esteban :) >>> Yes, we tried both, #wrapFlag: flase and #autoFit: false. And with both >>> cases we still have the problem. >>> >> >> Ok, but look at DiffMorph>>setText and it ends up calling setTextBasic:, >> which, under certain conditions, does a >> >> self textMorph >> contents: aText >> wrappedTo: self innerExtent x >> >> > Good catch. So....shouldn't there be an if of wrapFlag: and if it is true > we use #contents: aText #wrappedTo: otherwise we use #newContents: ? > > > > >> Which will put back the wrapFlag to true... >> >> (many of the textMorph contents: method may set back the wrapFlag to >> true. There is something about having a nil container in the TextMorph code >> to free the wrapping). >> >> I would really like to have the Jejak tracer working on 2.0 to be able to >> see better what's going on. >> >> Thierry >> >> >> We were doing, for example: >>> >>> newSrcMorph >>> "Answer a new src text morph." >>> | pluggableTextMorph | >>> pluggableTextMorph := (self newTextEditorFor: self >>> getText: nil >>> setText: nil >>> getEnabled: nil) >>> hideVScrollBarIndefinitely: true; >>> borderWidth: 0; >>> enabled: false; >>> wrapFlag: false; >>> selectionColor: self textSelectionColor; >>> setText: ''; >>> hShowScrollBar; >>> alwaysShowHScrollBar: true. >>> pluggableTextMorph textMorph autoFit: false. >>> pluggableTextMorph textMorph wrapFlag: false. >>> ^ pluggableTextMorph >>> >>> >>> same problem :( >>> >>> I'm attaching two images of how it should be and how it is now. >>> >>> Thanks, >>> Esteban >>> >>> >>> There is something called wrapFlag in TextMorphForEditView inside >>> all PluggableTextMorph(s). >>> >>> Not sure if this is the setting forcing that behavior. >>> >>> Thierry >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>> >>> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Sept. 5, 2012

Re: [Pharo-project] Zinc-HTTP-Deprecated

by Sven Van Caekenberghe

FYI, Sven Van Caekenberghe uploaded a new version of Zinc-HTTP to project Zinc HTTP Components: http://www.squeaksource.com/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenbergh… ==================== Summary ==================== Name: Zinc-HTTP-SvenVanCaekenberghe.300 Author: SvenVanCaekenberghe Time: 5 September 2012, 1:59:02 am UUID: a09fb75e-0ba5-489c-bc1b-435481a08164 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.299 removal of all classes in Zinc-HTTP-Deprecated - ZnClientOld - ZnFixedClient - ZnExtendedFixedClient - ZnUserAgent - ZnHttpClient - ZnUserAgentSettings as well as all their unit test classes On 23 Aug 2012, at 15:52, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > There is a class category called 'Zinc-HTTP-Deprecated'. It contains some old classes that were replaced/superceded by newer ones almost a year ago. > > I plan to actually delete these and their unit tests in a commit in the next couple of days. > > Specifically, the following classes will be removed: > > - ZnClientOld > - ZnFixedClient > - ZnExtendedFixedClient > - ZnUserAgent > - ZnHttpClient > - ZnUserAgentSettings > > I hope nobody uses these anymore. > > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill

Sept. 5, 2012

Re: [Pharo-project] morphic help needed

by Mariano Martinez Peck

On Wed, Sep 5, 2012 at 1:43 PM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > Le 05/09/2012 13:31, Mariano Martinez Peck a Ã©crit : > >> >> >> On Wed, Sep 5, 2012 at 1:31 PM, Goubier Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr**>> wrote: >> >> Le 05/09/2012 13:20, Esteban Lorenzano a Ã©crit : >> >> Hi, >> >> Me and Mariano are trying to fix the DiffMorph in 2.0 (if you >> noticed, >> it is broken), and we noticed that the difference between 1.4 >> and 2.0 is >> that now the PluggableTextMorph inside is wrapping the text (non >> respecting the endline, but arranging them to be shown in the >> morph), >> instead showing an horizontal scroll bar to move around. >> We are lost in the obscure mist of morphic world... and we don't >> know >> how to restore that behavior. >> >> Can someone help? >> >> of course, this is important... not just because, also because I >> need to >> make integrations and I cannot because I don't know what changed >> :) >> >> >> I told you Esteban :) >> Yes, we tried both, #wrapFlag: flase and #autoFit: false. And with both >> cases we still have the problem. >> > > Ok, but look at DiffMorph>>setText and it ends up calling setTextBasic:, > which, under certain conditions, does a > > self textMorph > contents: aText > wrappedTo: self innerExtent x > > Good catch. So....shouldn't there be an if of wrapFlag: and if it is true we use #contents: aText #wrappedTo: otherwise we use #newContents: ? > Which will put back the wrapFlag to true... > > (many of the textMorph contents: method may set back the wrapFlag to true. > There is something about having a nil container in the TextMorph code to > free the wrapping). > > I would really like to have the Jejak tracer working on 2.0 to be able to > see better what's going on. > > Thierry > > > We were doing, for example: >> >> newSrcMorph >> "Answer a new src text morph." >> | pluggableTextMorph | >> pluggableTextMorph := (self newTextEditorFor: self >> getText: nil >> setText: nil >> getEnabled: nil) >> hideVScrollBarIndefinitely: true; >> borderWidth: 0; >> enabled: false; >> wrapFlag: false; >> selectionColor: self textSelectionColor; >> setText: ''; >> hShowScrollBar; >> alwaysShowHScrollBar: true. >> pluggableTextMorph textMorph autoFit: false. >> pluggableTextMorph textMorph wrapFlag: false. >> ^ pluggableTextMorph >> >> >> same problem :( >> >> I'm attaching two images of how it should be and how it is now. >> >> Thanks, >> Esteban >> >> >> There is something called wrapFlag in TextMorphForEditView inside >> all PluggableTextMorph(s). >> >> Not sure if this is the setting forcing that behavior. >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- Mariano http://marianopeck.wordpress.com

Sept. 5, 2012

Re: [Pharo-project] morphic help needed

by Goubier Thierry

Le 05/09/2012 13:31, Mariano Martinez Peck a Ã©crit : > > > On Wed, Sep 5, 2012 at 1:31 PM, Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>> wrote: > > Le 05/09/2012 13:20, Esteban Lorenzano a Ã©crit : > > Hi, > > Me and Mariano are trying to fix the DiffMorph in 2.0 (if you > noticed, > it is broken), and we noticed that the difference between 1.4 > and 2.0 is > that now the PluggableTextMorph inside is wrapping the text (non > respecting the endline, but arranging them to be shown in the > morph), > instead showing an horizontal scroll bar to move around. > We are lost in the obscure mist of morphic world... and we don't > know > how to restore that behavior. > > Can someone help? > > of course, this is important... not just because, also because I > need to > make integrations and I cannot because I don't know what changed :) > > > I told you Esteban :) > Yes, we tried both, #wrapFlag: flase and #autoFit: false. And with both > cases we still have the problem. Ok, but look at DiffMorph>>setText and it ends up calling setTextBasic:, which, under certain conditions, does a self textMorph contents: aText wrappedTo: self innerExtent x Which will put back the wrapFlag to true... (many of the textMorph contents: method may set back the wrapFlag to true. There is something about having a nil container in the TextMorph code to free the wrapping). I would really like to have the Jejak tracer working on 2.0 to be able to see better what's going on. Thierry > We were doing, for example: > > newSrcMorph > "Answer a new src text morph." > | pluggableTextMorph | > pluggableTextMorph := (self newTextEditorFor: self > getText: nil > setText: nil > getEnabled: nil) > hideVScrollBarIndefinitely: true; > borderWidth: 0; > enabled: false; > wrapFlag: false; > selectionColor: self textSelectionColor; > setText: ''; > hShowScrollBar; > alwaysShowHScrollBar: true. > pluggableTextMorph textMorph autoFit: false. > pluggableTextMorph textMorph wrapFlag: false. > ^ pluggableTextMorph > > > same problem :( > > I'm attaching two images of how it should be and how it is now. > > Thanks, > Esteban > > > There is something called wrapFlag in TextMorphForEditView inside > all PluggableTextMorph(s). > > Not sure if this is the setting forcing that behavior. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 5, 2012