December 2009 - Pharo-dev - lists.pharo.org

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

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

by Colin Putney

On 2009-12-28, at 7:10 PM, pharo-project-request(a)lists.gforge.inria.fr wrote: >>> >>> Right now, in our Pharo images we are loading the following packages from >>> http://source.wiresong.ca/ob >> >> AFAIK, the updated code from >> http://source.lukas-renggli.ch/omnibrowser hasn't been merged into the >> repository of Colin yet. I assume that will happen sometime soon. >> >> > > Colin: Right now we are building our official Pharo images using > http://source.wiresong.ca/ob repository, not > http://source.lukas-renggli.ch/omnibrowser > > Do you think that this can be merged ? Yes. I definitely want to have a new release that includes all of Lukas' latest work, pulled from the wiresong repository. I'm just a bit bogged down in Real Life at the moment. :-) Colin

Dec. 29, 2009

Re: [Pharo-project] Tests of OmniBrowser

by Colin Putney

On Mon, 28 Dec 2009, Lukas Renggli wrote: > >>> There are more related to the packages we are including? >> >> No. Only the core bits of OB are tested. There aren't any tests for the refactoring code or Shout. > > The refactoring code is quite well tested with the tests of the > refactoring engine. The thing that is not tested is the RB integration > in OB: hounders of new commands and a couple of extra browsers. I am > sorry, I was too lazy to write these tests. > > Lukas Oh, of course, I should have mentioned this in my reply to Mariano. If you're running a test suite to ensure that OB is working, it should include all the Refactory tests. BTW, no disrespect intended. I'm very glad to have refactoring integration in OB, tests or no tests! Colin

Dec. 29, 2009