On Tue, Feb 3, 2009 at 10:01 AM, Petr Rockai <[email protected]> wrote: > Hi, > > I guess Salvatore could cross-review, I'm just going to read through this and > if I encounter anything, note it inline. > > > Don't set stdin's buffering; Haskeline will do that for us. > ----------------------------------------------------------- > Removes without_buffering from a lot of places, as advertised. I'd like to > hear > a comment from Judah on how the buffering issue is handled by haskeline, > though. My pet peeve with that keeping a key pressed to get past many patches > screws up some internal state right now. It might be because the buffering is > disabled all the time, but the program is not ready to read. IIUIC, haskeline > will only disable buffering while it is ready to process input? Maybe that > will > actually fix that bug.
Yes, Haskeline temporarily disables buffering while reading user input (i.e., only during a call to getInputLine or getInputChar). So I don't expect this to be an issue, but let me know if you encounter any strange behavior. > Don't use the bytestring-mmap package on Windows. > ------------------------------------------------- > I would have expected cabal to deal with unavailability of bytestring-mmap on > windows gracefully by itself? Does it cause any actual trouble this way? > (Can't > check as I don't have a windows host available.) Unfortunately, when "cabal install" tries fetching dependencies from hackage it isn't smart enough to avoid building the unix package on Windows. (Just doing a "runghc Setup configure/build/install" probably works, though.) Incidentally, darcs.cabal already does this same trick for the terminfo package. -Judah _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
