Minimizing an Application
I received this comment on Facebook: Smalltalk is a fantastic language and its development environment can't be beat... But the documentation for the many open source implementations is contradictory or confusing or missing. I can't speak for the commercial versions. Without an experienced mentor it is not possible to create a complex app. And even when you have done so, *I know no way to strip out the unused part of the image as well as the embedded source code*. ----- This issue of stripping out unused code seems to recur a lot. And truth be told, I've never seen a clear explanation of how to do this. Can someone provide clear direction? Is this documented anywhere? I'd like to use the information in future to assuage other people's concerns. Thanks. -- View this message in context: http://forum.world.st/Minimizing-an-Application-tp4963262.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
There has been a lot of great work on this front on the Pharo side from the "team" and PharoLambda has made use of it (although it's a tiny project). My footprint is ~22mb including vm & image. And leaving out sources. The ./scripts directory has the example of how to do it, along side the .gitlab-ci.yml file. Unlike the commercial distributions (and this may have changed recently), there is a minimal image you can have download, which has enough to bootstrap loading your project via metacello. There are no browser tools or morphic things in the starting image I have chosen. You can potentially get smaller - but it's a decent result. The only bit I added was to remove testcases (optional), and clear down metacello. It's probably worthy of a blog post - but honestly the running example is pretty straight forward. The commercial tools all have a decent "strip dead code" tool, that does a similar thing in reverse - which is equally a decent way of approaching the problem and can lead to even tinier results. Tim Sent from my iPhone
On 21 Aug 2017, at 21:25, horrido <horrido.hobbies@gmail.com> wrote:
I received this comment on Facebook:
Smalltalk is a fantastic language and its development environment can't be beat... But the documentation for the many open source implementations is contradictory or confusing or missing. I can't speak for the commercial versions. Without an experienced mentor it is not possible to create a complex app. And even when you have done so, *I know no way to strip out the unused part of the image as well as the embedded source code*. -----
This issue of stripping out unused code seems to recur a lot. And truth be told, I've never seen a clear explanation of how to do this. Can someone provide clear direction? Is this documented anywhere? I'd like to use the information in future to assuage other people's concerns.
Thanks.
-- View this message in context: http://forum.world.st/Minimizing-an-Application-tp4963262.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
VA Smalltalk doesn't strip an image; it builds a new image based on application dependencies. With VA's packaging functionality, you are more likely to get a packaging error that reports you are trying to use something that isn't reachable according to the defined dependencies. I admit that except for the first few years, most of my early Smalltalk experience involved ENVY and VA/VisualAge Smalltalk. Still, I prefer it's practice of building an image based on what you have told it to include. On Aug 21, 2017 15:22, "Tim Mackinnon" <tim@testit.works> wrote:
There has been a lot of great work on this front on the Pharo side from the "team" and PharoLambda has made use of it (although it's a tiny project).
My footprint is ~22mb including vm & image. And leaving out sources.
The ./scripts directory has the example of how to do it, along side the .gitlab-ci.yml file.
Unlike the commercial distributions (and this may have changed recently), there is a minimal image you can have download, which has enough to bootstrap loading your project via metacello. There are no browser tools or morphic things in the starting image I have chosen.
You can potentially get smaller - but it's a decent result. The only bit I added was to remove testcases (optional), and clear down metacello.
It's probably worthy of a blog post - but honestly the running example is pretty straight forward.
The commercial tools all have a decent "strip dead code" tool, that does a similar thing in reverse - which is equally a decent way of approaching the problem and can lead to even tinier results.
Tim
Sent from my iPhone
On 21 Aug 2017, at 21:25, horrido <horrido.hobbies@gmail.com> wrote:
I received this comment on Facebook:
Smalltalk is a fantastic language and its development environment can't be beat... But the documentation for the many open source implementations is contradictory or confusing or missing. I can't speak for the commercial versions. Without an experienced mentor it is not possible to create a complex app. And even when you have done so, *I know no way to strip out the unused part of the image as well as the embedded source code*. -----
This issue of stripping out unused code seems to recur a lot. And truth be told, I've never seen a clear explanation of how to do this. Can someone provide clear direction? Is this documented anywhere? I'd like to use the information in future to assuage other people's concerns.
Thanks.
-- View this message in context: http://forum.world.st/ Minimizing-an-Application-tp4963262.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
VAST provided such image deployment tool, where you could save the deployment instructions, as whether to include/exclude certain packages, classes, methods, etc. It was great, although it wasn't "easy" to work with. Dolphin Smalltalk has an Image Stripper, that does something like that, but by "removing" stuff from a copy of the image, it worked really well in practice and was super easy to use. Also, you can decide what "SessionManager" will be used in the deployed image, for a normal development image, it is DevelopmentSessionManger, but for a web app it could be a CommandLineSessionManager, or if you have a GUI desktop app, it could be your own session manager class. But what I liked the most was VisualSmalltalk's SLL (Smalltalk's Linked Library), where you could "link" your application with true modules, that were binary. You explicitly specify its contents (classes, methods, pools, etc.) when building (compiling), and could be replaced without having to redeploy everything. It could lead to some dependency hell if done wrong, but not more than any other module solution. And they were very compact. In my Pharo deployments, since they are web applications, I always deployed the whole image in the server, built from a vanilla one, but without stripping anything. Regards, Esteban A. Maringolo 2017-08-22 0:22 GMT-03:00 Richard Sargent <richard.sargent@gemtalksystems.com>:
VA Smalltalk doesn't strip an image; it builds a new image based on application dependencies. With VA's packaging functionality, you are more likely to get a packaging error that reports you are trying to use something that isn't reachable according to the defined dependencies.
I admit that except for the first few years, most of my early Smalltalk experience involved ENVY and VA/VisualAge Smalltalk. Still, I prefer it's practice of building an image based on what you have told it to include.
On Aug 21, 2017 15:22, "Tim Mackinnon" <tim@testit.works> wrote:
There has been a lot of great work on this front on the Pharo side from the "team" and PharoLambda has made use of it (although it's a tiny project).
My footprint is ~22mb including vm & image. And leaving out sources.
The ./scripts directory has the example of how to do it, along side the .gitlab-ci.yml file.
Unlike the commercial distributions (and this may have changed recently), there is a minimal image you can have download, which has enough to bootstrap loading your project via metacello. There are no browser tools or morphic things in the starting image I have chosen.
You can potentially get smaller - but it's a decent result. The only bit I added was to remove testcases (optional), and clear down metacello.
It's probably worthy of a blog post - but honestly the running example is pretty straight forward.
The commercial tools all have a decent "strip dead code" tool, that does a similar thing in reverse - which is equally a decent way of approaching the problem and can lead to even tinier results.
Tim
Sent from my iPhone
On 21 Aug 2017, at 21:25, horrido <horrido.hobbies@gmail.com> wrote:
I received this comment on Facebook:
Smalltalk is a fantastic language and its development environment can't be beat... But the documentation for the many open source implementations is contradictory or confusing or missing. I can't speak for the commercial versions. Without an experienced mentor it is not possible to create a complex app. And even when you have done so, *I know no way to strip out the unused part of the image as well as the embedded source code*. -----
This issue of stripping out unused code seems to recur a lot. And truth be told, I've never seen a clear explanation of how to do this. Can someone provide clear direction? Is this documented anywhere? I'd like to use the information in future to assuage other people's concerns.
Thanks.
-- View this message in context: http://forum.world.st/Minimizing-an-Application-tp4963262.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
We would like to have dll like deployment too. But I'm too dull to know how to do implement it. Stef On Tue, Aug 22, 2017 at 2:17 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
VAST provided such image deployment tool, where you could save the deployment instructions, as whether to include/exclude certain packages, classes, methods, etc. It was great, although it wasn't "easy" to work with.
Dolphin Smalltalk has an Image Stripper, that does something like that, but by "removing" stuff from a copy of the image, it worked really well in practice and was super easy to use. Also, you can decide what "SessionManager" will be used in the deployed image, for a normal development image, it is DevelopmentSessionManger, but for a web app it could be a CommandLineSessionManager, or if you have a GUI desktop app, it could be your own session manager class.
But what I liked the most was VisualSmalltalk's SLL (Smalltalk's Linked Library), where you could "link" your application with true modules, that were binary. You explicitly specify its contents (classes, methods, pools, etc.) when building (compiling), and could be replaced without having to redeploy everything. It could lead to some dependency hell if done wrong, but not more than any other module solution. And they were very compact.
In my Pharo deployments, since they are web applications, I always deployed the whole image in the server, built from a vanilla one, but without stripping anything.
Regards,
Esteban A. Maringolo
2017-08-22 0:22 GMT-03:00 Richard Sargent <richard.sargent@gemtalksystems.com>:
VA Smalltalk doesn't strip an image; it builds a new image based on application dependencies. With VA's packaging functionality, you are more likely to get a packaging error that reports you are trying to use something that isn't reachable according to the defined dependencies.
I admit that except for the first few years, most of my early Smalltalk experience involved ENVY and VA/VisualAge Smalltalk. Still, I prefer it's practice of building an image based on what you have told it to include.
On Aug 21, 2017 15:22, "Tim Mackinnon" <tim@testit.works> wrote:
There has been a lot of great work on this front on the Pharo side from the "team" and PharoLambda has made use of it (although it's a tiny project).
My footprint is ~22mb including vm & image. And leaving out sources.
The ./scripts directory has the example of how to do it, along side the .gitlab-ci.yml file.
Unlike the commercial distributions (and this may have changed recently), there is a minimal image you can have download, which has enough to bootstrap loading your project via metacello. There are no browser tools or morphic things in the starting image I have chosen.
You can potentially get smaller - but it's a decent result. The only bit I added was to remove testcases (optional), and clear down metacello.
It's probably worthy of a blog post - but honestly the running example is pretty straight forward.
The commercial tools all have a decent "strip dead code" tool, that does a similar thing in reverse - which is equally a decent way of approaching the problem and can lead to even tinier results.
Tim
Sent from my iPhone
On 21 Aug 2017, at 21:25, horrido <horrido.hobbies@gmail.com> wrote:
I received this comment on Facebook:
Smalltalk is a fantastic language and its development environment can't be beat... But the documentation for the many open source implementations is contradictory or confusing or missing. I can't speak for the commercial versions. Without an experienced mentor it is not possible to create a complex app. And even when you have done so, *I know no way to strip out the unused part of the image as well as the embedded source code*. -----
This issue of stripping out unused code seems to recur a lot. And truth be told, I've never seen a clear explanation of how to do this. Can someone provide clear direction? Is this documented anywhere? I'd like to use the information in future to assuage other people's concerns.
Thanks.
-- View this message in context: http://forum.world.st/Minimizing-an-Application-tp4963262.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Pharo desperately needs an image management tool. But in the end it will be up to the code hero that will decided the bite the bullet and do it. There are like a ton of things that can improve and a ton of potential ideas and projects, this is just one. It wont be easy though because code inside Pharo has the tendency to inter depend in some not so elegant ways. The fact that methods are so small and so many makes it hard to tell how uninstall a package will brake your image. I speak out of experience of actually trying this and corrupting the image (aka I was never to get the image to work again). Makes me wonder whether a solution would be to approach this in a "lazy kid cleans his room , by putting everything under his bed" kind of way. Create filters inside the System Browser that hide much of the mess and it make image seem far smaller and far simpler than it actual is. Of course its not an actual solution if you really want a reduced pharo image, but 10mbs which is the size pharo image can be reduced to is nothing for todays TBs hard drives and GBs flash drives and online storage. Unless you do an embedded app and 10 mbs are huge for your limited storage. On Wed, Aug 23, 2017 at 11:50 AM Stephane Ducasse <stepharo.self@gmail.com> wrote:
We would like to have dll like deployment too. But I'm too dull to know how to do implement it.
Stef
On Tue, Aug 22, 2017 at 2:17 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
VAST provided such image deployment tool, where you could save the deployment instructions, as whether to include/exclude certain packages, classes, methods, etc. It was great, although it wasn't "easy" to work with.
Dolphin Smalltalk has an Image Stripper, that does something like that, but by "removing" stuff from a copy of the image, it worked really well in practice and was super easy to use. Also, you can decide what "SessionManager" will be used in the deployed image, for a normal development image, it is DevelopmentSessionManger, but for a web app it could be a CommandLineSessionManager, or if you have a GUI desktop app, it could be your own session manager class.
But what I liked the most was VisualSmalltalk's SLL (Smalltalk's Linked Library), where you could "link" your application with true modules, that were binary. You explicitly specify its contents (classes, methods, pools, etc.) when building (compiling), and could be replaced without having to redeploy everything. It could lead to some dependency hell if done wrong, but not more than any other module solution. And they were very compact.
In my Pharo deployments, since they are web applications, I always deployed the whole image in the server, built from a vanilla one, but without stripping anything.
Regards,
Esteban A. Maringolo
2017-08-22 0:22 GMT-03:00 Richard Sargent < richard.sargent@gemtalksystems.com>:
VA Smalltalk doesn't strip an image; it builds a new image based on application dependencies. With VA's packaging functionality, you are more likely to get a packaging error that reports you are trying to use something that isn't reachable according to the defined dependencies.
I admit that except for the first few years, most of my early Smalltalk experience involved ENVY and VA/VisualAge Smalltalk. Still, I prefer it's practice of building an image based on what you have told it to include.
On Aug 21, 2017 15:22, "Tim Mackinnon" <tim@testit.works> wrote:
There has been a lot of great work on this front on the Pharo side from the "team" and PharoLambda has made use of it (although it's a tiny project).
My footprint is ~22mb including vm & image. And leaving out sources.
The ./scripts directory has the example of how to do it, along side the .gitlab-ci.yml file.
Unlike the commercial distributions (and this may have changed
recently),
there is a minimal image you can have download, which has enough to bootstrap loading your project via metacello. There are no browser tools or morphic things in the starting image I have chosen.
You can potentially get smaller - but it's a decent result. The only bit I added was to remove testcases (optional), and clear down metacello.
It's probably worthy of a blog post - but honestly the running example is pretty straight forward.
The commercial tools all have a decent "strip dead code" tool, that does a similar thing in reverse - which is equally a decent way of approaching the problem and can lead to even tinier results.
Tim
Sent from my iPhone
On 21 Aug 2017, at 21:25, horrido <horrido.hobbies@gmail.com> wrote:
I received this comment on Facebook:
Smalltalk is a fantastic language and its development environment can't be beat... But the documentation for the many open source implementations is contradictory or confusing or missing. I can't speak for the commercial versions. Without an experienced mentor it is not possible to create a complex app. And even when you have done so, *I know no way to strip out the unused part of the image as well as the embedded source code*. -----
This issue of stripping out unused code seems to recur a lot. And truth be told, I've never seen a clear explanation of how to do this. Can someone provide clear direction? Is this documented anywhere? I'd like to use the information in future to assuage other people's concerns.
Thanks.
-- View this message in context: http://forum.world.st/Minimizing-an-Application-tp4963262.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
...10mbs which is the size pharo image can be reduced to is nothing for todays TBs hard drives and GBs flash drives and online storage. Unless you do an embedded app and 10 mbs are huge for your limited storage.
Or you want to minimize initial startup time, including the time it takes to transmit the entire system over the net. -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com voice through 2017-09-12: + 1 510 833 5799 (SMS ok) +31 20 893 2796 (no SMS)
Indeed that can be a barrier but why you would want to transmit an entire image instead of portion of it using something like fuel files or other binary formats ? It would dramatically reduce the size of data you transmit. On Thu, Aug 24, 2017 at 8:10 PM Craig Latta <craig@blackpagedigital.com> wrote:
...10mbs which is the size pharo image can be reduced to is nothing for todays TBs hard drives and GBs flash drives and online storage. Unless you do an embedded app and 10 mbs are huge for your limited storage.
Or you want to minimize initial startup time, including the time it takes to transmit the entire system over the net.
-C
-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com voice through 2017-09-12: + 1 510 833 5799 <(510)%20833-5799> (SMS ok) +31 20 893 2796 <+31%2020%20893%202796> (no SMS)
I understand that to mean effectively that you are "opening" the image across the net - so eventually you need to whole image transmitted, but you don't have to wait for the whole thing before you start running it. cheers -ben On Fri, Aug 25, 2017 at 2:00 AM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Indeed that can be a barrier but why you would want to transmit an entire image instead of portion of it using something like fuel files or other binary formats ? It would dramatically reduce the size of data you transmit.
On Thu, Aug 24, 2017 at 8:10 PM Craig Latta <craig@blackpagedigital.com> wrote:
...10mbs which is the size pharo image can be reduced to is nothing for todays TBs hard drives and GBs flash drives and online storage. Unless you do an embedded app and 10 mbs are huge for your limited storage.
Or you want to minimize initial startup time, including the time it takes to transmit the entire system over the net.
-C
-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com voice through 2017-09-12: + 1 510 833 5799 <(510)%20833-5799> (SMS ok) +31 20 893 2796 <+31%2020%20893%202796> (no SMS)
I still dont know what opening has to do with transmitting, even when you do it remotely , a socket / websocket connection should be all you need. For me transmitting the entire image would be necessary only in the case you want to install it remotely and that remote location has no immediate access to the installation. On Fri, Aug 25, 2017 at 7:14 AM Ben Coman <btc@openinworld.com> wrote:
I understand that to mean effectively that you are "opening" the image across the net - so eventually you need to whole image transmitted, but you don't have to wait for the whole thing before you start running it. cheers -ben
On Fri, Aug 25, 2017 at 2:00 AM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Indeed that can be a barrier but why you would want to transmit an entire image instead of portion of it using something like fuel files or other binary formats ? It would dramatically reduce the size of data you transmit.
On Thu, Aug 24, 2017 at 8:10 PM Craig Latta <craig@blackpagedigital.com> wrote:
...10mbs which is the size pharo image can be reduced to is nothing for todays TBs hard drives and GBs flash drives and online storage. Unless you do an embedded app and 10 mbs are huge for your limited storage.
Or you want to minimize initial startup time, including the time it takes to transmit the entire system over the net.
-C
-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com voice through 2017-09-12: + 1 510 833 5799 <(510)%20833-5799> (SMS ok) +31 20 893 2796 <+31%2020%20893%202796> (no SMS)
Mariano's PhD was on this - as mentioned it to me a few weeks ago. This was one of the reasons for building fuel - to enable this sort of thing on top - and he proved it worked. Dimitrus - the idea is to I have a small core that loads quick and then less used elements can be paged in when needed (but maybe that's what you're saying too). I disagree that Pharo desperately needs image assembly tools. It's quite specialised - and we have some core tools to work with, and minimal images to start from. While I'd love more - finishing off what we already have in play (e.g. Got, bloc, Calypso ...) would seem more urgent. Tim Sent from my iPhone
On 25 Aug 2017, at 08:47, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
I still dont know what opening has to do with transmitting, even when you do it remotely , a socket / websocket connection should be all you need. For me transmitting the entire image would be necessary only in the case you want to install it remotely and that remote location has no immediate access to the installation.
On Fri, Aug 25, 2017 at 7:14 AM Ben Coman <btc@openinworld.com> wrote: I understand that to mean effectively that you are "opening" the image across the net - so eventually you need to whole image transmitted, but you don't have to wait for the whole thing before you start running it. cheers -ben
On Fri, Aug 25, 2017 at 2:00 AM, Dimitris Chloupis <kilon.alios@gmail.com> wrote: Indeed that can be a barrier but why you would want to transmit an entire image instead of portion of it using something like fuel files or other binary formats ? It would dramatically reduce the size of data you transmit.
On Thu, Aug 24, 2017 at 8:10 PM Craig Latta <craig@blackpagedigital.com> wrote:
...10mbs which is the size pharo image can be reduced to is nothing for todays TBs hard drives and GBs flash drives and online storage. Unless you do an embedded app and 10 mbs are huge for your limited storage.
Or you want to minimize initial startup time, including the time it takes to transmit the entire system over the net.
-C
-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com voice through 2017-09-12: + 1 510 833 5799 (SMS ok) +31 20 893 2796 (no SMS)
It is always easier to start than to finish something. :) For the small core we are getting there as Guillermo work showed it to us. 70 is bootstrap from source. Do you believe it? It is real and tangible. People can do it on their own machine. And this is just the start. Now we have our roadmap it is available and we will work on that roadmap. We know where we go and why we go there :). Stef On Fri, Aug 25, 2017 at 1:44 PM, Tim Mackinnon <tim@testit.works> wrote:
Mariano's PhD was on this - as mentioned it to me a few weeks ago. This was one of the reasons for building fuel - to enable this sort of thing on top - and he proved it worked.
Dimitrus - the idea is to I have a small core that loads quick and then less used elements can be paged in when needed (but maybe that's what you're saying too).
I disagree that Pharo desperately needs image assembly tools. It's quite specialised - and we have some core tools to work with, and minimal images to start from.
While I'd love more - finishing off what we already have in play (e.g. Got, bloc, Calypso ...) would seem more urgent.
Tim
Sent from my iPhone
On 25 Aug 2017, at 08:47, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
I still dont know what opening has to do with transmitting, even when you do it remotely , a socket / websocket connection should be all you need. For me transmitting the entire image would be necessary only in the case you want to install it remotely and that remote location has no immediate access to the installation.
On Fri, Aug 25, 2017 at 7:14 AM Ben Coman <btc@openinworld.com> wrote:
I understand that to mean effectively that you are "opening" the image across the net - so eventually you need to whole image transmitted, but you don't have to wait for the whole thing before you start running it. cheers -ben
On Fri, Aug 25, 2017 at 2:00 AM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Indeed that can be a barrier but why you would want to transmit an entire image instead of portion of it using something like fuel files or other binary formats ? It would dramatically reduce the size of data you transmit.
On Thu, Aug 24, 2017 at 8:10 PM Craig Latta <craig@blackpagedigital.com> wrote:
...10mbs which is the size pharo image can be reduced to is nothing for todays TBs hard drives and GBs flash drives and online storage. Unless you do an embedded app and 10 mbs are huge for your limited storage.
Or you want to minimize initial startup time, including the time it takes to transmit the entire system over the net.
-C
-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com voice through 2017-09-12: + 1 510 833 5799 (SMS ok) +31 20 893 2796 (no SMS)
Hi--
...10mbs which is the size pharo image can be reduced to is nothing for todays TBs hard drives and GBs flash drives and online storage. Unless you do an embedded app and 10 mbs are huge for your limited storage.
Or you want to minimize initial startup time, including the time it takes to transmit the entire system over the net.
...transmitting the entire image would be necessary only in the case you want to install it remotely and that remote location has no immediate access to the installation.
Yes, that's what I meant by "initial startup". -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com voice through 2017-09-12: + 1 510 833 5799 (SMS ok) +31 20 893 2796 (no SMS)
ah ok , thanks for the clarification , Craig and Tim , this makes more sense to me now :) On Sat, Aug 26, 2017 at 3:44 AM Craig Latta <craig@blackpagedigital.com> wrote:
Hi--
...10mbs which is the size pharo image can be reduced to is nothing for todays TBs hard drives and GBs flash drives and online storage. Unless you do an embedded app and 10 mbs are huge for your limited storage.
Or you want to minimize initial startup time, including the time it takes to transmit the entire system over the net.
...transmitting the entire image would be necessary only in the case you want to install it remotely and that remote location has no immediate access to the installation.
Yes, that's what I meant by "initial startup".
-C
-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com voice through 2017-09-12: + 1 510 833 5799 <(510)%20833-5799> (SMS ok) +31 20 893 2796 <+31%2020%20893%202796> (no SMS)
If you start with a minimal imaqe, it's not obvious to me how you'd add a missing class and pull in all of its dependencies (which can be voluminous). And for a large application, there could be many, many missing classes. This sounds rather arduous. Tim Mackinnon wrote
There has been a lot of great work on this front on the Pharo side from the "team" and PharoLambda has made use of it (although it's a tiny project).
My footprint is ~22mb including vm & image. And leaving out sources.
The ./scripts directory has the example of how to do it, along side the .gitlab-ci.yml file.
Unlike the commercial distributions (and this may have changed recently), there is a minimal image you can have download, which has enough to bootstrap loading your project via metacello. There are no browser tools or morphic things in the starting image I have chosen.
You can potentially get smaller - but it's a decent result. The only bit I added was to remove testcases (optional), and clear down metacello.
It's probably worthy of a blog post - but honestly the running example is pretty straight forward.
The commercial tools all have a decent "strip dead code" tool, that does a similar thing in reverse - which is equally a decent way of approaching the problem and can lead to even tinier results.
Tim
Sent from my iPhone
On 21 Aug 2017, at 21:25, horrido <
horrido.hobbies@
> wrote:
I received this comment on Facebook:
Smalltalk is a fantastic language and its development environment can't be beat... But the documentation for the many open source implementations is contradictory or confusing or missing. I can't speak for the commercial versions. Without an experienced mentor it is not possible to create a complex app. And even when you have done so, *I know no way to strip out the unused part of the image as well as the embedded source code*. -----
This issue of stripping out unused code seems to recur a lot. And truth be told, I've never seen a clear explanation of how to do this. Can someone provide clear direction? Is this documented anywhere? I'd like to use the information in future to assuage other people's concerns.
Thanks.
-- View this message in context: http://forum.world.st/Minimizing-an-Application-tp4963262.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/Minimizing-an-Application-tp4963262p4963349.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Hi Richard, If you make sure that you have a seed and maps of dependencies for all the packages you use then you can build daily your project with a integration farm. I worked with Envy and I was used to load in one click a working or deployed image. And it worked. Then working on the granularity of your packages and their dependencies you can control what you deploy. We are going in that direction for Pharo because we believe it is the way for most projects. So in the future we will get PharoSeed and Pharo as two images we maintain and deploy but people will build their own based on PharoSeed. Now guillermo is his PhD developed also a shrinking system that can produce hyper specialised image (and quite small we got up to 11k image for 2 + 3). We could produce a WebCounter Seaside app in 500 k. Now such scenarios are more for advanced and specific use. Stef On Tue, Aug 22, 2017 at 12:46 PM, horrido <horrido.hobbies@gmail.com> wrote:
If you start with a minimal imaqe, it's not obvious to me how you'd add a missing class and pull in all of its dependencies (which can be voluminous). And for a large application, there could be many, many missing classes. This sounds rather arduous.
Tim Mackinnon wrote
There has been a lot of great work on this front on the Pharo side from the "team" and PharoLambda has made use of it (although it's a tiny project).
My footprint is ~22mb including vm & image. And leaving out sources.
The ./scripts directory has the example of how to do it, along side the .gitlab-ci.yml file.
Unlike the commercial distributions (and this may have changed recently), there is a minimal image you can have download, which has enough to bootstrap loading your project via metacello. There are no browser tools or morphic things in the starting image I have chosen.
You can potentially get smaller - but it's a decent result. The only bit I added was to remove testcases (optional), and clear down metacello.
It's probably worthy of a blog post - but honestly the running example is pretty straight forward.
The commercial tools all have a decent "strip dead code" tool, that does a similar thing in reverse - which is equally a decent way of approaching the problem and can lead to even tinier results.
Tim
Sent from my iPhone
On 21 Aug 2017, at 21:25, horrido <
horrido.hobbies@
> wrote:
I received this comment on Facebook:
Smalltalk is a fantastic language and its development environment can't be beat... But the documentation for the many open source implementations is contradictory or confusing or missing. I can't speak for the commercial versions. Without an experienced mentor it is not possible to create a complex app. And even when you have done so, *I know no way to strip out the unused part of the image as well as the embedded source code*. -----
This issue of stripping out unused code seems to recur a lot. And truth be told, I've never seen a clear explanation of how to do this. Can someone provide clear direction? Is this documented anywhere? I'd like to use the information in future to assuage other people's concerns.
Thanks.
-- View this message in context: http://forum.world.st/Minimizing-an-Application-tp4963262.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/Minimizing-an-Application-tp4963262p4963349.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 22-08-17 12:46, horrido wrote:
If you start with a minimal imaqe, it's not obvious to me how you'd add a missing class and pull in all of its dependencies (which can be voluminous). And for a large application, there could be many, many missing classes. This sounds rather arduous.
That has been solved by Craig years ago. Instead of DNU you just load the code from a connected image. Stephan
2017-08-24 14:51 GMT-03:00 stephan <stephan@stack.nl>:
On 22-08-17 12:46, horrido wrote:
If you start with a minimal imaqe, it's not obvious to me how you'd add a missing class and pull in all of its dependencies (which can be voluminous). And for a large application, there could be many, many missing classes. This sounds rather arduous.
That has been solved by Craig years ago. Instead of DNU you just load the code from a connected image.
Has this been tested in Pharo? I'm aware of this since I have memory, but I haven't know of any production system using it. Regards! Esteban A. Maringolo
participants (9)
-
Ben Coman -
Craig Latta -
Dimitris Chloupis -
Esteban A. Maringolo -
horrido -
Richard Sargent -
stephan -
Stephane Ducasse -
Tim Mackinnon