Re: [GHC] #3081: Double output after Ctrl+C on Windows
system cp foo foo.bup deleteFile foo If I Ctrl+C during the cp did I just delete my one copy of foo? On Windows, Ctrl-C will unblock a blocked system call. e.g. read() returns with zero. Apparently system foo also returns as soon as you press Ctrl-C, I'm not entirely sure why. Perhaps because the program has been killed? So, to check my understanding: * Haskell program invokes system * Use presses Ctrl+C * System returns and Haskell program continues executing * Ctrl+C is thrown and Haskell program aborts That sounds really dangerous - like a race condition between the system returning and the Haskell program aborting. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Show instance of Ratio
Hi The GHC Show instance of Ratio is different from that in Yhc/Hugs/The Report. There has been a discussion in the bug tracker, which you can follow at http://hackage.haskell.org/trac/ghc/ticket/1920 . I thought I'd summarise everyone's positions, and the possible actions we can take. Problem - showing a Ratio using GHC places no spaces around the %, in Hugs/Yhc/The Report it has spaces. Read the bug tracker for an example. Solution EITHER: Make all compilers put out spaces OR: Make no compilers put out spaces The alternative is to have different compilers do different things, which I think we can agree is bad (TM). As a more general point, should all infix constructors have spaces around them or not. Whatever we decide, it would be weird for it to apply to only the Ratio instance and not others. I think we should solve this problem now. It makes sense to come to some consensus which Haskell' will follow, then fix whichever set of compilers is determined to be wrong. Opinions -- The basic differing of opinions is should Show print the minimal ASCII representation (Neil Mitchell, Simon Marlow) or something that is slightly pretty where possible (Ross Patterson, Ian Lynagh). Comments welcome. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1518: Make it possible to evaluate monadic actions when assigning record fields (-)
Hi Adde, #1518: Make it possible to evaluate monadic actions when assigning record fields It is currently not possible to build records from values resulting from monadic actions while still using the field-specifiers. This is quite a significant change to the language, which isn't precise enough. Perhaps if you discussed it on the haskell-cafe@ or haskell-prime@ mailing lists first you might be able to firm up what you are asking for, including the desugaring rules etc. You might also find that people have developed something to get round this. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1278: filepath’s makeRel ative does not work for relative directories
Hi I'd expect something like this: org / makeRelative org x == x or at least something like normalise (org / makeRelative org x) == normalise x at least on a best effort basis. Alas thats not true, because makeRelative can insert .. paths which can't be removed by normalise as they might be symlinks elsewhere. I wonder if makeRelative should insert .. paths - any thoughts? Now makeRelative can no longer insert .. paths, they have a habit of going wrong with symlinks etc so best to play it safe. The new code has been checked in. Joachim - please test and check that this meets you needs. The example you gave is now one of the properties in the interface. http://www.cs.york.ac.uk/fp/haddock/filepath/System-FilePath-Posix.html#v%3AmakeRelative The two basic QuickCheck properties are: takeDrive x == x || makeRelative x (x `combine` y) == y isRelative x || y `combine` makeRelative y x == x Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1278: filepath's makeRelative does not work for relative directories
Hi Isaac, The two basic QuickCheck properties are: takeDrive x == x || makeRelative x (x `combine` y) == y isRelative x || y `combine` makeRelative y x == x What is takeDrive? The haddock mentions those properties, but I can't find any other reference to or definition of takeDrive on the page produced by haddock, so it doesn't seem like very useful documentation at the moment :) One of the massive complications of a FilePath library is that Windows has many syntaxes for drives - \?\\share\, \\share\, c:\, \ - etc - in varying combinations of / and \ slashes with varying combinations of meaning. Unix on the other hand has only one drive specifier, which is /. As a result there are a load of functions such as takeDrive, dropDrive etc which are internal to the library, and which get tested (there is a #ifdef TESTING) with appropriate properties. In a couple of places, the quickcheck properties need to depend on these drive functions, which aren't exported - sad, but filepaths (esp on Windows) weren't designed with a sound formal logical semantics behind them. As it happens, in this particular case, if you give a drive which is the first argument, and has some other curious properties, then the condition won't hold - but only on Windows. I've modified the properties so they now say: -- Windows: makeRelative x (x `combine` y) == y || takeDrive x == x -- Posix: makeRelative x (x `combine` y) == y Hopefully this will make it more clear that at least on Posix you don't need to care. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1278: filepath’s makeRel ative does not work for relative directories
Hi hmm, looking at it, makeRelative has no generalised QuickCheck properties, and all the specific instances are on absolute paths. I'll try and come up with a patch for this that does the right thing in this situation. I'd expect something like this: org / makeRelative org x == x or at least something like normalise (org / makeRelative org x) == normalise x at least on a best effort basis. Alas thats not true, because makeRelative can insert .. paths which can't be removed by normalise as they might be symlinks elsewhere. I wonder if makeRelative should insert .. paths - any thoughts? If not, then we could do: org / makeRelative org x == x makeRelative x (x / y) = y Thoughts? Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics
Hi In response to Neil: why use `unsafePerformIO` rather than IO exceptions here? I think you're asking for more trouble... Are you referring to ioError? My knowledge of exceptions in Haskell is limited. The error architecture is often a long way from the IO monad, so whatever we do can't require the IO monad. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Visual Haskell's Hello, World
Hi Bill, It seems trivial, but I think the contents of main.hs in the Visual Haskell default project should include a getChar: Then people will wonder why their app has stopped, and get very confused. A much better solution would be for GHC in Visual Studio to pause at the end of a console application and give the user a program terminated, press any key to finish message. Ideally at the end of every program, not just for the sample one. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: haddock's image markup doesn't work for me
Hi -- | images/stock-icons/stock_about_24.png Why not: -- | images/stock-icons/stock_about_24.png I thought that was the syntax. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHCi and Windows 98
Hi Steven, If you are just getting started, and GHC is giving you no luck, try Hugs (in particular WinHugs) which does work on Win98. http://www.haskell.org/hugs/ Thanks Neil On 12/7/06, Steven Tinsley [EMAIL PROTECTED] wrote: Good day to you. I installed GHC 6.6 on a Windows 98 SE system recently having decided to try to learn this language. Unfortunetley, GHCi causes an This program has performed an illegal operation error at startup and is shut down. This happens just after Loading base packagelinkingdone is shown. Windows produces this error message: [code] GHC caused an invalid page fault in module GHC.EXE at 0167:00c82e26. Registers: EAX=0078 CS=0167 EIP=00c82e26 EFLGS=00010297 EBX=00d963c8 SS=016f ESP=010cdd50 EBP=01c43f3c ECX=0007 DS=016f ESI=01be57e8 FS=1617 EDX= ES=016f EDI=01be57f4 GS= Bytes at CS:EIP: 66 83 3c 50 00 74 19 ff 45 00 83 ef 08 b8 18 2e Stack dump: 0078 0200 0001 00d0fe5c 0002 00cddbb6 0001 00c34b9c 00408442 [/code] Just thought you'd like to know. Thanks. Steven. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #974: Add isLeft, isRight, fromLeft, fromRight, and splitEithers to Data.Either
Hi #974: Add isLeft, isRight, fromLeft, fromRight, and splitEithers to Data.Either Woohoo! Finally! This proposal would add basic functionality to `Either` similar to that for `Maybe`. The `splitEithers` function of type `[Either a b] - ([a],[b])` is unique; however, it seems to be a widely useful function. This (in my mind) is a parallel to unzip? unzipEithers to me gives a much clearer picture of what is going on here. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #870: extra commas accepted in import export lists
Hi Bulat, as Duncan said, it's Good Thing. i permanently use this trick in the export lists. it's much better to change Haskell standard :) Really? I can perfectly understand that (export1, export2, ) is a useful thing to have - now that last element is not special in any way, and so if you are conditionally preprocessing you don't need to figure out future elements to get this element right. Note that this proposal and patch still allows that. Now what is disallows is (,export1,,, export2, ) do you really have a preprocessor situation where something like this comes up? Can't you just move the comma's inside the conditional? It seems a more structured and well thought out use of preprocessing if you keep the comma's correct. This issue has broken the Hugs library builds quite a few times - and I can fully understand that Ross wants things to stop breaking in Hugs land! Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Incomplete documentation
Hi, Taking a look at: http://haskell.org/ghc/docs/latest/html/libraries/base/GHC-ConsoleHandler.html#v%3AinstallHandler On Windows this has the members: data ConsoleEvent = ControlC | Break | Close | Logoff | Shutdown data Handler = Default | Ignore | Catch (ConsoleEvent - IO ()) flushConsole :: GHC.IOBase.Handle - IO () installHandler :: Handler - IO Handler In the docs it has nothing. By not providing documentation, its much harder for people to use the functions, if they can even figure out they exist. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #840: GHC on loosing its handles takes 100% CPU
Hi I'm not doubting that it's genuine -- but can anyone make a reproducible test case? The test case I put in the bug report makes it 100% reproducable on both my machines. I guess that means its a machine specific bug. Thanks Neil Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Lennart Augustsson | Sent: 04 August 2006 13:47 | To: Bulat Ziganshin | Cc: GHC; glasgow-haskell-bugs@haskell.org | Subject: Re: [GHC] #840: GHC on loosing its handles takes 100% CPU | | It happens all the time to me that GHC doesn't die properly on windows. | Every so often I have to kill a few straggling ghc processes. They | all spin consuming 100% CPU when this happens. | | -- Lennart | | On Aug 2, 2006, at 10:09 , Bulat Ziganshin wrote: | | Hello GHC, | | Wednesday, August 2, 2006, 4:33:09 PM, you wrote: | | #840: GHC on loosing its handles takes 100% CPU | | import System.Process | main = runInteractiveCommand ghc | | When run terminates immediately, as expected, but leaves an instance | of ghc running. The ghc process takes up 100% of the CPU time, and | seemingly does nothing. | | well, i have similar problem: there are only 256 megs on my machine | and sometimes when ghc compilation uses more than 200 megs and starts | trashing memory, i tries to stop it by hitting Ctrl-C. in this | situation it's rather typical that i got back my console (and rerun | ghc) but old GHC process don't killed and continue to compile program. | i can investigate it further but don't know what to do. at least it | seems that memory trashing is required to uncover this problem. i also | should note that i run ghc --make from the .cmd file so there is a | whole stack of processes runned. may be i just kill higher-level ghc | (or even cmd) and lower-level ghc still continue to do it's job? i'm | not sure.. | | -- | Best regards, | Bulatmailto:[EMAIL PROTECTED] | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: unsafeCoerce#
Hi In that bit of the manual it also has inline as both the section headings, so lazy won't show up in the table of contents. (a typo) I didn't think to search the manual anyway, so it would be nice if they could get added to the haddock index in some way. Thanks Neil On 7/31/06, Simon Peyton-Jones [EMAIL PROTECTED] wrote: Good idea. There's suitable section here in the HEAD manual, here: http://www.haskell.org/ghc/dist/current/docs/users_guide/special-ids.htm l#id3159468 I'll add a subsection about unsafeCoerce# Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Neil Mitchell | Sent: 31 July 2006 00:45 | To: glasgow-haskell-bugs@haskell.org | Subject: unsafeCoerce# | | Hi, | | Finding unsafeCoerce# in the documentation is challenging at best. | It's not indexed by Haddock, which in turn means its not indexed by | Hoogle. Lambdabot doesn't find it. Googling gave me GhcExts (from an | old Happy file), which I guessed at GHC.Exts. | | Someone in #haskell suggested GHC.Base. I'm not sure where I should | import it from, but it would be nice if the docs included it | somewhere. | | Thanks | | Neil | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
unsafeCoerce#
Hi, Finding unsafeCoerce# in the documentation is challenging at best. It's not indexed by Haddock, which in turn means its not indexed by Hoogle. Lambdabot doesn't find it. Googling gave me GhcExts (from an old Happy file), which I guessed at GHC.Exts. Someone in #haskell suggested GHC.Base. I'm not sure where I should import it from, but it would be nice if the docs included it somewhere. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GHCi on loosing its handles takes 100% CPU
Hi On Windows, GHC 6.4.2, the following program: import System.Process main = runInteractiveCommand ghc When run terminates immediately, as expected, but leaves an instance of ghc running. The ghc process takes up 100% of the CPU time, and seemingly does nothing. If ghci is used as the argument instead of ghc, then both ghc and ghci are left running, with ghc on 100% CPU time. In contrast, if hugs or Yhc or edit (or pretty much any program on my system) is run in exactly the same way, they terminate as soon as the main program is finished. Is there any chance that GHC could do this too? Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
forkIO and not -threaded
Hi, main = do forkIO $ print yes print done Compiled without -threaded, on 6.2.2 gives yes done on 6.4.2 done Seems the semantics of forkIO in this case has changed completely? Of course, I actually wanted -threaded and had forgot it, so I'm entirely happy if it just raises an error :) Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Missing haddock documentation
Hi, I'm not sure if anyone has noticed already, but the module documentation has gone missing: Linked to from here: http://haskell.org/ghc/docs/latest/html/libraries/index.html Does not exist: http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html Hoogle relies on these libraries as well, so I got an error when following a link. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Bug: Windows, -o, --make and relinking
Hi, GHC 6.4.2 doesn't normally relink when invoked with --make if the target file has not changed. This is very very useful! Create a Main.hs, and compile with ghc --make twice, first time it compiles, second time it does nothing. Compile with ghc --make -o file.exe twice, first time it compiles, second time it does nothing. Compile with ghc --make -o file (note the absence of .exe). First time it compiles as file.exe, second time and every time after it relinks. This is the bug. On Windows -o file means -o file.exe, and I guess the file file rather than file.exe is checked if it is up to date or not. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
File remains locked after crash
Hi, On Windows, using GHCi 6.4.2, its possible to lock files open: Change to a directory and run, at the prompt, with a file called test2.txt already created: writeFile test1.txt (error fail) or readFile test2.txt putStrLn (error fail) The file test.txt is created, for the first. In both cases, the error fail is given. Now its impossible to delete the two files using Windows explorer, because they are held open by GHCi. The only way I can find for GHCi to release the file is to close GHCi and restart it. It would be much nicer if GHCi had closed all open handles by the time it returned back to the prompt. Ross Paterson suggested an improved writeFile, which would close the file on error: import Control.Exception import System.IO writeFile' :: FilePath - String - IO () writeFile' f txt = bracket (openFile f WriteMode) hClose (flip hPutStr txt) Which might work better. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Show Bug (I think)
Hi,
---
data Item = Item1 Item
| Item2 {a :: Int}
deriving (Show, Read)
value = Item1 (Item2 1)
valueHugs = Item1 Item2 {a = 1}
valueGhc = Item1 (Item2 {a = 1})
readItem x = (read x) :: Item
--
With the following code show value under Hugs and Ghc give different
results. readItem valueHugs and valueGhc both succeed under Hugs, but
readItem valueHugs fails under GHC.
I guess this is a bug with GHC, since that text for valueHugs on the
command line succeeds with GHCi - i.e. typed directly not with read.
Hugs: WinHugs CVS
GHC: 6.4.2 Windows
Thanks
Neil
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Segfault on Windows
Hi It doesn't crash for me, but I get an error message: With the stock 6.4.2 I get the same error as yours. Sorry, I was on holiday and had missed the fact that 6.4.2 was out :) Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Segfault on Windows
Hi, I can reliably get ghc to crash on windows: AppName: ghc.exe AppVer: 0.0.0.0 ModName: unknown ModVer: 0.0.0.0 Offset: Code: 0xc005 This is using both ghc 6.4.1 and ghc-6.4.2.20060329-i386-unknown-mingw32.tar on Windows XP. The way I am getting this to occur is: * Check out the base libraries with darcs * Create setup.hs, with main = defaultMainWithHooks defaultUserHooks * runhaskell Setup.hs configure * runhaskell Setup.hs build crash, as above Unfortunately, I've tweaked a large number of things (cabal, winhugs, cpphs, haddock) and have all my files in surprising places etc - so this might be hard to reproduce. Interestingly, main = defaultMain does not crash ghc Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
