[ANN] 3.9a7004

3.9a7004
-------------
        fasterMorpic: optimized extension/properties code for number of sends
        -------
        Change Set: AutoDeselectToolFixes-wiz
        Author: (wiz) Jerome Peace
        For doubleClick to work in lists autoDeselect must be explicitly  
disabled. There are four places
         where This needs to be done on the tool end of thing.
        -------
        0003108: [quickFix] In 7002 selecting connector catagory or alpha p  
catagory gets a debug box.
        0002500: In6713 Sometimes a Legitimate request generates DNU  
PseudoClass>>isTraits
        0002991: [Fix] Workspaces initial extent is too large for most uses.
        0002151: Max number of literals checked in MethodNode instead of  
CompiledMethod
        0003128: [Fix] In 7002 Using browser buttons to ask for  
prettyprinting gets DNU Compiler>>asText
        0001048: [ENH] SystemNavigation>>allImplementorsOf:localTo:
        0002779: 3.9a-6721 theme... button on Services Browser gives 'key  
not found' walkback


3.9a7003
-------------

        Change Set: decorateFix-bf
        Author: Bert Freudenberg
        Bullet-proof browser against removed class
        ---------
        0001913: Make all implementors of #nextPut: to return the argument  
(instead of self)
        Changed some implementors of #nextPut: to return the argument (and  
not return self).
        This to be consistent with primitiveNextPut and all other  
implementors of #nextPut:
        kwl: As dicusses with Ken and Craig on #squeak IRC.
        --------
        0001733: [ENH][FIX] String-upToDep-huma
        Really deprecates SequenceableCollection>>#upTo: to #copyUpTo:
        --------
        PlusTools do not register in Filelist when not active
        -------
        0003049: fast window resizing needed
        0001596: [BUG][FIX] lurking signals in EventSensor
        -------
        - PolygonMorph.st from Connectors
        - cleanups for preference removal
        ------
         removed preferences
         #allowCelesteTell #useFileList2. #enableInternetConfig
         #browserNagIfNoClassComment #alternativeWindowLook
        #alternativeScrollbarLook #inboardScrollbars #fastSplitterResize
       

On Tue, 2006-02-28 at 19:26 +0100, Marcus Denker wrote:
> 3.9a7004
<snip lots of great detail>

> 3.9a7003
<more good stuff>

Marcus,

I want to thank you for continuing to actively progress 3.9a.  Even more
I really want to thank you for taking the time to provide so much useful
detail in your announcements to the list about each update.  This is the
sort of information that can often seem superfluous to some but can be
exceedingly valuable when trying to track down what happened when
because something seems to have gone wrong or simply due to curiousity.

I really appreciate it,

Ken

Ken Causey <ken <at> kencausey.com> writes:

A question from me, if I may: The breakdown of bugs-fixed-in-this-release that
Marcus has posted is indeed excellent - and very useful example for those of us
who are using Squeak at work (with a Mantis installation) of giving our testers
a build along with all the bugs fixed that they need to test.

So my question is: Is this breakdown generated automatically with some tool, or
by hand? If by tool - is it in Squeakmap? If not, is anybody writing one?

Ahem, I appear to have sneaked more than one question in there - apologies for
my wiley ways.

Cheers,
S

On 01.03.2006, at 11:24, Simon Kirk wrote:

embarrisingly

On 01.03.2006, at 13:11, Marcus Denker wrote:

Hmm... I wanted to check if the Dictionary in MacOS knows this word,  
but some key-combination
along ctrl-d actually sends a message. So consider this the be  
tripple - embarrassing (google-spell-corrected ;-))

So: No, by hand... but stuff like this should be automated... we need  
build-servers, test-server, better
per-project bug-tracking (integrated with SqueakSource)...

      Marcus

+ 100 :)

Thanks for pushing that release....
Will be back soon...I hope.

PS: I hope to have some good tests for collection this year. And a  
first test server by Nicolas Melin

On 28 févr. 06, at 19:48, Ken Causey wrote:

Me too - thank you Marcus, Jerome, Bert and all others.

Marcus, would it be possible to have a breakdown of that log you just
posted, suitable for folks who've been away from things ? I think:

-  the 700x numbers are release numbers, corresponding to release
announcements, uploaded images etc. Two "unstable releases" were
announced here.

- ------ separates logical changes or change sets, though probably not
actual changesets just at the moment ? No, it looks like the second one
was a changeset. One of these logical changes (updates ?) might include
fixes for many mantis issues (the 000xxxx numbers).

- changes sometimes have no author information. That means they've come
from.. where ?


Thanks
-Simon

Il giorno mer, 01/03/2006 alle 17.55 +0100, stéphane ducasse ha scritto:
> + 100 :)
>
> Thanks for pushing that release....
> Will be back soon...I hope.
>
> PS: I hope to have some good tests for collection this year. And a  
> first test server by Nicolas Melin

There is also Cees' Squeak On Fire system:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-December/098645.html

        Giovanni

On 01.03.2006, at 21:51, Simon Michael wrote:

> Me too - thank you Marcus, Jerome, Bert and all others.
>
> Marcus, would it be possible to have a breakdown of that log you  
> just posted, suitable for folks who've been away from things ? I  
> think:
>
> -  the 700x numbers are release numbers, corresponding to release  
> announcements, uploaded images etc. Two "unstable releases" were  
> announced here.

In 3.9a we are trying to use Monticello for managing the image...

The update numbers (700x) are the number of changesets put in the  
update stream. The changeset loads one package ("ScriptLoader") that  
then has a build-script,
mainly loading a set of Monticello packages from the squeaksource  
server, sometimes the scriptloader script  has a postscript when  
needed (e.g. deleting preferences).

>
> - ------ separates logical changes or change sets, though probably  
> not actual changesets just at the moment ? No, it looks like the  
> second one was a changeset. One of these logical changes  
> (updates ?) might include fixes for many mantis issues (the 000xxxx  
> numbers).

the text was done by hand and follows no logic ;-) the numbers are  
manits bug numbers, yes. I don't post the full description there, but  
when a
changeset was done with a nice preamble, I choose mostly to post that  
instead of the mantis number.

The best name for the release-numbers would be "build" I'd say: I  
load changesets (or fix stuff directly when seeing a simple to fix bug).
Then I commit regularly to the source.squeakfoundation.org  
repository. When changes have piled up to be big enough for making
it worth the effort, I make a build script, put in on the  
updatestream and upload an image.

As I said, the setup is far from perfect.... and we really need to  
improve it. e.g. updating is far too slow, and updating over multiple  
builds is broken...

I like MC as a versioning system (it should be speed up at bit...).  
But for providing what we had with the update stream it's not
as good... what I would like would be a mix of the two: MC builds  
changesets that it then loads. There is a feature in SqueakSource
that allows this to be done on the server an then cached (Bert  
implemented that). But this brakes down as soon as you change
the code in the image via a normal changeset or a postscript: The  
diff the server builds between version is not the diff between
the real images, as the postscript is ignored. But it should be  
possible to build a changeset when building the release image....
somehow, with taking the postscripts into account. This could then  
even set all MC data (e.g. version number) correctly, beeing a true  
diff.

This then should be available for people through the update stream,  
allowing for fast update without the need of having MC load
ad decompress and diff everything on all clients... anyone would like  
to try implementing that?

And besides that, we need to automate much much more... I would like  
to have a system where I can commit to SqueakSource,
and every night a build is done *completely* automatic, with image  
generation+upload, mail to list with changelog, generation
of a changeset for the updatestream, everything.

> - changes sometimes have no author information. That means they've  
> come from.. where ?

Either I have forgotten the author information (which would be bad,  
sorry to everyone who had that happen).
Or the change is from me (e.g. I refactored some code now that  
CompiledMethods know their Selector and Class,
or some small stuff, or stuff for the NewCompiler overrides/
ClosureRuntime merge).

        Marcus