- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Help with a crash

by Mariano Martinez Peck

On Tue, Dec 29, 2009 at 6:13 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > lead to ugly side effects in loading specific packages. Details aside, > it > > seems _really_ bad to me for the vm to crash without leaving behind any > > traces of what happened. > > This is not a VM that crashes. In fact everything is still fully > functional and running. What Mariano is seeing is the emergency > debugger, a very primitive debugger implemented in > MorphicUIManager>>onPrimitiveError: used when everything else fails. > > Thanks Lukas for the explanation. Every day I learn something new :) Now I was wondering if we can change the onPrimitiveError: to something like this: onPrimitiveError: aString | context | (String streamContents: [:s | s nextPutAll: '***System error handling failed***'. s cr; nextPutAll: aString. context := thisContext sender sender. 200 timesRepeat: [context == nil ifFalse: [s cr; print: (context := context sender)]]. s cr; nextPutAll: '-------------------------------'. s cr; nextPutAll: 'Type CR to enter an emergency evaluator.'. s cr; nextPutAll: 'Type any other character to restart.']) displayAt: 10 @ 0. [Sensor keyboardPressed] whileFalse. Sensor keyboard = Character cr ifTrue: [Transcripter emergencyEvaluator]. World install "init hands and redisplay" I just changed to 200 timesRepeat instead of 20 so that to have the full stack, or at least, more than 20 lines and also the point of displayAt: 10 @ 0. because in my case I couldn't see the first letters of the windows. If you are ok, I can put a slice in the inbox and create the issue. Thanks Mariano > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 29, 2009

Re: [Pharo-project] Help with a crash

by Lukas Renggli

> lead to ugly side effects in loading specific packages.Â Details aside, it > seems _really_ bad to me for the vm to crash without leaving behind any > traces of what happened. This is not a VM that crashes. In fact everything is still fully functional and running. What Mariano is seeing is the emergency debugger, a very primitive debugger implemented in MorphicUIManager>>onPrimitiveError: used when everything else fails. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 29, 2009

Re: [Pharo-project] Help with a crash

by Schwab,Wilhelm K

Mariano, I had a similar problem on Linux a few months ago. It turned out to be my fault, and I am not certain how much a stack trace would have helped, because the problem was in the way I originally built the image, and that lead to ugly side effects in loading specific packages. Details aside, it seems _really_ bad to me for the vm to crash without leaving behind any traces of what happened. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Tuesday, December 29, 2009 11:59 AM To: Pharo Development Subject: [Pharo-project] Help with a crash Hi folks! I am having a crash in Mac OS using Squeak 4.2.2beta1U.app when trying to swap out unactive classes. In the image it appears a windows or something like a console with just a part of the stacktrace. I attach an screenshot. In PharoDebug.log I have nothing. I even tried to run the VM from command line, but nothing is shown in the console.. I opened a MacOS Console and the only thing I see is: "12/29/09 5:54:19 PM Spotlight[217] Invalid kMDItemPath for pharo1.0-10496-rc1dev09.11.5.dbx.changes " So, how can I get the full stacktrace of that ? Thanks Mariano

Dec. 29, 2009

Re: [Pharo-project] Help with a crash

by Lukas Renggli

That's the emergency debugger. It is used when processing an error (writing the error log, opening the debugger, etc) causes another error. From the stack trace you can see that there is something wrong with the PreDebugWindow, an icon seems to be missing. Lukas 2009/12/29 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi folks! I am having a crash in Mac OSÂ using Squeak 4.2.2beta1U.appÂ when > trying to swap out unactive classes. > > In the image it appears a windows or something like a console with just a > part of the stacktrace.Â I attach an screenshot. > > In PharoDebug.log I have nothing. I even tried to run the VM from command > line, but nothing is shown in the console.. > > I opened a MacOS Console and the only thing I see is: > > "12/29/09 5:54:19 PM Spotlight[217] Invalid kMDItemPath for > pharo1.0-10496-rc1dev09.11.5.dbx.changes " > > So, how can I get the full stacktrace of that ? > > Thanks > > Mariano > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 29, 2009

Re: [Pharo-project] Pharo-project Digest, Vol 20, Issue 286

by Colin Putney

On 2009-12-29, at 8:39 AM, StÃ©phane Ducasse wrote: > Colin should we reply to you in addition than to pharo? > Lukas told me that the forge refused your email because you have your own smtp. I got that resolved, so my email should be working normally now. I'm on the pharo list, but not following it terribly closely. If there's something you need a response to CC me directly, and I'll respond to the list. Colin

Dec. 29, 2009

[Pharo-project] Help with a crash

by Mariano Martinez Peck

Hi folks! I am having a crash in Mac OS using Squeak 4.2.2beta1U.app when trying to swap out unactive classes. In the image it appears a windows or something like a console with just a part of the stacktrace. I attach an screenshot. In PharoDebug.log I have nothing. I even tried to run the VM from command line, but nothing is shown in the console.. I opened a MacOS Console and the only thing I see is: "12/29/09 5:54:19 PM Spotlight[217] Invalid kMDItemPath for pharo1.0-10496-rc1dev09.11.5.dbx.changes " So, how can I get the full stacktrace of that ? Thanks Mariano

Dec. 29, 2009

Re: [Pharo-project] Pharo-project Digest, Vol 20, Issue 286

by StÃ©phane Ducasse

On Dec 29, 2009, at 4:50 PM, Colin Putney wrote: > > On 2009-12-29, at 2:15 AM, pharo-project-request(a)lists.gforge.inria.fr wrote: > >> >>> Good point. When I have a fix for OB under pharo. What is the preferred >>> ?process. So far I posted them on the bug tracker, is that okay? >> >> OB has its bug tracker at <http://code.google.com/p/omnibrowser/>. >> >> In the past people have been committing fixes to >> http://source.wiresong.ca/ob. The problem with this approach was that >> there is no control over what got integrated. People submitted changes >> to wrong packages, untested changes, changes that broke the tests, >> changes that broke the meta-model, or changes that simply broke some >> browsers. Then people merged random branches and it was not clear what >> to load, what worked and what didn't. I don't know what the take on >> this is from Colin? > > Yes, we definitely need a little more process around this. I'm thinking of having a separate inbox repository where contributions can be made. Once a contribution had been tested, it would be promoted to the main repository. Ultimately, I'd like to have a robot do at least part of that - run the tests and either report test failures or promote the changes - but for now we can do it manually. > > Thoughts? would be cool. (I got no time to have a look at Mason). We brainstormed with henrik or I do not remember who about the same setup for validating packages for given version of pharo. Colin should we reply to you in addition than to pharo? Lukas told me that the forge refused your email because you have your own smtp. > Colin > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 29, 2009

Re: [Pharo-project] Assumptions (was Re: akuhn/SUnit, christmas edition :)

by Adrian Kuhn

Name: SUnit-AdrianKuhn.122 Author: AdrianKuhn Time: 29 December 2009, 5:14:01 pm UUID: cc99ab5b-294e-4142-a5da-baf8af550a0f Ancestors: SUnit-AdrianKuhn.120 Renamed assumptions to #skipUnless:. As suggested on mailing list renamed #assumeThat: to #skipUnless. A skipped test is marked as 'skipped' which counts as passed and is thus a green result. Also, added unconditional #skip message.

Dec. 29, 2009

[Pharo-project] pharo images - Win32 Installer

by Torsten Bergmann

>We have been discussing this and we want to be sure people understand that >1.1 is unstable and very yet in development. Yes, but I name them similar to the images they were built from (the ones Damien provides). You have to ask him to rename them first. At least I've updated the download page to: Windows Installer 1.0-10502-rc1dev09.12.2 (Pharo 1.0 RC1) Windows Installer 1.1-11112-alphadev09.12.2 (Pharo 1.1 unstable Alpha) Bye Torsten -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Dec. 29, 2009

Re: [Pharo-project] Pharo-project Digest, Vol 20, Issue 286

by Colin Putney

On 2009-12-29, at 2:15 AM, pharo-project-request(a)lists.gforge.inria.fr wrote: > >> Good point. When I have a fix for OB under pharo. What is the preferred >> ?process. So far I posted them on the bug tracker, is that okay? > > OB has its bug tracker at <http://code.google.com/p/omnibrowser/>. > > In the past people have been committing fixes to > http://source.wiresong.ca/ob. The problem with this approach was that > there is no control over what got integrated. People submitted changes > to wrong packages, untested changes, changes that broke the tests, > changes that broke the meta-model, or changes that simply broke some > browsers. Then people merged random branches and it was not clear what > to load, what worked and what didn't. I don't know what the take on > this is from Colin? Yes, we definitely need a little more process around this. I'm thinking of having a separate inbox repository where contributions can be made. Once a contribution had been tested, it would be promoted to the main repository. Ultimately, I'd like to have a robot do at least part of that - run the tests and either report test failures or promote the changes - but for now we can do it manually. Thoughts? Colin

Dec. 29, 2009