Hi.
I was running the full test suite (which takes a LONG time), and it encountered a #halt in Decompiler>>pushTemporaryVariable:
When trying to figure out where this was, it appears to be in DecompilerTests>>testDecompilerInClassesCNtoCZ.
Appears to be because the image is now borked - unusuable. Any attempt to browse one of those classes or methods throws an error about the change file failing (primGetPosition: failed).
Is this related to the "don't log changes while tests are running"? Or something else.
Also, based on that test name, is it really and truely going through every class in the image an decompiling them?
Thanks, cbc
Hi Chris,
On Wed, Jun 13, 2018 at 8:34 PM, Chris Cunningham cunningham.cb@gmail.com wrote:
Hi.
I was running the full test suite (which takes a LONG time), and it encountered a #halt in Decompiler>>pushTemporaryVariable:
When trying to figure out where this was, it appears to be in DecompilerTests>>testDecompilerInClassesCNtoCZ.
Appears to be because the image is now borked - unusuable. Any attempt to browse one of those classes or methods throws an error about the change file failing (primGetPosition: failed).
Is this related to the "don't log changes while tests are running"? Or something else.
Something else. It is due to some serious bugs with the full block support that we get with the SistaV1 bytecode set. Full block support implies that blocks are now their own methods, rather than sequences of byte codes and literals embedded in the enclosing compiled method. I can see a problem in the Decompiler (the halt in Decompiler>>pushTemporaryVariable:) but also a possibly related issue in the debugger where stepping within a full block doesn't highlight the pc correctly. I'll be looking at these over the next few days (I have a priority that I'll have to squeeze this along side).
Also, based on that test name, is it really and truely going through every class in the image an decompiling them?
Damn right ;-)
Thanks,
cbc
_,,,^..^,,,_ best, Eliot
Hi Chris,
On Wed, Jun 13, 2018 at 8:34 PM, Chris Cunningham cunningham.cb@gmail.com wrote:
Hi.
I was running the full test suite (which takes a LONG time), and it encountered a #halt in Decompiler>>pushTemporaryVariable:
When trying to figure out where this was, it appears to be in DecompilerTests>>testDecompilerInClassesCNtoCZ.
Appears to be because the image is now borked - unusuable. Any attempt to browse one of those classes or methods throws an error about the change file failing (primGetPosition: failed).
Is this related to the "don't log changes while tests are running"? Or something else.
As stated earlier it is due to bugs in the decompiler/debugger (specifically block start to temp name mapping) in the full block regime. You should find this fixed in Compiler-eem.383/Compiler-eem.384. Thank you _very much_ for spotting this. It would have been an awful black mark on the new release.
[snip]
_,,,^..^,,,_ best, Eliot
On Sat, Jun 16, 2018 at 3:26 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Chris,
On Wed, Jun 13, 2018 at 8:34 PM, Chris Cunningham <cunningham.cb@gmail.com
wrote:
Hi.
I was running the full test suite (which takes a LONG time), and it encountered a #halt in Decompiler>>pushTemporaryVariable:
When trying to figure out where this was, it appears to be in DecompilerTests>>testDecompilerInClassesCNtoCZ.
Appears to be because the image is now borked - unusuable. Any attempt to browse one of those classes or methods throws an error about the change file failing (primGetPosition: failed).
Is this related to the "don't log changes while tests are running"? Or something else.
As stated earlier it is due to bugs in the decompiler/debugger (specifically block start to temp name mapping) in the full block regime. You should find this fixed in Compiler-eem.383/Compiler-eem.384. Thank you _very much_ for spotting this. It would have been an awful black mark on the new release.
Thank you for fixing it. Just verifying that it truly does work. And with a recent/decent cog/spur VM, the full decompiler test of all methods in the image really isn't that slow, either (fast, even - 45 seconds on my machine). Thanks, Chris
[snip] _,,,^..^,,,_ best, Eliot
On Sat, 14 Jul 2018, Chris Cunningham wrote:
On Sat, Jun 16, 2018 at 3:26 PM, Eliot Miranda eliot.miranda@gmail.com wrote: Hi Chris, On Wed, Jun 13, 2018 at 8:34 PM, Chris Cunningham cunningham.cb@gmail.com wrote: Hi. I was running the full test suite (which takes a LONG time), and it encountered a #halt in Decompiler>>pushTemporaryVariable:
When trying to figure out where this was, it appears to be in DecompilerTests>>testDecompilerInClassesCNtoCZ.
Appears to be because the image is now borked - unusuable. Any attempt to browse one of those classes or methods throws an error about the change file failing (primGetPosition: failed).
I've never seen this error before, but I know for sure that if you run ImageSegmentTest, it will break your image[1].
Levente
[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-June/199208.html
Is this related to the "don't log changes while tests are running"? Or something else.
As stated earlier it is due to bugs in the decompiler/debugger (specifically block start to temp name mapping) in the full block regime. You should find this fixed in Compiler-eem.383/Compiler-eem.384. Thank you _very much_ for spotting this. It would have been an awful black mark on the new release.
Thank you for fixing it. Just verifying that it truly does work. And with a recent/decent cog/spur VM, the full decompiler test of all methods in the image really isn't that slow, either (fast, even - 45 seconds on my machine). Thanks, Chris [snip] _,,,^..^,,,_ best, Eliot
squeak-dev@lists.squeakfoundation.org
-
Chris Cunningham -
Eliot Miranda -
Levente Uzonyi