|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000354||mercury||Bug||public||2014-08-24 09:16||2014-08-30 08:55|
|Platform||AMD64||OS||Gentoo Linux||OS Version||not applicable|
|Target Version||Fixed in Version|
|Summary||0000354: Building mercury_cairo fails in version 14.01|
|Description||Whenever I attempt to build mercury_cairo with Mercury 14.01 I get a failure as follows:|
Installing grade reg.gc.decldebug.stseg
Uncaught Mercury exception:
Software Error: transform_hlds.table_gen: predicate `transform_hlds.table_gen.type_save_category'/2: Unexpected: unexpected category
** Error making `Mercury/reg.gc.decldebug.stseg/x86_64-unknown-linux-gnu/Mercury/cs/cairo.c'.
|Steps To Reproduce||mmc --make libmercury_cairo.install|
|Additional Information||I have tried both gcc-4.8.3 and gcc-4.9.1. My C library is glibc 2.19. My Cairo is version 1.12.16 and is located in /usr. (I adjusted Cairo.options to suit.)|
|Tags||No tags attached.|
The problem also occurs on the current master branch. I have uploaded a minimal test case for it.
Affected grades seem to be all those containing a debug or decldebug component.
I/O tabling has two main purposes. The first and more important is to allow the debugger to replay parts of the program execution for the programmer, which requires making I/O operations idempotent (so that we get the same results on the second, third etc "execution" as on the first). The second purpose is to let the person using the debugger actually see a list of the I/O actions, and their results.
I believe that the root of the problem here is that the compiler can do the second part only if it has access to the type_infos describing the types of the arguments of the I/O action. With the current infrastructure for representing typeclass information, this is not always possible in the presence of typeclass constraints on I/O action predicates. The reason is that polymorphism.m can hide the typeinfo for a type variable that is subject to a typeclass constraint arbitrarily deep inside the typeclass_info for that constraint, but the RTTI can encode such locations only up to a fixed depth (currently only the shallowest embedded is encodable). Rather than allow I/O tabling for SOME typeclass-constrained predicates but not others, the current system consistently does not allow it for any. Of course, the error indication could be better.
When I designed the I/O tabling system, I did NOT design it for I/O actions whose types include typeclass constraints. There were two reasons for this. First, none of the I/O actions in the Mercury standard library have typeclass constraints; second, I/O actions are written in languages like C, which themselves have no class system.
While fully fixing this limitation would be desirable, it would also be a huge amount of work. However, there are two possible short term fixes.
The first fix is actually a simple workaround. I haven't tested it with mercury_cairo, but it works with bug354.m: simply compile the module with the mmc flag --trace-table-io-only-retry. This tells the compiler to generate I/O tabling code that serves only the first purpose I mentioned above (making I/O actions idempotent in mdb), but not the second (printing those actions in mdb).
chemoelectric, please enable this flag for all the modules of mercury_cairo, and tell us what happens.
The second possible fix, which I will look into in the next few days, would make this unnecessary by automatically imposing the effect of --trace-table-io-only-retry on any I/O predicates that have typeclass constraints on them.
|The first workaround also works for the full mercury_cairo library. I'll add that workaround to the 14.01 branch.|
|The workaround works for me, too.|
|Fix committed 2014 aug 30.|
|2014-08-24 09:16||chemoelectric||New Issue|
|2014-08-24 23:14||juliensf||File Added: bug354.m|
|2014-08-24 23:15||juliensf||Note Added: 0000763|
|2014-08-24 23:15||juliensf||Assigned To||=> juliensf|
|2014-08-24 23:15||juliensf||Status||new => confirmed|
|2014-08-25 01:46||zs||Assigned To||juliensf => zs|
|2014-08-25 01:46||zs||Status||confirmed => assigned|
|2014-08-25 02:45||zs||Note Added: 0000764|
|2014-08-25 03:30||juliensf||Note Added: 0000765|
|2014-08-26 04:00||chemoelectric||Note Added: 0000767|
|2014-08-30 08:55||zs||Note Added: 0000768|
|2014-08-30 08:55||zs||Status||assigned => resolved|
|2014-08-30 08:55||zs||Resolution||open => fixed|