On Tue, 2009-05-05 at 08:53 -0700, John M McIntosh wrote: > No, the intent is preserve the images as they are shipped see > > http://www.mobilewikiserver.com/ST80Docs.html > & John, while looking at the above link I instantly developed a massive need for an iphone. That is sooo good. Thanks!!
Norbert > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
