GHC from CVS HEAD does not require that the Main module export main

2005-06-13 Thread Brian Smith
The Haskell 98 report says A Haskell program is a collection of
modules, one of which, by convention, must be called Main and must
export the value main. However, the program below builds and executes
fine.

module Main() -- should be module Main or module Main(main)
where
main = putStrLn Hello, World

$ runghc Main.hs
Hello, World
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


GHC from CVS

2001-04-10 Thread Ralf Hinze

Dear all,

after the failed attempts to install ghc 5.00 from
the packages you provide, I downloaded ghc from the
cvs repository. It compiles just fine except that ghci
is not built:

 ghci
ghc-5.00: not built for interactive use

Do I have to specify this explicitly?

Cheers, Ralf


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs



Re: GHC from CVS

2001-04-10 Thread Marcus Shawcroft

Ralf Hinze wrote:

 It compiles just fine except that ghci is not built:
  ghci
 ghc-5.00: not built for interactive use

 Do I have to specify this explicitly?

 Cheers, Ralf

Hi

ghci is not built unless you are compiling with ghc 4.11 or better. Try
rebuilding ghc using the 5.00 version that you have just built.

/Marcus




I think you will find that ghci is not built



 ___
 Glasgow-haskell-bugs mailing list
 [EMAIL PROTECTED]
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

--
Marcus Shawcroft
Ericsson Mobile Applications




___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs



RE: GHC from CVS

2001-04-10 Thread Julian Seward (Intl Vendor)


| after the failed attempts to install ghc 5.00 from
| the packages you provide, I downloaded ghc from the
| cvs repository. It compiles just fine except that ghci
| is not built:
| 
|  ghci
| ghc-5.00: not built for interactive use
| 
| Do I have to specify this explicitly?

No.  Interactive use is only available when HEAD compiles HEAD.

I tested the installation on a Suse 7.1 box here last night.
Yes, there are problems, which we hope to fix.  In the meantime
it is easy to get an install working -- the only issue is
the readline.so problem.  We fixed this by making libreadline.so.3
be a symlink to libreadline.so.4, and then GHCi started up fine.

So I suggest you do that too.

I'll look into the make install-docs problem today.

J

___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs



Re: GHC from CVS

2001-04-10 Thread Jeffrey R. Lewis

Marcus Shawcroft wrote:

 Ralf Hinze wrote:

  It compiles just fine except that ghci is not built:
   ghci
  ghc-5.00: not built for interactive use
 
  Do I have to specify this explicitly?
 
  Cheers, Ralf

 Hi

 ghci is not built unless you are compiling with ghc 4.11 or better. Try
 rebuilding ghc using the 5.00 version that you have just built.


And to get a usable system, I've found that you have to compile it with
itself again - i.e. compile it three times.  Unless I bootstrap to stage
3, recompilation is hopelessly confused: compile a program from scratch -
no problem, but make a simple modification, then recompile, and you're
likely to get all kinds of strange linker errors.

--Jeff



___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs



RE: GHC from CVS

2001-04-10 Thread Julian Seward (Intl Vendor)


| And to get a usable system, I've found that you have to 
| compile it with
| itself again - i.e. compile it three times.  Unless I 
| bootstrap to stage
| 3, recompilation is hopelessly confused: compile a program 
| from scratch -
| no problem, but make a simple modification, then recompile, and you're
| likely to get all kinds of strange linker errors.

Wa?!  We've worked correctly for months with using stage2
bootstraps.  If stage2 /= stage3, something is seriously
wrong.  

Can you send some details of the kinds of problems you get?

J

___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs



works (was: Re: ghc from CVS (1999/07/31) throws core...)

1999-08-04 Thread Michael Weber

On Tue, Aug 03, 1999 at 01:49:36 -0700, Simon Marlow wrote:
 Yesterday's sources were fully broken due to a bogus commit made by me.
 Things should be ok now.

Bad luck to me :-(

However, I just wanted to give some feedback that now it's working again
(1999/08/03) on Linux (packages downloadable this afternoon).


Cheers,
Michael
-- 
W*ndoze NT is faster... CRASHING!



Re: ghc from CVS (1999/07/31) throws core...

1999-08-03 Thread Kevin GLYNN


Hmmm,  just a me-too :-(

it dies very quickly,  just after a couple of calls to times according 
to strace and possibly in a function called Main_main_info() according 
to gdb. 


k



Michael Weber writes:
  
  But my core dumps, don't give any "blahblah exception (core dumped)"
  messages. The programs just die (at a very early stage). I still think, it's
  something with glibc stuff...
  
  
  Cheers,
  Michael
  -- 
  XXXVI:  The thickness of the proposal required to win a multimillion dollar
  contract is about one millimeter per million dollars.  If all the
  proposals conforming to this standard were piled on top of each other
  at the bottom of the Grand Canyon it would probably be a good idea.
  



RE: ghc from CVS (1999/07/31) throws core...

1999-08-03 Thread Simon Marlow


 I wish, I could have provided more debugging info, but 
 strace's and gdb's
 output isn't very helpful at all. How do I enable those 
 IF_DEBUG(...) macros
 (or something that helps tracking down the problem)? I tried, 
 but it seems I
 overlooked something...

I add the following lines to my build.mk to build a debugging RTS:

GhcRtsHcOpts = -optc-DDEBUG
GhcRtsCcOpts = -optc-g
SRC_HC_OPTS += -lbfd -liberty
STRIP=echo

Cheers,
Simon



RE: ghc from CVS (1999/07/31) throws core...

1999-08-03 Thread Simon Marlow

 $ cat tmp.lhs
  module Main( main ) where
  main = putStr $ show q
   where q = quot 1 0
 $ ghc-4.02 tmp.lhs
 ghc-4.02: module version changed to 176; reason: usages changed
  1006 swift ~/ghc/constraints/mixed
 $ a.out
 
 Fail: Prelude.Integral.quot{Integer}: divide by 0
  1007 swift ~/ghc/constraints/mixed
 $ ghc-4.04 tmp.lhs
 ghc-4.04: module version changed to 177; reason: usages changed
  1008 swift ~/ghc/constraints/mixed
 $ a.out
 Arithmetic Exception (core dumped)

I'm afriad that one's my fault; the definition of quot for Integers changed
in 4.04.  Anyway, testing for divide by zero isn't required by the Haskell
report.

Cheers,
Simon



Re: ghc from CVS (1999/07/31) throws core...

1999-08-02 Thread Marc van Dongen

: Hi!
: 
: I tried to recompile the latest ghc (1999/07/31) on a Linux/glibc2.1.1
: system (egcs 2.91.66), but there seems to be a problem: the build works, but
: the resulting compiler produces executables, that throw core, even with
: "main = return ()".

I've noticed that as well. Code like

does not produce proper error messages anymore which it did with
ghc-4.02. One wonders where the performance boost came from:-)

$ cat tmp.lhs
 module Main( main ) where
 main = putStr $ show q
  where q = quot 1 0
$ ghc-4.02 tmp.lhs
ghc-4.02: module version changed to 176; reason: usages changed
 1006 swift ~/ghc/constraints/mixed
$ a.out

Fail: Prelude.Integral.quot{Integer}: divide by 0
 1007 swift ~/ghc/constraints/mixed
$ ghc-4.04 tmp.lhs
ghc-4.04: module version changed to 177; reason: usages changed
 1008 swift ~/ghc/constraints/mixed
$ a.out
Arithmetic Exception (core dumped)


Regards,


Marc van Dongen



ghc from CVS (1999/07/31) throws core...

1999-08-02 Thread Michael Weber

Hi!

I tried to recompile the latest ghc (1999/07/31) on a Linux/glibc2.1.1
system (egcs 2.91.66), but there seems to be a problem: the build works, but
the resulting compiler produces executables, that throw core, even with
"main = return ()".

I have a CVS version from 1999/07/10, and this one works. I subsequently
recompiled this version with itself several times, no problem.

Since the old version still compiles (I tried this night), and also Manuel
produced a glibc2.1 version of ghc: did anyone change some parts of the rts
or compiler, that could be touchy to specific glibc versions? Or is the
problem related elsewhere?

I wish, I could have provided more debugging info, but strace's and gdb's
output isn't very helpful at all. How do I enable those IF_DEBUG(...) macros
(or something that helps tracking down the problem)? I tried, but it seems I
overlooked something...

However, I "hello-debugged" the problematic version and traced it to
ghc/rts/Schedule.c:

case ThreadEnterGHC:
  ret = StgRun((StgFunPtr) stg_enterStackTop);


The case statement is reached, but then the segmentation fault happens
somewhere in StgRun() or something it calls (*hmm* I don't regard this info
as very helpful at all, since this is pretty early in the startup
process...)


Cheers,
Michael
-- 
* Software Engineering is like looking for a black cat in a dark room in
  which there is no cat.
* Systems Engineering is like looking for a black cat in a dark room in
  which there is no cat and someone yells "I got it!"



Re: ghc from CVS (1999/07/31) throws core...

1999-08-02 Thread Michael Weber

On Mon, Aug 02, 1999 at 12:54:23 +0100, Marc van Dongen wrote:
[...]
 I've noticed that as well. Code like
 
 does not produce proper error messages anymore which it did with
 ghc-4.02. One wonders where the performance boost came from:-)
 
 $ cat tmp.lhs
  module Main( main ) where
  main = putStr $ show q
   where q = quot 1 0
[...]
 $ a.out
 Arithmetic Exception (core dumped)

Yes, but:

\begin{code}
module Main( main ) where
main = putStr $ show q
 where q = quot 1 (0::Int)
\end{code}
gives: Fail: Prelude.Integral.quot{Int}: divide by 0

IIRC, Integer isn't Div-By-Zero-checked (for performance reasons).

But my core dumps, don't give any "blahblah exception (core dumped)"
messages. The programs just die (at a very early stage). I still think, it's
something with glibc stuff...


Cheers,
Michael
-- 
XXXVI:  The thickness of the proposal required to win a multimillion dollar
contract is about one millimeter per million dollars.  If all the
proposals conforming to this standard were piled on top of each other
at the bottom of the Grand Canyon it would probably be a good idea.