The Trunk: Collections.spur-ul.586.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Collections.spur-ul.586.mcz

commits-2
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

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections.spur-ul.586.mcz

Tobias Pape

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…
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections.spur-ul.586.mcz

Levente Uzonyi-2
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.

Levente

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections.spur-ul.586.mcz

Tobias Pape

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?


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections.spur-ul.586.mcz

Eliot Miranda-2


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?  

--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections.spur-ul.586.mcz

Tobias Pape

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


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections.spur-ul.586.mcz

Eliot Miranda-2
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

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





--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections.spur-ul.586.mcz

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections.spur-ul.586.mcz

David T. Lewis
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