Runtime obesity

>Hi,
>
>the runtimes are getting bigger and bigger... Here is my data point for
>the discussion:
>The size of the exe with compressed image:
>7.3.1: 5120 KB
>7.4: 5604 KB
>
>My code remained the same and I used the same settings for the packager
>(just for the windows platform with only the windows UI).
>
>I really hope that this trend (holding for a couple of releases now) will
>not continue.
>With all the talk about building up images, I fear to face 20 MB+ images
>in the future.
>This would mean the end of VisualWorks for desktop tools (maybe not for
>the applications, since people are prepared to get a coffee when starting
>up the program).
>
>cheers (worried),
>     Christian

> -----Ursprüngliche Nachricht-----
> Von: James Robertson [mailto:[hidden email]]
> Gesendet: Dienstag, 7. März 2006 13:43
> An: [hidden email]
> Betreff: Re: Runtime obesity
>
>
> I discussed this with Alan, who did a lot of work on the RTP
> this last
> release.  He'll correct me if I miss something :)
>
> As I understand it, the older rtp was stripping out things that
> realistically should not have been stripped out, while the
> newer one is
> more careful.
>
> Something you might try: In preview/packaging, you'll find
> base.im.  The
> stock visual.im is over 11 MB, while base.im is just under 9.
>
> At 02:45 AM 3/7/2006, you wrote:
> >Hi,
> >
> >the runtimes are getting bigger and bigger... Here is my
> data point for
> >the discussion:
> >The size of the exe with compressed image:
> >7.3.1: 5120 KB
> >7.4: 5604 KB
> >
> >My code remained the same and I used the same settings for
> the packager
> >(just for the windows platform with only the windows UI).
> >
> >I really hope that this trend (holding for a couple of
> releases now) will
> >not continue.
> >With all the talk about building up images, I fear to face
> 20 MB+ images
> >in the future.
> >This would mean the end of VisualWorks for desktop tools
> (maybe not for
> >the applications, since people are prepared to get a coffee
> when starting
> >up the program).
> >
> >cheers (worried),
> >     Christian
>
> <Talk Small and Carry a Big Class Library>
> James Robertson, Product Manager, Cincom Smalltalk
> http://www.cincomsmalltalk.com/blog/blogView
>
>
>

>Cheers,
>        Christian
>
>> -----Ursprüngliche Nachricht-----
>> Von: James Robertson [mailto:[hidden email]]
>> Gesendet: Dienstag, 7. März 2006 13:43
>> An: [hidden email]
>> Betreff: Re: Runtime obesity
>>
>>
>> I discussed this with Alan, who did a lot of work on the RTP
>> this last
>> release.  He'll correct me if I miss something :)
>>
>> As I understand it, the older rtp was stripping out things that
>> realistically should not have been stripped out, while the
>> newer one is
>> more careful.
>>
>> Something you might try: In preview/packaging, you'll find
>> base.im.  The
>> stock visual.im is over 11 MB, while base.im is just under 9.
>>
>> At 02:45 AM 3/7/2006, you wrote:
>> >Hi,
>> >
>> >the runtimes are getting bigger and bigger... Here is my
>> data point for
>> >the discussion:
>> >The size of the exe with compressed image:
>> >7.3.1: 5120 KB
>> >7.4: 5604 KB
>> >
>> >My code remained the same and I used the same settings for
>> the packager
>> >(just for the windows platform with only the windows UI).
>> >
>> >I really hope that this trend (holding for a couple of
>> releases now) will
>> >not continue.
>> >With all the talk about building up images, I fear to face
>> 20 MB+ images
>> >in the future.
>> >This would mean the end of VisualWorks for desktop tools
>> (maybe not for
>> >the applications, since people are prepared to get a coffee
>> when starting
>> >up the program).
>> >
>> >cheers (worried),
>> >     Christian
>>
>> <Talk Small and Carry a Big Class Library>
>> James Robertson, Product Manager, Cincom Smalltalk
>> http://www.cincomsmalltalk.com/blog/blogView
>>
>>
>>

>At 08:54 AM 3/7/2006, Christian Haider wrote:
>>I am using the base.im since it was introduced...
>>
>>I understand that the packager is more careful now and that is ok for the
>>newcomer. But in the case where it worked before, it just means that it
>>includes many things now that are obviously not needed.
>
>I don't think I'd consider it quite that way. In the case before it would have been including only part of something, so it would have obviously not worked, except that the code was never run. So before it also included many things that were obviously not needed, just not enough to make them actually work. So, where the old one would leave half of, say, the settings framework in, the new one will leave all of it, so settings will actually work. If you want to not include them, then it's much easier than it was to look at what's been included or excluded and remove particular packages, either within RTP, or by just not having them in the image to start with. And of course in many circumtsnaces the old version left out many things that obviously were needed.
>
>The only thing I'm aware of that was actually added to the base image in 7.4 were the Standard IO Streams.
>
>So if you're just using the same settings as previously, it would probably be a good idea to review your settings, since the entire organizational principle for RTP changed, and it's much easier to exclude, e.g. class extensions which may drag along large extra chunks of code.
>
>>There is a nice way to tell the packager which classes and selectors are to
>>be included (#dynamicallyReferencedClasses and friends). Could Cincom think
>>about something along the lines to exclude things to be packaged (maybe
>>#notReferencedXXX and friends).
>
>That seems reasonable, although I think it would mostly only be useful for user code. For libraries, I don't really know what will and won't be used. And if I do know that something is definitely not going to be needed at runtime, rather than annotating the code to indicate that it should be stripped, I think I would be better off to put the development-time and run-time code in different packages.
>
>Perhaps a more useful annotation would be one on packages to tell RTP that this package should by default, be unloaded before stripping. Or if we had a code annotation, to treat it as meaning that a particular reference should not be counted, e.g. this class uses a symbol that might be a class name in other circumstances, but I know it's not used that way.
>
>
>>Cheers,
>>        Christian
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: James Robertson [mailto:[hidden email]]
>>> Gesendet: Dienstag, 7. März 2006 13:43
>>> An: [hidden email]
>>> Betreff: Re: Runtime obesity
>>>
>>>
>>> I discussed this with Alan, who did a lot of work on the RTP
>>> this last
>>> release.  He'll correct me if I miss something :)
>>>
>>> As I understand it, the older rtp was stripping out things that
>>> realistically should not have been stripped out, while the
>>> newer one is
>>> more careful.
>>>
>>> Something you might try: In preview/packaging, you'll find
>>> base.im.  The
>>> stock visual.im is over 11 MB, while base.im is just under 9.
>>>
>>> At 02:45 AM 3/7/2006, you wrote:
>>> >Hi,
>>> >

> -----Ursprüngliche Nachricht-----
> Von: Alan Knight [mailto:[hidden email]]
> Gesendet: Dienstag, 7. März 2006 15:42
> An: [hidden email]; [hidden email]
> Betreff: Re: AW: Runtime obesity
>
>
> At 08:54 AM 3/7/2006, Christian Haider wrote:
> >I am using the base.im since it was introduced...
> >
> >I understand that the packager is more careful now and that
> is ok for the
> >newcomer. But in the case where it worked before, it just
> means that it
> >includes many things now that are obviously not needed.
>
> I don't think I'd consider it quite that way. In the case
> before it would have been including only part of something,
> so it would have obviously not worked, except that the code
> was never run. So before it also included many things that
> were obviously not needed, just not enough to make them
> actually work. So, where the old one would leave half of,
> say, the settings framework in, the new one will leave all of
> it, so settings will actually work. If you want to not
> include them, then it's much easier than it was to look at
> what's been included or excluded and remove particular
> packages, either within RTP, or by just not having them in
> the image to start with. And of course in many circumtsnaces
> the old version left out many things that obviously were needed.
>
> The only thing I'm aware of that was actually added to the
> base image in 7.4 were the Standard IO Streams.
>
> So if you're just using the same settings as previously, it
> would probably be a good idea to review your settings, since
> the entire organizational principle for RTP changed, and it's
> much easier to exclude, e.g. class extensions which may drag
> along large extra chunks of code.
>
> >There is a nice way to tell the packager which classes and
> selectors are to
> >be included (#dynamicallyReferencedClasses and friends).
> Could Cincom think
> >about something along the lines to exclude things to be
> packaged (maybe
> >#notReferencedXXX and friends).
>
> That seems reasonable, although I think it would mostly only
> be useful for user code. For libraries, I don't really know
> what will and won't be used. And if I do know that something
> is definitely not going to be needed at runtime, rather than
> annotating the code to indicate that it should be stripped, I
> think I would be better off to put the development-time and
> run-time code in different packages.
>
> Perhaps a more useful annotation would be one on packages to
> tell RTP that this package should by default, be unloaded
> before stripping. Or if we had a code annotation, to treat it
> as meaning that a particular reference should not be counted,
> e.g. this class uses a symbol that might be a class name in
> other circumstances, but I know it's not used that way.
>
>
> >Cheers,
> >        Christian
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: James Robertson [mailto:[hidden email]]
> >> Gesendet: Dienstag, 7. März 2006 13:43
> >> An: [hidden email]
> >> Betreff: Re: Runtime obesity
> >>
> >>
> >> I discussed this with Alan, who did a lot of work on the RTP
> >> this last
> >> release.  He'll correct me if I miss something :)
> >>
> >> As I understand it, the older rtp was stripping out things that
> >> realistically should not have been stripped out, while the
> >> newer one is
> >> more careful.
> >>
> >> Something you might try: In preview/packaging, you'll find
> >> base.im.  The
> >> stock visual.im is over 11 MB, while base.im is just under 9.
> >>
> >> At 02:45 AM 3/7/2006, you wrote:
> >> >Hi,
> >> >
> >> >the runtimes are getting bigger and bigger... Here is my
> >> data point for
> >> >the discussion:
> >> >The size of the exe with compressed image:
> >> >7.3.1: 5120 KB
> >> >7.4: 5604 KB
> >> >
> >> >My code remained the same and I used the same settings for
> >> the packager
> >> >(just for the windows platform with only the windows UI).
> >> >
> >> >I really hope that this trend (holding for a couple of
> >> releases now) will
> >> >not continue.
> >> >With all the talk about building up images, I fear to face
> >> 20 MB+ images
> >> >in the future.
> >> >This would mean the end of VisualWorks for desktop tools
> >> (maybe not for
> >> >the applications, since people are prepared to get a coffee
> >> when starting
> >> >up the program).
> >> >
> >> >cheers (worried),
> >> >     Christian
> >>
> >> <Talk Small and Carry a Big Class Library>
> >> James Robertson, Product Manager, Cincom Smalltalk
> >> http://www.cincomsmalltalk.com/blog/blogView
> >>
> >>
> >>
>
> --
> Alan Knight [|], Cincom Smalltalk Development
> [hidden email]
> [hidden email]
> http://www.cincom.com/smalltalk
>
> "The Static Typing Philosophy: Make it fast. Make it right.
> Make it run." - Niall Ross
>
>
>

> Perhaps it would be a good idea to have a BOF for the runtime packager  
> at Smalltalk Solutions.  A detailed walkthrough of how to best use it  
> would be very helpful.  Or, maybe just make a screencast and put it on  
> the web.  I know there is a very simple example screencast by James, but  
> an in-depth one would be great.  There's a lot of stuff to know about  
> the RTP.   :-)
>
> -Carl Gundel, author of Liberty BASIC
> http://www.libertybasic.com
>
>  ..... Original Message .......
> On Tue, 07 Mar 2006 09:42:25 -0500 Alan Knight <[hidden email]> wrote:
>> At 08:54 AM 3/7/2006, Christian Haider wrote:
>>> I am using the base.im since it was introduced...
>>>
>>> I understand that the packager is more careful now and that is ok for  
>>> the
>>> newcomer. But in the case where it worked before, it just means that it
>>> includes many things now that are obviously not needed.
>>
>> I don't think I'd consider it quite that way. In the case before it  
>> would have been including only part of something, so it would have  
>> obviously not worked, except that the code was never run. So before it  
>> also included many things that were obviously not needed, just not  
>> enough to make them actually work. So, where the old one would leave  
>> half of, say, the settings framework in, the new one will leave all of  
>> it, so settings will actually work. If you want to not include them,  
>> then it's much easier than it was to look at what's been included or  
>> excluded and remove particular packages, either within RTP, or by just  
>> not having them in the image to start with. And of course in many  
>> circumtsnaces the old version left out many things that obviously were  
>> needed.
>>
>> The only thing I'm aware of that was actually added to the base image  
>> in 7.4 were the Standard IO Streams.
>>
>> So if you're just using the same settings as previously, it would  
>> probably be a good idea to review your settings, since the entire  
>> organizational principle for RTP changed, and it's much easier to  
>> exclude, e.g. class extensions which may drag along large extra chunks  
>> of code.
>>
>>> There is a nice way to tell the packager which classes and selectors  
>>> are to
>>> be included (#dynamicallyReferencedClasses and friends). Could Cincom  
>>> think
>>> about something along the lines to exclude things to be packaged (maybe
>>> #notReferencedXXX and friends).
>>
>> That seems reasonable, although I think it would mostly only be useful  
>> for user code. For libraries, I don't really know what will and won't  
>> be used. And if I do know that something is definitely not going to be  
>> needed at runtime, rather than annotating the code to indicate that it  
>> should be stripped, I think I would be better off to put the  
>> development-time and run-time code in different packages.
>>
>> Perhaps a more useful annotation would be one on packages to tell RTP  
>> that this package should by default, be unloaded before stripping. Or  
>> if we had a code annotation, to treat it as meaning that a particular  
>> reference should not be counted, e.g. this class uses a symbol that  
>> might be a class name in other circumstances, but I know it's not used  
>> that way.
>>
>>
>>> Cheers,
>>>        Christian
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: James Robertson [mailto:[hidden email]]
>>>> Gesendet: Dienstag, 7. März 2006 13:43
>>>> An: [hidden email]
>>>> Betreff: Re: Runtime obesity
>>>>
>>>>
>>>> I discussed this with Alan, who did a lot of work on the RTP
>>>> this last
>>>> release.  He'll correct me if I miss something :)
>>>>
>>>> As I understand it, the older rtp was stripping out things that
>>>> realistically should not have been stripped out, while the
>>>> newer one is
>>>> more careful.
>>>>
>>>> Something you might try: In preview/packaging, you'll find
>>>> base.im.  The
>>>> stock visual.im is over 11 MB, while base.im is just under 9.
>>>>
>>>> At 02:45 AM 3/7/2006, you wrote:
>>>> >Hi,
>>>> >

> Hi all,
>
> An interesting path to be explored can be the generation
>  of images inside running images (called image gestation).
>
> I have built many images and cross-VM images
>  (e.g. building new smalltalk 3D ambiences for
>  entertrainment industry, when we didn´t have
>  a running VM), resulting in interesting images
>  from 80kb -for helloWorld on console- to
>  complete running application environments.
>
> The technique start from gestation of a minimum
>  environment inside a running host; and use the
>  host´s tools (browsers and inspectors, & automated
>  nutrition tools) to put methods inside the child image.
> Then a system tracer is run to dump child image
>  contents (patching and cutting references to host
>  image) and doing custom primitive transforms if
>  required (e.g. when generating cross image development)
>
> I have encountered that building images by gestation
>  is much more easy than shrinking running images;
>  because you build the image in a constructive
>  manner (on real running requirements) and not by
>  reduction.
>
> One of the most valuable nutrient tools has been
>  method tracers that register method activations.
> They can be used to record the methods requiered
>  while evaluating an expression in the host image,
>  and then inject the collected methods (and classes)
>  onto the child image.
>
> More details and samples can be found at
>  http://www.aleReimondo.com.ar/ImageGestation
>
> best,
> Ale.
>
>
> ----- Original Message -----
> From: "Bruce Badger" <[hidden email]>
> To: "Vwnc" <[hidden email]>
> Sent: Tuesday, March 07, 2006 5:24 PM
> Subject: Re: AW: Runtime obesity
>
>
> On 08/03/06, Charles A. Monteiro <[hidden email]> wrote:
>
> > So I'm game if anybody is interested, Bruce perhaps :)
>
> Sure!
>
> I think a build-up BOF would be fairly short, though:
>
>  Users: "We want a smaller better understood base.im"
>
>  Cincom: "We know.  We're working on it."
>
>  All: "Beer!"
>
> Perhaps a BOF on "Deployment" would be the way to go.  Then we can
> talk about the base.im for the first 10 seconds, and then talk about
> RTP and perhaps get input from people using other Smalltalk
> implementations too.
>
> All the best,
>    Bruce
> --
> Make the most of your skills - with OpenSkills
> http://www.openskills.org/
>

> Hi all,
>
> An interesting path to be explored can be the generation
>  of images inside running images (called image gestation).
>
> I have built many images and cross-VM images
>  (e.g. building new smalltalk 3D ambiences for
>  entertrainment industry, when we didn´t have
>  a running VM), resulting in interesting images
>  from 80kb -for helloWorld on console- to
>  complete running application environments.
>
> The technique start from gestation of a minimum
>  environment inside a running host; and use the
>  host´s tools (browsers and inspectors, & automated
>  nutrition tools) to put methods inside the child image.
> Then a system tracer is run to dump child image
>  contents (patching and cutting references to host
>  image) and doing custom primitive transforms if
>  required (e.g. when generating cross image development)
>
> I have encountered that building images by gestation
>  is much more easy than shrinking running images;
>  because you build the image in a constructive
>  manner (on real running requirements) and not by
>  reduction.
>
> One of the most valuable nutrient tools has been
>  method tracers that register method activations.
> They can be used to record the methods requiered
>  while evaluating an expression in the host image,
>  and then inject the collected methods (and classes)
>  onto the child image.
>
> More details and samples can be found at
>  http://www.aleReimondo.com.ar/ImageGestation
>
> best,
> Ale.

>> Perhaps it would be a good idea to have a BOF for the runtime packager  
>> at Smalltalk Solutions.  A detailed walkthrough of how to best use it  
>> would be very helpful.  Or, maybe just make a screencast and put it on  
>> the web.  I know there is a very simple example screencast by James, but  
>> an in-depth one would be great.  There's a lot of stuff to know about  
>> the RTP.   :-)
>>
>> -Carl Gundel, author of Liberty BASIC
>> http://www.libertybasic.com
>>
>>  ..... Original Message .......
>> On Tue, 07 Mar 2006 09:42:25 -0500 Alan Knight <[hidden email]> wrote:
>>> At 08:54 AM 3/7/2006, Christian Haider wrote:
>>>> I am using the base.im since it was introduced...
>>>>
>>>> I understand that the packager is more careful now and that is ok for  
>>>> the
>>>> newcomer. But in the case where it worked before, it just means that it
>>>> includes many things now that are obviously not needed.
>>>
>>> I don't think I'd consider it quite that way. In the case before it  
>>> would have been including only part of something, so it would have  
>>> obviously not worked, except that the code was never run. So before it  
>>> also included many things that were obviously not needed, just not  
>>> enough to make them actually work. So, where the old one would leave  
>>> half of, say, the settings framework in, the new one will leave all of  
>>> it, so settings will actually work. If you want to not include them,  
>>> then it's much easier than it was to look at what's been included or  
>>> excluded and remove particular packages, either within RTP, or by just  
>>> not having them in the image to start with. And of course in many  
>>> circumtsnaces the old version left out many things that obviously were  
>>> needed.
>>>
>>> The only thing I'm aware of that was actually added to the base image  
>>> in 7.4 were the Standard IO Streams.
>>>
>>> So if you're just using the same settings as previously, it would  
>>> probably be a good idea to review your settings, since the entire  
>>> organizational principle for RTP changed, and it's much easier to  
>>> exclude, e.g. class extensions which may drag along large extra chunks  
>>> of code.
>>>
>>>> There is a nice way to tell the packager which classes and selectors  
>>>> are to
>>>> be included (#dynamicallyReferencedClasses and friends). Could Cincom  
>>>> think
>>>> about something along the lines to exclude things to be packaged (maybe
>>>> #notReferencedXXX and friends).
>>>
>>> That seems reasonable, although I think it would mostly only be useful  
>>> for user code. For libraries, I don't really know what will and won't  
>>> be used. And if I do know that something is definitely not going to be  
>>> needed at runtime, rather than annotating the code to indicate that it  
>>> should be stripped, I think I would be better off to put the  
>>> development-time and run-time code in different packages.
>>>
>>> Perhaps a more useful annotation would be one on packages to tell RTP  
>>> that this package should by default, be unloaded before stripping. Or  
>>> if we had a code annotation, to treat it as meaning that a particular  
>>> reference should not be counted, e.g. this class uses a symbol that  
>>> might be a class name in other circumstances, but I know it's not used  
>>> that way.
>>>
>>>
>>>> Cheers,
>>>>        Christian
>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: James Robertson [mailto:[hidden email]]
>>>>> Gesendet: Dienstag, 7. März 2006 13:43
>>>>> An: [hidden email]
>>>>> Betreff: Re: Runtime obesity
>>>>>
>>>>>
>>>>> I discussed this with Alan, who did a lot of work on the RTP
>>>>> this last
>>>>> release.  He'll correct me if I miss something :)
>>>>>
>>>>> As I understand it, the older rtp was stripping out things that
>>>>> realistically should not have been stripped out, while the
>>>>> newer one is
>>>>> more careful.
>>>>>
>>>>> Something you might try: In preview/packaging, you'll find
>>>>> base.im.  The
>>>>> stock visual.im is over 11 MB, while base.im is just under 9.
>>>>>
>>>>> At 02:45 AM 3/7/2006, you wrote:
>>>>> >Hi,
>>>>> >

> Hi all,
>
> An interesting path to be explored can be the generation
>  of images inside running images (called image gestation).
>
> I have built many images and cross-VM images
>  (e.g. building new smalltalk 3D ambiences for
>  entertrainment industry, when we didn´t have
>  a running VM), resulting in interesting images
>  from 80kb -for helloWorld on console- to
>  complete running application environments.
>
> The technique start from gestation of a minimum
>  environment inside a running host; and use the
>  host´s tools (browsers and inspectors, & automated
>  nutrition tools) to put methods inside the child image.
> Then a system tracer is run to dump child image
>  contents (patching and cutting references to host
>  image) and doing custom primitive transforms if
>  required (e.g. when generating cross image development)
>
> I have encountered that building images by gestation
>  is much more easy than shrinking running images;
>  because you build the image in a constructive
>  manner (on real running requirements) and not by
>  reduction.
>
> One of the most valuable nutrient tools has been
>  method tracers that register method activations.
> They can be used to record the methods requiered
>  while evaluating an expression in the host image,
>  and then inject the collected methods (and classes)
>  onto the child image.
>
> More details and samples can be found at
>  http://www.aleReimondo.com.ar/ImageGestation
>
> best,
> Ale.

> I'd definitely be attending that BOF. I have a lot of experience with
> this stuff now and I can throw out some real numbers from our
> experience packaging XML WithStyle.
>
> Cheers,
> Michael
>
>> I think it would be more interesting to organize a BOF where all of us
>> that are attempting "build up" Smalltalk Runtime Environment approaches  
>> to
>> deployment get together and talk about what works , what does not, how  
>> to
>> get a smaller base.im than the 8mb provided, although I can appreciate
>> that you Carl may want as small an image as possible and therefore
>> stripping I want a smaller SRE , I also would not mind talking about how
>> to securely load parcels, authenticate parcels etc.
>
>> So I'm game if anybody is interested, Bruce perhaps :)
>
>> -Charles
>
>> On Tue, 07 Mar 2006 04:06:00 -0500, Carl Gundel <[hidden email]>
>> wrote:
>
>>> Perhaps it would be a good idea to have a BOF for the runtime packager
>>> at Smalltalk Solutions.  A detailed walkthrough of how to best use it
>>> would be very helpful.  Or, maybe just make a screencast and put it on
>>> the web.  I know there is a very simple example screencast by James,  
>>> but
>>> an in-depth one would be great.  There's a lot of stuff to know about
>>> the RTP.   :-)
>>>
>>> -Carl Gundel, author of Liberty BASIC
>>> http://www.libertybasic.com
>>>
>>>  ..... Original Message .......
>>> On Tue, 07 Mar 2006 09:42:25 -0500 Alan Knight <[hidden email]> wrote:
>>>> At 08:54 AM 3/7/2006, Christian Haider wrote:
>>>>> I am using the base.im since it was introduced...
>>>>>
>>>>> I understand that the packager is more careful now and that is ok for
>>>>> the
>>>>> newcomer. But in the case where it worked before, it just means that  
>>>>> it
>>>>> includes many things now that are obviously not needed.
>>>>
>>>> I don't think I'd consider it quite that way. In the case before it
>>>> would have been including only part of something, so it would have
>>>> obviously not worked, except that the code was never run. So before it
>>>> also included many things that were obviously not needed, just not
>>>> enough to make them actually work. So, where the old one would leave
>>>> half of, say, the settings framework in, the new one will leave all of
>>>> it, so settings will actually work. If you want to not include them,
>>>> then it's much easier than it was to look at what's been included or
>>>> excluded and remove particular packages, either within RTP, or by just
>>>> not having them in the image to start with. And of course in many
>>>> circumtsnaces the old version left out many things that obviously were
>>>> needed.
>>>>
>>>> The only thing I'm aware of that was actually added to the base image
>>>> in 7.4 were the Standard IO Streams.
>>>>
>>>> So if you're just using the same settings as previously, it would
>>>> probably be a good idea to review your settings, since the entire
>>>> organizational principle for RTP changed, and it's much easier to
>>>> exclude, e.g. class extensions which may drag along large extra chunks
>>>> of code.
>>>>
>>>>> There is a nice way to tell the packager which classes and selectors
>>>>> are to
>>>>> be included (#dynamicallyReferencedClasses and friends). Could Cincom
>>>>> think
>>>>> about something along the lines to exclude things to be packaged  
>>>>> (maybe
>>>>> #notReferencedXXX and friends).
>>>>
>>>> That seems reasonable, although I think it would mostly only be useful
>>>> for user code. For libraries, I don't really know what will and won't
>>>> be used. And if I do know that something is definitely not going to be
>>>> needed at runtime, rather than annotating the code to indicate that it
>>>> should be stripped, I think I would be better off to put the
>>>> development-time and run-time code in different packages.
>>>>
>>>> Perhaps a more useful annotation would be one on packages to tell RTP
>>>> that this package should by default, be unloaded before stripping. Or
>>>> if we had a code annotation, to treat it as meaning that a particular
>>>> reference should not be counted, e.g. this class uses a symbol that
>>>> might be a class name in other circumstances, but I know it's not used
>>>> that way.
>>>>
>>>>
>>>>> Cheers,
>>>>>        Christian
>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: James Robertson [mailto:[hidden email]]
>>>>>> Gesendet: Dienstag, 7. März 2006 13:43
>>>>>> An: [hidden email]
>>>>>> Betreff: Re: Runtime obesity
>>>>>>
>>>>>>
>>>>>> I discussed this with Alan, who did a lot of work on the RTP
>>>>>> this last
>>>>>> release.  He'll correct me if I miss something :)
>>>>>>
>>>>>> As I understand it, the older rtp was stripping out things that
>>>>>> realistically should not have been stripped out, while the
>>>>>> newer one is
>>>>>> more careful.
>>>>>>
>>>>>> Something you might try: In preview/packaging, you'll find
>>>>>> base.im.  The
>>>>>> stock visual.im is over 11 MB, while base.im is just under 9.
>>>>>>
>>>>>> At 02:45 AM 3/7/2006, you wrote:
>>>>>> >Hi,
>>>>>> >
>
>
>

> On 08/03/06, Charles A. Monteiro <[hidden email]> wrote:
>
>> So I'm game if anybody is interested, Bruce perhaps :)
>
> Sure!
>
> I think a build-up BOF would be fairly short, though:
>
>  Users: "We want a smaller better understood base.im"
>
>  Cincom: "We know.  We're working on it."
>
>  All: "Beer!"
>
> Perhaps a BOF on "Deployment" would be the way to go.  Then we can
> talk about the base.im for the first 10 seconds, and then talk about
> RTP and perhaps get input from people using other Smalltalk
> implementations too.
>
> All the best,
>    Bruce
> --
> Make the most of your skills - with OpenSkills
> http://www.openskills.org/

> Hi (again),
>
> My last email was on image gestation...
>  e.g. the use of the objects in the runing environment
>  to build a new environment from bigbang objects.
> Another interesting point to explore is the creation
>  of a custom VM to run the generated images...
> The tool that generates the new image and dump
>  it on disk, also knows what primitives are really
>  requiered and, if we have a model of the VM in
>  the image, we can also write the VM code adapted
>  to minimum requitrements for generated image.
> The reduction of VM size (and customization of VM
>  according to runtime schemas) is as important as
>  image size when images are reduced.
>
> best,
> Ale.
>
>
>
> ----- Original Message -----
> From: "Alejandro F. Reimondo" <[hidden email]>
> To: "Bruce Badger" <[hidden email]>
> Cc: "smalltalking" <[hidden email]>; <[hidden email]>
> Sent: Tuesday, March 07, 2006 6:32 PM
> Subject: Re: AW: Runtime obesity
>
>
>> Hi all,
>>
>> An interesting path to be explored can be the generation
>>  of images inside running images (called image gestation).
>>
>> I have built many images and cross-VM images
>>  (e.g. building new smalltalk 3D ambiences for
>>  entertrainment industry, when we didn´t have
>>  a running VM), resulting in interesting images
>>  from 80kb -for helloWorld on console- to
>>  complete running application environments.
>>
>> The technique start from gestation of a minimum
>>  environment inside a running host; and use the
>>  host´s tools (browsers and inspectors, & automated
>>  nutrition tools) to put methods inside the child image.
>> Then a system tracer is run to dump child image
>>  contents (patching and cutting references to host
>>  image) and doing custom primitive transforms if
>>  required (e.g. when generating cross image development)
>>
>> I have encountered that building images by gestation
>>  is much more easy than shrinking running images;
>>  because you build the image in a constructive
>>  manner (on real running requirements) and not by
>>  reduction.
>>
>> One of the most valuable nutrient tools has been
>>  method tracers that register method activations.
>> They can be used to record the methods requiered
>>  while evaluating an expression in the host image,
>>  and then inject the collected methods (and classes)
>>  onto the child image.
>>
>> More details and samples can be found at
>>  http://www.aleReimondo.com.ar/ImageGestation
>>
>> best,
>> Ale.
>>
>>
>> ----- Original Message -----
>> From: "Bruce Badger" <[hidden email]>
>> To: "Vwnc" <[hidden email]>
>> Sent: Tuesday, March 07, 2006 5:24 PM
>> Subject: Re: AW: Runtime obesity
>>
>>
>> On 08/03/06, Charles A. Monteiro <[hidden email]> wrote:
>>
>> > So I'm game if anybody is interested, Bruce perhaps :)
>>
>> Sure!
>>
>> I think a build-up BOF would be fairly short, though:
>>
>>  Users: "We want a smaller better understood base.im"
>>
>>  Cincom: "We know.  We're working on it."
>>
>>  All: "Beer!"
>>
>> Perhaps a BOF on "Deployment" would be the way to go.  Then we can
>> talk about the base.im for the first 10 seconds, and then talk about
>> RTP and perhaps get input from people using other Smalltalk
>> implementations too.
>>
>> All the best,
>>    Bruce
>> --
>> Make the most of your skills - with OpenSkills
>> http://www.openskills.org/
>>

> Hi Carl,
>
>> Any thoughts on how hard would this
>> be to implement on VW?
>
> One of the requirements of my work is that it must
>  a exist a SystemTracer or any other form to dump
>  a new image from the running system.
> The SystemTracer was present in smalltalk/80
>  and Digitalk Smalltalks. New version of commertial
>  smalltalks remove this facility prohibiting the users
>  to build images from runing object system, truncating
>  the power of the object environment to build "applications"
>  and "programs", instead of real object systems (organic
>  software); and prohibiting to make severe changes
>  to the environment.
>
> I must implement the gestation framework using
>  squeak because VisualSmalltalk (the platform I use to
>  make my essays) has a severe limitation: it does not
>  let the user to build images nor core library SLL
>  (e.g. parcels). It was a limitation imposed by the
>  provider in VS version that reduced the power
>  of people using the platform and force us to
>  use non-commertial platforms like Squeak.
> The gestation framework is entirelly written
>  in Smalltalk, and does not requiere any primitive
>  support (only method activation tracer requieres
>  a VM change, but it is only required to automate
>  nutrition of the child image)
>
> best,
> Ale.
>
>
>
> ----- Original Message -----
> From: "Carl Gundel" <[hidden email]>
> To: "'Vwnc'" <[hidden email]>
> Sent: Tuesday, March 07, 2006 7:47 PM
> Subject: Re: AW: Runtime obesity
>
>
> Alejandro,
>
> This seems very similar to what Craig Latta is doing with Spoon.  Both
> your work and his are on Squeak.  Any thoughts on how hard would this
> be to implement on VW?
>
> -Carl
>
> On Mar 7, 2006, at 4:32 PM, Alejandro F. Reimondo wrote:
>
>> Hi all,
>>
>> An interesting path to be explored can be the generation
>>  of images inside running images (called image gestation).
>>
>> I have built many images and cross-VM images
>>  (e.g. building new smalltalk 3D ambiences for
>>  entertrainment industry, when we didn´t have
>>  a running VM), resulting in interesting images
>>  from 80kb -for helloWorld on console- to
>>  complete running application environments.
>>
>> The technique start from gestation of a minimum
>>  environment inside a running host; and use the
>>  host´s tools (browsers and inspectors, & automated
>>  nutrition tools) to put methods inside the child image.
>> Then a system tracer is run to dump child image
>>  contents (patching and cutting references to host
>>  image) and doing custom primitive transforms if
>>  required (e.g. when generating cross image development)
>>
>> I have encountered that building images by gestation
>>  is much more easy than shrinking running images;
>>  because you build the image in a constructive
>>  manner (on real running requirements) and not by
>>  reduction.
>>
>> One of the most valuable nutrient tools has been
>>  method tracers that register method activations.
>> They can be used to record the methods requiered
>>  while evaluating an expression in the host image,
>>  and then inject the collected methods (and classes)
>>  onto the child image.
>>
>> More details and samples can be found at
>>  http://www.aleReimondo.com.ar/ImageGestation
>>
>> best,
>> Ale.