All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akira Yokosawa <akiyks@gmail.com>
To: paulmck@linux.vnet.ibm.com
Cc: perfbook@vger.kernel.org, Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [PATCH v2 0/3] qqz and runlatex improvements
Date: Sat, 23 Apr 2016 23:56:20 +0900	[thread overview]
Message-ID: <571B8D14.4090401@gmail.com> (raw)
In-Reply-To: <571B5FBE.6030005@gmail.com>

On 2016/04/23 20:42, Akira Yokosawa wrote:
>>From 0a9063f5bfc9a984b505fefe54d347f39e099f58 Mon Sep 17 00:00:00 2001
> From: Akira Yokosawa <akiysw@gmail.com>
> Date: Sat, 23 Apr 2016 20:37:29 +0900
> Subject: [PATCH v2 0/3] qqz and runlatex improvements
> 

Hi, Paul

I should have mentioned that this series is rebased to the current master
431a80df9d6e ("Fix build error on Fedora 23 with texlive").

Regarding to ("[PATCH v2 2/3] Improve behavior of build scripts"), I
want to add some comments in the form of a reply to your previous feedback.
As I refactored the script, please note that in-line comments do not
exactly match the actual patch.

> To see what I am getting at, please add a "\ref{this is a typo}" or a
> reference to any other non-\label string, then type "make".  This is a
> pure error that no number of reruns will fix, but the build script will
> nevertheless crank away multiple times.
> 

I checked several intentional error cases for this patch. However, I'm
sure you are the one who will use the scripts most heavily, you might
find corner cases I'm not aware of. 

> Before, it would run bibtex and stop.  (Which, I freely admit, wasn't
> particularly good behavior either!)
> 
> My question is whether it is possible to make the script let the user
> know why it is re-running latex, so that the user can choose to kill
> it early, if appropriate.  Or, alternatively (and for extra credit!),
> recognize which labels are undefined, and do more passes if they are
> quick-quiz links.

I've not gone so far as to distinguish whether a warning is of a quick-quiz
link or not, but I think current level of output should be quite useful
for most of the cases. Please give it a try.

>> --- 
>> #!/bin/sh
>> # [snip]
>> #
>>
>> if test -z "$1"
>> then
>> 	echo No latex file, aborting.
>> 	exit 1
>> fi
>>
>> basename=`echo $1 | sed -e 's/\.tex$//'`
>>
>> iter=1
>> echo "pdflatex $iter"
>> pdflatex $basename > /dev/null 2>&1 < /dev/null || :
>> if grep -q '! Emergency stop.' $basename.log
>> then
>> 	echo "----- Fatal latex error, see $basename.log for details. -----"
> 
> Please add "exit 1" here.  (Yes, this was a bug in my orignal.  But as
> long as we are here...)
> 

Done.

>> fi
>> if grep -q 'LaTeX Warning: There were undefined references' $basename.log
>> then
>> 	if test -d "$2"
>> 	then
>> 		bibtex $basename || :
>> 	else
>> 		echo "No bibliography directory, skipping bibtex."
>> 	fi
>> fi
>> while grep -q 'LaTeX Warning: There were undefined references' $basename.log
>> do
>> 	if test "$iter" -eq 4
>> 	then
>> 		echo "Iteration limit: $iter passes through pdflatex"
>> 		exit 1
>> 	fi
>> 	iter=`expr $iter + 1`
> 
> This would be one point to add some indication of why we are doing
> another pass through the loop.  Might be as simple as adding "Undefined
> references" to the "echo" below.  Or maybe even show the last symbol
> listed as undefined.
>

Done.

And I made a change so that the giving-up of the iteration is decided
by the result of comparison of recent two logs. When they have identical
warnings, giving-up logic kicks in (note that there are special cases
mentioned in the commit message) and the remaining warning messages will be
displayed. The messages should contain the info of undefined symbols.

>> 	echo "pdflatex $iter"
>> 	pdflatex $basename > /dev/null 2>&1 < /dev/null || :
>> 	if grep -q '! Emergency stop.' $basename.log
>> 	then
>> 		echo "----- Fatal latex error, see $basename.log for details. -----"
>> 		exit 1
>> 	fi
>> done
>> while grep -q 'LaTeX Warning: Label(s) may have changed' $basename.log
>> do
>> 	if test "$iter" -ge 4
>> 	then
>> 		echo "Iteration limit: $iter passes through pdflatex"
>> 		exit 1
>> 	fi
>> 	iter=`expr $iter + 1`
> 
> This would be one point to add some indication of why we are doing
> another pass through the loop.  Might be as simple as adding "Label(s)
> may have changed" to the "echo" below.
> 

Done.

>> 	echo "pdflatex $iter"
>> 	pdflatex $basename > /dev/null 2>&1 < /dev/null || :
>> 	if grep -q '! Emergency stop.' $basename.log
>> 	then
>> 		echo "----- Fatal latex error, see $basename.log for details. -----"
>> 		exit 1
>> 	fi
>> done
>> grep "LaTeX Warning:" $basename.log
>> exit 0
>>
> 
> 

As for the bibtex part moved to Makefile, I made '.bbl' be dependent
on '.aux.' 
'.aux' requires pdflatex to run for the first time, so I separated
'runfirstlatex.sh.' Since '.aux' is always updated by pdflatex, this
means that bibtex is always invoked for a normal 'make.'
If you absolutely want bibtex *not* to run (and you are sure that '.bib'
files are not modified), touch a related '.bbl' file just before a 'make'.
Then 'runfirstlatex.sh' won't be invoked. But I think bibtex itself is
fairly quick, and simply doing 'make' is acceptable. Please give it a try
and let me know how it feels like.

I also made changes in the comment area at the head of each script. I added
my copyright notices there, but not sure if those are what are expected.
Could you please give a look at them, too?

                                                         Thanks, Akira


  parent reply	other threads:[~2016-04-23 14:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-23 11:42 [PATCH v2 0/3] qqz and runlatex improvements Akira Yokosawa
2016-04-23 11:44 ` [PATCH v2 1/3] qqz: Improve accuracy of cross-links Akira Yokosawa
2016-04-23 11:46 ` [PATCH v2 2/3] Improve behavior of build scripts Akira Yokosawa
2016-04-23 11:48 ` [PATCH v2 3/3] Remove *.bbl from repository Akira Yokosawa
2016-04-23 14:56 ` Akira Yokosawa [this message]
2016-04-23 19:24   ` [PATCH v2 0/3] qqz and runlatex improvements Paul E. McKenney
2016-04-23 19:20 ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=571B8D14.4090401@gmail.com \
    --to=akiyks@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=perfbook@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.