On Fri, 22 Feb 2008 18:43:37 +0100, Andreas wrote:
> Igor Stasenko wrote: >> Well, there is people who wish to see such capabilities, and if Spoon >> features orthogonal to your approach, then why not include them? > > Because there is cost associated with it. Probably some runtime cost > (which I haven't measured) but definitely cost in terms of added > complexity in the VM. > >> In this case both camps will feel suited with new VM and can use it in >> one way or another. > > My problem with this is that I cannot see any situation in which someone > would really want to rely on that mechanism. It seems to me that the > approach is (as you said in an earlier email) a way to create smaller > images "without much effort". I'm interested in the *hard* way of doing > this (i.e., by going in and refactoring and removing things manually) > because I think this is the only way in which it can be done in practice. As an example, in the 3.9 stock .image there are some 434 methods in just 49 classes which have directly to do (sending messages to one another) with compilation, class building, decompilation and context (#fork etc). Some 73 "system,kernel" classes (from magnitude, collection, stream, exception, traits) and some 21 supportive global instances (+classes for source code support and text/style support, +"misc") are referenced directly (by name) by the methods of the above. Lists with details are at the bottom. The references to #(PopupMenu, FileDirectory, FileStream, text/style support, SecurityManager, Sensor) can be moved out of the way of classes responsible for compilation, class building, decompilation and context, by refactoring and removing things manually. I could do the same analysis+report, with other details and/or constraints (I'm using my datalog query tool in Squeak) for the next layer, and between layers (example: the above 49 classes' methods v.s. collections, streams, magnitudes), for any reasonable .image, if that's interesting for Squeakers. /Klaus > But be that as it may - the real question is this: Let's assume we have > a tiny kernel image that is about 100k in size and that we can build up > from. What good is the mechanism at this point? It seems to me that it > is only useful to get to a small image but once this is achieved it's > basically obsolete. Right. That's why I'm doing analysis+report in a workspace and not in a fancy new UI :) > And I'm definitely not in favor to modify the VM for something that will > only have a very short window of usefulness. > > Cheers, > - Andreas > List of the 21 global instances (+source code support +text/style support +"misc"): #(#ColoredCodeStream #FileDirectory #FileStream #FullVocabulary #PopUpMenu #PrimitiveNode #Processor #RemoteString #ScreenedVocabulary #SecurityManager #Sensor #Smalltalk #SourceFiles #SyntaxError #SystemOrganization #TextConstants #TextMorphEditor #TextStyle #Transcript #UIManager #Undeclared) List of the 73 "system,kernel" classes, used by name by the classes at the bottom: #(#Array #Association #AttemptToWriteReadOnlyGlobal #Bag #Beeper #BlockCannotReturn #BreakpointManager #ByteArray #ByteString #ChangeSet #Character #ClassCategoryReader #ClassCommentReader #Date #Dictionary #DiskProxy #Duration #Error #ExceptionAboutToReturn #FileDoesNotExistException #Float #IdentityDictionary #IdentitySet #ImageSegment #ImageSegmentRootStub #InMidstOfFileinNotification #InstVarRefLocator #InstructionPrinter #LargeNegativeInteger #LargePositiveInteger #LocalSends #Message #MessageCatcher #MessageNotUnderstood #MethodDictionary #MethodReference #Number #Object #OrderedCollection #OutOfScopeNotification #ParserRemovedUnusedTemps #PositionableStream #Preferences #Process #ProtoObject #ProvideAnswerNotification #ProvidedSelectors #ReadStream #ReadWriteStream #Semaphore #SendInfo #SequenceableCollection #Set #SharedPool #SmalltalkImage #SortedCollection #String #Symbol #SyntaxErrorNotification #SystemChangeNotifier #SystemNavigation #SystemVersion #Time #TimedOut #ToolSet #TraitComposition #TraitCompositionException #UndefinedObject #UnhandledError #Utilities #WeakArray #WeakKeyToCollectionDictionary #WriteStream) List of the 49 classes which have directly to do with compilation, class building, decompilation and context: #(#AssignmentNode #BasicClassOrganizer #Behavior #BlockArgsNode #BlockClosure #BlockContext #BlockNode #BraceNode #CascadeNode #Categorizer #Class #ClassBuilder #ClassDescription #ClassOrganizer #CommentNode #CompiledMethod #CompiledMethodWithNode #Compiler #ContextPart #Decompiler #DecompilerConstructor #DecompilerConstructor #Encoder #Encoder #InstructionStream #KeyWordNode #LeafNode #LiteralDictionary #LiteralNode #LiteralVariableNode #MessageAsTempNode #MessageNode #MessagePartNode #Metaclass #MethodContext #MethodNode #MethodProperties #MethodTempsNode #ParseNode #ParseStack #Parser #Pragma #ReturnNode #Scanner #SelectorNode #SystemOrganizer #TempVariableNode #TileMessageNode #VariableNode) |
Free forum by Nabble | Edit this page |