[squeak-dev] MC broken / how to update in 3.11 alpha?

Hi -

I was just doing some stuff in 3.10 when I decided to try the 3.11
alpha. First of all, can we *please* rename the image to 3.11 instead of
3.10.2 "bc"? The reason being that 1) I've never seen the designation
"build candidate" for any software project, and 2) it gets extremely
confusing when you have to distinguish "3.10.2" (which works fine) from
"3.10.2 bc" (which breaks). Much simpler to call 3.11 alpha what it is:
3.11 alpha.

Anyway, enough of that. What I noticed in 3.11 alpha (no I won't call it
3.10.2 bc ;-) is that apparently Monticello got badly broken. I have not
been able to load or browse any packages at all; every attempt to do so
died with the stack trace below.

At which point I thought I'll just see if that has been fixed already
(which I presume it probably has) but I couldn't for the hell of it find
out what the process for updating that image is. Can someone shed a
light on the process? Even better, write it up and put it into the
welcome window? (and while you're at it rename the image to 3.11 alpha
in case I haven't mentioned that ;-)

Thanks,
   - Andreas


VM: Win32 - a SmalltalkImage
Image: Squeak3.10.2bc-beta [latest update: #7179]

SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir
C:\Squeak\3.11\081216-1256-Squeak3.10.2bc-beta\081216-1256-Squeak3.10.2bc-beta
Trusted Dir
C:\Squeak\3.11\081216-1256-Squeak3.10.2bc-beta\081216-1256-Squeak3.10.2bc-beta\andreas
Untrusted Dir C:\My Squeak\andreas

UndefinedObject(Object)>>doesNotUnderstand: #addAll:
        Receiver: nil
        Arguments and temporary variables:
                aMessage: addAll: an OrderedCollection(a
MCClassDefinition(B3DEngineConstants) ...etc...
        Receiver's instance variables:
nil

[] in MCMczReader>>extractDefinitionsFrom: {[:rc |  reader := rc on:
member contentStream text.  definitions addAll: rea...]}
        Arguments and temporary variables:
                member: a ZipFileMember(snapshot/source.st)
                reader: a MCStReader
                rc: MCStReader

MCStReader class(Object)>>ifNotNilDo:
        Receiver: MCStReader
        Arguments and temporary variables:
                aBlock: [] in MCMczReader>>extractDefinitionsFrom: {[:rc |  reader :=
rc on: me...etc...
        Receiver's instance variables:
                superclass: MCSnapshotReader
                methodDict: a MethodDictionary(#addDefinitionsFromDoit:->a
CompiledMethod (1525...etc...
                format: 134
                instanceVariables: nil
                organization: ('as yet unclassified' addDefinitionsFromDoit:
categoryFromDoIt: ...etc...
                subclasses: {MCCsReader}
                name: #MCStReader
                classPool: nil
                sharedPools: nil
                environment: a SystemDictionary(lots of globals)
                category: #'Monticello-Base-Chunk Format'
                traitComposition: nil
                localSelectors: nil

MCMczReader>>extractDefinitionsFrom:
        Receiver: a MCMczReader
        Arguments and temporary variables:
                member: a ZipFileMember(snapshot/source.st)
                reader: a MCStReader
                rc: MCStReader
        Receiver's instance variables:
                stream: a RWBinaryOrTextStream a ByteArray(80 75 3 4 20 0 0 0 8 0 86
3 101 48 1...etc...
                package: a MCPackage(Balloon3D-Constants)
                info: a MCVersionInfo(Balloon3D-Constants-ar.4)
                definitions: nil
                dependencies: nil
                stepChildren: nil
                zip: a ZipArchive
                snapshot: nil
                infoCache: a Dictionary('005012f2-87f9-6342-b736-ac5003facd22'->a
MCVersionInfo...etc...


--- The full stack ---
UndefinedObject(Object)>>doesNotUnderstand: #addAll:
[] in MCMczReader>>extractDefinitionsFrom: {[:rc |  reader := rc on:
member contentStream text.  definitions addAll: rea...]}
MCStReader class(Object)>>ifNotNilDo:
MCMczReader>>extractDefinitionsFrom:
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[] in MCMczReader>>loadSnapshot {[:m | self extractDefinitionsFrom: m]}
OrderedCollection>>do:
MCMczReader>>loadSnapshot
MCMczReader>>snapshot
MCMczReader(MCVersionReader)>>basicVersion
MCMczReader>>basicVersion
MCMczReader(MCVersionReader)>>version
[] in MCHttpRepository(MCFileBasedRepository)>>loadVersionFromFileNamed:
{[:r | r version]}
MCMczReader(Object)>>ifNotNilDo:
MCHttpRepository>>versionReaderForFileNamed:do:
MCHttpRepository(MCFileBasedRepository)>>loadVersionFromFileNamed:
[] in MCHttpRepository(MCFileBasedRepository)>>versionFromFileNamed:
{[self loadVersionFromFileNamed: aString]}
Dictionary>>at:ifAbsent:
MCHttpRepository(MCFileBasedRepository)>>versionFromFileNamed:
[] in MCHttpRepository(MCFileBasedRepository)>>versionWithInfo:ifAbsent:
{[:fileName |  version := self versionFromFileNamed: fileName.  version
info ...]}
Array(SequenceableCollection)>>do:
MCHttpRepository(MCFileBasedRepository)>>versionWithInfo:ifAbsent:
MCHttpRepository(MCRepository)>>versionWithInfo:
MCVersionInfo>>loadVersionFrom:
MCRepositoryPackagesVersionsInspector(MCRepositoryVersionsInspector)>>load
PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction
PluggableButtonMorphPlus>>performAction
[] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: {[:m | (m
containsPoint: evt cursorPoint)   ifTrue: [m performAction]]}
Array(SequenceableCollection)>>do:
PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp:
PluggableButtonMorphPlus>>mouseUp:
PluggableButtonMorphPlus(Morph)>>handleMouseUp:
MouseButtonEvent>>sentTo:
PluggableButtonMorphPlus(Morph)>>handleEvent:
PluggableButtonMorphPlus(Morph)>>handleFocusEvent:
[] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.
ActiveEvent := anEvent.  result := focusHolder     han...]}
[] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]}
BlockContext>>on:do:
PasteUpMorph>>becomeActiveDuring:
...etc...

Andreas Raab wrote:
> Hi -
>
> I was just doing some stuff in 3.10 when I decided to try the 3.11
> alpha. First of all, can we *please* rename the image to 3.11 instead
> of 3.10.2 "bc"? The reason being that 1) I've never seen the
> designation "build candidate" for any software project, and 2) it gets
> extremely confusing when you have to distinguish "3.10.2" (which works
> fine) from "3.10.2 bc" (which breaks). Much simpler to call 3.11 alpha
> what it is: 3.11 alpha.
But it isn't 3.11 alpha. it has no changes to the base image, except
what are required to support loading LPF and make a 3.10 base image
usable for building production images using Sake/Packages. It is
designated 'beta' because subject to last minute snags (ahem!) it should
be release quality. I used to call it 3.10.2LPF, We could call it
build-base, or anything you like except 3.11alpha.

The difference with this process and previous releases, is that this
release is planned, there is a design, the tasks are in place, they just
need fleshing out. (at least thats the theory), so when these tasks are
ready and applied for the first time, that is when we call things alpha.

In the alpha you will see, classes moved to different places to tidy
things up, some stuff removed, some stuff renamed, deprecated methods
removed etc. I have already written that bit.

The "process" involves defining sets of tasks to create deliverables in
parallel. The application of fixes will be what makes things potentially
unstable so I dont want to over do it with too many so hopefully we wont
stay in alpha too long.

3.10.2bc -> 3.11tc -> 3.11rc -> 3.11-test -> 3.11-light -> 3.11-fun
(build0 - nofixes)
               -> 3.11tc -> 3.11rc -> 3.11-test -> 3.11-light ->
3.11-fun (build1 - 50 fixes) etc.

I am working on tasks to load fixes,
http://bugs.squeak.org/installer_export.php?project=Squeak only went
live yesterday. I also started harvesting edgars SqueakLightII script to
make a few more things unloadable to generate a 3.11-light etc.
> Anyway, enough of that. What I noticed in 3.11 alpha
It isnt 3.11 alpha, its a package of the tools I have been using to
produce production images for almost a year, with the addition of
Sake/Packages
> (no I won't call it 3.10.2 bc ;-) is that apparently Monticello got
> badly broken.
I didnt have this problem, I built an image on it so I have no idea what
is going on.

Keith
 

Andreas Raab wrote:
> Hi -
>
> I was just doing some stuff in 3.10 when I decided to try the 3.11
> alpha. First of all, can we *please* rename the image to 3.11 instead
> of 3.10.2 "bc"? The reason being that 1) I've never seen the
> designation "build candidate" for any software project, and 2) it gets
> extremely confusing when you have to distinguish "3.10.2" (which works
> fine) from "3.10.2 bc" (which breaks). Much simpler to call 3.11 alpha
> what it is: 3.11 alpha.
But it isn't 3.11 alpha. it has no changes to the base image, except
what are required to support loading LPF and make a 3.10 base image
usable for building production images using Sake/Packages. It is
designated 'beta' because subject to last minute snags (ahem!) it should
be release quality. I used to call it 3.10.2LPF, We could call it
build-base, or anything you like except 3.11alpha.

The difference with this process and previous releases, is that this
release is planned, there is a design, the tasks are in place, they just
need fleshing out. (at least thats the theory), so when these tasks are
ready and applied for the first time, that is when we call things alpha.

In the alpha you will see, classes moved to different places to tidy
things up, some stuff removed, some stuff renamed, deprecated methods
removed etc. I have already written that bit.

The "process" involves defining sets of tasks to create deliverables in
parallel. The application of fixes will be what makes things potentially
unstable so I dont want to over do it with too many so hopefully we wont
stay in alpha too long.

3.10.2bc -> 3.11tc -> 3.11rc -> 3.11-test -> 3.11-light -> 3.11-fun
(build0 - nofixes)
               -> 3.11tc -> 3.11rc -> 3.11-test -> 3.11-light ->
3.11-fun (build1 - 50 fixes) etc.

I am working on tasks to load fixes,
http://bugs.squeak.org/installer_export.php?project=Squeak only went
live yesterday. I also started harvesting edgars SqueakLightII script to
make a few more things unloadable to generate a 3.11-light etc.
> Anyway, enough of that. What I noticed in 3.11 alpha
It isnt 3.11 alpha, its a package of the tools I have been using to
produce production images for almost a year, with the addition of
Sake/Packages
> (no I won't call it 3.10.2 bc ;-) is that apparently Monticello got
> badly broken.
I didnt have this problem, I built an image on it so I have no idea what
is going on.

Keith

Keith Hodges wrote:
It's not "changes to the base image" that make a Squeak release. A
Squeak release is to a large extent the (versions of) packages shipped
with it. And yes, you can update them individually if you like but there
is a release process behind the included packages as well. If there
wasn't, we wouldn't include them to begin with. And the list of
new/updated packages in the welcome window alone is enough to give this
a 3.11 designation:

* SqueakMap - catalog/categories browsers
* Universes
* Installer
* SUnit
* Sake
* Packages
* Tasks
* SystemEditor
* Monticello 1.5 including:
        - PackageInfo
        - MonticelloConfigurations
        - File support
        - Orphanage
        - AtomicLoading (not enabled by default)

I mean, seriously, this is a ton of stuff! And it's quite a bit
different from 3.10 and it *does* include changes to the base image.
Given the amount of changes, that image really should not be called 3.10
any longer; you are only creating confusion by insisting this be called
3.10.

> The difference with this process and previous releases, is that this
> release is planned, there is a design, the tasks are in place, they just
> need fleshing out. (at least thats the theory), so when these tasks are
> ready and applied for the first time, that is when we call things alpha.

Then call the prior phase development, pre-alpha or whatever else you
like. But given the amount of modification I don't think you should
continue to refer to it as 3.10.

All of which is great. Though it would be good if you would communicate
about this more often so that there is some visibility of the process.

>> (no I won't call it 3.10.2 bc ;-) is that apparently Monticello got
>> badly broken.
> I didnt have this problem, I built an image on it so I have no idea what
> is going on.

Of course, right that moment Squeaksource goes down :-) Well, in any
case, when it's back up, try this. Point your MC to this repository:

MCHttpRepository
        location: 'http://www.squeaksource.com/Balloon3D'
        user: ''
        password: ''

And try to load or browse "Balloon3D-Constants-ar.4.mcz". When I do
this, I die with the trace that I sent. However,
Balloon3D-Constants-ar.5.mcz which was published from loading the above
into 3.10 will load fine. I think this is quite repeatable.

Cheers,
   - Andreas

> And try to load or browse "Balloon3D-Constants-ar.4.mcz". When I do
> this, I die with the trace that I sent. However,
> Balloon3D-Constants-ar.5.mcz which was published from loading the
> above into 3.10 will load fine. I think this is quite repeatable.
>
The first problem is that this file doesnt include snapshot.bin, which
results in it defaulting to reading source.st, yep this was broken.
Thanks for the test case.

Fixed in latest LPF, and you should be able to load the latest
Monticello.impl

Keith

 > I mean, seriously, this is a ton of stuff! And it's quite a bit
 > different from 3.10 and it *does* include changes to the base image.
 > Given the amount of changes, that image really should not be called
 > 3.10 any longer; you are only creating confusion by insisting this be
 > called 3.10.

      I agree. I would call this 3.11 alpha. I don't understand Keith's
hesitancy. If this causes us to use more minor version numbers in the 3
series, so be it; there's no shortage. :)


-C

[1] http://netjam.org/versions

--
Craig Latta
www.netjam.org

>>>>> "Craig" == Craig Latta <[hidden email]> writes:

>> I mean, seriously, this is a ton of stuff! And it's quite a bit
>> different from 3.10 and it *does* include changes to the base image.
>> Given the amount of changes, that image really should not be called
>> 3.10 any longer; you are only creating confusion by insisting this be
>> called 3.10.

Craig>      I agree. I would call this 3.11 alpha. I don't understand Keith's
Craig> hesitancy. If this causes us to use more minor version numbers in the 3
Craig> series, so be it; there's no shortage. :)

Keep in mind that the work to clean the license is being based on
3.10.2, and will become Squeak 4.0.  So, any other work that is targetting
3.10.2 as a base will have to be *rebased* on *top* of 4.0 to be accepted
in the 4.x stream of Squeak.

This is why we need to get Squeak 4.0 out quickly, so that further
revolutionary changes have a solid clean-licensed base.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion