Ticket #25 (closed enhancement: fixed)

Opened 9 years ago

Last modified 9 years ago

Incorporate some 6.10 improvements

Reported by: judah Owned by:
Priority: minor Milestone: 0.4
Version: 0.2 Keywords:


This is just a reminder that several changes should be made for GHC 6.10 (either to make code cleaner or to ensure compatibility)

The tasks to watch:

  • 2301: Proper handling of SIGINT (throw Ctrl-C exception)
  • 2451: New signal-handling API
  • 1198: hWaitForInput on Windows
  • Unicode support for text I/O (Release plan)
  • 2363: getChar, hWaitForInput, et al cannot be interrupted with -threaded

Change History

Changed 9 years ago by judah

  • milestone set to 0.3

If possible, I'd like to remain buildable from 6.6 or later. At least, we should not lose features from version 0.2.1 (so for example if non-UTF8 Unicode I/O only occurs 6.10, that should be fine).

I need to watch the 6.10 library changes and decide whether depending only on base<4 is the right choice.

Changed 9 years ago by judah

  • priority changed from major to minor
  • milestone changed from 0.3 to 0.4

I've confirmed that the relevant bits work fine when built against ghc-6.10, now that we require base<4.

I'm keeping this ticket open for now, since it would be nice to actually start using the 6.10 improvements at some point.

Changed 9 years ago by judah

  • summary changed from Be compatible with 6.10 improvements to Incorporate some 6.10 improvements

Changed 9 years ago by judah

  • status changed from new to closed
  • resolution set to fixed

These questions all appear to be resolved:

  • the extensible-exceptions package lets us be compatible with all versions of ghc since at least 6.6.1 (if not older)
  • ctrl-c handling has been decoupled from the rest of Haskeline's UI
  • unicode support has its own tickets now (#22, #43) which are waiting on ghc features
  • The existing character-reading code will still be necessary for older versions of ghc, and has also turned out to provide some advantages over more naive methods:
    • Windows key reading requires the low-level ReadConsoleInput function anyway
    • using hGetNonBlocking makes control sequence reading simpler and more robust.
Note: See TracTickets for help on using tickets.