Squeak-dev January 2005

squeak-dev@lists.squeakfoundation.org

134 participants
235 discussions

[BUG][TEST] ChangeSet losing class category changes in Squeak 3.7+
by David T. Lewis 21 Feb '05

21 Feb '05

Class category changes are not being properly added to the default changeset in Squeak 3.7 (and 3.8, 3.9). The attached test case will pass in Squeak 3.6, and fail in Squeak 3.[7-9]. The effect of this bug is that class category reorganizations are lost when managing code with change sets. - Dave

3 5

Re: New FileSystem (was RE: About a new roadmap for 3.9)
by David T. Lewis 08 Feb '05

08 Feb '05

On Fri, Dec 17, 2004 at 04:54:33PM +1100, Russell Penney wrote: > > My plan is to have nearly everything written in Squeak with very basic > primitives, that way it allows more control. > > Fundamentally there are 3 classes: > File handles file access > Directory handles directory access > FileSystem handles the raw access and provides a unified interface for Files > and Directories. Russell, If you're going to do a complete rewrite, it would also be good to generalize the notion of an I/O channel for files, sockets, pipes, or whatever other external resources can be modeled in this way. I took a step in this direction with IOHandle (on Squeak Map). This has not been updated for current Squeak, but I'll be happy to do so if you have an interest. IOHandle separates the representation of I/O channels such as files and sockets from the higher level stream and file system stuff. On Squeak versions up through 3.6, you can install IOHandle to move all the low-level representations out of FileStream and Socket without breaking the old code (this is a bit tricky, because you have to be able to keep using the changes file while filing in the changes). To make it work on current Squeak, I would need to adapt it for the new Sockets classes, and redo the installation process. You might also find some useful things in DirectoryPlugin on SM, although this is intended to support the current file system, and it's probably best to throw all of this out and start fresh. Dave

14 22

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

08 Feb '05

> From: [...] Cees de Groot > On Sun, 30 Jan 2005 10:20:55 -0000, Peter Crowther > <Peter(a)ozzard.org> > wrote: > > > -- another way -- > > Hear, hear! (mostly. There are quite a number of nits in your > story I'd > like to pick, but I'm not going to do that at this moment) Well, quite. You didn't expect me to spoil a one-sided email like that by weakening my case, did you? ;-) > BTW - I'm thinking that we could decide to "just do it". I think Craig already has. Like most prophets and visionaries, he has confused a lot of folks in the process. > it is a whole lot better than what we've got now > and could be done immediately, just by deciding to do it. And that, I would argue, is a key point. As Craig has found, one person 'just doing' works for that person. As we have found on this list, a large group delegating a few people to go away and debate something then maybe do it sometime... doesn't work either, as the frictional costs are too high and nobody in the small group wants the results enough. This is actually a third problem with Squeak as an OS project... It's too big, and does too many things, none well enough to be best-of-breed. So there's always a better tool to use for any particular problem. Who would rally round the new, slimmer image? Certainly not the Croquet/Teatime crowd. Not the UI folks. It wouldn't do multimedia... Really, it's a bit difficult to know who would take it and use it. This shouldn't stop somebody doing it, however, and publishing the result; that way, people might pick it up and use it. But that 'somebody' should need/want it *for themselves*, so that they'll put the effort in. > But by Just Doing It, we could actually attempt to tackle > these issues instead of constantly debating them. Quite. > (re breakage - I just realized that it should be possible to > use the RB > rewriting stuff with thisContext sender to actually rewrite > methods that > call obsolete stuff and send the maintainer of the package an > auto-generated patch. Now that'd be an elegant tool for > dealing with bit rot ;)). Quick, find an academic and publish a paper :-). - Peter

6 7

[ANN] Stable Squeak 3.7 Universe
by Lex Spoon 07 Feb '05

07 Feb '05

Okay, I finally posted an image based on the Stable Squeak 3.7 Universe. http://minnow.cc.gatech.edu/squeak/3835 This is a good starter image for two groups of people: # Newbies to Squeak, who want to see what Squeak is like. They can click on the projects and have them reliably load. Further, they don't care whether they have the newest packages available - they are happy to play with the most popular ones. # Application developers. If you are writing a program in Squeak, as opposed to working on Squeak itself, then you would like to have a stable baseline to start from. This image is perfect: it is well defined and all the packages load successfully. As a special case, classes that use Squeak, would find this a good image to start from. These user groups are not served by our current release process. Even if they grab a 3.7 image (or more likely, an even older one), how are they to access the packages that were available at the time? 3.7u answers that question: the set of packages is listed in a universe, and that particular universe is not allowed to be modified except for extremely important bug fixes. Comments welcome. I'll post new bugfix releases over time, but will not include any major changes. The Stable 3.7 Universe is "stable" because it doesn't change, not because it works perfectly. -Lex

5 7

[ENH] ChangeSetRefactoring-gk with changeset splitting!
by goran.krampe＠bluefish.se 07 Feb '05

07 Feb '05

from preamble: "Change Set: ChangeSetRefactoring-gk Date: 16 December 2004 Author: Göran Krampe NOTE: Not for inclusion in image - needs feedback and refinement etc. This changeset contains a few refactorings, some Collection enhancements, minor fixes and adds three new actions in the changesorters for splitting changesets and mailing them to maintainers. It also messes around in PackageInfo so it should NOT be included 'as is' as an update."!

2 2

[ENH] remove deprecated Chronology methods in 3.9 [cd][su][sm]
by Brent Pinkney 07 Feb '05

07 Feb '05

Hi, 'From Squeak3.9alpha of ''2 November 2004'' [latest update: #6537] on 30 January 2005 at 9:50:13 am'! "Change Set: removeDeprecatedChronology-brp Date: 30 January 2005 Author: Brent Pinkney Remove all deprected methods from Kernel-Chronology. The methods were deprecated and 3.7 and are therefore due for removal in 3.9. All 406 tests in Kernel-Chronology Tests succeed and the PDAMorph still works. Any empty categories (deprecated) are removed by the postscript. Brent

2 2

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

Re: Non-debuggerable situation
by Chris Muller 02 Feb '05

02 Feb '05

I'm glad we agree that it should at least not get into this situation where it allocates memory endlessly and can thus disrupt other programs running on the OS. I compared the list of ProtoObject methods in 3.7 and 3.9 and see no difference. So it must be a change in the debugger code. I also noticed it happens on my 3.8-6326 unstable image. Anyone have any ideas?

3 4

FFI Win32 api calls with LPTSTR args?
by Cees de Groot 02 Feb '05

02 Feb '05

Hi, I want to use some Win32 API functions to make my app a bit more windoze friendly, most notably to place temporary files in the correct location (GetTempPath) and to find out where the user's home directory is (haven't found that one yet ;)). My knowledge of FFI is as big as that of Win32, i.e. almost completely absent. I haven't seen an example that uses the 'LPTSTR' (char **?) argument type, so I'm a bit at a loss as how to do this - could somebody help me here? TIA, Cees

7 12

Re: Let us face reality
by Lex Spoon 01 Feb '05

01 Feb '05

This talk of paying worries me. I see many open source projects that do very well with very little funding. I see many people participating in Squeak -- after all, just look how many ENH's we have. :) Surely there is a way to channel all this energy, especially given the large number of successful OS projects in the universe? I fear that if we use money to prop up our current situation, we will just keep on doing things in a sub-optimal way. Surely we can figure out what the other guys do, that we do not? I do not oppose spending money in general on Squeak; I simply worry about trying to use it to speed up business as usual. > - Packaging. Packaging. Packaging. Did I mention Packaging? You will never > get enough manpower together to manage a monolithic image. Not unless you > want to call yourself Java or something. I'm quite sure that as soon as > the core is of a managable proportion, a lot of the backlog will vanish > because the load will be distributed; if someone doesn't take up 'his' > bugs, just kill them. If a package is not maintained and starts to exhibit > bit rot problems, junk it. Here here!! You are all tired of hearing it, but Debian does *fabulously* on very little money. 8000+ packages and 900+ developers. A major part of Debian, I think, is that everything is divided into packages and each package has a maintainer. Un-maintained packages are gradually marginalized and then removed from the distribution. When there is a bug report, it's easy to see who is responsible, and it's easy for the responsible person to become aware of it. Are there any bugs posted against Chuck right now on Mantis? I have no idea. And what about Nebraska, which is still in the image? Eek. In Debian, I have exactly two bug reports open. > - A good portal where new members, as someone else explained here, are > presented with information about what constitutes good behavior; if more > people get invited to the harvesting process, AND the scope decreases, we > can go a long way towards making the maintenance manageable. I don't know if it needs to be the front page, but I certainly agree that our current situation is very confusing. Further, it's tough to contribute. As I've posted before, opening BFAV and looking at random enh's and fix's is quite hard, and feels wasteful of my time. http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-June/078737.html It has occured to me to sign up as the Nebraska maintainer, but I don't even know how. I could figure it out, I guess, and I will eventually, but shouldn't this be very easy? Someone volunteered for EToys not too long ago (Ned I think), and it was actually *overlooked* because they merely posted it to the list. A SqueakSource-like portal would rock, but a great start would be for someone to go through the swiki and really organize all the pages about our processes, whatever they are. Start from here: "How to contribute to Squeak" http://minnow.cc.gatech.edu/squeak/3279 This page is honestly not bad, but it bothers me that "maintain a package" and "assume responsibility for a segment of Squeak" are not listed on this page. I know its in the swiki somewhere... > I'm putting up the devil's advocate hat here, it'd be nice if more people > could earn their money with Squeak, especially if they'd develop Squeak > rather then develop in Squeak, but I'm not convinced that it is this > community's most pressing problem at the moment. Well, I'd like to see it, but again, I want us to be extremely careful about where we interject money. It will prop up one part, but if it is failing on its own, is it really something we want to spend money on? I say we pay people to make Squeak books. :) -Lex

11 14

Jump to page: