Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?

[Sigbjorn Finne]

Simon Marlow wrote:

On 29/04/2009 01:23, Sigbjorn Finne wrote:

Thanks Simon,

sorry for not noticing your reply amidst the flow of g-h-b ticket 
reports

before now. As there is no need to sail that close to the wind of
playing with the delicate linking & loading orders of the CRT and
base DLLs like kernel32, my suggestion would be simply to avoid
it. You don't do any explicit "-lgcc -lc" trickery when invoking gcc/ld
on other platforms, so why be different?

Apart from the changes to Win32.cabal and base.cabal mentioned
in the original e-mail, injecting addDLL() calls for kernel32 and
msvcrt in initLinker() ought to do it.


I've now done exactly that.  This seems like a good fix to try to get 
into 6.10.4 - can you think of any unexpected consequences?


Cool, given that the RTS already has those two DLLs loaded & repeated 
addDLL()s
is fine (i.e., if other packages contain e.g., "kernel32" uses), I can't 
think of any...other

than possibly more contribs from people building on Windows ;-)

If you feel the risk is not worth taking for 6.10.4, I'm totally fine 
with pushing it out.


thanks,
--sigbjorn

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

Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?

[Sigbjorn Finne]

Thanks Simon,

sorry for not noticing your reply amidst the flow of g-h-b ticket reports
before now. As there is no need to sail that close to the wind of
playing with the delicate linking & loading orders of the CRT and
base DLLs like kernel32, my suggestion would be simply to avoid
it. You don't do any explicit "-lgcc -lc" trickery when invoking gcc/ld
on other platforms, so why be different?

Apart from the changes to Win32.cabal and base.cabal mentioned
in the original e-mail, injecting addDLL() calls for kernel32 and
msvcrt in initLinker() ought to do it.

--sigbjorn

On 4/27/2009 04:58, Simon Marlow wrote:

On 24/04/2009 23:04, Sigbjorn Finne wrote:

I've been experiencing repeated woes over the past 4-5 months
when trying to spin up build trees on Windows with the new build
system. This is happening on the 3-4 boxes that I regularly develop on,
which leads me to believe that this may not be limited to just me..

The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when
compiled and linked via the 'ghc' that's configured against, will 
produce
.exe's that crashes right out of the gates. gdb'ing the generated 
binaries,
the crash is happening in the CRT startup code & with some further 
poking
around I've been able to determine that it is the explicit presence 
of "-l"
options for 'kernel32' and 'msvcrt' when linking that's the cause. 
This is
with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 
2.19).

Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is
well-behaved, but ghc is still using gcc-3.4.5.


We have seen this problem here on Satnam Singh's machine, but we 
eventually put it down to a conflict between versions of certain MSYS 
bits.  There may indeed be a real problem here, I don't know.


On Satnam's machine we established that the problem was provoked by 
updating binutils, and the solution was "don't do that" (Satnam had 
originally done this because the windres that comes with MSYS was 
incompatible with GHC, but that can be worked around by just copying 
in a suitable windres).


We also tracked it down as far as compiling a trivial C program with 
-lmsvcrt.


Incedentally if you follow the instructions on the wiki exactly, you 
won't run into this problem: 
http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows.



There's a couple of things that are odd here:

* base.cabal files have kernel32 and msvcrt as extra-libraries. This is
clearly
not required when doing invocations via ld(1), and causes considerable
mischief,
so it'd be good if there was a way in .cabal files to distinguish
between stuff that
goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's
InstalledPackageInfos. (Is there? Couldn't locate anything appropriate
while
working with the Cabal sources..)

* 'base' needing to include these two dependencies even for GHCi 
usage. A

running RTS will have these loaded already, so it really ought to have
primed
the list of opened DLLs by explicitly loading them upon initialization
of the linker.
[I've got a trivial patch against rts/Linker.c that does this; can
forward/commit if
of interest..]


I've no idea why these library dependencies are there.  It might well 
be historical.  I'm happy to defer to Windows experts such as yourself 
on whether we should have them or not (I guess not?).



* In addition to the patch referred to above, to solve these problems, I
had to scrub
libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the
package.conf's for the
versions of ghc I'm building against had to be edited, limiting the use
of 'kernel32'
and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32'
packages.

Long and rambling..hope you made it this far ;-) Is anyone else running
into this issue &
should we do something about it? If not, details of compilation
environment that
you've got that avoids running into this issue would be most welcome.
It's a bit of a
chore spinning up new builds, as is.


One open question is whether we should expect "gcc foo.c -lmsvcrt" to 
work.  It works with older versions of MSYS/mingw, but apparently not 
with more recent versions.  On the face of it this seems like it ought 
to be harmless, since msvcrt will eventually be linked in anyway.


Cheers,
Simon


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

Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?

[Sigbjorn Finne]

Oh, and a simple test case:

foo$ cat a.c
int main() { return 0; }
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c
foo$ ./a ; echo $?
0
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c -lkernel32
foo$ ./a ; echo $?
0
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c -lkernel32 -lmsvcrt
foo$ ./a ; echo $?

5
foo$

--sigbjorn

On 4/25/2009 11:38, Sigbjorn Finne wrote:

On 4/25/2009 05:37, Ian Lynagh wrote:

Hi Sigbjorn,

On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote:
 

I've been experiencing repeated woes over the past 4-5 months
when trying to spin up build trees on Windows with the new build
system.



By "new build system" do you mean
http://darcs.haskell.org/ghc-new-build-system/
?
  

Hi Ian,

young and old. The above one + ones using the older (git & darcs 
versions)



The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when
compiled and linked via the 'ghc' that's configured against, will 
produce

.exe's that crashes right out of the gates.



Do you mean that building GHC fails, or that building other things using
the built GHC fails? If the latter, can you give a testcase please?


  
Right, when building the repo contents. Any .hsc that's in the tree 
elicits a hard crash (i.e.,
dialog box pops up reporting the failure of any *_hsc_make.exe ) This 
is when building with

6.10.1, but that's not the real cause here.

If I don't take the evasive action (as outlined in the original 
e-mail), the resulting stage1/stage2
ghc installs will fail also (provided I've manually guided the build 
process past these crashes

to reach completion first, of course.)

hth
--sigbjorn

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


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

Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?

[Sigbjorn Finne]

On 4/25/2009 05:37, Ian Lynagh wrote:

Hi Sigbjorn,

On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote:
  

I've been experiencing repeated woes over the past 4-5 months
when trying to spin up build trees on Windows with the new build
system.



By "new build system" do you mean
http://darcs.haskell.org/ghc-new-build-system/
?
  

Hi Ian,

young and old. The above one + ones using the older (git & darcs versions)


The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when
compiled and linked via the 'ghc' that's configured against, will produce
.exe's that crashes right out of the gates.



Do you mean that building GHC fails, or that building other things using
the built GHC fails? If the latter, can you give a testcase please?


  
Right, when building the repo contents. Any .hsc that's in the tree 
elicits a hard crash (i.e.,
dialog box pops up reporting the failure of any *_hsc_make.exe ) This is 
when building with

6.10.1, but that's not the real cause here.

If I don't take the evasive action (as outlined in the original e-mail), 
the resulting stage1/stage2
ghc installs will fail also (provided I've manually guided the build 
process past these crashes

to reach completion first, of course.)

hth
--sigbjorn

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

Linking hsc2hs .c output on Windows w/ build system: is it just me..?

[Sigbjorn Finne]

Hi,

I've been experiencing repeated woes over the past 4-5 months
when trying to spin up build trees on Windows with the new build
system. This is happening on the 3-4 boxes that I regularly develop on,
which leads me to believe that this may not be limited to just me..

The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when
compiled and linked via the 'ghc' that's configured against, will produce
.exe's that crashes right out of the gates. gdb'ing the generated binaries,
the crash is happening in the CRT startup code & with some further poking
around I've been able to determine that it is the explicit presence of "-l"
options for 'kernel32' and 'msvcrt' when linking that's the cause. This is
with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19).
Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is
well-behaved, but ghc is still using gcc-3.4.5.

There's a couple of things that are odd here:

* base.cabal files have kernel32 and msvcrt as extra-libraries. This is 
clearly
   not required when doing invocations via ld(1), and causes 
considerable mischief,
   so it'd be good if there was a way in .cabal files to distinguish 
between stuff that

   goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's
   InstalledPackageInfos. (Is there? Couldn't locate anything 
appropriate while

   working with the Cabal sources..)

* 'base' needing to include these two dependencies even for GHCi usage. A
   running RTS will have these loaded already, so it really ought to 
have primed
   the list of opened DLLs by explicitly loading them upon 
initialization of the linker.
   [I've got a trivial patch against rts/Linker.c that does this; can 
forward/commit if

   of interest..]

* In addition to the patch referred to above, to solve these problems, 
I had to scrub
   libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the 
package.conf's for the
   versions of ghc I'm building against had to be edited, limiting the 
use of 'kernel32'
   and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' 
packages.


Long and rambling..hope you made it this far ;-) Is anyone else running 
into this issue &
should we do something about it? If not, details of compilation 
environment that
you've got that avoids running into this issue would be most welcome. 
It's a bit of a

chore spinning up new builds, as is.

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

Re: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs

[Sigbjorn Finne]

If you're referring to ghc-pkg-inplace invocations from Cabal, the
same hack was applied in utils/ghc-pkg also.

--sigbjorn

On 3/6/2007 08:46, Simon Marlow wrote:
Ah, so you did, thanks for reminding me.  We still need to do 
something about ghc-pkg, though.


Cheers,
Simon

Sigbjorn Finne wrote:
I added support for generating .bat files (to HEAD, I believe) for 
these in-place
wrappers some time ago just to address this issue, so you may want to 
look into

dragging those Makefile mods over.

--sigbjorn

On 3/5/2007 08:58, GHC wrote:

#1196: Cabal on Windows doesn't like the in-place GHCs
-+-- 

Reporter:  igloo |   Owner: Type:  
bug   |  Status:  newPriority:  normal|   
Milestone:  _|_   Component:  Compiler  | Version:  
6.6Severity:  normal|Keywords:   
Difficulty:  Unknown   |Testcase:  cabal01

Architecture:  Unknown   |  Os:  Windows
-+-- 


From e.g. a cmd prompt, Windows doesn't like the in-place GHCs:
 {{{
 C:\>C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace 

 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace' 
is

 not recognized as an internal or external command, operable program or
 batch file.

 C:\>cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-
 inplace
 #!/bin/sh
 exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc
 -BC:cygwinhomeianghc6.6-branchbuild "$@"
 }}}
 which means the cabal01 test fails thus:
 {{{
 $ ./setup configure --prefix=`pwd`/install --with-
 compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc-
 inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace
 --enable-library-profiling
 setup.exe: Warning: Package is copyright All Rights Reserved
 setup.exe: Warning: No license-file field.
 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace' 
is

 not recognized as an internal or external command,
 operable program or batch file.
 Configuring test-1.0...
 }}}
 (the odd output order is due to buffering)

  
 



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


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



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

Re: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs

[Sigbjorn Finne]

I added support for generating .bat files (to HEAD, I believe) for these 
in-place
wrappers some time ago just to address this issue, so you may want to 
look into

dragging those Makefile mods over.

--sigbjorn

On 3/5/2007 08:58, GHC wrote:

#1196: Cabal on Windows doesn't like the in-place GHCs
-+--
Reporter:  igloo |   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone:  _|_
   Component:  Compiler  | Version:  6.6
Severity:  normal|Keywords: 
  Difficulty:  Unknown   |Testcase:  cabal01

Architecture:  Unknown   |  Os:  Windows
-+--
From e.g. a cmd prompt, Windows doesn't like the in-place GHCs:
 {{{
 C:\>C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace
 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace' is
 not recognized as an internal or external command, operable program or
 batch file.

 C:\>cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-
 inplace
 #!/bin/sh
 exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc
 -BC:cygwinhomeianghc6.6-branchbuild "$@"
 }}}
 which means the cabal01 test fails thus:
 {{{
 $ ./setup configure --prefix=`pwd`/install --with-
 compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc-
 inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace
 --enable-library-profiling
 setup.exe: Warning: Package is copyright All Rights Reserved
 setup.exe: Warning: No license-file field.
 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace' is
 not recognized as an internal or external command,
 operable program or batch file.
 Configuring test-1.0...
 }}}
 (the odd output order is due to buffering)

  



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


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

Re: [GHC] #942: Windows programs throw uncaught Invalid HANDLE exception on exit

[Sigbjorn Finne]

Ought to (but don't sue me if it doesn't.)

--sigbjorn

Bulat Ziganshin wrote:

Hello Sigbjorn,

Tuesday, October 31, 2006, 10:04:52 PM, you wrote:

is that means that current 6.6 precompiled snapshots like
http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20061031-i386-unknown-mingw32.tar.gz
should work fine? this problem is very important for me too


  
  

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

Re: [GHC] #942: Windows programs throw uncaught Invalid HANDLE exception on exit

[Sigbjorn Finne]

[Due to a somewhat inconvenient HD meltdown some weeks ago, I lost a bunch
of data/user settings amongst other things, including the password to 
GHC's Trac,

hence this lame response directly to the mailing list]

I fixed this one a week or two ago on the 6.6 branch --

   http://www.haskell.org/pipermail/cvs-ghc/2006-October/032154.html

Have not had the time&space to drag it over to HEAD since then.

hth
--sigbjorn

GHC wrote:

#942: Windows programs throw uncaught Invalid HANDLE exception on exit
+---
 Reporter:  [EMAIL PROTECTED] |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Milestone:  6.6.1  
Component:  Runtime System  |Version:  6.6
 Severity:  major   | Resolution: 
 Keywords:  uncaught exception HANDLE exit  | Difficulty:  Unknown
 Testcase:  N/A |   Architecture:  x86
   Os:  Windows |  
+---

Changes (by [EMAIL PROTECTED]):

  * severity:  normal => major

Comment:

 I've changed the severity to major because I feel this bug prevents me
 distributing any binaries compiled under ghc6.6 for Windows, since whether
 or not the bug is "visible" (ie if you choose to run the binary under a
 debugger), obviously something is very wrong indeed with the runtime or
 else it wouldn't be trying to use an invalid handle (or cause one of the
 windows DLLs to do so) at program exit.

  



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

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

Re: ghc-6.6 on Windows Vista: "cannot exec as"

[Sigbjorn Finne]

Thank you, something's changed wrt path handling it seems. A temporary
fix/workaround (as reported by other Vista users) is to add the
ghc-6.6\gcc-lib directory to your PATH.

If you have the time, here's a couple of things to try out to
diagnose the problem further:

c:\foo> echo int x = 22; > foo.c
c:\foo> c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib/ -c foo.c
<...> # expected to fail (same as ghc's invoc of gcc below)
c:\foo> c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib -c foo.c
<...> # what happens here?
c:\foo> c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib\ -c foo.c
<...> # what happens here?

--sigbjorn

Satnam Singh wrote:

The -v output below. I shall try it with Vista RC2 and see if that make a 
difference.
The same installer file on Windows XP and Windows Server seems to work fine.

Cheers,

Satnam

C:\sd\satnams\haskell\hello>ghc Hello.hs
gcc: installation problem, cannot exec `as': No such file or directory

C:\sd\satnams\haskell\hello>ghc -v Hello.hs
Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 
6.6
Using package config file: c:\ghc\ghc-6.6\package.conf
wired-in package base mapped to base-2.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0
wired-in package template-haskell mapped to template-haskell-2.0
Hsc static flags: -static
Created temporary directory: C:/Users/satnams/AppData/Local/Temp/ghc5440_0
*** Checking old interface for main:Main:
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 10
*** Simplify:
Result size = 8
*** Tidy Core:
Result size = 8
*** CorePrep:
Result size = 10
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** Assembler:
c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib/ -I. -c 
C:\Users\satnams\AppData\Local\Temp\ghc5440_0\ghc5440_0.s -o Hello.o
gcc: installation problem, cannot exec `as': No such file or directory
*** Deleting temp files:
Deleting: C:/Users/satnams/AppData/Local/Temp/ghc5440_0/ghc5440_0.s
*** Deleting temp dirs:
Deleting: C:/Users/satnams/AppData/Local/Temp/ghc5440_0

C:\sd\satnams\haskell\hello>

-Original Message-
From: Sigbjorn Finne [mailto:[EMAIL PROTECTED]
Sent: 18 October 2006 14:03
To: Satnam Singh
Cc: GHC-bugs list
Subject: Re: ghc-6.6 on Windows Vista: "cannot exec as"


Thanks; for people that don't have access to Vista, the output resulting
from 'ghc -v Hello.hs' would help narrowing this down a bit...I hope.

--sigbjorn

Satnam Singh wrote:
  

I just installed GHC-6.6. on Windows Vista RC1 (using the MSI
installer) but when I compile I get the error:

c:\sd\satnams\haskell\hello>ghc Hello.hs

gcc: installation problem, cannot exec `as': No such file or directory

Has anyone else noticed this?

And before anyone tells me to: no, I can't use Linux!


Cheers,


Satnam



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

Re: ghc-6.6 on Windows Vista: "cannot exec as"

[Sigbjorn Finne]

Thanks; for people that don't have access to Vista, the output resulting
from 'ghc -v Hello.hs' would help narrowing this down a bit...I hope.

--sigbjorn

Satnam Singh wrote:


I just installed GHC-6.6. on Windows Vista RC1 (using the MSI 
installer) but when I compile I get the error:


c:\sd\satnams\haskell\hello>ghc Hello.hs

gcc: installation problem, cannot exec `as': No such file or directory

Has anyone else noticed this?

And before anyone tells me to: no, I can’t use Linux!


Cheers,


Satnam



Satnam Singh
Microsoft
7 JJ Thomson Avenue
Cambridge
CB3 0FB
United Kingdom

Email: [EMAIL PROTECTED] 
UK tel: +44 1223 479905
US tel: +1 206 219 9024
Fax: +44 1223 479 999
UK cell: +44 7979 648412
URL: http://research.microsoft.com/~satnams 


MSN IM: [EMAIL PROTECTED]



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


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

Re: [GHC] #891: hsc2hs tries to remove an open file

[Sigbjorn Finne]

This is a long standing, irksome Win32 timing issue, and is not
GC related (AFAICR, it was reproducible in straight C code).

A better workaround, which was experimented with in STABLE
at some point, is to simply delay the clean up of the files until
the end of hsc2hs's run

--sigbjorn

GHC wrote:

#891: hsc2hs tries to remove an open file
-+--
Reporter:  eivuokko  |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.4.2  
Severity:  normal| Keywords: 
  Os:  Windows   |   Difficulty:  Unknown
Architecture:  Unknown   |  
-+--

hsc2hs sometimes fails with error "Permission denied" in Windows.  This is
 because it tries to remove a file it has open handle to.  The error
 usually repeats per-machine and file, but what file and machine it shows
 up with, is random.

 As a workaround, calls to removeFile can be removed, or exceptions
 catched.

 From a mail by Brian Smith:
 http://www.haskell.org/pipermail/cvs-ghc/2006-September/031186.html

  



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


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

Re: [GHC] #882: Overflow bug in System.Time

[Sigbjorn Finne]

The fix is trivial though (and have been applied to HEAD) --
 http://hackage.haskell.org/trac/ghc/ticket/588

--sigbjorn

GHC wrote:

#882: Overflow bug in System.Time
---+
Reporter:  simonpj |Owner: 
Type:  bug |   Status:  new
Priority:  normal  |Milestone: 
   Component:  libraries/base  |  Version:  6.4.2  
Severity:  normal  | Keywords: 
  Os:  Unknown |   Difficulty:  Unknown
Architecture:  Unknown |  
---+

Frederik Eaton reports: The Glorious Glasgow Haskell Compilation System,
 version 6.4.3.20060816
 {{{
 > now <- getClockTime
 > addToClockTime (TimeDiff {tdYear = 0, tdMonth = 0, tdDay = 0, tdHour =
 0, tdMin = 0, tdSec = 0, tdPicosec = }) now
 *** Exception: Time.toClockTime: picoseconds out of range

 }}}

 This is clearly a bug.  Simon Marlow comments: System.Time is kind-of
 deprecated: the new time package is intended to supercede it, but I have
 been reluctant to really deprecate System.Time because it comes from
 Haskell98, and also because we don't have much experience with its
 replacement.

  



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


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

Re: [GHC] #840: GHC on "loosing" its handles takes 100% CPU

[Sigbjorn Finne]

But as long as it's Haskell code consuming all those CPU cycles,
it can't be all bad? :)

If any of you are running into this while invoking "ghci.exe",
you may want to play with using "ghc.exe --interactive" instead
to see if that improves matters. Not using "ghci.exe" avoids
a layer of sub-process'ery and console event handling nonsense;
a culprit, perhaps?

--sigbjorn

- Original Message - 
From: "Lennart Augustsson" <[EMAIL PROTECTED]>

To: "Bulat Ziganshin" <[EMAIL PROTECTED]>
Cc: "GHC" <[EMAIL PROTECTED]>; 
Sent: Friday, August 04, 2006 05:46
Subject: Re: [GHC] #840: GHC on "loosing" its handles takes 100% CPU



It happens all the time to me that GHC doesn't die properly on windows.
Every so often I have to kill a few straggling ghc processes.  They  
all spin consuming 100% CPU when this happens.


-- Lennart

On Aug 2, 2006, at 10:09 , Bulat Ziganshin wrote:


Hello GHC,

Wednesday, August 2, 2006, 4:33:09 PM, you wrote:


#840: GHC on "loosing" its handles takes 100% CPU



 import System.Process
 main = runInteractiveCommand "ghc"



 When run terminates immediately, as expected, but leaves an instance
 of ghc running. The ghc process takes up 100% of the CPU time, and
 seemingly does nothing.


well, i have similar problem: there are only 256 megs on my machine
and sometimes when ghc compilation uses more than 200 megs and starts
trashing memory, i tries to stop it by hitting Ctrl-C. in this
situation it's rather typical that i got back my console (and rerun
ghc) but old GHC process don't killed and continue to compile program.
i can investigate it further but don't know what to do. at least it
seems that memory trashing is required to uncover this problem. i also
should note that i run "ghc --make" from the .cmd file so there is a
whole stack of processes runned. may be i just kill higher-level ghc
(or even cmd) and lower-level ghc still continue to do it's job? i'm
not sure..

--
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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


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

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

Re: Strange behaviour with classes (both Hugs and GHC)

[Sigbjorn Finne]

Hi,

if you desugar the definition that's causing the type error,
perhaps it becomes a little bit clearer what's going on, i.e.,
from

problematic :: MyAnnotatedType Int
problematic = defaultVal{theInt=42,theAnnotation=10}

you expand this to

problematic' = case defaultVal of { MAT a b c -> MAT 42 b 10 }

Clearly, the type of 'c' is ambiguous here. Interestingly, if Haskell 98
had defined record update expr "e{fields}" as having the same type
as "e", this wouldn't have been an issue:

no_probs =
case defaultVal of { m@(MAT a b c) -> (MAT 42 b 10) `asTypeOf` m}

hth
--sigbjorn

- Original Message - 
From: "Magnus Björk" <[EMAIL PROTECTED]>

To: ; 
Sent: Monday, May 29, 2006 03:34
Subject: Strange behaviour with classes (both Hugs and GHC)



I just ran into a strange behaviour of both Hugs and GHC. I discussed it
with John Hughes who managed to find a workaround, and suggested that I
ask you whether this is really expected behaviour.

The attached file contains a small example that exhibits the problem.

--
/MpB







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



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

Re: getDirectoryContents: failed (No error)

[Sigbjorn Finne]

The previous bug was in the handling of .bss sections for relocatable
object files in the RTS linker -- the fix is included in STABLE. It's
not clear that it would apply in this context though.

I'm not able to reproduce this one with last night's STABLE build.
Perhaps the bug reporter could add details on how the binary was
built & run, maybe even include "-v" on the GHC command-line?

thx
--sigbjorn

- Original Message - 
From: "Simon Marlow" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; 
; <[EMAIL PROTECTED]>

Sent: Friday, March 03, 2006 02:54
Subject: Re: getDirectoryContents: failed (No error)



Martin Boeker wrote:

this error has been reported before and was fixed in ghc 6.4.1 but has 
been revived in ghc 6.4.2:


test3.exe: .: getDirectoryContents: failed (No error)

module Main where

import System.Directory

main =do s <- getDirectoryContents "."
   putStr (concat s)

This works fine for ghc 6.4.1 bld1. The error is encountered in 6.4.2 
snapshots from Feb. 25 and newer (elder ones have not tested), and the 
same snapshots with the MinGW files from afore mentioned ghc 6.4.1 (it's 
not the MinGW).


My system is: Cygwin (WinXP) and ghc 6.4.1 bld1 or 6.4.2 (Cajal works 
better).


Thanks; I've made a ticket for this:

  http://hackage.haskell.org/trac/ghc/ticket/712

Sigbjorn: do you think this is the same problem as before?  (see
http://www.haskell.org//pipermail/glasgow-haskell-bugs/2005-July/005338.html)

Cheers,
Simon 


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

Re: Bug in cvs head ghci

[Sigbjorn Finne]

Yep, reproducible with last night's HEAD build on mingw
(but not STABLE.)

--sigbjorn

- Original Message - 
From: "Simon Peyton-Jones" <[EMAIL PROTECTED]>

To: "wld" <[EMAIL PROTECTED]>; 
Sent: Friday, December 16, 2005 08:13
Subject: RE: Bug in cvs head ghci



Strange.  This does not happen for me on Linux or Windows (GHc 6.4.1).
Has anyone else seen it?

Simon

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of wld
| Sent: 08 December 2005 13:25
| To: glasgow-haskell-bugs@haskell.org
| Subject: Bug in cvs head ghci
| 
| HI,
| 
| Typing

|Prelude> :b GHC.Base
| 
| I get

| [snip]
|   data Addr#
|   data Array# a
|   data Bool = False | True
|   data ByteArray#
|   data Char#
|   data Char = C# Char#
|   data Double#
|   data Float#*** Exception: No match in record selector
TyCon.tyConTyVars
|   Prelude>
| 
| ghc built on Linux with

| - ghc 6.4.1
| - gcc 4.0.2
| 
| --

| V.Rudenko
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

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

Re: Network Exception

[Sigbjorn Finne]

Just to be clear -- this is with ghc-6.4.1 as distributed
via the GHC web pages and not some local build..?

I can't explain this -- the example code you give will have
successfully started up WinSock (version 1.1) prior to
calling getHostName, so that error condition doesn't
make much sense.

Given the two networking issues you've already come
across, I wouldn't discount the option that this might
be due to a local problem with your networking setup
(WinSock proxy config..?)

--sigbjorn

- Original Message - 
From: "Arias" <[EMAIL PROTECTED]>

To: "Sigbjorn Finne" <[EMAIL PROTECTED]>
Cc: 
Sent: Friday, October 14, 2005 14:01
Subject: Re: Network Exception



Thanks for the reply.

I don't know if the problem is the same, but when I try to run this code:

main = withSocketsDo $ do
  host <- getHostName
  putStrLn host

the getHostName throws this exception:

 getHostName: failed (Successful WSAStartup not yet performed 
(WSANOTINITIALISED))


:( I'm using Windows XP Professional

Sigbjorn Finne escribió:


Hi,

that error message is a bit confusing, to say the least:
getProtocolByName identifies itself as getServiceEntry
when failing. In this case, I'm quite sure, your snippet
fails because (getProtocolByName "tcp") isn't successful.
I've no idea why your /etc/protocols doesn't contain an entry
for 'tcp'.

The error message in said function has now been fixed; thanks
for the report.

--sigbjorn

- Original Message - From: "Arias" <[EMAIL PROTECTED]>
To: 
Sent: Friday, October 14, 2005 06:47
Subject: Network Exception



Hi,

I've a problem, I'm using this code on GHC compiler version 6.4.1:

--- BEGIN ---
module Main where
import System.IO
import Network

main = withSocketsDo $ do
handle <- connectTo "localhost" ( PortNumber 8080 )
hSetBuffering handle LineBuffering
hClose handle
--- END ---

The problems is that it throws an exception at connectTo, the exception 
is:


getServiceEntry: does not exist (no such service entry)

The server and the port is correct, I have apache listening on port 8080 
and if I put http://localhost:8080/ on browser it loads a web page.


Do somebody knows what it happens and how to fix it? thanks.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users








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

Re: cc1plus.exe not included in Win32 distro

[Sigbjorn Finne]

It was intentionally removed (the intention being to remove
heft from the installer) after it had been unintentionally
included for quite a while.

The rule has always been that only tools that GHC depends
upon to operate are bundled with it on the mingw side --
the only exception to that rule has been the recent inclusion
of 'ar'.

Should GHC binary dists include a C++ compiler? I'd say
no, but if there are practical and compelling reasons to do
so, it's no big deal to re-include the binary.

--sigbjorn

- Original Message - 
From: "Bulat Ziganshin" <[EMAIL PROTECTED]>

To: 
Sent: Friday, October 14, 2005 10:49
Subject: cc1plus.exe not included in Win32 distro



Hello all,

the official Win32 distro
(http://www.haskell.org/ghc/dist/6.4.1/ghc-6-4-1.msi)

does not contain cc1plus.exe, needed to compile CPP files:

C:\FreeArchiver> ghc a.cpp
gcc: installation problem, cannot exec `cc1plus': No such file or 
directory


is this a packaging bug or intentional change?

--
Best regards,
Bulatmailto:[EMAIL PROTECTED]



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


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

Re: Network Exception

[Sigbjorn Finne]

Hi,

that error message is a bit confusing, to say the least:
getProtocolByName identifies itself as getServiceEntry
when failing. In this case, I'm quite sure, your snippet
fails because (getProtocolByName "tcp") isn't successful.
I've no idea why your /etc/protocols doesn't contain an entry
for 'tcp'.

The error message in said function has now been fixed; thanks
for the report.

--sigbjorn

- Original Message - 
From: "Arias" <[EMAIL PROTECTED]>

To: 
Sent: Friday, October 14, 2005 06:47
Subject: Network Exception



Hi,

I've a problem, I'm using this code on GHC compiler version 6.4.1:

--- BEGIN ---
module Main where
import System.IO
import Network

main = withSocketsDo $ do
handle <- connectTo "localhost" ( PortNumber 8080 )
hSetBuffering handle LineBuffering
hClose handle
--- END ---

The problems is that it throws an exception at connectTo, the exception 
is:


getServiceEntry: does not exist (no such service entry)

The server and the port is correct, I have apache listening on port 8080 
and if I put http://localhost:8080/ on browser it loads a web page.


Do somebody knows what it happens and how to fix it? thanks.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users 


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

Fw: 6.4.1 win32 candidate installer

[Sigbjorn Finne]

FYI - widening the (testing) audience a bit.

--sigbjorn

- Original Message - 
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Sent: Monday, August 22, 2005 13:59
Subject: 6.4.1 win32 candidate installer



With 6.4.1 being close to done, I've rolled an MSI
test installer of the bits -- available as

http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-1-20050822.msi

Reports of installer snafus or any other problems using it
are most welcome.

thanks
--sigbjorn



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

Re: Undefined symbols on new install of ghc 6.2.2

[Sigbjorn Finne]

Can't think of a reasonable explanation for the behaviour
you're seeing, I'm afraid. If you look at the undefined
symbols from the link, _ZCMain_main_closure
isn't being found -- it should be in Build.o, which is included
on the command line. The weird thing is that the linker
does report undefined symbols from that closure's
entry point, _ZCMain_main_entry (in Build.o), but fails to
see the (.data) symbol for the closure itself.

On the off-chance you haven't tried this already, could you try
to delete the object files and re-do the --make? Add -fvia-C
while you're at it.

If you want to examine what the linker actually slurps in,
try -optl-Wl,--verbose

GHC binary installs on Windows are islands as far as tools
needed to compile&link Haskell code goes. You may run into
trouble if you compile a .c file with a local installation of
gcc and then try to link the object file with ghc, but I don't
think that's the case here.

--sigbjorn

- Original Message - 
From: "Alastair Reid" <[EMAIL PROTECTED]>

To: "Sigbjorn Finne" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, August 22, 2005 06:16
Subject: RE: Undefined symbols on new install of ghc 6.2.2



Thanks Sigbjorn,

Chris gave these a shot and everything looks right.  (i.e., the symbols
exist, tmpdir is big and changing it doesn't help and invoking ghc on
the .o files directly doesn't help.)

Also, building with the latest release of ghc works fine.  (This is
slightly tedious because we need both 6.2.2 and 6.4 at the moment but
we'll probably update our code to work with 6.4 sometime soon anyway.)

One interesting detail was that the .a file has names with
triple-underscore prefixes but the linker error messages have
single-underscore prefixes.  Is this just the linker deleting _'s when
displaying error messages or is this the real problem?
I'm not sure what Chris has installed on his machine but is it possible
that if he had cygwin (say) installed the gcc from that install would be
used instead of the one that comes in the ghc package?  



--
Alastair Reid, Principal Engineer, R&D
ARM Ltd, 110 Fulbourn Rd, Cambridge, CB1 9NJ.
T: +44 1223 406 109



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

Re: Undefined symbols on new install of ghc 6.2.2

[Sigbjorn Finne]

Puzzling; couple of things to check for:

- nm -o c:/ghc/ghc-6.2.2/libHSbase.a | grep 'T ___stginit_Prelude'

 is successful.

- the TMPDIR setting appears to be w:/tmp -- make sure that actually
 exists & isn't clogged up. Does changing it to "." (or somesuch) alter
 the behaviour?

- does an invocation of the form "ghc -o build.exe MakeUtils.o Build.o 
"

 succeed?

--sigbjorn

- Original Message - 
From: "Alastair Reid" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 17, 2005 05:59
Subject: Undefined symbols on new install of ghc 6.2.2


One of my colleagues just installed ghc 6.2.2 on their Windows machine.
GHC compiles fine but ghc --make fails at the linking stage with a bunch
of undefined symbols that ought to have been part of the ghc install
like:

./MakeUtils.o(.text+0x43): In function `_stginit_MakeUtils_':
: undefined reference to `_stginit_IO_'
./MakeUtils.o(.text+0x4d): In function `_stginit_MakeUtils_':
: undefined reference to `_stginit_Prelude_'
./MakeUtils.o(.text+0x5c): In function `r1pU_srt':
: undefined reference to `GHCziBase_zdfEqZMZN_closure'

(see attached file for complete list of undefined symbols).

We've checked that the lib files exist and confirmed that he installed
ghc in the normal place (see message at end of this message).
ghc-6.2.2 works just fine on my machine.

Does this ring any bells for anyone?

--
Alastair Reid, Principal Engineer, R&D
ARM Ltd, 110 Fulbourn Rd, Cambridge, CB1 9NJ.
T: +44 1223 406 109



-Original Message-

Alastair Reid wrote:

Can you try:

  ghc -v

this will produce a few hundred lines of output amongst which
there's a bunch of filenames like

  c:/ghc/ghc-6.2.2
  c:/ghc/ghc-6.2.2/imports
  c:/ghc/ghc-6.2.2/hslibs-imports/util

The first should have a bunch of files with names like
libHS*.a and is the most important
The latter should have a bunch of *.hi files (and seem to be
fine since you got as far as linking).


Assuming you mean that these directories should have the files you name
(not the output of ghc -v), then, yes, they are present.


Check you're not really low on diskspace in case the install
silently failed (e.g., the 100s of Mbytes of libHS*.a files
weren't all installed).


Plenty of disc space.


If that looks plausible, try adding the -v flag to the ghc
--make command line to see if you get any useful info about
the failure.
If still nothing, try -v4 and -v5 to get extra verbosity.


I tried this but learnt nothing new (see attached). Is it possible that
I need to set some environment variables other than PATH (e.g.
LD_LIBRARY_PATH)?


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

Re: stdin set to nonblocking mode

[Sigbjorn Finne]

"Simon Marlow" <[EMAIL PROTECTED]> writes:



...

No - read() can always return less than the requested amount of data,
even when not in O_NONBLOCK mode.



Hmm, care to give some details as to why you equate "can" with
"always will" on all platforms?

--sigbjorn

___
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

[Sigbjorn Finne]

"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

Re: getDirectoryContents fails in GHC 6.5 snapshots, works in GHC 6.4.1 snapshots

[Sigbjorn Finne]

Mystery now solved (*), nightly builds should now behave a bit better
when it comes to directory handling.

--sigbjorn

* - gcc-3.4.* mingw builds hard-codes default include search paths
referring to /mingw/. My local box happened to contain an older mingw
dist in that location, leading to confusion about the layout of 'struct 
dirent'.


- Original Message - 
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, August 08, 2005 10:38
Subject: Re: getDirectoryContents fails in GHC 6.5 snapshots,works in GHC 
6.4.1 snapshots




I can repro it too. Looks as if the dirent.h implementation of the
mingw snapshot that the nightlies are using is spongled. Simple
stuff like

#include 
#include 
#include 
int main()
{
 DIR* dp;
 struct dirent* de;

 dp = opendir("c:\\");
 while (de = readdir(dp)) {
 printf("%s\n",de->d_name);
 }
 closedir(dp);
 return 0;
}

fails. I'll upgrade and see if that improves matters.

--sigbjorn

- Original Message - 
From: "Brian Smith" <[EMAIL PROTECTED]>

To: 
Sent: Monday, August 08, 2005 10:31
Subject: Re: getDirectoryContents fails in GHC 6.5 snapshots,works in GHC 
6.4.1 snapshots




On 8/8/05, Simon Marlow <[EMAIL PROTECTED]> wrote:

On 29 July 2005 23:53, Brian Smith wrote:

> On 7/20/05, Brian Smith <[EMAIL PROTECTED]> wrote:
>> This bug breaks Cabal 1.0 and Cabal 1.1.1.
>> Expected results: passed
>> Actual results: *** Exception: c:\: getDirectoryContents: failed (No
>> error)
>>
I tried various versions and couldn't reproduce the error.  I tried:


Yes, it fails for every directory. I actually noticed the problem by
when using Cabal, which uses getDirectoryContents. But, I did some
more testing. This works:

   > ghc --make Main.lhs -o main
   > main
   passed

But, this fails:

   > ghci Main.lhs
   Prelude Main> main
   *** Exception: C:\temp\bugs\getDirectoryContents:
getDirectoryContents: failed (
No error)

and this fails:

   > runghc Main.lhs
   *** Exception: C:\temp\bugs\getDirectoryContents:
getDirectoryContents: failed (
No error)

This indicates to me that there is not any problem with my filesystem.
Instead, it seems like it is likely a problem with the linker. Now, I
see what the cause of the problem is:

http://www.haskell.org//pipermail/cvs-ghc/2005-June/025579.html
Sigbjorn Finne sof at galois.com wrote on Mon Jun 20 12:29:24 EDT 2005:
I'll switch over to using gcc-3.4.2 for the nightly builds to see where 
takes us.


And, in my previous message I wrote:


Build 20050620 works fine, but Build 20050622 fails.
I noticed that on 2005-06-21 the build failed. I also noticed that
before 2005-06-21, the tar.gz's are ~1 larger than the ones after
2005-06-21.


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


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


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

Re: getDirectoryContents fails in GHC 6.5 snapshots, works in GHC 6.4.1 snapshots

[Sigbjorn Finne]

I can repro it too. Looks as if the dirent.h implementation of the
mingw snapshot that the nightlies are using is spongled. Simple
stuff like

#include 
#include 
#include 
int main()
{
 DIR* dp;
 struct dirent* de;

 dp = opendir("c:\\");
 while (de = readdir(dp)) {
 printf("%s\n",de->d_name);
 }
 closedir(dp);
 return 0;
}

fails. I'll upgrade and see if that improves matters.

--sigbjorn

- Original Message - 
From: "Brian Smith" <[EMAIL PROTECTED]>

To: 
Sent: Monday, August 08, 2005 10:31
Subject: Re: getDirectoryContents fails in GHC 6.5 snapshots,works in GHC 
6.4.1 snapshots




On 8/8/05, Simon Marlow <[EMAIL PROTECTED]> wrote:

On 29 July 2005 23:53, Brian Smith wrote:

> On 7/20/05, Brian Smith <[EMAIL PROTECTED]> wrote:
>> This bug breaks Cabal 1.0 and Cabal 1.1.1.
>> Expected results: passed
>> Actual results: *** Exception: c:\: getDirectoryContents: failed (No
>> error)
>>
I tried various versions and couldn't reproduce the error.  I tried:


Yes, it fails for every directory. I actually noticed the problem by
when using Cabal, which uses getDirectoryContents. But, I did some
more testing. This works:

   > ghc --make Main.lhs -o main
   > main
   passed

But, this fails:

   > ghci Main.lhs
   Prelude Main> main
   *** Exception: C:\temp\bugs\getDirectoryContents:
getDirectoryContents: failed (
No error)

and this fails:

   > runghc Main.lhs
   *** Exception: C:\temp\bugs\getDirectoryContents:
getDirectoryContents: failed (
No error)

This indicates to me that there is not any problem with my filesystem.
Instead, it seems like it is likely a problem with the linker. Now, I
see what the cause of the problem is:

http://www.haskell.org//pipermail/cvs-ghc/2005-June/025579.html
Sigbjorn Finne sof at galois.com wrote on Mon Jun 20 12:29:24 EDT 2005:
I'll switch over to using gcc-3.4.2 for the nightly builds to see where 
takes us.


And, in my previous message I wrote:


Build 20050620 works fine, but Build 20050622 fails.
I noticed that on 2005-06-21 the build failed. I also noticed that
before 2005-06-21, the tar.gz's are ~1 larger than the ones after
2005-06-21.


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


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

Re: Feature request: Windows ZIP Distribution

[Sigbjorn Finne]

Bulat Ziganshin <[EMAIL PROTECTED]> writes:


SF> That's an impressive reduction in size; compressing the
SF> CAB file inside the MSI using the LZW-based compressor
SF> that Microsoft provides with their 'makecab' utility didn't

LZX (very different from LZW, born long ago, in 1984)

btw, while writing this letter i compressed GHC 6.4 installation with
cabarc. it results in 33 megs only (!). may be when you creating your
installation, you are using MSZIP compression instead of LZX? or you
compress with LZX:15, i.e. with minimal 32 kb dictionary instead of
LZX:21?



Cool, thanks for trying this out, Bulat. When fixing on MSZIP as the
compressor for the tool that creates these MSIs sometime ago, I did play
with different memory sizes for LZX, but the resulting installers
didn't reduce space usage by all that much, so I opted to just go with the
cheap&cheerful MSZIP. This wasn't with GHC installers though, and as
your experience shows that fixing on always using MSZIP wasn't
such a good idea. I'll go with LZX for the next GHC release, as I'm able
to reproduce what you're seeing.


...


Re: lzma, 7-zip: I'm not questioning the improvements possible going this
route, just that I won't be doing it for now. Others are free to offer up 
other
distribution forms, of course. However, as an end-user on a Windows 
platform,

I do prefer using non-executable installers.

--sigbjorn

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

Re: Feature request: Windows ZIP Distribution

[Sigbjorn Finne]

That's an impressive reduction in size; compressing the
CAB file inside the MSI using the LZW-based compressor
that Microsoft provides with their 'makecab' utility didn't
make much of a difference in size (but increased compression
time quite a bit.) I'm idly speculating that LZMA's larger dictionaries
is what's paying off here. Thanks for the pointer, I'll definitely
play with it.
I'm not planning on switching to 7-Zip in the near future though.
However, I think Brian Smith's suggestion of offering up a
.zip'ed up version of the GHC distribution tree is a good
one & plan to do that for the next release. It can then be used
to derive other distribution/installer formats.
--sigbjorn
- Original Message - 
From: "Bulat Ziganshin" <[EMAIL PROTECTED]>
To: "Sigbjorn Finne" <[EMAIL PROTECTED]>
Cc: 
Sent: Wednesday, May 18, 2005 23:09
Subject: Re[2]: Feature request: Windows ZIP Distribution


Hello Sigbjorn,
Wednesday, May 18, 2005, 8:38:55 PM, you wrote:
SF> The 6.4 installer has a UI bug that may prevent you from using
SF> it on a box where you don't have admin privs. Try starting up the 
installer,
SF> hit Next, followed by Back. That should bring up a dialog letting you 
choose
SF> whether to perform a user or machine wide installation. Select the 
former

nice bug! :)
you can cut installer size in 1.5-2 times by repacking it with another
compressor - LZMA. i tried this on the your 6.4 distribution and whole
installed directory was packed down to 26 megs
to get this work you can either switch to Nullsoft installer, which
has support for LZMA, or create self-extracting module with help of
7-zip (www.7-zip.org) anf include this self-extractor in your installer
in order to test lzma compression, download abovementioned 7-zip and
try it on some directory with the following cmdline:
7z a archive -r -mx9
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]

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

Re: Feature request: Windows ZIP Distribution

[Sigbjorn Finne]

One e-mail regarding this would do.. :)
The 6.4 installer has a UI bug that may prevent you from using
it on a box where you don't have admin privs. Try starting up the installer,
hit Next, followed by Back. That should bring up a dialog letting you choose
whether to perform a user or machine wide installation. Select the former 
and
proceed as before. Hopefully that does it.

Distributing a .zip wouldn't be a big deal, just want to make sure it is 
solving
a real problem.

--sigbjorn
- Original Message - 
From: Brian Smith
To: glasgow-haskell-bugs@haskell.org
Sent: Wednesday, May 18, 2005 08:57
Subject: Feature request: Windows ZIP Distribution

Hi,
I think it would be convenient for some users (including me at this 
particular moment) if the Windows binary distribution of GHC was available 
as a ZIP file. My laptop died and I am using a shared computer with the 
Windows Installer disabled, thus I cannot use the MSI distribution. Maybe 
other people have similar situations. Note that ZIP files (unlike TAR.GZ 
files) can be unzipped in Windows XP without any third-party tools.

Thanks,
Brian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [nightly] 26-Apr-2005 build of HEAD on OpenBSD/x86

[Sigbjorn Finne]

Ditto w/ HEAD -- the compilation error refers to '&stderr'.
For that to work, 'stderr' has to be an lvalue, which is an
unsound assumption (mingw defines it as "&(_iob[STDERR_FILENO])".)
--sigbjorn
- Original Message - 
From: "Conal Elliott" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, April 26, 2005 09:46
Subject: FW: [nightly] 26-Apr-2005 build of HEAD on OpenBSD/x86


I am getting this same barfage on WinXP ("invalid lvalue in unary `&'"
while compiling raisezh_fast in Exception.cmm).  From cvs-ghc mail, it
looks like this one has been coming up for a few days now.
- Conal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Donald Bruce Stewart
Sent: Tuesday, April 26, 2005 2:25 AM
To: [EMAIL PROTECTED]
Subject: [nightly] 26-Apr-2005 build of HEAD on OpenBSD/x86
Build description = HEAD on OpenBSD/x86
Build location= /home/dons/head-gcc3
Build config file =
/home/dons/head-gcc3/nightly/site/pls/conf-HEAD-manzano
Nightly build started on manzano at Tue Apr 26 19:00:17 EST 2005.
using existing source tree... ok. (GHC Version 6.5)
 Updating source tree ... ok.
 Building stage 1 compiler... failed; relevant barfage is below.
 Building Haddock ... ok.
 Building Alex... ok.
 Building Happy   ... ok.
No successfully built compilers to test; aborting.


The last 30 lines of
/home/dons/head-gcc3/logs/i386-unknown-openbsd-stage1 are


../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
-optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel
-optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O  -O2 -static -I.
-#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include
RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h
-#include Sanity.h -#include STM.h -#include Storage.h -#include
SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h
-#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h
-#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint  -hisuf p_hi
-hcsuf p_hc -osuf p_o -prof   -c Weak.c -o Weak.p_o
../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
-optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel
-optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O  -O2 -static -I.
-#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include
RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h
-#include Sanity.h -#include STM.h -#include Storage.h -#include
SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h
-#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h
-#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint  -hisuf p_hi
-hcsuf p_hc -osuf p_o -prof   -c hooks/FlagDefaults.c -o
hooks/FlagDefaults.p_o
../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
-optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel
-optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O  -O2 -static -I.
-#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include
RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h
-#include Sanity.h -#include STM.h -#include Storage.h -#include
SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h
-#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h
-#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint  -hisuf p_hi
-hcsuf p_hc -osuf p_o -prof   -c hooks/InitEachPE.c -o
hooks/InitEachPE.p_o
../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
-optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel
-optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O  -O2 -static -I.
-#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include
RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h
-#include Sanity.h -#include STM.h -#include Storage.h -#include
SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h
-#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h
-#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint  -hisuf p_hi
-hcsuf p_hc -osuf p_o -prof   -c hooks/MallocFail.c -o
hooks/MallocFail.p_o
../../ghc/compiler/ghc-inplace -

Re: Build problem from CVS ...?

[Sigbjorn Finne]

Did you do a 'cvs up' with the -d option to have it create
new directories? ghc/lib/compat/include contains directory.h,
and is a fairly new addition.
--sigbjorn
- Original Message - 
From: "David Duke" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, April 26, 2005 06:59
Subject: Build problem from CVS ...?


I've been running ghc6.5, downloaded and built along with the other 
tools in the fptools cvs repository (I have no pressing need for cutting 
edge code, but using the fptools repository is convenient in providing 
everything in the one place!).  

This morning I updated my repository and tried to rebuild; that failed, 
so I ran update again, made "distclean", and tried again (autoreconf, 
./configure, make) ... Compilation is failing in ghc with the following 
error:


===fptools== Recursively making `boot' in compat ...
PWD = /home/djd/builds/fptools/ghc/lib


==fptools== make boot - --no-print-directory -r;
 in /home/djd/builds/fptools/ghc/lib/compat

../../../glafp-utils/mkdependC/mkdependC -f .depend-I. -Iinclude 
-I../../includes  -- -O-- cbits/directory.c cbits/rawSystem.c
cbits/directory.c:11:23: directory.h: No such file or directory
cbits/directory.c:11:23: directory.h: No such file or directory
Indeed, there is no file directory.h under the source tree.  Should this 
have been created during configuration - either way, any suggestions on 
why it is missing?

thanks,
David
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: win98, ctrl-c & System.system (was: Updated 6.4 Windows installer RC)

[Sigbjorn Finne]

"Simon Marlow" <[EMAIL PROTECTED]> writes:

...
Prelude> System.system "ls" >>= print
*** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist
(No such fi le or directory)
Prelude> System.Cmd.rawSystem "ls" [] >>= print
_viminfo  getname.pl  index.html
ExitSuccess
Prelude> System.system "false" >>= print
*** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist
(No such fi le or directory)
Prelude> System.Cmd.rawSystem "false" [] >>= print
ExitFailure 1
Works for me!  Remember that System.system is executing CMD.EXE, not
Cygwin bash, so it'll probably have a different PATH and might not be
able to find your Cygwin binaries.  Both System.system "dir", and
System.system "c:/cygwin/bin/ls" work for me.
There's no such thing as cmd.exe on Win9x, it's COMMAND.EXE/COM.
Some System.Process.* code ought to be looking at the COMSPEC env
variable and not hard-code the name of the command processor. However,
I don't think COMMAND.EXE supports the /c switch...why the switch away
from just using libc/msvcrt's system() for System.system?
--sigbjorn
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: misaligned block returned

[Sigbjorn Finne]

Hi,
8 == ERROR_NOT_ENOUGH_MEMORY, which sounds
reasonable (albeit cryptic) since Win32 has a default user
process size limit of 2Gb.
--sigbjorn
- Original Message - 
From: "Andreas Marth" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, January 13, 2005 07:41
Subject: misaligned block returned


Hi!
I tried to pass a big heap to a program and get the following error:
getMBlocks: VirtualAlloc failed with: 8
main: internal error: getMBlocks: misaligned block returned
   Please report this as a bug to glasgow-haskell-bugs@haskell.org,
   or http://www.sourceforge.net/projects/ghc/
That happens even for a "Hello world" program. The border is 1956M.
So +RTS -M1956M -RTS is fine. +RTS -M1957M -RTS yields the error above.
PS: I know that is a big heap and I could probably do with less when I 
track
the space leak down, but at the moment it is not worth the effort. I only
need a single run that passes. (With probably 2.5 - 3 GB memory usage.)

PPS: Please cc any answers to me because I am not subscribed to
haskell-glasgow-bugs.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs 
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: threadDelay space leak under win32

[Sigbjorn Finne]

Fixed now on the STABLE branch, but 6.2.2 and, at least,
all previous 6.x releases suffer from this embarrassing mem
leak. Thanks for reporting the problem.
--sigbjorn
- Original Message - 
From: "Simon Marlow" <[EMAIL PROTECTED]>
To: "Philippa Cowderoy" <[EMAIL PROTECTED]>; 
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, November 08, 2004 07:54
Subject: RE: threadDelay space leak under win32


On 07 November 2004 22:47, Philippa Cowderoy wrote:
Using the binary distros of GHC 6.2.1 and 6.2.2 under Win2K, this
leaks 12K of memory per second on my machine (as do larger programs
using threadDelay in the idle event of a wxHaskell app):
module Main where
import Control.Concurrent
main = (threadDelay 1000) >> main
I've no idea if it also happens on *nix platforms, or with a
win32/cygwin build.
Yes, that looks like a memory leak somewhere in the Async IO subsystem
on Windows.  The leak goes away using the threaded RTS on the latest CVS
version of GHC, because there we're using plain sleep() calls to
implement threadDelay and bypassing AsyncIO.
Sigbjorn: you're the owner of the Windows AsyncIO implementation, care
to look into this leak?
Cheers,
Simon 
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [Haskell-cafe] hugs segmentation fault

[Sigbjorn Finne]

"Jon Fairbairn" <[EMAIL PROTECTED]> writes:
On 2004-10-29 at 00:50BST Ben Rudiak-Gould wrote:
Jon Fairbairn wrote:

Well, here's a sample session I recorded just now:
C:\>\ghc\ghc-6.2.1\bin\ghci
 

Prelude> let p = 1 : [2 * x | x <- p, x < 1] in p
[1*** Exception: <>
Prelude> 123
Fail: thread blocked indefinitely
C:\>
Does this only happen to me?
I'm using Linux, you Windows. I suspect there's a hint
there. Has this been reported to Glasgow Haskell bugs?
(cc'd)
Plenty of times, but maybe not that particular manifestation of
the problem. Fixed in 6.2.2
--sigbjorn
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Data instances in ghc 6.2.1?

[Sigbjorn Finne]

"Claus Reinke" <[EMAIL PROTECTED]> writes:
...
> 
> PS. I never was quite sure why Haskell systems need an installer
> on Windows? There used to be Haskell libraries for accessing
> the registry, so filetype-associations and Start menu entries
> could be done optionally, by a little separate Haskell program, 
> and since GHC doesn't do any localisation or PATH settings, 
> the rest would mostly just be decompression and unpacking, 
> right? Or is that too naive a view of things?-)
> 

No, not at all -- at least not for nightly snapshots, good old tarballs is
the best way to distribute these. Installers makes better sense for
releases though, providing a one(2?)-click package for people to
get started with GHC, i.e., not requiring users to have misc utils
(e.g., tar/winzip) installed on their machines.

Writing a Haskell program that manipulates your file type associations
wouldn't be hard.

--sigbjorn

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

Re: Panic

[Sigbjorn Finne]

Hi Arjan,

the underlying GNU binutils issue which causes this was
fixed some 9 months ago. I've been using a new mingw
binutils snapshot for a while which includes it -- it's
available from

http://www.mingw.org/download.shtml

(look for binutils-2.15.90-20040222.)

You'll still see the warning from GHCi's linker about relocations,
but no need to worry.

hth
--sigbjorn

- Original Message - 
From: "Arjan van IJzendoorn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 10, 2004 06:49
Subject: Panic


> Hello GHC people,
>
> I'm having a lot of fun with GHC and wxHaskell, but at one point something
> unwanted happened. I created a version of wxHaskell from source with extra
> GHC options "-prof -auto-all"; I wanted to have a profiling version of
> wxHaskell so I can get a stack trace when my program crashes. The creation
> and installation of that version of wxHaskell went fine. When I tried to
> load my project NetEdit into ghci, I got the message at the end of this
> e-mail.  Using ghc (instead of GHCi) gives another message:
>
> src/Common.hs:3:
> Failed to load interface for `Graphics.UI.WX':
> Could not find interface file for `Graphics.UI.WX'
> (use -v to see a list of the files searched for)
>
> Cheers, Arjan
>
> --
>
> C:\dev\netedit\NetEdit>ghci -package wx -lsmilec -ilib\DData:src
src\Main.hs
>___ ___ _
>   / _ \ /\  /\/ __(_)
>  / /_\// /_/ / /  | |  GHC Interactive, version 6.2.1, for Haskell 98.
> / /_\\/ __  / /___| |  http://www.haskell.org/ghc/
> \/\/ /_/\/|_|  Type :? for help.
>
> Loading package base ... linking ... done.
> Loading package haskell98 ... linking ... done.
> Loading package lang ... linking ... done.
> Loading package concurrent ... linking ... done.
> Loading package QuickCheck ... linking ... done.
> Loading package util ... linking ... done.
> Loading package data ... linking ... done.
> Loading package wxcore ... linking ... WARNING: Overflown relocation field
> (# re
> locs found: 30765)
>
> C:/cygwin/usr/local/lib/wxcore0.o: unknown symbol `_CC_LIST'
> ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1):
> can't load package `wxcore'
>
> Please report it as a compiler bug to [EMAIL PROTECTED],
> or http://sourceforge.net/projects/ghc/.
>

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

Re: heap exhausted error

[Sigbjorn Finne]

MessageThanks, tidied up a while back - 6.2.1 includes the fix.

--sigbjorn

- Original Message - 
From: herington, dean
To: '[EMAIL PROTECTED]'
Sent: Monday, May 03, 2004 08:07
Subject: heap exhausted error


   ___ ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |  GHC Interactive, version 6.0.1, for Haskell 98.
/ /_\\/ __  / /___| |  http://www.haskell.org/ghc/
\/\/ /_/\/|_|  Type :? for help.

Loading package base ... linking ... done.
Prelude> :m +List
Prelude List> [] \\ [1..]
: internal error: RTS exhausted max heap size (268435456 bytes)

Please report this as a bug to [EMAIL PROTECTED],
or http://www.sourceforge.net/projects/ghc/


As the heap exhaustion is expected and user-caused, I'm not sure why the
above is an "internal error".  But I'm reporting it as requested.

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

Re: Release Candidate for 6.2.1 available

[Sigbjorn Finne]

I take that partially back, there does seem to be an issue
with "c:/Program Files/" installs; I'll try to look into it.

Still puzzled as to why your c:/ghc/ghc-6.2.1/ fails though.

--sigbjorn

- Original Message - 
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: "Peter Strand" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, March 12, 2004 10:27
Subject: Re: Release Candidate for 6.2.1 available


> This looks a bit odd; your -v output suggests that GHC
> is still installed in c:/ghc/ghc-6.2.1/, not in a space-separated
> directory. What platform is this on?
>
> Installing GHC in c:/Program Files/GHC/ seems to work just
> fine here (w/ XP.)
>
> --sigbjorn
>
> - Original Message - 
> From: "Peter Strand" <[EMAIL PROTECTED]>
> To: "GHC users" <[EMAIL PROTECTED]>
> Sent: Friday, March 12, 2004 09:33
> Subject: Re: Release Candidate for 6.2.1 available
>
>
> > Sigbjorn Finne wrote:
> >
> > >An installer for Windows users can now also be found in
> > >that directory.
> > >
> > >- Original Message - 
> > >From: "Simon Marlow" <[EMAIL PROTECTED]>
> > >Subject: RE: Release Candidate for 6.2.1 available
> > >
> > >
> > >>>   ghc-6.2.20040304 and later are release candidates for 6.2.1
> > >>>Get them from here: http://www.haskell.org/ghc/dist/stable/dist/
> > >>>
> > >>>
> > >>This is your last chance to test...  I'm going to freeze the release
on
> > >>Monday (15 March).
> > >>
> > >>
> >
> > If installed under a directory with spaces, it fails to produce object
> files.
> > 6.2 has the same problem, 6.0.1 works.
> >
> > End of output from "ghc -v --make t.hs":
> >
> > ...
> > ...
> > C:\ghc\ghc 6.2.1\gcc -B"C:\ghc\ghc 6.2.1\gcc-lib/" -I. -I. -c
> C:\DOCUME~1\peter\
> > LOCALS~1\Temp\ghc536.s -o t.o
> >
> > Failed: C:\ghc\ghc 6.2.1\gcc -B"C:\ghc\ghc 6.2.1\gcc-lib/" -I. -I. -c
> C:\DOCUME~
> > 1\peter\LOCALS~1\Temp\ghc536.s -o t.orawSystem: does not exist (No such
> file or directory)
> > *** Deleting temp files
> > Deleting: C:/DOCUME~1/peter/LOCALS~1/Temp/ghc536.s
> >
> >
> >
> > /Peter
>
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

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

Re: Release Candidate for 6.2.1 available

[Sigbjorn Finne]

This looks a bit odd; your -v output suggests that GHC
is still installed in c:/ghc/ghc-6.2.1/, not in a space-separated
directory. What platform is this on?

Installing GHC in c:/Program Files/GHC/ seems to work just
fine here (w/ XP.)

--sigbjorn

- Original Message - 
From: "Peter Strand" <[EMAIL PROTECTED]>
To: "GHC users" <[EMAIL PROTECTED]>
Sent: Friday, March 12, 2004 09:33
Subject: Re: Release Candidate for 6.2.1 available


> Sigbjorn Finne wrote:
>
> >An installer for Windows users can now also be found in
> >that directory.
> >
> >- Original Message - 
> >From: "Simon Marlow" <[EMAIL PROTECTED]>
> >Subject: RE: Release Candidate for 6.2.1 available
> >
> >
> >>>   ghc-6.2.20040304 and later are release candidates for 6.2.1
> >>>Get them from here: http://www.haskell.org/ghc/dist/stable/dist/
> >>>
> >>>
> >>This is your last chance to test...  I'm going to freeze the release on
> >>Monday (15 March).
> >>
> >>
>
> If installed under a directory with spaces, it fails to produce object
files.
> 6.2 has the same problem, 6.0.1 works.
>
> End of output from "ghc -v --make t.hs":
>
> ...
> ...
> C:\ghc\ghc 6.2.1\gcc -B"C:\ghc\ghc 6.2.1\gcc-lib/" -I. -I. -c
C:\DOCUME~1\peter\
> LOCALS~1\Temp\ghc536.s -o t.o
>
> Failed: C:\ghc\ghc 6.2.1\gcc -B"C:\ghc\ghc 6.2.1\gcc-lib/" -I. -I. -c
C:\DOCUME~
> 1\peter\LOCALS~1\Temp\ghc536.s -o t.orawSystem: does not exist (No such
file or directory)
> *** Deleting temp files
> Deleting: C:/DOCUME~1/peter/LOCALS~1/Temp/ghc536.s
>
>
>
> /Peter

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

Re: Hello world fails on Win32

[Sigbjorn Finne]

I don't have access to a Win9x system right now, but
could you try compiling your example w/ 6.2 as follows:

ghc -o main
main.hs -pgma"c:\\ghc\\ghc-6.2\\gcc.exe -B\"C:\GHC\GHC-6.2\gcc-lib/\""

(minus any line wrapping my e-mail client will no doubt introduce.)

--sigbjorn


- Original Message - 
From: "Gour" <[EMAIL PROTECTED]>
To: "glasgow-haskell-bugs" <[EMAIL PROTECTED]>
Sent: Thursday, January 01, 2004 10:49
Subject: Re: Hello world fails on Win32


> Simon Peyton-Jones ([EMAIL PROTECTED]) wrote:
>
> > There's something very mysterious going on.  GHC does not depend on you
> > having any particular version of gcc etc; it all comes in the bundle.
>
> Yes, it looks mysterious.
>



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

Re: internal error: RTS exhausted max heap size (GHC 6.0.1)

[Sigbjorn Finne]

Hi,

thanks for the report. The handling of heap overflows
on your platform has been cleaned up in the current
sources, see:

http://haskell.org/pipermail/glasgow-haskell-bugs/2003-October/003699.html
http://haskell.org/pipermail/cvs-ghc/2003-October/018987.html

--sigbjorn

- Original Message - 
From: "Ben Rudiak-Gould" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 14, 2003 00:07
Subject: internal error: RTS exhausted max heap size (GHC 6.0.1)


> Athlon, Windows 2000, 512MB RAM, GHC 6.0.1 installed from
> www.haskell.org/ghc/dist/6.0.1/ghc-6-0-1.msi.
>
> > copy con bug.hs
> import Data.Array.IO (IOUArray)
> import Data.Array.MArray (newArray)
> import Data.Word (Word8)
>
> emptyArray :: IO (IOUArray Int Word8)
> emptyArray = newArray (1,1600) 0
>
> main = undefined
> ^Z
> > ghci bug.hs
>___ ___ _
>   / _ \ /\  /\/ __(_)
>  / /_\// /_/ / /  | |  GHC Interactive, version 6.0.1, for Haskell 98.
> / /_\\/ __  / /___| |  http://www.haskell.org/ghc/
> \/\/ /_/\/|_|  Type :? for help.
>
> Loading package base ... linking ... done.
> Compiling Main ( bug.hs, interpreted )
> Ok, modules loaded: Main.
> *Main> foo <- newArray (1,1600) 0 :: IO (IOUArray Int Word8)
> *Main> bar <- emptyArray
> : internal error: RTS exhausted max heap size (268435456
bytes)
>
> Please report this as a bug to [EMAIL PROTECTED],
> or http://www.sourceforge.net/projects/ghc/
>
>
> The "foo <-" line also runs far more slowly than I'd expect it to.
>
>
> -- Ben
>

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

Re: Overflown relocs in ghci

[Sigbjorn Finne]

Just to bring this one up-to-date -- Nathan Sidwell contributed
a BFD patch a couple of weeks ago which looks as if it fixes the
bug referred to below. So, once that fix percolates through to
a mingw release, this manual splitting up of object files should
be a thing of the past for GHC package builders on win32.

--sigbjorn

- Original Message - 
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: "Pasch, Thomas (ACTGRO)" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, October 24, 2003 15:17
Subject: Re: Overflown relocs in ghci


> Hi,
> 
> it looks as if you're running into a GNU ld/BFD bug
> where it emits bogus PE object files that have more than
> 0x relocations. The last time I looked this bug still
> wasn't fixed in the BFD codebase & there wasn't any
> noticeable interest in fixing it when I reported the bug
> a year or two ago.
> 
> The workaround is to split up the .o files that make up
> your package into two or more .o's, along the lines of
> how the "base" package does it.
> 
> hth
> --sigbjorn
> 
> Pasch, Thomas (ACTGRO) wrote:
> > Hello,
> > 
> > I'm working at the haskell-java bridge win32 port
> > (http://sourceforge.net/projects/jvm-bridge). I'm
> > using a recent MinGW installation and a ghc
> > 6.0.1. I can build tests in the Examples directory
> > without a problem. But when using ghci, I got
> > the following:
> > 
> > $ ghci -package javavm
> >___ ___ _
> >   / _ \ /\  /\/ __(_)
> >  / /_\// /_/ / /  | |  GHC Interactive, version 6.0.1, for
> > Haskell 98. / /_\\/ __  / /___| |  http://www.haskell.org/ghc/
> > \/\/ /_/\/|_|  Type :? for help.
> > 
> > Loading package base ... linking ... done.
> > Loading package lang ... linking ... done.
> > Loading package concurrent ... linking ... done.
> > Loading package haskell98 ... linking ... done.
> > Loading package javavm ... linking ... Overflown relocs: 4
> > done.
> > Prelude> :q
> > Leaving GHCi.
> > 
> > What does "Overflown relocs" mean? It seems to be
> > a problem, because when I try to load HelloWorld.hs:
> > 
> > Prelude> :load HelloWorld.hs
> > Skipping  Class_java_io_PrintStream ( Class_java_io_PrintStream.hs,
> > ./Class_java
> > _io_PrintStream.o )
> > Skipping  Class_java_lang_System ( Class_java_lang_System.hs,
> > ./Class_java_lang_
> > System.o )
> > Skipping  HelloWorld_JVM   ( HelloWorld_JVM.hs, ./HelloWorld_JVM.o )
> > Skipping  Main ( HelloWorld.hs, ./HelloWorld.o )
> > Ok, modules loaded: Main, HelloWorld_JVM, Class_java_lang_System,
> > Class_java_io_
> > PrintStream.
> > Prelude Main> main
> > 
> > ./HelloWorld.o: unknown symbol `___stginit_HelloWorldzuJVM_'
> > 
> > Sincerly,
> > 
> > Thomas
> > 
> 
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Overflown relocs in ghci

[Sigbjorn Finne]

Hi,

it looks as if you're running into a GNU ld/BFD bug
where it emits bogus PE object files that have more than
0x relocations. The last time I looked this bug still
wasn't fixed in the BFD codebase & there wasn't any
noticeable interest in fixing it when I reported the bug
a year or two ago.

The workaround is to split up the .o files that make up
your package into two or more .o's, along the lines of
how the "base" package does it.

hth
--sigbjorn

Pasch, Thomas (ACTGRO) wrote:
> Hello,
> 
> I'm working at the haskell-java bridge win32 port
> (http://sourceforge.net/projects/jvm-bridge). I'm
> using a recent MinGW installation and a ghc
> 6.0.1. I can build tests in the Examples directory
> without a problem. But when using ghci, I got
> the following:
> 
> $ ghci -package javavm
>___ ___ _
>   / _ \ /\  /\/ __(_)
>  / /_\// /_/ / /  | |  GHC Interactive, version 6.0.1, for
> Haskell 98. / /_\\/ __  / /___| |  http://www.haskell.org/ghc/
> \/\/ /_/\/|_|  Type :? for help.
> 
> Loading package base ... linking ... done.
> Loading package lang ... linking ... done.
> Loading package concurrent ... linking ... done.
> Loading package haskell98 ... linking ... done.
> Loading package javavm ... linking ... Overflown relocs: 4
> done.
> Prelude> :q
> Leaving GHCi.
> 
> What does "Overflown relocs" mean? It seems to be
> a problem, because when I try to load HelloWorld.hs:
> 
> Prelude> :load HelloWorld.hs
> Skipping  Class_java_io_PrintStream ( Class_java_io_PrintStream.hs,
> ./Class_java
> _io_PrintStream.o )
> Skipping  Class_java_lang_System ( Class_java_lang_System.hs,
> ./Class_java_lang_
> System.o )
> Skipping  HelloWorld_JVM   ( HelloWorld_JVM.hs, ./HelloWorld_JVM.o )
> Skipping  Main ( HelloWorld.hs, ./HelloWorld.o )
> Ok, modules loaded: Main, HelloWorld_JVM, Class_java_lang_System,
> Class_java_io_
> PrintStream.
> Prelude Main> main
> 
> ./HelloWorld.o: unknown symbol `___stginit_HelloWorldzuJVM_'
> 
> Sincerly,
> 
> Thomas
> 

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

Re: valgrind error

[Sigbjorn Finne]

Thanks for the report. That unnecessary copying operation
was removed in HEAD a couple of months back; the upcoming
6.2 release includes the changes.

--sigbjorn

- Original Message - 
From: "Abraham Egnor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, October 11, 2003 08:07
Subject: valgrind error


> Just for fun, I decided to run valgrind on the "empty program", i.e. main
> = return (), compiled with ghc 6.0.1.  Much to my surprise, it found an
> error:
>
> ==21117== Source and destination overlap in strcpy(0xbc02, 0xbc04)
> ==21117==at 0x40021E99: strcpy (mac_replace_strmem.c:87)
> ==21117==by 0x8063D45: setupRtsFlags (in
> /home/abe/src/haskell/test/empty)
> ==21117==by 0x402B3DBD: __libc_start_main (in /lib/libc-2.3.2.so)
> ==21117==by 0x8049320: (within /home/abe/src/haskell/test/empty)
>
> I'm not sure whether this is even a bug or just an artifact of weird
> memory handing in the RTS, but it's worrying either way.
>
> Abe
>

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

Re: renameFile in GHC 6.0 (Windows)

[Sigbjorn Finne]

Hi there,

thanks for pointing this one out -- the CVS version of renameFile now
behaves uniformly across platforms.

--sigbjorn

- Original Message - 
From: "Ben Horsfall" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 07, 2003 21:48
Subject: renameFile in GHC 6.0 (Windows)


> I noticed that renameFile in the Directory module in GHC 6.0 on Windows
(NT 4
> Workstation; sorry, I didn't check the service pack) throws an error when
a
> file already exists in the new FilePath (sorry again, I can't remember the
> exact error). The Report (& GHC documentation) say that "If the new object
> already exists, it is atomically replaced by the old object", and that
> behaviour seems to be implemented correctly by GHC 6.0 on Linux.
>

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

Re: GHCi bug - the impossible happened loading FranTk with ghc-6.0 on Win32

[Sigbjorn Finne]

Sigh, this time with an attachement..

- Original Message - 
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: "Simon Peyton-Jones" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, June 23, 2003 12:53
Subject: Re: GHCi bug - the impossible happened loading FranTk with ghc-6.0
on Win32


> I tidied up this aspect of TclHaskell / FranTk as part of a Galois
> project a while ago. Attached are the as-is changes needed to
> avoid being dependent on RTS internals & stop doing a busy wait.
> In addition to these diffs, you also want to comment out the defn of
> isOnlyProcess in  TclCompatibilityGhcSupportsConcurrency.hs
>
> hth
> --sigbjorn
>
> - Original Message - 
> From: "Simon Peyton-Jones" <[EMAIL PROTECTED]>
> To: "GHC bugs" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
> Cc: "Meurig Sage" <[EMAIL PROTECTED]>
> Sent: Monday, June 23, 2003 02:32
> Subject: RE: GHCi bug - the impossible happened loading FranTk with
ghc-6.0
> on Win32
>
>
> > Simon
> >
> > The underlying problem is that no one is maintaining FranTk at the
> > moment.  Perhaps you'd like to?
> >
> > Anyway, FranTk seems to use an un-documented (and therefore unreliable)
> > hook into GHC's RTS.  When you use GHCi to load systems that link to RTS
> > hooks, the dynamic linker's symbol table must be initialised to include
> > those symbols.  So the 'solution' here is to add 'run_queue_hd' to the
> > RTS_SYMBOLS in ghc/rts/Linker.c.  You'll need to build GHC from source
> > do to this.
> >
> > Longer term, it'd be a good plan to see just what FranTk wants to know
> > here, and what API the RTS should expose to support it.
> >
> > Admittedly, ghci dies with a rather unhelpful message
> >
> > Simon
> >
> >
> > | -Original Message-
> > | From: Meurig Sage [mailto:[EMAIL PROTECTED]
> > | Sent: 12 June 2003 16:26
> > | To: Simon Peyton-Jones
> > | Cc: Meurig Sage
> > | Subject: Re: GHCi bug - the impossible happened loading FranTk with
> > ghc-6.0 on Win32
> > |
> > | Hi Simon
> > |
> > ...
> > |
> > | That being said as far as I remember:
> > | FranTk contains the following function which attempts to check whether
> > there
> > | are any other threads waiting to be scheduled. If there are none then
> > it
> > | blocks waiting for more user input events, if there are any then it
> > simply
> > | queries the user input event queue and returns immediately. This makes
> > use
> > | of a variable run_queue_hd exported by Schedule.h (I think) in the ghc
> > | run-time system. When I was working on this in ghc-5.0x ghc compiled
> > ghc
> > | code provided access to this variable but ghc-i did not. Not sure what
> > Simon
> > | Marlow has done to this since.
> > |
> > | Hope this helps
> > |
> > | The function that does the check is the following one in
> > | FranTk/TclHaskellSrc/TclCompatibilityGhcSupportsConcurrency.hs.
> > |
> > |
> > | isOnlyProcess :: IO Bool
> > | isOnlyProcess = fmap toBool $ _casm_ ``%r = run_queue_hd ==
> > END_TSO_QUEUE;''
> > |  where
> > |   toBool :: Int -> Bool
> > |   toBool 0 = False
> > |   toBool _ = True
> > |
> > | Meurig
> > |
> > | - Original Message -
> > | From: "Simon Peyton-Jones" <[EMAIL PROTECTED]>
> > | To: "Meurig Sage" <[EMAIL PROTECTED]>
> > | Sent: Thursday, June 12, 2003 2:13 PM
> > | Subject: FW: GHCi bug - the impossible happened loading FranTk with
> > ghc-6.0
> > | on Win32
> > |
> > |
> > | Hi Meurig
> > |
> > | Are you still around?  Do you remember what the issue is here?  We
> > | havn't the foggiest idea
> > |
> > | Simon
> > |
> > | -Original Message-
> > | From: [EMAIL PROTECTED]
> > | [mailto:[EMAIL PROTECTED] On Behalf Of Guest,
> > | Simon
> > | Sent: 12 June 2003 09:12
> > | To: [EMAIL PROTECTED]
> > | Subject: GHCi bug - the impossible happened loading FranTk with
> > ghc-6.0
> > | on Win32
> > |
> > | I can use FranTk with GHC-6.0 on Windows XP just fine in some
> > | configurations.
> > | It's OK when compiling with GHC.  It's also OK with GHCi when using
> > | FranTk with no concurrency.
> > |
> > | However, when trying to load a concurrency enabled FranTk into GHCi, I
>

Re: GHCi bug - the impossible happened loading FranTk with ghc-6.0 on Win32

[Sigbjorn Finne]

I tidied up this aspect of TclHaskell / FranTk as part of a Galois
project a while ago. Attached are the as-is changes needed to
avoid being dependent on RTS internals & stop doing a busy wait.
In addition to these diffs, you also want to comment out the defn of
isOnlyProcess in  TclCompatibilityGhcSupportsConcurrency.hs

hth
--sigbjorn

- Original Message - 
From: "Simon Peyton-Jones" <[EMAIL PROTECTED]>
To: "GHC bugs" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: "Meurig Sage" <[EMAIL PROTECTED]>
Sent: Monday, June 23, 2003 02:32
Subject: RE: GHCi bug - the impossible happened loading FranTk with ghc-6.0
on Win32


> Simon
>
> The underlying problem is that no one is maintaining FranTk at the
> moment.  Perhaps you'd like to?
>
> Anyway, FranTk seems to use an un-documented (and therefore unreliable)
> hook into GHC's RTS.  When you use GHCi to load systems that link to RTS
> hooks, the dynamic linker's symbol table must be initialised to include
> those symbols.  So the 'solution' here is to add 'run_queue_hd' to the
> RTS_SYMBOLS in ghc/rts/Linker.c.  You'll need to build GHC from source
> do to this.
>
> Longer term, it'd be a good plan to see just what FranTk wants to know
> here, and what API the RTS should expose to support it.
>
> Admittedly, ghci dies with a rather unhelpful message
>
> Simon
>
>
> | -Original Message-
> | From: Meurig Sage [mailto:[EMAIL PROTECTED]
> | Sent: 12 June 2003 16:26
> | To: Simon Peyton-Jones
> | Cc: Meurig Sage
> | Subject: Re: GHCi bug - the impossible happened loading FranTk with
> ghc-6.0 on Win32
> |
> | Hi Simon
> |
> ...
> |
> | That being said as far as I remember:
> | FranTk contains the following function which attempts to check whether
> there
> | are any other threads waiting to be scheduled. If there are none then
> it
> | blocks waiting for more user input events, if there are any then it
> simply
> | queries the user input event queue and returns immediately. This makes
> use
> | of a variable run_queue_hd exported by Schedule.h (I think) in the ghc
> | run-time system. When I was working on this in ghc-5.0x ghc compiled
> ghc
> | code provided access to this variable but ghc-i did not. Not sure what
> Simon
> | Marlow has done to this since.
> |
> | Hope this helps
> |
> | The function that does the check is the following one in
> | FranTk/TclHaskellSrc/TclCompatibilityGhcSupportsConcurrency.hs.
> |
> |
> | isOnlyProcess :: IO Bool
> | isOnlyProcess = fmap toBool $ _casm_ ``%r = run_queue_hd ==
> END_TSO_QUEUE;''
> |  where
> |   toBool :: Int -> Bool
> |   toBool 0 = False
> |   toBool _ = True
> |
> | Meurig
> |
> | - Original Message -
> | From: "Simon Peyton-Jones" <[EMAIL PROTECTED]>
> | To: "Meurig Sage" <[EMAIL PROTECTED]>
> | Sent: Thursday, June 12, 2003 2:13 PM
> | Subject: FW: GHCi bug - the impossible happened loading FranTk with
> ghc-6.0
> | on Win32
> |
> |
> | Hi Meurig
> |
> | Are you still around?  Do you remember what the issue is here?  We
> | havn't the foggiest idea
> |
> | Simon
> |
> | -Original Message-
> | From: [EMAIL PROTECTED]
> | [mailto:[EMAIL PROTECTED] On Behalf Of Guest,
> | Simon
> | Sent: 12 June 2003 09:12
> | To: [EMAIL PROTECTED]
> | Subject: GHCi bug - the impossible happened loading FranTk with
> ghc-6.0
> | on Win32
> |
> | I can use FranTk with GHC-6.0 on Windows XP just fine in some
> | configurations.
> | It's OK when compiling with GHC.  It's also OK with GHCi when using
> | FranTk with no concurrency.
> |
> | However, when trying to load a concurrency enabled FranTk into GHCi, I
> | get "the impossible happened".
> |
> | I tried the workaround for the other GHCi bug, but this apparently
> | different, as shown below.
> |
> | Full disclosure requires me to highlight the following text from the
> | FranTk makefile:
> |
> | # Ununcomment this line to support concurrency.
> | # This support does NOT work with ghci. It does not currently export
> | # the special run_head_queue variable. Will allegedly
> | # be fixed in a future version of ghc.
> |
> | # this version supports concurrency
> | SUPPORTCONCURRENCY = TclCompatibilityGhcSupportsConcurrency.hs
> |
> | Is it simply that this hasn't been fixed yet?  (I'm not sure what
> | symptoms are "expected".)
> | I'd very much like to be able to use FranTk with concurrency.  Any
> | chance of a fix?
> |
> | cheers,
> | Simon
> |
> | 
> | sjg-pc$ ghci
> |___ ___ _
> |   / _ \ /\  /\/ __(_)
> |  / /_\// /_/ / /  | |  GHC Interactive, version 6.0, for Haskell
> 98.
> | / /_\\/ __  / /___| |  http://www.haskell.org/ghc/
> | \/\/ /_/\/|_|  Type :? for help.
> |
> | Loading package base ... linking ... done.
> | Loading package lang ... linking ... done.
> | Loading package text ... linking ... done.
> | Prelude> :t GHC.Err.error
> | GHC.Err.error :: forall a. [Char] -> a
> | Prelude> :set -package FranTk
> | Loading package concurrent ... linking ... done.
> | Loading package haskell98 ... linking

Re: COM events with HaskellDirect?

[Sigbjorn Finne]

Yes, examples/ie-listen/ in the HDirect distrib demonstrates
how to sink events (from IE, in that particular example.)

--sigbjorn

[btw, the CVS version of HDirect was updated a while ago to
work with current versions of GHC & Hugs.]

- Original Message - 
From: "Paul Steckler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 21, 2003 14:07
Subject: COM events with HaskellDirect?


> A user asks: Is it possible to have a COM component scripted with 
> Haskell invoke Haskell code via a COM event?
> 
> -- Paul
> 
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: getProtocolNumber garbage (was: Network on Win98: failed - socket - no error ??)

[Sigbjorn Finne]

Thanks for chasing this one down. WinSock only supports
'short's as protocol numbers in 'protoent's, whereas 'int's seems
to be the norm, hence the garbled result.

Shouldn't be too hard to fix.

--sigbjorn

- Original Message -
From: "Claus Reinke" <[EMAIL PROTECTED]>
To: "Simon Peyton-Jones" <[EMAIL PROTECTED]>; "Sigbjorn Finne"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, March 07, 2003 11:06
Subject: getProtocolNumber garbage (was: Network on Win98: failed - socket -
no error ??)


>
> okay, after giving myself a day to recover from the frustration,
> I've given it fresh try today, and can at last report the source
> of the problem and a workaround (thanks to Sigbjorn for helping
> me to narrow down the source). I leave precise location of the
> bug and proper fix to the experts:-)
>
> ghc's 'getProtocolNumber "tcp"' returns garbage on my win98 box
> (ghc-5.04.2, perhaps a marshalling problem??).
>
> perl's version gives me: 6
> ghc's version gives me: 1398538246
>
> Putting in the more sensible value explicitly makes the program
> work as expected, so winsock was really quite right to report
>
> WSAEAFNOSUPPORT 10047
> Address family not supported by protocol family,
>
> just that I didn't expect the error to be with the parameters..
> (and my hacked-up error-reporting didn't include the
> erroneous values themselves..).
>
>
> On the topic of libraries: although ghc doesn't value binary compatibility
> as high as its user's do;-) I would expect the libraries to develop faster
than
> ghc's binary incompatibilities in the near future (or is this
unreasonable?).
>
> So it would really be useful to have regular binary snapshots of the
libaries,
> built to work with(*) the latest binary release of GHC, but distributed
separately.
> When the current libraries can no longer be built for the latest GHC
release, it's
> a sure sign that a new one is needed..
>
> (*) note that this might well be different from "built with", as long as
the ghc
> modifications needed do not compromise binary compatibility.
>
> >A word of caution here.  Parts of the libraries, especially base/GHC/*,
> >may be GHC-version-specific.  We do not put lots of ifdefs in the
> >library sources to cope with different GHC versions, because they are
> >expected to be built with the GHC from the same tree.
> >So, it may work, but it may not.
>
> The usual cvs-rule is not to check in things that don't compile, so even
> without lots of ifdefs, it would be useful to have a simple text file for
> each package, stating the version of GHC/Hugc/nhc with which it was
> compiled (and wether or not it compiles with the latest binary release?).
>
> Btw, does the web interface to the cvs-tree give me an easy way to see
> the precise source versions wich make up the latest binary release? I find
> it difficult to check whether there have been any changes relevant to my
> problems. A good start would be to have the tag for the latest binary
release
> as the selected diff target by default?
>
> Finally cheerful again,
> Claus
>
>
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

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

Re: Network on Win98: failed - socket - no error ??

[Sigbjorn Finne]

Something's up with your WinSock setup on that machine,
I suspect -- works fine on the Win98 box I tested it on.
You may want to investigate whether the 'identical' client
written in C (or some such) behaves as expected on that
box..

The HEAD version of the 'network' package tidies up the
propagation of WinSock errors. It also drops the need for
the user to remember to use withSocketsDo.

--sigbjorn


- Original Message -
From: "Claus Reinke" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 05, 2003 04:36
Subject: Re: Network on Win98: failed - socket - no error ??


> [moved from ghc-users]
>
> I'm still not sure what I'm doing wrong in using the Network library,
> (inserting WSAGetLastError after the socket call returns 10047 -
> address family not supported by protocol family; better than "no error",
> but what do I do about it? modified source attached for reference),
> but the handling of errors in Network now definitely looks like a bug to
me:
>
> When the implementation is based on WinSock, functions should not check
> for errno, but for WSAGetLastError, especially so if control-flow depends
on
> the result..
>
> Cheers,
> Claus
>
>
> WSAEAFNOSUPPORT 10047
> Address family not supported by protocol family.
> An address incompatible with the requested protocol was used. All sockets
are created with an
> associated address family (that is, AF_INET for Internet Protocols) and a
generic protocol type
> (that is, SOCK_STREAM). This error is returned if an incorrect protocol is
explicitly requested in
> the socket call, or if an address of the wrong family is used for a
socket, for example, in sendto.
>
>
> > Still looking for inspirations on this one. I'm not at all sure I
interpret the chain
> > of indirections in the CVS sources correctly, but Network.Socket uses
> > throwErrnoIfMinus1Retry, which does indeed try to use errno to figure
out
> > what went wrong. Is that redirected anywhere for windows?
> >
> > Because, in their infinite wisdom, the designers of Windows Sockets have
> > decided that errno isn't the way:
> >
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win
sock/error_codes_errno_h
> > _errno_and_wsagetlasterror_2.asp
> >
> > Platform SDK: Windows Sockets 2
> >
> > Error Codes - errno, h_errno and WSAGetLastError
> >
> > Error codes set by Windows Sockets are not made available through
the errno variable.
> > Additionally, for the getXbyY class of functions, error codes are not
made available through the
> > h_errno variable. Instead, error codes are accessed by using the
WSAGetLastError function. This
> > function is provided in Windows Sockets as a precursor (and eventually
an alias) for the
> Microsoft®
> > Windows® function GetLastError. This is intended to provide a reliable
way for a thread in a
> > multithreaded process to obtain per-thread error information.
> > ...
> >
> > Just trying to make sure that I'm worrying about the "right" error
message..
> >
> > Cheers,
> > Claus
> >
> >
> > - Original Message -
> > From: "Claus Reinke" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, March 03, 2003 12:14 PM
> > Subject: Network on Win98: failed - socket - no error ??
> >
> >
> > > I'm playing with the Network library (the recommended portable way?)
and
> > > have a surprising problem with a simple client/server example. As the
same
> > > program works fine on Solaris and Win2k, I suspect its a standard
"feature"
> > > and someone here with more network programming experience might be
> > > able to enlighten me?
> > >
> > > - Server: listenOn port, then accept handle and enter loop, echoing
from
> > > handle to stdout
> > > - Client: connectTo "localhost" port, then enter loop echoing from
> > > stdin to handle
> > >
> > > Both programs work on Solaris and Win2k, but fail on Win98, with:
> > >
> > > Fail: failed
> > > Action: socket
> > > Reason: No error
> > >
> > > which would be merely amusing, I guess, if I knew what it meant, and
> > > what to do about it?
> > >
> > > Cheers,
> > > Claus
>
>

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

Re: GHC Undefined

[Sigbjorn Finne]

If you're mixing code compiled and linked with different
versions of binutils / gcc, then you're pretty much on your
own - i.e., I'm assuming you didn't build pdcurses via
'ghc' but 'gcc' & 'ld'/'dllwrap'.

--sigbjorn

- Original Message -
From: "michael vorin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 14:13
Subject: GHC Undefined


> Whilst I was trying to get the curses binding example in QForeign to
compile
> - I stumbled on what I believe to be a bug. Essentialy I believe that the
> version of ld.exe that you have packaged up with ghc 5.04 win32 has a bug
or
> is perhaps badly configured.
>
> ghc uses - GNU ld version 2.11.90 (20010704) (with BFD 2.11.90)
>
> which did not properly resolve external references to variables (see
below).
>
> I resolved problem by using - GNU ld version 2.13, from current mingw
> release.
>
> my configuration
> GHC 5.04 Win32 running on win2K platform.
> What I encountered
> 
> ghc -fglasgow-exts CursesTest.hs CursesTest_hsc.c Curses.hs curses_hsc.c
> -lpdcurses
>
> curses_hsc.o(.text+0x4):curses_hsc.c: undefined reference to `stdscr'
> curses_hsc.o(.text+0x10):curses_hsc.c: undefined reference to `LINES'
> curses_hsc.o(.text+0x1c):curses_hsc.c: undefined reference to `COLS'
> curses_hsc.o(.text+0x28):curses_hsc.c: undefined reference to
`COLOR_PAIRS'
> curses_hsc.o(.text+0x34):curses_hsc.c: undefined reference to `COLORS'
>
>
> when I had a look at the object files and the libpdcurses.dll, the
> appropriate symbols were in fact defined, and in fact all functions were
> resolved, the above symbols represent bindings to variables declared as
> follows:-
>
> extern int LINES;
>
> 2. setup of a test
> -
> I setup a test (test.c attached) where I just had one external reference
> that I was trying to resolve. I compiled it
>
>
> curses\tst-lines>ghc tst.c -o tst.exe -lpdcurses
> tst.o(.text+0x4):tst.c: undefined reference to `LINES'
>
> curses\tst-lines>gcc tst.c -o tst.exe -lpdcurses
> Info: resolving _LINES by linking to __imp__LINES (auto-import)
>
> the above should give the same result, i.e. the later result
>
> 3. fix
> 
> I copied ld.exe from my mingw release (version 2.13) over ld.exe in the
ghc
> release (version 2.11.90 ). This solved my problem
>
> 4. postmortem
> -
> why the problem ? Does this problem occur with all external variable
> references or is limitted to a few dll libraries, does it occur linking
> against static libraries ?
>
> I don't know
>
>
>
> _
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>

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

Re: import ambiguity

[Sigbjorn Finne]

Hi,

thanks for the report. Now fixed.

--sigbjorn

- Original Message - 
From: "Dean Herington" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 23, 2002 09:14
Subject: import ambiguity


> With the program:
> 
> import Exception
> main = let catch = Prelude.catch in catch (print "ok") print
> 
> hugs 98 version 20021021 gives:
> 
...
> Dependency analysis
> ERROR "ImportAmbiguity.hs":2 - Ambiguous variable occurrence "catch"
> *** Could refer to: Prelude.catch Exception.catch
> 
...

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

Re: Directory.doesDirectoryExist inconsistency

[Sigbjorn Finne]

That would take care of the incompatibility here, but
it's a slippery slope. Should Haskell provide you with
a platform-independent view of filenames and file
systems?

--sigbjorn

- Original Message -
From: "Simon Peyton-Jones" <[EMAIL PROTECTED]>
To: "Sigbjorn Finne" <[EMAIL PROTECTED]>; "Claus Reinke"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, October 22, 2002 08:50
Subject: RE: Directory.doesDirectoryExist inconsistency


> Sigbjorn (and others interested in Win32 I/O behaviour)
>
> The fact that MS CRT differs from Unix doesn't mean that the Haskell
> interface should necessarily differ.  The Haskell impl of
> doesDirectoryExist could, on Win32, trim off trailing '/' or '\', in
> order to make the behaviour consistent.  Where it's possible to get
> consistent behaviour, we should strive for that.  Do you agree?
>
> Simon
>
> | -Original Message-
> | From: Sigbjorn Finne [mailto:sof@;galois.com]
> | Sent: 16 October 2002 15:54
> | To: Claus Reinke
> | Cc: [EMAIL PROTECTED]
> | Subject: Re: Directory.doesDirectoryExist inconsistency
> |
> | This is known behaviour of the MS CRT implementation
> | of stat() on directories -- trailing slashes will cause it to
> | report ENOENT.
> |
> | Undesirable behaviour, you might (reasonably) say, but
> | the format of FilePaths is left system-specific by Haskell98.
> |
> | --sigbjorn
> |
> | - Original Message -
> | From: "Claus Reinke" <[EMAIL PROTECTED]>
> | To: <[EMAIL PROTECTED]>
> | Sent: Wednesday, October 16, 2002 07:21
> | Subject: Directory.doesDirectoryExist inconsistency
> |
> |
> | > I've just been chasing a portability problem, where a largish
> third-party
> | > program works fine on our suns (ghc-5.02.3), but chokes under
> | > cygwin/windows (ghc-5.04). Comes down to an inconsistency in the
> | > handling of (trailing?) slashes in Directory.doesDirectoryExist (see
> | > a and b below).
> | >
> | ...
> |
> | ___
> | Glasgow-haskell-bugs mailing list
> | [EMAIL PROTECTED]
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

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

Re: Directory.doesDirectoryExist inconsistency

[Sigbjorn Finne]

This is known behaviour of the MS CRT implementation
of stat() on directories -- trailing slashes will cause it to
report ENOENT.

Undesirable behaviour, you might (reasonably) say, but
the format of FilePaths is left system-specific by Haskell98.

--sigbjorn

- Original Message - 
From: "Claus Reinke" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 16, 2002 07:21
Subject: Directory.doesDirectoryExist inconsistency


> I've just been chasing a portability problem, where a largish third-party
> program works fine on our suns (ghc-5.02.3), but chokes under
> cygwin/windows (ghc-5.04). Comes down to an inconsistency in the
> handling of (trailing?) slashes in Directory.doesDirectoryExist (see
> a and b below).
> 
...

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

Re: Newbie building GHC

[Sigbjorn Finne]

Oops, while trivial, I forgot to include the main.c test
wrapper:

foo$ cat main.c
#include 
extern int invokeCmd(char* cmd);

int main() {
  printf("%d\n", invokeCmd("uname"));
  return 0;
}


--sigbjorn

- Original Message ----- 
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Saswat Anand" <[EMAIL PROTECTED]>
Sent: Thursday, September 26, 2002 12:18
Subject: Re: Newbie building GHC


> Here's more background info:
> 
> - On a Redhat 7.2 box, install the ghc-5.04.1 RPM
> - do the following:
> 
> rh7.2$ cat M.hs
> module M where { import System; main = system "uname" >>= print }
> rh7.2$ ghc -o m M.hs
> rh7.2$ ./m
> ExitFailure 127
> 
> You can also reproduce this using just C code by compiling
> up the attached invoke.c file on a RedHat 7.3 box, and
> then linking it together with this little test stub on a RH7.2
> box:
> 
> rh7.3$ gcc --version
> 2.96
> rh7.3$ gcc -O -c invoke.c
> 
> ---
> 
> rh7.2$ gcc --version
> 2.96
> rh7.2$ gcc -o main main.c invoke.o
> rh7.2$ ./main
> 127
> rh7.2$ 
> 
> Peering at the generated binaries and assembly output, it
> appears as if BFD (=> assembler/linker) has changed
> the code it emits to refer to strings in the read-only
> data section. 
> 
> Fascinating though that is, avoiding mixing code built on
> these two 'platforms' is probably the only valuable piece
> of info to take away from all this.
> 
> May I suggest the GHC downloads page drops the claim
> that the 5.04.1 RPMs will work under RH7.2?
> 
> --sigbjorn
> 
> - Original Message - 
> From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
> To: "Saswat Anand" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Thursday, September 26, 2002 08:52
> Subject: Re: Newbie building GHC
> 
> 
> > Hi there,
> > 
> > we've been running into similar problems here on a Redhat 7.2
> > box using the ghc-5.04.1 RPM (which was built on RedHat 7.3).
> > The salient line from your strace output is the following one:
> > 
> > [pid  1514] execve("n/sh", ["/bin/sh", "-c", "gcc Adjustor.c
> > -o /tmp/ghc1513.s"...], [/* 36 vars */])
> >   = -1 ENOENT (No such file or directory)
> > 
> > execl() (called by System.system) is somehow causing execve()
> > to be invoked with a stripped off command arg.
> > 
> > The cause of this suspected outbreak of Linux versionitis is as yet
> > unknown (gcc? glibc?..), but you may want to try installing the
> > .tar.bz2 instead (which was built on a RH 7.2 box.) That worked
> > around the problem here, at least.
> > 
> > hth
> > --sigbjorn
> > 
> 
> 

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

Re: Newbie building GHC

[Sigbjorn Finne]

Here's more background info:

- On a Redhat 7.2 box, install the ghc-5.04.1 RPM
- do the following:

rh7.2$ cat M.hs
module M where { import System; main = system "uname" >>= print }
rh7.2$ ghc -o m M.hs
rh7.2$ ./m
ExitFailure 127

You can also reproduce this using just C code by compiling
up the attached invoke.c file on a RedHat 7.3 box, and
then linking it together with this little test stub on a RH7.2
box:

rh7.3$ gcc --version
2.96
rh7.3$ gcc -O -c invoke.c

---

rh7.2$ gcc --version
2.96
rh7.2$ gcc -o main main.c invoke.o
rh7.2$ ./main
127
rh7.2$ 

Peering at the generated binaries and assembly output, it
appears as if BFD (=> assembler/linker) has changed
the code it emits to refer to strings in the read-only
data section. 

Fascinating though that is, avoiding mixing code built on
these two 'platforms' is probably the only valuable piece
of info to take away from all this.

May I suggest the GHC downloads page drops the claim
that the 5.04.1 RPMs will work under RH7.2?

--sigbjorn

----- Original Message - 
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: "Saswat Anand" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, September 26, 2002 08:52
Subject: Re: Newbie building GHC


> Hi there,
> 
> we've been running into similar problems here on a Redhat 7.2
> box using the ghc-5.04.1 RPM (which was built on RedHat 7.3).
> The salient line from your strace output is the following one:
> 
> [pid  1514] execve("n/sh", ["/bin/sh", "-c", "gcc Adjustor.c
> -o /tmp/ghc1513.s"...], [/* 36 vars */])
>   = -1 ENOENT (No such file or directory)
> 
> execl() (called by System.system) is somehow causing execve()
> to be invoked with a stripped off command arg.
> 
> The cause of this suspected outbreak of Linux versionitis is as yet
> unknown (gcc? glibc?..), but you may want to try installing the
> .tar.bz2 instead (which was built on a RH 7.2 box.) That worked
> around the problem here, at least.
> 
> hth
> --sigbjorn
> 



#include 
#include 
#include 
#include 

int 
invokeCmd(char* cmd)
{
int pid;
int wstat;

switch(pid = fork()) {
case -1:
if (errno != EINTR) {
return -1;
}
case 0:
  {
/* the child */
execl("/bin/sh", "sh", "-c", cmd, NULL);
_exit(127);
  }
}

while (waitpid(pid, &wstat, 0) < 0) {
if (errno != EINTR) {
return -1;
}
}

if (WIFEXITED(wstat))
return WEXITSTATUS(wstat);
else if (WIFSIGNALED(wstat)) {
errno = EINTR;
}
else {
/* This should never happen */
}
return -1;

}

Re: Newbie building GHC

[Sigbjorn Finne]

Hi there,

we've been running into similar problems here on a Redhat 7.2
box using the ghc-5.04.1 RPM (which was built on RedHat 7.3).
The salient line from your strace output is the following one:

[pid  1514] execve("n/sh", ["/bin/sh", "-c", "gcc Adjustor.c
-o /tmp/ghc1513.s"...], [/* 36 vars */])
  = -1 ENOENT (No such file or directory)

execl() (called by System.system) is somehow causing execve()
to be invoked with a stripped off command arg.

The cause of this suspected outbreak of Linux versionitis is as yet
unknown (gcc? glibc?..), but you may want to try installing the
.tar.bz2 instead (which was built on a RH 7.2 box.) That worked
around the problem here, at least.

hth
--sigbjorn

- Original Message -
From: "Saswat Anand" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, September 23, 2002 23:44
Subject: Re: Newbie building GHC


> I ran strace with -ff option. Attached is the trace file. I can see many
"No
> such file or directory" in the trace. Can you see the problem?
>
> Thanks
> Saswat
>
>
>

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

Re: External Core typechecker

[Sigbjorn Finne]

 "Kirsten Chevalier" <[EMAIL PROTECTED]> writes:
> On Thu, Sep 05, 2002 at 12:20:27PM -0700, Sigbjorn Finne wrote:
> > To enable type checking of Core, compile with -dcore-lint
> >
> 
> Ah, thanks. You'd think it would do that by default when starting from
> an external Core file (hint :-))
> 

It actually does, but the type checking code that that front-end (re-)uses
does just a limited amount of checking (e.g., function applications aren't
checked..), hence the suggestion of using the more thorough -dcore-lint

--sigbjorn


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

Re: External Core typechecker

[Sigbjorn Finne]

To enable type checking of Core, compile with -dcore-lint

--sigbjorn

- Original Message -
From: "Kirsten Chevalier" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 05, 2002 12:05
Subject: External Core typechecker


> GHC doesn't seem to do much typechecking on external Core files; it
happily
> compiles .hcr files with type errors that then segfault when you run the
> program. An example of such a program is attached (the type error is on
> line 19, where cons is applied to the Integer type and two integer lists).
>
> I'm using the latest version of GHC (built from CVS sources yesterday,
using
> GHC 5.04 to bootstrap), on a RedHat Linux box with gcc 2.96.
>
> --
> Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in
doubt


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

Re: select() failure

[Sigbjorn Finne]

"Dean Herington" <[EMAIL PROTECTED]> writes:
> >
> > The assumption is that FDs are marked as non-blocking, so this won't
> > be a problem. Do you have a good reason not to have your FDs marked
> > as such?
>
> One reason is complexity.  If  I mark my FDs with O_NONBLOCK, don't I need
to
> wrap a loop around the `threadWaitRead`/`fdRead` combination, repeating
when
> `fdRead` returns error `EAGAIN`?
>

Yes, but the alternative of not doing so is much worse IMHO (you're forced
to
limit yourself to 1-byte read()s to avoid blocking.)

--sigbjorn


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

Re: select() failure

[Sigbjorn Finne]

"Dean Herington" <[EMAIL PROTECTED]> writes:
>
...
>
> When a thread wants to read from a file descriptor, its logic looks like:
>
> threadWaitRead (fdToInt fd)
> ([char], 1) <- locked (fdRead fd 1)
>
> where `locked` obtains and holds the aforementioned lock for the duration
of
> its argument action.
>
> Reflecting on the above, I now realize that the recent change
> (/fptools/ghc/rts/Select.c?rev=1.22 in GHC 5.04) to wake up all threads
when
> select() returns an EBADF error, though well-intentioned, is
inappropriate.
> The point of `threadWaitRead` and `threadWaitWrite` is to block the
calling
> thread until it's known that a subsequent call involving the given file
> descriptor will not block.  Allowing all threads to continue--even those
> whose file descriptor is not yet ready--allows for exactly the deadlock
that
> `threadWaitRead` and `threadWaitWrite` are designed to avoid.
>

The assumption is that FDs are marked as non-blocking, so this won't
be a problem. Do you have a good reason not to have your FDs marked
as such?

> I consider it a bug in select() that, when EBADF is reported, the sets of
> "ready" file descriptors are not also reported.

That would be the wrong thing to do, assuming the FD_SETs are in any
way valid when select() returns failure.

--sigbjorn


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

Re: ghc installer for Windows

[Sigbjorn Finne]

Hi,

I'm unable to reproduce the error on any local machines,
so could you try doing the following:

- start up a command shell
- cd into the directory where the 5.04 msi files lives
- run the following command:

 c:\downloads> msiexec /i ghc-5-04.msi /l* msi.log

that will run the MS installer with logging turned on. If you
could either send or point me at a copy of the resulting log
file, msi.log, that'd be very helpful in trying to narrow down
the cause of this.

thanks
--sigbjorn

- Original Message - 
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Stephen Eldridge" <[EMAIL PROTECTED]>
Sent: Monday, July 15, 2002 06:33
Subject: Fw: ghc installer for Windows


> Thanks for the report, forwarded to the bugs list.
> 
> It should be noted that the installer currently assumes
> that you're an administrator on the machine you're
> using.
> 
> --sigbjorn
> 
> - Original Message - 
> From: "Stephen Eldridge" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 15, 2002 05:25
> Subject: ghc installer for Windows
> 
> 
> > The current installer for ghc 5.05.1 seems to be faulty.
> > Rather to my surprise, I could only select a drive other than
> > the boot drive by going into the custom menu. Having selected
> > F: I then had to create the directory I wanted - ghc\ghc-5.04 -
> > before I could proceed (something apparently unnecessary
> > had I accepted the default). Unfortunately, the install then stops
> > with the error message that the network location
> > \C:\WINNT\Profiles\All Users\Start Menu\.
> > could not be accessed. If this message is correct then
> > the installer is looking for a malformed address with
> > the single backslash preceding the drive letter.
> > 
> > 
> > Stephen Eldridge
> > phone: 0161-200-3352email: [EMAIL PROTECTED]
> > Department of Computation, UMIST, Manchester M60 1QD
> 
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

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

Fw: ghc installer for Windows

[Sigbjorn Finne]

Thanks for the report, forwarded to the bugs list.

It should be noted that the installer currently assumes
that you're an administrator on the machine you're
using.

--sigbjorn

- Original Message - 
From: "Stephen Eldridge" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 15, 2002 05:25
Subject: ghc installer for Windows


> The current installer for ghc 5.05.1 seems to be faulty.
> Rather to my surprise, I could only select a drive other than
> the boot drive by going into the custom menu. Having selected
> F: I then had to create the directory I wanted - ghc\ghc-5.04 -
> before I could proceed (something apparently unnecessary
> had I accepted the default). Unfortunately, the install then stops
> with the error message that the network location
> \C:\WINNT\Profiles\All Users\Start Menu\.
> could not be accessed. If this message is correct then
> the installer is looking for a malformed address with
> the single backslash preceding the drive letter.
> 
> 
> Stephen Eldridge
> phone: 0161-200-3352email: [EMAIL PROTECTED]
> Department of Computation, UMIST, Manchester M60 1QD

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

Fw: crash with GHC 5.04

[Sigbjorn Finne]

Hi,

this appears to be GC-related; forwarded to the
bugs list. Thanks for the report.

--sigbjorn

- Original Message -
From: "Mark Tehver" <[EMAIL PROTECTED]>
To: "Sigbjorn Finne" <[EMAIL PROTECTED]>
Sent: Saturday, July 13, 2002 07:38
Subject: crash with GHC 5.04


> Hi again,
>
> I have run into another problem that I believe may be a bug in GHC 5.04.
> Perhaps I should post this to ghc-bugs mailing list as I am not sure
> if it is a Windows specific issue or something more general.
>
> Anyway, the problem is that the example I have attached to this mail
> crashes. It is a relatively simple example (I encountered a
> similar problem in a larger program and tried to simplify the issue as
> much as possible), the C++ program calls several functions that are
> exported from Haskell. For some reason, crash occours in loop
> interation 32. This does not seem to be C compiler problem as it happends
> with both MS VC and GCC. The program does not crash when I use GHC 5.02.3.
>
> Mark
>



crash.zip
Description: Zip compressed data

Re: unable to create DLL with GHC 5.04

[Sigbjorn Finne]

Hi,

looks as if you're mixing mingw and cygwin object
files. ghc-5.04 is mingw-based, so make sure you
feed in the flag -mno-cygwin to gcc when compiling
.c files.

--sigbjorn

- Original Message -
From: "Mark Tehver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 11, 2002 12:42
Subject: unable to create DLL with GHC 5.04


> Hi!
>
>   I seem to have some problem building DLLs under Win32 with GHC 5.04.
> When I follow the instructions from
>
http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/win32-dlls-forei
gn.html
> all looks ok until I do the last step. Then linker reports:
>
>
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld:
> warning: cannot find entry symbol _DllMainCRTStartup@12; defaulting to
> 63601000
>
C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xab1):StgMiscClosures.h
c:
> undefined reference to `_imp___iob'
>
C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xae5):StgMiscClosures.h
c:
> undefined reference to `_imp___iob'
>
C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xb19):StgMiscClosures.h
c:
> undefined reference to `_imp___iob'
>
C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xb4d):StgMiscClosures.h
c:
> undefined reference to `_imp___iob'
>
C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xb81):StgMiscClosures.h
c:
> undefined reference to `_imp___iob'
>
C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xbb5):StgMiscClosures.h
c:
> more undefined references to `_imp___iob' follow
> collect2: ld returned 1 exit status
> dllwrap: gcc exited with status 1
>
> With GHC 5.02.x all seemed to work fine...
>
> Best regards,
>
> Mark
>
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

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

Re: global random number generator initialisation

[Sigbjorn Finne]

You don't say, but I'm assuming you're using a recent'ish
GHC snapshot. A wibble that prevented the system/standard
RNG from being seeded with a time-varying value was fixed
sometime last week, so 5.04 will have it included.

--sigbjorn

- Original Message - 
From: "Ian Lynagh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 04, 2002 14:10
Subject: global random number generator initialisation


> 
> The library report, in "17.3  The global random number generator", says
> 
> It is initialised automatically in some system-dependent fashion,
> for example, by using the time of day, or Linux's kernel random
> number generator.
> 
> However, under Linux "randomIO :: IO Int" seems to generate the same
> values on each run.
> 
> The IO versions, randomRIO and randomIO, use the global random
> number generator (see Section 17.3).
> 
> While the report doesn't require it to be set to something pseudo random
> it would be nice if it was. Is there an obvious way to set it to
> something pseudo random in Haskell? The Time module isn't as well
> equiped as it could be for the task.
> 
> 
> Thanks
> Ian
> 


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

Re: GHC on Cygwin

[Sigbjorn Finne]

"Koen Claessen" <[EMAIL PROTECTED]> writes:
>
...
> 
> However, ghci crashes at start up time! I get the following
> behavior:
> 
> >>>
> [lap/bin] -: ./ghci
...
> 
> Loading package base ... linking ...
> /d/Work/Packages/Ghc/Install/lib/ghc-5.03/HSbase_cbits.o:
> unknown symbol `_sigaddset'
> ghc-5.03: panic! (the `impossible' happened, GHC version
> 5.03):
> can't load package `base'
> 
...
> 
> What to do?

I fixed the source of this one last week, so make sure the
compiler you're using to _build_ GHCi has got
an up-to-date version of ghc/rts/Linker.c

Once you do, you need to rebuild its ghc/rts, followed by
a re-link of the ghc executable that's invoked in the above.

--sigbjorn


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

Re: Install on win98 gives error

[Sigbjorn Finne]

"Jon Fairbairn" <[EMAIL PROTECTED]> writes:


> > Anyway, a new 5.02.3 installer which I _believe_ works around
> > the problem is available as:
> >
> >http://galois.com/~sof/ghc-5-02-3-1.msi
> >
> > It's a big download (~21M), but if you could try it out & let me
> > know if it improves matters, I'd appreciate it.
>
> As far as I can tell it installs without problem.  I
> selected uninstall first, and then ran install and got no
> errors.  I don't know whether the fact that a ghc had been
> installed and uninstalled might conceal any problems, but I
> don't know how to do better than that!
>

That's the way to do it - thanks for trying it out and
reporting back. I've uploaded the new installer to haskell.org
and adjusted the link on the downloads page to point to it
instead.

btw, this installer should also behave better with non-English
versions of Windows, adding GHC to the localised name of
the Programs folder on the startup menu.

> Thanks for mending it. BTW, is your name actually Sigbjorn,
> or has it got ASCIIfied from Sigbjörn?
>

It's o with a slash -- grew up in a 7 bit world and have yet
to bother upgrading :)

--sigbjorn


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

Re: Install on win98 gives error

[Sigbjorn Finne]

Hi there,

thanks for the report - Andre reported the same problem a while
ago, but I forgot to respond to him after having tracked down
the cause of the problem (sorry, Andre.)

Anyway, a new 5.02.3 installer which I _believe_ works around
the problem is available as:

   http://galois.com/~sof/ghc-5-02-3-1.msi

It's a big download (~21M), but if you could try it out & let me
know if it improves matters, I'd appreciate it. FYI, it does the
trick on a local Win98 box.

I'll spare you the grimy details, but this ultimately boils down to
Win9x OSes having a (16k-2) length limit on Registry entries.

--sigbjorn

- Original Message -
From: "Jon Fairbairn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 03, 2002 08:48
Subject: Install on win98 gives error


>
> I downloaded ghc-5.02.3 for win32 and Windows Installer.
> Installing ghc basically worked except that I got
>
>
>Error 1406. Could not write value _MainFeature to key
>UNKNOWN\Features\8C655693FA0801D4E7FA1CA60C4AAE1.
> Verify that you have sufficient access to that key, or contact your
>support personnel.
>
> or something very like it during the install (it doesn't
> seem to let you copy the text of the dbox). Now when I try
> to start ghci from the start menu I get the above error. If
> I click on ignore, ghci runs OK, so I don't really know what
> it's wittering about.
>
> BTW, the page  http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
> > mentions  http://www.haskell.org/ghc/docs/latest/set/bug-reports.html
> >, which doesn't exist.
>
> Cheers,
>
>  Jón
>


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

Re: External Core front-end in GHC 5.03

[Sigbjorn Finne]

I'm able to reproduce this with a stage1 build (built using
ghc-5.02.3), but not a stage2 build. Looks as if
parser/ParserCore.y is tickling a bug in 5.02.3 - try
regenerating parser/ParserCore.hs with Happy, but
stay away from the -c option - e.g.,

   foo$ happy -g parser/ParserCore.y

followed by a re-make in ghc/compiler. That "solves"
the problem for me.

--sigbjorn

- Original Message -
From: "Kirsten Chevalier" <[EMAIL PROTECTED]>
To: "Sigbjorn Finne" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, May 13, 2002 17:26
Subject: Re: External Core front-end in GHC 5.03


> On Wed, May 08, 2002 at 07:18:17AM -0700, Sigbjorn Finne wrote:
> > Hi,
> >
> > I'm unable to reproduce this here (with a 2002-05-07 HEAD build.)
> > Make sure no interface files from earlier GHC builds are in scope;
> > the -dshow-passes output you give hints that this _might_ be the cause.
> >
>
> I'm still having the same problem -- I tried the newest version of GHC
from
> CVS (as of today), as well as the April 11 snapshot (ghc-5.03.20020410). I
> don't think that any older interface files are in scope -- at least, there
are
> none in the same directory as the program being compiled. Any other ideas?
>
> Thanks,
> Kirsten
> (my original message is below)
>
> > - Original Message -
> > From: "Kirsten Chevalier" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Friday, May 03, 2002 15:39
> > Subject: External Core front-end in GHC 5.03
> >
> >
> > > Hi,
> > > I just downloaded and built the latest version of GHC from the CVS
> > repository
> > > yesterday and tried to use it to compile an external Core file, which
> > caused
> > > the compiler to crash:
> > >
> > > $ ghc -fext-core -fno-code hello.hs
> > > $ ghc hello.hcr
> > > Segmentation fault
> > >
> > > I know that the external Core feature is still a work in progress, but
is
> > > there something I should be doing differently or is it totally broken?
> > Here
> > > are the relevant details:
> > >
> > > $ uname -a
> > > Linux puma 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown
> > >
> > > $ gcc -v
> > > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> > > gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)
> > >
> > > and the results of compiling with -v:
> > > $ ghc -v hello.hcr
> > > Glasgow Haskell Compiler, Version 5.03, for Haskell 98, compiled by
GHC
> > version 5.02.1
> > > Using package config file:
> >
/home/crete/lumberjacks3/krc/ghc/fptools-build/ghc/driver/package.conf.inpla
> > ce
> > >
> > >  Packages 
> > > 
> > >
> > > Hsc static
> >
flags: -static -fignore-interface-pragmas -fomit-interface-pragmas -fdo-lamb
> > da-eta-expansion -flet-no-escape
> > > *** Checking old interface for hs = Just "hello.hcr", hspp = Just
> > "hello.hcr":
> > > *** Renamer:
> > > Segmentation fault
> > >
> > > The program I'm trying to compile is just:
> > >
> > > main = putStr "Hello world!"
> > >
> > > Thanks,
> > > Kirsten
> > >
>
> --
> Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in
doubt
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

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

Re: unsafePtrEq in 5.03?

[Sigbjorn Finne]

A spot of CVS archeology revealed that it was removed as
a primop as part of a NCG overhaul couple of months ago.
Don't know if leaving it out was simply an omission or
if there's something deeper going on.

Anyway, you can approximate the old defn with the following:

module PtrEq where

import GHC.Base
unsafePtrEq :: a -> a -> Bool
unsafePtrEq a b = (unsafeCoerce# a) `eqAddr#` (unsafeCoerce# b)

Clearly, it doesn't chase indirections.

hth
--sigbjorn

- Original Message - 
From: Conal Elliott 
To: Ghc-Bugs 
Sent: Tuesday, April 16, 2002 18:43
Subject: unsafePtrEq in 5.03?


Did unsafePtrEq disappear between 5.02 and 5.03?  - Conal

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

Re: Weird Activation Records (Fixed!)

[Sigbjorn Finne]

[moved to glasgow-haskell-bugs]

"Wolfgang Thaller" <[EMAIL PROTECTED]> writes:
>
 ...
>
> Due too my lack of Perl knowledge, I didn't yet manage to remove the 
> jumps from the slow to the fast entry points, and a function called 
> __DISCARD__ must be present for linking (it's never called, though).
> Should the old PowerPC code in the mangler be kept there? It assumes 
> a slightly different assembler dialect and a completely different 
> linker, and as it just asks for $TargetPlatform =~ /^powerpc|rs6000/, 
> it keeps getting in the way...

The uses of 'powerpc' refer to an AIX port that was done quite a while ago,
so if it's conflicting with your mods, just substitute 'powerpc' for
'powerpc-ibm-aix'

--sigbjorn


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

Re: IO.hReady, hWaitForInput differ on Linux / Windows

[Sigbjorn Finne]

Hi,

I added Win32 support for these a while ago; the 5.03
snapshot includes it.

--sigbjorn

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 27, 2002 23:37
Subject: IO.hReady, hWaitForInput differ on Linux / Windows


> Hi there,
>
> I'm using ghc 5.02.2 on Suse Linux 7.3 and Win2000.
> While on Linux everything seems to work as documented,
> on Windows 2000 "IO.hReady" always returns "True", which also
> means that "IO.hWaitForInput" always blocks even if no input is
> available.
>
> I would be very grateful for any hints how to avoid this problem.
>
> Cheers, dirk
>
>

__
> Die Nummer, die man nie vergisst: Ihre persönliche Wunschrufnummer von
WEB.DE!
> Jetzt einsteigen http://freemail.web.de/?mc=990002
>
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

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

ghc-5.02.2 panic (was: (no subject))

[Sigbjorn Finne]

Hi,

looks like a bona fide bug; thanks for reporting it. In order to
be able to fix it, any chance of you sending us that Main.hs?

thanks,
--sigbjorn

- Original Message - 
From: "Loffler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 25, 2002 12:47
Subject: (no subject)


> Hi,
> 
> I typed:
> ghc Main.hs
> 
> and then GHC said:
> GHC.EXE: panic! (the `impossible' happened, GHC version 5.02.2):
> Maybe.fromJust: Nothing
> 
> Please report it as a compiler bug to [EMAIL PROTECTED],
> or http://sourceforge.net/projects/ghc/.
> 
> -- Maarten
> 


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

Re: handling embedded spaces in output from ghc -M]

[Sigbjorn Finne]

Hi,

you're making a mountain out of a molehill; couple of
workarounds spring to mind:

* transform the -i path you feed to GHC -M, i.e., something
   like

ghc -M  -i`cygpath -w -s "c:\Program Files\GreenCard"`/lib/ghc

* post-process the generated dependencies file to insert the double
   quotes and/or escape the spaces yourself.

--sigbjorn

- Original Message - 
From: "Antony Courtney" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 25, 2002 00:14
Subject: [Fwd: handling embedded spaces in output from ghc -M]


> Hi,
> 
> I never heard a reply to this.
> 
> Is there any hope of getting this fixed?
> 
> If not, I'll have to ship my own private binary release of greencard 
> under windows, just so that it doesn't install in a directory with an 
> embedded space(!)  :-(
> 
> Thanks,
> 
> -antony
> 
> -- 
> Antony Courtney
> Grad. Student, Dept. of Computer Science, Yale University
> [EMAIL PROTECTED]  http://www.apocalypse.org/pub/u/antony
> 

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

Re: 'Pretty' does not export ($+$)

[Sigbjorn Finne]

Strange, the following compiles just fine with
5.02.1 on a Win2k box:

module Foo where { import Pretty ; x y = y Pretty.$+$ y }

--sigbjorn

- Original Message -
From: "Duncan Coutts" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 17, 2002 16:13
Subject: 'Pretty' does not export ($+$)


>
> The pretty printing module 'Pretty' in the text package does not export
the
> ($+$) operator. The documentation says it does (and it certianly should).
>
> I'm using ghc 5.02.1
>
> Duncan


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

Re: PAP_Entry: CATCH_FRAME

[Sigbjorn Finne]

Simon may have gone home for the weekend, so just
to let you know that he's checked in a fix for this
problem in the current CVS sources.

--sigbjorn

- Original Message -
From: "Peter White" <[EMAIL PROTECTED]>
To: "Simon Marlow" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, February 15, 2002 09:05
Subject: RE: PAP_Entry: CATCH_FRAME


> I have managed to create a small program that reproduces the error the way
I
> get to it. The output it produces is:
>
> Handler got: 1
> Exception: 1st
> Handler got: 2
> Error1: fatal error: PAP_entry: CATCH_FRAME
>
> The program was in a file "Error1.hs", that is why the fatal error begins
> with "Error1". The program follows, I hope this is helpful.
>
> module Main where
>
> import Concurrent
> import qualified Exception as E
>
> trapHandler :: MVar Int -> IO ()
> trapHandler inVar =
>   (do { trapMsg <- takeMVar inVar
>   ; putStrLn ("Handler got: " ++ show trapMsg)
>   ; trapHandler inVar
>   }
>   )
>   `E.catch`
>   (trapExc inVar)
>
> trapExc :: MVar Int -> E.Exception -> IO ()
> trapExc inVar e =
>   do { putStrLn ("Exception: " ++ show e)
>  ; trapHandler inVar
>  }
>
> main :: IO ()
> main =
>   do { inVar <- newEmptyMVar
>  ; tid <- forkIO (trapHandler inVar)
>  ; yield
>  ; putMVar inVar 1
>  ; threadDelay 1000
>  ; throwTo tid (E.UserError "1st")
>  ; threadDelay 1000
>  ; putMVar inVar 2
>  ; threadDelay 1000
>  ; throwTo tid (E.UserError "2nd")
>  ; threadDelay 1000
>  ; putStrLn "All done"
>  }
>
>
>
> -Original Message-
> From: Simon Marlow [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 15, 2002 2:55 AM
> To: Peter White; [EMAIL PROTECTED]
> Subject: RE: PAP_Entry: CATCH_FRAME
>
>
> > What does it mean when you get the fatal error "PAP_Entry:
> > CATCH_FRAME". I
> > am using ghc version 5.03.20020204. I looked in the ghc
> > source code and the
> > comment next to this error message says that it cannot happen.
>
> Well, you must be imagining it then :-)
>
> Seriously, I've seen this error too.  Try 'interact (unlines.lines)' in
GHCi
> and press ^C to see it (this works in 5.02.2 too).  I've been meaning to
> look at it, hopefully I'll get around to it today.
>
> Cheers,
> Simon
>
>
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

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

Re: ghc.exe: fatal error: Windows programs can only use 256Mb of heap; sorry!

[Sigbjorn Finne]

 "Pasch, Thomas (ACTGRO)" <[EMAIL PROTECTED]> writes:
> $ ghc -package javavm -c Class_java_awt_Component.hs -o
> Class_java_awt_Component.o
> d:\Programme\ghc\ghc-5.02.2\bin\ghc.exe: fatal error: Windows programs can
> only use 256Mb of heap; sorry!
>
> Hello,
>
> is there anything I can change in order to avoid this message?
>

The 5.03 snapshot drops this hard-wired restriction, letting you use
a larger heap via the -M option.

hth
--sigbjorn


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

Re: Compiler 5.02 asked me to report a bug.

[Sigbjorn Finne]

Hi,

thanks for a fine bug report. The panic you're running
into is something that could be handled more gracefully
by the compiler.

Workaround is simple, just add -fvia-C to your GHC
command-line.

--sigbjorn

btw, I'd encourage you to make your Postgres Haskell
binding available to other Haskell programmers. Looks
like there's plenty of good stuff in there.

- Original Message -
From: "Brett Giles" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 09, 2002 12:31
Subject: Compiler 5.02 asked me to report a bug.


> Hi, While using green-card to create an interface for postgres database
> access, I recieved the following when I executed
>
> ghc -c PG.hs -o PG.o -fglasgow-exts -i/usr/local/gc-2.03/lib/ghc
> -package text -package data -package util
>
>
> ghc-5.02: panic! (the `impossible' happened, GHC version 5.02):
> Native code generator can't handle foreign call
> {-_ccall-}__casm ``do {PGresult * t;int result;
>  t = (PGresult *)%0;
>  do {   result = PQnfields( t );
>
>  %r = (int)(result);} while(0);} while(0);''
>
> Please report it as a compiler bug to [EMAIL PROTECTED],
> or http://sourceforge.net/projects/ghc/.
>
>
> I am using a newly compiled version of green-card (2.03) on Debian
> testing. This is interfacing to postgres version 7.1.3, standard Debian
> install.
>
> The ghc is the standard Debian testing install asl well.
>
> I have attached the PG.gc ,hs and .hi files, as well as an optional
> include file used for hugs...
>
> Please note, this interface has been working for hugs (albeit with
problems)
>
> Please let me know if there is anything I can do to assist in further
> debugging.
>
>
> Brett Giles
> Grad Student in formal methods, University of Calgary,
> http://www.cpsc.ucalgary.ca/~gilesb
>
>
..

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

win32 test installer

[Sigbjorn Finne]

A test Windows Installer for the 5.03 snapshot release is now
available via

   http://galois.com/~sof/ghc-5.03-20020208.msi (25.2M)

Unless I hear of any fatal flaws encountered using it or I
discover glitches while sleeping, it will go up on
haskell.org/ghc/ tomorrow morning (PST).

--sigbjorn


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

Re: Cygwin path support for ghc under Windows?

[Sigbjorn Finne]

You have to give more details than this; GHC does support
both '/' and '\' as path separator (but, of course, doesn't understand
nonsense like /cygdrive prefixes).

That GHC doesn't depend on cygwin is a feature, not a bug
(but if you want it to, you can compile it up for that 'platform'
instead).

--sigbjorn

- Original Message - 
From: "Antony Courtney" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 29, 2002 07:02
Subject: Cygwin path support for ghc under Windows?


> Hi,
> 
> This is more of a question than a bug report, so my appologies for using 
> what is probably the wrong email list.
> 
> Henrik Nilsson and I have just invested considerable effort in trying to 
> write portable, complete Makefiles for compiling and installing some of 
> our Haskell libraries with ghc under both Linux and Windows.  We have 
> invested a lot of work into factoring out platform- and site-specific 
> definitions from the common build rules and target lists.  Of course, 
> Cygwin and its port of GNU make is the only thing that makes this idea 
> even vaguely plausible.
> 
> When I look at the Win32-specific portion of the Makefile, it appears 
> that the *only* reason that I can't write one simple, portable GNU make 
> Makefile that would work on Linux and Windows is because ghc only 
> understands the Windows-style path name convention (with '\' as the path 
> seperator, and ':' for drive letters).  All of the other Cygwin tools 
> understand both the Windows-style and Cygwin/POSIX-style path names.
> 
> What are your thoughts on this matter?  Have you considered adding 
> POSIX-style path name support to ghc on Windows, either by hand or by 
> linking with cygwin?  After all, any Windows developer worth supporting 
> will have Cygwin installed anyway.  :-)
> 
> If there is interest but lack of resources, I would be happy to have a 
> go at implementing a minimalist form of such support.
> 
> -antony
> 
> -- 
> Antony Courtney
> Grad. Student, Dept. of Computer Science, Yale University
> [EMAIL PROTECTED]  http://www.apocalypse.org/pub/u/antony
> 
> 
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


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

Re: Simple sockets sample?

[Sigbjorn Finne]

I don't believe there's a bug in here, only perhaps in
the way the Socket functions are used:

main = withSocketsDo $ do
d <- connectTo host port  -- (1)
sendTo host port "GET / HTTP/1.0\r\n\r\n"; -- (2)
response <- recvFrom host port; -- (3)
putStrLn response
 where
host = "localhost"
port = Service "http"

(1) is creating a TCP connection, only never to use the
handle returned. (2) does effectively the same, but
closes the TCP connection after having transmitted
the HTTP request -- the web server presumably sees
this, but also sees that the client closes the socket.
(3) waits for an incoming connection from the web
server, which won't happen, as that's not how HTTP
works.

Someone suggested the following variation:

main :: IO ()
main = do
  h <- connectTo "www.yahoo.com" (PortNumber 80)
  hPutStrLn h "GET / HTTP/1.0\r\n\r\n"
  response <- hGetContents h
  putStrLn response

Almost, I'd make two changes to have it work on all
platforms:

main :: IO ()
main = withSocketsDo $ do
  h <- connectTo "www.yahoo.com" (PortNumber 80)
  hPutStrLn h "GET / HTTP/1.0\r\n\r\n"
  hFlush h
  response <- hGetContents h
  putStrLn response


withSocketsDo is reqd to start up WinSock & must always
be used if you want your socket code to work under Win32
(removing the need for explicit user-level initialisation is on
my ToDo list, however). Having to explicitly flush out the
request doesn't look quite right though, I'll have a closer
look.

hth
--sigbjorn

- Original Message -
From: "Simon Marlow" <[EMAIL PROTECTED]>
To: "Dominic Cooney" <[EMAIL PROTECTED]>; "Jens Petersen"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, January 28, 2002 04:36
Subject: RE: Simple sockets sample?


> > I realize that my use of the API was incredibly naïve and
> > that I should
> > have been using h* methods with the handle returned from
> > connectTo. But
> > it is connectTo that is failing as described.
> >
> > It fails interactively too with ghci, and regardless of using Server
> > "http" or PortNumber 80.
> >
> > The revised code below unfortunately gives the following error:
> >
> > Main> main
> > *** Exception: does not exist
> > Action: getProtocolByName
> > Reason: no such protocol entry
>
> There were some problems with Sockets on Windows platforms in versions
5.02 and 5.02.1 of GHC.  Version 5.02.2 should be better behaved, although I
admit I haven't tested this personally.
>
> Cheers,
> Simon
>
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


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

Re: ghci panic (unknown symbol stg_gc_l1)

[Sigbjorn Finne]

Hi,

GHCi doesn't load the RTS package (nor GMP),
as they're both baked into the binary. My guess is that
you've built ghci using 5.02.1; you need to use 5.02.2
(i.e., do two stage build.)  The missing symbol was
introduced in 5.02.2's RTS.

hth
--sigbjorn

- Original Message -
From: "Pixel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 26, 2002 08:07
Subject: ghci panic (unknown symbol stg_gc_l1)


> % ghci
> [...]
> Loading package std ... linking ... /usr/lib/ghc-5.02.2/HSstd.o: unknown
symbol `stg_gc_l1'
> ghc-5.02.2: panic! (the `impossible' happened, GHC version 5.02.2):
> can't load package `std'
> [...]
>
>
> (it seems) it should load package "rts" before "std", but (it seems) it
doesn't:
>
>
> % for i in /usr/lib/ghc-5.02.2/*.o; do nm $i | grep -q "T stg_gc_l1" &&
echo $i; done
> /usr/lib/ghc-5.02.2/HSrts.o
>
> % ghci -v5
> [...]
> Using package config file: /usr/lib/ghc-5.02.2/package.conf
> [...]
> Package
>{name = "std",
> import_dirs = ["/usr/lib/ghc-5.02.2/imports/std"],
> source_dirs = [],
> library_dirs = ["/usr/lib/ghc-5.02.2"],
> hs_libraries = ["HSstd"],
> extra_libraries = ["HSstd_cbits"],
> include_dirs = [],
> c_includes = ["HsStd.h"],
> package_deps = ["rts"],
> extra_ghc_opts = [],
> extra_cc_opts = [],
> [...]
> Loading package std ... linking ... /usr/lib/ghc-5.02.2/HSstd.o: unknown
symbol `stg_gc_l1'
>
>
> "strace -efile ghci" doesn't show anything weird, except maybe:
> stat64("./Prelude.hs", 0xbfffcfe0)  = -1 ENOENT (No such file or
directory)
> stat64("./Prelude.lhs", 0xbfffcfe0) = -1 ENOENT (No such file or
directory)
> stat64("./Prelude.hi-boot-5", 0xbfffcfe0) = -1 ENOENT (No such file or
directory)
> stat64("./Prelude.hi-boot", 0xbfffcfe0) = -1 ENOENT (No such file or
directory)
>
>
> I wanted to have a look at the code to find out what's wrong, but i can't
find
> the time :-(
>
> ghci is built using http://people.mandrakesoft.com/~prigaux/ghc.spec where
> %configure is ./configure
i586-mandrake-linux-gnu --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin -
-sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/
include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var/lib --s
haredstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info
>
> Any idea what's wrong?
>
>
> Thanks
>
> --
> Pixel
> programming languages addict  http://merd.net/pixel/language-study/
>
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


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

Re: ghci panic

[Sigbjorn Finne]

"Antony Courtney" <[EMAIL PROTECTED]> writes:
>
 ...
> Skipping  HavenTest( HavenTest.hs, ./HavenTest.o )
> PEi386 object has suspiciously large string table; > 64k relocs?
> ghc.exe: panic! (the `impossible' happened, GHC version 5.02.1):
>  loadObj: failed
> 
Hi,

this is a known issue with GHCi's linker, for which there's no good
workaround for you other than to try to split up that module.

If the module isn't particularly larger than any of the others, please
let us know.

--sigbjorn



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

Re: Compilation bug

[Sigbjorn Finne]

--with-hc only configures what's used to compile 'generic' Haskell
code (i.e., not the contens of ghc/compiler). (As Simon suggests),
use --with-ghc to control what GHC to to use to compile the
compiler bits, i.e.,

  ./configure --with-ghc=/usr/local/bin/ghc-5.02.2 \
   --with-hc=/usr/local/bin/ghc-5.02.2

will use 5.02.2 all over the place.

hth
--sigbjorn

- Original Message -
From: "Leon Smith" <[EMAIL PROTECTED]>
To: "Simon Marlow" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, January 23, 2002 11:24
Subject: Re: Compilation bug


> Ok,  I configured ghc-5.02.2 using the option
> --with-hc=/usr/local/bin/ghc-5.02.2.Then, when I compiled it, sometime
it
> would use /usr/local/bin/ghc-5.02.2, and sometimes it would use
/usr/bin/ghc,
> which is ghc-4.08.1 that was supplied with my Debian system.
>
> Then, I changed my path to have /usr/local/bin in front of /usr/bin,
removed
> the build tree, and recreated the links. Again, I used the --with-hc
option,
> but even then, it's still occasionally using /usr/local/bin/ghc.  This
> happens to be a symbolic link to ghc-5.02.2, but it still shouldn't be
doing
> this.
>
> best,
> leon
>
>
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


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

Re: Compilation of GHC under Windows

[Sigbjorn Finne]

Hi,

the current contents of the CVS repository will require a little
bit of work before it is possible to do a cygwin build using
a mingw-based version of GHC (which ghc-5.02.2 is).

If you're content to do a mingw build instead, try running the
configure script with the extra option
--host=i386-unknown-mingw32 (or --build=i386-unknown-mingw32,
depending on what version of autoconf you're using). Re-make
after that.

hth
--sigbjorn
- Original Message -
From: Krasimir Angelov
To: [EMAIL PROTECTED]
Sent: Sunday, January 13, 2002 12:01
Subject: Compilation of GHC under Windows


Hi How can I compile GHC from sources under Windows? I tried to compile
ghc-5.02.1 and ghc-5.02.2 under cygwin but the compilation failed. First the
configure program locates the installed Cygwin's ReadLine package and then
then Makefile searches for the ReadLine library from the Haskell's Utils
package. When I remove ReadLine from Cygwin, compilation continues. Second
trouble is related to hsc2hs. After Hsc2Hs generates C program (for example
tst.c) it tries to run it with ./tst. Under Windows this failed because
backslash is treated as option delimiter. After that Hsc2Hs tries to remove
"tst" file instead of "tst.exe". At the end compilation of linker.c also
fails Krasimir




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

ghc-5.03 release candidate installer available (win32)

[Sigbjorn Finne]

In preparation for a ghc-5.03 snapshot release, a
test installer for Win32 platforms is now available:
  
http://www.galois.com/~sof/ghc-503.msi  (*)

Size: 25.1 Mb.

Please let me know if you run into any problems with it.

thanks,
--sigbjorn

btw, Mike Thomas deserves a special mention for very
helpful (and quick) feedback on the ghc-5.02.2 RC installer.
Feedback that has been used to improve both the 5.02.2
and 5.03 installer setups.

* - This installer relies on the Windows Installer runtime to
operate. If, after having downloaded the above file,
double-clicking on the MSI file doesn't start up the installer,
the likely cause is that you don't have the runtime installed
on your machine. Redistributables of the runtime can be
downloaded from Microsoft:

 *  http://www.microsoft.com/downloads/release.asp?releaseid=32831
 (Windows 95,98 and ME version)
 * http://www.microsoft.com/downloads/release.asp?releaseid=32832
(Windows NT and 2000 version).

Try installing the appropriate version before double-clicking
again on the GHC installer.




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

ghc-5.02.2 release candidate installer available (win32)

[Sigbjorn Finne]

In preparation for the upcoming release of 5.02.2, I've
made available a test installer for Win32 platforms, in the
hope that any packaging glitches can be caught before it's
too late. The installer is available via
  
http://www.galois.com/~sof/ghc-502-2.msi  (*)

It's big: 21.7 Mb.

Please let me know if you run into any problems with it
(or not).

thanks,
--sigbjorn

* - This installer relies on the Windows Installer runtime to
operate. If, after having downloaded the above file,
double-clicking on the MSI file doesn't start up the installer,
the likely cause is that you don't have the runtime installed
on your machine. Redistributables of the runtime can be
downloaded from Microsoft:

 *  http://www.microsoft.com/downloads/release.asp?releaseid=32831
 (Windows 95,98 and ME version)
 * http://www.microsoft.com/downloads/release.asp?releaseid=32832
(Windows NT and 2000 version).

Try installing the appropriate version before double-clicking
again on the GHC installer.



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

Re: UDP reception bug in ghc-5.02.1 ?

[Sigbjorn Finne]

Hi,

yep, it's a bug in SocketPrim.recvFrom - it's busted in 5.02.1, I'm afraid.
It fails to init the 'fromlen' arg before calling recvfrom() + it doesn't
work with connection-oriented sockets (not that the latter is affecting
you here), which is why it fails to unravel the SockAddr once
recvfrom() returns.  Fixed in the current dev sources.

--sigbjorn

btw, you probably want to add a type signature for 'receiverPort', i.e.,

  receiverPort :: PortNumber

That way you avoid having to define your own intToPortNumber.

- Original Message - 
From: "Rafael Lorandi de Oliveira" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, December 07, 2001 05:08
Subject: UDP reception bug in ghc-5.02.1 ?


> Good morning,
> 
> I am implementing a communication system in Haskell via UDP, and (I 
> think) I've foud a bug in SocketPrim. Would you mind taking a look :-) ?
> 
> Consider the codes "udpSend.hs" and "udpRecv.hs":
> 
> 
> 
> 
> -- udpSend.hs
> -- send "Hello World" to port UDP:1500 of a remote host
> --
> -- compiled and tested with ghc-5.02.1
> -- compile with: ghc -fglasgow-exts --make -package net -o udpSend 
> udpSend.hs
> -- run with: ./udpSend 
> 
> module Main where
> 
> import Word
> import IO
> import System
> import SocketPrim
> import BSD
> 
> receiverPort = 1500
> 
> main :: IO ()
> main = do
> 
>   protoNum <- BSD.getProtocolNumber "udp"
>   sock <- SocketPrim.socket AF_INET Datagram protoNum
> 
>   let sin_port = SocketPrim.aNY_PORT
>   sin_addr = SocketPrim.iNADDR_ANY
>   sockAddr = SocketPrim.SockAddrInet sin_port sin_addr in
> SocketPrim.bindSocket sock sockAddr
> 
>   args <- System.getArgs
>   hEntry <- BSD.getHostByName (head args)
> 
>   -- SocketPrim doesn't export 'intToPortNumber'. Is there a better way 
> to do this?
>   let sin_port = Main.intToPortNumber receiverPort
>   sin_addr = BSD.hostAddress hEntry
>   sendAddr = SocketPrim.SockAddrInet sin_port sin_addr in
> SocketPrim.sendTo sock "Hello World" sendAddr
> 
>   return ()
> 
> 
> intToPortNumber :: Int -> PortNumber
> intToPortNumber v = PortNum (htons (fromIntegral v))
> 
> foreign import "htons" unsafe htons :: Word16 -> Word16
> 
> 
> 
> 
> -- udpRecv.hs
> -- listen port UDP:1500 and print received data
> --
> -- compiled and tested with ghc-5.02.1
> -- compile with: ghc -fglasgow-exts --make -package net -o udpRecv 
> udpRecv.hs
> -- run with: ./udpRecv
> 
> module Main where
> 
> import Word
> import IO
> import System
> import SocketPrim
> import BSD
> 
> receiverPort = 1500
> maxMsg = 100
> 
> main :: IO ()
> main = do
> 
>   protoNum <- BSD.getProtocolNumber "udp"
>   sock <- SocketPrim.socket AF_INET Datagram protoNum
> 
>   -- SocketPrim doesn't export 'intToPortNumber'. Is there a better way 
> to do this?
>   let sin_port = Main.intToPortNumber receiverPort
>   sin_addr = SocketPrim.iNADDR_ANY
>   sockAddr = SocketPrim.SockAddrInet sin_port sin_addr in
> SocketPrim.bindSocket sock sockAddr
> 
>   (recvHello, _, (SockAddrInet sin_port sin_addr)) <- 
> SocketPrim.recvFrom sock maxMsg
> 
>   addr <- SocketPrim.inet_ntoa sin_addr
>   IO.putStrLn ("udpRecv: from " ++ addr ++ ":UDP" ++ (show sin_port) ++ 
> " : " ++ recvHello)
> 
>   return ()
> 
> 
> intToPortNumber :: Int -> PortNumber
> intToPortNumber v = PortNum (htons (fromIntegral v))
> 
> foreign import "htons" unsafe htons :: Word16 -> Word16
> 
> 
> 
> 
> This is what happens in my machine (Debian GNU/Linux 2.2r3 with kernel 
> 2.2.19):
> 
> (terminal #1)
> ...$ ./udpRecv
> (blocking at 'recvFrom')
> 
> (terminal #2)
> ...$ ./udpSend 10.0.10.195
> ...$
> 
> (terminal #1)
> 
> Fail: SocketPrim.hsc:241: Non-exhaustive patterns in case
> 
> ...$
> 
> 
> This happens because "family" enters the case statement with the value 0 
> (zero) in SocketPrim.peekSockAddr.
> 
> If I build C versions of udpSend and udpReceive, I have:
>   - udpSend.c  with  udpSend.c --> OK
>   - udpSend.c  with  udpRecv.hs --> Fail
>   - udpSend.hs  with  udpRecv.c --> OK
> 
> Therefore I think the problem is into the reception application (right?).
> 
> 
> Thanks in advance.
> 
> Best regards,
> Rafael Lorandi de Oliveira
> Development Engineer - R&D
> AsGa S/A
> www.asga.com.br
> 



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

Re: --+ not treated as a start of a comment

[Sigbjorn Finne]

Thanks, I've made Hugs98 comply with the Report.

--sigbjorn

- Original Message - 
From: "Ian Lynagh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, December 09, 2001 10:43
Subject: --+ not treated as a start of a comment


> 
> If I have
> 
> foo = 0 --+ 1
> 
> then ghc tells me
> 
> tt.lhs:2: Variable not in scope: `--+'
> 
> while the report (and hugs) believe "--+ 1" is a comment.
> 
> 
> Thanks
> Ian
> 
> 
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


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

Re: GHC bug

[Sigbjorn Finne]

Hi,

the bug fixer may have contacted you separately, but for
the benefit of the mailing list and/or you, this one has now
been fixed (i.e., deriving empty datatypes is not permitted).
Thanks for reporting it.

--sigbjorn

- Original Message - 
From: "Hal Daume III" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 30, 2001 09:24
Subject: GHC bug


> Prelude> :reload 
> Compiling XBar ( /nfs/isd/hdaume/projects/XBar/XBar.hs,
> interpreted )
> ghc-5.02.1: panic! (the `impossible' happened, GHC version 5.02.1):
> TcGenDeriv:mk_FunMonoBind
> 
> Please report it as a compiler bug to [EMAIL PROTECTED],
> or http://sourceforge.net/projects/ghc/.
> 
> This happened immediately after I change line 35 in the attached program
> from:
> 
>   data DummyHead
> 
> to
> 
>   data DummyHead deriving (Show, Eq)
> 
> I wasn't sure whether it would allow me to derive instances on a datatype
> with no constructors...I know this was recently added and I guess all the
> bugs haven't been worked out.  I'm using the solaris build of ghc.
> 
> --
> Hal Daume III
> 
>  "Computer science is no more about computers| [EMAIL PROTECTED]
>   than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
> 


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

Re: Building dlls with ghc

[Sigbjorn Finne]

Hi,

thanks for the report. First off, I should say that the 5.02 release
didn't focus on DLL production at all, so I'm not too surprised you're
coming across a gremlin or two.

However, I'm not able to reproduce the break you're experiencing,
my --mk-dll tests break much earlier than that. If you could provide
more info on the exact steps you followed, I'd appreciate it. The
nature of the bug I'm coming across is bad enough to render
--mk-dll unusable with 5.02.1, I'm afraid. The next release (and the
CVS repo sources) will include a fix.

Thanks for pointing out the omission of 'dllwrap'; it should of course
be included.

hth
--sigbjorn

- Original Message - 
From: "Ronald Legere" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 30, 2001 20:42
Subject: Building dlls with ghc 


> Dear haskellers,
>I have been trying to build a dll that has haskell
> functions in it, but it doesnt seem to be working in
> the latest 5.02.1 windows installer version. 
>  First, 
>   ghc --mk-dll ..
>   Doesnt do anything since it cannot find dllwrap,
> which
> doesnt come with the windows installer.
> 
>   Then, since I have cygwin (ver 1.3.5) i can put
> cygwin/bin on my path and try that, but not
> suprisingly that fails :) dllwrap runs fine, but then
> the linker complains about multiple definitions of 
> __main, in particular from libm.a(d27.0) and 
> libmingw32.a(gccmain.o).  Note that I do routinely
> link up haskell executables in both dos shells and
> cygwin shells with no troubles though. 
>I suppose that dll building just doesnt work at the
> moment, or do I just have a particulalry goofy 
> situation... or should I just try to build my own
> ghc in the cygwin environment so I am not mixing 
> things?? 
> 
> 
> __
> Do You Yahoo!?
> Buy the perfect holiday gifts at Yahoo! Shopping.
> http://shopping.yahoo.com
> 
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


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

Re: greencard bug

[Sigbjorn Finne]

Hi,

you don't say how you processed that example .gc file with GreenCard,
but I'm guessing you used the '--target ghc' option. If that's the case,
have
a look at

  http://www.haskell.org/greencard/type-sig.html#SEC-BODY

which discusses safe vs. unsafe calls -- i.e., in your case you need to
change
the %code below to %safecode. (Alternatively, use the -S option).

hth
--sigbjorn

- Original Message -
From: "Chen Yu" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2001 03:42
Subject: greencard bug


> Hi, there
>I am using Greencard with Hask's foreign function export. I found
> the following program can cause seg-fault. Anyone has any idea? BTW,
> if I replace greencard with Hask's foreign function import, there
> is no such error.
>
> in ABC.gc:
>
> foreign export ccall "h_add" h_add :: Int -> IO Int
> h_add a = do
> putStrLn "in haskell callback"
> return (a + 1)
>
> %fun add ::  Int -> IO(Int)
> %call (int a)
> %code int r;
> % r = c_add (a);
> %result (int r)
>
> and the result is like:
>
> in c callback
> in haskell callback
> Segmentation Fault
>
>
>
>
> in add.c:
>
> _RESULT c_add(int a) {
> printf("in c callback\n");
> return h_add(a);
> }
>
>
> TIA!
>
> --
> chenyu
> in Main.hs:
>
> main = do
> a <- add 127
> putStrLn (show a)
>



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

Re: HDirect (CVS version) - some bugs

[Sigbjorn Finne]

Thanks for the bug report. I've checked in a fix for 1), but
for 2), I suggest instead of doing

  void pj_set_finder( const char *(*)(const char *) );

you express this as

  typedef [string]char* (*StringTrans) ([in,string]char* arg1);
  void pj_set_finder([in]StringTrans arg);

as HDirect doesn't currently handle 'const' qualifiers as well as it
could.

--sigbjorn

- Original Message -
From: "Mike Thomas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Sigbjorn Finne" <[EMAIL PROTECTED]>
Sent: Wednesday, November 07, 2001 15:42
Subject: HDirect (CVS version) - some bugs


> Hi there.
>
> Attached is a small zip file containing some idl and header files which
are
> meant to define an interface to Frank Warmerdam's map projection library.
>
> The problems can be reproduced by unzipping, going to the top level
> directory and running "make".  I am using Windows NT GHC 5.02 and CVS
> version of HDirect.
>
> 1. The C stub code ("Proj.c") generated for structures defined in the idl
> with lower-case leading characters has upper case leading characters eg:
> projXY in the IDL is converted to ProjXY.  I have worked around this by
> including a header file ("nameconvert.h") with macros which change the
names
> back to those used in the library headers, but this is messy.
>
> 2. The Haskell code ("Proj.hs") contains some strange definitions to do
with
> a datatype "IHC_TAG_0", which causes the errors below when compiled.   The
> datatype is associated with a function which takes another function as an
> argument:
>
> void pj_set_finder( const char *(*)(const char *) );
>
> Cheers
>
> Mike Thomas
>
> --- IHC_TAG_0 error messages 
>
> ghc -c -package lang -package com -fglasgow-exts -fvia-C Proj.hs -o
> proj_hs.o
>
> Proj.hs:338:
> Couldn't match
> `PrelMaybe.Maybe (PrelBase.Char -> PrelIOBase.IO PrelBase.Char)'
> against
> `IHC_TAG_0'
> Expected type: PrelMaybe.Maybe
>(PrelBase.Char -> PrelIOBase.IO PrelBase.Char)
> Inferred type: IHC_TAG_0
> In the third argument of `HDirect.marshallref', namely `arg10'
> In a 'do' expression pattern binding:
> arg10 <- HDirect.marshallref (HDirect.allocBytes (PrelReal.toInt
> sizeofI
> HC_TAG_0))
>  (HDirect.writeunique
> (HDirect.allocBytes (P
> relReal.toInt sizeofIHC_TAG_0))
>   writeIHC_TAG_0)
>  arg10
> make: *** [proj_hs.o] Error 1
>


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

Re: AbsCStixGen.gencode panic

[Sigbjorn Finne]

The native code generator only handles 'foreign import's with a
static target, which is why you're seeing this (HEAD handles
this situation a little bit more gracefully).

Use -fvia-C (or -O, which implicitly does the same thing).

--sigbjorn

- Original Message -
From: "Volker Stolz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 16, 2001 10:18
Subject: AbsCStixGen.gencode panic


> Beware, to reproduce you need c2hs & gtk+hs!
> Luckily, I can use the "-O" switch (does that option mean "turn errors
OFF"?)
> to get a perfectly working binary!
>
> ghc -c Get.lhs -o Get.o `c2hs-config --cflags`  -fglasgow-exts -package
lang
>
> ghc-5.02.1: panic! (the `impossible' happened, GHC version 5.02.1):
> AbsCStixGen.gencode
> typedef void ( *_ccall_fun_tys1Cc) (StgAddr, I_);
>
> \begin{code}
>
> module Main where
>
> import IO
> import Maybe
> import Monad
> import Foreign
> import CString
> import GModule
>
> type Fun = CString -> Int -> IO ()
> foreign import dynamic unsafe iterator__ :: FunPtr Fun -> Fun
>
> main :: IO ()
> main = do
>   withModule (Just ".") "simple" ModuleBindOnLoad $ \ mod -> do
> funptr <- moduleSymbol mod "simple"
> when (isNothing funptr) $ error "fo!"
> let res = iterator__ (castPtrToFunPtr (fromJust funptr))
> withCString "hello" $ \ str -> res str 1
>   return ()
>
> \end{code}
> --
> Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
>
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


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

Re: Happy generates uncompilable files

[Sigbjorn Finne]

Hi,

couple of things:

* you don't have to side-effect mk/config.mk{.in} to make
   any changes to the definitions in there. Just create your own
   mk/build.mk and add definitions of variables you need for
   your build tree to work/behave as expected. The build.mk
   defns override those in mk/config.mk

   (see 5.3 of the GHC Building Guide for more).

* the break you're seeing is due to the GHC native code generator
   not being able to handle Int16-sized values internally. My suggested
   fix for the problem you're running into would be not to change
   the options given to Happy, but to GHC - i.e., have it generate code
   via C  (==> add -fvia-C to rename/ParseIface_HC_OPTS and
   parser/Parser_HC_OPTS in ghc/compiler/Makefile).

   I've committed the latter fix.

hth
--sigbjorn

- Original Message -
From: "Josef Svenningsson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 08, 2001 08:15
Subject: Happy generates uncompilable files


> Hi!
>
> Here's a small patch to fptool/mk/config.mk.in which I need for the
> compiler to compile smoothely on my sparc:
>
> *** config.mk.inThu Nov  8 17:12:46 2001
> --- ../../fptools/mk/config.mk.in   Wed Nov  7 16:23:03 2001
> ***
> *** 833,843 
>   #
>   # Options to pass to Happy when we're going to compile the output with
> GHC
>   #
> - ifeq "$(i386_TARGET_ARCH)" "1"
>   GHC_HAPPY_OPTS= $(shell if ( test `echo $(HAPPY_VERSION)
> | sed -e "s/\(.*\)\..*/\1/g"` "-gt" "1" || test `echo $(HAPPY_VERSION) |
> sed -e "s/.*\.\(.*\)/\1/g"` "-ge" "9" ); then echo -agc; else echo -g; fi)
> - else
> - GHC_HAPPY_OPTS= -gc
> - endif
>
>   #
>   # Stuff from fptools/literate
> --- 833,839 
>
>
> Why? Because with the -a flag happy generates files which uses the
> Int16Rep function. This is only implemented for x86. :-(
>
> Could you please add this patch? It would make my life a lot easier.
>
> Cheers,
>
> /Josef
>
>
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


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

Re: Building GHC 5.02 on Solaris x86

[Sigbjorn Finne]

Simon Marlow <[EMAIL PROTECTED]> writes:
>
> Having just looked at the code, it seems we could recover the
> platform-independentness in the I/O library with just a small amount of
> wrapperage: most of the offending code is in PrelPosix.hsc, with a few
> #const's scattered around PrelHandle and PrelIO, and none of the
> affected areas are particularly performance-critical.
>
> Also needing wrappers are Time, CPUTime, Directory & System.  I'd say
> stop there, though - this is purely to make bootstrapping on a new OS
> easier, so we only need to apply the no-tool restriction to libraries
> needed by the compiler.
>

Good, let's sort this one out. ghc/compiler/ has its fingers deep in the pie
that is hslibs/, so presumably the restriction applies there also?

I'll happily convert some of these files (once I know what wrapper story
you have in mind); let me know.

--sigbjorn



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

Re: Building GHC 5.02 on Solaris x86

[Sigbjorn Finne]

"Alastair David Reid" <[EMAIL PROTECTED]> writes:
> 
> > So, bringing back the solution of having manually written C wrapper
> > functions which platform-independent Haskell source files will call
> > out to, would be preferable (in short, avoid the use of hsc2hs *or
> > any other extra tool* alltogether). I'm willing to make the
> > necessary changes.
> 
> You started by objecting to using a tool that commits your code to a
> platform too early.  I'm in complete agreement.
> 
> But now you seem to be objecting to using any tools at all.  This seems
> excessive.  Why not do one of:
> 

[..suggestions on what kind of tool to provide..]

> 
> (This is all on the assumption that the amount of code we're talking
> about is significant enough to care.  I have the impression that it is
> but could be wrong.)
> 

Yep, I'm of the humble(?) opinion that it is not. Minimising your tool
dependencies is always something to keep in mind too.

But let not that be the main point - the main point was that this problem
needs to be addressed, tool or no tool. I offered a no-tool solution which
has worked well in the past.

--sigbjorn



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