March 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: Random crashes?

by Henrik Johansen

Meh, bitten by default reply receiver... Sending it here as well in case it's of interest for others. Begin forwarded message: > From: Henrik Johansen <henrik.s.johansen(a)veloxit.no> > Date: March 30, 2011 5:10:01 PM GMT+02:00 > To: AxiNat <tibabenfortlapalanca(a)gmail.com> > Subject: Re: [Pharo-project] Random crashes? > > > On Mar 30, 2011, at 5:01 06PM, AxiNat wrote: > >> Hi Henrik and list, I was just asking how can I do the research by myself to find out where the bug comes from. >> >> Anyway, here's my config: >> >> Debian GNU/Linux wheezy/sid (testing) - Kernel version 2.6.32-5-686 >> >> CPU: Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz >> >> Smalltalk version 'Pharo1.2' >> Smalltalk vmVersion 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.35]' >> >> > Then I'd say there's probably a bug in code generation of the Cog JIT'er, seeing as how it doesn't crash right away. > Use of SSE2 instructions would be my first bet, but it looks like your processor supports those. > > First I'd try upgrading to a recent VM, .35 is really old, and there have been plenty of crash fixes since then. > > If that doesn't help, try to identify which piece of code gets JIT'ed right before the crash (using logs/a debug-built VM/gdb etc.), and try to create a reproducible test-case of the code that generates invalid instructions when JIT'ed. > > Then, submit testcase/details you just provided here to the Cog issue tracker, cross your fingers, and hope for the best :) > > Cheers, > Henry

March 30, 2011

Re: [Pharo-project] Random crashes?

by AxiNat

I was using the Cog VM shipped with the OneClick image, I'll update it right away. Thanks :) Bernat. 2011/3/30 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > On Mar 30, 2011, at 5:01 06PM, AxiNat wrote: > > > Hi Henrik and list, I was just asking how can I do the research by myself > to find out where the bug comes from. > > > > Anyway, here's my config: > > > > Debian GNU/Linux wheezy/sid (testing) - Kernel version 2.6.32-5-686 > > > > CPU: Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz > > > > Smalltalk version 'Pharo1.2' > > Smalltalk vmVersion 'Croquet Closure Cog VM [CoInterpreter > VMMaker-oscog.35]' > > > > > Then I'd say there's probably a bug in code generation of the Cog JIT'er, > seeing as how it doesn't crash right away. > Use of SSE2 instructions would be my first bet, but it looks like your > processor supports those. > > First I'd try upgrading to a recent VM, .35 is really old, and there have > been plenty of crash fixes since then. > > If that doesn't help, try to identify which piece of code gets JIT'ed right > before the crash (using logs/a debug-built VM/gdb etc.), and try to create a > reproducible test-case of the code that generates invalid instructions when > JIT'ed. > > Then, submit testcase/details you just provided here to the Cog issue > tracker, cross your fingers, and hope for the best :) > > Cheers, > Henry >

March 30, 2011

Re: [Pharo-project] Issue 3915 in pharo: Make all requests to open comparison morph (DiffMorph) go thru UIManager

by pharo＠googlecode.com

Updates: Status: FixProposed Labels: Milestone-1.3 Comment #1 on issue 3915 by marcus.d...(a)gmail.com: Make all requests to open comparison morph (DiffMorph) go thru UIManager http://code.google.com/p/pharo/issues/detail?id=3915 (No comment was entered for this change.)

March 30, 2011

Re: [Pharo-project] Random crashes?

by AxiNat

Hi Henrik and list, I was just asking how can I do the research by myself to find out where the bug comes from. Anyway, here's my config: Debian GNU/Linux wheezy/sid (testing) - Kernel version 2.6.32-5-686 CPU: Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz Smalltalk version 'Pharo1.2' Smalltalk vmVersion 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.35]' 2011/3/30 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > On Mar 30, 2011, at 4:32 25PM, AxiNat wrote: > > > Hi list, > > > > I was getting some random crashes in 1.1, so I switched to 1.2 some weeks > ago. It's been kind of stable until just today, when it started randomly > crashing again. At least the image isn't corrupted like it used to happen to > me in 1.1, but I'm wasting a lot of time recovering lost changes. > > > > The terminal just outputs "illegal hardware instruction", how could I > find out the bug's nature to fill in a bug report? > > > > Thanks! > > > > Bernat Romagosa. > > No info on OS, hardware, VM etc. you're using means you won't even getting > qualified guesses as answers to this. > > Cheers, > Henry >

March 30, 2011

Re: [Pharo-project] Random crashes?

by Henrik Johansen

On Mar 30, 2011, at 4:32 25PM, AxiNat wrote: > Hi list, > > I was getting some random crashes in 1.1, so I switched to 1.2 some weeks ago. It's been kind of stable until just today, when it started randomly crashing again. At least the image isn't corrupted like it used to happen to me in 1.1, but I'm wasting a lot of time recovering lost changes. > > The terminal just outputs "illegal hardware instruction", how could I find out the bug's nature to fill in a bug report? > > Thanks! > > Bernat Romagosa. No info on OS, hardware, VM etc. you're using means you won't even getting qualified guesses as answers to this. Cheers, Henry

March 30, 2011

[Pharo-project] Issue 3915 in pharo: Make all requests to open comparison morph (DiffMorph) go thru UIManager

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3915 by fernando...(a)gmail.com: Make all requests to open comparison morph (DiffMorph) go thru UIManager http://code.google.com/p/pharo/issues/detail?id=3915 I made all requests to comparing two methods to go thru UIManager, motivated by the need to decouple Polymorph and Morphic when choosing DiffMorph to use. I've added a setting on Polymorph also: PolymorphSystemSettings>>usePolymorphDiffMorph Attachments: DifferenceToUIManager.3.cs 8.0 KB

March 30, 2011

[Pharo-project] Random crashes?

by AxiNat

Hi list, I was getting some random crashes in 1.1, so I switched to 1.2 some weeks ago. It's been kind of stable until just today, when it started randomly crashing again. At least the image isn't corrupted like it used to happen to me in 1.1, but I'm wasting a lot of time recovering lost changes. The terminal just outputs "illegal hardware instruction", how could I find out the bug's nature to fill in a bug report? Thanks! Bernat Romagosa.

March 30, 2011

Re: [Pharo-project] who is using softSqueak and standard Squeak

by Alain Plantec

Le 30/03/2011 14:56, Helene Bilbo a Ã©crit : > Patrick Barroca wrote: >> My first look yesterday night taught me that different windows colour >> management is a basic behaviour of UITheme via #patchworkUIThemeColorFor:. >> If I simply subclass UITheme and do nothing more I get more or less a >> standard squeak theme with coloured windows minus some fills and borders >> styles. >> >> From here I think I could try to make a simple theme with the look of >> Glamourous one with support for squeak windows colour management. >> Is this the right direction ? >> > I was toying around with this yesterday. I also found methods for setting > the background of various UI elements in UITheme - but not yet for > PluggableTextMorph.. Do you know if there is a way to change the background > colors of PluggableTextMorph and OBPluggableTextMorph in UITheme? it is driven by: UITheme>>textEditorNormalFillStyleFor: aTextEditor UITheme>>textEditorDisabledFillStyleFor: aTextEditor ok in 1.3 > Or is > there a way to change the background of all UI elements in one place? afaik, not really. follow GLMUITheme class>>baseColor users, Only for the Glamour theme though. Cheers Alain > -- > View this message in context: http://forum.world.st/who-is-using-softSqueak-and-standard-Squeak-tp3407241… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

March 30, 2011

Re: [Pharo-project] who is using softSqueak and standard Squeak

by StÃ©phane Ducasse

> My first look yesterday night taught me that different windows colour management is a basic behaviour of UITheme via #patchworkUIThemeColorFor:. > If I simply subclass UITheme and do nothing more I get more or less a standard squeak theme with coloured windows minus some fills and borders styles. > > From here I think I could try to make a simple theme with the look of Glamourous one with support for squeak windows colour management. > Is this the right direction ? yes :) I plan to refactor/clean the theme package too. So if you have results let us know. Stef

March 30, 2011

Re: [Pharo-project] Loading GemTools in Pharo 1.1.1-dev

by Dario Trussardi

Veronica , if you work on Mac, consider this email from Dale : I have had trouble using GemTools on the Mac when running with a pharo version later than Pharo1.0 ... I have tried a number of different things and haven't | |figured out what is wrong, so for the MAC you need to use Pharo1.0 (that's what the GemTools one-click is based upon). Dario > Hi, > > I want to try GemStone. So I started loading GemTools in a Pharo image 1.1.1-dev without success. > An error appears when loading Metacello Browser version #development. > After that I tried to load first MetacelloBrowser and then I got the same error for OmniBrowser version #stable. > > What am I doing wrong? or do I need to use a different image? > > Regards, > Veronica

March 30, 2011