Does anybody know whether it's possible to get the error-row of a file being compiled when the error occurs in an include file?
For example, I'm compiling a file, say abc.p, that uses def.i all over the place. At some point, I make a change to abc.p that causes a compile error in one of the includes, so the message says that the error occurred at line 123 of def.i, but I want to know at which line in abc.p that is. In other words, the line number where the offending include file is used.
Even though "Compiler:Get-File-Name(n)" returns def.i and "Compiler:File-Name" returns abc.p, both "Compiler:Get-Row(n)" as well as "Compiler:Error-Row" returns the line number in def.i.
Any ideas?
My guess would be to save the compiler listing or debug file and look at that.
Beyond that, I don't think there's a way to do it now - you need to submit an enhancement request to get this functionality.
My way of tracking this kind of error is with
compile source.p preprocess source.pp.
open source.pp in the procedure editor and check syntax.
This gives you the error location in the expanded source.
Once you have found that locate code that is not part of the include and search for that code in the original source.
Related
When I build my Sphinx project I get a series of errors like this one -- three times:
content/swdocs.rsts:6: WARNING: Duplicate substitution definition name: "copy".
sdwocs.rsts contains common definitions. I include it in each ReStructuredText file in my doctree.
Many of the files in the doctree include additional RST files, but those files should not include swdocs.rsts, since they are effectively parts of a file that already includes it.
Something has gone wrong with this scheme -- presumably an included RST file that includes its own copy of swdocs.rsts -- but where? The message gives me no clue.
I've tried to find the error the hard way, by looking at every file where it could possibly be, and I've found nothing. Presumably something is wrong about my analysis of the problem, and it is hiding in some place or some form where it "could not possibly" be... but without a more informative message, I'm stuck.
How to get unstuck?
I have code where I'm writing to a file, and the next time I run the code after the code successfully runs, it gives me the following error:
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process:'minicube_HE022222.fits'
So every single time I have to change the name of the fits file and then there are no errors. It's just really frustrating having to change the filename everytime I run the code. Here is my code snippet:
new_hdu = fits.HDUList([fits.PrimaryHDU(mini_data), fits.ImageHDU(mini_error)])
new_hdu[0].header = qso_header
new_hdu.writeto('minicube_HE022222.fits',overwrite=True)
new_hdu.close()
I get the error at:
new_hdu.writeto('minicube_HE022222.fits',overwrite=True)
I close the file after writing to it but that doesn't help either.
Any suggestions are appreciated.
Update:
Here is another portion of a code where this error occurs:
hdus=[]
hdus.append(fits.PrimaryHDU())
hdus.append(fits.ImageHDU(par[0,:,:],name='amp_Hb'))
hdus.append(fits.ImageHDU(par[1,:,:],name='amp_OIII5007'))
hdus.append(fits.ImageHDU(par[2,:,:],name='amp_OIII5007_br'))
hdus.append(fits.ImageHDU(par[3,:,:],name='amp_Hb_br'))
hdus.append(fits.ImageHDU(par[4,:,:],name='amp_Hb1'))
hdus.append(fits.ImageHDU(par[5,:,:],name='amp_Hb2'))
hdus.append(fits.ImageHDU(par[6,:,:],name='amp_Fe5018_1'))
hdus.append(fits.ImageHDU(par[7,:,:],name='amp_Fe5018_2'))
hdus.append(fits.ImageHDU(par[8,:,:],name='m'))
hdus.append(fits.ImageHDU(par[9,:,:],name='c'))
hdu = fits.HDUList(hdus)
hdu.writeto('subcube_par_HE12_lsq.fits',overwrite=True)
It's only at the 'xxx.writeto' where the error occurs. If there's another way I can write to a file or update the existing file with the new data, please let me know. Thanks
As this comment notes, the way file I/O works on Windows is such that you can't overwrite a file if you have that file already open in another process. Are you writing this file and opening it in another program? If you have that file open in any other program then you can't overwrite it.
Do you need to be able to make in-place updates the file while it is open in another program? If so that may still be possible, but you can't use HDUList.writeto() as that effectively deletes the existing file and replaces it with a new one (rather than updating the existing file in-place).
Also, how are you running this code? Is it in a script? You mentioned having to change the filename every time but you could design things such that you wouldn't have to. I noticed that you have the filename hard-coded in your code, and that can and should be fixed if you want to write a more versatile script. For example, you could accept the filename as command-line argument. You could also have the script append a number to the filename or something if the file already exists.
All that said, you should figure out why you have the same file open in multiple programs.
One small usage aside:
The new_hdu.close() in your example doesn't actually do anything. The HDUList.close() method only makes sense when you open an existing FITS file from disk. Here you're creating an HDUList (the data structure representing a FITS file) in memory, and calling the high-level HDUList.writeto() which opens a file, writes the in-memory data to that file, and the closes the file. So the .close() in this case is a no-op. I'm guessing maybe you added it to try to fix your problem, but it's actually not relevant.
I did not find a better way to show error details in long form.
log.SetFlags(log.Llongfile)
I am particularly interested which file and line error happened. Is it any way to set long format application wide rather than add to every function?
You might want to consider gin to watch and tells you where errors happened after build.
make -C doc html latexpdf
yields this:
Package hyperref Message: Driver (autodetected): hpdftex.
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty))
(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/hypcap.sty))
(/usr/share/texlive/texmf-dist/tex/latex/multirow/multirow.sty)
Writing index file Arakoon.idx
(./Arakoon.aux)
Runaway argument?
{{1.10.3}{9}{Client side support\relax }{subsection.1.10.
! File ended while scanning use of \#newl#bel.
<inserted text>
\par
l.113 \begin{document}
?
If someone is still looking for this: For me usually, when a prior build had failed due to an error, subsequent builds would fail with this error. Solved it by deleting the main .aux file and building it again.
It is impossible to say with any confidence, but it looks like a fragile (non-robust) command in a subsubsection heading or a maths label (would be label 10.1.3), because:
It occurs at \begin{document}, when the .aux files are loaded,
The error indicates a malformed directive in the .aux file, and the presence of a \relax there - typically what command reduce to after having performed their side effect.
Two suggestions:
Generate an MWE by making a new document from this with all the body of your document except that heading/ equation (and perhaps the sentence following) deleted. Does this create the same error? If so, post it here. You might need some trial and error to find out which Lat3ex command is responsible, but it should contain the text Client side support.
Do read https://tex.stackexchange.com/questions/4736/what-is-the-difference-between-fragile-and-robust-commands - if I am right, you have a fragile command where it shouldn't be. Figure out what should be there instead.
Some executable files have resources marked "language neutral".
Is it possible to package these binaries using WiX?
The error I receive is: error LGHT0204 : ICE03: Invalid Language Id; Table: File, Column: Language, Key(s)
Setting the Product.Language attribute to '0' does not fix the problem.
You can suppress the retrieval of file information by passing this option to light.exe:
-sh
Suppress file information: do not get hash, version, language and
other file properties
To fix the original cause of the error, compare the incorrect language ID to the ones here.
Alternatively, if you verify that the Language Id is truly valid (I've never seen a case where the ICE was wrong though) then I would suppress the ICE before suppressing the hash information (-sh). The hash information is very important for your install. Instead use "light.exe -sice ICE03" to skip that ICE.
Also note that the ICE03 checks are pretty important so make sure you solve all the other issues befor supressing this it. There is a feature request out there to suppress only specific errors instead of the whole ICE.