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:
Andreas Raab wrote:
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'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.
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.
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 craig@netjam.org 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.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Craig Latta -
Keith Hodges -
merlyn＠stonehenge.com