<div dir="ltr">The error recovery doesn't matter. For instance I just rename a declaration so it no longer exists. The compiler will then produce an error for each usage of that symbol, saying it's no longer found, and it will report it at least once for every module where it used (I've noticed that the compiler will often only report one error if it is repeated multiple times in a module).<div><br></div><div>I'm not sure the rate of change is that low. I think the best idea would be put changes in branches so each set can be reviewed and tested before being merged. This would also allow people to choose what they want in their build. With the new GitHub repository this should be a lot easier than with CVS.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 11:56 AM, Jay K <span dir="ltr"><<a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr"><span class=""><div> > Error recovery is hard but the original authors laboured to implement it and it worked</div><div><br></div><div><br></div></span><div>Within a module it is unbounded problem and such labor will only slightly work.</div><div><br></div><div><br></div><div>That said, I know of no changes within modules or across modules wrt error recovery.</div><div>We can/should investigate and fix.</div><div><br></div><div>I don't think a compiler switch is a good idea here, as we should have a smaller matrix</div><div>of behaviors and the behavior you desire is probably the one and only way it should be.</div><div><br></div><div>Making switches for too many things is its own madness. Nobody runs the same thing</div><div>and the test matrix explodes.</div><div><br></div><div><br></div><div>Across modules we should probably just proceed, just being sure to error at the end (i.e. so we don't ship, and maybe so scripts don't proceed, though</div><div>actually, scripts probably should proceed, but again error at the end -- builds tend to contain <i>highly</i> <i>independent</i> graph pieces, even if there</div><div>are some heavily shared nodes at the root like m3core)</div><div><br></div><div><br></div><div>There are at least two schools of thought in software in general.</div><div><br></div><div>There is "fail fast" and "muddle along".</div><div><br></div><div><br></div><div>Generally older thinking is "muddle along", make a best effort attempt to work in the face of errors.</div><div><br></div><div><br></div><div>Newer thinking is "fail fast", and generally acknowledging that once there is an error, some?many?most?all "bets"</div><div>are off and best to stop, vs. doing the wrong thing.</div><div><br></div><div><br></div><div>But there is a middle ground, which is to try to think about dependencies and if errors in one place</div><div>really affect another. Often times, for a simple example, iterations of a loop are independent and failure</div><div>within one shouldn't stop the loop.</div><div><br></div><div><br></div><div>Imagine you specify to copy many files, but a few fail. Should you stop the copy at the first failure?</div><div>Should you rollback the earlier successful copies?</div><div><br></div><div>Should you have some level of "transactionality" so that no intermediate state is visible unless</div><div>the entire operation is guanteed to succeed?</div><div><br></div><div><br></div><div>Anyway, compilers, even within a module, seem popular to place in the middle and muddle along.</div><div>Their output is eventuall mission critical, but how they handle errors is not.</div><div>People like to get as many errors as possible, fix them all, try again.</div><div>Instead of the compiler stopping at the first. You know, to try to divide the quadratic nature</div><div>of fixing errors down to almost linear. But it depends on the nature of the error.</div><div><br></div><div><br></div><div>"breaking" a declaration is presumably removing it or changing it to a different valid declaration.</div><div>Changing it to a declaration that doesn't parse is risky -- you have to assume error recovery works a certain way.</div><div><br></div><div><br></div><div>I also discovered an incrementality problem -- if you move a module across packages.</div><div>That is probably not a new regression though.</div><div><br></div><div><br></div><div>I don't think we are losing functionality and all changes still come through m3commit.</div><div><br></div><div>Imho review can occur before or after change, but I know, not everyone in the world agrees.</div><div>Many development environments require review before commit.</div><div><br></div><div><br></div><div>There is the matter of if rate of change exceeds rate of review and needs to be throttled down,</div><div>but rate of change is <i>really quite low </i>(even if rate of review is even lower).</div><div><br></div><div><br></div><div> - Jay<br><br><br></div><div><hr>Date: Wed, 12 Aug 2015 11:21:42 -0700<br>From: <a href="mailto:lists@darko.org" target="_blank">lists@darko.org</a><br>To: <a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a><div><div class="h5"><br>CC: <a href="mailto:m3devel@elegosoft.com" target="_blank">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] cm3cg coverage/profiling features?<br><br><div dir="ltr">The larger point is that is that changes are being made to the compiler ad-hoc. There seems to be no consideration of the consequence of those changes and how it affects users. These changes are being made on the trunk instead of a branch and it may be hard to untangle them. If we're losing functionality accidently then something is wrong with the development process.<div><br></div><div>On this issue, ignoring cascading errors is perfectly legitimate but so is not ignoring them. I (used to) purposely break a declaration so see the consequences of it throughout the code and to reveal where the declaration was used. It's also very slow having to recompile after fixing a change in each client module to reveal the next place it needs fixing, just because it's in a different file.</div><div><br></div><div>Error recovery is hard but the original authors laboured to implement it and it worked, it shouldn't be lost. At the very least a compiler switch is in order here.</div><div><br></div><div>Either way this seems to be a bug because the compiler is also failing to track dependencies in some causes causing files not to be recompiled. For example it seems to be happening somewhere around using this sort of idiom:</div><div><br></div><div>INTERFACE Top;</div><div>TYPE T <: ROOT;</div><div>END Top.</div><div><br></div><div>INTERFACE Pub;</div><div>IMPORT Top;</div><div>TYPE TPub = OBJECT [...] END;</div><div>REVEAL Top.T <: TPub;</div><div>END Pub.</div><div><br></div><div>INTERFACE Pvt;</div><div>IMPORT Top, Pub;</div><div>TYPE TPvt = Pub.TPub OBJECT [...] END;<br></div><div>REVEAL Top.T <: TPvt;</div><div>END Pvt.</div><div><br></div><div>MODULE Top;<br></div><div>IMPORT Pub, Pvt; (* or equally, appearing in the EXPORTS list *)</div><div>REVEAL T = Pvt.TPvt BRANDED OBJECT [...] END;</div><div>BEGIN </div><div>END Top.</div><div><br></div><div>I suspect the problem has something to do with the "injection" of the partial revelations through importing interfaces.</div></div><div><br><div>On Wed, Aug 12, 2015 at 10:41 AM, Jay K <span dir="ltr"><<a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>></span> wrote:<br><blockquote style="padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div><div dir="ltr"><div>I understand your description of the changed behavior but I hadn't noticed either way.</div><div>Perhaps it was changed by accident and likely it should be unconditionally restored.</div><div>It depends somewhat. Error recovery isn't always easy.</div><div>Within a module, recovery is likely problematic.</div><div>If all interfaces compile successfully, then I believe all modules are independent and</div><div>failure in any one module should not stop compilation in another module.</div><div><br></div><div><br></div><div>If any interfaces fail to compile, then there could be quite a cascade across modules.</div><div>However the way to handle that is probably to ignore it. Attempt to compile all modules.</div><div>"Summarize" the error at the end.</div><div>i.e. the overall package build will fail.</div><div>Developer fixes it, rebuilds, possily only a small amount will rebuild.</div><div><br></div><div>In terms of the scripts, well, not clear. They are potentially iterating over a lot of code.</div><div>There is somewhat a dilemna of "interactive or not".<br>If I'm there watching and it stops, I might fix it fast, and resume, to success.</div><div><br></div><div>If I'm not watching, and the problem is small, it might be profitable to continue,</div><div>do the most possible, and then when I come back, I'll fix it up.</div><div><br></div><div><br></div><div>If the problem is large, it matters less. Continuing on might go fast if everything fails.</div><div>It is a somewhat interesting experiment -- put an error in RT0.i3 and see how long it takes</div><div>to attempt to compile every module in every package. err..wait..you can't ship with an error.</div><div>Continuing through packages after an error will build against older packages.</div><div><br></div><div><br></div><div>Consistency, well..partly it is based on what I notice and what I see.</div><div>What I see cluttering up where I need to debug and change.</div><div>True consistency might require knowing all and having infinite time.</div><div><br></div><div> - Jay<br><br><br><br></div><div><hr>Date: Wed, 12 Aug 2015 09:11:10 -0700<br>From: <a href="mailto:lists@darko.org" target="_blank">lists@darko.org</a><br>To: <a href="mailto:mika@async.caltech.edu" target="_blank">mika@async.caltech.edu</a>; <a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a><span><br>CC: <a href="mailto:m3devel@elegosoft.com" target="_blank">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] cm3cg coverage/profiling features?<br><br></span><div><div><div dir="ltr">OK, but can someone explain to me why other, less obscure features have been removed?<div><br></div><div>For instance, cm3 used to keep on compiling files after errors were found. Now it seems to stop after one module. That loss of functionality seriously reduces productivity. I couldn't find any switch to reverse the change. When was this change decided? Is there a way to restore it?</div><div><br></div><div>But more generally: even if the functionality is broken, if it's still there there is a chance someone will fix it, if we remove it we're drawing a line underneath it and ending it.</div><div><br></div><div>The repository is replete with stuff that isn't used or is broken, so removing this one function seems arbitrary. Should we have some sort of consistency?</div><div><br></div></div><div><br><div>On Wed, Aug 12, 2015 at 8:21 AM, <span dir="ltr"><<a href="mailto:mika@async.caltech.edu" target="_blank">mika@async.caltech.edu</a>></span> wrote:<br><blockquote style="padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">Don't forget the as-yet-unborn users!<br>
<br>
In all seriousness... the compiler includes a lot of cool stuff, and I<br>
wish it worked. I used some of these features that Jay is talking about<br>
when SRC M3 was all there was, and I remember it did work.<br>
<br>
I think the profiling (and probably other stuff) has been broken since<br>
today's junior high school students were born though.<br>
<br>
Mika<br>
<br>
Darko Volaric writes:<br>
>--===============9067918515746620203==<br>
>Content-Type: multipart/alternative; boundary=bcaec548634a0fec67051d1eb98e<br>
><br>
>--bcaec548634a0fec67051d1eb98e<br>
>Content-Type: text/plain; charset=UTF-8<br>
<div><div>><br>
>Why does it have to be removed? Is there some pressing reason that<br>
>justifies removing functionality? How does it improve the compiler?<br>
><br>
>Also, how does asking in the mailing list justify its removal? Not all<br>
>users follow the mailing list, and future users do not get a say.<br>
><br>
>On Tue, Aug 11, 2015 at 11:14 PM, Jay K <<a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>> wrote:<br>
><br>
>> Does anyone use the coverage or profiling or<br>
>> optimization-via-profiling-feedback features of cm3cg?<br>
>> I'm removing dead stuff.<br>
>><br>
>> Thank you,<br>
>> - Jay<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> M3devel mailing list<br>
>> <a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a><br>
>> <a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" rel="noreferrer" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a><br>
>><br>
>><br>
><br>
</div></div>>--bcaec548634a0fec67051d1eb98e<br>
>Content-Type: text/html; charset=UTF-8<br>
>Content-Transfer-Encoding: quoted-printable<br>
><br>
><div dir=3D"ltr">Why does it have to be removed? Is there some pressing rea=<br>
>son that justifies removing functionality? How does it improve the compiler=<br>
>?<div><br></div><div>Also, how does asking in the mailing list justify its =<br>
>removal? Not all users follow the mailing list, and future users do not get=<br>
> a say.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=<br>
>">On Tue, Aug 11, 2015 at 11:14 PM, Jay K <span dir=3D"ltr"><<a href=3D"=<br>
>mailto:<a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>" target=3D"_blank"><a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a></a>&g=<br>
>t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=<br>
> .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
><br>
><br>
><div><div dir=3D"ltr">Does anyone use the coverage or profiling or optimiza=<br>
>tion-via-profiling-feedback features of cm3cg?<div>I'm removing dead st=<br>
>uff.</div><div><br></div><div>Thank you,</div><div>=C2=A0- Jay<br><br><br><=<br>
>/div> </div></div><br>
><br>_______________________________________________<br><br>
>M3devel mailing list<br><br>
><a href=3D"mailto:<a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a>"><a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a></a><br><br>
><a href=3D"<a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" rel="noreferrer" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a>" rel=<br>
>=3D"noreferrer" target=3D"_blank"><a href="https://mail.elegosoft.com/cgi-bin/mailma=" rel="noreferrer" target="_blank">https://mail.elegosoft.com/cgi-bin/mailma=</a><br>
>n/listinfo/m3devel</a><br><br>
><br></blockquote></div><br></div><br>
><br>
>--bcaec548634a0fec67051d1eb98e--<br>
><br>
>--===============9067918515746620203==<br>
>Content-Type: text/plain; charset="us-ascii"<br>
>MIME-Version: 1.0<br>
>Content-Transfer-Encoding: 7bit<br>
>Content-Disposition: inline<br>
<span>><br>
>_______________________________________________<br>
>M3devel mailing list<br>
><a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a><br>
><a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" rel="noreferrer" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a><br>
><br>
</span>>--===============9067918515746620203==--<br>
</blockquote></div><br></div>
<br>_______________________________________________
M3devel mailing list
<a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a>
<a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a></div></div></div> </div></div>
</blockquote></div><br></div>
<br>_______________________________________________
M3devel mailing list
<a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a>
<a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a></div></div></div> </div></div>
</blockquote></div><br></div>