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?

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/7f86d0bf/attachment.html>