Hey guys, We need to be more organized about this - part of the changes you enumerate are included in the ones I posted on the 23rd.
The other things I did - * Give treatment 4 you describe to referencedClasses in the same class. Compile - MethodDefinition>>testLiterals self assert: (defn literals anySatisfy: [:e | e isVariableBinding and: [(e key = #Halt) & (e value = Halt)]]) BTW, you can just cut out the extra arguments on calls to ChooserMorph - they never did anything. They're out of whack with the RB, because I removed them there...
ducasse stephane ducasse@iam.unibe.ch wrote:
Could you poste your version on the squeak Foundation wiki ;) I was planning to do that but I'm ___really___ overloaded. I just the emails.
on 29/9/01 8:45 pm, Hans-Martin Mosner at hm.mosner@cityweb.de wrote:
Ok, so I've used Stef's Ginsu port, and with very little patching it ran very nicely in 3.1. Here's what I did:
- implement a method AlignmentMorph>>inset: (just returns self)
- changed UpdatingMenuItemMorph>>enablement: to ask the target and not
the wordingProvider 3. implemented ChooserMorph>>choose... with additional args (buttons+values+lines), which are silently ignored 4. changed MethodDefinition>>classReferences and ...>>globalReferences to use isVariableBinding instead of isKindOf: Association. BTW, does anybody know why the various Associationlike subclasses of LookupKey are not subclasses of Association?
Now I'm fooling around with the mechanism which moves definitions into and out of the Unmanaged package. It seems to do the wrong thing for clusters, because classes defined within different packages within the same cluster can't see each other. Seems like at least one of visibleClasses, allVisibleClasses, visibleClassNames and allVisibleClassNames is broken :-( Without really understanding the intended function of these messages, it looks to me that the overloaded definitions of visibleClasses in Cluster and Package shadows the one which seems most sensible to me, in Module...
Cheers, Hans-Martin
danielv@netvision.net.il wrote:
Hey guys, We need to be more organized about this - part of the changes you enumerate are included in the ones I posted on the 23rd.
Just shows how ill-organized I am :-( I think I remember reading somewhere about at least one of the issues, but could not find the place quickly, so I just started off with the ZIP file. Getting the current version of something out of n different sources, and combining things such that they work together is something I was never good at... Perhaps we need some kind of module and repository concept here :-)
BTW, I'm now working on producing a complete first modularization of the 3.1 image, but this will take some more time... Running the module builder again and again is somewhat time consuming.
Cheers, Hans-Martin
Henrik this would be really interesting to see if the concept of visibility used in Ginsu is applicable to your modules. Because we could use Ginsu as a tools to modularise the image, this way we could add functionality to Ginsu and use it as a slicing tools.
BTW, I'm now working on producing a complete first modularization of the 3.1 image, but this will take some more time... Running the module builder again and again is somewhat time consuming.
Hans-Martin just continue. This would be great if we could identify a gross architecture of the system and all the place to fix (where method have to be moved around...I should find some times to extract the fileList. I will try this week.
Stef
squeak-dev@lists.squeakfoundation.org