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

Re: [Pharo-project] VMMakerTool >>DoesNotUnderstand ModalFolderSelector

by StÃ©phane Ducasse

Hi jean-baptiste did you read the archives because Dave apparently fixes VMMaker so that you can generate a new VM under pharo. Let us know if you still have the problem. Probably FileList modal... On Aug 23, 2009, at 11:01 AM, jean baptiste arnaud wrote: > Hi, > I would like use VMMaker on Pharo. > I resolve all dependency for the VMMaker Package : > > -FFI,(ScriptLoader loadFFI.) > -Speech find in "Unstable Squeak" package from squeaksource > -Finally i install VMMaker from squeaksource > > VMMaker seems work correctly but not this UI. When load the > VMMakerTool, i have a error does not understand ModalFolderSelector. > > -- > Arnaud Jean Baptiste > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project FYI. This problem was originally reported on the Pharo list earlier this year. The fix is now in VMMaker on SqueakSource. ----- Forwarded message from "David T. Lewis" <lewis(a)mail.msen.com> ----- Date: Tue, 18 Aug 2009 08:05:22 -0400 From: "David T. Lewis" <lewis(a)mail.msen.com> To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org > Subject: Re: [Vm-dev] Fwd: [Pharo-project] Could not load VMMaker in 10315 VMMaker (from SqueakSource) can now be loaded into closure-enabled images. I was able to remove a couple of temp variables from the GeniePlugin primitive without affecting the logic. This was discussed on several lists back in May. The fix is in VMMaker-dtl.135 on SqueakSource, and is documented in Mantis http://bugs.squeak.org/view.php?id=7384. Dave On Mon, May 25, 2009 at 10:37:15PM -0400, David T. Lewis wrote: > > On Mon, May 25, 2009 at 11:06:10AM -0700, Eliot Miranda wrote: >> >> On Mon, May 25, 2009 at 7:40 AM, David T. Lewis >> <lewis(a)mail.msen.com> wrote: >> >>> >>> On Sun, May 24, 2009 at 01:44:52PM -0700, Eliot Miranda wrote: >>>> >>>> 3. refactor the GeniePlugin method into an outer args parser and >>>> an inner >>>> engine method and solve the problem. Since VMMaker will inline >>>> anyway >>> this >>>> shouldn't make performance worse. I haven't done this because >>>> I'm not >>> the >>>> author and it is quite a complex method. >>> >>> This sounds like the right thing to do, regardless of what may >>> change >>> in the compiler(s). >> >> >> +1 >> > > Well unfortunately the refactoring turns out to be easier said than > done. > At least it was easier for me to say it than it was for me to do it. > > I made a naive attempt to split the primitive into smaller methods, > but this > just ended up trading off too many things on the stack for too many > arguments > in an argument list. > > The method temp variables could be changed to be instance variables. > This > would probably work fine for any current VMs (not sure about Hydra), > but > it does not pass the smell test IMO. > > I suspect that Nathaniel Schaerli knew what he was doing when he wrote > this primitive, and I most certainly do not, so I don't expect that > I will > make much further progress on this front. > > Dave ----- End forwarded message ----- _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Hello squeak people > > Does anyone have a hint how to get (with reasonable effort) current > vmmaker setup? May be there is a prepared image somewhere? I'm > interested in building vm on windows. When I follow these > instructions: http://wiki.squeak.org/squeak/6102 i stuck during > loading of vmmaker from the squeak-map > > regards, > Danil Windows build instructions: http://squeakvm.org/win32/ http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/win32/docs/ Up to date VMMaker packages are on SqueakSource project VMMaker. The SqueakMap and Universes entries are a bit out of date. Dave _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 24, 2009

Re: [Pharo-project] Networking on images running on 64 bit OSes.

by Miguel Enrique CobÃ¡ Martinez

El dom, 23-08-2009 a las 18:40 -0500, Miguel Enrique CobÃ¡ Martinez escribiÃ³: > Is someone working on issues: > > http://code.google.com/p/pharo/issues/detail?id=1031 > http://code.google.com/p/pharo/issues/detail?id=961 > http://code.google.com/p/pharo/issues/detail?id=794 > > Without them fixed the in-image network doesn't work. > > CPU: intel > CPU arch: x86 > OS: Debian GNU/Linux i386 > OS arch: 32 bits > works: YES > > CPU: intel > CPU arch: x86_64 > OS: Debian GNU/Linux amd64 > OS arch: 64 bits > works: NO > > CPU: amd > CPU arch: x86_64 > OS: Debian GNU/Linux i386 > OS arch: 32 bits > works: YES > > CPU: amd > CPU arch: x86_64 > OS: Debian GNU/Linux amd64 > OS arch: 64 bits > works: NO > > In short it doesn't work on a 64 bit OS. > > I tried to see the source code for the squeak vm because it is the > primitives that are failing but I got confused and gave up. > > The interesting part that I found was this: > > static char localHostName[MAXHOSTNAMELEN]; > static u_long localHostAddress; /* GROSS IPv4 ASSUMPTION! */ > > assigned in: > > /* start a new network session */ > > sqInt sqNetworkInit(sqInt resolverSemaIndex) > { > if (0 != thisNetSession) > return 0; /* already initialised */ > gethostname(localHostName, MAXHOSTNAMELEN); > localHostAddress= nameToAddr(localHostName); > thisNetSession= clock() + time(0); > if (0 == thisNetSession) > thisNetSession= 1; /* 0 => uninitialised */ > resolverSema= resolverSemaIndex; > return 0; > } > > by means of: > > static int nameToAddr(char *hostName) > { > struct hostent *he; > > lastError= 0; /* ditto */ > if ((he= gethostbyname(hostName))) > return ntohl(*(long *)(he->h_addr_list[0])); > lastError= h_errno; /* and one more ditto */ > return 0; > } > > there it appears to call a system function (gethostbyname) > and to convert the result struct first entry on array h_addr_list. > > Well the point is, this is for someone with more experience with the > socket plugin in squeak. > > So, it is someone trying to fix this? Are there any news here? > It is a structural problem, because before this I could connect to the network in > my 64 bit OS on my x86_64 architecture without the ia32libs on debian. For these test > I installed the ia32libs package of debian in order load and start the closure vm. > > Maybe Jose Luis Redrejo has a hint about how to build the vm in order to having > a full networking vm/image. > > Or someone more involved with the internals of the vm. > I forgot to mention, this happens with the pharo recommended vm on: pharo-vm-0.15.2d-linux.zip but also with the squeak closure vm on: Squeak-3.10-6.i686-pc-linux-gnu.tar.gz that gives the following messages (the last one is the important) on trying to open a repository with monticello on my 64 bit OS. miguel@laptop:~/Squeak-3.10-6/i686-pc-linux-gnu/usr/local/lib/squeak/3.10-6$ ./squeak /home/miguel/azteca/magma.image ioLoadModule(./UUIDPlugin): libuuid.so.1: cannot open shared object file: No such file or directory ioLoadModule(UUIDPlugin): UUIDPlugin: cannot open shared object file: No such file or directory getaddrinfo: Name or service not known -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 24, 2009

[Pharo-project] Networking on images running on 64 bit OSes.

by Miguel Enrique CobÃ¡ Martinez

Is someone working on issues: http://code.google.com/p/pharo/issues/detail?id=1031 http://code.google.com/p/pharo/issues/detail?id=961 http://code.google.com/p/pharo/issues/detail?id=794 Without them fixed the in-image network doesn't work. CPU: intel CPU arch: x86 OS: Debian GNU/Linux i386 OS arch: 32 bits works: YES CPU: intel CPU arch: x86_64 OS: Debian GNU/Linux amd64 OS arch: 64 bits works: NO CPU: amd CPU arch: x86_64 OS: Debian GNU/Linux i386 OS arch: 32 bits works: YES CPU: amd CPU arch: x86_64 OS: Debian GNU/Linux amd64 OS arch: 64 bits works: NO In short it doesn't work on a 64 bit OS. I tried to see the source code for the squeak vm because it is the primitives that are failing but I got confused and gave up. The interesting part that I found was this: static char localHostName[MAXHOSTNAMELEN]; static u_long localHostAddress; /* GROSS IPv4 ASSUMPTION! */ assigned in: /* start a new network session */ sqInt sqNetworkInit(sqInt resolverSemaIndex) { if (0 != thisNetSession) return 0; /* already initialised */ gethostname(localHostName, MAXHOSTNAMELEN); localHostAddress= nameToAddr(localHostName); thisNetSession= clock() + time(0); if (0 == thisNetSession) thisNetSession= 1; /* 0 => uninitialised */ resolverSema= resolverSemaIndex; return 0; } by means of: static int nameToAddr(char *hostName) { struct hostent *he; lastError= 0; /* ditto */ if ((he= gethostbyname(hostName))) return ntohl(*(long *)(he->h_addr_list[0])); lastError= h_errno; /* and one more ditto */ return 0; } there it appears to call a system function (gethostbyname) and to convert the result struct first entry on array h_addr_list. Well the point is, this is for someone with more experience with the socket plugin in squeak. So, it is someone trying to fix this? Are there any news here? It is a structural problem, because before this I could connect to the network in my 64 bit OS on my x86_64 architecture without the ia32libs on debian. For these test I installed the ia32libs package of debian in order load and start the closure vm. Maybe Jose Luis Redrejo has a hint about how to build the vm in order to having a full networking vm/image. Or someone more involved with the internals of the vm. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 23, 2009

Re: [Pharo-project] Recursion - should there be a limit?

by Michael van der Gulik

On Sun, Aug 23, 2009 at 4:50 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Hello all, > > I (stupidly) created a runaway recursion that happened to be in a Seaside > app that uses LDAPLayer, and that is currently using drives shared over a > pre-production vpn from a 64 bit Ubuntu system. Hopefully you won't think > less of me for not immediately thinking of infinite recursion as the cause > of the problems. It did what is IMHO the worst thing a program can do: it > just stopped responding. It makes sense now, and the next time I see the > IDE get sluggish and finally lock up, I will probably think of recursion > before looking for strange causes. As it was, I simply moved breakpoints > around (making liberal use of the End Process button on Ubuntu's system > monitor) until I finally put one in front of something that I thought should > have worked, and in fact was the culprit. > > For good or bad, Dolphin would promptly complain of the callstack being too > deep, after which the mistake is fairly easy to find. I have never had > problems with that limit, but IIRC others have. Would it be simple to add > an optional limit on the stack depth? Would you do it, or would it be > asking for trouble? Is there a less invasive way to aid in debugging this > scenario? > For interest's sake, I'm eventually going to be implementing a solution to this called "Dominions". No promises though; I write code slowly but constantly, so it will get written but maybe not this year: http://gulik.pbworks.com/Dominions Briefly, a dominion is used for resource management. You run your code in a "dominion", which has memory, CPU, network and disk usage limits put on it. Different parts of Squeak (well, SecureSqueak) would need to be modified to support this: the scheduler, object creation (and GC?), network, file usage. Yea, it might be slow, but I need resource control more than I need speed. If you ran your code in a dominion and it ignited a fork bomb, only that dominion would be affected. It would run out of memory, stall and alert that dominion's manager... or something. The rest of the image would continue fine, including the UI so that you could debug stuff. That would give Java a good run for its money. Ever had an OutOfMemoryException on a production server before? Gulik. -- http://gulik.pbwiki.com/

Aug. 23, 2009

Re: [Pharo-project] over bloated image workaround

by Igor Stasenko

2009/8/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > the goal of pharo is also to avoid VW runtime packager (because the > package tries to statically find how to reduce > image size which is ***really*** difficult in a dynamic language. > Now Pavel got a 2mb image based on pharo: I imagine that we will be > able to start from this one to build up > pharo in the future :) > > 2mb is very very good size, especially for embedded solutions. > On Aug 23, 2009, at 3:14 AM, Carlos Crosetti wrote: > >> Mariano, Ivery value those scripts! >> >> My image is small, but anyway I couldn't resist the challenge and >> tried so far, >> I got my image shrunk down from 20.7mb to 18.2mb. >> >> This is probably a candidate for extending something I may >> call "the Pharo equivalent to VW Runtime Packager" - I am not so >> familiar to Pharo to know >> if such a feature exist. >> >> Regards, Carlos >> -----Mensaje original----- >> De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ]En nombre de Mariano Martinez Peck >> Enviado el: SÃ¡bado, 22 de Agosto de 2009 05:53 p.m. >> Para: Pharo-project(a)lists.gforge.inria.fr >> Asunto: Re: [Pharo-project] over bloated image workaround >> >> >> >> On Sat, Aug 22, 2009 at 5:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >> > wrote: >> We should check that. >> Can you open a ticket? >> >> >> Ok, done: http://code.google.com/p/pharo/issues/detail?id=1083 >> >> >> >> >> Stef >> On Aug 21, 2009, at 11:25 PM, Mariano Martinez Peck wrote: >> >> > Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or >> > similar. Marcelo Cortez gave me a couple of changes (fileouts) that >> > make my images go back to their original size or similar. For >> > example, it was tasted in a 87 MB and after this changes and this >> > stuff, it become in 24 MB. The same with another one from 65M to >> 35M. >> > >> > If you have a big Pharo image, save a copy and do this tests: >> > >> > 1) File in all the changes I attach. >> > 2) Go to a workspace and evaluate: >> > >> > OBDPAbstract reinitAllCache. >> > LocalSends Â allInstances first initialize. >> > EventManager Â resetMap. >> > Smalltalk garbageCollect. >> > >> > Did this make your image too much smaller? >> > >> > When I evaluate SystemNavigation default obsoleteBehavio size Â I >> > get a a number of 3 digits. >> > >> > Perhaps it is a matter with the OB. I guess it generates dependences >> > while you are developing a class and it creates on the fly an >> > obsolteClassXXX when there is something that doesn't exist. Â Then >> > they are processes and they are never garbage collected. >> > >> > When Â SmalltalkImage tries to fix the obsoletes delegates to the >> > literal frames of the compiled methods so that to search references >> > to the obsoletes. But references were not gone because they weren't >> > garbage collected. The same method finishes with error if the >> > obsoletes > 0. >> > >> > Does anyone has a comment for this? >> > >> > I tried to do my best to write in English from what Marcelo told me >> > and from what I can understand from the changesets. >> > >> > Best, >> > >> > Mariano _______________________________________________ >> > 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 > -- Best regards, Igor Stasenko AKA sig.

Aug. 23, 2009

Re: [Pharo-project] Offscreen drawing...

by John M McIntosh

Lawson, the browswer plugin logic does this type of interaction. The x11 unix running as a separate process draws to the X11window of the browser process, and uses pipes to coordinate data, movement of UI commands file upload/ download requests. The Window's version does a similar things I believe. The macintosh carbon VM (non x11 based) is a bit more complex since it can't share the drawing space of the browser task, it setups a shared memory space that is the backing store for squeak drawing, and for a semaphore Again unix pipes are used to coordinate UI commands but also draw commands back to the browser. The semaphore is used to regulate drawing between the VM and the browser process since the VM can generate drawing faster than the browser can render it on dual CPU machines. I'm not sure if this is what you are looking for? Squeak also has the concept of off screen forms (squeak surfaces) where you can render a form into a chunk of memory, or have something else render the visual data into that memory. The Quicktime plugin in the macintosh plugins source sets up a surface that quicktime draws into, then when quicktime renders the image and does a callback our callback routine signals a semaphore that then triggers a squeak process that draws the Form to the squeak display. The reverse is in Squeak you draw to the Form it renders the bits into the memory space allocated outside of the squeak oops space. On 23-Aug-09, at 1:34 AM, Lawson English wrote: > Is there a way to render into an offscreen buffer where the actual > host > hardware's address is specified? I realize that at the level of > implementing the hooks for the VM, this must be possible, but is it > [easily] possible to redirect the memory space that Squeak renders > to at > runtime, rather than during creation of the VM? > > I'm trying to understand how one might use the shared memory space of > Second LIfe's media plugin to be the drawing region of a regular > Squeak > Smalltalk workspace/drawing window. Being able to have fully active > Smalltalk-on-a-prim in SL would rock, especially if you could have a > choice of whether to work directly with the in-world rendering or with > the normal Squeak window's rendering. > > > The plugin can live in a separate process and communicate higher level > events via sockets and share memory for rendering so its not necessary > to have a fully standalone plugin. From the SL side, you could > conceivably have a regular Squeak development environment with the > added > ability to use a specified hardware buffer instead/in addition to the > regular Squeak window. Sorta like what seaside sorta does, but without > the overhead of rendering via html. > > > Lawson > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Aug. 23, 2009

Re: [Pharo-project] [BUG]NewInspector(Object)>>doesNotUnderstand: #extent:

by Damien Cassou

On Sun, Aug 23, 2009 at 11:41 AM, <roel.wuyts(a)gmail.com> wrote: > I opened a Pharo1.0-10418-BETAdev09.08.2 image, opened a class browser, > right-clicked the title bar of the System Browser, and selected Inspect. > An inspector opens (successfully), as well as a DNU that NewInsecptor > does not understand the message 'extent:'. > > Browsing around a bit shows that it expects that SystemBrowser expects > that it opens a morph and sends the 'etent:' message after opening the > inspector (note that it would be better to first resize before to avoid > redrawing and flickering). Hi Roel, http://code.google.com/p/pharo/issues/detail?id=1085 -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 23, 2009

Re: [Pharo-project] over bloated image workaround

by Esteban Lorenzano

+1 On 2009-08-23 10:55:01 -0300, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> said: > the goal of pharo is also to avoid VW runtime packager (because the > > package tries to statically find how to reduce > image size which is ***really*** difficult in a dynamic language. > Now Pavel got a 2mb image based on pharo: I imagine that we will be > > able to start from this one to build up > pharo in the future :) > > > On Aug 23, 2009, at 3:14 AM, Carlos Crosetti wrote: > >> Mariano, Ivery value those scripts! >> >> My image is small, but anyway I couldn't resist the challenge and > >> tried so far, >> I got my image shrunk down from 20.7mb to 18.2mb. >> >> This is probably a candidate for extending something I may >> call "the Pharo equivalent to VW Runtime Packager" - I am not so > >> familiar to Pharo to know >> if such a feature exist. >> >> Regards, Carlos >> -----Mensaje original----- >> De: >> pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bou > nces(a)lists.gforge.inria.fr > >> ]En nombre de Mariano Martinez Peck >> Enviado el: SÃ¡bado, 22 de Agosto de 2009 05:53 p.m. >> Para: Pharo-project(a)lists.gforge.inria.fr >> Asunto: Re: [Pharo-project] over bloated image workaround >> >> >> >> On Sat, Aug 22, 2009 at 5:42 AM, StÃ©phane Ducasse <stephane.ducasse@inr > ia.fr > >>> wrote: >> We should check that. >> Can you open a ticket? >> >> >> Ok, done: http://code.google.com/p/pharo/issues/detail?id=1083 >> >> >> >> >> Stef >> On Aug 21, 2009, at 11:25 PM, Mariano Martinez Peck wrote: >> >>> Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or >>> similar. Marcelo Cortez gave me a couple of changes (fileouts) that >>> make my images go back to their original size or similar. For >>> example, it was tasted in a 87 MB and after this changes and this >>> stuff, it become in 24 MB. The same with another one from 65M to > >> 35M. >>> >>> If you have a big Pharo image, save a copy and do this tests: >>> >>> 1) File in all the changes I attach. >>> 2) Go to a workspace and evaluate: >>> >>> OBDPAbstract reinitAllCache. >>> LocalSends allInstances first initialize. >>> EventManager resetMap. >>> Smalltalk garbageCollect. >>> >>> Did this make your image too much smaller? >>> >>> When I evaluate SystemNavigation default obsoleteBehavio size I >>> get a a number of 3 digits. >>> >>> Perhaps it is a matter with the OB. I guess it generates dependences >>> while you are developing a class and it creates on the fly an >>> obsolteClassXXX when there is something that doesn't exist. Then >>> they are processes and they are never garbage collected. >>> >>> When SmalltalkImage tries to fix the obsoletes delegates to the >>> literal frames of the compiled methods so that to search references >>> to the obsoletes. But references were not gone because they weren't >>> garbage collected. The same method finishes with error if the >>> obsoletes > 0. >>> >>> Does anyone has a comment for this? >>> >>> I tried to do my best to write in English from what Marcelo told me >>> and from what I can understand from the changesets. >>> >>> Best, >>> >>> Mariano _______________________________________________ >>> 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

Aug. 23, 2009

Re: [Pharo-project] over bloated image workaround

by StÃ©phane Ducasse

the goal of pharo is also to avoid VW runtime packager (because the package tries to statically find how to reduce image size which is ***really*** difficult in a dynamic language. Now Pavel got a 2mb image based on pharo: I imagine that we will be able to start from this one to build up pharo in the future :) On Aug 23, 2009, at 3:14 AM, Carlos Crosetti wrote: > Mariano, Ivery value those scripts! > > My image is small, but anyway I couldn't resist the challenge and > tried so far, > I got my image shrunk down from 20.7mb to 18.2mb. > > This is probably a candidate for extending something I may > call "the Pharo equivalent to VW Runtime Packager" - I am not so > familiar to Pharo to know > if such a feature exist. > > Regards, Carlos > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ]En nombre de Mariano Martinez Peck > Enviado el: SÃ¡bado, 22 de Agosto de 2009 05:53 p.m. > Para: Pharo-project(a)lists.gforge.inria.fr > Asunto: Re: [Pharo-project] over bloated image workaround > > > > On Sat, Aug 22, 2009 at 5:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > We should check that. > Can you open a ticket? > > > Ok, done: http://code.google.com/p/pharo/issues/detail?id=1083 > > > > > Stef > On Aug 21, 2009, at 11:25 PM, Mariano Martinez Peck wrote: > > > Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or > > similar. Marcelo Cortez gave me a couple of changes (fileouts) that > > make my images go back to their original size or similar. For > > example, it was tasted in a 87 MB and after this changes and this > > stuff, it become in 24 MB. The same with another one from 65M to > 35M. > > > > If you have a big Pharo image, save a copy and do this tests: > > > > 1) File in all the changes I attach. > > 2) Go to a workspace and evaluate: > > > > OBDPAbstract reinitAllCache. > > LocalSends allInstances first initialize. > > EventManager resetMap. > > Smalltalk garbageCollect. > > > > Did this make your image too much smaller? > > > > When I evaluate SystemNavigation default obsoleteBehavio size I > > get a a number of 3 digits. > > > > Perhaps it is a matter with the OB. I guess it generates dependences > > while you are developing a class and it creates on the fly an > > obsolteClassXXX when there is something that doesn't exist. Then > > they are processes and they are never garbage collected. > > > > When SmalltalkImage tries to fix the obsoletes delegates to the > > literal frames of the compiled methods so that to search references > > to the obsoletes. But references were not gone because they weren't > > garbage collected. The same method finishes with error if the > > obsoletes > 0. > > > > Does anyone has a comment for this? > > > > I tried to do my best to write in English from what Marcelo told me > > and from what I can understand from the changesets. > > > > Best, > > > > Mariano _______________________________________________ > > 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

Aug. 23, 2009

Re: [Pharo-project] over bloated image workaround

by Adrian Lienhard

On Aug 23, 2009, at 03:14 , Carlos Crosetti wrote: > Mariano, Ivery value those scripts! > > My image is small, but anyway I couldn't resist the challenge and > tried so > far, > I got my image shrunk down from 20.7mb to 18.2mb. > > This is probably a candidate for extending something I may > call "the Pharo equivalent to VW Runtime Packager" - I am not so > familiar to > Pharo to know > if such a feature exist. Yes, see ScriptLoader>>cleanUpForRelease and >>cleanUpForProduction. It doesn't clean up OB caches though, since I wrote these scripts for Pharo-core. Cheers, Adrian > > Regards, Carlos > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de > Mariano > Martinez Peck > Enviado el: SÃ¡bado, 22 de Agosto de 2009 05:53 p.m. > Para: Pharo-project(a)lists.gforge.inria.fr > Asunto: Re: [Pharo-project] over bloated image workaround > > > > > > On Sat, Aug 22, 2009 at 5:42 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > We should check that. > Can you open a ticket? > > > Ok, done: http://code.google.com/p/pharo/issues/detail?id=1083 > > > > > > Stef > > On Aug 21, 2009, at 11:25 PM, Mariano Martinez Peck wrote: > >> Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or >> similar. Marcelo Cortez gave me a couple of changes (fileouts) that >> make my images go back to their original size or similar. For >> example, it was tasted in a 87 MB and after this changes and this >> stuff, it become in 24 MB. The same with another one from 65M to 35M. >> >> If you have a big Pharo image, save a copy and do this tests: >> >> 1) File in all the changes I attach. >> 2) Go to a workspace and evaluate: >> >> OBDPAbstract reinitAllCache. >> LocalSends allInstances first initialize. >> EventManager resetMap. >> Smalltalk garbageCollect. >> >> Did this make your image too much smaller? >> >> When I evaluate SystemNavigation default obsoleteBehavio size I >> get a a number of 3 digits. >> >> Perhaps it is a matter with the OB. I guess it generates dependences >> while you are developing a class and it creates on the fly an >> obsolteClassXXX when there is something that doesn't exist. Then >> they are processes and they are never garbage collected. >> >> When SmalltalkImage tries to fix the obsoletes delegates to the >> literal frames of the compiled methods so that to search references >> to the obsoletes. But references were not gone because they weren't >> garbage collected. The same method finishes with error if the >> obsoletes > 0. >> >> Does anyone has a comment for this? >> >> I tried to do my best to write in English from what Marcelo told me >> and from what I can understand from the changesets. >> >> Best, >> > >> Mariano _______________________________________________ >> 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

Aug. 23, 2009