- Pharo-dev - lists.pharo.org

[Pharo-project] FW: Debugging Cog crash

by Schwab,Wilhelm K

Gratuitous default recipient... If there is a verbose dump option or other diagnostic efforts that will help, I will do my best to run them and report the results. I am fairly certain the vm is 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54]' (can verify later today), but this happened with an earlier Cog one-click too. There is something about the machine (UUID again?) that is different. I do not have root access to it, but I can get to a terminal. Ubuntu 10.10. ________________________________________ From: Schwab,Wilhelm K Sent: Friday, April 08, 2011 7:44 AM To: Mariano Martinez Peck Subject: RE: [Pharo-project] Debugging Cog crash Mariano, I first identified this problem/opportunity a while ago. At the time, there was no log - the vm just died. I can sniff around again as there might be one this time. My question at the time was whether there was something that I could enable to perhaps get more info. The output from the vm is, and I quote<g> "Segmentation fault". There is no other output. Perhaps it does not get far enough to have a call stack?? Bill ________________________________________ From: Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Friday, April 08, 2011 3:42 AM To: Squeak Development Discussion Virtual Machine; Pharo Development Cc: Schwab,Wilhelm K Subject: Re: [Pharo-project] Debugging Cog crash also...shouldn't be a crash/dump file somewhere? can you write the output of the console where you invoke the VM into a file ? (using > to redirect) Cheers Mariano On Thu, Apr 7, 2011 at 11:10 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Hello all, I have an account on an Ubuntu terminal server (at least I think that's what it would be called) running 10.10. The Cog one-click image crashes with "Segmentation fault" (if run from a terminal); the legacy VM seems to run the image nicely on the box. Any ideas? I will happily collect any facts that will be of help, but I need some direction. Bill -- Mariano http://marianopeck.wordpress.com

April 8, 2011

Re: [Pharo-project] A step toward reducing complexity

by Igor Stasenko

On 8 April 2011 11:02, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > On 8 Apr 2011, at 10:41, StÃ©phane Ducasse wrote: > >>>> is it for pharo? >>> >>> I do not know because I do not understand what the process is anymore. I tried to get a process going in which the design of UI goes through the same rigor and integration like the object-oriented design, but it did not work yet :(. >> >> You lost me there. > > Perhaps I did not understand your question. > >> You are talking about Glamour. > > No. Glamour is but an effort to stream knowledge through one technology. But, I am talking about the ui in general. I am talking about the fact that in the distribution is just fine to add another color, another kind of selection, another way of interactive, and nobody really cares. I know that the intention is not to have that at the end, but in the end we do have that, so the process is not working :). In the UI world we have what we hate in the programming world. > >>> We need a project. I proposed to do this in the context of the The Glamorous Toolkit project and to integrate all these concerns, including the UI look and feel. >> >> Yes I thought that this is what you were doing. > > I am doing that, but that is about it. The little pieces are not worked on because of this goal. They are worked on because someone has some interest in some corner. And they almost never get properly integrated. So, at the moment this project is failing from my point of view. > No. Its not failing. It just takes time. I remember that you came with initiative that you want to coordinate efforts about improving state of are about UI. And trust me, your been heard. > But, I will stop raising this issue :). > >>> I would offer to lead this. Right now, everyone is still pretty much working on UI by looking at smaller pieces in his own corner. That is not bad, but it is not enough. >> >> I'm talking just about the UITheme. So I was planning to rename the GLMglamour looks which is in pharo and do the refactoring but what I could do is to start from yours so that the one we use gets all your improvements. And you could load yours on the side. > > Ok. > > Cheers, > Doru > > >> Stef >>>>> >>> Like small graphical issues related to the fact that GLMUITheme does no longer inherit all the helpers and effects from Watery2. >>> >>> At the moment, I basically copied some of these from Watery2 (like the management of the close/minimize/maximize) buttons. >> >> > > -- > www.tudorgirba.com > > "Every successful trip needs a suitable vehicle." > > > > > > -- Best regards, Igor Stasenko AKA sig.

April 8, 2011

Re: [Pharo-project] A step toward reducing complexity

by Tudor Girba

Hi, On 8 Apr 2011, at 10:41, StÃ©phane Ducasse wrote: >>> is it for pharo? >> >> I do not know because I do not understand what the process is anymore. I tried to get a process going in which the design of UI goes through the same rigor and integration like the object-oriented design, but it did not work yet :(. > > You lost me there. Perhaps I did not understand your question. > You are talking about Glamour. No. Glamour is but an effort to stream knowledge through one technology. But, I am talking about the ui in general. I am talking about the fact that in the distribution is just fine to add another color, another kind of selection, another way of interactive, and nobody really cares. I know that the intention is not to have that at the end, but in the end we do have that, so the process is not working :). In the UI world we have what we hate in the programming world. >> We need a project. I proposed to do this in the context of the The Glamorous Toolkit project and to integrate all these concerns, including the UI look and feel. > > Yes I thought that this is what you were doing. I am doing that, but that is about it. The little pieces are not worked on because of this goal. They are worked on because someone has some interest in some corner. And they almost never get properly integrated. So, at the moment this project is failing from my point of view. But, I will stop raising this issue :). >> I would offer to lead this. Right now, everyone is still pretty much working on UI by looking at smaller pieces in his own corner. That is not bad, but it is not enough. > > I'm talking just about the UITheme. So I was planning to rename the GLMglamour looks which is in pharo and do the refactoring but what I could do is to start from yours so that the one we use gets all your improvements. And you could load yours on the side. Ok. Cheers, Doru > Stef >>>> >> Like small graphical issues related to the fact that GLMUITheme does no longer inherit all the helpers and effects from Watery2. >> >> At the moment, I basically copied some of these from Watery2 (like the management of the close/minimize/maximize) buttons. > > -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

April 8, 2011

Re: [Pharo-project] Making layouts using anchors

by Igor Stasenko

On 8 April 2011 09:41, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > In the current LayoutPolicy scheme there's no knowledge between the > brothers, for the anchors this would present a potential problem. > > What about moving this dependency to the parent, which knows all the > morphs, instead of introducing this knowledge in the brothers? > > In your example: > window anchorMorph: morph at: left > window anchorMorph: morph2 rightTo: morph. > Well, in the above you expressed same relationship just using different terms. You still want morph2 to align to right edge of morph. And for you, as a UI designer, it doesn't really matters where framework keeps this information - in parent morph or in morph itself. You just want morphs to obey specified rules, right? > Then Â it would be transparent to the current LayoutPolicy scheme, and > IMO the responsibilities are better distributed. > Eliminating the knowledge between brothers greatly simplifies the UI framework. > You can't eliminate such knowledge, otherwise you won't be able to maintain such kind of relationship between morphs. You may encode it using different means, but still as i said, if you want such kind of relationship, then you have to put this dependency "knowledge" somewhere. I prefer that morph controlling own layout by himself (parent could instruct child morph to follow specific layout, but the final decision where to put itself should be up to morph iself). Because, for example, if you let parent to control the bounds of its child morphs, then you have a problem. Suppose that you have a string morph, which knows that he has fixed width and height, but its positioning could be arbitrary. So, you setting either right or left anchor: stringMorph anchorLeft: window leftAnchor. or stringMorph anchorRight: window rightAnchor. but not both, because morph could calculate the opposite edge based on its own width. Or, maybe you could do that.. You could set things up like following: | leftAnchor | leftAnchor := window leftAnchor + 10. stringMorph anchorLeft: leftAnchor. stringMorph anchorRight: leftAnchor + stringMorph widthAnchor then in this case, a position of morph is controlled by its parent, while width is maintained by himself. (a morphs which know that they having rigid width or height properties, could simply override widthAnchor/heightAnchor and maintain own constraints in this way). > Fernando -- Best regards, Igor Stasenko AKA sig.

April 8, 2011

Re: [Pharo-project] A step toward reducing complexity

by StÃ©phane Ducasse

>> is it for pharo? > > I do not know because I do not understand what the process is anymore. I tried to get a process going in which the design of UI goes through the same rigor and integration like the object-oriented design, but it did not work yet :(. You lost me there. You are talking about Glamour. > We need a project. I proposed to do this in the context of the The Glamorous Toolkit project and to integrate all these concerns, including the UI look and feel. Yes I thought that this is what you were doing. > I would offer to lead this. Right now, everyone is still pretty much working on UI by looking at smaller pieces in his own corner. That is not bad, but it is not enough. I'm talking just about the UITheme. So I was planning to rename the GLMglamour looks which is in pharo and do the refactoring but what I could do is to start from yours so that the one we use gets all your improvements. And you could load yours on the side. Stef >>> > Like small graphical issues related to the fact that GLMUITheme does no longer inherit all the helpers and effects from Watery2. > > At the moment, I basically copied some of these from Watery2 (like the management of the close/minimize/maximize) buttons.

April 8, 2011

Re: [Pharo-project] Issue 3870 in pharo: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #4 on issue 3870 by nicolas....(a)gmail.com: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew http://code.google.com/p/pharo/issues/detail?id=3870 Name: SLICE-Issue-3870-CompiledMethodTest-testNew-nice.1 Dependencies: SUnit-nice.40123, KernelTests-nice.320 Fix #testNew and a missing subclass responsibility. Also fix a duplicated protocol 'Coverage' vs 'coverage' in super class (SUnit).

April 8, 2011

Re: [Pharo-project] Issue 3870 in pharo: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew

by pharo＠googlecode.com

Comment #3 on issue 3870 by marcus.d...(a)gmail.com: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew http://code.google.com/p/pharo/issues/detail?id=3870 I think we should deprecate ClassTestCase... at the time it looked like a nice idea, but in the meantime I got convinced that for tests, less magic is better and code duplication is not a problem. So all subclasses should just implement the handfull of tests that ClassTestCase provides themselves and we remove it.

April 8, 2011

Re: [Pharo-project] Issue 3870 in pharo: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew

by pharo＠googlecode.com

Comment #2 on issue 3870 by nicolas....(a)gmail.com: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew http://code.google.com/p/pharo/issues/detail?id=3870 But that is still not enough... #selectorsToBeIgnored is itself ignored for determining the test suite... What a mess ! It seems that other subclasses do redefine #testNew...

April 8, 2011

Re: [Pharo-project] Issue 3870 in pharo: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew

by pharo＠googlecode.com

Comment #1 on issue 3870 by nicolas....(a)gmail.com: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew http://code.google.com/p/pharo/issues/detail?id=3870 First, there is a missing subclassResponsibility in CompiledMethodTest Fixing this is not enough... The aim of the failing test is to check (CompiledMethod new) which never worked and shouldn't IMO. So #testNew should be among #selectorsToBeIgnored

April 8, 2011

Re: [Pharo-project] Debugging Cog crash

by Mariano Martinez Peck

also...shouldn't be a crash/dump file somewhere? can you write the output of the console where you invoke the VM into a file ? (using > to redirect) Cheers Mariano On Thu, Apr 7, 2011 at 11:10 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Hello all, > > I have an account on an Ubuntu terminal server (at least I think that's > what it would be called) running 10.10. The Cog one-click image crashes > with "Segmentation fault" (if run from a terminal); the legacy VM seems to > run the image nicely on the box. Any ideas? I will happily collect any > facts that will be of help, but I need some > direction. > > Bill > > > > -- Mariano http://marianopeck.wordpress.com

April 8, 2011