Notes |
|
|
Ditto for the Java grade. The issue is not present in rotd-2019-04-16. |
|
|
(0001025)
|
zs
|
2019-04-17 23:23
|
|
The problem was probably triggered by commit df47de186bf59c8c97010455c29c7ad765bfa3da,
but that was on March 31. So two things that may be
worth looking into are (a) why hasn't been a problem
in the last two weeks, and (b) why isn't this a problem
in other grades? |
|
|
(0001026)
|
zs
|
2019-04-17 23:25
|
|
It seems our notes crossed paths. If the problem was not present
in rotd-2019-04-16, then the March 31 commit could not have been
the cause.
What was the last commit present in rotd-2019-04-16? |
|
|
|
rotd-2019-04-16 was commit b70bdb2d9557ccc3f62abbc291a25dbc2f8dfc23.
(FYI, commit ids for all rotds are listed on the download page.)
The obvious point of difference between the csharp / java grades and the others is that the former
are compiled using --use-mmc-make.
|
|
|
(0001028)
|
zs
|
2019-04-17 23:54
|
|
There has been only one commit since, and that was a refactoring that should have had
only one change that could cause a change in behavior: the addition of this sanity test
in modules.m:
expect(unify(ModuleName, ParseTreeModuleName), ...)
Does the problem still occur if this is taken out? I can't check since my machine
does not have C#. (I will get a new laptop soon, which will get C# and Java.) |
|
|
|
Yes, the problem still occurs if that check is taken out. |
|
|
|
Annoyingly I can't check if the same issue occurs with --use-mmc-make and the C grades since
we have some problem there with the .mh files in the browser directory not being created, specifically
when we got to compile the trace directory:
./scripts/mgnuc --grade asm_fast.gc --c-debug --no-ansi -- -I. -IMercury/mihs/. -c mercury_trace_browse.c -o mercury_trace_browse.o
mercury_trace_browse.c:28:25: fatal error: mdb.browse.mh: No such file or directory |
|
|
|
Actually the issue with the trace directory is likely a manifestation of the same problem since building with --use-mmc-make works fine in asm_fast.gc with rotd-2019-04-16. (The C# and Java grades skip over the trace directory which is why the problem shows up in different places.) |
|
|
(0001033)
|
zs
|
2019-04-18 01:16
|
|
I just found and fixed a cut-and-paste bug. I think it should fix bug 478.
Please try it out.
By the way, testing proposed bug fixes for bugs with --use-mmc-make have
always been harder for me than testing for fixes for other kinds of bugs.
For other bugs, I build the maybe-fixed executable in a workspace, and use
a wrapper around lmc to try it out. But the lmc script sets up the environment
only for compilations that do NOT use --use-mmc-make, so this does not
work for --use-mmc-make bugs.
Since I don't use --use-mmc-make frequently, this is rarely a problem for me.
Since you use the Java and C# grades reasonably regularly, I expect it would be
more of a problem for you. How do you handle it? |
|
|
|
I've just restarted the ROTD build, so we'll know in a bit.
Generally, if I'm working on stuff related to the C# and Java grades I just install the whole system
and and work with that. (Once it is installed you can do an install from within the compiler directory if,
for example, the work is related to the compiler.) That's obviously not a great solution and I suspect it's only bearable because I have access to machines with lots of cores and lots of memory, so parallel builds at -j8 or more are feasible. |
|
|
(0001035)
|
zs
|
2019-04-18 01:48
|
|
That is what I do as well.
The reason why I don't find it satisfactory is not the CPU workload,
but the context switch overhead. I have to switch to doing something else
while waiting for the install, and switch back later when it is complete.
This wipes out details held in my brain's short term memory, requiring
them to the rebuilt later (and maybe again and again).
I was hoping you, or someone else who works with --use-mmc-make more than me,
would have found it less work in the long term just to teach lmc about --use-mmc-make. |
|
|
|
|
|
(0001037)
|
zs
|
2019-04-18 05:27
|
|
|