headers
Krasimir Angelov | 13 Jul 2002 11:06
Picon
Favicon

RE: ObjectIO


--- Simon Marlow <simonmar <at> microsoft.com> wrote:
> > I then upgraded my version to
> > 5.02.3 and now ObjectIO doesn't work anywhere
> anymore. The linker
> > complains in literally thousands of errors like
> the ones shown below.
> > This is a shame because we did like the ObjectIO
> library. Ah, my
> > colleague has just installed 5.02.1 and now it
> works on his system.
> 
> Yes, if you upgrade your version of GHC you need to
> recompile *any* code
> that was compiled by a previous version of GHC.  The
> compiler should be
> better about giving warnings in this case (I believe
> 5.04 will complain
> about patchlevel differences in interface files
> now).
> 
> Chees,
> 	Simon

You can upgrade to GHC-5.04. The latest Windows
release contains ObjectIO

Krasimir

__________________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sigbjorn Finne | 13 Jul 2002 16:02
Favicon

Fw: crash with GHC 5.04

Hi,

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

--sigbjorn

----- Original Message -----
From: "Mark Tehver" <mark <at> eeter.fi.tartu.ee>
To: "Sigbjorn Finne" <sof <at> galois.com>
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
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anders Lau Olsen | 14 Jul 2002 02:32
Picon

Underscores in qualified names in HsParser


HsParser is confused by the combination of qualified names and
identifiers starting with underscores. For example:

    module M where

    _f _ _ = 0

    x = 0 `M._f` 0 -- parse error at '.'

    y = M._f 0 0 -- parses as M . (_f 0 0)

I have tested this only for GHC 5.02. For what it's worth, I am pretty
sure the later versions behave the same, and that the fix is to
replace line 336 in Lexer.hs

    | isLower c -> do		-- qualified varid?

with

    | isLower c || c == '_' -> do	-- qualified varid?

Anders
Permalink | Reply | 0 comments |
headers
Volker Stolz | 15 Jul 2002 11:08

Re: sigCHLD signal handling (Was: Re: pipes? threadWaitRead?)

Am 10. Jul 2002 um 22:21 CEST schrieb Dean Herington:
> The first issue I confronted is that the get*ProcessStatus routines return
> an error rather than "nothing" if there is no candidate child process.

Yes, `waitpid' might return with EINTR which will cause an exception
(I just checked, it did). I'll try to devise a fix for PosixProcPrim.

Volker
Permalink | Reply | 2 comments |
headers
Ross Paterson | 15 Jul 2002 11:54
Picon
Favicon

Re: Underscores in qualified names in HsParser

Anders Lau Olsen <alauo <at> mip.sdu.dk> writes:
> HsParser is confused by the combination of qualified names and
> identifiers starting with underscores. For example:
> 
>     module M where
> 
>     _f _ _ = 0
> 
>     x = 0 `M._f` 0 -- parse error at '.'
> 
>     y = M._f 0 0 -- parses as M . (_f 0 0)
> 
> I have tested this only for GHC 5.02. For what it's worth, I am pretty
> sure the later versions behave the same, and that the fix is to
> replace line 336 in Lexer.hs
> 
>     | isLower c -> do           -- qualified varid?
> 
> with
> 
>     | isLower c || c == '_' -> do       -- qualified varid?

Thanks for the report and fix.  I've applied this change in CVS.
Permalink | Reply | 0 comments |
headers
Sigbjorn Finne | 15 Jul 2002 15:33
Favicon

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" <see <at> co.umist.ac.uk>
To: <sof <at> galois.com>
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-3352    email: see <at> co.umist.ac.uk
> Department of Computation, UMIST, Manchester M60 1QD
(Continue reading)

Permalink | Reply | 1 comment |
headers
Volker Stolz | 15 Jul 2002 16:10
Picon
Picon

Re: sigCHLD signal handling (Was: Re: pipes? threadWaitRead?)

In local.glasgow-haskell-bugs, you wrote:
> Am 10. Jul 2002 um 22:21 CEST schrieb Dean Herington:
>> The first issue I confronted is that the get*ProcessStatus routines return
>> an error rather than "nothing" if there is no candidate child process.
> 
> Yes, `waitpid' might return with EINTR which will cause an exception
> (I just checked, it did). I'll try to devise a fix for PosixProcPrim.

That's ECHILD, not EINTR.
The only nice way to figure this out might be keeping a global counter
(in an MVar), increasing it on forkProcess() and counting it down for
each "awaited" child. That way, you could safely loop on `waitpid' if
you know there should still be a child around (and you'll get `Nothing'
if it's not done yet).

Volker
--

-- 
http://news.bbc.co.uk: `Israeli forces [...], declaring curfews that
confine more than 700,000 people to their homes.'
Permalink | Reply | 1 comment |
headers
Simon Marlow | 15 Jul 2002 17:06
Picon
Favicon

RE: crash with GHC 5.04

It's a real bug.  A foreign-exported function is supposed to be
registered as a stable pointer by the initialisation function for a
module (ie. when you call startupHaskell()), but this isn't happening in
5.04.  The result is that eventually the garbage collector collects the
foreign-exported functions, when they should be retained.

One possible workaround is to arrange to register each foreign-exported
function as a stable pointer in your own code.  Or just go back to
5.02.3 for the time being.

We'll fix this bug in 5.04.1, which sadly might have to be sooner rather
than later.

Cheers,
	Simon

> -----Original Message-----
> From: Sigbjorn Finne [mailto:sof <at> galois.com] 
> Sent: 13 July 2002 15:02
> To: glasgow-haskell-bugs <at> haskell.org
> Cc: Mark Tehver
> Subject: Fw: crash with GHC 5.04
> 
> 
> Hi,
> 
> this appears to be GC-related; forwarded to the
> bugs list. Thanks for the report.
> 
> --sigbjorn
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Herington | 15 Jul 2002 18:33
Picon
Favicon

Re: sigCHLD signal handling (Was: Re: pipes? threadWaitRead?)

Volker Stolz wrote:

> In local.glasgow-haskell-bugs, you wrote:
> > Am 10. Jul 2002 um 22:21 CEST schrieb Dean Herington:
> >> The first issue I confronted is that the get*ProcessStatus routines return
> >> an error rather than "nothing" if there is no candidate child process.
> >
> > Yes, `waitpid' might return with EINTR which will cause an exception
> > (I just checked, it did). I'll try to devise a fix for PosixProcPrim.
>
> That's ECHILD, not EINTR.

Yes, that's what I would expect from reading the man page.

I was not complaining about the Unix semantics, just noting that there was a
subtlety I wasn't previously aware of that made my code more complex.

> The only nice way to figure this out might be keeping a global counter
> (in an MVar), increasing it on forkProcess() and counting it down for
> each "awaited" child. That way, you could safely loop on `waitpid' if
> you know there should still be a child around (and you'll get `Nothing'
> if it's not done yet).

Yes, that's exactly the solution I came up with.

> Volker

Thanks.

Dean
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sigbjorn Finne | 17 Jul 2002 00:48
Favicon

Re: ghc installer for Windows

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" <sof <at> galois.com>
To: <glasgow-haskell-bugs <at> haskell.org>
Cc: "Stephen Eldridge" <see <at> co.umist.ac.uk>
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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane