On Mon, Nov 08, 2010 at 10:30:21AM +0100, Henrik Johansen wrote:
Den 08.11.2010 04:28, skrev Andreas Raab:
On 11/7/2010 1:38 PM, Henrik Sperre Johansen wrote:
IMO the obvious solution is to fix the problem where it orginated, in the Pharo image.
Reverting would reintroduce getting invalid results from the plugin, without any workaround. Not really an option.
You could just fix the problem, you know :-) Seriously, if there's a bug in the plugin, perhaps we should fix that problem? After which reverting the method is obviously the correct solution for this problem.
Cheers,
- Andreas
Oh absolutely, you just have to add the disclaimer: "Only run this image with a VM built from VMMaker with an image version newer than XY (Pharo) or ZI (Squeak). :-) (Which is what I meant with reproducibility issues, btw)
Actually there is no problem with respect to image/VM compatibility at runtime. As long as the primitive has been built into the VM, it is going to work fine with any image that calls the named primitive.
But I think that Andreas is asking another question: What was the original motivation for renaming the method? And based on that, is there something that needs to be fixed in the primitive itself so that this will not be an issue? I don't really know the background on this myself, but it looks like there was a problem related to passing a WideString as a parameter to ByteString>>findSubstring:in:startingAt:matchTable:, and that the workaround in Pharo was to put an #isWideString check into #findSubstring:in:startingAt:matchTable: (which of course completely trashed the translation of #findSubstring:in:startingAt:matchTable: when translating to C).
The #isWideString check has a bad smell and suggests that there might be something that needs fixing in the primitive, after which the method could be reverted and everyone would be happy.
Unfortunately I am a modestly educated English speaker, so I am largely guessing as to the background on this issue ;)
Dave