<div dir="ltr">Hi David,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 4, 2015 at 7:25 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dave,<br>
<div><div class="h5"><br>
On Jul 4, 2015, at 7:15 AM, "David T. Lewis" <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
<br>
> On Sat, Jul 04, 2015 at 12:10:41AM -0400, David T. Lewis wrote:<br>
>> On Fri, Jul 03, 2015 at 07:23:27PM -0700, Eliot Miranda wrote:<br>
>>> Hi Chris, Hi All,<br>
>>><br>
>>> On Thu, Jul 2, 2015 at 12:26 PM, Chris Muller <<a href="mailto:ma.chris.m@gmail.com">ma.chris.m@gmail.com</a>> wrote:<br>
>>><br>
>>>> We have a release candidate image.<br>
>>>><br>
>>>> <a href="http://ftp.squeak.org/4.6/" rel="noreferrer" target="_blank">http://ftp.squeak.org/4.6/</a><br>
>>>><br>
>>>> The new sources file is required.<br>
>>>><br>
>>>> Please test your apps. This could be the final image unless major<br>
>>>> issues are uncovered.<br>
>>><br>
>>> One issue that I'm very tempted to address before the final release is the<br>
>>> bug to do with inadvertent editing of a breakpointed method.<br>
>><br>
>> Squeak 4.6 needs to be frozen. This sounds like something that can be<br>
>> addressed in a next release after 4.6, so lets do that please.<br>
><br>
> I guess that is entirely the wrong thing for me to say, since I don't<br>
> even know what would be involved in the fix.<br>
><br>
> What I should have said is that it is great that we have the release<br>
> candidate prepared in time for ECOOP (thanks!), so I think it would be<br>
> good to avoid any late changes to that release package unless really<br>
> necessary.<br>
<br>
</div></div>I was about to say that I agree with your first reply even though, having slept on it, I woke up realizing the #2 fix above is easy. So given yiur second message I'll implement #2 and leave #1 for after the release.<br>
<br>
To get the override in place, create a config for the status quo, commit a version of Kernel containing the default CompiledMethod>>#hasBreakpoint, create a config, then commit a version of System which restores the override. I guess I was tired last night cuz this is obvious. Ok time to get up, have a cup of tea and do this :)<br></blockquote><div><br></div><div>OK, #2 is implemented and committed. #1, the warning on defining a method containing a break, can wait until after the release. I think it's important to fix #2, though, because destroying method history is a bad bug. </div><div><br></div><div>Cheers!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Dave<br>
><br>
></blockquote></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>