Hey all,
It's been a while, but things are actually happening, Self-wise. I'll do up a email at some point, or you could drop by the Discord which I'm trying to hang out at.
However, I've got a question:
In the `tests` object, there are two methods which together form a test which is part of the VM Suite.
They are:
conversionPrologueTest = ( | | 'Testing conversion of method in prologue...' print. "shell useNIC." _Flush. [conversionPrologueTestLoop]. "browsing" (message copy receiver: self Selector: 'conversionPrologueTestLoop') fork. 1000 do: [ (vector copySize: 17 FillingWith: 0) asMirror removeAll. times delay: 1. '.' print. ]. 'ok' printLine. self).
and
conversionPrologueTestLoop = ( | v. vv. | v: vector copySize: 100. 1000 do: [vv: v at: 3 IfAbsent: 17. times delay: 1. '*' print.]. self).
If you run the test, it puts out a nice pattern of * and .
Dave left a comment: /Added in order to test the fix to the VM crashing that surfaced doing Klein export work in winter/spring 2003. -- David Ungar/
But sadly I am not any wiser :)
What was this for? Does this test still have a meaning and reason for existing?
- Russell
On Thu, Aug 17, 2023 at 16:30:36 +1000, Russell Allen wrote:
If you run the test, it puts out a nice pattern of * and .
Also this test seems to take a small eternity on my i386 reldbg build.
For comparison, a sparc -Og build on a 1GHz Ultra runs it in under a minute.
-uwe
Seeing as David hasn’t replied to Russell (yet?) I will offer a partial explanation:
Some of the tests are regression tests, designed to exercise a bug which has been fixed and to catch the (somewhat unlikely) possibility of it being reintroduced. To understand the bug, the test and the fix you’d need to look at the change log around the date the test was introduced. Some of the VM bugs found and fixed were extraordinarily narrow in the circumstances that trigger them and so the regression test can be impossible to understand in isolation, but they are usually abstracted from real-life code which exercised the bug. Perhaps David remembers more about this specific case (now 20 years old!) but I wasn’t actively working on the system at the time so can’t offer more info.
Mario
Dave left a comment: Added in order to test the fix to the VM crashing that surfaced doing Klein export work in winter/spring 2003. -- David Ungar
But sadly I am not any wiser :)
What was this for? Does this test still have a meaning and reason for existing?
Guys,
I am so sorry that I missed this message! Thanks, Mario, for replying!
Back in the day, patterns of *’s and .’s were used on line printers to print out pictures of…never mind. So, if the test doesn’t print out anything that looks like something… Wait a minute, that’s not right.
At first glance, I have no idea, but let me think…The 17 was just a placeholder I used. (“17 is the most random number…”) I think that the on-stack replacement was probably screwing up something like 3/5ths of the time. And the optimized stack frame would cause a crash when it went wrong. This may be the infamous bug that took 5 minutes at least to surface, when it did. Turned out that someone (Mario will know who, but I don’t mention his name here), writing the SIC, I think, used one-letter names for arrays containing the next free register? and another different one-letter-name for the next free stack location. In this case, the dynamic optimization resulted in the SIC using the wrong one-letter-name to allocate local variable sort of thing.
That’s my theory and I’m sticking to it.
Thanks for your patience,
- Dave
On Aug 30, 2023, at 4:12 PM, Mario Wolczko mario@wolczko.com wrote:
Seeing as David hasn’t replied to Russell (yet?) I will offer a partial explanation:
Some of the tests are regression tests, designed to exercise a bug which has been fixed and to catch the (somewhat unlikely) possibility of it being reintroduced. To understand the bug, the test and the fix you’d need to look at the change log around the date the test was introduced. Some of the VM bugs found and fixed were extraordinarily narrow in the circumstances that trigger them and so the regression test can be impossible to understand in isolation, but they are usually abstracted from real-life code which exercised the bug. Perhaps David remembers more about this specific case (now 20 years old!) but I wasn’t actively working on the system at the time so can’t offer more info.
Mario
Dave left a comment: Added in order to test the fix to the VM crashing that surfaced doing Klein export work in winter/spring 2003. -- David Ungar
But sadly I am not any wiser :)
What was this for? Does this test still have a meaning and reason for existing?
Self-interest mailing list -- self-interest@lists.selflanguage.org To unsubscribe send an email to self-interest-leave@lists.selflanguage.org
Must’ve been Cliff Click.
On Aug 30, 2023, at 4:23 PM, David Ungar ungar@mac.com wrote:
Guys,
I am so sorry that I missed this message! Thanks, Mario, for replying!
Back in the day, patterns of *’s and .’s were used on line printers to print out pictures of…never mind. So, if the test doesn’t print out anything that looks like something… Wait a minute, that’s not right.
At first glance, I have no idea, but let me think…The 17 was just a placeholder I used. (“17 is the most random number…”) I think that the on-stack replacement was probably screwing up something like 3/5ths of the time. And the optimized stack frame would cause a crash when it went wrong. This may be the infamous bug that took 5 minutes at least to surface, when it did. Turned out that someone (Mario will know who, but I don’t mention his name here), writing the SIC, I think, used one-letter names for arrays containing the next free register? and another different one-letter-name for the next free stack location. In this case, the dynamic optimization resulted in the SIC using the wrong one-letter-name to allocate local variable sort of thing.
That’s my theory and I’m sticking to it.
Thanks for your patience,
- Dave
On Aug 30, 2023, at 4:12 PM, Mario Wolczko mario@wolczko.com wrote:
Seeing as David hasn’t replied to Russell (yet?) I will offer a partial explanation:
Some of the tests are regression tests, designed to exercise a bug which has been fixed and to catch the (somewhat unlikely) possibility of it being reintroduced. To understand the bug, the test and the fix you’d need to look at the change log around the date the test was introduced. Some of the VM bugs found and fixed were extraordinarily narrow in the circumstances that trigger them and so the regression test can be impossible to understand in isolation, but they are usually abstracted from real-life code which exercised the bug. Perhaps David remembers more about this specific case (now 20 years old!) but I wasn’t actively working on the system at the time so can’t offer more info.
Mario
Dave left a comment: Added in order to test the fix to the VM crashing that surfaced doing Klein export work in winter/spring 2003. -- David Ungar
But sadly I am not any wiser :)
What was this for? Does this test still have a meaning and reason for existing?
Self-interest mailing list -- self-interest@lists.selflanguage.org To unsubscribe send an email to self-interest-leave@lists.selflanguage.org
Yeah, that’s the ticket!
On Aug 30, 2023, at 4:38 PM, Mario Wolczko mario@wolczko.com wrote:
Must’ve been Cliff Click.
On Aug 30, 2023, at 4:23 PM, David Ungar ungar@mac.com wrote:
Guys,
I am so sorry that I missed this message! Thanks, Mario, for replying!
Back in the day, patterns of *’s and .’s were used on line printers to print out pictures of…never mind. So, if the test doesn’t print out anything that looks like something… Wait a minute, that’s not right.
At first glance, I have no idea, but let me think…The 17 was just a placeholder I used. (“17 is the most random number…”) I think that the on-stack replacement was probably screwing up something like 3/5ths of the time. And the optimized stack frame would cause a crash when it went wrong. This may be the infamous bug that took 5 minutes at least to surface, when it did. Turned out that someone (Mario will know who, but I don’t mention his name here), writing the SIC, I think, used one-letter names for arrays containing the next free register? and another different one-letter-name for the next free stack location. In this case, the dynamic optimization resulted in the SIC using the wrong one-letter-name to allocate local variable sort of thing.
That’s my theory and I’m sticking to it.
Thanks for your patience,
- Dave
On Aug 30, 2023, at 4:12 PM, Mario Wolczko mario@wolczko.com wrote:
Seeing as David hasn’t replied to Russell (yet?) I will offer a partial explanation:
Some of the tests are regression tests, designed to exercise a bug which has been fixed and to catch the (somewhat unlikely) possibility of it being reintroduced. To understand the bug, the test and the fix you’d need to look at the change log around the date the test was introduced. Some of the VM bugs found and fixed were extraordinarily narrow in the circumstances that trigger them and so the regression test can be impossible to understand in isolation, but they are usually abstracted from real-life code which exercised the bug. Perhaps David remembers more about this specific case (now 20 years old!) but I wasn’t actively working on the system at the time so can’t offer more info.
Mario
Dave left a comment: Added in order to test the fix to the VM crashing that surfaced doing Klein export work in winter/spring 2003. -- David Ungar
But sadly I am not any wiser :)
What was this for? Does this test still have a meaning and reason for existing?
Self-interest mailing list -- self-interest@lists.selflanguage.org To unsubscribe send an email to self-interest-leave@lists.selflanguage.org
Self-interest mailing list -- self-interest@lists.selflanguage.org To unsubscribe send an email to self-interest-leave@lists.selflanguage.org
self-interest@lists.selflanguage.org
-
David Ungar -
Mario Wolczko -
Russell Allen -
Valery Ushakov