Hi Frank,
Yes, but the stripping out part is manual. Well, it's scripted [1], and when a new package becomes unloadable I add it to the script, run ... snip ...
I was thinking about something. Your Stripping script, and any external ".st" script for that matter, should be a one-liner simply to call one single method, rather than having any sort of code with implementation details. One reason for this is so that browsing senders will miss as little as possible due to being externalized in an .st script.
But another reason is because Stripping should be regarded *as valuable* a use-case as Assembling.
There are two scenarios for deploying a minimal production image. The "conventional" way, used by other languages, is to develop the code base in a rich fat image and, when its ready, version it all up and Assemble it manually into a brand new SqueakTrunk image, sans all the richness.
The other way, supported only by Smalltalk, is where I start with a ReleaseSqueakTrunk image (rich and fat) and develop my code and objects until I'm ready to deploy. Instead of being required to hand-assemble a new image I simply Strip the image I'm in and deploy that.
(As I type this e-mail, the merits of Spoons approach continue to woo me. Craig?!)
On 31 July 2013 16:47, Chris Muller asqueaker@gmail.com wrote:
Hi Frank,
Yes, but the stripping out part is manual. Well, it's scripted [1], and when a new package becomes unloadable I add it to the script, run ... snip ...
I was thinking about something. Your Stripping script, and any external ".st" script for that matter, should be a one-liner simply to call one single method, rather than having any sort of code with implementation details. One reason for this is so that browsing senders will miss as little as possible due to being externalized in an .st script.
I'm prepared to be argued over to agreeing with you, which means that at the moment I don't :). The reason is that I don't see a car factory inside my car: the car factory assembles a bunch of bits and gives me a car. (This is one of the things that annoys me about Metacello: I don't want to see ConfigurationOfs in my image.)
But another reason is because Stripping should be regarded *as valuable* a use-case as Assembling.
Definitely at the moment. Much later, I expect people to not be doing much Stripping because there simply won't be much call for it.
Or, put another way, with a strongly modular image you could easily build a near minimal custom image. If you needed to minimise that, sure, you could reach for other tools.
There are two scenarios for deploying a minimal production image. The "conventional" way, used by other languages, is to develop the code base in a rich fat image and, when its ready, version it all up and Assemble it manually into a brand new SqueakTrunk image, sans all the richness.
No. The usual mainstream approach is the opposite: it builds an application up from a bunch of libraries together with your own code to produce a binary. That binary doesn't have an IDE in it, or a debugger, or anything else that I'd expect from a rich fat image.
Stripping is _hard_. Just look at all the Self literature. (My brief Googling has failed me, but I did read an interesting approach in connection with abstract interpretation.) Well. It's very easy to remove things from an image. The problem is removing only the bad bits and leaving the good bits.
The other way, supported only by Smalltalk, is where I start with a ReleaseSqueakTrunk image (rich and fat) and develop my code and objects until I'm ready to deploy. Instead of being required to hand-assemble a new image I simply Strip the image I'm in and deploy that.
(As I type this e-mail, the merits of Spoons approach continue to woo me. Craig?!)
As Eliot put it, Spoon and my packaging work are pushing two different things: Spoon produces _minimal_ images, while I'm trying to produce _modular_ images. If you think of the two processes as vectors, they're _broadly_ in the same direction, but they're not parallel.
frank
Frank Shearar wrote:
I'm prepared to be argued over to agreeing with you, which means that at the moment I don't :). The reason is that I don't see a car factory inside my car: the car factory assembles a bunch of bits and gives me a car. (This is one of the things that annoys me about Metacello: I don't want to see ConfigurationOfs in my image.)
But there is a bacteria factory inside a bacteria :-)
That doesn't mean that I don't prefer Smalltalks that grow (like Smalltalk Express, a.k.a. Smalltalk V/Win) to those you have to strip.
Stripping is _hard_. Just look at all the Self literature. (My brief Googling has failed me, but I did read an interesting approach in connection with abstract interpretation.) Well. It's very easy to remove things from an image. The problem is removing only the bad bits and leaving the good bits.
The automatic approach was based on type inference rather than abstract interpretation:
http://selflanguage.org/documentation/published/gold.html "Sifting Out the Gold: Delivering Compact Applications From an Exploratory Object-Oriented Environment" Ole Agesen and David Ungar
There is also David Ungar's work on the Transporter where users have to manually annotate objects so they can be moved between images. This can be combined with the fact that the Self VM can start with a very minimal "empty world" and bootstrap from a bunch of text files (the text to bytecodes compiler is in the VM instead of the image) to deliver a stripped down system with just the application. But I think that the automatic solution in the above paper is more interesting for this discussion.
-- Jecel
Yes, but the stripping out part is manual. Well, it's scripted [1], and when a new package becomes unloadable I add it to the script, run ... snip ...
I was thinking about something. Your Stripping script, and any external ".st" script for that matter, should be a one-liner simply to call one single method, rather than having any sort of code with implementation details. One reason for this is so that browsing senders will miss as little as possible due to being externalized in an .st script.
I'm prepared to be argued over to agreeing with you, which means that at the moment I don't :). The reason is that I don't see a car factory inside my car: the car factory assembles a bunch of bits and gives me a car. (This is one of the things that annoys me about Metacello: I don't want to see ConfigurationOfs in my image.)
Good luck with that car company. :) A factory with no development tools, and no visibility from the "car", I predict a crash at some point in the near future (pun intended). :)
I guess I regard the the image as both car AND factory. We're dealing with a car that has the ability to mutate from a Cadillac into a Prius, why shouldn't that capability be visible and managed under the same powerful dev tools as everything else?
There are two scenarios for deploying a minimal production image. The "conventional" way, used by other languages, is to develop the code base in a rich fat image and, when its ready, version it all up and Assemble it manually into a brand new SqueakTrunk image, sans all the richness.
No. The usual mainstream approach is the opposite: it builds an application up from a bunch of libraries together with your own code to produce a binary. That binary doesn't have an IDE in it, or a debugger, or anything else that I'd expect from a rich fat image.
That's exactly what I said. "Assemble".
Stripping is _hard_. Just look at all the Self literature. (My brief Googling has failed me, but I did read an interesting approach in connection with abstract interpretation.) Well. It's very easy to remove things from an image. The problem is removing only the bad bits and leaving the good bits.
"Strip" is not a good word because it evokes all the complicated graph-traversal stuff like deploying a "stripped" image from VisualAge. I'm simply talking about large-grained "unloading extranneous packages", which have no bearing on an app, just as you do with your .st script, for the purpose of running in production with a smaller image.
But, I want to be able to TEST my application with a... let's call it "Reduced" image without having to version all code and re-Assemble it into an entirely new image first. Smalltalk embraces the idea of live and continuous evolution of software, and so Reduce will be needed much more often than Assemble.
The other way, supported only by Smalltalk, is where I start with a ReleaseSqueakTrunk image (rich and fat) and develop my code and objects until I'm ready to deploy. Instead of being required to hand-assemble a new image I simply Strip the image I'm in and deploy that.
(As I type this e-mail, the merits of Spoons approach continue to woo me. Craig?!)
As Eliot put it, Spoon and my packaging work are pushing two different things: Spoon produces _minimal_ images, while I'm trying to produce _modular_ images. If you think of the two processes as vectors, they're _broadly_ in the same direction, but they're not parallel.
Maybe you could help me understand -- what is the benefit of "modularity" at the package level?
We all grok the benefit of *functional* modularity -- where individual methods do one and only one thing and individual classes embody a coherent and limited group of related behaviors. This allows programs to be more understandable and upgradeable.
But what is the benefit of *package* modularity? To me, it relates to _image size_ and little else. Less code is easier to understand than more code, it takes up less memory, and probably runs faster.
But besides that, more packages complicates Assembly. And Reduced images are less capable of dealing with bugs due to lack of IDE tools.
So, I guess I don't know what a "modular" image is or why I would want one. My use-cases are I want Rich for development, and Reduced for production. Both Spoon and your "modularisation-of-packages" work seem equally aimed at the latter goal. If not, then for what do I want Modular?
Thanks.
On 1 August 2013 17:07, Chris Muller asqueaker@gmail.com wrote:
Yes, but the stripping out part is manual. Well, it's scripted [1], and when a new package becomes unloadable I add it to the script, run ... snip ...
I was thinking about something. Your Stripping script, and any external ".st" script for that matter, should be a one-liner simply to call one single method, rather than having any sort of code with implementation details. One reason for this is so that browsing senders will miss as little as possible due to being externalized in an .st script.
I'm prepared to be argued over to agreeing with you, which means that at the moment I don't :). The reason is that I don't see a car factory inside my car: the car factory assembles a bunch of bits and gives me a car. (This is one of the things that annoys me about Metacello: I don't want to see ConfigurationOfs in my image.)
Good luck with that car company. :) A factory with no development tools, and no visibility from the "car", I predict a crash at some point in the near future (pun intended). :)
I guess I regard the the image as both car AND factory. We're dealing with a car that has the ability to mutate from a Cadillac into a Prius, why shouldn't that capability be visible and managed under the same powerful dev tools as everything else?
There are two scenarios for deploying a minimal production image. The "conventional" way, used by other languages, is to develop the code base in a rich fat image and, when its ready, version it all up and Assemble it manually into a brand new SqueakTrunk image, sans all the richness.
No. The usual mainstream approach is the opposite: it builds an application up from a bunch of libraries together with your own code to produce a binary. That binary doesn't have an IDE in it, or a debugger, or anything else that I'd expect from a rich fat image.
That's exactly what I said. "Assemble".
Right, sorry. I saw the "develop the code base in a rich fat image" part, and didn't properly register the rest of the sentence.
Stripping is _hard_. Just look at all the Self literature. (My brief Googling has failed me, but I did read an interesting approach in connection with abstract interpretation.) Well. It's very easy to remove things from an image. The problem is removing only the bad bits and leaving the good bits.
"Strip" is not a good word because it evokes all the complicated graph-traversal stuff like deploying a "stripped" image from VisualAge. I'm simply talking about large-grained "unloading extranneous packages", which have no bearing on an app, just as you do with your .st script, for the purpose of running in production with a smaller image.
Come to think of it, I'm not stripping anything. I'm unteasing packages and, when they have no higher level packages depending on them, I'm adding them to the recipe that builds the image.
But, I want to be able to TEST my application with a... let's call it "Reduced" image without having to version all code and re-Assemble it into an entirely new image first. Smalltalk embraces the idea of live and continuous evolution of software, and so Reduce will be needed much more often than Assemble.
Well, of course, you need to do precisely that, and for good reason: how can you otherwise be confident that the thing you _think_ you built is the thing you _intended_ to build?
Live and continuous evolution of software is orthogonal to modularity. You can get far without it. And having it doesn't mean you stop evolving.
The other way, supported only by Smalltalk, is where I start with a ReleaseSqueakTrunk image (rich and fat) and develop my code and objects until I'm ready to deploy. Instead of being required to hand-assemble a new image I simply Strip the image I'm in and deploy that.
(As I type this e-mail, the merits of Spoons approach continue to woo me. Craig?!)
As Eliot put it, Spoon and my packaging work are pushing two different things: Spoon produces _minimal_ images, while I'm trying to produce _modular_ images. If you think of the two processes as vectors, they're _broadly_ in the same direction, but they're not parallel.
Maybe you could help me understand -- what is the benefit of "modularity" at the package level?
We all grok the benefit of *functional* modularity -- where individual methods do one and only one thing and individual classes embody a coherent and limited group of related behaviors. This allows programs to be more understandable and upgradeable.
But what is the benefit of *package* modularity? To me, it relates to _image size_ and little else. Less code is easier to understand than more code, it takes up less memory, and probably runs faster.
It relates to libraries. Think of a package as providing some kind of library, like openssl does. Do you care about openssl's internal architecture? Of course not. But without packages you can't even tell where one thing starts and another ends. Initially independent systems grow roots into each other until they become inseparable. Once they're inseparable, they're less useful, because you can't choose one or the other.
But besides that, more packages complicates Assembly. And Reduced images are less capable of dealing with bugs due to lack of IDE tools.
More packages complicates assembly? Maybe, but at a sublinear rate: you don't care about the parts that make up my package.
I don't intend for people to _work_ in reduced images. That's why I've taken such pains to have a ReleaseSqueakTrunk so people still get the big box of toys. It's just that the toys are actually separable.
So, I guess I don't know what a "modular" image is or why I would want one. My use-cases are I want Rich for development, and Reduced for production. Both Spoon and your "modularisation-of-packages" work seem equally aimed at the latter goal. If not, then for what do I want Modular?
So perhaps an analogy. The Squeak image is a bowl of ramen. It has bits of pork (because that's my favourite kind of ramen), noodles, soup, leaves. How do you know where one noodle starts and another ends? They're tangled together. You pull on an ingredient, and hope (because this is a highly dynamic, highly reflective environment) that when you start pulling on that loose noodle end you don't end up trying to cram the entire bowlful of ramen in your mouth.
Spoon's approach is to use a bunch of chopsticks, spear the pork, tape the chopsticks to the side of the bowl, and upend the bowl. Only the speared bits stay behind. You have a minimal bowl.
What modularity does is not give you a bowl of ramen. It gives you a collection of bowls, each of which holds one of the ingredients. If you don't like pork, you don't put any pork in the bowl. (Perhaps a helpful restaurant will pre-assemble these ingredients into a selection of tasty meals!)
Modularity lets you put fences (to switch analogies) around parts of the code such that you can understand the system as a whole that much more simply. "This uses Tools, and System, and Collections. And Kernel, of course."
So modularity exposes the high level structure of the image. Knowing that is very useful in understanding the image!
Thanks.
Sure! I hope I've shed some light on the issue.
frank
On 8/1/13, Frank Shearar frank.shearar@gmail.com wrote:
On 1 August 2013 17:07, Chris Muller asqueaker@gmail.com wrote:
Yes, but the stripping out part is manual. Well, it's scripted [1], and when a new package becomes unloadable I add it to the script, run ... snip ...
I was thinking about something. Your Stripping script, and any external ".st" script for that matter, should be a one-liner simply to call one single method, rather than having any sort of code with implementation details. One reason for this is so that browsing senders will miss as little as possible due to being externalized in an .st script.
I'm prepared to be argued over to agreeing with you, which means that at the moment I don't :). The reason is that I don't see a car factory inside my car: the car factory assembles a bunch of bits and gives me a car. (This is one of the things that annoys me about Metacello: I don't want to see ConfigurationOfs in my image.)
Good luck with that car company. :) A factory with no development tools, and no visibility from the "car", I predict a crash at some point in the near future (pun intended). :)
I guess I regard the the image as both car AND factory. We're dealing with a car that has the ability to mutate from a Cadillac into a Prius, why shouldn't that capability be visible and managed under the same powerful dev tools as everything else?
There are two scenarios for deploying a minimal production image. The "conventional" way, used by other languages, is to develop the code base in a rich fat image and, when its ready, version it all up and Assemble it manually into a brand new SqueakTrunk image, sans all the richness.
No. The usual mainstream approach is the opposite: it builds an application up from a bunch of libraries together with your own code to produce a binary. That binary doesn't have an IDE in it, or a debugger, or anything else that I'd expect from a rich fat image.
That's exactly what I said. "Assemble".
Right, sorry. I saw the "develop the code base in a rich fat image" part, and didn't properly register the rest of the sentence.
Stripping is _hard_. Just look at all the Self literature. (My brief Googling has failed me, but I did read an interesting approach in connection with abstract interpretation.) Well. It's very easy to remove things from an image. The problem is removing only the bad bits and leaving the good bits.
"Strip" is not a good word because it evokes all the complicated graph-traversal stuff like deploying a "stripped" image from VisualAge. I'm simply talking about large-grained "unloading extranneous packages", which have no bearing on an app, just as you do with your .st script, for the purpose of running in production with a smaller image.
Come to think of it, I'm not stripping anything. I'm unteasing packages and, when they have no higher level packages depending on them, I'm adding them to the recipe that builds the image.
But, I want to be able to TEST my application with a... let's call it "Reduced" image without having to version all code and re-Assemble it into an entirely new image first. Smalltalk embraces the idea of live and continuous evolution of software, and so Reduce will be needed much more often than Assemble.
Well, of course, you need to do precisely that, and for good reason: how can you otherwise be confident that the thing you _think_ you built is the thing you _intended_ to build?
Live and continuous evolution of software is orthogonal to modularity. You can get far without it. And having it doesn't mean you stop evolving.
The other way, supported only by Smalltalk, is where I start with a ReleaseSqueakTrunk image (rich and fat) and develop my code and objects until I'm ready to deploy. Instead of being required to hand-assemble a new image I simply Strip the image I'm in and deploy that.
(As I type this e-mail, the merits of Spoons approach continue to woo me. Craig?!)
As Eliot put it, Spoon and my packaging work are pushing two different things: Spoon produces _minimal_ images, while I'm trying to produce _modular_ images. If you think of the two processes as vectors, they're _broadly_ in the same direction, but they're not parallel.
Maybe you could help me understand -- what is the benefit of "modularity" at the package level?
We all grok the benefit of *functional* modularity -- where individual methods do one and only one thing and individual classes embody a coherent and limited group of related behaviors. This allows programs to be more understandable and upgradeable.
WHAT ARE THE BENEFITS OF PACKAGE MODULARITY?
But what is the benefit of *package* modularity? To me, it relates to _image size_ and little else. Less code is easier to understand than more code, it takes up less memory, and probably runs faster.
It relates to libraries. Think of a package as providing some kind of library, like openssl does. Do you care about openssl's internal architecture? Of course not. But without packages you can't even tell where one thing starts and another ends. Initially independent systems grow roots into each other until they become inseparable. Once they're inseparable, they're less useful, because you can't choose one or the other.
+1 And work on it independently.
But besides that, more packages complicates Assembly. And Reduced images are less capable of dealing with bugs due to lack of IDE tools.
More packages complicates assembly? Maybe, but at a sublinear rate: you don't care about the parts that make up my package.
I don't intend for people to _work_ in reduced images. That's why I've taken such pains to have a ReleaseSqueakTrunk so people still get the big box of toys. It's just that the toys are actually separable.
So, I guess I don't know what a "modular" image is or why I would want one. My use-cases are I want Rich for development, and Reduced for production. Both Spoon and your "modularisation-of-packages" work seem equally aimed at the latter goal. If not, then for what do I want Modular?
So perhaps an analogy. The Squeak image is a bowl of ramen. It has bits of pork (because that's my favourite kind of ramen), noodles, soup, leaves. How do you know where one noodle starts and another ends? They're tangled together. You pull on an ingredient, and hope (because this is a highly dynamic, highly reflective environment) that when you start pulling on that loose noodle end you don't end up trying to cram the entire bowlful of ramen in your mouth.
Spoon's approach is to use a bunch of chopsticks, spear the pork, tape the chopsticks to the side of the bowl, and upend the bowl. Only the speared bits stay behind. You have a minimal bowl.
What modularity does is not give you a bowl of ramen. It gives you a collection of bowls, each of which holds one of the ingredients. If you don't like pork, you don't put any pork in the bowl. (Perhaps a helpful restaurant will pre-assemble these ingredients into a selection of tasty meals!)
Modularity lets you put fences (to switch analogies) around parts of the code such that you can understand the system as a whole that much more simply. "This uses Tools, and System, and Collections. And Kernel, of course."
So modularity exposes the high level structure of the image. Knowing that is very useful in understanding the image!
Thanks.
Sure! I hope I've shed some light on the issue.
frank
WHAT ARE THE BENEFITS OF PACKAGE MODULARITY?
Yeah, pretty dumb question. I realized that when I read your answers. I'm still interested, though, about the cases which are supported by Assemble vs. the cases which are supported by Reduce.
Frank, I about busted a gut (LOL!!) with the Ramen analogy. Good one. :D
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Frank Shearar -
H. Hirzel -
Jecel Assumpcao Jr.