darcs patch: Replace custom forever_ with library equivalent

Replaced a custom forever implementation in Main.hsc by the equivalent
from the standard libraries. I guess it was legacy code, since forever
wasn't in Control.Monad in ghc 6.6 as far as I know.
Wed Jan 14 22:55:56 CET 2009 Daniel Schoepe

Only risk is on say, Debian, where they've an older GHC. Anyone know the status of GHC on those systems? asgaroth_:
Replaced a custom forever implementation in Main.hsc by the equivalent from the standard libraries. I guess it was legacy code, since forever wasn't in Control.Monad in ghc 6.6 as far as I know.
Wed Jan 14 22:55:56 CET 2009 Daniel Schoepe
* Replaced custom forever_ by library function New patches:
[Replaced custom forever_ by library function Daniel Schoepe
**20090114215556] { hunk ./XMonad/Main.hsc 146 userCode $ startupHook initxmc -- main loop, for all you HOF/recursion fans out there. - forever_ $ prehandle =<< io (nextEvent dpy e >> getEvent e) + forever $ prehandle =<< io (nextEvent dpy e >> getEvent e)
return () where hunk ./XMonad/Main.hsc 150 - forever_ a = a >> forever_ a - -- if the event gives us the position of the pointer, set mousePosition prehandle e = let mouse = do guard (ev_event_type e `elem` evs) return (fromIntegral (ev_x_root e) }
Context:
[Call logHook as the very last action in windows Spencer Janssen
**20081209233700 Ignore-this: 4396ad891b607780f8e4b3b6bbce87e ] [Accept inferior crossing events. This patch enables fmouse-focus-follows-screen Spencer Janssen **20081205045130 Ignore-this: 3ac329fb92839827aed0a4370784cabd ] [Tile all windows at once Spencer Janssen **20081118074447] [Factor rational rect scaling into a separate function Spencer Janssen **20081118072849] [Change screen focus by clicking on the root window. Spencer Janssen **20081106224031 This is a modification of a patch from Joachim Breitner. ] [Fix #192. Spencer Janssen **20081021220059] [select base < 4 for building on ghc 6.10 Adam Vogt **20081013214509] [add killWindow function Joachim Breitner **20081005001804 This is required to kill anything that is not focused, without having to focus it first. ] [add'l documentation Devin Mullins **20080927234639] [Regression: ungrab buttons on *non* root windows Spencer Janssen **20081007214351] [Partial fix for #40 Spencer Janssen **20081007212053 Improvements: - clicking on the root will change focus to that screen - moving the mouse from a window on a screen to an empty screen changes focus to that screen The only remaining issue is that moving the mouse between two empty screens does not change focus. In order to solve this, we'd have to select motion events on the root window, which is potentially expensive. ] [Track mouse position via events received Spencer Janssen **20081007203953] [Fix haddock Spencer Janssen **20081007094641] [Move screen locating code into pointScreen Spencer Janssen **20081007094207] [Make pointWithin a top-level binding Spencer Janssen **20081007090229] [sp README, CONFIG, STYLE, TODO gwern0@gmail.com**20080913024457] [Use the same X11 dependency as xmonad-contrib Spencer Janssen **20080921061508] [Export focusUp' and focusDown' -- work entirely on stacks Spencer Janssen **20080911214803] [add W.shiftMaster, fix float/tile-reordering bug Devin Mullins **20080911053909] [TAG 0.8 Spencer Janssen **20080905195412] [Spelling. Any bets on how long this has been there? Spencer Janssen **20080905195211] [Bump version to 0.8 Spencer Janssen **20080905194225] [Remove obsolete comments about darcs X11 Spencer Janssen **20080905194915] [Recommend latest packages rather than specific versions Spencer Janssen **20080905194837] [Also remove -optl from the executable section Spencer Janssen **20080820210023] [-optl-Wl,-s is not needed with recent Cabal versions Spencer Janssen **20080820204102] [Haddock links Malebria **20080601212515] [Haddock syntax for enumeration Malebria **20080601204951] [I prefer the spencerjanssen@gmail.com address now Spencer Janssen **20080714202650] [Raise windows in the floating layer when moving or resizing Trevor Elliott **20080521215057] [add currentTag convenience function Devin Mullins **20080511224258] [Make Mirror a newtype Spencer Janssen **20080508104640] [Comments Spencer Janssen **20080507013122] [Break long line Spencer Janssen **20080507012608] [Style Spencer Janssen **20080507012519] [Simplify Spencer Janssen **20080507011309] [Overhaul Choose, fixes issue 183 Spencer Janssen **20080506220809] [Remember if focus changes were caused by mouse actions or by key commands Klaus Weidner **20080502175603 If the user used the mouse to change window focus (moving into or clicking on a window), this should be handled differently than focus changes due to keyboard commands. Specifically, it's inappropriate to discard window enter/leave events while the mouse is moving. This fixes the bug where a fast mouse motion across multiple windows resulted in the wrong window keeping focus.
It's also helpful information for contrib modules such as UpdatePointer - it's supposed to move the mouse pointer only in response to keyboard actions, not if the user was moving the mouse. ] [Wibble Spencer Janssen
**20080506203840] [Added doShift function for more user-friendly hooks Ivan N. Veselov **20080506185757] [use named colours. fixes startup failure on the XO Don Stewart **20080502210149] [Set focus *after* revealing windows Spencer Janssen **20080407222559] [Reveal windows after moving/resizing them. Spencer Janssen **20080407220756 This should reduce the number of repaints for newly visible windows. ] [Hide newly created but non-visible windows (fixes bug #172) Spencer Janssen **20080430014012] [formatting, eta expansion Don Stewart **20080418184337] [XMonad.ManageHook: add 'appName', another name for 'resource' Lukas Mai **20080406012006] [XMonad.ManageHook: make 'title' locale-aware; haddock cleanup Lukas Mai **20080406011338 The code for 'title' was stolen from getname.patch (bug #44). ] [XMonad.Main: call setlocale on startup Lukas Mai
**20080406011234] [floats always use current screen (with less bugs) robreim@bobturf.org**20080405135009] [XMonad.Operations: applySizeHint reshuffle Lukas Mai **20080404215615 Make applySizeHints take window borders into account. Move old functionality to applySizeHintsContents. Add new mkAdjust function that generates a custom autohinter for a window. ] [XMonad.Layout: documentation cleanup Lukas Mai
**20080404215444] [Remove gaps from the example config Spencer Janssen **20080329232959] [Remove gaps Spencer Janssen **20080325091526] [TAG 0.7 Spencer Janssen **20080329210249] Patch bundle hash: ef4a14f0e22b06712aac9975c8df956a9b2846ba
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

Hi, Am Freitag, den 16.01.2009, 13:38 -0800 schrieb Don Stewart:
Only risk is on say, Debian, where they've an older GHC.
Anyone know the status of GHC on those systems?
ghc-6.8.2 is what you need to worry about, so this should be ok. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

On Saturday 17 January 2009 00:38:32 Don Stewart wrote:
Only risk is on say, Debian, where they've an older GHC.
Anyone know the status of GHC on those systems?
ghc-6.6 on Etch (stable) ghc-6.8.2 on Lenny (testing) and unstable Source: http://packages.debian.org/search?keywords=ghc6

Don Stewart wrote:
Only risk is on say, Debian, where they've an older GHC.
Anyone know the status of GHC on those systems?
As far as I know xmonad doesn't even build on ghc 6.6 anymore, so I don't think that these system would have to be considered, but I'm not completely sure. Can anyone confirm this?

Daniel Schoepe
Don Stewart wrote:
Only risk is on say, Debian, where they've an older GHC.
Anyone know the status of GHC on those systems?
As far as I know xmonad doesn't even build on ghc 6.6 anymore, so I don't think that these system would have to be considered, but I'm not completely sure. Can anyone confirm this?
xmonad do, xmonad-contrib don't. See OpenBSD ports, only xmonad is available because of ghc 6.6. -- Guillaume Pinot http://www.irccyn.ec-nantes.fr/~pinot/ ``Computers are good at following instructions, but not at reading your mind.'' -- Donald E. Knuth, the TeXbook () ASCII ribbon campaign -- Against HTML e-mail /\ http://www.asciiribbon.org -- Against proprietary attachments

texitoi:
Daniel Schoepe
writes: Don Stewart wrote:
Only risk is on say, Debian, where they've an older GHC.
Anyone know the status of GHC on those systems?
As far as I know xmonad doesn't even build on ghc 6.6 anymore, so I don't think that these system would have to be considered, but I'm not completely sure. Can anyone confirm this?
xmonad do, xmonad-contrib don't. See OpenBSD ports, only xmonad is available because of ghc 6.6.
Why does it fail with 6.6? We can probably rectify that. -- Don

Don Stewart
texitoi:
xmonad do, xmonad-contrib don't. See OpenBSD ports, only xmonad is available because of ghc 6.6.
Why does it fail with 6.6? We can probably rectify that.
I have tested with 0.7, not 0.8 or later, but I do not think it has changed. Some modules do not compile on xmonad-contrib. See http://article.gmane.org/gmane.os.openbsd.ports/29137 for a patch removing non-compiling modules. Right now, xmonad is still in 0.7 in the OpenBSD port tree. There is a patch on the mailing list, but not commited (I think because of the removed gap in 0.8 with no replaccement without contrib). ghc 6.6 is right now the ghc version on OpenBSD because of bootstrap problem of ghc. There is a port not yet commited for 6.10 (I think it is not yet comited because of ports not working with 6.10). If you need a 0.8 test on OpenBSD, I can reinstall ghc 6.6 and try to compil xmonad and xmonad-contrib 0.8. -- Guillaume Pinot http://www.irccyn.ec-nantes.fr/~pinot/ ``Computers are good at following instructions, but not at reading your mind.'' -- Donald E. Knuth, the TeXbook () ASCII ribbon campaign -- Against HTML e-mail /\ http://www.asciiribbon.org -- Against proprietary attachments

On Fri, Jan 16, 2009 at 3:38 PM, Daniel Schoepe
Replaced a custom forever implementation in Main.hsc by the equivalent from the standard libraries. I guess it was legacy code, since forever wasn't in Control.Monad in ghc 6.6 as far as I know.
Wed Jan 14 22:55:56 CET 2009 Daniel Schoepe
* Replaced custom forever_ by library function
hunk ./XMonad/Main.hsc 146 userCode $ startupHook initxmc -- main loop, for all you HOF/recursion fans out there. - forever_ $ prehandle =<< io (nextEvent dpy e >> getEvent e) + forever $ prehandle =<< io (nextEvent dpy e >> getEvent e) return () where hunk ./XMonad/Main.hsc 150 - forever_ a = a >> forever_ a - -- if the event gives us the position of the pointer, set mousePosition prehandle e = let mouse = do guard (ev_event_type e `elem` evs) return (fromIntegral (ev_x_root e) -------------------- This patch still applies to core. I think it ought to be applied. Besides the general goodness of not rolling our own and duplicating libraries, the chief objection was people might not be using GHC 6.8 or newer. But that was more than a year ago, and even Debian stable is using 6.8.2: - http://packages.debian.org/search?keywords=ghc6 - http://packages.debian.org/lenny/ghc6 And I strongly suspect that we already broke GHC 6.6 compatibility in several many ways. So there's no downside to applying this, and only upside. -- gwern

On Mon, Mar 22, 2010 at 4:28 PM, Gwern Branwen
On Fri, Jan 16, 2009 at 3:38 PM, Daniel Schoepe
wrote: Replaced a custom forever implementation in Main.hsc by the equivalent from the standard libraries. I guess it was legacy code, since forever wasn't in Control.Monad in ghc 6.6 as far as I know.
Wed Jan 14 22:55:56 CET 2009 Daniel Schoepe
* Replaced custom forever_ by library function hunk ./XMonad/Main.hsc 146 userCode $ startupHook initxmc
-- main loop, for all you HOF/recursion fans out there. - forever_ $ prehandle =<< io (nextEvent dpy e >> getEvent e) + forever $ prehandle =<< io (nextEvent dpy e >> getEvent e)
return () where hunk ./XMonad/Main.hsc 150 - forever_ a = a >> forever_ a - -- if the event gives us the position of the pointer, set mousePosition prehandle e = let mouse = do guard (ev_event_type e `elem` evs) return (fromIntegral (ev_x_root e)
--------------------
This patch still applies to core.
I think it ought to be applied. Besides the general goodness of not rolling our own and duplicating libraries, the chief objection was people might not be using GHC 6.8 or newer.
But that was more than a year ago, and even Debian stable is using 6.8.2: - http://packages.debian.org/search?keywords=ghc6 - http://packages.debian.org/lenny/ghc6
And I strongly suspect that we already broke GHC 6.6 compatibility in several many ways.
So there's no downside to applying this, and only upside.
Thoughts? -- gwern

On Thu, Mar 25, 2010 at 9:32 AM, Gwern Branwen
On Mon, Mar 22, 2010 at 4:28 PM, Gwern Branwen
wrote: On Fri, Jan 16, 2009 at 3:38 PM, Daniel Schoepe
wrote: Replaced a custom forever implementation in Main.hsc by the equivalent from the standard libraries. I guess it was legacy code, since forever wasn't in Control.Monad in ghc 6.6 as far as I know.
Wed Jan 14 22:55:56 CET 2009 Daniel Schoepe
* Replaced custom forever_ by library function hunk ./XMonad/Main.hsc 146 userCode $ startupHook initxmc
-- main loop, for all you HOF/recursion fans out there. - forever_ $ prehandle =<< io (nextEvent dpy e >> getEvent e) + forever $ prehandle =<< io (nextEvent dpy e >> getEvent e)
return () where hunk ./XMonad/Main.hsc 150 - forever_ a = a >> forever_ a - -- if the event gives us the position of the pointer, set mousePosition prehandle e = let mouse = do guard (ev_event_type e `elem` evs) return (fromIntegral (ev_x_root e)
--------------------
This patch still applies to core.
I think it ought to be applied. Besides the general goodness of not rolling our own and duplicating libraries, the chief objection was people might not be using GHC 6.8 or newer.
But that was more than a year ago, and even Debian stable is using 6.8.2: - http://packages.debian.org/search?keywords=ghc6 - http://packages.debian.org/lenny/ghc6
And I strongly suspect that we already broke GHC 6.6 compatibility in several many ways.
So there's no downside to applying this, and only upside.
Thoughts?
Ping. -- gwern

Quoting Gwern Branwen
On Thu, Mar 25, 2010 at 9:32 AM, Gwern Branwen
wrote: On Mon, Mar 22, 2010 at 4:28 PM, Gwern Branwen
wrote: On Fri, Jan 16, 2009 at 3:38 PM, Daniel Schoepe
wrote: Replaced a custom forever implementation in Main.hsc by the equivalent from the standard libraries. I guess it was legacy code, since forever wasn't in Control.Monad in ghc 6.6 as far as I know.
Wed Jan 14 22:55:56 CET 2009 Daniel Schoepe
* Replaced custom forever_ by library function Thoughts?
Yes, please! 2 cents, etc. ~d
participants (7)
-
Daniel Schoepe
-
Don Stewart
-
Gwern Branwen
-
Joachim Breitner
-
Khudyakov Alexey
-
TeXitoi
-
wagnerdm@seas.upenn.edu