non-positive argument error on NVidia Xinerama set

[GoogleCodeExporter]

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

Are you using an xmonad.hs?  Please attach it and the output of "xmonad
--recompile".

Please provide any additional information below.

Original issue reported on code.google.com by seanerussell on 22 Jan 2010 at 7:01

[GoogleCodeExporter]

Nice.  Accidental carriage return caused this to be submitted.

Anyhoo, I have an NVidia dual monitor graphics card set up to serve up two 
screens
via Xinerama.  Initially, xmonad worked on this setup, but didn't recognize the
second monitor; eventually, I found out that the Haskell X11 library hadn't been
compiled with Xinerama, so I fixed that.  Now, xmonad exits as soon as it is 
started
with an error that:

  xmonad-i386-linux: xmonad: StackSet: non-positive argument to StackSet.new

I stripped my xmonad.hs down to the bare minimum (so that it didn't reference
StackSet at all), and the error was still reported.

In fact, I'm not sure that this has anything to do with Xinerama, now, because 
I've
just tried to run xmonad on an Xnest session, and got the same error.

I'm sure that this is a local problem, but I'm not sure how to proceed in 
debugging
this.  Any suggestions?

xmonad: 0.9.1
GHC: 6.10.4
xorg: 7.3
ubuntu: Ubuntu 8.04.3 LTS

All Haskell dependencies have been built out of cabal, refreshed as of 
2010-01-22.

'xmonad --recompile' produces no STDERR/STDOUT output, and exits with exit code 
0.

Original comment by seanerussell on 22 Jan 2010 at 7:17

Attachments:

• xmonad.hs

[GoogleCodeExporter]

Eh.  Close it.  On a whim I recompiled the main xmonad package, and the problem 
has
gone away.  Sorry for the line noise.

Original comment by seanerussell on 22 Jan 2010 at 7:24

[GoogleCodeExporter]

Remember that whenever you rebuild a package xmonad depends on (such as X11), 
you
must 'Setup clean' before rebuilding and reinstalling xmonad and xmonad-contrib.

GHC doesn't notice when dependencies change, so it will sometimes build nonsense
executables if there's an inconsistent build environment.

Original comment by SpencerJ...@gmail.com on 23 Jan 2010 at 6:04

[GoogleCodeExporter]

Yes, I didn't expect GHC to notice the dependency, but I expected cabal to have 
noticed.

Off topic: I'd have hoped that a dependency manager like cabal would at 
least... you 
know... manage dependencies.  It doesn't seem to; there's no "recompile 
everything 
that depends on this package" option, or even "show me what depends on this 
package".

Anyway, rants aside, this issue can be closed.  Thanks again.

Original comment by seanerussell on 23 Jan 2010 at 11:53

[GoogleCodeExporter]

As I understand it, cabal doesn't currently deal with updates and dependency 
checking because it's too easy to 
get into "diamond dependency" issues.  (Package A updated, package B's deps 
specify old version, package C's 
deps either specify new version or default version, package D tries to use 
packages B and C => bad things 
happen; the only way to prevent this "automatically" would be to refuse to 
allow package A to be updated at all, 
and if package D is installed later it must refuse to allow the install until 
someone fixes the dependency conflict 
manually.)

Original comment by allber...@gmail.com on 23 Jan 2010 at 12:01

[GoogleCodeExporter]

Aaaaand... just for completeness: the lack of proper dependency checking -- and 
the 
inability for cabal to detect when dependencies change and recompile dependent 
packages -- is a known and triaged bug:

   http://hackage.haskell.org/trac/hackage/ticket/15

It was just unknown to me :-)

Original comment by seanerussell on 23 Jan 2010 at 12:02

[GoogleCodeExporter]

Original comment by SpencerJ...@gmail.com on 24 Jan 2010 at 12:54

• Changed state: Invalid

[GoogleCodeExporter]

I want to add a comment that this error message can also be caused by a wrong 
xmonad config (I spent some time looking for this). Briefly, if you have 
strictly more xinerama screens than initial workspaces in your xmonad config (I 
use DynamicWorkspaces), then you will see this crash, and it will go away if 
you add more initial workspaces in your xmonad config or if you change the 
screens config using xrandr so that there appear to be fewer screens on startup.

Original comment by dominique.devriese@gmail.com on 13 Dec 2011 at 9:04

[GoogleCodeExporter]

So, seems xmonad needs to do some checks on startup: if (number of workspaces) 
< (number of xinerama screens) then add some additional workspaces. The patch 
is quite trivial.

Original comment by ilya.por...@gmail.com on 13 Dec 2011 at 10:08

[GoogleCodeExporter]

It would be better to fix the `new` function, such that it will actually allow 
for more xinerama screens than there are workspaces, if this doesn't break any 
invariants.

Original comment by jesper.reenberg on 13 Dec 2011 at 8:41