October 2010 - Pharo-dev - lists.pharo.org

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

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

by Max Leske

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? 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

Oct. 9, 2010

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

by Levente Uzonyi

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 >

Oct. 9, 2010

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

by Levente Uzonyi

On Sat, 9 Oct 2010, Max Leske wrote: > Cool! I'll try that, thanks. > > I just wonder: It says in the Notes "If `-memory' is not specified then the heap will grow dynamically.". As I understand that, the image should not run out of space before the OS does (or the address range assigned by the OS). So can this option reserve more memory than the OS would otherwise allow? > I'll try it out and let you know what happened. -memory allocates the memory when the VM starts. Use -mmap (un un*x) if you want the VM to dinamically grow the heap. AFAIK the windows VM doesn't support more than 512MB. Levente > > Cheers, > Max > > > > On 09.10.2010, at 19:48, 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. >> >> >> 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 >

Oct. 9, 2010

Re: [Pharo-project] 12186 image quit problem

by Levente Uzonyi

On Sat, 9 Oct 2010, Igor Stasenko wrote: > 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. It's probably easy to find the cause of the deadlock if you're able to print the stacks. Levente > 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] Getting my head around low space

by Max Leske

Cool! I'll try that, thanks. I just wonder: It says in the Notes "If `-memory' is not specified then the heap will grow dynamically.". As I understand that, the image should not run out of space before the OS does (or the address range assigned by the OS). So can this option reserve more memory than the OS would otherwise allow? I'll try it out and let you know what happened. Cheers, Max On 09.10.2010, at 19:48, 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. > > > 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

Oct. 9, 2010

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

by Adrian Lienhard

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. 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

Oct. 9, 2010

[Pharo-project] Getting my head around low space

by Max Leske

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

Oct. 9, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

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.

Oct. 9, 2010

Re: [Pharo-project] Learning by download all the mcz files from a repository

by Schwab,Wilhelm K

I thought your name was familiar. Hello! One caution/suggestion about your idea: a piece of code could be left unchanged because it is unused or poorly maintained. There are parts of the network, streams, file system, etc. that *should* have changed long ago. Core concept or complacency? But even calling attention to what does and does not change without knowing why could have some value. Note the reference to similar work in this thread. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of HwaJong Oh [daliot.oh(a)gmail.com] Sent: Saturday, October 09, 2010 8:38 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Learning by download all the mcz files from a repository Your name is very familar. Are you Bill Schwab from Dolphin community? If true, hi! I just want to be productive by learning packages effectively by researching better way of doing it. This idea is just one of them. The point of the idea is, sometimes knowing history can explain better than just knowing present. Quantum theory is very hard to understand, but its history tells us why the equations has to change. Some unexplainable facts enters and new theory can expain the past facts and new facts together. I think it is very similar in software. It has to change for a reason which was not the case in the past. Besides I can find some classes which do not change in the timeline. They can be considered as core concept of the package. Best regards HwaJong Oh -- View this message in context: http://forum.world.st/Learning-by-download-all-the-mcz-files-from-a-reposit… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ 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 Levente Uzonyi

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:. Levente > > > Stef > > _______________________________________________ > 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] [ANN] New Reef page and Tutorial available

by Esteban Lorenzano

Hi, Yes... I still need to write two or three more tutorials, then I'll unify all and publish in the collaboractive book :) Cheers, Esteban On 2010-10-08 18:00:36 -0300, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> said: > Cool we want more :) > Yes :) > May be after we could turn that into a chapter for the book. > Stef > >> Hi, >> As I promised at ESUG 2010, I created a page to keep Reef information >> and documentation... >> You can see it here: http://www.smallworks.com.ar/en/community/Reef >> >> Also, I began to write a tutorial for Reef, the first part is here: >> http://www.smallworks.com.ar/en/community/Reef/reefSimpleTutorialPart1 >> And the slides for the presentation is here: >> http://www.slideshare.net/EstebanLM/reef-esug-2010 >> >> >> Cheers, >> Esteban >> _______________________________________________ >> 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] [ANN] Soap Webservices for pharo

by Esteban Lorenzano

cool :) On 2010-10-09 03:30:52 -0300, Guillermo Polito <guillermopolito(a)gmail.com> said: > > > Ok, tests are green (except by one that fails because a particular problem > in my machine's dnss, hehe). > > I've tested its examples in pharo 1.1 between two images my machine, and it > works :). > > To download it: > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSoapOpera'; > load. > > ConfigurationOfSoapOpera project lastVersion load > > To use it, look at the examples in the code and the doc in: > http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/index.html. > > > Sleepy cheers :D, > Guille > > On Tue, Oct 5, 2010 at 1:02 PM, St=C3=A9phane Ducasse > <stephane.ducasse(a)inria.fr>wrote: > >> cool! >> >>> A little of progress... >>> >>> I fixed the underscores assignments, and Preferences references. >>> I built a first metacello configuration to download this package: >>> >>> Gofer it >>> squeaksource:'MetacelloRepository'; >>> package:'ConfigurationOfSoapOpera'; >>> load >>> >>> ConfigurationOfSoapOpera project lastVersion load >>> >>> It depends on ConfigurationOfKomHttpServer (Komanche). >>> I will enhance it in the future to make it depend in the Xml parser in >> XMLSupport. >>> >>> By now, in my 1.2 core image the tests are: 134 run, 121 passes, 0 >> expected failures, 2 failures, 11 errors, 0 unexpected passes. >>> >>> Cheers! >>> >>> 2010/10/4 Janko Miv=C5=A1ek >>> <janko.mivsek(a)eranova.si> >>> Hi guys, >>> >>> Nice to see that SOA Web Services in Squeak/Pharo is rolling on again. >>> We really need that, if we want Pharo to be useful in commercial, >>> specially in so called "enterprisely" world. Those who listen Andreas >>> Th=C3=B6nne's talk on ESUG, know what I mean. >>> >>> What we really need on SOA Web Services front: >>> >>> - WSDL support, >>> - XML <-> Object mapping. >>> - Tools >>> >>> Goal should be a "one-click" use of Web Services. From both client and >>> server setup. As all Smalltalks support it, except Squeak/Pharo yet not= > . >>> Look at excellent VW or VA Smalltlak WebServices suport for inspiration= > . >>> >>> Best regards >>> Janko >>> >>> On 04. 10. 2010 16:21, Guillermo Polito wrote: >>>> http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html<= > http://www.mars.dti.ne.jp/%7Eumejava/smalltalk/soapOpera/soapCore.html> >>>> >>>> So, we have some tasks now: >>>> >>>> - put it in squeaksource >>>> - test it in pharo >>>> - build a metacello config >>>> - document it? >>>> >>>> Any help is really appreciated, since I don't have too much time. >>>> >>>> Cheers, >>>> Guille >>>> >>>> ---------- Forwarded message ---------- >>>> From: *Masashi Umezawa* <umejava(a)mars.dti.ne.jp >>>> <mailto:umejava@mars.dti.ne.jp>> >>>> Date: Mon, Oct 4, 2010 at 8:46 AM >>>> Subject: Re: About SoapOpera and SoapCore >>>> To: Guillermo Polito <guillermopolito(a)gmail.com >>>> <mailto:guillermopolito@gmail.com>> >>>> >>>> >>>> Hi Guillermo, >>>> >>>> I am happy to hear that SoapOpera and SoapCore would be useful for yo= > ur >>>> projects. Please feel free to reuse my Soap stuff. >>>> Recently I do not have enough time to upgrade those packages. So I >>>> really appreciate your offer. >>>> >>>> I hope SoapOpera and SoapCore will start growing again! >>>> >>>> Best regards, >>>> >>>> Guillermo Polito <guillermopolito(a)gmail.com >>>> <mailto:guillermopolito@gmail.com>> wrote: >>>>> Hi! >>>>> >>>>> My name's Guillermo and I'm from Argentina. I'm participating in th= > e >>>> pharo >>>>> project (www.pharo-project.org <http://www.pharo-project.org>), and = > I >>>> would love to integrate your soap >>>>> package into our available packages :). >>>>> I was wandering if you let us put it into squeaksource >>>> (www.squeaksource.com <http://www.squeaksource.com>) >>>>> and mantain it for our use, because pharo is growing very quickly an= > d >> it >>>>> needs this kind of really cool stuff :). Of course we will keep the >> MIT >>>>> license. >>>>> >>>>> Thank you for your time and sorry for bothering :P! >>>>> Guille >>>> >>>> --- >>>> [:masashi | ^umezawa] >>> >>> >>> -- >>> Janko Miv=C5=A1ek >>> AIDA/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >>> _______________________________________________ >>> 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 >> > > > Ok, tests are green (except by one that fails because a particular problem = > in my machine's dnss, hehe). I've tested its examples in pha= > ro 1.1 between two images my machine, and it works :). To download i= > t: > Gofer it =C2=A0=C2=A0=C2=A0 squeaksource: 'MetacelloRepository&#= > 39;; =C2=A0=C2=A0=C2=A0 package: 'ConfigurationOfSoapOpera'; = > =C2=A0=C2=A0=C2=A0 load. =C2=A0=C2=A0=C2=A0 ConfigurationOfSoapOpera= > project lastVersion load To use it, look at the examples in the cod= > e and the doc in: <a href=3D"http://www.mars.dti.ne.jp/~umejava/smalltalk/s= > oapOpera/index.html">http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera= > /index.html</a>. > Sleepy cheers :D, Guille <div class=3D"gmail_quote">On Tu= > e, Oct 5, 2010 at 1:02 PM, St=C3=A9phane Ducasse <<a h= > ref=3D"mailto:stephane.ducasse@inria.fr">stephane.ducasse(a)inria.fr</a>><= /span> > > wrote: > <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= > r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">cool! > <div class=3D"im"> > > A little of progress... > > > > I fixed the underscores assignments, and Preferences references. > > I built a first metacello configuration to download this package: > > > > Gofer it > > =C2=A0 =C2=A0 squeaksource:'MetacelloRepository'; > > =C2=A0 =C2=A0 package:'ConfigurationOfSoapOpera'; > > =C2=A0 =C2=A0 load > > > > ConfigurationOfSoapOpera project lastVersion load > > > > It depends on ConfigurationOfKomHttpServer (Komanche). > > I will enhance it in the future to make it depend in the Xml parser in= > XMLSupport. > > > > By now, in my 1.2 core image the tests are: =C2=A0134 run, 121 passes,= > 0 expected failures, 2 failures, 11 errors, 0 unexpected passes. > > > > Cheers! > > > > 2010/10/4 Janko Miv=C5=A1ek <<a href=3D"mailto:janko.mivsek@eranova= > .si">janko.mivsek(a)eranova.si</a>> > </div><div><div></div><div class=3D"h5">> Hi guys, > > > > Nice to see that SOA Web Services in Squeak/Pharo is rolling on again.= > > > We really need that, if we want Pharo to be useful in commercial, > > specially in so called "enterprisely" world. Those who liste= > n Andreas > > Th=C3=B6nne's talk on ESUG, know what I mean. > > > > What we really need on SOA Web Services front: > > > > - WSDL support, > > - XML <-> Object mapping. > > - Tools > > > > Goal should be a "one-click" use of Web Services. From both = > client and > > server setup. As all Smalltalks support it, except Squeak/Pharo yet no= > t. > > Look at excellent VW or VA Smalltlak WebServices suport for inspiratio= > n. > > > > Best regards > > Janko > > > > On 04. 10. 2010 16:21, Guillermo Polito wrote: > > > <a href=3D"http://www.mars.dti.ne.jp/%7Eumejava/smalltalk/soapOpe= > ra/soapCore.html" target=3D"_blank">http://www.mars.dti.ne.jp/~umejava/smal= > ltalk/soapOpera/soapCore.html</a> > > > > > > So, we have some tasks now: > > > > > > - put it in squeaksource > > > - test it in pharo > > > - build a metacello config > > > - document it? > > > > > > Any help is really appreciated, since I don't have too much t= > ime. > > > > > > Cheers, > > > Guille > > > > > > ---------- Forwarded message ---------- > > > From: *Masashi Umezawa* <<a > href=3D"mailto:umejava@mars.dti.ne= > .jp">umejava(a)mars.dti.ne.jp</a> > > > <mailto:<a > href=3D"mailto:umejava@mars.dti.ne.jp">umejava@mars= .dti.ne.jp</a>>> > > > > Date: Mon, Oct 4, 2010 at 8:46 AM > > > Subject: Re: About SoapOpera and SoapCore > > > To: Guillermo Polito <<a href=3D"mailto:guillermopolito@gmail.= > com">guillermopolito(a)gmail.com</a> > > > <mailto:<a > href=3D"mailto:guillermopolito@gmail.com">guillermo= polito(a)gmail.com</a>>> > > > > > > > > > > Hi Guillermo, > > > > > > I am happy to hear that SoapOpera and SoapCore would be useful fo= > r your > > > projects. Please feel free to reuse my Soap stuff. > > > Recently I do not have enough time to upgrade those packages. So = > I > > > really appreciate your offer. > > > > > > I hope SoapOpera and SoapCore will start growing again! > > > > > > Best regards, > > > > > > Guillermo Polito <<a > href=3D"mailto:guillermopolito@gmail.com"= >> guillermopolito(a)gmail.com</a> > > > <mailto:<a > href=3D"mailto:guillermopolito@gmail.com">guillermo= polito(a)gmail.com</a>>> > > wrote: > > >> Hi! > > >> > > >> My name's Guillermo and I'm from Argentina. =C2=A0I&#= > 39;m participating in the > > > pharo > > >> project (<a href=3D"http://www.pharo-project.org" target=3D"_= > blank">www.pharo-project.org</a> <<a href=3D"http://www.pharo-project.or= > g" target=3D"_blank">http://www.pharo-project.org</a>>), and I > > > would love to integrate your soap > > >> package into our available packages :). > > >> I was wandering if you let us put it into squeaksource > > > (<a href=3D"http://www.squeaksource.com" target=3D"_blank">www.sq= > ueaksource.com</a> <<a href=3D"http://www.squeaksource.com" target=3D"_b= > lank">http://www.squeaksource.com</a>>) > > >> and mantain it for our use, because pharo is growing very qui= > ckly and it > > >> needs this kind of really cool stuff :). =C2=A0Of course we w= > ill keep the MIT > > >> license. > > >> > > >> Thank you for your time and sorry for bothering :P! > > >> Guille > > > > > > --- > > > [:masashi | ^umezawa] > > > > > > -- > > Janko Miv=C5=A1ek > > AIDA/Web > > Smalltalk Web Application Server > > <a href=3D"http://www.aidaweb.si" target=3D"_blank">http://www.aidaweb= > .si</a> > > > > _______________________________________________ > > Pharo-project mailing list > > <a > href=3D"mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@l= ists.gforge.inria.fr</a> > > > <a href=3D"http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo= > -project" target=3D"_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/li= > stinfo/pharo-project</a> > > > > _______________________________________________ > > Pharo-project mailing list > > <a > href=3D"mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@l= ists.gforge.inria.fr</a> > > > <a href=3D"http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo= > -project" target=3D"_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/li= > stinfo/pharo-project</a> > > > _______________________________________________ > Pharo-project mailing list > <a > href=3D"mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project(a)lists.= gforge.inria.fr</a> <a > > href=3D"http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-proj= > ect" target=3D"_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/listinf= > o/pharo-project</a> > </div></div></blockquote></div> > > > > > _______________________________________________ > 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 Schwab,Wilhelm K

Stef, FWIW, the biggest problem I see with this is returning nil rather than raising an exception. With that omission corrected, there are various ways I could envision it working, probably centered on failing to open a writable stream, but if one asks for a read-only stream, there would be no need for an error. I don't too much care what the rules are, so long as the system enforces them consistently and tells me when I violate them. Attached is a partial view of what I have been doing as I find such things in my way. The goals are to provide entry points that my existing code expects and to (a path, not a destination) never fail silently. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, October 09, 2010 2:39 AM To: Pharo Development Subject: [Pharo-project] readonly status conflict with reading Hi john When I set on mac a file to readonly, I get nil when I do FileStream named: 'foo.txt' Stef _______________________________________________ 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] [squeak-dev] Cog+NativeBoost Linux32 binaries available

by Juan Vuletich

Hi Folks, Igor Stasenko wrote: > ... > Also, it would be cool to sync with Juan and his work on Morphic 3. > I'd like to provide a GL backend for Morphic 3. > > But its unclear to me, what plans Juans having about it. Recently he > said that he won't make any public releases. > But i really hope that we could work together on it, because such > ambitious projects need more than a single man > in order to complete. > My attempt to raise some funds to be able to work on it yielded very modest results. As a result, I'm spending more time in regular, paid work that I'd like (lately, even Drupal and PHP...). This means I don't have much time left. And most of it goes in keeping Cuis updated. So, Morphic 3 will keep advancing at a slow pace. Help in this regard would be much appreciated. Cheers, Juan Vuletich

Oct. 9, 2010

Re: [Pharo-project] XTream was Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Sven Van Caekenberghe

Martin & Michael, Thank you first for coming up with xtreams and second for taking the open source route and doing the effort to promote it. I've been browsing a bit in vwnc 7.7 and it really shows that you guys have been thinking about this for quite some time and that this is not the first implementation. This is Smalltalk code that confirms my belief why Smalltalk is better. I am happy with your reaction and I agree with the goal that xstreams should be loadable and usable next to the standard stuff. Selector names are clearly carefully chosen to make this possible, class names are a bit harder for Smalltalks without name spaces ;-) I think we (for me, that is Pharo users, for others that might be Squeak users) should really take this opportunity (your invitation) and help turn the xstreams codebase into something portable to multiple Smalltalk implementations. With Nicolas there is already somebody with great concrete experience and actual code to help make this a reality. If I can, I will at least be an interested user and hopefully also capable of contributing. Sven On 08 Oct 2010, at 22:04, mkobetic(a)gmail.com wrote: > I saw this thread on the pharo list and figured that a bit of feedback from Michael and myself might be helpful. Please, forgive the cross-posting, this concerns both dialects and I'd like to make this discussion visible on the VW side as well. > > First of all, let me thank everyone for the "xtreamly" positive feedback. It sure feels good to get a thumbs up once in a while. So, thanks! > > Since there was a question earlier about availability of my ESUG slides, I'll also add that a rather crude and plain but usable pdf export of those is available on the ESUG slideshare. I'd be happy to forward the pdf to anyone interested as well. It's full of examples and it certainly should be easier to copy those from there than from the video or memory :-). > > As far as the future plans for Xtreams go (at least on VW side), we'd primarily like to validate the design with actual use, and fix any outstanding issues of course. We are certainly open towards collaboration with others on further development or porting efforts. I'd be happy to help sort out any porting issues (at least from the VW side). > > Regarding the general direction of the project, we are skeptical about the possibility of maintaining backward compatibility with the classic streams and yet being able to make the kind of changes that we're experimenting with in Xtreams. At this point we believe that the only practical approach is to let them live side by side and let people chose whichever fits better their needs. If Xtreams ever do gain significant acceptance there certainly is a very real possibility that we'll end up having to live with both frameworks, maybe forever. But we don't think there's practical way to somehow evolve the classic streams into something like Xtreams without wreaking havoc. > > That's also partly why we took the liberty of changing even the basic APIs. They don't behave quite the same way (intentionally) in a number of cases and given that the two will likely have to coexist in the same context, it might be actually beneficial to make them distinctly different, so that it's clear which one is used where. Anyway, what I'm getting at is that some of the choices we've already made with Xtreams might be hard for us to compromise on, but we can certainly discuss the options. On the other hand, implementation changes that aid portability and don't compromise the basic goals are certainly a fair game. Ideally we'll be able to agree on an arrangement that would allow the project to co-evolve on multiple-dialects without the need to effectively fork the code-base. That would certainly be worth-while and we're definitely interested in trying to achieve that. I'll be at the Smalltalks 2010 conference in november and would be happy to discuss any details if there are people interested in this. > > Obviously, given the license, people are free to fork the code or start from scratch or whatever and take it in whatever direction they see fit. I just want to make it clear that we are open to collaboration as long as we can agree on general direction. So, no hard feelings Nicolas :-), although we may want to sort out the naming eventually just for the sake of avoiding confusion in the Squeak and Pharo world (if Xtreams ever get traction there). > > Anyway, I'm now subscribed to the pharo list so I'm reachable both there and on vwnc. > > Martin > > "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Yes that's a correct description of the past and present. >> >> The futur is opened, and the main options for Squeak Xtream are: >> 1) change goals to get closer to VW - with a compatible API and lot of >> mud underneath to glue the implementation on squeak >> 2) stay at a proof of concept experimental level >> 3) continue developping independantly as a replacement for Stream >> >> There is a lot of buzz recently, and a renewed interest in VW Xtream. >> So there is a chance to gather enough force to attempt a squeak port, >> whether based on Squeak Xtream experiments or not. >> But it's not to me alone to answer this challenge. >> >> Nicolas >> >>> Sven >>> >>> _______________________________________________ >>> 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

Re: [Pharo-project] Learning by download all the mcz files from a repository

by HwaJong Oh

Your name is very familar. Are you Bill Schwab from Dolphin community? If true, hi! I just want to be productive by learning packages effectively by researching better way of doing it. This idea is just one of them. The point of the idea is, sometimes knowing history can explain better than just knowing present. Quantum theory is very hard to understand, but its history tells us why the equations has to change. Some unexplainable facts enters and new theory can expain the past facts and new facts together. I think it is very similar in software. It has to change for a reason which was not the case in the past. Besides I can find some classes which do not change in the timeline. They can be considered as core concept of the package. Best regards HwaJong Oh -- View this message in context: http://forum.world.st/Learning-by-download-all-the-mcz-files-from-a-reposit… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 9, 2010

Re: [Pharo-project] Strange code replacement when prompting unknown selector

by Juan Vuletich

Sounds reasonable. Cheers, Juan Vuletich Mariano Martinez Peck wrote: > > > 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com > <mailto:guillermopolito@gmail.com>> > > The problem seems to be between /TextEditor>>correctFrom:to:with:/ > and /Parser>>substituteWord:wordInterval:offset:/ > > The TextEditor isn't using well the selection offset to calculate > the replacement, and the parser is sending an interval that's not > the one that the Editor must replace. > > I think the right place to put this is the Editor, but behind > another message like replaceInSelectionFrom:to:with: > > What do you think? > > Guille > > > > On Wed, Oct 6, 2010 at 6:33 PM, Guillermo Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > http://code.google.com/p/pharo/issues/detail?id=3070 > > Cheers! > Guille > > > > _______________________________________________ > 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 > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 > >

Oct. 9, 2010

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by Juan Vuletich

Hi Folks, Cuis doesn't include #autoEnclose, so I don't know how it should behave. Cheers, Juan Vuletich Mariano Martinez Peck wrote: > Guille, if I remember correctly (not sure), these new classes like > TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i > think he is in the mailing list but not read it so frequently. So, for > this issues maybe you can cc'ed him. > > Cheers > > Mariano > > 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com > <mailto:guillermopolito@gmail.com>> > > Here is the piece of code that's behaving weird > > TextEditor>>dispatchOn: > > ... > ... > char := aKeyboardEvent keyCharacter. > openers := '([{'. > closers := ')]}'. > ( closers includes: char) ifTrue: [ self blinkPrevParen: > char ]. > result := self normalCharacter: aKeyboardEvent. > (self class autoEnclose and: [ openers includes: char ]) > not ifTrue: [ ^ result ]. > suffix := closers at: (openers indexOf: char). > paragraph text append: suffix asString. > self moveCursor: [ : position | position ] forward: true > specialBlock: [ : pos | "no special behavior" ] event: > aKeyboardEvent . > self userHasEdited. > > ------------------------------------- > > So, if I evaluate "TextEditor autoEnclose: false", it is stops > behaving like that :) > > What should be the desired behavior? Having it configurable as it > is today but fix the strange bracket adding? remove this behavior? > I can't find now how ParagraphEditor did this. > > Guille > > > On Wed, Oct 6, 2010 at 10:34 PM, Guillermo Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > Yes, the issue can be reduced to: > > open parenthesis (or brackets), then something else (anywhere > in the editor). > > 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com > <mailto:marianopeck@gmail.com>> > > I detected a similar problem: > > once you type an opening parenthesis, and then something > else, it adds a new one at the END of the code > > check http://code.google.com/p/pharo/issues/detail?id=2939 > > 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com > <mailto:guillermopolito@gmail.com>> > > http://code.google.com/p/pharo/issues/detail?id=3069 > > if you type: > > [] -> []] > > () -> ()) > > {} -> {}} > > > > > Bye! > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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 > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 > >

Oct. 9, 2010