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

Re: [Pharo-project] Sockets in Pharo CollaborActive Book

by Noury Bouraqadi

Hi Bill, On 1 sept. 2010, at 05:59, Schwab,Wilhelm K wrote: > The deeper question is whether we want to document how things are, or they they *should be* - which is VERY much different from the eventless and timeout ridden design that we have now. It desperately needs to be redesigned. > I agree that the current status of the networking libraries is horrible. But, to learn the current status and think of the alternatives, I felt the need to understand how thinks work now. As StÃ©f said, Luc and I started the Ocean project. Thanks you Bill and to Guille for your proposal to help. It's a pitty that you don't attend to the ESUG conf (Your names are not on the registrations list) otherwise we could discuss this better. Cause Luc and I will give a short presentation describing the current status of Ocean and where it is headed. Now, we need to think how to split the project in order to have other contributions. Note BTW, our goal is to have a low-level Pharo wrappers of the networking facilities of the OS. We started using Alien to avoid using a plugin and ease portability. Once we get this low-level layer, we'll go on and use it in an OOP middleware like rST and UbiquiTalk. Which is after all, the right level to work with since we want to deal with objects and message sends. A direct use of Sockets isn't really OO most of the time. Noury

Sept. 4, 2010

Re: [Pharo-project] Memory problems on Windows

by Mariano Martinez Peck

You can also ask in VM mailing list. I cc'ed them. On Sat, Sep 4, 2010 at 4:52 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > Hello, > > Sorry for the delay in reply. For some reason the first time I looked at > your message in my newsreader (Thunderbird/GMane) the message was in French > and written to someone else. Apparently the software did something strange. > > To answer your question. Yes. I tried this in both the standard vm and the > standard Pharo 1.1 image. > > I start the vm/image with -memory: 1000 > and open a new Workspace, then copy the below memory settings and doit. > I then do a := Array new: 100000000. > > That seemingly succeeds but only takes me up to a little below 500mb ram. > If I attempt to do another array of another 100,000,000 objects, I get the > Low Space error. > > With the standard vm and image, it just sits there consuming cpu with > simply doing the array initialization. I am on a quad core server with 6gm > ram and it has currently consumed over 36 cpu minutes of one of the cores. > At this point I quit the image. I could do things in the UI but it is not > very responsive. > > In the Cog vm/image, the array creation returns almost immediately and > waits for other instructions. > > As I write this I have to go back to Squeak 3.7.1vm and either the 3.8 or > 3.10 image, for it to be successful. Outside of that I can't get past 500mb > of ram. This server generally sits at only using 30% of ram. > > For enterprise/business endeavors, I thing Pharo really needs to be able to > use all the memory the OS will allow it. I know that it being a 32 bit app > does create some limits on some OSes. But neither of my Vista machines > imposes a limit that I can't live with at the moment. > > Thanks for your reply. I am neither a vm nor Smalltalk expert so I don't > know how to proceed from here outside of reducing my applications memory > needs by putting more into the database and only having the data in memory > that is absolutely necessary for the analysis I am attempting. > > Jimmie > > > On 9/1/2010 4:48 AM, StÃ©phane Ducasse wrote: > >> do you have the same problem with the normal VM? >> >> On Sep 1, 2010, at 5:25 AM, Jimmie Houchin wrote: >> >> Hello, >>> >>> I am developing an application which processes and generates a large >>> amount of data. In a recent attempt I encountered an Space is Low error. >>> >>> This is occurring in a Pharo 1.1 image using the latest Pharo and Cog >>> VMs. I am opening the vm with the -memory: 1000 parameter. >>> The below code I have applied the from the Squeak list from the 100 >>> Million Objects thread. But the problem occurs at about 500mb of ram on a >>> computer with 3 (or 6) gb of ram, with only 65% of physical ram in use. The >>> os is Vista. >>> >>> Any help in using more memory, as much as necessary for the app, would be >>> greatly appreciated. >>> >>> initializeMemorySettings >>> "Initialize the memory and GC settings to be more in line with QF >>> requirements" >>> >>> "The following settings affect the rate incremental GCs and tenuring" >>> >>> "Limit incremental GC activity to run every 40k allocations" >>> SmalltalkImage current vmParameterAt: 5 put: 40000. "allocations between >>> GCs (default: 4000)" >>> "Limit tenuring threshold to only tenure w/> 10k survivors" >>> SmalltalkImage current vmParameterAt: 6 put: 10000. "tenuring threshold >>> (default: 2000)" >>> >>> "These settings affect overall memory usage" >>> >>> "Only give memory back to the OS when we have more than 16MB free" >>> SmalltalkImage current vmParameterAt: 24 put: 16*1024*1024. "default >>> 8MB" >>> "Try to keep 8MB headroom at all times" >>> SmalltalkImage current vmParameterAt: 25 put: 8*1024*1024. "default 4MB" >>> "These settings describe what to do when we're close to running out of >>> free space" >>> >>> "Tell the VM that we'd rather grow than spinning in tight GC loops" >>> SmalltalkImage current gcBiasToGrow: true. "default: false" >>> "Tell the VM to do a fullGC for good measure if the above growth >>> exceeded 16MB" >>> SmalltalkImage current gcBiasToGrowLimit: 16*1024*1024. "default: 0" >>> >>> Thanks, >>> >>> Jimmie Houchin >>> >>> >>> _______________________________________________ >>> 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 >

Sept. 4, 2010

Re: [Pharo-project] Package comments

by StÃ©phane Ducasse

>> > I just played with HelpSystem in-depth for the first time and it's really > cool. I'll start using it. > > @Steph: What's the advantage, if any, of DrDoc's approach, and could the two > be integrated? Bert suggested hooking custom PackageInfo classes into > HelpSystem on the Squeak list @ > http://forum.world.st/Documentation-What-about-package-comments-td2062634.h…. I need metadata for packages - license - author - source - documentation -> so why not handling it suing help but may be we just need a With the rewrite of package I did and nearly nobody care about we can just add all the meta data and help to them without relying on yet another class and superclass. DrDoc is not really working and nearly emtpy. It was a toy to play with the idea. It is just a little class that can be added to any package and does not rely on a superclass to have the metadata. I prefer that than to rely on CustomHelp or a superclass. Now if you follow the list you probably know my state of mind... Stef

Sept. 4, 2010

Re: [Pharo-project] Issue 2844 in pharo: String>>#numArgs is broken

by StÃ©phane Ducasse

yes but marcus will deal with that since I'm full with 1.2 On Sep 3, 2010, at 11:12 PM, Schwab,Wilhelm K wrote: > Stef, > > Does that mean that 1.1 will be patched accordingly? I have been thinking of building a new 1.1 image but can safely postpone that until this is ready if that is the intent. > > Bill > > > ________________________________________ > From: pharo(a)googlecode.com [pharo(a)googlecode.com] > Sent: Friday, September 03, 2010 3:23 PM > To: Schwab,Wilhelm K > Subject: Re: Issue 2844 in pharo: String>>#numArgs is broken > > Comment #5 on issue 2844 by stephane.ducasse: String>>#numArgs is broken > http://code.google.com/p/pharo/issues/detail?id=2844 > > marcus will integrate it in the 1.1.1 batch he will do soon :) > > -- > You received this message because you starred the issue. > You may adjust your notification preferences at: > https://code.google.com/hosting/settings > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 4, 2010

Re: [Pharo-project] systemNavigation cleaning

by StÃ©phane Ducasse

On Sep 3, 2010, at 11:04 PM, Lukas Renggli wrote: > I agree that SystemNavigation is ugly, but *a lot* of existing code > depends on it. Well if I start forking all the classes that we should fix because there are used it will be endless. I was thinking to start also to look at senders and use deprecate. do you have a lot of external tools that use it? Also fixing the system is the best way to make sure that it is always running. Look at it nearly nobody looked at my rewrite of packages (ok three people, henrik, you and doru), nearly nobody looked at a the new update streamer (cyrille uses it but did not look at it), ... > Why not just use BrowserEnvironment if you need something convenient > and nice? And at some point integrate that into PharoCore? This is the idea. But I think that system navigation is a superset of Now since BrowserEnvironment is in RB this brings the problem of how do I integrate that. So cleaning first systemNavigation would be a way to have a better pictures of what is working duplicated.... or not. So what do you suggest? Separating BrowserEnvironment and its superclass from RB and starting to - check its api - improve it - migrate caller of systemNavigation -> BrowserEnvironment (rename browserEnvironment) Stef > > Lukas > > On 3 September 2010 22:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi all >> >> I'm cleaning SystemNavigation (no comment). >> Now I really SystemNavigation to be able to navigate a given environment (instance of SystemDictionary). >> Therefore I introduced an analyzedEnvironment and I will funnel most methods to use it. >> >> Now some queries are doing memory scanning (allBehaviorDo:) so >> I would like to use the following semantics for the method names >> all* will refer to methods that are not respecting the analyzedEnvironment but could scan the complete memory >> and I would like to introduce their pendant to convey the fact that they only take as input a given environment. >> >> Example >> allClasses >> vs classes >> >> This would allow us to have in place a nice infrastructure to load and analyse code in a separate environment and >> do atomica loading. This was done like that in VW30. >> >> What do you think. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 4, 2010

Re: [Pharo-project] [OSProcess] Proposal for Pharo 1.2 compatibility

by StÃ©phane Ducasse

I integrated the undeprecation suggested by henrik On Sep 3, 2010, at 10:17 PM, David T. Lewis wrote: > On Fri, Sep 03, 2010 at 08:57:55PM +0200, St?phane Ducasse wrote: >> Hi david >> >> I think that you should wait. 1.1 is stable and out. > > Thanks Stef, good advice, that's what I will do. > > Dave > > >> 1.2 is in flux. When 1.2 gets in beta this will be time to settle down things. >> Cyrille I know why you want 1.2 version else you cannot build a hudson working solution >> to run top of the edge version. Now I will do the changes suggested by henrik to get a backward compatible version. >> I suggest to use metacello to control version now I understand that people want to avoid branching >> now it means that we (the people working on the unstable stream may lack tools but this is ok). >> >> Stef >> >> On Sep 3, 2010, at 6:30 PM, David T. Lewis wrote: >> >>> On Fri, Sep 03, 2010 at 01:03:31PM +0200, Cyrille Delaunay wrote: >>>> Hello, >>>> >>>> I would suggest to replace the two methods >>>> -------------------------------------------------------------- >>>> OSPRocess class >> platformName >>>> "After Squeak version 3.6, #platformName was moved to SmalltalkImage " >>>> >>>> ^ ((Smalltalk classNamed: 'SmalltalkImage') >>>> ifNil: [^ Smalltalk platformName]) current platformName >>>> >>>> OSPRocess class >> osVersion >>>> "After Squeak version 3.6, #osVersion was moved to SmalltalkImage " >>>> >>>> ^ ((Smalltalk classNamed: 'SmalltalkImage') >>>> ifNil: [^ Smalltalk osVersion]) current osVersion >>>> >>>> -------------------------------------------------------------- >>>> by: >>>> ------------------------------------------------------------- >>>> OSProcess class >> platformName >>>> ^ ((Smalltalk classNamed: 'OSPlatform') >>>> ifNil: [ >>>> (Smalltalk classNamed: 'SmalltalkImage') current >>>> ifNil: [^ Smalltalk platformName]]) platformName >>>> >>>> OSProcess class >> osVersion >>>> ^ ((Smalltalk classNamed: 'OSPlatform') >>>> ifNil: [ >>>> (Smalltalk classNamed: 'SmalltalkImage') current >>>> ifNil: [^ Smalltalk osVersion]]) osVersion >>>> ------------------------------------------------------------ >>>> >>>> to avoid deprecation messages when using it in Pharo 1.2. Does it looks >>>> good? I'm not able to publish on the squeaksource repository >>> >>> This failed on the first Pharo image that I tried, which was a >>> Pharo-1.1-11400-rc2dev10.06.1 image. I think this is the subject >>> of some recent refactoring, so I'm not sure if it's safe to use >>> it yet (will somebody try to load OSProcess in one of the images >>> that has OSPlatform but that does not yet have the #platformName >>> refactoring?). >>> >>> I expect that there are several versions of Pharo in general >>> circulation, so can someone give me some guidance as to whether >>> it is safe to code for "OSPlatform current platformName" as the >>> expected idiom on Pharo, or should we wait a while and live with >>> the deprecation warnings? >>> >>> Thanks, >>> >>> Dave >>> >>> >>> _______________________________________________ >>> 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

Sept. 4, 2010

Re: [Pharo-project] PharoKernel #12121

by StÃ©phane Ducasse

> I was just thinking if this really makes sense or not...Suppose I have the PharoCore image 12121. > > From that image, I can shrink it and generate PharoKernel 12121. > > If I then have a configuration to load the core again, I will have again PharoCore 12121, which I already have, and which I can directly use. So...what is the sense of creating again PharoCore from PharoKernel? > > A different story is if PharoCore 12121 DOES NOT exist before...so you start from PharoKernel 12121 and THEN create PharoCore....but PharoKernel is a shrink from PharoCore...soo...? > > I am confused :( > > cheers > > mariano > > > So ... listen little jedi - if we do not have an infrastructure in place to manage lot of packages then there is no need to push to get a little core. - I would be already really happy if I can take pharoKernel + MCloader -> loading metacello and loading all the packages and get 12121 - Now when we are in step 2 we will be able to - cut packages change the map and snap out fingers or think about the forces and produce better packaged system - iterate - I'm not a big believer of shrinking and I would like to have a bootstrap but this is the path to go. so ideally at the end of the process we should be able to even recreate bootstrappedpharoKernel from itself of another image. Stef

Sept. 4, 2010

Re: [Pharo-project] Single instance executables

by Denis Kudriashov

You could open some file for write at image startup. When its failed you know that another image already started 2010/9/2, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > I realize that I hold an unpopular position on this, but it *will* come back > to haunt us: we need to have a way to warn the user if a second copy of > Pharo is launched. Random meltdowns and lost work will result from the > current behavior. Let me be more bold: lost work and random corrrupted > images *are resulting* from the current behavior; they are either > unrecognized, or simply ignored, but it is happening. > > Is there a way to fix it? On Windows, I recall creating an OS semaphore > with a given name and if that exists, bail out before the session even gets > going. We would need a cross-platform way to do that (or at least a > Linux/Mac way to do it - Windows has a mechanism), and then a place to abort > startup early enough to prevent problems. Any ideas? > > Bill > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 4, 2010

Re: [Pharo-project] PharoKernel #12121

by Pavel Krivanek

Hi, 2010/9/3 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Fri, Sep 3, 2010 at 11:22 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> for me this is simple >> Â Â Â Â - I would like to use a metacello configuration to reload >> everything in between >> Â Â Â Â this kernel image and the current 12121 but I do not have the time. >> > > I was just thinking if this really makes sense or not...Suppose I have the > PharoCore image 12121. > > From that image, I can shrink it and generate PharoKernel 12121. > > If I then have a configuration to load the core again, I will have again > PharoCore 12121, which I already have, and which I can directly use. > So...what is the sense of creating again PharoCore from PharoKernel? > > A different story is if PharoCore 12121 DOES NOT exist before...so you start > from PharoKernel 12121 and THEN create PharoCore....but PharoKernel is a > shrink from PharoCore...soo...? > > I am confused :( Original KernelImage used a Morphic image as the starting point too. The build-server updated the image, shrinked to the kernel and then he created a set of various headless and GUI-containing images (kernel, base, seaside, seasidexul, morhpiccore, tools, etoys...) where the original starting image was only one of many. Plus: - you can create updated kernel image without need of MC and network support in the kernel - you have better control about content of the image - the initialization process of the packages (like Morphic) is described well - you can create a build & test server easily with a lot of output images - requires good modularization - you have direct feedback if the shrink&build process is not broken Minus: - changes file is bigger because it stores all code above the level of the kernel as the new code Note that the shrinking process will be replaced with direct image bootstrapping. Cheers -- Pavel > > cheers > > mariano > > >> >> So ... >> >> On Sep 2, 2010, at 11:08 PM, Lukas Renggli wrote: >> >> > Very impressive. Can't wait to see Pharo built from such a small image. >> > >> > Lukas >> > >> > On 2 September 2010 23:02, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> > wrote: >> >> Hi, >> >> >> >> I uploaded the new version of PharoKernel #12121: >> >> >> >> >> >> https://gforge.inria.fr/frs/download.php/27438/PharoKernel-1.2-12121.zip >> >> >> >> The shrinking process is now based on packages. >> >> >> >> Cheers >> >> -- Pavel >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > >> > >> > -- >> > Lukas Renggli >> > www.lukas-renggli.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 >

Sept. 4, 2010

Re: [Pharo-project] Memory problems on Windows

by Jimmie Houchin

Hello, Sorry for the delay in reply. For some reason the first time I looked at your message in my newsreader (Thunderbird/GMane) the message was in French and written to someone else. Apparently the software did something strange. To answer your question. Yes. I tried this in both the standard vm and the standard Pharo 1.1 image. I start the vm/image with -memory: 1000 and open a new Workspace, then copy the below memory settings and doit. I then do a := Array new: 100000000. That seemingly succeeds but only takes me up to a little below 500mb ram. If I attempt to do another array of another 100,000,000 objects, I get the Low Space error. With the standard vm and image, it just sits there consuming cpu with simply doing the array initialization. I am on a quad core server with 6gm ram and it has currently consumed over 36 cpu minutes of one of the cores. At this point I quit the image. I could do things in the UI but it is not very responsive. In the Cog vm/image, the array creation returns almost immediately and waits for other instructions. As I write this I have to go back to Squeak 3.7.1vm and either the 3.8 or 3.10 image, for it to be successful. Outside of that I can't get past 500mb of ram. This server generally sits at only using 30% of ram. For enterprise/business endeavors, I thing Pharo really needs to be able to use all the memory the OS will allow it. I know that it being a 32 bit app does create some limits on some OSes. But neither of my Vista machines imposes a limit that I can't live with at the moment. Thanks for your reply. I am neither a vm nor Smalltalk expert so I don't know how to proceed from here outside of reducing my applications memory needs by putting more into the database and only having the data in memory that is absolutely necessary for the analysis I am attempting. Jimmie On 9/1/2010 4:48 AM, StÃ©phane Ducasse wrote: > do you have the same problem with the normal VM? > > On Sep 1, 2010, at 5:25 AM, Jimmie Houchin wrote: > >> Hello, >> >> I am developing an application which processes and generates a large amount of data. In a recent attempt I encountered an Space is Low error. >> >> This is occurring in a Pharo 1.1 image using the latest Pharo and Cog VMs. I am opening the vm with the -memory: 1000 parameter. >> The below code I have applied the from the Squeak list from the 100 Million Objects thread. But the problem occurs at about 500mb of ram on a computer with 3 (or 6) gb of ram, with only 65% of physical ram in use. The os is Vista. >> >> Any help in using more memory, as much as necessary for the app, would be greatly appreciated. >> >> initializeMemorySettings >> "Initialize the memory and GC settings to be more in line with QF requirements" >> >> "The following settings affect the rate incremental GCs and tenuring" >> >> "Limit incremental GC activity to run every 40k allocations" >> SmalltalkImage current vmParameterAt: 5 put: 40000. "allocations between GCs (default: 4000)" >> "Limit tenuring threshold to only tenure w/> 10k survivors" >> SmalltalkImage current vmParameterAt: 6 put: 10000. "tenuring threshold (default: 2000)" >> >> "These settings affect overall memory usage" >> >> "Only give memory back to the OS when we have more than 16MB free" >> SmalltalkImage current vmParameterAt: 24 put: 16*1024*1024. "default 8MB" >> "Try to keep 8MB headroom at all times" >> SmalltalkImage current vmParameterAt: 25 put: 8*1024*1024. "default 4MB" >> "These settings describe what to do when we're close to running out of free space" >> >> "Tell the VM that we'd rather grow than spinning in tight GC loops" >> SmalltalkImage current gcBiasToGrow: true. "default: false" >> "Tell the VM to do a fullGC for good measure if the above growth exceeded 16MB" >> SmalltalkImage current gcBiasToGrowLimit: 16*1024*1024. "default: 0" >> >> Thanks, >> >> Jimmie Houchin >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 4, 2010