Hi Marcel,
On Wed, Nov 23, 2022 at 2:20 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hmm... 1024 bytes in a ByteArray will be 1029 bytes on disk. So it's okay, I suppose. Interestingly, a DoubleByteArray is use 5142 bytes on disk. A WordArray uses 4101 bytes hmm... okay. Strange for the DoubleByteArray though...
IIRC these files include textual Smalltalk code for certain post-processing operations (if not, I apologise). So it may be worth-while "reading" the file in the FileList and seeing if there are any obvious differences between the generated files. I expect that there are a small set of privileged classes that have special support while others get more voluminous support.
Am 23.11.2022 11:13:09 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Aha! Thanks for the clarification! :-)
Best, Marcel
Am 23.11.2022 03:54:55 schrieb David T. Lewis lewis@mail.msen.com: On Tue, Nov 22, 2022 at 10:58:09AM +0100, Marcel Taeumel wrote:
Hi all --
Should the following work?
No, it should not work. And yes, it will lock up the image (confirmed on Linux 64-bit).
class := DoubleByteArray. size := 10. dummy := 123.
array := class new: size. array?? atAllPut: dummy.
(DataStream newFileNamed: 'numbers') nextPut: array; close.
stream := DataStream fileNamed: 'numbers'.?? load := stream readArray. stream close. load explore
DataStream>>readArray is a private method that will do bad things if you call it at the wrong time. In the example above, it reads a number from the wrong place in the stream (because it should not have been called at that point). This number is used to allocate an array with over 150 million 8-byte slots, leading to the apparent image lockup.
The fix would be to put the private methods into a method category labeled "private".
Dave