Stefan O'Rear wrote:

On Mon, Jun 11, 2007 at 11:32:39AM +1000, Dave Harrison wrote:

...

Hey all,

I've been trying out the new tabbed layout and it was working really well for about 2 hours, then it suddenly just started killing my X for some reason.

What I was finding was that as soon as I switched screens my session would die (dropping me back to the gdm login page). It would also do this if I switched to a workspace > 5. Weird eh ?

I'm using the darcs head for contrib, xmonad and x11-extras, so I pulled the latest (again, just to be sure) for them and no updates. I'm also using Feisty Ubuntu as my OS if that makes any difference.

I rebuilt and reinstalled, no luck.

As soon as I dropped the tabbed module out and rebuilt/reinst xmonad it's all back to working again (albeit sans tabbing which I really REALLY miss now already :-) ).

Not being an X guru, and not very up on haskell, I'm not sure how to try and debug this ... can anyone suggest how I might try and track this problem down ?

You're not alone - #xmonad says:

18:16 < jcreigh> oh, joy: xmonad crashes. (bug in tabbed) 18:16 < jcreigh> I think it only affects Xinerama. 18:18 < sjanssen> huh? what business does tabbed have crashing? 18:18 < jcreigh> the bug seems to be: attempting to switch to an empty workspace while there is still a tabbed workspace visble makes xmonad die: "xmonad: No match in record selector StackSet.focus"

Yep, that matches my experience exactly.

On Mon, Jun 11, 2007 at 11:39:56AM +1000, Donald Bruce Stewart wrote:

Looks like is should be using 'peek' instead of the partial function, 'focus'. I presume David will take care of this soon.

Any chance we can avoid exporting partial functions from StackSet? It's not much use in terms of robustness to quickcheck that StackSet behaves properly and then export functions that will kill xmonad if used improperly. Also nice would be the ability to catch exceptions in the X monad (as discussed before). It seems that xlib crashes when I try to find the width of a string. I'd enjoy not having to log in again when this happens. In general, stability seems to be the weakest point of xmonad at the moment--contrary to the advertizing. -- David Roundy http://www.darcs.net

Hi

...

Any chance we can avoid exporting partial functions from StackSet? It's not much use in terms of robustness to quickcheck that StackSet behaves properly and then export functions that will kill xmonad if used improperly.

Yes, we ought to look through the functions in StackSet and evaluate whether the partial functions are worth keeping. I defer to Don on this one, because it's his code.

I've pointed out before that you export these partial functions. If you really don't want to export partial functions, Catch is the tool to use :)

...

In general, stability seems to be the weakest point of xmonad at the moment--contrary to the advertizing.

I disagree with this statement. In general, xmonad's core has been very stable. All the crashes I've seen lately are due to buggy contrib modules.

Perhaps you need to start "quality-controlling" the contrib module - ideally in an automated way. Are the contrib's pure, or do they involve the X layer? Could you quickcheck/catch them? Thanks Neil

Hi

Any chance catch can verify that an IO operation cannot fail? e.g. *I* know that (getCurrentDirectory `catch` \_ -> return "foo") cannot fail, but does Catch know that? Could it be taught?

Should be easy. The current Catch model of IO is: data IO a = IO a If you change the model to: data IO a = IOSuccess a | IOFail Then you can have main do a pattern-match on IOSuccess, and the "Prelude.catch" function will detect IOFail and take the alternative route. With Catch you currently need to provide an abstraction of each IO function, for example readFile is defined as: readFile file = IO any0 (where any0 is a special primitive to Catch that returns non-deterministically any value of the appropriate type) If you then mark the IO operations that can fail, with any0 (which is equivalent to IOSuccess any0 ||||| IOFail in this case), Catch will detect which functions are called which may raise an exception. Thanks Neil

droundy:

On Mon, Jun 11, 2007 at 10:32:11AM -0500, Spencer Janssen wrote:

...

...

Also nice would be the ability to catch exceptions in the X monad (as discussed before). It seems that xlib crashes when I try to find the width of a string. I'd enjoy not having to log in again when this happens.

The ability to catch exceptions would be nice, but it's hard to say how such a facility should work. Do we roll back state on an exception? We have to be careful here because there are certain state components (like mapped, waitingUnmap) that bring dire consequences when lost.

Obviously thought would need to go into it, and we'd only explicitely catch exceptions--particularly when calling user-defined code.

...

Furthermore, I think that catching errors in layouts is the wrong attitude: we want xmonad to crash in these early development stages to reveal bugs.

I disagree.

...

For xmonad hackers, I suggest using a wrapper script that restarts xmonad when it returns with a non-zero exit code.

Not a bad idea, but for the moment I suspect that all xmonad users are xmonad hackers. And since the only way to configure xmonad is to hack its

I note today I was at a workshop (yes, a programming languages one...) but there were 3 xmonad users in the room. Only one was an xmonad hacker :-) -- Don

droundy:

On Mon, Jun 11, 2007 at 10:32:11AM -0500, Spencer Janssen wrote:

...

...

Also nice would be the ability to catch exceptions in the X monad (as discussed before). It seems that xlib crashes when I try to find the width of a string. I'd enjoy not having to log in again when this happens.

The ability to catch exceptions would be nice, but it's hard to say how such a facility should work. Do we roll back state on an exception? We have to be careful here because there are certain state components (like mapped, waitingUnmap) that bring dire consequences when lost.

Obviously thought would need to go into it, and we'd only explicitely catch exceptions--particularly when calling user-defined code.

...

Furthermore, I think that catching errors in layouts is the wrong attitude: we want xmonad to crash in these early development stages to reveal bugs.

I disagree.

...

For xmonad hackers, I suggest using a wrapper script that restarts xmonad when it returns with a non-zero exit code.

Not a bad idea, but for the moment I suspect that all xmonad users are xmonad hackers. And since the only way to configure xmonad is to hack its code, and there doesn't seem to be any consensus for changing that, I think it's a good idea to make it easier to safely hack xmonad.

...

...

In general, stability seems to be the weakest point of xmonad at the moment--contrary to the advertizing.

I disagree with this statement. In general, xmonad's core has been very stable. All the crashes I've seen lately are due to buggy contrib modules.

The problem is that very little of xmonad's code is in its core. The pleasant aspect of xmonad (or rather, what I wished I had with ion3) is the nice interface for extending and customizing it. When that nice interface causes xmonad to crash when you make a mistake, it's not so nice. I end up keeping an ion3 open for editing xmonad, because xmonad is so unstable.

You mean, because you can hack internal structures however you want, so you can break things? The xmonad core is *not* xmonad + random extensions. And random extensions -- now they're in X -- can crash the system if you want. "xmonad is so unstable" isn't the right way to talk about arbitrary, deep customisation, and its inherant ability to break things. -- Don

droundy:

On Tue, Jun 12, 2007 at 06:29:38PM +1000, Donald Bruce Stewart wrote:

...

...

The problem is that very little of xmonad's code is in its core. The pleasant aspect of xmonad (or rather, what I wished I had with ion3) is the nice interface for extending and customizing it. When that nice interface causes xmonad to crash when you make a mistake, it's not so nice. I end up keeping an ion3 open for editing xmonad, because xmonad is so unstable.

You mean, because you can hack internal structures however you want, so you can break things? The xmonad core is *not* xmonad + random extensions. And random extensions -- now they're in X -- can crash the system if you want.

"xmonad is so unstable" isn't the right way to talk about arbitrary, deep customisation, and its inherant ability to break things.

But we're haskell developers, we should hold ourselves to higher standards. We've got powerful static typechecking, and you claim that xmonad has a clean well-tested design. In my opinion a good design for an extensible system involves making it *robustly* extensible, and that's where xmonad falls down. When it's safer to modify a program extensible in lua than one extensible in haskell, it means we're doing a pathetic job, and not making proper use of our language.

Solutions to the problem of safe, powerful extensibility welcome, David. I'd be happy to limit extensibility to pure functions, as we originally did. That's the best method I know of, for language-based safety. -- Don

droundy:

On Wed, Jun 13, 2007 at 12:04:20AM +1000, Donald Bruce Stewart wrote:

...

droundy:

...

On Tue, Jun 12, 2007 at 06:29:38PM +1000, Donald Bruce Stewart wrote:

...

...

The problem is that very little of xmonad's code is in its core. The pleasant aspect of xmonad (or rather, what I wished I had with ion3) is the nice interface for extending and customizing it. When that nice interface causes xmonad to crash when you make a mistake, it's not so nice. I end up keeping an ion3 open for editing xmonad, because xmonad is so unstable.

You mean, because you can hack internal structures however you want, so you can break things? The xmonad core is *not* xmonad + random extensions. And random extensions -- now they're in X -- can crash the system if you want.

"xmonad is so unstable" isn't the right way to talk about arbitrary, deep customisation, and its inherant ability to break things.

But we're haskell developers, we should hold ourselves to higher standards. We've got powerful static typechecking, and you claim that xmonad has a clean well-tested design. In my opinion a good design for an extensible system involves making it *robustly* extensible, and that's where xmonad falls down. When it's safer to modify a program extensible in lua than one extensible in haskell, it means we're doing a pathetic job, and not making proper use of our language.

Solutions to the problem of safe, powerful extensibility welcome, David. I'd be happy to limit extensibility to pure functions, as we originally did. That's the best method I know of, for language-based safety.

That idea is totally flawed.

Hmm. Why the strong language? It seems out of place on happy xmonad@.

Exceptions are thrown just as often from pure code as they are from IO code. If Haskell had some inherent way to verify

You don't call Xlib from pure code. So that's one big source of instability eliminated. That was why extensions were originally set as pure.

that functions are total, then your reasoning would be sound. As it is, our only hope for robustness is really to catch errors. That and to make it easier to avoid accidentally using partial functions.

Both of which we continue to work on. And so the effort to continue to keep the core xmonad, without extension, solid, while allowing people to implement ion in the config files, continues. -- Don

sjanssen:

On Mon, 11 Jun 2007 06:15:30 -0700 David Roundy wrote:

...

On Mon, Jun 11, 2007 at 11:39:56AM +1000, Donald Bruce Stewart wrote:

...

Looks like is should be using 'peek' instead of the partial function, 'focus'. I presume David will take care of this soon.

Any chance we can avoid exporting partial functions from StackSet? It's not much use in terms of robustness to quickcheck that StackSet behaves properly and then export functions that will kill xmonad if used improperly.

Yes, we ought to look through the functions in StackSet and evaluate whether the partial functions are worth keeping. I defer to Don on this one, because it's his code.

I belive their only exported so QuickCheck works. Any thoughts on how to separate the QC internals, from the export list?

...

Also nice would be the ability to catch exceptions in the X monad (as discussed before). It seems that xlib crashes when I try to find the width of a string. I'd enjoy not having to log in again when this happens.

The ability to catch exceptions would be nice, but it's hard to say how such a facility should work. Do we roll back state on an exception? We have to be careful here because there are certain state components (like mapped, waitingUnmap) that bring dire consequences when lost.

Furthermore, I think that catching errors in layouts is the wrong attitude: we want xmonad to crash in these early development stages to reveal bugs.

For xmonad hackers, I suggest using a wrapper script that restarts xmonad when it returns with a non-zero exit code.

...

In general, stability seems to be the weakest point of xmonad at the moment--contrary to the advertizing.

I disagree with this statement. In general, xmonad's core has been very stable. All the crashes I've seen lately are due to buggy contrib modules.

And if we restrict layouts to pure functions, as we used to, we get safety, at the cost of expressiveness. The contrib modules aren't xmonad, after all, they're random, unaudited patches. Hopefully they work, but they're not xmonad. -- Don

droundy:

On Mon, Jun 11, 2007 at 11:39:56AM +1000, Donald Bruce Stewart wrote:

...

Looks like is should be using 'peek' instead of the partial function, 'focus'. I presume David will take care of this soon.

Any chance we can avoid exporting partial functions from StackSet? It's not much use in terms of robustness to quickcheck that StackSet behaves properly and then export functions that will kill xmonad if used improperly.

Note we don't have a clear API yet -- yet we allow very deep customisation -- there's a tension there.

Also nice would be the ability to catch exceptions in the X monad (as discussed before). It seems that xlib crashes when I try to find the width of a string. I'd enjoy not having to log in again when this happens.

In general, stability seems to be the weakest point of xmonad at the moment--contrary to the advertizing.

The core is pretty tough, but contrib modules can do anything -- now that we allow them to be in X. David, wasn't that your idea? ;) -- Don