zim-wiki team mailing list archive

[Klaus-Dieter Bauer <bauer.klaus.dieter@xxxxxxxxx>]

2012/12/18 Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>

> On Tue, Dec 18, 2012 at 11:13 AM, JP Vossen <jp@xxxxxxxxxxxxx> 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

Attachment: zim.log
Description: Binary data