Mac OS X mode issues

[Wanimatrix]

These modes currently don't work on Mac OS X:

• Dialog

Traceback (most recent call last):
  File "./kotnetcli.py", line 220, in <module>
    aanstuurderObvArgumenten(argumentenParser())
  File "./kotnetcli.py", line 184, in aanstuurderObvArgumenten
    co = communicator.DialogCommunicator()
  File "/Volumes/MacintoshHD/Users/wouterfranken/Development/kotnetcliFork/kotnetcli/communicator.py", line 111, in __init__
    self.d = Dialog(dialog="dialog")
  File "/usr/local/lib/python2.7/site-packages/dialog.py", line 1346, in __init__
    self._dialog_prg = _path_to_executable(dialog)
  File "/usr/local/lib/python2.7/site-packages/dialog.py", line 485, in _path_to_executable
    "can't find the executable for the dialog-like "
dialog.ExecutableNotFound

• Bubble

Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
Traceback (most recent call last):
  File "./kotnetcli.py", line 220, in <module>
    aanstuurderObvArgumenten(argumentenParser())
  File "./kotnetcli.py", line 191, in aanstuurderObvArgumenten
    co = communicator.BubbleCommunicator()
  File "/Volumes/MacintoshHD/Users/wouterfranken/Development/kotnetcliFork/kotnetcli/communicator.py", line 94, in __init__
    notify2.init("kotnetcli")
  File "/usr/local/lib/python2.7/site-packages/notify2.py", line 93, in init
    bus = dbus.SessionBus(mainloop=mainloop)
  File "/usr/local/lib/python2.7/site-packages/dbus/_dbus.py", line 211, in __new__
    mainloop=mainloop)
  File "/usr/local/lib/python2.7/site-packages/dbus/_dbus.py", line 100, in __new__
    bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/local/lib/python2.7/site-packages/dbus/bus.py", line 122, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoMemory: Not enough memory

[GijsTimmers]

Thank you.

[jovanbulck]

I doubt that dialog will ever work on OS X since the python implementation uses the Linux/UNIX dialog utility on the back-end and as far as I know, there's no implementation for OS X. That's why you get:

File "/usr/local/lib/python2.7/site-packages/dialog.py", line 485, in _path_to_executable
    "can't find the executable for the dialog-like "
dialog.ExecutableNotFound

We should probably catch this exception for systems that don't have dialog installed and report a nice error message...

[GijsTimmers]

Another option: create a custom Argumentenparser() per OS. Windows supports the least Communicator()s, so ArgumentenparserWindows() should be the first, and ArgumentenparserMac and ArgumentenparserLinux() should inherit methods from the first.

This way, when a user starts kotnetcli with the --help flag, he'll only be presented options that actually work.

[jovanbulck]

We should also fix the import statements in a cleaner way: only import when actually used. I.e. import dialog only in DialogCommunicator.init() and colorama only in ColoramaCommunicator.init() etc.

[Wanimatrix]

Yes, this would be better, we can then delete the dialog dependency for Mac OS X as it doesn’t work anyway so it’s quite useless to download this dependency.

[probberechts]

You just need brew install dialog to get dialog working on OSX.

[jovanbulck]

Thanks, does ./kotnetcli.py -d actually work in master when brew installing dialog on osx?

In the new dev-branch (which at the moment doesn't support dialog yet) communicator dependencies are not imported until needed, so it's not a 'hard' dependency anyway

[Wanimatrix]

Ok, I didn't knew that such a package existed for Mac OS X and it appears to work.
But as I am home now, I will check next week how well it works.

[GijsTimmers]

@probberechts Thank you for reporting this, I've updated the Mac OSX dependencies.

[jovanbulck]

@Wouter92 Communicators have undergone major changes lately. Lazy importing of communicator dependencies should work smoothly now. Could you try it out on OS X? Also, could you give the new Qt GUI front-end a try:

$ git checkout dev-communicators
$ ./kotnetcli-runner.py # or ./kotnetcli-dummy.py if not on KotNet
$ ./kotnetcli-runner.py --dialog
$ ./kotnetgui-runner.py

If no more OS X problems arise, this one can be closed.

[Wanimatrix]

Ok, these are my results:

The first one sometimes fails, when it fails I get:

Kotnetverbinding testen... [ OK ]
Gegevens ophalen.......... [ OK ]
Gegevens opsturen......... [ OK ]
Gegevens verwerken........ [FAIL]
Inloggen.................. [FAIL]
ERROR::Internal kotnetcli exception. Contacteer de kotnetcli developers om ondersteuning te krijgen.
====== TRACEBACK BELOW ======
Traceback (most recent call last):
  File "$KOTNETCLI/kotnetcli/kotnetcli/worker.py", line 47, in go
    self.do_work(co, creds)
  File "$KOTNETCLI/kotnetcli/kotnetcli/worker.py", line 97, in do_work
    self.login_resultaten(co)
  File "$KOTNETCLI/kotnetcli/kotnetcli/worker.py", line 118, in login_resultaten
    tup = self.browser.login_parse_results()
  File "$KOTNETCLI/kotnetcli/kotnetcli/browser.py", line 184, in login_parse_results
    elif self.rccode == RC_INTERNAL_SCRIPT_ERR:
AttributeError: 'KotnetBrowser' object has no attribute 'rccode'
====== END OF TRACEBACK ======

This is partly due to a bug here: the "self" is too much ;). But after fixing that bug I get this:

Kotnetverbinding testen... [ OK ]
Gegevens ophalen.......... [ OK ]
Gegevens opsturen......... [ OK ]
Gegevens verwerken........ [FAIL]
Inloggen.................. [FAIL]
ERROR::De netlogin server geeft een onbekende rc-code '213' terug. Contacteer de kotnetcli developers om ondersteuning te krijgen.
[FAIL]
Inloggen.................. [FAIL]
ERROR::Internal kotnetcli exception. Contacteer de kotnetcli developers om ondersteuning te krijgen.
====== TRACEBACK BELOW ======
Traceback (most recent call last):
  File "$KOTNETCLI/kotnetcli/kotnetcli/worker.py", line 47, in go
    self.do_work(co, creds)
  File "$KOTNETCLI/kotnetcli/kotnetcli/worker.py", line 97, in do_work
    self.login_resultaten(co)
  File "$KOTNETCLI/kotnetcli/kotnetcli/worker.py", line 134, in login_resultaten
    co.eventFailureUnknownRC(rccode, html)
  File "$KOTNETCLI/kotnetcli/kotnetcli/communicator/quietc.py", line 150, in eventFailureUnknownRC
    self.print_err_info(self.err_info_rc.format(html=html))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xef' in position 7371: ordinal not in range(128)
====== END OF TRACEBACK ======

The dialog doesn't work for some reason, when I try it says
ERROR::kotnetcli: import error when trying to create 'dialog' communicator: No module named dialog.
Even after installing dialog via brew.

The gui version works always (that's because it uses the DummyBrowser).

[jovanbulck]

Nice thanks!

This is partly due to a bug here: the "self" is too much ;)

Good catch! You can open a pull request if you like.

But after fixing that bug I get this:

Ok, interesting. I'll open a new bug report for that one.

The dialog doesn't work for some reason, when I try it says
ERROR::kotnetcli: import error when trying to create 'dialog' communicator: No module named dialog.
Even after installing dialog via brew.

All right. That's the expected behaviour: failing gracefully. However, I was not expecting an ImportError but the dialog.ExecutableNotFound exception from above. My bet: you've installed (some) dialog command line utility via brew, but still need to install the python bindings via pip install python2-dialog or so? Could you maybe try running dialog directly from the shell? (Not confident that's even possible at all on OSX.)

The gui version works always (that's because it uses the DummyBrowser).

:-)

[Wanimatrix]

Pull request done.

Ok, after doing pip install python2-pythondialog the dialog works. However, when receiving that 213 code the dialog did not end gracefully: I got a Traceback to this line.

[jovanbulck]

However, when receiving that 213 code the dialog did not end gracefully: I got a Traceback to this line.

Hmm, the problem here is that a new exception is raised while in the process of displaying additional info on the previous one... The current communicators do not anticipate such a scenario. That's also why the ColoramaCommunicator above ouputs two ERROR:: and [FAIL]s. I'll try to have a closer look later.