In C, if I need the sine function then I include the math library
and use the sine function where needed. The compiler (linker
actually) insures that
the sine function is included in my binary but that nothing else from
the math
library gets included. [I am assuming no dynamicly linked libraries
here.]
Compared to Smalltalk this is very efficient since it helps keep by
binary small.

In the versions of Smalltalk I know, the situation is rather
different. If I need a method
from some package then I include the package in my image and use the
method.
The difference is that there is no linker to discard all the
components from the
package that I don't use. Furthermore, because of the dynamic nature

"Ralph" == Ralph Boland <rpboland at (no spam) gmail.com> writes:

"Ralph" == Ralph Boland <rpbol... at (no spam) gmail.com> writes:

Ralph> In the versions of Smalltalk I know, the situation is rather different.
Ralph> If I need a method from some package then I include the package in my
Ralph> image and use the method.  The difference is that there is no linker to
Ralph> discard all the components from the package that I don't use.
Ralph> Furthermore, because of the dynamic nature of Smalltalk, it is much
Ralph> more difficult for there to be a linker like facility to recognize the
Ralph> unused components of the package and not load them into the image.
Ralph> Thus a Smalltalk image can contain many unused methods which bloat the
Ralph> image.

What is the "Smalltalk [you] know"?  Most modern versions of Smalltalk have an
"image stripper" that reduces an image down to just what needs to be present
to deploy.

The first question I'd ask - and I'm being serious, not mean - is
this:

"Why do you care?"

To explain: neither disk space, memory, or bandwidth are limited in
the ways they were 10 years ago (or indeed, even 5 years ago).  I have
4 gb of memory and 250 gb of disk on the 2 year old macbook pro I'm
typing on; given such systems, it hardly seems worth it to worry about
a few hundred kbytes of library code being loaded extraneously.

...

True, if you're thinking of a single image.
In a multi-image Seaside server deployment, reducing each image's
memory footprint is useful.

Building a runtime image is one thing that VA Smalltalk does very
well.  Our runtime images are about 6 mb.

On Aug 4, 7:35 am, jarober <jaro... at (no spam) gmail.com> wrote:> The first question I'd ask - and I'm being serious, not mean - is
this:

"Why do you care?"

To explain: neither disk space, memory, or bandwidth are limited in
the ways they were 10 years ago (or indeed, even 5 years ago).  I have
4 gb of memory and 250 gb of disk on the 2 year old macbook pro I'm
typing on; given such systems, it hardly seems worth it to worry about
a few hundred kbytes of library code being loaded extraneously.

...

Using Runtime Packager, I can achieve the same thing with VisualWorks
or ObjectStudio.  However, I've personally stopped using them - the
pain is too high, and the gain too small.

YMMV, of course.

On Aug 4, 9:47 am, Bohdan <bne... at (no spam) gmail.com> wrote:



True, if you're thinking of a single image.
In a multi-image Seaside server deployment, reducing each image's
memory footprint is useful.

Building a runtime image is one thing that VA Smalltalk does very
well.  Our runtime images are about 6 mb.

On Aug 4, 7:35 am, jarober <jaro... at (no spam) gmail.com> wrote:> The first question I'd ask - and I'm being serious, not mean - is
this:

"Why do you care?"

To explain: neither disk space, memory, or bandwidth are limited in
the ways they were 10 years ago (or indeed, even 5 years ago).  I have
4 gb of memory and 250 gb of disk on the 2 year old macbook pro I'm
typing on; given such systems, it hardly seems worth it to worry about
a few hundred kbytes of library code being loaded extraneously.

...

To be fair, VSE had SLL's as early as 1994 or so, and VW has had
parcels since 1995. This isn't any kind of radically new feature for
Smalltalk.

On Aug 4, 1:02 pm, "Frank Lesser [LSW]" <frank-les... at (no spam) lesser-
software.com> wrote:
We are working in the Beta version of DNG that will use a new concept of
SLLs, which will be explained in detail at the DNG event in Tarivisio in
September.

In the versions of Smalltalk I know, the situation is rather
different.