RE: readFile close behaviour

2001-10-08 Thread Simon Marlow

  If it was semiclosed, the physical handle could be closed 
 immediately.
 
 I think my statement was too weak.  It shouldn't matter whether the
 handle is open or semi-closed: if there are no references left to it
 it should be closed.

And how do you define what it means to have no references left?  This
depends on having some well-defined operational semantics for Haskell,
which we don't have.  The upshot is that while GHC might notice that you
have dropped a Handle, another implementation which doesn't do black
holing, stack stubbing, strictness analysis, GC evaluation of selector
thunks or any of the other tricks we do to avoid space leaks might not
notice.  Your program can still run out of file descriptors when
compiled with one compiler but not with another, regardless of the
finalization policy.

Furthermore, as Alastair points out, while GHC will schedule the
finalizer to run, there's no guarantee that it will run in a timely
fashion.  This is something we could hack our way around, I suppose, but
it's ugly.

IMHO if you want to do any kind of heavyweight I/O in Haskell, you
shouldn't use lazy file reading.

Cheers,
Simon

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



RE: compiler bug

2001-10-08 Thread Simon Marlow


 when i loaded my ass2 GameFrontEnd.hs into ghci, this came up
 
 
 Please report it as a compiler bug to 
 [EMAIL PROTECTED],
 or http://sourceforge.net/projects/ghc/
 
 ghc-5.00.2: panic! (the
 `impossible' happened, GHC version 5.00.2):
 loadObj: failed

Hi there, and thanks for the report.  Could you please try again with
GHC 5.02, and if the problem persists then send us more details: the
complete command line used to invoke GHCi, the output produced when the
-v flag is added, and the source/object files you were trying to lead at
the time.

Cheers,
Simon

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



Re: GHC 5.02 Win32

2001-10-08 Thread Sigbjorn Finne

Yes, non-interactive uses of the Win32 library appear to
be in a non-working state (at least with my copy of ghc-5.02,
don't know if there's been any stealth updates to the installer
binary.)

As a stop-gap measure, replace ghc-5.02's libHSwin32.a
(after having saved it away) with the one contained in

   http://www.galconn.com/~sof/HSwin32.zip

and try again. Hopefully this can be fixed in the installer proper..

(The cause of it all is that libHSwin32.a lacks a pair of _stub.c files
which contains the code that takes care of the window/dialogue
callbacks into Haskell).

hth
--sigbjorn

- Original Message -
From: Mike Thomas [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, October 07, 2001 19:58
Subject: GHC 5.02 Win32


 Hi there.

 Congratulations on 5.02 -  a lot of work in that one for you.

 The web site Win32 example program doesn't link due to an undefined
 reference to Win32Window_dfQU which is defined in HSwin321.o.
Although
 that file is listed in the package.conf entry for win32, it (and it's
 presumed companion HSwin322.o) does not appear in the verbose output from
 ghc's call to ld (an extract is below) when -package win32 is passed
to
 ghc.  The win32 libraries are there, however.

 Cheers

 Mike Thomas.

 .

  e:\ghc\ghc-5.02\gcc-lib\ld.exe -Bdynamic -o hello.exe -u
 _Addr_Azh_static_info -u _PrelBase_Izh_sta
 tic_info -u _PrelBase_Czh_static_info -u _PrelFloat_Fzh_static_info -u
 _PrelFloat_Dzh_static_info -u
  _PrelPtr_Ptr_static_info -u _PrelWord_Wzh_static_info -u
 _PrelInt_I8zh_static_info -u _PrelInt_I16z
 h_static_info -u _PrelInt_I32zh_static_info -u
_PrelInt_I64zh_static_info -u
 _PrelWord_W8zh_static_i
 nfo -u _PrelWord_W16zh_static_info -u _PrelWord_W32zh_static_info -u
 _PrelWord_W64zh_static_info -u
 _PrelStable_StablePtr_static_info -u _PrelBase_Izh_con_info -u
 _PrelBase_Czh_con_info -u _PrelFloat_
 Fzh_con_info -u _PrelFloat_Dzh_con_info -u _PrelPtr_Ptr_con_info -u
 _PrelStable_StablePtr_con_info -
 u _PrelBase_False_closure -u _PrelBase_True_closure -u
 _PrelPack_unpackCString_closure -u _PrelIOBas
 e_stackOverflow_closure -u _PrelIOBase_heapOverflow_closure -u
 _PrelIOBase_NonTermination_closure -u
  _PrelIOBase_BlockedOnDeadMVar_closure -u
 _PrelWeak_runFinalizzerBatch_closure -u ___stginit_Prelude
  -u _PrelMain_mainIO_closure -u ___stginit_PrelMain
 e:/ghc/ghc-5.02/gcc-lib/crt2.o -Le:/ghc/ghc-5.02
  -Le:/ghc/ghc-5.02/gcc-lib
 hello.o -lHSwin32 -luser32 -lgdi32 -lwinmm -lkernel32 -ladvapi32 -lHSlang
  -lHSlang_cbits -lHSstd -lHSstd_cbits -lwsock32 -lmsvcrt -lHSrts -lm -lwin
mm
  -lwsock32 -lgmp -lmingw

32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lming
 w32 -lgcc -lmoldname -lm
 svcrt

e:/ghc/ghc-5.02/libHSwin32.a(Win32Window__106.o)(.text+0x2ba)://c/tmp/ghc169
 2.hc: undefined referenc
 e to `Win32Window_dfQU'

 ..


 ___
 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