-
mhaupt committed revision 61 to the Potato SVN repository, changing 13 files.
2008-10-27 10:25:09 UTC in Potato
-
Asking for the senders of #new produces a subscript out of bounds error in CompiledMethod(Object)>>at:.
2008-10-20 15:50:00 UTC in Potato
-
I've inserted some debugging output in BitBlt.loadBitBltFromWarping() now, and added even more debug outputs in the place where the failure occurs. (See the source code for details.)
I verified that the primitive in question does *NOT* fail when the same operation is run on the standard Squeak VM. So there must be something wrong with the implementation we've got.
2008-08-29 13:54:44 UTC in Potato
-
mhaupt committed revision 60 to the Potato SVN repository, changing 3 files.
2008-08-29 13:52:25 UTC in Potato
-
The problem is due to primitive 96 (copyBits) failing; I could track this down to BitBlt.loadBitBltFromWarping() which returns false. Perhaps it's an "expected" failure, but then, the image fallback should not lead to the observed problem.
2008-08-29 12:45:09 UTC in Potato
-
mhaupt committed revision 59 to the Potato SVN repository, changing 1 files.
2008-08-29 12:02:12 UTC in Potato
-
I performed some checks as suggested by Robert Wierschke; here are the results:
- the problem occurs both in images with 1-bit and 32-bit colour depth,
- it occurs for other parameters than 5 (e.g., 1, 3, 4, 50),
- the exact nature of the problem is that BitBlt gets a Fraction parameter, which is not allowed (see attached screenshot).
File Added: potato.MainSchnappschuss001.png.
2008-08-29 11:57:55 UTC in Potato
-
In trying to track down the source of this issue, it turned out that it was already present in SVN revision 1 of Potato. It's good to know that none of the primitive and special object handling code is involved, but it's not good either to have this problem. This will be dealt with in a dedicated branch based on the current trunk.
2008-08-29 09:46:24 UTC in Potato
-
This bug was most likely introduced during some primitive implementation work. As it exists in the trunk (rev. 39), it is possible that the Large****tiveInteger handling primitives are responsible. This will be dealt with in the Mandala branch. It is highest priority as it obviously breaks compatibility.
2008-08-29 09:31:28 UTC in Potato
-
mhaupt committed revision 58 to the Potato SVN repository, changing 3 files.
2008-08-29 09:28:21 UTC in Potato
