The changes look quite reasonable to me; all they do is making some of the primitives a little more flexible with respect to execution from other places (which would break otherwise). The "user flag" in the CMs seems useful for a variety of applications (Islands just being one potential application for this flag). Given the ability to use named primitives for all but the most time-critical primitives, this looks like a reasonable choice (in particular considering that primitives in the range affected have never been used so there is no potential for breaking anything).
The only potential issue I could see is that primitiveStringReplace has a *slightly* different boundary check than the one being in 3.6a VMMaker. It is not clear to me whether the difference is intentional or not and (lacking any history information in the SAR file, sigh...) I can't see whether this was changed by VMMaker or by the Islands changed. In any case, it needs to be sorted out.
Cheers, - Andreas
< I'm a bug-fixing machine! >
This post brought to you by the BugFixArchiveViewer, a handy tool that makes it easy to comment on proposed fixes and enhancements for Squeak. For more information, check out the Web page for the BugFixArchiveViewer project: http://minnow.cc.gatech.edu/squeak/3214
< I'm a bug-fixing machine! >
"Andreas Raab" andreas.raab@gmx.de wrote:
The only potential issue I could see is that primitiveStringReplace has a *slightly* different boundary check than the one being in 3.6a VMMaker. It is not clear to me whether the difference is intentional or not and (lacking any history information in the SAR file, sigh...) I can't see whether this was changed by VMMaker or by the Islands changed. In any case, it needs to be sorted out.
Ah, but there are still timestamps there. Interestingly enough, the version in VMMakerBlahBlah is stamped "stamp: 'ls 8/18/1998 06:24'!" and the one in forgivingPrims.st is "stamp: 'ls 8/17/2000 17:36'!". So Lex is the culprit in either case; somebody arrest that man! I certainly didn't _deliberately_ alter the prim in the process of assembling the VMMaker code package.
Interestingly enough, it tunrs out that the older version istheone in theSqueakV3.sources and there is NO later version in the accumulated changes up to 3.6. Thus we must interrogate Lex in the Comfy Chair (Oh No, not the Comfy Chair!) which as we all know is in Room 101.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- They must have done a clean boot on him.
"Andreas Raab" andreas.raab@gmx.de wrote:
The only potential issue I could see is that primitiveStringReplace has a *slightly* different boundary check than the one being in 3.6a VMMaker. It is not clear to me whether the difference is intentional or not and (lacking any history information in the SAR file, sigh...) I can't see whether this was changed by VMMaker or by the Islands changed. In any case, it needs to be sorted out.
Under threat of the comfy chair, I must admit it was intentional. The idea, as I recall through the dim fogginess of time, was that you could now do a 0-length replacement--a noop--without the primitive failing. A 0-length replacement is specified by having the "stop" index be one less than the "start" index.
I'm struggling amazingly hard not to say any more about this tiny subject. I've now written and deleted 3-4 paragraphs! Let me just say that if this change continues to be annoying, I'd be fine with the check going back the way it was.
As for the previous changes, note that Islands happened in Squeak 2.8 and 2.9, and that my previous tweak to this method happened two years prior to Islands -- whatever version of Squeak that would be. Surely that would explain Tim's Twilight Zone observation of the method that was changed but yet never patched. It was patched in the 2.x update stream!
Lex
Hi Lex,
Thanks for clarifying this - actually my concern wasn't about changing it but rather that the current implementation might be buggy.
BTW, do you have a few test cases for the things you've done? They would be helpful both, for illustrating the changes as well as making sure that someone installing Islands isn't going to be screwed by accidentally using a VM that doesn't have those changes.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Lex Spoon Sent: Thursday, July 10, 2003 6:20 AM To: The general-purpose Squeak developers list Subject: Re: [ENH] VM tweaks for Islands project
"Andreas Raab" andreas.raab@gmx.de wrote:
The only potential issue I could see is that
primitiveStringReplace has a *slightly* different boundary check than the one being in 3.6a VMMaker. It is not clear to me whether the difference is intentional or not and (lacking any history information in the SAR file, sigh...) I can't see whether this was changed by VMMaker or by the Islands changed. In any case, it needs to be sorted out.
Under threat of the comfy chair, I must admit it was intentional. The idea, as I recall through the dim fogginess of time, was that you could now do a 0-length replacement--a noop--without the primitive failing. A 0-length replacement is specified by having the "stop" index be one less than the "start" index.
I'm struggling amazingly hard not to say any more about this tiny subject. I've now written and deleted 3-4 paragraphs! Let me just say that if this change continues to be annoying, I'd be fine with the check going back the way it was.
As for the previous changes, note that Islands happened in Squeak 2.8 and 2.9, and that my previous tweak to this method happened two years prior to Islands -- whatever version of Squeak that would be. Surely that would explain Tim's Twilight Zone observation of the method that was changed but yet never patched. It was patched in the 2.x update stream!
Lex
"Lex Spoon" lex@cc.gatech.edu wrote:
I'm struggling amazingly hard not to say any more about this tiny subject. I've now written and deleted 3-4 paragraphs! Let me just say that if this change continues to be annoying, I'd be fine with the check going back the way it was.
As Andreas said, so long as we know there is no major change intended we can be happy with either version. There are few things as disconcerting as finding a small looking change that makes you think it might actually be important but no known reason for it.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim The whole is the sum of its parts, plus one or more bugs
Incorporated into the VMMaker 3.6b package
< I'm a bug-fixing machine! >
This post brought to you by the BugFixArchiveViewer, a handy tool that makes it easy to comment on proposed fixes and enhancements for Squeak. For more information, check out the Web page for the BugFixArchiveViewer project: http://minnow.cc.gatech.edu/squeak/3214
< I'm a bug-fixing machine! >
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Lex Spoon -
Tim Rowledge -
tim＠sumeru.stanford.edu