possible bug in tabbed window extension
I've just upgraded to the latest xmonad in darcs, and it's great! However, one thing that used to work doesn't work anymore. I bind mod-button3 to the kill command, and when I put the cursor on a tab and hit mod-button3 the entire X server crashes! When I do it outside of a tab it works fine. FWIW the relevant part of my Config.hs is: -- | -- default actions bound to mouse events -- mouseBindings :: M.Map (KeyMask, Button) (Window -> X ()) mouseBindings = M.fromList $ -- mod-button1 %! Set the window to floating mode and move by dragging [ ((modMask, button1), (\w -> focus w >> mouseMoveWindow w)) -- mod-button2 %! Set the window to floating mode and resize by dragging , ((modMask, button2), (\w -> focus w >> mouseResizeWindow w)) -- mod-button3 %! Kill a window , ((modMask, button3), (\_ -> kill)) -- Extension-provided mouse bindings ] Anybody have any idea what's going wrong? TIA, Mike
On Fri, Oct 05, 2007 at 02:48:29AM -0700, Michael Vanier wrote:
I've just upgraded to the latest xmonad in darcs, and it's great! However, one thing that used to work doesn't work anymore. I bind mod-button3 to the kill command, and when I put the cursor on a tab and hit mod-button3 the entire X server crashes! When I do it outside of a tab it works fine. FWIW the relevant part of my Config.hs is:
[...]
Anybody have any idea what's going wrong?
yes, a stupid assumption I made when using fromJust a bit too liberally. a patch is comming. andrea
On 2007-10-05 12:52:05 Andrea Rossato wrote:
On Fri, Oct 05, 2007 at 02:48:29AM -0700, Michael Vanier wrote:
I've just upgraded to the latest xmonad in darcs, and it's great! However, one thing that used to work doesn't work anymore. I bind mod-button3 to the kill command, and when I put the cursor on a tab and hit mod-button3 the entire X server crashes! When I do it outside of a tab it works fine. FWIW the relevant part of my Config.hs is:
[...]
Anybody have any idea what's going wrong?
yes, a stupid assumption I made when using fromJust a bit too liberally.
I wonder: would it be feasible to sandbox layouts (and other 'user' code) somewhat, so that a bug like this would perhaps just cause Xmonad to switch to Full rather than blowing away the session? It would make experimenting a bit less troublesome. /J
On Sat, Oct 06, 2007 at 07:53:07AM +0100, Jamie Webb wrote:
I wonder: would it be feasible to sandbox layouts (and other 'user' code) somewhat, so that a bug like this would perhaps just cause Xmonad to switch to Full rather than blowing away the session? It would make experimenting a bit less troublesome.
That would be really nice, even though I don't know if there are nice ways to do it. Moreover I think there's a consensus that QC should be the way to go (especially with the new pureLayout and pureMessage). Take also into account that so far we didn't feel it necessary. My code is the only one that has been proved to be prone to such stupid, and still crash producing, bugs. As in this example, where I have an OR in a conditional and then, in the body of the function, I just take into account only the first possibility, the problem is that I didn't yet develop that sensibility to not to even write such stupid errors. Something the other contributors already have. Luckily I'm quite fast in providing a fixes so, after a few weeks of debugging, even my code stabilizes. For testing purposes I extensively use Xnest, and a simple hack in my .xprofile so that, when an instance of xmonad crashes, another one takes over: while [ 1 ]; do /usr/local/bin/xmonad /usr/local/bin/xmonad.bak done Andrea
j:
On 2007-10-05 12:52:05 Andrea Rossato wrote:
On Fri, Oct 05, 2007 at 02:48:29AM -0700, Michael Vanier wrote:
I've just upgraded to the latest xmonad in darcs, and it's great! However, one thing that used to work doesn't work anymore. I bind mod-button3 to the kill command, and when I put the cursor on a tab and hit mod-button3 the entire X server crashes! When I do it outside of a tab it works fine. FWIW the relevant part of my Config.hs is:
[...]
Anybody have any idea what's going wrong?
yes, a stupid assumption I made when using fromJust a bit too liberally.
I wonder: would it be feasible to sandbox layouts (and other 'user' code) somewhat, so that a bug like this would perhaps just cause Xmonad to switch to Full rather than blowing away the session? It would make experimenting a bit less troublesome.
Good point, can you please add a ticket for this. With pure layouts, this should really be prevented. And don't use fromJust, Andrea. Partial functions are evil, when people's data is at stake. -- Don
On Sat, Oct 06, 2007 at 03:34:43AM -0700, Don Stewart wrote:
j:
On 2007-10-05 12:52:05 Andrea Rossato wrote:
yes, a stupid assumption I made when using fromJust a bit too liberally.
I wonder: would it be feasible to sandbox layouts (and other 'user' code) somewhat, so that a bug like this would perhaps just cause Xmonad to switch to Full rather than blowing away the session? It would make experimenting a bit less troublesome.
Good point, can you please add a ticket for this. With pure layouts, this should really be prevented. And don't use fromJust, Andrea. Partial functions are evil, when people's data is at stake.
you learn step by step, error by error... when you are lucky enough to get to know the errors you did... this is why free software is such a great learning experience... done on others' data... andrea
On Sat, Oct 06, 2007 at 07:53:07AM +0100, Jamie Webb wrote:
On 2007-10-05 12:52:05 Andrea Rossato wrote:
On Fri, Oct 05, 2007 at 02:48:29AM -0700, Michael Vanier wrote:
I've just upgraded to the latest xmonad in darcs, and it's great! However, one thing that used to work doesn't work anymore. I bind mod-button3 to the kill command, and when I put the cursor on a tab and hit mod-button3 the entire X server crashes! When I do it outside of a tab it works fine. FWIW the relevant part of my Config.hs is:
[...]
Anybody have any idea what's going wrong?
yes, a stupid assumption I made when using fromJust a bit too liberally.
I wonder: would it be feasible to sandbox layouts (and other 'user' code) somewhat, so that a bug like this would perhaps just cause Xmonad to switch to Full rather than blowing away the session? It would make experimenting a bit less troublesome.
I haven't been following this bug, but we certainly used to have precisely this sandbox in place, and it definitely worked. It involves catchX, and I think the code is still there, but someone may have removed it from one of the invocations. My feeling is that any X code (or ideally any pure code) that is not part of core should be called with catchX whenever possible. Haskell has all the infrastructure needed to very easily do this kind of sandboxing (exceptions). -- David Roundy Department of Physics Oregon State University
David Roundy wrote:
I haven't been following this bug, but we certainly used to have precisely this sandbox in place, and it definitely worked. It involves catchX, and I think the code is still there, but someone may have removed it from one of the invocations. My feeling is that any X code (or ideally any pure code) that is not part of core should be called with catchX whenever possible. Haskell has all the infrastructure needed to very easily do this kind of sandboxing (exceptions).
Can QuickCheck be used to insert bottoms sometimes in Contrib/Config code and see if an exception ever escapes, so it's easier to tell whether catchX is in all the right places? Isaac
On Mon, Oct 08, 2007 at 12:00:37PM -0300, Isaac Dupree wrote:
David Roundy wrote:
I haven't been following this bug, but we certainly used to have precisely this sandbox in place, and it definitely worked. It involves catchX, and I think the code is still there, but someone may have removed it from one of the invocations. My feeling is that any X code (or ideally any pure code) that is not part of core should be called with catchX whenever possible. Haskell has all the infrastructure needed to very easily do this kind of sandboxing (exceptions).
Can QuickCheck be used to insert bottoms sometimes in Contrib/Config code and see if an exception ever escapes, so it's easier to tell whether catchX is in all the right places?
Quickcheck can't be used with anything in the X monad, so no. At least not the quickcheck I'm familiar with... -- David Roundy Department of Physics Oregon State University
On Wed, Oct 10, 2007 at 11:41:08AM -0400, David Roundy wrote:
On Mon, Oct 08, 2007 at 12:00:37PM -0300, Isaac Dupree wrote:
Can QuickCheck be used to insert bottoms sometimes in Contrib/Config code and see if an exception ever escapes, so it's easier to tell whether catchX is in all the right places?
Quickcheck can't be used with anything in the X monad, so no. At least not the quickcheck I'm familiar with...
Google QuickCheckM. I haven't spent enough time investigating it to see if it would apply.
me:
On Wed, Oct 10, 2007 at 11:41:08AM -0400, David Roundy wrote:
On Mon, Oct 08, 2007 at 12:00:37PM -0300, Isaac Dupree wrote:
Can QuickCheck be used to insert bottoms sometimes in Contrib/Config code and see if an exception ever escapes, so it's easier to tell whether catchX is in all the right places?
Quickcheck can't be used with anything in the X monad, so no. At least not the quickcheck I'm familiar with...
Google QuickCheckM. I haven't spent enough time investigating it to see if it would apply.
It might be doable, but I'm not familiar with it either. Good old exceptoins can be caught in a QC property with unsafePerformIO well enough though. See tests/Properties.hs for error failing tests. -- Don
participants (7)
-
Andrea Rossato -
David Roundy -
Devin Mullins -
Don Stewart -
Isaac Dupree -
Jamie Webb -
Michael Vanier