In the following MWE I put an extra space in front of tikzpicture. When running this with LuaLaTeX, I get 18 errors (not really part of the question, but why is that so sensitive, does matter at all and has such bad error messages???). When running it with arara, I get a complete breakdown of the process. I have to stop the two (why two?) lualatex.exe processes in my Windows Task Manager.

This is really annoying. Is there something in arara or in TeXnicCenter or in LuaLaTeX?

% arara: lualatex: { shell: yes }



\begin{ tikzpicture}    
    \draw (0,0) -- (1,1);


Edit when I stop the process of the first lualatex.exe, the building process continues showing me the one actual error. Then it starts the run and stops as before. When stopping the second process, arara writes ? FAILURE and TeXnicCenter Building process canceled by user.

  • 8
    I believe you answered your question yourself: the correct code is \begin{tikzpicture} (without space). \begin{ tikzpicture} is just wrong, so there is no reason to expect lualatex, arara or any other TeX tool to process it correctly! – Xavier Aug 7 '13 at 13:35
  • 3
    This is the standard behaviour of arara, if any of the commands it runs produces an error, the arara reports FAILED. – Andrew Swann Aug 7 '13 at 14:03
  • 1
    But it doesn't for me. It stops in this line. The button "cancel building process" in TeXnicCenter is out of function. As I wrote: it's a break down or a veeeery slow report of FAILED. My System: MikTeX 2.9 on XP 64 bit. Arara downloaded today. – LaRiFaRi Aug 7 '13 at 14:12
  • 3
    Why the close votes? Also this seems to be a TC bug. From terminal it goes through – percusse Aug 7 '13 at 14:22
  • 2
    I'll take a look. :) My good friend percusse mentioned a similar behaviour before, and I suspect it's somehow related to the way the editor handles external processes (I assume the issue is not reproduced when arara is called from the terminal Update: percusse just confirmed this). I have no Windows machine at the moment, but I'll try to set up a VM and take a closer look at everything, from the JVM memory allocation with arara to the API calls from TeXnicCenter. Sorry for the trouble. – Paulo Cereda Aug 7 '13 at 14:24

Dealing with processes is not a trivial task, sadly.

From the terminal, arara prints the compilation status and ends, as expected. When called from editors, I believe it's a matter on how each developer decided to handle process input/output. From TeXworks, things seem smooth, even if it requires user interaction. I once once a problem with TeXnicCenter when trying to rerun pdflatex: the last process call got stuck somehow and files were locked. The only way to have my files "released" was to kill the offending process via task manager, so things started working again.

TeXnicCenter gave me a couple of headaches in the past, so I still believe there's nothing I could do on my end (the arara part). That said, it's worth mentioning that Windows behaves quite differently from Unix.

arara is a Java program. Any calls to arara will redirect to a call to java -jar arara.jar and the Java Virtual Machine will be in charge of the execution. In Unix, we have that as a shell script (thanks to Karl for the suggestion), and in Windows, it's an .exe; both are, in fact, wrappers to the .jar itself. Maybe, maybe TeXnicCenter is confused with the .exe resolving to a call to the JVM. What I can suggest is the following:

Try replacing the call to C:\Program Files\arara\arara.exe in TeXnicCenter with a direct call to the JVM with java -jar "C:\Program Files\arara\arara.jar", followed of course by the editor parameters. At least now we are "skipping" one expansion from the wrapper to a VM call. But this is just a thought, I have no Windows machine around to test it. :(

Sorry for the imprecise answer, but sadly the solution (if any) is on uncharted territory. As I mentioned before, calling stuff from stuff is very tricky and, most of the time, we just get the idea from phenomena observation. :(

I'm in the middle of developing a new version. I'll see what can be done when dealing with processes. That's also a hint for me to set a Windows VM. At least I'll have Windows inside a cage, where it should be. :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for?Browse other questions tagged or ask your own question.