July 2007 - xmonad - Haskell.org

xmonad crashing
by Geoffrey Alan Washburn 12 Jul '07

12 Jul '07

After pulling in a few recent patches I've been having problems with xmonad crashing when I close windows from Thunderbird. I haven't extensively tested whether there are other applications that this happens with. xmonad dies with the following information. I'm compiling with ghc 6.6 on Linux. Let me know if there is some additional information that I can provide. Xlib: extension "XINERAMA" missing on display ":0.0". test: 24: /home/geoffw/.dmenu_cache: unexpected operator test: 24: /home/geoffw/.dmenu_cache: unexpected operator test: 24: /home/geoffw/.dmenu_cache: unexpected operator *** glibc detected *** /home/geoffw/bin/xmonad: free(): invalid pointer: 0x0818d7a4 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7d637cd] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7d66e30] /usr/lib/libX11.so.6(XFree+0x1d)[0xb7efbdbd] /home/geoffw/bin/xmonad[0x80b0be8] ======= Memory map: ======== 08048000-0818b000 r-xp 00000000 03:03 3604679 /home/geoffw/bin/xmonad 0818b000-0819c000 rwxp 00143000 03:03 3604679 /home/geoffw/bin/xmonad 0819c000-081e0000 rwxp 0819c000 00:00 0 [heap] b7900000-b7921000 rwxp b7900000 00:00 0 b7921000-b7a00000 ---p b7921000 00:00 0 b7b00000-b7c00000 rwxp b7b00000 00:00 0 b7c0d000-b7c18000 r-xp 00000000 03:03 2900764 /lib/libgcc_s.so.1 b7c18000-b7c19000 rwxp 0000a000 03:03 2900764 /lib/libgcc_s.so.1 b7c19000-b7cda000 r-xs 00000000 00:08 311820296 /SYSV00000000 (deleted) b7cda000-b7cdc000 rwxp b7cda000 00:00 0 b7cdc000-b7cef000 r-xp 00000000 03:03 2900078 /lib/tls/i686/cmov/libpthread-2.5.so b7cef000-b7cf1000 rwxp 00013000 03:03 2900078 /lib/tls/i686/cmov/libpthread-2.5.so b7cf1000-b7cf3000 rwxp b7cf1000 00:00 0 b7cf3000-b7cf7000 r-xp 00000000 03:03 2311161 /usr/lib/libXdmcp.so.6.0.0 b7cf7000-b7cf8000 rwxp 00003000 03:03 2311161 /usr/lib/libXdmcp.so.6.0.0 b7cf8000-b7cfa000 r-xp 00000000 03:03 2311140 /usr/lib/libXau.so.6.0.0 b7cfa000-b7cfb000 rwxp 00001000 03:03 2311140 /usr/lib/libXau.so.6.0.0 b7cfb000-b7cfc000 rwxp b7cfb000 00:00 0 b7cfc000-b7e37000 r-xp 00000000 03:03 2900016 /lib/tls/i686/cmov/libc-2.5.so b7e37000-b7e38000 r-xp 0013b000 03:03 2900016 /lib/tls/i686/cmov/libc-2.5.so b7e38000-b7e3a000 rwxp 0013c000 03:03 2900016 /lib/tls/i686/cmov/libc-2.5.so b7e3a000-b7e3d000 rwxp b7e3a000 00:00 0 b7e3d000-b7e44000 r-xp 00000000 03:03 2900080 /lib/tls/i686/cmov/librt-2.5.so b7e44000-b7e46000 rwxp 00006000 03:03 2900080 /lib/tls/i686/cmov/librt-2.5.so b7e46000-b7e8a000 r-xp 00000000 03:03 2310430 /usr/lib/libgmp.so.3.4.1 b7e8a000-b7e8b000 rwxp 00044000 03:03 2310430 /usr/lib/libgmp.so.3.4.1 b7e8b000-b7eb0000 r-xp 00000000 03:03 2900043 /lib/tls/i686/cmov/libm-2.5.so b7eb0000-b7eb2000 rwxp 00024000 03:03 2900043 /lib/tls/i686/cmov/libm-2.5.so b7eb2000-b7ebf000 r-xp 00000000 03:03 2314013 /usr/lib/libXext.so.6.4.0 b7ebf000-b7ec0000 rwxp 0000d000 03:03 2314013 /usr/lib/libXext.so.6.4.0 b7ec0000-b7fad000 r-xp 00000000 03:03 2311650 /usr/lib/libX11.so.6.2.0 b7fad000-b7fb1000 rwxp 000ed000 03:03 2311650 /usr/lib/libX11.so.6.2.0 b7fb1000-b7fb2000 rwxp b7fb1000 00:00 0 b7fb2000-b7fb4000 r-xp 00000000 03:03 2311665 /usr/lib/libXinerama.so.1.0.0 b7fb4000-b7fb5000 rwxp 00001000 03:03 2311665 /usr/lib/libXinerama.so.1.0.0 b7fb5000-b7fb7000 r-xp 00000000 03:03 2900041 /lib/tls/i686/cmov/libdl-2.5.so b7fb7000-b7fb9000 rwxp 00001000 03:03 2900041 /lib/tls/i686/cmov/libdl-2.5.so b7fd0000-b7fd2000 rwxp b7fd0000 00:00 0 b7fd2000-b7feb000 r-xp 00000000 03:03 2900027 /lib/ld-2.5.so b7feb000-b7fed000 rwxp 00019000 03:03 2900027 /lib/ld-2.5.so bfc41000-bfc58000 rwxp bfc41000 00:00 0 [stack] ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso] The application 'Gecko' lost its connection to the display :0.0; most likely the X server was shut down or you killed/destroyed the application. The application 'Gecko' lost its connection to the display :0.0; most likely the X server was shut down or you killed/destroyed the application. The application 'Gecko' lost its connection to the display :0.0; most likely the X server was shut down or you killed/destroyed the application. Xlib: extension "XINERAMA" missing on display ":0.0". test: 24: /home/geoffw/.dmenu_cache: unexpected operator

8 19

darcs patch: NamedWindows: removed getClassHint that is the cause o...
by Andrea Rossato 12 Jul '07

12 Jul '07

Hi, this patch soft of fixes the crash issue. It removes the work aroung I proposed for non latin window's names: using the reasourse name provided by getClassHint. This one is causing the problem. So, we need to fix this first. To XMonad core team: I don't know if this patch must be applied: probably it can be used by Tabbed users till when getClassHint is fixed. I don't know... you see! Ciao Andrea who's going to have some breackfast now Thu Jul 12 07:47:52 CEST 2007 Andrea Rossato <andrea.rossato(a)unibz.it> * NamedWindows: removed getClassHint that is the cause of some crashing My work around for non latin string in WindowNames requires getClassHint that is, so far, buggy. For the time being we will not have non latin names in tabs. But at least the Tabbed layout is not going to crash XMonad.

4 5

darcs patch: added support for XChangeWindowAttributes
by Andrea Rossato 11 Jul '07

11 Jul '07

Hi, Since I cannot stand C anymore this is the needed support to rewrite the last Robert's stuff. The rest is comming as soon as possible. Maybe my firt XMonad module... ;-) ciao andrea Wed Jul 11 09:58:44 CEST 2007 Andrea Rossato <andrea.rossato(a)unibz.it> * added support for XChangeWindowAttributes

2 1

darcs patch: restore focus to currently focused window after "float...
by Jason Creighton 11 Jul '07

11 Jul '07

Mon Jul 9 22:26:31 MDT 2007 Jason Creighton <jcreigh(a)gmail.com> * restore focus to currently focused window after "float" (closes #32)

2 1

turn any window into a statusbar or manage/unmage windows 'remotely'
by Robert Manea 11 Jul '07

11 Jul '07

Hi, as the question: 'How can I make xmonad ignore application "foo" and have it appear on every workspace?' is kind of a FAQ in xmonad's IRC channel, i wrote a tiny application just for this purpose. Source is attached below, usage is trivial: - retreive the window ID of the application you want to unmanage/manage with 'xwininfo' - invoke the program below, like: * unmanage <windowid> * manage <windowid> Compilation und usage instructions are in the code.. Have fun, Rob.

2 1

[ot] [xmobar-related] existentials for plugin-ing (?)
by Andrea Rossato 10 Jul '07

10 Jul '07

Hi, I had this crazy idea a couple of nights ago. I didn't dare to ask in the haskell-cafe because I fear it could be too stupid. The xmonad community is smaller (even though the greatest haskeller I know about read and write xmonad code: so posting here could be even worse...;-) so I'm posting here. It is vaguely related to XMonad after all. XMobar, the status bar I'm writing for XMonad, now runs monitors internally. You set monitors and external commands in the configuration file. I'm thinking of writing also command line options, but the possibility of using a readable data type for reading a configuration file can make users' life easier, I think, even though there are no debugging messages and that can be confusing (but you can test the configuration with ghc!). Now, in the configuration there is this commands option, a list of tuples: the data type for commands and an Int, the interval for each successive runs. The data type for the commands was suggested by Spencer. Very simply: data Command = Exec ProgramName Args | Network Interface Args etc., where Network is a constructor to be used for running the network interface monitor. Then there is a class (Exec - not much fantasy, I know) for which a method (run :: e -> IO String) must be defined. So there are all the needed instances for running, showing, etc, etc. Now, I though that writing a plugin should just mean creating a type and making it an instance of Exec. XMobar takes the list of the commands to be run from the configuration "commands" option, so that's easy: just a polymorphic list of commands to be run and I don't need anything else for supporting plugins...;-) Cool I though, it's just a matter of creating the needed polymorphic list. With one more constrain: Config, that has that list inside, must be readable! Ok, this is not an easy task, since existentially qualified types are not derivable, and reading them seemed not even possible.[1] Writing a too complicated parser for a Read instance is not an option. Now, thanks to the help of Claus Reinke I came up with a solution for that too.[2] The code[3] works! You can feed readConfig with a file like this: MD {rec1 = "Ciao", rec2 = "Ciao Ciao", rec3 = [MT (T3a,1),MT (T2b,3),MT (T1b,3),MT (T1a,3)]} and it reads it! Now I would like to ask you if such an approach could be tried or is just insane. I mean, would you run a status bar that, to configure with you favorite plugin (type HelloWorld = HelloWorld [] []), requires you to write in Config.hs something like: hidden = undefined :: (Commands,(HelloWorld,())) I don't know if I would. Let me know your thoughts please, in exchange I'll chase and try to fix as many XMobar bugs as I possibly can ...;-) All the best Andrea [1] According to this thread: http://www.haskell.org/pipermail/haskell-cafe/2004-April/006092.html [2] Look here: http://www.haskell.org/pipermail/haskell-cafe/2007-July/028205.html http://www.haskell.org/pipermail/haskell-cafe/2007-July/028227.html [3] the code {-# OPTIONS -fglasgow-exts #-} module Test where import Control.Monad import Text.Read import Text.ParserCombinators.ReadPrec data MyData = MD { rec1 :: String , rec2 :: String , rec3 :: [MyType] } deriving (Read,Show) data MyType = forall e . (MyClass e,Show e, Read e) => MT (e,Int) instance Show MyType where show (MT a) = "MT " ++ show a class MyClass c where myShow :: c -> String data TipoA = T1a | T2a | T3a deriving(Show,Read,Eq) instance MyClass TipoA where myShow T1a = "t1a" myShow T2a = "t2a" myShow T3a = "t3a" data TipoB = T1b | T2b | T3b deriving(Show,Read,Eq) instance MyClass TipoB where myShow T1b = "t1b" myShow T2b = "t2b" myShow T3b = "t3b" -- tricky part starts here -- the solution comes from Claus Reinke class ReadAsAnyOf ts ex where -- read an existential as any of hidden types ts readAsAnyOf :: ts -> ReadPrec ex instance ReadAsAnyOf () ex where readAsAnyOf ~() = mzero instance (Read t, Show t, MyClass t, ReadAsAnyOf ts MyType) => ReadAsAnyOf (t,ts) MyType where readAsAnyOf ~(t,ts) = r t `mplus` readAsAnyOf ts where r t = do { m <- readPrec; return (MT (m `asTypeOf` (t,0))) } instance Read MyType where readPrec = readMT readMT :: ReadPrec MyType readMT = prec 10 $ do Ident "MT" <- lexP parens $ readAsAnyOf hidden -- r T1a `mplus` r T1b hidden = undefined :: (TipoA,(TipoB,())) readConfig :: FilePath -> IO MyData readConfig f = do s <- readFile f case reads s of [(config,_)] -> return config [] -> error ("Corrupt config file: " ++ f) _ -> error ("Some problem occured. Aborting...")

1 0

Issue 34 in xmonad: focusedBorderColor does not follow focus that is requested by application
by codesite-noreply＠google.com 10 Jul '07

10 Jul '07

Issue 34: focusedBorderColor does not follow focus that is requested by application http://code.google.com/p/xmonad/issues/detail?id=34 New issue report by JinXiaoyong: What steps will reproduce the problem? 1. (server-start) in GNU Emacs and leave the mouse pointer in Emacs 2. use emacsclient in an xterm 3. Emacs will acquire the focus, but the border color is still normal What is the expected output? What do you see instead? Of course the border color should have changed to focusedBorderColor, but it didn't, though emacs did obtain the focus. What version of the product are you using? On what operating system? xmonad from darcs repository. Emacs unicode-branch-2 from cvs. Gentoo Linux. Xorg 7.2.0 Please provide any additional information below. Other applications that acquire focus by themselves could possibly have the same issue. In my case, for the Emacs, it's important that the mouse pointer was in the Emacs window while you run the emacsclient in the xterm. Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 32 in xmonad: gnome-panel take focus when autohide
by codesite-noreply＠google.com 10 Jul '07

10 Jul '07

Issue 32: gnome-panel take focus when autohide http://code.google.com/p/xmonad/issues/detail?id=32 Comment #2 by jcreigh: Hmm. The reason the reason we focusWindow first is so that we can shift it to the right workspace. (Currently, "shift" can only move the focused window.) Not quite sure how we should fix this yet. Issue attribute updates: Status: Accepted -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

mod-{w,e,r} don't work when OpenOffice.org has focus
by Kai Grossjohann 10 Jul '07

10 Jul '07

I have two heads, the left one shows workspace 1 which is in full layout and contains OpenOffice, Firefox and Adobe Reader. The right head shows different workspaces as time goes by, usually in tiled layout. Now it turns out that OpenOffice somehow grabs focus so that mod-e does not work to switch to the second head. I can still do mod-j to switch to a different client on the left head, and then mod-e works. But when OpenOffice has focus and after I click into it, then mod-e will not work to set the focus to the right hand head. Has anyone else observed the same? Is there a fix? What can I do to help debug it? (I don't grok Haskell, though I'm trying.) Kai

2 3

darcs patch: LayoutScreens.hs: correct module header. (and 1 more)
by joachim.fasting＠gmail.com 09 Jul '07

09 Jul '07

Sun Jul 1 23:57:12 CEST 2007 joachim.fasting(a)gmail.com * LayoutScreens.hs: correct module header. Sat Jul 7 23:28:36 CEST 2007 joachim.fasting(a)gmail.com * Spiral.hs: correct module header.

2 1