November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] What is the limit

by Esteban A. Maringolo

El Tue Nov 25 2014 at 4:19:46 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > 2014-11-25 20:11 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > > >> But it will not move farther by writing next lengthy mails to this list > >> ;-) > > > This means I should restrain myself from sharing my opinion on some > topics > > for which I use Pharo on a daily basis? > > No, that is an explanation why my mail is not longer :-) > > Excellent point ;)

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Pavel Krivanek

2014-11-25 20:11 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > > > El Tue Nov 25 2014 at 3:54:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > escribiÃ³: >> >> 2014-11-25 18:51 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > > >> >> > I'd love to download a no morphic image and load my configurations on >> > top of >> > it, but it really won't make much difference in my current usage >> > scenarios. >> >> In fact, we already achieved this goal in June ;-) >> >> https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… > > > It will be available in Pharo 4. Great :) > >> But it will not move farther by writing next lengthy mails to this list >> ;-) > > > This means I should restrain myself from sharing my opinion on some topics > for which I use Pharo on a daily basis? No, that is an explanation why my mail is not longer :-) -- Pavel > > Regards,

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Esteban A. Maringolo

El Tue Nov 25 2014 at 3:54:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > 2014-11-25 18:51 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > > > I'd love to download a no morphic image and load my configurations on > top of > > it, but it really won't make much difference in my current usage > scenarios. > > In fact, we already achieved this goal in June ;-) > https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo- > 4.0-Bootstrap-Step-3-ConfigurationOfIDE/ It will be available in Pharo 4. Great :) But it will not move farther by writing next lengthy mails to this list ;-) > This means I should restrain myself from sharing my opinion on some topics for which I use Pharo on a daily basis? Regards,

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Pavel Krivanek

2014-11-25 18:51 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > > El Tue Nov 25 2014 at 1:22:50 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > escribiÃ³: >> >> I think is you who is confusing apple and oranges. >> at first time, a check of my iphone shows that more than half of the apps >> I use are bigger than 30m (and 30% of them are regularly 50m and moreâ¦ I >> even have apps 500+)â¦ and those applications are the ones that I use the >> most. >> no games there. They are: fb, mail, whatsapp, keynote, etc. (ah, noâ¦ there >> is a sudoku there.. 60m :P) >> > > Again... FB, MAIL, WhatsApp, KeyNote. Those are super mainstream > applications. Tell me about a "regular" native app. I'm not fluent with iOS > to compare. > > Duolingo, TED, Flipboard, and even Google's Play Store all take ~15 MB each. > > I build Android apps, packed with lots of third party libraries and they are > around ~2-3MB including some static assets. They're small and gzipped, for > sure, but I don't find a better way to trim the image to be closer to that > other than zipping it. > >> >> Now, for distributing your application your image will be not equal to >> your development image. You will strip things and reduce some others (there >> is a shrink process that Pavel does in the Pharo-minimal image and time ago >> I made some experiments and I ended with an usable 8m image running in >> iPhoneâ¦ I even got a 4m image but no morphic was present so it was using >> ObjectiveCBridge to show some screens with functionalityâ¦) > > > Modularity is the key, and we'll not have it, so I'm fine with what you guys > do. > I'd love to download a no morphic image and load my configurations on top of > it, but it really won't make much difference in my current usage scenarios. In fact, we already achieved this goal in June ;-) https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… But it will not move farther by writing next lengthy mails to this list ;-) -- Pavel >> Also, for production you will be removing sources and changes, so you do >> not have to take those into account (even taking it, they are never loaded >> into image, they are accessed when needed). > > > Unless you want to apply (compile/file-in) changes on the running image, on > that case you'll need a changes file. (please tell me I've been wrong all > this time). > >> >> Soâ¦ I think a mobile final app of 20m - 50m (and take into account that a >> 50m app will be really big, DrGeo2 was 35m) is perfectly reasonable. Is not >> huge and most applications nowadays (even the stupid ones) occupies way >> more. > > > On the server, the size doesn't matter to much to me, on mobile I still > consider those weights to be excessive. Particularly if it is about code and > not static assets. > > Add music, images and video and that size will be nothing. > > >> Now, that 5% idle is much-much more worrying that app size. And we already >> have an even VM who does not consumes that (JB did it) It will be integrated >> soon (JB needs to finish I donât know exactly what). > > > This is certainly more important and affects me more than transfering 50 > extra megs to the servers on each release. So please ignore all I said > before and focus on this. :) I look forward to see this available! > > Regards!

Nov. 25, 2014

Re: [Pharo-dev] Pharo is mine

by Thierry Goubier

Hi Kilon, I updated the configurations (and the Readme as well). It should load an up to date version on Pharo3 and Pharo4, whether in stable or in development mode. Note, I use baselines in with both github:// urls (stable) and gitfiletree:// urls (development). Thierry Le 25/11/2014 00:00, kilon alios a Ã©crit : > > > >> I'm slowly learning to use baselines and github:// urls..., but the > gitfiletree ones are so convenient for development. > > I used baseline for Nireas because it allows other users to install my > app without the need to install git, I have not used gitfiletree because > I heard that some people have corrupt commits with it or something > similar and I am not experienced enough with git to deal with such > issues plus filetree allowed me to use my familiar workflow that I had > with python with command line git and github. But a tool like > gitfieltree or gitfiletree itself is definetly the future of Pharo and > git. Users like me that love git and github need a tool that offers > close integration with git and I am certainly glad gitfiletree is around > . I think I will give gitfiletree another try as well. > >>>Select the abstract class for commands, its AlTreeCommand (in > Al-TreeMorph package). > > no idea where that is, I also used find class and cant find such class. > Where is the Al-TreeMorph package ? > > also I tried some shortcuts CTRL+F does not work for me, it does > nothing. I can open finder manually though.

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Eliot Miranda

On Tue, Nov 25, 2014 at 8:43 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > 2014-11-25 17:24 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> and btwâ¦ spur format will consume more memory. >> > > Why ? > 32-bit Spur grows the image by about 15% over 32-bit V3. This is because - all objects have a 64-bit header, whereas compact headers in V3 mean that small Arrays and CompiledMethods have a 32-bit header. - all objects are padded to a 64-bit boundary whereas in V3 objects are padded to a 32-bit boundary. > If I remember correctly the first Squeak image generated was 3% smaller. > How bigger is the spur Pharo image compared to the regular image ? > No, that was my clerical error that I stupidly wrote up in my first blog post. I corrected the pst a while back. +15% is the consistent result nowadays. Note that 64-bit Spur grows by about another 25%, giving about a 44% increase over V3. but yet, memory management will be a lot more efficient soâ¦ :P >> >> Esteban >> >> On 25 Nov 2014, at 17:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> I think is you who is confusing apple and oranges. >> at first time, a check of my iphone shows that more than half of the apps >> I use are bigger than 30m (and 30% of them are regularly 50m and moreâ¦ I >> even have apps 500+)â¦ and those applications are the ones that I use the >> most. >> no games there. They are: fb, mail, whatsapp, keynote, etc. (ah, noâ¦ >> there is a sudoku there.. 60m :P) >> >> Nowâ¦ size occupied is not the same as size in memory. This is the size >> occupied by all app (binaries + data) and I donât really know of how much >> that would be for real (I know facebook eats a lot)â¦ Pharo, in the other >> side, is not using regularly (in iPhone) more than 32m when executing. >> Thatâs because you are not loading all image in memory, you paginate the >> loading (and Marianoâs phd demonstrated that you usually does not use more >> than 20% of what is inside your image, so most frequently you do not load >> it completely at all). >> >> For DrGeo2 I needed to expand that memory to 64m, but it was still in the >> reasonable numbers. >> >> Now, for distributing your application your image will be not equal to >> your development image. You will strip things and reduce some others (there >> is a shrink process that Pavel does in the Pharo-minimal image and time ago >> I made some experiments and I ended with an usable 8m image running in >> iPhoneâ¦ I even got a 4m image but no morphic was present so it was using >> ObjectiveCBridge to show some screens with functionalityâ¦) >> Also, for production you will be removing sources and changes, so you do >> not have to take those into account (even taking it, they are never loaded >> into image, they are accessed when needed). >> >> Soâ¦ I think a mobile final app of 20m - 50m (and take into account that a >> 50m app will be really big, DrGeo2 was 35m) is perfectly reasonable. Is not >> huge and most applications nowadays (even the stupid ones) occupies way >> more. >> >> Now, that 5% idle is much-much more worrying that app size. And we >> already have an even VM who does not consumes that (JB did it) It will be >> integrated soon (JB needs to finish I donât know exactly what). >> >> Esteban >> >> >> On 25 Nov 2014, at 16:58, Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >> >> Kilon, >> >> The comparison you're doing is wrong, you're comparing apples to oranges. >> >> To start with, I have Android KitKat where a clean Facebook app takes >> 33MB (as per the latest release), Chrome 65MB, etc. You might be counting >> app data as total size, but the data+cache part is variable and subject to >> each device. >> >> 20+ Megs for mobile is HUGE, the only reason to use and download such >> apps is if they are (or are perceived) as "indispensable", like social >> network, mail or browsing. Games fall into a different category, the >> average size for such apps take more space (but are also the first ones to >> be removed when available storage starts to reach its limit). >> >> On the other hand you should compare Pharo apps/with other development >> languages/IDEs/toolkits. Leaving aside GUI-less/file based tools (which are >> smaller) Pharo shines during the development stage taking an order of >> magnitude less than many of the IDEs out there. >> But the produced artifacts, being indistinguishable from the development >> image itself, takes the same size. >> >> Because it is "self contained" it uses only a few shared libraries or >> even complete frameworks like JRE/.net. Pros and Cons of this approach. The >> resource requirements of Pharo (and most Smalltalks) is linear as you add >> more images, you can't leverage "common" code between them. >> >> My servers are "simple web apps" that take ~40MB of image + 100+ MB of >> changes. All built from a clean Pharo image, with all caches flushed. For >> me that is A LOT. Not to mention the constant 5% CPU idling. >> >> I can live with that because the benefits I get outweighs the cons >> mentioned before, but saying that 40MB is not big for a program is not >> true, and it's plainly false on mobile. >> >> And in my opinion, and take this as 100% personal taste/experience, but >> being reckless about size/cpu requirements of the software you build leads >> to bloatware. >> >> Regards! >> >> El Tue Nov 25 2014 at 5:07:26 AM, kilon alios <kilon.alios(a)gmail.com> >> escribiÃ³: >> >>> Ok here are the apps I use that loads of people also have in their >>> phones that are more than 30 MBs >>> >>> 1) PDF Reader - 237MB >>> 2) Facebook - 178 MB >>> 3) Chrome - 148 MB >>> 4) Respawnables (Game) 133 MB >>> 5) Yahoo Mail - 126 MB >>> 6) Firefox - 98 MB >>> 7) Candy Crash Saga - 65 MB >>> 8) G+ - 56 MB >>> 9) Pet Rescue Saga - 53 MB >>> 10) Google Search - 50MB >>> 11) GMAIL - 43MB >>> 12) Facebook Messenger - 35 MB >>> 13) Google Maps - 32 MB >>> 14) Twitter - 30 MB >>> >>> Also a +1.000.000 to Marcus about the fact that in a few years 4 GB Ram >>> will be the standard for mobile platforms. >>> >>> Squeak is around 8Mbs but then I dont use it because it has all sort of >>> issues on android. >>> >>> >> >> > -- best, Eliot

Nov. 25, 2014

Re: [Pharo-dev] NativeBoost

by Eliot Miranda

On Tue, Nov 25, 2014 at 5:06 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Please enlighten me as well. I also do not yet understand the idea of this > unification layer. > "Unification layer" is just a name. IMO Ronie is doing something much more useful. He is architecting the marshalling layer of the FFI so that it can - be portable - work in both the Cog JIT and the Interpreter This is effectively an abstract instruction set for executing low-level machine intsructions. It can be used for FFI call-out marshalling, but it can also be used for low-level code generation, and we are using it in Sista. COnsequently Ronie's "Low code" as it is properly called can be an integral component to both a high-quality FFI and a fast VM. For me this is a useful substrate for an FFI that can be high quality. But note that it is only one component. The other components are - an image-level ABI compiler whose job it is to generate the correct marshalling code for different platforms. The FFI for processors such as IA64/x86-64 is complex, and a compiler is the only performant way to generate correct marshalling code - callback machinery. I have already designed and implemented this in the context of Alien. The architecture is portable; it can function correctly on x86-64 and ARM, not just x86. > So far we have > 1. FFI -> not maintained very well, no callbacks > This is simply false. The FFI was in active use at Qwaq where Cog was first implemented. I have continued to maintain and enhance it, reimplementing it so that it is a pure Smalltalk plugin with no assembler support code, so that it is reentrant. Recently Doug McPherson has implemented the ARM version alongside my original x86 version. > 2. Alien -> should provide the callbacks, hard to find a predefined > package/VM combination > Every Cog VM supports Alien callbacks. The Alien package Alien-eem.24 at http://www.squeaksource.com/Alien "jsut works", at least in Squeak. Try it. > 3. NativeBoost was supposed to be the better one, was based on AsmJit and > replace 1. and 2. > I disagree. NativeBoost has not been designed with portability in mind, nor has it been designed with interpretive VMs in mind. Further Igor made no attempt to work with me in providing the support he needs from Cog to integrate NativeBoost when I visited Rmod early this year. According to my knowledge it was the goal to continue with NB, integrate it > (which is done) > and move it forward as the single solution for external calls and > callbacks. > > So why do we need another layer (and mixed approach with still old FFI) > instead of working > on bringing NB to the other platforms as well and work on a good > NativeBoost. Wasn't there > already work for AsmJit for ARM? > We have a functional FFI at the moment, FFI + Alien for callbacks. This is in industrial use, both at Terf (nee Qwaq) and Cadence. We have NativeBoost that does not work on ARM. We have Ronie's work on low code that fits both with a well-architected FFI and with Sista. I am frustrated that there is no coherence in our work here. I have a clear understanding of what architecture can work, a clear vision, and yet other than Ronie, all I see is FUD ("Alien doesn't work", "FFI doesn't work", "Alien callbacks don't work"; all false). I wish this wasn't the case. I do not have time right now to work on all of Spur, Spur 64, Sista and find time to architect the FFI. But I know how this stuff works (I've implemented what works now) and as the leads VM architect isn't it right that the community try and work with me rather than without me? > Thx > T. > > > Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr > > Von: "Markus Fritsche" <mfritsche(a)reauktion.de> > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > Betreff: Re: [Pharo-dev] NativeBoost > > > > On 2014-11-24 23:34, Esteban Lorenzano wrote: > > > > > now, since the most common use of NB is for FFI, and NB is not present > > > in all platforms, we are working (Ronie, in this case) in a âunified > > > FFIâ, which will provide a common abstraction layer for several FFI > > > frameworks (NB, OldFFI, Alienâ¦). With that, we can choose which one > > > of the frameworks we use depending on the situation (but ideally, we > > > will maintain just one, the one that fits better in Pharo). > > > > I feel that providing a common abstraction layer on top of the various > > approaches to interface to C/ C++ libraries won't be useful and should > > be considered a waste of resources. From what I understood from the > > documentation, NativeBoost seems to be the most complete interface > > technology yet. I would rather (as in: If I was capable) try to get > > NativeBoost into Squeak and add the functionality missing that still > > justifies the existence of FFI and Alien than creating an abstraction > > layer that can't cope with the differences in the tools (which was the > > reason for their first creation despite the available ones). > > > > I tried to play around with FFI and creating plugins in Squeak and > > failed (I didn't try very hard though). NativeBoost was the first thing > > I was able to wrap a DLL myself and understand how to do it. The only > > thing that I wasn't able to wrap my mind around was finalization, but > > that is also due to the fact that I couldn't find understandable (read: > > understandable to me) documentation about the underlying concept in > > Pharo. > > > > (OT: Finalization and concurrency probably is more about the concept > > rather than the implementation in Pharo?) > > > > This is a piece of opinion. We all know, that unfortunately, one doesn't > > have to have knowledge to have an opinion, so if my opinion is wrong due > > to lack of knowledge, please ignore it. > > > > Best regards, > > Markus > > > > > > > > -- best, Eliot

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by kilon alios

*"I also speak about user experience. Updating a large app takes more time than updating a small one. A shorter period of installation means more conversions."* the average connection speed for wifi adsl is like 1 mb/s even for a 30 mb/s its like 30 seconds and maybe another 30 to install. Is that so bad ? Even on slow mobile phone connection should not be more than few minutes. *"So deploying an app to manage 1000 pictures is the same as deploying THE SAME APP to manage Instagram?* *Sorry, but I don't get this. Usually your app server and your app data don't even share the same host computer, considering it is only one and it is not sharded/clustered."* Again as a user how am I suppose to know the diffirence ? All I care is how much space this app needs to run. In case of pharo I have not even bothered to analyse how much every single thing takes space. As a user how I benefit from knowing that the executable is 10 mbs when the app needs 1 GB to run smoothly ? Is it unreasonable that I care about the size of the whole package and even its future size under normal usage than size of individual parts ? *"It runs on Android. Even though it doesn't have a native Android look, nor it complies to most of the Android Development Guidelines.* *But I agree that 30 MBs is not something to worry about. I simply raised my longwinded opinion that I don't consider 30MB to be small on a mobile device."* it does ? now you have my full attention. I know that there was a build but I heard it had issues and was not working. I saw recently work on improving the multitouch and on screen keyboard but again I have seen no build . Does multitouch work properly ? Squeak has problem with multitouch. If pharo is usable on Android I want it in my Nexus NOW! How I do that ? Is there a simple way to install it ? I would love to try it. I would prefer not to have to build it myself. I really dont care about the native look and how much it complies, the fact that I will be able to run my pharo apps on my nexus and my galaxy note tablet would be awesome.

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Richard Sargent

EstebanLM wrote >> On 24 Nov 2014, at 23:48, > phil@ > wrote: >> >> On mobile, large apps are not staying installed for long as they are all >> competing for the always too small space. >> >> If say Twitter will do with is huge size, other apps will be compared to >> it. Which means that a 30 mÃ©gas app us a monster asking for removal. >> > the average size of any app in iPhone is around 25m (or it was in 2012, > nowadays should be more), so I hardly believe that :) > > I have a "flashlight" app installed. It has one feature: to turn on the > light. It's total storage on my S3 is 26.3 MB. ... for a freaking > flashlight! > > Amazon app: 67 MB > Costco: 26 MB > Facebook: 208 MB!! > Google Play Books (with few books): 32 MB > Google Search: 81 MB > > I agree there is value in a small footprint, but not that much. As others > have said: Moore's law. > > > Esteban > >> I rooted my phone to be able to remove vendor apps in order to get some >> more space. >> >> Phil >> >> Le 24 nov. 2014 22:31, "kilon alios" < > kilon.alios@ > <mailto: > kilon.alios@ > >> a Ã©crit : >> I have an OS (Yosemite) thats takes 5 out my 8 GB of Ram. Google Chrome >> with opened 20 tabs that consumes around 1 GB of Ram. Games that eat Ram >> like peanuts and I do 3d graphics with blender which also can consume GBs >> like no tommorow. Music productions was not much diffirent either. I >> watch movies which are several GBs each. I have 1 TB drive its already >> half full (mainly because of movies). >> >> 32 mb is nothing. XCode with an empty project cosumes 130 MB. Dont forget >> that it loads no libraries like Pharo and definetly is no live coding >> enviroment. >> >> Pharo consumes around 80MBs >> >> Emacs with zero guis still consumes 40mbs. >> >> Small is not beautiful its irrelevant. >> >> Unless you are on a platform that has real problem with sizes. >> >> On Mon, Nov 24, 2014 at 10:29 PM, Hilaire < > hilaire@ > <mailto: > hilaire@ > >> wrote: >> Pharo 1.4 image = 15MB >> Pharo 3 image = 22MB >> Pharo4 image = 32MB >> >> Don't know about Pharo 2.0 as, skip it. >> >> Is there a limit? >> >> Hopefully I gave up on the idea of tablet use but aren't we loosing the >> sight on small is beautiful? >> >> Hilaire >> >> -- >> Dr. Geo - http://drgeo.eu <http://drgeo.eu/> >> iStoa - http://istoa.drgeo.eu <http://istoa.drgeo.eu/> >> >> >> -- View this message in context: http://forum.world.st/What-is-the-limit-tp4792049p4792243.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Esteban A. Maringolo

El Tue Nov 25 2014 at 2:06:36 PM, kilon alios <kilon.alios(a)gmail.com> escribiÃ³: > > >> The comparison you're doing is wrong, you're comparing apples to > oranges. > > If humans had not the capacity to compare apple and oranges and find the > differences we would never have came down the trees. > It wasn't humans what came down the trees. But I got it ;-) > I don't mind being wrong, thats life. > > its huge for you, I have no problem with that , I wish you success to your > ever going saga of reducing size. I have no clue how tiny sizes will > benefit you as developer and your users. I would love to read your > reasoning. > > I am talking about the user experience , I am an adroind user I am not an > android developer nor do I care to enter the suffering zone of android and > web development , I had enough nightmares with C++. Out of curiosity I > check app reviews because I like to know that the app I am about to install > is not crap . I never , ever, ever , recall anyone complain about an app > being 60Mbs and saying "fuck this bloated shit I am unistalling it right > now" . 99.9% the complains are that the app was not even able to run and > usually is because of the know android incompatibilities , or the phone / > tablet is crap , or just the occasional bug. > I also speak about user experience. Updating a large app takes more time than updating a small one. A shorter period of installation means more conversions. > For me I would define as huge an app that takes around 80% of disk space > thats around 6GB since my nexus is 8GB in size. I am sorry bur I cant > justify calling something huge based on my simple skill on reasoning > something that takes 0.25 % of my storage . Its not even a 1%. > > As a developer if Pharo was 1GB large but could make android development a > piece of cake I would not hesitate to install it, assuming my phone would > be able to run it smoothly . I am serious. > The last assumption you make is the key here. Not all phones are Galaxy S5 or iPhone 5, and it will get worse as the upcoming wave of "Internet of things" devices will require software to run of it. But with a similar reasoning one could argue that it doesn't make sense to optimize communication protocols because links are getting faster everyday. Somehow it holds true, but if you start big, it's really hard to trim it down. I also dont care how one counts the size of an app, for me anything that is > associated with the app is part of the app, that includes all the data. > So deploying an app to manage 1000 pictures is the same as deploying THE SAME APP to manage Instagram? Sorry, but I don't get this. Usually your app server and your app data don't even share the same host computer, considering it is only one and it is not sharded/clustered. I ran Smalltalk applications with <20 MB of executable file / assets, and databases going from 10MB to lots of GB. And it was the same application. When I updated it I just had to update the exec files (the image mostly), the database was unchanged. So it was a 10MB update as much. > > Ironically we sit here and talk about the size of pharo would take on > android but Pharo cannot even run on android. I dont know I just feel Pharo > has much bigger things to worry about out than 30+ MBs. > It runs on Android. Even though it doesn't have a native Android look, nor it complies to most of the Android Development Guidelines. But I agree that 30 MBs is not something to worry about. I simply raised my longwinded opinion that I don't consider 30MB to be small on a mobile device.

Nov. 25, 2014