[squeak-dev] category support fixes for MC1.5?
Locked
[squeak-dev] category support fixes for MC1.5?
 
|
Hi All,
we're using MC1.5 & I just had cause to reload all my packages in a fresh image and I've noticed that none of my class categories were moved over. The bug is that the category order exists only implicitly in the source/source.st element of the mcz and doesn't exist at all in the snapshot.bin so when loading loads from snapshot.bin one ends up with some essentially random category order. Anyone have fixes for this?
TIA
|
Re: [squeak-dev] category support fixes for MC1.5?
|
|
2009/3/26 Eliot Miranda <[hidden email]>:
> Hi All, > we're using MC1.5 & I just had cause to reload all my packages in a > fresh image and I've noticed that none of my class categories were moved > over. The bug is that the category order exists only implicitly in the > source/source.st element of the mcz and doesn't exist at all in the > snapshot.bin so when loading loads from snapshot.bin one ends up with some > essentially random category order. Anyone have fixes for this? > TIA > as a side note, are categoty order are that important? To me, its a browser who should care to show them in alphabetical order to ease finding a needed caterory , when they number are big (like in Object) > > -- Best regards, Igor Stasenko AKA sig. |
Re: [squeak-dev] category support fixes for MC1.5?
|
|
On Thu, Mar 26, 2009 at 1:09 PM, Igor Stasenko <[hidden email]> wrote: 2009/3/26 Eliot Miranda <[hidden email]>: For me yes. I depend on it. In a big class like StackInterpreter (Interpreter) a good category order is essential to my productivity. I spent an hour or two changing the category order in StackInterpereter and making sure things were logically laid out and (at least for me) the time was well worth it. I still have to use find method wildcard... more often than I'd like. Without the order (StackInterpreter has about 45 categories) finding things is hell. That's why I sent the first message,. When I loaded my package into a new image the category order was gone. I moved it across by hand, but that's tedious and shouldn't be necessary.
Alphabetical order is OK for some classses, especially if it is smart, as Vassili did in VisualWorks where initialize* comes first, then alphabetic nonprivate, then private*. But for the StackInterpreter I have initialisation/shell related categories, interpreter core categories, bytecode categories, primitive categories and then debuging and translation categories:
initialization interpreter shell message sending method lookup cache stack pages frame access handler search internal interpreter access
compiled methods jump bytecodes return bytecodes stack bytecodes send bytecodes common selector sends primitive support arithmetic integer primitives
arithmetic largeint primitives arithmetic float primitives comparison float primitives arithmetic primitive support control primitives indexing primitives indexing primitive support
I/O primitives I/O primitive support bitblt support image segment in/out memory space primitives object memory support object access primitives object format
other primitives plugin primitives plugin primitive support plugin support process primitives process primitive support sound primitives system control primitives
image save/restore callback support debug printing debug support utilities translation support Without it finding things goes slowly....
|
[squeak-dev] Re: category support fixes for MC1.5?
|
|
In reply to this post by Igor Stasenko
Igor Stasenko wrote:
> as a side note, are category order are that important? Yes. > To me, its a browser who should care to show them in alphabetical > order to ease finding a needed caterory , when they number are big > (like in Object) There is logical order (initialize comes first, then accessing, private goes last) that I usually stick to. But more importantly there is internal consistency. To me it makes a big difference to see, e.g., events accessing private filters initialize queries vs. initialize accessing events filters queries private (this is an example taken straight out of code that I'm looking at this very moment with MC having messed it up into the first form where I wrote it in the second form). At the very least MC should respect the intention of people who care. Cheers, - Andreas |
|
|
In reply to this post by Eliot Miranda-2
Eliot Miranda wrote:
> Hi All, > > we're using MC1.5 & I just had cause to reload all my packages in > a fresh image and I've noticed that none of my class categories were > moved over. The bug is that the category order exists only implicitly > in the source/source.st <http://source.st> element of the mcz and > doesn't exist at all in the snapshot.bin so when loading loads from > snapshot.bin one ends up with some essentially random category order. > Anyone have fixes for this? > checking the current MC1.5 it is saving category definitions in the snapshot.bin file. what version did you save it with? Keith |
Re: [squeak-dev] category support fixes for MC1.5?
|
|
On Sat, Mar 28, 2009 at 7:09 AM, Keith Hodges <[hidden email]> wrote:
Have you tested that a load of a package containing some large class not currently in your image loads with correct organization? (VMMaker is ideal).
Ours is derived from Monticello-avi.275. Checking differences is tedious because we've mapped _ to :=. But I see that Monticello-avi.277 doesn't allow the active repo to be switched mid commit, which is a fix I want (thanks Avi!). So once Ive merged I'll root around and try and give you a better answer.
|
|
|
Eliot Miranda wrote:
> > > On Sat, Mar 28, 2009 at 7:09 AM, Keith Hodges > <[hidden email] <mailto:[hidden email]>> wrote: > > Eliot Miranda wrote: > > Hi All, > > > > we're using MC1.5 & I just had cause to reload all my > packages in > > a fresh image and I've noticed that none of my class categories were > > moved over. The bug is that the category order exists only > implicitly > > in the source/source.st <http://source.st> <http://source.st> > element of the mcz and > > doesn't exist at all in the snapshot.bin so when loading loads from > > snapshot.bin one ends up with some essentially random category > order. > > Anyone have fixes for this? > > > Hi Eliot, > > checking the current MC1.5 it is saving category definitions in the > snapshot.bin file. > > > Have you tested that a load of a package containing some large class > not currently in your image loads with correct organization? (VMMaker > is ideal). (I dont have SystemEditor loaded or enabled though.) Keith |
Re: [squeak-dev] category support fixes for MC1.5?
|
|
On Sat, Mar 28, 2009 at 10:44 AM, Keith Hodges <[hidden email]> wrote:
Ah, sorry. That's not a good test. The order that you get is the order in which methods come in (which might be alphabetical). i.e. after the load the first category in your organization will be the category of the first method loaded, the second category will be the category of the next method not in the first category and so on. Since VMMaker-ar.118 has this organization anyway you won't see any change.
So... reorganize the categories in Interpreter in VMMaker-ar.118 so they're e.g. alphabetical, save that and ten load it into a fresh image and see what you get.
|
Re: [squeak-dev] Re: category support fixes for MC1.5?
|
|
In reply to this post by Andreas.Raab
On Mar 26, 2009, at 2:45 PM, Andreas Raab wrote:
> Igor Stasenko wrote: >> as a side note, are category order are that important? > > Yes. > >> To me, its a browser who should care to show them in alphabetical >> order to ease finding a needed caterory , when they number are big >> (like in Object) > > There is logical order (initialize comes first, then accessing, > private goes last) that I usually stick to. But more importantly > there is internal consistency. To me it makes a big difference to > see, e.g., > > events > accessing > private > filters > initialize > queries > > vs. > > initialize > accessing > events > filters > queries > private > > (this is an example taken straight out of code that I'm looking at > this very moment with MC having messed it up into the first form > where I wrote it in the second form). At the very least MC should > respect the intention of people who care. <apologies> <flippancy magnitude="high"> This is why for years, file explorers have preferred to present directories and files in the order you created them, rather than in alphabetical order. Every file manager worth its salt, knows that when a person lays out the contents of a folder, that presentation trumps all else. It's why we the unix mv command has the -o (--order) option, so that you can change the order your directory contents are stored and presented. I know when I'm sysadmining my box, I'm just always greatful that / Users shows up at the top. It's the obvious logical top choice. And / Applications at the bottom. With less important things like /Library and /temp in the middle. It's why Apple, those really smart UI guys, always allow you to rearrange your mailboxes and filters, rather than use alphabetical. And your photo categories. And you movies. And your iTunes playlists. I'm especially thankful for this in iTunes. There is a logical order to my smartlists: Hard Rock Classical Motivational Speeches Smalltalk Podcasts Cap'n Geech & The Shrimp Shack Shooters This is so much better than: Cap'n Geech & The Shrimp Shack Shooters Classical Hard Rock Motivational Speeches Smalltalk Podcasts It drives me nuts when people have changed the order to not match the logical order. </flippancy> </apologies> -- Travis Griggs Objologist "An idea, like a ghost, must be spoken to a little before it will explain itself." - Charles Dickens |
|
|
In reply to this post by Eliot Miranda-2
Eliot Miranda wrote:
> > > On Sat, Mar 28, 2009 at 10:44 AM, Keith Hodges > <[hidden email] <mailto:[hidden email]>> wrote: > > Eliot Miranda wrote: > > > > > > On Sat, Mar 28, 2009 at 7:09 AM, Keith Hodges > > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> wrote: > > > > Eliot Miranda wrote: > > > Hi All, > > > > > > we're using MC1.5 & I just had cause to reload all my > > packages in > > > a fresh image and I've noticed that none of my class > categories were > > > moved over. The bug is that the category order exists only > > implicitly > > > in the source/source.st <http://source.st> > <http://source.st> <http://source.st> > > element of the mcz and > > > doesn't exist at all in the snapshot.bin so when loading > loads from > > > snapshot.bin one ends up with some essentially random category > > order. > > > Anyone have fixes for this? > > > > > Hi Eliot, > > > > checking the current MC1.5 it is saving category definitions > in the > > snapshot.bin file. > > > > > > Have you tested that a load of a package containing some large class > > not currently in your image loads with correct organization? > (VMMaker > > is ideal). > VMMaker-ar.118 loaded in the correct order for me. > > > Ah, sorry. That's not a good test. The order that you get is the > order in which methods come in (which might be alphabetical). i.e. > after the load the first category in your organization will be the > category of the first method loaded, the second category will be the > category of the next method not in the first category and so on. > Since VMMaker-ar.118 has this organization anyway you won't see any > change. > > So... reorganize the categories in Interpreter in VMMaker-ar.118 so > they're e.g. alphabetical, save that and ten load it into a fresh > image and see what you get. > interpreter is only one Category. Are we talking about different things? I am beginning to think you are talking about method categories, rather than class categories. Keith |
Re: [squeak-dev] category support fixes for MC1.5?
|
|
On Sat, Mar 28, 2009 at 12:00 PM, Keith Hodges <[hidden email]> wrote:
Uh, yes :)
|
|
|
Eliot Miranda wrote:
> > > On Sat, Mar 28, 2009 at 12:00 PM, Keith Hodges > <[hidden email] <mailto:[hidden email]>> wrote: > > Eliot Miranda wrote: > > > > > > On Sat, Mar 28, 2009 at 10:44 AM, Keith Hodges > > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> wrote: > > > > Eliot Miranda wrote: > > > > > > > > > On Sat, Mar 28, 2009 at 7:09 AM, Keith Hodges > > > <[hidden email] > <mailto:[hidden email]> <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > > <mailto:[hidden email] > <mailto:[hidden email]>>>> wrote: > > > > > > Eliot Miranda wrote: > > > > Hi All, > > > > > > > > we're using MC1.5 & I just had cause to reload > all my > > > packages in > > > > a fresh image and I've noticed that none of my class > > categories were > > > > moved over. The bug is that the category order > exists only > > > implicitly > > > > in the source/source.st <http://source.st> > <http://source.st> > > <http://source.st> <http://source.st> > > > element of the mcz and > > > > doesn't exist at all in the snapshot.bin so when loading > > loads from > > > > snapshot.bin one ends up with some essentially > random category > > > order. > > > > Anyone have fixes for this? > > > > > > > Hi Eliot, > > > > > > checking the current MC1.5 it is saving category > definitions > > in the > > > snapshot.bin file. > > > > > > > > > Have you tested that a load of a package containing some > large class > > > not currently in your image loads with correct organization? > > (VMMaker > > > is ideal). > > VMMaker-ar.118 loaded in the correct order for me. > > > > > > Ah, sorry. That's not a good test. The order that you get is the > > order in which methods come in (which might be alphabetical). i.e. > > after the load the first category in your organization will be the > > category of the first method loaded, the second category will be the > > category of the next method not in the first category and so on. > > Since VMMaker-ar.118 has this organization anyway you won't see any > > change. > > > > So... reorganize the categories in Interpreter in VMMaker-ar.118 so > > they're e.g. alphabetical, save that and ten load it into a fresh > > image and see what you get. > > > I am feeling thick... "reorganise the categories in > Interpreter"... but > interpreter is only one Category. Are we talking about different > things? > > I am beginning to think you are talking about method categories, > rather > than class categories. > > > Uh, yes :) > correct order in the snapshot.bin The bad news is that, all the definitions go through a sorting process prior to loading in order to ensure that as much as possible loads. I think that we MC users must have got used to this state of affairs. Keith |
Re: [squeak-dev] category support fixes for MC1.5?
|
|
On 28.03.2009, at 21:07, Keith Hodges wrote: > Eliot Miranda wrote: >> >> >> On Sat, Mar 28, 2009 at 12:00 PM, Keith Hodges >> <[hidden email] <mailto:[hidden email]>> wrote: >> >> I am beginning to think you are talking about method categories, >> rather >> than class categories. >> >> >> Uh, yes :) >> > Ok, the good news is that the method definitions are stored in the > correct order in the snapshot.bin > > The bad news is that, all the definitions go through a sorting process > prior to loading in order to ensure that as much as possible loads. I > think that we MC users must have got used to this state of affairs. Even if reordering methods is necessary it should be simple to apply the right categorization afterwards, no? The reordering is a big issue for long-time Smalltalkers (and even more the intrusive practice of identifying extension methods and overrides by star categories). - Bert - |
|
|
Bert Freudenberg wrote:
> > On 28.03.2009, at 21:07, Keith Hodges wrote: > >> Eliot Miranda wrote: >>> >>> >>> On Sat, Mar 28, 2009 at 12:00 PM, Keith Hodges >>> <[hidden email] <mailto:[hidden email]>> wrote: >>> >>> I am beginning to think you are talking about method categories, >>> rather >>> than class categories. >>> >>> >>> Uh, yes :) >>> >> Ok, the good news is that the method definitions are stored in the >> correct order in the snapshot.bin >> >> The bad news is that, all the definitions go through a sorting process >> prior to loading in order to ensure that as much as possible loads. I >> think that we MC users must have got used to this state of affairs. > > > Even if reordering methods is necessary it should be simple to apply > the right categorization afterwards, no? > > The reordering is a big issue for long-time Smalltalkers (and even > more the intrusive practice of identifying extension methods and > overrides by star categories). > > - Bert - easily. But this will send older MC's back to parsing the source.st I held back to think it through, because this would be the first time that MC1.5 has saved snapshot.bin files that are not compatible with older MC1.0s. You appeared to think that this would be ok. Keith p.s. we are planning for a completely new improved format for 1.7 |
|
|
> The methodCategorization can be added to the MCClassDefinitions fairly > easily. But this will send older MC's back to parsing the source.st > > I held back to think it through, because this would be the first time > that MC1.5 has saved snapshot.bin files that are not compatible with > older MC1.0s. You appeared to think that this would be ok. > > Keith > > p.s. we are planning for a completely new improved format for 1.7 > > I have tested loading/saving VMMaker in both MC1.5 and Pharo's MC. To try it out, having loaded LevelPlayingField. (Installer url: 'http://www.squeaksource.com/mc/Monticello.impl-kph.643.mcz') bootstrap. Keith |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |