headers
Mitchell, Neil | 8 Sep 10:40

Windows build failure

Hi,

I've just tried building GHC HEAD using GHC 6.8.3 on Windows following
the instructions on the wiki
(http://hackage.haskell.org/trac/ghc/wiki/Building/Windows)

I initially got a failure about cc1 not being found when executing
6.8.3's gcc, which I worked around by adding c:/ghc/ghc-6.8.3/gcc-lib at
the end of the path (i.e. last priority)

After this error I get a problem with include files, see the attached
log file. It looks like include files are going wrong between Mingw and
6.8.3. My current $PATH variable is:

/cygdrive/c/mingw/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdr
ive/c/WI
NNT/Microsoft.NET/Framework/v2.0.50727:/cygdrive/c/local/MikTex/texmf/mi
ktex/bin
:/cygdrive/c/Perl/site/bin:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/WINNT
/system3
2:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/CSsystem
:/cygdri
ve/c/Utils:/cygdrive/c/Program
Files/Sybase.12/OCS-12_0/bin:/cygdrive/c/ghc/ghc-
6.8.3:/cygdrive/c/ghc/ghc-6.8.3/bin:/cygdrive/c/bin:/cygdrive/c/Program
Files/Ha
skell/bin:/cygdrive/f/ImslNT.30/CNL/Bin:/cygdrive/c/Utils/mks/mksnt:/cyg
drive/f/
Fame/76:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/ghc/ghc-6.8.3/gcc-lib
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mitchell, Neil | 5 Sep 16:11

(no subject)

Hi Claus,

I was reading your instructions on the GHC wiki page,
http://hackage.haskell.org/trac/ghc/wiki/Building/Windows, and they are
wonderful - exactly what I wanted. However, they don't work. When
downloading Cygwin you are told to add haskell.org/ghc/cygwin as a path
so it can pick up the setup.ini file. However, in the latest version of
Cygwin it obvious wants signatures for all the .ini files:

---------------------------
Cygwin Setup
---------------------------
Unable to get http://www.haskell.org/ghc/cygwin/setup.ini.sig from
<http://www.haskell.org/ghc/cygwin>
---------------------------
OK   
---------------------------

Could someone please add the appropriate signature file?

Thanks

Neil

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Gavin | 3 Sep 05:56

rebinding arrow notation

Section 8.3.5 of the documentation says:

   Arrow notation (see Section 8.9, “Arrow notation ”) uses whatever arr, (>>>),
   first, app, (|||) and loop functions are in scope. But unlike the other
   constructs, the types of these functions must match the Prelude types very
   closely. Details are in flux; if you want to use this, ask!

I want to do this.  Is there anything special I should know?

Pete
Permalink | Reply | 2 comments |
headers
Simon Marlow | 2 Sep 14:35

*BSD GHC hackers needed...

While perusing the tickets in the 6.10.1 milestone I spotted 3 that look to 
be FreeBSD-specific:

2476	internal error: awaitEvent: descriptor out of range	
2502	segfault with GHC.Handle.fdToHandle'
2511	unix package doesnt load in ghci on freebsd/amd64

It's unlikely that we'll get to these in time for 6.10.1.  Any FreeBSD 
hackers out there want to take a look?  Help/advice is available as usual.

There's also one NetBSD-specific ticket:

2351	NetBSD defines ELF_ST_TYPE

(that one is easy), and one that I think applies to all the *BSDs:

2063	Breackage on OpenBSD due to mmap remap

(actually the latter one is a top priority, because without it GHCi can't 
work, so we need it fixed for 6.10.1).

Cheers,
	Simon
Permalink | Reply | 0 comments |
headers
Wolfgang Jeltsch | 2 Sep 13:18

GADT pattern match in non-rigid context

Hello,

I have some code giving me the error message: “GADT pattern match in non-rigid 
context for … Tell GHC HQ if you'd like this to unify the context”.  I 
reduced my code to the following example which still gives this error 
message:

> data T a b where
> 
>     C :: T a [b]
> 
> f :: (forall a'. T a' b) -> T a b
> f t = case t of C -> C

How do I work around this error?  Some former e-mail discussion gave the hint 
of adding a type signature but this probably doesn’t work in my case.  Note 
also that specializing the type of the argument t to T a b inside the 
definition of f is not an option since in the real code I need the first 
argument of T to be universally quantified for calling another function which 
needs this quantification.

I use GHC 6.8.2.  Don’t know whether this problem still shows up with GHC HEAD 
but am interested in hearing whether this is the case.

I’m thankful for any help.

Best wishes,
Wolfgang
Permalink | Reply | 1 comment |
headers
Mitchell, Neil | 2 Sep 11:48

Windows snapshot binaries

Hi,

Looking at:

http://www.haskell.org/ghc/dist/current/dist/

The latest Windows binary appears to be the 22nd of June, and thus is
before things such as the Control.Exception changes, and will not work
with the current version of Haddock. Is it possible to get an updated
binary?

From what I remember, these snapshots are also used for the Windows
binary release, so will have to be fixed before 6.10 can be released.

Thanks

Neil

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================
Permalink | Reply | 0 comments |
headers
Sterling Clover | 30 Aug 20:52

Where STM is unstable at the moment, and how we can fix it

This email is inspired by the discussion here: http:// 
hackage.haskell.org/trac/ghc/ticket/2401

As the ticket discusses, unsafeIOToSTM is, unlike unsafePerformIO or  
unsafeInterleaveIO, genuinely completely unsafe in that there is no  
way to use it such that a segfault or deadlock is not at least  
somewhat encouraged. The code attached to the ticket creates a  
deadlock solely through using it to write to stdout. But, for the  
same reason that unsafeIOToSTM is unstable, unsafeInterleaveIO now is  
very unstable as well -- conceivably, data generated from functions  
with lazy IO (including those in the prelude) could cause deadlocks  
within STM, and even segfaults.

In summary, a "validation" step is performed on all threads inside  
atomically blocks during garbage collection. This validation step  
will, on encountering invalid threads (i.e. ones which should be  
rolled back) immediately kill them dead and retry. This is different  
than the implementation described in the STM paper, where rollbacks  
only occur on commit. However, it does add a measure of efficiency.  
The problem is that the validation code disregards exception  
handlers, since rollback is not an exception, and so anything  
embedded in STM that brackets an IO action, for example, can be  
rolled back without the final part of the exception even being called.

As Simon M. notes, the obvious solution would be to turn rollbacks  
into regular exceptions, but this would open a number of cans of worms.

A start, though not sufficient, would be for stm validation to  
respect blocked status -- not to block on it, obviously, but simply  
to refuse to rollback a transaction within it. Validation on GC is,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Peyton-Jones | 26 Aug 17:49

GHC's build system

Friends

There's been quite a bit of discussion about GHC's build system recently, and in particular about the use of
Cabal.  Responding to that discussion we now have a new plan, described here:

        http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem

If you've taken an interest in the earlier thread, now would be a good time to look at our plan and help us
improve it.

In concrete terms, we propose to develop the changes (which should not be a radical upheaval) on a branch,
and merge them into the head *after* the 6.10 code fork.  So the new build system won't be on the 6.10 branch. 
It'll take a while to make the new system stabilise, and we want to get 6.10 out!

Some comments and suggestions are best done by email, but please feel free to clarify or amplify wording on
the Wiki itself, or add lists of questions and open issues.  The two media are suitable for different
things.  But we do want to end up with a *comprehensible* description, with long-term value, of how the new
system works, so where things are obscure please help us to clarify it.

All this is somewhat separate to the question of what version control system to use for what.  We're still
working on that question!

Simon
Permalink | Reply | 1 comment |
headers
Chad Scherrer | 22 Aug 23:17

"dataflow rewriting engine"

Hello GHC,

This page
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/IntegratedCodeGen
mentions a to-be-developed "dataflow rewriting engine". Can someone
please send a description of what this will do?

Thanks!
--

-- 

Chad Scherrer

"Time flies like an arrow; fruit flies like a banana" -- Groucho Marx
Permalink | Reply | 11 comments |
headers
C Rodrigues | 22 Aug 16:05

Re: SHA1.hs woes, was Version control systems


I've "fixed" this problem by increasing the number of registers used on ia64 to 34.  The problem will show up
again if anyone finds a way to make GCC use even more registers.

-heatsink

>> 
>> Sorry, I couldn't find the rest of the preceding message. Someone  
>> wrote that they had to turn down cc flags to get SHA1.hs to compile on  
>> IA64.
> 
> Yep.
> 
>> What C compiler was being used, and what were the symptoms?
> 
> GCC.
> 
> As I recall the symptoms were that gcc used more than 32 registers and
> then the mangler balked. The reason is that a registerised ia64 build
> expects to only use the first 32 registers but does not take any
> precautions to make sure that this is the case. It just relies on the
> fact that most code coming out of the ghc backend cannot make use of
> more than a handful of registers. If gcc does actually use more then the
> mangler catches this. We tried some flags to make gcc restrict itself to
> a subset of the registers but could not get it to obey.
> 
> Duncan
_________________________________________________________________
Talk to your Yahoo! Friends via Windows Live Messenger.  Find out how.
http://www.windowslive.com/explore/messenger?ocid=TXT_TAGLM_WL_messenger_yahoo_082008
(Continue reading)

Permalink | Reply | 0 comments |
headers
Venkat Ramanan | 21 Aug 22:16

ghci history.

Hi all,

I've just started learning haskell.

I encountered a strange behaviour in ghci.

1. ghci doesn't seem to do pruning of duplicate expressions. If the same expression is entered twice, both of them are stored in the history instead of just one. Bash uses environmental variables (HISTCONTROL and HISTIGNORE ) to modify this behavior.

Is there a way to get the same behaviour in ghci?

2. Does the history of ghci get stored somewhere in a file? That would be useful.

I'm using ghc-6.8.2 (ubuntu 8.04).

Also, is there an updated ghc package (6.8.3)  for ubuntu? If not, I'll try to install the binary.

Thanks,
Venkat.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Permalink | Reply | 2 comments |

Gmane