Hi Nicolas, Tim, Jakob,
Note that LargePositive/NegativeInteger convert the magnitude as ByteArray. I presume we should do the same for negative SmallInteger... But the fact that two different (Small)Integer convert to the same ByteArray is a smell, isn't it?
Could you give me an example?
The VM won't do any flip of bytes (except at image startup if we restore on a platform with different endianness - untested, because we currently have no such platform).
Sorry, I should have expressed my question more clearly: will ByteArray adoptInstance: #(1 2 3 100 255 256) asWordArray perform any malloc/memcpy of all the data or will the VM just change the class membership of the existing object? Asking as a VM noob. :-)
I suggest that we implement SwapEndianness in RawBitsArray.
Sounds useful!
You make me think that I should use some BitBlt trick for Bulk Byte Swapping when we read/write an array!
It's funny to see how we have been choosing the same route as mainstream HPC: First implementing a dedicated graphics module (i.e., GPU/BitBlt) and making it fast, than (ab)using it for non-graphic operations that benefit from the same kind of optimizations (gzip compression, sound processing, etc.). :D But at least this approach properly modularizes a certain kind of computing-intensive operations, so when we adapt the BitBlt plugin to new GPU generations, gzip will become faster as well. :-)
This discussion started a while back (last October!) when I was having a problem with Seaside entity tag creation. I thought we pretty much concluded that #asByteArray wasn't a very good method name that had become misused in way too many ways.
As mentioned before, I do not insist on the name #asByteArray, but I would like to have the general functionality under whatever name in the trunk.
veryBasicNext sounds like a leaky abstraction to me. Isn't there any Stream implementation that will use #basicAt: on #next and #basicAtPut: on #nextPut:?
Apparently not! Canweaddthatplease? :-)
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2024-02-07T19:45:16+01:00, jakres+squeak@gmail.com wrote:
Am Mi., 7. Feb. 2024 um 17:12 Uhr schrieb <christoph.thiede(a)student.hpi.uni-potsdam.de>:
IMHO all integers should implement #asByteArray. By the way, Pharo 5+ and Squot also implement this on Integer.
To be more precise, the extension comes from FileSystem-Git and I had to copy the method from Pharo to get this to work without more changes. It is used when writing the Git repository files. Actually I cannot tell from the name of the message how many bytes it will produce for a small number. It will produce three bytes for 65536 and I wonder when that is the right thing to do...
By the way, I also dislike the duplication between #mimeDecode and #mimeDecodeToByteArray where the only difference is "nextPut: byte" vs "nextPut: byte asCharacter". Would it be reasonable to have #veryBasicNext and #veryBasicNextPut: on Stream and subclasses that map to #basicAt: and #basicAt:put: of the underlying collection? I tested it out; it works for me.
veryBasicNext sounds like a leaky abstraction to me. Isn't there any Stream implementation that will use #basicAt: on #next and #basicAtPut: on #nextPut:?
Kind regards, Jakob