Well, with the following script it seems I am able to embed all source code in trailers:
| trailer source key dict classes | dict := IdentityDictionary new. CompiledMethod allInstances do: [:aMethod | trailer := aMethod trailer. source := aMethod getSource. trailer sourceCode: source. dict at: aMethod put: (aMethod copyWithTrailerBytes: trailer). ]. dict keys asArray elementsExchangeIdentityWith: dict values asArray.
Problem is that after executing the script, when a method is recompiled from the system browser, it puts back a trailer with a .changes pointer :( I will see if I find where I can change that.
In another thread, Stefan Marr asked "Is there any general use for such an embedding, beside making the finder usable?" I would just give my answer: 1) From a design point of view, I think that CompiledMethodTrailer is the correct place where source code should be stored. 2) I can understand to put source code in files would make sense 20 years ago. But I don't think so anymore... a normal notebook has 8gb of RAM these days. 3) I think (I should measure it) that having source code in the image is faster, even thought that's the least I care about. 4) Ease the logic of pointers in the trailer... 5) Easy of versioning for a binary serializer ;) so for example in Fuel we can now be able to serialize compiled methods with trailer that have the source code. Hence, versioning it (Monticello) is easier. So...what I would do (that's just my opinion) is: 1) always store source code in trailer 2) do not use .sources anymore 3) Use .changes ONLY for recovery but not for getting source code (#getSource) 4) Provide a way to shrink an image for production cases where people is interested in image size. Can can very easily replace compiled methods trailers with empty trailers (zap) and then if it just happens that you need the sources..you decompile it. Maybe there are obvious drawbacks I am not seeing... Cheers -- Mariano http://marianopeck.wordpress.com