- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Getting my head around low space

by Levente Uzonyi

On Sat, 9 Oct 2010, Max Leske wrote: > I'm actually working on a mac, so that shouldn't be the problem. > So your proposition to use -mmap would be unix specific? Is the option available on mac? I don't have a Mac, but you can easily check it by starting an image with "-mmap 64m", then allocating a 64MB array in the image. If it fails, then the switch works, otherwise not. Levente > > Thanks, > Max > > > On 09.10.2010, at 21:34, Levente Uzonyi wrote: > >> On Sat, 9 Oct 2010, Adrian Lienhard wrote: >> >>> The unix VM and apparently also the Mac VM has an option -memory that allows you to set a heap size: >>> >>> [adrian:/Applications/Squeak 4.2.3beta1U.app/Contents/MacOS] ./Squeak\ VM\ Opt -help >>> Usage: ./Squeak VM Opt [<option>...] [<imageName> [<argument>...]] >>> ./Squeak VM Opt [<option>...] -- [<argument>...] >>> >>> Common <option>s: >>> -help print this help message, then exit >>> -memory <size>[mk] use fixed heap size (added to image size) >>> -pathenc <enc> set encoding for pathnames (default: macintosh) >>> -headless run in headless (no window) mode (default: false) >>> >>> Notes: >>> <imageName> defaults to `Squeak.image'. >>> If `-memory' is not specified then the heap will grow dynamically. >>> <argument>s are ignored, but are processed by the Squeak image. >>> The first <argument> normally names a Squeak `script' to execute. >>> Precede <arguments> by `--' to use default image. >> >> This is ok for Mac, but the unix VM takes different arguments. >> >> >> Levente >> >>> >>> >>> HTH, >>> Adrian >>> >>> On Oct 9, 2010, at 18:01 , Max Leske wrote: >>> >>>> Hi >>>> >>>> I'm having trouble with low space warnings in Pharo. Is there a source on how much memory the image can get from the OS? Is there maybe a way to up that limit? I am loading a lot of data into the image and the limit at the moment seems to be around 500 MB. >>>> >>>> Thanks for any ideas. >>>> >>>> Cheers, >>>> Max >>>> _______________________________________________ >>>> 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 >

Oct. 10, 2010

Re: [Pharo-project] Xtreams : first embryonary port on Squeak

by Schwab,Wilhelm K

FWIW, SIF might help you: http://www.pocketsmalltalk.com/sif/ I have put a lot of code through it in the past couple of years. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Saturday, October 09, 2010 6:33 PM To: The general-purpose Squeak developers list; Pharo Development; vwnc(a)cs.uiuc.edu Subject: [Pharo-project] Xtreams : first embryonary port on Squeak So, I started a quick port of VW Xtreams to Squeak this evening. Only the Xtreams-Core and the trivial Xtreams-Terminals (no file/pipe/socket/pointer). You'll find code at http://www.squeaksource.com/XTream. My previous experimental Xtream project has been renamed SqueaXTream to reduce confusion, but still sits in the same project. Please find my report below. cheers Nicolas --------------------- REPORT --------------------- THE CONTENTS: This first port is made of 3 packages - Xtreams-Core - Xtreams-Terminals - Xtreams-VWCompatible Plus 2 tests - Xtreams-CoreTests - Xtreams-TerminalsTests Please notice I removed one hyphen from test package names for MC compatibility. THE PROCEDURE: I didn't use FileOut30 not any more advanced tool, but just a simple copy/paste strategy. This gave me a chance to do a fast review of code. For porting the future evolutions of VW Xtreams, more advanced tools will be necessary, the manual approach does not scale. THE MODIFICATIONS: The changes I made are quite restricted, which indicates that Xtreams is not that hard to port. Main changes are due to lack of namespace in Squeak: - I added a XT prefix to every Xtreams classes (no Namespace in Squeak) - I added XTPools, a SharedPool for holding the single Xtreams namespace variable DefaultBufferSize - I transformed class SharedVariables into class variables and added proper class side initialization for these in XTWriteStream For the rest, I tried to not change Xtreams contents. but rather did implement VW compatible messages when possible in the Xtreams-VWCompatible package when they did not exist in Squeak. These message are a full rewrite and are also released under MIT license. The few exceptions are: - I modified originator -> self originator in XTIncomplete. - I changed the senders of #newInFixedSpace: to rather send an #error: 'not implemented in Squeak' in XTRecyclingBuffer - I replaced #waitIfCurtailedSignal/#signal with a #critical: section in XTRecyclingBuffer - I replaced Core.Timer after:do: with self after:do: in Xtreams-CoreTests A DISCUSSION OF TECHNICAL DETAILS: I first attempted to replace #growToAtLeast: with #grownBy: because Squeak become: is notoriously inefficient. But obviously, this did not work, the tests rely on destination preserving its identity. This clearly is going to degrade micro benchmarks when the destination collection capacity is not well adjusted in advance. I think we should discuss this particular point. Is identity preservation absolutely required, or just convenient ? THE STATUS OF TESTS: Tests do not all pass. There seems to be a bug in Squeak #replace:from:to:with: when the replacement is the collection itself, moved to the right (this is with a COG VM). THE FUTURE: I will probably continue porting with reduced activity, so I invite any interested person to help. Right now, the project is world writeable, code commited here falling under MIT license. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010

Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak

by Levente Uzonyi

On Sun, 10 Oct 2010, Nicolas Cellier wrote: > So, I started a quick port of VW Xtreams to Squeak this evening. > Only the Xtreams-Core and the trivial Xtreams-Terminals (no > file/pipe/socket/pointer). > You'll find code at http://www.squeaksource.com/XTream. > My previous experimental Xtream project has been renamed SqueaXTream > to reduce confusion, but still sits in the same project. > Please find my report below. Great. :) > > cheers > > Nicolas > > --------------------- REPORT --------------------- > > THE CONTENTS: > > This first port is made of 3 packages > - Xtreams-Core > - Xtreams-Terminals > - Xtreams-VWCompatible > Plus 2 tests > - Xtreams-CoreTests > - Xtreams-TerminalsTests > Please notice I removed one hyphen from test package names for MC compatibility. > > THE PROCEDURE: > > I didn't use FileOut30 not any more advanced tool, but just a simple > copy/paste strategy. > This gave me a chance to do a fast review of code. > For porting the future evolutions of VW Xtreams, more advanced tools > will be necessary, the manual approach does not scale. If you can create a diff from the VW changes, then porting "by hand" shouldn't be hard. > > THE MODIFICATIONS: > > The changes I made are quite restricted, which indicates that Xtreams > is not that hard to port. > Main changes are due to lack of namespace in Squeak: > - I added a XT prefix to every Xtreams classes (no Namespace in Squeak) > - I added XTPools, a SharedPool for holding the single Xtreams > namespace variable DefaultBufferSize > - I transformed class SharedVariables into class variables and added > proper class side initialization for these in XTWriteStream > > For the rest, I tried to not change Xtreams contents. but rather did > implement VW compatible messages when possible in the > Xtreams-VWCompatible package when they did not exist in Squeak. > These message are a full rewrite and are also released under MIT license. > The few exceptions are: > - I modified originator -> self originator in XTIncomplete. > - I changed the senders of #newInFixedSpace: to rather send an #error: > 'not implemented in Squeak' in XTRecyclingBuffer > - I replaced #waitIfCurtailedSignal/#signal with a #critical: section > in XTRecyclingBuffer > - I replaced Core.Timer after:do: with self after:do: in Xtreams-CoreTests > > A DISCUSSION OF TECHNICAL DETAILS: > > I first attempted to replace #growToAtLeast: with #grownBy: because > Squeak become: is notoriously inefficient. > But obviously, this did not work, the tests rely on destination > preserving its identity. > This clearly is going to degrade micro benchmarks when the destination > collection capacity is not well adjusted in advance. > I think we should discuss this particular point. Is identity > preservation absolutely required, or just convenient ? I've never seen a real world example where this identity preservation was useful, but it causes trouble when literals aren't immutable. IMHO the #become: send is just convenient with VW's stream implementation and it has no advantage over Squeak's approach. > > THE STATUS OF TESTS: > > Tests do not all pass. There seems to be a bug in Squeak > #replace:from:to:with: when the replacement is the collection itself, > moved to the right (this is with a COG VM). #replace:from:to:with: is not supposed to work for moves. IIRC the primitive version uses memcpy (or strncpy), so moving to the left works just because the undelying C function supports it. I used to (ab)use this feature though. Levente > > THE FUTURE: > > I will probably continue porting with reduced activity, so I invite > any interested person to help. Right now, the project is world > writeable, code commited here falling under MIT license. > >

Oct. 10, 2010

Re: [Pharo-project] Getting my head around low space

by Mariano Martinez Peck

On Sat, Oct 9, 2010 at 9:58 PM, Max Leske <maxleske(a)gmail.com> wrote: > I'm actually working on a mac, so that shouldn't be the problem. > So your proposition to use -mmap would be unix specific? Is the option > available on mac? > I think you can also modify the file Info.plist. Take the squeak app, right click, show package contents. There go to "Contents" and there you will find such file. There, you can change the property SqueakMaxHeapSize. Put 2 gb or whatever you want. Cheers Mariano > > Thanks, > Max > > > On 09.10.2010, at 21:34, Levente Uzonyi wrote: > > > On Sat, 9 Oct 2010, Adrian Lienhard wrote: > > > >> The unix VM and apparently also the Mac VM has an option -memory that > allows you to set a heap size: > >> > >> [adrian:/Applications/Squeak 4.2.3beta1U.app/Contents/MacOS] ./Squeak\ > VM\ Opt -help > >> Usage: ./Squeak VM Opt [<option>...] [<imageName> [<argument>...]] > >> ./Squeak VM Opt [<option>...] -- [<argument>...] > >> > >> Common <option>s: > >> -help print this help message, then exit > >> -memory <size>[mk] use fixed heap size (added to image size) > >> -pathenc <enc> set encoding for pathnames (default: macintosh) > >> -headless run in headless (no window) mode (default: false) > >> > >> Notes: > >> <imageName> defaults to `Squeak.image'. > >> If `-memory' is not specified then the heap will grow dynamically. > >> <argument>s are ignored, but are processed by the Squeak image. > >> The first <argument> normally names a Squeak `script' to execute. > >> Precede <arguments> by `--' to use default image. > > > > This is ok for Mac, but the unix VM takes different arguments. > > > > > > Levente > > > >> > >> > >> HTH, > >> Adrian > >> > >> On Oct 9, 2010, at 18:01 , Max Leske wrote: > >> > >>> Hi > >>> > >>> I'm having trouble with low space warnings in Pharo. Is there a source > on how much memory the image can get from the OS? Is there maybe a way to up > that limit? I am loading a lot of data into the image and the limit at the > moment seems to be around 500 MB. > >>> > >>> Thanks for any ideas. > >>> > >>> Cheers, > >>> Max > >>> _______________________________________________ > >>> 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 >

Oct. 9, 2010

[Pharo-project] Xtreams : first embryonary port on Squeak

by Nicolas Cellier

So, I started a quick port of VW Xtreams to Squeak this evening. Only the Xtreams-Core and the trivial Xtreams-Terminals (no file/pipe/socket/pointer). You'll find code at http://www.squeaksource.com/XTream. My previous experimental Xtream project has been renamed SqueaXTream to reduce confusion, but still sits in the same project. Please find my report below. cheers Nicolas --------------------- REPORT --------------------- THE CONTENTS: This first port is made of 3 packages - Xtreams-Core - Xtreams-Terminals - Xtreams-VWCompatible Plus 2 tests - Xtreams-CoreTests - Xtreams-TerminalsTests Please notice I removed one hyphen from test package names for MC compatibility. THE PROCEDURE: I didn't use FileOut30 not any more advanced tool, but just a simple copy/paste strategy. This gave me a chance to do a fast review of code. For porting the future evolutions of VW Xtreams, more advanced tools will be necessary, the manual approach does not scale. THE MODIFICATIONS: The changes I made are quite restricted, which indicates that Xtreams is not that hard to port. Main changes are due to lack of namespace in Squeak: - I added a XT prefix to every Xtreams classes (no Namespace in Squeak) - I added XTPools, a SharedPool for holding the single Xtreams namespace variable DefaultBufferSize - I transformed class SharedVariables into class variables and added proper class side initialization for these in XTWriteStream For the rest, I tried to not change Xtreams contents. but rather did implement VW compatible messages when possible in the Xtreams-VWCompatible package when they did not exist in Squeak. These message are a full rewrite and are also released under MIT license. The few exceptions are: - I modified originator -> self originator in XTIncomplete. - I changed the senders of #newInFixedSpace: to rather send an #error: 'not implemented in Squeak' in XTRecyclingBuffer - I replaced #waitIfCurtailedSignal/#signal with a #critical: section in XTRecyclingBuffer - I replaced Core.Timer after:do: with self after:do: in Xtreams-CoreTests A DISCUSSION OF TECHNICAL DETAILS: I first attempted to replace #growToAtLeast: with #grownBy: because Squeak become: is notoriously inefficient. But obviously, this did not work, the tests rely on destination preserving its identity. This clearly is going to degrade micro benchmarks when the destination collection capacity is not well adjusted in advance. I think we should discuss this particular point. Is identity preservation absolutely required, or just convenient ? THE STATUS OF TESTS: Tests do not all pass. There seems to be a bug in Squeak #replace:from:to:with: when the replacement is the collection itself, moved to the right (this is with a COG VM). THE FUTURE: I will probably continue porting with reduced activity, so I invite any interested person to help. Right now, the project is world writeable, code commited here falling under MIT license.

Oct. 9, 2010

Re: [Pharo-project] 12186 image quit problem

by Schwab,Wilhelm K

No argument there. You might have had better weak collections to work with, but hopefully things like Cog and Sig's finalization improvements will give us similar advantages. Either way, it is important to have good session start/stop awareness and to sever ties at the right time (and to not do so at the wrong times). ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Saturday, October 09, 2010 5:24 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem On Sat, Oct 9, 2010 at 2:05 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Sig, Ignore this if you see fit; it might not apply, but don't dismiss it too quickly - it will apply somewhere, somehow. First, are these things happening on shutdown, or on image save? I ask because while they seem to be getting straightened out over time, those concepts have long been intermingled to disadvantage that appears to be greatly underestimated. The correct solution to many startup/shtudown cleanup takes some adjustment. Image save is nothing - ignore it. Shutdown can almost be ignored, though it is wise and polite to try to clean up external resources, and we should have good tools for developers wanting/needing to do so in their own programs. A good OS will clean up resources when something quits, but Andreas and others would point out that there might not be an OS, or it might have been written in the north western US :) The real house cleaning magic happens on startup - all the stuff you bravely ignored on save is now, finally, junk and needs to be discarded. By following this approach, an image save is no big deal, the system does the best it can to clean up after itself on shutdown, and things that were retained post-save (because the image needs to be able to plod along as though nothing happened) get chopped out early in startup and lazily recreated when appropriate. But remember it is far more efficient in start-up time to use a weak collection of objects that need to be junked/voided/finalized than an allInstancesDo: or two. I made VisualWorks start up about 4 times quicker by e.g. keeping font instances in a collection for voiding their handles on start-up. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] Sent: Saturday, October 09, 2010 11:38 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] 12186 image quit problem On 9 October 2010 09:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: > Igor > > Is it also related to > http://code.google.com/p/pharo/issues/detail?id=3048 > too? > related? not quite. However by fixing it we at least hide the problem. Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown. It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock. > Stef > >>>>>> with the MCMethodDefinition>>shutdown hack it work well >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 9, 2010

Re: [Pharo-project] 12186 image quit problem

by Eliot Miranda

On Sat, Oct 9, 2010 at 2:05 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Sig, > > Ignore this if you see fit; it might not apply, but don't dismiss it too > quickly - it will apply somewhere, somehow. First, are these things > happening on shutdown, or on image save? I ask because while they seem to > be getting straightened out over time, those concepts have long been > intermingled to disadvantage that appears to be greatly underestimated. > > The correct solution to many startup/shtudown cleanup takes some > adjustment. Image save is nothing - ignore it. Shutdown can almost be > ignored, though it is wise and polite to try to clean up external resources, > and we should have good tools for developers wanting/needing to do so in > their own programs. A good OS will clean up resources when something quits, > but Andreas and others would point out that there might not be an OS, or it > might have been written in the north western US :) > > The real house cleaning magic happens on startup - all the stuff you > bravely ignored on save is now, finally, junk and needs to be discarded. By > following this approach, an image save is no big deal, the system does the > best it can to clean up after itself on shutdown, and things that were > retained post-save (because the image needs to be able to plod along as > though nothing happened) get chopped out early in startup and lazily > recreated when appropriate. > But remember it is far more efficient in start-up time to use a weak collection of objects that need to be junked/voided/finalized than an allInstancesDo: or two. I made VisualWorks start up about 4 times quicker by e.g. keeping font instances in a collection for voiding their handles on start-up. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [ > siguctua(a)gmail.com] > Sent: Saturday, October 09, 2010 11:38 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 12186 image quit problem > > On 9 October 2010 09:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > Igor > > > > Is it also related to > > http://code.google.com/p/pharo/issues/detail?id=3048 > > too? > > > > related? not quite. However by fixing it we at least hide the problem. > > Somehow , removing weakdependent during shutdown leads to semaphore > deadlock. > But i don't think that it exactly because MCMethodDefinition registers > weakdependent. > It could be any other thing, which registers weakdependent and then > tries to remove it from weakdependents during > shutdown. > > It also quite hard to reproduce. I was able to lock image few times > using script , which Pavel provided. > But then running same image with same VM again, didn't lead to lock. > > > Stef > > > >>>>>> with the MCMethodDefinition>>shutdown hack it work well > >> > > > > > > _______________________________________________ > > 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 >

Oct. 9, 2010

Re: [Pharo-project] Getting my head around low space

by Schwab,Wilhelm K

Max, You are probably way ahead of this (and keep pushing the envelope<g>), but you do know about #release, right? A couple of weeks ago I ran some fairly intense calculations that resulted in low space conditions. Sending #release to the participants (and implementing it correctly) fixed it. One thing that IMHO has never worked well, or at least not as well as advertised, in Dolphin is relying on its finalization "water mark" to trigger cleanup of finalizable objects on need. Most notably, I found it necessary to explicitly clean up ODBC statements to avoid errors/crashes. How much memory do you need? May I ask for what? 32 or 64 bit? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Max Leske [maxleske(a)gmail.com] Sent: Saturday, October 09, 2010 12:01 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Getting my head around low space Hi I'm having trouble with low space warnings in Pharo. Is there a source on how much memory the image can get from the OS? Is there maybe a way to up that limit? I am loading a lot of data into the image and the limit at the moment seems to be around 500 MB. Thanks for any ideas. Cheers, Max _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 9, 2010

Re: [Pharo-project] 12186 image quit problem

by Schwab,Wilhelm K

Sig, Ignore this if you see fit; it might not apply, but don't dismiss it too quickly - it will apply somewhere, somehow. First, are these things happening on shutdown, or on image save? I ask because while they seem to be getting straightened out over time, those concepts have long been intermingled to disadvantage that appears to be greatly underestimated. The correct solution to many startup/shtudown cleanup takes some adjustment. Image save is nothing - ignore it. Shutdown can almost be ignored, though it is wise and polite to try to clean up external resources, and we should have good tools for developers wanting/needing to do so in their own programs. A good OS will clean up resources when something quits, but Andreas and others would point out that there might not be an OS, or it might have been written in the north western US :) The real house cleaning magic happens on startup - all the stuff you bravely ignored on save is now, finally, junk and needs to be discarded. By following this approach, an image save is no big deal, the system does the best it can to clean up after itself on shutdown, and things that were retained post-save (because the image needs to be able to plod along as though nothing happened) get chopped out early in startup and lazily recreated when appropriate. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Saturday, October 09, 2010 11:38 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem On 9 October 2010 09:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor > > Is it also related to > http://code.google.com/p/pharo/issues/detail?id=3048 > too? > related? not quite. However by fixing it we at least hide the problem. Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown. It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock. > Stef > >>>>>> with the MCMethodDefinition>>shutdown hack it work well >> > > > _______________________________________________ > 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

Oct. 9, 2010

Re: [Pharo-project] readonly status conflict with reading

by StÃ©phane Ducasse

On Oct 9, 2010, at 3:48 PM, Levente Uzonyi wrote: > On Sat, 9 Oct 2010, StÃ©phane Ducasse wrote: > >> Hi john >> >> When I set on mac a file to readonly, I get nil when I do >> FileStream named: 'foo.txt' > > I guess that's #fileNamed:, not #named:. When you send that method, you're trying to open the file in read-write mode. If you just want to read from a file then use #readOnlyFileNamed:. Yes stupid me. I really do not like this file operation names. Stef

Oct. 9, 2010