[tex-live] "Invisible" errors during installation

[Siep Kroonenberg]

On Sun, Nov 16, 2008 at 03:55:44PM +0000, Philip TAYLOR wrote:
> Dear Siep --
>
> Siep Kroonenberg wrote:
>> On Sun, Nov 16, 2008 at 11:42:19AM +0000, Philip TAYLOR wrote:
>>> would you like me to revert to e-mailing the list rather
>>> than just you two ?
>>
>> Please do.
>>
>> As to the hang: PostMessage doesn't seem to do the job, so I am
>> going to try SendMessageTimeout instead.
>
> "Doesn't do the job" as in "Doesn't send a message",
> or "Doesn't cure the hang" ?  As far as I can tell,
> it cures the hang, but I have never seen any
> message from the installer that I can recognise
> as such, so I do not know if any of the versions
> have ever successfully produced a message on
> my system.  What format would you expect the
> message to take, and in which window should it
> occur ?

It is supposed to notify the system that environment variables have
changed. This notification doesn't seem to have taken place with
PostMessage, i.e if I start a new command console then it shows the
old environment variables. This is not fatal to the installation,
since a re-login will take care of the notification. But according
to you it does cure the hang.

>> A question: are these results from your virtual machine or from your
>> live system? All these problems cost us an enormous amount of time,
>> so I would like to be sure that we are debugging the TL installer,
>> not your Windows installation.
>
> Well, I have no wish to place any unneeded load on your time,
> but equally I do not have any evidence to suggest that my
> Windows installation is defective : the most recent error
> reports were all from the live system, because having
> proved in the VM that the hang did not occur, I needed
> to get back to trying to find out why it /did/ occur
> on the live system.  I think it is fair to suggest that
> if SendMessage can cause a hang on my system, it can
> cause a hang on others, and therefore we should try
> to identify the cause and eliminate it.  To support
> this, I think it is clear that Microsoft would not
> have gone to the trouble of writing SendMessageTimeout
> if timeouts were not expected to (a) occur, and
> (b) cause problems.
>
> ** Phil.

In the case of the hung broadcast message, you pointed out a simple
workaround that can be implemented whether or not we can reproduce
the problem. I just need to check that it doesn't upset anything.
As I wrote above, my even simpler workaround - which hasn't been
committed yet - does create a new problem but maybe
SendMessageTimeout does better in this respect.

But in general, it is difficult to fix problems that we cannot
reproduce. If you can't reproduce the problem on your virtual
machine then there is a strong possibility that we won't be able to
reproduce the problem either.

But I agree that it would be desirable if users got a clear message
in case of non-fatal problems.

-- 
Siep Kroonenberg