The Glasgow Haskell Users Mailing List

Gregory Wright | 1 Apr 2010 03:10

Re: Profiling bug in 6.10.4


On 3/31/10 11:44 AM, Ian Lynagh wrote:
> On Mon, Mar 22, 2010 at 02:54:26PM -0400, Gregory Wright wrote:
>    
>> Now they seem to both be correct.  The key value is at the bottom of
>> column 8.  This should be 2.386e-1
>> (which means that 23.86 percent of the protons in the early universe end
>> up as helium).  So it
>> seems that this is a problem either with 6.10.4, or with OS X.
>>
>> Quite strange.  I will try to get 6.12 building on my machine to see if
>> the problem persists.
>>      
> It would also be worth trying without the -optc-O3 and -optc-ffast-math
> flags, as the different code generated may confuse the mangler.
>
> If none of that helps, can you file a ticket please? If you can boil it
> down to a small self-contained testcase (in particular, removing the
> hmatrix dependency, if necessary by inlining code you need from it)
> that would make it easier to investigate.
>
>
> Thanks
> Ian
>
>
>    
Removing -optc-O3 and -optc-ffast-math did not help.  In fact, I took at 
all of the
ghc options I was passing and the problem is still there. I will try to

(Continue reading)

headers

Ian Lynagh | 1 Apr 2010 14:28

ANNOUNCE: GHC 6.12.2 Release Candidate 1


Hi all,

We are pleased to announce the first release candidate for GHC 6.12.2:

    http://www.haskell.org/ghc/dist/6.12.2-rc1/

As well as the source tarball:
    ghc-6.12.1.20100330-src.tar.bz2
there are installers for Windows (i386) and OS X (i386), and binary
distributions for x86_64/Linux and i386/Linux.

Please test as much as possible; bugs are much cheaper if we find them
before the release!

Thanks
Ian, on behalf of the GHC team

headers

Ian Lynagh | 1 Apr 2010 14:34

Re: Plans for GHC 6.12.2

On Fri, Mar 26, 2010 at 07:31:20AM +0900, Yusaku Hashimoto wrote:
> How about dynamic libraries on Mac?
> 
> http://hackage.haskell.org/trac/ghc/ticket/3550
> 
> If the patch works fine, please include it in the next release.

I wasn't able to get this done in time, sorry.

Thanks
Ian

headers

Simon Marlow | 1 Apr 2010 16:40

Re: Profiling bug in 6.10.4

On 01/04/2010 02:10, Gregory Wright wrote:
>
> On 3/31/10 11:44 AM, Ian Lynagh wrote:
>> On Mon, Mar 22, 2010 at 02:54:26PM -0400, Gregory Wright wrote:
>>> Now they seem to both be correct. The key value is at the bottom of
>>> column 8. This should be 2.386e-1
>>> (which means that 23.86 percent of the protons in the early universe end
>>> up as helium). So it
>>> seems that this is a problem either with 6.10.4, or with OS X.
>>>
>>> Quite strange. I will try to get 6.12 building on my machine to see if
>>> the problem persists.
>> It would also be worth trying without the -optc-O3 and -optc-ffast-math
>> flags, as the different code generated may confuse the mangler.
>>
>> If none of that helps, can you file a ticket please? If you can boil it
>> down to a small self-contained testcase (in particular, removing the
>> hmatrix dependency, if necessary by inlining code you need from it)
>> that would make it easier to investigate.
>>
>>
>> Thanks
>> Ian
>>
>>
> Removing -optc-O3 and -optc-ffast-math did not help. In fact, I took at
> all of the
> ghc options I was passing and the problem is still there. I will try to
> reduce the failure
> to a self contained testcase. I don't use much from hmatrix --- aside

(Continue reading)

headers

Vladimir Reshetnikov | 3 Apr 2010 15:40

Different behavior of GHC 6.10.1 and Hugs (Sep 2006)

Hi list,

GHC 6.10.1:

Prelude> :t let f x y = return x == return y in f

let f x y = return x == return y in f :: (Eq (m a), Monad m) => a -> a -> Bool

Hugs (Sep 2006):

Hugs> :t let f x y = return x == return y in f

ERROR - Ambiguous type signature in inferred type

*** ambiguous type : (Eq (a b), Monad a) => b -> b -> Bool

*** assigned to : f

Who is right?

--

Thanks

Vladimir

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

headers

Gracjan Polak | 5 Apr 2010 11:43

ClockTime closure linking issue


Hi all,

Probable bug in GHC, I want to inquire before I report it proper. Did anybody
see something like this:

c:\Sources\happstack\happstack\templates\project>cabal build
[1 of 1] Compiling Main             ( Setup.hs, dist\setup\Main.o )
Linking .\dist\setup\setup.exe ...
Preprocessing executables for guestbook-1.0...
Building guestbook-1.0...
[11 of 11] Compiling Main             ( src\Main.hs, dist\build\guestbook-server
\guestbook-server-tmp\Main.o )
Linking dist\build\guestbook-server\guestbook-server.exe ...
dist\build\guestbook-server\guestbook-server-tmp\GuestBook\State2.o:fake:(.text+
0x6d89): undefined reference to `happstackzm0zi4zi3_HappstackziStateziClockTime_
constrZMabmKZN_closure'
dist\build\guestbook-server\guestbook-server-tmp\GuestBook\State2.o:fake:(.text+
0x6dd1): undefined reference to `happstackzm0zi4zi3_HappstackziStateziClockTime_
dataTypeZMabmJZN_closure'
[...lots of same messages skipped...]
collect2: ld returned 1 exit status

Application is from

http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack/templates/project

The Glorious Glasgow Haskell Compilation System, version 6.12.1

System Windows Vista 32bit.

Help!

--

-- 
Gracjan

headers

Philip Weaver | 5 Apr 2010 12:01

GHC internal error

Hi all,

A program that I built with GHC is crashing at runtime with the following error:

internal error: eval_thunk_selector: strange selectee 12

I have not found much via Google, just an old post regarding ghc 6.0 that recommends cleaning and rebuilding. I have cleaned the build directory and re-built the executable, and I still get the error.

The program is a compiler, and this error began showing up after I added support for memoization of results using the ST Monad and STRefs. For example, the following function creates a reference to a thunk:

newMutableRef m

= do ref <- newSTRef $ error "access ref too soon!"

let m' = do r <- m

writeSTRef ref (return r)

return r

writeSTRef ref m'

return $ ref

Here's some information about my system:

GHC 6.12.1
Mac OS X 10.6.3 (Snow Leopard)

So, what could cause this error? Any suggestions that can help me narrow down the problem would be greatly appreciated. If this is in fact a GHC bug, I'd like to find a workaround for now and also reproduce it in a small example so I can file a bug report.

- Philip

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

headers

Jeremy Shaw | 5 Apr 2010 14:37

Re: ClockTime closure linking issue

My first guess is that it is another instance of this bug:

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

You might be able to use this option:

--haddockdir=DIR installation directory for haddock interfaces

though perhaps that flag is only in the latest version of cabal / ghc.

- jeremy

On Apr 5, 2010, at 4:43 AM, Gracjan Polak wrote:

Hi all,

Probable bug in GHC, I want to inquire before I report it proper. Did anybody
see something like this:

c:\Sources\happstack\happstack\templates\project>cabal build
[1 of 1] Compiling Main ( Setup.hs, dist\setup\Main.o )
Linking .\dist\setup\setup.exe ...
Preprocessing executables for guestbook-1.0...
Building guestbook-1.0...
[11 of 11] Compiling Main ( src\Main.hs, dist\build\guestbook-server
\guestbook-server-tmp\Main.o )
Linking dist\build\guestbook-server\guestbook-server.exe ...
dist\build\guestbook-server\guestbook-server-tmp\GuestBook\State2.o:fake:(.text+
0x6d89): undefined reference to `happstackzm0zi4zi3_HappstackziStateziClockTime_
constrZMabmKZN_closure'
dist\build\guestbook-server\guestbook-server-tmp\GuestBook\State2.o:fake:(.text+
0x6dd1): undefined reference to `happstackzm0zi4zi3_HappstackziStateziClockTime_
dataTypeZMabmJZN_closure'
[...lots of same messages skipped...]
collect2: ld returned 1 exit status

Application is from

http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack/templates/project

The Glorious Glasgow Haskell Compilation System, version 6.12.1

System Windows Vista 32bit.

Help!

--
Gracjan

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

headers

Gracjan Polak | 5 Apr 2010 15:03

Re: ClockTime closure linking issue


Jeremy Shaw <jeremy <at> n-heptane.com> writes:

> 
> My first guess is that it is another instance of this bug:
> http://hackage.haskell.org/trac/ghc/ticket/3799

Seems like putting

documentation: True

into

C:\Users\gracjan\AppData\Roaming\cabal\config

makes this error stand out

--

-- 
Gracjan

headers

Don Stewart | 5 Apr 2010 20:59

Re: GHC internal error

Any 'internal error' is almost certainly an RTS or compiler bug. Can you
make a bug report?

philip.weaver:
> Hi all,
> 
> A program that I built with GHC is crashing at runtime with the following
> error:
> 
>     internal error: eval_thunk_selector: strange selectee 12
> 
> I have not found much via Google, just an old post regarding ghc 6.0 that
> recommends cleaning and rebuilding.  I have cleaned the build directory and
> re-built the executable, and I still get the error.
> 
> The program is a compiler, and this error began showing up after I added
> support for memoization of results using the ST Monad and STRefs.  For example,
> the following function creates a reference to a thunk:
> 
> newMutableRef m
>   = do ref <- newSTRef $ error "access ref too soon!"
>        let m' = do r <- m
>                    writeSTRef ref (return r)
>                    return r
>        writeSTRef ref m'
>        return $ ref
> 
> Here's some information about my system:
> 
>   • GHC 6.12.1
>   • Mac OS X 10.6.3 (Snow Leopard)
> 
> So, what could cause this error?  Any suggestions that can help me narrow down
> the problem would be greatly appreciated.  If this is in fact a GHC bug, I'd
> like to find a workaround for now and also reproduce it in a small example so I
> can file a bug report.
> 
> - Philip
> 

> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users <at> haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

13	May 2013
35	April 2013
66	March 2013
106	February 2013
305	January 2013
172	December 2012
117	November 2012
106	October 2012
100	September 2012
154	August 2012
151	July 2012
98	June 2012
46	May 2012
131	April 2012
181	March 2012
254	February 2012
326	January 2012
128	December 2011
158	November 2011
143	October 2011
113	September 2011
180	August 2011
99	July 2011
89	June 2011
87	May 2011
96	April 2011
143	March 2011
157	February 2011
148	January 2011
85	December 2010
194	November 2010
124	October 2010
170	September 2010
84	August 2010
86	July 2010
90	June 2010
65	May 2010
143	April 2010
133	March 2010
171	February 2010
101	January 2010
143	December 2009
144	November 2009
148	October 2009
56	September 2009
114	August 2009
132	July 2009
146	June 2009
191	May 2009
152	April 2009
265	March 2009
187	February 2009
135	January 2009
153	December 2008
393	November 2008
235	October 2008
232	September 2008
286	August 2008
88	July 2008
197	June 2008
134	May 2008
112	April 2008
172	March 2008
180	February 2008
275	January 2008
319	December 2007
339	November 2007
123	October 2007
156	September 2007
99	August 2007
98	July 2007
172	June 2007
237	May 2007
190	April 2007
197	March 2007
130	February 2007
100	January 2007
152	December 2006
217	November 2006
305	October 2006
191	September 2006
309	August 2006
231	July 2006
134	June 2006
141	May 2006
192	April 2006
206	March 2006
141	February 2006
113	January 2006
148	December 2005
147	November 2005
147	October 2005
111	September 2005
111	August 2005
114	July 2005
196	June 2005
135	May 2005
142	April 2005
233	March 2005
282	February 2005
138	January 2005
87	December 2004
141	November 2004
191	October 2004
101	September 2004
127	August 2004
54	July 2004
201	June 2004
106	May 2004
115	April 2004
135	March 2004
69	February 2004
143	January 2004
108	December 2003
86	November 2003
136	October 2003
120	September 2003
84	August 2003
105	July 2003
168	June 2003
140	May 2003
108	April 2003
89	March 2003
138	February 2003
153	January 2003
128	December 2002
210	November 2002
137	October 2002
162	September 2002
104	August 2002
192	July 2002
190	June 2002
136	May 2002
166	April 2002
99	March 2002
160	February 2002
110	January 2002
81	December 2001
123	November 2001
200	October 2001
124	September 2001
123	August 2001
90	July 2001
68	June 2001
90	May 2001
112	April 2001
62	March 2001
72	February 2001
36	January 2001
46	December 2000
45	November 2000
47	October 2000

Mon	Tue	Wed	Thu	Fri	Sat	Sun

			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30