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

Re: [Pharo-project] Issue 670: Should clean Morph menu

by StÃ©phane Ducasse

magic of morphic :) Stef On May 26, 2010, at 11:29 AM, Gary Chambers wrote: > Well, even if a morph does not, at any one time, use a table layout the settings are preserved and use if switched to a table layout... > > Curiously these options are pretty much the only ones I use from the menu ;-) > > > Regards, Gary > ----- Original Message ----- > From: Carla F. Griggio > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Tuesday, May 25, 2010 10:25 PM > Subject: Re: [Pharo-project] Issue 670: Should clean Morph menu > > Well, I haven't tried all those actions, but if it helps in any way, the ones I usually use are: > > grab > delete > copy text > submorphs > inspect > show actions > debug-> > inspect morph > inspect model > browse morph class > browse model class > > > > I don't see what the layout options do. I don't know much about layouts, so maybe this doesn't make sense, but... shouldn't the options for table layout be available only if the morph I'm dealing with has a table layout? > > > > On Tue, May 25, 2010 at 5:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > **EXCELLENT** > truly excellent > Yes we try to sort that and get some cleaning. > > > grab > > copy to paste buffer > > collapse > > delete > > copy text > > go behind > > add halo > > duplicate > > embed into-> > > PasteUpMorph > > SystemWindow > > resize > > change color... > > drop shadow-> > > show shadow > > shadow color... > > shadow offset... > > layout-> > > no layout > > proportional layout > > table layout > > change layout inset... > > child layout-> > > disable layout in tables > > horizontal resizing-> > > rigid > > shrink wrap > > space fill > > vertical resizing-> > > rigid > > shrink wrap > > space fill > > table layout-> > > reverse table cells > > clip to cell size > > rubber band cells > > change cell inset... > > change min cell size... > > change max cell size... > > list direction-> > > ... > > wrap direction-> > > ... > > cell positioning-> > > ... > > list centering-> > > ... > > wrap centering-> > > ... > > list spacing-> > > ... > > cell spacing-> > > ... > > provide clipping > > submorphs > ?? > > > inspect > > explore > > > browse hierarchy > ?? > > > save morph in file > > attach to resource > ?? > > > show actions > > debug-> > > inspect morph > > inspect owner chain > > inspect model > > explore morph > > browse morph class > > browse model class > > explore view hierarchy > > call #tempCommand > ?? > > define #tempCommand > ?? > > > open editing > > edit label... > > > > Cheers, > > Guille > > _______________________________________________ > > 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

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by StÃ©phane Ducasse

hi richard > WTF?! If you have a real argument we are really open to discussion. > These are the only reasons? I think that they are sufficient but again we are not saying that we know everything and that any solutions could not be rollback. We are doing and learning. Now having clean, lean and fast core classes are important. Because we could have and:or: or:and: and:and:or: and a couple of others in that case. > Why do we have #value:value:value: then? Because this is part of block protocol in the ANSI and because you cannot do it only with value: >> - and: is optimized by the compiler > We could use C, where "everything" is optimized by the compiler. I think that your point is out of scope but if you want you can use C. Stef

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Mariano Martinez Peck

http://forum.world.st/about-and-and-and-and-and-or-or-tp1477719p1477719.html On Wed, May 26, 2010 at 11:53 AM, Richard Durr <richard.durr(a)googlemail.com>wrote: > WTF?! These are the only reasons? > > > Why do we have #value:value:value: then? > > > - and: is optimized by the compiler > We could use C, where "everything" is optimized by the compiler. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 26, 2010

[Pharo-project] obsolete method?

by StÃ©phane Ducasse

no senders. May be we should removed? StrikeFont>>displayStringR2L: aString on: aBitBlt from: startIndex to: stopIndex at: aPoint kern: kernDelta "You are screwed if you reach this method." aBitBlt displayString: aString from: startIndex to: stopIndex at: aPoint strikeFont: self kern: kernDelta.

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Richard Durr

WTF?! These are the only reasons? Why do we have #value:value:value: then? > - and: is optimized by the compiler We could use C, where "everything" is optimized by the compiler.

May 26, 2010

Re: [Pharo-project] "Smalltalk signalLowSpace" freeze the image

by StÃ©phane Ducasse

I integrated it. Stef On May 26, 2010, at 11:24 AM, Mariano Martinez Peck wrote: > Thanks Torsten. Indeed, the fix works perfect at least for this problem. > > Cheers > > Mariano > > On Tue, May 25, 2010 at 6:43 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Now on: > > http://code.google.com/p/pharo/issues/list?cursor=2473 > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > 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

May 26, 2010

Re: [Pharo-project] ConnectionQueue defect in 1.0

by Henrik Johansen

Yes, it is broken. To me, removing the return of true, and changing the method comment to reflect the real return values seem like the "simplest" solution. There seems to have been some issues related to clock wraparound fixed around the time of the method time stamps, not sure if the ^true was just a way to align better with the comment, or a real fix for something though :/ Cheers, Henry On May 25, 2010, at 8:58 44PM, Schwab,Wilhelm K wrote: > Hello all, > > Please see attached - CAREFULLY :) It turns out that NetworkSmokeTest will fail in your images, for want of #nextMany: and other additions I have made to streams. > PS. What is wrong with next: ?

May 26, 2010

[Pharo-project] [update 1.1] #11372

by StÃ©phane Ducasse

11372 ----- - Issue 2276: MNU offList - Issue 2474: OSPlatformTest#testStartUpList fails

May 26, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/list?cursor=2477 Stef On May 26, 2010, at 11:16 AM, Mariano Martinez Peck wrote: > and we should open a bug ticket....too much emails.. > > On Wed, May 26, 2010 at 9:39 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > maybe the condenseChanges with the new method trailer? > > > On Tue, May 25, 2010 at 10:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I noticed a problem between > 11357 and 11363 today > apparently class definitions containing traits loses their traits. > > Stef > > On May 25, 2010, at 3:10 PM, Torsten Bergmann wrote: > > > 1. If you select a trait in the browser (for instance "NSTInflating") > > and select "browse hierarchy (h)" from the context menu you will > > notice a > > > > Trait(Object)>>doesNotUnderstand: #allSubclassesWithLevelDo:startingLevel: > > > > error. > > > > > > 2. While it was no problem to build the pharo-dev from a > > core 11367 image using ConfigurationOfPharo it now crashes with a DNU > > while loading Nile when I use a newer pharo #11371 core image. > > > > Bye > > T. > > > > > > > > -- > > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > > > _______________________________________________ > > 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

May 26, 2010

Re: [Pharo-project] Issue 670: Should clean Morph menu

by Gary Chambers

Well, even if a morph does not, at any one time, use a table layout the settings are preserved and use if switched to a table layout... Curiously these options are pretty much the only ones I use from the menu ;-) Regards, Gary ----- Original Message ----- From: Carla F. Griggio To: Pharo-project(a)lists.gforge.inria.fr Sent: Tuesday, May 25, 2010 10:25 PM Subject: Re: [Pharo-project] Issue 670: Should clean Morph menu Well, I haven't tried all those actions, but if it helps in any way, the ones I usually use are: grab delete copy text submorphs inspect show actions debug-> inspect morph inspect model browse morph class browse model class I don't see what the layout options do. I don't know much about layouts, so maybe this doesn't make sense, but... shouldn't the options for table layout be available only if the morph I'm dealing with has a table layout? On Tue, May 25, 2010 at 5:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: **EXCELLENT** truly excellent Yes we try to sort that and get some cleaning. > grab > copy to paste buffer > collapse > delete > copy text > go behind > add halo > duplicate > embed into-> > PasteUpMorph > SystemWindow > resize > change color... > drop shadow-> > show shadow > shadow color... > shadow offset... > layout-> > no layout > proportional layout > table layout > change layout inset... > child layout-> > disable layout in tables > horizontal resizing-> > rigid > shrink wrap > space fill > vertical resizing-> > rigid > shrink wrap > space fill > table layout-> > reverse table cells > clip to cell size > rubber band cells > change cell inset... > change min cell size... > change max cell size... > list direction-> > ... > wrap direction-> > ... > cell positioning-> > ... > list centering-> > ... > wrap centering-> > ... > list spacing-> > ... > cell spacing-> > ... > provide clipping > submorphs ?? > inspect > explore > browse hierarchy ?? > save morph in file > attach to resource ?? > show actions > debug-> > inspect morph > inspect owner chain > inspect model > explore morph > browse morph class > browse model class > explore view hierarchy > call #tempCommand ?? > define #tempCommand ?? > open editing > edit label... > > Cheers, > Guille > _______________________________________________ > 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

May 26, 2010