- Pharo-dev - lists.pharo.org

Re: [Pharo-project] debugger problems?

by Eliot Miranda

On Tue, Jan 25, 2011 at 2:58 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > yes as Adrian pointed out debugger highlighting is broken in Pharo. > Has been since the very beginning. what we need ideally is a set of > test cases describing the desired behaviour. i struggled to simulate > this, i am not sure what a good test harness is for the debugger. > ideally the highlighting can be tested without the debugger (i.e > without the necessary processes and activations), just triggering the > necessary execution machinery that calculates highlight offsets > (intervals). With a good set of tests we could then better compare > Squeak and Pharo implementations because a lot of fixes go into squeak > and we need to harvest them over here. any help of course welcome in > this area. I poke at it now and then.... > Take a look at the ClosureCompilerTest>>testSourceRangeAccessForClosureBytecodeInjectInto which tests the source ranges (that the debugger uses to highlight) for all pcs in the inject:into: method. > cheers, > Mike > > On Tue, Jan 25, 2011 at 2:20 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > 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. 26, 2011

Re: [Pharo-project] debugger problems?

by Michael Roberts

yes as Adrian pointed out debugger highlighting is broken in Pharo. Has been since the very beginning. what we need ideally is a set of test cases describing the desired behaviour. i struggled to simulate this, i am not sure what a good test harness is for the debugger. ideally the highlighting can be tested without the debugger (i.e without the necessary processes and activations), just triggering the necessary execution machinery that calculates highlight offsets (intervals). With a good set of tests we could then better compare Squeak and Pharo implementations because a lot of fixes go into squeak and we need to harvest them over here. any help of course welcome in this area. I poke at it now and then.... cheers, Mike On Tue, Jan 25, 2011 at 2:20 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > 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] why does monticello updates accessing web when i save on dir?

by HwaJong Oh

Why on earth does Pharo thinks me as professional? I am not at that level yet. :-) So the waiting is needed for saver save. I should endure this, but I makes harder for my micro commit habbit. I try to commit as small as refactoring operation defined in the book "Refactoring-M. Fowler" so the reader of my code will clearly see the change. The commit cycle 1. refactor 2. run test 3. read package change 4. commit with comment with refactoring name followed by extra info: "ExtractMethod: #refreshLayoutsFor: " The waiting distracts my focus applying this. 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] why does monticello updates accessing web when i save on dir?

by HwaJong Oh

Why on earth does Pharo thinks me as professional? I am not at that level yet. :-) So the waiting is needed for saver save. I should endure this, but I makes harder for my micro commit habbit. I try to commit as small as refactoring operation defined in the book "Refactoring-M. Fowler" so the reader of my code will clearly see the change. The commit cycle 1. refactor 2. run test 3. read package change 4. commit with comment with refactoring name followed by extra info: "ExtractMethod: #refreshLayoutsFor: " The waiting distracts my focus applying this. 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

[Pharo-project] Weird behavior in a package loaded with Monticello?

by simondenier

Recently I took a look at the Global Keys project of Tony Fleig and noticed something strange. The package GlobalKeys makes some class extensions to the HandMorph class, extensions which are accessors to an instance variable. Since instance variable can't be included in class extensions, the variable appears as undeclared instead. HandMorph>>globalKeystrokeHandler "class extension" ^globalKeystrokeHandler "is an undeclared variable" HandMorph>>globalKeystrokeHandler: aOneArgBlock globalKeystrokeHandler := aOneArgBlock However, when loading the package, class side initialization uses the mutator #globalKeystrokeHandler: to set a default behavior for 'World activeHand' (an instance of HandMorph) and... it works! No error, it just works as if the instance variable is well defined and can be accessed without problem. GlobalKeys class>>setHandMorphHook "called by class initialization" World activeHand globalKeystrokeHandler: [ :ev | | retval | retval := false. "..." ] How can it be that the first invocation of #globalKeystrokeHandler: in #setHandMorphHook does not crash? Try the following: Gofer new squeaksource: 'GlobalKeys'; version: 'GlobalKeys-TonyFleig.9'; load Print it: World activeHand globalKeystrokeHandler ---> print the source of a code block Now debug the above snippet and proceed *into* globalKeystrokeHandler Print it again ----> print nil as if the code was recompiled once processed by the debugger You can also add the instance var globalKeystrokeHandler, recompile, it will be set to nil. -- View this message in context: http://forum.world.st/Weird-behavior-in-a-package-loaded-with-Monticello-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 25, 2011

[Pharo-project] Fwd: Google Summer of Code 2011 Announced

by Stefan Marr

Hi: Is anyone organizing something for GSOC this year? We definitely would like to propose one or two RoarVM+Pharo projects. Best regards Stefan > ---------- Forwarded message ---------- > From: Carol Smith <carols(a)google.com> > Date: Mon, Jan 24, 2011 at 23:21 > Subject: Google Summer of Code 2011 Announced > To: Google Summer of Code Announce > <google-summer-of-code-announce(a)googlegroups.com> > > > Hi all, > We're pleased to announce that Google Summer of Code will be happening > for its seventh year this year. Please check out the blog post [1] > about the program and read the FAQs [2] and Timeline [3] on Melange > for more information. > [1] - http://google-opensource.blogspot.com/2011/01/google-summer-of-code-announc… > [2] - http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/fa… > [3] - http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/ti… > Cheers, > Carol > > -- > You received this message because you are subscribed to the Google > Groups "Google Summer of Code Announce" group. > To post to this group, send email to > google-summer-of-code-announce(a)googlegroups.com. > To unsubscribe from this group, send email to > google-summer-of-code-announce+unsubscribe(a)googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-summer-of-code-announce?hl=en. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 25, 2011

Re: [Pharo-project] Pharo on the iPhone

by Hilaire Fernandes

Le 24/01/2011 19:22, Alexandre Bergel a Ã©crit : > Unfortunately, my resources are scarce. iPhone are not really spread in Chile. I haven't seen a student having one. > > Is it possible to make DrGeo available on iTune? Not yet. Hilaire

Jan. 25, 2011

[Pharo-project] just to tell you that I love all these activities and energy around pharo :)

by StÃ©phane Ducasse

This is really giving me a lot of energy to build the next generation. I busy writing project proposals to get money for the future, but all these activities and cool changes push me to hack and improve the system, its process and the doc. Stef

Jan. 25, 2011

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

by StÃ©phane Ducasse

if you save locally did you try to psuh the changes with gofer Gofer new ... ; push On Jan 25, 2011, at 2:44 PM, 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 StÃ©phane Ducasse

I love to hear that kind of news. In addition, I think that we should really get rid of toolBuilder because it will not support new ui elements. Stef On Jan 25, 2011, at 4:31 PM, Gary Chambers wrote: > OK, try the following, after filing in attached change set, > I've had a dabble with announcements too ;-) ... > > > | container morph1 morph2 morph3 morph4 ex1 ex2 ex3 ex4 sp1 sp2 sp3| > 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. > morph4 := (PanelMorph new fillStyle: (SolidFillStyle color: Color green)) 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: 3; expanded: true. > ex4 := (UITheme builder newExpander: 'Green' for: morph4) spaceFillWeight: 4; expanded: true. > sp1 := EdgeGripMorph new > target: ex1; > edgeName: #bottom; > fitTargetOwner: true; > on: #mouseDown send: #expandedSizingRigid to: ex1. > sp2 := EdgeGripMorph new > target: ex2; > edgeName: #bottom; > fitTargetOwner: true; > on: #mouseDown send: #expandedSizingRigid to: ex2. > sp3 := EdgeGripMorph new > target: ex3; > edgeName: #bottom; > fitTargetOwner: true; > on: #mouseDown send: #expandedSizingRigid to: ex3. > ex1 announcer on: ExpanderMorphAnnouncement do: [:ann | > sp1 > visible: ann expanderMorph expanded; > disableTableLayout: ann expanderMorph expanded not]. > ex2 announcer on: ExpanderMorphAnnouncement do: [:ann | > sp2 > visible: ann expanderMorph expanded; > disableTableLayout: ann expanderMorph expanded not]. > ex3 announcer on: ExpanderMorphAnnouncement do: [:ann | > sp3 > visible: ann expanderMorph expanded; > disableTableLayout: ann expanderMorph expanded not]. > container := UITheme builder newColumn: { > ex1. > sp1. > ex2. > sp2. > ex3. > sp3. > ex4}. > container cellInset: 0. > container extent: 400@400. > container openInWindow. > > > > > Once people are happy with it I'll wrap thing up into a new morph that > takes the burdensome details away (ExpanderGroupMorph or something like that). > Later, like tabs, ability to add/remove sections dynamically etc. > > Regards, Gary > > ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, January 25, 2011 3:07 PM > Subject: Re: [Pharo-project] collapsing panes > > >> I'm working on it... changeset soon... >> >> Regards, Gary >> >> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, January 25, 2011 2:15 PM >> Subject: Re: [Pharo-project] collapsing panes >> >> >> 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." >> >> >> >> > <ExpanderTweak.2.cs>

Jan. 25, 2011