Minimizing an Application
Locked
 
|
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. |
|
|
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
|
Re: Minimizing an Application
Administrator
|
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" <[hidden email]> wrote:
|
|
|
In reply to this post by Tim Mackinnon
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.
|
Re: Minimizing an Application
|
|
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 <[hidden email]> 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. > |
Re: Minimizing an Application
|
|
In reply to this post by Richard Sargent
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 <[hidden email]>: > 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" <[hidden email]> 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 <[hidden email]> 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. >> > |
Re: Minimizing an Application
|
|
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 <[hidden email]> 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 <[hidden email]>: >> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: We would like to have dll like deployment too. But I'm too dull to |
|
|
> ...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 [hidden email] voice through 2017-09-12: + 1 510 833 5799 (SMS ok) +31 20 893 2796 (no SMS) |
Re: Minimizing an Application
|
|
In reply to this post by horrido
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 |
|
|
In reply to this post by Craig Latta
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 <[hidden email]> wrote:
|
Re: Minimizing an Application
|
|
In reply to this post by Stephan Eggermont-3
2017-08-24 14:51 GMT-03:00 stephan <[hidden email]>:
> 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 |
|
|
In reply to this post by kilon.alios
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 <[hidden email]> 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 <[hidden email]> 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
|
Re: Minimizing an Application
|
|
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >> 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 <[hidden email]> >>> 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 >>>> [hidden email] >>>> voice through 2017-09-12: >>>> + 1 510 833 5799 (SMS ok) >>>> +31 20 893 2796 (no SMS) >>>> >>>> >> > |
|
|
In reply to this post by kilon.alios
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 [hidden email] 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 <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |