On Mar 25, 2020, at 12:52 PM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
Hm, it would be indeed very confusing it the same code worked in a workspace but not in a compiled method.
Would it be a trade-off if we changed Object >> #readFrom: to apply #asWriteable on the deserialized object?
Yes, I suggested this in response to Levente’s commit of System-ul.1148. It might need to be smart. For example, if the deserialized object referred to a literal deep within its structure, that literal shouldn’t be changed. So it might me that the right way to implement this is indeed to change evaluation within readFrom: a it only makes literals within the doit(s) created writable.
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com Gesendet: Mittwoch, 25. März 2020 18:45:37 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Save as new image -> ModificationForbidden!
Hi Jakob,
On Mar 25, 2020, at 10:13 AM, Jakob Reschke forums.jakob@resfarm.de wrote: If you write #(1 2 3) in an inspector on a variable and accept that value, does it now make the variable's value immutable?
Read-only ;-) Potsdam were the people who wanted the language ui change from mutable/immutable to writable/read-only to reserve mutable/immutable for deep immutability for E-style concurrency :-)
Yes, it means it is marked as read-only. Currently you can either write #(1 2 3) copy or #(1 2 3) beWritableObject. But we could modify the Inspector’s accept action to preserve the state if the object is of the same class, etc. I’m not necessarily in favor of such auto-magic; it can get tricky. But I understand that this use case might turn out to be tedious.
I guess what we should be doing is collecting these “gotchers” for the HelpBrowser page on read-only literals that we’ll want to feature in the release.
And of course we’re early in the discussion Levente started about whether literals answered by doits should be read-only or not. I said I thought they should be in the interests of consistency. But in the interests of utility one might want them to be writable. I think one wants large integers and floats to be read-only no matter what, right? So we’re taking about literal arrays, byte arrays, and strings. If so, it seems to me that the right place to do any modifications to make things writable is in the evaluators. Perhaps we add an evaluateWritableResult: or add a writableResult: argument to the core evaluator api that would make array, byte array and string results writable iff the argument was true, the result was of the relevant class and it was a literal in the doit method.
Weird (or perhaps not) that I can’t remember this issue ever coming up in VisualWorks. Anyone got a better recollection than me?
Marcel Taeumel marcel.taeumel@hpi.de schrieb am Mi., 25. März 2020, 09:36:
Why do you think this is the wrong print string?
It happens easily to evaluate the printString again. If we now have ModificationForbidden, this can be quite confusing.
Same for #storeString:
{1. 2. 3} storeString -> '#(1 2 3)'
Best, Marcel
Am 25.03.2020 09:32:04 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel, hi Levente!
For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:
x := {1. 2. 3}. x at: 1 put: #foo. x "#(#foo 2 3) --- wrong print string!"
Why do you think this is the wrong print string? {#foo. 2. 3} is also printed as #(#foo 2 3).
Also, the following example shows that brace nodes generate a new instance each time:
c := Object newSubclass. c compile: 'foo ^ {1. 2. 3}'. o := c new. o foo at: 1 put: #foo. o foo. "#(1 2 3)"
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Mittwoch, 25. März 2020 09:19:01 An: gettimothy via Squeak-dev Betreff: Re: [squeak-dev] Save as new image -> ModificationForbidden!
Hi Levente, hi Christoph.
I cannot reproduce this using a fresh Trunk image
I am not exactly sure why my Trunk image keeps generating those private keys. But I am happy that the bug surfaced. Now we need to address it. :-)
The main issue is that literal objects created by Compiler >> #evaluate:* are now immutable but I think they shouldn't be. What do you think?
Well, I think that literals producing numbers, strings, or symbols should be protected in this way. For literal arrays, I am not so sure.
For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:
x := {1. 2. 3}. x at: 1 put: #foo. x "#(#foo 2 3) --- wrong print string!"
y := #(1 2 3). y at: 1 put: #foo. "ModificationForbidden"
Then, in the past, I have been complaining about the array cache in compiled methods:
someDefault ^ #(1 2 3)
In this case, I expected the method to always return a new array. Now, it is immutable, but that is not as expected. I think. Is it still cached?
In my case here, the code tries to change a LargePositiveInteger, not an array, which has always been wrong. :-) Is there a way to safely discard a LargePositiveInteger from memory?
System-ul.1148 should work the issue around. Please let me know if it
helped.
Not quite. I think have to manually clear the current keys in the SecurityManager first.
Best, Marcel
Am 24.03.2020 21:18:51 schrieb Levente Uzonyi leves@caesar.elte.hu:
Hi Marcel,
System-ul.1148 should work the issue around. Please let me know if it helped. The main issue is that literal objects created by Compiler >> #evaluate:* are now immutable but I think they shouldn't be. What do you think?
Levente
On Tue, 24 Mar 2020, Marcel Taeumel wrote:
Hi, there.
I just wanted to save a 32-bit image (Update 19541, VM 202003021730, Windows 10) under a new filename.
Boom! ModificationForbidden!
Here is the interesting stack:
Context>>modificationForbiddenFor:at:put: LargePositiveInteger(Object)>>basicAt:put: SecurityManager>>flushSecurityKey: SecurityManager>>flushSecurityKeys SecurityManager>>shutDown SecurityManager class>>shutDown SecurityManager class(Behavior)>>shutDown: [] in SmalltalkImage>>send:toClassesNamedIn:with: OrderedCollection>>do: SmalltalkImage>>send:toClassesNamedIn:with: SmalltalkImage>>processShutDownList:
Well, that code tries to change a LargePositiveInteger:
SecurityManager >> flushSecurityKey: aKey "Flush a security key" | n | n := aKey first. 1 to: n basicSize do:[:i| n basicAt: i put: 0]. n := aKey second. 1 to: n basicSize do:[:i| n basicAt: i put: 0].
How to fix that without breaking security measures or the underlying concept?
Best, Marcel
Hi Christoph,
On Wed, Mar 25, 2020 at 7:12 PM Eliot Miranda eliot.miranda@gmail.com wrote:
On Mar 25, 2020, at 12:52 PM, Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
Hm, it would be indeed very confusing it the same code worked in a workspace but not in a compiled method.
Would it be a trade-off if we changed Object >> #readFrom: to apply #asWriteable on the deserialized object?
Yes, I suggested this in response to Levente’s commit of System-ul.1148. It might need to be smart. For example, if the deserialized object referred to a literal deep within its structure, that literal shouldn’t be changed. So it might me that the right way to implement this is indeed to change evaluation within readFrom: a it only makes literals within the doit(s) created writable.
See if this makes sense in Inbox; Compiler-eem.421 and Kernel-eem.1320 in Inbox and see if you like the approach.
Name: Compiler-eem.421 Author: eem Time: 25 March 2020, 9:00:37.328826 pm UUID: 7bacb14a-f088-4fca-aa94-35dae28aa8e8 Ancestors: Compiler-nice.420
A suggested implementation of writable results from doits. This scheme is careful to only make read-only collection literals that the compiler makes read-only, not e.g. numeric literals (which should always be read-only) or objects the evaluation makes read-only.
Name: Kernel-eem.1320 Author: eem Time: 25 March 2020, 9:01:48.950717 pm UUID: 5e03652f-dca4-40fb-991e-ec71a89bb282 Ancestors: Kernel-eem.1319
Use Compiler-eem.421 to make Object class>>readFrom: answer writable collection literals.
Best, Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com *Gesendet:* Mittwoch, 25. März 2020 18:45:37 *An:* The general-purpose Squeak developers list *Betreff:* Re: [squeak-dev] Save as new image -> ModificationForbidden!
Hi Jakob,
On Mar 25, 2020, at 10:13 AM, Jakob Reschke forums.jakob@resfarm.de wrote:
If you write #(1 2 3) in an inspector on a variable and accept that value, does it now make the variable's value immutable?
Read-only ;-) Potsdam were the people who wanted the language ui change from mutable/immutable to writable/read-only to reserve mutable/immutable for deep immutability for E-style concurrency :-)
Yes, it means it is marked as read-only. Currently you can either write #(1 2 3) copy or #(1 2 3) beWritableObject. But we could modify the Inspector’s accept action to preserve the state if the object is of the same class, etc. I’m not necessarily in favor of such auto-magic; it can get tricky. But I understand that this use case might turn out to be tedious.
I guess what we should be doing is collecting these “gotchers” for the HelpBrowser page on read-only literals that we’ll want to feature in the release.
And of course we’re early in the discussion Levente started about whether literals answered by doits should be read-only or not. I said I thought they should be in the interests of consistency. But in the interests of utility one might want them to be writable. I think one wants large integers and floats to be read-only no matter what, right? So we’re taking about literal arrays, byte arrays, and strings. If so, it seems to me that the right place to do any modifications to make things writable is in the evaluators. Perhaps we add an evaluateWritableResult: or add a writableResult: argument to the core evaluator api that would make array, byte array and string results writable iff the argument was true, the result was of the relevant class and it was a literal in the doit method.
Weird (or perhaps not) that I can’t remember this issue ever coming up in VisualWorks. Anyone got a better recollection than me?
Marcel Taeumel marcel.taeumel@hpi.de schrieb am Mi., 25. März 2020, 09:36:
Why do you think this is the wrong print string?
It happens easily to evaluate the printString again. If we now have ModificationForbidden, this can be quite confusing.
Same for #storeString:
{1. 2. 3} storeString -> '#(1 2 3)'
Best, Marcel
Am 25.03.2020 09:32:04 schrieb Thiede, Christoph < christoph.thiede@student.hpi.uni-potsdam.de>:
Hi Marcel, hi Levente!
For starters, the #printString of modifiable arrays is wrong if
literal arrays should be immutable:
x := {1. 2. 3}. x at: 1 put: #foo. x "#(#foo 2 3) --- wrong print string!"
Why do you think this is the wrong print string? {#foo. 2. 3} is also printed as #(#foo 2 3).
Also, the following example shows that brace nodes generate a new instance each time:
c := Object newSubclass. c compile: 'foo ^ {1. 2. 3}'. o := c new. o foo at: 1 put: #foo. o foo. "#(1 2 3)"
Best, Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Mittwoch, 25. März 2020 09:19:01 *An:* gettimothy via Squeak-dev *Betreff:* Re: [squeak-dev] Save as new image -> ModificationForbidden!
Hi Levente, hi Christoph.
I cannot reproduce this using a fresh Trunk image
I am not exactly sure why my Trunk image keeps generating those private keys. But I am happy that the bug surfaced. Now we need to address it. :-)
The main issue is that literal objects created by Compiler >>
#evaluate:* are now immutable but I think they shouldn't be. What do you think?
Well, I think that literals producing numbers, strings, or symbols should be protected in this way. For literal arrays, I am not so sure.
For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:
x := {1. 2. 3}. x at: 1 put: #foo. x "#(#foo 2 3) --- wrong print string!"
y := #(1 2 3). y at: 1 put: #foo. "ModificationForbidden"
Then, in the past, I have been complaining about the array cache in compiled methods:
someDefault ^ #(1 2 3)
In this case, I expected the method to always return a new array. Now, it is immutable, but that is not as expected. I think. Is it still cached?
In my case here, the code tries to change a LargePositiveInteger, not an array, which has always been wrong. :-) Is there a way to safely discard a LargePositiveInteger from memory?
System-ul.1148 should work the issue around. Please let me know if it
helped.
Not quite. I think have to manually clear the current keys in the SecurityManager first.
Best, Marcel
Am 24.03.2020 21:18:51 schrieb Levente Uzonyi leves@caesar.elte.hu: Hi Marcel,
System-ul.1148 should work the issue around. Please let me know if it helped. The main issue is that literal objects created by Compiler >> #evaluate:* are now immutable but I think they shouldn't be. What do you think?
Levente
On Tue, 24 Mar 2020, Marcel Taeumel wrote:
Hi, there.
I just wanted to save a 32-bit image (Update 19541, VM 202003021730,
Windows 10) under a new filename.
Boom! ModificationForbidden!
Here is the interesting stack:
Context>>modificationForbiddenFor:at:put: LargePositiveInteger(Object)>>basicAt:put: SecurityManager>>flushSecurityKey: SecurityManager>>flushSecurityKeys SecurityManager>>shutDown SecurityManager class>>shutDown SecurityManager class(Behavior)>>shutDown: [] in SmalltalkImage>>send:toClassesNamedIn:with: OrderedCollection>>do: SmalltalkImage>>send:toClassesNamedIn:with: SmalltalkImage>>processShutDownList:
Well, that code tries to change a LargePositiveInteger:
SecurityManager >> flushSecurityKey: aKey "Flush a security key" | n | n := aKey first. 1 to: n basicSize do:[:i| n basicAt: i put: 0]. n := aKey second. 1 to: n basicSize do:[:i| n basicAt: i put: 0].
How to fix that without breaking security measures or the underlying
concept?
Best, Marcel
squeak-dev@lists.squeakfoundation.org
-
Eliot Miranda