On 11/8/2010 1:30 AM, 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)
Only for an interim period and only if you intend to use VMMaker.
As for why I haven't just fixed it: For it to work correctly, I can't really see any way around choosing different paths based on whether either/both of the arguments are WideStrings.
Let's start with a more basic question: What is the supposed problem? It may require different code paths, but it may not. Depends on what exactly the problem is.
I was of the assumption you could only do type annotations in code primitives written this way, not lookup classes etc. I'd be delighted if that were incorrect, or there's some other way to differentiate the two my limited VM knowledge does not cover.
I imagine the match table part would have to be rewritten as well if one wanted to use it for Unicode-aware caseinsensitive search, there are 1050 1:1 upper/lowercase mappings in Unicode, last one at codepoint 66639. So in that case there's more work than one would expect, and a good solution would not be backwards-compatible either way.
See above. I'm not clear what problem you're trying to address; it would help to state that clearly - perhaps you have a test handy that illustrates the problem?
Cheers, - Andreas