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

Re: [Pharo-dev] Dependencies Analyzer

by phil＠highoctane.be

Load in 3.0, add a package, run dependencies. âPhil

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Hilaire

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. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by ClÃ©ment Bera

2014-11-25 17:24 GMT+01:00 Esteban Lorenzano <estebanlm(a)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 ? 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. >> >> > >

Nov. 25, 2014

Re: [Pharo-dev] What is the limit

by Esteban Lorenzano

and btwâ¦ spur format will consume more memory. 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 <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 Esteban Lorenzano

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 <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] Dependencies Analyzer

by stepharo

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] What is the limit

by Esteban A. Maringolo

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

Nov. 25, 2014

Re: [Pharo-dev] Mess in Theme hierarchy again

by Hilaire

Thanks Le 25/11/2014 15:30, Marcus Denker a Ã©crit : > >> On 25 Nov 2014, at 15:24, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> Le 25/11/2014 08:16, Marcus Denker a Ã©crit : >>> Nobody did anything (the only thing I did is to remove *a lot* of duplicated methods >>> im the hierarchy). >> >> Ok >> Switch to DarkTheme, then to WaterTheme. Text color scheme get wrong. >> > > I think this is because of #installFullTheme > > if you add this to UITheme (the superclass of all) it should work: > > installFullTheme > "Installs full theme: > this theme > default forts > desktop background > completion list colors" > > self beCurrent. > SHPreferences setStyleTable: SHTextStylerST80 blueStyleTable. > PolymorphSystemSettings desktopColor: Color lightGray lighter lighter. > NECPreferences backgroundColor: UITheme current windowColor. > Paragraph insertionPointColor: UITheme current caretColor. > > > -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Nov. 25, 2014

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

by Sebastian Sastre

Itâs a good optimization helps > On Nov 24, 2014, at 11:09 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > So I have this problemâ¦ each time I open a MC browser I see something like this: > > <Screen Shot 2014-11-24 at 14.04.44.png> > > 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 >

Nov. 25, 2014

Re: [Pharo-dev] Dependencies Analyzer

by Christophe Demarey

Le 25 nov. 2014 Ã 15:03, phil(a)highoctane.be a Ã©crit : > I installed it in my 3.0 but it crashes with a DNU on TreeNodeModel>>position: > > 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. 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