Eliot Miranda uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections.spur-ul.586.mcz ==================== Summary ==================== Name: Collections.spur-ul.586 Author: eem Time: 28 October 2014, 10:22:44.764 am UUID: 2412b3e4-6494-45ce-b462-0a783482d92b Ancestors: Collections-ul.586, Collections.spur-cmm.585 Collections-ul.586 patched for Spur by SpurBootstrapMonticelloPackagePatcher Cog-eem.212 Symbol table changes: - ensure that enumerations stay consistent - avoid read-write and write-write race conditions - added a safe #condenseNewSymbols method, which is a replacement for former unsafe methods (#shutDown: and #compactSymbolTable). It's also automatically triggered whenever there are more than 1000 NewSymbols. - deprecated #compactSymbolTable - updated some comments Note that interning many symbols is a bit slower, but thread safety is more important. =============== Diff against Collections-ul.586 =============== Item was changed: ==== ERROR === Error: Unrecognized class type 28 October 2014 5:24:06.757 pm VM: unix - a SmalltalkImage Image: Squeak3.11alpha [latest update: #8824] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /home/squeaksource Trusted Dir /home/squeaksource/secure Untrusted Dir /home/squeaksource/My Squeak MCClassDefinition(Object)>>error: Receiver: a MCClassDefinition(Character) Arguments and temporary variables: aString: 'Unrecognized class type' Receiver's instance variables: name: #Character superclassName: #Magnitude variables: an OrderedCollection(a MCClassVariableDefinition(CharacterTable) a M...etc... category: #'Collections-Strings' type: #immediate comment: 'I represent a character by storing its associated Unicode as an unsig...etc... commentStamp: 'eem 8/12/2014 14:53' traitComposition: nil classTraitComposition: nil MCClassDefinition>>kindOfSubclass Receiver: a MCClassDefinition(Character) Arguments and temporary variables: Receiver's instance variables: name: #Character superclassName: #Magnitude variables: an OrderedCollection(a MCClassVariableDefinition(CharacterTable) a M...etc... category: #'Collections-Strings' type: #immediate comment: 'I represent a character by storing its associated Unicode as an unsig...etc... commentStamp: 'eem 8/12/2014 14:53' traitComposition: nil classTraitComposition: nil MCClassDefinition>>printDefinitionOn: Receiver: a MCClassDefinition(Character) Arguments and temporary variables: stream: a WriteStream Receiver's instance variables: name: #Character superclassName: #Magnitude variables: an OrderedCollection(a MCClassVariableDefinition(CharacterTable) a M...etc... category: #'Collections-Strings' type: #immediate comment: 'I represent a character by storing its associated Unicode as an unsig...etc... commentStamp: 'eem 8/12/2014 14:53' traitComposition: nil classTraitComposition: nil [] in MCDiffyTextWriter(MCStWriter)>>writeClassDefinition: Receiver: a MCDiffyTextWriter Arguments and temporary variables: definition: a WriteStream s: a MCClassDefinition(Character) Receiver's instance variables: stream: a WriteStream initStream: nil --- The full stack --- MCClassDefinition(Object)>>error: MCClassDefinition>>kindOfSubclass MCClassDefinition>>printDefinitionOn: [] in MCDiffyTextWriter(MCStWriter)>>writeClassDefinition: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - String class(SequenceableCollection class)>>new:streamContents: String class(SequenceableCollection class)>>streamContents: MCDiffyTextWriter(MCTextWriter)>>chunkContents: MCDiffyTextWriter(MCStWriter)>>writeClassDefinition: MCDiffyTextWriter(MCStWriter)>>visitClassDefinition: MCClassDefinition>>accept: [] in MCDiffyTextWriter(MCTextWriter)>>visitInFork: String class(SequenceableCollection class)>>new:streamContents: String class(SequenceableCollection class)>>streamContents: MCDiffyTextWriter(MCTextWriter)>>visitInFork: MCDiffyTextWriter>>writePatchFrom:to: MCDiffyTextWriter>>writeModification: [] in MCDiffyTextWriter>>writePatch: SortedCollection(OrderedCollection)>>do: MCDiffyTextWriter>>writePatch: SSDiffyTextWriter>>writePatch: [] in SSDiffyTextWriter>>writeVersion:for: BlockClosure>>on:do: SSDiffyTextWriter>>writeVersion:for: [] in SSEMailSubscription>>versionAdded:to: BlockClosure>>on:do: SSEMailSubscription>>versionAdded:to: [] in [] in SSProject>>versionAdded: [] in BlockClosure>>newProcess |
On 28.10.2014, at 17:23, [hidden email] wrote: > Item was changed: > ==== ERROR === > > Error: Unrecognized class type Well, this is gonna be interesting in the future. Are SPUR MCZs now completely incompatible to non-spur MCZs? This would be terrible… |
On Tue, 28 Oct 2014, Tobias Pape wrote:
> > On 28.10.2014, at 17:23, [hidden email] wrote: > >> Item was changed: >> ==== ERROR === >> >> Error: Unrecognized class type > > Well, this is gonna be interesting in the future. > Are SPUR MCZs now completely incompatible to non-spur MCZs? > > This would be terrible… > SqueakSource. I shouldn't be hard to fix it for someone who knows how SqueakSource works, and what the new formats are. Levente |
On 28.10.2014, at 20:28, Levente Uzonyi <[hidden email]> wrote: > On Tue, 28 Oct 2014, Tobias Pape wrote: > >> >> On 28.10.2014, at 17:23, [hidden email] wrote: >> >>> Item was changed: >>> ==== ERROR === >>> >>> Error: Unrecognized class type >> >> Well, this is gonna be interesting in the future. >> Are SPUR MCZs now completely incompatible to non-spur MCZs? >> >> This would be terrible… >> > > No, but Spur has new class formats which are not recognized by SqueakSource. I shouldn't be hard to fix it for someone who knows how SqueakSource works, and what the new formats are. SqueakSource uses the available Monticello. This obviously means that the “old” monticello is incompatible to the Class formats of SPUR, right? |
On Tue, Oct 28, 2014 at 12:31 PM, Tobias Pape <[hidden email]> wrote:
Arguably. But simply update Monticello to Monticello-eem.592 or later and there's no problem. Can we not do that for the SqueakSource image? best, Eliot
|
On 28.10.2014, at 22:31, Eliot Miranda <[hidden email]> wrote: > On Tue, Oct 28, 2014 at 12:31 PM, Tobias Pape <[hidden email]> wrote: > > On 28.10.2014, at 20:28, Levente Uzonyi <[hidden email]> wrote: > > > On Tue, 28 Oct 2014, Tobias Pape wrote: > > > >> > >> On 28.10.2014, at 17:23, [hidden email] wrote: > >> > >>> Item was changed: > >>> ==== ERROR === > >>> > >>> Error: Unrecognized class type > >> > >> Well, this is gonna be interesting in the future. > >> Are SPUR MCZs now completely incompatible to non-spur MCZs? > >> > >> This would be terrible… > >> > > > > No, but Spur has new class formats which are not recognized by SqueakSource. I shouldn't be hard to fix it for someone who knows how SqueakSource works, and what the new formats are. > > SqueakSource uses the available Monticello. > This obviously means that the “old” monticello is incompatible to > the Class formats of SPUR, right? > > Arguably. But simply update Monticello to Monticello-eem.592 or later and there's no problem. Can we not do that for the SqueakSource image? Should be possible. But I have no access to it. While we are at it; can we make provisions for GemStone class formats? They differ ever so slightly and it is really hard to keep all in sync. We now have: Squeak/Pharo Class formats (ca Squeak 3.8 - Squeak 4.6/Pharo3.0) Squeak/Pharo SPUR Class Formats (current and possibly onward) GemStone class formats (somewhat mapped from the squeak ones) I did a bit of coding for the gemstone monticello version about one or two years back and the mapping between the known monticello class formats and gemstone class formats is a little fragile, I think. Best -Tobias |
Hi Tobias,
On Tue, Oct 28, 2014 at 3:03 PM, Tobias Pape <[hidden email]> wrote:
I wouldn't know, but perhaps you could take a look? I had to do very little to support a new format. The one method I needed to modify was MCClassDefinition>>#kindOfSubclass We now have: GemStone class formats (somewhat mapped from the squeak ones) best, Eliot
|
In reply to this post by Eliot Miranda-2
On Tue, Oct 28, 2014 at 02:31:38PM -0700, Eliot Miranda wrote:
> On Tue, Oct 28, 2014 at 12:31 PM, Tobias Pape <[hidden email]> wrote: > > > > > On 28.10.2014, at 20:28, Levente Uzonyi <[hidden email]> wrote: > > > > > On Tue, 28 Oct 2014, Tobias Pape wrote: > > > > > >> > > >> On 28.10.2014, at 17:23, [hidden email] wrote: > > >> > > >>> Item was changed: > > >>> ==== ERROR === > > >>> > > >>> Error: Unrecognized class type > > >> > > >> Well, this is gonna be interesting in the future. > > >> Are SPUR MCZs now completely incompatible to non-spur MCZs? > > >> > > >> This would be terrible??? > > >> > > > > > > No, but Spur has new class formats which are not recognized by > > SqueakSource. I shouldn't be hard to fix it for someone who knows how > > SqueakSource works, and what the new formats are. > > > > SqueakSource uses the available Monticello. > > This obviously means that the ???old??? monticello is incompatible to > > the Class formats of SPUR, right? > > > > Arguably. But simply update Monticello to Monticello-eem.592 or later and > there's no problem. Can we not do that for the SqueakSource image? > Good question. We should try it and find out. The source.squeak.org and squeaksource.com servers are now running on pretty much the same image, so if we can fix it for one we will fix it for both. I'll try to look into this soon if noone else gets to it first. Dave |
In reply to this post by Eliot Miranda-2
On Tue, Oct 28, 2014 at 03:21:15PM -0700, Eliot Miranda wrote:
> Hi Tobias, > > On Tue, Oct 28, 2014 at 3:03 PM, Tobias Pape <[hidden email]> wrote: > > > > > On 28.10.2014, at 22:31, Eliot Miranda <[hidden email]> wrote: > > > > > On Tue, Oct 28, 2014 at 12:31 PM, Tobias Pape <[hidden email]> wrote: > > > > > > On 28.10.2014, at 20:28, Levente Uzonyi <[hidden email]> wrote: > > > > > > > On Tue, 28 Oct 2014, Tobias Pape wrote: > > > > > > > >> > > > >> On 28.10.2014, at 17:23, [hidden email] wrote: > > > >> > > > >>> Item was changed: > > > >>> ==== ERROR === > > > >>> > > > >>> Error: Unrecognized class type > > > >> > > > >> Well, this is gonna be interesting in the future. > > > >> Are SPUR MCZs now completely incompatible to non-spur MCZs? > > > >> > > > >> This would be terrible??? > > > >> > > > > > > > > No, but Spur has new class formats which are not recognized by > > SqueakSource. I shouldn't be hard to fix it for someone who knows how > > SqueakSource works, and what the new formats are. > > > > > > SqueakSource uses the available Monticello. > > > This obviously means that the ???old??? monticello is incompatible to > > > the Class formats of SPUR, right? > > > > > > Arguably. But simply update Monticello to Monticello-eem.592 or later > > and there's no problem. Can we not do that for the SqueakSource image? > > > > > > Should be possible. But I have no access to it. > > > > While we are at it; can we make provisions for > > GemStone class formats? They differ ever so slightly > > and it is really hard to keep all in sync. > > > > I wouldn't know, but perhaps you could take a look? I had to do very > little to support a new format. The one method I needed to modify was > MCClassDefinition>>#kindOfSubclass Tobias, If you do anything with this, please let me know if I can help. Your own work on SqueakSource is more advanced than whatever we are currently running on squeak.org and squeaksource.com, but if you want or need access to those images I'll make sure you can get a copy. I don't think that we should make them publicly downloadable because they may contain passwords and personal information. Note that I am not really a squeaksource expert, I'm just trying to keep squeaksource.com running reliably. I'll try to update Monticello in a copy of the existing squeaksource.com image, but if you have something better that includes Gemstone support I would be happy to follow your lead if possible. Dave |
Free forum by Nabble | Edit this page |