Squeak-dev February 2005

squeak-dev@lists.squeakfoundation.org

191 participants
430 discussions

Shrinking sucks!
by Torsten Bergmann 04 Feb '05

04 Feb '05

Hi, Image stripping is the most boring and stupid task ever invented for Smalltalk. Nobody builds a house by taking a rock, a knife and starts carving. We should build it step by step and stone by stone. Even when the removal task is automated (ST/MT has a good image stripper) there are cases you have to take care. If you use #perform: somewhere in your code you have to reference the symbol of the method you are calling - otherwise it's not in the runtime image. If method's have the same signature they are all in the runtime, even if just one is needed since the type info is dynamic. (That doesnt mean that we should switch to static typed languages). The current problem we have is the (currently) unmaintainable huge squeak image and the lack of time we are able to spend to repair and maintain it. There is lot's of stuff in it - MVC, morphic, old code from disney, etoys, code from research projects, ... and different people have different ideas what to do with it. I agree with Cees that it is wise to have a small core kernel which should be maintainable by the harvesters. I would vote for including namespaces and a packaging system into it's metamodel and try to keep it as small and simple as possible. Starting from this we could load packages like a command line squeak, traits, croquet, etoys, morphic, ... and create distributions. We should at least have keep one "full image" distribution assembling all the interesting projects to keep the dynabook nature and multimedia part of squeak. So what we need is an image builder (maybe from the "spoon" project) and build a small maintainable core image with support for SqueakMap. Just my 2 cents. Bye Torsten -- Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail

3 2

SqueakMap about to move!
by goran.krampe＠bluefish.se 04 Feb '05

04 Feb '05

Hi all! We have been busy bees getting our new box running smoothly, box1.squeakfoundation.org. Lots of services have been moved over there from the old box and things have also been moved from squeak.sourceforge.net, which we also are preparing to abandon. Now, the time has come for SqueakMap to take the jump. :) This will happen today within an hour or two. What will happen is that the web UI will be non available and you will not be able to update your map in your image. But installing packages etc should of course still work fine - the server isn't involved in those activities. Eventually SM will be back online and you shouldn't see any difference. regards, Göran

1 0

Squeak is an unsuccessful open source project (was RE: Let us face reality)
by Peter Crowther 03 Feb '05

03 Feb '05

> From: ... stéphane ducasse [...] > But what we really need is a leadership which can be an organization > that for example > can collect funds, have a decent web page, identify target, motivate > people, value enhancements... > and not just a bunch of people working on projects without > communication. [...] Coming in late to the discussion - apologies. Sorry, Stef, but I disagree. What a successful open source project really needs are: 1. A small, close-knit bunch of people working on Squeak to achieve their own ends (these may not be 'leaders'), and distributing that product; 2. A way of allowing a larger group to modify and extend the products of that small group, and then to distribute those products. I am going to argue that Squeak has *never* had that combination and, as a result, has never been a successful open source project. -- the old way -- Squeak sort-of worked in the days of SqC. It worked because there were a core bunch of people who could and would sort out the problems, sometimes *despite* the larger community. The rest of us could argue, redesign, jabber away until we were blue in the face, but development continued despite all the noise. There weren't 'working groups' and 'cleanup projects' and the like; there were people who trusted each other to fix the problems while working solo. This works for a small group of Smalltalk developers, as our beloved "exquisite personal computing environment" can just-about deal with coders importing code from others in a small group. It's hard to do this with even a few people working on the same project, however, and seems to get exponentially harder as the number of developers increases. Some of us in the larger group didn't always like the way the development was going. When a new image came out, we found that the extensions we had made didn't work any more, and we had to fix them or let them rot. So we clamoured to get 'our' bit into the 'base' image, because then it was more likely that it would be maintained. That didn't work, because the central maintainers couldn't maintain the extra bits and they rotted anyway. But neither was it possible to keep reasonable external packages that could be added in, because those packages relied on too much of that highly-functional, extensible class hierarchy in the core. Implementation inheritance is inherently fragile - as I think every package maintainer has found out when something minor changes in a base class and suddenly your code no longer works. -- the new way -- SqC dispersed. Image maintenance was taken over by the larger group - and, immediately, the problems started. Our "exquisite personal computing environment" turned round and bit us, because it *sucks* as a system in which a large number of developers can work. We're now in the position of having a small group of 'harvesters', whose job is to examine changes submitted by others and to perform a damage-limitation exercise on the amount of change going on in the core image. It's a tough job; it burns people out. But, because we have this monolithic image, we don't have the choice. The larger group are still no better off; possibly worse off. We still develop code. We are still encouraged by the functionality in this huge code base, and we still choose to use implementation inheritance to extend the system as there is no other mechanism in Squeak for extension. We still get ticked off when something modifies behaviour on which we depend; but now, we cannot even be sure that the modification is sensible, as the harvesters are having to pull in changes from many people and attempt to make them work together. This situation will remain while we continue to use implementation inheritance from base classes that evolve. -- another way -- 1. Throw away the notion that you can depend on that big, juicy class library. You can't, and it's a mistake to try, because it will evolve faster than you can keep up and your code will rot. 2. Decide on a very small, stable core. Collection and number classes may be a good start. 3. Introduce a proper notion of interfaces for these. Freeze the interfaces, either formally or by people avoiding modifying them. 4. Build up from this core. In each package - for example, the MVC UI - define and freeze interfaces. Document all the dependencies. Ensure each package can be loaded into an image that only has its dependencies loaded; and ensure that a package *cannot* alter any other package. Yes, this means that nobody except the maintainer of the core can touch Object, for any reason, no matter how apparently noble. We will then have a basis for a system that might begin to satisfy (2) above. (1) will only happen when another (non-SqC) group of people get together and decide to use Squeak for a project. The larger community cannot force it. Note that by making a system that is suitable for parallel development by many developers, we have thrown away most of the things that make Squeak such a productive system for developers. We have moved away from the concept of an exquisite personal computing environment to something much more rigid and prescriptive. This may put people off adopting such an approach, but I think stability and flexibility are mutually exclusive goals. -- conclusion -- Due to Squeak's origin as a personal computing environment, it has never had a way of allowing a large group of developers to work on it and re-use each others' artifacts. Current efforts are attempting to change that, but there is no appetite for throwing the image away and starting again with a small core - a very hard task, made harder by the fact that all the development tools are in-image and need a larger core. So the architecture of Smalltalk itself is against us. Newcomers come in, realise that they can change the world in Squeak, do so, and then get discouraged when their code no longer works in the next minor version. So they put Squeak away - nice toy, unsuitable for me - and go back to perl, or Java, or .Net, or something that has a stable core and where their code won't break in the next minor revision. And it takes them more effort to develop in that environment, but *much* less effort to maintain. I admire Craig Latta's work on small images that do not contain a development system. If we are ever to build a Squeak that allows many developers to work in parallel, Craig's work - or something very similar - is going to be pivotal, as the *only* way to build and test the core parts of such a system. I'll leave you with one last puzzle: why does majorShrink exist? Why isn't it majorGrow? - Peter

8 11

minor bug fixes for Skylark theme
by Pavel Krivanek 03 Feb '05

03 Feb '05

Here you can find new version of Skylark theme (skin for Squeak 3.7/3.8) including font settings patch for Shout: http://www.comtalk.net/Squeak/87 Pavel

1 0

RE: [BUG] in color (Color r: 1 g:0 b:0) * #(1 1 1) -> DNU
by Frank Shearar 03 Feb '05

03 Feb '05

I wrote: > stéphane ducasse <ducasse(a)iam.unibe.ch> wrote: > > > > in the comment of Color we read that we can * a color by an > > array to get > > > > self assert: (Color r: 1 g:0 b:0) * #(1 1 1) = Color red > > > > But (Color r: 1 g:0 b:0) * #(1 1 1) raises an error > > Hm yes; Color>>* has a method pattern (I can't recall the > proper name?) of > > * aNumber > "Answer this color with its RGB multiplied by the given > number. " > "(Color brown * 2) display" > > and dates from 1997/02/11 - it looks like the comment is just > plain wrong? > > I don't mind writing a fix, if someone tells me which > solution to use: fix the comment, or fix the code (and of > course write a test). Why work when I can procrastinate & work on Squeak? I've mailed a fix, titled ColorTimesArray-fbs. frank ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ********************************************************************

1 0

Subversion mirror up!
by goran.krampe＠bluefish.se 03 Feb '05

03 Feb '05

Hi all! Ok, I have been fighting with Subversion (sigh...) and now I have finally gotten it all together on our new SqF box (box1.squeakfoundation.org). Currently I have a full mirror of the current master Squeak VM Subversion repository (http://squeak.hpl.hp.com/svn/squeak) and that mirror is available readonly at: http://box1.squeakfoundation.org/svn/mirrors/squeak This mirror syncs with the master every 10 minutes. If that is too seldom, let me know. :) To check out tutti la frutti, you do of course: svn co http://box1.squeakfoundation.org/svn/mirrors/squeak ...or just the trunk: svn co http://box1.squeakfoundation.org/svn/mirrors/squeak/trunk I got some help from Chia-liang Kao, the author of SVN::Mirror (thank god for open source), and it seems to work fine. regards, Göran

1 0

[FIX] ColorTimeArray-fbs
by frank.shearar＠rnid.org.uk 03 Feb '05

03 Feb '05

from preamble: "Change Set: ColorTimeArray-fbs Date: 3 February 2005 Author: Frank Shearar The comment for Color claims you can multiply a Color by an array. This changeset actually satisfies that claim."!

1 0

RE: [BUG] in color (Color r: 1 g:0 b:0) * #(1 1 1) -> DNU
by Frank Shearar 03 Feb '05

03 Feb '05

stéphane ducasse <ducasse(a)iam.unibe.ch> wrote: > > in the comment of Color we read that we can * a color by an > array to get > > self assert: (Color r: 1 g:0 b:0) * #(1 1 1) = Color red > > But (Color r: 1 g:0 b:0) * #(1 1 1) raises an error Hm yes; Color>>* has a method pattern (I can't recall the proper name?) of * aNumber "Answer this color with its RGB multiplied by the given number. " "(Color brown * 2) display" and dates from 1997/02/11 - it looks like the comment is just plain wrong? I don't mind writing a fix, if someone tells me which solution to use: fix the comment, or fix the code (and of course write a test). frank ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ********************************************************************

1 0

Re: Is there a simple way /automatic way to produce a sar from a bunch of mcz files?
by Chris Muller 03 Feb '05

03 Feb '05

> Yes. > ... Whatever happened to SarBuilder?

3 2

BFAV hickup and Squeak files mirroring!
by goran.krampe＠bluefish.se 03 Feb '05

03 Feb '05

Hi companions! (trying to vary my greetings a bit) Yesterday when I was busy setting up our new fine SqF box I accidentally messed up BFAV. Perhaps noone noticed?! :) Anyway, I think I got it back on track - seems to work for me. If there still are issues, then... it was my fault. :) The thing that triggered this was that we upgraded to apache2 on that box and I didn't recall that BFAV used Apache. Btw, feel free to start mirroring Squeak files (the ones previously hosted on SF, the Win32 VM): http://box1.squeakfoundation.org/files/MIRRORING.txt ...and I am also setting up a Subversion mirror there. Eh, I hope. It's messy stuff. regards, Göran

1 0

Jump to page: