<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi Jakob,<br><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Mar 25, 2020, at 10:13 AM, Jakob Reschke <forums.jakob@resfarm.de> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto">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?</div></div></blockquote><div><br></div>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 :-)<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Weird (or perhaps not) that I can’t remember this issue ever coming up in VisualWorks.  Anyone got a better recollection than me?</div><div><br><blockquote type="cite"><div dir="ltr">Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> schrieb am Mi., 25. März 2020, 09:36:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div id="m_3471274172129945034__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:#000000">
                                        > <span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px">Why do you think this is the wrong print string?</span><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px"><br></span></div><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px">It happens easily to evaluate the printString again. If we now have ModificationForbidden, this can be quite confusing.</span></div><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px"><br></span></div><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px">Same for #storeString:</span></div><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px"><br></span></div><div><span style="font-family:Calibri,Helvetica,sans-serif"><span style="font-size:16px">{1. 2. 3} storeString         -> '#(1 2 3)'</span></span><br></div><div><span style="font-family:Calibri,Helvetica,sans-serif"><span style="font-size:16px"><br></span></span></div><div><span style="font-family:Calibri,Helvetica,sans-serif"><span style="font-size:16px">Best,</span></span></div><div><span style="font-family:Calibri,Helvetica,sans-serif"><span style="font-size:16px">Marcel</span></span></div><div></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px">
                        <p style="color:#aaaaaa;margin-top:10px">Am 25.03.2020 09:32:04 schrieb Thiede, Christoph <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de" target="_blank" rel="noreferrer">christoph.thiede@student.hpi.uni-potsdam.de</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif">

<div id="m_3471274172129945034divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>Hi Marcel, hi Levente!</p>
<p><br>
</p>
<p>> <span style="font-size:12pt">For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:</span></p>
<div>> </div>
<div>> x := {1. 2. 3}.</div>
<div>> x at: 1 put: #foo.</div>
<div>> x "#(#foo 2 3) --- wrong print string!"</div>
<div><br>
</div>
<div><span style="font-size:12pt">Why do you think this is the wrong print string? {#foo. 2. 3} is also printed as #(#foo 2 3).</span><br>
</div>
<div><br>
</div>
<div>Also, the following example shows that brace nodes generate a new instance each time:</div>
<div><br>
</div>
<div>
<div>c := Object newSubclass.</div>
<div>c compile: 'foo ^ {1. 2. 3}'.</div>
<div>o := c new.</div>
<div>o foo at: 1 put: #foo.</div>
<div>o foo. "#(1 2 3)"</div>
<br>
</div>
<div>Best,</div>
<div>Christoph</div>
<p>
</p><div id="m_3471274172129945034Signature">
<div id="m_3471274172129945034divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="divtagdefaultwrapper">
<div><span style="font-size:10pt;color:#808080"></span></div>
</div>
</div>
</div>
<p></p></div>
<hr style="display:inline-block;width:98%">
<div id="m_3471274172129945034divRplyFwdMsg" dir="ltr"><span style="font-family:Calibri,sans-serif;color:#000000"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank" rel="noreferrer">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Taeumel, Marcel<br>
<b>Gesendet:</b> Mittwoch, 25. März 2020 09:19:01<br>
<b>An:</b> gettimothy via Squeak-dev<br>
<b>Betreff:</b> Re: [squeak-dev] Save as new image -> ModificationForbidden!</span>
<div> </div>
</div>
<div>
<div id="m_3471274172129945034__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:#000000">
Hi Levente, hi Christoph.
<div><br>
</div>
<div>> <span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px">I cannot reproduce this using a fresh Trunk image</span></div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px"><br>
</span></div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px">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. :-)</span></div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px"><br>
</span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">> The main issue is that literal objects created by Compiler >> #evaluate:*  </span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">are now immutable but I
 think they shouldn't be. What do you think?</span><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px"><br>
</span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br>
</span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">Well, I think that literals producing numbers, strings, or symbols should be protected in this way. For literal arrays, I am not so sure.</span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br>
</span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:</span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br>
</span></div>
<div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">x := {1. 2. 3}.</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">x at: 1 put: #foo.</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">x "#(#foo 2 3) --- wrong print string!"</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px"><br>
</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">y := #(1 2 3).</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">y at: 1 put: #foo. "ModificationForbidden"</span></span></div>
</div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px"><br>
</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">Then, in the past, I have been complaining about the array cache in compiled methods:</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px"><br>
</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">someDefault</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">   ^ #(1 2 3)</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px"><br>
</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">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?</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px"><br>
</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">***</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px"><br>
</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">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?</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px"><br>
</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">> </span></span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">System-ul.1148 should work the issue around. Please let me know if it</span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"> </span></div>
<span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">helped.</span>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px"><br>
</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">Not quite. I think have to manually clear the current keys in the SecurityManager first.</span></span></div>
<div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px"><br>
</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">Best,</span></span></div>
<div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">Marcel</span></span></div>
<div></div>
</div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">
<p style="color:#aaaaaa;margin-top:10px">Am 24.03.2020 21:18:51 schrieb Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank" rel="noreferrer">leves@caesar.elte.hu</a>>:</p>
<div style="font-family:Arial,Helvetica,sans-serif">Hi Marcel,<br>
<br>
System-ul.1148 should work the issue around. Please let me know if it <br>
helped.<br>
The main issue is that literal objects created by Compiler >> #evaluate:* <br>
are now immutable but I think they shouldn't be. What do you think?<br>
<br>
<br>
Levente<br>
<br>
On Tue, 24 Mar 2020, Marcel Taeumel wrote:<br>
<br>
> Hi, there.<br>
> <br>
> I just wanted to save a 32-bit image (Update 19541, VM 202003021730, Windows 10) under a new filename.<br>
> <br>
> Boom! ModificationForbidden!<br>
> <br>
> Here is the interesting stack:<br>
> <br>
> Context>>modificationForbiddenFor:at:put:<br>
> LargePositiveInteger(Object)>>basicAt:put:<br>
> SecurityManager>>flushSecurityKey:<br>
> SecurityManager>>flushSecurityKeys<br>
> SecurityManager>>shutDown<br>
> SecurityManager class>>shutDown<br>
> SecurityManager class(Behavior)>>shutDown:<br>
> [] in SmalltalkImage>>send:toClassesNamedIn:with:<br>
> OrderedCollection>>do:<br>
> SmalltalkImage>>send:toClassesNamedIn:with:<br>
> SmalltalkImage>>processShutDownList:<br>
> <br>
> Well, that code tries to change a LargePositiveInteger:<br>
> <br>
> SecurityManager >> flushSecurityKey: aKey<br>
> "Flush a security key"<br>
> | n |<br>
> n := aKey first.<br>
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].<br>
> n := aKey second.<br>
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].<br>
> <br>
> How to fix that without breaking security measures or the underlying concept?<br>
> <br>
> Best,<br>
> Marcel<br>
> <br>
><br>
<br>
</div>
</blockquote>
</div>
</div>
</div></blockquote>
                                        </div></div><br>
</blockquote></div>
<span></span><br></div></blockquote></div></body></html>