Ok, well the ugly part of this is that we have some Slang in the base pharo, either as Slang code or doubling as primitive failure recovery code . Normally if we had say: primAddActiveEdgeTableEntryFrom: edgeEntry "Add edge entry to the AET." <primitive: 'primitiveAddActiveEdgeEntry' module: 'B2DPlugin'> (self canProceedAfter: self primGetFailureReason) ifTrue:[ ^self primAddActiveEdgeTableEntryFrom: edgeEntry ]. ^self primitiveFailed It would invoke the primitive 'primitiveAddActiveEdgeEntry' in the named plugin 'B2DPlugin' which is located either as a plugin, or compiled into the VM. If the primitive call fails or the primitive fails the call it would then execute the smalltalk failure code. In the case above it would execute the canProceedAfter: and either do the primAddActiveEdgeTableEntryFrom: or the primitiveFailed which would cause the walkback. So looking at var: varSymbol declareC: an example would be ByteString>>indexOfAscii: anInteger inString: aString startingAt: start | stringSize | <primitive: 'primitiveIndexOfAsciiInString' module: 'MiscPrimitivePlugin'> self var: #aCharacter declareC: 'int anInteger'. self var: #aString declareC: 'unsigned char *aString'. stringSize := aString size. start to: stringSize do: [:pos | (aString at: pos) asciiValue = anInteger ifTrue: [^ pos]]. ^ 0 This and others are in the MiscPrimitivePlugin, BUT BUT it's possible that aString isn't a byte or word array object, but understands size, and at: so the the C code will fail, but the Smalltalk code will run. Being clever here we are using the the method to contain both the smalltalk code and the Slang code because it's the same. So you can't remove the smalltalk code because it likely has a purpose in special cases. {"MiscPrimitivePlugin", "primitiveIndexOfAsciiInString", (void*)primitiveIndexOfAsciiInString}, {"MiscPrimitivePlugin", "primitiveCompareString", (void*)primitiveCompareString}, {"MiscPrimitivePlugin", "primitiveStringHash", (void*)primitiveStringHash}, {"MiscPrimitivePlugin", "primitiveConvert8BitSigned", (void*)primitiveConvert8BitSigned}, {"MiscPrimitivePlugin", "primitiveFindFirstInString", (void*)primitiveFindFirstInString}, {"MiscPrimitivePlugin", "primitiveDecompressFromByteArray", (void*)primitiveDecompressFromByteArray}, {"MiscPrimitivePlugin", "primitiveTranslateStringWithTable", (void*)primitiveTranslateStringWithTable}, {"MiscPrimitivePlugin", "primitiveFindSubstring", (void*)primitiveFindSubstring}, {"MiscPrimitivePlugin", "primitiveCompressToByteArray", (void*)primitiveCompressToByteArray}, Also see {"ADPCMCodecPlugin", "primitiveDecodeStereo", (void*)primitiveDecodeStereo}, {"ADPCMCodecPlugin", "primitiveDecodeMono", (void*)primitiveDecodeMono}, {"ADPCMCodecPlugin", "primitiveEncodeStereo", (void*)primitiveEncodeStereo}, {"ADPCMCodecPlugin", "primitiveEncodeMono", (void*)primitiveEncodeMono}, For inline: It's not quite clear if *all* code is in plugins since WarpBlt>>rgbMap: sourcePixel from: nBitsIn to: nBitsOut called via WarpBlt>>mixPix: pix sourceMap: sourceMap destMap: destMap called via WarpBlt>>warpBitsSmoothing: n sourceMap: sourceMap which might be called as a primitive failure case for primitiveWarpBits so you can't remove it. But maybe this is the only special case and you could put inline: in WarpBlt and remove from Object>> The same might apply to var: varSymbol declareC: but would you put that in the using class or retain in Object? Of course if your goal is to simplify Object you might consider moving it. However VMMaker likely would need to consider if it should extend Object. To fully remove var:declareC: & inline: I think you'd would end up with a method in Pharo, and a slightly different method in VMMaker, which isn't a good choice. On 23-Dec-08, at 2:20 PM, Stéphane Ducasse wrote:
Hi
I'm trying to learn something while reading Object methods. I was wondering whether var: varSymbol declareC: declString and inline: should not be put as Object extension in VMMaker instead of been kept in Object. Now I saw that these methods have senders in the image. Does it mean that part of the code of these senders can be executed when we consider that these two methods are doing nothing? This could be used to debug the code before generating C from it. are my hypotheses correct?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================