2012/12/18 Jaap Karssenberg <jaap.karssenb...@gmail.com> > On Tue, Dec 18, 2012 at 11:13 AM, JP Vossen <j...@jpsdomain.org> wrote: > > On 12/18/2012 02:57 AM, Jaap Karssenberg wrote: > >> > >> Probably you have to use the "--standalone" switch in this case. This > >> was also reported for version 0.57. > > > > > > Yup, that worked. And now that you mention it, I vaguely remember that. > > > > So either of these work in a shortcut: > > "C:\Program Files\zim\zim.pyw" --standalone > > --or-- > > C:\Python26\pythonw.exe "c:\Program Files\zim\zim.pyw" --standalone > > > > (Anyone who gets here via search engine, note my previous message > detailing > > where "zim.pyw" came from.) > > Just tested on my own system, but for me running pythonw *without* > --standalone works just fine. Executed with a shortcut terminal pops > up briefly but closes automatically when zim window pops up. (Which > makes sense as the initial process quits ones the background process > is started.) > > Using python 2.7 on windows 7. > > Regards, > > Jaap
Some observations from my side (Windows 7 64bit, Python 2.7 (Enthought Distribution), zim 0.58). If run as "python zim.py", I get the notebook-selection dialogue and can open other notebooks with Ctrl-O. But If I press F1, the manual doesn't appear. When adding either --debug or --verbose, the console says on F1-press: C:\Python27\python.exe: can't open file 'zim': [Errno 2] No such file or directory If I run zim as "pythonw zim.py" I get the notebook-selection dialogue, but after selecting a notebook the notebook dialogue disappears, pythonw.exe keeps running in the background but nothing happens. In order to get debug output I modified zim.py (saved as zim-customstart.py) to write zim.log also when run with pythonw.exe ( see also https://bugs.launchpad.net/zim/+bug/1091606 ). I ran "pythonw zim-customstart.py --verbose --debug", tried to open a notebook and then killed the pythonw-processes to gain access to zim.log, which reads: Traceback (most recent call last): File "<string>", line 1, in <module> File "C:\Python27\lib\multiprocessing\forking.py", line 373, in main prepare(preparation_data) File "C:\Python27\lib\multiprocessing\forking.py", line 488, in prepare '__parents_main__', file, path_name, etc File "E:\portable\zim-0.58\zim-customstart.py", line 79, in <module> zim.main(argv) File "E:\portable\zim-0.58\zim\__init__.py", line 294, in main zim.ipc.handle_argv() File "E:\portable\zim-0.58\zim\ipc.py", line 117, in handle_argv servermain() File "E:\portable\zim-0.58\zim\ipc.py", line 296, in servermain os.dup2(si.fileno(), sys.stdin.fileno()) OSError: [Errno 0] Error Just for reference from ipc.py the relevant code part: def servermain(): '''Main function for the servr process''' # Decouple from parent environment # and redirect standard file descriptors os.chdir("/") si = file(os.devnull, 'r') os.dup2(si.fileno(), sys.stdin.fileno()) # Here the Error occurs. I.e. setting STDIN to "devnull" fails. Interestingly though, when run from an interactive console (both ipython and "python -i") the code works (but renders the console unusable). The maimed python processes kept running after closing the host window (cmd.exe) and caused some single-core CPU load. Per running "maimed" python process, there was 4% cpu load by python.exe and an additional 4% in csrss.exe (Client/Server Run-Time Subsystem according to neuter.com), i.e. totalling half a core on my hyperthreaded quadcore. The spike in heat and fan noise of the device suggest that turbo-boost was active too. It seems windows doesn't like STDIN being connected to "NUL" for whatever reason. Interestingly, when running a script-file import os import sys nul = file(os.devnull,'r') os.dup2(nul.fileno(), sys.stdin.fileno()) print "test" the script terminated without any issues, so the weird behaviour of interactive sessions probably is causes by the interactive processing of input. Sadly, "Errno 0" isn't exactly helping either. Assuming this is a forwarded C-error-code, 0 should normally mean, that there is NO error. Anyway, among the possbile error reasons for the C-function dup2, I found only one plausible reason: One of the file descriptors may be invalid. -- Addition -- In further test-runs I produced a yet more-confusing zim.log. In addition to the OSError it contains a region of binary zeros (for whatever reason) and some EOFError: Traceback (most recent call last): File "zim-customstart.py", line 79, in <module> zim.main(argv) File "E:\portable\zim-0.58\zim\__init__.py", line 445, in main gui = server.get_notebook(notebook) File "E:\portable\zim-0.58\zim\ipc.py", line 757, in get_notebook return self.get_proxy(RemoteObject(self._notebookklass, uri), open) File "E:\portable\zim-0.58\zim\ipc.py", line 739, in get_proxy self.init_object(remoteobject) File "E:\portable\zim-0.58\zim\ipc.py", line 705, in call re = conn.recv() EOFError The full log file is sent as attachment. regards, Klaus
zim.log
Description: Binary data
_______________________________________________ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp