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

Re: [Pharo-project] Issue 3594 in pharo: Expander needs tweaking to enable resize in a TableLayout

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #2 on issue 3594 by tudor.gi...(a)gmail.com: Expander needs tweaking to enable resize in a TableLayout http://code.google.com/p/pharo/issues/detail?id=3594 (No comment was entered for this change.)

Jan. 25, 2011

Re: [Pharo-project] debugger problems?

by Adrian Lienhard

On Jan 25, 2011, at 14:05 , Tudor Girba wrote: > I am not alone! :) > > Anyone else noticed this? yes Is it http://code.google.com/p/pharo/issues/detail?id=709 ? Adrian

Jan. 25, 2011

Re: [Pharo-project] Issue 3594 in pharo: Expander needs tweaking to enable resize in a TableLayout

by pharo＠googlecode.com

Comment #1 on issue 3594 by tudor.gi...(a)gmail.com: Expander needs tweaking to enable resize in a TableLayout http://code.google.com/p/pharo/issues/detail?id=3594 And now with the attachment Attachments: ExpanderTweak.1.cs 757 bytes

Jan. 25, 2011

Re: [Pharo-project] why does monticello updates accessing web when i save on dir?

by Adrian Lienhard

Does it access the web when you store to your local repo or when you copy to SqueakSource? Was that different with Squeak? If there's some unnecessary "activity" I would be interested to know about ;) Cheers, Adrian On Jan 25, 2011, at 14:44 , HwaJong Oh wrote: > > Saving packages in my local directory repository and then copying them to the > squeaksource is my pattern of work since Squeak. But, when I apply that > pattern, Pharo accesses web everytime i save a version taking long time. Is > this behavior have some meaning or is it some sort of side effect? > > Best Regards > -- > View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 25, 2011

Re: [Pharo-project] collapsing panes

by Tudor Girba

Ahh, indeed! My bad. Thanks Gary. The main issue that seems to be left is the resizing. Currently, resizing propagates the changes to all the following morphs. This is great when the table layout is inside a GeneralScrollPane, but it leads to a bit of an odd behavior when stretching inside a bounded morph. Is there an easy option to change the behavior of the resizer? Cheers, Doru On 25 Jan 2011, at 12:07, Gary Chambers wrote: > Hi Doru, > > The weight should be applied to the expanders themselves... > > > ex1 := (UITheme builder newExpander: 'Red' for: morph1) > spaceFillWeight: 1; > expanded: true. > ex2 := (UITheme builder newExpander: 'Blue' for: morph2) > spaceFillWeight: 2; > expanded: true. > ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) > spaceFillWeight: 3; > expanded: true. > > Regards, Gary > > ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, January 24, 2011 9:14 PM > Subject: Re: [Pharo-project] collapsing panes > > > Hi Gary, > > On 24 Jan 2011, at 16:16, Gary Chambers wrote: > >> Hi, >> I don't think the layouts can be merged, as such, as they have very different >> approaches. >> >> With the TableLayout, it is possible to assign "weights" to each spaceFill >> section to get what you want, I think. (see #spaceFillWeight:) > > I tried to use it, but I get no effect when I use it in your example. > > Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am I doing wrong? > > | container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2| > morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red)) > hResizing: #spaceFill; > vResizing: #spaceFill. > morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue)) > hResizing: #spaceFill; > vResizing: #spaceFill; > spaceFillWeight: 10. > morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow)) > hResizing: #spaceFill; > vResizing: #spaceFill. > ex1 := (UITheme builder newExpander: 'Red' for: morph1) expanded: true. > ex2 := (UITheme builder newExpander: 'Blue' for: morph2) expanded: true. > ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) expanded: true. > sp1 := EdgeGripMorph new > target: ex1; > edgeName: #bottom; > vResizing: #rigid; > extent: 24 @ ProportionalSplitterMorph splitterWidth; > on: #mouseDown send: #expandedSizingRigid to: ex1. > sp2 := EdgeGripMorph new > target: ex2; > edgeName: #bottom; > vResizing: #rigid; > extent: 24 @ ProportionalSplitterMorph splitterWidth; > on: #mouseDown send: #expandedSizingRigid to: ex2. > container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}. > container cellInset: 0. > container extent: 400@400. > container openInWindow. > > Cheers, > Doru > > > >> Regards, Gary >> >> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, January 24, 2011 2:32 PM >> Subject: Re: [Pharo-project] collapsing panes >> >> >> Thanks a lot, Gary! I gave it a try and it does go in the wanted direction. >> >> Now, the next question. I see that you are using a TableLayout. Is there a way to specify a proportion (like in the proportional layout?) for the initial extent of the inner panes? >> >> If yes, then I suppose we could merge the two layouts into one. >> >> Cheers, >> Doru >> >> >> On 24 Jan 2011, at 14:51, Benjamin wrote: >> >>> I love that :) >>> It could be very useful ^^ >>> >>> >>> Ben >>> >>> On Jan 24, 2011, at 2:36 PM, Gary Chambers wrote: >>> >>>> Tricky... >>>> Just an experiment, but try the following after filing in attached change set. >>>> Can make the re-proportioning explicit and maybe fix things to constrain to >>>> the owner morph if interested... >>>> >>>> >>>> | container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2| >>>> morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red)) >>>> hResizing: #spaceFill; >>>> vResizing: #spaceFill. >>>> morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue)) >>>> hResizing: #spaceFill; >>>> vResizing: #spaceFill. >>>> morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow)) >>>> hResizing: #spaceFill; >>>> vResizing: #spaceFill. >>>> ex1 := (UITheme builder newExpander: 'Red' for: morph1) >>>> expanded: true. >>>> ex2 := (UITheme builder newExpander: 'Blue' for: morph2) >>>> expanded: true. >>>> ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) >>>> expanded: true. >>>> sp1 := EdgeGripMorph new >>>> target: ex1; >>>> edgeName: #bottom; >>>> vResizing: #rigid; >>>> extent: 24 @ ProportionalSplitterMorph splitterWidth; >>>> on: #mouseDown send: #expandedSizingRigid to: ex1. >>>> sp2 := EdgeGripMorph new >>>> target: ex2; >>>> edgeName: #bottom; >>>> vResizing: #rigid; >>>> extent: 24 @ ProportionalSplitterMorph splitterWidth; >>>> on: #mouseDown send: #expandedSizingRigid to: ex2. >>>> container := UITheme builder newColumn: { >>>> ex1. >>>> sp1. >>>> ex2. >>>> sp2. >>>> ex3}. >>>> container cellInset: 0. >>>> container extent: 400@400. >>>> container openInWindow. >>>> >>>> >>>> >>>> Have a play/fun. >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >>>> To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Friday, January 21, 2011 11:18 PM >>>> Subject: [Pharo-project] collapsing panes >>>> >>>> >>>> Hi, >>>> >>>> I have a question about how to obtain an effect similar to minimizing a pane in Eclipse. Let's consider the example from below. I have a ProportionalLayout because I want to fill the entire space and be able to resize the inside panes. Now, I would also like to have some way of collapsing one of the panes and have the rest resize to fill the rest of the space. It's a bit like I would need some part of a behavior from the TableLayout. >>>> >>>> Can anyone provide me with some hints in this direction? Do I need to create a new Layout? >>>> >>>> | container morph1 morph2 morph3 window | >>>> container := PanelMorph new. >>>> morph1 := PanelMorph new fillStyle: (SolidFillStyle color: Color red). >>>> morph2 := PanelMorph new fillStyle: (SolidFillStyle color: Color blue). >>>> morph3 := PanelMorph new fillStyle: (SolidFillStyle color: Color yellow). >>>> container changeProportionalLayout. >>>> container addMorph: morph1 fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0.33)). >>>> container addMorph: morph2 fullFrame: (LayoutFrame fractions: (0 @ 0.33 corner: 1 @ 0.66)). >>>> container addMorph: morph3 fullFrame: (LayoutFrame fractions: (0 @ 0.66 corner: 1 @ 1)). >>>> container addPaneSplitters. >>>> container fillStyle: (SolidFillStyle color: Color yellow). >>>> container extent: 400@400. >>>> container openInWindow. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Be rather willing to give than demanding to get." >>>> >>>> >>>> >>>> <ExpanderTweak.1.cs> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Every now and then stop and ask yourself if the war you're fighting is the right one." >> >> >> >> >> > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

Jan. 25, 2011

[Pharo-project] Issue 3594 in pharo: Expander needs tweaking to enable resize in a TableLayout

by pharo＠googlecode.com

Status: Accepted Owner: tudor.gi...(a)gmail.com Labels: Milestone-1.2 Type-RequestForEnhancement New issue 3594 by tudor.gi...(a)gmail.com: Expander needs tweaking to enable resize in a TableLayout http://code.google.com/p/pharo/issues/detail?id=3594 The attached change set from Gary makes the following code to work: | container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2| morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red)) hResizing: #spaceFill; vResizing: #spaceFill. morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue)) hResizing: #spaceFill; vResizing: #spaceFill. morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow)) hResizing: #spaceFill; vResizing: #spaceFill. ex1 := (UITheme builder newExpander: 'Red' for: morph1) spaceFillWeight: 1; expanded: true. ex2 := (UITheme builder newExpander: 'Blue' for: morph2) spaceFillWeight: 2; expanded: true. ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) spaceFillWeight: 2; expanded: true. sp1 := EdgeGripMorph new target: ex1; edgeName: #bottom; vResizing: #rigid; extent: 24 @ ProportionalSplitterMorph splitterWidth; on: #mouseDown send: #expandedSizingRigid to: ex1. sp2 := EdgeGripMorph new target: ex2; edgeName: #bottom; vResizing: #rigid; extent: 24 @ ProportionalSplitterMorph splitterWidth; on: #mouseDown send: #expandedSizingRigid to: ex2. container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}. container cellInset: 0. container extent: 400@400. container openInWindow.

Jan. 25, 2011

Re: [Pharo-project] Issue 3573 in pharo: Failing Test: CompiledMethodTest.testPerformInSuperclassCanExecutelongMethodWithTemps

by pharo＠googlecode.com

Comment #1 on issue 3573 by marcus.d...(a)gmail.com: Failing Test: CompiledMethodTest.testPerformInSuperclassCanExecutelongMethodWithTemps http://code.google.com/p/pharo/issues/detail?id=3573 See Issue 3468

Jan. 25, 2011

Re: [Pharo-project] problem starting up with a script on windows

by Tudor Girba

I managed to debug some more and the problem seems to be introduced by System-Download after the version System-Download-StephaneDucasse.51. If you try any of the newer version, you should get the error. Ah, one more detail: I worked on a Windows Server 2008 R2 using a Cog VM (both r2316 and r2348). It would be great if someone else could confirm. Cheers, Doru On 25 Jan 2011, at 14:04, Tudor Girba wrote: > Hi, > > There seems to be a problem with starting a Pharo 1.2-based image with an initial .st script on Windows. > > The problem seems to be in CodeLoader>>installSourceFiles and it is related to the contentStream retrieved from the HTTPDownloadRequest being nil. I attached the debug.log. > > I checked the paths and they are all correct. In fact, if I run the same script with a Pharo 1.1.1 image, everything works as expected. I also tried to drag and drop the .st script and again, everything works as expected. So, it seems that there is some initialization problem. > > I cannot debug well because I do not have a Windows machine (the situation happens on a server that I cannot access easily). Can someone take a look to see if the problem can be reproduced? > > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "The coherence of a trip is given by the clearness of the goal." > > > <PharoDebug.log> -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

Jan. 25, 2011

Re: [Pharo-project] Hapao for Test coverage!

by Alexandre Bergel

> I encountered the same bug mentioned by Lukas in Profiler>>#runningUnitTests:atEachTestEvaluate: The problem should now have disappeared. > I think you just have to reject abstract classes from the sunitClasses collection. True. We will fix this. http://code.google.com/p/moose-technology/issues/detail?id=503 Cheers, Alexandre > > On Tue, Jan 25, 2011 at 10:57 AM, Vanessa PeÃ±a <vane.c.pena(a)gmail.com> wrote: > Thank you very much for your help :) > > > On Mon, Jan 24, 2011 at 10:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > This is cool to have news! > Excellent idea. > I will try to help you to post regularly. > > > On Jan 24, 2011, at 11:01 AM, Marcus Denker wrote: > > > On Thu, Jan 20, 2011 at 6:41 PM, Vanessa PeÃ±a <vane.c.pena(a)gmail.com> wrote: > >> Hello all, > >> > >> We are happy to introduce you Hapao, an innovative test coverage tool which > >> gives you an intuitive graphical representation to visually assess the > >> quality of the coverage. > >> > >> For more information and download you can visit us at: > >> http://hapao.dcc.uchile.cl/ > >> Of course, all feedback is always welcome :) > >> > > Very nice! > > > > One small thing: the dialog selecting the packages at the beginning should > > label the button "continue"", not "terminate" (which sounds like cancel to me). > > > > I added a blog post: http://pharo-project.org/news > > > > > > -- > > Marcus Denker -- denker(a)acm.org > > http://www.marcusdenker.de > > > > > > > > > -- > GaÃ«tan Le Brun > www.linkedin.com/in/gaetanlebrun > > "The best way to predict the future is to invent it.", A.Kay, 1971 > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 25, 2011

[Pharo-project] why does monticello updates accessing web when i save on dir?

by HwaJong Oh

Saving packages in my local directory repository and then copying them to the squeaksource is my pattern of work since Squeak. But, when I apply that pattern, Pharo accesses web everytime i save a version taking long time. Is this behavior have some meaning or is it some sort of side effect? Best Regards -- View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 25, 2011