No, the intent is preserve the images as they are shipped see http://www.mobilewikiserver.com/ST80Docs.html & http://www.mobilewikiserver.com/SqueakDocs.html
However if you have a script that removals all the *extra* things that people could run for server images that would be helpful at least to me, I realize that most folks don't care about 8MB, but on tiny devices that 8MB is golden... On 5-May-09, at 1:28 AM, stéphane ducasse wrote: > John > > for your images did you remove tests and other unnecessary stuff? > The 10300 is 12.7mb without removing all kind of crap like the > scriptLoader and the tests. > I hope that we will be able to slowly get more and more modular: > once project/bookmorph are gone. > I imagine (did not read carefully the details of we got about the > chase of the unclosed handles) > that the startup behavior could be also improved. > > Stef > > On May 5, 2009, at 10:17 AM, John M McIntosh wrote: > >> Tsk, well I was off to bed, but thought I should make some notes. >> >> Last night I push out two electronic books showing smalltalk-80 >> based source code to Apple for iPhone review. >> One was based on the latest pharo of end of april 09 with closures >> the other based on the sq3.10.2-719web09.04.1.zip no closures. >> The two e-books apps are identical except for the code base. >> >> I dropped the wikiserver stuff into both, happy since the changes >> required were non-existent for pharo and one or two for sq3.10.2 >> >> (a) The sq3.10.2 version was missing some of the extra add-on Pier >> stuff, and has the LGPL Swazoo which makes some folks run for the >> fire exit. >> >> (b) The pharo image is 20.2 mb, the sq3.10.2 is 25.2 mb, so 5MB >> bigger. >> >> (c) The pharo image needed about 35mb of ram to be happy, the sq >> 3.10.2 about 40mb >> (c2) The pharo image ramps to the welcome screen using 19.23 mb >> ram, 97.12mb virtual >> (c3) The sq 3.10.2 image ramps using 19.05mb and 102.12 virtual. >> This makes sense because I avoid a full gc and doing allInstances, >> so the code base is really startup logic and seaside. >> (I had to fix the sq 3.10.2 image because of ignored bug using >> allInstances I reported years back, never fixed, but fixed in pharo >> last fall). >> >> (d) The pharo image needs 2.6 to 6.6% cpu on the iphone at idle, >> the sq 3.10.2 needs 8 to 18% >> (to be fair here I could bring some fixes into the 3.10.2 image to >> reduce the cpu time, but really those fixes should have gone in >> years ago...) >> >> (e) The sq 3.10.2 book feels sluggish. the pharo less so. So the sq >> 3.10.2 excessive CPU usage is the usability killer here. >> >> To be fair WikiServer is happy with 20MB of ram with a 10.5MB image >> size, and runs with a 0 to 0.9% cpu usage at idle, starup ram of >> 11.69, virtual memory of 90.34 >> Lots of hours to get there.. >> >> PS I see the etoys image is only 16.4 MB, well that doesn't include >> seaside etc, but if you need that you should start with etoys as >> the base and add pier and seaside, less bloated I'd guess, and >> supported for that etoy feature set you need? = = = ======================================================================== John M. McIntosh <[email protected]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
