Squeakfoundation June 2003

squeakfoundation@lists.squeakfoundation.org

30 participants
59 discussions

Re: [Squeakfoundation]Shepherding large enhancements
by Daniel Vainsencher 29 Jun '03

29 Jun '03

Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > Doug Way <dway(a)riskmetrics.com> wrote: > > > Although it's getting > > a bit late for 3.6alpha if we're moving to beta on Friday, but who knows... > I _really_ don't think that is a good idea. We really ought to get at > least the basic, decently reviewed and tested, stuff that we declared in > the image before changing to beta. We're not being pushed by any dumbass > marketing droid for a release date so let's take the luxury of at least > trying to achieve feature completion! Sorry, I'm lost. Are you saying that we should wait until someone reviews every single thing in the game plan? Does this include SM1.1 which isn't released yet? and Anthony's run time fixes, which nobody that understands exceptions is volunteering to review? I think we should release this weekend what we already have finished and reviewed, and see if someone can help along what didn't get ready, so they get in early in 3.7. > If someone can point me to where the code is I'll check out the > simulator changes so we can at least get _them_ done. Cool. Install BFAV from SM, filter by string "simulator". > In return I want > someone to review the DeclarativePools stuff. :-) Too late, AviB has already posted a quite positive review :-) I'll probably look and approve them today or tommorrow. Daniel

3 2

Re: [Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
by Anthony Hannan 27 Jun '03

27 Jun '03

Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: > Anthony Hannan wrote: > > Class>>becomeClass: otherClass - Become forward the other class and > > fix up the global dictionary and system organization as well. > Do you have some test for these one because I would like to know what > is the consequence limit of becomeClass: especially in terms of the > metaclass? Does it work on metaclass too? Yes, but I have taken this change out as well as several others because I don't use them anymore. If someone wants them I can post them in a separate package. > By the way what is the difference between literal equal and ==. I'm > sure there is one but your example does not bring that up front. > 'foo' = #foo, but ('foo' literalEqual: #foo) not. When compiling a method, multiple references to the same literal are combined together into a single literal and held in the compiled method. Suppose you have both 'foo' and #foo in your method. If the compiler uses #= it would incorrectly combine 'foo' and #foo. Hence it uses #literalEqual: instead. Previously this test was coded in long form in the compiler and other places like CompiledMethod>>= that tested for literals.. > I want to know if these protocols work well in subclasses > > SequenceableCollection>>allButFirstDo:,allButLastDo:,atLast:,atLast:put > > : > > ,copyGrowBy:copyWithFirst:,detectIndex:,reverseDetect:,slide:by:,with:w > > i > > thIndexDo: As far as I know they work in subclasses. Some of been removed like becomeClass: because they are no longer used. > I really think that we should not introduce this that way. > > Collection>>collectArray: - Same as collect: except always return an > > array. > Normally collect returns the same kind of collection that the one that > is iterated, so what are the other alternatives. > Anthony why do you need it and why (mycol collect: []) asArray or > myColl asArray collect: [] > does not work. I imagine that this is too costly. So why don't you > manipulate directly array or why do you need array at the end? Your right. I removed this. > > OrderedCollection>>bottom,top,pop,push,etc. - stack protocol. > I really have a problem with this one. because I will get an > orderedCollection sends it but I do not know what push means in > terms of OrderedCollection because I will be able to send other message > of orderedCollection to the collection and I can mess up everything. > so why don't you implement a Stack if you need one and we can this > class to the collection hierarchy. Your right again. I removed this stack protocol from Collection. And changed my code to use normal OrderedCollection protocol. > > Number>>extend: - Like #to: except designate the length instead of the last. > DNU (but did not get the time to look inside) I removed this one as well. > and also to the point of Smacc. Using if using the output of a > tool forces us to have the same license that the tool, I stop CS. > Because I use latex and it does not mean that my articles are GNU > license. Goran answered this. We want everything changeable within Squeak. Cheers, Anthony __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

2 1

re: reviewing the simulator fixes
by Daniel Vainsencher 27 Jun '03

27 Jun '03

Why is the simulator dependent on VMMaker? curious. Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > > > > If someone can point me to where the code is I'll check out the > > > simulator changes so we can at least get _them_ done. > > > > http://aspn.activestate.com/ASPN/Mail/Message/squeak/1662509 > OK, so far as I can see _none_ of this goes in the basic image and the > only issues are > a) remembering to rename a couple of things since I am proposing > renaming Test* to SmartSyntax* since it is a little less meaningless. > b) deciding whether the simulator stuff ought to be dropped in with the > VMMaker package or be kept as a separate but dependent package. > > This means that this punchlist item now also depends on DeclarativePools > :-) > > tim > -- > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > Useful random insult:- Got a life, but wasn't sure what to do with it. > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

6 7

Re: [Squeakfoundation]Shepherding large enhancements
by Daniel Vainsencher 26 Jun '03

26 Jun '03

I think you're completely right. Of these big projects, the ones that moved are the ones that had a harvester actively looking out for them, and moving them forward process wise. As someone doing some of this, I don't think we can "assign" anyone to work on these. Its more a question of whether other harvesters actually want to get involved with this aspect of the process. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > > 1 Removals > > 2 KCP > > 3 MCP > > 4 Anthony runtime enhancements (split in two - fixes and closures) > > 5 Craig's simulator fixes > > 6 mir Network rewrite > > 7 TrueTypeTextStyle > > 8 Diego look style enhancements > > 9 Replace fonts with AccuFonts (mainly in order to remove the old - > > people can now load additional nice fonts themselves anyway). > > 10 SM 1.1 > > 11 Inclusion of SM plus related packages in the release image (though > > maintained as packages, not directly by update stream). > > Here's our current 3.6 plan list of larger enhancements/tasks. Right > now, we have 4 1/2 of these done... maybe we'll get a couple more in > before the end of the week. They've been moving along somewhat slowly > for various reasons. > > For larger enhancements, specifically these ones singled out for the > 3.6 release, I wonder if it would help to assign a guide or harvester > as a "shepherd" for each one. Someone who would be responsible for > tracking progress on the enhancement and deciding when enough review > has happened and when it's ready to go in. Right now, there's not > really anyone responsible for most of these, so it sort of falls to me > to make sure something happens, or a random person complaining on one > of the mailing lists. I don't really have time to handle all of these > myself. > > I remember Goran hinted at something like this with his PROP proposal > or whatever it was. But just something simple like assigning people to > shepherd these items might help things get done. > > Does this make sense? > > - Doug > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

9 14

Re: [Squeakfoundation]Shepherding large enhancements
by Daniel Vainsencher 26 Jun '03

26 Jun '03

Amen to that. BTW, everyone is welcome to join the review fest going on in the final hours of 3.6alpha by installing the BFAV and reviewing/testing/ commenting something (even if its small). I intend to do some approving tommorrow, so stuff that gets enough loving and is ready still has a chance to get in. Daniel PS. You might want to look at http://minnow.cc.gatech.edu/squeak/3103 Jimmie Houchin <jhouchin(a)texoma.net> wrote: > Just wanted to make a few comments in the midst of the all the heat and > smoke, but no _anger_. :) > > Like many I am for the Squeak which can be anything you want it to be. > Server Squeak, Multimedia Squeak, OS Environment Squeak. > > I really like the TTF and New Look stuff. I would really like the visual > aspects of Squeak to be polished and shine, shine, shine. :) > > I understand those who want to honor the _Date_ committment. > I understand those who want to honor a _Feature_ committment. > I agree. :) > > I would like to encourage those who may be discouraged because of a > perception of slow progress. The perception of their goodies possibly > (but hopefully will now) not getting in due only becoming available just > prior to the _Date_. > > Understand that the process is not mature. > The tools are not mature. > > Much of the time during this _alpha_ period have been without Marcus as > Harvestor and without BFAV. > > From my perception the BFAV is enabling more people to step up to the > plate and contribute. As the tools and _process_ improve more people > will likely join in to help as the time committment might not be as high. > > We have much to be encouraged about. Please, please be encouraged and > not discouraged. The good things will make it into Squeak (via SM or > image). And please feel free to define what you call _good things_. > > I don't believe that the Guides/Community choosing to either continue > forward with 3.6 and _Date_ or delay the _Date_ to help the _Features_ > with hurt Squeak or the community. > > We need to allow the Guides and the Community and the Process to mature > the Process for all of us to fully grasp it. > > So whether the _Date_ is strictly adhered to or if a small 1-2 week > delay is introduced, we need to understand it doesn't make any of this a > normative part of the _Process_. It won't break anything. These are > growing pains. Be of good cheer. That is a good thing. It means progress. > > So please cheer up. > We have much to be thankful for and much to look forward to. > > Jimmie Houchin > Squeak Cheerleader > RA RA SHISH BOOM BA. ;) > (ahhhh! now I've shouted. :) > > > Proverbs 17:22 > A merry heart does good like a medicine: but a broken spirit dries up > the bones. > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Shepherding large enhancements
by Doug Way 26 Jun '03

26 Jun '03

> 1 Removals > 2 KCP > 3 MCP > 4 Anthony runtime enhancements (split in two - fixes and closures) > 5 Craig's simulator fixes > 6 mir Network rewrite > 7 TrueTypeTextStyle > 8 Diego look style enhancements > 9 Replace fonts with AccuFonts (mainly in order to remove the old - > people can now load additional nice fonts themselves anyway). > 10 SM 1.1 > 11 Inclusion of SM plus related packages in the release image (though > maintained as packages, not directly by update stream). Here's our current 3.6 plan list of larger enhancements/tasks. Right now, we have 4 1/2 of these done... maybe we'll get a couple more in before the end of the week. They've been moving along somewhat slowly for various reasons. For larger enhancements, specifically these ones singled out for the 3.6 release, I wonder if it would help to assign a guide or harvester as a "shepherd" for each one. Someone who would be responsible for tracking progress on the enhancement and deciding when enough review has happened and when it's ready to go in. Right now, there's not really anyone responsible for most of these, so it sort of falls to me to make sure something happens, or a random person complaining on one of the mailing lists. I don't really have time to handle all of these myself. I remember Goran hinted at something like this with his PROP proposal or whatever it was. But just something simple like assigning people to shepherd these items might help things get done. Does this make sense? - Doug

2 1

Harvesting Guidelines on Swiki
by Daniel Vainsencher 26 Jun '03

26 Jun '03

I added some philosophy to them, since they seemed very laconic, and what was there was very technical. Feel free to add what's still missing, argue about what's there... Andreas was right that for people to benefit from an explicit, open process, the rationales have to be documented... at http://minnow.cc.gatech.edu/squeak/3155 Another point to consider is that I'm not quite sure if non-harvesters will notice that it would do them good to read this, too. Maybe an added pointer in the right place would solve this? or maybe some of more general ideas should be on the new how to contribute to Squeak page (http://minnow.cc.gatech.edu/squeak/3279)? Ideas welcome. Daniel

1 0

Re: [Squeakfoundation]Shepherding large enhancements
by Daniel Vainsencher 26 Jun '03

26 Jun '03

diegogomezdeck(a)consultar.com wrote: > > SO WHY DO YOU WAKE UP NOW, INSTEAD OF WAKING UP A COUPLE OF WEEKS AGO > > WHEN WE FIRST SAID WHAT WASN'T GOING TO BE READY, AND START REVIEWING > > LIKE THERE'S NO TOMMORROW??? > > Am I suscribed to the same list than you? Yes, just not to the precise same point of view... :-) > I'm reading email like the stef's one for weeks! That's exactly the point - me too. And I've never seen an email saying "please have cool stuff in the release" ever result in progress. If Stef's email (or any of the others) had been saying "please delay the release, I promise to review NewLook until date X, but can't quite make the current deadline", that would have been something to talk about. Especially since the cool things have already *been done*, by you. If they're done now, for weeks, and people don't review them, why should we expect a delay in the release to help? [some of us ... want to do something else ... the process isn't enough - A. too much bureaucracy B. Configurations are missing] I've been fully awake since our previous way of making progress stopped working, sometime last year. Since then, I've worked at identifying the issues we'll need to deal with, and help change the community's system so that it won't choke on it. I don't think we're even nearly done, but I think we're much closer than a year ago, or even a release ago. But ideas on how to further reduce the work it takes, or increase the freedom to individual developers would of course be more than welcome. Maybe if you can be more specific about who "some of us" are, and what direction you want to go, we can together identify how to help you better. Daniel

1 0

RE: [Squeakfoundation]Shepherding large enhancements
by Daniel Vainsencher 26 Jun '03

26 Jun '03

I agree that time that goes by without us having package releases is pain. Every update that breaks compatibility demands a fork of affected packages, because we don't have releases to reflect the adaptation. But this seems to be dependent only on package releases and the update stream. How does the 3.6 release aggrevate this? One thing you may mean is that 3.6 will be disconnected from it's appropriate package version. My proposal was to release 3.6 as Full only, in effect making a release of the old type, as if we hadn't done the removals, except that the packaged application will now be updated as packages, like the SM related packages are (PackageInfo and friends). Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi Göran, > > A silent thought: > > IMHO SM1.1 can wait until early 3.7. Even if it breaks my > > heart to admit it. :-) > > It can't wait any longer than 3.6. I've mentioned this before but things > will get critical with 3.6. Once significant packages are permanently hosted > outside the Squeak image it means we'll have some serious trouble > maintaining these without SM1.1. For example, consider the VMMaker package - > if that gets "out of sync" during 3.7alpha we're really screwed. The same > holds for a number of packages but VMMaker is probably the most critical in > this regard. > > If we really want these packages to live permanently outside the image then > we need SM1.1. Everything else is going to be one big mess and the longer > (in terms of releases) we have to wait before it comes the worse it'll get. > > Cheers, > - Andreas > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation]Shepherding large enhancements
by Daniel Vainsencher 26 Jun '03

26 Jun '03

goran.krampe(a)bluefish.se wrote: > Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: > > >> > > > I'm against having a release on Friday. > > > > > > Just look at the BugfixArchive: There's a lot of stuff pending, which > > > really needs to be included. And my feeling is, that there's just > > > not enough "new" stuff in 3.6 to allow a new release: Like 3.5, we'd > > > get a "new release" nobody would use. > > > > Agree as I mention in one of my early emails. > > 3.6 should be sexy in terms of new stuff/clean/improvements. > > Let us make it really sexy. > > Hmmm. And then people - WHY DIDN'T YOU SAY THIS WHEN THE 3.6 PLAN WAS > POSTED??? Ahh, that is so right. And also - SO WHY DO YOU WAKE UP NOW, INSTEAD OF WAKING UP A COUPLE OF WEEKS AGO WHEN WE FIRST SAID WHAT WASN'T GOING TO BE READY, AND START REVIEWING LIKE THERE'S NO TOMMORROW??? Ok, got that out of my system, phew. Sorry ;-) BTW, I'm glad to see more people doing the BFAV thing, and advancing the process, but this doesn't clash with making a release in any way whatsoever. People can go on coding and reviewing and advancing Squeak right through beta and gamma - harvesters will simply have a slightly bigger pile when we enter 3.7 alpha. Daniel

3 3

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