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

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by David T. Lewis

On Sun, Feb 22, 2009 at 01:47:40PM +0100, Bruce O'Neel wrote: > > I downloaded Ian's image/changes bundle named unix-3.10-4.vmm.tar.gz from http://www.squeakvm.org/unix/ > and looked into it a bit. > > In ObjectMemory biasToGrow it looks like the problem is > > biasToGrow > | growSize | > growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock) > self growObjectMemory: growSize > > there are no '.'s after the lines. Shouldn't it look like: > > biasToGrow > | growSize | > growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock). > self growObjectMemory: growSize. > > that? > > It looks like the slang interpreter/translater must be coughing a bit on what is basically > slight invalid syntax, right? This is http://bugs.squeak.org/view.php?id=6667. The fix was applied to VMMaker-tpr.63. You are probably using sources generated from VMMaker 3.8b6, which is the same as VMMaker-tpr.58, so the sources you are using would not have this fix. If someone can build a VM using more up to date VMMaker and verify that the problem goes away, that would be good. I suggest using VMMaker-dtl.113 from the VMMaker project on SqueakSource for this. (Note, there is a more recent VMMaker-eem.114 that contains Eliot's updates for block closures, but you may have trouble loading it into some Squeak/Pharo images. The glitch may be sorted out by the time you read this, if not just stick with VMMaker-dtl.113 or earlier for now.) > > I guess that next up I have to figure out how to actually run vm maker :-) > Yes :) Dave

Feb. 22, 2009

Re: [Pharo-project] Shadow in Watery2

by Alexandre Bergel

If this would help grabbing and dragging windows faster, I would use it. Alexandre On 22 Feb 2009, at 14:43, Rob Rothwell wrote: > For that, I would ask "is it worth it?" How many users are just > going to turn on the fastDragWindowForMorphic preference anyway?! > > For some reason that little delay when you grab a window to move it > always prompts me to do so! > > Just my thought on the matter... > > Take care, > > Rob > > On Sun, Feb 22, 2009 at 7:10 AM, Gary Chambers <gazzaguru2(a)btinternet.com > > wrote: > Yeah, the ordinary drop shadow was quite simple to implement. > Hand-grabbed drop shadows are altogether much nastier! > Not impossible but would require some evil hacking. > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 21, 2009 1:58 PM > Subject: Re: [Pharo-project] Shadow in Watery2 > > > > 2009/2/21 Marcus Denker <denker(a)iam.unibe.ch>: > >> Gary, > >> > >> Watery2 looks better and better :-) Great! > >> > >> One question regarding the shadow: Now the active window has > >> a translucent shadow (like macos), very nice. > >> > >> But it's turned off and replaced with the hard non-translucend > >> Morphic shadow while moving the window. > >> Would it be possible to render the same shadow, even wen picking > >> up windows? This would result in a much smoother apperance, and I > >> think it even would feel faster. > >> > > Good luck with that.. For shadow when picking up responds the hand > morph.. > > There is quite sophisticated logic which caching the morph > appearance > > when its in hand.. along with shadow. > > I tried to reproduce this effect on my GLCanvas, but found it > > impossible to do without support of render buffers extension :) > > > >> Marcus > >> > >> -- > >> Marcus Denker -- denker(a)acm.org > >> http://www.marcusdenker.de > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > _______________________________________________ > > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 22, 2009

Re: [Pharo-project] Shadow in Watery2

by Igor Stasenko

2009/2/22 Rob Rothwell <r.j.rothwell(a)gmail.com>: > For that, I would ask "is it worth it?" How many users are just going to > turn on the fastDragWindowForMorphic preference anyway?! > > For some reason that little delay when you grab a window to move it always > prompts me to do so! > > Just my thought on the matter... > Well, of course its not worth doing. On my place, i would delete all shadowing logic/support at all :) But for keeping consistency , i think this is the right way to make shadows working similar for all cases. > Take care, > > Rob > > On Sun, Feb 22, 2009 at 7:10 AM, Gary Chambers <gazzaguru2(a)btinternet.com> > wrote: >> >> Yeah, the ordinary drop shadow was quite simple to implement. >> Hand-grabbed drop shadows are altogether much nastier! >> Not impossible but would require some evil hacking. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Igor Stasenko" <siguctua(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Saturday, February 21, 2009 1:58 PM >> Subject: Re: [Pharo-project] Shadow in Watery2 >> >> >> > 2009/2/21 Marcus Denker <denker(a)iam.unibe.ch>: >> >> Gary, >> >> >> >> Watery2 looks better and better :-) Great! >> >> >> >> One question regarding the shadow: Now the active window has >> >> a translucent shadow (like macos), very nice. >> >> >> >> But it's turned off and replaced with the hard non-translucend >> >> Morphic shadow while moving the window. >> >> Would it be possible to render the same shadow, even wen picking >> >> up windows? This would result in a much smoother apperance, and I >> >> think it even would feel faster. >> >> >> > Good luck with that.. For shadow when picking up responds the hand >> > morph.. >> > There is quite sophisticated logic which caching the morph appearance >> > when its in hand.. along with shadow. >> > I tried to reproduce this effect on my GLCanvas, but found it >> > impossible to do without support of render buffers extension :) >> > >> >> Marcus >> >> >> >> -- >> >> Marcus Denker -- denker(a)acm.org >> >> http://www.marcusdenker.de >> >> >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko AKA sig. >> > >> > _______________________________________________ >> > 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 22, 2009

Re: [Pharo-project] Shadow in Watery2

by Rob Rothwell

For that, I would ask "is it worth it?" How many users are just going to turn on the fastDragWindowForMorphic preference anyway?! For some reason that little delay when you grab a window to move it always prompts me to do so! Just my thought on the matter... Take care, Rob On Sun, Feb 22, 2009 at 7:10 AM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > Yeah, the ordinary drop shadow was quite simple to implement. > Hand-grabbed drop shadows are altogether much nastier! > Not impossible but would require some evil hacking. > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 21, 2009 1:58 PM > Subject: Re: [Pharo-project] Shadow in Watery2 > > > > 2009/2/21 Marcus Denker <denker(a)iam.unibe.ch>: > >> Gary, > >> > >> Watery2 looks better and better :-) Great! > >> > >> One question regarding the shadow: Now the active window has > >> a translucent shadow (like macos), very nice. > >> > >> But it's turned off and replaced with the hard non-translucend > >> Morphic shadow while moving the window. > >> Would it be possible to render the same shadow, even wen picking > >> up windows? This would result in a much smoother apperance, and I > >> think it even would feel faster. > >> > > Good luck with that.. For shadow when picking up responds the hand > morph.. > > There is quite sophisticated logic which caching the morph appearance > > when its in hand.. along with shadow. > > I tried to reproduce this effect on my GLCanvas, but found it > > impossible to do without support of render buffers extension :) > > > >> Marcus > >> > >> -- > >> Marcus Denker -- denker(a)acm.org > >> http://www.marcusdenker.de > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > _______________________________________________ > > 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 >

Feb. 22, 2009

Re: [Pharo-project] Question about Morphic

by Alexandre Bergel

> canvas isVisible: aRectangle You great Man Igor, spaciba Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 22, 2009

Re: [Pharo-project] [update] #10241

by Adrian Lienhard

I'm debugging it right now. What you see are only secondary symptoms because the debugger cannot read the sources anymore because the source pointers have already been modified but the sources file is still the old one... To avoid this and still see the problem, modify #moveChangesTo: to not move the source (moveSource: false). The actual problem seems to be related to UTF8 conversion or stream positioning (UTF8TextConverter>>errorMalformedInput). Backlog attached. Adrian On Feb 22, 2009, at 14:00 , StÃ©phane Ducasse wrote: > I added a trace in condenseChanges > > > PluggableTabBarMorph > PluggableTabButtonMorph > PluggableTextAttribute > PluggableTextEditorMorph > PluggableTextFieldMorph > PluggableTextMorph > (and is Undeclared) (See is Undeclared) (Unless is Undeclared) > (works is Undeclared) (Portions is Undeclared) (Copyright is > Undeclared) > > > > Stef > > On Feb 22, 2009, at 1:50 PM, StÃ©phane Ducasse wrote: > >> I tried >> - to recompile the method licenseString on Smalltalk >> - remove it completely from the system >> >> I still get the same problem >> >> Stef >> >> On Feb 22, 2009, at 12:21 PM, StÃ©phane Ducasse wrote: >> >>> Adrian in 10241 when i did Smalltalk condenseChanges >>> >>> I got a ClassDescription >>> >>> syntax error on the license >>> >>> >>> " >>> use and modification subject to a liberal open source license. See >>> the main Squeak website for details. Unless stated to the contrary, >>> works submitted for incorporation into or for distribution with >>> Squeak >>> shall be presumed subject to the same license. >>> >>> Portions of Squeak are: >>> >>> Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. >>> Copyright (c) 1997-2001 Walt Disney Company, and/or >>> Copyrighted works of many other contributors. >>> All rights reserved. >>> ' >>> >>> " >>> >>> I think that fixing the condensing is the next key items since now >>> we >>> cannot work with Moose anymore. The changeset is getting too close >>> to >>> the limit. >>> >>> Stef >>> >>> >>> On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: >>> >>>> #10241 >>>> >>>> Issue 167: >>>> - Traits implementation refactoring (no sharing of compiled methods >>>> and source) >>>> - New tests for Traits MOP >>>> >>>> >>>> Since this changes the handling of sources, the following issues >>>> with >>>> condensing changes may be resolved: >>>> http://code.google.com/p/pharo/issues/detail?id=466 >>>> http://code.google.com/p/pharo/issues/detail?id=470 >>>> >>>> Can somebody check these issues? >>>> >>>> Adrian >>>> ___________________ >>>> http://www.adrian-lienhard.ch/ >>>> >>>> >>>> _______________________________________________ >>>> 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

Feb. 22, 2009

Re: [Pharo-project] [update] #10241

by StÃ©phane Ducasse

I tried again and got another stop not at the same place in paragraphEditor The key problem right now is that this crappy compiler does not raise exception but open pops.... Stef On Feb 22, 2009, at 2:00 PM, StÃ©phane Ducasse wrote: > I added a trace in condenseChanges > > > PluggableTabBarMorph > PluggableTabButtonMorph > PluggableTextAttribute > PluggableTextEditorMorph > PluggableTextFieldMorph > PluggableTextMorph > (and is Undeclared) (See is Undeclared) (Unless is Undeclared) > (works is Undeclared) (Portions is Undeclared) (Copyright is > Undeclared) > > > > Stef > > On Feb 22, 2009, at 1:50 PM, StÃ©phane Ducasse wrote: > >> I tried >> - to recompile the method licenseString on Smalltalk >> - remove it completely from the system >> >> I still get the same problem >> >> Stef >> >> On Feb 22, 2009, at 12:21 PM, StÃ©phane Ducasse wrote: >> >>> Adrian in 10241 when i did Smalltalk condenseChanges >>> >>> I got a ClassDescription >>> >>> syntax error on the license >>> >>> >>> " >>> use and modification subject to a liberal open source license. See >>> the main Squeak website for details. Unless stated to the contrary, >>> works submitted for incorporation into or for distribution with >>> Squeak >>> shall be presumed subject to the same license. >>> >>> Portions of Squeak are: >>> >>> Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. >>> Copyright (c) 1997-2001 Walt Disney Company, and/or >>> Copyrighted works of many other contributors. >>> All rights reserved. >>> ' >>> >>> " >>> >>> I think that fixing the condensing is the next key items since now >>> we >>> cannot work with Moose anymore. The changeset is getting too close >>> to >>> the limit. >>> >>> Stef >>> >>> >>> On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: >>> >>>> #10241 >>>> >>>> Issue 167: >>>> - Traits implementation refactoring (no sharing of compiled methods >>>> and source) >>>> - New tests for Traits MOP >>>> >>>> >>>> Since this changes the handling of sources, the following issues >>>> with >>>> condensing changes may be resolved: >>>> http://code.google.com/p/pharo/issues/detail?id=466 >>>> http://code.google.com/p/pharo/issues/detail?id=470 >>>> >>>> Can somebody check these issues? >>>> >>>> Adrian >>>> ___________________ >>>> http://www.adrian-lienhard.ch/ >>>> >>>> >>>> _______________________________________________ >>>> 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 >

Feb. 22, 2009

Re: [Pharo-project] [update] #10241

by StÃ©phane Ducasse

I added a trace in condenseChanges PluggableTabBarMorph PluggableTabButtonMorph PluggableTextAttribute PluggableTextEditorMorph PluggableTextFieldMorph PluggableTextMorph (and is Undeclared) (See is Undeclared) (Unless is Undeclared) (works is Undeclared) (Portions is Undeclared) (Copyright is Undeclared) Stef On Feb 22, 2009, at 1:50 PM, StÃ©phane Ducasse wrote: > I tried > - to recompile the method licenseString on Smalltalk > - remove it completely from the system > > I still get the same problem > > Stef > > On Feb 22, 2009, at 12:21 PM, StÃ©phane Ducasse wrote: > >> Adrian in 10241 when i did Smalltalk condenseChanges >> >> I got a ClassDescription >> >> syntax error on the license >> >> >> " >> use and modification subject to a liberal open source license. See >> the main Squeak website for details. Unless stated to the contrary, >> works submitted for incorporation into or for distribution with >> Squeak >> shall be presumed subject to the same license. >> >> Portions of Squeak are: >> >> Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. >> Copyright (c) 1997-2001 Walt Disney Company, and/or >> Copyrighted works of many other contributors. >> All rights reserved. >> ' >> >> " >> >> I think that fixing the condensing is the next key items since now we >> cannot work with Moose anymore. The changeset is getting too close to >> the limit. >> >> Stef >> >> >> On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: >> >>> #10241 >>> >>> Issue 167: >>> - Traits implementation refactoring (no sharing of compiled methods >>> and source) >>> - New tests for Traits MOP >>> >>> >>> Since this changes the handling of sources, the following issues >>> with >>> condensing changes may be resolved: >>> http://code.google.com/p/pharo/issues/detail?id=466 >>> http://code.google.com/p/pharo/issues/detail?id=470 >>> >>> Can somebody check these issues? >>> >>> Adrian >>> ___________________ >>> http://www.adrian-lienhard.ch/ >>> >>> >>> _______________________________________________ >>> 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 >

Feb. 22, 2009

Re: [Pharo-project] [update] #10241

by StÃ©phane Ducasse

I tried - to recompile the method licenseString on Smalltalk - remove it completely from the system I still get the same problem Stef On Feb 22, 2009, at 12:21 PM, StÃ©phane Ducasse wrote: > Adrian in 10241 when i did Smalltalk condenseChanges > > I got a ClassDescription > > syntax error on the license > > > " > use and modification subject to a liberal open source license. See > the main Squeak website for details. Unless stated to the contrary, > works submitted for incorporation into or for distribution with Squeak > shall be presumed subject to the same license. > > Portions of Squeak are: > > Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. > Copyright (c) 1997-2001 Walt Disney Company, and/or > Copyrighted works of many other contributors. > All rights reserved. > ' > > " > > I think that fixing the condensing is the next key items since now we > cannot work with Moose anymore. The changeset is getting too close to > the limit. > > Stef > > > On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: > >> #10241 >> >> Issue 167: >> - Traits implementation refactoring (no sharing of compiled methods >> and source) >> - New tests for Traits MOP >> >> >> Since this changes the handling of sources, the following issues with >> condensing changes may be resolved: >> http://code.google.com/p/pharo/issues/detail?id=466 >> http://code.google.com/p/pharo/issues/detail?id=470 >> >> Can somebody check these issues? >> >> Adrian >> ___________________ >> http://www.adrian-lienhard.ch/ >> >> >> _______________________________________________ >> 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 >

Feb. 22, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by Bruce O'Neel

Hi, I downloaded Ian's image/changes bundle named unix-3.10-4.vmm.tar.gz from http://www.squeakvm.org/unix/ and looked into it a bit. In ObjectMemory biasToGrow it looks like the problem is biasToGrow | growSize | growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock) self growObjectMemory: growSize there are no '.'s after the lines. Shouldn't it look like: biasToGrow | growSize | growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock). self growObjectMemory: growSize. that? It looks like the slang interpreter/translater must be coughing a bit on what is basically slight invalid syntax, right? I guess that next up I have to figure out how to actually run vm maker :-) cheers bruce On Fri, Feb 20, 2009 at 12:32:52PM +0100, Bruce O'Neel wrote: > > Hi, > > Um, yes, I know you've discussed this before, but.... > > I'm not sure it's just a gcc 4.3.2 problem. > > I downloaded and poked at the tar file of 3.10-4's source. I got this from > http://squeakvm.org/unix/. > > The error message comes from uxGrowMemoryBy, but, I think it comes from > being called (two frames higher) in incrementalGC. > > The code is (from the gnu-interp.c file, though interp.c is the same): > > if (((((usqInt) ((longAt(foo->freeBlock)) & AllButTypeMask))) < (((usqInt) foo->growHeadroom))) && (foo->gcBiasToGrow > 0)) { > /* begin biasToGrow */ > /* begin growObjectMemory: */ > foo->statGrowMemory += 1; > limit = sqGrowMemoryBy(foo->memoryLimit, growSize); > if (!(limit == foo->memoryLimit)) { > foo->memoryLimit = limit - 24; > initializeMemoryFirstFree(foo->freeBlock); > } > weDidGrow = 1; > } > > So we call sqGrowMemoryBy with growSize which is used to calculate newDelta in uxGrowMemoryBy. > > A search of incrementalGC though shows that growSize, a sqInt is declared it's never set. > It turns out that with my system (Debian Lenny ppc, with gcc 4.3.2) growSize is zeroed. > Maybe that's the 'problem' with gcc 4.3.2? > > If I set it to some number, say, 100000, then a print statement just before > sqGrowMemoryBy comes out and squeak grows its memory, and, volia, no crash. > > Now, this might just be bypassing the real problem, but, it's unclear to me how > an uninitialized growSize would be a good idea. > > This also explains why my previous workaround, using the flag -memory on the command line, > caused the problem to not occur. > > cheers > > bruce > > On Thu, Feb 19, 2009 at 09:18:49AM -0800, John M McIntosh wrote: > > look in the archive and on the vm-dev list I think people agree this > > is a gcc 4.3 issue. > > > > On 19-Feb-09, at 4:15 AM, Bruce O'Neel wrote: > > > > > Hi, > > > > > > Is it possible this error? > > > > > > sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0` failed. > > > Aborted > > > > > > I get this following the procedure below on a Debian Lenny PPC > > > system with Squeak 3.10-4. > > > Gcc is 4.3.2. I do not get this on a Ubuntu hardy ppc system with > > > the same version of squeak. > > > Gcc is slightly older at 4.2.3. > > > > > > I've worked around this, for the moment, by adding -memory 200m to > > > the squeak > > > command line. > > > > > > I spent some weekend debugging this, but, I didn't find where the > > > problem it is comes > > > from. > > > > > > cheers > > > > > > bruce > > > > -- > > = > > = > > = > > ======================================================================== > > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > > = > > = > > = > > ======================================================================== > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 22, 2009