[squeak-dev] Save as new image -> ModificationForbidden!

Eliot Miranda eliot.miranda at gmail.com
Thu Mar 26 02:12:55 UTC 2020





>> On Mar 25, 2020, at 12:52 PM, Thiede, Christoph <Christoph.Thiede at 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 at lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda at 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 at 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 at 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 at 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 at 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 at 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
>>>>> > 
>>>>> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200325/b7ed1b20/attachment.html>


More information about the Squeak-dev mailing list