Squeakfoundation March 2003

squeakfoundation@lists.squeakfoundation.org

27 participants
66 discussions

[UPDATES] 3.4 is now final
by Doug Way 03 Mar '03

03 Mar '03

Hello all, 3.4 is now finalized! I just issued an update offering the choice of moving a 3.4gamma image to 3.4, or to 3.5alpha. (Technically, the choice was already offered in an earlier update when 3.4gamma was created, but since the two update streams contain the same fixes, I offered the choice again.) A 3.4 final image/changes/readme .zip file is available on the ftp site, here: ftp://st.cs.uiuc.edu/Smalltalk/Squeak/3.4/ Please give this a quick test if you have a chance, just to make sure there are no major problems with the image. A major problem roughly meaning: any significant problem which was *not* in 3.4gammaOne. This image should be identical to 3.4gammaOne, except for incorporating the last update (5170), and some content changes in the Welcome... window, which were discussed on the SqF list (on Feb. 4 & 8). The 3.4 release is still not complete in the sense that the squeak.org downloads page has not been updated to point to the appropriate 3.4 bundles. When that is done, that will be the true "release date" for 3.4. Allowing a few days to make sure there are no major problems with this image, and also to create the release bundles with VMs, I think we should shoot for updating squeak.org in 3-4 days. Anyway, I'd like to thank Scott Wallace for spending time helping me get the update stream going, and with all of the release details. And, of course, thanks to all of SqC for "releasing" Squeak to the Guides and the community at large! - Doug Way

1 0

[UPDATES] 3.4 is now final
by Doug Way 03 Mar '03

03 Mar '03

1 0

Re: [Squeakfoundation]re: Outstanding 3.4 bugs?
by Daniel Vainsencher 03 Mar '03

03 Mar '03

What I'm getting at here is that we have some fixes backlogged, which it would be nice to get out into a release faster than the usual. I mean mostly the one that has project saving broken, and a few more. Also, it would be good, IMO, to exercise the process a bit more. Doug just did it the first time, maybe doing it again would let us know what takes time about it, what can be streamlined, what can be automated. It doesn't mean we have to commit to a 1 month release, and it doesn't mean that very many things have to go in. Since few things will change, there's less of a need for general exercising of the image, it's more important to make sure that the fixes get reviewed and tested properly. Which is also something we should improve, in order to speed up harvesting. I agree that stating "To get into 3.5, it has to posted, reviewed and tested by 2 independent Squeakers that know whereof they speak, before week n" will probably help. The remaining alpha time can be used to deal with the integration. I don't know how much time it'll take, let's just try to keep it light and quick. Daniel Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > > > Suggestion - make 3.5 a very short release, consisting mainly of getting > > as many fixes in as we can, and giving them a proper testing. It's an > > opportunity for us Guides to warm up at doing the whole process > > ourselves. I'm talking about a time scale of 1 month total - 2 weeks > > alpha, 1 week beta, 1 week gamma, release. > I find it just about impossible to imagine getting stuff done that > quickly given the geographic and chronologic spread of people involved. > It'll take more than two weeks before any decent number of people heve > even downloaded 3.4, let alone done anything much to find and fix any > bugs. > > For topics to cover > + relating to the vm, how about incorporating any removal of vm/slang > code that we can manage - JMM & I have been trying to get a decent > release of codegen stuff together and can probably produce a removal > update and re-install package. > + in the image, how about the remove-b3d etc changes? > + how about declaring that only fixes released by a certain date will > be considered and that after that only comment improvements will be > accepted ? > > tim > > -- > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > <-------- The information went data way --------> > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

[DOCS] Update of the very first page of Squeakfoundation Swiki needed
by Hannes Hirzel 01 Mar '03

01 Mar '03

Hi I did some tentative updating of http://swiki.squeakfoundation.org/squeakfoundation/1 Could somebody have a look at it and update if further please! Thank you -- Hannes

1 0

Re: [Squeakfoundation]Collecting tests?
by Daniel Vainsencher 01 Mar '03

01 Mar '03

Not yet. I'll give it a shot. Daniel Marcus Denker <marcus(a)ira.uka.de> wrote: > On Sat, Mar 01, 2003 at 01:59:32AM +0300, Daniel Vainsencher wrote: > > Why generate a class? this could make things hard to find. Just make a > > tool that adds a new method to "MiscTestCase". Maybe we won't accept > > this mess into the image <g>, but it makes adding a test trivial, and if > > it's good, it certainly can be maintained by someone on SM, and it's > > very easy to factor it out into it's own class in time. > > > Have you tried "Browser Unit Test Support" from SqueakMap? > > This definitly is a step in the right direction: > > Summary: Adds some unit testing support facilities in the browsers > Author: Romain Robbes > Maintainer: Romain Robbes > > Description: > > This package adds a few buttons to the browsers in order to have a better > integration of unit tests during class developpement. It enables you to > easily switch back and forth from a class and it's unit test, allowing the > same thing a the method level. It also adds a convenient way to run the > test of the current class, giving automatic feedback to the user. Moreover, > test creation is handled automagically if a class test/method test doesn't > exist yet (don't worry, the choice is up to you :-)). Last and not least, > it works for nearly all kinds of class browsers, and so integrates nicely > with the RefactoringBrowser and the StarBrowser. > > > Marcus > > -- > Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation]Collecting tests?
by Daniel Vainsencher 01 Mar '03

01 Mar '03

Why generate a class? this could make things hard to find. Just make a tool that adds a new method to "MiscTestCase". Maybe we won't accept this mess into the image <g>, but it makes adding a test trivial, and if it's good, it certainly can be maintained by someone on SM, and it's very easy to factor it out into it's own class in time. Daniel Mike Roberts <mike(a)mjr104.co.uk> wrote: > On Fri, Feb 28, 2003 at 05:39:52PM +0100, Andreas Raab wrote: > > Add a place to Squeak where it's _really_ easy to write a single > > test without having to make a class first > > > > I like your thoughts. How about a 'Test Pit' which is similar to a Workspace but allows you to write simple assertions about what you are testing. I can imagine how it would work but don't know how to implement it... (except in Python). Could you bind a subset of the methods of TestCase into the scope of the workspace so you could just write quick statements and then hit a button to do-it all and give you a quick result. Or maybe you could have a global QuickTest bound in the workspace which provided assert: deny: etc. Then you could possibly hit a button to generate a proper class for you after asking you for the name. If the text in the workspace only used the protocol of TestCase then it could just become the body of a test - you could neaten it up/ improve with the browser(s) later. > > The only thing I'm not quite sure about is getting the objects in that you want to test if they already exist somewhere. Maybe you could enable morph-workspace dropping, although I haven't played with that yet so I'm not exactly sure how that works. > > Does this sound like what you had in mind? > > If this was in the Tools flap then you could grab it out, write a test and then there could be suitable buttons for 'mail to list' etc. > > Mike > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

3 2

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 March 2003