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.s...@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 > <emaring...@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.sarg...@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.hobb...@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. > >>> > >> > > > >
