<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>It isn't perfectly scientific, as even full paths on a machine<div>can have variable meaning through time.</div><div><br></div><div><br></div><div>For example, I can delete some source, put other source in its place,</div><div>similar or different.</div><div><br></div><div><br></div><div>And on Windows there is the "net use" feature where drive letters</div><div>map to the network. Then you delete the use, and make another one,</div><div>same letter, different place.</div><div><br></div><div><br></div><div>Similar to mounting on Unixy systems.</div><div><br></div><div><br></div><div>Here is another story in this area.</div><div>Hopefully I have my facts correct.</div><div>Perhaps it is just apocryphal and I filled in details to suit my agenda.</div><div>We can double check it all with a bit of time.</div><div><br></div><div><br></div><div>Visual C++, has, like any other system, some value for __FILE__</div><div>and some values in the debugging information.</div><div><br></div><div><br></div><div>A long time ago, they were both whatever you passed on the command line.</div><div><br></div><div><br></div><div>At some point, a switch was added /FC that meant "full path the values</div><div>in the debugging information". I believe this was added around Visual C++ 5.0.</div><div><span style="font-size: 12pt;">Later however, it was realized, that should always </span><span style="font-size: 12pt;">be how it works. The switch</span></div><div><span style="font-size: 12pt;">no longer does anything.</span></div><div><br></div><div><br></div><div><br></div><div>Or maybe /FC still serves to full path __FILE__ but no longer has any</div><div>affect on debugging information.</div><div>I'd have to go back and try every compiler I have to verify.</div><div><br></div><div><br></div><div>So, I think this actually motivate my other point from years ago,</div><div>which is to full path the file names in the debug info, but not necessarily here.</div><div>But I want both. :)</div><div><br></div><div><br></div><div>I debug a lot of stuff, and it is unavoidably difficult, but some things</div><div>just make it unnecessarily more difficult and tedious.</div><div><br></div><div><br></div><div>We should actually be recording crcs of source files and the assert</div><div>can go off and find the source and report if it matches.</div><div>Or at least the assert can report the crc and user can verify it himself.</div><div>i.e. once an assert fails, you can't do much reliably.</div><div><br></div><div><br></div><div>And yes, when there is no CM3_ROOT or such, unclear what part</div><div>of the path to truncate.</div><div>Which motivates the other option -- don't truncate anything.</div><div><br></div><div><br></div><div>I believe the names have to be unique "across the link".</div><div>Visible or not, I'm not sure it matters.</div><div>I don't believe we use the "static" feature of C/.obj files,</div><div>so even non public functions, and the globals, are in a shared global</div><div>namespace.</div><div><br></div><div>And with dynamic linking, you can't be sure they don't survive</div><div>into the dynamic link search space at least on Unixy systems..</div><div><br></div><div> - Jay<br><br><br><br><div>> Date: Sun, 30 Aug 2015 12:26:21 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] paths too truncated in assertion failures<br>> <br>> I too have long wished for a longer path in these messages. Although<br>> all source files in a package are required to have unique simple names,<br>> I doubt this is true between packages, except for visible interfaces.<br>> Even when unique, unless you have it all memorized, it is just an extra<br>> step to find a source file from only a simple name, when you are trying<br>> concentrate on the bug. "../src/" usually provides no information.<br>> <br>> I would be happy if the paths only went back as far as, say, cm3, for<br>> things in the repo, but how would we define where to stop for outside<br>> code? In a way, I think a full path as on the machine where the program<br>> was compiled might be more helpful anyway. Otherwise, that is really lost<br>> information, if you have any reason to care about it. A partial path<br>> that translates in an apparent way from the compiling to the executing<br>> machine could even be misleading, as the files could be quite different.<br>> <br>> OTOH, this can happen even when it's all the same machine, though probably<br>> less likely.<br>> <br>> On 08/29/2015 05:12 PM, Jay K wrote:<br>> > These messages:<br>> ><br>> > ***<br>> > *** runtime error:<br>> > *** <*ASSERT*> failed.<br>> > *** file "../src/convert/Convert.m3", line 47<br>> > ***<br>> ><br>> ><br>> > 1) It should really be a full path.<br>> ><br>> > I know people will disagree with me.<br>> > You want more commonality across machines.<br>> > I'm not sure that is worth it.<br>> > In particular, debuggers always work more easily with full paths, for local private builds.<br>> > Hopefully for debugging someone else's, some search path<br>> > with "prefix replacement" is viable.<br>> > But debugging your own build is more common and ideally<br>> > no special setting is needed to make that work.<br>> ><br>> > Yes, full paths could "leak" across machines but I think that is ok.<br>> ><br>> > I did work on this long ago but people disagreed with at the time.<br>> ><br>> ><br>> > 2) We could/should trim the root of the git checkout, so it says<br>> > e.g. m3-sys/m3front/src/convert/Convert.m3 if that is easy.<br>> ><br>> ><br>> > Some C compilers have that feature, when people are concered<br>> > with cross machine consistency for the sake of caching and similar<br>> > build optimizations.<br>> ><br>> ><br>> > I still prefer #1.<br>> ><br>> ><br>> > 3) Or at least m3front/src/convert/Convert.m3<br>> > 3b) or ../../m3front/src/convert/Convert.m3<br>> ><br>> ><br>> > if we really want it to be a correct relative path from the target directory.<br>> ><br>> ><br>> > A big part of the problem is the build system is geared toward packages,<br>> > not multiple packages. I'd like to solve this problem too somehow someday.<br>> ><br>> ><br>> > Really -- #1 -- source paths should be full paths.<br>> ><br>> > C compilers vary here btw, in terms of what __FILE__ is and what is<br>> > in debugging information.<br>> > Sometimes whatever is passed on the command line is used.<br>> > Sometimes full paths are computed by the compiler.<br>> ><br>> ><br>> > - Jay<br>> ><br>> ><br>> > _______________________________________________<br>> > M3devel mailing list<br>> > M3devel@elegosoft.com<br>> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> ><br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br></div></div> </div></body>
</html>