Python wmiirc: Mod-a and Mod-p not working

[GoogleCodeExporter]

What steps will reproduce the problem?
1. wmii -r python/wmiirc
2. Mod4-p or Mod4-a
3.

What is the expected output? What do you see instead?
I expect a menu to show up. But nothing happens.

What version of the product are you using (wmii -v)? On what operating
system?
hg2518. Python was updated to 2.6.3 yesterday, if that matters.

Please provide any additional information below.
The tag menus are working fine.
I did the updates wmii from 2511 to 2518 and Python to 2.6.3 at the same
time. So there may be the chance that this is Python related.
Unfortunately, I cannot roll back to 2.6.2, to check this.

Original issue reported on code.google.com by skwi...@googlemail.com on 4 Oct 2009 at 6:40

[GoogleCodeExporter]

Some status scripts are not updating for me anymore. This came up at the same 
time,
so maybe it is related. If not, tell me and I will file a separate issue.

Correctly updating:
@defmonitor
def battery(self):
    for line in open('/proc/acpi/battery/BAT1/state','r'):
        if len(line.split()) >= 3 and line.split()[0] == 'remaining':
            return line.split()[2] + 'mAh'
    return 'no battery info'

Not updating since the update from 2511 to 2518:
@defmonitor
def netz(self):
    return call('iwgetid', '-r')
@defmonitor
def time(self):
    return call('date','+%a %d %b %T')

(The shipped time function never worked for me (did not update even before 
2511),
this is why I use this call to date.)

Original comment by skwi...@googlemail.com on 4 Oct 2009 at 6:50

[GoogleCodeExporter]

Issue 139 has been merged into this issue.

Original comment by maglion...@gmail.com on 14 Oct 2009 at 7:51

[GoogleCodeExporter]

Maybe this helps:
> wmiir xwrite /ctl exec wmii -r python/wmiirc
-> Mod-p -> nothing happens, no menu.
> wmiir xwrite /ctl exec wmii -r wmiirc
-> The menu comes up immediately.

Looks like anything blocks the menu from spawning until the Python wmiirc 
finishes.

I know you asked me to check since which revision this occurs, but it is a bit
difficult with the Arch PKGBUILDS to update to anything but tip.
However, I tested the Python wmiirc (with tip) on a Gentoo machine with Python 
2.6.2
and this issue does not occur. All menus are fine.

Original comment by skwi...@googlemail.com on 15 Oct 2009 at 8:00

[GoogleCodeExporter]

Just noticed that the menu I talked about has no choices and anything I type 
into it
is not executed.

Original comment by skwi...@googlemail.com on 15 Oct 2009 at 8:07

[GoogleCodeExporter]

Can one of you please run the attached script and post the results, along with 
any
observations? Instructions are at the top of the file.

Original comment by maglion...@gmail.com on 16 Oct 2009 at 10:06

Attachments:

• menu_test.py

[GoogleCodeExporter]

Expected results:
    Calling Async, daemon
    Result: Async, daemon: a
    Calling Async, nodaemon
    Result: Async, nodaemon: b
    Calling Sync,  nodaemon
    Result: Sync,  nodaemon: c
    Calling Pre-imported, daemon
    Result: Pre-imported, daemon: d
    Calling Pre-imported, nodaemon
    Result: Pre-imported, nodaemon: e

Calling Async, daemon
Result: Async, daemon: a
Calling Async, nodaemon
Result: Async, nodaemon: b
Calling Sync,  nodaemon
Result: Sync,  nodaemon: c
Calling Pre-imported, daemon
Result: Pre-imported, daemon: d
Calling Pre-imported, nodaemon
Result: Pre-imported, nodaemon: e

With the menu open entering "killall menu_test.py" works as intended.

Original comment by rusty.a...@googlemail.com on 16 Oct 2009 at 10:34

[GoogleCodeExporter]

That's somewhat distressing. Ok, we'll have to try the installed module:

#!/usr/bin/env python
import os, sys, time
sys.path = [p + '/python' for p in os.environ['WMII_CONFPATH'].split(':')] + 
sys.path

from pyxp.client import Client
keys = Client(namespace='wmii').read('/keys')
from pygmi import Menu, call
Client(namespace='wmii').write('/keys', keys)

Menu(choices=call('ls', '/usr/bin').split('\n'),
     action=lambda v: sys.stdout.write(v + '\n')).call()

time.sleep(400)

Original comment by maglion...@gmail.com on 16 Oct 2009 at 12:29

[GoogleCodeExporter]

Saving the above as program_menu and invoking with "python program_menu" brings 
up 
wimenu and the normal searchable list of commands/programs, anything that I 
attempt to 
execute gets printed to stdout without actaully being executed. 

Original comment by rusty.a...@googlemail.com on 16 Oct 2009 at 2:36

[GoogleCodeExporter]

Ok...

Let's make sure that the keys are actually grabbed. Run `wmiir read /event`
and then press M-p (whatever your modifier key is) and M-a and see if you get
any Key events. If not, run `wmiir read /keys` and make sure that they're
actually there.

If that works, add the next 2 lines to ~/.wmii/wmiirc_local.py:

from wmiirc import Actions
events.bind({ 'Eval': lambda args: Actions.eval_(args) })

After you restart wmiirc (or wmii), you should be able to eval arbitrary
python code from your wmiirc's context. So, first stab:

    wmiir xwrite /event 'Eval program_menu.call()'

That should launch the program menu, in theory. May as well add the next two
for good measure:

    wmiir xwrite /event 'Eval action_menu.call()'
    wmiir xwrite /event 'Eval tag_menu.call()'

If that doesn't work, try these:

    wmiir xwrite /event 'Eval Menu(choices=list("abcde")).call()'
    wmiir xwrite /event 'Eval call("wimenu", input="a\nb\nc\nd")'

One of the above has to fail.

Original comment by maglion...@gmail.com on 16 Oct 2009 at 3:40

• Added labels: Component-Scripts, Milestone-Release-3.9, Priority-Critical, Type-Defect

[GoogleCodeExporter]

    wmiir read /event 
Mod+a/p returns correctly.

    wmiir xwrite /event 'Eval program_menu.call()' 
    wmiir xwrite /event 'Eval action_menu.call()'
These don't return anything.

    wmiir xwrite /event 'Eval tag_menu.call()'
    wmiir xwrite /event 'Eval Menu(choices=list("abcde")).call()'
    wmiir xwrite /event 'Eval call("wimenu", input="a\nb\nc\nd")'
All return an action, either the tag menu or 'a b c d e' 'a b c d' action menu 
options.

Adding my wmiirc_local.py just in case,

import pygmi
from pygmi import *

from wmiirc import Actions
events.bind({ 'Eval': lambda args: Actions.eval_(args) })

# Load Monitor
monitors['load'].active = False
@defmonitor
def s5load(self):
  return ' '.join(open('/proc/loadavg').read().split(' ')[:3])

# Clock
from datetime import datetime
@defmonitor(colors=wmii['normcolors'], name='time')
def time(self):
    return datetime.now().strftime('%c')

# Tagging
wmii.tagrules = (
  ('MPlayer|VLC', '~'),
  ('mutt|Sylpheed', '+email'),
  ('ncmpcpp', '+music'),
  ('icecat', '+web'),
)

# Keybinds
keys.bind('main', (
  "Running programs",
  ('%(mod)s-Shift-q', "Quit",
    lambda k: wmii.ctl('quit')),
))

Original comment by rusty.a...@googlemail.com on 16 Oct 2009 at 4:12

[GoogleCodeExporter]

Ok, great, that's progress.

My best guess, judging by your other problems with status monitors, is that
your system has issues with importing modules from within functions. I think
this should solve your problem:

sudo patch "${WMII_CONFPATH##*:}/python/pygmi/menu.py" <<!
--- a/alternative_wmiircs/python/pygmi/menu.py
+++ b/alternative_wmiircs/python/pygmi/menu.py
@@ -1,4 +1,5 @@
 from pygmi.util import call
+from threading import Thread

 __all__ = 'Menu', 'ClickMenu'

@@ -10,7 +11,6 @@ def inthread(fn, action):
         return res
     if not action:
         return run()
-    from threading import Thread
     t = Thread(target=run)
     t.daemon = True
     t.start()
!

Original comment by maglion...@gmail.com on 17 Oct 2009 at 8:18

[GoogleCodeExporter]

Still no luck.
I've not played a lot with arch's PKGBUILD or patching, but wmii built fine and 
the 
patch looks to have been applied.

cat -n /etc/wmii-hg/python/pygmi/menu.py

     1  from pygmi.util import call
     2  from threading import Thread
     3  
     4  __all__ = 'Menu', 'ClickMenu'
     5  
     6  def inthread(fn, action):
     7      def run():
     8          res = fn()
     9          if action:
    10              return action(res)
    11          return res
    12      if not action:
    13          return run()
    14      t = Thread(target=run)
    15      t.daemon = True
    16      t.start()
    17  
    /* snip */

Original comment by rusty.a...@googlemail.com on 17 Oct 2009 at 10:20

[GoogleCodeExporter]

Well, that patch was meant to be applied after install.
I applied it and see no difference. Menus not working.

Original comment by skwi...@googlemail.com on 17 Oct 2009 at 6:10

[GoogleCodeExporter]

Ok, I managed to have a PKGBUILD for a fixed revision. So I went back till 
3.9a2,
which definitely worked for me, and it did not work. This makes me think that 
the
Python 2.6.3 update broke things instead of any wmii update. Would be good if 
anyone
can confirm working menus with Python 2.6.3.

Original comment by skwi...@googlemail.com on 17 Oct 2009 at 6:52

[GoogleCodeExporter]

Thanks, updating python breaks it for me, too.

Original comment by maglion...@gmail.com on 17 Oct 2009 at 10:06

[GoogleCodeExporter]

Can you verify that this is fixed by revision e7dccbb4544a?

Original comment by maglion...@gmail.com on 17 Oct 2009 at 11:50

• Changed state: Started

[GoogleCodeExporter]

This issue was updated by revision c12cd18e53.

This is a very strange issue. It turns out that subprocess
won't work from non-main threads while a module is being
imported. Since the wmiirc entered its event loop rather than
returning, it was causing problems. I suspect it was also the
cause of the stack traces being printed at interperater shutdown.

Original comment by maglion...@gmail.com on 18 Oct 2009 at 3:38

• Changed state: Fixed

[GoogleCodeExporter]

Confirmed that this is fixed, status monitor and clock, Mod + a/p are all 
working out 
of the box.
Thanks for your patience :)

Original comment by rusty.a...@googlemail.com on 18 Oct 2009 at 7:30

[GoogleCodeExporter]

Also fixed for me, thanks a lot. Hard decision between sh and Python wmiirc now.

Original comment by skwi...@googlemail.com on 18 Oct 2009 at 6:01