Hi Christoph,

On Wed, Mar 25, 2020 at 7:12 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> 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.
>

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.

<http://www.hpi.de/>
>
> 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
>> >
>> >
>>
>>
>>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200325/891c3cbd/attachment-0001.html>