If I put '/cygdrive/c/Program Files (x86)/Zotero/zotero.exe' -ZoteroDebugText in CGwin, where do I find the output after Zotero closed?
I'm not sure what you mean here. That should just log to the same Cygwin window, which persists even after Zotero closes.
If I try to save it from the terminal, the file is not created (out of memory). If i select all and copy to clipboard, Zotero is terminated immediately.
It might be helpful to see the end of the output, which you should be able to copy from the terminal even if you can't copy the whole thing.
The only lines appearing in cgwin after entering the command with parameter is:
Christoph@DESKTOP-IKH02IE ~ $ '/cygdrive/c/Program Files (x86)/Zotero/zotero.exe' -ZoteroDebugText [GFX1]: Potential driver version mismatch ignored due to missing DLLs 0.0.0.0 and 0.0.0.0
Nothing is logged in this window at all. My fault?
Not sure — it works for me with that exact same command line. But you can also try setting extensions.zotero.debug.log to true from the Config Editor in the Advanced pane of the Zotero preferences.
Believe it or not, but if Zotero is run within the Cygwin environment, it works and gets through my entire document. The RAM usage climbs to 800mb but remains there (my sqlite-file is about 400mb). All performance graphs (CPU, RAM and I/O) look completely different. It still takes some time (see below) but this is fine!
zotero(3)(+0205880): Integration: updateDocument complete in 2829.968s
zotero(3)(+0015556): Integration: WinWord-refresh:'C:\Downloads-Temp\Gesamtdatei.doc' complete in 4313.876s
To be completely sure I ran the fields-update without Cygwin again. Same error then: out of memory.
I assume this MUST mean something. Somehow Windows (regardless of 32 or 64 bit) is compromising Zotero’s performance. Maybe this is why you could not reproduce my error, as you might work with a Linux machine.
Albeit my case is somehow exceptional, I think (at least within the humanities!) there will be other cases as soon as Zotero users write their “big books”. It would be a bad thing if Zotero has a limit of fields. Maybe you can adjust the standalone engine for Windows machines accordingly?
I am also working in a Max-Planck-Institute and there is some rivalry among EndNote and Zotero users. I will do my best to promote Zotero after this…
One last thing: I would like to express my gratitude to dstillman, adomasven, and fbennett by naming them in the acknowledgements of my thesis. May I do so? May I use real names? If you don’t want to post them, email me at [http://heimat.de/home/c-sander/mail.gif].
Somehow Windows (regardless of 32 or 64 bit) is compromising Zotero’s performance. Maybe this is why you could not reproduce my error, as you might work with a Linux machine.
It's still just the same Windows executable, not a Linux one, even if you're starting it from Cygwin. Did you try via the Windows Run dialog?
@c-sander Glad it worked! Would still be interesting to see the log for the operation, just to see how long which parts of it took and see whether we could improve anywhere.
@dstillman Right. I was a littel mistaken. A typical fallacy: Post hoc ergo propter hoc. The same result is produced if run with the debut flag in windows. Without the flag, it crashes. So, this seems to be the cause.
It seems, btw, that I still can make Zotero crash at 1,4GB RAM usage: By assigning a new CS to the large document. For me, this is not an issue, but in principle...
@c-sander: I have recently been working with data gleaned earlier from Zotero interaction with the document you kindly provided, in connection with a processor performance issue. It is very useful to have such a large data set for testing purposes. Could I have your permission to share the data with other developers of CSL tools?
@fbennett : That's nice to hear, and yes, you can use my data, but please don't make it public (i.e. don't upload it to a public domain etc.) but only share it with your peers and colleagues.
As a matter of fact, the book is going to be published and you and your colleagues will be mentioned in the acknowledgements.
Many thanks - and congratulations on the publication! The care that went into the manuscript is evident from the references. At our end, with the latest kit and in a browser test environment, the citations and bibliography now render in just over 15 minutes, applying one of our most demanding styles.
Upgrade Storage
The only lines appearing in cgwin after entering the command with parameter is:
Christoph@DESKTOP-IKH02IE ~
$ '/cygdrive/c/Program Files (x86)/Zotero/zotero.exe' -ZoteroDebugText
[GFX1]: Potential driver version mismatch ignored due to missing DLLs 0.0.0.0 and 0.0.0.0
Nothing is logged in this window at all. My fault?
Will post the log later.
zotero(3)(+0205880): Integration: updateDocument complete in 2829.968s
zotero(3)(+0015556): Integration: WinWord-refresh:'C:\Downloads-Temp\Gesamtdatei.doc' complete in 4313.876s
To be completely sure I ran the fields-update without Cygwin again. Same error then: out of memory.
I assume this MUST mean something. Somehow Windows (regardless of 32 or 64 bit) is compromising Zotero’s performance. Maybe this is why you could not reproduce my error, as you might work with a Linux machine.
Albeit my case is somehow exceptional, I think (at least within the humanities!) there will be other cases as soon as Zotero users write their “big books”. It would be a bad thing if Zotero has a limit of fields. Maybe you can adjust the standalone engine for Windows machines accordingly?
I am also working in a Max-Planck-Institute and there is some rivalry among EndNote and Zotero users. I will do my best to promote Zotero after this…
One last thing: I would like to express my gratitude to dstillman, adomasven, and fbennett by naming them in the acknowledgements of my thesis. May I do so? May I use real names? If you don’t want to post them, email me at [http://heimat.de/home/c-sander/mail.gif].
--> obviously without the square bracket after the file extension.
The same result is produced if run with the debut flag in windows. Without the flag, it crashes. So, this seems to be the cause.
@adomasven Will post a log asap.
See log: http://heimat.de/home/c-sander/log_crash.txt
--> the log file (pure text) is 150mb!
As a matter of fact, the book is going to be published and you and your colleagues will be mentioned in the acknowledgements.