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