[M3devel] paths too truncated in assertion failures

[Rodney M. Bates]

I too have long wished for a longer path in these messages.  Although
all source files in a package are required to have unique simple names,
I doubt this is true between packages, except for visible interfaces.
Even when unique, unless you have it all memorized, it is just an extra
step to find a source file from only a simple name, when you are trying
concentrate on the bug.  "../src/" usually provides no information.

I would be happy if the paths only went back as far as, say, cm3, for
things in the repo, but how would we define where to stop for outside
code?  In a way, I think a full path as on the machine where the program
was compiled might be more helpful anyway.  Otherwise, that is really lost
information, if you have any reason to care about it.  A partial path
that translates in an apparent way from the compiling to the executing
machine could even be misleading, as the files could be quite different.

OTOH, this can happen even when it's all the same machine, though probably
less likely.

On 08/29/2015 05:12 PM, Jay K wrote:
> These messages:
>
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "../src/convert/Convert.m3", line 47
> ***
>
>
> 1) It should really be a full path.
>
> I know people will disagree with me.
> You want more commonality across machines.
> I'm not sure that is worth it.
> In particular, debuggers always work more easily with full paths, for local private builds.
> Hopefully for debugging someone else's, some search path
> with "prefix replacement" is viable.
> But debugging your own build is more common and ideally
> no special setting is needed to make that work.
>
> Yes, full paths could "leak" across machines but I think that is ok.
>
> I did work on this long ago but people disagreed with at the time.
>
>
> 2) We could/should trim the root of the git checkout, so it says
> e.g. m3-sys/m3front/src/convert/Convert.m3 if that is easy.
>
>
> Some C compilers have that feature, when people are concered
> with cross machine consistency for the sake of caching and similar
> build optimizations.
>
>
> I still prefer #1.
>
>
> 3) Or at least m3front/src/convert/Convert.m3
> 3b) or ../../m3front/src/convert/Convert.m3
>
>
> if we really want it to be a correct relative path from the target directory.
>
>
> A big part of the problem is the build system is geared toward packages,
> not multiple packages. I'd like to solve this problem too somehow someday.
>
>
> Really -- #1 -- source paths should be full paths.
>
> C compilers vary here btw, in terms of what __FILE__ is and what is
> in debugging information.
> Sometimes whatever is passed on the command line is used.
> Sometimes full paths are computed by the compiler.
>
>
>   - Jay
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org