Re: [bug #43122] texi2dvi does not compile enough times to get toc

[Vincent Belaïche]

My answers below...

Le 04/09/2015 12:20, Gavin Smith a écrit :
> On 3 September 2015 at 22:02, Vincent Belaïche
> <address@hidden> wrote:
>> Hello Gavin,
>>
>> I had a look to your second patch, and I have some comments
>>
>> 1) on the way that you have factorized code between functions
>>    generated_files_get_from_fls and generated_files_get_from_log, what
>>    you did is call one of this functions inside generated_files_set and
>>    place the result in a variable generated_files, and then echo this
>>    variable content as the first stage of the pipe inside
>>    generated_files_get. It seems over-complex compared to the method
>>    which I have used in my second patch : just call one of these two
>>    functions by using a function pointer $generated_files_raw_get as the
>>    first stage of the pipe.
>
> It stops the output files (log or fls) being grep'd multiple times.
> Although I do see that it could be harder to follow what's happening.
> I did it the way you suggested, and it worked okay.

Ok, I had not understood the motivation. If generated_file_get is called
several times for the same tex run, then it is not only grepping that
is uselessly duplicated, but also sorting and uniqing.

I think that this is an optimization issue that we should address as a
different change request. What we need is some cache mechanism for the
generated_file_get function with some generated_file_flag flag that is reset at 
every
run_tex and set at every generated_file_get function. The
generated_file_get would save its result in some variable
generated_file_cache and use $generated_file_cache when
generated_file_flag is set, or do the processing otherwise.

Maybe rather than setting the flag in run_tex, generated_file_flag could
save the fls/log file timestamp in some variable generated_file_ts, and
use generated_file_cache when the file time stamp is equal to
$generated_file_flag.

Well, anyway, this is another issue.

>
>>
>>    Also, I don't understand why you need to bracketize
>>
>
[...]


>> 4) I don't think that the .fls to .flz renaming can work properly. The
>>    problem is that whatever renaming you use, you will still have at
>>    some point tex writing the .fls file as a recorder file, at the same
>>    time as reading it as an \input file.
>
> Maybe the recorder file is separate from the other files in a way and
> there's no problem with it having the same name as a file opened with
> \openout or \openin?
>

Yes, I think so. This is not the problem I had in mind (see below)

> From the point of view of the operating system, there's no problem,
> because these are two different files, in different directories.

No ! With MikTeX I find the recorder file in the *SAME* directoy as the
the index file. I modified the dummy.texi example, and I put just before
the \input texinfo line some TeX code that creates 1400 lines in the
recoder file --- the intension was to force TeX do some flushing of
recoder file to hard drive, so that when inputing the index there would
be some collision. But this did not happen --- execution was *VERY*
slow, but the compilation cycling and the output dummy.pdf were ok. The
only thing is that bash has output some message that the forking
resource was temporarilly not available --- well TeX was stuck for some
time before it could exit.

So I think that MikTeX si playing some smart trick, like writing the
recorder to some temp file, and in the last minute, just before exiting,
moving this temp file to the real recorder file. I don't not, really,
how it could work, but anyway we should investigage.

> It depends then on the point of view of the TeX program.
>
>>    I am not even sure that MikTeX consider at all the TEXINPUTS env
>>    variable. Anyway, even if MikTeX would consider this variable that
>>    would not work if you need it, because texi2dvi is running under
>>    MSYS, so the path are set à la MSYS,
>>    e.g. 
>> /c/Programmes/installation/texinfo-install/trunk/util/dummy.t2d/pdf/bak,
>>    while MikTeX expect MSWindows path, with `c:' instead of `/c'. In
>>    general, the use of absolute paths instead of relative paths makes
>>    things more difficult when you are mixing non MSYS application in an
>>    MSYS environment.
>>
>>    I made a test of your patch with the dummy.texi attached, and it
>>    worked fine for the fls/fl/flz stuff when starting from scratch. But,
>>    I think that this is just a lucky strike, and I will strive to make
>>    it fail...
>
> I'm just learning about the TEXINPUTS environment variable for web2c
> and kpathsea, but if we can't control the TeX search path, then there
> would seem to be no hope.
>

That is what I was thinking, but all the same it worked for some magical
reason ;-/. I don't like magics very much, as far as I don't
understand...

Well this is why I was suggesting to solve it at the texinfo.tex level,
by some fl -> _0, that seems more rational.

> I've attached an updated patch. I'm going to get this committed to the
> repository, as a base for further work.

Well, I would like to have Karl's opinion about what direction is the
best one to solve this issue. As I said with MikTeX, yes your patch
seems to work, but that might be, in MikTeX case, thanks to luck or some
tricks played by MikTeX.

If you wish I can provide a patch to texinfo.tex doing the fl->_0 stuff.

   Vincent.



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com

dummy.texi
Description: application/texinfo