Re: (no subject)
On 19/12/2006 08:45, mm wrote: I can not login to the GHC Trac with the login/password suggested at the homepage. Could someone please confirm that it is currently not working? I just tried it here, and it worked for me. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
haskell98 package not linked by default in 7.0.1 (was: Re: making 7.01-pre)
On 30/10/2010 16:52, David Fox wrote: On Sat, Oct 30, 2010 at 4:43 AM, Serge D. Mechvelianimech...@botik.ru wrote: Dear GHC developers, I am testing this fresh ghc-7.0.0.20101028 on Debian Linux, i386-family. Making it from source by ghc-6.12.3 is all right. Then, making it from source by itself reports (here I abbreviate the messages by inserting `...') - + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old ... ... inplace/bin/mkdirhier utils/ghc-cabal/dist/build/tmp//. inplace/bin/mkdirhier bootstrapping/. /home/mechvel/ghc/7.01pre/inst1/bin/ghc -H32m -O --make utils/ghc-cabal/ghc-cabal.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal ... ... rm -f compiler/stage1/ghc_boot_platform.h Creating compiler/stage1/ghc_boot_platform.h... Done. /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Irts -DGEN_HASKELL -c includes/mkDerivedConstants.c -o includes/dist-ghcconstants/build/mkDerivedConstants.o ... ... ... utils/genprimopcode/dist/build/Lexer.o: In function `s2yT_info': (.text+0x1e1d): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' ... ... utils/genprimopcode/dist/build/Parser.o: In function `s4pK_info': (.text+0x5691): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' collect2: ld returned 1 exit status make[1]: *** [utils/genprimopcode/dist/build/tmp/genprimopcode] Error 1 make: *** [all] Error 2 - Why cannot it make itself? genprimopcode now needs -package array to build. We'll fix this in the build system but it raises an interesting point that we probably haven't publicised much. Previously we linked the haskell98 package by default, which also caused its dependencies (include array) to also be linked, but in 7.0.1 we don't link haskell98 by default, only base. If you're using --make (which is now the default in 7.0.1), you won't notice any difference, because all package dependencies are automatically linked, so this only makes a differences in one-shot mode where you compile each module to .o files first and then link by saying ghc Main.o Foo.o Bar.o -o prog So if you're doing this, and the program has dependencies on modules not in base, then you need to list them explicitly, e.g. ghc -package haskell98 Main.o Foo.o Bar.o -o prog This is part of moving from Haskell 98 to Haskell 2010 as our default base language. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: #4316: Getting the lexer state to check for AlternativeLayoutMode
On 18/10/2010 05:53, Vivian McPhail wrote: On 18 October 2010 15:37, Vivian McPhail haskell.vivian.mcph...@gmail.com mailto:haskell.vivian.mcph...@gmail.com wrote: Hi, In attempting to use the lexer to see whether we are within an alternative layout context: [..] I have a function which tells us if there is layout going on: activeContext :: P Bool activeContext = do ctxt - getALRContext expc - getAlrExpectingOCurly impt - implicitTokenPending case (ctxt,expc) of ([],Nothing) - return impt _other - return True Okay, this function is doing the right thing. I also tried counting curly brackets, which also doesn't work for the same reason: In AlternativeLayoutMode, when an EOF is encountered and there is an outstanding context, the context is removed and a closing curly is inserted (ITeof, ALRLayout _ _ : ls, _) - do setALRContext ls setNextToken t return (L thisLoc ITccurly) So as it stands, if we simply lex the ghci command line, we will never be inside a layout context once we see the EOF token. Right, so you need to lex up to the end of the line, but without letting the lexer see the EOF token, presumably? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Spam on the Trac
On 20/07/10 17:05, Sean Leather wrote: I just saw a lot of spam posts to the GHC Trac. Is there any way to prevent future occurrences of this? All the spam has been removed from the Trac, though unfortunately we can't remove it from the mailing list archives so easily. I'm not sure exactly who removed it all - I removed some of it, but the spammer account had already been removed when I got there. We do have the Trac spam filter plugin, and since having that enabled we haven't had problems with spam for quite a while. I'm not exactly sure how the recent flurry of spam got through, but we'll have to keep an eye on things and try to diagnose the problem if it happens again. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Segfault in ghc head -fllvm
Don, did you recompile all the libraries after updating GHC? We
recently turned on TNTC, which would cause breakages if you had any
libraries or packages compiled the old way.
Cheers,
Simon
On 29/06/2010 04:21, Don Stewart wrote:
This comes from a Haskell game, where the C program was about 10x
faster again (thanks to SSE).
The C program to test against is here:
http://stackoverflow.com/questions/3115540
Maybe use it as a benchmark?
-- Don
davidterei:
Too Slow :).
I fixed a few bugs in the LLVM backend in the last 24 hours, they seem
to have fixed this segault (that or I'm not reproducing your results
right). I can compile and run this program fine with latest GHC Head
under both 32/64 bit Linux.
Under 32bit I get a nice speed up with the LLVM backend but under 64
bit, fasm gives me about 1.5s and fllvm gives me about 1.8s which
isn't very good. So will have to investigate that, its quite unusual
for the ncg to beat llvm by anything more then 10%.
Cheers,
David
On 29 June 2010 03:32, Don Stewartd...@galois.com wrote:
The following vector program segfaults with the latest head snapshot,
{-# LANGUAGE BangPatterns #-}
{-
ghc 6.12.1 -O2
1.752
-}
import Data.Vector.Storable
import qualified Data.Vector.Storable as V
import Foreign
import Foreign.C.Types
-- Define a 4 element vector type
data Vec4 = Vec4 {-# UNPACK #-} !CFloat
{-# UNPACK #-} !CFloat
{-# UNPACK #-} !CFloat
{-# UNPACK #-} !CFloat
-- Ensure we can store it in an array
instance Storable Vec4 where
sizeOf _ = sizeOf (undefined :: CFloat) * 4
alignment _ = alignment (undefined :: CFloat)
{-# INLINE peek #-}
peek p = do
a- peekElemOff q 0
b- peekElemOff q 1
c- peekElemOff q 2
d- peekElemOff q 3
return (Vec4 a b c d)
where
q = castPtr p
{-# INLINE poke #-}
poke p (Vec4 a b c d) = do
pokeElemOff q 0 a
pokeElemOff q 1 b
pokeElemOff q 2 c
pokeElemOff q 3 d
where
q = castPtr p
a = Vec4 0.2 0.1 0.6 1.0
m = Vec4 0.99 0.7 0.8 0.6
add :: Vec4 - Vec4 - Vec4
{-# INLINE add #-}
add (Vec4 a b c d) (Vec4 a' b' c' d') = Vec4 (a+a') (b+b') (c+c') (d+d')
mult :: Vec4 - Vec4 - Vec4
{-# INLINE mult #-}
mult (Vec4 a b c d) (Vec4 a' b' c' d') = Vec4 (a*a') (b*b') (c*c') (d*d')
vsum :: Vec4 - CFloat
{-# INLINE vsum #-}
vsum (Vec4 a b c d) = a+b+c+d
multList :: Int - Vector Vec4 - Vector Vec4
multList !count !src
| count= 0= src
| otherwise = multList (count-1) $ V.map (\v - add (mult v m) a)
src
main = do
print $ Data.Vector.Storable.sum
$ Data.Vector.Storable.map vsum
$ multList repCount
$ Data.Vector.Storable.replicate arraySize (Vec4 0 0 0 0)
repCount, arraySize :: Int
repCount = 1
arraySize = 2
$ ghc-6.13.20100625 -fllvm -O2 --make A.hs
[1 of 1] Compiling Main ( A.hs, A.o )
Linking A ...
$ ./A
zsh: segmentation fault ./A
___
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] #650: Improve interaction between mutable arrays and GC
Switching to the new server has messed up threading for ghc-bugs emails. I think the culprit is this: References: 047.44b951cd4b5aa8536d862412c8d86...@abbot.galois.com In-Reply-To: 047.44b951cd4b5aa8536d862412c8d86...@abbot.galois.com these references point to @abbot.galois.com, rather than @monk.galois.com. It's not a showstopper, but it's somewhat annoying. Can anything be done about it? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3709: Data.Either.partitionEithers is not lazy enough
On 03/12/2009 14:12, Henning Thielemann wrote: On Thu, 3 Dec 2009, Malcolm Wallace wrote: #3709: Data.Either.partitionEithers is not lazy enough This is a behavioural change, e.g.: Main case partitionEithers1 [Left 'a', error Not me] of (x : _, _) - x Program error: Not me Main case partitionEithers2 [Left 'a', error Not me] of (x : _, _) - x 'a' Yes, and isn't that the point of the bugfix? No non-bottoming program has changed, but fewer programs fail now. I find it hard to imagine that anyone could have been relying on getting a crash here. Making something more lazy can cause a memory leak. and a time leak, or a stack overflow. People might complain if we made foldl' more lazy :-) Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: mkdirhier fails on Ubuntu Hardy i686 with dash shell
On 25/10/2009 19:34, Ian Lynagh wrote: On Mon, Oct 19, 2009 at 12:49:44PM -0600, Zooko Wilcox-O'Hearn wrote: Replacing the contents of mkdirhier and mkdirhier.sh with mkdir -p $* works-around the problem. Does anyone know why we don't just call mkdir -p normally? Are there portability problems with it? I believe 'mkdir -p' was not supported by some old unices, but AFAICT it seems to be supported by everything we build on these days. It probably wouldn't hurt to use it instead of mkdirhier. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: runhaskell script on head build
On 26/08/2009 11:05, David Duke wrote: This didn't seem like a ghc bug per se, but am happy to put an entry into trac if appropriate. In playing with DPH, I've recently tried building the head code, using Mac OSX 10.5.8 and ghc 6.10.4 After compiling and installing, I tried building an existing package, and noticed that runhaskell was returning with no result. On looking at the script, runhaskell/runghc from the head build is attempting to execute /usr/local/bin/ghc-stage2, rather than /usr/local/bin/ghc. The attempt to invoke the stage2 compiler is coming from the runghc.wrapper text in ghc/utils/runghc. Problem with the wrapper, or did I break something in the build process? My fault, I tried to make inplace/bin/runghc work, and broke the installed version at the same time. Am fixing it now. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: panic initC: srt_lbl on 6.10.3
On 28/06/2009 05:39, Conal Elliott wrote: I'm getting panic! (the 'impossible' happened) / initC: srt_lbl in ghc 6.10.3. Does anyone have an educated guess about initC: srt_lbl ? Oddly, ghci doesn't throw the panic. When I comment out some GADT code, the panic goes away. It's a pretty generic failure. -dcore-lint might trigger a failure earlier, but that probably won't help you. We need to reproduce the bug. Can you tell us how? (don't worry if the code depends on external packages, but ideally keep the dependencies to a minimum if you can). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [HOpenGL] renderString not working in ghci
On 01/06/2009 23:39, Sven Panne wrote: So my question is again: Why is -fPIC not the default for GHC on x86_64? If we don't want the overhead, that's OK (any benchmark numbers?), but then GHC's documentation should really contain a big, fat warning that GHCi's dynamic linker gets cases like the one above wrong. There is a ticket, BTW: http://hackage.haskell.org/trac/ghc/ticket/781 I've milestoned it for 6.12.1 and made it high priority. I think the only reason that -fPIC is not the default right now on x86_64 is that (a) it's (still) experimental, and (b) we don't know what performance implications it has. Duncan will hopefully be able to resolve both in due course. Duncan: just to clarify, the problem here is that in the x86_64 small memory model (the default), external references from non-PIC code are assigned 32-bit addresses. ld.so makes this work in two ways: * if the symbol points to code, then a jump trampoline is installed in the PLT, and the 32-bit address points to it * if the symbol points to data, then the data object is moved with the dreaded R_COPY relocation, so that it ends up within the low 2Gb and the 32-bit relocation is large enough. the problem is that in GHCi's linker we don't know which symbols point to data and which point to code. So we assume they point to code (data is quite rare), and install trampolines. If we use -fPIC, then external references are made via the PLT or GOT, and the problem doesn't occur. I mentioned this in a comment on #1876: http://hackage.haskell.org/trac/ghc/ticket/1876#comment:11 One thing we could do to help would be to spot foreign import ccall foo foo :: Ptr T where T is not a function type, and emit a warning suggesting the use of -fPIC. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
On 29/04/2009 01:23, Sigbjorn Finne wrote: Thanks Simon, sorry for not noticing your reply amidst the flow of g-h-b ticket reports before now. As there is no need to sail that close to the wind of playing with the delicate linking loading orders of the CRT and base DLLs like kernel32, my suggestion would be simply to avoid it. You don't do any explicit -lgcc -lc trickery when invoking gcc/ld on other platforms, so why be different? Apart from the changes to Win32.cabal and base.cabal mentioned in the original e-mail, injecting addDLL() calls for kernel32 and msvcrt in initLinker() ought to do it. I've now done exactly that. This seems like a good fix to try to get into 6.10.4 - can you think of any unexpected consequences? Cheers, Simon --sigbjorn On 4/27/2009 04:58, Simon Marlow wrote: On 24/04/2009 23:04, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. This is happening on the 3-4 boxes that I regularly develop on, which leads me to believe that this may not be limited to just me.. The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. gdb'ing the generated binaries, the crash is happening in the CRT startup code with some further poking around I've been able to determine that it is the explicit presence of -l options for 'kernel32' and 'msvcrt' when linking that's the cause. This is with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is well-behaved, but ghc is still using gcc-3.4.5. We have seen this problem here on Satnam Singh's machine, but we eventually put it down to a conflict between versions of certain MSYS bits. There may indeed be a real problem here, I don't know. On Satnam's machine we established that the problem was provoked by updating binutils, and the solution was don't do that (Satnam had originally done this because the windres that comes with MSYS was incompatible with GHC, but that can be worked around by just copying in a suitable windres). We also tracked it down as far as compiling a trivial C program with -lmsvcrt. Incedentally if you follow the instructions on the wiki exactly, you won't run into this problem: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. There's a couple of things that are odd here: * base.cabal files have kernel32 and msvcrt as extra-libraries. This is clearly not required when doing invocations via ld(1), and causes considerable mischief, so it'd be good if there was a way in .cabal files to distinguish between stuff that goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is there? Couldn't locate anything appropriate while working with the Cabal sources..) * 'base' needing to include these two dependencies even for GHCi usage. A running RTS will have these loaded already, so it really ought to have primed the list of opened DLLs by explicitly loading them upon initialization of the linker. [I've got a trivial patch against rts/Linker.c that does this; can forward/commit if of interest..] I've no idea why these library dependencies are there. It might well be historical. I'm happy to defer to Windows experts such as yourself on whether we should have them or not (I guess not?). * In addition to the patch referred to above, to solve these problems, I had to scrub libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the package.conf's for the versions of ghc I'm building against had to be edited, limiting the use of 'kernel32' and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' packages. Long and rambling..hope you made it this far ;-) Is anyone else running into this issue should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. One open question is whether we should expect gcc foo.c -lmsvcrt to work. It works with older versions of MSYS/mingw, but apparently not with more recent versions. On the face of it this seems like it ought to be harmless, since msvcrt will eventually be linked in anyway. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Inter-module links with Haddock broken?
On 28/04/2009 16:52, David Waern wrote: 2009/4/28 Sven Pannesven.pa...@aedion.de: Am Samstag, 25. April 2009 14:48:03 schrieb Sven Panne: Currently I am unable to make inter-module links (of the form 'Foo.Bar.baz') work with the Haddock shipped with GHC 6.10.2. [...] Until a few moments ago, I wasn't aware of the fact that Haddock has a trac for itself nowadays, so I guess my problem is a symptom of: http://trac.haskell.org/haddock/ticket/78 What is the schedule for the Haddock milestone 2.5.0 mentioned in that ticket? When can we expect that fix in a shipped GHC? We have no schedule yet. I will just release it when I have had time to fix enough bugs that it's worth making a release. Help wanted :-) I'm not sure if we can do Haddock fixes for 6.10.3. Can we? Otherwise an updated Haddock will not ship with GHC until 6.12.1. Not sure if Haddock will be installed by GHC installations in the future though, since I think the Haskell Platform is supposed to manage that. Is this correct? GHC will continue to ship Haddock, since the two are closely tied together nowadays by virtue of the GHC API. Ian will have to comment on the status of 6.10.3, I think it's very close to being ready to roll. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
On 24/04/2009 23:04, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. This is happening on the 3-4 boxes that I regularly develop on, which leads me to believe that this may not be limited to just me.. The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. gdb'ing the generated binaries, the crash is happening in the CRT startup code with some further poking around I've been able to determine that it is the explicit presence of -l options for 'kernel32' and 'msvcrt' when linking that's the cause. This is with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is well-behaved, but ghc is still using gcc-3.4.5. We have seen this problem here on Satnam Singh's machine, but we eventually put it down to a conflict between versions of certain MSYS bits. There may indeed be a real problem here, I don't know. On Satnam's machine we established that the problem was provoked by updating binutils, and the solution was don't do that (Satnam had originally done this because the windres that comes with MSYS was incompatible with GHC, but that can be worked around by just copying in a suitable windres). We also tracked it down as far as compiling a trivial C program with -lmsvcrt. Incedentally if you follow the instructions on the wiki exactly, you won't run into this problem: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. There's a couple of things that are odd here: * base.cabal files have kernel32 and msvcrt as extra-libraries. This is clearly not required when doing invocations via ld(1), and causes considerable mischief, so it'd be good if there was a way in .cabal files to distinguish between stuff that goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is there? Couldn't locate anything appropriate while working with the Cabal sources..) * 'base' needing to include these two dependencies even for GHCi usage. A running RTS will have these loaded already, so it really ought to have primed the list of opened DLLs by explicitly loading them upon initialization of the linker. [I've got a trivial patch against rts/Linker.c that does this; can forward/commit if of interest..] I've no idea why these library dependencies are there. It might well be historical. I'm happy to defer to Windows experts such as yourself on whether we should have them or not (I guess not?). * In addition to the patch referred to above, to solve these problems, I had to scrub libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the package.conf's for the versions of ghc I'm building against had to be edited, limiting the use of 'kernel32' and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' packages. Long and rambling..hope you made it this far ;-) Is anyone else running into this issue should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. One open question is whether we should expect gcc foo.c -lmsvcrt to work. It works with older versions of MSYS/mingw, but apparently not with more recent versions. On the face of it this seems like it ought to be harmless, since msvcrt will eventually be linked in anyway. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3081: Double output after Ctrl+C on Windows
Neil Mitchell wrote: 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 Yes. That sounds really dangerous - like a race condition between the system returning and the Haskell program aborting. I don't know why system returns, but one valid reason would be if the child process had died due to the same Ctrl-C. As Duncan says, in this case we ought to raise the Ctrl-C exception in the parent, but (a) none of this is implemented in the current process library, and (b) I'm not sure if you can tell whether a child died due to Ctrl-C on Windows. Also since Windows has no process groups, I don't think system is returning as a result of the child dying. It's more likely to be returning because of some silly Win32ism, like the way read() returns 0 on Windows when you press Ctrl-C. The latter also leads to very strange behaviour unless you check for it (which we don't, and we probably should). Consoles are very weird on Windows. Ctrl-C doesn't even work at all in MSYS or (certain types of) Cygwin windows, or xterms - it kills the program, but the program doesn't get a signal. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3081: Double output after Ctrl+C on Windows
Neil Mitchell wrote: I think I'm confused. I thought Ctrl+C was abort the program now, so figured that foo bar, where foo get's a Ctrl+C means bar is never executed? The double buffering thing I can understand, but the fact that bar gets executed at all is a little confusing. What if I did: 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? Cheers, Simon Thanks Neil On Thu, Mar 12, 2009 at 10:18 AM, GHC t...@galois.com wrote: #3081: Double output after Ctrl+C on Windows ---+ Reporter: NeilMitchell|Owner: Type: bug | Status: new Priority: normal |Milestone: _|_ Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ---+ Changes (by simonmar): * owner: simonmar = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3081#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ 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: build failure for 6.10.1, missing ghcautoconf.h
Conal Elliott wrote: I just tried to build 6.10.1 from the source tarball (http://haskell.org/ghc/dist/6.10.1/ghc-6.10.1-src.tar.bz2) (plus extralibs) on Ubuntu 8.10, building with ghc-6.11. I got the following error: Configuring ghc-bin-6.10.1... /home/conal/downloads/ghc-6.10.1/libraries/cabal-bin /usr/local/bin/ghc /home/conal/downloads/ghc-6.10.1/libraries/bootstrapping.conf build --distpref dist-stage1 --ghc-option=-H32m --ghc-option=-O --ghc-option=-H32m --ghc-option=-O Preprocessing executables for ghc-bin-6.10.1... Building ghc-bin-6.10.1... In file included from Main.hs:14:0: /usr/local/lib/ghc-6.11.20081103/ghc-6.11.20081103/include/HsVersions.h:23:0: error: ../includes/ghcautoconf.h: No such file or directory make[2]: *** [build.stage.1] Error 1 make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 [EMAIL PROTECTED]:~/downloads/ghc-6.10.1$ Is this problem known? Does it come from building 6.10.1 with 6.11? I didn't see a followup to this. Conal, are you still seeing this? I don't have any idea what's going on, and we don't see this on our Windows builds, but we can certainly investigate further. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2305: GHC does not care __RENAME macro
GHC wrote: #2305: GHC does not care __RENAME macro -+-- Reporter: iquiw| Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler (FFI) |Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: NetBSD | -+-- Changes (by simonpj): * status: closed = reopened * cc: [EMAIL PROTECTED] (added) * resolution: invalid = Comment: But Don Cave records in this email that the libraries we ship with GHC are missing some such wrappers. So really this is an open bug until someone adds the wrappers to the appropriate libraries. Thus I'm re-opening. (Re-close if I'm under a mis-apprehension.) I thougt we ought to have a separate ticket for the NetBSD-specific bug. Not a big deal though. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] Bug in parallel GHC runtime?
Don Stewart wrote:
Hi,
Thanks for the bug report.
This should be filed on the GHC bug tracker,
http://hackage.haskell.org/trac/ghc/newticket?type=bug
And I've forwarded it to the glasgow-haskell-bugs mailing list.
Please try with the 6.8.3 RC we just released. I fixed a bug that could be
the cause of this.
http://www.haskell.org/pipermail/glasgow-haskell-users/2008-May/014814.html
Cheers,
Simon
kolar:
Hello all,
The attached file was compiled by the following command:
ghc -O2 --make -threaded ltest1pl.hs -o alall
When run in a sequential mode, I get this result:
./alall
Starting ...
Lst1: 416665
Lst2: 4166916670
T1: 0m 1.0e-6s
36
End!
On the other hand, when run in a threaded mode, I get the following error:
./alall +RTS -N2
Starting ...
Lst1: 416665
Lst2: 4166916670
T1: 0m 0.0s
Segmentation fault
Is it fault of the GHC runtime, or is it something on my side?
My machine: uname -a
Linux pc 2.6.24-ARCH #1 SMP PREEMPT Sun Mar 30 10:50:22 CEST 2008 x86_64
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
My ghc: ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.2
Thanks and regards
Dusan
--import Control.Concurrent
--import Control.Concurrent.MVar
import System.Time
import Control.Parallel.Strategies
--import Data.List (foldl')
import qualified Data.ByteString as B
sumAllSums [] = 0
sumAllSums l@(_:xs) = sumlist 0 l + sumAllSums xs
where sumlist res [] = res
sumlist sr (v:vs) = sumlist (sr+v) vs
wlist2wbs [] = B.pack []
wlist2wbs l@(_:_) = B.pack $ encode l
where
encode :: Integral a = [Int] - [a]
encode [] = []
encode (x:xs) =
if x==0 then 0:0:encode xs
else fromIntegral (x `mod` 256) : fromIntegral (x `div` 256) : encode xs
main = do
putStrLn $ Starting ...
let lst1 = [0..4]
let lst2 = [0..5]
let bs1 = wlist2wbs lst1
let bs2 = wlist2wbs lst2
tm1 - getClockTime
let (v1:v2:_) = parMap rnf sumAllSums [lst1,lst2]
tm1' - getClockTime
putStrLn (Lst1: ++ show v1)
putStrLn (Lst2: ++ show v2)
let tdiff1 = diffClockTimes tm1' tm1
--let tdiff2 = diffClockTimes tm2' tm2
putStrLn $ T1: ++ show (tdMin tdiff1) ++ m ++ show (fromIntegral(tdSec tdiff1) +
fromIntegral(tdPicosec tdiff1)/1e12) ++ s
--putStrLn $ T2: ++ show (tdMin tdiff2) ++ m ++ show (fromIntegral(tdSec tdiff2)
+ fromIntegral(tdPicosec tdiff2)/1e12) ++ s
putStrLn $ show $ {-ibs1 +-} B.index bs1 9 + B.index bs2 4 {-((bs1 +
fromIntegral (B.index bs2 9)) :: Integer)-}
putStrLn $ End!
{-
main = do
tm1 - getClockTime
putStrLn $ Starting ...
mv1 - newEmptyMVar
mv2 - newEmptyMVar
t1 - forkIO (putMVar mv1 $! sumAllSums [0..4])
t2 - forkIO (putMVar mv2 $! sumAllSums [1..5])
v1 - takeMVar mv1
v2 - takeMVar mv2
killThread t1
killThread t2
putStrLn $ Result: ++ show (v1+v2)
tm2 - getClockTime
let tdiff = diffClockTimes tm2 tm1
putStrLn $ End! ++ show (tdMin tdiff) ++ m ++ show (fromIntegral(tdSec tdiff) +
fromIntegral(tdPicosec tdiff)/1e12) ++ s
-}
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
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] #1540: GHC on Macs
#1540: GHC on Macs --+--- -- Reporter: guest | Owner: Type: task | Status: closed Priority: high | Milestone: 6.8 branch Component: Build System |Version: 6.6.1 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Architecture: x86 Os: MacOS X | --+--- -- Changes (by chak): * status: new = closed * resolution: = fixed Comment: It's done. The HEAD has all the patches, and merged patches for the 6.8 branch are waiting for Ian's approval to push. I announced a trial package on the [http://www.haskell.org/pipermail/glasgow-haskell- users/2008-February/014298.html mailing list] and there is [wiki:Building/MacOSX/Installer detailed documentation] on the wiki. I will close this ticket. There may be bugs and missing features with the current implementation, but they should be filed as separate bug reports. Excellent, nice work! Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1015: regex001(ghci,threaded1) seg-faults under Solaris
Christian Maeder wrote: Hi Simon, could you please supply a testsuite.tgz for ghc-6.8.2 so that I can test it? (Or say how to easily get the testsuite only). I hope ghc-6.8.2 is sufficient for testing. A recent testsuite should be fine, that test hasn't changed in ages. In the future, I'll try to make sure we tag the testsuite for each GHC release. Cheers, Simon Cheers Christian see also http://hackage.haskell.org/trac/ghc/ticket/2025 GHC wrote: #1015: regex001(ghci,threaded1) seg-faults under Solaris ---+ Reporter: [EMAIL PROTECTED] | Owner: Type: bug| Status: new Priority: normal | Milestone: _|_ Component: Compiler |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Solaris| ---+ Comment (by simonmar): Christian - is this bug still relevant? ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: compiling ghc w/o ghc
Bulat Ziganshin wrote: i've seen the following report from a man who tried to compile 6.8.1 under linux without having any ghc installed: checking for ghc... no checking for path to top of build tree... ./configure: line 2724: -v0: command not found ./configure: line 2728: utils/pwd/pwd: No such file or directory line 2724: $WithGhc -v0 --make pwd -o pwd the $WithGhc variable is empty afaiu, configure should stop at the moment when previous ghc isn't found (he was extracted ghc-6.8.1-src-extralibs.tar.bz2 and ghc-6.8.1-src.tar.bz2 if that matter) Thanks, I'm validating a fix for this. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1943: round function causes cblas NaNs
GHC wrote: When I first submitted this the attach file action failed due to the size of my binaries. I mistakenly then resubmitted the bug and attached the files to ticket 1944. So this bug should be merged with 1944 or better just deleted. Ticket deleted. Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.6.1 testsuite on arm eabi: TestStub_stub.h: No such file or directory
Martin Guy wrote: 2007/11/20, Simon Marlow [EMAIL PROTECTED]: Martin Guy wrote: $ .../ghc6-6.6.1/testsuite/tests/ghc-regress$ make stage=2 fast make-fast-stage=2.errs 21 Wrong exit code (expected 0 , actual 2 ) /tmp/ghc27396_0/ghc27396_0.hc:5:27: error: TestStub_stub.h: No such file or directory This could be a difference in how gcc on your platform is finding header files, perhaps. Could you add -v to the GHC command line and send us the output? I find I get the same behaviour in x86 when using -fvia-C, and arm is always via-C so I've decided not to worry about it, but here is the -v output when running the guts of driver035 manually: This is a bug that was fixed in 6.8.1. The testsuite now has extra tests for this case (-stubdir and -fvia-C). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci ':browse *module' does not list items in source order
Claus Reinke wrote: [trac seems unreachable at the moment, hence good old email] while trying to write a test for an extension of :browse, i encountered an issue with the existing functionality: the order of names is not stable, making it difficult to write meaningful tests for :browse. a reduced test case output are appended below, showing that output order is affected by prior usage, in both 6.6.1 and HEAD. Yes, I noticed this too. i would prefer for the items to appear in source order, but at the point :browse gets a hand on them, source location information might not be available; sorting by Name would be random due to uniqueIds, and lexicographic sorting would be confusing to users (spreading related items all over the alphabet, instead of keeping the order in which they appear in source and documentation). is there a way to keep the items in source order, within each module (modules themselves could be sorted lexicographically)? I think what we want differs depending on whether you're browsing the whole module (:browse *M) or just the exports (:browse M). In the former case, you want the source ordering, and we have that because the module was compiled in this session and all the Names will have source locations (GHC.nameSrcSpan). However, :browse *M gives you the entire top-level scope rather than just the local bindings, so we probably want to separate local from non-local entities and sort the non-local entities alphabetically. In the second case, you want the export-list ordering, i.e. the same ordering that the entities occur in the Haddock documentation. Unfortunately this information isn't retained, so we'll have to settle for alphabetic sorting. It would be great if you could implement this, or else just submit a ticket. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.8.1-candidate tested
Serge D. Mechveliani wrote: Dear GHC developers, I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on Dumatel. It looks all right (except the bug-candidate for -O which is common to all GHC versions and which I recently reported ). On DoCon, ghc-6.8.0.20071015 1) builds the project 2-3 times faster than ghc-6.6.1, 2) its produced .a code is 1.6 times larger, I have noticed binary sizes increasing by around 20% on the nofib suite too. We've discovered one issue with some dictionaries not being inlined when we would expect them to, but there may be others. I'm investigating. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: profiling missing from snapshot?
Ketil Malde wrote: I installed the binary ghc-6.8.0.20071017 snapshot, but when I try to compile with -prof, I get % ghc --make -O2 src/Xml2Xls -o xml2xls2 -prof [1 of 1] Compiling Main ( src/Xml2Xls.hs, src/Xml2Xls.o ) Linking xml2xls2 ... /usr/bin/ld: cannot find -lHSrts_p collect2: ld returned 1 exit status 'locate HSrts_p' and other searches only find some old ghc-6.6 stuff. This one we know about: http://hackage.haskell.org/trac/ghc/ticket/1778 Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1738: GADT3 test failure
GHC wrote:
#1738: GADT3 test failure
-+--
Reporter: simonmar |Owner:
Type: bug | Status: closed
Priority: normal|Milestone: 6.10 branch
Component: Compiler | Version: 6.9
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Os: Unknown | Testcase: GADT3
Architecture: Unknown |
-+--
Changes (by chak):
* status: new = closed
* resolution: = fixed
hunk ./tests/ghc-regress/indexed-types/should_compile/all.T 50
-test('GADT3', expect_broken_for(1738, ['normal','optc']), compile, [''])
+test('GADT3', normal, compile, [''])
this test now fails on the stable branch - I assume the patch isn't going
to be merged, right? In that case we want an
expect_broken_if_compiler_lt in all.T.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Request for inline control of warning level
(I can't resist the opportunity to extend this conversation to 3 Simons :-) Simon Peyton-Jones wrote: | OPTIONS_GHC pragmas allow warnings to be enabled or disabled for a | particular file, but there are some limitations: | | * It doesn't override command-line settings (being tacked on the start, | rather than the end, of the options lists, I believe) I don't think this is right -- or if it is, it's a bug. The OPTIONS_GHC stuff is supposed to override command-line opts The Users Guide says: NOTE: the contents of OPTIONS_GHC are prepended to the command-line options, so you do have the ability to override OPTIONS_GHC settings via the command line. So GHC is at least behaving as documented. | * It doesn't work on sections of the code, but rather the whole file. True, and it'd be great to give more local pragma control -- a good feature request. Someone might want to work out details of the programmer's eye view and make a Trac feature request There's a ticket for it: http://hackage.haskell.org/trac/ghc/ticket/602 Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: runghc printing result of main when main is not IO ()
Tomasz Zielonka wrote: Hello! Consider: $ cat R.hs main = return [()] $ runghc R.hs [()] This was a bit surprising for me, because I thought that runghc mimics the way a compiled program behaves. This doesn't happen with 6.6.1, I believe we fixed it at some point by having runghc perform main return () instead of just main. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Data.HashTable.hashInt seems somewhat sub-optimal
[EMAIL PROTECTED] wrote: I tried submitting this bug through the tracker, but it seemed to give me permissions errors - probably a firewall issue here. :( Apologies. Anyway... Prelude Data.HashTable.hashInt 0 0 Prelude Data.HashTable.hashInt 1 -1 Prelude Data.HashTable.hashInt 2 -1 Prelude Data.HashTable.hashInt 3 -2 Prelude Data.HashTable.hashInt 4 -2 Prelude Data.HashTable.hashInt 5 -2 Prelude Data.HashTable.hashInt 6 -3 Prelude Data.HashTable.hashInt 7 -3 Prelude Data.HashTable.hashInt 8 -4 Prelude Data.HashTable.hashInt 9 -4 Prelude Data.HashTable.hashInt 10 -4 Prelude Data.HashTable.hashInt 200 -77 Prelude Data.HashTable.hashInt 201 -77 Prelude Data.HashTable.hashInt 202 -78 I prefer to use hashing to decrease the likelihood of collisions, not increase them. ;) I think the original algorithm was quite possibly supposed to use the bottom 32 bits of the result, although this means that changes in higher bits of the input do not affect lower bits of the hash. It should probably also use unsigned multiplication. Perhaps a better solution would be to xor or add together the high and low 32 bits? (I'm not sure as I haven't read the literature). FYI, this was a bug that has since been fixed. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug report: picoseconds handling in System.Time
Andrei Paskevich wrote: The diffClockTimes function can generate TimeDiff's with a negative value of tdPicosec. When you pass such a TimeDiff to addToClockTime, the latter may send negative picoseconds to toClockTime, provoking the error picoseconds out of range. While we are at it, please, teach normalizeTimeDiff to normalize tdPicoSeconds, too. This misfeature hangs around for too long :) Best regards, Andrei P.S. I'm not subscribed to the list, so please cc: me if needed. There are a number of serious problems with System.Time. If you're doing calculations involving time periods, I strongly suggest moving to the new time package (Data.Time etc.). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: stg_ap_pp_ret
Frederik Eaton wrote: No time to try to reproduce it, I'm preparing for a conference ;) I haven't seen the bug recently, but ... tangentially I was musing that if someone could devote some time to turning the GHC internal error message (which I've seen on over a hundred occasions, I'm sure) into a tool that queries the user and then, if he is OK with sharing his code (as a quite large number of programmers are) sends a core dump of GHC into some repository to be analysed, it might be beneficial for the GHC development process in the long run. This concept probably has a standard name that I don't know - I think something vaguely similar was done with some web browsers once, although perhaps not with the entire program state. It sounds like it might be difficult to implement, though. Just a thought. For some errors that would definitely be useful - e.g. for a GHC panic if there was an option to send the source code back to us automatically, I'm sure that would help us track down bugs more quickly. Unfortunately the crash you ran into was in the runtime, and in my experience just looking at a snapshot of the state at the point of the crash is unlikely to be revealing. I can very rarely track down an RTS bug from just a core dump. Still, I think the idea in principle is great - we want to make it easier for people to package up all the information we need to repeat a bug. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: stg_ap_pp_ret
Frederik Eaton wrote: I've been seeing this a lot: interactive: internal error: stg_ap_pp_ret (GHC version 6.6.1 for i386_unknown_linux) Sometimes it seems to go away when I remove .o and .hi files and recompile, but it keeps coming back when I make edits and/or compile with different optimisation options or something. We'll need a way to repeat it. Can you make it repeatable? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Vote for GHC 6.8 bugs!
Tomasz Zielonka wrote: On Tue, Jul 03, 2007 at 09:28:35AM +0100, Simon Peyton-Jones wrote: We have just instituted a cheap-and-cheerful mechanism for voting. Each bug has a 'cc' field. To vote, just add your email address to the cc field! How should we separate email addresses? Right now people use different characters: space, comma or semicolon. From a glance at the Trac code, I'd say comma or space, but not semicolon. Cheers, Smion ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -keep-hc-files or -keep-hc-file?
Ian Lynagh wrote: On Thu, Jun 28, 2007 at 03:46:31PM +0200, Christian Maeder wrote: Christian Maeder schrieb: I'm currently confused if it must be plural or singular (or any) http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#keeping-intermediates shows plural options whereas http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id3131928 shows them in singular (except -keep-tmp-files) Well spotted; thanks for reporting it! The plural options work! So flag-reference.html should be corrected. In actual fact the flag reference was exactly right, except the flags could take any argument, which they then ignore (so the ss were being treated as an argument when you gave the flags as plurals). This meant that things like -keep-s-file=no would also result in the .s file being kept, so I've changed the code to accept only -keep-foo (makes sense when using ghc -c) and -keep-foos (makes sense when using ghc --make). -keep-tmp-files is still plural-only. Everything should be consistent now. Just FYI, historically, these flags were called -keep-hc-file-too, -keep-s-file-too, etc. When I rewrote the driver I made it ignore the suffix, so that I could shorten the flag names and keep backwards compatibility. I don't think anyone still uses the old names. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1468: :browse should browse currently loaded module
Josef Svenningsson wrote: On 6/28/07, *GHC* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: #1468: :browse should browse currently loaded module +--- Reporter: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | Owner: Type: feature request| Status: new Priority: low| Milestone: Component: GHCi |Version: 6.6.1 Severity: trivial| Keywords: Difficulty: Easy (1 hr)| Os: Unknown Testcase: | Architecture: Unknown +--- With module Foo loaded, :browse should be equivalent to :browse Foo. Yes! I've wanted this a thousand times. If there was a voting mechanism on Trac I would vote for this feature. Add yourself to the CC list for the bug - this is our low-tech voting mechanism for now. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: haskell static libraries issue on Solaris 10 x86...
Christian Maeder wrote: Simon Marlow schrieb: Christian Maeder wrote: [...] In PrimOps.s it looks (wrongly mangled?) like this: .text .align 4 .type GHC_ZCCReturnable_static_info, @object .size GHC_ZCCReturnable_static_info, 4 .zero 4 .globl GHC_ZCCReturnable_static_info GHC_ZCCReturnable_static_info: [...] I guess we should just eliminate the .size directives if the linker is going to be picky about them. In ghc-asm.lprl you'll find $T_COPY_DIRVS = '^\s*\.(globl|type|size|local)'; if you change it to $T_COPY_DIRVS = '^\s*\.(globl|local)'; Now it looks like: .text .align 4 .zero 4 GHC_ZCCCallable_static_info: .text .align 4 .zero 4 .globl GHC_ZCCReturnable_static_info and elfdump shows: Section Header[1]: sh_name: .text sh_addr: 0 sh_flags: [ SHF_ALLOC SHF_EXECINSTR ] sh_size: 0x213c sh_type:[ SHT_PROGBITS ] and size 0! [...] [206] 0x213c 0x NOTY GLOB D0 .text GHC_ZCCReturnable_static_info Is this going to work? Should be ok, yes. The .size and .type information is only used when linking dynamically (at least on platforms I'm familiar with, which doesn't include Solaris), and we're only using static libraries here. It might be more correct for _info symbols to get .type function, since they're followed by code. I don't think we should worry about this though. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: haskell static libraries issue on Solaris 10 x86...
Christian Maeder wrote: Rod Evans schrieb: If this solves your problem ghc has a problem with object splitting under some solaris linkers Are you talking about the size issue we're presently discussing, or another issue in which the Solaris linkers fail you? We'd be happy to work with you directly to investigate things. I'm only talking about this size issue. The size problem occurs already in PrimOps.o (that is created from C-- sources PrimOps.cmm). Object splitting created the original file Utils__90.o with the size problem. http://www.opensolaris.org/jive/thread.jspa?threadID=32325tstart=0 (I don't now yet if the original Utils.o has a size problem, too.) I suppose creating object files from plain C should not result in object files with a size problem. Simon, do you have any idea why PrimOps.o has this problem (although only for a picky new linker)? Thanks for the pointer. I'm guessing the bogus .size information is a result of the reorganisation of the .s file that we do before assembling it: gcc inserts .size directives, we move things around in the .s, and at the end it the .size directives aren't right any more. The only reason we keep the .size directives around at all is because certain tools (like Valgind for example) don't work without .size information. GHC itself, including our dynamic linker, works fine without it. I can't tell exactly what has gone wrong in this particular instance - you'll need to compile the offending module with -keep-raw-s-file -keep-s-file and inspect those .size directives. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: haskell static libraries issue on Solaris 10 x86...
Christian Maeder wrote: Simon Marlow schrieb: The only reason we keep the .size directives around at all is because certain tools (like Valgind for example) don't work without .size information. GHC itself, including our dynamic linker, works fine without it. I can't tell exactly what has gone wrong in this particular instance - you'll need to compile the offending module with -keep-raw-s-file -keep-s-file and inspect those .size directives. At the end of PrimOps.raw_s there (probably correctly) is: .globl GHC_ZCCReturnable_static_info .align 4 .type GHC_ZCCReturnable_static_info, @object .size GHC_ZCCReturnable_static_info, 4 GHC_ZCCReturnable_static_info: .zero 4 All .text blocks are followed by p2align 2,,3 and typically look like: .string delayzh_fast .text .p2align 2,,3 In PrimOps.s it looks (wrongly mangled?) like this: .text .align 4 .type GHC_ZCCReturnable_static_info, @object .size GHC_ZCCReturnable_static_info, 4 .zero 4 .globl GHC_ZCCReturnable_static_info GHC_ZCCReturnable_static_info: Right, I see the problem. The mangler moved the symbol to the end of the structure as it was supposed to (info tables are laid out backwards in memory), but it left the .size directive in place. There apparently isn't a way to indicate the size of a structure that has a symbol at the end and not one at the beginning :-) I guess we should just eliminate the .size directives if the linker is going to be picky about them. In ghc-asm.lprl you'll find $T_COPY_DIRVS = '^\s*\.(globl|type|size|local)'; if you change it to $T_COPY_DIRVS = '^\s*\.(globl|local)'; that will get rid of all the .size directives. It's a bit brutal, but there isn't an easy way currently to just elimiante the problematic ones (the native code generator should generate the right thing, it's just the via-C code path that goes wrong). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: release notes
Frederik Eaton wrote: OK I see, I was switching from a ghc-6.6.20070420 binary release to the Debian package. I must have installed the 'extralibs' package or something together with the former...? Just to be clear, ghc-6.6.20070420 isn't a release, it's a snapshot. You probably installed the binary distribution produced by our overnight build, which does include the extralibs. The Debian package splits out the extralibs into separate packages, so you can install and upgrade them separately. Cheers, Simon Frederik On Thu, Jun 07, 2007 at 04:23:17PM +0100, Simon Marlow wrote: Frederik Eaton wrote: Hello, Perhaps it's a bit late, but should the release notes for 6.6.1 mention that many libraries have been split off from the main package (at least in the Debian version)? I am looking here: /usr/share/doc/ghc6/changelog.Debian.gz and here: http://haskell.org/ghc/docs/6.6.1/html/users_guide/release-6-6-1.html and I don't see anything. That change happened in version 6.6, you'll see it in the 6.6 release notes. Incedentally, I think the 6.6.1 manual should have contained the 6.6 release notes too, perhaps that was an oversight. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: release notes
Frederik Eaton wrote: Hello, Perhaps it's a bit late, but should the release notes for 6.6.1 mention that many libraries have been split off from the main package (at least in the Debian version)? I am looking here: /usr/share/doc/ghc6/changelog.Debian.gz and here: http://haskell.org/ghc/docs/6.6.1/html/users_guide/release-6-6-1.html and I don't see anything. That change happened in version 6.6, you'll see it in the 6.6 release notes. Incedentally, I think the 6.6.1 manual should have contained the 6.6 release notes too, perhaps that was an oversight. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
Deborah Goldsmith wrote: On May 23, 2007, at 2:08 AM, Simon Marlow wrote: Deborah Goldsmith wrote: On May 22, 2007, at 1:59 AM, Christian Maeder wrote: What are you trying to achieve? Did you compile parts with ghc-6.6 and ghc-6.6.1? (That may explain the crash.) If you have installed my binary distribution you don't need to compile the sources anymore (except for the sake of testing). This is purely for the sake of testing. As the subject indicates, I'm trying to build GHC from source on 10.5. I've built earlier versions successfully on 10.4. I did do a make clean between attempts, but I will try throwing the source directory away and re-extracting from the tar archive next. One possibility is that if you compiled GHC via C (I believe this is still the default in 6.6.1), then changes in the gcc shipped with 10.5 might be causing problems. You might get further by adding SRC_HC_OPTS = -O -fasm GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O -fasm GhcLibHcOpts= -O -fasm to your mk/build.mk. This might fix your build, but you'll still be left with some incompatibility between GHC and the gcc in 10.5. You already encountered one such problem, when using -split-objs, right? If you get a successful build it should be easier to debug this. I already have a usable build -- the 6.6.1 binary release that Christian put together works fine on 10.5. Actually there appears to be a problem with that 6.6.1 binary release, at least on your system. Both crashes that you described were in the stage1 compiler, which is compiled by your installed 6.6.1. So either (a) your installed 6.6.1 is generating bogus code (which is why I suspected a gcc incompatibility, because that would explain why Christian doesn't see the same crash) (b) there's a bug in GHC which makes it segfault on OS X 10.5. I'd say (b) is highly unlikely - GHC just a Haskell program (well, mostly), and it therefore shouldn't segfault. Still, you tried with -O -fasm and that didn't help. So I'm at a loss to explain why your stage1 GHC is crashing. Probably the only way forward at this point is to get out gdb and figure out what's going wrong. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: binary distribution problem
John Meacham wrote: also, ghc seems to produce noticibly faster 32 bit code than 64 bit code. I haven't observed that here, although the GC overhead for 64-bit binaries tends to be higher because it's shuffling twice as many bytes around. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
Deborah Goldsmith wrote: Actually, I'm not sure that's what's going on. The unresolved symbol error is: ../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -package-name base-2.1.1 -O -Rghc-timing -fgenerics -fgenerics -split-objs-c Foreign/C/Error.hs -o Foreign/C/Error.o -ohi Foreign/C/Error.hi /tmp/ghc78351_0/ghc78351_0.split__108.s:unknown:Undefined local symbol L_strerror$UNIX2003$stub So the reference actually is to the version *with* $UNIX2003 appended. Also, both strerror and strerror$UNIX2003 are present in the library being linked against, so if the FFI were going straight to strerror (old version), it would find it, because it's still there for compatibility. The only way that a symbol like L_strerror$UNIX2003$stub would be generated would be if someone *were* including unistd.h. There's no way the $UNIX2003 would creep in otherwise. Also, it says it's a local symbol. Also note the leading L; I would expect the symbol to be _strerror$UNIX2003$stub. The actual symbols exported by /usr/lib/libSystem.dylib in 10.5 are: c59c T _strerror 000b7fb4 T _strerror$UNIX2003 Ok, then we'll have to dig further. Suggestions: - turn off splitting: add SplitObjs=NO to mk/build/mk. If this makes the error go away, then the problem is likely in the split script (driver/split/ghc-split.lprl). - If the error is still there without splitting, then compile the module with -keep-tmp-files, and take a look at the .s and .raw_s files to see where the local symbol is coming from. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
Deborah Goldsmith wrote: I believe what's going on here is that strerror has been changed for better Unix conformance, under the control of the __DARWIN_UNIX03 preprocessor flag. This is something you'll see in 10.4.x too. Here's an excerpt from /usr/include/unistd.h on 10.4.9: #if __DARWIN_UNIX03 pid_tsetpgrp(void) __DARWIN_ALIAS(setpgrp); #else /* !__DARWIN_UNIX03 */ int setpgrp(pid_t pid, pid_t pgrp);/* obsoleted by setpgid() */ #endif /* __DARWIN_UNIX03 */ where __DARWIN_ALIAS and __DARWIN_UNIX03 come from /usr/include/sys/cdefs.h: #if __DARWIN_UNIX03 !defined(__LP64__) #define __DARWIN_ALIAS(sym) __asm(_ __STRING(sym) $UNIX2003) #else #define __DARWIN_ALIAS(sym) #endif The idea behind this is that if something is compiled with __DARWIN_UNIX03 (for Unix 2003 conformance) it links to a version of the routine with $UNIX2003 appended (for 32-bit architectures). If not, it gets the old version (for compatibility). In 10.5, strerror() now falls under this switch where it didn't in 10.4: char*strerror(int) __DARWIN_ALIAS(strerror); (In this case the function signature hasn't changed as it did with setpgrp, but presumably the semantics have.) I don't have a MacOS X machine here to investigate, but I can take a guess at what the problem is. When GHC compiles using its built-in native code generator, the names of functions mentioned in FFI declarations are taken literally: nothing is reading /usr/include/unistd.h, so there's no way to make the connection between strerror and strerror$UNIX2003. To justify this, we say that the Haskell FFI is binding to the C ABI, not API. The way to work around it is to add a stub C function to one of the C files in the base package, e.g. HsBase.h. There are many such stubs there already, for C functions that are implemented as macros. In most cases the C standard says which functions are allowed to be implemented as macros, so we can use appropriate stubs to forestall such issues, but changing the name with __asm doesn't count as a macro (presumably that's why you guys did it this way?). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC 6.6 panic from Data.Binary.Builder? reproducible on linux and mac os/x
S. Alexander Jacobson wrote: How to reproduce: $ curl http://searchpath.org/searchpath/SearchPath.hs SearchPath.hs $ ghc --make SearchPath.hs -o sp $ ./sp -f runghc --sp HAppS.Protocols.HTTP.FileServer --http-port=7000 searchpath will download all the needed modules and calls out to shell to run this: runghc -i.haskell_cache/http_searchpath.org-default.map.cache .haskell_cache/http_searchpath.org-default.map.cache/HAppS/Protocols/HTTP/FileServer.hs --http-port=7000 which produces the following error: ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for i386-apple-darwin): ByteCodeFFI.mkMarshalCode_wrk(x86) L_ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This particular panic was fixed in 6.6.1. It was a missing case in the handling of foreign imports by the byte-code compiler. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1275: ghci debugger is broken in the HEAD
Ian Lynagh wrote: On Sat, Apr 14, 2007 at 05:36:57PM -, GHC wrote: #1275: ghci debugger is broken in the HEAD Thanks, we are aware of this, we believe it is related to Wolfgang' patches changing the symbol names of datacons. But Bernie will be out for the next two weeks or so, and I haven't looked at his code for datacon recovery yet. I might give a look anyway, with an eye open for an easy fix. It's not particularly urgent; I was just sorting out the testsuite unexpected failures and it's nice to be able to point at a bug when marking a test as expected to be broken, so that when you come back to it in a couple of months time you know what's going on. I'm working on Bernie's patches with a view to committing something soon - hopefully this week. The new breakpoint code is sharing code with the coverage implementation, so I want to make sure we haven't broken anything. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci question
Duncan Coutts wrote: On Wed, 2007-04-04 at 00:01 +0100, Frederik Eaton wrote: Hello, This is a bit lame but I don't know where to find the information... I am wondering if ghci is OK to use with threads now. It seems to work but I have written down in some of my source code that a certain function won't work under ghci because it uses threads and I can't remember what the symptom of the problem was. Some Haskell libs that bind to foreign thread-unsafe libraries cannot safely be used with multiple Haskell threads in the threaded runtime system (and of course ghhci uses the threaded rts these days). In particular GUI libs are affected by this. For example you can use Gtk2Hs in GHCi, but if you forkIO and call GUI stuff from multiple threads... boom (or more likely an xlib error or segfault). There's info on the Gtk2Hs site about how to do it safely. Also, there are some library functions that will block all Haskell threads unless used with the threaded RTS (e.g. System.Process.waitForProcess). These are now safe to use with GHCi. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1110: Setting PATH needed in Windows Vista
Ross Paterson wrote: On Mon, Apr 02, 2007 at 10:48:11AM -, GHC wrote: [http://www.makegamegold.com World Of Warcraftwow gold][http://www.makegamegold.com/default.asp?cateid=6 wow gold][http://www.makegamegold.com/default.asp?cateid=6 gold wow So the ticket spammers have arrived at the GHC trac (having already attacked the Hugs and Hackage ones). Deleting seekgzl would be a stop-gap measure, but we need a real defence. I've removed the account, deleted all the spam, and turned off modifications by unknown users for now. We really need to upgrade Trac and get those anti-spam tools! Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1110: Setting PATH needed in Windows Vista
Ross Paterson wrote: On Mon, Apr 02, 2007 at 10:48:11AM -, GHC wrote: [http://www.makegamegold.com World Of Warcraftwow gold][http://www.makegamegold.com/default.asp?cateid=6 wow gold][http://www.makegamegold.com/default.asp?cateid=6 gold wow So the ticket spammers have arrived at the GHC trac (having already attacked the Hugs and Hackage ones). Deleting seekgzl would be a stop-gap measure, but we need a real defence. If anyone wants to delete spam on the other Tracs, then the little script in ~simonmar/bin/delete-ticket-changes will probably be useful. I tried removing messages from the list archive, but it doesn't seem to be possible without breaking the URLs of existing messages unfortunately. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] Visual Haskell install error
Thanks for the analysis. You can use the GHC bug tracker for tickets against Visual Haskell - just set the Component field to Visual Haskell. Unfortunately we can't guarantee to fix anything promptly; Krasimir Angelov is the only person actively working on Visual Haskell, and he's been quiet recently. Cheers, Simon Liam Clarke wrote: Did you use the default install directory or a custom one? A custom directory what caused this error for me. The simple solution was to uninstall and reinstall to the default Program Files\Visual Haskell path. Alternately, have a look at this file here - http://darcs.haskell.org/vshaskell/vs_haskell_setup/setup.vbs What's failing is the calls to regsvr32.exe - if you search your system for vs_haskell.dll, you'll most likely find that it's in... C:\Program Files\Visual Haskell\bin, no matter what install directory you specified. If you check the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Visual Haskell\Visual Studio version\InstallDir you'll see that it's set to the one you specified (where Visual Studio version is 7.1 for 2003 and 8.0 for VS 2005. So what's happening is that regsvr32 is trying to find the DLL's in the \bin directory of your specified install dir, but the DLL's are over in Program Files... not sure what other bugs this could introduce, hence why I reinstalled to Progam Files etc. If you run the following three commands in a command prompt, it should work to some extent, but I'll reiterate that I haven't tested this. regsvr32.exe /i:8.0 /n /s C:\Program Files\bin\vs_haskell.dll regsvr32.exe /i:8.0 /n /s C:\Program Files\bin\vs_haskell_babel.dll regsvr32.exe /i:8.0 /n /s C:\Program Files\bin\vs_haskell_babel.dll VS 2003 users should replace 8.0 with 7.1... Now, is there a bug tracker anywhere for this, or is it just the mailing list? I think the hardcoded paths in http://darcs.haskell.org/vshaskell/vs_haskell_setup/Common.wxs need to be tweaked, or the reg key(s) modified. :-) Anyway, hope that helps you, good luck. Liam Clarke ___ 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: How about change prep-bin-dist-mingw's default enviroment up todate?
Claus Reinke wrote: ps there has to be a less ugly way to get the doc path than this, though: ghc-pkg field base haddock-html | sed -e 's/^[^:]*: //' -e 's/$topdir/echo `ghc --print-libdir`/e' http://hackage.haskell.org/trac/ghc/ticket/937 This fix will be in 6.6.1. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs
Ah, so you did, thanks for reminding me. We still need to do something about
ghc-pkg, though.
Cheers,
Simon
Sigbjorn Finne wrote:
I added support for generating .bat files (to HEAD, I believe) for these
in-place
wrappers some time ago just to address this issue, so you may want to
look into
dragging those Makefile mods over.
--sigbjorn
On 3/5/2007 08:58, GHC wrote:
#1196: Cabal on Windows doesn't like the in-place GHCs
-+--
Reporter: igloo | Owner: Type:
bug | Status: newPriority: normal|
Milestone: _|_ Component: Compiler | Version: 6.6
Severity: normal|Keywords: Difficulty: Unknown
|Testcase: cabal01
Architecture: Unknown | Os: Windows
-+--
From e.g. a cmd prompt, Windows doesn't like the in-place GHCs:
{{{
C:\C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace' is
not recognized as an internal or external command, operable program or
batch file.
C:\cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-
inplace
#!/bin/sh
exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc
-BC:cygwinhomeianghc6.6-branchbuild $@
}}}
which means the cabal01 test fails thus:
{{{
$ ./setup configure --prefix=`pwd`/install --with-
compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc-
inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace
--enable-library-profiling
setup.exe: Warning: Package is copyright All Rights Reserved
setup.exe: Warning: No license-file field.
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace' is
not recognized as an internal or external command,
operable program or batch file.
Configuring test-1.0...
}}}
(the odd output order is due to buffering)
___
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: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics
Neil Mitchell wrote: 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. Yes - the example was in the IO monad so I thought you could use IO exceptions. In any case, I don't recommend using 'error' (or indeed 'unsafePerformIO') for errors you report to the user, purely because of its non-deterministic semantics. If you use a suitable error monad or IO exceptions, you can be sure that you'll get the same behaviour regardless of compiler or optimisation settings. Cheers, Simon ___ 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
The code in YHC is roughly if some list is empty then error No files found else error Many files found. If this code were changed to the equivalent of error (if some list is empty then No files found else Many files found), would there still be circumstances where the actual output produced could vary? Maybe. If GHC knows that error is strict (which it might well do) then you could be back where you started. Cheers, Simon ___ 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
Simon Marlow wrote: The code in YHC is roughly if some list is empty then error No files found else error Many files found. If this code were changed to the equivalent of error (if some list is empty then No files found else Many files found), would there still be circumstances where the actual output produced could vary? Maybe. If GHC knows that error is strict (which it might well do) then you could be back where you started. Oops, error isn't strict, never mind. Cheers, Simon ___ 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
Simon Marlow wrote: Simon Marlow wrote: The code in YHC is roughly if some list is empty then error No files found else error Many files found. If this code were changed to the equivalent of error (if some list is empty then No files found else Many files found), would there still be circumstances where the actual output produced could vary? Maybe. If GHC knows that error is strict (which it might well do) then you could be back where you started. Oops, error isn't strict, never mind. Ok, so error *is* strict. Please ignore me, I have a cold and I'm having a bad day :-( Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: trac-ticket/955
Christian Maeder wrote: For some reason I cannot login using guest guest http://hackage.haskell.org/trac/ghc/ticket/955 I only want to suggest to change the milestone to 6.8. Although the code-bloat is not nice, we could live with it. Somebody changed the password for guest again. I must figure out how to disable that. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Stretching the Storage Manager a little too much...
Michael Weber wrote: [I am reading ghc-bugs via the list archives, Cc'ing me would make me see responses faster] Here's a simple memoization function: applyMemo :: (Eq a1,Show a1) = (a1 - b) - MVar [(a1,b)] - (a1 - b) applyMemo f refTable x1 = unsafePerformIO $ do -- print x1 table - takeMVar refTable let key = x1 case lookup key table of Nothing - do let result = f x1 putMVar refTable $! (key,result):table return result Just memo - putMVar refTable table return memo The code above is a cut-down example. Initially, I tried to use Data.HashTable, then IORef (Data.Map ...), then MVars. However, what remains is that I get funny results: loop, thread blocked indefinitely, hangs, depending on the exact implementation of applyMemo, whether I use ghci or ghc, and which function I memoize (something with a more interesting call pattern than fib). Would you mind submitting a complete test case that we can use to reproduce the problem? We can probably reconstruct one from your description, but you probably already have the code lying around. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug interactive: internal error: interpretBCO: unknown or unimplemented opcodes
Matthew Sackman wrote: interactive: internal error: interpretBCO: unknown or unimplemented opcode 20196 (GHC version 6.6 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted Thanks for the report - this bug has already been fixed, see http://hackage.haskell.org/trac/ghc/ticket/1013 Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: (no subject)
mm wrote: I can not login to the GHC Trac with the login/password suggested at the homepage. Could someone please confirm that it is currently not working? Someone changed the password for 'guest' :-( Now fixed. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in GHC master Makefile
Norman Ramsey wrote: 'make uninstall' silently does nothing: I'm not aware of 'make uninstall' ever working, in fact I don't think I've ever tried it. Probably we should just disable it, I'm not sure it's worth the trouble to get it right. Ian, what do you think? P.S. The web interface for submitting bugs won't let me log in. that's bad, what happened? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: help with threadDelay
Ian Lynagh wrote: [moving to glasgow-haskell-bugs] On Wed, Nov 15, 2006 at 11:40:12PM +, Neil Davies wrote: however when -threaded is used you get some interesting effects, including returning too early: Tgt/Actual = 0.000125/0.34s, diff = -0.91s Thanks for the report; I can reproduce it on Linux/amd64. OK, so the bug here is that threadDelay n might return after less than n microseconds. This looks like it's caused by truncation problems when converting times to ticks (where a tick is 1/50 of a second), e.g. while trying to sleep for 1.953125s one run started at 1164157960.773726s which is (Int) 1164157960 * 50 + 773726 * 50 / 100 = (Int) 58207898038.6863 = 58207898038 ticks and woke the thread up at 1164157962.708609s which is (Int) 1164157962 * 50 + 708609 * 50 / 100 = (Int) 58207898135.4305 = 58207898135 ticks The difference is 58207898135 - 58207898038 = 97 ticks. Meanwhile we're trying to sleep for (Int) 50 * 1.953125 = (Int) 97.65625 = 97 ticks However, 1164157962.708609s - 1164157960.773726s = 1.93488311767578s which is 0.0182418823242201s too short. The problem is that we have counted 0.6863 ticks before the start time, not counted 0.4305 ticks before the finish time and have been waiting 0.65625 ticks too short a time. Thus we have counted (0.6863-0.4305 + 0.65625) / 50 == 0.018241 too much time. I think the answer is that let target = now + usecs `quot` tick_usecs in GHC/Conc.lhs should be let target = 1 + now + (usecs + tick_usecs - 1) `quot` tick_usecs I'm also a bit dubious about the use of the constant 50 for the number of ticks per second, but the results with +RTS -V0.001 don't look any more wrong so perhaps I just need to get some sleep. The hardcoded 50 in GHC/Conc.lhs matches up with TICK_FREQ in libraries/base/includes/HsBase.h. It could probably be made larger without any ill effects. I agree that we should round up the target time to the nearest tick rather than rounding down, though. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: cabal, extralibs, no happy
Christian Maeder wrote: 3. the happy-1.15 sources can not be compiled due to http://haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.html # The HasBounds class has been removed from Data.Array.Base, and its bounds method is now in the IArray class. The MArray class has also gained a method getBounds. # Is there any easy fix? Yes, get Happy from darcs: http://darcs.haskell.org/happy I'm currently preparing the 1.16 release, you can get a release candidate here: http://haskell.org/happy/happy-1.16rc2.tar.gz. Feedback very welcome. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: smart relinking bug
Lemmih wrote: On 10/21/06, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Lemmih, Saturday, October 21, 2006, 8:11:02 PM, you wrote: gcc -c -o a.o a.c ghc --make Main.hs a.o this command incorrectly don't relinks executable if a.c was changed but Main.hs wasn't Did you mean a.o instead of a.c? if a.c changes then first line will recompile it and change a.o too :) for '--make' command a.o will be changed and main.hs remains old Ah, I didn't read the two lines as a single command. I think adding something like this to DriverPipeline should fix it: extra_ld_inputs - readIORef v_Ld_inputs extra_times - mapM (IO.try . getModificationTime) extra_ld_inputs) let linking_needed | Left _ - e_exe_time = True | Right t - e_exe_time = any (t ) (map linkableTime linkables) || any (t ) [ t' | Right t' - extra_times ] Looks good - you can simplify with a ++ instead of the ||, though. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Broken snapshot archives
Tomasz Zielonka wrote: Some recent GHC snapshot files seem to be broken. For example with http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060927-i386-unknown-linux.tar.bz2 I get: $ tar jxf ghc-6.5.20060927-i386-unknown-linux.tar.bz2 bzip2: Compressed file ends unexpectedly; perhaps it is corrupted? *Possible* reason follows. bzip2: Inappropriate ioctl for device Input file = (stdin), output file = (stdout) It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now Yes, this is due to a long-standing problem with our firewalls that sometimes cause corruption of an SSH connection. I'll try to make it retry or delete the file on failure instead of leaving a broken tarball in place. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
Tomasz Zielonka wrote: On Tue, Sep 26, 2006 at 01:46:30AM +0100, Ian Lynagh wrote: I couldn't reproduce this with a simple program that forked off 4 threads to do computation on a single CPU machine, and neither could someone on IRC with head from Sep 15 on a Core Duo. Is it possible to send us a small example program along with exactly what flags you used to compile and run it please? It turns out it happens even with the simplest program: main = return Compilation command: ghc -threaded --make B -o B Running: [EMAIL PROTECTED]:~/src/par$ ./B +RTS -sstderr ./B +RTS -sstderr 21,864 bytes allocated in the heap 1,404 bytes copied during GC (scavenged) 4,156 bytes copied during GC (not scavenged) 21,936 bytes maximum residency (1 sample(s)) 1 collections in generation 0 ( 0.00s) 1 collections in generation 1 ( 0.00s) 1 Mb total memory in use Task 0 (worker) : MUT time: 402094045.13s ( 0.00s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 1 (worker) : MUT time: 200.00s ( 0.00s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 2 (worker) : MUT time: 0.00s ( 0.00s elapsed) GC time: 0.00s ( 0.00s elapsed) INIT time0.00s ( 0.00s elapsed) MUT time0.00s ( 0.00s elapsed) GCtime0.00s ( 0.00s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time0.00s ( 0.00s elapsed) %GC time 0.0% (11.5% elapsed) Alloc rate21,864,000,000 bytes per MUT second Productivity 100.0% of total user, 0.2% of total elapsed It doesn't happen when I compile without -threaded. But it doesn't show task statistics then. Perhaps clock_gettime() is returning strange results on your system. Could you try compiling with -threaded -debug, and run the program under gdb. Set a breakpoint in getThreadCPUTime(), and take a look at what gets returned by clock_gettime(). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Summary of GHC 6.6 test suite failures on MSYS/MinGW
Brian Smith wrote: On 9/26/06, *Simon Marlow* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Brian Smith wrote: The test always failed. When I decreased the number of threads in the test from 5,000 to 1,400 or so, then the tests passed sometimes, and sometimes failed. Decreasing the number of threads to under a thousand made the test pass consistently. IIRC, the test failed almost immediately upon executing. conc023 creates 5000 threads that all do threadDelay with varying delays. On Windows, with both the threaded and non-threaded runtimes, this results in 5000 OS threads being created, which is usually enough to fill up your VM. I intend to fix this, at least in the threaded RTS, in fact it'll be part of the fix for http://hackage.haskell.org/trac/ghc/ticket/637. The I/O manager thread handles sleeps and signals, but currently isn't implemented on Windows. It already passes in the threaded RTS and every other way except GHCi: normal, opt, optasm, prof, profasm, threaded1, and threaded2. That is what I thought was strange. It's slightly odd that the test only runs out of memory in GHCi, but I doubt there's anything GHCi-specific about the problem, just probably GHCi needs more memory full stop. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
Tomasz Zielonka wrote: On Wed, Sep 27, 2006 at 09:25:39AM +0100, Simon Marlow wrote: Perhaps clock_gettime() is returning strange results on your system. Could you try compiling with -threaded -debug, and run the program under gdb. When I compile with -threaded -debug, the stats are OK :-/ Ok, maybe try strace? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Summary of GHC 6.6 test suite failures on MSYS/MinGW
Brian Smith wrote: On 9/25/06, *Ian Lynagh* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Wed, Sep 13, 2006 at 12:23:27PM -0500, Brian Smith wrote: * conc023(ghci) This test only fails when run via GHCi. This test runs out of memory. The error message to stderr is: conc023: failed to create OS thread: Not enough storage is available to process this command. When I came back to the computer I saw that Windows was warning me that I was out of virtual memory and that it was increasing my page file size. I have 1GB of RAM which I think should be sufficient to run the testsuite successfully. Does that happen repeatably? The test always failed. When I decreased the number of threads in the test from 5,000 to 1,400 or so, then the tests passed sometimes, and sometimes failed. Decreasing the number of threads to under a thousand made the test pass consistently. IIRC, the test failed almost immediately upon executing. conc023 creates 5000 threads that all do threadDelay with varying delays. On Windows, with both the threaded and non-threaded runtimes, this results in 5000 OS threads being created, which is usually enough to fill up your VM. I intend to fix this, at least in the threaded RTS, in fact it'll be part of the fix for http://hackage.haskell.org/trac/ghc/ticket/637. The I/O manager thread handles sleeps and signals, but currently isn't implemented on Windows. Now, when I tried to rerun the tests against the latest ghc-6.6, ghc.exe is segfaulting on ffi012(ghci), conc049(ghci), and conc023(ghci): Unhandled exception at 0x0207fc58 in ghc.exe: 0xC005: Access violation. That's a bit worrying... Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #724: tee complains if used in a process started by ghc
GHC wrote: #724: tee complains if used in a process started by ghc ---+ Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.8 Component: libraries/base|Version: 6.4.1 Severity: normal| Resolution: Keywords:| Os: Unknown Difficulty: Moderate (1 day) | Architecture: Unknown ---+ Changes (by igloo): * milestone: 6.6 = 6.8 we might be able to get this into 6.6.1, it doesn't involve any API changes (well, perhaps strictly speaking there would be a change in that the std file descriptors wouldn't be set to O_NONBLOCK, but I doubt that would affect anyone adversely). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: weird data corruption
Frederik Eaton wrote: Hey, it looks like the output of two threads is being interleaved one character at a time. Is that really the most efficient way to schedule threads? Anyway, so I guess I need to set stdout and stderr to be line buffered? Perhaps that should be the default setting? ... stderr is always unbufferred by default, this is pretty standard (I believe it's the same in C's stdio). stdout should be line bufferred if connected to a terminal, or block-bufferred if connected to a file. Cheers, Simon 2006-08-22 22:49:58 4: querying (select cmdid from pfcq_study_cmdid where user=2;) 2006-08-22 22:49:58 4: duration: 0.5 msec 2006-08-22 22:49:58 4: executing (up2d0a0t6e- 0p8f-c2q2_ s2t2u:d4y9_:c5m8d i3d: sueste rc m=d i2d, =c ocmmmdaindd+ 1= wrheegries tuesre-rp=a2g;e)- vi2e0w0 6-20080-62-20 82-22:24 92:25:84 94::5 8 3d:u reaxteicount:i n0g. 3( smtsaerct t2r0a0n6s-a0c8t-i2o2n )2 2:24090:65-80 84-:2 2e x2e2c:u4t9i:n5g8 (3c:o m m idtu)r ation: 5.9e-2 msec 2006-08-22 22:49:58 3: querying (select cmdid from pfcq_study_cmdid where user=2;) 2006-08-22 22:49:58 3: duration: 0.3 msec 2006-08-22 22:49:58 3: executing (update pfcq_study_cmdid set cmdid = cmdid+1 where user=2;) Frederik On Tue, Aug 22, 2006 at 02:43:36PM +0100, Frederik Eaton wrote: I can't repeat it, but I can let you know if it happens again. I'm writing with 'hPutStr', but not directly - rather via some modules in a package I wrote. Kernel is Linux 2.6.16, libc 2.3.6, running Debian. Frederik On Tue, Aug 22, 2006 at 10:14:19AM +0100, Simon Marlow wrote: Can you repeat it? What API are you using to write the file? On what OS? Cheers, Simon Frederik Eaton wrote: Sorry, forgot to say that I was using GHC 6.4.2 the first time, and ghc-6.4.3.20060816 this time. Frederik On Mon, Aug 21, 2006 at 10:45:40PM +0100, Frederik Eaton wrote: Hi, I'm seeing some odd data corruption in a log file. Below, the second line should be a SQL query (prefixed by a timestamp). It's turned into garbage, but apparently not just random bytes. I'm using HSQL - that's the only external library, and it uses FFI, so there might be some bad memory management, but I thought I should ask if other people have seen something similar. It's the second time this has happened to me. # fillUpQueue 8-22010 62-20:83-12:12 62:2 :e3x1e:c2u6t:i nqgu e(rdyeilnegt e( sferloemc tp fccoqu_nstt(u*d)y _fqruoemu ep fwchqe_rset usdqy__uqsueeru e= w2h)e re sq_user = 2) 2006-08-21 22:31:27: duration: 843.8 msec # addToQueue # getNewCards # getVT 2006-08-21 22:31:27: querying (select max(res_num) from pfcq_study_results where res_user = 2) 2006-08-21 22:31:27: duration: 152.6 msec Regards, Frederik -- http://ofb.net/~frederik/ -- http://ofb.net/~frederik/ ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: weird data corruption
Can you repeat it? What API are you using to write the file? On what OS? Cheers, Simon Frederik Eaton wrote: Sorry, forgot to say that I was using GHC 6.4.2 the first time, and ghc-6.4.3.20060816 this time. Frederik On Mon, Aug 21, 2006 at 10:45:40PM +0100, Frederik Eaton wrote: Hi, I'm seeing some odd data corruption in a log file. Below, the second line should be a SQL query (prefixed by a timestamp). It's turned into garbage, but apparently not just random bytes. I'm using HSQL - that's the only external library, and it uses FFI, so there might be some bad memory management, but I thought I should ask if other people have seen something similar. It's the second time this has happened to me. # fillUpQueue 8-22010 62-20:83-12:12 62:2 :e3x1e:c2u6t:i nqgu e(rdyeilnegt e( sferloemc tp fccoqu_nstt(u*d)y _fqruoemu ep fwchqe_rset usdqy__uqsueeru e= w2h)e re sq_user = 2) 2006-08-21 22:31:27: duration: 843.8 msec # addToQueue # getNewCards # getVT 2006-08-21 22:31:27: querying (select max(res_num) from pfcq_study_results where res_user = 2) 2006-08-21 22:31:27: duration: 152.6 msec Regards, Frederik -- http://ofb.net/~frederik/ ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc searches for package libraries relative to cwd?
Frederik Eaton wrote: Hi all, It seems that ghc is searching for package libraries relative to the current directory. Is that the intended behavior? ghci does the same thing, by the way. $ pwd /home/frederik/GSLHaskell2 $ ghc --make ../test-proc.hs -package GSL Chasing modules from: ../test-proc.hs Compiling Main ( ../test-proc.hs, ../test-proc.o ) Linking ... $ cd .. $ ghc --make test-proc.hs -package GSL Chasing modules from: test-proc.hs Skipping Main ( test-proc.hs, test-proc.o ) Linking ... /usr/bin/ld: cannot find -lHSGSL-0.5 collect2: ld returned 1 exit status GHC searches for libraries using the library-dirs field of the package. Try doing a 'ghc-pkg field GSL library-dirs' and see if there are any relative pathnames in there. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Incomplete documentation
Neil Mitchell wrote: 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. Fixed, thanks. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #843: Dependency information for the linking step
Volker Wysk wrote:
On Tuesday 08 August 2006 14:08, GHC wrote:
#843: Dependency information for the linking step
+--
- Reporter: [EMAIL PROTECTED] | Owner:
Type: feature request| Status: new
Priority: normal | Milestone:
Component: Compiler |Version: 6.4.1
Severity: normal | Resolution:
Keywords: dependency generation | Os: Linux
Difficulty: Easy (1 hr)| Architecture: Unknown
+--
- Comment (by simonmar):
Then I have another trick for you:
{{{
ghc --make -pgml echo Main.hs -v0 | ghc -e 'interact (unwords . filter
(.o `Data.List.isSuffixOf`) . words)'
}}}
Does this solve the problem?
Yes! I have no idea what's going on, though.
-pgml echo uses echo as the linker program, so the linker command line is
sent to stdout, then we pipe it through something that extracts the object
filenames - I used ghc -e, but you could use sed or perl or something else. The
version I gave above doesn't work properly if the filenames contain spaces.
However, it triggers another problem, which I haven't reported. When
calling ghc -M src/prog.hs, where prog.hs is the main module, then the
name of the object file is reported as src/prog.o. When calling it in
conjunction with -odir, such as ghc -M -odir build src/prog.hs, then you
get build/Main.o. Of course this can't be used, because all of the
programs' main modules become build/Main.o.
This isn't a bug, it's the defined behaviour of -odir. See the documentation:
http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#output-files
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Threading woes on FreeBSD
Gregory Wright wrote: Some additional information on the threading problems experienced on FreeBSD. The system was FreeBSD 6.1-RELEASE-p2, dual 2.8 GHz Xeon. I built ghc-6.4.2 from cvs using the FreeBSD ports version of ghc-6.4.2. (The latter has the threaded RTS disabled.) I ran the ghc-regress tests on the built compiler. I used the libmap.conf (5) method to change the threading library from pthreads to libthr and libc_r. The build from cvs uses pthreads by default. The compiler using pthreads had 47 unexpected failures, and accumulated about 30 timeout processes, which were just burning cpu cycles. Using the reentrant c library (libc_r) gave essentially the same result, with a tens of timeout processes consuming cpu but apparently doing nothing else. When I used the 1:1 threading library (libthr) the testing process ground to a halt, with just one timeout process consuming about 95 percent of the cpu. I kill the test, since it had not made significant progress in about 5 hours. That's a useful data point, we know that just switching to -lthr or -lc_r will not fix this. I'm going to set aside working on the FreeBSD threading question and concentrate on threaded runtime problem on OS X. I had originally hoped that they would show similar behavior, but that seems to not be the case. No problem, I'm on the trail of the FreeBSD problem (on your box :-). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug in users manual, 6.4.2, section on pattern guards
Matthew Cox wrote: One example given in this discussion is: clunky env var1 var1 = case lookup env var1 of Nothing - fail Just val1 - case lookup env var2 of Nothing - fail Just val2 - val1 + val2 where fail = val1 + val2 this needs to be fixed to: clunky env var1 var1 = case lookup env var1 of Nothing - fail Just val1 - case lookup env var2 of Nothing - fail Just val2 - val1 + val2 where fail = var1 + var2(Added for emphasis) I didn't see it myself on the first readthrough, but I was comparing structure between two examples and noticed the discrepency. Let's fix it for correctness' sake. fixed; thanks. Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug in GHC 6.4.1 and 6.4.2
Fritz Henglein wrote: According to a message from GHCi, version 6.4.1 (see below; bug also reproduceable with 6.4.2, though not shown here since it consistently resulted in a core dump without prior message) under Windows XP (fully updated per 2006-07-15), I am herewith reporting what appears to be a bug in GHC. Please see transcript below; the source file in question is included as an attachment. (Lacking both efficient Haskell programming skills and an understanding of the internals of GHC I have refrained from attempting to isolate the bug by reducing the code.) Should there be a simple work-around or something unsafe in my code (though I wouldn't know what: no unsafe operations are used; no polymorphism is present), I would greatly appreciate hearing about it. Thanks, good bug. The problem was: index (minBound::Int16,maxBound) maxBound -1 ie. index for Int16 should have converted to Int *before* doing the subtraction. This is related to another problem (that I think we have a ticket for), namely that the type of index precludes having really large arrays: index :: Ix i = (i,i) - i - Int if the index must fit in an Int, then GHC can't cope with arrays with more than 2^31 elements (on a 32-bit machine), and in general Haskell doesn't allow arrays with more than 2^29 elements. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Missing haddock documentation
Neil Mitchell wrote: 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. Seems to work ok for now... maybe a transient problem? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #738: ghc can't load files with selinux Enforcing
Jens Petersen wrote: Perhaps someone who knows SELinux would like to describe how to set up an exception for GHC so we can put it in the FAQ? I have added: /usr/bin/chcon -t unconfined_execmem_exec_t /path/to/binary/prog to the %post install scripts of the darcs and haddock packages in Fedora Extras for now, and will do the same for the ghc package (it needs it for more programs). This avoids having to set allow_execmem system wide. I just wonder if the ghc case is harder since programs compiled by ghc using the rts need exceptions too not just ghc itself. Of course if the RTS was a shared library on Linux, then probably just its .so file would need to have execmem context set. I have added this information to the FAQ, thanks. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: arithmetic sequences and the prelude: minor problems?
Laszlo Nemeth wrote: Incidentally, [1..5] is accepted (no space between 1 and the dots), while [False..True] is not (no spaces after False), which appears to be a parsing inconsistency. It's a bug, but a known one (we have a test in the test suite for it). Hugs has the same bug, so at least there's some consistency across implementations. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: unexpected arithmetic sequence and deriving Enum behaviour
Hi Laszlo, Laszlo Nemeth wrote: Consider the following code fragment: data Colour = Red | Black | Blue deriving (Show, Bounded) instance Enum Colour where succ Red = Black succ Black = Blue succ Blue = error succ of maxBound fromEnum Red = 1 fromEnum Black = 2 fromEnum Blue = 3 toEnum 1 = Red toEnum 2 = Black toEnum 3 = Blue toEnum n = error (? ++show n) main = do print $ [Red ..] Notice that there is no deriving Enum (which would be an error according to the Report) Why do you say that? Can you give a pointer to the relevant text in the report? I can't see anything wrong here. The minimal complete instance of Enum consists of toEnum and fromEnum, which yours does. and there is no definition for 'enumFrom'. So, in the first place I'd expect a warning for main for the use of the arithmetic sequence, something about a missing definition. There isn't one, and the program compiles. Interestingly, -ddump-deriv doesn't show anything about deriving instances for Colour, yet, obviously something gets derived. When you run it, it dies with an error message from 'toEnum n' (or non-exhaustive pattern if you leave that one out). Looking at core reveals the reason for this: [ core snipped ] The max bound which gets used is the one for Int, not for Colour! This is because, as per the report, GHC defines the default method for enumFrom as: enumFrom x = map toEnum [fromEnum x ..] the sequence on the RHS is at type Int, and hence doesn't terminate until it reaches maxBound::Int. Perhaps you expect that, because your type is also an instance of Bounded, that enumFrom should behave differently. However, there can only be one default method for enumFrom. Perhaps this isn't a bug, but definitely an undocumented and rather unexpected 'feature'. This is with ghc-6.4 onwards, and I haven't checked earlier versions. You're right, I don't think it's a bug. Also, if you had derived Enum instead of defining it, you would have got a version that behaved in the expected way. You defined an instance of Enum yourself, and got exactly what you asked for! Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ASSERTION FAILED: file GC.c, line 1352
Joachim Breitner wrote: I have created a small app here, using gtk and hsql, and I sometimes get crashes with this debug message: internal error: ASSERTION FAILED: file GC.c, line 1352 What information do you need to further debug this, or what can I do myself to find the problem? We normally need a reproducible test case, which means we'll need the code for your example, together with all relevant information: versions of everything (GHC, gcc, GTK, HSQL, etc.), and what platform you're using. It's best if you can put all this information into a new ticket in the bug tracker: http://hackage.haskell.org/trac/ghc/. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc 6.4.1 failed to build on IRIX64 6.5.29
Andrew Jones wrote: /tmp/ghc363448.lpp:0: internal compiler error: Abort Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. ghc: 165577416 bytes, 35 GCs, 565100/969672 avg/max bytes residency (2 samples), 17M in use, 0.02 INIT (0.00 elapsed), 6.26 MUT (19.68 elapsed), 0.29 GC (0.41 elapsed) :ghc gmake[2]: *** [depend] Error 1 gmake[1]: *** [boot] Error 1 gmake[1]: Leaving directory `/disk2/src/ghc-6.4.1/ghc' gmake: *** [build] Error 1 [EMAIL PROTECTED] This one appears to be a crash in gcc, not much we can do about that I'm afraid. Try a different version of gcc. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC 6.2.2 and 6.4.1 on IRIX64 both failed, this time with new error
Andrew Jones wrote: This is the failed 6.4.1 build, but when using 3.4.6 instead of 3.4.0, both 6.2.2 and 6.4.1 fail this way. [EMAIL PROTECTED] --version gcc (GCC) 3.4.6 [EMAIL PROTECTED] -aR IRIX64 godot 6.5 6.5.29f 01090133 IP27 [EMAIL PROTECTED] --version The Glorious Glasgow Haskell Compilation System, version 6.2 ==fptools== gmake all -wr; in /disk2/src/ghc-6.4.1/ghc/rts ../../ghc/compiler/ghc-inplace -L/usr/freeware/lib64 -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o Cmm lint error: in proc stg_ap_0_ret in basic block c2 in assignment: R1 = I32[R1 + 8 + 0]; This looks like an inconsistency in bit widths somewhere: GHC thinks the width of a word is 64, but soemthing else thinks its 32 bits. I suspect ghc/includes/DerivedConstants.h doesn't agree with ghc/includes/ghcautoconf.h. Perhaps you're not passing -mabi when compiling ghc/includes/mkDerivedConstants.h? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #738: ghc can't load files with selinux Enforcing
Jens Petersen wrote: Jon Fairbairn wrote: Fixed in the HEAD and the 6.4 branch, but I haven't been able to test (don't have SE Linux on a local machine). Please download a snapshot and try it out, if possible. That does seem to mend it for me. Note that my report says it only seems to happen x86_64 while in fact the fault /is/ present on x86 in 6.4.1 I don't see it with i386 FC5 with ghc-6.4.2, but I received a report on it for x86_64 FC5 when selinux is enforcing. Today I tried ghc-6.4.2.20060619-x86_64-unknown-linux on x86_64 FC6test1 with enforcing selinux however and still get: ghc: internal error: getMBlock: mmap: Permission denied from the rts. (setsebool allow_execmem 1 works around it.) My fix works around allow_execheap being set to 0, but not allow_execmem. This page describes how to work around allow_execmem: http://people.redhat.com/drepper/selinux-mem.html But I really object to having to go to such lengths just to work around an overly restrictive security policy. GHC really does do runtime code generation, so it really does need some writable/executable memory. Perhaps someone who knows SELinux would like to describe how to set up an exception for GHC so we can put it in the FAQ? How do things like Mono work on an SELinux system, do they have a policy exception set up? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #729: Build system uses wrong version of include files.
Can anyone comment further on this bug? I've forgotten who the
submitter is, and we need more information.
From the description, it looks like the installed version of HsUnix.h
is being used while compiling the compiler, which is correct for the stage1
compiler, but would be wrong for stage2. Which stage is this?
Cheers,
Simon
GHC wrote:
#729: Build system uses wrong version of include files.
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Build System |Version: 6.4.1
Severity: normal| Resolution:
Keywords:| Os: MacOS X
Difficulty: Unknown | Architecture: powerpc
---+
Old description:
The situation: I am building 6.4.1 using 6.4.1. The installed version was
by a package installer. Now I want to build a source myself, since I want
to see if I can change some things. After the usual stuff and doing make
I obtain this error message:
utils/PrimPacked.lhs:263:0:
Warning: foreign declaration uses deprecated non-standard syntax
In file included from /tmp/ghc25249.hc:5:
/usr/local/lib/ghc-6.4.1/include/HsUnix.h: In function
'__hsunix_rtldNext':
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: 'RTLD_NEXT'
undeclared (first use in this function)
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: (Each undeclared
identifier is reported only once
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: for each function
it appears in.)
/usr/local/lib/ghc-6.4.1/include/HsUnix.h: In function
'__hsunix_rtldDefault':
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:107: error: 'RTLD_DEFAULT'
undeclared (first use in this function)
ghc: 50080464 bytes, 11 GCs, 1535164/2972296 avg/max bytes residency (2
samples), 19M in use, 0.13 INIT (0.00 elapsed), 0.51 MUT (1.45 elapsed),
0.28 GC (0.36 elapsed) :ghc
make[2]: *** [stage1/utils/PrimPacked.o] Error 1
make[1]: *** [all] Error 1
make: *** [build] Error 1
Having looked at it for a while and discussing the problem with Arthur
van Leeuwen,
we decided that the problem is that the build system uses the HsUnix.h
file of the
existing distribution, and not the one from the sources. The problem
arises because
these two files are different.
New description:
The situation: I am building 6.4.1 using 6.4.1. The installed version was
by a package installer. Now I want to build a source myself, since I want
to see if I can change some things. After the usual stuff and doing make I
obtain this error message:
{{{
utils/PrimPacked.lhs:263:0:
Warning: foreign declaration uses deprecated non-standard syntax
In file included from /tmp/ghc25249.hc:5:
/usr/local/lib/ghc-6.4.1/include/HsUnix.h: In function
'__hsunix_rtldNext':
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: 'RTLD_NEXT'
undeclared (first use in this function)
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: (Each undeclared
identifier is reported only once
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: for each function it
appears in.)
/usr/local/lib/ghc-6.4.1/include/HsUnix.h: In function
'__hsunix_rtldDefault':
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:107: error: 'RTLD_DEFAULT'
undeclared (first use in this function)
ghc: 50080464 bytes, 11 GCs, 1535164/2972296 avg/max bytes residency (2
samples), 19M in use, 0.13 INIT (0.00 elapsed), 0.51 MUT (1.45 elapsed),
0.28 GC (0.36 elapsed) :ghc
make[2]: *** [stage1/utils/PrimPacked.o] Error 1
make[1]: *** [all] Error 1
make: *** [build] Error 1
}}}
Having looked at it for a while and discussing the problem with Arthur van
Leeuwen,
we decided that the problem is that the build system uses the HsUnix.h
file of the
existing distribution, and not the one from the sources. The problem
arises because
these two files are different.
___
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: lack of automatic recompilation after library updating
Bulat Ziganshin wrote: i just reinstalled FPS library with new version downloaded via darcs (both old and new versions are 0.7, difference is few days only) i run the following to update lib: runghc Setup.hs unregister runghc Setup.hs clean runghc Setup.hs build runghc Setup.hs install and then i try to rebuild my app. it does not feels that FPS library was updated and don't recompiled modules that use it. can this be considered as bug? ghc 6.4.2/windows If I understand your description correctly, this is by design. GHC doesn't track version dependencies (in the .hi version sense) across package boundaries, which means that if you update a package then code that uses the package will not be automatically rebuilt by GHC. One reason for this was to reduce the amount of clutter in .hi files and speed up compilation. Package modules are assumed to be pre-built and static, that's all. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: One-character bug in time library
wld wrote: Sorry ;) On 6/5/06, wld [EMAIL PROTECTED] wrote: Hi, File package.conf.in (darcs GHC HEAD) contains the following line: hs-libraries: HSTime This should be of course hs-libraries: HSTime Certainly, hs-libraries: HStime Fixed, thanks. Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #738: ghc can't load files with selinux Enforcing
Jon Fairbairn wrote: On Wed, 31 May 2006 14:15:26 - you wrote: #738: ghc can't load files with selinux Enforcing ---+ Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: closed Priority: normal |Milestone: 6.4.3 Component: Runtime System | Version: 6.4.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Architecture: x86_64 (amd64) | Os: Linux ---+ Changes (by simonmar): * resolution: = fixed * status: new = closed Comment: Fixed in the HEAD and the 6.4 branch, but I haven't been able to test (don't have SE Linux on a local machine). Please download a snapshot and try it out, if possible. That does seem to mend it for me. Note that my report says it only seems to happen x86_64 while in fact the fault /is/ present on x86 in 6.4.1 Great, thanks Jon. Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Christian Maeder wrote: Christian Maeder wrote: Ok, I'm recompiling Now compilation (from cvs of yesterday) failed at: /local/home/maeder/ghc-6.4.3-pre/ghc/rts/libHSrts_thr.a(Storage.thr_o): In function `allocateExec': Storage.c:(.text+0xc58): undefined reference to `getPageSize' Storage.c:(.text+0xcb4): undefined reference to `setExecutable' /local/home/maeder/ghc-6.4.3-pre/ghc/rts/libHSrts_thr.a(Storage.thr_o): In function `freeExec': Storage.c:(.text+0xdcc): undefined reference to `setExecutable' collect2: ld returned 1 exit status ghc: 14233900 bytes, 3 GCs, 164960/164960 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.13 MUT (10.53 elapsed), 0.03 GC (0.05 elapsed) :ghc gmake[2]: *** [stage2/ghc-6.4.2] Error 1 gmake[2]: Leaving directory `/local/home/maeder/ghc-6.4.3-pre/ghc/compiler' gmake[1]: *** [stage2] Error 2 gmake[1]: Leaving directory `/local/home/maeder/ghc-6.4.3-pre' gmake: *** [bootstrap2] Error 2 Looks like the file OSMem.o is missing from your RTS build somehow. It should be in ghc/rts/posix. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: 6.4.2 under solaris
On 01 June 2006 11:26, Christian Maeder wrote: I've recompiled ghc-6.4.2 from cvs again without -threaded. The regression test looks much better now (below). Do you know if the stage2 compiler works with -threaded? Or does it still crash? The conc-cases go through now, but the following problems do still exist: cc04 (and ffi012) reported: 'calling convention not supported on this architecture: stdcall' ffi004 (arr016, ffi009 and maessen-hashtab) produced 'Segmentation Fault' with Wrong exit code (expected 0 , actual 139 ) That needs to be investigated. Let me know if you want to see the whole log. I've circumvented the too few arguments to function 'ctime_r'-problem now by simply deleting ctime_r from the configure file. Ok, but that doesn't help me find a fix. Any chance you could investigate why my fix didn't work? It apparently worked on the machine I tried it on, but I think that was Solaris 9. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Christian Maeder wrote: Christian Maeder wrote: Well. at least Florenz reported independently the same ctime_r problem under Solaris 10 in http://hackage.haskell.org/trac/ghc/ticket/775 Ok, he used the original 6.4.2 sources that did not have your fix. What file was supposed to fix the problem? Ach, my fault. Somehow I forgot to merge that fix into the 6.4 branch. Sorry :-( It should be there now. The file RtsUtils.c has changed. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug with Char.isAlpha
Michael Nagel wrote: I am using the precompiled windows version of ghc-6.4.2 and for some reason Prelude Char.isAlpha '§' returns true. Hugs however, is of the opinion that the paragraph sign is not an alphabetic character and so am I. I did not find any rationale for this behavior (as no system I know of treats the §-sign as an alphabetic char) so I think it is a bug and should be fixed. Regards, Michael PS: I have not been using ghc(i) for too long, so if I missed something, please let me know. This looks like some kind of input problem: I get the same results as you when using a Windows command shell, but not when using an xterm or on Unix. The problem is better illustrated like this: Prelude '§' '\245' but '\245' is not the § character, it is the õ character. So the command shell has done some translation before GHCi even saw the character. On Un*x, or in an xterm on Windows, I get Prelude '§' '\167' I claim this is not our bug. If anyone knows a workaround or can explain why this happens, please let us know. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: compiling from source - error
If this error is not repeatable, then it is likely a hardware glitch. If it is repeatable, can you give us more information: - what platform is this? - where did you get your 6.4.1 distribution? Cheers, Simon Johan Meskens CS3 jmcs3 wrote: ==fptools== make all - --no-print-directory -r; in /home/jmcs3/Desktop/ghc-6.4.2.20060524/ghc/utils/hsc2hs /usr/bin/ghc -H16m -O -i../../lib/compat -ignore-package Cabal -Rghc-timing -Wal l-c Main.hs -o Main.o -ohi Main.hi Main.hs:887:0: Warning: Defined but not used: `unDosifyPath' ghc-6.4.1: internal error: scavenge: unimplemented/strange closure type 30091 @ 0x4229afa0 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ make[3]: *** [Main.o] Error 254 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/jmcs3/Desktop/ghc-6.4.2.20060524/ghc' make: *** [build] Error 1 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Visual Haskell
James Chaffee wrote: I downloaded the installer package for Visual Haskell and attempted to install it. I have Visual Studio 2005. The install went to a point where it said a script was missing and then proceeded to uninstall itself. I would very much like to install the package? Is there something I can do. Sorry, the current Visual Haskell distribution doesn't work with VS 2005. We hope to release an updated installer at some point. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
Christian Maeder wrote: Christian Maeder wrote: using Rev. 1.1.2.3 of timeout.hs I could run the testsuite until conc020 which did then sleep with truss repeatedly outputting: I ran the testsuite now with ghc-6.4.1. The results are attached at http://hackage.haskell.org/trac/ghc/ticket/752 First of all I had to add optl-lrt to ghc-6.4.1 in order to be able to link the threaded cases to aboid undefined reference to `sched_yield' in OSThreads.c:(.text+0x90) Is -threaded the cause for the ghc-6.4.2 problems under solaris? conc020(threaded) seg-faulted with ghc-6.4.1 (while being treated with truss) Oh, I just noticed: simplrun004(opt) did not terminate yet: PID USERNAME THR PRI NICE SIZE RES STATE TIMECPU COMMAND 26436 maeder 1 00 4520K 3032K run 575:29 75.33% simplrun004 truss -p 26436 shows: Received signal #28, SIGVTALRM [caught] lwp_sigmask(SIG_SETMASK, 0x0800, 0x) = 0xFFBFFEFF [0x] setcontext(0xFFBFD280) lwp_sigmask(SIG_SETMASK, 0x, 0x) = 0xFFBFFEFF [0x] lwp_sigmask(SIG_SETMASK, 0x, 0x) = 0xFFBFFEFF [0x] lwp_sigmask(SIG_SETMASK, 0x, 0x) = 0xFFBFFEFF [0x] lwp_sigmask(SIG_SETMASK, 0x, 0x) = 0xFFBFFEFF [0x] Received signal #28, SIGVTALRM [caught] I've fixed the cause of the hangs on Solaris, I believe. Also, the ctime_r() and -lrt problems are both fixed. If you grab the ghc-6-4-branch from CVS you'll get the code with these fixes. I'd be interested to know if it works for you, and if you could do a testsuite run too that would be great. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: More on the OS X crashes
Thanks Greg. Wolfgang Thaller has promised to take a look at this, but I think he's quite busy at the moment. Cheers, Simon Gregory Wright wrote: Hi, I've built a compiler with debugging turned on and have obtained what might be useful information about the crashes on OS X. When I try to do a build, in this case, of NewBinary, I get --- Configuring hs-NewBinary DEBUG: Executing proc-pre-com.apple.configure-configure-0 ghc-6.4.2: internal error: ASSERTION FAILED: file GC.c, line 4356 Please report this as a compiler bug. See: http://www.haskell.org/ghc/reportabug Error: Target com.apple.configure returned: shell command ghc -lintl -o Setup Setup.lhs -package Cabal returned error 254 Command output: ghc-6.4.2: internal error: ASSERTION FAILED: file GC.c, line 4356 (The ghc output lines are bracketed by some darwinports status info.) I've seen the same assertion failure in other cases, but it is not entirely repeatable. Smells like something is not initialized or aligned correctly. (I even got this error from compiling main = putStrLn Hello, World! but that hasn't happened again since I built ghc over.) And for some reason when I build ghc on OS X with debugging turned on, I need to explicit link in -lintl or I miss a symbol that libbfd or libiberty is looking for. But that is probably neither here nor there. The assertion being violated is ASSERT(frame bottom); and it's not surprising that things rapidly go pear shaped if this isn't true. Any ideas on how to proceed? Just as a test, I built a compiler using GC.c from 6.4.1 but it quickly segfaulted. I just had a hope that the significant changes may have been local to the GC.c file. This is evidently not the case. Best Wishes, Greg ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
