On Jul 26, 2021, at 7:34 AM, Fabio Niephaus lists@fniephaus.com wrote:
Hi Eliot,
On Mon, Jul 26, 2021 at 4:26 PM Eliot Miranda eliot.miranda@gmail.com wrote: Hi Fabio,
On Jul 24, 2021, at 3:27 AM, Fabio Niephaus lists@fniephaus.com wrote:
Hi all, Just scanned my image for read-only objects and these were all their classes: ByteSymbol UndefinedObject ByteString Array GitStamp True ByteArray. For some reason, False seems to be missing. Hence, this is true: `true isReadOnlyObject ~~ false isReadOnlyObject` Seems like a minor bug somewhere?
Look at my code in the Compiler for setting literals to be read only. Clearly it makes sense to set read only on array literals (Array, ByteArray, ByteString/WideString, ByteSymbol/WideSymbol) and boxed numbers (LargeXXXXiveInteger, BoxedFloat64), but it makes little sense to set nil, true & false to be read only (they have no mutable state and so are effectively read only any way). I expect you’ll find that my code is too careless and accidentally applies read only ness to nil, false and/or true. A fix would involve correcting the code and adding a post load action to remove read only ness from nil, false and true.
Sounds reasonable. Since this is your code, would you mind taking care of this when you have some time?
Yes I would. I am currently mid way through attempting to speed up the FFI having written most of the code to allow much faster invocation of named primitives that don’t use much stack space. Last night I found the new code doesn’t handle failure correctly and will spend the day fixing that. Once I have that robe I can get back to seeing that the new FFI allows Turf to function. And once that is done I can get back to finishing the Terf release. Yo see the effort involved look at the number of methods in the VMMaker.oscog-eem.2994 commit. Clément and I have been wanting to do this for years. It should have a measurable impact on large integer performance, string hash, etc. but it is at least a week’s intense work.
So I would really appreciate if someone could take a look at the one method in the bytecode compiler that applies read only ness, and give it the review that it needs, because I didn’t get it right, because it’s there in the image, because it’s an easy task, because it’s a nice gift in a gift economy.
Many thanks,
Snotty passive aggression doesn’t cut it fir me I’m afraid.
Fabio
Cheers, Fabio
On Tue, Jul 27, 2021 at 6:47 AM Eliot Miranda eliot.miranda@gmail.com wrote:
[...] I would really appreciate if someone could take a look at the one method in the bytecode compiler that applies read only ness, and give it the review that it needs, because I didn’t get it right, because it’s there in the image, because it’s an easy task, [...]
This part of your reply is giving us the right hints. We should take further discussion to squeak-dev since it does not appear to be a VM issue.
Vanessa
On Tue, Jul 27, 2021 at 3:47 PM Eliot Miranda eliot.miranda@gmail.com wrote:
On Jul 26, 2021, at 7:34 AM, Fabio Niephaus lists@fniephaus.com wrote:
Hi Eliot,
On Mon, Jul 26, 2021 at 4:26 PM Eliot Miranda eliot.miranda@gmail.com wrote: Hi Fabio,
On Jul 24, 2021, at 3:27 AM, Fabio Niephaus lists@fniephaus.com wrote:
Hi all, Just scanned my image for read-only objects and these were all their classes: ByteSymbol UndefinedObject ByteString Array GitStamp True ByteArray. For some reason, False seems to be missing. Hence, this is true: `true isReadOnlyObject ~~ false isReadOnlyObject` Seems like a minor bug somewhere?
Look at my code in the Compiler for setting literals to be read only. Clearly it makes sense to set read only on array literals (Array, ByteArray, ByteString/WideString, ByteSymbol/WideSymbol) and boxed numbers (LargeXXXXiveInteger, BoxedFloat64), but it makes little sense to set nil, true & false to be read only (they have no mutable state and so are effectively read only any way). I expect you’ll find that my code is too careless and accidentally applies read only ness to nil, false and/or true. A fix would involve correcting the code and adding a post load action to remove read only ness from nil, false and true.
Sounds reasonable. Since this is your code, would you mind taking care of this when you have some time?
Yes I would. I am currently mid way through attempting to speed up the FFI having written most of the code to allow much faster invocation of named primitives that don’t use much stack space. Last night I found the new code doesn’t handle failure correctly and will spend the day fixing that. Once I have that robe I can get back to seeing that the new FFI allows Turf to function. And once that is done I can get back to finishing the Terf release. Yo see the effort involved look at the number of methods in the VMMaker.oscog-eem.2994 commit. Clément and I have been wanting to do this for years. It should have a measurable impact on large integer performance, string hash, etc. but it is at least a week’s intense work.
So I would really appreciate if someone could take a look at the one method in the bytecode compiler that applies read only ness, and give it the review that it needs, because I didn’t get it right, because it’s there in the image, because it’s an easy task, because it’s a nice gift in a gift economy.
Many thanks,
Snotty passive aggression doesn’t cut it fir me I’m afraid.
Oh, I didn't mean to sound aggressive. Apologies for my poor choice of words, Eliot. I'll add this to my todo list and fix it when I have some time (I honestly don't know how to set up post load actions).
Fabio
Fabio
Cheers, Fabio
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Fabio Niephaus -
Vanessa Freudenberg