#8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I'm aware of your effort actually, it's here:[https://github.com/Mistuke /ghc-win-io-system/] isn't? And i'm sure you are an windows expert ;) The old `IODevice` typeclass is not satisfactory and i indeed want to define new one. The encoding problems in base use functions from C runtime on windows instead of using windows API directly, which is the culprit IMO. Because most of the windows API have wide-char version which can directly use UTF-16, isn't? But libuv really solved most of those problems VERY WELL. for example it mapped window console API to accept ansi escaped code, so we get colorful ansi terminal for free, and it does the heavy work to shim the UTF-16 encoded `readConsoleInputW/writeConsoleOutputW` to accept UTF-8 buffers, which reduced much of the headache. The real remaining problem is how to make libuv with with ghc's scheduler, which i think i have a plan, i describe it in the github link above, please have a look. Finally, if we can manage leverage libuv to do I/O in haskell, we can save lots of repeated work, libuv is really an all-in-one solution for I/O problems: tcp, pipes, process, file watchers, etc. You name it! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler