[M3devel] cm3cg coverage/profiling features?

Wed Aug 12 20:21:42 CEST 2015

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.

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.

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.

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:

INTERFACE Top;
TYPE T <: ROOT;
END Top.

INTERFACE Pub;
IMPORT Top;
TYPE TPub = OBJECT [...] END;
REVEAL Top.T <: TPub;
END Pub.

INTERFACE Pvt;
IMPORT Top, Pub;
TYPE TPvt = Pub.TPub OBJECT [...] END;
REVEAL Top.T <: TPvt;
END Pvt.

MODULE Top;
IMPORT Pub, Pvt; (* or equally, appearing in the EXPORTS list *)
REVEAL T = Pvt.TPvt BRANDED OBJECT [...]  END;
BEGIN
END Top.

I suspect the problem has something to do with the "injection" of the
partial revelations through importing interfaces.

On Wed, Aug 12, 2015 at 10:41 AM, Jay K <jay.krell at cornell.edu> wrote:

> I understand your description of the changed behavior but I hadn't noticed
> either way.
> Perhaps it was changed by accident and likely it should be unconditionally
> restored.
> It depends somewhat. Error recovery isn't always easy.
> Within a module, recovery is likely problematic.
> If all interfaces compile successfully, then I believe all modules are
> independent and
> failure in any one module should not stop compilation in another module.
>
>
> If any interfaces fail to compile, then there could be quite a cascade
> across modules.
> However the way to handle that is probably to ignore it. Attempt to
> compile all modules.
> "Summarize" the error at the end.
> i.e. the overall package build will fail.
> Developer fixes it, rebuilds, possily only a small amount will rebuild.
>
> In terms of the scripts, well, not clear. They are potentially iterating
> over a lot of code.
> There is somewhat a dilemna of "interactive or not".
> If I'm there watching and it stops, I might fix it fast, and resume, to
> success.
>
> If I'm not watching, and the problem is small, it might be profitable to
> continue,
> do the most possible, and then when I come back, I'll fix it up.
>
>
> If the problem is large, it matters less. Continuing on might go fast if
> everything fails.
> It is a somewhat interesting experiment -- put an error in RT0.i3 and see
> how long it takes
> to attempt to compile every module in every package. err..wait..you can't
> ship with an error.
> Continuing through packages after an error will build against older
> packages.
>
>
> Consistency, well..partly it is based on what I notice and what I see.
> What I see cluttering up where I need to debug and change.
> True consistency might require knowing all and having infinite time.
>
>  - Jay
>
>
>
> ------------------------------
> Date: Wed, 12 Aug 2015 09:11:10 -0700
> From: lists at darko.org
> To: mika at async.caltech.edu; jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] cm3cg coverage/profiling features?
>
> OK, but can someone explain to me why other, less obscure features have
> been removed?
>
> 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?
>
> 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.
>
> 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?
>
>
> On Wed, Aug 12, 2015 at 8:21 AM, <mika at async.caltech.edu> wrote:
>
> Don't forget the as-yet-unborn users!
>
> In all seriousness... the compiler includes a lot of cool stuff, and I
> wish it worked.  I used some of these features that Jay is talking about
> when SRC M3 was all there was, and I remember it did work.
>
> I think the profiling (and probably other stuff) has been broken since
> today's junior high school students were born though.
>
>     Mika
>
> Darko Volaric writes:
> >--===============9067918515746620203==
> >Content-Type: multipart/alternative; boundary=bcaec548634a0fec67051d1eb98e
> >
> >--bcaec548634a0fec67051d1eb98e
> >Content-Type: text/plain; charset=UTF-8
> >
> >Why does it have to be removed? Is there some pressing reason that
> >justifies removing functionality? How does it improve the compiler?
> >
> >Also, how does asking in the mailing list justify its removal? Not all
> >users follow the mailing list, and future users do not get a say.
> >
> >On Tue, Aug 11, 2015 at 11:14 PM, Jay K <jay.krell at cornell.edu> wrote:
> >
> >> Does anyone use the coverage or profiling or
> >> optimization-via-profiling-feedback features of cm3cg?
> >> I'm removing dead stuff.
> >>
> >> Thank you,
> >>  - Jay
> >>
> >>
> >>
> >> _______________________________________________
> >> M3devel mailing list
> >> M3devel at elegosoft.com
> >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> >>
> >>
> >
> >--bcaec548634a0fec67051d1eb98e
> >Content-Type: text/html; charset=UTF-8
> >Content-Transfer-Encoding: quoted-printable
> >
> ><div dir=3D"ltr">Why does it have to be removed? Is there some pressing
> rea=
> >son that justifies removing functionality? How does it improve the
> compiler=
> >?<div><br></div><div>Also, how does asking in the mailing list justify
> its =
> >removal? Not all users follow the mailing list, and future users do not
> get=
> > a say.</div></div><div class=3D"gmail_extra"><br><div
> class=3D"gmail_quote=
> >">On Tue, Aug 11, 2015 at 11:14 PM, Jay K <span dir=3D"ltr"><<a
> href=3D"=
> >mailto:jay.krell at cornell.edu" target=3D"_blank">jay.krell at cornell.edu
> </a>&g=
> >t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0
> 0=
> > .8ex;border-left:1px #ccc solid;padding-left:1ex">
> >
> >
> ><div><div dir=3D"ltr">Does anyone use the coverage or profiling or
> optimiza=
> >tion-via-profiling-feedback features of cm3cg?<div>I'm removing dead
> st=
> >uff.</div><div><br></div><div>Thank you,</div><div>=C2=A0-
> Jay<br><br><br><=
> >/div>                                    </div></div>
> ><br>_______________________________________________<br>
> >M3devel mailing list<br>
> ><a href=3D"mailto:M3devel at elegosoft.com">M3devel at elegosoft.com</a><br>
> ><a href=3D"https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel"
> rel=
> >=3D"noreferrer" target=3D"_blank">
> https://mail.elegosoft.com/cgi-bin/mailma=
> >n/listinfo/m3devel</a><br>
> ><br></blockquote></div><br></div>
> >
> >--bcaec548634a0fec67051d1eb98e--
> >
> >--===============9067918515746620203==
> >Content-Type: text/plain; charset="us-ascii"
> >MIME-Version: 1.0
> >Content-Transfer-Encoding: 7bit
> >Content-Disposition: inline
> >
> >_______________________________________________
> >M3devel mailing list
> >M3devel at elegosoft.com
> >https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> >
> >--===============9067918515746620203==--
>
>
>
> _______________________________________________ M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150812/b68fe198/attachment-0002.html>