Re: PDF is broken for @notation{} encoding

[David Kastrup]

"Phil Holmes" <address@hidden> writes:

> ----- Original Message ----- 
> From: "David Kastrup" <address@hidden>
> To: "James Lowe" <address@hidden>
> Cc: "Phil Holmes" <address@hidden>; <address@hidden>
> Sent: Tuesday, May 26, 2015 9:02 AM
> Subject: Re: PDF is broken for @notation{} encoding
>
>
>> James Lowe <address@hidden> writes:
>>
>>> On 26/05/15 08:35, David Kastrup wrote:
>>>> James Lowe <address@hidden> writes:
>>>>
>>>>> On 25/05/15 16:08, Phil Holmes wrote:
>>>>>> I can try again, but it was consistent.  James might want to try?
>>>>>
>>>>> If it helps.
>>>>>
>>>>> I get the same thing too.
>>>>
>>>> How much effort is it to do one iteration on one affected file?  I have
>>>> absolutely no clue how this may come about so if one could figure out
>>>> _which_ of the added defines is responsible, it might help boiling this
>>>> down.  One can probably do some sort of manual bisection on the added
>>>> commands but it would still require something like 7 runs.
>>>>
>>>
>>> I don't really have any experience with 'bisections' so if you can give
>>> me some relatively simple instructions, I don't mind doing the gruntwork
>>> building doc over and over.
>>
>> Oh, I was not talking about "git bisect".  I was talking about figuring
>> out manually which of definitions was at fault here.  The whole diff is
>
>
> I'll do this later today.

Thanks.  The process as I outlines it basically assumes a single
culprit.  It may make sense to verify sometimes that the untested half
indeed behaves as expected (namely opposite to the tested half).  This
additional check will make sense particularly at the start of the
process (when one determines the behavior when deleting the whole first
half of the diff) and at the end (when one determines which of two
definitions might make the whole difference).

Obviously we cannot test all possible 2^32 combinations.  But about 2 to
3 more tests over the 5 tests needed under the assumption that exactly
one definition is at fault would likely clarify things more.

-- 
David Kastrup