GHC 6.6 panic from Data.Binary.Builder? reproducible on linux and mac os/x

[S. Alexander Jacobson]

Thinking about it further, I like the convention that the target of runhaskell 
MUST be Main.main.  It simplifies a lot of assumptions about intent.  It means 
that if I put a module named Main in HAppS/HTTP/FileServer, searchpath doesn't 
have to do anything special to figure out what it should do.

    sp runhaskell --sp HAppS.HTTP.FileServer --http-port=7000

Will download everything required at start serving files out of the current 
directory on port 7000 no fuss and no muss.  I withdraw the complaint and the 
bug report.

Note: In the next version of searchpath I hope to get rid of the --sp and have 
it just know that if it doesn't see the module on the path, it should download 
it.

-Alex-

On Mon, 30 Apr 2007, Simon Marlow wrote:

> S. Alexander Jacobson wrote:
>> I've since modified sp to add a main-is which prevents the panic and 
>> replaces it with a complaint about Main e.g.
>>
>>   runghc -i.haskell_cache/http_searchpath.org-default.map.cache -main-is 
>> HAppS.Protocols.HTTP.FileServer.main 
>> .haskell_cache/http_searchpath.org-default.map.cache/HAppS/Protocols/HTTP/FileServer.hs 
>> --http-port=7000
>>
>>   <interactive>:1:211:
>>     Failed to load interface for `Main':
>>       Use -v to see a list of the files searched for.
>
> runghc expects to run Main.main, I'm afraid it doesn't pay any attention to 
> the -main-is flag (this flag is just passed along to GHC).  We do have a 
> :main command that runghc really ought to use, but unfortunately it's not 
> quite that simple.  I'll create a ticket, thanks for the bug report.
>
> Instead of runghc, as a workaround you could use ghc -e directly.
>
> Cheers,
> 	Simon
>