Squeakfoundation June 2003

squeakfoundation@lists.squeakfoundation.org

30 participants
59 discussions

RE: [Squeakfoundation]re: TrueType font support and 3.6
by Daniel Vainsencher 23 Jun '03

23 Jun '03

[In design terms, Yoshiki's solution is very simple] I'm very glad to hear that. [acknowledgement and fixes to small issues raised] Now you've moved it a little bit closer to being the simplest thing that could possibly work. Considering the review you gave generally, it's quite probably close enough, too. Of course, we'll respect Yoshikis wish to wait for his new version. [generally - does code need to be perfect before we'll even look at it?] Depends. If the code is two isSymbol methods, yes, it needs to be perfect. OTOH, for something that simple, I don't mind if the implementor is the reviewer is the approver. For the other extreme case, something that touches lots of innards, and affects everything, like Anthony's closure changes, it's obvious to me that there's no way to make it perfect. However, to minimize the pain in changes to more publically released code, such as images, I would definitely want it to be reviewed by at least one other expert in the area, and preferably at least one other, and that the issues they raise be dealt with. It still won't be perfect, but it'll be doing reasonable justice to future users of the code. And since I know I'm not qualified to do justice to his changes, I currently see no way my even looking at it can help, really (though in this specific case, I tried anyway). Yoshiki's code is somewhere between the two extremes, and should be treated accordingly. With a review by you and a review by Goran, and a response to those issues when Yoshiki can get to it, I'm sure we'll be in good shape. [What are the measures?] Note that "the simplest thing that could possibly work" is to be interpreted very widely. It means it should have comments, but only comments that actually help. All the good things you mentioned about Yoshiki's solutions to various problems fall under this too. As long as one can easily point out something that is definitely an improvement, however small, it isn't the simplest thing that could possibly work. Of course to avoid infinite effort, we need to be practical, so see the paragraphs above about limiting the effort. A very good starting point to see what this includes is http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork and http://c2.com/cgi/wiki?WhatIsSimplest Now does it work for you both abstractly and concretely? Do you have some suggestions for improvement? (I'll summarize and post these as a draft for review rules). [critique about implicitly returning self method] If this method was in use, it would be very nearly semantically equivalent to not existing, since it does nothing except a super send. Very nearly, but not quite, because it doesn't return the super sends result. Which could, imaginably, be justified, but is much more likely to simply a source of endless confusion if someone modifies the super implementations return value, and then, sometimes, "his change doesn't work". Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > This is a multi-part message in MIME format. > > --Boundary_(ID_JoGVnwLKXwZRd95pmxwCeg) > Content-type: text/plain; charset=us-ascii > Content-transfer-encoding: 7BIT > > > Andreas, does this help? > > Abstractly yes, concretely I'm not sure. I'll give you my take on it in the > TTF discussion: > > * Is it the simplest thing that could possibly work? > > I would claim so. When Yoshiki first did it I was more than just a little > surprised to see not only that he'd done it but also how simple it was. I > had been looking into this myself and there were a number of problems where > I simply had no idea how to do them (most importantly how to deal with color > changes in the text). Given that Yoshiki's code does not require any kind of > low-level surgery (such as new primitives, BitBlt combination rules etc), > yes I claim it is absolutely the simplest thing that could possibly work. > > * Does it have dead code? > > The one method you mentioned (and where I still don't understand the > critique about sending to super and implicitly returning self ;-) seems > unused. I've attached a fix which simply removes it. > > * Does it have extensions to classes which are not strictly required? > > All of the extensions are required. > > * Does it break or undo other peoples work? > > There is one conflict with an MCP change to which a fix is attached. > > Summary: If I take your measures then to me everything's fine with the two > attached minor changes. > > Cheers, > - Andreas > > > -----Original Message----- > > From: squeakfoundation-bounces(a)lists.squeakfoundation.org > > [mailto:squeakfoundation-bounces@lists.squeakfoundation.org] > > On Behalf Of Daniel Vainsencher > > Sent: Sunday, June 22, 2003 3:33 AM > > To: Discussing the Squeak Foundation > > Subject: RE: [Squeakfoundation]re: TrueType font support and 3.6 > > > > > > I'll take that as a reminder that we haven't yet created the official > > submission/review policy we talked about last week. Here's a draft - > > > > Code submitted should be the simplest thing that could possibly work > > (*), where "work" is defined as providing the functionality promised > > (ENH) or correcting the bug (FIX) without creating others. > > > > (*) note that this precludes, among other forms of complexity - > > 1. Dead code that does nothing. > > 2. Extensions to existing classes that are not strictly > > required for the > > code to work. > > 3. Breaking or undoing other peoples changes. > > > > Andreas, does this help? > > > > Daniel > > > > Andreas Raab <andreas.raab(a)gmx.de> wrote: > > > Hi Daniel, > > > > > > > > If alpha is closed without the TTF stuff > > > > > it means you've delayed the most important improvement to > > > > > Squeak's user interface in the last three years. > > > > Have you ever failed a test because you didn't put in the > > > > effort and had to do it over? did you blame the teacher for > > > > writing the test? > > > > > > Yes, but in these situations the rules were clear to me and > > I knew what > > > exactly I should have done differently. > > > > > > Again: Please explain to me what your desired code quality > > is. What measures > > > do you use? What are the rules? > > > > > > > You may see things so that you think that I'm delaying > > this code, but > > > > this code could easily be cleaner, and you know it, and you can do > > > > something about it just as easily as me. > > > > > > Only if I know the rules. Otherwise I can only wait until > > there is some > > > critique here or there and depending on your workload this > > may take days, > > > weeks, or months. > > > > > > > [Conflicts are hard to find] > > > > Well, yes. Do you think that the fact that conflict > > detection is hard > > > > means that we should ignore it? > > > > > > You lost me here. Finding potential conflicts with other > > packages is quite > > > simple once you've got the stuff loaded. Just go into a > > dual change sorter > > > and choose "conflicts with other change sets" and it'll > > list you all of > > > them. Then you turn on the diffs and voila! all your > > conflicts get nicely > > > highlighted. Fixing them can be a different matter though ;-) > > > > > > > [DecPools and KCP] > > > > The fact that conflicts with packages are hard to solve is a sad > > > > consequence of not having package releases. It is made more > > > > difficult by having more packages, but the solution is not > > > > in going back to a monolithic image, but in improving our > > > > infrastructure (SM1.1). > > > > > > You lost me again. I don't see how the above is related to > > my question about > > > how to handle a concrete case in a concrete situation. > > Please explain. > > > > > > > Wish I could give you a release date for that, but I can't. > > > > > > I sure hope it's soon. I already started to manually mirror > > important > > > packages in order to be able to rely on the right versions. > > It sucks like > > > hell but there's nothing else I can do. > > > > > > > When we're talking about a package, like RB, what I did > > was fork it into > > > > two packages. When we're talking about a patch like > > DecPools, I would > > > track > > > > the current alpha, because the version for an old 3.6 won't be > > > particularly > > > > useful to anyone. > > > > > > I think it's quite valuable to have it available for older > > Squeak versions. > > > The point is that someone may want to load a package which > > contains a > > > declarative pool in something like 3.4/3.5. Having the > > package at SqueakMap > > > means that they have at least a chance to try it. > > > > > > Cheers, > > > - Andreas > > > > > > _______________________________________________ > > > Squeakfoundation mailing list > > > Squeakfoundation(a)lists.squeakfoundation.org > > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > _______________________________________________ > > Squeakfoundation mailing list > > Squeakfoundation(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > --Boundary_(ID_JoGVnwLKXwZRd95pmxwCeg) > Content-type: application/octet-stream; name=RemoveGrafportMethod.1.cs > Content-transfer-encoding: quoted-printable > Content-disposition: attachment; filename=RemoveGrafportMethod.1.cs > > 'From Squeak3.6alpha of ''17 March 2003'' [latest update: #5278] on 22 = > June 2003 at 2:15:28 pm'!=0DGrafPort removeSelector: = > #installTTCFont:foregroundColor:backgroundColor:!=0D= > > --Boundary_(ID_JoGVnwLKXwZRd95pmxwCeg) > Content-type: application/octet-stream; name=FixConflict.1.cs > Content-transfer-encoding: quoted-printable > Content-disposition: attachment; filename=FixConflict.1.cs > > 'From Squeak3.6alpha of ''17 March 2003'' [latest update: #5278] on 22 = > June 2003 at 2:16:22 pm'!=0D=0D!CanvasDecoder methodsFor: 'decoding' = > stamp: 'ar 6/22/2003 14:16'!=0DprocessCommand: command onForceDo: = > forceBlock=0D | verb verbCode |=0D command isEmpty ifTrue: [ ^self = > ].=0D=0D verb _ command first.=0D verbCode :=3D verb first.=0D=0D = > verbCode =3D CanvasEncoder codeClip ifTrue: [ ^self setClip: command = > ].=0D verbCode =3D CanvasEncoder codeTransform ifTrue: [ ^self = > setTransform: command ].=0D verbCode =3D CanvasEncoder codeText ifTrue: = > [ ^self drawText: command ].=0D verbCode =3D CanvasEncoder codeLine = > ifTrue: [ ^self drawLine: command ].=0D verbCode =3D CanvasEncoder = > codeRect ifTrue: [ ^self drawRect: command ].=0D verbCode =3D = > CanvasEncoder codeBalloonRect ifTrue: [ ^self drawBalloonRect: command = > ].=0D verbCode =3D CanvasEncoder codeBalloonOval ifTrue: [ ^self = > drawBalloonOval: command ].=0D verbCode =3D CanvasEncoder = > codeInfiniteFill ifTrue: [ ^self drawInfiniteFill: command ].=0D=0D = > verbCode =3D CanvasEncoder codeOval ifTrue: [ ^self drawOval: command = > ].=0D verbCode =3D CanvasEncoder codeImage ifTrue: [ ^self drawImage: = > command ].=0D verbCode =3D CanvasEncoder codeReleaseCache ifTrue: [ = > ^self releaseImage: command ].=0D verbCode =3D CanvasEncoder codePoly = > ifTrue: [ ^self drawPoly: command ].=0D verbCode =3D CanvasEncoder = > codeStencil ifTrue: [ ^self drawStencil: command ].=0D verbCode =3D = > CanvasEncoder codeForce ifTrue: [ ^self forceToScreen: command = > withBlock: forceBlock ].=0D verbCode =3D CanvasEncoder codeFont ifTrue: = > [ ^self addFontToCache: command ].=0D verbCode =3D CanvasEncoder = > codeTTCFont ifTrue: [ ^self addTTCFontToCache: command ].=0D verbCode = > =3D CanvasEncoder codeExtentDepth ifTrue: [ ^self extentDepth: command = > ].=0D verbCode =3D CanvasEncoder codeShadowColor ifTrue: [ ^self = > shadowColor: command ].=0D=0Dself error: 'unknown command: ', command = > first.! !=0D=0D= > > --Boundary_(ID_JoGVnwLKXwZRd95pmxwCeg) > MIME-version: 1.0 > Content-type: text/plain; charset=us-ascii > Content-transfer-encoding: 7BIT > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > --Boundary_(ID_JoGVnwLKXwZRd95pmxwCeg)--

1 0

RE: [Squeakfoundation]re: TrueType font support and 3.6
by Daniel Vainsencher 23 Jun '03

23 Jun '03

goran.krampe(a)bluefish.se wrote: > Hi guys! > > Let me be really quick and to the point. I just read through this whole > TTF thread... Phew. ;-) You two guys need to relax and try to > communicate better. Or something, I don't know. :-) Yes you do, as usual, you hit the nail on the head, IMHO. I'm starting to think Andreas and me are communication jinxed - maybe be we both feel strongly about very close topics, but look at them just differently enough to miss it. > BUT I personally want code cleaned up before going in! And I am not > talking about complicated things here - simply a bit more comments, > remove dead method and some other cruft etc. 30 minutes work tops - > mostly comments actually. That summarizes my position quite well. Daniel

1 0

A Steward volunteering! Re: We need a Maintainer for Scamper...
by goran.krampe＠bluefish.se 23 Jun '03

23 Jun '03

Hi Serge, fellow Guides and all! Serge Stinckwich <Serge.Stinckwich(a)info.unicaen.fr> wrote: > Le sam 21/06/2003 à 13:59, Marcus Denker a écrit : > > Hi, > > > > Anyone interested in maintaining Scamper? SqueakMap says: > > > > Scamper > > Summary: Installs the Scamper web browser application > > Author: Lex Spoon > > Maintainer: Nobody yet > > Registrant: Adam Spitz > > > > At least we need someone who collects ENH/FIXes from the list, send > > [closed] message and, from time to time, make a new release... > > > > Marcus > > I would like to help Squeak dev, but don't want to be part of a core > part. So if no one make an objection, i could register to maintain this > package. Goodie! To keep things simple then - I am moving this message over to the SqF-list and keeping you in the To: field if you are not on that list. Fellow Guides: Can we agree to place Serge as a Steward for Scamper? :-) When (I assume this) the other Guides approve you, you can email Adam Spitz to get the password for the registration and then edit it. You could fix the summary while you are at it btw (that it "installs" is not really interesting). Then I will sign you up on this page: http://minnow.cc.gatech.edu/squeak/3088 Read a bit more btw on http://minnow.cc.gatech.edu/squeak/3091 regards, Göran

2 1

Re: [Squeakfoundation]Just let me know if I lose my time and yours
by Daniel Vainsencher 23 Jun '03

23 Jun '03

Hi Stef. I think so far KCP has given us changes that are definitely for the better. Where I thought that some changes are wrong, I said it (things that should be class extensions, but implemented on Kernel classes). Andreas' warning to find good concepts for classes before moving them sounds like a good idea to me. I think there are a lot of places we could take ideas from (other big projects have preferences/utilities too, or maybe deal with some of the same functionalities). Where you are not sure you have a clear concept, it might be better to delay working on it until later. But so far, so good. I think people do understand the importance of what you're doing, and that's why you're getting comments and suggestions. Daniel Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: > I do it because I feel > it important. > Now if you think that I'm over cleaning, over refactoring, if you think > that I'm > creating too much classes and that Squeak should stay the way it is, > Stef

8 23

Squeak downloads
by Andreas Raab 23 Jun '03

23 Jun '03

Hi Guys, I had recently the need to review the download and installation of Squeak on various platforms and to be honest - it's a mess. If you try to find your way around Squeak.org's download area you get lost so incredibly fast, it's amazing that some people manage to get Squeak anyways. Since I know that all of you are busy, I've done some work on it. My proposal is to link from Squeak.org directly into the main Squeak Swiki and there, provide a download page as can be seen at: http://minnow.cc.gatech.edu/squeak/3262 Let me say a few words about what I'm trying to do here. First of all, the point is to download Squeak not to look at funny pictures. The eye-candy at Squeak.org is certainly nice but when it comes to download we want those files - and nothing more. So there are quite deliberately no icons on this page. Secondly, I think people often look for documentation of Squeak most of which is found at the Swiki. Hosting the download page at the Swiki itself means that *everyone* who has ever downloaded Squeak has seen the Swiki at least once. That's what the first sentence in the above is for - so people know they are now at the right place. In addition, using a Swiki means we can much more easily change and update things. When a new version gets out we just change it and then, as the latest platform bundles come in, update the information appropriately. The download area at the Swiki also means we have a more level playing ground for alternative ports (you may see that one entry lists MobVM which is otherwise impossible to find). About the contents of the download table: * "full" means a bundle that absolutely includes everything you need to run Squeak. As we don't provide this for all packages we may have some missing entries. However, it's a Swiki so it's simple for people to make one up on their own and we just link it. * "image" means image+changes+sources for the listed "stable" version of that platform. Nothing is more bothering than to see that a BeOS port exist but not to know what one needs to download. * "stable VM" means the latest stable VM known to run well for the listed stable version of Squeak. Therefore, "image" + "stable VM" is everything you need if you haven't a full package available * "VM source code" explicitly links to the source code for the VM in question. Many people find it extremely hard to find the sources for VMs so here we can point them directly towards it. In addition, we have an "info" link which allows us to link to specific places for some VM/port. This allows us to decouple the primary download place from information such as port maintainer, release notes, specific bits about the platform. All of this is useful information but it should be hosted elsewhere. Based on the above download page, I figure that a new Squeak release process (exemplified with 3.6) would consist of the following steps: a) we make a copy of the current download page and name it appropriately (such as "DownloadsForSqueak3.5") - this is now a "previous version" b) change the latest stable version and link to the previous version. In effect this means you can always wander backwards through all the old versions and get - for example - exactly the "right" VM for Squeak 3.2 or so. Therefore we only need to link to some previous versions here. c) Update the links for the "primary" full/image packages which Bruce handles. >From here on, we can leave everything as is. If we have some platform maintainer who wants to update his or her port, she can simply update "her row" in the table. So it's a very simple, straightforward and obvious process which means that if people are interested they have a single place where they can download about everything that's interesting about Squeak. What do you think? Cheers, - Andreas

11 13

Re: [Squeakfoundation]Squeak downloads
by Daniel Vainsencher 22 Jun '03

22 Jun '03

I like the design. The security concerns seem a bit bogus to me - the download page was always on the swiki, and it's not that hard to change the link to point to some "warez" FTP site full of appropriately named trojans. Harder than with the new scheme, but not very hard. I think we can switch to this layout, and handle security lazily - start worrying after the first attack. Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi Guys, > > I had recently the need to review the download and installation of Squeak on > various platforms and to be honest - it's a mess. If you try to find your > way around Squeak.org's download area you get lost so incredibly fast, it's > amazing that some people manage to get Squeak anyways. > > Since I know that all of you are busy, I've done some work on it. My > proposal is to link from Squeak.org directly into the main Squeak Swiki and > there, provide a download page as can be seen at: > > http://minnow.cc.gatech.edu/squeak/3262 > > > Let me say a few words about what I'm trying to do here. > > First of all, the point is to download Squeak not to look at funny pictures. > The eye-candy at Squeak.org is certainly nice but when it comes to download > we want those files - and nothing more. So there are quite deliberately no > icons on this page. > > Secondly, I think people often look for documentation of Squeak most of > which is found at the Swiki. Hosting the download page at the Swiki itself > means that *everyone* who has ever downloaded Squeak has seen the Swiki at > least once. That's what the first sentence in the above is for - so people > know they are now at the right place. In addition, using a Swiki means we > can much more easily change and update things. When a new version gets out > we just change it and then, as the latest platform bundles come in, update > the information appropriately. The download area at the Swiki also means we > have a more level playing ground for alternative ports (you may see that one > entry lists MobVM which is otherwise impossible to find). > > About the contents of the download table: > * "full" means a bundle that absolutely includes everything you need to run > Squeak. As we don't provide this for all packages we may have some missing > entries. However, it's a Swiki so it's simple for people to make one up on > their own and we just link it. > * "image" means image+changes+sources for the listed "stable" version of > that platform. Nothing is more bothering than to see that a BeOS port exist > but not to know what one needs to download. > * "stable VM" means the latest stable VM known to run well for the listed > stable version of Squeak. Therefore, "image" + "stable VM" is everything you > need if you haven't a full package available > * "VM source code" explicitly links to the source code for the VM in > question. Many people find it extremely hard to find the sources for VMs so > here we can point them directly towards it. > > In addition, we have an "info" link which allows us to link to specific > places for some VM/port. This allows us to decouple the primary download > place from information such as port maintainer, release notes, specific bits > about the platform. All of this is useful information but it should be > hosted elsewhere. > > Based on the above download page, I figure that a new Squeak release process > (exemplified with 3.6) would consist of the following steps: > a) we make a copy of the current download page and name it appropriately > (such as "DownloadsForSqueak3.5") - this is now a "previous version" > b) change the latest stable version and link to the previous version. In > effect this means you can always wander backwards through all the old > versions and get - for example - exactly the "right" VM for Squeak 3.2 or > so. Therefore we only need to link to some previous versions here. > c) Update the links for the "primary" full/image packages which Bruce > handles. > > >From here on, we can leave everything as is. If we have some platform > maintainer who wants to update his or her port, she can simply update "her > row" in the table. So it's a very simple, straightforward and obvious > process which means that if people are interested they have a single place > where they can download about everything that's interesting about Squeak. > > What do you think? > > Cheers, > - Andreas > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

5 4

RE: [Squeakfoundation]re: TrueType font support and 3.6
by Daniel Vainsencher 22 Jun '03

22 Jun '03

I'll take that as a reminder that we haven't yet created the official submission/review policy we talked about last week. Here's a draft - Code submitted should be the simplest thing that could possibly work (*), where "work" is defined as providing the functionality promised (ENH) or correcting the bug (FIX) without creating others. (*) note that this precludes, among other forms of complexity - 1. Dead code that does nothing. 2. Extensions to existing classes that are not strictly required for the code to work. 3. Breaking or undoing other peoples changes. Andreas, does this help? Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi Daniel, > > > > If alpha is closed without the TTF stuff > > > it means you've delayed the most important improvement to > > > Squeak's user interface in the last three years. > > Have you ever failed a test because you didn't put in the > > effort and had to do it over? did you blame the teacher for > > writing the test? > > Yes, but in these situations the rules were clear to me and I knew what > exactly I should have done differently. > > Again: Please explain to me what your desired code quality is. What measures > do you use? What are the rules? > > > You may see things so that you think that I'm delaying this code, but > > this code could easily be cleaner, and you know it, and you can do > > something about it just as easily as me. > > Only if I know the rules. Otherwise I can only wait until there is some > critique here or there and depending on your workload this may take days, > weeks, or months. > > > [Conflicts are hard to find] > > Well, yes. Do you think that the fact that conflict detection is hard > > means that we should ignore it? > > You lost me here. Finding potential conflicts with other packages is quite > simple once you've got the stuff loaded. Just go into a dual change sorter > and choose "conflicts with other change sets" and it'll list you all of > them. Then you turn on the diffs and voila! all your conflicts get nicely > highlighted. Fixing them can be a different matter though ;-) > > > [DecPools and KCP] > > The fact that conflicts with packages are hard to solve is a sad > > consequence of not having package releases. It is made more > > difficult by having more packages, but the solution is not > > in going back to a monolithic image, but in improving our > > infrastructure (SM1.1). > > You lost me again. I don't see how the above is related to my question about > how to handle a concrete case in a concrete situation. Please explain. > > > Wish I could give you a release date for that, but I can't. > > I sure hope it's soon. I already started to manually mirror important > packages in order to be able to rely on the right versions. It sucks like > hell but there's nothing else I can do. > > > When we're talking about a package, like RB, what I did was fork it into > > two packages. When we're talking about a patch like DecPools, I would > track > > the current alpha, because the version for an old 3.6 won't be > particularly > > useful to anyone. > > I think it's quite valuable to have it available for older Squeak versions. > The point is that someone may want to load a package which contains a > declarative pool in something like 3.4/3.5. Having the package at SqueakMap > means that they have at least a chance to try it. > > Cheers, > - Andreas > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

RE: [Squeakfoundation]re: TrueType font support and 3.6
by Daniel Vainsencher 21 Jun '03

21 Jun '03

> No, we don't "all agree". That's my point. If you consider the above to be > serious flaws that need to be fixed then please explain to me what the > "desired code quality" is that you are trying to achieve. To me, this is > nit-picking. You don't, but Yoshiki agrees. I have no ideas what issues he is working on, and what their intersection is with the ones I raised but he's stated that we shouldn't integrate the current version. I don't consider the above to be "serious flaws". I consider the above to be the kind of small cruft that naturally accumulates when building something, and gets easily cleaned out *before* it gets integrated and forgotten, so that we don't one day need a TTFCP. You think this is nit picking, I think code should be clean as it can reasonably be. The price to clean it today is tiny compared to the price paid by everyone that will try to maintain the code in the future. > If alpha is closed without the TTF stuff > it means you've delayed the most important improvement to Squeak's user > interface in the last three years. Have you ever failed a test because you didn't put in the effort and had to do it over? did you blame the teacher for writing the test? You may see things so that you think that I'm delaying this code, but this code could easily be cleaner, and you know it, and you can do something about it just as easily as me. As for my role in this, I don't agree that welcoming cruft into Squeak arbitrarily is the way to advance it. I think this is clearly about values, and maybe about that "Vision" you were looking for so hard - I think Squeak's code should be something that people enjoy reading. I think much of the power Smalltalk has had over Smalltalkers' ideas comes from teaching them by example "this is how it should be". Cruft in the Basic Squeak image sabotages that effect, and makes Squeak weaker in something that really matters. I'm going over to a friend whom I'm teaching Smalltalk, we'll be looking at squeak code, and he'll be asking "why did they do that?" with all intention to learn something new. And I'll say to him, "Oh, no, ignore that, some people think it's ok to let cruft into the image (but look at the beautiful fonts it gives us!). Here, look at this bit, this one is good... well mostly". [Conflicts are hard to find] Well, yes. Do you think that the fact that conflict detection is hard means that we should ignore it? We can do the work at integration, or we can be surprised later by problems in releases newbies use. This extra work is the price of distributed development. The problems of unchecked conflicts will get worse with more contributors. BTW, feel free to try out and improve Dougs conflict checker. [DecPools and KCP] The fact that conflicts with packages are hard to solve is a sad consequence of not having package releases. It is made more difficult by having more packages, but the solution is not in going back to a monolithic image, but in improving our infrastructure (SM1.1). Wish I could give you a release date for that, but I can't. When we're talking about a package, like RB, what I did was fork it into two packages. When we're talking about a patch like DecPools, I would track the current alpha, because the version for an old 3.6 won't be particularly useful to anyone. Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi Daniel, > > > Do we disagree on the code, on the software engineering rule of thumb, > > on its application to this code, or on its application to > > Squeak code in general? > > We disagree on the terms "flaw" and "error". The issues you originally > mention may (depending on ones interpretation, certainly not mine - see > below) be seen as "flaws" but there are definitely no "errors" in what you > describe. None of them (not a single one) will prevent Squeak to function > correctly. > > > I don't see what this has to do with beta > > It has a whole lot to do with beta. If alpha is closed without the TTF stuff > it means you've delayed the most important improvement to Squeak's user > interface in the last three years. For reasons which I find impossible to > follow. > > > I also never required that conflicts be checked with "all > > ongoing work" - MCP is part of Squeak 3.6 as of 5240, IIRC. > > Conflicts with previously included work should be detected > > and resolved, of course - when we don't > > do this, we get the annoying "didnt I fix this already" effect. > > Are you aware that right now this is almost impossible? For example, I've > posted the declarative pools at SqueakMap and there are a few conflicts with > KCP changes. Fixing these conflicts means that suddenly noone in pre-3.6 > systems can load this any longer. So how do you propose to proceed in this > situation? > > I'd argue that what we want to do is to load the existing code base and fix > the conflicts as things get integrated. This leaves the package at SqueakMap > alone and will allow others to use it, too. > > [snip] > > On the other hand, the work hasn't been done yet to bring it up > > to the desired quality level. > > Desired by whom? Looking at your critique in detail: > > > - at least one method clashes with MCP. > > It's not "at least" one method but "exactly" one method and the conflict is > that some "verb first" has been reverted to "verb at: 1". > > > - The single GrafPort method sends to super but > > implicitly returns self. > > I don't get the point here. Why can't a method send to super and implicitly > return self? In any case, it seems that this method is just a left-over from > later improvements. > > > - Paragraph>>asForm does an "isKindOf: TTCFont" > > Again, what's your point here? Paragraphs have to know fonts or else they > can't function correctly. One can argue that using isKindOf: is generally > not good style (and I agree on this) but in this particular case the action > taken is so specific for TTCFonts that it makes perfect sense to use > #isKindOf:. > > > Claim I - We have a piece of code that's candidate for inclusion. We all > > agree it has flaws as detected by even cursory inspections. > > No, we don't "all agree". That's my point. If you consider the above to be > serious flaws that need to be fixed then please explain to me what the > "desired code quality" is that you are trying to achieve. To me, this is > nit-picking. > > Cheers, > - Andreas > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

RE: [Squeakfoundation]re: TrueType font support and 3.6
by Daniel Vainsencher 21 Jun '03

21 Jun '03

Hi Andreas - I'm confused too. Let's try to isolate the problem. Claim I - We have a piece of code that's candidate for inclusion. We all agree it has flaws as detected by even cursory inspections. Claim II - I percieve as a very obvious, general rule that at every stage of mixing code in with more of the real world, the price of fixing errors goes up, because problems are easier to solve in isolation. Therefore, make it work, make it right, then deploy wider. Conclusion - I claim this piece of code (and all others) should be fixed first, and accepted later. Do we disagree on the code, on the software engineering rule of thumb, on its application to this code, or on its application to Squeak code in general? I don't see what this has to do with beta - beta is there because inspections and isolated testing aren't perfect, not as an excuse to ignore them. I also never required that conflicts be checked with "all ongoing work" - MCP is part of Squeak 3.6 as of 5240, IIRC. Conflicts with previously included work should be detected and resolved, of course - when we don't do this, we get the annoying "didnt I fix this already" effect. This situation will always arise for each of us personally - we want to include something because it is cool functionality. On the other hand, the work hasn't been done yet to bring it up to the desired quality level. What will we do, every time we're in this bind? argue on SqF, or review on squeak-dev? Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Daniel, > > > A quicky partial review of v5 does > > show some things that could use some cleanup: > > - at least one method clashes with MCP. > > - The single GrafPort method sends to super but implicitly returns > > self. > > - Paragraph>>asForm does an "isKindOf: TTCFont" > > > > So IMO, this code doesn't belong in Basic, yet. > > Err ... excuse me, but the above issues sound exactly like the things one > would address in *beta* not in alpha. Requiring (for example) that there are > no conflicts with any other ongoing work is almost impossible - the > declarative pools have some conflicts too and I won't bother tracking all of > the yet-to-come KCP changes until I actually know them (as in: being > finalized and published). > > Seriously confused, > - Andreas > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

4 3

Re: [Squeakfoundation]KCP & 3.6
by Daniel Vainsencher 21 Jun '03

21 Jun '03

I disagree with the current calls to delay the release. If we wait for everyone to get whatever matters to them in, we might never make a release again :-) I don't see anything wrong with stuff waiting for 3.7 - DecPools included. I know a few of us feel "in the middle of" various projects, but I think the release process has value too - it reminds us to clean the table every so often. I think between the KCP deprecations and the network rewrite, we've had enough change that it will do us good to focus on stability before we keep moving ahead. More generally - if we think about the process as a whole, not just the particular point in time were in, the only right kinds of reasons to delay the move to beta are "it doesn't meet our functionality goals". A more specific example is "without this new function, all of this other stuff we inserted makes no sense AND it is hard to remove that stuff". Only right kind of reason to avoid moving from beta to gamma is "this version doesn't meet our stability goals". Which I think should be "this version should be stabler than the previous one". So a one week delay of beta to insert parts of KCP that relate to what's already in makes a little sense. Delaying by a month just to get more stuff in now that the harvesting process is livelier, seems unjustified to me - we can get that after the version fork. Speaking of which - at which stage do we create the 3.7 update stream? last time we did it on entry to beta, IIRC, yet some might say entry to gamma is more reasonable. What do we think? Daniel Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > I don't think we're anywhere near ready for beta right now; just for an > example in my area there is the DeclarativePools stuff to decide on. > > tim > -- > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > Strange OpCodes: KFP: Kindle Fire in Printer > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

9 21

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation June 2003