[ ghc-Bugs-1206426 ] SHGetFolderPath link error
Bugs item #1206426, was opened at 2005-05-21 23:43 Message generated for change (Comment added) made by sigbjorn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1206426&group_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: 6.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: SHGetFolderPath link error Initial Comment: Vivian McPhail On Win9x with GHC 6.4.1 Attempting to compile Cabal setup.exe is linked to missing export SHELL32.DLL:SHGetFolderPathA There is a dll named ShFolder.dll which can be downloaded from microsoft to provide this function. I note that libshfolder.a is also to be found in $GHC/gcc-lib directory. I have (manually) added "ShFolder" to extraLibraries of Cabal in package.conf, which fixed the problem when running GHCi. However, when running the Cabal package setup.exe the above error (in a dialog box) occurs. I ran ghc with -v to see the libraries linked against, and they included -lshfolder. I cannot figure out what is going wrong here. Does shell32 say it exports the function and thus prevent ShFolder from providing it? -- >Comment By: Sigbjorn Finne (sigbjorn) Date: 2005-08-11 10:11 Message: Logged In: YES user_id=232905 Closing this bug as I haven't heard back. The change suggested by the bug reporter has made its way into the CVS sources for Cabal (rev. 1.18 of package.conf.in). If this turns out not to fix the issue, let's re-open this bug. -- Comment By: Sigbjorn Finne (sigbjorn) Date: 2005-07-06 10:44 Message: Logged In: YES user_id=232905 Making that same change here gives me a setup.exe that isn't dependent on shell32.dll, but shfolder.dll only. Could you provide the exact steps you're following and/or e- mail me the final binary so that I can poke around a bit more? --sigbjorn -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1206426&group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1186911 ] Prologue junk?
Bugs item #1186911, was opened at 2005-04-20 20:25 Message generated for change (Comment added) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1186911&group_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: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Simon Marlow (simonmar) Summary: Prologue junk? Initial Comment: Compiling Omega 1.0 (from Tim Sheard's home page) under GHC 6.4 for Windows XP by Christopher Dutchyn ([EMAIL PROTECTED]) C:\spl\Omega1.0>ghc Main.hs -prof -auto-all --make - fglasgow-exts -package lang -fallow-undecidable- instances ... successful modules elided ... Compiling LangEval ( ./LangEval.hs, ./LangEval.o ) ./LangEval.hs:22:0: Warning: Module `IOExts' is deprecated: This library will go away soon; see Data.Array.IO, Data.IORef, and System.IO ./LangEval.hs:278:8: Warning: Pattern match(es) are overlapped In the definition of `mf': mf p v = ... Prologue junk?: .globl _LangEval_vals_entry _LangEval_vals_entry: movl$4588, %eax call__alloca /APP -- >Comment By: Simon Peyton Jones (simonpj) Date: 2005-08-11 15:20 Message: Logged In: YES user_id=50165 No response, so closing the bug. -- Comment By: Simon Marlow (simonmar) Date: 2005-06-03 10:23 Message: Logged In: YES user_id=48280 I believe I've fixed this, though I haven't tested the fix. Please could you try again with a snapshot of ghc 6.4.1 generated any time after today? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1186911&group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1213876 ] Xlib Types Not Instances of Anything
Bugs item #1213876, was opened at 2005-06-02 23:55 Message generated for change (Comment added) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1213876&group_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: Open Resolution: None Priority: 5 Submitted By: Jon Cast (jcast) Assigned to: Nobody/Anonymous (nobody) Summary: Xlib Types Not Instances of Anything Initial Comment: The types defined by newtype in Graphics.X11.Xlib.Types are not instances of any type classes. Ptr, on the other hand, which these types are synonyms for, is an instance of Eq, Ord, Show, Typeable, Data, Storable, and several other classes not relevant to the usage of pointers in Graphics.X11.Xlib. -- >Comment By: Simon Peyton Jones (simonpj) Date: 2005-08-11 15:15 Message: Logged In: YES user_id=50165 Ross Paterson is looking into this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1213876&group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1245810 ] Random.StdGen slowness
Bugs item #1245810, was opened at 2005-07-27 08:32
Message generated for change (Comment added) made by simonpj
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1245810&group_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: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Remi Turk (remit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Random.StdGen slowness
Initial Comment:
Two (performance) problems in one:
{-# OPTIONS -fffi #-}
module Main (main) where
import Control.Monad
import Random
foreign import ccall unsafe "random" _crandom :: IO Int
randomInt :: (Int, Int) -> IO Int
randomInt (min,max) = do
n <- _crandom
return $ min + n `rem` range
where
range = max - min + 1
main = replicateM_ (5*10^6) $ do
x <- randomRIO (0::Int,1000) :: IO Int
x `seq` return ()
return ()
First, without the "seq" at the end, hardly anything is
evaluated and we're building huge amounts of thunks.
Three ideas about this one:
- Blame the user :)
- data StdGen = StdGen !Int !Int
Use strict fields in StdGen. Doesn't actually help
(at least in this example).
- Force evaluation of the StdGen in getStdRandom.
Does help in this example, but also changes behaviour
of the library:
x <- randomRIO undefined
currently dies only when x (or the result of a later
randomRIO) is evaluated. This change causes it to die
immediately.
Second, even _with_ the "seq", replacing "randomRIO" by
"randomInt" speeds the thing up with a factor of about
30. (2 to 3.6, in a "real world" university practicum
exercise of 900 lines of code)
Even given the fact that they're not really doing the
same thing, this seems rather much :(
--
>Comment By: Simon Peyton Jones (simonpj)
Date: 2005-08-11 15:10
Message:
Logged In: YES
user_id=50165
If someone can narrow down why things speed up by a factor
of 30, and can give us a better characterised case where
GHC is giving bad performance, we'd be happy to investigate.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1245810&group_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 (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1256785&group_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: 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=detail&atid=108032&aid=1256785&group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: stdin set to nonblocking mode
"Simon Marlow" <[EMAIL PROTECTED]> writes: On 11 August 2005 01:18, John Meacham wrote: Why do we set file descriptors to nonblocking mode anyway if they are waited on by a select. there shouldn't be a need to use both It avoids an extra system call per read(), i.e. a single read() instead of select() + read(). And there's a slight chance of a race between the select() and read() calls, if some other thread or process is reading from the same descriptor. With non-blocking read(), this isn't an issue. The overhead of the extra syscall is probably a non-issue, but the race is mildly worrying. The main reason for using non-blocking descriptors is that select() only tells you that I/O is possible over a descriptor, not the amount. Hence block read()s and writes() run the real risk of blocking the whole system. Insisting on single byte read()/write()s is not an option ;-) --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1251699 ] ghc-6.4.1.20050801: panic!
Bugs item #1251699, was opened at 2005-08-04 09:03
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1251699&group_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: None
Priority: 5
Submitted By: Gour (ggd)
Assigned to: Nobody/Anonymous (nobody)
Summary: ghc-6.4.1.20050801: panic!
Initial Comment:
Hi!
I've pulled the latest Yi code from the darcs
repository and tried to compile it with 'make
way=static' using ghc-6.4.1.20050801 compiler.
Here is the result:
[...]
ghc -Wall -Werror -Icbits -Imk -funbox-strict-fields
-O2 -fasm -threaded -package-conf yi.conf
-package yi -i -Icbits -Imk -c Yi.hs -o Yi.o -ohi Yi.hi
ghc -Wall -Werror -Icbits -Imk -funbox-strict-fields
-O2 -fasm -threaded -package-conf yi.conf
-package yi -c Main.hs -o Main.o -ohi Main.hi
./Yi.hi :
Interface file inconsistency:
home-package module `Yi.Editor' is mentioned,
but does not appear in the dependencies of the
interface
ghc-6.4.1.20050801: panic! (the `impossible'
happened, GHC version 6.4.1.20050801):
forkM Declaration for staticzumain{v}
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Sincerely,
Gour
--
>Comment By: Simon Marlow (simonmar)
Date: 2005-08-11 13:13
Message:
Logged In: YES
user_id=48280
Ok, I now see that you added --make to the build of Main,
and removing it makes the crash happen.
Here's what's happening: you compiled Yi.hs with the -i
flag, which empties the search path. So Yi.Editor is found
in the yi package, and Yi.hi records a dependency on package
yi. All fine so far. But when you compile Main, you didn't
use the -i flag, and Yi.Editor is now found on the search
path, so GHC considers it to be a local module rather than a
package module. Confusion naturally ensues.
Officially this is driver error - you haven't compiled all
your modules with a consistent view of the module namespace.
Putting Yi and Main in a separate directory will solve the
problem.
It would be nice if GHC didn't fail in such an ugly way.
We'll look into improving it.
--
Comment By: Gour (ggd)
Date: 2005-08-11 13:00
Message:
Logged In: YES
user_id=728695
I'm on x86_64.
Have you tried that one?
Sincerely,
Gour
--
Comment By: Simon Marlow (simonmar)
Date: 2005-08-11 12:48
Message:
Logged In: YES
user_id=48280
I tried to reproduce this just now and failed - the build
goes through for me with 6.4.1.20050801.
However, from your description of the problem, I can imagine
there might be problems. I'd still like to find out exactly
what causes the crash, though.
--
Comment By: Don Stewart (dons)
Date: 2005-08-04 11:47
Message:
Logged In: YES
user_id=880987
Seems we can work around this by adding --make when compiling Main.hs
(though we shouldn't have to):
/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage1/ghc-inplace
-Wall -Werror -Icbits -Imk -funbox-strict-fields -O2 -fasm -threaded
-I/usr/local/include -package-conf yi.conf -package yi -package yi --make -c
Main.hs -o Main.o
Chasing modules from: Main.hs
[ 1 of 38] Skipping Yi.Version ( Yi/Version.hs, Yi/Version.o )
[ 2 of 38] Compiling Yi.Undo[boot]( Yi/Undo.hs-boot, Yi/Undo.o-boot )
[ 3 of 38] Skipping Yi.Style ( Yi/Style.hs, Yi/Style.o )
[ 4 of 38] Skipping Yi.String( Yi/String.hs, Yi/String.o )
...
[37 of 38] Skipping Yi ( Yi.hs, Yi.o )
[38 of 38] Compiling Main ( Main.hs, Main.o )
/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage1/ghc-inplace
-o yi-static -L/usr/local/lib -package-conf yi.conf -package yi -package yi
Main.o Yi.o
Note that nothing is recompiled -- only Main.hs (though there appears to be an
unneccessary recompilation of Yi.Undo.hs-boot, btw).
The .hi file for Main.hs in fact turns out as desired:
interface Main 1 6050 where
export Main main
module dependencies: Yi
package dependencies: base-1.0 mtl-1.0 yi-0.1
despite --make chasing module depends in Yi/*
So I'm wondering if ghc is getting confused by the fact that Main depends on
things in Yi/*, but isn't supposed to actually use that directory directly for
any dependencies (it should use -package yi)?
-- Don
--
Comment By: Don Stewart (dons)
Date: 2005-08-04 10:48
Message:
Log
[ ghc-Bugs-1251699 ] ghc-6.4.1.20050801: panic!
Bugs item #1251699, was opened at 2005-08-04 11:03
Message generated for change (Comment added) made by ggd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1251699&group_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.20050801: panic!
Initial Comment:
Hi!
I've pulled the latest Yi code from the darcs
repository and tried to compile it with 'make
way=static' using ghc-6.4.1.20050801 compiler.
Here is the result:
[...]
ghc -Wall -Werror -Icbits -Imk -funbox-strict-fields
-O2 -fasm -threaded -package-conf yi.conf
-package yi -i -Icbits -Imk -c Yi.hs -o Yi.o -ohi Yi.hi
ghc -Wall -Werror -Icbits -Imk -funbox-strict-fields
-O2 -fasm -threaded -package-conf yi.conf
-package yi -c Main.hs -o Main.o -ohi Main.hi
./Yi.hi :
Interface file inconsistency:
home-package module `Yi.Editor' is mentioned,
but does not appear in the dependencies of the
interface
ghc-6.4.1.20050801: panic! (the `impossible'
happened, GHC version 6.4.1.20050801):
forkM Declaration for staticzumain{v}
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Sincerely,
Gour
--
>Comment By: Gour (ggd)
Date: 2005-08-11 15:00
Message:
Logged In: YES
user_id=728695
I'm on x86_64.
Have you tried that one?
Sincerely,
Gour
--
Comment By: Simon Marlow (simonmar)
Date: 2005-08-11 14:48
Message:
Logged In: YES
user_id=48280
I tried to reproduce this just now and failed - the build
goes through for me with 6.4.1.20050801.
However, from your description of the problem, I can imagine
there might be problems. I'd still like to find out exactly
what causes the crash, though.
--
Comment By: Don Stewart (dons)
Date: 2005-08-04 13:47
Message:
Logged In: YES
user_id=880987
Seems we can work around this by adding --make when compiling Main.hs
(though we shouldn't have to):
/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage1/ghc-inplace
-Wall -Werror -Icbits -Imk -funbox-strict-fields -O2 -fasm -threaded
-I/usr/local/include -package-conf yi.conf -package yi -package yi --make -c
Main.hs -o Main.o
Chasing modules from: Main.hs
[ 1 of 38] Skipping Yi.Version ( Yi/Version.hs, Yi/Version.o )
[ 2 of 38] Compiling Yi.Undo[boot]( Yi/Undo.hs-boot, Yi/Undo.o-boot )
[ 3 of 38] Skipping Yi.Style ( Yi/Style.hs, Yi/Style.o )
[ 4 of 38] Skipping Yi.String( Yi/String.hs, Yi/String.o )
...
[37 of 38] Skipping Yi ( Yi.hs, Yi.o )
[38 of 38] Compiling Main ( Main.hs, Main.o )
/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage1/ghc-inplace
-o yi-static -L/usr/local/lib -package-conf yi.conf -package yi -package yi
Main.o Yi.o
Note that nothing is recompiled -- only Main.hs (though there appears to be an
unneccessary recompilation of Yi.Undo.hs-boot, btw).
The .hi file for Main.hs in fact turns out as desired:
interface Main 1 6050 where
export Main main
module dependencies: Yi
package dependencies: base-1.0 mtl-1.0 yi-0.1
despite --make chasing module depends in Yi/*
So I'm wondering if ghc is getting confused by the fact that Main depends on
things in Yi/*, but isn't supposed to actually use that directory directly for
any dependencies (it should use -package yi)?
-- Don
--
Comment By: Don Stewart (dons)
Date: 2005-08-04 12:48
Message:
Logged In: YES
user_id=880987
I get the same result with HEAD too. It seems to have emerged in the
last few days, stable branch from July 20 builds fine.
To reproduce:
darcs get --set-scripts-executable http://www.cse.unsw.edu.au/~dons/code/yi
cd yi
./configure --with-ghc=ghc-6.5
make way=static
which results in:
/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage1/ghc-inplace
-Wall -Werror -Icbits -Imk -funbox-strict-fields -O2 -fasm -threaded
-I/usr/local/include -package-conf yi.conf -package yi -i -Icbits -Imk -c Yi.hs
-o Yi.o -ohi Yi.hi
/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage1/ghc-inplace
-Wall -Werror -Icbits -Imk -funbox-strict-fields -O2 -fasm -threaded
-I/usr/local/include -package-conf yi.conf -package yi -c Main.hs -o Main.o
-ohi Main.hi
Yi.hi :
Interface file inconsistency:
home-package module `Yi.Editor' is mentioned,
but does not appear in the depende
[ ghc-Bugs-1251699 ] ghc-6.4.1.20050801: panic!
Bugs item #1251699, was opened at 2005-08-04 09:03
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1251699&group_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.20050801: panic!
Initial Comment:
Hi!
I've pulled the latest Yi code from the darcs
repository and tried to compile it with 'make
way=static' using ghc-6.4.1.20050801 compiler.
Here is the result:
[...]
ghc -Wall -Werror -Icbits -Imk -funbox-strict-fields
-O2 -fasm -threaded -package-conf yi.conf
-package yi -i -Icbits -Imk -c Yi.hs -o Yi.o -ohi Yi.hi
ghc -Wall -Werror -Icbits -Imk -funbox-strict-fields
-O2 -fasm -threaded -package-conf yi.conf
-package yi -c Main.hs -o Main.o -ohi Main.hi
./Yi.hi :
Interface file inconsistency:
home-package module `Yi.Editor' is mentioned,
but does not appear in the dependencies of the
interface
ghc-6.4.1.20050801: panic! (the `impossible'
happened, GHC version 6.4.1.20050801):
forkM Declaration for staticzumain{v}
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Sincerely,
Gour
--
>Comment By: Simon Marlow (simonmar)
Date: 2005-08-11 12:48
Message:
Logged In: YES
user_id=48280
I tried to reproduce this just now and failed - the build
goes through for me with 6.4.1.20050801.
However, from your description of the problem, I can imagine
there might be problems. I'd still like to find out exactly
what causes the crash, though.
--
Comment By: Don Stewart (dons)
Date: 2005-08-04 11:47
Message:
Logged In: YES
user_id=880987
Seems we can work around this by adding --make when compiling Main.hs
(though we shouldn't have to):
/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage1/ghc-inplace
-Wall -Werror -Icbits -Imk -funbox-strict-fields -O2 -fasm -threaded
-I/usr/local/include -package-conf yi.conf -package yi -package yi --make -c
Main.hs -o Main.o
Chasing modules from: Main.hs
[ 1 of 38] Skipping Yi.Version ( Yi/Version.hs, Yi/Version.o )
[ 2 of 38] Compiling Yi.Undo[boot]( Yi/Undo.hs-boot, Yi/Undo.o-boot )
[ 3 of 38] Skipping Yi.Style ( Yi/Style.hs, Yi/Style.o )
[ 4 of 38] Skipping Yi.String( Yi/String.hs, Yi/String.o )
...
[37 of 38] Skipping Yi ( Yi.hs, Yi.o )
[38 of 38] Compiling Main ( Main.hs, Main.o )
/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage1/ghc-inplace
-o yi-static -L/usr/local/lib -package-conf yi.conf -package yi -package yi
Main.o Yi.o
Note that nothing is recompiled -- only Main.hs (though there appears to be an
unneccessary recompilation of Yi.Undo.hs-boot, btw).
The .hi file for Main.hs in fact turns out as desired:
interface Main 1 6050 where
export Main main
module dependencies: Yi
package dependencies: base-1.0 mtl-1.0 yi-0.1
despite --make chasing module depends in Yi/*
So I'm wondering if ghc is getting confused by the fact that Main depends on
things in Yi/*, but isn't supposed to actually use that directory directly for
any dependencies (it should use -package yi)?
-- Don
--
Comment By: Don Stewart (dons)
Date: 2005-08-04 10:48
Message:
Logged In: YES
user_id=880987
I get the same result with HEAD too. It seems to have emerged in the
last few days, stable branch from July 20 builds fine.
To reproduce:
darcs get --set-scripts-executable http://www.cse.unsw.edu.au/~dons/code/yi
cd yi
./configure --with-ghc=ghc-6.5
make way=static
which results in:
/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage1/ghc-inplace
-Wall -Werror -Icbits -Imk -funbox-strict-fields -O2 -fasm -threaded
-I/usr/local/include -package-conf yi.conf -package yi -i -Icbits -Imk -c Yi.hs
-o Yi.o -ohi Yi.hi
/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage1/ghc-inplace
-Wall -Werror -Icbits -Imk -funbox-strict-fields -O2 -fasm -threaded
-I/usr/local/include -package-conf yi.conf -package yi -c Main.hs -o Main.o
-ohi Main.hi
Yi.hi :
Interface file inconsistency:
home-package module `Yi.Editor' is mentioned,
but does not appear in the dependencies of the interface
ghc-6.5: panic! (the `impossible' happened, GHC version 6.5):
forkM Declaration for staticzumain{v}
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or
RE: stdin set to nonblocking mode
On 11 August 2005 01:18, John Meacham wrote: > Why do we set file descriptors to nonblocking mode anyway if they are > waited on by a select. there shouldn't be a need to use both It avoids an extra system call per read(), i.e. a single read() instead of select() + read(). And there's a slight chance of a race between the select() and read() calls, if some other thread or process is reading from the same descriptor. With non-blocking read(), this isn't an issue. The overhead of the extra syscall is probably a non-issue, but the race is mildly worrying. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Cabal on OS X; ghc segfault?
On 11 August 2005 04:05, Andre Pang wrote:
> On 23/07/2005, at 12:12 AM, Gregory Wright wrote:
>
>> I'm trying to get caballized package deployment working on Mac OS X.
>>
>> However, trying to build a package using runhaskell results in:
>>
>>
>> crossroads-able> runhaskell Setup.hs configure
>> Warning: No license-file field.
>> Configuring harp-0.2...
>> configure: searching for ghc in path.
>> configure: found ghc at /opt/local/bin/ghc
>> runhaskell: waitForProcess: interrupted (Interrupted system call)
>
> Hi Gregory, you may be happy (I think :) to know I'm having this
> problem too on Mac OS X, so it's not just you. So far, I've found
> that compiling Setup.hs ("ghc --make -o setup Setup.hs") and then
> running the resulting ./setup executable has never caused a problem,
> whereas I get the same waitForProcess error message that you do when
> I use runhaskell.
>
> It would be worthwhile seeing whether using GHCi to invoke Setup.hs
> causes a similar problem.
Hi Andre,
Greg reported that the problem was fixed in 6.4.1 GHC snapshots. Can
you try that?
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: --make and -main-is still not working together?
Ah I see now. The underlying problem is that GHC's "no need to recompile" check takes account of changes in the source file, but does not take into account changes in the flags. So it skipped recompiling Test2, but it should have recompiled it to make the -main-is take effect. Failing to do so gives a bad error message, as you found. I've filed a sourceforge bug, but I doubt we'll get to it quickly. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Niels | Sent: 11 August 2005 09:29 | To: glasgow-haskell-bugs@haskell.org | Subject: Re: --make and -main-is still not working together? | | > I can't reproduce this failure: | > | > ~/scratch > cat ModName/Main.hs | > module ModName.Main where | > main=print "hello" | > ~/scratch > ghc -o out --make ModName/Main.hs -main-is ModName.Main.main | > Chasing modules from: ModName/Main.hs | > Skipping ModName.Main ( ModName/Main.hs, ModName/Main.o ) | > Linking ... | > | > This is 6.4 on x86/Linux. Is there anything I'm missing? | | 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. | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1256533 ] Recompilation check should include flags
Bugs item #1256533, was opened at 2005-08-11 09:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1256533&group_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: 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=detail&atid=108032&aid=1256533&group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-635718 ] Bad space behaviour with huge input file
Bugs item #635718, was opened at 2002-11-08 23:43 Message generated for change (Comment added) made by ajk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=635718&group_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: 5.04 Status: Closed Resolution: Rejected Priority: 6 Submitted By: Antti-Juhani Kaijanaho (ajk) Assigned to: Simon Peyton Jones (simonpj) Summary: Bad space behaviour with huge input file Initial Comment: The attached files (actually, just UnicodeData.hs but the other file is imported by it) trigger very bad space and time behaviour in ghc during compilation. One attempt went up to 500 MB of virtual memory (256 physical available) on my i386 machine. The compilation ran for more than an hour until killed (stuck in the rename phase). I had another version (available on request) of this that has all the data in a string, compiled into an object file using gcc (in no time!), accessed using FFI and then using read made into a real data structure. The program, looking up one entry in the resulting FiniteMap, has a memory hit of approximately 130 MB and runs in one minute (which, while still too much, is bearable). So it seems there is lots to improve in the compiler in this case (we are essentially talking about the same process taking way too much time and memory when done by the compiler, compared to the program itself doing it - and even then the memory requirement is outrageous). Even some sort of special-casing pragma that allows me to ask for lighter treatment of pure data would be good (and a way to statically initialize a FiniteMap...) I'm sorry but I do not have any simpler input files to offer. -- >Comment By: Antti-Juhani Kaijanaho (ajk) Date: 2005-08-11 11:39 Message: Logged In: YES user_id=14329 Ok. I can relate to that :) Some background: When I originally submitted this bug, I had already tried many ways of achieving what I wanted; some of them involved constant expressions, some didn't. All of them had bad space/time behaviour; what I submitted was what I had when I gave up. The best solution I found involved a C string foreign-imported and parsed at Haskell side at run-time, like I indicated in the original message. I'm now satisfied with your response (in case it isn't apparent:). -- Comment By: Simon Marlow (simonmar) Date: 2005-08-11 11:22 Message: Logged In: YES user_id=48280 Ok, the syntax errors aren't really syntax errors. You missed the "0x" off the front of many hex constants, with the results that things like 000A is two lexemes. It parsed ok, but the renamer would have caught the errors. The point is I don't know whether we should expect GHC to be able to compile this module in reasonable time/space. The requirements are likely to increase non-linearly with the size of the program, because it is one huge non-constant nested exrpression. 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). -- Comment By: Antti-Juhani Kaijanaho (ajk) Date: 2005-08-11 10:54 Message: Logged In: YES user_id=14329 Of course it is a huge file. That's the whole point of this bug report :) And as to it being syntactically invalid, and having type errors - I believe this is all the more reason to fix this. How am I supposed to fix these issues if the compiler does not give me a diagnostic? I can appreciate that typechecking can have inherently bad space/time behaviour for pathetic cases, but if we are talking about a syntactically invalid file, the compiler should not even get to typechecking, now should it. Parsing, however, is a well-understood part of computer science and has no such nasty surprises. -- Comment By: Simon Marlow (simonmar) Date: 2005-08-10 18:03 Message: Logged In: YES user_id=48280 This source file is simply huge (6M) and contains a single large nested non-constant expression. Also, it isn't syntactically correct, and even when the syntax errors are fixed it has type errors. I'm going to close this bug. Feel free to submit more examples of code that GHC takes too long to compile, but there's not much we can do with this one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=635718&group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/gl
Re: --make and -main-is still not working together?
> I can't reproduce this failure: > > ~/scratch > cat ModName/Main.hs > module ModName.Main where > main=print "hello" > ~/scratch > ghc -o out --make ModName/Main.hs -main-is ModName.Main.main > Chasing modules from: ModName/Main.hs > Skipping ModName.Main ( ModName/Main.hs, ModName/Main.o ) > Linking ... > > This is 6.4 on x86/Linux. Is there anything I'm missing? 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. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-635718 ] Bad space behaviour with huge input file
Bugs item #635718, was opened at 2002-11-08 21:43 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=635718&group_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: 5.04 Status: Closed Resolution: Rejected Priority: 6 Submitted By: Antti-Juhani Kaijanaho (ajk) Assigned to: Simon Peyton Jones (simonpj) Summary: Bad space behaviour with huge input file Initial Comment: The attached files (actually, just UnicodeData.hs but the other file is imported by it) trigger very bad space and time behaviour in ghc during compilation. One attempt went up to 500 MB of virtual memory (256 physical available) on my i386 machine. The compilation ran for more than an hour until killed (stuck in the rename phase). I had another version (available on request) of this that has all the data in a string, compiled into an object file using gcc (in no time!), accessed using FFI and then using read made into a real data structure. The program, looking up one entry in the resulting FiniteMap, has a memory hit of approximately 130 MB and runs in one minute (which, while still too much, is bearable). So it seems there is lots to improve in the compiler in this case (we are essentially talking about the same process taking way too much time and memory when done by the compiler, compared to the program itself doing it - and even then the memory requirement is outrageous). Even some sort of special-casing pragma that allows me to ask for lighter treatment of pure data would be good (and a way to statically initialize a FiniteMap...) I'm sorry but I do not have any simpler input files to offer. -- >Comment By: Simon Marlow (simonmar) Date: 2005-08-11 08:22 Message: Logged In: YES user_id=48280 Ok, the syntax errors aren't really syntax errors. You missed the "0x" off the front of many hex constants, with the results that things like 000A is two lexemes. It parsed ok, but the renamer would have caught the errors. The point is I don't know whether we should expect GHC to be able to compile this module in reasonable time/space. The requirements are likely to increase non-linearly with the size of the program, because it is one huge non-constant nested exrpression. 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). -- Comment By: Antti-Juhani Kaijanaho (ajk) Date: 2005-08-11 07:54 Message: Logged In: YES user_id=14329 Of course it is a huge file. That's the whole point of this bug report :) And as to it being syntactically invalid, and having type errors - I believe this is all the more reason to fix this. How am I supposed to fix these issues if the compiler does not give me a diagnostic? I can appreciate that typechecking can have inherently bad space/time behaviour for pathetic cases, but if we are talking about a syntactically invalid file, the compiler should not even get to typechecking, now should it. Parsing, however, is a well-understood part of computer science and has no such nasty surprises. -- Comment By: Simon Marlow (simonmar) Date: 2005-08-10 15:03 Message: Logged In: YES user_id=48280 This source file is simply huge (6M) and contains a single large nested non-constant expression. Also, it isn't syntactically correct, and even when the syntax errors are fixed it has type errors. I'm going to close this bug. Feel free to submit more examples of code that GHC takes too long to compile, but there's not much we can do with this one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=635718&group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-635718 ] Bad space behaviour with huge input file
Bugs item #635718, was opened at 2002-11-08 23:43 Message generated for change (Comment added) made by ajk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=635718&group_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: 5.04 Status: Closed Resolution: Rejected Priority: 6 Submitted By: Antti-Juhani Kaijanaho (ajk) Assigned to: Simon Peyton Jones (simonpj) Summary: Bad space behaviour with huge input file Initial Comment: The attached files (actually, just UnicodeData.hs but the other file is imported by it) trigger very bad space and time behaviour in ghc during compilation. One attempt went up to 500 MB of virtual memory (256 physical available) on my i386 machine. The compilation ran for more than an hour until killed (stuck in the rename phase). I had another version (available on request) of this that has all the data in a string, compiled into an object file using gcc (in no time!), accessed using FFI and then using read made into a real data structure. The program, looking up one entry in the resulting FiniteMap, has a memory hit of approximately 130 MB and runs in one minute (which, while still too much, is bearable). So it seems there is lots to improve in the compiler in this case (we are essentially talking about the same process taking way too much time and memory when done by the compiler, compared to the program itself doing it - and even then the memory requirement is outrageous). Even some sort of special-casing pragma that allows me to ask for lighter treatment of pure data would be good (and a way to statically initialize a FiniteMap...) I'm sorry but I do not have any simpler input files to offer. -- >Comment By: Antti-Juhani Kaijanaho (ajk) Date: 2005-08-11 10:54 Message: Logged In: YES user_id=14329 Of course it is a huge file. That's the whole point of this bug report :) And as to it being syntactically invalid, and having type errors - I believe this is all the more reason to fix this. How am I supposed to fix these issues if the compiler does not give me a diagnostic? I can appreciate that typechecking can have inherently bad space/time behaviour for pathetic cases, but if we are talking about a syntactically invalid file, the compiler should not even get to typechecking, now should it. Parsing, however, is a well-understood part of computer science and has no such nasty surprises. -- Comment By: Simon Marlow (simonmar) Date: 2005-08-10 18:03 Message: Logged In: YES user_id=48280 This source file is simply huge (6M) and contains a single large nested non-constant expression. Also, it isn't syntactically correct, and even when the syntax errors are fixed it has type errors. I'm going to close this bug. Feel free to submit more examples of code that GHC takes too long to compile, but there's not much we can do with this one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=635718&group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
