Re: small errors in ghc 6.6

2006-09-19 Thread Einar Karttunen
On 19.09 21:28, Tomasz Zielonka wrote:
> On Tue, Sep 19, 2006 at 09:13:56PM +0200, Rene de Visser wrote:
> > I would suggest -fforce-recomp for force recompilation.
> 

-frecompile-all

- Einar Karttunen
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: small errors in ghc 6.6

2006-09-19 Thread Tomasz Zielonka
On Tue, Sep 19, 2006 at 09:13:56PM +0200, Rene de Visser wrote:
> I would suggest -fforce-recomp for force recompilation.

I like it.

Best regards
Tomasz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: small errors in ghc 6.6

2006-09-19 Thread Rene de Visser
"Tomasz Zielonka" <[EMAIL PROTECTED]> schrieb im Newsbeitrag 
news:[EMAIL PROTECTED]
> BTW. The -fno-recomp option has a very unintuitive name, at least for
> me. When I see "-fno-recomp", my brain thinks "no recompilation",
> meaning "no unneccesary recompilation", which is what --make does by
> default. Using "-fno-recomp" causes all modules to be recompiled,
> whether they changed or not. I think one of -frecomp or
> -fno-recomp-checking would be much clearer. But it's probably too
> late to change that...

I believe this is worth fixing. Everytime I see "-fno-recomp" I always read 
it as no recompilation.
A synonym could be added in 6.6.
I would suggest -fforce-recomp for force recompilation.

In 6.8 -fno-recomp could be flagged as obsolete.
In 7.0 it could be removed.

Rene.



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: small errors in ghc 6.6

2006-09-19 Thread Tomasz Zielonka
On Tue, Sep 19, 2006 at 02:33:46PM +0400, Bulat Ziganshin wrote:
> 3. ghc 6.6 includes smart relinking capability which don't relink exe
> file if it already exists and .hs source files was not changed. that's
> great but ignores other .o files that can be also linked to program,
> for example those that was compiled from C sources:
> 
> gcc -c -o a.o a.c
> ghc --make Main.hs a.o
> 
> this command incorrectly don't relinks executable if a.c was changed
> but Main.hs wasn't

The is another similar problem. Let's say I have an up-to-date compiled
program and I want to recompile it with profiling turned on.  In older
ghc version adding -prof option caused all modules to be recompiled and
the whole application relinked. Now I have to manually delete the
application binary to force recompilation or use -fno-recomp.

BTW. The -fno-recomp option has a very unintuitive name, at least for
me. When I see "-fno-recomp", my brain thinks "no recompilation",
meaning "no unneccesary recompilation", which is what --make does by
default. Using "-fno-recomp" causes all modules to be recompiled,
whether they changed or not. I think one of -frecomp or
-fno-recomp-checking would be much clearer. But it's probably too
late to change that...

Best regards
Tomasz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


small errors in ghc 6.6

2006-09-19 Thread Bulat Ziganshin
Hello glasgow-haskell-users,

i've put my hands on the ghc 6.6/mingw32 dated 1st september
(http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-mingw32.tar.gz)

overall, compilation of my 5 kloc application was fine. on the
6.2->6.4 transition, i was bitten by two API changes, but this time
all APIs and language features i used remains stable. it's great!

the most funny part was that parallel arrays are still work :)))


nevertheless, i've captured several minor problems:

1. ghc +RTS -A10m aborts with the message:

ghc.exe: getMBlocks: VirtualAlloc MEM_COMMIT failed: The parameter is incorrect.

although i guess that it was already fixed since 1st September. btw,
how about adding using various RTS switches to ghc as test cases? GHC
is very large program and any problems with RTS flags would be captured in
this way


2. ghc compilation don't includes directory where Rts.h, Stg.h and
similar files resides, "$(GHC)\lib\i386-unknown-mingw32\include" on my
installation. it results in failing of via-C compilation, compilation
of *stub.c files, and inclusion of "Typeable.h". i was going around
this problem by using -I switch. it's possible that it's just
packaging problem. again - isn't it possible to catch this problem by
testsuite?

imho, that this error was not catched means that windows version isn't
really tested by anyone? how about trying to build various packages on
mingw32 version as test before releasing 6.6?


3. ghc 6.6 includes smart relinking capability which don't relink exe
file if it already exists and .hs source files was not changed. that's
great but ignores other .o files that can be also linked to program,
for example those that was compiled from C sources:

gcc -c -o a.o a.c
ghc --make Main.hs a.o

this command incorrectly don't relinks executable if a.c was changed
but Main.hs wasn't


-- 
Best regards,
 Bulat  mailto:[EMAIL PROTECTED]

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users