Hi folks...
I'm working on assembling the full image for 3.7.
There are some packages that make sense for developers but for media-users. (VMMaker, Refactoring Browser, etc).
The goal in Small-Land is to cover media-users.
So the question: The Full 3.7 has to cover users AND developers?
I vote to cover only user assuming the developers can assemble they own images. The other option is to assemble more than one Full-Image (Media, Developers, etc) but in this case we need more soldiers.
Thoughts?
Diego
Hi,
Diego Gomez Deck wrote:
I vote to cover only user assuming the developers can assemble they own images.
What about developpers new to Squeak? We need to provide them with most popular/usefull programming tools. I'm thinking to my students. I use Squeak in my courses to introduce OO programming. I have only few hours for it. Then I leave students play with Squeak (for those willing to) on their own. Of course, I can provide them a special image with a set of tools. But : - they get more impressed if they learn that all those tools are provided in the official image - they may get lost if they they work during clases with my specific image and don't retreive the same tools when downloading a new "full" version
Even for developpers familiar with Squeak. I thinking here to people like me that need to reinstall their favourite tools every time they start using a new version/release. Fortunately, their is developpers workspace on SqueakMap. But, it takes some extra time to install it. And, it does not always work with developpment (alpha, beta) versions (at least with 3.7)....
Noury
(responding to an old thread)
Noury Bouraqadi wrote:
Diego Gomez Deck wrote:
I vote to cover only user assuming the developers can assemble they own images.
What about developpers new to Squeak? We need to provide them with most popular/usefull programming tools. I'm thinking to my students. I use Squeak in my courses to introduce OO programming. I have only few hours for it. Then I leave students play with Squeak (for those willing to) on their own. Of course, I can provide them a special image with a set of tools. But :
- they get more impressed if they learn that all those tools are
provided in the official image
- they may get lost if they they work during clases with my specific
image and don't retreive the same tools when downloading a new "full" version
I agree. I think it's probably simpler to have just have one Full image which has lots of developer goodies as well as media content. It's not worth the extra maintenance effort to have a special Media-Full image, and then a Developer-Full image. Image size should not be an issue... for those who don't have enough memory (should only be PDA users at this point), they should use Basic anyway. (At this point even the Squeak Full image is tiny compared to a Java development environment like Eclipse.)
However, I understand that getting this Full Assembler package together is a lot of work for Diego. So if he wants to limit the amount of developer goodies to a modest number of things for now, that makes sense. I guess it depends a lot on which packages tend to cause conflicts by overwriting methods, etc... that should be discouraged as much as possible and we should get any necessary changes into the base image instead.
Anyway, as a start, I'd say something like the Refactoring Browser would be worth having in Full, assuming it's in working order and doesn't cause too many conflicts.
- Doug
On May 20, 2004, at 1:59 PM, Doug Way wrote:
I agree. I think it's probably simpler to have just have one Full image which has lots of developer goodies as well as media content. It's not worth the extra maintenance effort to have a special Media-Full image, and then a Developer-Full image.
However, I understand that getting this Full Assembler package together is a lot of work for Diego. So if he wants to limit the amount of developer goodies to a modest number of things for now, that makes sense.
This seems somewhat contradictory. Either we have a Full image which does have developer goodies, or Diego doesn't have time to include them and so we need a separate Developer-Full image. To say "we don't need a developer image because the media image will have developer stuff, but we don't have time to actually put the developer stuff in because media is a higher priority" doesn't make sense: you end up just not meeting the needs of the developers.
I don't mind which we go with, as I can see good arguments either way, but if the Full image is not in practice going to include adequate developer support, then let's be explicit about that and open the way for someone to put together a proper developer-oriented distribution.
Avi Bryant wrote:
On May 20, 2004, at 1:59 PM, Doug Way wrote:
I agree. I think it's probably simpler to have just have one Full image which has lots of developer goodies as well as media content. It's not worth the extra maintenance effort to have a special Media-Full image, and then a Developer-Full image.
However, I understand that getting this Full Assembler package together is a lot of work for Diego. So if he wants to limit the amount of developer goodies to a modest number of things for now, that makes sense.
This seems somewhat contradictory. Either we have a Full image which does have developer goodies, or Diego doesn't have time to include them and so we need a separate Developer-Full image. To say "we don't need a developer image because the media image will have developer stuff, but we don't have time to actually put the developer stuff in because media is a higher priority" doesn't make sense: you end up just not meeting the needs of the developers.
I don't mind which we go with, as I can see good arguments either way, but if the Full image is not in practice going to include adequate developer support, then let's be explicit about that and open the way for someone to put together a proper developer-oriented distribution.
True. Mostly I was fishing about to get an idea of whether Diego was interested in doing this, and whether he'd be able to get a sufficient number of developer goodies for such an image. Although what exactly would go in the developer portion of this image is up for debate... we haven't actually had an image like this before. (not maintained on SM, anyway)
If Diego doesn't want to do the developer tools stuff, we'll have to find a volunteer to maintain the Developer-Full image content.
Ideally, if it's doable, I still think we'd be better off with one Full image (Media+Developer) and not two separate ones.
- Doug
Doug Way wrote:
[snip]
However, I understand that getting this Full Assembler package together is a lot of work for Diego. So if he wants to limit the amount of developer goodies to a modest number of things for now, that makes sense. I guess it depends a lot on which packages tend to cause conflicts by overwriting methods, etc...
[start emphasis]
that should be discouraged as much as possible and we should get any necessary changes into the base image instead.
[end empasis]
Right. I want to give support to this. I read it as Doug wanting to use the energy of the developers of developer-goodie-packages to help improve the quality of the base (image).
That is a great goal and it might just work, also because the developers of developer-goodie-packages are rather well-positioned to improve the quality of the base. After all, the knowledge they acquire about the base in order to be able to build their tools in the first place, helps them to be able to improve the base too.
It seems that historically, this has not always been how it goes. Is it accurate to think that frequently, a change to the base for the benefit of one package, breaks one or more other packages? I haven't been keeping logs about such events, but from following squeak-dev and my own experience of trying to load add-ons, it seems like this does indeed happen.
How to improve this situation? I see two approaches that might help: 1) self-testing packages 2) "hygienic packages"
Ad 1), self-testing packages: If packages are equipped with a command to run a self-test, which verifies whether they are working well, all such packages can be loaded together in a "dev-all-self-testing" image and any possible problems identified. So the message to the goodie-developers is: equip your work with a self-test button, and we can include it in "dev-all-self-testing" (which could be the base from which to build "dev-full"), and ensure it works up to the level of assurance that you yourself have built-in through the self-tests you included.
Ad 2), "hygienic packages": A "hygienic package" is a package of which we can know in advance, that it does not break any other package. This is something that would depend on a working namespace system. Because all the code is in its own namespace, then if no other code in our image uses the same namespace, we know that loading the hygienic package can't break anything in our image. Loading a "hygienic package" also can't break any other "hygienic package" we might want to load later (unless they use the same namespace, which is not difficult to avoid).
[I have studied Goran's namespace proposal, including the code, and it would seem it enables hygienic packages. But it does a few other things as well, and I would rather advocate, as a first step top take, the simplest namespace system that can work: which would be a namespace system that does just enough to enable "hygienic packages". This would use some form of Andreas' parser mod allowing Xxx::Yyy global names, which I think is not only clever, but in this case also a good idea :-).]
Self-testing packages can be done without having namespaces and would start to help avoiding functional conflicts going undetected, and reduce the workload of the people who integrate things to produce distribution images.
BTW, self-testing packages are not just a wild idea: I have written all my packages to be self-testing for quite a while, and it works excellently. QA is very effective and not much work. I use the self-testing ability to do TDD on those packages as well, but that is optional and there are many parts I have designed up front as well, and then completed/enhanced with TDD and secured with regression-tests. My packages include their own tests, but they also include their own testing and error-reporting engine. But this last aspect (having your own engine) is by no means required; an external testing/reporting tool like SUnit can be used as well.
Having no concrete plans to implement any of this myself specifically for Squeak, take-up of any of these ideas depends on others. So, does this make any sense to anyone here?
Cheers,
Peter
squeak-dev@lists.squeakfoundation.org