September 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Debugging aids

by StÃ©phane Ducasse

send us the code :) stef On Sep 5, 2008, at 5:45 PM, Bill Schwab wrote: > Hello all, > > Random thoughts/wishes: > > The UI discussion reminded me of a couple of things. Squeak appears > to > overwrite its debug log; minimally, I think there should be an > option to > append, and it probably should default to true. Many times, I've had > what our British friends would call a knock-on effect overwrite the > trace of the real cause of the problem. The same should apply to the > crash dump. > > The option to show call stacks (which I am not seeing on the Linux VM, > and would like to<g>), should show all non-dead threads, not simply > the > active thread. IIRC, there has been some progress on that front. > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 5, 2008

[Pharo-project] Debugging aids

by Bill Schwab

Hello all, Random thoughts/wishes: The UI discussion reminded me of a couple of things. Squeak appears to overwrite its debug log; minimally, I think there should be an option to append, and it probably should default to true. Many times, I've had what our British friends would call a knock-on effect overwrite the trace of the real cause of the problem. The same should apply to the crash dump. The option to show call stacks (which I am not seeing on the Linux VM, and would like to<g>), should show all non-dead threads, not simply the active thread. IIRC, there has been some progress on that front. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029

Sept. 5, 2008

Re: [Pharo-project] Crashing the image with polymorph in one line :)

by Gary Chambers

Attached is the crash.dmp I got on second attempt (just bombed first time with no warning)... Gary. ----- Original Message ----- From: "Adrian Lienhard" <adi(a)netstyle.ch> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> Sent: Friday, September 05, 2008 12:50 PM Subject: Re: [Pharo-project] Crashing the image with polymorph in one line :) The cause of this crash would probably be easy to detect using message send tracing in the VM. See "VM for Squeak with message sent instrumentation" on http://www.smalltalkconsulting.com/squeak.html (I once used it to debug an issue on linux but had to modify and compile my own VM because this feature is not in the VM by default). Adrian On Sep 5, 2008, at 13:32 , StÃ©phane Ducasse wrote: > I will try to find out more. > Indeed this is strange and worth reporting that to squeak-dev. > > stef > On Sep 5, 2008, at 12:24 PM, Gary Chambers wrote: > >> Hi Stef. >> >> Do you have a related crash.dmp or SqueakDebug.log file after the crash? >> >> I've tried with a 3.9 image and also get a VM crash. >> As a workaround, close all unnecessary windows/morphs then, in a class >> browser selecfte the ScrollPane class, use the halos to grab the code >> pane and place in the World desktop. Then close the class browser (code >> pane remains), make the change to the class template, select all and >> do-it. Seems ok then. >> >> I have occasionally noticed that the VM will crash when recompiling some >> morph classes while they are in use. >> >> Regards, Gary. >> >> ----- Original Message ----- From: "StÃ©phane Ducasse" >> <stephane.ducasse(a)inria.fr >> > >> To: "An open mailing list to discuss any topics related to an open- >> sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Thursday, September 04, 2008 8:05 PM >> Subject: [Pharo-project] Crashing the image with polymorph in one line >> :) >> >> >>> Hi gary >>> >>> I wanted to remove the class ComponentLikeMorph from the system. >>> So I redefined ScrollPane to be a subclass of the superclass of >>> ComponentLikeMorph >>> >>> MorphicModel subclass: #ScrollPane >>> instanceVariableNames: 'scrollBar scroller retractableScrollBar >>> scrollBarOnLeft getMenuSelector getMenuTitleSelector scrollBarHidden >>> hasFocus hScrollBar' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Morphic-Windows' >>> >>> >>> it works in pharo 64 >>> >>> but it crashes systematically the vm when polymorph is loaded. >>> >>> Stef >>> >>> _______________________________________________ >>> 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

Sept. 5, 2008

Re: [Pharo-project] Crashing the image with polymorph in one line :)

by Adrian Lienhard

The cause of this crash would probably be easy to detect using message send tracing in the VM. See "VM for Squeak with message sent instrumentation" on http://www.smalltalkconsulting.com/squeak.html (I once used it to debug an issue on linux but had to modify and compile my own VM because this feature is not in the VM by default). Adrian On Sep 5, 2008, at 13:32 , StÃ©phane Ducasse wrote: > I will try to find out more. > Indeed this is strange and worth reporting that to squeak-dev. > > stef > On Sep 5, 2008, at 12:24 PM, Gary Chambers wrote: > >> Hi Stef. >> >> Do you have a related crash.dmp or SqueakDebug.log file after the >> crash? >> >> I've tried with a 3.9 image and also get a VM crash. >> As a workaround, close all unnecessary windows/morphs then, in a >> class browser selecfte the ScrollPane class, use the halos to grab >> the code pane and place in the World desktop. Then close the class >> browser (code pane remains), make the change to the class template, >> select all and do-it. Seems ok then. >> >> I have occasionally noticed that the VM will crash when recompiling >> some morph classes while they are in use. >> >> Regards, Gary. >> >> ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr >> > >> To: "An open mailing list to discuss any topics related to an open- >> sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Thursday, September 04, 2008 8:05 PM >> Subject: [Pharo-project] Crashing the image with polymorph in one >> line :) >> >> >>> Hi gary >>> >>> I wanted to remove the class ComponentLikeMorph from the system. >>> So I redefined ScrollPane to be a subclass of the superclass of >>> ComponentLikeMorph >>> >>> MorphicModel subclass: #ScrollPane >>> instanceVariableNames: 'scrollBar scroller retractableScrollBar >>> scrollBarOnLeft getMenuSelector getMenuTitleSelector >>> scrollBarHidden hasFocus hScrollBar' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Morphic-Windows' >>> >>> >>> it works in pharo 64 >>> >>> but it crashes systematically the vm when polymorph is loaded. >>> >>> Stef >>> >>> _______________________________________________ >>> 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

Sept. 5, 2008

Re: [Pharo-project] Crashing the image with polymorph in one line :)

by StÃ©phane Ducasse

I will try to find out more. Indeed this is strange and worth reporting that to squeak-dev. stef On Sep 5, 2008, at 12:24 PM, Gary Chambers wrote: > Hi Stef. > > Do you have a related crash.dmp or SqueakDebug.log file after the > crash? > > I've tried with a 3.9 image and also get a VM crash. > As a workaround, close all unnecessary windows/morphs then, in a > class browser selecfte the ScrollPane class, use the halos to grab > the code pane and place in the World desktop. Then close the class > browser (code pane remains), make the change to the class template, > select all and do-it. Seems ok then. > > I have occasionally noticed that the VM will crash when recompiling > some morph classes while they are in use. > > Regards, Gary. > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr > > > To: "An open mailing list to discuss any topics related to an open- > sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Thursday, September 04, 2008 8:05 PM > Subject: [Pharo-project] Crashing the image with polymorph in one > line :) > > >> Hi gary >> >> I wanted to remove the class ComponentLikeMorph from the system. >> So I redefined ScrollPane to be a subclass of the superclass of >> ComponentLikeMorph >> >> MorphicModel subclass: #ScrollPane >> instanceVariableNames: 'scrollBar scroller retractableScrollBar >> scrollBarOnLeft getMenuSelector getMenuTitleSelector >> scrollBarHidden hasFocus hScrollBar' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Morphic-Windows' >> >> >> it works in pharo 64 >> >> but it crashes systematically the vm when polymorph is loaded. >> >> Stef >> >> _______________________________________________ >> 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 >

Sept. 5, 2008

Re: [Pharo-project] About UI enhancements

by Gary Chambers

----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, September 05, 2008 8:25 AM Subject: [Pharo-project] About UI enhancements > > > > Questions > ======== > > - Why the UITheme is responsible to open widgets. Why this is not the > UIManager subclass > because now a lot of the interface has to be duplicated in UITheme. > > Answer because the theme is a variation which requires more subtle > controls. > Now I have the impression that it means that the UIManager is not well > done then. > > > > - Why in the following method basicNew is used and not new (which would > call initialize anyway)? > Looks like a leftover required before the refactoring of the initialisation of FileDialogWindow... I'll check and change to just use new in these cases. > chooseDirectoryIn: aThemedMorph title: title path: path > "Answer the result of a file dialog with the given title, choosing > directories only." > > |fd| > fd := FileDialogWindow basicNew > initialize; > title: title; > answerDirectory. > path ifNotNil: [fd selectPathName: path]. > ^(aThemedMorph openModal: fd) answer > > > > > To support better integration: > ======================= > We could merge > UIManager subclasses MorphicUIManager and PSUIManager > > PSPluggableListSpec should be merged into PluggableListSpec > > > I tried to understand the difference between standardWindow and > pluggableWindow to see if it would make sense to merge them. > The "pluggable" subclasses support ToolBuilder as aside from the original classes. I guess all the pluggable variants could be merged into their superclasses and ToolBuilder pointed to the original classes. > > I started to check all the extensions and yes there are some work but > ideally removing the override would be good. > > > > > > > Stef > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 5, 2008

Re: [Pharo-project] Crashing the image with polymorph in one line :)

by Gary Chambers

Hi Stef. Do you have a related crash.dmp or SqueakDebug.log file after the crash? I've tried with a 3.9 image and also get a VM crash. As a workaround, close all unnecessary windows/morphs then, in a class browser selecfte the ScrollPane class, use the halos to grab the code pane and place in the World desktop. Then close the class browser (code pane remains), make the change to the class template, select all and do-it. Seems ok then. I have occasionally noticed that the VM will crash when recompiling some morph classes while they are in use. Regards, Gary. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, September 04, 2008 8:05 PM Subject: [Pharo-project] Crashing the image with polymorph in one line :) > Hi gary > > I wanted to remove the class ComponentLikeMorph from the system. > So I redefined ScrollPane to be a subclass of the superclass of > ComponentLikeMorph > > MorphicModel subclass: #ScrollPane > instanceVariableNames: 'scrollBar scroller retractableScrollBar > scrollBarOnLeft getMenuSelector getMenuTitleSelector scrollBarHidden > hasFocus hScrollBar' > classVariableNames: '' > poolDictionaries: '' > category: 'Morphic-Windows' > > > it works in pharo 64 > > but it crashes systematically the vm when polymorph is loaded. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 5, 2008

Re: [Pharo-project] How to contribute

by StÃ©phane Ducasse

>> Hi all >> >> if you want to help pharo, it would be good to: >> - go over some of the messages I sent to the mailinglist and turn >> some of the points >> as issue >> - from memory I see the extensions of keith of kernel >> - the fixes of nicolas >> - fixing Author initials to get real name instead + a license >> - enhance DrDoc. >> - Run SmallLint on some packages. >> - take some issues and fix them. >> - helping for the integration server. >> >> This afternoon I will empty the inbox. >> Marcus how can we help for the NewCompiler? > > The next step seems to be to take the closure stuff of Eliot and > merge it into Pharo. > The problem is that we would need new VMs for that... and one can > not even start > to do anything until this is done. So may be the first step is to - check vm building who can build what I imagine that we will have the same problem with the TTF and freetype support. Am'I correct? in parallel - make sure that NewCompiler is ready to replace the oldCompiler >> Do you have a roadmap? > > -> Eliot's closures in the image. > -> port NewCompiler to emit code for this closure implementation > -> clean up newcompiler. Remove non-closure hacks > -> Evaluate to use the old parser as an alternative frontend. > > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 5, 2008

Re: [Pharo-project] How to contribute

by Alexandre Bergel

> - helping for the integration server. I am currently working on this. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 5, 2008

Re: [Pharo-project] How to contribute

by Marcus Denker

On 05.09.2008, at 09:08, StÃ©phane Ducasse wrote: > Hi all > > if you want to help pharo, it would be good to: > - go over some of the messages I sent to the mailinglist and turn > some of the points > as issue > - from memory I see the extensions of keith of kernel > - the fixes of nicolas > - fixing Author initials to get real name instead + a license > - enhance DrDoc. > - Run SmallLint on some packages. > - take some issues and fix them. > - helping for the integration server. > > This afternoon I will empty the inbox. > Marcus how can we help for the NewCompiler? The next step seems to be to take the closure stuff of Eliot and merge it into Pharo. The problem is that we would need new VMs for that... and one can not even start to do anything until this is done. > > Do you have a roadmap? > -> Eliot's closures in the image. -> port NewCompiler to emit code for this closure implementation -> clean up newcompiler. Remove non-closure hacks -> Evaluate to use the old parser as an alternative frontend. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 5, 2008