Imagine this.
You select one or various categories and "Intelligent Shrink" browse all the image searching all the objects thath the selected categories uses. If a categorie is not use or not will use it for our selected categories then erase it.
Example: I create a "set" of objects, and use objects from Kernel, Morphic etc.. But no object uses Monticello. Then, "Intelligent Shrink" may delete all Monticello's class not used.
Is this possible on Squeak?
Cheers.
Hi!
Imagine this.
You select one or various categories and "Intelligent Shrink" browse all the image searching all the objects thath the selected categories uses. If a categorie is not use or not will use it for our selected categories then erase it.
Example: I create a "set" of objects, and use objects from Kernel, Morphic etc.. But no object uses Monticello. Then, "Intelligent Shrink" may delete all Monticello's class not used.
Is this possible on Squeak?
I guess there are a whole bunch of ways to do such an analysis (that is more or less probably to be correct), MudPie springs to mind of course.
Can't give you an SM-link right now because the nameservers for squeak.org seems to be unreachable right now - have no idea. I can't verify if SM is up or down because I don't have the IP of squeak.org in my head.
regards, Göran
I don't know if others thinks like me, but I think something like this could be intereseting for prepare a ready for end-users image (without 70MB of size)
Something like this could have "don't delete develop tools" for example, but all the packages don't used, disappear from this image.
En Thu, 22 Feb 2007 12:47:12 +0100, Göran Krampe goran@krampe.se escribió:
Hi!
Imagine this.
You select one or various categories and "Intelligent Shrink" browse all the image searching all the objects thath the selected categories uses. If a categorie is not use or not will use it for our selected categories then erase it.
Example: I create a "set" of objects, and use objects from Kernel, Morphic etc.. But no object uses Monticello. Then, "Intelligent Shrink" may delete all Monticello's class not used.
Is this possible on Squeak?
I guess there are a whole bunch of ways to do such an analysis (that is more or less probably to be correct), MudPie springs to mind of course.
Can't give you an SM-link right now because the nameservers for squeak.org seems to be unreachable right now - have no idea. I can't verify if SM is up or down because I don't have the IP of squeak.org in my head.
regards, Göran
Hi,
I played with this idea of automatical image segmentation but the fastest, safest and maybe the only possible way now is to do that all by hand. The better way to create specialized images is IMHO from bottom. So we should simply continue in started modularization and packaging effort.
Cheers, -- Pavel
On 2/22/07, Giuseppe Luigi Punzi glpunzi@zyoconsulting.com wrote:
I don't know if others thinks like me, but I think something like this could be intereseting for prepare a ready for end-users image (without 70MB of size)
Something like this could have "don't delete develop tools" for example, but all the packages don't used, disappear from this image.
En Thu, 22 Feb 2007 12:47:12 +0100, Göran Krampe goran@krampe.se escribió:
Hi!
Imagine this.
You select one or various categories and "Intelligent Shrink" browse all the image searching all the objects thath the selected categories uses. If a categorie is not use or not will use it for our selected categories then erase it.
Example: I create a "set" of objects, and use objects from Kernel, Morphic etc.. But no object uses Monticello. Then, "Intelligent Shrink" may delete all Monticello's class not used.
Is this possible on Squeak?
I guess there are a whole bunch of ways to do such an analysis (that is more or less probably to be correct), MudPie springs to mind of course.
Can't give you an SM-link right now because the nameservers for squeak.org seems to be unreachable right now - have no idea. I can't verify if SM is up or down because I don't have the IP of squeak.org in my head.
regards, Göran
-- Giuseppe Luigi Punzi - Consultor
:: ZYO Consulting ::email: glpunzi@zyoconsulting.com tlfno: +34 675 145 912 web: http://www.zyoconsulting.co
Fast or not is not a problem. This could be for run once.
Otherwise, if 3.10 will work all with modules, this is not needed.
En Thu, 22 Feb 2007 13:05:20 +0100, Pavel Krivanek squeak1@continentalbrno.cz escribió:
Hi,
I played with this idea of automatical image segmentation but the fastest, safest and maybe the only possible way now is to do that all by hand. The better way to create specialized images is IMHO from bottom. So we should simply continue in started modularization and packaging effort.
Cheers, -- Pavel
On 2/22/07, Giuseppe Luigi Punzi glpunzi@zyoconsulting.com wrote:
I don't know if others thinks like me, but I think something like this could be intereseting for prepare a ready for end-users image (without 70MB of size)
Something like this could have "don't delete develop tools" for example, but all the packages don't used, disappear from this image.
En Thu, 22 Feb 2007 12:47:12 +0100, Göran Krampe goran@krampe.se escribió:
Hi!
Imagine this.
You select one or various categories and "Intelligent Shrink" browse
all
the image searching all the objects thath the selected categories
uses.
If a categorie is not use or not will use it for our selected categories then erase it.
Example: I create a "set" of objects, and use objects from Kernel, Morphic etc.. But no object uses Monticello. Then, "Intelligent Shrink" may delete
all
Monticello's class not used.
Is this possible on Squeak?
I guess there are a whole bunch of ways to do such an analysis (that
is
more or less probably to be correct), MudPie springs to mind of
course.
Can't give you an SM-link right now because the nameservers for squeak.org seems to be unreachable right now - have no idea. I can't verify if
SM is
up or down because I don't have the IP of squeak.org in my head.
regards, Göran
-- Giuseppe Luigi Punzi - Consultor
:: ZYO Consulting ::email: glpunzi@zyoconsulting.com tlfno: +34 675 145 912 web: http://www.zyoconsulting.co
On 22-Feb-07, at 4:05 AM, Pavel Krivanek wrote:
Hi,
I played with this idea of automatical image segmentation but the fastest, safest and maybe the only possible way now is to do that all by hand. The better way to create specialized images is IMHO from bottom.
Consider also 'Spoon'. Start from almost nothing, add what you need, provide a mechanism to add on the fly. If you're really sure what you want, disable that last item.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Close your eyes and press escape three times.
On Thu, 22 Feb 2007 17:42:52 +0100, tim Rowledge wrote:
On 22-Feb-07, at 4:05 AM, Pavel Krivanek wrote:
Hi,
I played with this idea of automatical image segmentation but the fastest, safest and maybe the only possible way now is to do that all by hand. The better way to create specialized images is IMHO from bottom.
Consider also 'Spoon'. Start from almost nothing, add what you need, provide a mechanism to add on the fly. If you're really sure what you want, disable that last item.
Yeah, I would really like to see Spoon applied to Giuseppe's needs, just to learn what comes out.
/Klaus
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Close your eyes and press escape three times.
"Spoon way" is the oposite to "Intelligent Shrink" ideas.
Spoon Way = Add all as you want. IS = Erase all you don't need.
As I said, If 3.10 will work with modules, and you can start with a basic (basic=minimun for start and add packages) image and add all you need, then this is unnecesary.
This could be usefull if you don't want to have Developer Utilitys on the image for end users (as LockDown packages do, but this package, disable it, not delete it. I have better ideas for lockdown package, but this is other story).
En Thu, 22 Feb 2007 18:14:03 +0100, Klaus D. Witzel klaus.witzel@cobss.com escribió:
On Thu, 22 Feb 2007 17:42:52 +0100, tim Rowledge wrote:
On 22-Feb-07, at 4:05 AM, Pavel Krivanek wrote:
Hi,
I played with this idea of automatical image segmentation but the fastest, safest and maybe the only possible way now is to do that all by hand. The better way to create specialized images is IMHO from bottom.
Consider also 'Spoon'. Start from almost nothing, add what you need, provide a mechanism to add on the fly. If you're really sure what you want, disable that last item.
Yeah, I would really like to see Spoon applied to Giuseppe's needs, just to learn what comes out.
/Klaus
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Close your eyes and press escape three times.
Hi Giuseppe--
"Spoon way" is the oposite to "Intelligent Shrink" ideas.
Spoon Way = Add all as you want. IS = Erase all you don't need.
But of course the starting point for Spoon was produced by erasing everything that isn't needed (in this case, everything that isn't needed to start and extend the system). That's *exactly* what you're talking about, and it's provably correct. I encourage everyone to re-read the progress reports in the Spoon archives[1], starting at [2] is probably best. I have written about this at length.
thanks,
-C
[1] http://lists.squeakfoundation.org/pipermail/spoon [2] http://tinyurl.com/2gbext (lists.squeakfoundation.org)
El 2/22/07 3:03 PM, "Craig Latta" craig@netjam.org escribió:
But of course the starting point for Spoon was produced by erasing everything that isn't needed (in this case, everything that isn't needed to start and extend the system). That's *exactly* what you're talking about, and it's provably correct. I encourage everyone to re-read the progress reports in the Spoon archives[1], starting at [2] is probably best. I have written about this at length.
thanks,
This is fine to watch thing, for learn a lot of. When I began to play in shrinking business, Craig was one of my inspirers.
And if someone take some time, could found "Fenix" , Alejandro Reimondo complete 3.2 system for made micro images from one what continue running, don't is destroyed, etc.
Still smaller 2+2 and exit image.
From here and documentation what in some moment Jecel point, I learn the
"mother and child" idea.
You could have the big image what have all tools you wish "Mother" and the small image what you wish.
But child grows , eventually.
Edgar
__________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas
From: "Giuseppe Luigi Punzi" glpunzi@zyoconsulting.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: "Inteligent" Shrink? Date: Thu, 22 Feb 2007 18:23:26 +0100
"Spoon way" is the oposite to "Intelligent Shrink" ideas.
Spoon Way = Add all as you want. IS = Erase all you don't need.
As I said, If 3.10 will work with modules, and you can start with a basic (basic=minimun for start and add packages) image and add all you need, then this is unnecesary.
I disagree with this. I would always want an "Intelligent Shrink" because I prefer to work with an image that has everything in, but if I were to make something to deploy to an end user I would want to break out just the app I am giving them. And I don't want to do that manually.
_________________________________________________________________ Refi Now: Rates near 39yr lows! $430,000 Mortgage for $1,399/mo - Calculate new payment http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-17727&moid=7...
Hi JJ,
J J escribió:
From: "Giuseppe Luigi Punzi" glpunzi@zyoconsulting.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: "Inteligent" Shrink? Date: Thu, 22 Feb 2007 18:23:26 +0100
"Spoon way" is the oposite to "Intelligent Shrink" ideas.
Spoon Way = Add all as you want. IS = Erase all you don't need.
As I said, If 3.10 will work with modules, and you can start with a basic (basic=minimun for start and add packages) image and add all you need, then this is unnecesary.
I disagree with this. I would always want an "Intelligent Shrink" because I prefer to work with an image that has everything in, but if I were to make something to deploy to an end user I would want to break out just the app I am giving them. And I don't want to do that manually.
Well, you are right.
There are some page on the swiki or other web where you can share ideas or bountys?. For example, I (and others as I can see) would like something like this, but I don't have the experience for do it.
Cheers.
On Sun, 25 Feb 2007 23:43:18 +0100, Giuseppe Luigi Punzi wrote:
Hi JJ,
J J escribió:
From: "Giuseppe Luigi Punzi" glpunzi@zyoconsulting.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: "Inteligent" Shrink? Date: Thu, 22 Feb 2007 18:23:26 +0100
"Spoon way" is the oposite to "Intelligent Shrink" ideas.
Spoon Way = Add all as you want. IS = Erase all you don't need.
As I said, If 3.10 will work with modules, and you can start with a basic (basic=minimun for start and add packages) image and add all you need, then this is unnecesary.
I disagree with this. I would always want an "Intelligent Shrink" because I prefer to work with an image that has everything in, but if I were to make something to deploy to an end user I would want to break out just the app I am giving them. And I don't want to do that manually.
Well, you are right.
There are some page on the swiki or other web where you can share ideas or bountys?. For example, I (and others as I can see) would like something like this, but I don't have the experience for do it.
You might want to look at an existing class (invented by Ted Kaehler),
- http://ftp.squeak.org/1.23/1.22-1.23%20FileIns/SystemTracer.st
HTH.
/Klaus
Cheers.
Given the current state of things, it is important to have tools for shrinking. I've been programming in Smalltalk for 20 years, and I've seen lots of different tools. My conclusion is that the "shrinking" model is flawed, and it would be better to focus on making Squeak "growable".
If you develop in an image and have no way of getting all your code out of an image then you are in trouble. Images are fragile. You can't merge images. If you want to give your code to someone else, or if they want to give it to you, one of you has to move code out of the image and give it to someone else. So, it is important to keep your code in files, whether as .cs files or in Monticello.
If your code is in files, there is no argument against growing an image. Sure, you will develop in a huge "dev" image. But it is built out of components and many of those components are not used by your application. It is a lot easier to shrink a build script than to shrink an image. You could have a tool that automatically shrinks your build script by deleting packages one by one and seeing if your application still runs all its tests.
Shrinking an image is hard work and not for the faint of heart. I always tell my students to build their application first and worry about shrinking at the end. That is because they will be a lot better at Smalltalk at the end of the project than at the beginning, and so they will be better able to learn to shrink their image.
-Ralph
Having packaged Smalltalk apps in the past, I agree with this, and would remind people that the whole "shrink" metaphor arose out of commercial goals -- that is, in order to deploy a Smalltalk "application" built on a proprietary platform you needed to remove the compiler and development tools to comply with a vendor's license. Since Squeak does not have such licensing issues for deployment, the whole "shrink" idea is obsolete IMHO.
Why take a perfectly working application and start potentially introducing all sorts of random errors into it at the last minute just to save a bit of storage space and network bandwidth (especially these days)? And if storage space and bandwidth does matter in your situation even now, then building up from a small base (including a text based one) is a much more reliable way to produce quality deployable applications.
--Paul Fernhout
Ralph Johnson wrote:
Given the current state of things, it is important to have tools for shrinking. I've been programming in Smalltalk for 20 years, and I've seen lots of different tools. My conclusion is that the "shrinking" model is flawed, and it would be better to focus on making Squeak "growable".
If you develop in an image and have no way of getting all your code out of an image then you are in trouble. Images are fragile. You can't merge images. If you want to give your code to someone else, or if they want to give it to you, one of you has to move code out of the image and give it to someone else. So, it is important to keep your code in files, whether as .cs files or in Monticello.
If your code is in files, there is no argument against growing an image. Sure, you will develop in a huge "dev" image. But it is built out of components and many of those components are not used by your application. It is a lot easier to shrink a build script than to shrink an image. You could have a tool that automatically shrinks your build script by deleting packages one by one and seeing if your application still runs all its tests.
Shrinking an image is hard work and not for the faint of heart. I always tell my students to build their application first and worry about shrinking at the end. That is because they will be a lot better at Smalltalk at the end of the project than at the beginning, and so they will be better able to learn to shrink their image.
On Mon, 26 Feb 2007 11:26:07 -0800, Paul D. Fernhout pdfernhout@kurtz-fernhout.com wrote:
Why take a perfectly working application and start potentially introducing all sorts of random errors into it at the last minute just to save a bit of storage space and network bandwidth (especially these days)?
Security?
A good question, but if you are serious about security, a much more secure system is going to come from building a system up (especially up from a textual description), and understanding what each component you include does, and testing all their interactions, rather than just accepting what results from some random shrink command that may or may not remove code with various security problems. Security is not an add-on -- if you want a secure application, the idea of security needs to be woven throughout everything you do -- initial image or source, code development processes, deployment approach, update streams, and so on.
--Paul Fernhout
Blake wrote:
On Mon, 26 Feb 2007 11:26:07 -0800, Paul D. Fernhout pdfernhout@kurtz-fernhout.com wrote:
Why take a perfectly working application and start potentially introducing all sorts of random errors into it at the last minute just to save a bit of storage space and network bandwidth (especially these days)?
Security?
On Mon, 26 Feb 2007 12:21:07 -0800, Paul D. Fernhout pdfernhout@kurtz-fernhout.com wrote:
A good question, but if you are serious about security, a much more secure system is going to come from building a system up (especially up from a textual description), and understanding what each component you include does, and testing all their interactions, rather than just accepting what results from some random shrink command that may or may not remove code with various security problems. Security is not an add-on -- if you want a secure application, the idea of security needs to be woven throughout everything you do -- initial image or source, code development processes, deployment approach, update streams, and so on.
Perhaps I had not followed closely enough the discussion, but I thought we were talking about options in the absence of being able to grow from nothing. So:
Why take a perfectly working application and start potentially introducing all sorts of random errors into it at the last minute just to save a bit of storage space and network bandwidth (especially these days)?
I thought you were offering the option of:
a) Leave all code in. b) Shrink, causing potential problems.
In which case, (b) is, if not more secure, easier to check, presumably. If we have another option:
c) Build, adding only what's needed.
Well, sure, I'll take (c). But I don't think we can ever escape (b) entirely, since our development image includes all our development tools, as opposed to simply being created by them. In fact, I wonder if that wouldn't resolve some issues: Having a development image which is used to build on a target image.
===Blake===
Blake wrote:
On Mon, 26 Feb 2007 11:26:07 -0800, Paul D. Fernhout pdfernhout@kurtz-fernhout.com wrote:
Why take a perfectly working application and start potentially introducing all sorts of random errors into it at the last minute just to save a bit of storage space and network bandwidth (especially these days)?
Security?
There is hardly any goal for which shrinking is a more decidedly unsuited approach than security. While it may be possible to plug a few holes that way (which is probably what you were thinking, e.g., "remove the dangerous code" somehow) a truly secure system is one that never had that dangerous code in the first place, e.g., was built without it.
The main problem with shrinking is that it's usually not predictable, e.g., driven by some sort of heuristics like messages not sent anywhere, and unless you unload entire modules (in which case shrinking is effectively equivalent to building the system from scratch [*1]) a non-predictable result is about the worst thing one can imagine for a secure system.
[*1] Except for side-effects which is another reason for building it from scratch instead of shrinking - that "dangerous" code may leave artifacts in the image even after it has been unloaded.
Cheers, - Andreas
On Mon, 26 Feb 2007 12:27:03 -0800, Andreas Raab andreas.raab@gmx.de wrote:
There is hardly any goal for which shrinking is a more decidedly unsuited approach than security. While it may be possible to plug a few holes that way (which is probably what you were thinking, e.g., "remove the dangerous code" somehow) a truly secure system is one that never had that dangerous code in the first place, e.g., was built without it.
As I said to Paul, I thought the discussion had already remoevd building-from-scratch as an option, and the question was, "Given the vast bandwidth and disk space we all have, why bother with shrinking at all?"
Blake wrote:
On Mon, 26 Feb 2007 12:27:03 -0800, Andreas Raab andreas.raab@gmx.de wrote:
There is hardly any goal for which shrinking is a more decidedly unsuited approach than security. While it may be possible to plug a few holes that way (which is probably what you were thinking, e.g., "remove the dangerous code" somehow) a truly secure system is one that never had that dangerous code in the first place, e.g., was built without it.
As I said to Paul, I thought the discussion had already remoevd building-from-scratch as an option, and the question was, "Given the vast bandwidth and disk space we all have, why bother with shrinking at all?"
And the above is the answer: If security is your goal, don't bother shrinking. It's not worth it. Rather than shrinking, rethink your lines of defense and which threat model you need to defend against and how. Which can of course include the removal of certain methods or classes but you are then no longer randomly "shrinking" but rather performing an explicit process of securing your image against attacks which has much more in common with building it up, since it has explicit goals and isn't one of them "oh, lemme see if I can just remove this class" approaches.
[BTW, I think there is some confusion with various posters what "shrinking" means. For me it is the process of applying a heuristic to determine which classes and methods can be removed. In other words, it is NOT a process where a developer decides explicitly what gets removed, which is why there is a certain amount of unpredictability and randomness to it].
Cheers, - Andreas
On Mon, 26 Feb 2007 13:51:08 -0800, Andreas Raab andreas.raab@gmx.de wrote:
[BTW, I think there is some confusion with various posters what "shrinking" means. For me it is the process of applying a heuristic to determine which classes and methods can be removed. In other words, it is NOT a process where a developer decides explicitly what gets removed, which is why there is a certain amount of unpredictability and randomness to it].
You're correct. I don't know that I'd trust an algorithm to do it. In fact, I'm rather sure I wouldn't.
Andreas Raab wrote:
[BTW, I think there is some confusion with various posters what "shrinking" means. For me it is the process of applying a heuristic to determine which classes and methods can be removed. In other words, it is NOT a process where a developer decides explicitly what gets removed, which is why there is a certain amount of unpredictability and randomness to it].
So the inverse conclusion is that if a developer writes an application there is "a certain amount of unpredictability and randomness to it" what it actually contains?
No wonder we have so many bugs in our programs ;-)
Michael
From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: "Inteligent" Shrink? Date: Mon, 26 Feb 2007 13:51:08 -0800
[BTW, I think there is some confusion with various posters what "shrinking" means. For me it is the process of applying a heuristic to determine which classes and methods can be removed. In other words, it is NOT a process where a developer decides explicitly what gets removed, which is why there is a certain amount of unpredictability and randomness to it].
For me, the term "shrinking" is what Dolphin does to generate a windows app from a package in the image. I'm not sure how the dependencies are determined, but there is a dependency pane in the browser that shows you what classes your package depends on. You can manually add more if you need to, do scripts and things. But I guess the key point is, you know what is going to happen when you press the "shrink" button: everything not in the package or the dependencies list will not be written into the next EXE.
_________________________________________________________________ Win a Zunemake MSN® your homepage for your chance to win! http://homepage.msn.com/zune?icid=hmetagline
The idea isn't obsolete at all. Look at many of the major applications from Squeak: all slimmed down versions of Squeak and in some cases you wouldn't even realize it was Squeak if you didn't know what to look for.
And I don't understand all the talk about it being so hard to do. Dolphin does it and it works wonderfully afaik.
The bottom line is, Linux and (I think) Mac are a market that is open for someone who can build GUI applications very quickly. Who ever can make the nicest apps the fastest will win these markets. But if you come thumping the blue book saying "stand alone apps are obsolete, just use the image" then don't even waste your time.
If Alan Kay's new project works out maybe this will change some-what, but for the existing OS'es, deployed applications will be stand alone if they want any acceptance.
From: "Paul D. Fernhout" pdfernhout@kurtz-fernhout.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: "Inteligent" Shrink? Date: Mon, 26 Feb 2007 14:26:07 -0500
Having packaged Smalltalk apps in the past, I agree with this, and would remind people that the whole "shrink" metaphor arose out of commercial goals -- that is, in order to deploy a Smalltalk "application" built on a proprietary platform you needed to remove the compiler and development tools to comply with a vendor's license. Since Squeak does not have such licensing issues for deployment, the whole "shrink" idea is obsolete IMHO.
Why take a perfectly working application and start potentially introducing all sorts of random errors into it at the last minute just to save a bit of storage space and network bandwidth (especially these days)? And if storage space and bandwidth does matter in your situation even now, then building up from a small base (including a text based one) is a much more reliable way to produce quality deployable applications.
--Paul Fernhout
Ralph Johnson wrote:
Given the current state of things, it is important to have tools for shrinking. I've been programming in Smalltalk for 20 years, and I've seen lots of different tools. My conclusion is that the "shrinking" model is flawed, and it would be better to focus on making Squeak "growable".
If you develop in an image and have no way of getting all your code out of an image then you are in trouble. Images are fragile. You can't merge images. If you want to give your code to someone else, or if they want to give it to you, one of you has to move code out of the image and give it to someone else. So, it is important to keep your code in files, whether as .cs files or in Monticello.
If your code is in files, there is no argument against growing an image. Sure, you will develop in a huge "dev" image. But it is built out of components and many of those components are not used by your application. It is a lot easier to shrink a build script than to shrink an image. You could have a tool that automatically shrinks your build script by deleting packages one by one and seeing if your application still runs all its tests.
Shrinking an image is hard work and not for the faint of heart. I always tell my students to build their application first and worry about shrinking at the end. That is because they will be a lot better at Smalltalk at the end of the project than at the beginning, and so they will be better able to learn to shrink their image.
_________________________________________________________________ With tax season right around the corner, make sure to follow these few simple tips. http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.a...
I agree And what is an image if not a clever cache. So why the following scenario would not work (dave thomas was describing it somehow at ESUG in 2002 ) and dave simmons S# was basically it (certainly GNU Smalltalk bootstrap too): - have a tiny core - load the packages from a script - save your cache
to deploy remove the tools and other development packages.
On 26 févr. 07, at 13:18, Ralph Johnson wrote:
Given the current state of things, it is important to have tools for shrinking. I've been programming in Smalltalk for 20 years, and I've seen lots of different tools. My conclusion is that the "shrinking" model is flawed, and it would be better to focus on making Squeak "growable".
If you develop in an image and have no way of getting all your code out of an image then you are in trouble. Images are fragile. You can't merge images. If you want to give your code to someone else, or if they want to give it to you, one of you has to move code out of the image and give it to someone else. So, it is important to keep your code in files, whether as .cs files or in Monticello.
If your code is in files, there is no argument against growing an image. Sure, you will develop in a huge "dev" image. But it is built out of components and many of those components are not used by your application. It is a lot easier to shrink a build script than to shrink an image. You could have a tool that automatically shrinks your build script by deleting packages one by one and seeing if your application still runs all its tests.
Shrinking an image is hard work and not for the faint of heart. I always tell my students to build their application first and worry about shrinking at the end. That is because they will be a lot better at Smalltalk at the end of the project than at the beginning, and so they will be better able to learn to shrink their image.
-Ralph
Well you bring up a good point. I think the first thing we need to do is get into a fully packaged (via universes, or something like that) world where such a tool only need look at package dependencies, not every single method/class.
From: "Pavel Krivanek" squeak1@continentalbrno.cz Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: "Inteligent" Shrink? Date: Thu, 22 Feb 2007 13:05:20 +0100
Hi,
I played with this idea of automatical image segmentation but the fastest, safest and maybe the only possible way now is to do that all by hand. The better way to create specialized images is IMHO from bottom. So we should simply continue in started modularization and packaging effort.
Cheers, -- Pavel
On 2/22/07, Giuseppe Luigi Punzi glpunzi@zyoconsulting.com wrote:
I don't know if others thinks like me, but I think something like this could be intereseting for prepare a ready for end-users image (without 70MB of size)
Something like this could have "don't delete develop tools" for example, but all the packages don't used, disappear from this image.
En Thu, 22 Feb 2007 12:47:12 +0100, Göran Krampe goran@krampe.se escribió:
Hi!
Imagine this.
You select one or various categories and "Intelligent Shrink" browse
all
the image searching all the objects thath the selected categories
uses.
If a categorie is not use or not will use it for our selected categories then erase it.
Example: I create a "set" of objects, and use objects from Kernel, Morphic etc.. But no object uses Monticello. Then, "Intelligent Shrink" may delete
all
Monticello's class not used.
Is this possible on Squeak?
I guess there are a whole bunch of ways to do such an analysis (that is more or less probably to be correct), MudPie springs to mind of course.
Can't give you an SM-link right now because the nameservers for squeak.org seems to be unreachable right now - have no idea. I can't verify if SM
is
up or down because I don't have the IP of squeak.org in my head.
regards, Göran
-- Giuseppe Luigi Punzi - Consultor
:: ZYO Consulting ::email: glpunzi@zyoconsulting.com tlfno: +34 675 145 912 web: http://www.zyoconsulting.co
_________________________________________________________________ Find what you need at prices youll love. Compare products and save at MSN® Shopping. http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001...
Hi Giuseppe,
For reference see SystemDictionary>>removeAllUnSentMessages
Cheers,
-- Diego
Imagine this.
You select one or various categories and "Intelligent Shrink" browse all the image searching all the objects thath the selected categories uses. If a categorie is not use or not will use it for our selected categories then erase it.
Example: I create a "set" of objects, and use objects from Kernel, Morphic etc.. But no object uses Monticello. Then, "Intelligent Shrink" may delete all Monticello's class not used.
Is this possible on Squeak?
Cheers.
For an example of further use of these ideas, look at http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html and try to understand it.
Cheers, Juan Vuletich
Hi Giuseppe,
For reference see SystemDictionary>>removeAllUnSentMessages
Cheers,
-- Diego
Imagine this.
You select one or various categories and "Intelligent Shrink" browse all the image searching all the objects thath the selected categories uses. If a categorie is not use or not will use it for our selected categories then erase it.
Example: I create a "set" of objects, and use objects from Kernel, Morphic etc.. But no object uses Monticello. Then, "Intelligent Shrink" may delete all Monticello's class not used.
Is this possible on Squeak?
Cheers.
El 2/22/07 9:14 AM, "Diego Gomez Deck" DiegoGomezDeck@consultar.com escribió:
Hi Giuseppe,
For reference see SystemDictionary>>removeAllUnSentMessages
Cheers,
-- Diego
And removing all , learn how blow a image.
Diego, you what always say what cutting a image is playing Jack the Ripper :=)
Today, Giussepe, the smaller ,cleaner Squeak based system is of Pavel.
Take this as base of any what Squeak becomes in future , current 3.10 process when go out I hope ends 1/3 smaller and clean what 3.9 is.
And all modularization process , packages or "ladrillos" as I call, become less esoteric
Edgar
__________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas
Edgar writes:
Today, Giussepe, the smaller, cleaner Squeak based system is of Pavel.
Take this as base of any what Squeak becomes in future...
I disagree. The Spoon systems are both much smaller and cleaner (easier to justify the presence of each object).
-C
El 2/22/07 6:13 PM, "Craig Latta" craig@netjam.org escribió:
I disagree. The Spoon systems are both much smaller and cleaner(easier to justify the presence of each object).
Craig you must read my other mail!!
And my opinion as I said in other list is what eventually Spoon become Squeak or viceversa.
I admire your work !!
Perhaps I should said:
"Today is easier you could build some application using existent Squeak stuff "
Possible you disagree too.
Continue your good work, let Pavel , me and others do what we could for enhancing Squeak
Edgar
__________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas
This is what I was suggesting before. I don't know if it exists or not, but something like this could be used to generate executables from an image. That is, I may have an MPEG player, a web site, something to control robots, etc., but I can select one of those and do the shrink to have a releasable exe.
From: "Giuseppe Luigi Punzi" glpunzi@zyoconsulting.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: squeak-dev@lists.squeakfoundation.org Subject: "Inteligent" Shrink? Date: Thu, 22 Feb 2007 11:39:22 +0100
Imagine this.
You select one or various categories and "Intelligent Shrink" browse all the image searching all the objects thath the selected categories uses. If a categorie is not use or not will use it for our selected categories then erase it.
Example: I create a "set" of objects, and use objects from Kernel, Morphic etc.. But no object uses Monticello. Then, "Intelligent Shrink" may delete all Monticello's class not used.
Is this possible on Squeak?
Cheers.
-- Giuseppe Luigi Punzi - Consultor
:: ZYO Consulting ::email: glpunzi@zyoconsulting.com tlfno: +34 675 145 912 web: http://www.zyoconsulting.co
_________________________________________________________________ Want a degree but can't afford to quit? Top school degrees online - in as fast as 1 year http://forms.nextag.com/goto.jsp?url=/serv/main/buyer/education.jsp?doSearch...
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Blake -
Craig Latta -
Diego Gomez Deck -
Edgar J. De Cleene -
Giuseppe Luigi Punzi -
Göran Krampe -
J J -
jvuletich＠dc.uba.ar -
Klaus D. Witzel -
Michael Rueger -
Paul D. Fernhout -
Pavel Krivanek -
Ralph Johnson -
stephane ducasse -
tim Rowledge