Squeak-dev February 2003

squeak-dev@lists.squeakfoundation.org

195 participants
766 discussions

RE: ComSwiki enhancement request (was Re: [ENH][DOC]MorphClassComment-efc)
by Brent Vukmer 28 Feb '03

28 Feb '03

So every newly-created class would automatically have a hyperlink to the appropriate Swiki page? Sweeeet...... -----Original Message----- From: Doug Way [mailto:dway@riskmetrics.com] Sent: Thursday, February 27, 2003 8:50 PM To: swiki-bugs(a)cc.gatech.edu; The general-purpose Squeak developers list Subject: ComSwiki enhancement request (was Re: [ENH][DOC]MorphClassComment-efc) I guess I've mentioned this before, but one simple solution would be to have an automatic link of some sort (or perhaps a menu item) from the class comment in the Squeak browser to open scamper on a corresponding swiki page about the class. This way, the swiki page could have more recent class comments if available, easily editable by anyone, as a sort of backup to the class comment in the image (which as we know is often missing completely). And this backup comment would be easily accessible from the class browser. However, we'd need a reliable way to specify a swiki page based on its name. Something like http://minnow.cc.gatech.edu/squeak?page=Morph should access the page "Morph" on the swiki. Right now, you can try something like http://minnow.cc.gatech.edu/squeak/morph but it doesn't work reliably (as in this case). I'm submitting this an an official ComSwiki enhancement request this time, if anyone feels like adding this feature. :-) - Doug Way Eddie Cottongim wrote: > > I had really only intended the swiki page to be a temporary work area. But I > do like the idea of some kind of linkage between internal and external docs. > > It would be nice if there was a way for the swiki to directly reflect the > comments in the image (like javadoc but more dynamically bound), have a way > to annotate them, and provide a way that people could harvest updated > comments to go into the image. Something like, "show me all the class > comments people have annotated/updated since #5183", and the harvester would > pick the ones he/she thought were improvements for inclusion with the image. > --I don't think you'd want the new comments to go in the image > directly/automatically. Too easy for junk to get in that way. > --Need to work out the semantics of what happens when the image comment is > updated: Probably the comment text would be updated, but old annotations > would stay. > > Maybe someone did that already. Just an idea. > > Eddie > > ----- Original Message ----- > From: "Brent Vukmer" <bvukmer(a)blackboard.com> > To: "The general-purpose Squeak developers list" > <squeak-dev(a)lists.squeakfoundation.org> > Sent: Thursday, February 27, 2003 11:38 AM > Subject: RE: [ENH][DOC] MorphClassComment-efc > > Looks great. What about putting a hyperlink to the Swiki page for this > class comment( assuming that page is up-to-date ), within the class > comment?

1 0

ClassBuilder fix, SqueakMap, and releasing 3.4
by Brent Vukmer 28 Feb '03

28 Feb '03

Andreas's fix for the ClassBuilder bug is now on SqueakMap. So is the suite of unit tests that Andreas created to test ClassBuilder. On the docs side, I've created the following chain of Swiki pages: "Documentation"->"Known Bugs"->"Known Bugs in 3.4"->"Adding instVar to ClassDescription breaks ClassBuilder" We have SqueakMap fix-love and Swiki documentation-love for the bug. Let's roll with the 3.4 release. Cheers, Brent

1 0

[ANN] SUnit test suite for ClassBuilder posted on SqueakMap
by Brent Vukmer 28 Feb '03

28 Feb '03

1 0

[ANN] MetaClassBuilderFix posted on SqueakMap
by Brent Vukmer 28 Feb '03

28 Feb '03

1 0

re: release prioritization
by Craig Latta 28 Feb '03

28 Feb '03

Hi Hannes-- > Not having a proper test culture in Squeak leads us to have this kind > of funny discussions. Perhaps you could elaborate as to what you consider a proper test culture. In the meantime, I think we do have a constructive process. In particular, we decided we wanted to make a release which supported SqueakMap. We did this, we tested it, and now we're going to release it. > Measuring risk just with a feeling in the guts? No; I think Doug is measuring risk by estimating the impact of leaving out changes on the system's likely audience. > "I feel like releaseing... I'm scary of metaclasses ....people don't use them anyway...". No one said that. :) > But there is no idea if a release is better then an old one on the > existing stuff or not. It's my understanding that we're gradually building up unit tests for the entire system. We're making progress. We're not there yet, but I don't think it should hold up releases, especially minor ones. > For me 3.4 will be a "release" which is not proper Smalltalk (in > the sense of the last 20 years) as it breaks in a fundamental way > without the fix by Andreas. There are many other fundamental bugs in the system, several of which have been in the system for many years. The assertion is that their impact on the usability of 3.4, particularly on its new functionality (SqueakMap), is low. > He really has done an *excellent job*. And the test case he > provided in just 30 minutes is wonderful! And the > community is not able to verify his fix in 3 days ?? I don't think anyone disputes the quality and verification of Andreas' fix. But the actual act of incorporating it into a release, and testing for errors that occur during that act, take time. Given the relatively low impact of that bug (even though that part of the system is indeed fundamental), there seems to be no disadvantage in deferring the fix to 3.5a. It seems to me that we were getting bogged down with a "just one more" mentality. Yes, a particular fix may take add three days to a release cycle, but these delays add up. For me, the delays make the Squeak project markedly less satisfying. Right now, I'd like to be able to tell newcomers "take a look at Squeak from squeak.org" and know that they'll get a release with SqueakMap support. > The 3.4 release was planned for the end of 2002. No we are two month > later. Four, actually. :) > I wonder where this time pressure comes from? Obviously, since this is a volunteer effort, there is no direct time pressure. Rather than time pressure, I think there is motivation; in this case, a motivation to support SqueakMap in the release that most newcomers will use. I also think it'd be good for us as a community to develop expeditious release skills. In my opinion, we were overrating the importance of several features and fixes with regard to the release schedule. > On the other side at least some customers do not want a buggy 3.4. Again, I posit that relatively few people are likely to encounter the bug to which you refer, and those who do will be eminently capable and motivated to ge the fix. If you disagree, let's hear your rationale. As you mentioned, the stakes are relatively low. I'm surprised that you're so upset at deferring the rest of the fixes. This is a minor release (3.x). I'd certainly like to be more conservative with release 4, but the sorts of fixes we're discussing now are what minor releases are for. > On the other side this discussion about "releases" is in some > sense a non issue as probably in the future we will have > different configurations which will be packed for various > target groups and automatically tested before releasing. Indeed. In fact, I think eventually the release artifact will be laughably tiny. > I could live with the idea of a buggy 3.4 if 3.5 for example > is planned for doing in two months time. Then 3.4 would > just be some kind of intermediary release. Precisely. :) > The heading speaks of "priorization". Where are > the plans for future releases? Non-existant! Clearly, then, now is the time to make the schedule. If you have suggestions, let's hear them. Remember that Squeak has never really had a priori feature/fix schedules before. I'm all for them. > Is there a check list what 3.4 should be? Yes. It was verbalized at the Squeak BOF at OOPSLA 2002, then discussed on the list, where consensus was (seemingly) achieved. The checklist consisted simply of "SqueakMap support". > You guides, please do your homework! This stuff needs to be done via public discussion; I don't think it's appropriate for the guides to come up with it by themselves. -C p.s. I'm not even going to touch the Microsoft comments. ;) -- Craig Latta improvisational musical informaticist craig(a)netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

Re: [Squeakfoundation] re: release prioritization (was "ClassBuilder problem")
by Daniel Vainsencher 28 Feb '03

28 Feb '03

I mean that we'll need a better mechanism than this for updating packages that are in the image. Putting them in the package will cause problems when, for example, a different change gets applied in the update stream. But I agree it's a good short term solution. Daniel Ned Konz <ned(a)bike-nomad.com> wrote: > On Thursday 27 February 2003 05:30 pm, Daniel Vainsencher wrote: > > 2. Archive viewer bug fix gets auto-installed by SARInstaller > > (which, btw, has it's own problems). > > Is there something I missed there? > > -- > Ned Konz > http://bike-nomad.com > GPG key ID: BEEA7EFE

1 0

Next generation XScale PXA255
by Yoshiki.Ohshima＠acm.org 28 Feb '03

28 Feb '03

Hello, From various sources (the first one I saw was Sumi-san's dairy web page:-), Toshiba is planning to release a PDA that uses revised stepping XScale chip called PXA 255. The rumor is that the bus speed (and bandwidth) is twice as fast as PXA 250. Hopefully they also fix the cache issue (and probably more issues I don't know) so that Squeak runs much faster on such PDAs. The dissapointment with the current XScale was rather big, but I'm now looking forward to PXA 255! Stay tuned, -- Yoshiki

1 0

Re: [Squeakfoundation]re: release prioritization (was "ClassBuilder problem")
by Hannes Hirzel 28 Feb '03

28 Feb '03

Hi Doug Doug Way <dway(a)riskmetrics.com> wrote: > > Okay, I'm very easily talked out of delaying the 3.4 release any > further :-) (and was having second thoughts after posting that last > message), so I agree with the prevailing opinion to leave this change > out and go ahead with the release. Well of course you guides can do anything you want "releasing" things, i.e. putting a label on a jar and call it a "release". Not having a proper test culture in Squeak leads us to have this kind of funny discussions. Measuring risk just with a feeling in the guts? "I feel like releaseing... I'm scary of metaclasses ....people don't use them anyway...". Releaseing something at the moment just means that enough new features have been added and the guides feel that people have not been complaining too much about new bugs. But there is no idea if a release is better then an old one on the existing stuff or not. Be assured the first thing I will do after downloading your release is to include the fix of Andreas and already I will not work on your "release" anymore. And many of the list members will just do the same. For me 3.4 will be a "release" which is not proper Smalltalk (in the sense of the last 20 years) as it breaks in a fundamental way without the fix by Andreas. He really has done an *excellent job*. And the test case he provided in just 30 minutes is wonderful! And the community is not able to verify his fix in 3 days ?? I wonder where this time pressure comes from? The 3.4 release was planned for the end of 2002. No we are two month later. So what? Are customers pressing somewhere? In fact that would be good. On the other side at least some customers do not want a buggy 3.4. MS projects often get delayed much longer and with the .NET initiative (an approach with a VM as well!) they want to do it "right", even if that causes delays! Again: where is the time pressure? There a good releases and others. Regards Hannes Hirzel P.S. On the other side this discussion about "releases" is in some sense a non issue as probably in the future we will have different configurations which will be packed for various target groups and automatically tested before releasing. I could live with the idea of a buggy 3.4 if 3.5 for example is planned for doing in two months time. Then 3.4 would just be some kind of intermediary release. P.S. 2 The heading speaks of "priorization". Where are the plans for future releases? Non-existant! Is there a check list what 3.4 should be? I didn't find it yet although as a member of the documentation team I had surfed a lot over the existing Squeak web pages and I was active at the mailing list. You guides , please do your homework!

2 1

Re: [FIX] ClassBuilder problem
by Hannes Hirzel 28 Feb '03

28 Feb '03

Doug Way <dway(a)riskmetrics.com> wrote: > A general question: Do you think this fix looks reasonably safe enough to > include with 3.4gamma? I was going to finalize 3.4 by tomorrow, but if we add > this, we would need to postpone the release by a few days at least to test > this a bit. Postponing? Yes! On the other hand, this is a sort-of important fix which may be > worth delaying 3.4 by a few days. You put it excellently! -- Hannes

1 0

[Squeakfoundation]re: release prioritization (was "ClassBuilder problem")
by Daniel Vainsencher 28 Feb '03

28 Feb '03

I second Craig - let's release. As I've said before, when thinking about adding any sort of fix at this point we need to weight the real cost of adding it (including risks that the bug fix is imperfect, or reveals another bug, or..) to the real cost of not adding it (remember we can back port a bug fix to a finalized version, after the change has been tested to death in the new development version, if we get complaints about it). In this specific case, IIUC, the analysis is like this - 1. Not that many newbies try to reshape ClassDescription. 2. Archive viewer bug fix gets auto-installed by SARInstaller (which, btw, has it's own problems). Therefore, release without it, patch later iff needed. Daniel Craig Latta <craig(a)netjam.org> wrote: > > Colin writes: > > > I think it would be worth delaying the release of 3.4 to include this > > fix. Having easy-to-install packages for Traits and Islands would be > > very beneficial. The more people can play around with and exercise > > that code, the better. > > I don't think that's a convincing rationale for inclusion in 3.4. The > 3.4 release is a vehicle for SqueakMap. I think only problems which have > a catastrophic effect on a newcomer's ability to use SqueakMap should > delay 3.4. > > Ned writes (on the Foundation list): > > > ...since Andreas just posted the ClassBuilder fix, I'm thinking that > > may be worth including and postponing the release by a few days for > > people to test. > > Why? (And I don't use question marks lightly in this message, since I > know they could cause more delay. :) > > > Since I'm doing that, I could also perhaps include Ned's recent > > ArchiveViewer fix, since I've looked at that and its seems > > straightforward and is a somewhat important fix. > > (: > > I don't think "somewhat important" cuts it at this release stage. > Instead, I think it's better to weigh the results of leaving something > out, rather than of including it. > > My recollection of our group discussions at OOPSLA, in November 2002, > were that we would take 3.2, add SqueakMap support to it, and release it > as 3.4. It is now February 2003. This surprises me, even given our > history. :) > > I think we should release 3.4 now, and defer all outstanding available > fixes into the 3.5a stream (subject to harvester approval). In our > current situation, I think anyone likely to encounter the bugs described > recently will be able to get them easily from the update stream. In the > meantime, newcomers will have easier access to SqueakMap sooner. I think > it's time to release. > > > thanks, > > -C > > -- > Craig Latta > improvisational musical informaticist > craig(a)netjam.org > www.netjam.org/resume > Smalltalkers do: [:it | All with: Class, (And love: it)] > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
77
Older →

Jump to page: