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

Re: [Pharo-dev] What is the limit

by Esteban Lorenzano

> On 25 Nov 2014, at 18:51, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > > El Tue Nov 25 2014 at 1:22:50 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@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. puffâ¦ skype, g drive (75m in my case), g+, youtube, one app from here which is called voyages-scnf, a pedometer, g maps, foursquare, a chess, one called transpole (also from transport, here) and even vorterix radioâ¦ all 20m+ but also you are assuming people accept the size of the main stream apps because they are main stream, when the reality is what Kilon says: no body cares, no body ever look at it. in fact, the only thing I look at is how much my battery drains if Iâm using the appâ¦ that is far more important than app size. > > 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. that doesnât mean your app will take 2-3m when usedâ¦ it will be more. Also pharo packed is a lot less than regular size :) > > 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. we will be there. soon. > > 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). you will not do that in a mobile app, I hopeâ¦ but also, you do not need themâ¦ in the worst case it will be created when you do the file in. (btwâ¦ Pharo3 does not have decompiler, something that you need. Pharo4 has it) > > 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. â¦ and I think you are wrong :) > > 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! yeah, we are working for you :) Esteban > > Regards!

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Esteban A. Maringolo

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. > 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

Float class comment

by Eliot Miranda

Hi All, who wrote the Float class comment? Two things, - first the comment mentions "I" and thanks several people, but there is no comment stamp to reveal the author. It would be lovely if the author could "sign" this comment - second, there seems to be a minor error (but I'm no expert), the comment states "It may help you to know that the basic format is... sign 1 bit exponent 11 bits with bias of 1023 (16r3FF) to produce an exponent in the range -1023 .. +1024 - 16r000: significand = 0: Float zero significand ~= 0: Denormalized number (exp = -1024, no hidden '1' bit) - 16r7FF: significand = 0: Infinity significand ~= 0: Not A Number (NaN) representation mantissa 53 bits, but only 52 are stored (20 in the first word, 32 in the second). This is because a normalized mantissa, by definition, has a 1 to the right of its floating point, and IEEE-754 omits this redundant bit to gain an extra bit of precision instead. People talk about the mantissa without its leading one as the FRACTION, and with its leading 1 as the SIGNFICAND." But if the significand has a leading zero then surely the section in the middle should read sign 1 bit exponent 11 bits with bias of 1023 (16r3FF) to produce an exponent in the range -1023 .. +1024 - 16r000: mantissa = 0: Float zero mantissa ~= 0: Denormalized number (exp = -1024, no hidden '1' bit) - 16r7FF: mantissa = 0: Infinity mantissa ~= 0: Not A Number (NaN) representation Right? -- best, Eliot

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by phil＠highoctane.be

Pharo runs on Android. Phil On Tue, Nov 25, 2014 at 6:06 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > >> 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. I don't mind being > wrong, thats life. > > >> 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). > > 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. > > 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. > > 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. > > I am coding for fun 25 years, I was around when kbs meants what gbs mean > nowdays and its a blessing that nowdays I dont even care how large an > android app really is. If it was not for this thread I would not even > bothered to check the free space in my phone. In old days running out of > space was one of the most annoying things. Having to change diskettes to > load a lousy games and waiting and waiting and waiting. Here we are now and > we are debating 30MBs and 20MBs ..... I feel so lucky. > > Which makes me wonder not how many people out there really care about app > sizes but really how many of them even bother to check their free space. > > "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)." > > hmm thats very interesting Esteban I assumed that Pharo loaded everything > because its a live enviroment , really impressed at the optimizations you > guys do. > > 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. > > But hey we are a community I dont expect every single one of us to have > the same demands and needs. >

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Esteban Lorenzano

> On 25 Nov 2014, at 17:44, Hilaire <hilaire(a)drgeo.eu> wrote: > > Le 25/11/2014 17:22, Esteban Lorenzano a Ã©crit : >> For DrGeo2 I needed to expand that memory to 64m, but it was still in >> the reasonable numbers. >> > > How come so much? Image of latest built is below 10MB. Iâm talking by memory here, but I remember with âmax memoryâ set to 32m I was having low memory warnings and I doubled it (no heuristics, it just looked âfineâ to jump from 32 to 64 :P) and solved the problem. The problem could be happening in development images (before compaction)â¦ but as I said, this was two years ago so I might be wrong. :P One thing to take into account is that memory management for pharo is/was not optimal, and VM could be asking for more memory than needed in certain circumstances. Other thing is that memory needed != memory of image. Of course, at the beginning it is, but you start creating/destroying objects right after, so your needs change. And well, there are tons other possible reasons, but in the case of DrGeo, I *think* (I donât remember well) it was when rendering images (the predefined images: the screenshots when browsing examples, etc.). Esteban > > Hilaire > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > >

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Esteban Lorenzano

> On 25 Nov 2014, at 17:43, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > 2014-11-25 17:24 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > and btwâ¦ spur format will consume more memory. > > Why ? > > If I remember correctly the first Squeak image generated was 3% smaller. How bigger is the spur Pharo image compared to the regular image ? Iâm having 15% bigger images. I always assumed it was going to be like that because of the differences on header sizesâ¦ but I suppose the amount of ancient compact-non compact classes has something to do. Esteban > > 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 <mailto:estebanlm@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 <mailto:emaringolo@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 <mailto:kilon.alios@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. >>> >> > >

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by kilon alios

>> 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. I don't mind being wrong, thats life. >> 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). 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. 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. 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. I am coding for fun 25 years, I was around when kbs meants what gbs mean nowdays and its a blessing that nowdays I dont even care how large an android app really is. If it was not for this thread I would not even bothered to check the free space in my phone. In old days running out of space was one of the most annoying things. Having to change diskettes to load a lousy games and waiting and waiting and waiting. Here we are now and we are debating 30MBs and 20MBs ..... I feel so lucky. Which makes me wonder not how many people out there really care about app sizes but really how many of them even bother to check their free space. "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)." hmm thats very interesting Esteban I assumed that Pharo loaded everything because its a live enviroment , really impressed at the optimizations you guys do. 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. But hey we are a community I dont expect every single one of us to have the same demands and needs.

Nov. 25, 2014

Re: [Pharo-dev] Dependencies Analyzer

by Christophe Demarey

If you do not care of the UI, it should work on both Pharo 30 and 40. You can use: (PDPackageAnalyzerTreeModel onPackagesMatch: 'AST*') relationGraph explore ... but it is hard to see directly the information you need. If you have graphviz installed, you could use PDGraphVizGenerator newWith: (PDPackageAnalyzerTreeModel onPackagesMatch: 'AST*') relationGraph named: 'ast' Le 25 nov. 2014 Ã 17:51, phil(a)highoctane.be a Ã©crit : > Can understand that. > > Will try with previous version. > > Now, 3.0 is what I use for production code, not 4.0. > Is the version with 3.0 at the same location? Elsewhere? > > > Phil > > > > On Tue, Nov 25, 2014 at 5:07 PM, stepharo <stepharo(a)free.fr> wrote: > it is to work on Pharo40. > I did not want to maintain two versions. > I loaded it like this: > > Gofer it > smalltalkhubUser: 'BaptisteQuide' project: 'PackageDependenciesAnalysis'; > configuration; > loadStable > > The article on > > http://www.baptistequide.fr/packagedependencies.php > > says that it loads on 3.0 but well, it doesn't say it works there. > > You're right. the latest version does not work on Pharo 30. > It should not be a big deal to have it working. Most specific parts are related to Nautilus and spec changes. > For example #updatePackageGroupAndClassList is bot implemented in PackageTreeNautilusUI in Pharo 30. Probably it was removed. > Yes probably > Philippe if you take a version before it should load. > I moved the repo to PharoExtras with the version for Pharo40. > > > > I do not find a reference to #position: in the Package-Dependencies package, so it's difficult to guess the problem root. How to reproduce? > > > >

Nov. 25, 2014

Re: [Pharo-dev] changing MC repository url display

by Ben Coman

Esteban Lorenzano wrote: > Hi, > > So I have this problemâ¦ each time I open a MC browser I see something > like this: > > > And as you can seeâ¦ most important part of the repositories (the NAME) > is hidded because window is small. > Of course, I can enlarge the screen to see the names, but that made me > think the way the information is presented is not good (because the > place, sthub, ss, ss3 or whatever) is less important than the repository > name. > So I would like to change that to something like: > > Pharo/Pharo40 (smalltalkhub.com <http://smalltalkhub.com>) > Pharo/Pharo40Inbox (smalltalkhub.com <http://smalltalkhub.com>) > Moose/Glamour (smalltalkhub.com <http://smalltalkhub.com>) > ./mc (filetree) > VMMaker (source.squeak.org <http://source.squeak.org>) > â¦ etcâ¦ > > since this is a small change that has a huge visual impact, I would like > to discuss it before. > So, what do you think? > > Esteban > How would it look to just right justify the text? cheers -ben

Nov. 25, 2014

Re: [Pharo-dev] Dependencies Analyzer

by phil＠highoctane.be

Can understand that. Will try with previous version. Now, 3.0 is what I use for production code, not 4.0. Is the version with 3.0 at the same location? Elsewhere? Phil On Tue, Nov 25, 2014 at 5:07 PM, stepharo <stepharo(a)free.fr> wrote: > it is to work on Pharo40. > I did not want to maintain two versions. > >> I loaded it like this: >>> >>> Gofer it >>> smalltalkhubUser: 'BaptisteQuide' project: 'PackageDependenciesAnalysis'; >>> configuration; >>> loadStable >>> >>> The article on >>> >>> http://www.baptistequide.fr/packagedependencies.php >>> >>> says that it loads on 3.0 but well, it doesn't say it works there. >>> >> >> You're right. the latest version does not work on Pharo 30. >> It should not be a big deal to have it working. Most specific parts are >> related to Nautilus and spec changes. >> For example #updatePackageGroupAndClassList is bot implemented in >> PackageTreeNautilusUI in Pharo 30. Probably it was removed. >> > Yes probably > Philippe if you take a version before it should load. > I moved the repo to PharoExtras with the version for Pharo40. > > > >> I do not find a reference to #position: in the Package-Dependencies >> package, so it's difficult to guess the problem root. How to reproduce? >> >> > >

Nov. 25, 2014