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 iStoa - http://istoa.drgeo.eu
well⦠fthis days stay with the micro-concept of image sizes of ancient times does not looks like a reasonable approach. Lots of conditions changed and nowadays RAM is very cheap (and even tablets has enough of them) but then, there are some points to observe that can help you: - Pharo4 will not have 32m, this is still a alpha version. It will be a lot smaller (I suppose a bit bigger than Pharo3, but not much more) - We are also producing the Pharo-minimal images as part of the process, which are stripped versions with (for now) 6m size. Of course this one does not have a lot of things that has to be reintroduced if desired (like morphic), but I think is easy to have an image smaller than 10m with all you need when going production in a tablet. now⦠about small is beauty. We incorporated a lot of new cool stuff (many that no one will ever notice, or use), and we need to improve in the cleaning side⦠there are tons of things to clean or remove there. cheers, Esteban
On 24 Nov 2014, at 21:29, Hilaire <hilaire@drgeo.eu> 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 iStoa - http://istoa.drgeo.eu
Let's see then.. Le 24/11/2014 21:39, Esteban Lorenzano a écrit :
well⦠fthis days stay with the micro-concept of image sizes of ancient times does not looks like a reasonable approach. Lots of conditions changed and nowadays RAM is very cheap (and even tablets has enough of them) but then, there are some points to observe that can help you:
- Pharo4 will not have 32m, this is still a alpha version. It will be a lot smaller (I suppose a bit bigger than Pharo3, but not much more) - We are also producing the Pharo-minimal images as part of the process, which are stripped versions with (for now) 6m size. Of course this one does not have a lot of things that has to be reintroduced if desired (like morphic), but I think is easy to have an image smaller than 10m with all you need when going production in a tablet.
now⦠about small is beauty. We incorporated a lot of new cool stuff (many that no one will ever notice, or use), and we need to improve in the cleaning side⦠there are tons of things to clean or remove there.
-- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Let's see then..
Hilaire Guille is spending hour one having a bootstrapped kernel based on pavel images. with about 400 Mb and removing dependencies. Everybody can help. We aask a student to develop a nice tools to spot wrong dependencies: lookat PharoExtras ToolsDependencyAnalyser And send fixes. Once the bootstrap arrives to a reasonable state we will work on creating configuration of for image level. I have been splitting (and still continuing) polymorph and removing some complexity. Now this is a *****DIFFICUL******* and not sexy (where is the fame?) to reduce and modularise a system. So if you are concerned about the size, give a try to help.
Le 24/11/2014 21:39, Esteban Lorenzano a écrit :
well⦠fthis days stay with the micro-concept of image sizes of ancient times does not looks like a reasonable approach. Lots of conditions changed and nowadays RAM is very cheap (and even tablets has enough of them) but then, there are some points to observe that can help you:
- Pharo4 will not have 32m, this is still a alpha version. It will be a lot smaller (I suppose a bit bigger than Pharo3, but not much more) - We are also producing the Pharo-minimal images as part of the process, which are stripped versions with (for now) 6m size. Of course this one does not have a lot of things that has to be reintroduced if desired (like morphic), but I think is easy to have an image smaller than 10m with all you need when going production in a tablet.
now⦠about small is beauty. We incorporated a lot of new cool stuff (many that no one will ever notice, or use), and we need to improve in the cleaning side⦠there are tons of things to clean or remove there.
400 megs ? O_o Le 25 nov. 2014 08:08, "stepharo" <stepharo@free.fr> a écrit :
Let's see then..
Hilaire
Guille is spending hour one having a bootstrapped kernel based on pavel images. with about 400 Mb and removing dependencies. Everybody can help. We aask a student to develop a nice tools to spot wrong dependencies: lookat PharoExtras ToolsDependencyAnalyser And send fixes. Once the bootstrap arrives to a reasonable state we will work on creating configuration of for image level. I have been splitting (and still continuing) polymorph and removing some complexity. Now this is a *****DIFFICUL******* and not sexy (where is the fame?) to reduce and modularise a system. So if you are concerned about the size, give a try to help.
Le 24/11/2014 21:39, Esteban Lorenzano a écrit :
well⦠fthis days stay with the micro-concept of image sizes of ancient times does not looks like a reasonable approach. Lots of conditions changed and nowadays RAM is very cheap (and even tablets has enough of them) but then, there are some points to observe that can help you:
- Pharo4 will not have 32m, this is still a alpha version. It will be a lot smaller (I suppose a bit bigger than Pharo3, but not much more) - We are also producing the Pharo-minimal images as part of the process, which are stripped versions with (for now) 6m size. Of course this one does not have a lot of things that has to be reintroduced if desired (like morphic), but I think is easy to have an image smaller than 10m with all you need when going production in a tablet.
now⦠about small is beauty. We incorporated a lot of new cool stuff (many that no one will ever notice, or use), and we need to improve in the cleaning side⦠there are tons of things to clean or remove there.
Le 25/11/14 08:28, phil@highoctane.be a écrit :
400 megs ? O_o
Sorry classes. He has the seaside counter with 500 k
Le 25 nov. 2014 08:08, "stepharo" <stepharo@free.fr <mailto:stepharo@free.fr>> a écrit :
Let's see then..
Hilaire
Guille is spending hour one having a bootstrapped kernel based on pavel images. with about 400 Mb and removing dependencies. Everybody can help. We aask a student to develop a nice tools to spot wrong dependencies: lookat PharoExtras ToolsDependencyAnalyser And send fixes. Once the bootstrap arrives to a reasonable state we will work on creating configuration of for image level. I have been splitting (and still continuing) polymorph and removing some complexity. Now this is a *****DIFFICUL******* and not sexy (where is the fame?) to reduce and modularise a system. So if you are concerned about the size, give a try to help.
Le 24/11/2014 21:39, Esteban Lorenzano a écrit :
well⦠fthis days stay with the micro-concept of image sizes of ancient times does not looks like a reasonable approach. Lots of conditions changed and nowadays RAM is very cheap (and even tablets has enough of them) but then, there are some points to observe that can help you:
- Pharo4 will not have 32m, this is still a alpha version. It will be a lot smaller (I suppose a bit bigger than Pharo3, but not much more) - We are also producing the Pharo-minimal images as part of the process, which are stripped versions with (for now) 6m size. Of course this one does not have a lot of things that has to be reintroduced if desired (like morphic), but I think is easy to have an image smaller than 10m with all you need when going production in a tablet.
now⦠about small is beauty. We incorporated a lot of new cool stuff (many that no one will ever notice, or use), and we need to improve in the cleaning side⦠there are tons of things to clean or remove there.
Isn't Oz giving us images without UI tools? Where do we stand on the remote browser thing? ( A la Spoon browser ). Thierry, Do you think we could have AltBrowser do that remote thing? Phil
Le 25/11/14 08:30, phil@highoctane.be a écrit :
Isn't Oz giving us images without UI tools?
It is a prototype and as you know a prototype require engineering manpower.
Where do we stand on the remote browser thing? ( A la Spoon browser ).
Thierry,
Do you think we could have AltBrowser do that remote thing?
Phil
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.
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@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.
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@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@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.
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@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@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@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.
2014-11-25 17:24 GMT+01:00 Esteban Lorenzano <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 ? but yet, memory management will be a lot more efficient so⦠:P
Esteban
On 25 Nov 2014, at 17:22, Esteban Lorenzano <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@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@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.
On 25 Nov 2014, at 17:43, Clément Bera <bera.clement@gmail.com> wrote:
2014-11-25 17:24 GMT+01:00 Esteban Lorenzano <estebanlm@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@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@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@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.
On Tue, Nov 25, 2014 at 8:43 AM, Clément Bera <bera.clement@gmail.com> wrote:
2014-11-25 17:24 GMT+01:00 Esteban Lorenzano <estebanlm@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@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@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@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
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
On 25 Nov 2014, at 17:44, Hilaire <hilaire@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
El Tue Nov 25 2014 at 1:22:50 PM, Esteban Lorenzano <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. 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!
On 25 Nov 2014, at 18:51, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
El Tue Nov 25 2014 at 1:22:50 PM, Esteban Lorenzano <estebanlm@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!
2014-11-25 18:51 GMT+01:00 Esteban A. Maringolo <emaringolo@gmail.com>:
El Tue Nov 25 2014 at 1:22:50 PM, Esteban Lorenzano <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.
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!
El Tue Nov 25 2014 at 3:54:13 PM, Pavel Krivanek <pavel.krivanek@gmail.com> escribió:
2014-11-25 18:51 GMT+01:00 Esteban A. Maringolo <emaringolo@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,
2014-11-25 20:11 GMT+01:00 Esteban A. Maringolo <emaringolo@gmail.com>:
El Tue Nov 25 2014 at 3:54:13 PM, Pavel Krivanek <pavel.krivanek@gmail.com> escribió:
2014-11-25 18:51 GMT+01:00 Esteban A. Maringolo <emaringolo@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,
El Tue Nov 25 2014 at 4:19:46 PM, Pavel Krivanek <pavel.krivanek@gmail.com> escribió:
2014-11-25 20:11 GMT+01:00 Esteban A. Maringolo <emaringolo@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 ;)
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.
Pharo runs on Android. Phil On Tue, Nov 25, 2014 at 6:06 PM, kilon alios <kilon.alios@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.
El Tue Nov 25 2014 at 2:06:36 PM, kilon alios <kilon.alios@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.
*"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.
2014-11-25 8:30 GMT+01:00 phil@highoctane.be <phil@highoctane.be>:
Isn't Oz giving us images without UI tools?
Where do we stand on the remote browser thing? ( A la Spoon browser ).
Thierry,
Do you think we could have AltBrowser do that remote thing
I've never thought of that. Well, I did a bit, but not enough to be able to give you a man-month (or a man-week) target. It would be cool to factor out the IDE to system protocol so that you could remote it for any browser. Steph, what would be the situation for you with an internship to do something like that? As an aside, are the minimal images available from the zeroconf scripts? I could play a bit around with that (something like the GitFileTree-MergeDriver does not require a GUI, and it would be cool to be able to write an install makefile with a minimal image). Thierry
Phil
Le 25/11/2014 08:08, stepharo a écrit :
Guille is spending hour one having a bootstrapped kernel based on pavel images. with about 400 Mb and removing dependencies. Everybody can help. We aask a student to develop a nice tools to spot wrong dependencies: lookat PharoExtras ToolsDependencyAnalyser And send fixes. Once the bootstrap arrives to a reasonable state we will work on creating configuration of for image level. I have been splitting (and still continuing) polymorph and removing some complexity. Now this is a *****DIFFICUL******* and not sexy (where is the fame?) to reduce and modularise a system.
Yes, I know it is difficult.
So if you are concerned about the size, give a try to help.
I would love to, but given my little time slot I can dedicate to Smalltalk, by doing so I will have to stop Dr.Geo et al. I hope time will give oportunity to help in on way or another. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
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@drgeo.eu> 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 iStoa - http://istoa.drgeo.eu
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. 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@gmail.com> 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@drgeo.eu> 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 iStoa - http://istoa.drgeo.eu
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.
I rooted my phone to be able to remove vendor apps in order to get some more space.
who said 30mbs are large for mobile phones ? Twitter is reporting 57mbs memory consumption on my phone. Its a Google Nexus 4 , its 1 year and a half old now. It has 2 gb of Ram, 1 GB is free. Storage wise, both Android and iOS have loads of Games that require at least a 1 GB download. Loads of people usually complain and rage on the comment section why the game does not run on their smartphone that does not stop the game from being highly rated and having hundrends of millions of downloads. I use the famous clean master it reports cleaning 1 GB data at least once per month (is reporting that has cleaned 20 GBs so far) and I dont even use my smartphone that frequently. I use it like 1 hour per day. That data is stuff downloaded by twitter and chrome for caching etc . Most users have no clue how much they download and what exactly.
I think this discussion answers the wrong question. The question should not be if something is large or small compared with the size of the disc. The question should be: is it larger than it has to be for what it does? It is precisely this question that will keep Pharo slim. Nowadays, the greatest problem in software engineering is the limit of the human brain, not of the machine. Doru On Tue, Nov 25, 2014 at 12:18 AM, kilon alios <kilon.alios@gmail.com> 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.
I rooted my phone to be able to remove vendor apps in order to get some more space.
who said 30mbs are large for mobile phones ?
Twitter is reporting 57mbs memory consumption on my phone. Its a Google Nexus 4 , its 1 year and a half old now. It has 2 gb of Ram, 1 GB is free.
Storage wise, both Android and iOS have loads of Games that require at least a 1 GB download. Loads of people usually complain and rage on the comment section why the game does not run on their smartphone that does not stop the game from being highly rated and having hundrends of millions of downloads.
I use the famous clean master it reports cleaning 1 GB data at least once per month (is reporting that has cleaned 20 GBs so far) and I dont even use my smartphone that frequently. I use it like 1 hour per day. That data is stuff downloaded by twitter and chrome for caching etc .
Most users have no clue how much they download and what exactly.
-- www.tudorgirba.com "Every thing has its own flow"
my opinion is this : if something needs to go because it does not add to the usefulness of the package , then kill it without hesitation and kill it with fire. But if you kill it just for the sake of keeping the distribution small then yes I have a problem with that especially for platforms that size is not an issue for the vast majority of users. Other than that I leave it to the good judgement of pharoers , obviously sometime is not a simple decision and will depend on the particulars of the situation.
Well, I am working with a couple startups in the mobile space. You see that people uninstall larger apps. It is not an opinion it is a metric. Also I am speaking about RAM too. Nexus devices are special as they usually manage storage well and have more than other devices. I have a nexus 7 around. Some apps are not able to go to the external SD card and with devices with 4 or 8 GB internal storage it becomes an issue once you factor in pictures, movies etc. Cleanmaster not withstanding. I use it too. But not everyone knows about it. Lower end smartphones aren't as good. I want Pharo to be relevant on my mobe as a dev platform through HTML5. Maybe not today but ultimately. Part of that is reducing the footprint. Java runs on the mobe in a smaller footprint. So can Pharo. A modular Pharo is the key and it is not easy to achieve it seems. PharoME - "Micro Edition" is a powerful value proposition for a lot of use cases. Coupled with things like what Goran does with Nim could open interesting avenues. I agree that machines are getting more powerful and this will not matter in the long run. But for getting in the game now it does. That's the whole point I think. Phil Le 25 nov. 2014 00:48, "kilon alios" <kilon.alios@gmail.com> a écrit :
my opinion is this : if something needs to go because it does not add to the usefulness of the package , then kill it without hesitation and kill it with fire.
But if you kill it just for the sake of keeping the distribution small then yes I have a problem with that especially for platforms that size is not an issue for the vast majority of users.
Other than that I leave it to the good judgement of pharoers , obviously sometime is not a simple decision and will depend on the particulars of the situation.
Phil If you put money on the table this can change the game. Now our resources are CONSTRAINED> Stef
Well, I am working with a couple startups in the mobile space.
You see that people uninstall larger apps.
It is not an opinion it is a metric. Also I am speaking about RAM too.
Nexus devices are special as they usually manage storage well and have more than other devices. I have a nexus 7 around.
Some apps are not able to go to the external SD card and with devices with 4 or 8 GB internal storage it becomes an issue once you factor in pictures, movies etc. Cleanmaster not withstanding. I use it too. But not everyone knows about it.
Lower end smartphones aren't as good.
I want Pharo to be relevant on my mobe as a dev platform through HTML5. Maybe not today but ultimately.
Part of that is reducing the footprint. Java runs on the mobe in a smaller footprint. So can Pharo. A modular Pharo is the key and it is not easy to achieve it seems.
PharoME - "Micro Edition" is a powerful value proposition for a lot of use cases.
Coupled with things like what Goran does with Nim could open interesting avenues.
I agree that machines are getting more powerful and this will not matter in the long run. But for getting in the game now it does. That's the whole point I think.
Phil
Le 25 nov. 2014 00:48, "kilon alios" <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> a écrit :
my opinion is this : if something needs to go because it does not add to the usefulness of the package , then kill it without hesitation and kill it with fire.
But if you kill it just for the sake of keeping the distribution small then yes I have a problem with that especially for platforms that size is not an issue for the vast majority of users.
Other than that I leave it to the good judgement of pharoers , obviously sometime is not a simple decision and will depend on the particulars of the situation.
I am working hard on that one :-) And deploying production Pharo stuff on quite a couple of systems. I hope to be able to demo that in January. Phil Le 25 nov. 2014 08:42, "stepharo" <stepharo@free.fr> a écrit :
Phil
If you put money on the table this can change the game. Now our resources are CONSTRAINED>
Stef
Well, I am working with a couple startups in the mobile space.
You see that people uninstall larger apps.
It is not an opinion it is a metric. Also I am speaking about RAM too.
Nexus devices are special as they usually manage storage well and have more than other devices. I have a nexus 7 around.
Some apps are not able to go to the external SD card and with devices with 4 or 8 GB internal storage it becomes an issue once you factor in pictures, movies etc. Cleanmaster not withstanding. I use it too. But not everyone knows about it.
Lower end smartphones aren't as good.
I want Pharo to be relevant on my mobe as a dev platform through HTML5. Maybe not today but ultimately.
Part of that is reducing the footprint. Java runs on the mobe in a smaller footprint. So can Pharo. A modular Pharo is the key and it is not easy to achieve it seems.
PharoME - "Micro Edition" is a powerful value proposition for a lot of use cases.
Coupled with things like what Goran does with Nim could open interesting avenues.
I agree that machines are getting more powerful and this will not matter in the long run. But for getting in the game now it does. That's the whole point I think.
Phil Le 25 nov. 2014 00:48, "kilon alios" <kilon.alios@gmail.com> a écrit :
my opinion is this : if something needs to go because it does not add to the usefulness of the package , then kill it without hesitation and kill it with fire.
But if you kill it just for the sake of keeping the distribution small then yes I have a problem with that especially for platforms that size is not an issue for the vast majority of users.
Other than that I leave it to the good judgement of pharoers , obviously sometime is not a simple decision and will depend on the particulars of the situation.
On 25 Nov 2014, at 08:27, phil@highoctane.be wrote:
Well, I am working with a couple startups in the mobile space.
You see that people uninstall larger apps.
It is not an opinion it is a metric. Also I am speaking about RAM too.
Nexus devices are special as they usually manage storage well and have more than other devices. I have a nexus 7 around.
Some apps are not able to go to the external SD card and with devices with 4 or 8 GB internal storage it becomes an issue once you factor in pictures, movies etc. Cleanmaster not withstanding. I use it too. But not everyone knows about it.
Lower end smartphones aren't as good.
I want Pharo to be relevant on my mobe as a dev platform through HTML5. Maybe not today but ultimately.
Part of that is reducing the footprint. Java runs on the mobe in a smaller footprint. So can Pharo. A modular Pharo is the key and it is not easy to achieve it seems.
in iOS, pharo does not load all image into RAM for running, it just loads a paginated version, so you do not have all image in memory at a time. this was a cool solution at the moment. the problem why pharo is not more used in mobile is because it was slower than a native app, and there were some problems due the absence of FFI on ARM. With Nick Ager we even did an extension to transform the main window of an iPhone into a WebView, handled (at the moment) by a seaside app using jquery mobile. results were interesting (although I disagree with html5 supporters and I think it is still ages far from truly native). Esteban
PharoME - "Micro Edition" is a powerful value proposition for a lot of use cases.
Coupled with things like what Goran does with Nim could open interesting avenues.
I agree that machines are getting more powerful and this will not matter in the long run. But for getting in the game now it does. That's the whole point I think.
Phil Le 25 nov. 2014 00:48, "kilon alios" <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> a écrit : my opinion is this : if something needs to go because it does not add to the usefulness of the package , then kill it without hesitation and kill it with fire.
But if you kill it just for the sake of keeping the distribution small then yes I have a problem with that especially for platforms that size is not an issue for the vast majority of users.
Other than that I leave it to the good judgement of pharoers , obviously sometime is not a simple decision and will depend on the particulars of the situation.
Le 25 nov. 2014 08:59, "Esteban Lorenzano" <estebanlm@gmail.com> a écrit :
On 25 Nov 2014, at 08:27, phil@highoctane.be wrote:
Well, I am working with a couple startups in the mobile space.
You see that people uninstall larger apps.
It is not an opinion it is a metric. Also I am speaking about RAM too.
Nexus devices are special as they usually manage storage well and have
more than other devices. I have a nexus 7 around.
Some apps are not able to go to the external SD card and with devices
with 4 or 8 GB internal storage it becomes an issue once you factor in pictures, movies etc. Cleanmaster not withstanding. I use it too. But not everyone knows about it.
Lower end smartphones aren't as good.
I want Pharo to be relevant on my mobe as a dev platform through HTML5.
Maybe not today but ultimately.
Part of that is reducing the footprint. Java runs on the mobe in a
smaller footprint. So can Pharo.
A modular Pharo is the key and it is not easy to achieve it seems.
in iOS, pharo does not load all image into RAM for running, it just loads a paginated version, so you do not have all image in memory at a time. this was a cool solution at the moment. the problem why pharo is not more used in mobile is because it was slower than a native app, and there were some problems due the absence of FFI on ARM. With Nick Ager we even did an extension to transform the main window of an iPhone into a WebView, handled (at the moment) by a seaside app using jquery mobile. results were interesting (although I disagree with html5 supporters and I think it is still ages far from truly native).
I saw some of that in the iOS VM. It is nice. HTML5 is not native speed indeed. But I am on the HTML5 bandwagon, so, that's what I do use. Hence my interest in Amber for example. Phil
Esteban
PharoME - "Micro Edition" is a powerful value proposition for a lot of
use cases.
Coupled with things like what Goran does with Nim could open interesting
avenues.
I agree that machines are getting more powerful and this will not matter
in the long run. But for getting in the game now it does. That's the whole point I think.
Phil
Le 25 nov. 2014 00:48, "kilon alios" <kilon.alios@gmail.com> a écrit :
my opinion is this : if something needs to go because it does not add
to the usefulness of the package , then kill it without hesitation and kill it with fire.
But if you kill it just for the sake of keeping the distribution small
then yes I have a problem with that especially for platforms that size is not an issue for the vast majority of users.
Other than that I leave it to the good judgement of pharoers ,
obviously sometime is not a simple decision and will depend on the particulars of the situation.
On 24 Nov 2014, at 23:48, phil@highoctane.be 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 :) 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@gmail.com <mailto:kilon.alios@gmail.com>> 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@drgeo.eu <mailto:hilaire@drgeo.eu>> 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/>
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.
On 24 Nov 2014, at 21:29, Hilaire <hilaire@drgeo.eu> 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?
Keeping mind that most of this is -> some artefact of the build process that the stack is saved open the image and save it down to 31.2MB -> the ScriptLoader package (with >123 KLOC now) down to 25.5MB -> Monticello meta data down to 22.5MB And this is even not what we will have for the release, as there is e.g. 500KB of loreIpsum strings in the image⦠that should be removed. (they are for testing the editor) Now yes, there is more code in the image than for Pharo 1.4: - Metacello. This is *HUGE* - Versionner - Kommitter - OSWindow - Rubrick editor + tests - Glamour + GT with tests - â¦... 22.5 MB is not a lot for all that. Now this image has all tests and all tools. #cleanUpForProduction removes Versionner and unloads all tests. ===> down to 17,8 MB Not too bad! Questions to ask: - is 22MB really big? Many of the apps on my phone are *much* larger than that. Even very simple ones. People these days complain when phones come with âonly 1GB of RAMâ. - Time is on our side. Moore Law for storage says we can double every year and stay constant. And I am willing to invest that for more expressive power, at least some years. - If we would *really* care for space: Wouldnât we start to e.g. start to do thing like string sharing and compression of some unused data? As always: nothing happens by itselfâ¦. Marcus
Of course there are issues on the tracker for all of them...
-> some artefact of the build process that the stack is saved open the image and save it down to 31.2MB
https://pharo.fogbugz.com/f/cases/14367 <https://pharo.fogbugz.com/f/cases/14367>
-> the ScriptLoader package (with >123 KLOC now) down to 25.5MB
https://pharo.fogbugz.com/f/cases/14359 <https://pharo.fogbugz.com/f/cases/14359>
-> Monticello meta data down to 22.5MB
https://pharo.fogbugz.com/f/cases/2711 <https://pharo.fogbugz.com/f/cases/2711>
And this is even not what we will have for the release, as there is e.g. 500KB of loreIpsum strings in the image⦠that should be removed. (they are for testing the editor)
https://pharo.fogbugz.com/f/cases/14315 <https://pharo.fogbugz.com/f/cases/14315> Marcus
if you use declarative style and make Jenkings build images for production, you can include in your deops pipeline to remove Monticello too What good that would make to size*? sebastian o/ * BTW also mobile would 99% probably not be using Monticello
On 25/11/2014, at 05:33, Marcus Denker <marcus.denker@inria.fr> wrote:
Now this image has all tests and all tools. #cleanUpForProduction removes Versionner and unloads all tests.
===> down to 17,8 MB
participants (14)
-
Clément Bera -
Eliot Miranda -
Esteban A. Maringolo -
Esteban Lorenzano -
Hilaire -
kilon alios -
Marcus Denker -
Pavel Krivanek -
phil＠highoctane.be -
Richard Sargent -
Sebastian Sastre -
stepharo -
Thierry Goubier -
Tudor Girba