[ ghc-Bugs-1228084 ] OpenAL needs -pthread
Bugs item #1228084, was opened at 2005-06-27 10:04 Message generated for change (Comment added) made by spanne You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1228084group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries (other) Group: None Status: Closed Resolution: None Priority: 3 Private: No Submitted By: Volker Stolz (volkersf) Assigned to: Sven Panne (spanne) Summary: OpenAL needs -pthread Initial Comment: On FreeBSD (and maybe NetBSD as well), OpenAL needs -pthread in CFLAGS/LDFLAGS: configure:2352: gcc -o conftest -I/usr/local/include -L/usr/local/lib conftest.c -lopenal 5 /usr/local/lib/libopenal.so: undefined reference to `pthread_create' /usr/local/lib/libopenal.so: undefined reference to `pthread_attr_init' /usr/local/lib/libopenal.so: undefined reference to `pthread_exit' This should best be solved during configure instead of setting this globally. Also, this probably needs to be propagated into OpenAL. cabal for linking a resulting application (although already the RTS should pull in -pthread). -- Comment By: Sven Panne (spanne) Date: 2008-11-06 09:38 Message: This bug tracker isn't used anymore, and I'm quite sure that I've fixed this bug a long time ago. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1228084group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1353257 ] Problem with Threading under GHC
Bugs item #1353257, was opened at 2005-11-10 16:12 Message generated for change (Comment added) made by schachblocki You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1353257group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GHCi Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marco Block (schachblocki) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with Threading under GHC Initial Comment: hi ghc-friends, i try the following code, but it don't work: import System.Process import Control.Concurrent import System.IO p = threadDelay 1000 main3 = do putStrLn test hClose stdin (inp, out, err, pid) - runInteractiveProcess Test.exe [] Nothing Nothing p forkIO (putStrLn = hGetContents out) forkIO (putStrLn = hGetContents err) p putStrLn inp forkIO (hPutStrLn inp in hClose inp) p forkIO (putStrLn = hGetContents out) forkIO (putStrLn = hGetContents err) putStrLn out threadDelay 100 forkIO (hPutStrLn inp quit hClose inp) hShow out return () thanks for helping. -- Comment By: Marco Block (schachblocki) Date: 2005-12-21 13:55 Message: Logged In: YES user_id=1376599 Sorry ... we working on so many problems and now it's time for the GHC-Answer :). Ok, we have one executable program we wants to start and after the start we give him one parameter which is a string. The executable file is a chess engine. Communication is like: e2e4 then we waiting for response ... and the engine sais: c7c5 this is our thread. But the code doesn't work. The engine was started but not the communication. thanks alot. -- Comment By: Simon Marlow (simonmar) Date: 2005-11-10 16:59 Message: Logged In: YES user_id=48280 Please could you give more information: we don't know what Test.exe is. What do you expect to happen, and what in fact does happen? What behaviour are you claiming is at fault? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1353257group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1373474 ] Retainer and biographical profiling with STM
Bugs item #1373474, was opened at 2005-12-05 11:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1373474group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Runtime System Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Simon Marlow (simonmar) Assigned to: Simon Marlow (simonmar) Summary: Retainer and biographical profiling with STM Initial Comment: Retainer profiling (-hr) and biographical profiling (-hb) do not currently work with STM, they result in errors like this: internal error: Invalid object in isRetainer(): 67 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1373474group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1370370 ] panic! 'impossible' happened, thread blocked indefinitely
Bugs item #1370370, was opened at 2005-11-30 21:04 Message generated for change (Comment added) made by kgrapone You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1370370group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GHCi Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: panic! 'impossible' happened, thread blocked indefinitely Initial Comment: GHCi, version 6.4.1, crashed with the following error: ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1): thread blocked indefinitely Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. I was calling a test function which was forking a Thread which was blocking in an 'atomically' waiting on a TChan. If I ran the test function a second time, while the Thread from the first run is presumably still hanging around, I would receive the above error/crash. If I reloaded the source in GHCi after running the test function a single time GHCi would give an error message (but not crash): *** Exception: thread blocked indefinitely Most of the time after the error message there would be no modules loaded. I could load again, and repeat the fun. _Very_ occasionaly the modules would remain loaded and I could repeat the cycle without having to reload the modules. Since fixing my test function so the forked Thread dies at the desired time (ie now it won't be hanging around blocked on the TChan) I haven't observed the failure. My email: [EMAIL PROTECTED] -- Comment By: kgrapone (kgrapone) Date: 2005-12-05 22:21 Message: Logged In: YES user_id=1397718 Following is a minimal(ish) test case. It behaves a little differently from the original, seems to be some timing issues involved. Running runTest badLoop multiple times will eventually kill GHCi. Interleaving with runTest goodLoop will sometimes get you the other effects I mentioned above. --BEGIN CODE-- module Test where import Control.Concurrent.STM import Control.Concurrent import Control.Exception import Prelude hiding (catch) runTest loop = do (tc1, tc2, tmv) - atomically (do tmv - newEmptyTMVar tc1 - newTChan tc2 - newTChan return (tc1, tc2, tmv) ) myTId - myThreadId forkIO (forked loop (tc1, tc2, tmv, myTId)) atomically (writeTChan tc1 blah) atomically (writeTChan tc1 blah2) return done forked loop args@(tc1, tc2, tmv, hisTId) = catch ((loop args) = setTMV . Just) hndlr `finally` setTMV Nothing where setTMV x = atomically (tryPutTMVar tmv x return ()) hndlr (AsyncException ThreadKilled) = return () hndlr e = throwTo hisTId e goodLoop args@(tc1, tc2, tmv, hisTId) = do x - atomically (readTChan tc1) x' - return $ reverse x atomically (writeTChan tc2 x') if x == blah2 then return () else goodLoop args badLoop args@(tc1, tc2, tmv, hisTId) = do x - atomically (readTChan tc1) x' - return $ reverse x atomically (writeTChan tc2 x') badLoop args --END CODE-- -- Comment By: Simon Marlow (simonmar) Date: 2005-12-02 09:32 Message: Logged In: YES user_id=48280 Please can you supply code to reproduce the bug. This might be the same bug as #1274506. -- Comment By: Nobody/Anonymous (nobody) Date: 2005-11-30 21:10 Message: Logged In: NO Oh, yeah: Running a 32bit Linux 2.6 kernel -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1370370group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1075259 ] Wrong overlapped/missing pattern warnings
Bugs item #1075259, was opened at 2004-11-29 14:00
Message generated for change (Comment added) made by simonpj
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1075259group_id=8032
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Compiler (Parser)
Group: 6.2.2
Status: Open
Resolution: None
Priority: 2
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong overlapped/missing pattern warnings
Initial Comment:
compiling:
module Overlap where
f (n+1) = 2
f 0 = 1
emits wrongly:
Warning: Pattern match(es) are overlapped
In the definition of `f': f 0 = ...
The Patterns are disjoint, aren't they? At least f 0
yields 1 when evaluated and negative inputs for f are
rejected. However the warning is not emitted if the two
equations are given in reversed order.
Christian ([EMAIL PROTECTED])
--
Comment By: Simon Peyton Jones (simonpj)
Date: 2005-12-02 09:12
Message:
Logged In: YES
user_id=50165
Another example from Neil Mitchell
I have been playing around with -fwarn-incomplete-patterns
under GHC
6.4.1 on Windows.
-- no warning
ex1 x = ss
where (s:ss) = x
-- no warning
ex2 x = let (s:ss) = x in ss
--Warning: Pattern match(es) are non-exhaustive
-- In a case alternative: Patterns not matched:
[]
ex3 x = case x of ~(s:ss) - ss
I have translated all 3 functions using the rules supplied
in the Haskell 98 report, so they all have the same
meaning, but only one gives an error. Is it intentional to
ignore where/let pattern matches?
--
Comment By: Simon Peyton Jones (simonpj)
Date: 2004-12-13 09:49
Message:
Logged In: YES
user_id=50165
Here's another example, from Peter White
When I compile the following module with the -Wall option on
ghc v6.2.1
I get warnings:
Warning: Pattern match(es) are non-exhaustive
In a record-update construct: Patterns not matched D2.
The warnings occur at both of the indicated places in the
module.
Since the functions both handle all the cases of the data
type D, it
seems the warning should not be given.
data D = D1 { f1 :: Int } | D2
-- Use pattern matching in the argument
f :: D - D
f d1@(D1 {f1 = n}) = d1 { f1 = f1 d1 + 1 } -- Warning here
f d = d
-- Use case pattern matching
g :: D - D
g d1 = case d1 of
D1 { f1 = n } - d1 { f1 = n + 1 } -- Warning here
also
D2- d1
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1075259group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1274506 ] GHCi doesn't run computations in a new thread
Bugs item #1274506, was opened at 2005-08-27 08:29 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1274506group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GHCi Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Don Stewart (dons) Assigned to: Nobody/Anonymous (nobody) Summary: GHCi doesn't run computations in a new thread Initial Comment: A broken QuickCheck property cause ghci to panic after reloading the module. Seen in stable and head branch. paprika$ ghci T.hs *Main do_test test : * (0) *Main :reload ghc-6.5: panic! (the `impossible' happened, GHC version 6.5): loop Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. Changing the property to check for empty lists causes the test to pass, and reload to work fine. -- Don Stewart -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-08-30 12:25 Message: Logged In: YES user_id=50165 Test.Quickcheck.Batch.run forks a watcher thread that sends a NonTermination exception to the parent; the idea is to time-out tests that run too long. The parent kills the watcher when the test completes. Sadly, the parent doesn't kill the watcher when the test itself throws an exception. So, two problems: 1. The run in QuickCheck.Batch is wrong and should be fixed. I'm not sure who wrote it. 2. GHCi itself can be killed by a thread spawned by an evaluation started by GHCi. That's really a bug; but I'm not sure about the best way to fix it. I'm going to leave this until Simon gets back from paternity leave! Simon -- Comment By: Don Stewart (dons) Date: 2005-08-27 08:32 Message: Logged In: YES user_id=880987 Here's the test case, since uploading files is annoying in sourceforge: import Test.QuickCheck.Batch prop_silly :: [()] - Bool prop_silly xs = head xs == head xs do_test = runTests test defOpt [ run prop_silly ] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1274506group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1370370 ] panic! 'impossible' happened, thread blocked indefinitely
Bugs item #1370370, was opened at 2005-11-30 21:04 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1370370group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GHCi Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: panic! 'impossible' happened, thread blocked indefinitely Initial Comment: GHCi, version 6.4.1, crashed with the following error: ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1): thread blocked indefinitely Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. I was calling a test function which was forking a Thread which was blocking in an 'atomically' waiting on a TChan. If I ran the test function a second time, while the Thread from the first run is presumably still hanging around, I would receive the above error/crash. If I reloaded the source in GHCi after running the test function a single time GHCi would give an error message (but not crash): *** Exception: thread blocked indefinitely Most of the time after the error message there would be no modules loaded. I could load again, and repeat the fun. _Very_ occasionaly the modules would remain loaded and I could repeat the cycle without having to reload the modules. Since fixing my test function so the forked Thread dies at the desired time (ie now it won't be hanging around blocked on the TChan) I haven't observed the failure. My email: [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2005-12-02 09:32 Message: Logged In: YES user_id=48280 Please can you supply code to reproduce the bug. This might be the same bug as #1274506. -- Comment By: Nobody/Anonymous (nobody) Date: 2005-11-30 21:10 Message: Logged In: NO Oh, yeah: Running a 32bit Linux 2.6 kernel -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1370370group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1194392 ] internal error in GHC
Bugs item #1194392, was opened at 2005-05-03 04:49 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1194392group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Simon Marlow (simonmar) Summary: internal error in GHC Initial Comment: http://bugs.darcs.net//Ticket/Display.html?id=339 -- Comment By: Nobody/Anonymous (nobody) Date: 2005-12-02 08:03 Message: Logged In: NO Likely the same bug as: http://sourceforge.net/tracker/index.php?func=detailaid=1194393group_id=8032atid=108032 -- Comment By: Zooko O'Whielacronx (zooko) Date: 2005-11-28 07:52 Message: Logged In: YES user_id=52562 Hooray! A repeatable test case has been found! http://bugs.darcs.net/issue8 -- Comment By: Simon Marlow (simonmar) Date: 2005-09-23 03:19 Message: Logged In: YES user_id=48280 Without a repeatable test case, there's nothing we can do with this bug report, sorry. If it reappears, feel free to post more information and we can re-open the bug. -- Comment By: Zooko O'Whielacronx (zooko) Date: 2005-06-10 08:00 Message: Logged In: YES user_id=52562 For what it is worth, I haven't gotten any of these errors since I stopped trying to use darcs on lots of large binary patches containing 100's of MB per patch. So I suspect the bug is triggered by certain memory usage patterns... -- Comment By: Simon Marlow (simonmar) Date: 2005-05-03 08:10 Message: Logged In: YES user_id=48280 We need a repro case: a darcs repository from which to pull, and the sources to the darcs version that exhibits the error. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1194392group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1370875 ] panic! impossible happened: ds_app_type
Bugs item #1370875, was opened at 2005-12-01 13:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1370875group_id=8032
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jose Emilio Labra Gayo (labra)
Assigned to: Nobody/Anonymous (nobody)
Summary: panic! impossible happened: ds_app_type
Initial Comment:
When I try to compile:
class G a where
f :: G a
I obtain:
ghc.exe: panic! (the `impossible' happened, GHC version
6.4): ds_app_type Prueba.G{tc r1Yg} [a{tv a1Yq}]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1370875group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1370885 ] object code blow up by minor source code change
Bugs item #1370885, was opened at 2005-12-01 14:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1370885group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: C Maeder (c_maeder) Assigned to: Nobody/Anonymous (nobody) Summary: object code blow up by minor source code change Initial Comment: If you unpack the archive and compile the files with optimization by: time ghc -no-recomp --make -O HasCASL/hacapa.hs This takes about 5 minutes and generates an unstripped binary of 4MB. Apply the (little) patch for HugesPJ.hs -- the one I've sent before and that is included as patch in the top-level directory. Our (slightly modified) copy of HughesPJ.hs is Common/Lib/Pretty.hs: patch -p0 Common/Lib/Pretty.hs patch Now compilation takes 7 minutes and the binary gets size 6 MB. Particularly the file HasCASL/PrintLe.o has grown from 90 KB to 2 MB. (Compiling HasCASL/PrintLe.hs takes visibly longer, too) (Patching can be reversed by: patch -p0 -R Common/Lib/Pretty.hs patch ) This blow-up of object code caused a link failure on our mac for a final (stripped) binary that should have a size of around 36 MB. (The link failure on macs is another issue that may need attention in the future.) The data below is obtained with ghc-6.4.1 under linux. Cheers Christian [EMAIL PROTECTED]:~/haskell/examples uname -a Linux turing 2.6.11.4-21.9-default #1 Fri Aug 19 11:58:59 UTC 2005 i686 i686 i386 GNU/Linux [EMAIL PROTECTED]:~/haskell/examples ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4.1 [EMAIL PROTECTED]:~/haskell/examples gcc --version gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) Copyright (C) 2003 Free Software Foundation, Inc. [...] [EMAIL PROTECTED]:~/haskell/examples time ghc -no-recomp --make -O HasCASL/hacapa.hs Chasing modules from: HasCASL/hacapa.hs Compiling Common.Lib.State ( ./Common/Lib/State.hs, ./Common/Lib/State.o ) [...] Compiling Main ( HasCASL/hacapa.hs, HasCASL/hacapa.o ) Linking ... real6m0.739s user5m42.199s sys 0m9.590s [EMAIL PROTECTED]:~/haskell/examples ll a.out HasCASL/PrintLe.o -rwxr-xr-x 1 maeder wimi 4674747 2005-12-01 14:17 a.out -rw-r--r-- 1 maeder wimi 90308 2005-12-01 14:14 HasCASL/PrintLe.o [EMAIL PROTECTED]:~/haskell/examples patch -p0 Common/Lib/Pretty.hs patch patching file Common/Lib/Pretty.hs Hunk #1 succeeded at 564 (offset -42 lines). Hunk #2 succeeded at 609 (offset -42 lines). [EMAIL PROTECTED]:~/haskell/examples time ghc -no-recomp --make -O HasCASL/hacapa.hs Chasing modules from: HasCASL/hacapa.hs Compiling Common.Lib.State ( ./Common/Lib/State.hs, ./Common/Lib/State.o ) [...] Compiling Main ( HasCASL/hacapa.hs, HasCASL/hacapa.o ) Linking ... real8m7.962s user7m46.492s sys 0m12.345s [EMAIL PROTECTED]:~/haskell/examples ll a.out HasCASL/PrintLe.o -rwxr-xr-x 1 maeder wimi 6470827 2005-12-01 14:42 a.out -rw-r--r-- 1 maeder wimi 2007272 2005-12-01 14:40 HasCASL/PrintLe.o -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1370885group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1370875 ] panic! impossible happened: ds_app_type
Bugs item #1370875, was opened at 2005-12-01 13:37
Message generated for change (Comment added) made by simonpj
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1370875group_id=8032
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Compiler
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jose Emilio Labra Gayo (labra)
Assigned to: Nobody/Anonymous (nobody)
Summary: panic! impossible happened: ds_app_type
Initial Comment:
When I try to compile:
class G a where
f :: G a
I obtain:
ghc.exe: panic! (the `impossible' happened, GHC version
6.4): ds_app_type Prueba.G{tc r1Yg} [a{tv a1Yq}]
--
Comment By: Simon Peyton Jones (simonpj)
Date: 2005-12-01 15:45
Message:
Logged In: YES
user_id=50165
Fixed some time ago; upgrade to 6.4.1.
Simon
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1370875group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1370370 ] panic! 'impossible' happened, thread blocked indefinitely
Bugs item #1370370, was opened at 2005-11-30 13:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1370370group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GHCi Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: panic! 'impossible' happened, thread blocked indefinitely Initial Comment: GHCi, version 6.4.1, crashed with the following error: ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1): thread blocked indefinitely Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. I was calling a test function which was forking a Thread which was blocking in an 'atomically' waiting on a TChan. If I ran the test function a second time, while the Thread from the first run is presumably still hanging around, I would receive the above error/crash. If I reloaded the source in GHCi after running the test function a single time GHCi would give an error message (but not crash): *** Exception: thread blocked indefinitely Most of the time after the error message there would be no modules loaded. I could load again, and repeat the fun. _Very_ occasionaly the modules would remain loaded and I could repeat the cycle without having to reload the modules. Since fixing my test function so the forked Thread dies at the desired time (ie now it won't be hanging around blocked on the TChan) I haven't observed the failure. My email: [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1370370group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1370370 ] panic! 'impossible' happened, thread blocked indefinitely
Bugs item #1370370, was opened at 2005-11-30 13:04 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1370370group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GHCi Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: panic! 'impossible' happened, thread blocked indefinitely Initial Comment: GHCi, version 6.4.1, crashed with the following error: ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1): thread blocked indefinitely Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. I was calling a test function which was forking a Thread which was blocking in an 'atomically' waiting on a TChan. If I ran the test function a second time, while the Thread from the first run is presumably still hanging around, I would receive the above error/crash. If I reloaded the source in GHCi after running the test function a single time GHCi would give an error message (but not crash): *** Exception: thread blocked indefinitely Most of the time after the error message there would be no modules loaded. I could load again, and repeat the fun. _Very_ occasionaly the modules would remain loaded and I could repeat the cycle without having to reload the modules. Since fixing my test function so the forked Thread dies at the desired time (ie now it won't be hanging around blocked on the TChan) I haven't observed the failure. My email: [EMAIL PROTECTED] -- Comment By: Nobody/Anonymous (nobody) Date: 2005-11-30 13:10 Message: Logged In: NO Oh, yeah: Running a 32bit Linux 2.6 kernel -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1370370group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1369699 ] powerpc/linux segfaulting binaries
Bugs item #1369699, was opened at 2005-11-30 13:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1369699group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Don Stewart (dons) Assigned to: Nobody/Anonymous (nobody) Summary: powerpc/linux segfaulting binaries Initial Comment: (Just so we don't forget) On powerpc/linux both yi and hmp3 segfault immediately when built the -fvia-C or -fasm ways, with (in the case of hmp3): (gdb) where #0 0x100529d4 in __stginit_Binary_ () #1 0x1046ed78 in StgRun () #2 0x104671e0 in hs_add_root () #3 0x10467128 in startupHaskell () #4 0x10464f18 in main () and in __stginit_Main_() with yi. They die before any code in Main.main is executed. Not much other info seems available. Both these applications are built with the ncurses binding, and this appears to be the same problem repored to the lists back in June 05 by J. Bobbio: http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg07478.html A test case is attached to that mail. To reproduce the hmp3 crash: $ darcs get --partial http://www.cse.unsw.edu.au/~dons/code/hmp3 And follow the cabalised build process. Both applications work on apple/powerpc, interestingly enough. -- Don -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1369699group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1162762 ] fromInteger-related pattern match overlap warnings
Bugs item #1162762, was opened at 2005-03-13 20:19
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1162762group_id=8032
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Compiler
Group: 6.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ashley Yakeley (ashley-y)
Assigned to: Simon Peyton Jones (simonpj)
Summary: fromInteger-related pattern match overlap warnings
Initial Comment:
The compiler incorrectly gives Warning: Pattern match(es) are
overlapped for this file:
{-# OPTIONS -Werror #-}
module Buggy where
instance (Num a) = Num (Maybe a) where
(Just a) + (Just b) = Just (a + b)
_ + _ = Nothing
(Just a) - (Just b) = Just (a - b)
_ - _ = Nothing
(Just a) * (Just b) = Just (a * b)
_ * _ = Nothing
negate (Just a) = Just (negate a)
negate _ = Nothing
abs (Just a) = Just (abs a)
abs _ = Nothing
signum (Just a) = Just (signum a)
signum _ = Nothing
fromInteger = Just . fromInteger
f :: Maybe Int - Int
f 1 = 1
f Nothing = 2
f _ = 3
--
Comment By: Nobody/Anonymous (nobody)
Date: 2005-11-29 20:15
Message:
Logged In: NO
If we define the first line as:
f (Just 1) = 1
there is no problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1162762group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1364839 ] ghc-pkg to build ghci libraries on install
Bugs item #1364839, was opened at 2005-11-23 17:11 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364839group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: ghc-pkg to build ghci libraries on install Initial Comment: This is with GHC 6.4.1. ghci is not supported on AIX. I recently tried to isntall MissingH with Cabal. I got: # ./setup install Installing: /usr/local/lib/MissingH-0.12.0 /usr/local/bin MissingH-0.12.0... Registering MissingH-0.12.0... Reading package info from .installed-pkg-config ... done. building GHCi library /usr/local/lib/MissingH-0.12.0/HSMissingH-0.12.0.o...ld: 0706-027 The -x flag is ignored. ld: 0706-012 The -- flag is not recognized. ld: 0706-012 The -w flag is not recognized. ld: 0706-012 The -h flag is not recognized. ghc-pkg list does not see the package after this, either. I'm not sure why Cabal seems to think it needs to build a GHCi library, and it's even more concerning that invalid flags are being given to ld. -- Comment By: Simon Marlow (simonmar) Date: 2005-11-28 11:11 Message: Logged In: YES user_id=48280 Cabal 1.0 (in GHC 6.4.x) invokes ghc-pkg with the --auto-ghci-libs option. Cabal 1.1.x builds the GHCi libs itself, which is much better. This should be fixed in Cabal 1.1.x, or if not, it is a bug in Cabal. I should really deprecate ghc-pkg's --auto-ghci-libs option, it was only a stopgap anyway. -- Comment By: John Goerzen (jgoerzen) Date: 2005-11-23 19:25 Message: Logged In: YES user_id=491567 After talking with Isaac Jones, he asked me to run install -v4. The last command it runs is: Registering MissingH-0.12.0... /usr/local/bin/ghc-pkg --auto-ghci-libs update .installed-pkg-config Reading package info from .installed-pkg-config ... done. building GHCi library /usr/local/lib/MissingH-0.12.0/HSMissingH-0.12.0.o...ld: 0706-027 The -x flag is ignored. ld: 0706-012 The -- flag is not recognized. ld: 0706-012 The -w flag is not recognized. ld: 0706-012 The -h flag is not recognized. If I manually run: /usr/local/bin/ghc-pkg update .installed-pkg-config Reading package info from .installed-pkg-config ... done. warning: can't find GHCi lib HSMissingH-0.12.0.o Saving old package config file... done. Writing new package config file... done. it works fine. So looks like the bug is in ghc-pkg. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364839group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1364820 ] LDFLAGS not used by generated ghc
Bugs item #1364820, was opened at 2005-11-23 16:42 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364820group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: LDFLAGS not used by generated ghc Initial Comment: Hello, I specified LDFLAGS=-Wl,-bbigtoc which is needed to link programs of any size on AIX, including ghc. The stage1/ghc-inplace compiler, however, is not passing this along to gcc. I can manually run the commands that make is running, add -optl -Wl,-bbigtoc and get the correct result, but GHC should do this itself. This is GHC 6.4.1. -- Comment By: Simon Marlow (simonmar) Date: 2005-11-28 11:19 Message: Logged In: YES user_id=48280 Where do you want LDFLAGS to be used? Just when building GHC, or do you want them to be added for every link in the tree? And when the GHC you're building does any linking itself? We don't tend to use LDFLAGS/CFLAGS because they're a bit global, it's not usually what you want. Instead, you should modify build.mk, something like this: GhcStage1HcOpts += -optl-Wl,-bbigtoc and if you want GHC to always add this option for you, then the best place to put it is the ld-options field of the rts package (see ghc/rts/package.conf.in). (also there's machdepCCOptions in ghc/compiler/main/DynFlags, but that applies to all C compilations and it's wired into the compiler, so that's perhaps not as suitable). -- Comment By: John Goerzen (jgoerzen) Date: 2005-11-23 16:57 Message: Logged In: YES user_id=491567 The final (stage2) compiler also does not honor these flags automatically. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364820group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1364820 ] LDFLAGS not used by generated ghc
Bugs item #1364820, was opened at 2005-11-23 11:42 Message generated for change (Comment added) made by jgoerzen You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364820group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: LDFLAGS not used by generated ghc Initial Comment: Hello, I specified LDFLAGS=-Wl,-bbigtoc which is needed to link programs of any size on AIX, including ghc. The stage1/ghc-inplace compiler, however, is not passing this along to gcc. I can manually run the commands that make is running, add -optl -Wl,-bbigtoc and get the correct result, but GHC should do this itself. This is GHC 6.4.1. -- Comment By: John Goerzen (jgoerzen) Date: 2005-11-28 08:17 Message: Logged In: YES user_id=491567 All of the above, really. I want LDFLAGS to be used when building ghc, any other tools in the tree, and when GHC does linking itself. I'll take a look at the config options you mentioned. Did I miss them in the docs somewhere? If not, could this bug be considered a request to document this? -- Comment By: Simon Marlow (simonmar) Date: 2005-11-28 06:19 Message: Logged In: YES user_id=48280 Where do you want LDFLAGS to be used? Just when building GHC, or do you want them to be added for every link in the tree? And when the GHC you're building does any linking itself? We don't tend to use LDFLAGS/CFLAGS because they're a bit global, it's not usually what you want. Instead, you should modify build.mk, something like this: GhcStage1HcOpts += -optl-Wl,-bbigtoc and if you want GHC to always add this option for you, then the best place to put it is the ld-options field of the rts package (see ghc/rts/package.conf.in). (also there's machdepCCOptions in ghc/compiler/main/DynFlags, but that applies to all C compilations and it's wired into the compiler, so that's perhaps not as suitable). -- Comment By: John Goerzen (jgoerzen) Date: 2005-11-23 11:57 Message: Logged In: YES user_id=491567 The final (stage2) compiler also does not honor these flags automatically. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364820group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1194393 ] segmentation fault
Bugs item #1194393, was opened at 2005-05-03 11:49 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1194393group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Simon Marlow (simonmar) Summary: segmentation fault Initial Comment: http://bugs.darcs.net//Ticket/Display.html?id=367 -- Comment By: Zooko O'Whielacronx (zooko) Date: 2005-11-28 15:52 Message: Logged In: YES user_id=52562 Hooray! A repeatable test case has been found! http://bugs.darcs.net/issue8 -- Comment By: Simon Marlow (simonmar) Date: 2005-09-23 10:19 Message: Logged In: YES user_id=48280 Without a repeatable test case, there's nothing we can do with this bug report, sorry. If it reappears, feel free to post more information and we can re-open the bug. -- Comment By: Zooko O'Whielacronx (zooko) Date: 2005-06-10 15:00 Message: Logged In: YES user_id=52562 For what it is worth, I haven't gotten any of these errors since I stopped trying to use darcs on lots of large binary patches containing 100's of MB per patch. So I suspect the bug is triggered by certain memory usage patterns... -- Comment By: Simon Marlow (simonmar) Date: 2005-05-03 15:07 Message: Logged In: YES user_id=48280 If the darcs devs can confirm that this is most likely a bug in GHC, as opposed to a bug in darcs due to use of FFI or unsafeWhatNot, then we'll look into it. We need a repro case (the repository that caused the failure, at least), and the same darcs sources. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1194393group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1194392 ] internal error in GHC
Bugs item #1194392, was opened at 2005-05-03 11:49 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1194392group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Simon Marlow (simonmar) Summary: internal error in GHC Initial Comment: http://bugs.darcs.net//Ticket/Display.html?id=339 -- Comment By: Zooko O'Whielacronx (zooko) Date: 2005-11-28 15:52 Message: Logged In: YES user_id=52562 Hooray! A repeatable test case has been found! http://bugs.darcs.net/issue8 -- Comment By: Simon Marlow (simonmar) Date: 2005-09-23 10:19 Message: Logged In: YES user_id=48280 Without a repeatable test case, there's nothing we can do with this bug report, sorry. If it reappears, feel free to post more information and we can re-open the bug. -- Comment By: Zooko O'Whielacronx (zooko) Date: 2005-06-10 15:00 Message: Logged In: YES user_id=52562 For what it is worth, I haven't gotten any of these errors since I stopped trying to use darcs on lots of large binary patches containing 100's of MB per patch. So I suspect the bug is triggered by certain memory usage patterns... -- Comment By: Simon Marlow (simonmar) Date: 2005-05-03 15:10 Message: Logged In: YES user_id=48280 We need a repro case: a darcs repository from which to pull, and the sources to the darcs version that exhibits the error. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1194392group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1363942 ] nativeGen/MachRegs.lhs:1016: parse error
Bugs item #1363942, was opened at 2005-11-22 16:22 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363942group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: nativeGen/MachRegs.lhs:1016: parse error Initial Comment: I am attempting to build GHC 6.4.1 on AIX 5.1L using GHC 6.2.1 as the host compiler. Everything proceeds fine until the crash here. I believe that the problem is that no content for the callClobberedRegs defined for AIX. In particular, powerpc_TARGET_ARCH will be defined, but there is no clause in that file for PowerPC. I will attach a build log. -- Comment By: Simon Marlow (simonmar) Date: 2005-11-23 12:21 Message: Logged In: YES user_id=48280 Fixed to omit building the NCG on AIX by default. -- Comment By: John Goerzen (jgoerzen) Date: 2005-11-22 16:27 Message: Logged In: YES user_id=491567 a further comment: perhaps this is a configure error -- nativeGen still isn't available on AIX, is it? I just ran ./configure --prefix=/usr/local to start this. -- Comment By: John Goerzen (jgoerzen) Date: 2005-11-22 16:23 Message: Logged In: YES user_id=491567 Forgot to add: using GCC 4.0.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363942group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1364837 ] AdjustorAsm.S doesn't build on AIX
Bugs item #1364837, was opened at 2005-11-23 12:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364837group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: AdjustorAsm.S doesn't build on AIX Initial Comment: OK, this is a weird one. I'm building GHC 6.4.1 on AIX and using IBM's assembler, since GNU binutils is known to have issues on AIX. When the build reached AdjustorAsm.S, I got: imer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#inclu de Apply.h -fvia-C -dcmm-lint -c AdjustorAsm.S -o AdjustorAsm.o Assembler: /tmp//ccq7dlbU.s: line 15: 1252-016 The specified opcode or pseudo-op is not val id. Use supported instructions or pseudo-ops only. /tmp//ccq7dlbU.s: line 48: 1252-149 Instruction subf is not implemented in the c urrent assembly mode COM. /tmp//ccq7dlbU.s: line 52: 1252-142 Syntax error. /tmp//ccq7dlbU.s: line 53: 1252-142 Syntax error. /tmp//ccq7dlbU.s: line 58: 1252-142 Syntax error. /tmp//ccq7dlbU.s: line 59: 1252-142 Syntax error. make[2]: *** [AdjustorAsm.o] Error 1 After some research, I added -opta -Wa,-mppc, which reduced the errors to: /tmp//ccA1yNhC.s: line 15: 1252-016 The specified opcode or pseudo-op is not val id. Use supported instructions or pseudo-ops only. /tmp//ccA1yNhC.s: line 52: 1252-142 Syntax error. /tmp//ccA1yNhC.s: line 53: 1252-142 Syntax error. /tmp//ccA1yNhC.s: line 58: 1252-142 Syntax error. /tmp//ccA1yNhC.s: line 59: 1252-142 Syntax error. I examined the temp files and found that line 15 contains only the word .text. I was finally able to work around the problem by adding -opta -save-temps to the command line, then using GNU as like so: as mppc -I. AdjustorAsm.s -o AdjustorAsm.o I then copied the resulting .o file to the thr, p, debug, etc. .o files. The build was then able to complete. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364837group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1364839 ] Cabal tries to build ghci libraries on install
Bugs item #1364839, was opened at 2005-11-23 12:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364839group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: Cabal tries to build ghci libraries on install Initial Comment: This is with GHC 6.4.1. ghci is not supported on AIX. I recently tried to isntall MissingH with Cabal. I got: # ./setup install Installing: /usr/local/lib/MissingH-0.12.0 /usr/local/bin MissingH-0.12.0... Registering MissingH-0.12.0... Reading package info from .installed-pkg-config ... done. building GHCi library /usr/local/lib/MissingH-0.12.0/HSMissingH-0.12.0.o...ld: 0706-027 The -x flag is ignored. ld: 0706-012 The -- flag is not recognized. ld: 0706-012 The -w flag is not recognized. ld: 0706-012 The -h flag is not recognized. ghc-pkg list does not see the package after this, either. I'm not sure why Cabal seems to think it needs to build a GHCi library, and it's even more concerning that invalid flags are being given to ld. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364839group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1363821 ] 'Bug' when installing GHC 6.4.1
Bugs item #1363821, was opened at 2005-11-22 06:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363821group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 'Bug' when installing GHC 6.4.1 Initial Comment: I installed GHC-6.4.1.pkg.zip under MacOSX, and selected the startup volume for install. The idea is that he puts the ghc exec. and the rest in /usr/local. In my case, /usr/local/ is a symbolic link to another partition. It turns out that the installer then removes this link, makes a new subdir /usr/local/ and installs ghc in there. This means, all my other stuff has become inaccessible. My feeling is that this is a bug. I can imagine that you check whether /usr/local exists and whether it is a directory, and maybe the case that it is a symbolic link to a directory is not yet covered. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363821group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1363942 ] nativeGen/MachRegs.lhs:1016: parse error
Bugs item #1363942, was opened at 2005-11-22 11:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363942group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: nativeGen/MachRegs.lhs:1016: parse error Initial Comment: I am attempting to build GHC 6.4.1 on AIX 5.1L using GHC 6.2.1 as the host compiler. Everything proceeds fine until the crash here. I believe that the problem is that no content for the callClobberedRegs defined for AIX. In particular, powerpc_TARGET_ARCH will be defined, but there is no clause in that file for PowerPC. I will attach a build log. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363942group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1363942 ] nativeGen/MachRegs.lhs:1016: parse error
Bugs item #1363942, was opened at 2005-11-22 11:22 Message generated for change (Comment added) made by jgoerzen You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363942group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: nativeGen/MachRegs.lhs:1016: parse error Initial Comment: I am attempting to build GHC 6.4.1 on AIX 5.1L using GHC 6.2.1 as the host compiler. Everything proceeds fine until the crash here. I believe that the problem is that no content for the callClobberedRegs defined for AIX. In particular, powerpc_TARGET_ARCH will be defined, but there is no clause in that file for PowerPC. I will attach a build log. -- Comment By: John Goerzen (jgoerzen) Date: 2005-11-22 11:23 Message: Logged In: YES user_id=491567 Forgot to add: using GCC 4.0.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363942group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1363942 ] nativeGen/MachRegs.lhs:1016: parse error
Bugs item #1363942, was opened at 2005-11-22 11:22 Message generated for change (Comment added) made by jgoerzen You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363942group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: nativeGen/MachRegs.lhs:1016: parse error Initial Comment: I am attempting to build GHC 6.4.1 on AIX 5.1L using GHC 6.2.1 as the host compiler. Everything proceeds fine until the crash here. I believe that the problem is that no content for the callClobberedRegs defined for AIX. In particular, powerpc_TARGET_ARCH will be defined, but there is no clause in that file for PowerPC. I will attach a build log. -- Comment By: John Goerzen (jgoerzen) Date: 2005-11-22 11:27 Message: Logged In: YES user_id=491567 a further comment: perhaps this is a configure error -- nativeGen still isn't available on AIX, is it? I just ran ./configure --prefix=/usr/local to start this. -- Comment By: John Goerzen (jgoerzen) Date: 2005-11-22 11:23 Message: Logged In: YES user_id=491567 Forgot to add: using GCC 4.0.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363942group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1162965 ] Exponential behaviour with type synonyms
Bugs item #1162965, was opened at 2005-03-14 12:54 Message generated for change (Comment added) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1162965group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Simon Peyton Jones (simonpj) Assigned to: Simon Peyton Jones (simonpj) Summary: Exponential behaviour with type synonyms Initial Comment: You're quite right. GHC has a simple but non- performant representation of type synonyms in types, so as to be able to generate good error messages, In particular, the type S t where S is a type synonym defined by 'type S a = s', is represented as SynNote (S t) (s [t/a]) That is, (S t) is represented by *both* its un-expanded and expanded form. The SynNote is ignored by unification, but the un- expanded form is useful for error messages. Unfortunately, t is duplicated, as you can see, and that leads to the behaviour you describe. I don't see myself fixing this soon, at least partly because I can't see an obvious way to fix it that doesn't lose error message behaviour. I'm going to open a SourceForge bug for it. If anyone has good ideas, let me know. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Iavor Diatchki | Sent: 17 February 2005 01:27 | To: glasgow-haskell-bugs@haskell.org | Subject: 'type' declarations | | hello, | ghc seems to be having trouble with 'type' declarations. | while compiling (i guess kind checking is the correct word here) | the following program for a very long time, ghc (6.2) runs out of 300Mb of heap. | | module Test where | | type S = Maybe | type S2 n = S (S n) | type S4 n = S2 (S2 n) | type S8 n = S4 (S4 n) | type S16 n = S8 (S8 n) | type S32 n = S16 (S16 n) | | type N64 n = S32 (S32 n) | | type N64' = | S ( S ( S ( S ( S ( S ( S ( S ( | S ( S ( S ( S ( S ( S ( S ( S ( | S ( S ( S ( S ( S ( S ( S ( S ( | S ( S ( S ( S ( S ( S ( S ( S ( | S ( S ( S ( S ( S ( S ( S ( S ( | S ( S ( S ( S ( S ( S ( S ( S ( | S ( S ( S ( S ( S ( S ( S ( S ( | S ( S ( S ( S ( S ( S ( S ( S ( | Int | | | | | | | | | | if i remove the N64 definition things work. i guess something | exponential is happening | (substitution?). | | -iavor -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-11-21 11:28 Message: Logged In: YES user_id=50165 I've fixed the exponential behaviour arising from synonyms being held in both expanded and unexpanded form. The test is tc199.hs. However, this SourceForge bug has a type that genuinely is exponential in the program size, so it remains un-fixed. Simon -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1162965group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1362711 ] Recompilation check fails for TH
Bugs item #1362711, was opened at 2005-11-21 11:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1362711group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Template Haskell Group: None Status: Open Resolution: None Priority: 3 Submitted By: Simon Peyton Jones (simonpj) Assigned to: Simon Peyton Jones (simonpj) Summary: Recompilation check fails for TH Initial Comment: The recompilation check only recompiles a module when the *interface* of a module it imports changes. But with Template Haskell, it may need to be recompiled when the *implementation* changes. Concrete example below. It's quite awkward to fix. * Perhaps a module that contains any splices should be recompiled always. * Perhaps a module that exports any TH stuff (how would we tell?) should be flagged as changed if anything about it changes. Simon The following scenario reproduces this error (thanks to Bulat Ziganshin [EMAIL PROTECTED]): 1) create Main.hs containing code module Main where import Sub main = print $x and Sub.hs containing code module Sub where x = [| 1 |] 2) compile them with --make: C:\!\Haskell\!ghc --make -fth Main.hs Chasing modules from: Main.hs Compiling Sub ( ./Sub.hs, ./Sub.o ) Compiling Main ( Main.hs, Main.o ) Loading package base-1.0 ... linking ... done. Loading package haskell98-1.0 ... linking ... done. Loading package template-haskell-1.0 ... linking ... done. Linking ... C:\!\Haskell\!main.exe 1 3) now change Sub.hs to the following code: module Sub where x = [| 2 |] 4) and recompile program: C:\!\Haskell\!ghc --make -fth Main.hs Chasing modules from: Main.hs Compiling Sub ( ./Sub.hs, ./Sub.o ) Skipping Main ( Main.hs, Main.o ) Linking ... C:\!\Haskell\!main.exe 1 As you see, Main.hs is not recompiled despite the fact that definition of x is changed and now program must print 2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1362711group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1358718 ] undefined behavior in time_str (RtsUtils.c)
Bugs item #1358718, was opened at 2005-11-16 22:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1358718group_id=8032
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Runtime System
Group: 6.4.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: undefined behavior in time_str (RtsUtils.c)
Initial Comment:
code looks like this:
char *
time_str(void)
{
static time_t now = 0;
static char nowstr[26];
if (now == 0) {
time(now);
strcpy(nowstr, ctime(now));
strcpy(nowstr+16,nowstr+19); /* this is undefined
behavior as buffers overlap, probably
will show undesired effects if compiler utilise
copy optimisations */
nowstr[21] = '\0';
}
return nowstr;
}
corrected should look like this:
char *
time_str(void)
{
static time_t now = 0;
static char nowstr[26];
if (now == 0) {
time(now);
/* ctime_r(now,nowstr); this is better if available */
strcpy(nowstr,ctime(now));
memmove(nowstr+16,nowstr+19,7);
}
return nowstr;
}
--
[EMAIL PROTECTED] , Branimir Maksimovic
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1358718group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1353390 ] unknown exception
Bugs item #1353390, was opened at 2005-11-10 19:20 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1353390group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 6.4.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Rich (rmfought) Assigned to: Nobody/Anonymous (nobody) Summary: unknown exception Initial Comment: Compiling hsgnutls-0.2.1, get the following error: Glasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.4 Using package config file: /usr/lib/ghc-6.4.1/package.conf Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Setup.lhs *** Literate pre-processor /usr/lib/ghc-6.4.1/unlit -h Setup.lhs Setup.lhs /tmp/ghc15830.lpp Stable modules: *** Compiling Main ( Setup.lhs, Setup.o ): compile: input file /tmp/ghc15830.lpp *** Checking old interface for Main: Skipping Main ( Setup.lhs, Setup.o ) *** Deleting temp files Deleting: /tmp/ghc15830.s Warning: deleting non-existent /tmp/ghc15830.s Upsweep completely successful. *** Deleting temp files Deleting: link: linkables are ... LinkableM (Thu Nov 10 09:33:46 CST 2005) Main [DotO Setup.o] Linking ... *** Deleting temp files Deleting: /tmp/ghc15830.lpp ghc-6.4.1: ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1): unknown exception This occured after I unregistered Cabal-1.0 , and installed Cabal 1.1.1. The compilation went fine before this. -- Comment By: Simon Marlow (simonmar) Date: 2005-11-11 11:06 Message: Logged In: YES user_id=48280 The error message is at fault - it is trying to compain about a missing package. You probalby have another package that depends on the Cabal-1.0 that you removed. The bug has been fixed, the fix will be in 6.4.2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1353390group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1353257 ] Problem with Threading under GHC
Bugs item #1353257, was opened at 2005-11-10 16:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1353257group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GHCi Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marco Block (schachblocki) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with Threading under GHC Initial Comment: hi ghc-friends, i try the following code, but it don't work: import System.Process import Control.Concurrent import System.IO p = threadDelay 1000 main3 = do putStrLn test hClose stdin (inp, out, err, pid) - runInteractiveProcess Test.exe [] Nothing Nothing p forkIO (putStrLn = hGetContents out) forkIO (putStrLn = hGetContents err) p putStrLn inp forkIO (hPutStrLn inp in hClose inp) p forkIO (putStrLn = hGetContents out) forkIO (putStrLn = hGetContents err) putStrLn out threadDelay 100 forkIO (hPutStrLn inp quit hClose inp) hShow out return () thanks for helping. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1353257group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1353390 ] unknown exception
Bugs item #1353390, was opened at 2005-11-10 13:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1353390group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Rich (rmfought) Assigned to: Nobody/Anonymous (nobody) Summary: unknown exception Initial Comment: Compiling hsgnutls-0.2.1, get the following error: Glasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.4 Using package config file: /usr/lib/ghc-6.4.1/package.conf Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Setup.lhs *** Literate pre-processor /usr/lib/ghc-6.4.1/unlit -h Setup.lhs Setup.lhs /tmp/ghc15830.lpp Stable modules: *** Compiling Main ( Setup.lhs, Setup.o ): compile: input file /tmp/ghc15830.lpp *** Checking old interface for Main: Skipping Main ( Setup.lhs, Setup.o ) *** Deleting temp files Deleting: /tmp/ghc15830.s Warning: deleting non-existent /tmp/ghc15830.s Upsweep completely successful. *** Deleting temp files Deleting: link: linkables are ... LinkableM (Thu Nov 10 09:33:46 CST 2005) Main [DotO Setup.o] Linking ... *** Deleting temp files Deleting: /tmp/ghc15830.lpp ghc-6.4.1: ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1): unknown exception This occured after I unregistered Cabal-1.0 , and installed Cabal 1.1.1. The compilation went fine before this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1353390group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1348090 ] HUnit treats failures as errors
Bugs item #1348090, was opened at 2005-11-04 11:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1348090group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries (other) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Wehr (stefanheimann) Assigned to: Nobody/Anonymous (nobody) Summary: HUnit treats failures as errors Initial Comment: HUnit treats a failure in a testcase as an error. I attached a patch that fixes the problem. I tested the patch with ghc and hugs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1348090group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1078231 ] GHCi stdin buffering strange
Bugs item #1078231, was opened at 2004-12-03 02:46 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1078231group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Open Resolution: None Priority: 2 Submitted By: Simon Peyton Jones (simonpj) Assigned to: Nobody/Anonymous (nobody) Summary: GHCi stdin buffering strange Initial Comment: Ben Rudiak-Gould reports This is a bizarre problem that's been randomly biting me for ages, but I just recently figured out how to reliably reproduce it. Steps to reproduce: 1. Install GHC 6.2.2 for Win32 from the MSI file at haskell.org. (Older versions also exhibit the bug.) 2. Start GHCi from the command line with no options. While it's loading (before the Prelude prompt appears), press the letter 'p' on the keyboard. 3. After the prompt appears, press the 'i' and Enter keys. 4. Instead of 3.141592653589793, GHCi reports Variable not in scope: `gi'. The character that gets munged is always the first character of the input line, and it always gets replaced with the letter g, regardless of what it was initially. It's not visibly munged: that is, the interaction looks like Prelude pi interactive:1: Variable not in scope: `gi' The same problem appears if I press both 'p' and 'i' before the prompt appears, and Enter after. But it does not appear if I press all three keys before the prompt appears, or all three after. (I told you it was weird.) I seem to remember that using :r or :l also triggers the bug on the next input, but I haven't tested that recently. I've encountered this problem on at least two different machines, at least two versions of NT (Win2K and WinXP), and many versions of GHC. -- Comment By: Nobody/Anonymous (nobody) Date: 2005-11-03 08:28 Message: Logged In: NO I submitted a not-so-good report on the same bug http://sourceforge.net/tracker/?group_id=8032atid=108032func=detailaid=1329672 the reply blames a bug in windows and says it's as fixed as it can be in 6.4.1 -- Comment By: Nobody/Anonymous (nobody) Date: 2005-02-08 22:13 Message: Logged In: NO Hmm, doesn't affect Mac OS-X 10.2.2, ghci v6.0.1: [EMAIL PROTECTED] ~$ghci pi ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.0.1, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Prelude pi 3.141592653589793 Prelude -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1078231group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1344553 ] GHC and GHCi hang when compiling simple program
Bugs item #1344553, was opened at 2005-11-01 05:40 Message generated for change (Comment added) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1344553group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: GHC and GHCi hang when compiling simple program Initial Comment: When interpreting the following four-line program using GHCi on Windows, GHCi hangs, never completing compilation and giving no output: data Paradox = Roll (Paradox - Int) unroll (Roll x) = x selfapply x = unroll x x uhoh = selfapply (Roll selfapply) If I add a simple main method of the form 'main = do print (fst (Hello world, uhoh))', and then compile with GHC, it hangs as well. However, if I use a main method which does not mention uhoh, such as 'main = do print Hello world', and then compile with GHC, compilation is successful. However, in this case, compilation with GHCi still hangs. As it happens, I have seen this bug in both versions 6.4 and 6.4.1 of GHC for Windows. -Sridhar Ramesh, [EMAIL PROTECTED] -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-11-01 10:12 Message: Logged In: YES user_id=50165 This is a documented bug. http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs. html#bugs-ghc Until it bites on a program someone really cares about, I'm not going to fix it! (The only way I know to fix it involves imposing some arbitrary bound on the number of inlinings, which will be bad for some legitimate programs; or something more elaborate, which has a complexity burden of its own.) Simon -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1344553group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1330166 ] build fails on Linux/sparc (genprimopcode: parse error at)
Bugs item #1330166, was opened at 2005-10-18 14:28 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on Linux/sparc (genprimopcode: parse error at) Initial Comment: Build fails when building ghc 6.4.x (tested 6.4 and 6.4.1) on Linux/ sparc and using ghc 6.4 binaries for bootstrap: mkdir stage1/ndpFlatten mkdir stage1/iface mkdir stage1/cmm mkdir stage1/ghci Creating main/Config.hs ... done. Creating stage1/ghc_boot_platform.h... Done. sparc-pld-linux-gcc -E -undef -traditional -P -I../includes-x c prelude/primops.txt.pp | grep -v '^#pragma GCC' prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl prelude/ primops.txt primop-data-decl.hs-incl genprimopcode: parse error at (line 579, column 1): unexpected \t expecting primop, section or thats_all_folks make[2]: *** [primop-data-decl.hs-incl] Error 1 make[2]: *** Deleting file `primop-data-decl.hs-incl' make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/users/builder/rpm/BUILD/ghc-6. 4.1/ghc' The same problem doesn't exists when using ghc 6.2.x for bootstrapping (generated primops.txt is the same in both cases, tested via md5sum). Problem doesn't exists on other arch like x86, ppc, amd64, too. -- Comment By: Nobody/Anonymous (nobody) Date: 2005-11-01 11:20 Message: Logged In: NO isSpace doesn't work correctly [EMAIL PROTECTED] ~]$ cat Test.hs import Char main = print (isSpace '\t') [EMAIL PROTECTED] ~]$ ghc Test.hs -o Test ./Test False [EMAIL PROTECTED] ~]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4.1 more complete test: [EMAIL PROTECTED] ~]$ ghc Test.hs -o Test ./Test [True,False,True,True,False,True] [EMAIL PROTECTED] ~]$ cat Test.hs import Char; main = print (map isSpace \t\n\r\f\v) -- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-10-19 02:48 Message: Logged In: YES user_id=139606 File attached. -- Comment By: Simon Marlow (simonmar) Date: 2005-10-19 02:25 Message: Logged In: YES user_id=48280 perhaps there's something odd about your gcc. Can you upload a copy of primiops.txt? (it'll be in ghc/compiler/prelude). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1330166 ] build fails on Linux/sparc (genprimopcode: parse error at)
Bugs item #1330166, was opened at 2005-10-18 23:28 Message generated for change (Comment added) made by arekm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on Linux/sparc (genprimopcode: parse error at) Initial Comment: Build fails when building ghc 6.4.x (tested 6.4 and 6.4.1) on Linux/ sparc and using ghc 6.4 binaries for bootstrap: mkdir stage1/ndpFlatten mkdir stage1/iface mkdir stage1/cmm mkdir stage1/ghci Creating main/Config.hs ... done. Creating stage1/ghc_boot_platform.h... Done. sparc-pld-linux-gcc -E -undef -traditional -P -I../includes-x c prelude/primops.txt.pp | grep -v '^#pragma GCC' prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl prelude/ primops.txt primop-data-decl.hs-incl genprimopcode: parse error at (line 579, column 1): unexpected \t expecting primop, section or thats_all_folks make[2]: *** [primop-data-decl.hs-incl] Error 1 make[2]: *** Deleting file `primop-data-decl.hs-incl' make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/users/builder/rpm/BUILD/ghc-6. 4.1/ghc' The same problem doesn't exists when using ghc 6.2.x for bootstrapping (generated primops.txt is the same in both cases, tested via md5sum). Problem doesn't exists on other arch like x86, ppc, amd64, too. -- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-11-01 20:44 Message: Logged In: YES user_id=139606 -- Comment By: Nobody/Anonymous (nobody) Date: 2005-11-01 20:28 Message: Logged In: NO More [EMAIL PROTECTED] ~]$ cat Test.hs isSpaceTest c = c == ' ' || c == '\t'|| c == '\n'|| c == '\r'|| c == '\f'|| c == '\v'|| c == '\xa0' main = print (map isSpaceTest \t\n\r\f\v) [EMAIL PROTECTED] ~]$ ghc Test.hs -o Test ./Test [True,True,True,True,True,True] [EMAIL PROTECTED] ~]$ rm -f Test.hi Test.o [EMAIL PROTECTED] ~]$ ghc -O2 Test.hs -o Test ./Test [True,False,True,True,False,True] -- Comment By: Nobody/Anonymous (nobody) Date: 2005-11-01 20:20 Message: Logged In: NO isSpace doesn't work correctly [EMAIL PROTECTED] ~]$ cat Test.hs import Char main = print (isSpace '\t') [EMAIL PROTECTED] ~]$ ghc Test.hs -o Test ./Test False [EMAIL PROTECTED] ~]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4.1 more complete test: [EMAIL PROTECTED] ~]$ ghc Test.hs -o Test ./Test [True,False,True,True,False,True] [EMAIL PROTECTED] ~]$ cat Test.hs import Char; main = print (map isSpace \t\n\r\f\v) -- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-10-19 11:48 Message: Logged In: YES user_id=139606 File attached. -- Comment By: Simon Marlow (simonmar) Date: 2005-10-19 11:25 Message: Logged In: YES user_id=48280 perhaps there's something odd about your gcc. Can you upload a copy of primiops.txt? (it'll be in ghc/compiler/prelude). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1344553 ] GHC and GHCi hang when compiling simple program
Bugs item #1344553, was opened at 2005-10-31 21:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1344553group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: GHC and GHCi hang when compiling simple program Initial Comment: When interpreting the following four-line program using GHCi on Windows, GHCi hangs, never completing compilation and giving no output: data Paradox = Roll (Paradox - Int) unroll (Roll x) = x selfapply x = unroll x x uhoh = selfapply (Roll selfapply) If I add a simple main method of the form 'main = do print (fst (Hello world, uhoh))', and then compile with GHC, it hangs as well. However, if I use a main method which does not mention uhoh, such as 'main = do print Hello world', and then compile with GHC, compilation is successful. However, in this case, compilation with GHCi still hangs. As it happens, I have seen this bug in both versions 6.4 and 6.4.1 of GHC for Windows. -Sridhar Ramesh, [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1344553group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1339991 ] getOpt' checks non-option options
Bugs item #1339991, was opened at 2005-10-27 14:24 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1339991group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries/base Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: getOpt' checks non-option options Initial Comment: When given RequireOrder the getOpt' function should not parse options following a non-option. But currently (as of version 6.4.1 of ghc) it does. E.g. when parsing with RequireOrder and if invalid-opt3 is not a recognized option then the following produces an error: progname --valid-opt1 --valid-opt2 non-opt --invalid-opt3 However, anything after non-opt should not be parsed. The problem can be fixed as follows: 164c164 procNextOpt (NonOpt x) RequireOrder = ([],x:rest,us,[]) --- procNextOpt (NonOpt x) RequireOrder = ([],x:rest,[],[]) Best Sebastian -- Comment By: Nobody/Anonymous (nobody) Date: 2005-10-29 19:59 Message: Logged In: NO I forgot to mention, that the problem refers to the System.Console.GetOpt module and the fix is to be applied to the corresponding file GetOpt.hs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1339991group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Feature Requests-1239439 ] O'Haskell
Feature Requests item #1239439, was opened at 2005-07-16 14:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1239439group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Monique Louise de Barros Montei (mlbm) Assigned to: Nobody/Anonymous (nobody) Summary: O'Haskell Initial Comment: Is there any project for extending GHC with support to O'Haskell or any other object-oriented Haskell extesion? That could be very useful for improving Haskell interoperability with OO languages. Thanks in advance, Monique Monteiro -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1239439group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1256514 ] Declare large amounts of constant data
Feature Requests item #1256514, was opened at 2005-08-11 11:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1256514group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Antti-Juhani Kaijanaho (ajk) Assigned to: Nobody/Anonymous (nobody) Summary: Declare large amounts of constant data Initial Comment: Simon Marlow wrote in Bug#635718: It is true that GHC doesn't have a good way to declare large amounts of constant data. This is a shortcoming, but not a bug (please by all means submit a feature request). Submitting as requested:) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1256514group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1157515 ] GHCi support on x86_64
Feature Requests item #1157515, was opened at 2005-03-06 00:25 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1157515group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: GHCi support on x86_64 Initial Comment: I just installed the 64bit version of ghc on an athlon 64. ghc does work and produces correct 64bit code, but ghci fails to start. Here is the complete output: [EMAIL PROTECTED] ~]$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.2, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... /usr/lib64/ghc-6.2.2/HSbase.o: unknown architecture ghc-6.2.2: panic! (the `impossible' happened, GHC version 6.2.2): loadObj: failed Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. I'm using Fedora Core 3 and installed ghc using yum. If you have any questions, contact me: philipp.classen[AT]gmx.net Thanks, Philipp -- Comment By: Simon Marlow (simonmar) Date: 2005-09-23 10:28 Message: Logged In: YES user_id=48280 Basic GHCi support is available in 6.4.1. However, FFI support in GHCi is missing, and there are problems with accessing data in a shared library from Haskell code. -- Comment By: Simon Marlow (simonmar) Date: 2005-03-07 12:03 Message: Logged In: YES user_id=48280 Changed to a feature request; GHCi support is simply not present on x86_64 yet. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1157515group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1333482 ] Supertyping of classes
Feature Requests item #1333482, was opened at 2005-10-20 11:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1333482group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Supertyping of classes Initial Comment: see Supertyping Suggestion for Haskell [url]http://repetae.net/john/recent/out/supertyping.html[/url] example: [code] class Num a = Group a where (+) :: a - a - a negate :: a - a [/code] apart from multiple inheritance, it could work like this: [code] import Prelude hiding ((+),negate) import qualified Prelude ((+),negate) class Group a where (+) :: a - a - a negate :: a - a instance Num a = Group a where (+) = (Prelude.+) negate = Prelude.negate [/code] - coeus_at_gmx_de -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1333482group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1340203 ] Debug.Trace.trace should work on Show
Feature Requests item #1340203, was opened at 2005-10-28 04:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1340203group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Juliusz Chroboczek (jch) Assigned to: Nobody/Anonymous (nobody) Summary: Debug.Trace.trace should work on Show Initial Comment: Debug.Trace.trace has type trace :: String - a - a which forces me to insert calls to show. Could it be generalised to trace :: Show a = a - b - b Thanks, Juliusz Chroboczek -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1340203group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1340203 ] Debug.Trace.trace should work on Show
Feature Requests item #1340203, was opened at 2005-10-28 04:38 Message generated for change (Settings changed) made by jch You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1340203group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 2 Submitted By: Juliusz Chroboczek (jch) Assigned to: Nobody/Anonymous (nobody) Summary: Debug.Trace.trace should work on Show Initial Comment: Debug.Trace.trace has type trace :: String - a - a which forces me to insert calls to show. Could it be generalised to trace :: Show a = a - b - b Thanks, Juliusz Chroboczek -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1340203group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Bugs-1328684 ] Win GHC 6.4.1 crashes while building FastPackedString
Bugs item #1328684, was opened at 2005-10-17 14:12 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Joel Reymont (wagerlabs) Assigned to: Nobody/Anonymous (nobody) Summary: Win GHC 6.4.1 crashes while building FastPackedString Initial Comment: GHC 6.4.1, tried on Win2K and WinXP. To reproduce install GHC 6. 4.1 from the MSI, download the FastPackedString source code from darcs and build it according to instructions. Configure goes through but the build phases crashes with a memory access error. -- Comment By: Mark Wassell (markpwassell) Date: 2005-10-20 08:02 Message: Logged In: YES user_id=1363844 My problem with HSQL goes away with the new patched version as found at http://haskell.org/ghc/dist/6.4.1/ghc-6-4-1-bld1.msi. -- Comment By: Mark Wassell (markpwassell) Date: 2005-10-18 10:42 Message: Logged In: YES user_id=1363844 The same occurs when building hsql-1.6. HSQL can be downloaded from http://sourceforge.net/project/showfiles.php? group_id=65248package_id=93958. -- Comment By: Joel Reymont (wagerlabs) Date: 2005-10-17 14:57 Message: Logged In: YES user_id=1032541 Please follow the standard building procedure for FPS. The library is cabalized. I cannot attach the exact source code that makes GHC crash but it happens at the build step. -- Comment By: Joel Reymont (wagerlabs) Date: 2005-10-17 14:52 Message: Logged In: YES user_id=1032541 You can get FPS from http://www.cse.unsw.edu.au/~dons/fps.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1328901 ] internal error: schedule: awaitEvent() in threaded RTS
Bugs item #1328901, was opened at 2005-10-17 19:04 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328901group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Runtime System Group: 6.4.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: internal error: schedule: awaitEvent() in threaded RTS Initial Comment: [EMAIL PROTECTED] forked a thread that waits on a server socket. The main thread goes on to call threadDelay and putStrLn repeatedly. using GHC 6.4.1 on WinXP workstation. pls, find attached a build script and source code. this has been stripped down to a fairly minimal demonstration of the error. -- Comment By: Simon Marlow (simonmar) Date: 2005-10-21 10:54 Message: Logged In: YES user_id=48280 Thanks, this is a bug in the Network.Socket library on Windows when used with -threaded. It will be fixed in 6.4.2. For now, you can avoid -threaded, or wait for the next 6.4.x snapshot. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328901group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1329672 ] Corruption of expression typed at prompt
Bugs item #1329672, was opened at 2005-10-18 17:13 Message generated for change (Comment added) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1329672group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GHCi Group: 6.4.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Corruption of expression typed at prompt Initial Comment: [EMAIL PROTECTED] WinXP SP2 GHC 6.4.1 On two occasions now I have loaded my program and typed at the prompt toFile blah and got the error Not in scope 'goFile'. Repeating the expressione evaluates it correctly. Is strange that both times it was exactly the same function whose name was corrupted. Does not seem to particularly repeatable (I've had it twice out of maybe a hundred times I've done this) Doubt it has anything to do with the details of my code (which has changed substantially since last time this happened) Assume some (completely random) part of ghc is corrupting what was typed at the prompt. This will, unfortunately, probably make it completely impossible to find... -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-10-20 08:00 Message: Logged In: YES user_id=50165 This is a bug in Windows, I'm afraid. It corrupts the first character of typeahead. To mitigate its effects, GHCi does try to disable typeahead by flushing the console input buffer, that was how we resolved this issue a couple of months back. The flushing wasn't done as late as it could have been though, leaving a (short) window for the user to stick some characters into the input queue before the prompt appeared. Sigbjorn has narrowed down the size of this window to its minimum included that mod with the new installer for 6.4.1. Thanks Sigbjorn. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1329672group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1328684 ] Win GHC 6.4.1 crashes while building FastPackedString
Bugs item #1328684, was opened at 2005-10-18 00:12 Message generated for change (Comment added) made by markpwassell You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joel Reymont (wagerlabs) Assigned to: Nobody/Anonymous (nobody) Summary: Win GHC 6.4.1 crashes while building FastPackedString Initial Comment: GHC 6.4.1, tried on Win2K and WinXP. To reproduce install GHC 6. 4.1 from the MSI, download the FastPackedString source code from darcs and build it according to instructions. Configure goes through but the build phases crashes with a memory access error. -- Comment By: Mark Wassell (markpwassell) Date: 2005-10-20 18:02 Message: Logged In: YES user_id=1363844 My problem with HSQL goes away with the new patched version as found at http://haskell.org/ghc/dist/6.4.1/ghc-6-4-1-bld1.msi. -- Comment By: Mark Wassell (markpwassell) Date: 2005-10-18 20:42 Message: Logged In: YES user_id=1363844 The same occurs when building hsql-1.6. HSQL can be downloaded from http://sourceforge.net/project/showfiles.php? group_id=65248package_id=93958. -- Comment By: Joel Reymont (wagerlabs) Date: 2005-10-18 00:57 Message: Logged In: YES user_id=1032541 Please follow the standard building procedure for FPS. The library is cabalized. I cannot attach the exact source code that makes GHC crash but it happens at the build step. -- Comment By: Joel Reymont (wagerlabs) Date: 2005-10-18 00:52 Message: Logged In: YES user_id=1032541 You can get FPS from http://www.cse.unsw.edu.au/~dons/fps.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1330166 ] build fails on Linux/sparc (genprimopcode: parse error at)
Bugs item #1330166, was opened at 2005-10-18 21:28 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on Linux/sparc (genprimopcode: parse error at) Initial Comment: Build fails when building ghc 6.4.x (tested 6.4 and 6.4.1) on Linux/ sparc and using ghc 6.4 binaries for bootstrap: mkdir stage1/ndpFlatten mkdir stage1/iface mkdir stage1/cmm mkdir stage1/ghci Creating main/Config.hs ... done. Creating stage1/ghc_boot_platform.h... Done. sparc-pld-linux-gcc -E -undef -traditional -P -I../includes-x c prelude/primops.txt.pp | grep -v '^#pragma GCC' prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl prelude/ primops.txt primop-data-decl.hs-incl genprimopcode: parse error at (line 579, column 1): unexpected \t expecting primop, section or thats_all_folks make[2]: *** [primop-data-decl.hs-incl] Error 1 make[2]: *** Deleting file `primop-data-decl.hs-incl' make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/users/builder/rpm/BUILD/ghc-6. 4.1/ghc' The same problem doesn't exists when using ghc 6.2.x for bootstrapping (generated primops.txt is the same in both cases, tested via md5sum). Problem doesn't exists on other arch like x86, ppc, amd64, too. -- Comment By: Simon Marlow (simonmar) Date: 2005-10-19 09:25 Message: Logged In: YES user_id=48280 perhaps there's something odd about your gcc. Can you upload a copy of primiops.txt? (it'll be in ghc/compiler/prelude). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1330166 ] build fails on Linux/sparc (genprimopcode: parse error at)
Bugs item #1330166, was opened at 2005-10-18 23:28 Message generated for change (Comment added) made by arekm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on Linux/sparc (genprimopcode: parse error at) Initial Comment: Build fails when building ghc 6.4.x (tested 6.4 and 6.4.1) on Linux/ sparc and using ghc 6.4 binaries for bootstrap: mkdir stage1/ndpFlatten mkdir stage1/iface mkdir stage1/cmm mkdir stage1/ghci Creating main/Config.hs ... done. Creating stage1/ghc_boot_platform.h... Done. sparc-pld-linux-gcc -E -undef -traditional -P -I../includes-x c prelude/primops.txt.pp | grep -v '^#pragma GCC' prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl prelude/ primops.txt primop-data-decl.hs-incl genprimopcode: parse error at (line 579, column 1): unexpected \t expecting primop, section or thats_all_folks make[2]: *** [primop-data-decl.hs-incl] Error 1 make[2]: *** Deleting file `primop-data-decl.hs-incl' make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/users/builder/rpm/BUILD/ghc-6. 4.1/ghc' The same problem doesn't exists when using ghc 6.2.x for bootstrapping (generated primops.txt is the same in both cases, tested via md5sum). Problem doesn't exists on other arch like x86, ppc, amd64, too. -- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-10-19 11:48 Message: Logged In: YES user_id=139606 File attached. -- Comment By: Simon Marlow (simonmar) Date: 2005-10-19 11:25 Message: Logged In: YES user_id=48280 perhaps there's something odd about your gcc. Can you upload a copy of primiops.txt? (it'll be in ghc/compiler/prelude). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1332817 ] Windows HGL Thread problems
Bugs item #1332817, was opened at 2005-10-20 13:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1332817group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Runtime System Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Thomas (mjthomas) Assigned to: Nobody/Anonymous (nobody) Summary: Windows HGL Thread problems Initial Comment: With CVS HEAD (19 October 2005 Australian morning) the following minimal modifications to the HGL library give a runtime error in the GTest.exe example program: === ... handleEvent: Before getMessage. handleEvent: Before yield. GTest.exe: internal error: resumeThread: thread not found Please report this as a bug to glasgow-haskell- [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ === Without those two putStrLn () calls, none of the three example programs GTests.exe, Tests.exe or HelloWorld.exe displays a Window. With those two putStrLn () calls, all three example programs present their windows and both Tests.exe and HelloWorld.exe appear to run perfectly (although note that I have not seen them running at all other than in these tests). Cheers Mike Thomas = == RCS file: /home/cvs/root/fptools/libraries/HGL/Graphics/HGL/ Win32/WND.hs,v retrieving revision 1.9 diff -r1.9 WND.hs 130a131 putStrLn handleEvent: Before yield. 133a135 putStrLn handleEvent: Before getMessage. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1332817group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1328684 ] Win GHC 6.4.1 crashes while building FastPackedString
Bugs item #1328684, was opened at 2005-10-18 00:12 Message generated for change (Comment added) made by markpwassell You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joel Reymont (wagerlabs) Assigned to: Nobody/Anonymous (nobody) Summary: Win GHC 6.4.1 crashes while building FastPackedString Initial Comment: GHC 6.4.1, tried on Win2K and WinXP. To reproduce install GHC 6. 4.1 from the MSI, download the FastPackedString source code from darcs and build it according to instructions. Configure goes through but the build phases crashes with a memory access error. -- Comment By: Mark Wassell (markpwassell) Date: 2005-10-18 20:42 Message: Logged In: YES user_id=1363844 The same occurs when building hsql-1.6. HSQL can be downloaded from http://sourceforge.net/project/showfiles.php? group_id=65248package_id=93958. -- Comment By: Joel Reymont (wagerlabs) Date: 2005-10-18 00:57 Message: Logged In: YES user_id=1032541 Please follow the standard building procedure for FPS. The library is cabalized. I cannot attach the exact source code that makes GHC crash but it happens at the build step. -- Comment By: Joel Reymont (wagerlabs) Date: 2005-10-18 00:52 Message: Logged In: YES user_id=1032541 You can get FPS from http://www.cse.unsw.edu.au/~dons/fps.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1329672 ] Corruption of expression typed at prompt
Bugs item #1329672, was opened at 2005-10-18 10:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1329672group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GHCi Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Corruption of expression typed at prompt Initial Comment: [EMAIL PROTECTED] WinXP SP2 GHC 6.4.1 On two occasions now I have loaded my program and typed at the prompt toFile blah and got the error Not in scope 'goFile'. Repeating the expressione evaluates it correctly. Is strange that both times it was exactly the same function whose name was corrupted. Does not seem to particularly repeatable (I've had it twice out of maybe a hundred times I've done this) Doubt it has anything to do with the details of my code (which has changed substantially since last time this happened) Assume some (completely random) part of ghc is corrupting what was typed at the prompt. This will, unfortunately, probably make it completely impossible to find... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1329672group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1330166 ] build fails on Linux/sparc (genprimopcode: parse error at)
Bugs item #1330166, was opened at 2005-10-18 23:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on Linux/sparc (genprimopcode: parse error at) Initial Comment: Build fails when building ghc 6.4.x (tested 6.4 and 6.4.1) on Linux/ sparc and using ghc 6.4 binaries for bootstrap: mkdir stage1/ndpFlatten mkdir stage1/iface mkdir stage1/cmm mkdir stage1/ghci Creating main/Config.hs ... done. Creating stage1/ghc_boot_platform.h... Done. sparc-pld-linux-gcc -E -undef -traditional -P -I../includes-x c prelude/primops.txt.pp | grep -v '^#pragma GCC' prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl prelude/ primops.txt primop-data-decl.hs-incl genprimopcode: parse error at (line 579, column 1): unexpected \t expecting primop, section or thats_all_folks make[2]: *** [primop-data-decl.hs-incl] Error 1 make[2]: *** Deleting file `primop-data-decl.hs-incl' make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/users/builder/rpm/BUILD/ghc-6. 4.1/ghc' The same problem doesn't exists when using ghc 6.2.x for bootstrapping (generated primops.txt is the same in both cases, tested via md5sum). Problem doesn't exists on other arch like x86, ppc, amd64, too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1328684 ] Win GHC 6.4.1 crashes while building FastPackedString
Bugs item #1328684, was opened at 2005-10-17 14:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joel Reymont (wagerlabs) Assigned to: Nobody/Anonymous (nobody) Summary: Win GHC 6.4.1 crashes while building FastPackedString Initial Comment: GHC 6.4.1, tried on Win2K and WinXP. To reproduce install GHC 6. 4.1 from the MSI, download the FastPackedString source code from darcs and build it according to instructions. Configure goes through but the build phases crashes with a memory access error. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1328684 ] Win GHC 6.4.1 crashes while building FastPackedString
Bugs item #1328684, was opened at 2005-10-17 14:12 Message generated for change (Comment added) made by wagerlabs You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joel Reymont (wagerlabs) Assigned to: Nobody/Anonymous (nobody) Summary: Win GHC 6.4.1 crashes while building FastPackedString Initial Comment: GHC 6.4.1, tried on Win2K and WinXP. To reproduce install GHC 6. 4.1 from the MSI, download the FastPackedString source code from darcs and build it according to instructions. Configure goes through but the build phases crashes with a memory access error. -- Comment By: Joel Reymont (wagerlabs) Date: 2005-10-17 14:52 Message: Logged In: YES user_id=1032541 You can get FPS from http://www.cse.unsw.edu.au/~dons/fps.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1328684 ] Win GHC 6.4.1 crashes while building FastPackedString
Bugs item #1328684, was opened at 2005-10-17 14:12 Message generated for change (Comment added) made by wagerlabs You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joel Reymont (wagerlabs) Assigned to: Nobody/Anonymous (nobody) Summary: Win GHC 6.4.1 crashes while building FastPackedString Initial Comment: GHC 6.4.1, tried on Win2K and WinXP. To reproduce install GHC 6. 4.1 from the MSI, download the FastPackedString source code from darcs and build it according to instructions. Configure goes through but the build phases crashes with a memory access error. -- Comment By: Joel Reymont (wagerlabs) Date: 2005-10-17 14:57 Message: Logged In: YES user_id=1032541 Please follow the standard building procedure for FPS. The library is cabalized. I cannot attach the exact source code that makes GHC crash but it happens at the build step. -- Comment By: Joel Reymont (wagerlabs) Date: 2005-10-17 14:52 Message: Logged In: YES user_id=1032541 You can get FPS from http://www.cse.unsw.edu.au/~dons/fps.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328684group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1328901 ] internal error: schedule: awaitEvent() in threaded RTS
Bugs item #1328901, was opened at 2005-10-17 12:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328901group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Runtime System Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: internal error: schedule: awaitEvent() in threaded RTS Initial Comment: [EMAIL PROTECTED] forked a thread that waits on a server socket. The main thread goes on to call threadDelay and putStrLn repeatedly. using GHC 6.4.1 on WinXP workstation. pls, find attached a build script and source code. this has been stripped down to a fairly minimal demonstration of the error. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1328901group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1275126 ] configure problems with openGL and openAL
Bugs item #1275126, was opened at 2005-08-28 12:47 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1275126group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: configure problems with openGL and openAL Initial Comment: I've been compiling the latest GHC snapshot (6.4.1.20050827) from source and have encountered some annoying problems with the configure script not being as intelligent as it should be. This is on a GNU/Linux system running Debian unstable. Initially I didn't have the openGL GLU headers installed so I got a compile error when the glu.h file wasn't found. I believe that since the GLU library was installed, the configure script assumed that the GLU header file would be there -- or else it didn't check. Installing the GLU header files fixed this. Then I got a weird bug while compiling the openAL support in GHC: ==fptools== make all - --no-print-directory -r; in /home/mvanier/lang/useful/haskell/ghc/ghc-6.4.1.20050827/libraries/OpenAL rm -f Sound/OpenAL/ALC/Context.o; if [ ! -d Sound/OpenAL/ALC/Context_split ]; then mkdir Sound/OpenAL /ALC/Context_split; else /usr/bin/find Sound/OpenAL/ALC/Context_split -name '*.o' -print | xargs rm - f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -Wall -fffi -Iinclude '-#include HsOpenAL.h' -cpp -DCALLCON V=ccall -ignore-package OpenAL -O -Rghc-timing -fgenerics -package base -package OpenGL -fgenerics -split-objs-c Sound/OpenAL/ALC/Context.hs -o Sound/OpenAL/ALC/Context.o -ohi Sound/OpenAL/ALC/Co ntext.hi /tmp/ghc27232.hc: In function 's33v_ret': /tmp/ghc27232.hc:553: error: void value not ignored as it ought to be /tmp/ghc27232.hc: In function 's33y_ret': /tmp/ghc27232.hc:595: error: void value not ignored as it ought to be ghc: 60654736 bytes, 14 GCs, 2844362/5655392 avg/max bytes residency (3 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.18 MUT (0.40 elapsed), 0.09 GC (0.12 elapsed) :ghc make[2]: *** [Sound/OpenAL/ALC/Context.o] Error 1 make[1]: *** [all] Error 1 make: *** [build] Error 1 As a result, I disabled openAL support. Mike Vanier [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2005-10-12 13:05 Message: Logged In: YES user_id=48280 Fixed in libraries/OpenGL/configure.ac rev. 1.7 -- Comment By: Kevin Glynn (kagy) Date: 2005-10-08 11:08 Message: Logged In: YES user_id=37873 I can't see a way to reopen this bug report, but I think it should be. I hit the same problem with Debian unstable. Kevin -- Comment By: Nobody/Anonymous (nobody) Date: 2005-08-29 23:53 Message: Logged In: NO It's not a private setup; Debian has four packages: GL libs, GL headers, GLU libs, GLU headers. It's quite possible to install GL stuff without GLU. Surely it's not too much to check for glu.h as well as gl.h. -- Ross -- Comment By: Sven Panne (spanne) Date: 2005-08-29 20:26 Message: Logged In: YES user_id=50298 Regarding your GLU header problem: This will only happen if you have GL and GLU libraries installed and a GL header, but no GLU header. This is a rather obscure setup which I've never heard before: It is common that you either have a) no GL/GLU stuff at all (OpenGL ignorant system), b) only GL/GLU libraries (OpenGL *user* system), but no header c) GL/GLU libraries and headers (OpenGL *development* system). To avoid making the autoconf magic even more tricky, I declare your setup to be buggy. :-) Seriously: I think the autotools stuff should handle common differences between platforms, but not each and every obscure private setup, otherwise things get unmaintainable. Regarding the OpenAL problem: This is due to changes in the OpenAL API itself, which are already handled in the HEAD. Furthermore, the OpenAL stuff in the STABLE branch is practically unusable, because it is very incomplete. If you want a working and complete OpenAL binding, you can use the HEAD. I'll make no OpenAL the default in STABLE... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1275126group_id=8032 ___ Glasgow-haskell-bugs mailing list
[ ghc-Bugs-1275126 ] configure problems with openGL and openAL
Bugs item #1275126, was opened at 2005-08-28 12:47 Message generated for change (Comment added) made by kagy You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1275126group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: configure problems with openGL and openAL Initial Comment: I've been compiling the latest GHC snapshot (6.4.1.20050827) from source and have encountered some annoying problems with the configure script not being as intelligent as it should be. This is on a GNU/Linux system running Debian unstable. Initially I didn't have the openGL GLU headers installed so I got a compile error when the glu.h file wasn't found. I believe that since the GLU library was installed, the configure script assumed that the GLU header file would be there -- or else it didn't check. Installing the GLU header files fixed this. Then I got a weird bug while compiling the openAL support in GHC: ==fptools== make all - --no-print-directory -r; in /home/mvanier/lang/useful/haskell/ghc/ghc-6.4.1.20050827/libraries/OpenAL rm -f Sound/OpenAL/ALC/Context.o; if [ ! -d Sound/OpenAL/ALC/Context_split ]; then mkdir Sound/OpenAL /ALC/Context_split; else /usr/bin/find Sound/OpenAL/ALC/Context_split -name '*.o' -print | xargs rm - f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -Wall -fffi -Iinclude '-#include HsOpenAL.h' -cpp -DCALLCON V=ccall -ignore-package OpenAL -O -Rghc-timing -fgenerics -package base -package OpenGL -fgenerics -split-objs-c Sound/OpenAL/ALC/Context.hs -o Sound/OpenAL/ALC/Context.o -ohi Sound/OpenAL/ALC/Co ntext.hi /tmp/ghc27232.hc: In function 's33v_ret': /tmp/ghc27232.hc:553: error: void value not ignored as it ought to be /tmp/ghc27232.hc: In function 's33y_ret': /tmp/ghc27232.hc:595: error: void value not ignored as it ought to be ghc: 60654736 bytes, 14 GCs, 2844362/5655392 avg/max bytes residency (3 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.18 MUT (0.40 elapsed), 0.09 GC (0.12 elapsed) :ghc make[2]: *** [Sound/OpenAL/ALC/Context.o] Error 1 make[1]: *** [all] Error 1 make: *** [build] Error 1 As a result, I disabled openAL support. Mike Vanier [EMAIL PROTECTED] -- Comment By: Kevin Glynn (kagy) Date: 2005-10-08 11:08 Message: Logged In: YES user_id=37873 I can't see a way to reopen this bug report, but I think it should be. I hit the same problem with Debian unstable. Kevin -- Comment By: Nobody/Anonymous (nobody) Date: 2005-08-29 23:53 Message: Logged In: NO It's not a private setup; Debian has four packages: GL libs, GL headers, GLU libs, GLU headers. It's quite possible to install GL stuff without GLU. Surely it's not too much to check for glu.h as well as gl.h. -- Ross -- Comment By: Sven Panne (spanne) Date: 2005-08-29 20:26 Message: Logged In: YES user_id=50298 Regarding your GLU header problem: This will only happen if you have GL and GLU libraries installed and a GL header, but no GLU header. This is a rather obscure setup which I've never heard before: It is common that you either have a) no GL/GLU stuff at all (OpenGL ignorant system), b) only GL/GLU libraries (OpenGL *user* system), but no header c) GL/GLU libraries and headers (OpenGL *development* system). To avoid making the autoconf magic even more tricky, I declare your setup to be buggy. :-) Seriously: I think the autotools stuff should handle common differences between platforms, but not each and every obscure private setup, otherwise things get unmaintainable. Regarding the OpenAL problem: This is due to changes in the OpenAL API itself, which are already handled in the HEAD. Furthermore, the OpenAL stuff in the STABLE branch is practically unusable, because it is very incomplete. If you want a working and complete OpenAL binding, you can use the HEAD. I'll make no OpenAL the default in STABLE... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1275126group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1315472 ] in hdirect stdcall not supported on PPC Mac OS X 10.3
Bugs item #1315472, was opened at 2005-10-07 01:17 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1315472group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen J. Turnbull (yaseppochi) Assigned to: Nobody/Anonymous (nobody) Summary: in hdirect stdcall not supported on PPC Mac OS X 10.3 Initial Comment: I'm building CVS HEAD from 2005-10-05 with 6.4.1. I get the error in the attached log. I'm not in a hurry, but in a couple of months one of my projects will be to the point that I would like to call some Haskell code from another project written in C. If there's anything I can do to help with getting hdirect supported on Mac PowerBook G4 Mac OS X 10.3.9 panther Please let me know. (I probably will upgrade to 10.4 Tiger in the near future.) It would be nice if the build could fail safely (ie, not produce the hdirect library, but not stop the rest of the fptools build). There doesn't seem to be a way to disable the feature via configure. Stephen Turnbull [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2005-10-07 08:45 Message: Logged In: YES user_id=48280 This isn't an authoritative answer, but it is likely to be the case that H/Direct has never been ported to MacOS X, and H/Direct is not being actively maintained at the moment. Why do you need H/Direct? If you just need to call Haskell from C, there are a variety of ways to achieve that, with and without extra tools. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1315472group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1303232 ] parse error on input `\' when using -cpp
Bugs item #1303232, was opened at 2005-09-24 14:25 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1303232group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Peter (peter26) Assigned to: Nobody/Anonymous (nobody) Summary: parse error on input `\' when using -cpp Initial Comment: When compiling code like: infixl 9 \ (\) = undefined causes a parser error, when compiling with the -cpp option -- Comment By: Simon Marlow (simonmar) Date: 2005-10-07 08:48 Message: Logged In: YES user_id=48280 This is a limitation in CPP, which interprets a backslash at the end of a line as a line continuation. You can work around it in two ways: add a comment at the end of the line to fool CPP, or use cpphs instead (recent cpphs's work nicely with GHC, I believe). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1303232group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1315472 ] in hdirect stdcall not supported on PPC Mac OS X 10.3
Bugs item #1315472, was opened at 2005-10-07 10:17 Message generated for change (Comment added) made by yaseppochi You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1315472group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen J. Turnbull (yaseppochi) Assigned to: Nobody/Anonymous (nobody) Summary: in hdirect stdcall not supported on PPC Mac OS X 10.3 Initial Comment: I'm building CVS HEAD from 2005-10-05 with 6.4.1. I get the error in the attached log. I'm not in a hurry, but in a couple of months one of my projects will be to the point that I would like to call some Haskell code from another project written in C. If there's anything I can do to help with getting hdirect supported on Mac PowerBook G4 Mac OS X 10.3.9 panther Please let me know. (I probably will upgrade to 10.4 Tiger in the near future.) It would be nice if the build could fail safely (ie, not produce the hdirect library, but not stop the rest of the fptools build). There doesn't seem to be a way to disable the feature via configure. Stephen Turnbull [EMAIL PROTECTED] -- Comment By: Stephen J. Turnbull (yaseppochi) Date: 2005-10-07 18:55 Message: Logged In: YES user_id=88738 Thanks for the quick reply. I don't need HDirect specifically. I may want to call Haskell code from XEmacs, someday. I checked out fptools from CVS, the build broke in hdirect/lib, I looked to see if I needed it. Its docs claim to be the way of the future in Haskell FFI, so I concluded (a) I don't need it now and (b) I will very likely want (something like) it in the future. I reported this because cvs checkout fptools; cd fptools; ./configure; make seems like a pretty natural approach with a half-dozen prerequisite projects, and the build apparently breaks. (I wonder if make install would work, that probably chokes in the same place.) -- Comment By: Simon Marlow (simonmar) Date: 2005-10-07 17:45 Message: Logged In: YES user_id=48280 This isn't an authoritative answer, but it is likely to be the case that H/Direct has never been ported to MacOS X, and H/Direct is not being actively maintained at the moment. Why do you need H/Direct? If you just need to call Haskell from C, there are a variety of ways to achieve that, with and without extra tools. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1315472group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1315472 ] in hdirect stdcall not supported on PPC Mac OS X 10.3
Bugs item #1315472, was opened at 2005-10-07 01:17 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1315472group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Stephen J. Turnbull (yaseppochi) Assigned to: Nobody/Anonymous (nobody) Summary: in hdirect stdcall not supported on PPC Mac OS X 10.3 Initial Comment: I'm building CVS HEAD from 2005-10-05 with 6.4.1. I get the error in the attached log. I'm not in a hurry, but in a couple of months one of my projects will be to the point that I would like to call some Haskell code from another project written in C. If there's anything I can do to help with getting hdirect supported on Mac PowerBook G4 Mac OS X 10.3.9 panther Please let me know. (I probably will upgrade to 10.4 Tiger in the near future.) It would be nice if the build could fail safely (ie, not produce the hdirect library, but not stop the rest of the fptools build). There doesn't seem to be a way to disable the feature via configure. Stephen Turnbull [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2005-10-07 10:17 Message: Logged In: YES user_id=48280 Ah. You don't want to check out the whole of fptools. Take a look at the CVS cheat sheet here: http://www.haskell.org/ghc/docs/latest/html/building/sec-cvs.html -- Comment By: Stephen J. Turnbull (yaseppochi) Date: 2005-10-07 09:55 Message: Logged In: YES user_id=88738 Thanks for the quick reply. I don't need HDirect specifically. I may want to call Haskell code from XEmacs, someday. I checked out fptools from CVS, the build broke in hdirect/lib, I looked to see if I needed it. Its docs claim to be the way of the future in Haskell FFI, so I concluded (a) I don't need it now and (b) I will very likely want (something like) it in the future. I reported this because cvs checkout fptools; cd fptools; ./configure; make seems like a pretty natural approach with a half-dozen prerequisite projects, and the build apparently breaks. (I wonder if make install would work, that probably chokes in the same place.) -- Comment By: Simon Marlow (simonmar) Date: 2005-10-07 08:45 Message: Logged In: YES user_id=48280 This isn't an authoritative answer, but it is likely to be the case that H/Direct has never been ported to MacOS X, and H/Direct is not being actively maintained at the moment. Why do you need H/Direct? If you just need to call Haskell from C, there are a variety of ways to achieve that, with and without extra tools. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1315472group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1315472 ] in hdirect stdcall not supported on PPC Mac OS X 10.3
Bugs item #1315472, was opened at 2005-10-07 10:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1315472group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen J. Turnbull (yaseppochi) Assigned to: Nobody/Anonymous (nobody) Summary: in hdirect stdcall not supported on PPC Mac OS X 10.3 Initial Comment: I'm building CVS HEAD from 2005-10-05 with 6.4.1. I get the error in the attached log. I'm not in a hurry, but in a couple of months one of my projects will be to the point that I would like to call some Haskell code from another project written in C. If there's anything I can do to help with getting hdirect supported on Mac PowerBook G4 Mac OS X 10.3.9 panther Please let me know. (I probably will upgrade to 10.4 Tiger in the near future.) It would be nice if the build could fail safely (ie, not produce the hdirect library, but not stop the rest of the fptools build). There doesn't seem to be a way to disable the feature via configure. Stephen Turnbull [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1315472group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1309795 ] Control.Exception.assert broken with -O
Bugs item #1309795, was opened at 2005-09-30 21:20 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1309795group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries/base Group: 6.4.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Fergus Henderson (fergus) Assigned to: Nobody/Anonymous (nobody) Summary: Control.Exception.assert broken with -O Initial Comment: According to the ghc documentation (section 4.9 optimization and section 7.8 assertions in the user guide, and the documentation for Control.Exception in the hierarchical libraries guide), assertions should be checked unless explicitly disabled with -fignore-asserts, and the -O option should have no effect on them. But in ghc version 6.4.1.20050801, -O seems to also have the effect of disabling assertions: bash$ cat Test.hs import Control.Exception main = print (assert False (42::Int)) bash$ ghc -O Test.hs ./a.out 42 This undocumented behaviour is an egregious violation of the principle of least surprise. -- Comment By: Simon Marlow (simonmar) Date: 2005-10-05 13:13 Message: Logged In: YES user_id=48280 The documentation does actually mention that -fignore-asserts is turned on by -O (section 4.9.2), but section 7.8 doesn't make any mention of it. I've now fixed this. Thanks for the report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1309795group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1309795 ] Control.Exception.assert broken with -O
Bugs item #1309795, was opened at 2005-09-30 14:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1309795group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries/base Group: 6.4.1 Status: Open Resolution: None Priority: 5 Submitted By: Fergus Henderson (fergus) Assigned to: Nobody/Anonymous (nobody) Summary: Control.Exception.assert broken with -O Initial Comment: According to the ghc documentation (section 4.9 optimization and section 7.8 assertions in the user guide, and the documentation for Control.Exception in the hierarchical libraries guide), assertions should be checked unless explicitly disabled with -fignore-asserts, and the -O option should have no effect on them. But in ghc version 6.4.1.20050801, -O seems to also have the effect of disabling assertions: bash$ cat Test.hs import Control.Exception main = print (assert False (42::Int)) bash$ ghc -O Test.hs ./a.out 42 This undocumented behaviour is an egregious violation of the principle of least surprise. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1309795group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1303232 ] parse error on input `\' when using -cpp
Bugs item #1303232, was opened at 2005-09-24 14:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1303232group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter (peter26) Assigned to: Nobody/Anonymous (nobody) Summary: parse error on input `\' when using -cpp Initial Comment: When compiling code like: infixl 9 \ (\) = undefined causes a parser error, when compiling with the -cpp option -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1303232group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1256785 ] Recompilation check should include flags
Bugs item #1256785, was opened at 2005-08-11 15:05 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1256785group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Duplicate Priority: 3 Submitted By: Simon Peyton Jones (simonpj) Assigned to: Nobody/Anonymous (nobody) Summary: Recompilation check should include flags Initial Comment: GHC skips recompilation of a module if the module code hasn't changed, even if the flags in use *have* changed. A benign version is that switching on -O won't recompile modules that were compiled without -O. But here's a nastier version: changing the -main-is flag can lead to an obscure link error. Details below supplied by Niels [EMAIL PROTECTED] Simon Actually, i reproduced it now and the reason is a bit different. I have an application Test and Test2. They both have a main function. Test imports Test2 for some other function. So this is how those files look like: ~/pancake cat Test.hs module Test where import Test2 hiding (main) main = doit ~/pancake cat Test2.hs module Test2 where doit = print Test2.doit main = print Test2.main I then first compile the first app: ~/pancake ghc --make -main-is Test.main Test.hs Chasing modules from: Test.hs Compiling Test2( ./Test2.hs, ./Test2.o ) Compiling Test ( Test.hs, Test.o ) Linking ... then i compile the second app: ~/pancake ghc --make -main-is Test2.main Test2.hs Chasing modules from: Test2.hs Skipping Test2( Test2.hs, Test2.o ) Linking ... /usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function `main': : undefined reference to `__stginit_ZCMain' /usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0x28): In function `main': : undefined reference to `ZCMain_main_closure' collect2: ld returned 1 exit status So I guess generating Test2.o the first time and using - main-is renamed the main in Test2.o . Since it is not recompiled when I want to compile the second app, it fails because it cant find the main...I thought providing a -main-is flag again when compiling the second app would somehow force recompilation of Test2.o or at least fixing the 'renaming' that the first compilation of Test2.o had caused. greetings, Niels. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1256785group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1194393 ] segmentation fault
Bugs item #1194393, was opened at 2005-05-03 11:49 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1194393group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Simon Marlow (simonmar) Summary: segmentation fault Initial Comment: http://bugs.darcs.net//Ticket/Display.html?id=367 -- Comment By: Simon Marlow (simonmar) Date: 2005-09-23 10:19 Message: Logged In: YES user_id=48280 Without a repeatable test case, there's nothing we can do with this bug report, sorry. If it reappears, feel free to post more information and we can re-open the bug. -- Comment By: Zooko O'Whielacronx (zooko) Date: 2005-06-10 15:00 Message: Logged In: YES user_id=52562 For what it is worth, I haven't gotten any of these errors since I stopped trying to use darcs on lots of large binary patches containing 100's of MB per patch. So I suspect the bug is triggered by certain memory usage patterns... -- Comment By: Simon Marlow (simonmar) Date: 2005-05-03 15:07 Message: Logged In: YES user_id=48280 If the darcs devs can confirm that this is most likely a bug in GHC, as opposed to a bug in darcs due to use of FFI or unsafeWhatNot, then we'll look into it. We need a repro case (the repository that caused the failure, at least), and the same darcs sources. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1194393group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1194392 ] internal error in GHC
Bugs item #1194392, was opened at 2005-05-03 11:49 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1194392group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Simon Marlow (simonmar) Summary: internal error in GHC Initial Comment: http://bugs.darcs.net//Ticket/Display.html?id=339 -- Comment By: Simon Marlow (simonmar) Date: 2005-09-23 10:19 Message: Logged In: YES user_id=48280 Without a repeatable test case, there's nothing we can do with this bug report, sorry. If it reappears, feel free to post more information and we can re-open the bug. -- Comment By: Zooko O'Whielacronx (zooko) Date: 2005-06-10 15:00 Message: Logged In: YES user_id=52562 For what it is worth, I haven't gotten any of these errors since I stopped trying to use darcs on lots of large binary patches containing 100's of MB per patch. So I suspect the bug is triggered by certain memory usage patterns... -- Comment By: Simon Marlow (simonmar) Date: 2005-05-03 15:10 Message: Logged In: YES user_id=48280 We need a repro case: a darcs repository from which to pull, and the sources to the darcs version that exhibits the error. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1194392group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1170933 ] Sparc/Solaris: _module_registered in QuickCheck
Bugs item #1170933, was opened at 2005-03-26 09:10 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1170933group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GHCi Group: 6.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Axel Simon (as49) Assigned to: Nobody/Anonymous (nobody) Summary: Sparc/Solaris: _module_registered in QuickCheck Initial Comment: I compiled the ghc 6.4 source tarball on Solaris. Running ghci with QuickCheck fails with: Loading package base-1.0 ... linking ... done. Loading package QuickCheck-1.0 ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol _module_registered whilst processing object file /proj/haskell/lib/ghc-6.4/HSQuickCheck.o According to another bug, I should now check HSbase.o: [EMAIL PROTECTED]:/proj/haskell/lib/ghc-6.2:536$ nm /proj/haskell/lib/ghc-6.4/HSbase.o | grep _module_registered [26416] | 4| 4|OBJT |GLOB |0|COMMON |_module_registered [EMAIL PROTECTED]:/proj/haskell/lib/ghc-6.2:537$ nm /proj/haskell/lib/ghc-6.4/HSQuickCheck.o | grep _module_registered [738] | 4| 4|OBJT |GLOB |0|COMMON |_module_registered So somehow this symbol is erroneously defined in both. Any ideas? System is: SunOS myrtle 5.9 Generic_117171-07 sun4u sparc SUNW,Sun-Fire-480R Thanks, Axel. -- Comment By: Simon Marlow (simonmar) Date: 2005-09-23 10:21 Message: Logged In: YES user_id=48280 This was fixed in the 6.4.1 release (rev. 1.138 of ghc/driver/mangler/ghc-asm.lprl). -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-07-06 10:02 Message: Logged In: YES user_id=50165 This bug is specific to Sparc/Solaris. -- Comment By: Axel Simon (as49) Date: 2005-06-13 12:16 Message: Logged In: YES user_id=489164 I've just compiled ghc-6-4-branch and I still get this error message. In fact this error appears with many modules, e.g. cabal: [EMAIL PROTECTED]:~/source/hsx/haskell-src-exts:518$ ghci -package Cabal-1.0 ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Loading package Cabal-1.0 ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol _module_registered Does anybody have the same problem with ghci on Solaris? Does ghci work for anyone on Solaris? Any help appreciated, Axel. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1170933group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1300803 ] ghc-6.4.1: ghc-6.4.1: panic
Bugs item #1300803, was opened at 2005-09-23 13:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1300803group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gour (ggd) Assigned to: Nobody/Anonymous (nobody) Summary: ghc-6.4.1: ghc-6.4.1: panic Initial Comment: While trying to build hIDE with the latest code pulled on 23rd of Sept. 2005, I get the following: Building hide-yi-0.1.0... /usr/bin/ghc -package-name hide-yi -odir dist/build -hidir dist/build -hide-all-packages --make -i -isrc -Wall -Werror -fglasgow-exts -package base-1.0 -package gtk-0.9.9.5 -package sourceview-0.9.9.5 -package mtl-1.0 -package hide-shell-0.1.0 -package yi-0.2 Hide.Yi -v Glasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.4.1.20050801 Using package config file: /usr/lib64/ghc-6.4.1/package.conf Using package config file: /home/gour/.ghc/x86_64-linux-6.4.1/package.conf *** Deleting temp files Deleting: ghc-6.4.1: ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1): unknown exception Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. setup build failed for plugins/yiBase Here is the snippet from 'darcs changes, so you can discern the state of the hIDE repo (http://www.scannedinavian.org/repos/hIDE): [EMAIL PROTECTED] ~/repos/hIDE $ darcs changes --human-readable Fri Sep 23 00:30:07 CEST 2005 Duncan Coutts [EMAIL PROTECTED] * More GUI tweaks and demo editor improvements Thu Sep 22 17:06:16 CEST 2005 Duncan Coutts [EMAIL PROTECTED] * Fix up yiBase so it still works Fro the moment the yi widget gets it's own top level window, just until it is adapted to use the new ide shell interface Thu Sep 22 16:51:22 CEST 2005 Duncan Coutts [EMAIL PROTECTED] * More build.sh portability fixes Thu Sep 22 16:48:40 CEST 2005 Duncan Coutts [EMAIL PROTECTED] * Do not build with -threaded, use the gtk2hs thread hack. Thu Sep 22 16:46:31 CEST 2005 Duncan Coutts [EMAIL PROTECTED] * Add wadges of new GUI stuff This now has the file browser and a demo text editor using the model/view split. You can open multiple top level windows (View-New Window) and edit the same buffer from multiple windows. ... The yi repo is at: http://scannedinavian.com/repos/yi My system is: [EMAIL PROTECTED] ~/repos/yi $ uname -a Linux gaura-nitai 2.6.12-gentoo #3 Fri Aug 12 13:17:04 CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux Any additional info required? Sincerely, Gour -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1300803group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1300895 ] Incomplete pattern warnings with GADTs
Bugs item #1300895, was opened at 2005-09-23 14:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1300895group_id=8032
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Bringert (bring)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incomplete pattern warnings with GADTs
Initial Comment:
{-
With GADTs, -fwarn-incomplete-patterns complains
about missing
impossible cases.
-}
{-# OPTIONS_GHC -fglasgow-exts
-fwarn-incomplete-patterns #-}
data Var = Var
data Typ = Typ
data Tree a where
V :: String - Tree Var
T_int :: Tree Typ
getId :: Tree Var - String
getId (V x) = x
--getId T_int = T_int
{-
With the last line commented out:
gadt-pattern-warning.hs:11:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `getId': Patterns not
matched: T_int
Ok, modules loaded: Main.
With the last line not commented out:
gadt-pattern-warning.hs:12:6:
Inaccessible case alternative: Can't match types
`Typ' and `Var'
When checking the pattern: T_int
In the definition of `getId': getId T_int = T_int
Failed, modules loaded: none.
-}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1300895group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1293181 ] reporting the origin of kind errors
Bugs item #1293181, was opened at 2005-09-16 19:13 Message generated for change (Settings changed) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1293181group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: 6.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Chris Rodrigues (nokta_kanto) Assigned to: Nobody/Anonymous (nobody) Summary: reporting the origin of kind errors Initial Comment: This code produces a kind error in the class declaration. There is indeed a kind error, but I think the error message is somewhat misleading. It reports a kind error in the class declaration. The kind error is due to an inconsistency between usage of Name in the class and data declarations. It would make more sense to me if the kind error were reported in the data declaration, or if it contained some information on how the expected kind was inferred. -- beginning of code class (Show a, Eq a, Monad m) = Name m a where hashName :: a - Int newName :: m a data Name a = Exp a -- end of code The error reported is: test2.hs:1:0: Couldn't match kind `*' against `k_a16S - *' In the class declaration for `Name' -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-09-19 09:32 Message: Logged In: YES user_id=50165 Happily this one is fixed already: (Will be in 6.4.1) Foo1.hs:7:5: Kind error: `Name a' is not applied to enough type arguments In the data type declaration for `Exp' Thanks for reporting it -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1293181group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1292825 ] Warning -fwarn-unused-imports does not go away
Bugs item #1292825, was opened at 2005-09-16 12:05 Message generated for change (Settings changed) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1292825group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Warning -fwarn-unused-imports does not go away Initial Comment: When I compile the attached file, where I only want to import the instance declarations of the module Control.Monad.Reader, I still get an error with the flag -fwarn-unused-imports, even though this idiom is regarded OK according to the user manual. So, I would like GHC not to report this warning even with -fwarn-unused-imports. /Koen Claessen -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-09-19 12:37 Message: Logged In: YES user_id=50165 Which version of GHC? This one is fixed in GHC 6.4 Simon -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1292825group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1292825 ] Warning -fwarn-unused-imports does not go away
Bugs item #1292825, was opened at 2005-09-16 05:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1292825group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Warning -fwarn-unused-imports does not go away Initial Comment: When I compile the attached file, where I only want to import the instance declarations of the module Control.Monad.Reader, I still get an error with the flag -fwarn-unused-imports, even though this idiom is regarded OK according to the user manual. So, I would like GHC not to report this warning even with -fwarn-unused-imports. /Koen Claessen -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1292825group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1292829 ] Bad parse error message
Bugs item #1292829, was opened at 2005-09-16 05:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1292829group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Parser) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Bad parse error message Initial Comment: Simon asked me to report this very minor bug. When compiling a file that looks like: main = print (1+2 the parser complains (and rightly so). However, it blames the above on possibly incorrect indentation, whereas it is obvious I just forgot a parenthesis. /Koen Claessen -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1292829group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1293181 ] reporting the origin of kind errors
Bugs item #1293181, was opened at 2005-09-16 19:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1293181group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Chris Rodrigues (nokta_kanto) Assigned to: Nobody/Anonymous (nobody) Summary: reporting the origin of kind errors Initial Comment: This code produces a kind error in the class declaration. There is indeed a kind error, but I think the error message is somewhat misleading. It reports a kind error in the class declaration. The kind error is due to an inconsistency between usage of Name in the class and data declarations. It would make more sense to me if the kind error were reported in the data declaration, or if it contained some information on how the expected kind was inferred. -- beginning of code class (Show a, Eq a, Monad m) = Name m a where hashName :: a - Int newName :: m a data Name a = Exp a -- end of code The error reported is: test2.hs:1:0: Couldn't match kind `*' against `k_a16S - *' In the class declaration for `Name' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1293181group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1291820 ] Strictness problem
Bugs item #1291820, was opened at 2005-09-15 12:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1291820group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nils Anders Danielsson (nilsanders) Assigned to: Nobody/Anonymous (nobody) Summary: Strictness problem Initial Comment: As requested, this is a resubmission (and update) of a previously reported bug, to get it into the bug tracker. The following program should output something involving Correct: module Main where f x = case x of [EMAIL PROTECTED] - \y - x y [EMAIL PROTECTED] - \y - x y main = putStrLn $ f (error Correct) `seq` Error However, whether it does so is a non-trivial function of the GHC version and optimisation settings: GHC version -O2? Correct? -- 4.08.1 NoYes 4.08.1 Yes No 5.04.2 NoNo 5.04.2 Yes Yes 6.0.1 _ No 6.2.2 _ No 6.4 _ No 6.4.1.20050820 _ No All tests were run on a Solaris system. Different fs give different behaviour, at least for 6.0.1. Try e.g. f x = case x of True - id False - id -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1291820group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1290999 ] panic:Unify.unifyTauTyLists
Bugs item #1290999, was opened at 2005-09-14 15:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1290999group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Volker Stolz (volkersf) Assigned to: Nobody/Anonymous (nobody) Summary: panic:Unify.unifyTauTyLists Initial Comment: The attached sample program triggers a panic because I forgot to pass the type argument in the recursive algebraic datatype construction. The commented line is correct. GHC should not panic but instead provide a helpful error message. (Unluckily, I won't be able to test this with -HEAD atm) Compiling Main ( bugs.hs, interpreted ) ghc-6.4: panic! (the `impossible' happened, GHC version 6.4): Unify.unifyTauTyLists: mismatched type lists! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1290999group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1290999 ] panic:Unify.unifyTauTyLists
Bugs item #1290999, was opened at 2005-09-14 13:23 Message generated for change (Comment added) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1290999group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: 6.4 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Volker Stolz (volkersf) Assigned to: Nobody/Anonymous (nobody) Summary: panic:Unify.unifyTauTyLists Initial Comment: The attached sample program triggers a panic because I forgot to pass the type argument in the recursive algebraic datatype construction. The commented line is correct. GHC should not panic but instead provide a helpful error message. (Unluckily, I won't be able to test this with -HEAD atm) Compiling Main ( bugs.hs, interpreted ) ghc-6.4: panic! (the `impossible' happened, GHC version 6.4): Unify.unifyTauTyLists: mismatched type lists! -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-09-14 13:29 Message: Logged In: YES user_id=50165 Happily this is already fixed, and will be in 6.4.1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1290999group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1277825 ] segmentation fault when profiling large case
Bugs item #1277825, was opened at 2005-08-31 17:31 Message generated for change (Comment added) made by fergus You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1277825group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Profiling Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault when profiling large case Initial Comment: If the attached file is compiled with -prof -auto-all, the binary produced will segfault (even if RTS profiling options are not present). This seems to be caused by a combination of a case statement with a large number of branches and a relatively complex value at the end of each branch - reducing the number of branches by one or changing any of the data declarations to newtypes eliminates the segfault. -- Comment By: Fergus Henderson (fergus) Date: 2005-09-14 11:10 Message: Logged In: YES user_id=135331 No, I am not the original submitter. -- Comment By: Simon Marlow (simonmar) Date: 2005-09-13 01:51 Message: Logged In: YES user_id=48280 Fergus - are you the original submitter? What was different about the environment in which the bug exhibits? -- Comment By: Fergus Henderson (fergus) Date: 2005-09-05 14:48 Message: Logged In: YES user_id=135331 I tried reproducing this using ghc 6.4 on Debian Linux, but I was unable to reproduce the bug. The program compiled fine with ghc -prof -auto-all bug.hs and I was able to get a profile by running ./a.out +RTS -p and looking at a.out.prof. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1277825group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1285326 ] scavenge_one: strange object 47
Bugs item #1285326, was opened at 2005-09-08 20:18 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1285326group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: tuananhbirm (tuananhbirm) Assigned to: Nobody/Anonymous (nobody) Summary: scavenge_one: strange object 47 Initial Comment: Hi, i am running GHC 6.4, in Redhat 9, running sometimes with flag -threaded on. Please look at the file Mult.hs and function: startM1 (17-20) run this function for different inputs (orignially, multiply (1%7) with (0%2)) try to run with : (1%3) and (0%1) (2%3) and (0%1) (1%2) and (0%1) (1%5) and (0%1) Best regards TuanAnh -- Comment By: Simon Marlow (simonmar) Date: 2005-09-13 08:47 Message: Logged In: YES user_id=48280 After fixing the bug, I ran the test program for about 30mins and it still hadn't finished. Is there a way to run it for, say, 5 seconds? The fix will be in version 6.4.1. -- Comment By: tuananhbirm (tuananhbirm) Date: 2005-09-12 18:23 Message: Logged In: YES user_id=1341750 what do you mean by allow it to run for a shorter time ? btw, how do i use the fixed version of ghc ? (is there a patch for this bug or something similar ? ) Thanks a lot TuanAnh -- Comment By: Simon Marlow (simonmar) Date: 2005-09-12 15:56 Message: Logged In: YES user_id=48280 Fixed now, thanks for a good report. I'd like to use this as a test case - how can I provide inputs that allow it to run for a shorter time? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1285326group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1277825 ] segmentation fault when profiling large case
Bugs item #1277825, was opened at 2005-09-01 00:31 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1277825group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Profiling Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault when profiling large case Initial Comment: If the attached file is compiled with -prof -auto-all, the binary produced will segfault (even if RTS profiling options are not present). This seems to be caused by a combination of a case statement with a large number of branches and a relatively complex value at the end of each branch - reducing the number of branches by one or changing any of the data declarations to newtypes eliminates the segfault. -- Comment By: Simon Marlow (simonmar) Date: 2005-09-13 08:51 Message: Logged In: YES user_id=48280 Fergus - are you the original submitter? What was different about the environment in which the bug exhibits? -- Comment By: Fergus Henderson (fergus) Date: 2005-09-05 21:48 Message: Logged In: YES user_id=135331 I tried reproducing this using ghc 6.4 on Debian Linux, but I was unable to reproduce the bug. The program compiled fine with ghc -prof -auto-all bug.hs and I was able to get a profile by running ./a.out +RTS -p and looking at a.out.prof. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1277825group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1282571 ] +RTS -xc and SIGINT handler gives seg fault
Bugs item #1282571, was opened at 2005-09-05 22:33 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1282571group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Profiling Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Fergus Henderson (fergus) Assigned to: Nobody/Anonymous (nobody) Summary: +RTS -xc and SIGINT handler gives seg fault Initial Comment: To reproduce this bug, save the attached file Bug.hs, run the following commands ghc -package posix -prof -auto-all Bug.hs ./a.out +RTS -xc and then hit control-C. The result is a SIGSEGV inside fprintCCS(). -- Comment By: Simon Marlow (simonmar) Date: 2005-09-13 08:57 Message: Logged In: YES user_id=48280 This one has been fixed in 6.4.1 (out soon). -- Comment By: Fergus Henderson (fergus) Date: 2005-09-05 22:44 Message: Logged In: YES user_id=135331 The crash is a null pointer dereference in fprintCCS(). Here's a gdb stack trace (gdb) where #0 0x08072cbf in fprintCCS () #1 0x in ?? () #2 0x08077fa1 in raiseAsyncWithLock () #3 0x402b60f0 in ?? () #4 0x0809f3e8 in MainCapability () #5 0x402c2014 in ?? () #6 0x0807b2d2 in raisezh_fast () #7 0x401a3440 in _IO_2_1_stdout_ () from /lib/libc.so.6 #8 0x0809f174 in hp_file () #9 0x402c2024 in ?? () #10 0x in ?? () #11 0x0001 in ?? () #12 0x402c2024 in ?? () #13 0x0002 in ?? () #14 0x in ?? () #15 0x001c in ?? () #16 0x08099314 in Main_CAFs_cc () #17 0x01db846e in ?? () #18 0x08099334 in Main_CAFs_cc_ccs () The crash occurs at fprintCCS+44: 0x08072c93 fprintCCS+0: push %esi 0x08072c94 fprintCCS+1: push %ebx 0x08072c95 fprintCCS+2: sub$0x14,%esp 0x08072c98 fprintCCS+5: mov0x20(%esp),%esi 0x08072c9c fprintCCS+9: mov0x24(%esp),%ebx 0x08072ca0 fprintCCS+13: mov%esi,0x4(%esp) 0x08072ca4 fprintCCS+17: movl $0x3c,(%esp) 0x08072cab fprintCCS+24: call 0x80492c8 _init+712 0x08072cb0 fprintCCS+29: test %ebx,%ebx 0x08072cb2 fprintCCS+31: je 0x8072d0e fprintCCS+123 0x08072cb4 fprintCCS+33: cmp$0x809d100,%ebx 0x08072cba fprintCCS+39: je 0x8072d0e fprintCCS+123 0x08072cbc fprintCCS+41: mov0x4(%ebx),%eax 0x08072cbf fprintCCS+44: mov0x4(%eax),%eax eax is zero. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1282571group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1186741 ] stack overflow when loading a big
Bugs item #1186741, was opened at 2005-04-20 15:17 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1186741group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 6.2.2 Status: Closed Resolution: None Priority: 5 Submitted By: Peter (peter26) Assigned to: Nobody/Anonymous (nobody) Summary: stack overflow when loading a big Initial Comment: when loading a file with a very big list, ghci and ghc give a stack overflow error (also when stack is increase to 10M with the +RTS -Ksize option and stack size is set to unlimited using ulimit -s unlimited in linux). ghci also shows the error when loading the file. it would be at least better to report that the list is too big. -- Comment By: Simon Marlow (simonmar) Date: 2005-09-13 09:43 Message: Logged In: YES user_id=48280 We have fixed some performance problems that show up when you compile very long lists. We don't believe GHC is using non-linear stack, but it is reasonable for GHC to use linear stack space when compiling a long list - after all it is just syntactic sugar for a deeply nested expression. You should find that 6.4.1 is better than 6.4 in terms of performance, but it might not use less stack. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1186741group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1289569 ] hPutBuf doesn't respect LineBuffering
Bugs item #1289569, was opened at 2005-09-13 09:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1289569group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries/base Group: 6.4 Status: Open Resolution: None Priority: 3 Submitted By: Simon Marlow (simonmar) Assigned to: Simon Marlow (simonmar) Summary: hPutBuf doesn't respect LineBuffering Initial Comment: On 15 April 2005 02:39, Ian Lynagh wrote: If I run this program: -- import System.Cmd (system) import Foreign.C.String (castCharToCChar) import Foreign.Marshal.Array (newArray) import System.IO (hSetBinaryMode, hPutBuf, stdout, hSetBuffering, BufferMode(..)) main = do hSetBinaryMode stdout True hSetBuffering stdout LineBuffering p - newArray (map castCharToCChar foo\n) hPutBuf stdout p 4 system sleep 5 putStr bar\n -- compiled by GHC then it waits 5 seconds and then prints foo and bar together. With hugs, foo is printed and then 5 seconds later bar is printed, as I would expect. True, the implementation doesn't respect LineBuffering (though it does respect the other buffering modes, I believe). That's a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1289569group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1285326 ] scavenge_one: strange object 47
Bugs item #1285326, was opened at 2005-09-08 20:18 Message generated for change (Comment added) made by tuananhbirm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1285326group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: tuananhbirm (tuananhbirm) Assigned to: Nobody/Anonymous (nobody) Summary: scavenge_one: strange object 47 Initial Comment: Hi, i am running GHC 6.4, in Redhat 9, running sometimes with flag -threaded on. Please look at the file Mult.hs and function: startM1 (17-20) run this function for different inputs (orignially, multiply (1%7) with (0%2)) try to run with : (1%3) and (0%1) (2%3) and (0%1) (1%2) and (0%1) (1%5) and (0%1) Best regards TuanAnh -- Comment By: tuananhbirm (tuananhbirm) Date: 2005-09-13 09:46 Message: Logged In: YES user_id=1341750 The program is supposed to compute an infinite list, so it would never finish (however i never see the error after 100-150 digits). If you always get the result of [1,0,0,0,0. , then try with inputs whose denominators are not power of 2 (like (1%3 and 1%3) or (1%3 and 3%5)) ... Best regards TuanAnh -- Comment By: Simon Marlow (simonmar) Date: 2005-09-13 08:47 Message: Logged In: YES user_id=48280 After fixing the bug, I ran the test program for about 30mins and it still hadn't finished. Is there a way to run it for, say, 5 seconds? The fix will be in version 6.4.1. -- Comment By: tuananhbirm (tuananhbirm) Date: 2005-09-12 18:23 Message: Logged In: YES user_id=1341750 what do you mean by allow it to run for a shorter time ? btw, how do i use the fixed version of ghc ? (is there a patch for this bug or something similar ? ) Thanks a lot TuanAnh -- Comment By: Simon Marlow (simonmar) Date: 2005-09-12 15:56 Message: Logged In: YES user_id=48280 Fixed now, thanks for a good report. I'd like to use this as a test case - how can I provide inputs that allow it to run for a shorter time? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1285326group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1289573 ] mkProtoBCO: stack use won't fit in 16 bits 79141
Bugs item #1289573, was opened at 2005-09-13 09:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1289573group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Simon Marlow (simonmar) Assigned to: Nobody/Anonymous (nobody) Summary: mkProtoBCO: stack use won't fit in 16 bits 79141 Initial Comment: ERROR MESSAGE: Prelude :r Compiling BookData ( ./BookData.hs, interpreted ) ghc-6.2.2: panic! (the `impossible' happened, GHC version 6.2.2): mkProtoBCO: stack use won't fit in 16 bits 79141 Test case and rest of message here: http://www.haskell.org//pipermail/glasgow-haskell-bugs/2005-March/004871.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1289573group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-807249 ] Instance match failure on openTypeKind
Bugs item #807249, was opened at 2003-09-16 16:37 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=807249group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simon Peyton Jones (simonpj) Assigned to: Simon Peyton Jones (simonpj) Summary: Instance match failure on openTypeKind Initial Comment: Consider instance Show (a-gt;b) where ... foo x = show (\ _ -gt; True) This fails with: No instance for (Show (t -gt; Bool)) arising from use of `show' at Foo.hs:5 Reason: the type of (\_ -gt; True) is (t -gt; Bool) where t has an quot;openTypeKindquot;. It's possible that the function will be applied to say an Int#, and the openTypeKind records that this is OK. BUT, the instance decl Show (a-gt;b) has a::liftedTypeKind, and that doesn't match an openTypeKind type variable. This bug relates to GHC's unsatisfactory treatment of the variants of kind quot;typequot;, for which there are at least 2 other SourceForge bugs registered (753780 and 753777). It's very obscure, so I'm not going to fix it today. -- Comment By: Simon Marlow (simonmar) Date: 2005-07-11 10:36 Message: Logged In: YES user_id=48280 ghci015 now tests for this bug. -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-05-23 12:57 Message: Logged In: YES user_id=50165 I'm bumping up the priority of this bug, because it also happens if, in GHCi, you say Prelude :m +Text.Show.Functions Text.Show.Functions print (\x - x) (this elicits a no-such-instance error) It's even more perplexing that this does not happen if you say print id becuase 'id' has kind-defaulted type variables in its type. Sigh. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=807249group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1266898 ] parse error way too late
Bugs item #1266898, was opened at 2005-08-23 08:57 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1266898group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Parser) Group: 6.2.2 Status: Closed Resolution: None Priority: 5 Submitted By: Axel Simon (as49) Assigned to: Nobody/Anonymous (nobody) Summary: parse error way too late Initial Comment: On the attached file the compiler reports typeerror.hs:29: parse error (possibly incorrect indentation) where line no 29 is the type signature of the second function (lookup). I thought ghc was off by one line and looked desperately at line 30 (which was stupid since ghc's line numbers are only too far down, never early). The solution is that I missed the equal sign in the first function. I report this since I'm puzzled by the fact that ghc got all the way down to the next type signature before the parser found an error. Axel. -- Comment By: Simon Marlow (simonmar) Date: 2005-09-12 12:27 Message: Logged In: YES user_id=48280 The parse error is on the invisible ';' inserted by layout before the 'lookup' token. Before that, the declaration is a syntactically correct prefix of a declaration (the do expression is inside the guard!). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1266898group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1186431 ] mkGraph Stack Overflow
Bugs item #1186431, was opened at 2005-04-20 04:50
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1186431group_id=8032
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libraries (other)
Group: 6.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: mkGraph Stack Overflow
Initial Comment:
module Data.Graph.Inductive.Graph
mkGraph :: [LNode a] - [LEdge b] - gr a b
mkGraph dies on large graphs.
'mkGraph nodes edges' gives stack overflow error.
length nodes - 2
length edges - 40
--
Comment By: Simon Marlow (simonmar)
Date: 2005-09-12 12:34
Message:
Logged In: YES
user_id=48280
Closing following comment from the maintainer of the
relevant library.
--
Comment By: Martin Erwig (erwig)
Date: 2005-08-26 21:31
Message:
Logged In: YES
user_id=1335862
I will change the use of foldr to foldl in the next release of the FGL.
However, I do not intend to reimplement the graph representation
using Data.Map.
--
Comment By: Don Stewart (dons)
Date: 2005-07-07 04:49
Message:
Logged In: YES
user_id=880987
Here's a test program:
module Main where
import Data.Graph.Inductive ( Gr, mkGraph )
import Control.Exception( evaluate )
type Graph = Gr () ()
main = do
let nodes = [ (n,()) | n - [1 .. 2] ]
edges = [ (n,m,()) | (n,_) - nodes, (m,_) - nodes, n /= m ]
g = mkGraph nodes edges :: Graph
_ - Control.Exception.evaluate g
putStrLn done
Which will overflow:
$ ghc -O -package fgl Test.hs
$ ./a.out
Stack space overflow: current size 8388608 bytes.
Use `+RTS -Ksize' to increase it.
Now, we can squash this bug by replacing the foldr in insEdges in
Data.Graph.Inductive.Tree with a foldl':
--- /home/dons/fptools/libraries/fgl/Data/Graph/Inductive/Tree.hs
Thu Jul 7 11:58:34 2005
+++ ./Tree2.hs Thu Jul 7 14:07:38 2005
@@ -3,6 +3,7 @@
module Data.Graph.Inductive.Tree (Gr,UGr) where
+import Data.List(foldl')
import Data.Graph.Inductive.Graph
import Data.Graph.Inductive.Internal.FiniteMap
@@ -44,7 +45,10 @@
empty = Gr emptyFM
isEmpty (Gr g) = case g of {Empty - True; _ - False}
match = matchGr
- mkGraph vs es = (insEdges es . insNodes vs) empty
+ mkGraph vs es = (insEdges' es . insNodes vs) empty
+where
+ insEdges' es g = foldl' (flip insEdge) g es
+
labNodes (Gr g) = map (\(v,(_,l,_))-(v,l)) (fmToList g)
-- more efficient versions of derived class members
--
However, we'll still run out of heap after a couple of minutes anyway.
(this is for n=200 by the way)
$ time ./a.out
a.out: out of memory (requested 1048576 bytes)
./a.out 21.47s user 7.94s system 14% cpu 3:17.98 total
Down to n=50, some profiling reveals:
COST CENTREMODULE %time %alloc
updFM Tree2 56.2 70.2
updAdj Tree2 37.59.3
clearPred Tree2 6.2 10.3
Adding some `seq`s to updFM helps a little bit, knocking 25% off the allocs:
COST CENTREMODULE %time %alloc
updFM Tree2 35.7 61.1
updAdj Tree2 42.9 12.2
clearPred Tree2 21.4 13.5
Now n=200 still runs out of heap, just takes 25% longer.
Here's updFM, from Data/Graph/Inductive/Internal/FiniteMap.hs:
updFM :: Ord a = FiniteMap a b - a - (b - b) - FiniteMap a b
updFM (Node h l (j,x) r) i f
| ij= Node h (updFM l i f) (j,x) r
| ij= Node h l (j,x) (updFM r i f)
| otherwise = Node h l (j,f x) r
versus:
updFM (Node h l (j,x) r) i f
| ij= let l' = updFM l i f in l' `seq` Node h l' (j,x) r
| ij= let r' = updFM r i f in r' `seq` Node h l (j,x) r'
| otherwise = Node h l (j,f x) r
I wonder if a Graph implemented as a Data.Map would make any difference.
-- Don Stewart
[ ghc-Bugs-1285326 ] scavenge_one: strange object 47
Bugs item #1285326, was opened at 2005-09-08 20:18 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1285326group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: tuananhbirm (tuananhbirm) Assigned to: Nobody/Anonymous (nobody) Summary: scavenge_one: strange object 47 Initial Comment: Hi, i am running GHC 6.4, in Redhat 9, running sometimes with flag -threaded on. Please look at the file Mult.hs and function: startM1 (17-20) run this function for different inputs (orignially, multiply (1%7) with (0%2)) try to run with : (1%3) and (0%1) (2%3) and (0%1) (1%2) and (0%1) (1%5) and (0%1) Best regards TuanAnh -- Comment By: Simon Marlow (simonmar) Date: 2005-09-12 15:56 Message: Logged In: YES user_id=48280 Fixed now, thanks for a good report. I'd like to use this as a test case - how can I provide inputs that allow it to run for a shorter time? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1285326group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1285326 ] scavenge_one: strange object 47
Bugs item #1285326, was opened at 2005-09-08 20:18 Message generated for change (Comment added) made by tuananhbirm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1285326group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: tuananhbirm (tuananhbirm) Assigned to: Nobody/Anonymous (nobody) Summary: scavenge_one: strange object 47 Initial Comment: Hi, i am running GHC 6.4, in Redhat 9, running sometimes with flag -threaded on. Please look at the file Mult.hs and function: startM1 (17-20) run this function for different inputs (orignially, multiply (1%7) with (0%2)) try to run with : (1%3) and (0%1) (2%3) and (0%1) (1%2) and (0%1) (1%5) and (0%1) Best regards TuanAnh -- Comment By: tuananhbirm (tuananhbirm) Date: 2005-09-12 18:23 Message: Logged In: YES user_id=1341750 what do you mean by allow it to run for a shorter time ? btw, how do i use the fixed version of ghc ? (is there a patch for this bug or something similar ? ) Thanks a lot TuanAnh -- Comment By: Simon Marlow (simonmar) Date: 2005-09-12 15:56 Message: Logged In: YES user_id=48280 Fixed now, thanks for a good report. I'd like to use this as a test case - how can I provide inputs that allow it to run for a shorter time? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1285326group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1285326 ] scavenge_one: strange object 47
Bugs item #1285326, was opened at 2005-09-08 20:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1285326group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: tuananhbirm (tuananhbirm) Assigned to: Nobody/Anonymous (nobody) Summary: scavenge_one: strange object 47 Initial Comment: Hi, i am running GHC 6.4, in Redhat 9, running sometimes with flag -threaded on. Please look at the file Mult.hs and function: startM1 (17-20) run this function for different inputs (orignially, multiply (1%7) with (0%2)) try to run with : (1%3) and (0%1) (2%3) and (0%1) (1%2) and (0%1) (1%5) and (0%1) Best regards TuanAnh -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1285326group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1277825 ] segmentation fault when profiling large case
Bugs item #1277825, was opened at 2005-08-31 17:31 Message generated for change (Comment added) made by fergus You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1277825group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Profiling Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault when profiling large case Initial Comment: If the attached file is compiled with -prof -auto-all, the binary produced will segfault (even if RTS profiling options are not present). This seems to be caused by a combination of a case statement with a large number of branches and a relatively complex value at the end of each branch - reducing the number of branches by one or changing any of the data declarations to newtypes eliminates the segfault. -- Comment By: Fergus Henderson (fergus) Date: 2005-09-05 14:48 Message: Logged In: YES user_id=135331 I tried reproducing this using ghc 6.4 on Debian Linux, but I was unable to reproduce the bug. The program compiled fine with ghc -prof -auto-all bug.hs and I was able to get a profile by running ./a.out +RTS -p and looking at a.out.prof. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1277825group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1277023 ] panic! mkWWcpr: not a product
Bugs item #1277023, was opened at 2005-08-30 17:19
Message generated for change (Comment added) made by fergus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1277023group_id=8032
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Compiler
Group: 6.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: panic! mkWWcpr: not a product
Initial Comment:
I encountered the following bug:
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
mkWWcpr: not a product SPIRziSPIR.SPIR{tc r3jI}
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
This was in conjunction with the use of .hs-boot files
for recursive modules, though I don't know for sure if that
actually caused the problem.
Unfortunate I can't provide a simple reproducible test case
at this point, but I thought I'd let you know about the
bug anyway.
Fergus Henderson [EMAIL PROTECTED]
--
Comment By: Fergus Henderson (fergus)
Date: 2005-09-05 14:50
Message:
Logged In: YES
user_id=135331
Yes, I was using --make.
--
Comment By: Simon Peyton Jones (simonpj)
Date: 2005-09-01 01:10
Message:
Logged In: YES
user_id=50165
Definitely a bug, but hard to find without a test case.
Were you using --make? We've got a known problem there.
--
Comment By: Simon Peyton Jones (simonpj)
Date: 2005-09-01 01:07
Message:
Logged In: YES
user_id=50165
Definitely a bug, but hard to find without a test case.
Were you using --make? We've got a known problem there.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1277023group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
