Thanks. It's rather impressive, especially when I also looked at the new code
inserted into the script.
Nevertheless, I've found some important bugs, and I think this is the time for
human correction to the new code. The impression I get from it is that the
changes were made by someone (or something!) new to the project who has not yet
had experience of the complications I've dealt with over the years.
I'm hoping to try my hand at this. One motivation is that I am working with a
colleague who has been suffering from extremely long compilation times on his
typical scientific papers. (Long story here.) We've been working out ways to
improve this by a large factor. (That included a bug correction in the new
latexmk version.) Parallelization of custom dependencies would be valuable for
some cases. They are independent custom dependencies, and so very appropriate
for parallelization. But the current parallel version of latexmk failed quite
dramatically. I think the ultimate cause of the difficulty is that the source
files for the custom dependencies are generated during the pdflatex compilation
instead of being made by an external program like a diagram editor. I
conjecture that the parallelization code messes up some of the dependency
handling. (I already see a related issue in the treatment of file locks.)
(In contrast, parallelization worked beautifully on a book of mine, where the
custom dependencies are to make graphics files from source files generated by
other software.)
Luckily, the changes to the code made by copilot are nicely localized and
commented. They are also reasonably clean and clear, so improving it should be
reasonable to do.
I'll describe the bugs separately. But I also saw that copilot didn't
implement the treatment of Windows properly. It used a test for the
latexmk-defined variable $Windows_like, instead of testing the the OS being
reported as 'MSWin32'. So the copilot vetoed parallelization when the the
cygwin and msys version of perl is used, even though they run under a
linux-emulation subsystem that implements fork suitably, so that
parallelization works.
John
On 3/26/26 10:17 AM, Barak A. Pearlmutter wrote:
The github/copilot task sessions are apparently restricted in a
fashion that prevents tehm from being made public, even read-only, in
any straightforward fashion.
So I downloaded the task session HTML <body>...</body> (2Mb) and
uploaded the file to claude.ai and asked it to convert it to a
github-flavored markdown file preserving the collapsible parts (360k)
then uploaded it into a github gist.
https://gist.github.com/barak/50bdc4678ef0f06ab978a3e522f82e4c
Enjoy!
