<div dir="ltr"><div dir="ltr">Andres,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 13, 2019 at 8:47 PM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">One of the methods that won't work due to the closure indirection you <br>
mention is displayWorldSafely.  What a mess :(.<br>
<br>
This method also illustrates the problem I referred to earlier: there is <br>
code written in such a way that changing it demands too much energy. <br>
The system users shouldn't be held hostage by the system's own code.<br></blockquote><div><br></div><div>Yup, right now I suspect the image is going to be largely unusable as is.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Maybe if we split the work it won't be that bad to clean up.  One way or <br>
the other, that work should have been done before pushing out the <br>
changes, as you well note.<br></blockquote><div><br></div><div>I suspect that the majority of cases will be trivial to fix.  Some however...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think the best way to proceed is to revert the changes for now, decide <br>
calmly what we will do about this (i.e. without the rush to cobble some <br>
random patch together), then do that.<br></blockquote><div><br></div><div>Agreed.  The scope makes this a non-trivial change... let's neither rush nor abandon it.  Just revert it and build the tooling we need to understand the scope of it more fully.  It's entirely possible that 95% of the cases are trivial and 5% are problematic... that's not a deal-killer.</div><div><br></div>A couple ideas:<div><br></div><div>1) How about a changeset that just starts flagging senders of these 'tainted' do: blocks in the background? (i.e. don't halt or spew Transcript messages, just keep a collection that tracks occurrences in a running image when logging is enabled)  That way we can load whatever packages (either github or private), run tests, use the image for a while etc. and get a better idea of what needs to be looked at.</div><div><br></div><div>2) In thinking about the scenario of blocks being passed parameters for error handlers, we might see some crazy stuff out in the wild that will require non-trivial restructuring to fix... and as you mention, maybe some of them we will decide aren't worth fixing.  Perhaps we want to have a #on:taintedDo: method that allows non-local returns for those cases?  That would allow us to move forward for the default and likely vast majority of cases while also having flagged, minimized and contained the remaining problematic use cases.</div></div></div>