From rrnewton at gmail.com  Sat Feb  1 05:33:59 2014
From: rrnewton at gmail.com (Ryan Newton)
Date: Sat, 1 Feb 2014 00:33:59 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
Message-ID: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>

I commented on the commit here:


https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b

The problem is that our "cas" routine in SMP.h is similar to the C compiler
intrinsic __sync_val_compare_and_swap, in that it returns the old value.
 But it seems we cannot use a comparison against that old value to
determine whether or not the CAS succeeded.  (I believe the CAS may fail
due to contention, but the old value may happen to look like our old value.)

Unfortunately, this didn't occur to me until it started causing bugs [1]
[2].  Fixing casMutVar# fixes these bugs.  However, the way I'm currently
fixing CAS in the "atomic-primops" package is by using
__sync_bool_compare_and_swap:


https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200

What is the best fix for GHC itself?   Would it be ok for GHC to include a
C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise we need
another big ifdbef'd function like "cas" in SMP.h that has the
architecture-specific inline asm across all architectures.  I can write the
x86 one, but I'm not eager to try the others.

Best,
   -Ryan

[1] https://github.com/iu-parfunc/lvars/issues/70
[2] https://github.com/rrnewton/haskell-lockfree/issues/15
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/ad2bf67e/attachment.html>

From rrnewton at gmail.com  Sat Feb  1 05:58:13 2014
From: rrnewton at gmail.com (Ryan Newton)
Date: Sat, 1 Feb 2014 00:58:13 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
Message-ID: <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>

Then again... I'm having trouble seeing how the spec on page 3-149 of the
Intel manual would allow the behavior I'm seeing:

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

Nevertheless, this is exactly the behavior we're seeing with the current
Haskell primops.  Two threads simultaneously performing the same CAS(p,a,b)
can both think that they succeeded.





On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com> wrote:

> I commented on the commit here:
>
>
> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>
> The problem is that our "cas" routine in SMP.h is similar to the C
> compiler intrinsic __sync_val_compare_and_swap, in that it returns the old
> value.  But it seems we cannot use a comparison against that old value to
> determine whether or not the CAS succeeded.  (I believe the CAS may fail
> due to contention, but the old value may happen to look like our old value.)
>
> Unfortunately, this didn't occur to me until it started causing bugs [1]
> [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm currently
> fixing CAS in the "atomic-primops" package is by using
> __sync_bool_compare_and_swap:
>
>
> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>
> What is the best fix for GHC itself?   Would it be ok for GHC to include a
> C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise we need
> another big ifdbef'd function like "cas" in SMP.h that has the
> architecture-specific inline asm across all architectures.  I can write the
> x86 one, but I'm not eager to try the others.
>
> Best,
>    -Ryan
>
> [1] https://github.com/iu-parfunc/lvars/issues/70
> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/931c1730/attachment.html>

From carter.schonwald at gmail.com  Sat Feb  1 06:12:58 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2014 01:12:58 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
Message-ID: <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>

Hey Ryan,
looking at this closely
Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could that be the
culprit?

Could the issue be that we've not had a good stress test that would create
values that are equal on the 32bit range, but differ on the 64bit range,
and you're hitting that?

Could you try seeing if doing that change fixes things up?
(I may be completely wrong, but just throwing this out as a naive "obvious"
guess)


On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com> wrote:

> Then again... I'm having trouble seeing how the spec on page 3-149 of the
> Intel manual would allow the behavior I'm seeing:
>
>
> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>
> Nevertheless, this is exactly the behavior we're seeing with the current
> Haskell primops.  Two threads simultaneously performing the same CAS(p,a,b)
> can both think that they succeeded.
>
>
>
>
>
> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>
>> I commented on the commit here:
>>
>>
>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>
>> The problem is that our "cas" routine in SMP.h is similar to the C
>> compiler intrinsic __sync_val_compare_and_swap, in that it returns the old
>> value.  But it seems we cannot use a comparison against that old value to
>> determine whether or not the CAS succeeded.  (I believe the CAS may fail
>> due to contention, but the old value may happen to look like our old value.)
>>
>> Unfortunately, this didn't occur to me until it started causing bugs [1]
>> [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm currently
>> fixing CAS in the "atomic-primops" package is by using
>> __sync_bool_compare_and_swap:
>>
>>
>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>
>> What is the best fix for GHC itself?   Would it be ok for GHC to include
>> a C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise we need
>> another big ifdbef'd function like "cas" in SMP.h that has the
>> architecture-specific inline asm across all architectures.  I can write the
>> x86 one, but I'm not eager to try the others.
>>
>> Best,
>>    -Ryan
>>
>> [1] https://github.com/iu-parfunc/lvars/issues/70
>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/ee620af5/attachment-0001.html>

From carter.schonwald at gmail.com  Sat Feb  1 06:36:16 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2014 01:36:16 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
Message-ID: <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>

ok, i can confirm that on my 64bit mac, both clang and gcc use cmpxchgl
rather than cmpxchg
i'll whip up a strawman patch on head that can be cherrypicked / tested out
by ryan et al


On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> Hey Ryan,
> looking at this closely
> Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could that be the
> culprit?
>
> Could the issue be that we've not had a good stress test that would create
> values that are equal on the 32bit range, but differ on the 64bit range,
> and you're hitting that?
>
> Could you try seeing if doing that change fixes things up?
> (I may be completely wrong, but just throwing this out as a naive
> "obvious" guess)
>
>
> On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>
>> Then again... I'm having trouble seeing how the spec on page 3-149 of the
>> Intel manual would allow the behavior I'm seeing:
>>
>>
>> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>
>> Nevertheless, this is exactly the behavior we're seeing with the current
>> Haskell primops.  Two threads simultaneously performing the same CAS(p,a,b)
>> can both think that they succeeded.
>>
>>
>>
>>
>>
>> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>
>>> I commented on the commit here:
>>>
>>>
>>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>>
>>> The problem is that our "cas" routine in SMP.h is similar to the C
>>> compiler intrinsic __sync_val_compare_and_swap, in that it returns the old
>>> value.  But it seems we cannot use a comparison against that old value to
>>> determine whether or not the CAS succeeded.  (I believe the CAS may fail
>>> due to contention, but the old value may happen to look like our old value.)
>>>
>>> Unfortunately, this didn't occur to me until it started causing bugs [1]
>>> [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm currently
>>> fixing CAS in the "atomic-primops" package is by using
>>> __sync_bool_compare_and_swap:
>>>
>>>
>>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>>
>>> What is the best fix for GHC itself?   Would it be ok for GHC to include
>>> a C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise we need
>>> another big ifdbef'd function like "cas" in SMP.h that has the
>>> architecture-specific inline asm across all architectures.  I can write the
>>> x86 one, but I'm not eager to try the others.
>>>
>>> Best,
>>>    -Ryan
>>>
>>> [1] https://github.com/iu-parfunc/lvars/issues/70
>>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>>
>>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/2069551d/attachment.html>

From carter.schonwald at gmail.com  Sat Feb  1 06:58:28 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2014 01:58:28 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
Message-ID: <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>

woops, i mean cmpxchgq


On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> ok, i can confirm that on my 64bit mac, both clang and gcc use cmpxchgl
> rather than cmpxchg
> i'll whip up a strawman patch on head that can be cherrypicked / tested
> out by ryan et al
>
>
> On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> Hey Ryan,
>> looking at this closely
>> Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could that be the
>> culprit?
>>
>> Could the issue be that we've not had a good stress test that would
>> create values that are equal on the 32bit range, but differ on the 64bit
>> range, and you're hitting that?
>>
>> Could you try seeing if doing that change fixes things up?
>> (I may be completely wrong, but just throwing this out as a naive
>> "obvious" guess)
>>
>>
>> On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>
>>> Then again... I'm having trouble seeing how the spec on page 3-149 of
>>> the Intel manual would allow the behavior I'm seeing:
>>>
>>>
>>> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>>
>>> Nevertheless, this is exactly the behavior we're seeing with the current
>>> Haskell primops.  Two threads simultaneously performing the same CAS(p,a,b)
>>> can both think that they succeeded.
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>>
>>>> I commented on the commit here:
>>>>
>>>>
>>>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>>>
>>>> The problem is that our "cas" routine in SMP.h is similar to the C
>>>> compiler intrinsic __sync_val_compare_and_swap, in that it returns the old
>>>> value.  But it seems we cannot use a comparison against that old value to
>>>> determine whether or not the CAS succeeded.  (I believe the CAS may fail
>>>> due to contention, but the old value may happen to look like our old value.)
>>>>
>>>> Unfortunately, this didn't occur to me until it started causing bugs
>>>> [1] [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm
>>>> currently fixing CAS in the "atomic-primops" package is by using
>>>> __sync_bool_compare_and_swap:
>>>>
>>>>
>>>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>>>
>>>> What is the best fix for GHC itself?   Would it be ok for GHC to
>>>> include a C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise
>>>> we need another big ifdbef'd function like "cas" in SMP.h that has the
>>>> architecture-specific inline asm across all architectures.  I can write the
>>>> x86 one, but I'm not eager to try the others.
>>>>
>>>> Best,
>>>>    -Ryan
>>>>
>>>> [1] https://github.com/iu-parfunc/lvars/issues/70
>>>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/89e9051a/attachment.html>

From carter.schonwald at gmail.com  Sat Feb  1 07:33:24 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2014 02:33:24 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
 <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
Message-ID: <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>

i have a ticket for tracking this, though i'm thinking my initial attempt
at a patch generates the same object code as it did before.

@ryan, what CPU variant are you testing this on? is this on a NUMA machine
or something?


On Sat, Feb 1, 2014 at 1:58 AM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> woops, i mean cmpxchgq
>
>
> On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> ok, i can confirm that on my 64bit mac, both clang and gcc use cmpxchgl
>> rather than cmpxchg
>> i'll whip up a strawman patch on head that can be cherrypicked / tested
>> out by ryan et al
>>
>>
>> On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> Hey Ryan,
>>> looking at this closely
>>> Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could that be the
>>> culprit?
>>>
>>> Could the issue be that we've not had a good stress test that would
>>> create values that are equal on the 32bit range, but differ on the 64bit
>>> range, and you're hitting that?
>>>
>>> Could you try seeing if doing that change fixes things up?
>>> (I may be completely wrong, but just throwing this out as a naive
>>> "obvious" guess)
>>>
>>>
>>> On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>>
>>>> Then again... I'm having trouble seeing how the spec on page 3-149 of
>>>> the Intel manual would allow the behavior I'm seeing:
>>>>
>>>>
>>>> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>>>
>>>> Nevertheless, this is exactly the behavior we're seeing with the
>>>> current Haskell primops.  Two threads simultaneously performing the same
>>>> CAS(p,a,b) can both think that they succeeded.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>
>>>>> I commented on the commit here:
>>>>>
>>>>>
>>>>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>>>>
>>>>> The problem is that our "cas" routine in SMP.h is similar to the C
>>>>> compiler intrinsic __sync_val_compare_and_swap, in that it returns the old
>>>>> value.  But it seems we cannot use a comparison against that old value to
>>>>> determine whether or not the CAS succeeded.  (I believe the CAS may fail
>>>>> due to contention, but the old value may happen to look like our old value.)
>>>>>
>>>>> Unfortunately, this didn't occur to me until it started causing bugs
>>>>> [1] [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm
>>>>> currently fixing CAS in the "atomic-primops" package is by using
>>>>> __sync_bool_compare_and_swap:
>>>>>
>>>>>
>>>>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>>>>
>>>>> What is the best fix for GHC itself?   Would it be ok for GHC to
>>>>> include a C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise
>>>>> we need another big ifdbef'd function like "cas" in SMP.h that has the
>>>>> architecture-specific inline asm across all architectures.  I can write the
>>>>> x86 one, but I'm not eager to try the others.
>>>>>
>>>>> Best,
>>>>>    -Ryan
>>>>>
>>>>> [1] https://github.com/iu-parfunc/lvars/issues/70
>>>>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/c6aaa00b/attachment-0001.html>

From carter.schonwald at gmail.com  Sat Feb  1 07:44:00 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2014 02:44:00 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
 <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
 <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>
Message-ID: <CAHYVw0zDuSLjJJexdOjusbyr=Q5o7OdDG65g8wdseZqq6QgayQ@mail.gmail.com>

https://ghc.haskell.org/trac/ghc/ticket/8724#ticket is the ticket

when i'm more awake i'll experiment some more


On Sat, Feb 1, 2014 at 2:33 AM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> i have a ticket for tracking this, though i'm thinking my initial attempt
> at a patch generates the same object code as it did before.
>
> @ryan, what CPU variant are you testing this on? is this on a NUMA machine
> or something?
>
>
> On Sat, Feb 1, 2014 at 1:58 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> woops, i mean cmpxchgq
>>
>>
>> On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> ok, i can confirm that on my 64bit mac, both clang and gcc use cmpxchgl
>>> rather than cmpxchg
>>> i'll whip up a strawman patch on head that can be cherrypicked / tested
>>> out by ryan et al
>>>
>>>
>>> On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> Hey Ryan,
>>>> looking at this closely
>>>> Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could that be
>>>> the culprit?
>>>>
>>>> Could the issue be that we've not had a good stress test that would
>>>> create values that are equal on the 32bit range, but differ on the 64bit
>>>> range, and you're hitting that?
>>>>
>>>> Could you try seeing if doing that change fixes things up?
>>>> (I may be completely wrong, but just throwing this out as a naive
>>>> "obvious" guess)
>>>>
>>>>
>>>> On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>
>>>>> Then again... I'm having trouble seeing how the spec on page 3-149 of
>>>>> the Intel manual would allow the behavior I'm seeing:
>>>>>
>>>>>
>>>>> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>>>>
>>>>> Nevertheless, this is exactly the behavior we're seeing with the
>>>>> current Haskell primops.  Two threads simultaneously performing the same
>>>>> CAS(p,a,b) can both think that they succeeded.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>
>>>>>> I commented on the commit here:
>>>>>>
>>>>>>
>>>>>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>>>>>
>>>>>> The problem is that our "cas" routine in SMP.h is similar to the C
>>>>>> compiler intrinsic __sync_val_compare_and_swap, in that it returns the old
>>>>>> value.  But it seems we cannot use a comparison against that old value to
>>>>>> determine whether or not the CAS succeeded.  (I believe the CAS may fail
>>>>>> due to contention, but the old value may happen to look like our old value.)
>>>>>>
>>>>>> Unfortunately, this didn't occur to me until it started causing bugs
>>>>>> [1] [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm
>>>>>> currently fixing CAS in the "atomic-primops" package is by using
>>>>>> __sync_bool_compare_and_swap:
>>>>>>
>>>>>>
>>>>>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>>>>>
>>>>>> What is the best fix for GHC itself?   Would it be ok for GHC to
>>>>>> include a C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise
>>>>>> we need another big ifdbef'd function like "cas" in SMP.h that has the
>>>>>> architecture-specific inline asm across all architectures.  I can write the
>>>>>> x86 one, but I'm not eager to try the others.
>>>>>>
>>>>>> Best,
>>>>>>    -Ryan
>>>>>>
>>>>>> [1] https://github.com/iu-parfunc/lvars/issues/70
>>>>>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/edac9fa4/attachment.html>

From tkn.akio at gmail.com  Sat Feb  1 07:52:01 2014
From: tkn.akio at gmail.com (Akio Takano)
Date: Sat, 1 Feb 2014 16:52:01 +0900
Subject: Extending fold/build fusion
In-Reply-To: <1391181446.3184.25.camel@kirk>
References: <CAOGQyFsnEsvS47+PaMSZvWkPOPsjYfmbuC6Bfm02r-VX6t6-Dw@mail.gmail.com>
 <1390932396.2641.46.camel@kirk>
 <CAOGQyFup3pZ_H_9f148WK5-LucpfSCe0XPg=PgYxDdR4Q0aOLw@mail.gmail.com>
 <1391159897.3184.10.camel@kirk> <1391181446.3184.25.camel@kirk>
Message-ID: <CAOGQyFvqa=keriD9y-+Ggxvec7LWWjb_tp7XCP6Td_9g=CMVug@mail.gmail.com>

On Sat, Feb 1, 2014 at 12:17 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Dar Akio,
>
> I just noticed that even with your approach, the code for foldl-as-foldr
> is not automatically beautiful. Consider this:
>
> I modified the eft function to do to some heavy work at each step (or at
> least to look like that):
>
> myEft :: Int -> Int -> [Int]
> myEft = \from to -> buildW (myEftFB from to)
> {-# INLINE myEft #-}
>
> expensive :: Int -> Int
> expensive = (1+)
> {-# NOINLINE expensive #-}
>
> myEftFB
>   :: Int
>   -> Int
>   -> (Wrap f r)
>   -> (Int -> r -> r)
>   -> r
>   -> r
> myEftFB from to (Wrap wrap unwrap) cons nil = wrap go from nil
>   where
>     go = unwrap $ \i rest -> if i <= to
>       then cons i $ wrap go (expensive i) rest
>       else rest
> {-# INLINE[0] myEftFB #-}
>
> Then I wanted to see if "sum [f..t]" using this code is good:
>
> sumUpTo :: Int -> Int -> Int
> sumUpTo f t = WW.foldl' (+) 0 (myEft f t)
>
> And this is the core I get for the inner loop:
>
>     letrec {
>       $wa :: GHC.Prim.Int# -> GHC.Types.Int -> GHC.Types.Int
>       [LclId, Arity=1, Str=DmdType L]
>       $wa =
>         \ (ww2 :: GHC.Prim.Int#) ->
>           case GHC.Prim.<=# ww2 ww1 of _ {
>             GHC.Types.False -> GHC.Base.id @ GHC.Types.Int;
>             GHC.Types.True ->
>               let {
>                 e [Dmd=Just D(L)] :: GHC.Types.Int
>                 [LclId, Str=DmdType]
>                 e = F.expensive (GHC.Types.I# ww2) } in
>               \ (acc :: GHC.Types.Int) ->
>                 case acc of _ { GHC.Types.I# x ->
>                 case e of _ { GHC.Types.I# ww3 ->
>                 $wa ww3 (GHC.Types.I# (GHC.Prim.+# x ww2))
>                 }
>                 }
>           }; } in
>     $wa ww F.sumUpTo1
>
> (GHC 7.6.3, -O).
>
> See how it is still building up partial applications. So I am a bit
> confused now: I thought the (or one) motivation for your proposal is to
> produce good code in these cases. Or am I using your code wrongly?

Yes, this is supposed to work. Fortunately it was an easy fix:

https://github.com/takano-akio/ww-fusion/commit/ae26b18b135d92e0df7513e5efc0388e085698bf

Thank you for pointing this out!

-- Akio

>
> Greetings,
> Joachim
>
> --
> Joachim "nomeata" Breitner
>   mail at joachim-breitner.de * http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  * GPG-Key: 0x4743206C
>   Debian Developer: nomeata at debian.org

From carter.schonwald at gmail.com  Sat Feb  1 07:55:09 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2014 02:55:09 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CAHYVw0zDuSLjJJexdOjusbyr=Q5o7OdDG65g8wdseZqq6QgayQ@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
 <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
 <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>
 <CAHYVw0zDuSLjJJexdOjusbyr=Q5o7OdDG65g8wdseZqq6QgayQ@mail.gmail.com>
Message-ID: <CAHYVw0yRYUAfmpDbCzy2A3wSCUu5-gBN_RrJjkGvodZSznZR_w@mail.gmail.com>

Ryan, is your benchmark using CAS on pointers, or immediate words? trying
to get atomic primops to build on my 7.8 build on my mac


On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> https://ghc.haskell.org/trac/ghc/ticket/8724#ticket is the ticket
>
> when i'm more awake i'll experiment some more
>
>
> On Sat, Feb 1, 2014 at 2:33 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> i have a ticket for tracking this, though i'm thinking my initial attempt
>> at a patch generates the same object code as it did before.
>>
>> @ryan, what CPU variant are you testing this on? is this on a NUMA
>> machine or something?
>>
>>
>> On Sat, Feb 1, 2014 at 1:58 AM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> woops, i mean cmpxchgq
>>>
>>>
>>> On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> ok, i can confirm that on my 64bit mac, both clang and gcc use cmpxchgl
>>>> rather than cmpxchg
>>>> i'll whip up a strawman patch on head that can be cherrypicked / tested
>>>> out by ryan et al
>>>>
>>>>
>>>> On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> Hey Ryan,
>>>>> looking at this closely
>>>>> Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could that be
>>>>> the culprit?
>>>>>
>>>>> Could the issue be that we've not had a good stress test that would
>>>>> create values that are equal on the 32bit range, but differ on the 64bit
>>>>> range, and you're hitting that?
>>>>>
>>>>> Could you try seeing if doing that change fixes things up?
>>>>> (I may be completely wrong, but just throwing this out as a naive
>>>>> "obvious" guess)
>>>>>
>>>>>
>>>>> On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>
>>>>>> Then again... I'm having trouble seeing how the spec on page 3-149 of
>>>>>> the Intel manual would allow the behavior I'm seeing:
>>>>>>
>>>>>>
>>>>>> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>>>>>
>>>>>> Nevertheless, this is exactly the behavior we're seeing with the
>>>>>> current Haskell primops.  Two threads simultaneously performing the same
>>>>>> CAS(p,a,b) can both think that they succeeded.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>>
>>>>>>> I commented on the commit here:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>>>>>>
>>>>>>> The problem is that our "cas" routine in SMP.h is similar to the C
>>>>>>> compiler intrinsic __sync_val_compare_and_swap, in that it returns the old
>>>>>>> value.  But it seems we cannot use a comparison against that old value to
>>>>>>> determine whether or not the CAS succeeded.  (I believe the CAS may fail
>>>>>>> due to contention, but the old value may happen to look like our old value.)
>>>>>>>
>>>>>>> Unfortunately, this didn't occur to me until it started causing bugs
>>>>>>> [1] [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm
>>>>>>> currently fixing CAS in the "atomic-primops" package is by using
>>>>>>> __sync_bool_compare_and_swap:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>>>>>>
>>>>>>> What is the best fix for GHC itself?   Would it be ok for GHC to
>>>>>>> include a C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise
>>>>>>> we need another big ifdbef'd function like "cas" in SMP.h that has the
>>>>>>> architecture-specific inline asm across all architectures.  I can write the
>>>>>>> x86 one, but I'm not eager to try the others.
>>>>>>>
>>>>>>> Best,
>>>>>>>    -Ryan
>>>>>>>
>>>>>>> [1] https://github.com/iu-parfunc/lvars/issues/70
>>>>>>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ghc-devs mailing list
>>>>>> ghc-devs at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/72626f90/attachment-0001.html>

From mail at joachim-breitner.de  Sat Feb  1 10:27:53 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 01 Feb 2014 10:27:53 +0000
Subject: Extending fold/build fusion
In-Reply-To: <CAOGQyFvqa=keriD9y-+Ggxvec7LWWjb_tp7XCP6Td_9g=CMVug@mail.gmail.com>
References: <CAOGQyFsnEsvS47+PaMSZvWkPOPsjYfmbuC6Bfm02r-VX6t6-Dw@mail.gmail.com>
 <1390932396.2641.46.camel@kirk>
 <CAOGQyFup3pZ_H_9f148WK5-LucpfSCe0XPg=PgYxDdR4Q0aOLw@mail.gmail.com>
 <1391159897.3184.10.camel@kirk> <1391181446.3184.25.camel@kirk>
 <CAOGQyFvqa=keriD9y-+Ggxvec7LWWjb_tp7XCP6Td_9g=CMVug@mail.gmail.com>
Message-ID: <1391250473.2520.2.camel@kirk>

Dear Akio,

Am Samstag, den 01.02.2014, 16:52 +0900 schrieb Akio Takano:
> On Sat, Feb 1, 2014 at 12:17 AM, Joachim Breitner
> <mail at joachim-breitner.de> wrote:
> Yes, this is supposed to work. Fortunately it was an easy fix:
> 
> https://github.com/takano-akio/ww-fusion/commit/ae26b18b135d92e0df7513e5efc0388e085698bf
> 
> Thank you for pointing this out!

much better, and this way I understand better what?s going on.

I?m looking forward to your results from running nofib.

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/7a03aad5/attachment.sig>

From rrnewton at gmail.com  Sat Feb  1 14:10:53 2014
From: rrnewton at gmail.com (Ryan Newton)
Date: Sat, 1 Feb 2014 09:10:53 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CAHYVw0yRYUAfmpDbCzy2A3wSCUu5-gBN_RrJjkGvodZSznZR_w@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
 <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
 <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>
 <CAHYVw0zDuSLjJJexdOjusbyr=Q5o7OdDG65g8wdseZqq6QgayQ@mail.gmail.com>
 <CAHYVw0yRYUAfmpDbCzy2A3wSCUu5-gBN_RrJjkGvodZSznZR_w@mail.gmail.com>
Message-ID: <CACYs5AY9uBXtmO5g4xmqsQb9Hb7vH+aiYPtNUbTs+dJjMcbk+w@mail.gmail.com>

Hi Carter & others,

Carter, yes, this is CAS on pointers and in my next mail I'll try to come
up with some hypotheses as to why we may have (remaining) problems there.

But first, I have been assured that on x86 there is no failure mode in
which doing a comparison on the value read by CAS should not correctly
diagnose success or failure (same as directly reading the Zero Flag) [1].

And yet, there's this discrepancy, where the modified casMutVar that I
linked to does not have the failure.  As for reproducing the failure,
either of the two following tests will currently show problems:

   - Two threads try to casIORef False->True, both succeed
   - 120 threads try to read, increment, CAS until they succeed.  The total
   is often not 120 because multiple threads think the successfully
   incremented, say, 33->34.

Here's a specific recipe for the latter test on GHC 7.6.3 Mac or Linux:


*git clone git at github.com:rrnewton/haskell-lockfree-queue.git *
*cd haskell-lockfree-queue/AtomicPrimops/*

*git checkout 1a1e7e55f6706f9e5754*

*cabal sandbox init*

*cabal install -f-withTH -fforeign ./ ./testing --enable-tests*

*./testing/dist/dist-sandbox-*/build/test-atomic-primops/test-atomic-primops
-t n_threads*

You may have to run the last line several times to see the failure.

Best,
  -Ryan

[1] I guess the __sync_bool_compare_and_swap intrinsic which reads ZF is
there just to avoid the extra comparison.

[2] P.S. I'd like to try this on GHC head, but the RHEL 6 machine I usually
use to build it is currently not validating (below error, commit
65d05d7334).  After I debug this gmp problem I'll confirm that the bug
under discussion applies on the 7.8 branch.

    ./sync-all checkout ghc-7.8
    sh validate
...
/usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32
against `__gmpz_sub' can not be used when making a shared object; recompile
with -fPIC
libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value




On Sat, Feb 1, 2014 at 2:55 AM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> Ryan, is your benchmark using CAS on pointers, or immediate words? trying
> to get atomic primops to build on my 7.8 build on my mac
>
>
> On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> https://ghc.haskell.org/trac/ghc/ticket/8724#ticket is the ticket
>>
>> when i'm more awake i'll experiment some more
>>
>>
>> On Sat, Feb 1, 2014 at 2:33 AM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> i have a ticket for tracking this, though i'm thinking my initial
>>> attempt at a patch generates the same object code as it did before.
>>>
>>> @ryan, what CPU variant are you testing this on? is this on a NUMA
>>> machine or something?
>>>
>>>
>>> On Sat, Feb 1, 2014 at 1:58 AM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> woops, i mean cmpxchgq
>>>>
>>>>
>>>> On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> ok, i can confirm that on my 64bit mac, both clang and gcc
>>>>> use cmpxchgl rather than cmpxchg
>>>>> i'll whip up a strawman patch on head that can be cherrypicked /
>>>>> tested out by ryan et al
>>>>>
>>>>>
>>>>> On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> Hey Ryan,
>>>>>> looking at this closely
>>>>>> Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could that be
>>>>>> the culprit?
>>>>>>
>>>>>> Could the issue be that we've not had a good stress test that would
>>>>>> create values that are equal on the 32bit range, but differ on the 64bit
>>>>>> range, and you're hitting that?
>>>>>>
>>>>>> Could you try seeing if doing that change fixes things up?
>>>>>> (I may be completely wrong, but just throwing this out as a naive
>>>>>> "obvious" guess)
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>>
>>>>>>> Then again... I'm having trouble seeing how the spec on page 3-149
>>>>>>> of the Intel manual would allow the behavior I'm seeing:
>>>>>>>
>>>>>>>
>>>>>>> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>>>>>>
>>>>>>> Nevertheless, this is exactly the behavior we're seeing with the
>>>>>>> current Haskell primops.  Two threads simultaneously performing the same
>>>>>>> CAS(p,a,b) can both think that they succeeded.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>>>
>>>>>>>> I commented on the commit here:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>>>>>>>
>>>>>>>> The problem is that our "cas" routine in SMP.h is similar to the C
>>>>>>>> compiler intrinsic __sync_val_compare_and_swap, in that it returns the old
>>>>>>>> value.  But it seems we cannot use a comparison against that old value to
>>>>>>>> determine whether or not the CAS succeeded.  (I believe the CAS may fail
>>>>>>>> due to contention, but the old value may happen to look like our old value.)
>>>>>>>>
>>>>>>>> Unfortunately, this didn't occur to me until it started causing
>>>>>>>> bugs [1] [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm
>>>>>>>> currently fixing CAS in the "atomic-primops" package is by using
>>>>>>>> __sync_bool_compare_and_swap:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>>>>>>>
>>>>>>>> What is the best fix for GHC itself?   Would it be ok for GHC to
>>>>>>>> include a C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise
>>>>>>>> we need another big ifdbef'd function like "cas" in SMP.h that has the
>>>>>>>> architecture-specific inline asm across all architectures.  I can write the
>>>>>>>> x86 one, but I'm not eager to try the others.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>    -Ryan
>>>>>>>>
>>>>>>>> [1] https://github.com/iu-parfunc/lvars/issues/70
>>>>>>>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ghc-devs mailing list
>>>>>>> ghc-devs at haskell.org
>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/715694dd/attachment.html>

From griba2001 at gmail.com  Sat Feb  1 15:23:34 2014
From: griba2001 at gmail.com (Gabriel Riba)
Date: Sat, 1 Feb 2014 15:23:34 +0000 (UTC)
Subject: TypeNats trial on new ghc branch 7.8
Message-ID: <loom.20140201T155932-521@post.gmane.org>

I know that the TypeNats solver may not have been merged with 7.8 branch

but the compiler error looks so simple:

Couldn't match type ?(n + m) - 1? with ?(n - 1) + m?

    ---------------------------------
    {-# LANGUAGE DataKinds, GADTs, KindSignatures, TypeOperators, PolyKinds, 
ExistentialQuantification #-} 

    import GHC.TypeLits

    data Vect :: Nat -> * -> * where 
      Nil ::  Vect 0 a
      Cons :: a -> Vect (n-1) a -> Vect n a

    data MyProxy (n::Nat) = forall a. MyProxy (Vect n a)

    toProxy :: Vect (n::Nat) a -> MyProxy n
    toProxy v = MyProxy v

    len :: KnownNat n => Vect (n::Nat) a -> Integer
    len v = (natVal . toProxy) v                         -- Ok

    append :: Vect n a -> Vect m a -> Vect (n+m) a
    append Nil ys = ys
    append (Cons x xs) ys = Cons x (append xs ys)  -- compiler error


    main = do
      print $ len Nil                          -- Ok
      print $ len (Cons (1::Int) Nil)          -- Ok 
    ------------------------------------------------------


Error on "append  (Cons x xs) ys = ..."

    Couldn't match type ?(n + m) - 1? with ?(n - 1) + m?
    Expected type: Vect ((n + m) - 1) a
      Actual type: Vect ((n - 1) + m) a




From christiaan.baaij at gmail.com  Sat Feb  1 15:52:03 2014
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Sat, 1 Feb 2014 16:52:03 +0100
Subject: TypeNats trial on new ghc branch 7.8
In-Reply-To: <loom.20140201T155932-521@post.gmane.org>
References: <loom.20140201T155932-521@post.gmane.org>
Message-ID: <CABzw7bW9kPcL2qf+ApFOrqo=TYFEYSSHJFNd-22V9PNh4=kq6Q@mail.gmail.com>

The "simplified" solver, as in
https://github.com/ghc/ghc/tree/type-nats-simple, has been integrated as
far as I know.
I've been experimenting with my own solver:
https://gist.github.com/christiaanb/8396614
Here are some examples of the stuff that works with my solver:
https://github.com/christiaanb/clash-prelude/blob/newnats/src/CLaSH/Sized/Vector.hs


On Sat, Feb 1, 2014 at 4:23 PM, Gabriel Riba <griba2001 at gmail.com> wrote:

> I know that the TypeNats solver may not have been merged with 7.8 branch
>
> but the compiler error looks so simple:
>
> Couldn't match type '(n + m) - 1' with '(n - 1) + m'
>
>     ---------------------------------
>     {-# LANGUAGE DataKinds, GADTs, KindSignatures, TypeOperators,
> PolyKinds,
> ExistentialQuantification #-}
>
>     import GHC.TypeLits
>
>     data Vect :: Nat -> * -> * where
>       Nil ::  Vect 0 a
>       Cons :: a -> Vect (n-1) a -> Vect n a
>
>     data MyProxy (n::Nat) = forall a. MyProxy (Vect n a)
>
>     toProxy :: Vect (n::Nat) a -> MyProxy n
>     toProxy v = MyProxy v
>
>     len :: KnownNat n => Vect (n::Nat) a -> Integer
>     len v = (natVal . toProxy) v                         -- Ok
>
>     append :: Vect n a -> Vect m a -> Vect (n+m) a
>     append Nil ys = ys
>     append (Cons x xs) ys = Cons x (append xs ys)  -- compiler error
>
>
>     main = do
>       print $ len Nil                          -- Ok
>       print $ len (Cons (1::Int) Nil)          -- Ok
>     ------------------------------------------------------
>
>
> Error on "append  (Cons x xs) ys = ..."
>
>     Couldn't match type '(n + m) - 1' with '(n - 1) + m'
>     Expected type: Vect ((n + m) - 1) a
>       Actual type: Vect ((n - 1) + m) a
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/a2c17792/attachment-0001.html>

From carter.schonwald at gmail.com  Sat Feb  1 16:03:43 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2014 11:03:43 -0500
Subject: TypeNats trial on new ghc branch 7.8
In-Reply-To: <CABzw7bW9kPcL2qf+ApFOrqo=TYFEYSSHJFNd-22V9PNh4=kq6Q@mail.gmail.com>
References: <loom.20140201T155932-521@post.gmane.org>
 <CABzw7bW9kPcL2qf+ApFOrqo=TYFEYSSHJFNd-22V9PNh4=kq6Q@mail.gmail.com>
Message-ID: <CAHYVw0zD-XuEFz0f1C-T0V=bJ31A7amSZhpnwwb2F9Weapg=+A@mail.gmail.com>

Hey Gabriel,
As far as I could determine, there is no solver powers in 7.8
the "solver" can simply just check that  (2 + 3 )~5 and other simple
"compute to get equality" situations


On Sat, Feb 1, 2014 at 10:52 AM, Christiaan Baaij <
christiaan.baaij at gmail.com> wrote:

> The "simplified" solver, as in
> https://github.com/ghc/ghc/tree/type-nats-simple, has been integrated as
> far as I know.
> I've been experimenting with my own solver:
> https://gist.github.com/christiaanb/8396614
> Here are some examples of the stuff that works with my solver:
> https://github.com/christiaanb/clash-prelude/blob/newnats/src/CLaSH/Sized/Vector.hs
>
>
> On Sat, Feb 1, 2014 at 4:23 PM, Gabriel Riba <griba2001 at gmail.com> wrote:
>
>> I know that the TypeNats solver may not have been merged with 7.8 branch
>>
>> but the compiler error looks so simple:
>>
>> Couldn't match type ?(n + m) - 1? with ?(n - 1) + m?
>>
>>     ---------------------------------
>>     {-# LANGUAGE DataKinds, GADTs, KindSignatures, TypeOperators,
>> PolyKinds,
>> ExistentialQuantification #-}
>>
>>     import GHC.TypeLits
>>
>>     data Vect :: Nat -> * -> * where
>>       Nil ::  Vect 0 a
>>       Cons :: a -> Vect (n-1) a -> Vect n a
>>
>>     data MyProxy (n::Nat) = forall a. MyProxy (Vect n a)
>>
>>     toProxy :: Vect (n::Nat) a -> MyProxy n
>>     toProxy v = MyProxy v
>>
>>     len :: KnownNat n => Vect (n::Nat) a -> Integer
>>     len v = (natVal . toProxy) v                         -- Ok
>>
>>     append :: Vect n a -> Vect m a -> Vect (n+m) a
>>     append Nil ys = ys
>>     append (Cons x xs) ys = Cons x (append xs ys)  -- compiler error
>>
>>
>>     main = do
>>       print $ len Nil                          -- Ok
>>       print $ len (Cons (1::Int) Nil)          -- Ok
>>     ------------------------------------------------------
>>
>>
>> Error on "append  (Cons x xs) ys = ..."
>>
>>     Couldn't match type ?(n + m) - 1? with ?(n - 1) + m?
>>     Expected type: Vect ((n + m) - 1) a
>>       Actual type: Vect ((n - 1) + m) a
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/f0a17508/attachment.html>

From carter.schonwald at gmail.com  Sat Feb  1 16:27:21 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2014 11:27:21 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CACYs5AY9uBXtmO5g4xmqsQb9Hb7vH+aiYPtNUbTs+dJjMcbk+w@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
 <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
 <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>
 <CAHYVw0zDuSLjJJexdOjusbyr=Q5o7OdDG65g8wdseZqq6QgayQ@mail.gmail.com>
 <CAHYVw0yRYUAfmpDbCzy2A3wSCUu5-gBN_RrJjkGvodZSznZR_w@mail.gmail.com>
 <CACYs5AY9uBXtmO5g4xmqsQb9Hb7vH+aiYPtNUbTs+dJjMcbk+w@mail.gmail.com>
Message-ID: <CAHYVw0yhzysUz=R0BLt_e8b929ey1qH-kL5hx0rVCAm0JWfW-w@mail.gmail.com>

Hey Ryan, i've made the leap to using 7.8 on my machine, so i'll first have
to get some pull requests in on atomic-primops before I can test it locally
:), expect those patches later today!

looks like gcc's inline ASM logic is pretty correct, after testing it a bit
locally, pardon my speculative jumping the gun.


On Sat, Feb 1, 2014 at 9:10 AM, Ryan Newton <rrnewton at gmail.com> wrote:

> Hi Carter & others,
>
> Carter, yes, this is CAS on pointers and in my next mail I'll try to come
> up with some hypotheses as to why we may have (remaining) problems there.
>
> But first, I have been assured that on x86 there is no failure mode in
> which doing a comparison on the value read by CAS should not correctly
> diagnose success or failure (same as directly reading the Zero Flag) [1].
>
> And yet, there's this discrepancy, where the modified casMutVar that I
> linked to does not have the failure.  As for reproducing the failure,
> either of the two following tests will currently show problems:
>
>    - Two threads try to casIORef False->True, both succeed
>    - 120 threads try to read, increment, CAS until they succeed.  The
>    total is often not 120 because multiple threads think the successfully
>    incremented, say, 33->34.
>
> Here's a specific recipe for the latter test on GHC 7.6.3 Mac or Linux:
>
>
> *git clone git at github.com:rrnewton/haskell-lockfree-queue.git *
> *cd haskell-lockfree-queue/AtomicPrimops/*
>
> *git checkout 1a1e7e55f6706f9e5754*
>
> *cabal sandbox init*
>
> *cabal install -f-withTH -fforeign ./ ./testing --enable-tests*
>
> *./testing/dist/dist-sandbox-*/build/test-atomic-primops/test-atomic-primops
> -t n_threads*
>
> You may have to run the last line several times to see the failure.
>
> Best,
>   -Ryan
>
> [1] I guess the __sync_bool_compare_and_swap intrinsic which reads ZF is
> there just to avoid the extra comparison.
>
> [2] P.S. I'd like to try this on GHC head, but the RHEL 6 machine I
> usually use to build it is currently not validating (below error, commit
> 65d05d7334).  After I debug this gmp problem I'll confirm that the bug
> under discussion applies on the 7.8 branch.
>
>     ./sync-all checkout ghc-7.8
>     sh validate
> ...
> /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32
> against `__gmpz_sub' can not be used when making a shared object; recompile
> with -fPIC
> libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value
>
>
>
>
> On Sat, Feb 1, 2014 at 2:55 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> Ryan, is your benchmark using CAS on pointers, or immediate words? trying
>> to get atomic primops to build on my 7.8 build on my mac
>>
>>
>> On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> https://ghc.haskell.org/trac/ghc/ticket/8724#ticket is the ticket
>>>
>>> when i'm more awake i'll experiment some more
>>>
>>>
>>> On Sat, Feb 1, 2014 at 2:33 AM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> i have a ticket for tracking this, though i'm thinking my initial
>>>> attempt at a patch generates the same object code as it did before.
>>>>
>>>> @ryan, what CPU variant are you testing this on? is this on a NUMA
>>>> machine or something?
>>>>
>>>>
>>>> On Sat, Feb 1, 2014 at 1:58 AM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> woops, i mean cmpxchgq
>>>>>
>>>>>
>>>>> On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> ok, i can confirm that on my 64bit mac, both clang and gcc
>>>>>> use cmpxchgl rather than cmpxchg
>>>>>> i'll whip up a strawman patch on head that can be cherrypicked /
>>>>>> tested out by ryan et al
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <
>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>
>>>>>>> Hey Ryan,
>>>>>>> looking at this closely
>>>>>>> Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could that be
>>>>>>> the culprit?
>>>>>>>
>>>>>>> Could the issue be that we've not had a good stress test that would
>>>>>>> create values that are equal on the 32bit range, but differ on the 64bit
>>>>>>> range, and you're hitting that?
>>>>>>>
>>>>>>> Could you try seeing if doing that change fixes things up?
>>>>>>> (I may be completely wrong, but just throwing this out as a naive
>>>>>>> "obvious" guess)
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>>>
>>>>>>>> Then again... I'm having trouble seeing how the spec on page 3-149
>>>>>>>> of the Intel manual would allow the behavior I'm seeing:
>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>>>>>>>
>>>>>>>> Nevertheless, this is exactly the behavior we're seeing with the
>>>>>>>> current Haskell primops.  Two threads simultaneously performing the same
>>>>>>>> CAS(p,a,b) can both think that they succeeded.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>>>>
>>>>>>>>> I commented on the commit here:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>>>>>>>>
>>>>>>>>> The problem is that our "cas" routine in SMP.h is similar to the C
>>>>>>>>> compiler intrinsic __sync_val_compare_and_swap, in that it returns the old
>>>>>>>>> value.  But it seems we cannot use a comparison against that old value to
>>>>>>>>> determine whether or not the CAS succeeded.  (I believe the CAS may fail
>>>>>>>>> due to contention, but the old value may happen to look like our old value.)
>>>>>>>>>
>>>>>>>>> Unfortunately, this didn't occur to me until it started causing
>>>>>>>>> bugs [1] [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm
>>>>>>>>> currently fixing CAS in the "atomic-primops" package is by using
>>>>>>>>> __sync_bool_compare_and_swap:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>>>>>>>>
>>>>>>>>> What is the best fix for GHC itself?   Would it be ok for GHC to
>>>>>>>>> include a C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise
>>>>>>>>> we need another big ifdbef'd function like "cas" in SMP.h that has the
>>>>>>>>> architecture-specific inline asm across all architectures.  I can write the
>>>>>>>>> x86 one, but I'm not eager to try the others.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>    -Ryan
>>>>>>>>>
>>>>>>>>> [1] https://github.com/iu-parfunc/lvars/issues/70
>>>>>>>>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> ghc-devs mailing list
>>>>>>>> ghc-devs at haskell.org
>>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/98b74a1c/attachment-0001.html>

From rrnewton at gmail.com  Sat Feb  1 17:52:46 2014
From: rrnewton at gmail.com (Ryan Newton)
Date: Sat, 1 Feb 2014 12:52:46 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CAHYVw0yhzysUz=R0BLt_e8b929ey1qH-kL5hx0rVCAm0JWfW-w@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
 <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
 <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>
 <CAHYVw0zDuSLjJJexdOjusbyr=Q5o7OdDG65g8wdseZqq6QgayQ@mail.gmail.com>
 <CAHYVw0yRYUAfmpDbCzy2A3wSCUu5-gBN_RrJjkGvodZSznZR_w@mail.gmail.com>
 <CACYs5AY9uBXtmO5g4xmqsQb9Hb7vH+aiYPtNUbTs+dJjMcbk+w@mail.gmail.com>
 <CAHYVw0yhzysUz=R0BLt_e8b929ey1qH-kL5hx0rVCAm0JWfW-w@mail.gmail.com>
Message-ID: <CACYs5AZuc_6T+AGZFx_644XVGjC5x_6-PySWcyZhTUpUyE0qQw@mail.gmail.com>

Ok, here's another experiment, on this commit:


https://github.com/rrnewton/haskell-lockfree/commit/399bb19fa02eaf2f2eab5d02c4b608535362f9bc

Here, if I use GCC's __sync_val_compare_and_swap instead of GHC's version
of cas(), the problem also goes away.  I think these two implementations
should behave identically, and that they don't perhaps indicates that there
is something off about the inline asm, as Carter was suggesting:

*#if i386_HOST_ARCH || x86_64_HOST_ARCH*
*    __asm__ __volatile__ (*
*   "lock\ncmpxchg %3,%1"*
*          :"=a"(o), "=m" (*(volatile unsigned int *)p) *
*          :"0" (o), "r" (n));*
*    return o;*

The x86 CAS instruction must put the "return value" in the accumulator
register, and indeed this constrains "o" to be allocated to the accumulator
register, while the new value "n" can be in any register.

So if there's a problem, I don't know what it is.  Except I'm not sure what
the ramifications of "o" being a function parameter AND having an "=a"
constraint on it are...

   -Ryan



On Sat, Feb 1, 2014 at 11:27 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Hey Ryan, i've made the leap to using 7.8 on my machine, so i'll first
> have to get some pull requests in on atomic-primops before I can test it
> locally :), expect those patches later today!
>
> looks like gcc's inline ASM logic is pretty correct, after testing it a
> bit locally, pardon my speculative jumping the gun.
>
>
> On Sat, Feb 1, 2014 at 9:10 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>
>> Hi Carter & others,
>>
>> Carter, yes, this is CAS on pointers and in my next mail I'll try to come
>> up with some hypotheses as to why we may have (remaining) problems there.
>>
>> But first, I have been assured that on x86 there is no failure mode in
>> which doing a comparison on the value read by CAS should not correctly
>> diagnose success or failure (same as directly reading the Zero Flag) [1].
>>
>> And yet, there's this discrepancy, where the modified casMutVar that I
>> linked to does not have the failure.  As for reproducing the failure,
>> either of the two following tests will currently show problems:
>>
>>    - Two threads try to casIORef False->True, both succeed
>>    - 120 threads try to read, increment, CAS until they succeed.  The
>>    total is often not 120 because multiple threads think the successfully
>>    incremented, say, 33->34.
>>
>> Here's a specific recipe for the latter test on GHC 7.6.3 Mac or Linux:
>>
>>
>> *git clone git at github.com:rrnewton/haskell-lockfree-queue.git *
>> *cd haskell-lockfree-queue/AtomicPrimops/*
>>
>> *git checkout 1a1e7e55f6706f9e5754*
>>
>> *cabal sandbox init*
>>
>> *cabal install -f-withTH -fforeign ./ ./testing --enable-tests*
>>
>> *./testing/dist/dist-sandbox-*/build/test-atomic-primops/test-atomic-primops
>> -t n_threads*
>>
>> You may have to run the last line several times to see the failure.
>>
>> Best,
>>   -Ryan
>>
>> [1] I guess the __sync_bool_compare_and_swap intrinsic which reads ZF is
>> there just to avoid the extra comparison.
>>
>> [2] P.S. I'd like to try this on GHC head, but the RHEL 6 machine I
>> usually use to build it is currently not validating (below error, commit
>> 65d05d7334).  After I debug this gmp problem I'll confirm that the bug
>> under discussion applies on the 7.8 branch.
>>
>>     ./sync-all checkout ghc-7.8
>>     sh validate
>> ...
>> /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation
>> R_X86_64_32 against `__gmpz_sub' can not be used when making a shared
>> object; recompile with -fPIC
>> libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value
>>
>>
>>
>>
>> On Sat, Feb 1, 2014 at 2:55 AM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> Ryan, is your benchmark using CAS on pointers, or immediate words?
>>> trying to get atomic primops to build on my 7.8 build on my mac
>>>
>>>
>>> On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> https://ghc.haskell.org/trac/ghc/ticket/8724#ticket is the ticket
>>>>
>>>> when i'm more awake i'll experiment some more
>>>>
>>>>
>>>> On Sat, Feb 1, 2014 at 2:33 AM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> i have a ticket for tracking this, though i'm thinking my initial
>>>>> attempt at a patch generates the same object code as it did before.
>>>>>
>>>>> @ryan, what CPU variant are you testing this on? is this on a NUMA
>>>>> machine or something?
>>>>>
>>>>>
>>>>> On Sat, Feb 1, 2014 at 1:58 AM, Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> woops, i mean cmpxchgq
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald <
>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>
>>>>>>> ok, i can confirm that on my 64bit mac, both clang and gcc
>>>>>>> use cmpxchgl rather than cmpxchg
>>>>>>> i'll whip up a strawman patch on head that can be cherrypicked /
>>>>>>> tested out by ryan et al
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <
>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hey Ryan,
>>>>>>>> looking at this closely
>>>>>>>> Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could that
>>>>>>>> be the culprit?
>>>>>>>>
>>>>>>>> Could the issue be that we've not had a good stress test that would
>>>>>>>> create values that are equal on the 32bit range, but differ on the 64bit
>>>>>>>> range, and you're hitting that?
>>>>>>>>
>>>>>>>> Could you try seeing if doing that change fixes things up?
>>>>>>>> (I may be completely wrong, but just throwing this out as a naive
>>>>>>>> "obvious" guess)
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>>>>
>>>>>>>>> Then again... I'm having trouble seeing how the spec on page 3-149
>>>>>>>>> of the Intel manual would allow the behavior I'm seeing:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>>>>>>>>
>>>>>>>>> Nevertheless, this is exactly the behavior we're seeing with the
>>>>>>>>> current Haskell primops.  Two threads simultaneously performing the same
>>>>>>>>> CAS(p,a,b) can both think that they succeeded.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>>>>>
>>>>>>>>>> I commented on the commit here:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>>>>>>>>>
>>>>>>>>>> The problem is that our "cas" routine in SMP.h is similar to the
>>>>>>>>>> C compiler intrinsic __sync_val_compare_and_swap, in that it returns the
>>>>>>>>>> old value.  But it seems we cannot use a comparison against that old value
>>>>>>>>>> to determine whether or not the CAS succeeded.  (I believe the CAS may fail
>>>>>>>>>> due to contention, but the old value may happen to look like our old value.)
>>>>>>>>>>
>>>>>>>>>> Unfortunately, this didn't occur to me until it started causing
>>>>>>>>>> bugs [1] [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm
>>>>>>>>>> currently fixing CAS in the "atomic-primops" package is by using
>>>>>>>>>> __sync_bool_compare_and_swap:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>>>>>>>>>
>>>>>>>>>> What is the best fix for GHC itself?   Would it be ok for GHC to
>>>>>>>>>> include a C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise
>>>>>>>>>> we need another big ifdbef'd function like "cas" in SMP.h that has the
>>>>>>>>>> architecture-specific inline asm across all architectures.  I can write the
>>>>>>>>>> x86 one, but I'm not eager to try the others.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>>    -Ryan
>>>>>>>>>>
>>>>>>>>>> [1] https://github.com/iu-parfunc/lvars/issues/70
>>>>>>>>>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ghc-devs mailing list
>>>>>>>>> ghc-devs at haskell.org
>>>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/57c9523a/attachment.html>

From carter.schonwald at gmail.com  Sat Feb  1 18:03:50 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2014 13:03:50 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CACYs5AZuc_6T+AGZFx_644XVGjC5x_6-PySWcyZhTUpUyE0qQw@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
 <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
 <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>
 <CAHYVw0zDuSLjJJexdOjusbyr=Q5o7OdDG65g8wdseZqq6QgayQ@mail.gmail.com>
 <CAHYVw0yRYUAfmpDbCzy2A3wSCUu5-gBN_RrJjkGvodZSznZR_w@mail.gmail.com>
 <CACYs5AY9uBXtmO5g4xmqsQb9Hb7vH+aiYPtNUbTs+dJjMcbk+w@mail.gmail.com>
 <CAHYVw0yhzysUz=R0BLt_e8b929ey1qH-kL5hx0rVCAm0JWfW-w@mail.gmail.com>
 <CACYs5AZuc_6T+AGZFx_644XVGjC5x_6-PySWcyZhTUpUyE0qQw@mail.gmail.com>
Message-ID: <CAHYVw0w92JPqsqEtF9FX_NP=aDsSvadsTH32ii4WGiFeX=dO+Q@mail.gmail.com>

hrmmmm I have a crazy idea

"Compare RAX with r/m64. If equal, ZF is set and r64 is loaded into r/m64.
Else, clear ZF
and load r/m64 into RAX." is what the docs say for the cmpxchng instruction

so RAX is the old values,  (EAX in the  32bit case). And it looks like we
dont' set that explicitly when calling the asm .. CMPXCHG r/m64, r64

 hrmmm



On Sat, Feb 1, 2014 at 12:52 PM, Ryan Newton <rrnewton at gmail.com> wrote:

> Ok, here's another experiment, on this commit:
>
>
> https://github.com/rrnewton/haskell-lockfree/commit/399bb19fa02eaf2f2eab5d02c4b608535362f9bc
>
> Here, if I use GCC's __sync_val_compare_and_swap instead of GHC's version
> of cas(), the problem also goes away.  I think these two implementations
> should behave identically, and that they don't perhaps indicates that there
> is something off about the inline asm, as Carter was suggesting:
>
> *#if i386_HOST_ARCH || x86_64_HOST_ARCH*
> *    __asm__ __volatile__ (*
> *   "lock\ncmpxchg %3,%1"*
> *          :"=a"(o), "=m" (*(volatile unsigned int *)p) *
> *          :"0" (o), "r" (n));*
> *    return o;*
>
> The x86 CAS instruction must put the "return value" in the accumulator
> register, and indeed this constrains "o" to be allocated to the accumulator
> register, while the new value "n" can be in any register.
>
> So if there's a problem, I don't know what it is.  Except I'm not sure
> what the ramifications of "o" being a function parameter AND having an "=a"
> constraint on it are...
>
>    -Ryan
>
>
>
> On Sat, Feb 1, 2014 at 11:27 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> Hey Ryan, i've made the leap to using 7.8 on my machine, so i'll first
>> have to get some pull requests in on atomic-primops before I can test it
>> locally :), expect those patches later today!
>>
>> looks like gcc's inline ASM logic is pretty correct, after testing it a
>> bit locally, pardon my speculative jumping the gun.
>>
>>
>> On Sat, Feb 1, 2014 at 9:10 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>
>>> Hi Carter & others,
>>>
>>> Carter, yes, this is CAS on pointers and in my next mail I'll try to
>>> come up with some hypotheses as to why we may have (remaining) problems
>>> there.
>>>
>>> But first, I have been assured that on x86 there is no failure mode in
>>> which doing a comparison on the value read by CAS should not correctly
>>> diagnose success or failure (same as directly reading the Zero Flag) [1].
>>>
>>> And yet, there's this discrepancy, where the modified casMutVar that I
>>> linked to does not have the failure.  As for reproducing the failure,
>>> either of the two following tests will currently show problems:
>>>
>>>    - Two threads try to casIORef False->True, both succeed
>>>    - 120 threads try to read, increment, CAS until they succeed.  The
>>>    total is often not 120 because multiple threads think the successfully
>>>    incremented, say, 33->34.
>>>
>>> Here's a specific recipe for the latter test on GHC 7.6.3 Mac or Linux:
>>>
>>>
>>> *git clone git at github.com:rrnewton/haskell-lockfree-queue.git *
>>> *cd haskell-lockfree-queue/AtomicPrimops/*
>>>
>>> *git checkout 1a1e7e55f6706f9e5754*
>>>
>>> *cabal sandbox init*
>>>
>>> *cabal install -f-withTH -fforeign ./ ./testing --enable-tests*
>>>
>>> *./testing/dist/dist-sandbox-*/build/test-atomic-primops/test-atomic-primops
>>> -t n_threads*
>>>
>>> You may have to run the last line several times to see the failure.
>>>
>>> Best,
>>>   -Ryan
>>>
>>> [1] I guess the __sync_bool_compare_and_swap intrinsic which reads ZF is
>>> there just to avoid the extra comparison.
>>>
>>> [2] P.S. I'd like to try this on GHC head, but the RHEL 6 machine I
>>> usually use to build it is currently not validating (below error, commit
>>> 65d05d7334).  After I debug this gmp problem I'll confirm that the bug
>>> under discussion applies on the 7.8 branch.
>>>
>>>     ./sync-all checkout ghc-7.8
>>>     sh validate
>>> ...
>>> /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation
>>> R_X86_64_32 against `__gmpz_sub' can not be used when making a shared
>>> object; recompile with -fPIC
>>> libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value
>>>
>>>
>>>
>>>
>>> On Sat, Feb 1, 2014 at 2:55 AM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> Ryan, is your benchmark using CAS on pointers, or immediate words?
>>>> trying to get atomic primops to build on my 7.8 build on my mac
>>>>
>>>>
>>>> On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> https://ghc.haskell.org/trac/ghc/ticket/8724#ticket is the ticket
>>>>>
>>>>> when i'm more awake i'll experiment some more
>>>>>
>>>>>
>>>>> On Sat, Feb 1, 2014 at 2:33 AM, Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> i have a ticket for tracking this, though i'm thinking my initial
>>>>>> attempt at a patch generates the same object code as it did before.
>>>>>>
>>>>>> @ryan, what CPU variant are you testing this on? is this on a NUMA
>>>>>> machine or something?
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 1, 2014 at 1:58 AM, Carter Schonwald <
>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>
>>>>>>> woops, i mean cmpxchgq
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald <
>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>
>>>>>>>> ok, i can confirm that on my 64bit mac, both clang and gcc
>>>>>>>> use cmpxchgl rather than cmpxchg
>>>>>>>> i'll whip up a strawman patch on head that can be cherrypicked /
>>>>>>>> tested out by ryan et al
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <
>>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hey Ryan,
>>>>>>>>> looking at this closely
>>>>>>>>> Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could that
>>>>>>>>> be the culprit?
>>>>>>>>>
>>>>>>>>> Could the issue be that we've not had a good stress test that
>>>>>>>>> would create values that are equal on the 32bit range, but differ on the
>>>>>>>>> 64bit range, and you're hitting that?
>>>>>>>>>
>>>>>>>>> Could you try seeing if doing that change fixes things up?
>>>>>>>>> (I may be completely wrong, but just throwing this out as a naive
>>>>>>>>> "obvious" guess)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>>>>>
>>>>>>>>>> Then again... I'm having trouble seeing how the spec on page
>>>>>>>>>> 3-149 of the Intel manual would allow the behavior I'm seeing:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>>>>>>>>>
>>>>>>>>>> Nevertheless, this is exactly the behavior we're seeing with the
>>>>>>>>>> current Haskell primops.  Two threads simultaneously performing the same
>>>>>>>>>> CAS(p,a,b) can both think that they succeeded.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>>>>>>
>>>>>>>>>>> I commented on the commit here:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>>>>>>>>>>
>>>>>>>>>>> The problem is that our "cas" routine in SMP.h is similar to the
>>>>>>>>>>> C compiler intrinsic __sync_val_compare_and_swap, in that it returns the
>>>>>>>>>>> old value.  But it seems we cannot use a comparison against that old value
>>>>>>>>>>> to determine whether or not the CAS succeeded.  (I believe the CAS may fail
>>>>>>>>>>> due to contention, but the old value may happen to look like our old value.)
>>>>>>>>>>>
>>>>>>>>>>> Unfortunately, this didn't occur to me until it started causing
>>>>>>>>>>> bugs [1] [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm
>>>>>>>>>>> currently fixing CAS in the "atomic-primops" package is by using
>>>>>>>>>>> __sync_bool_compare_and_swap:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>>>>>>>>>>
>>>>>>>>>>> What is the best fix for GHC itself?   Would it be ok for GHC to
>>>>>>>>>>> include a C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise
>>>>>>>>>>> we need another big ifdbef'd function like "cas" in SMP.h that has the
>>>>>>>>>>> architecture-specific inline asm across all architectures.  I can write the
>>>>>>>>>>> x86 one, but I'm not eager to try the others.
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>>    -Ryan
>>>>>>>>>>>
>>>>>>>>>>> [1] https://github.com/iu-parfunc/lvars/issues/70
>>>>>>>>>>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> ghc-devs mailing list
>>>>>>>>>> ghc-devs at haskell.org
>>>>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/b908e973/attachment-0001.html>

From carter.schonwald at gmail.com  Sat Feb  1 19:17:13 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 1 Feb 2014 14:17:13 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CAHYVw0w92JPqsqEtF9FX_NP=aDsSvadsTH32ii4WGiFeX=dO+Q@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
 <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
 <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>
 <CAHYVw0zDuSLjJJexdOjusbyr=Q5o7OdDG65g8wdseZqq6QgayQ@mail.gmail.com>
 <CAHYVw0yRYUAfmpDbCzy2A3wSCUu5-gBN_RrJjkGvodZSznZR_w@mail.gmail.com>
 <CACYs5AY9uBXtmO5g4xmqsQb9Hb7vH+aiYPtNUbTs+dJjMcbk+w@mail.gmail.com>
 <CAHYVw0yhzysUz=R0BLt_e8b929ey1qH-kL5hx0rVCAm0JWfW-w@mail.gmail.com>
 <CACYs5AZuc_6T+AGZFx_644XVGjC5x_6-PySWcyZhTUpUyE0qQw@mail.gmail.com>
 <CAHYVw0w92JPqsqEtF9FX_NP=aDsSvadsTH32ii4WGiFeX=dO+Q@mail.gmail.com>
Message-ID: <CAHYVw0ze5zCmNb6HaSA0VX4tOAuXNJPTwNN3p6caRiwUs_ccXA@mail.gmail.com>

I got the test suite running on my (2 core) machine mac book air, with 7.8
i've run it several times, not seeing any failures


On Sat, Feb 1, 2014 at 1:03 PM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> hrmmmm I have a crazy idea
>
> "Compare RAX with r/m64. If equal, ZF is set and r64 is loaded into r/m64.
> Else, clear ZF
> and load r/m64 into RAX." is what the docs say for the cmpxchng
> instruction
>
> so RAX is the old values,  (EAX in the  32bit case). And it looks like we
> dont' set that explicitly when calling the asm .. CMPXCHG r/m64, r64
>
>  hrmmm
>
>
>
> On Sat, Feb 1, 2014 at 12:52 PM, Ryan Newton <rrnewton at gmail.com> wrote:
>
>> Ok, here's another experiment, on this commit:
>>
>>
>> https://github.com/rrnewton/haskell-lockfree/commit/399bb19fa02eaf2f2eab5d02c4b608535362f9bc
>>
>> Here, if I use GCC's __sync_val_compare_and_swap instead of GHC's version
>> of cas(), the problem also goes away.  I think these two implementations
>> should behave identically, and that they don't perhaps indicates that there
>> is something off about the inline asm, as Carter was suggesting:
>>
>> *#if i386_HOST_ARCH || x86_64_HOST_ARCH*
>> *    __asm__ __volatile__ (*
>> *   "lock\ncmpxchg %3,%1"*
>> *          :"=a"(o), "=m" (*(volatile unsigned int *)p) *
>> *          :"0" (o), "r" (n));*
>> *    return o;*
>>
>> The x86 CAS instruction must put the "return value" in the accumulator
>> register, and indeed this constrains "o" to be allocated to the accumulator
>> register, while the new value "n" can be in any register.
>>
>> So if there's a problem, I don't know what it is.  Except I'm not sure
>> what the ramifications of "o" being a function parameter AND having an "=a"
>> constraint on it are...
>>
>>    -Ryan
>>
>>
>>
>> On Sat, Feb 1, 2014 at 11:27 AM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> Hey Ryan, i've made the leap to using 7.8 on my machine, so i'll first
>>> have to get some pull requests in on atomic-primops before I can test it
>>> locally :), expect those patches later today!
>>>
>>> looks like gcc's inline ASM logic is pretty correct, after testing it a
>>> bit locally, pardon my speculative jumping the gun.
>>>
>>>
>>> On Sat, Feb 1, 2014 at 9:10 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>>
>>>> Hi Carter & others,
>>>>
>>>> Carter, yes, this is CAS on pointers and in my next mail I'll try to
>>>> come up with some hypotheses as to why we may have (remaining) problems
>>>> there.
>>>>
>>>> But first, I have been assured that on x86 there is no failure mode in
>>>> which doing a comparison on the value read by CAS should not correctly
>>>> diagnose success or failure (same as directly reading the Zero Flag) [1].
>>>>
>>>> And yet, there's this discrepancy, where the modified casMutVar that I
>>>> linked to does not have the failure.  As for reproducing the failure,
>>>> either of the two following tests will currently show problems:
>>>>
>>>>    - Two threads try to casIORef False->True, both succeed
>>>>    - 120 threads try to read, increment, CAS until they succeed.  The
>>>>    total is often not 120 because multiple threads think the successfully
>>>>    incremented, say, 33->34.
>>>>
>>>> Here's a specific recipe for the latter test on GHC 7.6.3 Mac or Linux:
>>>>
>>>>
>>>> *git clone git at github.com:rrnewton/haskell-lockfree-queue.git *
>>>> *cd haskell-lockfree-queue/AtomicPrimops/*
>>>>
>>>> *git checkout 1a1e7e55f6706f9e5754*
>>>>
>>>> *cabal sandbox init*
>>>>
>>>> *cabal install -f-withTH -fforeign ./ ./testing --enable-tests*
>>>>
>>>> *./testing/dist/dist-sandbox-*/build/test-atomic-primops/test-atomic-primops
>>>> -t n_threads*
>>>>
>>>> You may have to run the last line several times to see the failure.
>>>>
>>>> Best,
>>>>   -Ryan
>>>>
>>>> [1] I guess the __sync_bool_compare_and_swap intrinsic which reads ZF
>>>> is there just to avoid the extra comparison.
>>>>
>>>> [2] P.S. I'd like to try this on GHC head, but the RHEL 6 machine I
>>>> usually use to build it is currently not validating (below error, commit
>>>> 65d05d7334).  After I debug this gmp problem I'll confirm that the bug
>>>> under discussion applies on the 7.8 branch.
>>>>
>>>>     ./sync-all checkout ghc-7.8
>>>>     sh validate
>>>> ...
>>>> /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation
>>>> R_X86_64_32 against `__gmpz_sub' can not be used when making a shared
>>>> object; recompile with -fPIC
>>>> libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Feb 1, 2014 at 2:55 AM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> Ryan, is your benchmark using CAS on pointers, or immediate words?
>>>>> trying to get atomic primops to build on my 7.8 build on my mac
>>>>>
>>>>>
>>>>> On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> https://ghc.haskell.org/trac/ghc/ticket/8724#ticket is the ticket
>>>>>>
>>>>>> when i'm more awake i'll experiment some more
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 1, 2014 at 2:33 AM, Carter Schonwald <
>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>
>>>>>>> i have a ticket for tracking this, though i'm thinking my initial
>>>>>>> attempt at a patch generates the same object code as it did before.
>>>>>>>
>>>>>>> @ryan, what CPU variant are you testing this on? is this on a NUMA
>>>>>>> machine or something?
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Feb 1, 2014 at 1:58 AM, Carter Schonwald <
>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>
>>>>>>>> woops, i mean cmpxchgq
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald <
>>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> ok, i can confirm that on my 64bit mac, both clang and gcc
>>>>>>>>> use cmpxchgl rather than cmpxchg
>>>>>>>>> i'll whip up a strawman patch on head that can be cherrypicked /
>>>>>>>>> tested out by ryan et al
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <
>>>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hey Ryan,
>>>>>>>>>> looking at this closely
>>>>>>>>>> Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could that
>>>>>>>>>> be the culprit?
>>>>>>>>>>
>>>>>>>>>> Could the issue be that we've not had a good stress test that
>>>>>>>>>> would create values that are equal on the 32bit range, but differ on the
>>>>>>>>>> 64bit range, and you're hitting that?
>>>>>>>>>>
>>>>>>>>>> Could you try seeing if doing that change fixes things up?
>>>>>>>>>> (I may be completely wrong, but just throwing this out as a naive
>>>>>>>>>> "obvious" guess)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>>>>>>>
>>>>>>>>>>> Then again... I'm having trouble seeing how the spec on page
>>>>>>>>>>> 3-149 of the Intel manual would allow the behavior I'm seeing:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>>>>>>>>>>
>>>>>>>>>>> Nevertheless, this is exactly the behavior we're seeing with the
>>>>>>>>>>> current Haskell primops.  Two threads simultaneously performing the same
>>>>>>>>>>> CAS(p,a,b) can both think that they succeeded.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <rrnewton at gmail.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I commented on the commit here:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>>>>>>>>>>>
>>>>>>>>>>>> The problem is that our "cas" routine in SMP.h is similar to
>>>>>>>>>>>> the C compiler intrinsic __sync_val_compare_and_swap, in that it returns
>>>>>>>>>>>> the old value.  But it seems we cannot use a comparison against that old
>>>>>>>>>>>> value to determine whether or not the CAS succeeded.  (I believe the CAS
>>>>>>>>>>>> may fail due to contention, but the old value may happen to look like our
>>>>>>>>>>>> old value.)
>>>>>>>>>>>>
>>>>>>>>>>>> Unfortunately, this didn't occur to me until it started causing
>>>>>>>>>>>> bugs [1] [2].  Fixing casMutVar# fixes these bugs.  However, the way I'm
>>>>>>>>>>>> currently fixing CAS in the "atomic-primops" package is by using
>>>>>>>>>>>> __sync_bool_compare_and_swap:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>>>>>>>>>>>
>>>>>>>>>>>> What is the best fix for GHC itself?   Would it be ok for GHC
>>>>>>>>>>>> to include a C compiler intrinsic like __sync_val_compare_and_swap?
>>>>>>>>>>>>  Otherwise we need another big ifdbef'd function like "cas" in SMP.h that
>>>>>>>>>>>> has the architecture-specific inline asm across all architectures.  I can
>>>>>>>>>>>> write the x86 one, but I'm not eager to try the others.
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>>    -Ryan
>>>>>>>>>>>>
>>>>>>>>>>>> [1] https://github.com/iu-parfunc/lvars/issues/70
>>>>>>>>>>>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> ghc-devs mailing list
>>>>>>>>>>> ghc-devs at haskell.org
>>>>>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/f3a0af14/attachment.html>

From rrnewton at gmail.com  Sat Feb  1 19:35:54 2014
From: rrnewton at gmail.com (Ryan Newton)
Date: Sat, 1 Feb 2014 14:35:54 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CAHYVw0ze5zCmNb6HaSA0VX4tOAuXNJPTwNN3p6caRiwUs_ccXA@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
 <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
 <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>
 <CAHYVw0zDuSLjJJexdOjusbyr=Q5o7OdDG65g8wdseZqq6QgayQ@mail.gmail.com>
 <CAHYVw0yRYUAfmpDbCzy2A3wSCUu5-gBN_RrJjkGvodZSznZR_w@mail.gmail.com>
 <CACYs5AY9uBXtmO5g4xmqsQb9Hb7vH+aiYPtNUbTs+dJjMcbk+w@mail.gmail.com>
 <CAHYVw0yhzysUz=R0BLt_e8b929ey1qH-kL5hx0rVCAm0JWfW-w@mail.gmail.com>
 <CACYs5AZuc_6T+AGZFx_644XVGjC5x_6-PySWcyZhTUpUyE0qQw@mail.gmail.com>
 <CAHYVw0w92JPqsqEtF9FX_NP=aDsSvadsTH32ii4WGiFeX=dO+Q@mail.gmail.com>
 <CAHYVw0ze5zCmNb6HaSA0VX4tOAuXNJPTwNN3p6caRiwUs_ccXA@mail.gmail.com>
Message-ID: <CACYs5AaaAuS4e=kwMqB6vNnbLfBSTy1+Kjkbgm_Vz2Feg65rZQ@mail.gmail.com>

Ok, my bad, sorry all.

This is NOT a problem that will crop up in 7.8.   Rather, it's just a
problem with the duplicated bits of GHC RTS functionality that were stuck
into the atomic-primops library.  It was a C preprocessor problem that was
causing the inline asm we were discussing in this thread to not actually be
called.

Still, I'd like to be reminded of the rational for all this conditional
inline asm rather than using the C compiler intrinsics!  Anyone?

Best,
  -Ryan



On Sat, Feb 1, 2014 at 2:17 PM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> I got the test suite running on my (2 core) machine mac book air, with 7.8
> i've run it several times, not seeing any failures
>
>
> On Sat, Feb 1, 2014 at 1:03 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> hrmmmm I have a crazy idea
>>
>> "Compare RAX with r/m64. If equal, ZF is set and r64 is loaded into r/m64.
>> Else, clear ZF
>> and load r/m64 into RAX." is what the docs say for the cmpxchng
>> instruction
>>
>> so RAX is the old values,  (EAX in the  32bit case). And it looks like we
>> dont' set that explicitly when calling the asm .. CMPXCHG r/m64, r64
>>
>>  hrmmm
>>
>>
>>
>> On Sat, Feb 1, 2014 at 12:52 PM, Ryan Newton <rrnewton at gmail.com> wrote:
>>
>>> Ok, here's another experiment, on this commit:
>>>
>>>
>>> https://github.com/rrnewton/haskell-lockfree/commit/399bb19fa02eaf2f2eab5d02c4b608535362f9bc
>>>
>>> Here, if I use GCC's __sync_val_compare_and_swap instead of GHC's
>>> version of cas(), the problem also goes away.  I think these two
>>> implementations should behave identically, and that they don't perhaps
>>> indicates that there is something off about the inline asm, as Carter was
>>> suggesting:
>>>
>>> *#if i386_HOST_ARCH || x86_64_HOST_ARCH*
>>> *    __asm__ __volatile__ (*
>>> *   "lock\ncmpxchg %3,%1"*
>>> *          :"=a"(o), "=m" (*(volatile unsigned int *)p) *
>>> *          :"0" (o), "r" (n));*
>>> *    return o;*
>>>
>>> The x86 CAS instruction must put the "return value" in the accumulator
>>> register, and indeed this constrains "o" to be allocated to the accumulator
>>> register, while the new value "n" can be in any register.
>>>
>>> So if there's a problem, I don't know what it is.  Except I'm not sure
>>> what the ramifications of "o" being a function parameter AND having an "=a"
>>> constraint on it are...
>>>
>>>    -Ryan
>>>
>>>
>>>
>>> On Sat, Feb 1, 2014 at 11:27 AM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> Hey Ryan, i've made the leap to using 7.8 on my machine, so i'll first
>>>> have to get some pull requests in on atomic-primops before I can test it
>>>> locally :), expect those patches later today!
>>>>
>>>> looks like gcc's inline ASM logic is pretty correct, after testing it a
>>>> bit locally, pardon my speculative jumping the gun.
>>>>
>>>>
>>>> On Sat, Feb 1, 2014 at 9:10 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>>>
>>>>> Hi Carter & others,
>>>>>
>>>>> Carter, yes, this is CAS on pointers and in my next mail I'll try to
>>>>> come up with some hypotheses as to why we may have (remaining) problems
>>>>> there.
>>>>>
>>>>> But first, I have been assured that on x86 there is no failure mode in
>>>>> which doing a comparison on the value read by CAS should not correctly
>>>>> diagnose success or failure (same as directly reading the Zero Flag) [1].
>>>>>
>>>>> And yet, there's this discrepancy, where the modified casMutVar that I
>>>>> linked to does not have the failure.  As for reproducing the failure,
>>>>> either of the two following tests will currently show problems:
>>>>>
>>>>>    - Two threads try to casIORef False->True, both succeed
>>>>>    - 120 threads try to read, increment, CAS until they succeed.  The
>>>>>    total is often not 120 because multiple threads think the successfully
>>>>>    incremented, say, 33->34.
>>>>>
>>>>> Here's a specific recipe for the latter test on GHC 7.6.3 Mac or Linux:
>>>>>
>>>>>
>>>>> *git clone git at github.com:rrnewton/haskell-lockfree-queue.git *
>>>>> *cd haskell-lockfree-queue/AtomicPrimops/*
>>>>>
>>>>> *git checkout 1a1e7e55f6706f9e5754*
>>>>>
>>>>> *cabal sandbox init*
>>>>>
>>>>> *cabal install -f-withTH -fforeign ./ ./testing --enable-tests*
>>>>>
>>>>> *./testing/dist/dist-sandbox-*/build/test-atomic-primops/test-atomic-primops
>>>>> -t n_threads*
>>>>>
>>>>> You may have to run the last line several times to see the failure.
>>>>>
>>>>> Best,
>>>>>   -Ryan
>>>>>
>>>>> [1] I guess the __sync_bool_compare_and_swap intrinsic which reads ZF
>>>>> is there just to avoid the extra comparison.
>>>>>
>>>>> [2] P.S. I'd like to try this on GHC head, but the RHEL 6 machine I
>>>>> usually use to build it is currently not validating (below error, commit
>>>>> 65d05d7334).  After I debug this gmp problem I'll confirm that the bug
>>>>> under discussion applies on the 7.8 branch.
>>>>>
>>>>>     ./sync-all checkout ghc-7.8
>>>>>     sh validate
>>>>> ...
>>>>> /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation
>>>>> R_X86_64_32 against `__gmpz_sub' can not be used when making a shared
>>>>> object; recompile with -fPIC
>>>>> libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad
>>>>> value
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Feb 1, 2014 at 2:55 AM, Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> Ryan, is your benchmark using CAS on pointers, or immediate words?
>>>>>> trying to get atomic primops to build on my 7.8 build on my mac
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald <
>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>
>>>>>>> https://ghc.haskell.org/trac/ghc/ticket/8724#ticket is the ticket
>>>>>>>
>>>>>>> when i'm more awake i'll experiment some more
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Feb 1, 2014 at 2:33 AM, Carter Schonwald <
>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>
>>>>>>>> i have a ticket for tracking this, though i'm thinking my initial
>>>>>>>> attempt at a patch generates the same object code as it did before.
>>>>>>>>
>>>>>>>> @ryan, what CPU variant are you testing this on? is this on a NUMA
>>>>>>>> machine or something?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Feb 1, 2014 at 1:58 AM, Carter Schonwald <
>>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> woops, i mean cmpxchgq
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald <
>>>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> ok, i can confirm that on my 64bit mac, both clang and gcc
>>>>>>>>>> use cmpxchgl rather than cmpxchg
>>>>>>>>>> i'll whip up a strawman patch on head that can be cherrypicked /
>>>>>>>>>> tested out by ryan et al
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <
>>>>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey Ryan,
>>>>>>>>>>> looking at this closely
>>>>>>>>>>> Why isn't CAS using CMPXCHG8B on 64bit architectures?  Could
>>>>>>>>>>> that be the culprit?
>>>>>>>>>>>
>>>>>>>>>>> Could the issue be that we've not had a good stress test that
>>>>>>>>>>> would create values that are equal on the 32bit range, but differ on the
>>>>>>>>>>> 64bit range, and you're hitting that?
>>>>>>>>>>>
>>>>>>>>>>> Could you try seeing if doing that change fixes things up?
>>>>>>>>>>> (I may be completely wrong, but just throwing this out as a
>>>>>>>>>>> naive "obvious" guess)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <rrnewton at gmail.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Then again... I'm having trouble seeing how the spec on page
>>>>>>>>>>>> 3-149 of the Intel manual would allow the behavior I'm seeing:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>>>>>>>>>>>
>>>>>>>>>>>> Nevertheless, this is exactly the behavior we're seeing with
>>>>>>>>>>>> the current Haskell primops.  Two threads simultaneously performing the
>>>>>>>>>>>> same CAS(p,a,b) can both think that they succeeded.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <
>>>>>>>>>>>> rrnewton at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I commented on the commit here:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem is that our "cas" routine in SMP.h is similar to
>>>>>>>>>>>>> the C compiler intrinsic __sync_val_compare_and_swap, in that it returns
>>>>>>>>>>>>> the old value.  But it seems we cannot use a comparison against that old
>>>>>>>>>>>>> value to determine whether or not the CAS succeeded.  (I believe the CAS
>>>>>>>>>>>>> may fail due to contention, but the old value may happen to look like our
>>>>>>>>>>>>> old value.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Unfortunately, this didn't occur to me until it started
>>>>>>>>>>>>> causing bugs [1] [2].  Fixing casMutVar# fixes these bugs.  However, the
>>>>>>>>>>>>> way I'm currently fixing CAS in the "atomic-primops" package is by using
>>>>>>>>>>>>> __sync_bool_compare_and_swap:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>>>>>>>>>>>>
>>>>>>>>>>>>> What is the best fix for GHC itself?   Would it be ok for GHC
>>>>>>>>>>>>> to include a C compiler intrinsic like __sync_val_compare_and_swap?
>>>>>>>>>>>>>  Otherwise we need another big ifdbef'd function like "cas" in SMP.h that
>>>>>>>>>>>>> has the architecture-specific inline asm across all architectures.  I can
>>>>>>>>>>>>> write the x86 one, but I'm not eager to try the others.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>    -Ryan
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://github.com/iu-parfunc/lvars/issues/70
>>>>>>>>>>>>> [2] https://github.com/rrnewton/haskell-lockfree/issues/15
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> ghc-devs mailing list
>>>>>>>>>>>> ghc-devs at haskell.org
>>>>>>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/989d8abf/attachment-0001.html>

From marlowsd at gmail.com  Sat Feb  1 21:00:13 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 01 Feb 2014 21:00:13 +0000
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <CACYs5AaaAuS4e=kwMqB6vNnbLfBSTy1+Kjkbgm_Vz2Feg65rZQ@mail.gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
 <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
 <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>
 <CAHYVw0zDuSLjJJexdOjusbyr=Q5o7OdDG65g8wdseZqq6QgayQ@mail.gmail.com>
 <CAHYVw0yRYUAfmpDbCzy2A3wSCUu5-gBN_RrJjkGvodZSznZR_w@mail.gmail.com>
 <CACYs5AY9uBXtmO5g4xmqsQb9Hb7vH+aiYPtNUbTs+dJjMcbk+w@mail.gmail.com>
 <CAHYVw0yhzysUz=R0BLt_e8b929ey1qH-kL5hx0rVCAm0JWfW-w@mail.gmail.com>
 <CACYs5AZuc_6T+AGZFx_644XVGjC5x_6-PySWcyZhTUpUyE0qQw@mail.gmail.com>
 <CAHYVw0w92JPqsqEtF9FX_NP=aDsSvadsTH32ii4WGiFeX=dO+Q@mail.gmail.com>
 <CAHYVw0ze5zCmNb6HaSA0VX4tOAuXNJPTwNN3p6caRiwUs_ccXA@mail.gmail.com>
 <CACYs5AaaAuS4e=kwMqB6vNnbLfBSTy1+Kjkbgm_Vz2Feg65rZQ@mail.gmail.com>
Message-ID: <52ED605D.8050502@gmail.com>

So there's no problem in casMutVar#?

There's probably no good reason not to use the gcc intrinsics.  Either 
they didn't exist when I wrote the inline asm, or they had been added to 
gcc since I last read the docs.

Cheers,
Simon

On 01/02/2014 19:35, Ryan Newton wrote:
> Ok, my bad, sorry all.
>
> This is NOT a problem that will crop up in 7.8.   Rather, it's just a
> problem with the duplicated bits of GHC RTS functionality that were
> stuck into the atomic-primops library.  It was a C preprocessor problem
> that was causing the inline asm we were discussing in this thread to not
> actually be called.
>
> Still, I'd like to be reminded of the rational for all this conditional
> inline asm rather than using the C compiler intrinsics!  Anyone?
>
> Best,
>    -Ryan
>
>
>
> On Sat, Feb 1, 2014 at 2:17 PM, Carter Schonwald
> <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
>
>     I got the test suite running on my (2 core) machine mac book air,
>     with 7.8
>     i've run it several times, not seeing any failures
>
>
>     On Sat, Feb 1, 2014 at 1:03 PM, Carter Schonwald
>     <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
>
>         hrmmmm I have a crazy idea
>
>         "Compare RAX with r/m64. If equal, ZF is set and r64 is loaded
>         into r/m64. Else, clear ZF
>         and load r/m64 into RAX." is what the docs say for the cmpxchng
>         instruction
>
>         so RAX is the old values,  (EAX in the  32bit case). And it
>         looks like we dont' set that explicitly when calling the asm ..
>         CMPXCHG r/m64, r64
>
>           hrmmm
>
>
>
>
>         On Sat, Feb 1, 2014 at 12:52 PM, Ryan Newton <rrnewton at gmail.com
>         <mailto:rrnewton at gmail.com>> wrote:
>
>             Ok, here's another experiment, on this commit:
>
>             https://github.com/rrnewton/haskell-lockfree/commit/399bb19fa02eaf2f2eab5d02c4b608535362f9bc
>
>             Here, if I use GCC's __sync_val_compare_and_swap instead of
>             GHC's version of cas(), the problem also goes away.  I think
>             these two implementations should behave identically, and
>             that they don't perhaps indicates that there is something
>             off about the inline asm, as Carter was suggesting:
>
>             *#if i386_HOST_ARCH || x86_64_HOST_ARCH*
>             *    __asm__ __volatile__ (*
>             * "lock\ncmpxchg %3,%1"*
>             *          :"=a"(o), "=m" (*(volatile unsigned int *)p) *
>             *          :"0" (o), "r" (n));*
>             *    return o;*
>
>             The x86 CAS instruction must put the "return value" in the
>             accumulator register, and indeed this constrains "o" to be
>             allocated to the accumulator register, while the new value
>             "n" can be in any register.
>
>             So if there's a problem, I don't know what it is.  Except
>             I'm not sure what the ramifications of "o" being a function
>             parameter AND having an "=a" constraint on it are...
>
>                 -Ryan
>
>
>
>             On Sat, Feb 1, 2014 at 11:27 AM, Carter Schonwald
>             <carter.schonwald at gmail.com
>             <mailto:carter.schonwald at gmail.com>> wrote:
>
>                 Hey Ryan, i've made the leap to using 7.8 on my machine,
>                 so i'll first have to get some pull requests in on
>                 atomic-primops before I can test it locally :), expect
>                 those patches later today!
>
>                 looks like gcc's inline ASM logic is pretty correct,
>                 after testing it a bit locally, pardon my speculative
>                 jumping the gun.
>
>
>                 On Sat, Feb 1, 2014 at 9:10 AM, Ryan Newton
>                 <rrnewton at gmail.com <mailto:rrnewton at gmail.com>> wrote:
>
>                     Hi Carter & others,
>
>                     Carter, yes, this is CAS on pointers and in my next
>                     mail I'll try to come up with some hypotheses as to
>                     why we may have (remaining) problems there.
>
>                     But first, I have been assured that on x86 there is
>                     no failure mode in which doing a comparison on the
>                     value read by CAS should not correctly diagnose
>                     success or failure (same as directly reading the
>                     Zero Flag) [1].
>
>                     And yet, there's this discrepancy, where the
>                     modified casMutVar that I linked to does not have
>                     the failure.  As for reproducing the failure, either
>                     of the two following tests will currently show problems:
>
>                       * Two threads try to casIORef False->True, both
>                         succeed
>                       * 120 threads try to read, increment, CAS until
>                         they succeed.  The total is often not 120
>                         because multiple threads think the successfully
>                         incremented, say, 33->34.
>
>                     Here's a specific recipe for the latter test on GHC
>                     7.6.3 Mac or Linux:
>
>                     *git clone
>                     git at github.com:rrnewton/haskell-lockfree-queue.git
>                     *
>                     *cd haskell-lockfree-queue/AtomicPrimops/*
>                     *git checkout 1a1e7e55f6706f9e5754
>                     *
>                     *cabal sandbox init
>                     *
>                     *cabal install -f-withTH -fforeign ./ ./testing
>                     --enable-tests
>                     *
>                     *./testing/dist/dist-sandbox-*/build/test-atomic-primops/test-atomic-primops
>                     -t n_threads
>                     *
>
>                     You may have to run the last line several times to
>                     see the failure.
>
>                     Best,
>                        -Ryan
>
>                     [1] I guess the __sync_bool_compare_and_swap
>                     intrinsic which reads ZF is there just to avoid the
>                     extra comparison.
>
>                     [2] P.S. I'd like to try this on GHC head, but the
>                     RHEL 6 machine I usually use to build it is
>                     currently not validating (below error, commit
>                     65d05d7334).  After I debug this gmp problem I'll
>                     confirm that the bug under discussion applies on the
>                     7.8 branch.
>
>                          ./sync-all checkout ghc-7.8
>                          sh validate
>                     ...
>                     /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o:
>                     relocation R_X86_64_32 against `__gmpz_sub' can not
>                     be used when making a shared object; recompile with
>                     -fPIC
>                     libraries/integer-gmp/gmp/objs/aors.o: could not
>                     read symbols: Bad value
>
>
>
>
>                     On Sat, Feb 1, 2014 at 2:55 AM, Carter Schonwald
>                     <carter.schonwald at gmail.com
>                     <mailto:carter.schonwald at gmail.com>> wrote:
>
>                         Ryan, is your benchmark using CAS on pointers,
>                         or immediate words? trying to get atomic primops
>                         to build on my 7.8 build on my mac
>
>
>                         On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald
>                         <carter.schonwald at gmail.com
>                         <mailto:carter.schonwald at gmail.com>> wrote:
>
>                             https://ghc.haskell.org/trac/ghc/ticket/8724#ticket
>                             is the ticket
>
>                             when i'm more awake i'll experiment some more
>
>
>                             On Sat, Feb 1, 2014 at 2:33 AM, Carter
>                             Schonwald <carter.schonwald at gmail.com
>                             <mailto:carter.schonwald at gmail.com>> wrote:
>
>                                 i have a ticket for tracking this,
>                                 though i'm thinking my initial attempt
>                                 at a patch generates the same object
>                                 code as it did before.
>
>                                 @ryan, what CPU variant are you testing
>                                 this on? is this on a NUMA machine or
>                                 something?
>
>
>                                 On Sat, Feb 1, 2014 at 1:58 AM, Carter
>                                 Schonwald <carter.schonwald at gmail.com
>                                 <mailto:carter.schonwald at gmail.com>> wrote:
>
>                                     woops, i mean cmpxchgq
>
>
>                                     On Sat, Feb 1, 2014 at 1:36 AM,
>                                     Carter Schonwald
>                                     <carter.schonwald at gmail.com
>                                     <mailto:carter.schonwald at gmail.com>>
>                                     wrote:
>
>                                         ok, i can confirm that on my
>                                         64bit mac, both clang and gcc
>                                         use cmpxchgl rather than cmpxchg
>                                         i'll whip up a strawman patch on
>                                         head that can be cherrypicked /
>                                         tested out by ryan et al
>
>
>                                         On Sat, Feb 1, 2014 at 1:12 AM,
>                                         Carter Schonwald
>                                         <carter.schonwald at gmail.com
>                                         <mailto:carter.schonwald at gmail.com>>
>                                         wrote:
>
>                                             Hey Ryan,
>                                             looking at this closely
>                                             Why isn't CAS using
>                                             CMPXCHG8B on 64bit
>                                             architectures?  Could that
>                                             be the culprit?
>
>                                             Could the issue be that
>                                             we've not had a good stress
>                                             test that would create
>                                             values that are equal on the
>                                             32bit range, but differ on
>                                             the 64bit range, and you're
>                                             hitting that?
>
>                                             Could you try seeing if
>                                             doing that change fixes
>                                             things up?
>                                             (I may be completely wrong,
>                                             but just throwing this out
>                                             as a naive "obvious" guess)
>
>
>                                             On Sat, Feb 1, 2014 at 12:58
>                                             AM, Ryan Newton
>                                             <rrnewton at gmail.com
>                                             <mailto:rrnewton at gmail.com>>
>                                             wrote:
>
>                                                 Then again... I'm having
>                                                 trouble seeing how the
>                                                 spec on page 3-149 of
>                                                 the Intel manual would
>                                                 allow the behavior I'm
>                                                 seeing:
>
>                                                 http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>
>                                                 Nevertheless, this is
>                                                 exactly the behavior
>                                                 we're seeing with the
>                                                 current Haskell primops.
>                                                   Two threads
>                                                 simultaneously
>                                                 performing the same
>                                                 CAS(p,a,b) can both
>                                                 think that they succeeded.
>
>
>
>
>
>                                                 On Sat, Feb 1, 2014 at
>                                                 12:33 AM, Ryan Newton
>                                                 <rrnewton at gmail.com
>                                                 <mailto:rrnewton at gmail.com>>
>                                                 wrote:
>
>                                                     I commented on the
>                                                     commit here:
>
>                                                     https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>
>                                                     The problem is that
>                                                     our "cas" routine in
>                                                     SMP.h is similar to
>                                                     the C compiler
>                                                     intrinsic
>                                                     __sync_val_compare_and_swap,
>                                                     in that it returns
>                                                     the old value.  But
>                                                     it seems we cannot
>                                                     use a comparison
>                                                     against that old
>                                                     value to determine
>                                                     whether or not the
>                                                     CAS succeeded.  (I
>                                                     believe the CAS may
>                                                     fail due to
>                                                     contention, but the
>                                                     old value may happen
>                                                     to look like our old
>                                                     value.)
>
>                                                     Unfortunately, this
>                                                     didn't occur to me
>                                                     until it started
>                                                     causing bugs [1]
>                                                     [2].  Fixing
>                                                     casMutVar# fixes
>                                                     these bugs.
>                                                       However, the way
>                                                     I'm currently fixing
>                                                     CAS in the
>                                                     "atomic-primops"
>                                                     package is by using
>                                                     __sync_bool_compare_and_swap:
>
>                                                     https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>
>                                                     What is the best fix
>                                                     for GHC itself?
>                                                     Would it be ok for
>                                                     GHC to include a C
>                                                     compiler intrinsic
>                                                     like
>                                                     __sync_val_compare_and_swap?
>                                                       Otherwise we need
>                                                     another big ifdbef'd
>                                                     function like "cas"
>                                                     in SMP.h that has
>                                                     the
>                                                     architecture-specific inline
>                                                     asm across all
>                                                     architectures.  I
>                                                     can write the x86
>                                                     one, but I'm not
>                                                     eager to try the others.
>
>                                                     Best,
>                                                         -Ryan
>
>                                                     [1]
>                                                     https://github.com/iu-parfunc/lvars/issues/70
>                                                     [2]
>                                                     https://github.com/rrnewton/haskell-lockfree/issues/15
>
>
>
>                                                 _______________________________________________
>                                                 ghc-devs mailing list
>                                                 ghc-devs at haskell.org
>                                                 <mailto:ghc-devs at haskell.org>
>                                                 http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
>
>
>
>
>
>
>
>
>
>

From iavor.diatchki at gmail.com  Sat Feb  1 21:38:46 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sat, 1 Feb 2014 13:38:46 -0800
Subject: TypeNats trial on new ghc branch 7.8
In-Reply-To: <CAHYVw0zD-XuEFz0f1C-T0V=bJ31A7amSZhpnwwb2F9Weapg=+A@mail.gmail.com>
References: <loom.20140201T155932-521@post.gmane.org>
 <CABzw7bW9kPcL2qf+ApFOrqo=TYFEYSSHJFNd-22V9PNh4=kq6Q@mail.gmail.com>
 <CAHYVw0zD-XuEFz0f1C-T0V=bJ31A7amSZhpnwwb2F9Weapg=+A@mail.gmail.com>
Message-ID: <CAGK9nuquYqjR3NxHtaK=Vc5GdQCmYp6kd6Ey9iz6Zzz8U_49Nw@mail.gmail.com>

Hi,

yep that's exactly the case---the current solver can only do things like "2
+ 3 ~ 5".   The interesting new solver, which knows about linear
arithmetic, is currently on branch "decision-procedure"  but that's quite
out of date.  I am waiting for 7.8 to get out the door, and than I plan to
restart working on this, to get it updated and on the master branch,
hopefully to be part of the following GHC release.

-Iavor


On Sat, Feb 1, 2014 at 8:03 AM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> Hey Gabriel,
> As far as I could determine, there is no solver powers in 7.8
> the "solver" can simply just check that  (2 + 3 )~5 and other simple
> "compute to get equality" situations
>
>
> On Sat, Feb 1, 2014 at 10:52 AM, Christiaan Baaij <
> christiaan.baaij at gmail.com> wrote:
>
>> The "simplified" solver, as in
>> https://github.com/ghc/ghc/tree/type-nats-simple, has been integrated as
>> far as I know.
>> I've been experimenting with my own solver:
>> https://gist.github.com/christiaanb/8396614
>> Here are some examples of the stuff that works with my solver:
>> https://github.com/christiaanb/clash-prelude/blob/newnats/src/CLaSH/Sized/Vector.hs
>>
>>
>> On Sat, Feb 1, 2014 at 4:23 PM, Gabriel Riba <griba2001 at gmail.com> wrote:
>>
>>> I know that the TypeNats solver may not have been merged with 7.8 branch
>>>
>>> but the compiler error looks so simple:
>>>
>>> Couldn't match type ?(n + m) - 1? with ?(n - 1) + m?
>>>
>>>     ---------------------------------
>>>     {-# LANGUAGE DataKinds, GADTs, KindSignatures, TypeOperators,
>>> PolyKinds,
>>> ExistentialQuantification #-}
>>>
>>>     import GHC.TypeLits
>>>
>>>     data Vect :: Nat -> * -> * where
>>>       Nil ::  Vect 0 a
>>>       Cons :: a -> Vect (n-1) a -> Vect n a
>>>
>>>     data MyProxy (n::Nat) = forall a. MyProxy (Vect n a)
>>>
>>>     toProxy :: Vect (n::Nat) a -> MyProxy n
>>>     toProxy v = MyProxy v
>>>
>>>     len :: KnownNat n => Vect (n::Nat) a -> Integer
>>>     len v = (natVal . toProxy) v                         -- Ok
>>>
>>>     append :: Vect n a -> Vect m a -> Vect (n+m) a
>>>     append Nil ys = ys
>>>     append (Cons x xs) ys = Cons x (append xs ys)  -- compiler error
>>>
>>>
>>>     main = do
>>>       print $ len Nil                          -- Ok
>>>       print $ len (Cons (1::Int) Nil)          -- Ok
>>>     ------------------------------------------------------
>>>
>>>
>>> Error on "append  (Cons x xs) ys = ..."
>>>
>>>     Couldn't match type ?(n + m) - 1? with ?(n - 1) + m?
>>>     Expected type: Vect ((n + m) - 1) a
>>>       Actual type: Vect ((n - 1) + m) a
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140201/737ce4a6/attachment-0001.html>

From tkn.akio at gmail.com  Sun Feb  2 22:25:48 2014
From: tkn.akio at gmail.com (Akio Takano)
Date: Mon, 3 Feb 2014 07:25:48 +0900
Subject: Extending fold/build fusion
In-Reply-To: <1391159897.3184.10.camel@kirk>
References: <CAOGQyFsnEsvS47+PaMSZvWkPOPsjYfmbuC6Bfm02r-VX6t6-Dw@mail.gmail.com>
 <1390932396.2641.46.camel@kirk>
 <CAOGQyFup3pZ_H_9f148WK5-LucpfSCe0XPg=PgYxDdR4Q0aOLw@mail.gmail.com>
 <1391159897.3184.10.camel@kirk>
Message-ID: <CAOGQyFsFxRQY--KVpZBJOgY3ZHxwb3Oxgk5T=03Ofj8FPBi4wg@mail.gmail.com>

On Fri, Jan 31, 2014 at 6:18 PM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Dear Akio,
>
> Am Freitag, den 31.01.2014, 16:54 +0900 schrieb Akio Takano:
>> > Can you implement build via buildW, so that existing code like
>> >   "map"  [~1] forall f xs. map f xs = build (\c n -> foldr (mapFB c f) n xs)
>> > can be used unmodified? But probably not... but that would mean a
>> > noticeable incompatibility and a burden on library authors using list
>> > fusion.
>>
>> You can implement build in terms of buildW. However any list producer
>> defined using that definition of build would produce good code if the
>> final consumer is a left fold. The resulting code will be in CPS. On
>> the other hand, I imagine that if we also annotate foldl with oneShot,
>> this problem may become less severe.
>
> Hmm, I guess my question was not precise enough. Let me rephrase: To
> what extend can you provide the exsting foldr/build API _without_ losing
> the advantages of your approach?

Sorry, I had a bad typo in the previous message: I meant

Any list producer defined using that definition of build would *not*
produce good code if the final consumer is a left fold.

To answer your question: list producers defined using build will
continue to compile, but will *not* be able to take any advantages of
foldrW/buildW.

>
> Or put differently: Could you add a section to the wiki that serves as a
> migration guide to those who want to port their producers and consumers
> to your system, without having to fully understand what's going on?

I added a section for this:

https://github.com/takano-akio/ww-fusion#how-to-make-a-list-produer-work-with-foldrwbuildw-fusion

>
>
> Another thing that would be very interesting: Your framework seems to be
> quite general: Are there other useful worker-wrapper-transformations
> that one would possibly want to apply to a fused computations, besides
> the one that makes foldl work well? Other examples of
> w/w-transformations in GHC include
>  * Unboxing of parameters
>  * Unboxing of return values, returning multiple values
> but maybe you can think of other interesting examples.

I can't think of anything new, but I think it's often interesting to
do a (nested) CPR transformation for a fused function. I added such an
example (see serializeTree and foldIO_Ptr) :

https://github.com/takano-akio/ww-fusion/blob/master/test.hs#L23

However this kind of tricks may become unnecessary once GHC starts to
do nested CPRs.

>
> Am I right that the _consumer_ of a fused computation decides which
> worker-wrapper pair to use?

Yes.

>
>
> I still quite like the approach, mostly because it does so well for
> lists. I still have to fully grok it, though :-)
>
> Greetings,
> Joachim
>
>
> --
> Joachim Breitner
>   e-Mail: mail at joachim-breitner.de
>   Homepage: http://www.joachim-breitner.de
>   Jabber-ID: nomeata at joachim-breitner.de
>

From johan.tibell at gmail.com  Tue Feb  4 05:10:24 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 3 Feb 2014 21:10:24 -0800
Subject: Cabal release for 7.8
Message-ID: <CAK-tuPaoZXGMpFoVLRfshE2b5GNhC9Tn_r4R9mYTg487RAZ_9A@mail.gmail.com>

Hi,

I guess we need one last cabal release for 7.8? Are we ready for that now,
or do you expect any more 7.8 change that will require cabal changes?

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140203/9dd789bc/attachment.html>

From hvriedel at gmail.com  Tue Feb  4 07:21:01 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 04 Feb 2014 08:21:01 +0100
Subject: Cabal release for 7.8
In-Reply-To: <CAK-tuPaoZXGMpFoVLRfshE2b5GNhC9Tn_r4R9mYTg487RAZ_9A@mail.gmail.com>
 (Johan Tibell's message of "Mon, 3 Feb 2014 21:10:24 -0800")
References: <CAK-tuPaoZXGMpFoVLRfshE2b5GNhC9Tn_r4R9mYTg487RAZ_9A@mail.gmail.com>
Message-ID: <871tzjjqci.fsf@gmail.com>

On 2014-02-04 at 06:10:24 +0100, Johan Tibell wrote:
> I guess we need one last cabal release for 7.8? Are we ready for that now,
> or do you expect any more 7.8 change that will require cabal changes?

The RC1 has just started, and I'd rather wait a little more till we're
closer to a final release...

PS: We'll also need a 'cabal-install' release, as the current 1.18.0.2
    doesn't build with GHC 7.8RC1

PS2: would it be possible to have
     https://github.com/haskell/cabal/commit/32dddcb1f0495a633ab806e0bcd43816cac67b03
     picked up for 1.18 (assuming it applies cleanly)? It would make it
     easier to generate documentation tarballs for uploading to Hackage
     w/o needing to 'sed' away all 'file:///' prefixes.

From simonpj at microsoft.com  Tue Feb  4 08:04:13 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Feb 2014 08:04:13 +0000
Subject: Nightlies
In-Reply-To: <1390816044.2549.3.camel@kirk>
References: <52E4714B.5060905@fuuzetsu.co.uk> <1390734969.2515.6.camel@kirk>
 <CAEs96n0i0nQ+yqCq4rmCh4cR8Ph_cAH1eoQ7WhitEUOcTKACDQ@mail.gmail.com>
 <CAEs96n3Aj_qtmPVKsO34WOrbfntduyoo0Y-ggbJVJjCjWSj+Vw@mail.gmail.com>
 <1390816044.2549.3.camel@kirk>
Message-ID: <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>

Guys,

I want just to say thank you for thinking about this.  We badly need better nightly-builds for GHC, on a variety of platforms
a) to identify regressions, preferably to the actually commit that
   caused it, so Austin's big red message can go to the right person
b) to create binary snapshots that people can use without having to
   build GHC from scratch

Ian invested quite a bit of effort in a home-grown system to do just that, and I have no idea of how it stacks up against more widely-supported systems. 

These days GHC HQ is really just ghc-devs.  So please go right ahead... if you can converge to a solution and implement it, that'd be great.

Thanks

Simon 

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Joachim Breitner
| Sent: 27 January 2014 09:47
| To: ghc-devs at haskell.org
| Subject: Re: Nightlies
| 
| Good morning,
| 
| Am Sonntag, den 26.01.2014, 19:18 -0600 schrieb Austin Seipp:
| > Disregard all this, upon closer inspection I see you only wanted
| > ./validate anyway.* :)
| >
| > * But it still will hurt more when you add in low-powered builders.
| 
| right, I did not want to highjack the thread with my wishlist.
| 
| And even then I would not want low-powered builders, but rather one
| strong, ?most typical? setup. I think it would already by a big win if
| we ensured statically (heh) that every change to master has been
| validated completely once somewhere. And if for changes like the one I
| liked (removing dead code), as a developer I don?t have to laboriously
| enforce this invariant (which I obviously then didn?t do), but can rely
| on the safety nets of the infrastructure.
| 
| Greetings,
| Joachim
| 
| PS: I?m subscribed to the list, no need to mail me personally.
| 
| --
| Joachim ?nomeata? Breitner
|   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
|   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
|   Debian Developer: nomeata at debian.org

From simonpj at microsoft.com  Tue Feb  4 08:04:50 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Feb 2014 08:04:50 +0000
Subject: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve
 fusion
In-Reply-To: <058.101cb880f5abe7be42fa28550c431dbd@haskell.org>
References: <043.229b17c6b043d171889e26950a7c81e6@haskell.org>
 <058.101cb880f5abe7be42fa28550c431dbd@haskell.org>
Message-ID: <59543203684B2244980D7E4057D5FBC148761B98@DB3EX14MBXC312.europe.corp.microsoft.com>

Hi Ryan

Are you on this thread?   You probably should be!

Simon

| -----Original Message-----
| From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of
| GHC
| Sent: 27 January 2014 18:49
| Cc: ghc-tickets at haskell.org
| Subject: Re: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to
| achieve fusion
| 
| #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion
| -------------------------------------+---------------------------------
| ---
|         Reporter:  ion1              |            Owner:
|             Type:  feature request   |           Status:  patch
|         Priority:  normal            |        Milestone:
|        Component:  libraries/random  |          Version:  7.6.3
|       Resolution:                    |         Keywords:  fusion
| Operating System:  Unknown/Multiple  |     Architecture:
| Unknown/Multiple
|  Type of failure:  None/Unknown      |       Difficulty:  Unknown
|        Test Case:                    |       Blocked By:
|         Blocking:                    |  Related Tickets:  #4218
| -------------------------------------+---------------------------------
| ---
| 
| Comment (by nomeata):
| 
|  Thanks. From my POV it is worth adding even if you can?t measure a
|  performance gain; it is still good to know that nice code is being
|  generated. But of course it is up to Ryan Newton (random maintainer)
| to
|  decide this.
| 
| --
| Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8704#comment:4>
| GHC <http://www.haskell.org/ghc/>
| The Glasgow Haskell Compiler
| _______________________________________________
| ghc-tickets mailing list
| ghc-tickets at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-tickets

From simonpj at microsoft.com  Tue Feb  4 08:05:10 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Feb 2014 08:05:10 +0000
Subject: Request: export runTcInteractive from TcRnDriver
In-Reply-To: <E7F535B24A47D747A07D46C0AA82D43D1C7AA643@EXMBX21.ad.utwente.nl>
References: <E7F535B24A47D747A07D46C0AA82D43D1C7AA643@EXMBX21.ad.utwente.nl>
Message-ID: <59543203684B2244980D7E4057D5FBC148761BD9@DB3EX14MBXC312.europe.corp.microsoft.com>

No, there's no reason it's not exported, excepting only that it's not currently called outside TcRnDriver.

Go ahead and create a ticket and patch.  It should be exported from GHC.hs (ie the official GHC API), not merely from TcRnDriver.  And I suggest you add a comment with the export from GHC.hs to explain why it's exported.  Otherwise someone might delete it again!

Thx

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of p.k.f.holzenspies at utwente.nl
Sent: 29 January 2014 09:55
To: ghc-devs at haskell.org
Subject: Request: export runTcInteractive from TcRnDriver

Dear GHC-devs,

Is there a reason why, in HEAD, TcRnDriver does *not* export runTcInteractive? If not, can it please be added? (I considered sending a patch with this email, but it's so trivial a change that the check of the patch is more work than manually adding runTcInteractive to the export list.)

I'm developing against the GHC API of 7.6.3 and it would have saved me hours of work to have precisely that function. Seeing it's in HEAD, but not being exported seems a shame ;)

Regards,
Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/45a4b3de/attachment.html>

From simonpj at microsoft.com  Tue Feb  4 08:13:05 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Feb 2014 08:13:05 +0000
Subject: GHC boot-library package changelogs & release-notes
In-Reply-To: <87bnyubvf5.fsf@gnu.org>
References: <87bnyubvf5.fsf@gnu.org>
Message-ID: <59543203684B2244980D7E4057D5FBC148761EBB@DB3EX14MBXC312.europe.corp.microsoft.com>

Herbert

Would you like to add some notes to https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries, to describe what the file is, and the criteria for modifying it?  (After all, the patch history is a kind of change log too.)

Thanks

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Herbert Valerio Riedel
| Sent: 29 January 2014 16:33
| To: ghc-devs
| Subject: GHC boot-library package changelogs & release-notes
| 
| Hello fellow GHC devs,
| 
| As some of you might have noticed, I added a changelog.md file to
| libraries/base:
| 
|  https://github.com/ghc/packages-
| base/blob/c8634027d4e3315a2276fb1be8168c486419785a/changelog.md
| 
| (please feel free to fix any typos/omissions/whatever you notice)
| 
| My hope/motivation is that since Hackage gained the ability to display
| changelog files, the rather extensive changes in `base` might be a bit
| more easily/conveniently accessible on Hackage.
| 
| I chose to use Markdown format, as I believe it may be more convenient
| to maintain/edit the `base` changelog as plain text rather than having
| to edit XML after each noteworthy change in `base`. And as the
| release-notes typically only exploit a subset of the Docbook
| facilities,
| the conversion to Docbook XML could be performed semi-automatically
| shortly before a release.
| 
| Moreover, the release notes from previous major GHC release (which in
| the past contained the major changes in `base` et al.) are usually
| removed again. While a separate changelog file would usually retain
| (more) version history.
| 
| Therefore, I'd propose to switch from editing the user's guide release
| note for library release notes to using Hackage-changelog files in
| Markdown format (following a common structural convention) and make it
| the release-manager's responsibility to integrate the respective
| package's changelog content into the user's guide.
| 
| Any comments?
| 
| Cheers,
|   hvr
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From mail at joachim-breitner.de  Tue Feb  4 09:41:38 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 04 Feb 2014 09:41:38 +0000
Subject: Pre-Master checks (Was: Nightlies)
In-Reply-To: <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>
References: <52E4714B.5060905@fuuzetsu.co.uk> <1390734969.2515.6.camel@kirk>
 <CAEs96n0i0nQ+yqCq4rmCh4cR8Ph_cAH1eoQ7WhitEUOcTKACDQ@mail.gmail.com>
 <CAEs96n3Aj_qtmPVKsO34WOrbfntduyoo0Y-ggbJVJjCjWSj+Vw@mail.gmail.com>
 <1390816044.2549.3.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>
Message-ID: <1391506898.2719.23.camel@kirk>

Hi,

Am Dienstag, den 04.02.2014, 08:04 +0000 schrieb Simon Peyton Jones:
> I want just to say thank you for thinking about this.  We badly need better nightly-builds for GHC, on a variety of platforms
> a) to identify regressions, preferably to the actually commit that
>    caused it, so Austin's big red message can go to the right person

I believe we can do better, so that Austin?s big red message does not
have to be written in the first place.

Here is what I have in mind, and I?ll volunteer to implement it if
people think it is a good idea and I get the resources/permissions:

Proposal
~~~~~~~~

Nobody gets to push to master directly. Instead, every push to master is
diverted? to a temporary branch "validating/<some id>". One of our
servers detects the appearance of such a branch and will
 * check it out,
 * validate it,
 * if ok: check if master can still be fast-forward?ed to it,
 * if yes: push to master.

If it does not validate, or if master has changed in between, the branch
will be moved to failed/<some id>, and a message is sent to the pushing
developer?, including a tail of the log and a link to the full log.

Systems can fail, and maybe nothing validates anymore for reasons not
easily fixable. For that case, a backdoor is available: Pushes to the
branch "master-unchecked" will be moved to master, well, unchecked.

Benefits:
 * It is guaranteed that master has validated at least once somewhere.
   I.e. no need to ask on the mailing list ?does master validate for you
   right now??
 * It is now ok to do changes that are ?obviously correct? (comment
   changes, removing dead code, code reformatting) without having
   to validate manually, which _saves developer time_ (our most precious
   resource).

Downsides:
 * When two commits are racing for master, one will be rejected for
   being a non-fast-forward commit. The user will then have to merge
   or rebase and try again.
   But: The same would be true if he was validating locally (unless he
   does not validate the merge/rebase, in which case we are again where 
   we don?t want to be: Unvalidated versions in master.)


Is this something you would what, or could live with?

If it is technically feasible (given our hardware constraints,
repository structure and git?s feature) is a different question, which
needs to be discussed afterwards.

Greetings,
Joachim



? Might not be possible transparently
(http://stackoverflow.com/questions/21362833), but for the sake of
argument and workflow design, assume it was.
? As an approximation: The committer of the latest patch.

PS: I?m also considering (but not pushing hard) for a stronger variant
as follows. We do not need to discuss that now and should, if at all,
start the with the proposal above. I?m just adding it to show where this
is going ...
        
Stronger proposal
~~~~~~~~~~~~~~~~~

        Every commit in master needs to be validated! 
I tend to make sure that all patches on my branch validate individually
(git rebase -i -x "./validate" is a great tool here, you should use it!
). Contributors who do not want to go through that trouble should then
use "git merge --squash" to produce a single commit from their branch.

This would make the git history more useful for things like bitsecting.



-- 
Joachim Breitner
  e-Mail: mail at joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nomeata at joachim-breitner.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/b30a3c80/attachment.sig>

From eir at cis.upenn.edu  Tue Feb  4 14:42:32 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 4 Feb 2014 09:42:32 -0500
Subject: Pre-Master checks (Was: Nightlies)
In-Reply-To: <1391506898.2719.23.camel@kirk>
References: <52E4714B.5060905@fuuzetsu.co.uk> <1390734969.2515.6.camel@kirk>
 <CAEs96n0i0nQ+yqCq4rmCh4cR8Ph_cAH1eoQ7WhitEUOcTKACDQ@mail.gmail.com>
 <CAEs96n3Aj_qtmPVKsO34WOrbfntduyoo0Y-ggbJVJjCjWSj+Vw@mail.gmail.com>
 <1390816044.2549.3.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>
 <1391506898.2719.23.camel@kirk>
Message-ID: <4F3E4805-D83A-498A-8E9E-0D59A1E8C621@cis.upenn.edu>

Yay!

I, for one, would probably submit more bugfix patches with this structure in place. I take validating seriously, but my daily schedule often involves switching machines and tasks, and once I press "validate", it's often hours before I actually look at the results... by which time, some other commit may have come through. My need (real or perceived) for an uninterrupted chunk of time to make a patch stops me from doing them, sometimes.

With Joachim's structure, I could spend a half hour doing a quick patch (especially comments!) and push and move on.

Please do it! :)

Thanks!
Richard

PS: Transparency in the git redirects would be nice, of course, but is in no way necessary. We could I suppose add a "push" script to the repo that handles some of the overhead.

On Feb 4, 2014, at 4:41 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Hi,
> 
> Am Dienstag, den 04.02.2014, 08:04 +0000 schrieb Simon Peyton Jones:
>> I want just to say thank you for thinking about this.  We badly need better nightly-builds for GHC, on a variety of platforms
>> a) to identify regressions, preferably to the actually commit that
>>   caused it, so Austin's big red message can go to the right person
> 
> I believe we can do better, so that Austin?s big red message does not
> have to be written in the first place.
> 
> Here is what I have in mind, and I?ll volunteer to implement it if
> people think it is a good idea and I get the resources/permissions:
> 
> Proposal
> ~~~~~~~~
> 
> Nobody gets to push to master directly. Instead, every push to master is
> diverted? to a temporary branch "validating/<some id>". One of our
> servers detects the appearance of such a branch and will
> * check it out,
> * validate it,
> * if ok: check if master can still be fast-forward?ed to it,
> * if yes: push to master.
> 
> If it does not validate, or if master has changed in between, the branch
> will be moved to failed/<some id>, and a message is sent to the pushing
> developer?, including a tail of the log and a link to the full log.
> 
> Systems can fail, and maybe nothing validates anymore for reasons not
> easily fixable. For that case, a backdoor is available: Pushes to the
> branch "master-unchecked" will be moved to master, well, unchecked.
> 
> Benefits:
> * It is guaranteed that master has validated at least once somewhere.
>   I.e. no need to ask on the mailing list ?does master validate for you
>   right now??
> * It is now ok to do changes that are ?obviously correct? (comment
>   changes, removing dead code, code reformatting) without having
>   to validate manually, which _saves developer time_ (our most precious
>   resource).
> 
> Downsides:
> * When two commits are racing for master, one will be rejected for
>   being a non-fast-forward commit. The user will then have to merge
>   or rebase and try again.
>   But: The same would be true if he was validating locally (unless he
>   does not validate the merge/rebase, in which case we are again where 
>   we don?t want to be: Unvalidated versions in master.)
> 
> 
> Is this something you would what, or could live with?
> 
> If it is technically feasible (given our hardware constraints,
> repository structure and git?s feature) is a different question, which
> needs to be discussed afterwards.
> 
> Greetings,
> Joachim
> 
> 
> 
> ? Might not be possible transparently
> (http://stackoverflow.com/questions/21362833), but for the sake of
> argument and workflow design, assume it was.
> ? As an approximation: The committer of the latest patch.
> 
> PS: I?m also considering (but not pushing hard) for a stronger variant
> as follows. We do not need to discuss that now and should, if at all,
> start the with the proposal above. I?m just adding it to show where this
> is going ...
> 
> Stronger proposal
> ~~~~~~~~~~~~~~~~~
> 
>        Every commit in master needs to be validated! 
> I tend to make sure that all patches on my branch validate individually
> (git rebase -i -x "./validate" is a great tool here, you should use it!
> ). Contributors who do not want to go through that trouble should then
> use "git merge --squash" to produce a single commit from their branch.
> 
> This would make the git history more useful for things like bitsecting.
> 
> 
> 
> -- 
> Joachim Breitner
>  e-Mail: mail at joachim-breitner.de
>  Homepage: http://www.joachim-breitner.de
>  Jabber-ID: nomeata at joachim-breitner.de
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From fuuzetsu at fuuzetsu.co.uk  Tue Feb  4 15:26:44 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Tue, 04 Feb 2014 15:26:44 +0000
Subject: Pre-Master checks (Was: Nightlies)
In-Reply-To: <1391506898.2719.23.camel@kirk>
References: <52E4714B.5060905@fuuzetsu.co.uk> <1390734969.2515.6.camel@kirk>
 <CAEs96n0i0nQ+yqCq4rmCh4cR8Ph_cAH1eoQ7WhitEUOcTKACDQ@mail.gmail.com>
 <CAEs96n3Aj_qtmPVKsO34WOrbfntduyoo0Y-ggbJVJjCjWSj+Vw@mail.gmail.com>
 <1390816044.2549.3.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>
 <1391506898.2719.23.camel@kirk>
Message-ID: <52F106B4.5050405@fuuzetsu.co.uk>

On 04/02/14 09:41, Joachim Breitner wrote:
> Hi,
> 
> Am Dienstag, den 04.02.2014, 08:04 +0000 schrieb Simon Peyton Jones:
>> I want just to say thank you for thinking about this.  We badly need better nightly-builds for GHC, on a variety of platforms
>> a) to identify regressions, preferably to the actually commit that
>>    caused it, so Austin's big red message can go to the right person
> 
> I believe we can do better, so that Austin?s big red message does not
> have to be written in the first place.
> 
> Here is what I have in mind, and I?ll volunteer to implement it if
> people think it is a good idea and I get the resources/permissions:
> 
> Proposal
> ~~~~~~~~
> 
> Nobody gets to push to master directly. Instead, every push to master is
> diverted? to a temporary branch "validating/<some id>". One of our
> servers detects the appearance of such a branch and will
>  * check it out,
>  * validate it,
>  * if ok: check if master can still be fast-forward?ed to it,
>  * if yes: push to master.
> 
> If it does not validate, or if master has changed in between, the branch
> will be moved to failed/<some id>, and a message is sent to the pushing
> developer?, including a tail of the log and a link to the full log.
> 
> Systems can fail, and maybe nothing validates anymore for reasons not
> easily fixable. For that case, a backdoor is available: Pushes to the
> branch "master-unchecked" will be moved to master, well, unchecked.
> 
> Benefits:
>  * It is guaranteed that master has validated at least once somewhere.
>    I.e. no need to ask on the mailing list ?does master validate for you
>    right now??
>  * It is now ok to do changes that are ?obviously correct? (comment
>    changes, removing dead code, code reformatting) without having
>    to validate manually, which _saves developer time_ (our most precious
>    resource).
> 
> Downsides:
>  * When two commits are racing for master, one will be rejected for
>    being a non-fast-forward commit. The user will then have to merge
>    or rebase and try again.
>    But: The same would be true if he was validating locally (unless he
>    does not validate the merge/rebase, in which case we are again where 
>    we don?t want to be: Unvalidated versions in master.)
> 
> 
> Is this something you would what, or could live with?
> 
> If it is technically feasible (given our hardware constraints,
> repository structure and git?s feature) is a different question, which
> needs to be discussed afterwards.
> 
> Greetings,
> Joachim
> 
> 
> 
> ? Might not be possible transparently
> (http://stackoverflow.com/questions/21362833), but for the sake of
> argument and workflow design, assume it was.
> ? As an approximation: The committer of the latest patch.
> 
> PS: I?m also considering (but not pushing hard) for a stronger variant
> as follows. We do not need to discuss that now and should, if at all,
> start the with the proposal above. I?m just adding it to show where this
> is going ...
>         
> Stronger proposal
> ~~~~~~~~~~~~~~~~~
> 
>         Every commit in master needs to be validated! 
> I tend to make sure that all patches on my branch validate individually
> (git rebase -i -x "./validate" is a great tool here, you should use it!
> ). Contributors who do not want to go through that trouble should then
> use "git merge --squash" to produce a single commit from their branch.
> 
> This would make the git history more useful for things like bitsecting.
> 
> 
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

You mention that it's enough for one machine to validate the patch. What
if the change was for example to fix something on ARM (where builds take
a long time) and has no effect on x86? The x86 machine is likely to come
through first and give you the OK, pushing to master something that's
effectively not checked. In fact, the fastest slave is likely to come
through first every time and if it validates there (for example, I hear
that 64-bit Linux is the golden platform for validate), it will be
pushed to master.

I think the proposal needs an enhancement: ability to specify which
platform the commit needs to validate on (i.e. even if i686 comes
through first, we'll wait for ARM anyway) before being pushed in.

-- 
Mateusz K.

From carter.schonwald at gmail.com  Tue Feb  4 15:39:57 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 4 Feb 2014 10:39:57 -0500
Subject: Pre-Master checks (Was: Nightlies)
In-Reply-To: <52F106B4.5050405@fuuzetsu.co.uk>
References: <52E4714B.5060905@fuuzetsu.co.uk> <1390734969.2515.6.camel@kirk>
 <CAEs96n0i0nQ+yqCq4rmCh4cR8Ph_cAH1eoQ7WhitEUOcTKACDQ@mail.gmail.com>
 <CAEs96n3Aj_qtmPVKsO34WOrbfntduyoo0Y-ggbJVJjCjWSj+Vw@mail.gmail.com>
 <1390816044.2549.3.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>
 <1391506898.2719.23.camel@kirk> <52F106B4.5050405@fuuzetsu.co.uk>
Message-ID: <CAHYVw0z5OkzsrhBV_QKqUkCaXgtZmc=2gexmyRZgxwmr_gQJGA@mail.gmail.com>

This actually raises an important question: we don't have any good policy
for making sure validate / etc stays clean on all the platforms.   There's
enough variations that it might take an implausible amount of resources to
test all the targets we want to support on every commit. (Eg given how long
builds apparently take on certain platforms like arm, we'd need quite a few
wee arm machines to test arm at every commit.  Or maybe not?)

Point being: I agree that support tooling to make sure builds don't stay
broken and don't get broken aren't where it should be. And I  agree that
something like you describe should be done.  I'm just wondering if we have
the resources to do that correctly.

On Tuesday, February 4, 2014, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
wrote:

> On 04/02/14 09:41, Joachim Breitner wrote:
> > Hi,
> >
> > Am Dienstag, den 04.02.2014, 08:04 +0000 schrieb Simon Peyton Jones:
> >> I want just to say thank you for thinking about this.  We badly need
> better nightly-builds for GHC, on a variety of platforms
> >> a) to identify regressions, preferably to the actually commit that
> >>    caused it, so Austin's big red message can go to the right person
> >
> > I believe we can do better, so that Austin?s big red message does not
> > have to be written in the first place.
> >
> > Here is what I have in mind, and I?ll volunteer to implement it if
> > people think it is a good idea and I get the resources/permissions:
> >
> > Proposal
> > ~~~~~~~~
> >
> > Nobody gets to push to master directly. Instead, every push to master is
> > diverted? to a temporary branch "validating/<some id>". One of our
> > servers detects the appearance of such a branch and will
> >  * check it out,
> >  * validate it,
> >  * if ok: check if master can still be fast-forward?ed to it,
> >  * if yes: push to master.
> >
> > If it does not validate, or if master has changed in between, the branch
> > will be moved to failed/<some id>, and a message is sent to the pushing
> > developer?, including a tail of the log and a link to the full log.
> >
> > Systems can fail, and maybe nothing validates anymore for reasons not
> > easily fixable. For that case, a backdoor is available: Pushes to the
> > branch "master-unchecked" will be moved to master, well, unchecked.
> >
> > Benefits:
> >  * It is guaranteed that master has validated at least once somewhere.
> >    I.e. no need to ask on the mailing list ?does master validate for you
> >    right now??
> >  * It is now ok to do changes that are ?obviously correct? (comment
> >    changes, removing dead code, code reformatting) without having
> >    to validate manually, which _saves developer time_ (our most precious
> >    resource).
> >
> > Downsides:
> >  * When two commits are racing for master, one will be rejected for
> >    being a non-fast-forward commit. The user will then have to merge
> >    or rebase and try again.
> >    But: The same would be true if he was validating locally (unless he
> >    does not validate the merge/rebase, in which case we are again where
> >    we don?t want to be: Unvalidated versions in master.)
> >
> >
> > Is this something you would what, or could live with?
> >
> > If it is technically feasible (given our hardware constraints,
> > repository structure and git?s feature) is a different question, which
> > needs to be discussed afterwards.
> >
> > Greetings,
> > Joachim
> >
> >
> >
> > ? Might not be possible transparently
> > (http://stackoverflow.com/questions/21362833), but for the sake of
> > argument and workflow design, assume it was.
> > ? As an approximation: The committer of the latest patch.
> >
> > PS: I?m also considering (but not pushing hard) for a stronger variant
> > as follows. We do not need to discuss that now and should, if at all,
> > start the with the proposal above. I?m just adding it to show where this
> > is going ...
> >
> > Stronger proposal
> > ~~~~~~~~~~~~~~~~~
> >
> >         Every commit in master needs to be validated!
> > I tend to make sure that all patches on my branch validate individually
> > (git rebase -i -x "./validate" is a great tool here, you should use it!
> > ). Contributors who do not want to go through that trouble should then
> > use "git merge --squash" to produce a single commit from their branch.
> >
> > This would make the git history more useful for things like bitsecting.
> >
> >
> >
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org <javascript:;>
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
> You mention that it's enough for one machine to validate the patch. What
> if the change was for example to fix something on ARM (where builds take
> a long time) and has no effect on x86? The x86 machine is likely to come
> through first and give you the OK, pushing to master something that's
> effectively not checked. In fact, the fastest slave is likely to come
> through first every time and if it validates there (for example, I hear
> that 64-bit Linux is the golden platform for validate), it will be
> pushed to master.
>
> I think the proposal needs an enhancement: ability to specify which
> platform the commit needs to validate on (i.e. even if i686 comes
> through first, we'll wait for ARM anyway) before being pushed in.
>
> --
> Mateusz K.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/279dba55/attachment.html>

From mail at joachim-breitner.de  Tue Feb  4 15:57:08 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 04 Feb 2014 15:57:08 +0000
Subject: Pre-Master checks (Was: Nightlies)
In-Reply-To: <52F106B4.5050405@fuuzetsu.co.uk>
References: <52E4714B.5060905@fuuzetsu.co.uk> <1390734969.2515.6.camel@kirk>
 <CAEs96n0i0nQ+yqCq4rmCh4cR8Ph_cAH1eoQ7WhitEUOcTKACDQ@mail.gmail.com>
 <CAEs96n3Aj_qtmPVKsO34WOrbfntduyoo0Y-ggbJVJjCjWSj+Vw@mail.gmail.com>
 <1390816044.2549.3.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>
 <1391506898.2719.23.camel@kirk> <52F106B4.5050405@fuuzetsu.co.uk>
Message-ID: <1391529428.2719.39.camel@kirk>

Hi,

Am Dienstag, den 04.02.2014, 15:26 +0000 schrieb Mateusz Kowalczyk:
> You mention that it's enough for one machine to validate the patch. What
> if the change was for example to fix something on ARM (where builds take
> a long time) and has no effect on x86? The x86 machine is likely to come
> through first and give you the OK, pushing to master something that's
> effectively not checked. In fact, the fastest slave is likely to come
> through first every time and if it validates there (for example, I hear
> that 64-bit Linux is the golden platform for validate), it will be
> pushed to master.

sorry, I was not clear. There would be _one_ dedicated machine for doing
pre-master checks, and its main purpose is to detect obvious mistakes,
i.e. broken code, forgotten test output updates etc. It will not replace
the build farm that does daily checks on other systems.

If someone fixes a problem on an different architecture, I have no
doubts that we will have tested this fix. It is the forgotten update of
the import list (which will make validate fail for others, independent o
of the architecture) that I worry about.

Greetings,
Joachim



-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/51e4d1dc/attachment-0001.sig>

From simonpj at microsoft.com  Tue Feb  4 17:56:03 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Feb 2014 17:56:03 +0000
Subject: Pre-Master checks (Was: Nightlies)
In-Reply-To: <1391506898.2719.23.camel@kirk>
References: <52E4714B.5060905@fuuzetsu.co.uk> <1390734969.2515.6.camel@kirk>
 <CAEs96n0i0nQ+yqCq4rmCh4cR8Ph_cAH1eoQ7WhitEUOcTKACDQ@mail.gmail.com>
 <CAEs96n3Aj_qtmPVKsO34WOrbfntduyoo0Y-ggbJVJjCjWSj+Vw@mail.gmail.com>
 <1390816044.2549.3.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>
 <1391506898.2719.23.camel@kirk>
Message-ID: <59543203684B2244980D7E4057D5FBC148764927@DB3EX14MBXC312.europe.corp.microsoft.com>

I can see advantages here, similar to Richard.  I'm just a bit worried about keeping all those branches straight in my head.

Who names all these temporary branches?  Does someone delete them so they don't accumulate and dominate the branch list? 

Would need careful documenting, so that new people know exactly what to do.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Joachim Breitner
| Sent: 04 February 2014 09:42
| To: ghc-devs at haskell.org
| Subject: Re: Pre-Master checks (Was: Nightlies)
| 
| Hi,
| 
| Am Dienstag, den 04.02.2014, 08:04 +0000 schrieb Simon Peyton Jones:
| > I want just to say thank you for thinking about this.  We badly need
| better nightly-builds for GHC, on a variety of platforms
| > a) to identify regressions, preferably to the actually commit that
| >    caused it, so Austin's big red message can go to the right person
| 
| I believe we can do better, so that Austin?s big red message does not
| have to be written in the first place.
| 
| Here is what I have in mind, and I?ll volunteer to implement it if
| people think it is a good idea and I get the resources/permissions:
| 
| Proposal
| ~~~~~~~~
| 
| Nobody gets to push to master directly. Instead, every push to master
| is
| diverted? to a temporary branch "validating/<some id>". One of our
| servers detects the appearance of such a branch and will
|  * check it out,
|  * validate it,
|  * if ok: check if master can still be fast-forward?ed to it,
|  * if yes: push to master.
| 
| If it does not validate, or if master has changed in between, the
| branch
| will be moved to failed/<some id>, and a message is sent to the pushing
| developer?, including a tail of the log and a link to the full log.
| 
| Systems can fail, and maybe nothing validates anymore for reasons not
| easily fixable. For that case, a backdoor is available: Pushes to the
| branch "master-unchecked" will be moved to master, well, unchecked.
| 
| Benefits:
|  * It is guaranteed that master has validated at least once somewhere.
|    I.e. no need to ask on the mailing list ?does master validate for
| you
|    right now??
|  * It is now ok to do changes that are ?obviously correct? (comment
|    changes, removing dead code, code reformatting) without having
|    to validate manually, which _saves developer time_ (our most
| precious
|    resource).
| 
| Downsides:
|  * When two commits are racing for master, one will be rejected for
|    being a non-fast-forward commit. The user will then have to merge
|    or rebase and try again.
|    But: The same would be true if he was validating locally (unless he
|    does not validate the merge/rebase, in which case we are again where
|    we don?t want to be: Unvalidated versions in master.)
| 
| 
| Is this something you would what, or could live with?
| 
| If it is technically feasible (given our hardware constraints,
| repository structure and git?s feature) is a different question, which
| needs to be discussed afterwards.
| 
| Greetings,
| Joachim
| 
| 
| 
| ? Might not be possible transparently
| (http://stackoverflow.com/questions/21362833), but for the sake of
| argument and workflow design, assume it was.
| ? As an approximation: The committer of the latest patch.
| 
| PS: I?m also considering (but not pushing hard) for a stronger variant
| as follows. We do not need to discuss that now and should, if at all,
| start the with the proposal above. I?m just adding it to show where
| this
| is going ...
| 
| Stronger proposal
| ~~~~~~~~~~~~~~~~~
| 
|         Every commit in master needs to be validated!
| I tend to make sure that all patches on my branch validate individually
| (git rebase -i -x "./validate" is a great tool here, you should use it!
| ). Contributors who do not want to go through that trouble should then
| use "git merge --squash" to produce a single commit from their branch.
| 
| This would make the git history more useful for things like bitsecting.
| 
| 
| 
| --
| Joachim Breitner
|   e-Mail: mail at joachim-breitner.de
|   Homepage: http://www.joachim-breitner.de
|   Jabber-ID: nomeata at joachim-breitner.de


From carter.schonwald at gmail.com  Tue Feb  4 18:03:00 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 4 Feb 2014 13:03:00 -0500
Subject: Pre-Master checks (Was: Nightlies)
In-Reply-To: <59543203684B2244980D7E4057D5FBC148764927@DB3EX14MBXC312.europe.corp.microsoft.com>
References: <52E4714B.5060905@fuuzetsu.co.uk> <1390734969.2515.6.camel@kirk>
 <CAEs96n0i0nQ+yqCq4rmCh4cR8Ph_cAH1eoQ7WhitEUOcTKACDQ@mail.gmail.com>
 <CAEs96n3Aj_qtmPVKsO34WOrbfntduyoo0Y-ggbJVJjCjWSj+Vw@mail.gmail.com>
 <1390816044.2549.3.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>
 <1391506898.2719.23.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148764927@DB3EX14MBXC312.europe.corp.microsoft.com>
Message-ID: <CAHYVw0yiuSrtJ8eLRC-hcStuOd+UZr9esC2e+w18WR34RjxOCQ@mail.gmail.com>

one point in the design space (mind you one i'm not going to advocate) is
the testing / merging workflow that the Mozilla folks are doing for rust.
 Every patch / pull request gets tested by their build bot before merging.
Does make the commits on master look pretty mess / mergy though.

mind you its a bit tightly coupled to github, but some of the ideas *might*
be a good strawman.  Likewise, how does eg LLVM/Clang manage its
testing infrastructure?  How does GCC manage it?


On Tue, Feb 4, 2014 at 12:56 PM, Simon Peyton Jones
<simonpj at microsoft.com>wrote:

> I can see advantages here, similar to Richard.  I'm just a bit worried
> about keeping all those branches straight in my head.
>
> Who names all these temporary branches?  Does someone delete them so they
> don't accumulate and dominate the branch list?
>
> Would need careful documenting, so that new people know exactly what to do.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> | Joachim Breitner
> | Sent: 04 February 2014 09:42
> | To: ghc-devs at haskell.org
> | Subject: Re: Pre-Master checks (Was: Nightlies)
> |
> | Hi,
> |
> | Am Dienstag, den 04.02.2014, 08:04 +0000 schrieb Simon Peyton Jones:
> | > I want just to say thank you for thinking about this.  We badly need
> | better nightly-builds for GHC, on a variety of platforms
> | > a) to identify regressions, preferably to the actually commit that
> | >    caused it, so Austin's big red message can go to the right person
> |
> | I believe we can do better, so that Austin?s big red message does not
> | have to be written in the first place.
> |
> | Here is what I have in mind, and I?ll volunteer to implement it if
> | people think it is a good idea and I get the resources/permissions:
> |
> | Proposal
> | ~~~~~~~~
> |
> | Nobody gets to push to master directly. Instead, every push to master
> | is
> | diverted? to a temporary branch "validating/<some id>". One of our
> | servers detects the appearance of such a branch and will
> |  * check it out,
> |  * validate it,
> |  * if ok: check if master can still be fast-forward?ed to it,
> |  * if yes: push to master.
> |
> | If it does not validate, or if master has changed in between, the
> | branch
> | will be moved to failed/<some id>, and a message is sent to the pushing
> | developer?, including a tail of the log and a link to the full log.
> |
> | Systems can fail, and maybe nothing validates anymore for reasons not
> | easily fixable. For that case, a backdoor is available: Pushes to the
> | branch "master-unchecked" will be moved to master, well, unchecked.
> |
> | Benefits:
> |  * It is guaranteed that master has validated at least once somewhere.
> |    I.e. no need to ask on the mailing list ?does master validate for
> | you
> |    right now??
> |  * It is now ok to do changes that are ?obviously correct? (comment
> |    changes, removing dead code, code reformatting) without having
> |    to validate manually, which _saves developer time_ (our most
> | precious
> |    resource).
> |
> | Downsides:
> |  * When two commits are racing for master, one will be rejected for
> |    being a non-fast-forward commit. The user will then have to merge
> |    or rebase and try again.
> |    But: The same would be true if he was validating locally (unless he
> |    does not validate the merge/rebase, in which case we are again where
> |    we don?t want to be: Unvalidated versions in master.)
> |
> |
> | Is this something you would what, or could live with?
> |
> | If it is technically feasible (given our hardware constraints,
> | repository structure and git?s feature) is a different question, which
> | needs to be discussed afterwards.
> |
> | Greetings,
> | Joachim
> |
> |
> |
> | ? Might not be possible transparently
> | (http://stackoverflow.com/questions/21362833), but for the sake of
> | argument and workflow design, assume it was.
> | ? As an approximation: The committer of the latest patch.
> |
> | PS: I?m also considering (but not pushing hard) for a stronger variant
> | as follows. We do not need to discuss that now and should, if at all,
> | start the with the proposal above. I?m just adding it to show where
> | this
> | is going ...
> |
> | Stronger proposal
> | ~~~~~~~~~~~~~~~~~
> |
> |         Every commit in master needs to be validated!
> | I tend to make sure that all patches on my branch validate individually
> | (git rebase -i -x "./validate" is a great tool here, you should use it!
> | ). Contributors who do not want to go through that trouble should then
> | use "git merge --squash" to produce a single commit from their branch.
> |
> | This would make the git history more useful for things like bitsecting.
> |
> |
> |
> | --
> | Joachim Breitner
> |   e-Mail: mail at joachim-breitner.de
> |   Homepage: http://www.joachim-breitner.de
> |   Jabber-ID: nomeata at joachim-breitner.de
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/b60134f8/attachment.html>

From nicolas.frisby at gmail.com  Tue Feb  4 18:08:44 2014
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Tue, 4 Feb 2014 12:08:44 -0600
Subject: please elaborate on comment for base:Data.Type.Equality.(==)?
Message-ID: <CADfHYo4OR0Tt39svXLuw1AYmiKPBQsRZX8sn5-TfMB1yUM3=aQ@mail.gmail.com>

[CC'ing Richard, as I'm guessing he's the author of the comment.]

I have a question regarding the comment on the type
family Data.Type.Equality.(==).

  "A poly-kinded instance [of ==] is *not* provided, as a recursive
definition for algebraic kinds is generally more useful."

Can someone elaborate on "generally more useful".

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/1d7bc626/attachment.html>

From eir at cis.upenn.edu  Tue Feb  4 19:20:52 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 4 Feb 2014 14:20:52 -0500
Subject: please elaborate on comment for base:Data.Type.Equality.(==)?
In-Reply-To: <CADfHYo4OR0Tt39svXLuw1AYmiKPBQsRZX8sn5-TfMB1yUM3=aQ@mail.gmail.com>
References: <CADfHYo4OR0Tt39svXLuw1AYmiKPBQsRZX8sn5-TfMB1yUM3=aQ@mail.gmail.com>
Message-ID: <2617F99A-2DC8-4945-8A1E-AF7B9EFE2891@cis.upenn.edu>

Say I have

> data Nat = Zero | Succ Nat
> data SNat :: Nat -> * where
>   SZero :: SNat Zero
>   SSucc :: SNat n -> SNat (Succ n)
> data SBool :: Bool -> * where
>   SFalse :: SBool False
>   STrue :: SBool True

Now, I want

> eq :: SNat a -> SNat b-> SBool (a == b)
> eq SZero SZero = STrue
> eq (SSucc _) SZero = SFalse
> eq SZero (SSucc _) = SFalse
> eq (SSucc c) (SSucc d) = eq c d

Does that type check?

Suppose we have

> type family EqPoly (a :: k) (b :: k) :: Bool where
>   EqPoly a a = True
>   EqPoly a b = False
> type instance a == b = EqPoly a b

(Let's forget that the instance there would overlap with any other instance.)

Now, in the last line of `eq`, we have that the type of `eq c d` is `SBool (e == f)` where (c :: SNat e), (d :: SNat f), (a ~ Succ e), and (b ~ Succ f). But, does ((e == f) ~ (a == b))? It would need to for the last line of `eq` to type-check. Alas, there is no way to proof ((e == f) ~ (a == b)), so we're hosed.

Now, suppose

> type family EqNat a b where
>   EqNat Zero Zero = True
>   EqNat (Succ n) (Succ m) = EqNat n m
>   EqNat Zero (Succ n) = False
>   EqNat (Succ n) Zero = False
> type instance a == b = EqNat a b

Here, we know that (a ~ Succ e) and (b ~ Succ f), so we compute that (a == b) ~ (EqNat (Succ e) (Succ f)) ~ (EqNat e f) ~ (e == f). Huzzah!

Thus, the second version is better.

I hope this helps!
Richard

On Feb 4, 2014, at 1:08 PM, Nicolas Frisby <nicolas.frisby at gmail.com> wrote:

> [CC'ing Richard, as I'm guessing he's the author of the comment.]
> 
> I have a question regarding the comment on the type family Data.Type.Equality.(==).
> 
>   "A poly-kinded instance [of ==] is not provided, as a recursive definition for algebraic kinds is generally more useful."
> 
> Can someone elaborate on "generally more useful".
> 
> Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/c1aef559/attachment-0001.html>

From nicolas.frisby at gmail.com  Tue Feb  4 19:32:38 2014
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Tue, 4 Feb 2014 13:32:38 -0600
Subject: please elaborate on comment for base:Data.Type.Equality.(==)?
In-Reply-To: <2617F99A-2DC8-4945-8A1E-AF7B9EFE2891@cis.upenn.edu>
References: <CADfHYo4OR0Tt39svXLuw1AYmiKPBQsRZX8sn5-TfMB1yUM3=aQ@mail.gmail.com>
 <2617F99A-2DC8-4945-8A1E-AF7B9EFE2891@cis.upenn.edu>
Message-ID: <CADfHYo47BK3qsHHDkmT7QZL+uS0FSRmeO8gm8sV6fJ97omLYZQ@mail.gmail.com>

Great. Thanks.

This reminds me of one emphasis of McBride's lectures and keynotes
regarding Agda: it's generally a Good Thing for the shape of your type
level recursion to match your value level recursion.
On Feb 4, 2014 1:20 PM, "Richard Eisenberg" <eir at cis.upenn.edu> wrote:

> Say I have
>
> > data Nat = Zero | Succ Nat
> > data SNat :: Nat -> * where
> >   SZero :: SNat Zero
> >   SSucc :: SNat n -> SNat (Succ n)
> > data SBool :: Bool -> * where
> >   SFalse :: SBool False
> >   STrue :: SBool True
>
> Now, I want
>
> > eq :: SNat a -> SNat b-> SBool (a == b)
> > eq SZero SZero = STrue
> > eq (SSucc _) SZero = SFalse
> > eq SZero (SSucc _) = SFalse
> > eq (SSucc c) (SSucc d) = eq c d
>
> Does that type check?
>
> Suppose we have
>
> > type family EqPoly (a :: k) (b :: k) :: Bool where
> >   EqPoly a a = True
> >   EqPoly a b = False
> > type instance a == b = EqPoly a b
>
> (Let's forget that the instance there would overlap with any other
> instance.)
>
> Now, in the last line of `eq`, we have that the type of `eq c d` is `SBool
> (e == f)` where (c :: SNat e), (d :: SNat f), (a ~ Succ e), and (b ~ Succ
> f). But, does ((e == f) ~ (a == b))? It would need to for the last line of
> `eq` to type-check. Alas, there is no way to proof ((e == f) ~ (a == b)),
> so we're hosed.
>
> Now, suppose
>
> > type family EqNat a b where
> >   EqNat Zero Zero = True
> >   EqNat (Succ n) (Succ m) = EqNat n m
> >   EqNat Zero (Succ n) = False
> >   EqNat (Succ n) Zero = False
> > type instance a == b = EqNat a b
>
> Here, we know that (a ~ Succ e) and (b ~ Succ f), so we compute that (a ==
> b) ~ (EqNat (Succ e) (Succ f)) ~ (EqNat e f) ~ (e == f). Huzzah!
>
> Thus, the second version is better.
>
> I hope this helps!
> Richard
>
> On Feb 4, 2014, at 1:08 PM, Nicolas Frisby <nicolas.frisby at gmail.com>
> wrote:
>
> [CC'ing Richard, as I'm guessing he's the author of the comment.]
>
> I have a question regarding the comment on the type
> family Data.Type.Equality.(==).
>
>   "A poly-kinded instance [of ==] is *not* provided, as a recursive
> definition for algebraic kinds is generally more useful."
>
> Can someone elaborate on "generally more useful".
>
> Thank you.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/05a8b28d/attachment.html>

From rrnewton at gmail.com  Tue Feb  4 21:11:38 2014
From: rrnewton at gmail.com (Ryan Newton)
Date: Tue, 4 Feb 2014 16:11:38 -0500
Subject: [GHC] #8704: Use GHC.Exts.build in randoms,
 randomRs to achieve fusion
In-Reply-To: <59543203684B2244980D7E4057D5FBC148761B98@DB3EX14MBXC312.europe.corp.microsoft.com>
References: <043.229b17c6b043d171889e26950a7c81e6@haskell.org>
 <058.101cb880f5abe7be42fa28550c431dbd@haskell.org>
 <59543203684B2244980D7E4057D5FBC148761B98@DB3EX14MBXC312.europe.corp.microsoft.com>
Message-ID: <CACYs5AaKiqLcmANpmq24S7Ube6hwaAqqG=HLDbQJge5KV0YKyg@mail.gmail.com>

Thanks, no I was not CC'd.  Now I've added myself  to ghc-tickets
(alongside libraries, ghc-devs, haskell-cafe ... whew ;-) .)

An initial inspection of the patch looks fine.  I'll go ahead and merge it.

However, I remind everyone that the priority should be replacing random
entirely.  It's slow and known to be a bad algorithm (for the splitting
bit).  Koen Classen & co had an implementation in the Haskell symposium
paper that may be a candidate.




On Tue, Feb 4, 2014 at 3:04 AM, Simon Peyton Jones <simonpj at microsoft.com>wrote:

> Hi Ryan
>
> Are you on this thread?   You probably should be!
>
> Simon
>
> | -----Original Message-----
> | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of
> | GHC
> | Sent: 27 January 2014 18:49
> | Cc: ghc-tickets at haskell.org
> | Subject: Re: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to
> | achieve fusion
> |
> | #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion
> | -------------------------------------+---------------------------------
> | ---
> |         Reporter:  ion1              |            Owner:
> |             Type:  feature request   |           Status:  patch
> |         Priority:  normal            |        Milestone:
> |        Component:  libraries/random  |          Version:  7.6.3
> |       Resolution:                    |         Keywords:  fusion
> | Operating System:  Unknown/Multiple  |     Architecture:
> | Unknown/Multiple
> |  Type of failure:  None/Unknown      |       Difficulty:  Unknown
> |        Test Case:                    |       Blocked By:
> |         Blocking:                    |  Related Tickets:  #4218
> | -------------------------------------+---------------------------------
> | ---
> |
> | Comment (by nomeata):
> |
> |  Thanks. From my POV it is worth adding even if you can't measure a
> |  performance gain; it is still good to know that nice code is being
> |  generated. But of course it is up to Ryan Newton (random maintainer)
> | to
> |  decide this.
> |
> | --
> | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8704#comment:4>
> | GHC <http://www.haskell.org/ghc/>
> | The Glasgow Haskell Compiler
> | _______________________________________________
> | ghc-tickets mailing list
> | ghc-tickets at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-tickets
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/6d2a8283/attachment.html>

From afarmer at ittc.ku.edu  Tue Feb  4 21:22:56 2014
From: afarmer at ittc.ku.edu (Andrew Farmer)
Date: Tue, 4 Feb 2014 15:22:56 -0600
Subject: Summarize #7602
Message-ID: <CAJ14jR89-te-OR6r34UjNbkcB-9p4PpNUYkFbcOo1TBzPHzu2w@mail.gmail.com>

I know that #7602 has been mentioned as a final loose end in the RC. I was
wondering if someone in the know could summarize its status in regards to
how it effects GHC users.

Feel free to be blisteringly brief... ;-) I'm just looking for things like:
"this is a non-issue on modern OS X/Clang" or "it'll be fixed soon just be
patient" or "we've done our part, this is Apple's problem now".

I gave the trac thread a read-through, but there seems to be several
degrees of flexibility/workarounds, so I'm still not sure if this is
something I should worry about on my OS X machine.

Thanks for your cycles!
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/ecd0f3df/attachment.html>

From austin at well-typed.com  Tue Feb  4 21:31:28 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 4 Feb 2014 15:31:28 -0600
Subject: Summarize #7602
In-Reply-To: <CAJ14jR89-te-OR6r34UjNbkcB-9p4PpNUYkFbcOo1TBzPHzu2w@mail.gmail.com>
References: <CAJ14jR89-te-OR6r34UjNbkcB-9p4PpNUYkFbcOo1TBzPHzu2w@mail.gmail.com>
Message-ID: <CAEs96n33UdV4dN3Zkomu1qSxV0qTrtZMngaa3W8hf5WUoFfEvQ@mail.gmail.com>

TL;DR OS X suffers a performance hit when build with llvm-gcc/clang.
The binary builds are built this way. The fix I outlined in the ticket
(a fast `pthread_getspecific`/`pthread_setspecific`) could still work
to recover most of the performance, but Apple accidentally messed up
the Mavericks source code release, so I'm not sure if anything
regarding the pthread implementation has changed. If it hasn't, then I
think it should be reasonably easy to fix with some testing.

(The ticket is a bit of a long and dry read I'm afraid.)

On Tue, Feb 4, 2014 at 3:22 PM, Andrew Farmer <afarmer at ittc.ku.edu> wrote:
> I know that #7602 has been mentioned as a final loose end in the RC. I was
> wondering if someone in the know could summarize its status in regards to
> how it effects GHC users.
>
> Feel free to be blisteringly brief... ;-) I'm just looking for things like:
> "this is a non-issue on modern OS X/Clang" or "it'll be fixed soon just be
> patient" or "we've done our part, this is Apple's problem now".
>
> I gave the trac thread a read-through, but there seems to be several degrees
> of flexibility/workarounds, so I'm still not sure if this is something I
> should worry about on my OS X machine.
>
> Thanks for your cycles!
> Andrew
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From ggreif at gmail.com  Tue Feb  4 21:42:19 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Tue, 4 Feb 2014 22:42:19 +0100
Subject: Pre-Master checks (Was: Nightlies)
In-Reply-To: <CAHYVw0yiuSrtJ8eLRC-hcStuOd+UZr9esC2e+w18WR34RjxOCQ@mail.gmail.com>
References: <52E4714B.5060905@fuuzetsu.co.uk> <1390734969.2515.6.camel@kirk>
 <CAEs96n0i0nQ+yqCq4rmCh4cR8Ph_cAH1eoQ7WhitEUOcTKACDQ@mail.gmail.com>
 <CAEs96n3Aj_qtmPVKsO34WOrbfntduyoo0Y-ggbJVJjCjWSj+Vw@mail.gmail.com>
 <1390816044.2549.3.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>
 <1391506898.2719.23.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148764927@DB3EX14MBXC312.europe.corp.microsoft.com>
 <CAHYVw0yiuSrtJ8eLRC-hcStuOd+UZr9esC2e+w18WR34RjxOCQ@mail.gmail.com>
Message-ID: <CAK-hX0=ToJ8pwsFL5YGA_2WdEnnKVAcqF=vxy_QuYEB9mzcwXw@mail.gmail.com>

On 2/4/14, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> one point in the design space (mind you one i'm not going to advocate) is
> the testing / merging workflow that the Mozilla folks are doing for rust.
>  Every patch / pull request gets tested by their build bot before merging.
> Does make the commits on master look pretty mess / mergy though.
>
> mind you its a bit tightly coupled to github, but some of the ideas *might*
> be a good strawman.  Likewise, how does eg LLVM/Clang manage its
> testing infrastructure?  How does GCC manage it?

LLVM devs need to run 'make check' before committing to the repo. This
runs 8000+ tests in about 30 seconds.

Then there is the bot infrastructure at http://lab.llvm.org:8011/console ,
and who breaks a target is alerted by mail. But this applies to all
committers whose changes entered into (slow) builds. It is not
commit-exact, though better on the fast bots.

Cheers,

    Gabor

>
>
> On Tue, Feb 4, 2014 at 12:56 PM, Simon Peyton Jones
> <simonpj at microsoft.com>wrote:
>
>> I can see advantages here, similar to Richard.  I'm just a bit worried
>> about keeping all those branches straight in my head.
>>
>> Who names all these temporary branches?  Does someone delete them so they
>> don't accumulate and dominate the branch list?
>>
>> Would need careful documenting, so that new people know exactly what to
>> do.
>>
>> Simon
>>
>> | -----Original Message-----
>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>> | Joachim Breitner
>> | Sent: 04 February 2014 09:42
>> | To: ghc-devs at haskell.org
>> | Subject: Re: Pre-Master checks (Was: Nightlies)
>> |
>> | Hi,
>> |
>> | Am Dienstag, den 04.02.2014, 08:04 +0000 schrieb Simon Peyton Jones:
>> | > I want just to say thank you for thinking about this.  We badly need
>> | better nightly-builds for GHC, on a variety of platforms
>> | > a) to identify regressions, preferably to the actually commit that
>> | >    caused it, so Austin's big red message can go to the right person
>> |
>> | I believe we can do better, so that Austin's big red message does not
>> | have to be written in the first place.
>> |
>> | Here is what I have in mind, and I'll volunteer to implement it if
>> | people think it is a good idea and I get the resources/permissions:
>> |
>> | Proposal
>> | ~~~~~~~~
>> |
>> | Nobody gets to push to master directly. Instead, every push to master
>> | is
>> | diverted? to a temporary branch "validating/<some id>". One of our
>> | servers detects the appearance of such a branch and will
>> |  * check it out,
>> |  * validate it,
>> |  * if ok: check if master can still be fast-forward'ed to it,
>> |  * if yes: push to master.
>> |
>> | If it does not validate, or if master has changed in between, the
>> | branch
>> | will be moved to failed/<some id>, and a message is sent to the pushing
>> | developer?, including a tail of the log and a link to the full log.
>> |
>> | Systems can fail, and maybe nothing validates anymore for reasons not
>> | easily fixable. For that case, a backdoor is available: Pushes to the
>> | branch "master-unchecked" will be moved to master, well, unchecked.
>> |
>> | Benefits:
>> |  * It is guaranteed that master has validated at least once somewhere.
>> |    I.e. no need to ask on the mailing list "does master validate for
>> | you
>> |    right now?"
>> |  * It is now ok to do changes that are "obviously correct" (comment
>> |    changes, removing dead code, code reformatting) without having
>> |    to validate manually, which _saves developer time_ (our most
>> | precious
>> |    resource).
>> |
>> | Downsides:
>> |  * When two commits are racing for master, one will be rejected for
>> |    being a non-fast-forward commit. The user will then have to merge
>> |    or rebase and try again.
>> |    But: The same would be true if he was validating locally (unless he
>> |    does not validate the merge/rebase, in which case we are again where
>> |    we don't want to be: Unvalidated versions in master.)
>> |
>> |
>> | Is this something you would what, or could live with?
>> |
>> | If it is technically feasible (given our hardware constraints,
>> | repository structure and git's feature) is a different question, which
>> | needs to be discussed afterwards.
>> |
>> | Greetings,
>> | Joachim
>> |
>> |
>> |
>> | ? Might not be possible transparently
>> | (http://stackoverflow.com/questions/21362833), but for the sake of
>> | argument and workflow design, assume it was.
>> | ? As an approximation: The committer of the latest patch.
>> |
>> | PS: I'm also considering (but not pushing hard) for a stronger variant
>> | as follows. We do not need to discuss that now and should, if at all,
>> | start the with the proposal above. I'm just adding it to show where
>> | this
>> | is going ...
>> |
>> | Stronger proposal
>> | ~~~~~~~~~~~~~~~~~
>> |
>> |         Every commit in master needs to be validated!
>> | I tend to make sure that all patches on my branch validate individually
>> | (git rebase -i -x "./validate" is a great tool here, you should use it!
>> | ). Contributors who do not want to go through that trouble should then
>> | use "git merge --squash" to produce a single commit from their branch.
>> |
>> | This would make the git history more useful for things like bitsecting.
>> |
>> |
>> |
>> | --
>> | Joachim Breitner
>> |   e-Mail: mail at joachim-breitner.de
>> |   Homepage: http://www.joachim-breitner.de
>> |   Jabber-ID: nomeata at joachim-breitner.de
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>

From carter.schonwald at gmail.com  Tue Feb  4 21:54:16 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 4 Feb 2014 16:54:16 -0500
Subject: Summarize #7602
In-Reply-To: <CAEs96n33UdV4dN3Zkomu1qSxV0qTrtZMngaa3W8hf5WUoFfEvQ@mail.gmail.com>
References: <CAJ14jR89-te-OR6r34UjNbkcB-9p4PpNUYkFbcOo1TBzPHzu2w@mail.gmail.com>
 <CAEs96n33UdV4dN3Zkomu1qSxV0qTrtZMngaa3W8hf5WUoFfEvQ@mail.gmail.com>
Message-ID: <CAHYVw0y3yLQTpXOrJMXTjmvn4MR4Zs9gu0e917c+4a+PFKQ6qw@mail.gmail.com>

@Andrew, if you have GHC built with a real GCC, theres no perf issue.
(though if you built GHC with clang, thereis)

I've a bindist thats from the 7.8 branch from 5 days ago that I built wiht
GCC-4.8 here
https://github.com/cartazio/ghc/releases/tag/carters-build-7.8-preRC1
you may need to patch the settings file to point to your own GCC version

point being, no issue if you built with GCC. :)


On Tue, Feb 4, 2014 at 4:31 PM, Austin Seipp <austin at well-typed.com> wrote:

> TL;DR OS X suffers a performance hit when build with llvm-gcc/clang.
> The binary builds are built this way. The fix I outlined in the ticket
> (a fast `pthread_getspecific`/`pthread_setspecific`) could still work
> to recover most of the performance, but Apple accidentally messed up
> the Mavericks source code release, so I'm not sure if anything
> regarding the pthread implementation has changed. If it hasn't, then I
> think it should be reasonably easy to fix with some testing.
>
> (The ticket is a bit of a long and dry read I'm afraid.)
>
> On Tue, Feb 4, 2014 at 3:22 PM, Andrew Farmer <afarmer at ittc.ku.edu> wrote:
> > I know that #7602 has been mentioned as a final loose end in the RC. I
> was
> > wondering if someone in the know could summarize its status in regards to
> > how it effects GHC users.
> >
> > Feel free to be blisteringly brief... ;-) I'm just looking for things
> like:
> > "this is a non-issue on modern OS X/Clang" or "it'll be fixed soon just
> be
> > patient" or "we've done our part, this is Apple's problem now".
> >
> > I gave the trac thread a read-through, but there seems to be several
> degrees
> > of flexibility/workarounds, so I'm still not sure if this is something I
> > should worry about on my OS X machine.
> >
> > Thanks for your cycles!
> > Andrew
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/24b43bef/attachment.html>

From lukexipd at gmail.com  Wed Feb  5 02:22:03 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Tue, 4 Feb 2014 18:22:03 -0800
Subject: GHC iOS make binary-dist
Message-ID: <CAGo83CjC-zE4qi9076hPwsygrOdA40B=q2L0j7a=11tGV5zFAA@mail.gmail.com>

Hi folks,

I'm all set to release binaries for GHC iOS (arm and i386 simulator), but
didn't realize the "make binary-dist" machinery is broken for
cross-compilers.

I'm starting work on it but will be fumbling in the dark a bit so if anyone
has any knowledge or link or ideas on where to look, I'd love to hear them!

Here's the output of "make binary-dist" on a tree after a successful "make"
for arm-apple-darwin10 (which will "make install" perfectly).
http://lpaste.net/99475

Cheers
Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/1e1fa199/attachment.html>

From johan.tibell at gmail.com  Wed Feb  5 04:07:07 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 4 Feb 2014 20:07:07 -0800
Subject: Cabal release for 7.8
In-Reply-To: <871tzjjqci.fsf@gmail.com>
References: <CAK-tuPaoZXGMpFoVLRfshE2b5GNhC9Tn_r4R9mYTg487RAZ_9A@mail.gmail.com>
 <871tzjjqci.fsf@gmail.com>
Message-ID: <CAK-tuPaYse5fuoukzvAsvydhYWCOFEa3+KGmdrydkmu-TywcLw@mail.gmail.com>

On Mon, Feb 3, 2014 at 11:21 PM, Herbert Valerio Riedel
<hvriedel at gmail.com>wrote:

> On 2014-02-04 at 06:10:24 +0100, Johan Tibell wrote:
> > I guess we need one last cabal release for 7.8? Are we ready for that
> now,
> > or do you expect any more 7.8 change that will require cabal changes?
>
> The RC1 has just started, and I'd rather wait a little more till we're
> closer to a final release...
>
> PS: We'll also need a 'cabal-install' release, as the current 1.18.0.2
>     doesn't build with GHC 7.8RC1
>

I will make one as soon as the last Cabal release is out. Please let me
know when you're ready for that.

PS2: would it be possible to have
>
> https://github.com/haskell/cabal/commit/32dddcb1f0495a633ab806e0bcd43816cac67b03
>      picked up for 1.18 (assuming it applies cleanly)? It would make it
>      easier to generate documentation tarballs for uploading to Hackage
>      w/o needing to 'sed' away all 'file:///' prefixes.
>

This is already in the 1.18 branch as
1eb2181fae2b706ee8024d3f8fef104b5089b1a9. I intend to release the following
in the last patch release in the 1.18 series:

0d5ffeb91075739246627da17bda945aedc6a427 Disable
TemplateHaskell/{dynamic,profiling} tests on Travis.
ee6d1cf5cefe18f6d74ed379af21d92f8b0ae92d Don't use -dylib-install-name on
OS X with GHC > 7.8.
e97aa58f68519db54de1c62339459ebb88aed069 Add some more OS aliases.
1eb2181fae2b706ee8024d3f8fef104b5089b1a9 Fix the haddock --html-location=
for relative URLs
43f1e2a5a81688eb186102c684bb4d134ca3c63a Add CPP pragma to D.Simple.Setup
8aea1f994c526f0f43ac5b1b29b04e9ab4565b01 Bump Cabal version number to
1.18.1.3.
cb0ad7a77457ef77c34ab4b6d54e2bdc5a972fa1 Default 'library-for-ghci' to True
on Windows.
345650535993522a0fd75a53a4c681c5d3027030 Small warning.
8d168c5fbbcd01ce0c5ff3d9c4a959b4c0819746 Documentation fix.
e93b01dfb34ab1de6fbfaec1b5805eddbb8a46f5
s/extra-html-files/extra-doc-files/.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/5ae3fbcc/attachment.html>

From lukexipd at gmail.com  Wed Feb  5 04:59:32 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Tue, 4 Feb 2014 20:59:32 -0800
Subject: GHC iOS make binary-dist
In-Reply-To: <CAGo83CjC-zE4qi9076hPwsygrOdA40B=q2L0j7a=11tGV5zFAA@mail.gmail.com>
References: <CAGo83CjC-zE4qi9076hPwsygrOdA40B=q2L0j7a=11tGV5zFAA@mail.gmail.com>
Message-ID: <CAGo83Cgr97xgj=9FaoKo6tNXxYmEwab6AVh-Vs_rE_jjzZ8r4w@mail.gmail.com>

OK, I've made a bit of progress here.

Again, I have very little understanding of the binary-dist system so I hope
this isn't nonsense.

The utils/ghc-cabal/dist-install/build/tmp/ghc-cabal and
utils/ghc-pwd/dist-install/build/tmp/ghc-pwd
executables have .a extensions, which is a bug, but more importantly are
built for arm and thus can't be used.

lukexi at thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file
utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a
utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a: Mach-O executable arm

lukexi at thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file
utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a
utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a: Mach-O executable arm

So I tried switching them to the inplace/bin/ghc-cabal and
utils/ghc-pwd/dist-boot/ghc-pwd copies, respectively, with this patch:
http://lpaste.net/99485

This let me build the .tar.gz without errors, and ./configure it fine, but
make install fails here now.
"inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install
"/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc"
"/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc-pkg"
"/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129" '' '/usr/local'
'/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129'
'/usr/local/share/doc/ghc/html/libraries' NO
ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi
magic number mismatch: old/corrupt interface file? (wanted 33214052, got
129742)

http://lpaste.net/99486

(looks like a missing dash in the CrossCompilePrefix as well but that's a
minor issue)

Does this offer any clues?

Cheers
Luke


On Tue, Feb 4, 2014 at 6:22 PM, Luke Iannini <lukexipd at gmail.com> wrote:

> Hi folks,
>
> I'm all set to release binaries for GHC iOS (arm and i386 simulator), but
> didn't realize the "make binary-dist" machinery is broken for
> cross-compilers.
>
> I'm starting work on it but will be fumbling in the dark a bit so if
> anyone has any knowledge or link or ideas on where to look, I'd love to
> hear them!
>
> Here's the output of "make binary-dist" on a tree after a successful
> "make" for arm-apple-darwin10 (which will "make install" perfectly).
> http://lpaste.net/99475
>
> Cheers
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/d807bdd3/attachment.html>

From lukexipd at gmail.com  Wed Feb  5 05:24:16 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Tue, 4 Feb 2014 21:24:16 -0800
Subject: GHC iOS make binary-dist
In-Reply-To: <CAGo83Cgr97xgj=9FaoKo6tNXxYmEwab6AVh-Vs_rE_jjzZ8r4w@mail.gmail.com>
References: <CAGo83CjC-zE4qi9076hPwsygrOdA40B=q2L0j7a=11tGV5zFAA@mail.gmail.com>
 <CAGo83Cgr97xgj=9FaoKo6tNXxYmEwab6AVh-Vs_rE_jjzZ8r4w@mail.gmail.com>
Message-ID: <CAGo83Cjp4iAUqUumxt8HT1S7fw_WJWnLC--XOk=t5fMWq-YxZQ@mail.gmail.com>

Aha. Looks like the "target word size" is incorrect in the binary-dist
version.
Here's arm-apple-darwin10ghc --info (i.e., the binary-dist version)
http://lpaste.net/99489

and here's arm-apple-darwin10-ghc --info (from a working 'make install'ed
version)
http://lpaste.net/99490

A bad settings file, I guess. I'll see if I can fix that...
Cheers
Luke


On Tue, Feb 4, 2014 at 8:59 PM, Luke Iannini <lukexipd at gmail.com> wrote:

> OK, I've made a bit of progress here.
>
> Again, I have very little understanding of the binary-dist system so I
> hope this isn't nonsense.
>
> The utils/ghc-cabal/dist-install/build/tmp/ghc-cabal and utils/ghc-pwd/dist-install/build/tmp/ghc-pwd
> executables have .a extensions, which is a bug, but more importantly are
> built for arm and thus can't be used.
>
> lukexi at thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file
> utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a
> utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a: Mach-O executable arm
>
> lukexi at thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file
> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a
> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a: Mach-O executable arm
>
> So I tried switching them to the inplace/bin/ghc-cabal and
> utils/ghc-pwd/dist-boot/ghc-pwd copies, respectively, with this patch:
> http://lpaste.net/99485
>
> This let me build the .tar.gz without errors, and ./configure it fine, but
> make install fails here now.
> "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install
> "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc"
> "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc-pkg"
> "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129" '' '/usr/local'
> '/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129'
> '/usr/local/share/doc/ghc/html/libraries' NO
> ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi
> magic number mismatch: old/corrupt interface file? (wanted 33214052, got
> 129742)
>
> http://lpaste.net/99486
>
> (looks like a missing dash in the CrossCompilePrefix as well but that's a
> minor issue)
>
> Does this offer any clues?
>
> Cheers
> Luke
>
>
> On Tue, Feb 4, 2014 at 6:22 PM, Luke Iannini <lukexipd at gmail.com> wrote:
>
>> Hi folks,
>>
>> I'm all set to release binaries for GHC iOS (arm and i386 simulator), but
>> didn't realize the "make binary-dist" machinery is broken for
>> cross-compilers.
>>
>> I'm starting work on it but will be fumbling in the dark a bit so if
>> anyone has any knowledge or link or ideas on where to look, I'd love to
>> hear them!
>>
>> Here's the output of "make binary-dist" on a tree after a successful
>> "make" for arm-apple-darwin10 (which will "make install" perfectly).
>> http://lpaste.net/99475
>>
>> Cheers
>> Luke
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/e51b2efa/attachment-0001.html>

From kazu at iij.ad.jp  Wed Feb  5 05:35:34 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 05 Feb 2014 14:35:34 +0900 (JST)
Subject: doc fix
Message-ID: <20140205.143534.913329123037060433.kazu@iij.ad.jp>

Hi,

If I understand correctly, NoMonomorphismRestriction is now the
default for GHC 7.8. I think that its document explicitly describes
it.

--Kazu

From lukexipd at gmail.com  Wed Feb  5 05:43:14 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Tue, 4 Feb 2014 21:43:14 -0800
Subject: GHC iOS make binary-dist
In-Reply-To: <CAGo83Cjp4iAUqUumxt8HT1S7fw_WJWnLC--XOk=t5fMWq-YxZQ@mail.gmail.com>
References: <CAGo83CjC-zE4qi9076hPwsygrOdA40B=q2L0j7a=11tGV5zFAA@mail.gmail.com>
 <CAGo83Cgr97xgj=9FaoKo6tNXxYmEwab6AVh-Vs_rE_jjzZ8r4w@mail.gmail.com>
 <CAGo83Cjp4iAUqUumxt8HT1S7fw_WJWnLC--XOk=t5fMWq-YxZQ@mail.gmail.com>
Message-ID: <CAGo83Chq5AE-m9j6h_H+ofLi2rBBVpWMZdsFsw=uqcvFo=-=Kw@mail.gmail.com>

After fixing that, and the prefix missing a "-", I've got a working make
install! Hurray!

I'll tidy this up and make a patch.

Cheers
Luke

On Tue, Feb 4, 2014 at 9:24 PM, Luke Iannini <lukexipd at gmail.com> wrote:

> Aha. Looks like the "target word size" is incorrect in the binary-dist
> version.
> Here's arm-apple-darwin10ghc --info (i.e., the binary-dist version)
> http://lpaste.net/99489
>
> and here's arm-apple-darwin10-ghc --info (from a working 'make install'ed
> version)
> http://lpaste.net/99490
>
> A bad settings file, I guess. I'll see if I can fix that...
> Cheers
> Luke
>
>
> On Tue, Feb 4, 2014 at 8:59 PM, Luke Iannini <lukexipd at gmail.com> wrote:
>
>> OK, I've made a bit of progress here.
>>
>> Again, I have very little understanding of the binary-dist system so I
>> hope this isn't nonsense.
>>
>> The utils/ghc-cabal/dist-install/build/tmp/ghc-cabal and utils/ghc-pwd/dist-install/build/tmp/ghc-pwd
>> executables have .a extensions, which is a bug, but more importantly are
>> built for arm and thus can't be used.
>>
>> lukexi at thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file
>> utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a
>> utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a: Mach-O executable arm
>>
>> lukexi at thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file
>> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a
>> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a: Mach-O executable arm
>>
>> So I tried switching them to the inplace/bin/ghc-cabal and
>> utils/ghc-pwd/dist-boot/ghc-pwd copies, respectively, with this patch:
>> http://lpaste.net/99485
>>
>> This let me build the .tar.gz without errors, and ./configure it fine,
>> but make install fails here now.
>> "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install
>> "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc"
>> "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc-pkg"
>> "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129" '' '/usr/local'
>> '/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129'
>> '/usr/local/share/doc/ghc/html/libraries' NO
>> ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi
>> magic number mismatch: old/corrupt interface file? (wanted 33214052, got
>> 129742)
>>
>> http://lpaste.net/99486
>>
>> (looks like a missing dash in the CrossCompilePrefix as well but that's a
>> minor issue)
>>
>> Does this offer any clues?
>>
>> Cheers
>> Luke
>>
>>
>> On Tue, Feb 4, 2014 at 6:22 PM, Luke Iannini <lukexipd at gmail.com> wrote:
>>
>>> Hi folks,
>>>
>>> I'm all set to release binaries for GHC iOS (arm and i386 simulator),
>>> but didn't realize the "make binary-dist" machinery is broken for
>>> cross-compilers.
>>>
>>> I'm starting work on it but will be fumbling in the dark a bit so if
>>> anyone has any knowledge or link or ideas on where to look, I'd love to
>>> hear them!
>>>
>>> Here's the output of "make binary-dist" on a tree after a successful
>>> "make" for arm-apple-darwin10 (which will "make install" perfectly).
>>> http://lpaste.net/99475
>>>
>>> Cheers
>>> Luke
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/14df0774/attachment.html>

From lukexipd at gmail.com  Wed Feb  5 06:36:02 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Tue, 4 Feb 2014 22:36:02 -0800
Subject: ghc-ios 7.8 working build
Message-ID: <CAGo83CiyCsgtrZSbpCa400tDU6e=-uQuqfSEAE5246L=nawQQQ@mail.gmail.com>

Hi all,

I believe I've worked around the issues with make binary-dist and
cross-compilation.

This should be a working binary for iOS devices
https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2

Please try ./configure && make install (it should live happily next to your
current ghc as arm-apple-darwin10-ghc) and let me know so we can have a
build ready for 7.8 RC2!

Cheers
Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/de848037/attachment.html>

From djsamperi at gmail.com  Wed Feb  5 07:35:29 2014
From: djsamperi at gmail.com (Dominick Samperi)
Date: Wed, 5 Feb 2014 02:35:29 -0500
Subject: ghc-ios 7.8 working build
In-Reply-To: <CAGo83CiyCsgtrZSbpCa400tDU6e=-uQuqfSEAE5246L=nawQQQ@mail.gmail.com>
References: <CAGo83CiyCsgtrZSbpCa400tDU6e=-uQuqfSEAE5246L=nawQQQ@mail.gmail.com>
Message-ID: <CADUbQ5i5r0GuP0GrkjKS=9vtBNkCjQGL_0025V7hfhHDrKwOdQ@mail.gmail.com>

Hello Luke,

It installed without problems under Mac OS X Mavericks and reports the
version correctly. If there is some documentation that you can point me to
I will test on my simulator and iPhone.

Thanks,
Dominick


On Wed, Feb 5, 2014 at 1:36 AM, Luke Iannini <lukexipd at gmail.com> wrote:
> Hi all,
>
> I believe I've worked around the issues with make binary-dist and
> cross-compilation.
>
> This should be a working binary for iOS devices
> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2
>
> Please try ./configure && make install (it should live happily next to your
> current ghc as arm-apple-darwin10-ghc) and let me know so we can have a
> build ready for 7.8 RC2!
>
> Cheers
> Luke
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From lukexipd at gmail.com  Wed Feb  5 09:27:51 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Wed, 5 Feb 2014 01:27:51 -0800
Subject: ghc-ios 7.8 working build
In-Reply-To: <CADUbQ5i5r0GuP0GrkjKS=9vtBNkCjQGL_0025V7hfhHDrKwOdQ@mail.gmail.com>
References: <CAGo83CiyCsgtrZSbpCa400tDU6e=-uQuqfSEAE5246L=nawQQQ@mail.gmail.com>
 <CADUbQ5i5r0GuP0GrkjKS=9vtBNkCjQGL_0025V7hfhHDrKwOdQ@mail.gmail.com>
Message-ID: <CAGo83ChC5rjpxSAOQquajndU2Wde7ZJpuvUsGtwpfGZfjoTGkQ@mail.gmail.com>

Hi Dominick and all,

That's great news!

I've created a README here:
https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md

Note that the binary posted above is only for the device. I'll post the
simulator version shortly along with instructions on how to create fat
libraries that contain both simulator and device code.

Please let me know if you have any questions or issues!

Very best
Luke


On Tue, Feb 4, 2014 at 11:35 PM, Dominick Samperi <djsamperi at gmail.com>wrote:

> Hello Luke,
>
> It installed without problems under Mac OS X Mavericks and reports the
> version correctly. If there is some documentation that you can point me to
> I will test on my simulator and iPhone.
>
> Thanks,
> Dominick
>
>
> On Wed, Feb 5, 2014 at 1:36 AM, Luke Iannini <lukexipd at gmail.com> wrote:
> > Hi all,
> >
> > I believe I've worked around the issues with make binary-dist and
> > cross-compilation.
> >
> > This should be a working binary for iOS devices
> >
> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2
> >
> > Please try ./configure && make install (it should live happily next to
> your
> > current ghc as arm-apple-darwin10-ghc) and let me know so we can have a
> > build ready for 7.8 RC2!
> >
> > Cheers
> > Luke
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140205/7612ae91/attachment.html>

From djsamperi at gmail.com  Wed Feb  5 18:22:48 2014
From: djsamperi at gmail.com (Dominick Samperi)
Date: Wed, 5 Feb 2014 13:22:48 -0500
Subject: ghc-ios 7.8 working build
In-Reply-To: <CAGo83ChC5rjpxSAOQquajndU2Wde7ZJpuvUsGtwpfGZfjoTGkQ@mail.gmail.com>
References: <CAGo83CiyCsgtrZSbpCa400tDU6e=-uQuqfSEAE5246L=nawQQQ@mail.gmail.com>
 <CADUbQ5i5r0GuP0GrkjKS=9vtBNkCjQGL_0025V7hfhHDrKwOdQ@mail.gmail.com>
 <CAGo83ChC5rjpxSAOQquajndU2Wde7ZJpuvUsGtwpfGZfjoTGkQ@mail.gmail.com>
Message-ID: <CADUbQ5j2GDsfxiYKySvUxaBpLa9XUbQZrqNp=tvKK_p7HxNwfg@mail.gmail.com>

[Luke: forgot to forward to list, sorry for the duplicates]

There are two issues:

1. When I build Counter.a I see lots of messages from libtool saying
"has no symbols",
    for example:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool:
for architecture: armv7s file:
/usr/local/lib/arm-apple-darwin10-ghc-7.8.20140129/rts-1.0/libHSrts_thr.a(Sanity.thr_o)
has no symbols

2. I have not (yet) joined the developer program since I have no plans to deploy
    to the app store, so instead I have been following the
instructions here to deploy
    to my own device:
http://www.sysrage.net/guides/ios-programming/building-and-running-ios-applications-without-a-paid-developer-license

Following these instructions I am able to copy  HaskellCounter (my name for
your test app) to my device, and I see the HaskellCounter icon, but when I
start the app I just see a blank screen. Looking at

Counter.hs this is not too surprising, as I see no code that would update the
Single View screen? I'm not sure where the output of putStrLn goes when
an app is run on the device.

Dominick


On Wed, Feb 5, 2014 at 4:27 AM, Luke Iannini <lukexipd at gmail.com> wrote:
> Hi Dominick and all,
>
> That's great news!
>
> I've created a README here:
> https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md
>
> Note that the binary posted above is only for the device. I'll post the
> simulator version shortly along with instructions on how to create fat
> libraries that contain both simulator and device code.
>
> Please let me know if you have any questions or issues!
>
> Very best
> Luke
>
>
> On Tue, Feb 4, 2014 at 11:35 PM, Dominick Samperi <djsamperi at gmail.com>
> wrote:
>>
>> Hello Luke,
>>
>> It installed without problems under Mac OS X Mavericks and reports the
>> version correctly. If there is some documentation that you can point me to
>> I will test on my simulator and iPhone.
>>
>> Thanks,
>> Dominick
>>
>>
>> On Wed, Feb 5, 2014 at 1:36 AM, Luke Iannini <lukexipd at gmail.com> wrote:
>> > Hi all,
>> >
>> > I believe I've worked around the issues with make binary-dist and
>> > cross-compilation.
>> >
>> > This should be a working binary for iOS devices
>> >
>> > https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2
>> >
>> > Please try ./configure && make install (it should live happily next to
>> > your
>> > current ghc as arm-apple-darwin10-ghc) and let me know so we can have a
>> > build ready for 7.8 RC2!
>> >
>> > Cheers
>> > Luke
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>> >
>
>

From ekmett at gmail.com  Wed Feb  5 19:22:07 2014
From: ekmett at gmail.com (Edward A Kmett)
Date: Wed, 5 Feb 2014 14:22:07 -0500
Subject: doc fix
In-Reply-To: <20140205.143534.913329123037060433.kazu@iij.ad.jp>
References: <20140205.143534.913329123037060433.kazu@iij.ad.jp>
Message-ID: <C9FA5F65-D3E9-44AB-977A-47CA707AA246@gmail.com>

Isn't it just the default for ghci?

-Edward

> On Feb 5, 2014, at 12:35 AM, Kazu Yamamoto (????) <kazu at iij.ad.jp> wrote:
> 
> Hi,
> 
> If I understand correctly, NoMonomorphismRestriction is now the
> default for GHC 7.8. I think that its document explicitly describes
> it.
> 
> --Kazu
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

From krz.gogolewski at gmail.com  Wed Feb  5 19:44:11 2014
From: krz.gogolewski at gmail.com (Krzysztof Gogolewski)
Date: Wed, 5 Feb 2014 20:44:11 +0100
Subject: doc fix
In-Reply-To: <C9FA5F65-D3E9-44AB-977A-47CA707AA246@gmail.com>
References: <20140205.143534.913329123037060433.kazu@iij.ad.jp>
 <C9FA5F65-D3E9-44AB-977A-47CA707AA246@gmail.com>
Message-ID: <CA+h2Lz=n2FR2wtWqn4Pv-H0czgzxJm8YGe1zhoPL1qQBwv+S_A@mail.gmail.com>

That's correct: https://ghc.haskell.org/trac/ghc/ticket/3202

It was documented in the GHCi section of documentation, I added now a
mention in the MR section.


On Wed, Feb 5, 2014 at 8:22 PM, Edward A Kmett <ekmett at gmail.com> wrote:

> Isn't it just the default for ghci?
>
> -Edward
>
> > On Feb 5, 2014, at 12:35 AM, Kazu Yamamoto (????) <kazu at iij.ad.jp>
> wrote:
> >
> > Hi,
> >
> > If I understand correctly, NoMonomorphismRestriction is now the
> > default for GHC 7.8. I think that its document explicitly describes
> > it.
> >
> > --Kazu
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140205/8baa5f10/attachment.html>

From lukexipd at gmail.com  Wed Feb  5 20:50:13 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Wed, 5 Feb 2014 12:50:13 -0800
Subject: ghc-ios 7.8 working build
In-Reply-To: <CADUbQ5j2GDsfxiYKySvUxaBpLa9XUbQZrqNp=tvKK_p7HxNwfg@mail.gmail.com>
References: <CAGo83CiyCsgtrZSbpCa400tDU6e=-uQuqfSEAE5246L=nawQQQ@mail.gmail.com>
 <CADUbQ5i5r0GuP0GrkjKS=9vtBNkCjQGL_0025V7hfhHDrKwOdQ@mail.gmail.com>
 <CAGo83ChC5rjpxSAOQquajndU2Wde7ZJpuvUsGtwpfGZfjoTGkQ@mail.gmail.com>
 <CADUbQ5j2GDsfxiYKySvUxaBpLa9XUbQZrqNp=tvKK_p7HxNwfg@mail.gmail.com>
Message-ID: <CAGo83CjDPwOd17Q6Jki=me4nRL0+TEv-cidvd70_W2Mc_-M4sA@mail.gmail.com>

Hi Dominick,

Awesome. Sounds like everything's working perfectly : ). The 'has no
symbols' messages are normal and harmless; I think they can be fixed but in
the meantime there is a script in ghc-ios-scripts called "libtool-quiet"
that silences them. You can use it by adding  -pgmlibtool libtool-quiet to
your GHC arguments.

The output just goes to the iPhone's console which is normally shown in
Xcode when you run, but you can also access it with Apple's "iPhone
Configurator" app.
https://itunes.apple.com/us/app/apple-configurator/id434433123?mt=12 .

(You could also modify the example to return e.g. an Int and put that on
the screen with a UILabel or similar -- you can call Haskell from anywhere
in your app as long as you've called hs_init at the very beginning. A nice
trick is to create an NSObject category with a + (void)load { hs_init(NULL,
NULL) } method, which will ensure hs_init is called very early in your
program and then you don't have to worry about it anymore.)

Thanks so much for testing!
Cheers
Luke


On Wed, Feb 5, 2014 at 10:22 AM, Dominick Samperi <djsamperi at gmail.com>wrote:

> [Luke: forgot to forward to list, sorry for the duplicates]
>
> There are two issues:
>
> 1. When I build Counter.a I see lots of messages from libtool saying
> "has no symbols",
>     for example:
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool:
> for architecture: armv7s file:
>
> /usr/local/lib/arm-apple-darwin10-ghc-7.8.20140129/rts-1.0/libHSrts_thr.a(Sanity.thr_o)
> has no symbols
>
> 2. I have not (yet) joined the developer program since I have no plans to
> deploy
>     to the app store, so instead I have been following the
> instructions here to deploy
>     to my own device:
>
> http://www.sysrage.net/guides/ios-programming/building-and-running-ios-applications-without-a-paid-developer-license
>
> Following these instructions I am able to copy  HaskellCounter (my name for
> your test app) to my device, and I see the HaskellCounter icon, but when I
> start the app I just see a blank screen. Looking at
>
> Counter.hs this is not too surprising, as I see no code that would update
> the
> Single View screen? I'm not sure where the output of putStrLn goes when
> an app is run on the device.
>
> Dominick
>
>
> On Wed, Feb 5, 2014 at 4:27 AM, Luke Iannini <lukexipd at gmail.com> wrote:
> > Hi Dominick and all,
> >
> > That's great news!
> >
> > I've created a README here:
> > https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md
> >
> > Note that the binary posted above is only for the device. I'll post the
> > simulator version shortly along with instructions on how to create fat
> > libraries that contain both simulator and device code.
> >
> > Please let me know if you have any questions or issues!
> >
> > Very best
> > Luke
> >
> >
> > On Tue, Feb 4, 2014 at 11:35 PM, Dominick Samperi <djsamperi at gmail.com>
> > wrote:
> >>
> >> Hello Luke,
> >>
> >> It installed without problems under Mac OS X Mavericks and reports the
> >> version correctly. If there is some documentation that you can point me
> to
> >> I will test on my simulator and iPhone.
> >>
> >> Thanks,
> >> Dominick
> >>
> >>
> >> On Wed, Feb 5, 2014 at 1:36 AM, Luke Iannini <lukexipd at gmail.com>
> wrote:
> >> > Hi all,
> >> >
> >> > I believe I've worked around the issues with make binary-dist and
> >> > cross-compilation.
> >> >
> >> > This should be a working binary for iOS devices
> >> >
> >> >
> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2
> >> >
> >> > Please try ./configure && make install (it should live happily next to
> >> > your
> >> > current ghc as arm-apple-darwin10-ghc) and let me know so we can have
> a
> >> > build ready for 7.8 RC2!
> >> >
> >> > Cheers
> >> > Luke
> >> >
> >> > _______________________________________________
> >> > ghc-devs mailing list
> >> > ghc-devs at haskell.org
> >> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140205/8f1db7b4/attachment.html>

From djsamperi at gmail.com  Thu Feb  6 00:11:16 2014
From: djsamperi at gmail.com (Dominick Samperi)
Date: Wed, 5 Feb 2014 19:11:16 -0500
Subject: ghc-ios 7.8 working build
In-Reply-To: <CAGo83CjDPwOd17Q6Jki=me4nRL0+TEv-cidvd70_W2Mc_-M4sA@mail.gmail.com>
References: <CAGo83CiyCsgtrZSbpCa400tDU6e=-uQuqfSEAE5246L=nawQQQ@mail.gmail.com>
 <CADUbQ5i5r0GuP0GrkjKS=9vtBNkCjQGL_0025V7hfhHDrKwOdQ@mail.gmail.com>
 <CAGo83ChC5rjpxSAOQquajndU2Wde7ZJpuvUsGtwpfGZfjoTGkQ@mail.gmail.com>
 <CADUbQ5j2GDsfxiYKySvUxaBpLa9XUbQZrqNp=tvKK_p7HxNwfg@mail.gmail.com>
 <CAGo83CjDPwOd17Q6Jki=me4nRL0+TEv-cidvd70_W2Mc_-M4sA@mail.gmail.com>
Message-ID: <CADUbQ5ijEbZVf+AkLQTiSkVZggb7mxCboaTKXOgjCXV4fSzEmg@mail.gmail.com>

Thanks Luke,

It inserted a GUI component just to be sure that the app with Haskell embedded
is running properly, and I'm happy to report that it is.

I could not get Apple Configurator do show the app console log, and several
apps that used to provide this service were broken by recent Apple updates.
I tried reading the socket syslog.sock (on the device), but apparently app
console logs are not sent here.

I guess I need to join the developer program to do simple things
like read logs.

Dominick

On Wed, Feb 5, 2014 at 3:50 PM, Luke Iannini <lukexipd at gmail.com> wrote:
> Hi Dominick,
>
> Awesome. Sounds like everything's working perfectly : ). The 'has no
> symbols' messages are normal and harmless; I think they can be fixed but in
> the meantime there is a script in ghc-ios-scripts called "libtool-quiet"
> that silences them. You can use it by adding  -pgmlibtool libtool-quiet to
> your GHC arguments.
>
> The output just goes to the iPhone's console which is normally shown in
> Xcode when you run, but you can also access it with Apple's "iPhone
> Configurator" app.
> https://itunes.apple.com/us/app/apple-configurator/id434433123?mt=12 .
>
> (You could also modify the example to return e.g. an Int and put that on the
> screen with a UILabel or similar -- you can call Haskell from anywhere in
> your app as long as you've called hs_init at the very beginning. A nice
> trick is to create an NSObject category with a + (void)load { hs_init(NULL,
> NULL) } method, which will ensure hs_init is called very early in your
> program and then you don't have to worry about it anymore.)
>
> Thanks so much for testing!
> Cheers
> Luke
>
>
> On Wed, Feb 5, 2014 at 10:22 AM, Dominick Samperi <djsamperi at gmail.com>
> wrote:
>>
>> [Luke: forgot to forward to list, sorry for the duplicates]
>>
>> There are two issues:
>>
>> 1. When I build Counter.a I see lots of messages from libtool saying
>> "has no symbols",
>>     for example:
>>
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool:
>> for architecture: armv7s file:
>>
>> /usr/local/lib/arm-apple-darwin10-ghc-7.8.20140129/rts-1.0/libHSrts_thr.a(Sanity.thr_o)
>> has no symbols
>>
>> 2. I have not (yet) joined the developer program since I have no plans to
>> deploy
>>     to the app store, so instead I have been following the
>> instructions here to deploy
>>     to my own device:
>>
>> http://www.sysrage.net/guides/ios-programming/building-and-running-ios-applications-without-a-paid-developer-license
>>
>> Following these instructions I am able to copy  HaskellCounter (my name
>> for
>> your test app) to my device, and I see the HaskellCounter icon, but when I
>> start the app I just see a blank screen. Looking at
>>
>> Counter.hs this is not too surprising, as I see no code that would update
>> the
>> Single View screen? I'm not sure where the output of putStrLn goes when
>> an app is run on the device.
>>
>> Dominick
>>
>>
>> On Wed, Feb 5, 2014 at 4:27 AM, Luke Iannini <lukexipd at gmail.com> wrote:
>> > Hi Dominick and all,
>> >
>> > That's great news!
>> >
>> > I've created a README here:
>> > https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md
>> >
>> > Note that the binary posted above is only for the device. I'll post the
>> > simulator version shortly along with instructions on how to create fat
>> > libraries that contain both simulator and device code.
>> >
>> > Please let me know if you have any questions or issues!
>> >
>> > Very best
>> > Luke
>> >
>> >
>> > On Tue, Feb 4, 2014 at 11:35 PM, Dominick Samperi <djsamperi at gmail.com>
>> > wrote:
>> >>
>> >> Hello Luke,
>> >>
>> >> It installed without problems under Mac OS X Mavericks and reports the
>> >> version correctly. If there is some documentation that you can point me
>> >> to
>> >> I will test on my simulator and iPhone.
>> >>
>> >> Thanks,
>> >> Dominick
>> >>
>> >>
>> >> On Wed, Feb 5, 2014 at 1:36 AM, Luke Iannini <lukexipd at gmail.com>
>> >> wrote:
>> >> > Hi all,
>> >> >
>> >> > I believe I've worked around the issues with make binary-dist and
>> >> > cross-compilation.
>> >> >
>> >> > This should be a working binary for iOS devices
>> >> >
>> >> >
>> >> > https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2
>> >> >
>> >> > Please try ./configure && make install (it should live happily next
>> >> > to
>> >> > your
>> >> > current ghc as arm-apple-darwin10-ghc) and let me know so we can have
>> >> > a
>> >> > build ready for 7.8 RC2!
>> >> >
>> >> > Cheers
>> >> > Luke
>> >> >
>> >> > _______________________________________________
>> >> > ghc-devs mailing list
>> >> > ghc-devs at haskell.org
>> >> > http://www.haskell.org/mailman/listinfo/ghc-devs
>> >> >
>> >
>> >
>
>

From pho at cielonegro.org  Thu Feb  6 04:57:41 2014
From: pho at cielonegro.org (PHO)
Date: Thu, 06 Feb 2014 13:57:41 +0900 (JST)
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <52ED605D.8050502@gmail.com>
References: <CAHYVw0ze5zCmNb6HaSA0VX4tOAuXNJPTwNN3p6caRiwUs_ccXA@mail.gmail.com>
 <CACYs5AaaAuS4e=kwMqB6vNnbLfBSTy1+Kjkbgm_Vz2Feg65rZQ@mail.gmail.com>
 <52ED605D.8050502@gmail.com>
Message-ID: <20140206.135741.506818448.pho@cielonegro.org>

How about using libatomic_ops? [*1]

GCC atomic intrinsics are only provided by GCC >= 4.2. Clang seems to
have an equivalent set of intrinsics but in different names
[*2]. Basically we should avoid using any non-standard language
extensions where possible.


*1: https://github.com/ivmai/libatomic_ops/
*2: http://clang.llvm.org/docs/LanguageExtensions.html#langext-c11-atomic

Thanks,
PHO


From: Simon Marlow <marlowsd at gmail.com>
Subject: Re: Bad news: apparent bug in casMutVar going back to 7.2
Date: Sat, 01 Feb 2014 21:00:13 +0000

> So there's no problem in casMutVar#?
>
> There's probably no good reason not to use the gcc intrinsics.  Either
> they didn't exist when I wrote the inline asm, or they had been added
> to gcc since I last read the docs.
>
> Cheers,
> Simon
>
> On 01/02/2014 19:35, Ryan Newton wrote:
>> Ok, my bad, sorry all.
>>
>> This is NOT a problem that will crop up in 7.8.   Rather, it's just a
>> problem with the duplicated bits of GHC RTS functionality that were
>> stuck into the atomic-primops library.  It was a C preprocessor
>> problem
>> that was causing the inline asm we were discussing in this thread to
>> not
>> actually be called.
>>
>> Still, I'd like to be reminded of the rational for all this
>> conditional
>> inline asm rather than using the C compiler intrinsics!  Anyone?
>>
>> Best,
>>    -Ryan
>>
>>
>>
>> On Sat, Feb 1, 2014 at 2:17 PM, Carter Schonwald
>> <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>>
>> wrote:
>>
>>     I got the test suite running on my (2 core) machine mac book air,
>>     with 7.8
>>     i've run it several times, not seeing any failures
>>
>>
>>     On Sat, Feb 1, 2014 at 1:03 PM, Carter Schonwald
>>     <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>>
>>     wrote:
>>
>>         hrmmmm I have a crazy idea
>>
>>         "Compare RAX with r/m64. If equal, ZF is set and r64 is loaded
>>         into r/m64. Else, clear ZF
>>         and load r/m64 into RAX." is what the docs say for the cmpxchng
>>         instruction
>>
>>         so RAX is the old values,  (EAX in the  32bit case). And it
>>         looks like we dont' set that explicitly when calling the asm ..
>>         CMPXCHG r/m64, r64
>>
>>           hrmmm
>>
>>
>>
>>
>>         On Sat, Feb 1, 2014 at 12:52 PM, Ryan Newton <rrnewton at gmail.com
>>         <mailto:rrnewton at gmail.com>> wrote:
>>
>>             Ok, here's another experiment, on this commit:
>>
>>             https://github.com/rrnewton/haskell-lockfree/commit/399bb19fa02eaf2f2eab5d02c4b608535362f9bc
>>
>>             Here, if I use GCC's __sync_val_compare_and_swap instead of
>>             GHC's version of cas(), the problem also goes away.  I think
>>             these two implementations should behave identically, and
>>             that they don't perhaps indicates that there is something
>>             off about the inline asm, as Carter was suggesting:
>>
>>             *#if i386_HOST_ARCH || x86_64_HOST_ARCH*
>>             *    __asm__ __volatile__ (*
>>             * "lock\ncmpxchg %3,%1"*
>>             *          :"=a"(o), "=m" (*(volatile unsigned int *)p) *
>>             *          :"0" (o), "r" (n));*
>>             *    return o;*
>>
>>             The x86 CAS instruction must put the "return value" in the
>>             accumulator register, and indeed this constrains "o" to be
>>             allocated to the accumulator register, while the new value
>>             "n" can be in any register.
>>
>>             So if there's a problem, I don't know what it is.  Except
>>             I'm not sure what the ramifications of "o" being a function
>>             parameter AND having an "=a" constraint on it are...
>>
>>                 -Ryan
>>
>>
>>
>>             On Sat, Feb 1, 2014 at 11:27 AM, Carter Schonwald
>>             <carter.schonwald at gmail.com
>>             <mailto:carter.schonwald at gmail.com>> wrote:
>>
>>                 Hey Ryan, i've made the leap to using 7.8 on my machine,
>>                 so i'll first have to get some pull requests in on
>>                 atomic-primops before I can test it locally :), expect
>>                 those patches later today!
>>
>>                 looks like gcc's inline ASM logic is pretty correct,
>>                 after testing it a bit locally, pardon my speculative
>>                 jumping the gun.
>>
>>
>>                 On Sat, Feb 1, 2014 at 9:10 AM, Ryan Newton
>>                 <rrnewton at gmail.com <mailto:rrnewton at gmail.com>> wrote:
>>
>>                     Hi Carter & others,
>>
>>                     Carter, yes, this is CAS on pointers and in my next
>>                     mail I'll try to come up with some hypotheses as to
>>                     why we may have (remaining) problems there.
>>
>>                     But first, I have been assured that on x86 there is
>>                     no failure mode in which doing a comparison on the
>>                     value read by CAS should not correctly diagnose
>>                     success or failure (same as directly reading the
>>                     Zero Flag) [1].
>>
>>                     And yet, there's this discrepancy, where the
>>                     modified casMutVar that I linked to does not have
>>                     the failure.  As for reproducing the failure, either
>>                     of the two following tests will currently show problems:
>>
>>                       * Two threads try to casIORef False->True, both
>>                         succeed
>>                       * 120 threads try to read, increment, CAS until
>>                         they succeed.  The total is often not 120
>>                         because multiple threads think the successfully
>>                         incremented, say, 33->34.
>>
>>                     Here's a specific recipe for the latter test on GHC
>>                     7.6.3 Mac or Linux:
>>
>>                     *git clone
>>                     git at github.com:rrnewton/haskell-lockfree-queue.git
>>                     *
>>                     *cd haskell-lockfree-queue/AtomicPrimops/*
>>                     *git checkout 1a1e7e55f6706f9e5754
>>                     *
>>                     *cabal sandbox init
>>                     *
>>                     *cabal install -f-withTH -fforeign ./ ./testing
>>                     --enable-tests
>>                     *
>>                     *./testing/dist/dist-sandbox-*/build/test-atomic-primops/test-atomic-primops
>>                     -t n_threads
>>                     *
>>
>>                     You may have to run the last line several times to
>>                     see the failure.
>>
>>                     Best,
>>                        -Ryan
>>
>>                     [1] I guess the __sync_bool_compare_and_swap
>>                     intrinsic which reads ZF is there just to avoid the
>>                     extra comparison.
>>
>>                     [2] P.S. I'd like to try this on GHC head, but the
>>                     RHEL 6 machine I usually use to build it is
>>                     currently not validating (below error, commit
>>                     65d05d7334).  After I debug this gmp problem I'll
>>                     confirm that the bug under discussion applies on the
>>                     7.8 branch.
>>
>>                          ./sync-all checkout ghc-7.8
>>                          sh validate
>>                     ...
>>                     /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o:
>>                     relocation R_X86_64_32 against `__gmpz_sub' can not
>>                     be used when making a shared object; recompile with
>>                     -fPIC
>>                     libraries/integer-gmp/gmp/objs/aors.o: could not
>>                     read symbols: Bad value
>>
>>
>>
>>
>>                     On Sat, Feb 1, 2014 at 2:55 AM, Carter Schonwald
>>                     <carter.schonwald at gmail.com
>>                     <mailto:carter.schonwald at gmail.com>> wrote:
>>
>>                         Ryan, is your benchmark using CAS on pointers,
>>                         or immediate words? trying to get atomic primops
>>                         to build on my 7.8 build on my mac
>>
>>
>>                         On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald
>>                         <carter.schonwald at gmail.com
>>                         <mailto:carter.schonwald at gmail.com>> wrote:
>>
>>                             https://ghc.haskell.org/trac/ghc/ticket/8724#ticket
>>                             is the ticket
>>
>>                             when i'm more awake i'll experiment some more
>>
>>
>>                             On Sat, Feb 1, 2014 at 2:33 AM, Carter
>>                             Schonwald <carter.schonwald at gmail.com
>>                             <mailto:carter.schonwald at gmail.com>> wrote:
>>
>>                                 i have a ticket for tracking this,
>>                                 though i'm thinking my initial attempt
>>                                 at a patch generates the same object
>>                                 code as it did before.
>>
>>                                 @ryan, what CPU variant are you testing
>>                                 this on? is this on a NUMA machine or
>>                                 something?
>>
>>
>>                                 On Sat, Feb 1, 2014 at 1:58 AM, Carter
>>                                 Schonwald <carter.schonwald at gmail.com
>>                                 <mailto:carter.schonwald at gmail.com>> wrote:
>>
>>                                     woops, i mean cmpxchgq
>>
>>
>>                                     On Sat, Feb 1, 2014 at 1:36 AM,
>>                                     Carter Schonwald
>>                                     <carter.schonwald at gmail.com
>>                                     <mailto:carter.schonwald at gmail.com>>
>>                                     wrote:
>>
>>                                         ok, i can confirm that on my
>>                                         64bit mac, both clang and gcc
>>                                         use cmpxchgl rather than cmpxchg
>>                                         i'll whip up a strawman patch on
>>                                         head that can be cherrypicked /
>>                                         tested out by ryan et al
>>
>>
>>                                         On Sat, Feb 1, 2014 at 1:12 AM,
>>                                         Carter Schonwald
>>                                         <carter.schonwald at gmail.com
>>                                         <mailto:carter.schonwald at gmail.com>>
>>                                         wrote:
>>
>>                                             Hey Ryan,
>>                                             looking at this closely
>>                                             Why isn't CAS using
>>                                             CMPXCHG8B on 64bit
>>                                             architectures?  Could that
>>                                             be the culprit?
>>
>>                                             Could the issue be that
>>                                             we've not had a good stress
>>                                             test that would create
>>                                             values that are equal on the
>>                                             32bit range, but differ on
>>                                             the 64bit range, and you're
>>                                             hitting that?
>>
>>                                             Could you try seeing if
>>                                             doing that change fixes
>>                                             things up?
>>                                             (I may be completely wrong,
>>                                             but just throwing this out
>>                                             as a naive "obvious" guess)
>>
>>
>>                                             On Sat, Feb 1, 2014 at 12:58
>>                                             AM, Ryan Newton
>>                                             <rrnewton at gmail.com
>>                                             <mailto:rrnewton at gmail.com>>
>>                                             wrote:
>>
>>                                                 Then again... I'm having
>>                                                 trouble seeing how the
>>                                                 spec on page 3-149 of
>>                                                 the Intel manual would
>>                                                 allow the behavior I'm
>>                                                 seeing:
>>
>>                                                 http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>>
>>                                                 Nevertheless, this is
>>                                                 exactly the behavior
>>                                                 we're seeing with the
>>                                                 current Haskell primops.
>>                                                   Two threads
>>                                                 simultaneously
>>                                                 performing the same
>>                                                 CAS(p,a,b) can both
>>                                                 think that they succeeded.
>>
>>
>>
>>
>>
>>                                                 On Sat, Feb 1, 2014 at
>>                                                 12:33 AM, Ryan Newton
>>                                                 <rrnewton at gmail.com
>>                                                 <mailto:rrnewton at gmail.com>>
>>                                                 wrote:
>>
>>                                                     I commented on the
>>                                                     commit here:
>>
>>                                                     https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
>>
>>                                                     The problem is that
>>                                                     our "cas" routine in
>>                                                     SMP.h is similar to
>>                                                     the C compiler
>>                                                     intrinsic
>>                                                     __sync_val_compare_and_swap,
>>                                                     in that it returns
>>                                                     the old value.  But
>>                                                     it seems we cannot
>>                                                     use a comparison
>>                                                     against that old
>>                                                     value to determine
>>                                                     whether or not the
>>                                                     CAS succeeded.  (I
>>                                                     believe the CAS may
>>                                                     fail due to
>>                                                     contention, but the
>>                                                     old value may happen
>>                                                     to look like our old
>>                                                     value.)
>>
>>                                                     Unfortunately, this
>>                                                     didn't occur to me
>>                                                     until it started
>>                                                     causing bugs [1]
>>                                                     [2].  Fixing
>>                                                     casMutVar# fixes
>>                                                     these bugs.
>>                                                       However, the way
>>                                                     I'm currently fixing
>>                                                     CAS in the
>>                                                     "atomic-primops"
>>                                                     package is by using
>>                                                     __sync_bool_compare_and_swap:
>>
>>                                                     https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200
>>
>>                                                     What is the best fix
>>                                                     for GHC itself?
>>                                                     Would it be ok for
>>                                                     GHC to include a C
>>                                                     compiler intrinsic
>>                                                     like
>>                                                     __sync_val_compare_and_swap?
>>                                                       Otherwise we need
>>                                                     another big ifdbef'd
>>                                                     function like "cas"
>>                                                     in SMP.h that has
>>                                                     the
>>                                                     architecture-specific inline
>>                                                     asm across all
>>                                                     architectures.  I
>>                                                     can write the x86
>>                                                     one, but I'm not
>>                                                     eager to try the others.
>>
>>                                                     Best,
>>                                                         -Ryan
>>
>>                                                     [1]
>>                                                     https://github.com/iu-parfunc/lvars/issues/70
>>                                                     [2]
>>                                                     https://github.com/rrnewton/haskell-lockfree/issues/15
>>
>>
>>
>>                                                 _______________________________________________
>>                                                 ghc-devs mailing list
>>                                                 ghc-devs at haskell.org
>>                                                 <mailto:ghc-devs at haskell.org>
>>                                                 http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140206/90ef3815/attachment.sig>

From carter.schonwald at gmail.com  Thu Feb  6 05:09:16 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 6 Feb 2014 00:09:16 -0500
Subject: Bad news: apparent bug in casMutVar going back to 7.2
In-Reply-To: <52ED605D.8050502@gmail.com>
References: <CACYs5AY+KvJ-XWFx8L91HhzwBQqB_WvwF0+=Zxfuq=jUUCUyLw@mail.gmail.com>
 <CACYs5AYRXRfmS9vndvTF5GK4ih4Ou2EqEMHv+fqe+MOpacQA1A@mail.gmail.com>
 <CAHYVw0x6ztAXmBucEmM_SvaZs6Hwa=JyWnr2VuO_t_oO5av=OA@mail.gmail.com>
 <CAHYVw0zB=UBJy_3ReuPFPSFbWiwndN2pk2shpX6skd5bz=tKXQ@mail.gmail.com>
 <CAHYVw0wT3xY+cz-+3avewoFf2kgq7rXY7q7eo1+rohA-gDzBfg@mail.gmail.com>
 <CAHYVw0zYVv_bTe6ZotFXb70+UKG-Er=mjenXuC-iP-s4K9eHZw@mail.gmail.com>
 <CAHYVw0zDuSLjJJexdOjusbyr=Q5o7OdDG65g8wdseZqq6QgayQ@mail.gmail.com>
 <CAHYVw0yRYUAfmpDbCzy2A3wSCUu5-gBN_RrJjkGvodZSznZR_w@mail.gmail.com>
 <CACYs5AY9uBXtmO5g4xmqsQb9Hb7vH+aiYPtNUbTs+dJjMcbk+w@mail.gmail.com>
 <CAHYVw0yhzysUz=R0BLt_e8b929ey1qH-kL5hx0rVCAm0JWfW-w@mail.gmail.com>
 <CACYs5AZuc_6T+AGZFx_644XVGjC5x_6-PySWcyZhTUpUyE0qQw@mail.gmail.com>
 <CAHYVw0w92JPqsqEtF9FX_NP=aDsSvadsTH32ii4WGiFeX=dO+Q@mail.gmail.com>
 <CAHYVw0ze5zCmNb6HaSA0VX4tOAuXNJPTwNN3p6caRiwUs_ccXA@mail.gmail.com>
 <CACYs5AaaAuS4e=kwMqB6vNnbLfBSTy1+Kjkbgm_Vz2Feg65rZQ@mail.gmail.com>
 <52ED605D.8050502@gmail.com>
Message-ID: <CAHYVw0znTR45zuMmQeD76KbXh_+0e2ChrCgoM_WXGv+DXQmayQ@mail.gmail.com>

I'll add making that change to my inline primops task. (It does give nice
reference asm for that task. )
On Feb 1, 2014 1:00 PM, "Simon Marlow" <marlowsd at gmail.com> wrote:

> So there's no problem in casMutVar#?
>
> There's probably no good reason not to use the gcc intrinsics.  Either
> they didn't exist when I wrote the inline asm, or they had been added to
> gcc since I last read the docs.
>
> Cheers,
> Simon
>
> On 01/02/2014 19:35, Ryan Newton wrote:
>
>> Ok, my bad, sorry all.
>>
>> This is NOT a problem that will crop up in 7.8.   Rather, it's just a
>> problem with the duplicated bits of GHC RTS functionality that were
>> stuck into the atomic-primops library.  It was a C preprocessor problem
>> that was causing the inline asm we were discussing in this thread to not
>> actually be called.
>>
>> Still, I'd like to be reminded of the rational for all this conditional
>> inline asm rather than using the C compiler intrinsics!  Anyone?
>>
>> Best,
>>    -Ryan
>>
>>
>>
>> On Sat, Feb 1, 2014 at 2:17 PM, Carter Schonwald
>> <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
>>
>>     I got the test suite running on my (2 core) machine mac book air,
>>     with 7.8
>>     i've run it several times, not seeing any failures
>>
>>
>>     On Sat, Feb 1, 2014 at 1:03 PM, Carter Schonwald
>>     <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>>
>> wrote:
>>
>>         hrmmmm I have a crazy idea
>>
>>         "Compare RAX with r/m64. If equal, ZF is set and r64 is loaded
>>         into r/m64. Else, clear ZF
>>         and load r/m64 into RAX." is what the docs say for the cmpxchng
>>         instruction
>>
>>         so RAX is the old values,  (EAX in the  32bit case). And it
>>         looks like we dont' set that explicitly when calling the asm ..
>>         CMPXCHG r/m64, r64
>>
>>           hrmmm
>>
>>
>>
>>
>>         On Sat, Feb 1, 2014 at 12:52 PM, Ryan Newton <rrnewton at gmail.com
>>         <mailto:rrnewton at gmail.com>> wrote:
>>
>>             Ok, here's another experiment, on this commit:
>>
>>             https://github.com/rrnewton/haskell-lockfree/commit/
>> 399bb19fa02eaf2f2eab5d02c4b608535362f9bc
>>
>>             Here, if I use GCC's __sync_val_compare_and_swap instead of
>>             GHC's version of cas(), the problem also goes away.  I think
>>             these two implementations should behave identically, and
>>             that they don't perhaps indicates that there is something
>>             off about the inline asm, as Carter was suggesting:
>>
>>             *#if i386_HOST_ARCH || x86_64_HOST_ARCH*
>>             *    __asm__ __volatile__ (*
>>             * "lock\ncmpxchg %3,%1"*
>>             *          :"=a"(o), "=m" (*(volatile unsigned int *)p) *
>>             *          :"0" (o), "r" (n));*
>>             *    return o;*
>>
>>             The x86 CAS instruction must put the "return value" in the
>>             accumulator register, and indeed this constrains "o" to be
>>             allocated to the accumulator register, while the new value
>>             "n" can be in any register.
>>
>>             So if there's a problem, I don't know what it is.  Except
>>             I'm not sure what the ramifications of "o" being a function
>>             parameter AND having an "=a" constraint on it are...
>>
>>                 -Ryan
>>
>>
>>
>>             On Sat, Feb 1, 2014 at 11:27 AM, Carter Schonwald
>>             <carter.schonwald at gmail.com
>>             <mailto:carter.schonwald at gmail.com>> wrote:
>>
>>                 Hey Ryan, i've made the leap to using 7.8 on my machine,
>>                 so i'll first have to get some pull requests in on
>>                 atomic-primops before I can test it locally :), expect
>>                 those patches later today!
>>
>>                 looks like gcc's inline ASM logic is pretty correct,
>>                 after testing it a bit locally, pardon my speculative
>>                 jumping the gun.
>>
>>
>>                 On Sat, Feb 1, 2014 at 9:10 AM, Ryan Newton
>>                 <rrnewton at gmail.com <mailto:rrnewton at gmail.com>> wrote:
>>
>>                     Hi Carter & others,
>>
>>                     Carter, yes, this is CAS on pointers and in my next
>>                     mail I'll try to come up with some hypotheses as to
>>                     why we may have (remaining) problems there.
>>
>>                     But first, I have been assured that on x86 there is
>>                     no failure mode in which doing a comparison on the
>>                     value read by CAS should not correctly diagnose
>>                     success or failure (same as directly reading the
>>                     Zero Flag) [1].
>>
>>                     And yet, there's this discrepancy, where the
>>                     modified casMutVar that I linked to does not have
>>                     the failure.  As for reproducing the failure, either
>>                     of the two following tests will currently show
>> problems:
>>
>>                       * Two threads try to casIORef False->True, both
>>                         succeed
>>                       * 120 threads try to read, increment, CAS until
>>                         they succeed.  The total is often not 120
>>                         because multiple threads think the successfully
>>                         incremented, say, 33->34.
>>
>>                     Here's a specific recipe for the latter test on GHC
>>                     7.6.3 Mac or Linux:
>>
>>                     *git clone
>>                     git at github.com:rrnewton/haskell-lockfree-queue.git
>>                     *
>>                     *cd haskell-lockfree-queue/AtomicPrimops/*
>>                     *git checkout 1a1e7e55f6706f9e5754
>>                     *
>>                     *cabal sandbox init
>>                     *
>>                     *cabal install -f-withTH -fforeign ./ ./testing
>>                     --enable-tests
>>                     *
>>                     *./testing/dist/dist-sandbox-*
>> /build/test-atomic-primops/test-atomic-primops
>>                     -t n_threads
>>                     *
>>
>>                     You may have to run the last line several times to
>>                     see the failure.
>>
>>                     Best,
>>                        -Ryan
>>
>>                     [1] I guess the __sync_bool_compare_and_swap
>>                     intrinsic which reads ZF is there just to avoid the
>>                     extra comparison.
>>
>>                     [2] P.S. I'd like to try this on GHC head, but the
>>                     RHEL 6 machine I usually use to build it is
>>                     currently not validating (below error, commit
>>                     65d05d7334).  After I debug this gmp problem I'll
>>                     confirm that the bug under discussion applies on the
>>                     7.8 branch.
>>
>>                          ./sync-all checkout ghc-7.8
>>                          sh validate
>>                     ...
>>                     /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o:
>>                     relocation R_X86_64_32 against `__gmpz_sub' can not
>>                     be used when making a shared object; recompile with
>>                     -fPIC
>>                     libraries/integer-gmp/gmp/objs/aors.o: could not
>>                     read symbols: Bad value
>>
>>
>>
>>
>>                     On Sat, Feb 1, 2014 at 2:55 AM, Carter Schonwald
>>                     <carter.schonwald at gmail.com
>>                     <mailto:carter.schonwald at gmail.com>> wrote:
>>
>>                         Ryan, is your benchmark using CAS on pointers,
>>                         or immediate words? trying to get atomic primops
>>                         to build on my 7.8 build on my mac
>>
>>
>>                         On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald
>>                         <carter.schonwald at gmail.com
>>                         <mailto:carter.schonwald at gmail.com>> wrote:
>>
>>                             https://ghc.haskell.org/trac/
>> ghc/ticket/8724#ticket
>>                             is the ticket
>>
>>                             when i'm more awake i'll experiment some more
>>
>>
>>                             On Sat, Feb 1, 2014 at 2:33 AM, Carter
>>                             Schonwald <carter.schonwald at gmail.com
>>                             <mailto:carter.schonwald at gmail.com>> wrote:
>>
>>                                 i have a ticket for tracking this,
>>                                 though i'm thinking my initial attempt
>>                                 at a patch generates the same object
>>                                 code as it did before.
>>
>>                                 @ryan, what CPU variant are you testing
>>                                 this on? is this on a NUMA machine or
>>                                 something?
>>
>>
>>                                 On Sat, Feb 1, 2014 at 1:58 AM, Carter
>>                                 Schonwald <carter.schonwald at gmail.com
>>                                 <mailto:carter.schonwald at gmail.com>>
>> wrote:
>>
>>                                     woops, i mean cmpxchgq
>>
>>
>>                                     On Sat, Feb 1, 2014 at 1:36 AM,
>>                                     Carter Schonwald
>>                                     <carter.schonwald at gmail.com
>>                                     <mailto:carter.schonwald at gmail.com>>
>>                                     wrote:
>>
>>                                         ok, i can confirm that on my
>>                                         64bit mac, both clang and gcc
>>                                         use cmpxchgl rather than cmpxchg
>>                                         i'll whip up a strawman patch on
>>                                         head that can be cherrypicked /
>>                                         tested out by ryan et al
>>
>>
>>                                         On Sat, Feb 1, 2014 at 1:12 AM,
>>                                         Carter Schonwald
>>                                         <carter.schonwald at gmail.com
>>                                         <mailto:carter.schonwald@
>> gmail.com>>
>>                                         wrote:
>>
>>                                             Hey Ryan,
>>                                             looking at this closely
>>                                             Why isn't CAS using
>>                                             CMPXCHG8B on 64bit
>>                                             architectures?  Could that
>>                                             be the culprit?
>>
>>                                             Could the issue be that
>>                                             we've not had a good stress
>>                                             test that would create
>>                                             values that are equal on the
>>                                             32bit range, but differ on
>>                                             the 64bit range, and you're
>>                                             hitting that?
>>
>>                                             Could you try seeing if
>>                                             doing that change fixes
>>                                             things up?
>>                                             (I may be completely wrong,
>>                                             but just throwing this out
>>                                             as a naive "obvious" guess)
>>
>>
>>                                             On Sat, Feb 1, 2014 at 12:58
>>                                             AM, Ryan Newton
>>                                             <rrnewton at gmail.com
>>                                             <mailto:rrnewton at gmail.com>>
>>                                             wrote:
>>
>>                                                 Then again... I'm having
>>                                                 trouble seeing how the
>>                                                 spec on page 3-149 of
>>                                                 the Intel manual would
>>                                                 allow the behavior I'm
>>                                                 seeing:
>>
>>
>> http://www.intel.com/content/dam/www/public/us/en/
>> documents/manuals/64-ia-32-architectures-software-
>> developer-manual-325462.pdf
>>
>>                                                 Nevertheless, this is
>>                                                 exactly the behavior
>>                                                 we're seeing with the
>>                                                 current Haskell primops.
>>                                                   Two threads
>>                                                 simultaneously
>>                                                 performing the same
>>                                                 CAS(p,a,b) can both
>>                                                 think that they succeeded.
>>
>>
>>
>>
>>
>>                                                 On Sat, Feb 1, 2014 at
>>                                                 12:33 AM, Ryan Newton
>>                                                 <rrnewton at gmail.com
>>                                                 <mailto:
>> rrnewton at gmail.com>>
>>                                                 wrote:
>>
>>                                                     I commented on the
>>                                                     commit here:
>>
>>
>> https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0
>> 626ea6f36b
>>
>>                                                     The problem is that
>>                                                     our "cas" routine in
>>                                                     SMP.h is similar to
>>                                                     the C compiler
>>                                                     intrinsic
>>
>> __sync_val_compare_and_swap,
>>                                                     in that it returns
>>                                                     the old value.  But
>>                                                     it seems we cannot
>>                                                     use a comparison
>>                                                     against that old
>>                                                     value to determine
>>                                                     whether or not the
>>                                                     CAS succeeded.  (I
>>                                                     believe the CAS may
>>                                                     fail due to
>>                                                     contention, but the
>>                                                     old value may happen
>>                                                     to look like our old
>>                                                     value.)
>>
>>                                                     Unfortunately, this
>>                                                     didn't occur to me
>>                                                     until it started
>>                                                     causing bugs [1]
>>                                                     [2].  Fixing
>>                                                     casMutVar# fixes
>>                                                     these bugs.
>>                                                       However, the way
>>                                                     I'm currently fixing
>>                                                     CAS in the
>>                                                     "atomic-primops"
>>                                                     package is by using
>>
>> __sync_bool_compare_and_swap:
>>
>>
>> https://github.com/rrnewton/haskell-lockfree/commit/
>> f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-
>> be3304b3ecdd8e1f9ed316cd844d711aR200
>>
>>                                                     What is the best fix
>>                                                     for GHC itself?
>>                                                     Would it be ok for
>>                                                     GHC to include a C
>>                                                     compiler intrinsic
>>                                                     like
>>
>> __sync_val_compare_and_swap?
>>                                                       Otherwise we need
>>                                                     another big ifdbef'd
>>                                                     function like "cas"
>>                                                     in SMP.h that has
>>                                                     the
>>                                                     architecture-specific
>> inline
>>                                                     asm across all
>>                                                     architectures.  I
>>                                                     can write the x86
>>                                                     one, but I'm not
>>                                                     eager to try the
>> others.
>>
>>                                                     Best,
>>                                                         -Ryan
>>
>>                                                     [1]
>>
>> https://github.com/iu-parfunc/lvars/issues/70
>>                                                     [2]
>>
>> https://github.com/rrnewton/haskell-lockfree/issues/15
>>
>>
>>
>>
>> _______________________________________________
>>                                                 ghc-devs mailing list
>>                                                 ghc-devs at haskell.org
>>                                                 <mailto:
>> ghc-devs at haskell.org>
>>                                                 http://www.haskell.org/
>> mailman/listinfo/ghc-devs
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140206/be097c43/attachment-0001.html>

From ggreif at gmail.com  Thu Feb  6 11:41:45 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Thu, 6 Feb 2014 12:41:45 +0100
Subject: [commit: ghc] master: Mention that MR is off by default in GHCi
 in documentation (5bda0d0)
In-Reply-To: <20140206075248.3D81E2406B@ghc.haskell.org>
References: <20140206075248.3D81E2406B@ghc.haskell.org>
Message-ID: <CAK-hX0=jiRaHaKhZX7YuB5TmsQWxGTZLSqtTDm=qD2LbXq7msw@mail.gmail.com>

It would be probably clearer to say

"Since GHC 7.8.1, the monomorphism restriction is switched off by
default in GHCi."

This makes the awkward double-negation feeling go away.
What do others think?

Cheers,

    Gabor

On 2/6/14, git at git.haskell.org <git at git.haskell.org> wrote:
> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : master
> Link       :
> http://ghc.haskell.org/trac/ghc/changeset/5bda0d08d8fec86433917b65a93836d2372a5b5c/ghc
>
>>---------------------------------------------------------------
>
> commit 5bda0d08d8fec86433917b65a93836d2372a5b5c
> Author: Krzysztof Gogolewski <krz.gogolewski at gmail.com>
> Date:   Wed Feb 5 20:40:13 2014 +0100
>
>     Mention that MR is off by default in GHCi in documentation
>
>
>>---------------------------------------------------------------
>
> 5bda0d08d8fec86433917b65a93836d2372a5b5c
>  docs/users_guide/glasgow_exts.xml |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/docs/users_guide/glasgow_exts.xml
> b/docs/users_guide/glasgow_exts.xml
> index a3913cc..1564f38 100644
> --- a/docs/users_guide/glasgow_exts.xml
> +++ b/docs/users_guide/glasgow_exts.xml
> @@ -7862,7 +7862,8 @@ scope over the methods defined in the
> <literal>where</literal> part.  For exampl
>  4.5.5</ulink>
>  of the Haskell Report)
>  can be completely switched off by
> -<option>-XNoMonomorphismRestriction</option>.
> +<option>-XNoMonomorphismRestriction</option>. Since GHC 7.8.1, it is
> +switched off by default in GHCi.
>  </para>
>  </sect3>
>
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>

From lukexipd at gmail.com  Thu Feb  6 14:03:47 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Thu, 6 Feb 2014 06:03:47 -0800
Subject: GHC iOS 7.8.1 RC1 for Device & Simulator
Message-ID: <CAGo83Cgie8FOHtZ7a8Ls0KM_1YsbBF_YccV_41CaSv5kz+DZdA@mail.gmail.com>

Hi folks,

RC builds of GHC iOS are now ready for devices and the iOS simulator.

https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2
https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-simulator/ghc-7.8.20140130-i386-apple-ios.tar.bz2

You'll find complete instructions on their usage here, including compiling
cabal packages:
https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md

Please let me know how it goes!
Cheers
Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140206/bc649fea/attachment.html>

From rarash at student.chalmers.se  Thu Feb  6 14:12:30 2014
From: rarash at student.chalmers.se (Arash Rouhani)
Date: Thu, 6 Feb 2014 15:12:30 +0100
Subject: [commit: ghc] master: Mention that MR is off by default in GHCi
 in documentation (5bda0d0)
In-Reply-To: <CAK-hX0=jiRaHaKhZX7YuB5TmsQWxGTZLSqtTDm=qD2LbXq7msw@mail.gmail.com>
References: <20140206075248.3D81E2406B@ghc.haskell.org>
 <CAK-hX0=jiRaHaKhZX7YuB5TmsQWxGTZLSqtTDm=qD2LbXq7msw@mail.gmail.com>
Message-ID: <52F3984E.4040606@student.chalmers.se>

I agree. It was unclear to me first what "it" referred to.

/Arash

On 2014-02-06 12:41, Gabor Greif wrote:
> It would be probably clearer to say
>
> "Since GHC 7.8.1, the monomorphism restriction is switched off by
> default in GHCi."
>
> This makes the awkward double-negation feeling go away.
> What do others think?
>
> Cheers,
>
>      Gabor
>
> On 2/6/14, git at git.haskell.org <git at git.haskell.org> wrote:
>> Repository : ssh://git at git.haskell.org/ghc
>>
>> On branch  : master
>> Link       :
>> http://ghc.haskell.org/trac/ghc/changeset/5bda0d08d8fec86433917b65a93836d2372a5b5c/ghc
>>
>>> ---------------------------------------------------------------
>> commit 5bda0d08d8fec86433917b65a93836d2372a5b5c
>> Author: Krzysztof Gogolewski <krz.gogolewski at gmail.com>
>> Date:   Wed Feb 5 20:40:13 2014 +0100
>>
>>      Mention that MR is off by default in GHCi in documentation
>>
>>
>>> ---------------------------------------------------------------
>> 5bda0d08d8fec86433917b65a93836d2372a5b5c
>>   docs/users_guide/glasgow_exts.xml |    3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/docs/users_guide/glasgow_exts.xml
>> b/docs/users_guide/glasgow_exts.xml
>> index a3913cc..1564f38 100644
>> --- a/docs/users_guide/glasgow_exts.xml
>> +++ b/docs/users_guide/glasgow_exts.xml
>> @@ -7862,7 +7862,8 @@ scope over the methods defined in the
>> <literal>where</literal> part.  For exampl
>>   4.5.5</ulink>
>>   of the Haskell Report)
>>   can be completely switched off by
>> -<option>-XNoMonomorphismRestriction</option>.
>> +<option>-XNoMonomorphismRestriction</option>. Since GHC 7.8.1, it is
>> +switched off by default in GHCi.
>>   </para>
>>   </sect3>
>>
>>
>> _______________________________________________
>> ghc-commits mailing list
>> ghc-commits at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-commits
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From coreyoconnor at gmail.com  Thu Feb  6 20:22:37 2014
From: coreyoconnor at gmail.com (Corey O'Connor)
Date: Thu, 6 Feb 2014 12:22:37 -0800
Subject: [commit: ghc] master: Mention that MR is off by default in GHCi
 in documentation (5bda0d0)
In-Reply-To: <CAK-hX0=jiRaHaKhZX7YuB5TmsQWxGTZLSqtTDm=qD2LbXq7msw@mail.gmail.com>
References: <20140206075248.3D81E2406B@ghc.haskell.org>
 <CAK-hX0=jiRaHaKhZX7YuB5TmsQWxGTZLSqtTDm=qD2LbXq7msw@mail.gmail.com>
Message-ID: <CANTmfBTG3_rqRkY+suwYh=NuYxk6gcF0UgLKXcdaYqPT6z3ukw@mail.gmail.com>

+1

Also: Good news! I was unaware. :-)

-Corey O'Connor
coreyoconnor at gmail.com
http://corebotllc.com/


On Thu, Feb 6, 2014 at 3:41 AM, Gabor Greif <ggreif at gmail.com> wrote:

> It would be probably clearer to say
>
> "Since GHC 7.8.1, the monomorphism restriction is switched off by
> default in GHCi."
>
> This makes the awkward double-negation feeling go away.
> What do others think?
>
> Cheers,
>
>     Gabor
>
> On 2/6/14, git at git.haskell.org <git at git.haskell.org> wrote:
> > Repository : ssh://git at git.haskell.org/ghc
> >
> > On branch  : master
> > Link       :
> >
> http://ghc.haskell.org/trac/ghc/changeset/5bda0d08d8fec86433917b65a93836d2372a5b5c/ghc
> >
> >>---------------------------------------------------------------
> >
> > commit 5bda0d08d8fec86433917b65a93836d2372a5b5c
> > Author: Krzysztof Gogolewski <krz.gogolewski at gmail.com>
> > Date:   Wed Feb 5 20:40:13 2014 +0100
> >
> >     Mention that MR is off by default in GHCi in documentation
> >
> >
> >>---------------------------------------------------------------
> >
> > 5bda0d08d8fec86433917b65a93836d2372a5b5c
> >  docs/users_guide/glasgow_exts.xml |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/docs/users_guide/glasgow_exts.xml
> > b/docs/users_guide/glasgow_exts.xml
> > index a3913cc..1564f38 100644
> > --- a/docs/users_guide/glasgow_exts.xml
> > +++ b/docs/users_guide/glasgow_exts.xml
> > @@ -7862,7 +7862,8 @@ scope over the methods defined in the
> > <literal>where</literal> part.  For exampl
> >  4.5.5</ulink>
> >  of the Haskell Report)
> >  can be completely switched off by
> > -<option>-XNoMonomorphismRestriction</option>.
> > +<option>-XNoMonomorphismRestriction</option>. Since GHC 7.8.1, it is
> > +switched off by default in GHCi.
> >  </para>
> >  </sect3>
> >
> >
> > _______________________________________________
> > ghc-commits mailing list
> > ghc-commits at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-commits
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140206/3ebd8c8c/attachment.html>

From jan.stolarek at p.lodz.pl  Thu Feb  6 20:50:55 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 6 Feb 2014 21:50:55 +0100
Subject: 7.8.1-candidate fail
In-Reply-To: <1391717159.13808.11.camel@one.mechvel.pereslavl.ru>
References: <1391717159.13808.11.camel@one.mechvel.pereslavl.ru>
Message-ID: <201402062150.55164.jan.stolarek@p.lodz.pl>

I had the same problem on Debian Squeeze:

https://ghc.haskell.org/trac/ghc/ticket/8666

What is your distro?

CCing ghc-devs.

Janek

Dnia czwartek, 6 lutego 2014, Sergei Meshveliani napisa?:
> Dear GHC team,
>
> I am trying to test    ghc-7.8.20140130-src.tar.bz2
>
> I make it from source with   ghc-7.6.3  on Debian Linux (64 bit).
>
> ./configure  looks all right.
>
> And `make' reports after 40 minutes:
>
> -------------------------------------------------------
> ...
> ...
> "inplace/bin/ghc-stage1" -optc-Ilibraries/integer-gmp/.
> -optc-I'/home/mechvel/g.....
> ...
> ...
> /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation
> R_X86_64_32 against `__gmpz_sub' can not be used when making a shared
> object; recompile with -fPIC
> libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[1]: ***
> [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0\
> -ghc7.8.20140130.so] Error 1
> -------------------------------------------------------
>
>
> What might this mean? Need I to install a fresher  libgmp ?
>
> Thanks,
>
> ------
> Sergei
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



From krz.gogolewski at gmail.com  Thu Feb  6 22:18:30 2014
From: krz.gogolewski at gmail.com (Krzysztof Gogolewski)
Date: Thu, 6 Feb 2014 23:18:30 +0100
Subject: [commit: ghc] master: Mention that MR is off by default in GHCi
 in documentation (5bda0d0)
In-Reply-To: <CANTmfBTG3_rqRkY+suwYh=NuYxk6gcF0UgLKXcdaYqPT6z3ukw@mail.gmail.com>
References: <20140206075248.3D81E2406B@ghc.haskell.org>
 <CAK-hX0=jiRaHaKhZX7YuB5TmsQWxGTZLSqtTDm=qD2LbXq7msw@mail.gmail.com>
 <CANTmfBTG3_rqRkY+suwYh=NuYxk6gcF0UgLKXcdaYqPT6z3ukw@mail.gmail.com>
Message-ID: <CA+h2LznuuoF2aJvjBYc_7nv6G67gNCzvqKYND=XdTyhR8J0eBw@mail.gmail.com>

Done, thanks for the suggestion.


On Thu, Feb 6, 2014 at 9:22 PM, Corey O'Connor <coreyoconnor at gmail.com>wrote:

> +1
>
> Also: Good news! I was unaware. :-)
>
> -Corey O'Connor
> coreyoconnor at gmail.com
> http://corebotllc.com/
>
>
> On Thu, Feb 6, 2014 at 3:41 AM, Gabor Greif <ggreif at gmail.com> wrote:
>
>> It would be probably clearer to say
>>
>> "Since GHC 7.8.1, the monomorphism restriction is switched off by
>> default in GHCi."
>>
>> This makes the awkward double-negation feeling go away.
>> What do others think?
>>
>> Cheers,
>>
>>     Gabor
>>
>> On 2/6/14, git at git.haskell.org <git at git.haskell.org> wrote:
>> > Repository : ssh://git at git.haskell.org/ghc
>> >
>> > On branch  : master
>> > Link       :
>> >
>> http://ghc.haskell.org/trac/ghc/changeset/5bda0d08d8fec86433917b65a93836d2372a5b5c/ghc
>> >
>> >>---------------------------------------------------------------
>> >
>> > commit 5bda0d08d8fec86433917b65a93836d2372a5b5c
>> > Author: Krzysztof Gogolewski <krz.gogolewski at gmail.com>
>> > Date:   Wed Feb 5 20:40:13 2014 +0100
>> >
>> >     Mention that MR is off by default in GHCi in documentation
>> >
>> >
>> >>---------------------------------------------------------------
>> >
>> > 5bda0d08d8fec86433917b65a93836d2372a5b5c
>> >  docs/users_guide/glasgow_exts.xml |    3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/docs/users_guide/glasgow_exts.xml
>> > b/docs/users_guide/glasgow_exts.xml
>> > index a3913cc..1564f38 100644
>> > --- a/docs/users_guide/glasgow_exts.xml
>> > +++ b/docs/users_guide/glasgow_exts.xml
>> > @@ -7862,7 +7862,8 @@ scope over the methods defined in the
>> > <literal>where</literal> part.  For exampl
>> >  4.5.5</ulink>
>> >  of the Haskell Report)
>> >  can be completely switched off by
>> > -<option>-XNoMonomorphismRestriction</option>.
>> > +<option>-XNoMonomorphismRestriction</option>. Since GHC 7.8.1, it is
>> > +switched off by default in GHCi.
>> >  </para>
>> >  </sect3>
>> >
>> >
>> > _______________________________________________
>> > ghc-commits mailing list
>> > ghc-commits at haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-commits
>> >
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140206/f449ba6c/attachment-0001.html>

From djsamperi at gmail.com  Fri Feb  7 03:25:21 2014
From: djsamperi at gmail.com (Dominick Samperi)
Date: Thu, 6 Feb 2014 22:25:21 -0500
Subject: GHC iOS 7.8.1 RC1 for Device & Simulator
In-Reply-To: <CAGo83Cgie8FOHtZ7a8Ls0KM_1YsbBF_YccV_41CaSv5kz+DZdA@mail.gmail.com>
References: <CAGo83Cgie8FOHtZ7a8Ls0KM_1YsbBF_YccV_41CaSv5kz+DZdA@mail.gmail.com>
Message-ID: <CADUbQ5g=KThesw7YEEZmUj46vkKLd1kAE-AqMbqNPbau61i3wg@mail.gmail.com>

Thanks Luke!

Tested on simulator and device, and both work.

The docs need a few more comments, namely, users should
download the latest ghc-ios-scripts as these have changed,
and the output files Counter.a and Counter_stub.h are now
written to subdirectories build/i386 and build/arm for the
respective architectures.

Cheers,
Dominick

On Thu, Feb 6, 2014 at 9:03 AM, Luke Iannini <lukexipd at gmail.com> wrote:
> Hi folks,
>
> RC builds of GHC iOS are now ready for devices and the iOS simulator.
>
> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2
> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-simulator/ghc-7.8.20140130-i386-apple-ios.tar.bz2
>
> You'll find complete instructions on their usage here, including compiling
> cabal packages:
> https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md
>
> Please let me know how it goes!
> Cheers
> Luke
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From robstewart57 at gmail.com  Fri Feb  7 18:34:53 2014
From: robstewart57 at gmail.com (Rob Stewart)
Date: Fri, 7 Feb 2014 18:34:53 +0000
Subject: Support for glibc 2.12 in 7.8 RC2
Message-ID: <CA+ZOas+-1spbmNkJvXF-K8EAdVB7-M6YX2HgQu2BjKPZgXTrLA@mail.gmail.com>

Hi,

The 7.8 RC1 status page [1] states RC1 requires glibc 2.15, and that
RC2 will support glibc 2.13 to target Debian 7. CentOS 6 packages
glibc 2.12 and this will be the glibc version in the CentOS 6
lifetime.

Is there a possibility of stretching lower bounded support in RC2 down
to glibc 2.12? This would allow all CentOS users using any of the 6.*
releases to use 7.8, I think.

[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC1

--
Rob

From adam at well-typed.com  Fri Feb  7 20:05:06 2014
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 07 Feb 2014 20:05:06 +0000
Subject: workaround to get both domain-specific errors and also multi-modal
 type inference?
In-Reply-To: <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
References: <CADfHYo436qCHcPsiG+gS2WcSCn8s6ThsavdmQoiTPQv1tEnW_A@mail.gmail.com>
 <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
Message-ID: <52F53C72.5050305@well-typed.com>

Hi,

Good error messages are a hard problem. That said, I think little tweaks
like this might make sense. Richard Eisenberg and I were discussing this
earlier, and we wondered if the following might provide an alternative
approach:

Suppose a module provides a function

    describeError :: Constraint -> Maybe String

(exact type up for discussion). This could be called by the typechecker
when reporting errors in other modules, to provide a domain-specific
error message. Do you think this might work for your use case?

We need to think about how to mark this function as special: one option
is to provide a built-in typeclass like

    class TypeCheckerPlugin a where
      describeError :: Constraint -> Maybe String

and look for instances of this class. Interestingly, the class type is
irrelevant here; we're not interested in solving constraints involving
this class, just looking at the imported instances when running the
typechecker. Perhaps using a pragma might be more principled.

This came up in the context of a more general discussion of plugins to
extend the typechecker. For example, we might consider doing something
similar to *solve* constraints in a domain-specific way, as well as
reporting errors.

Sound plausible?

Adam


On 30/01/14 21:09, Nicolas Frisby wrote:
> Also, on the topic of patching GHC for domain-specific error messages,
> why not add a simple means to emit a custom error message? It would beat
> piggy-backing on the "no instance" messages as I currently plan to.
> 
> This seems safe and straight-forward:
> 
>> -- wired-in, cannot be instantiated
>> class GHC.Exts.PrintError (msg :: Symbol) (args :: [k])
> 
> Consider the class C fromy previous email. It's possible these two
> instances are now sufficient.
> 
>> instance C a b
>> instance PrintError ("You used %1 on the left and %2 on the right!" ::
> Symbol) [a,b] => C a b
> 
> And let's not forget warnings!
> 
>> -- wired-in, cannot be instantiated
>> class GHC.Exts.PrintWarn (msg :: Symbol) (args :: '[k])
> 
> Thanks again.
> 
> 
> On Thu, Jan 30, 2014 at 3:07 PM, Nicolas Frisby
> <nicolas.frisby at gmail.com <mailto:nicolas.frisby at gmail.com>> wrote:
> 
>     Hi all. I have a question for those savvy to the type-checker's
>     internal workings.
> 
>     For uses of the following function, can anyone suggest a means of
>     forcing GHC to attempt to solve C a b even if a~b fails?
> 
>     > dslAsTypeOf :: (C a b,a~b) => a -> b -> a
>     > dslAsTypeOf x _ = x
>     > 
>     > class C a b -- no methods
> 
>     Just for concreteness, the following are indicative of the variety
>     of instances that I expect C to have. (I don't think this actually
>     affects the question above.)
> 
>     > instance C DSLType1 DSLType1
>     > instance C DSLType2 DSLType2
>     > instance C x y => C (DSLType3 x) (DSLType3 y)
>     >
>     > instance IndicativeErrorMessage1 => C DSLType1 DSLType2
>     > instance IndicativeErrorMessage2 => C DSLType2 (DSLType3 y)
>     > 
>     > class IndicativeErrorMessage1 -- will never have instances
>     > class IndicativeErrorMessage2 -- will never have instances
> 
>     Thank you for your time.
> 
>     ===================================
> 
>     Keep reading for the "short story", the "long story", and two ideas
>     for a small GHC patch that would enable my technique outlined above.
> 
>     ===== short story =====
> 
>     The motivation of dslAsTypeOf is to provide improved error messages
>     when a and b are not equal.
> 
>     Unfortunately, the user will never see IndicativeErrorMessage. It
>     appears that GHC does not attempt to solve C a b if a~b fails.
>     That's understandable, since the solution of C a b almost certainly
>     depends on the "value" of its arguments...
> 
>     Hence, the question at the top of this email.
> 
>     ===== long story =====
> 
>     A lot of the modern type-level programming capabilities can be put
>     to great use in creating type systems for embedded domain specific
>     languages. These type systems can enforce some impressive properties.
> 
>     However, the error messages you get when one of those property is
>     not satisfied can be pretty abysmal.
> 
>     In my particular case, I have a phantom type where the tag carries
>     all the domain-specific information.
> 
>     > newtype U (tag :: [Info]) a = U a
> 
>     and I have an binary operation that requires the tag to be
>     equivalent for all three types.
> 
>     > plus :: Num a => U tag a -> U tag a -> U tag a
>     > plus (U x) (U y) = U $ x + y
> 
>     This effectively enforces the property I want for U values.
>     Unfortunately, the error messages can seem dimwitted.
> 
>     > ill_typed = plus (U 1 :: U [Foo,Bar,Baz] Int)  (U 2 :: U [Foo,Baz]
>     Int)
> 
>     The `ill_typed` value gives an error message (in GHC 7.8) saying
> 
>       Bar : Baz : []      is not equal to       Baz : []
> 
>     (It's worse in GHC 7.4. I don't have access to a 7.6 at the moment.)
> 
>     I'd much rather have it say that "Bar is missing from the first
>     summand's list." And I can define a class that effectively conveys
>     that information in a "domain-specific error message" which is
>     actually a "no instance of <IndicativeClassName> tag1 tag2" message.
> 
>     > friendlier_plus :: (FriendlyEqCheck tag1 tag2 tag3,Num a) => U
>     tag1 a -> U tag2 a -> U tag3 a
> 
>     The `friendlier_plus' function gives useful error messages if tag1,
>     tag2, and tag3 are all fully monomorphic.
> 
>     However, it does not support inference:
> 
>     > zero :: Num a => U tag a
>     > zero = U 0
>     > 
>     > x = U 4 :: U [Foo,Baz] Int
>     >
>     > -- both of these are ill-typed :(
>     > should_work1 = (friendlier_plus zero x) `asTypeOf` x    -- tag1 is
>     unconstrained
>     > should_work2 = friendlier_plus x x     -- tag3 is unconstrained
> 
>     Neither of those terms type-check, since FriendlyEqCheck can't
>     determine if the unconstrained `tag' variable is equal to the other
>     tags.
> 
>     So, can we get the best of both worlds?
> 
>     > best_plus ::
>     >   ( FriendlyEqCheck tag1 tag2 tag3
>          , tag1 ~ tag2, tag2 ~ tag3, Num a) => U tag1 a -> U tag2 a -> U
>     tag3 a
> 
>     No, unfortunately not. Now the `should_work*' functions type-check,
>     but an ill-typed use of `best_plus' gives the same poor error
>     message that `plus' would give.
> 
>     Hence, the question at the top of this email.
> 
>     ===== two ideas =====
> 
>     If my question at the top of this email cannot be answered in the
>     affirmative, perhaps a small patch to GHC would make this sort of
>     approach a viable lightweight workaround for improving
>     domain-specific error messages.
> 
>     (I cannot estimate how difficult this would be to implement in the
>     type-checker.)
> 
>     Two alternative ideas.
> 
>     1) An "ALWAYS_ATTEMPT" PRAGMA that you can place on the class C so
>     that it is attempted even if a related ~ constraint fails.
> 
>     2) An OrElse constraint former, offering *very* constrained
>     back-tracking.
> 
>     > possibleAsTypeOf :: ((a ~ b) `OrElse` C a b) => a -> b -> a
>     > possibleAsTypeOf x _ = x
> 
>     Requirements: C must have no superclasses, no methods, and no fundeps.
> 
>     Specification: If (a~b) fails and (C a b) is satisfiable, then the
>     original inequality error message would be shown to the user. Else,
>     C's error message is used.
> 
>     ===================================
> 
>     You made it to the bottom of the email! Thanks again.
> 
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From rrnewton at gmail.com  Sat Feb  8 02:05:35 2014
From: rrnewton at gmail.com (Ryan Newton)
Date: Fri, 7 Feb 2014 21:05:35 -0500
Subject: Support for glibc 2.12 in 7.8 RC2
In-Reply-To: <CA+ZOas+-1spbmNkJvXF-K8EAdVB7-M6YX2HgQu2BjKPZgXTrLA@mail.gmail.com>
References: <CA+ZOas+-1spbmNkJvXF-K8EAdVB7-M6YX2HgQu2BjKPZgXTrLA@mail.gmail.com>
Message-ID: <CACYs5Ab3Okr3DhFvi2HXbhjqo-kYQ0Asi9jKT6v9Wh-5T7CatA@mail.gmail.com>

Yes, this is a really annoying issue on RHEL, which includes many
supercomputers.

Sent from my phone.
On Feb 7, 2014 1:35 PM, "Rob Stewart" <robstewart57 at gmail.com> wrote:

> Hi,
>
> The 7.8 RC1 status page [1] states RC1 requires glibc 2.15, and that
> RC2 will support glibc 2.13 to target Debian 7. CentOS 6 packages
> glibc 2.12 and this will be the glibc version in the CentOS 6
> lifetime.
>
> Is there a possibility of stretching lower bounded support in RC2 down
> to glibc 2.12? This would allow all CentOS users using any of the 6.*
> releases to use 7.8, I think.
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC1
>
> --
> Rob
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140207/40c210f9/attachment.html>

From marlowsd at gmail.com  Sat Feb  8 16:37:53 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 08 Feb 2014 08:37:53 -0800
Subject: Request: export runTcInteractive from TcRnDriver
In-Reply-To: <59543203684B2244980D7E4057D5FBC148761BD9@DB3EX14MBXC312.europe.corp.microsoft.com>
References: <E7F535B24A47D747A07D46C0AA82D43D1C7AA643@EXMBX21.ad.utwente.nl>
 <59543203684B2244980D7E4057D5FBC148761BD9@DB3EX14MBXC312.europe.corp.microsoft.com>
Message-ID: <52F65D61.4030108@gmail.com>

I don't think it's a good idea to export it from GHC.hs, because it 
works in terms of TcRn, which isn't exposed via GHC.  Someone using this 
API will need to use other bits from the typechecker.

It's fine to export it from TcRnDriver (and of course add a comment to 
explain why).  Maybe there should be an "official" API at this level 
too, but someone will need to do some design work and figure out what 
needs to be provided.  For now it's fine to use the internal APIs, with 
the caveat that they often change from version to version.

Cheers,
Simon

On 04/02/2014 00:05, Simon Peyton Jones wrote:
> No, there?s no reason it?s not exported, excepting only that it?s not
> currently called outside TcRnDriver.
>
> Go ahead and create a ticket and patch.  It should be exported from
> GHC.hs (ie the official GHC API), not merely from TcRnDriver.  And I
> suggest you add a comment with the export from GHC.hs to explain why
> it?s exported.  Otherwise someone might delete it again!
>
> Thx
>
> Simon
>
> *From:*ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of
> *p.k.f.holzenspies at utwente.nl
> *Sent:* 29 January 2014 09:55
> *To:* ghc-devs at haskell.org
> *Subject:* Request: export runTcInteractive from TcRnDriver
>
> Dear GHC-devs,
>
> Is there a reason why, in HEAD, TcRnDriver does **not** export
> runTcInteractive? If not, can it please be added? (I considered sending
> a patch with this email, but it?s so trivial a change that the check of
> the patch is more work than manually adding runTcInteractive to the
> export list.)
>
> I?m developing against the GHC API of 7.6.3 and it would have saved me
> hours of work to have precisely that function. Seeing it?s in HEAD, but
> not being exported seems a shame ;)
>
> Regards,
>
> Philip
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From marlowsd at gmail.com  Sat Feb  8 16:51:01 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 08 Feb 2014 08:51:01 -0800
Subject: Pre-Master checks (Was: Nightlies)
In-Reply-To: <1391506898.2719.23.camel@kirk>
References: <52E4714B.5060905@fuuzetsu.co.uk> <1390734969.2515.6.camel@kirk>
 <CAEs96n0i0nQ+yqCq4rmCh4cR8Ph_cAH1eoQ7WhitEUOcTKACDQ@mail.gmail.com>
 <CAEs96n3Aj_qtmPVKsO34WOrbfntduyoo0Y-ggbJVJjCjWSj+Vw@mail.gmail.com>
 <1390816044.2549.3.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>
 <1391506898.2719.23.camel@kirk>
Message-ID: <52F66075.6070000@gmail.com>

On 04/02/2014 01:41, Joachim Breitner wrote:
> Proposal
> ~~~~~~~~
>
> Nobody gets to push to master directly. Instead, every push to master is
> diverted? to a temporary branch "validating/<some id>". One of our
> servers detects the appearance of such a branch and will
>   * check it out,
>   * validate it,
>   * if ok: check if master can still be fast-forward?ed to it,
>   * if yes: push to master.
>
> If it does not validate, or if master has changed in between, the branch
> will be moved to failed/<some id>, and a message is sent to the pushing
> developer?, including a tail of the log and a link to the full log.

The system should try to rebase and re-validate automatically in this 
case.  I think this is pretty important - otherwise pushes can fail for 
random reasons that are no fault of the developer.

Actually I'd even go so far as to say that if the rebase succeeds 
without conflicts then the push should go ahead.  Yes this can introduce 
bugs, but since a validate takes ~30 minutes at a certain rate of 
commits it becomes impossible to push anything if the tree must be 
validated and fast-forwarded to push.

Also, bear in mind that since this stands between a developer and 
getting their changes in, it really must work, all the time.  Be careful 
what you're signing up for :-)  My feeling is that as a first step this 
system should be treated as a validation service: we don't force people 
to use it if they don't want to, so that we can see how well it works 
over time and developers can gradually migrate to using it.  On that 
basis I'd be really happy to see it, and possibly to rely on it more 
over time.

Cheers,
Simon



> Systems can fail, and maybe nothing validates anymore for reasons not
> easily fixable. For that case, a backdoor is available: Pushes to the
> branch "master-unchecked" will be moved to master, well, unchecked.
>
> Benefits:
>   * It is guaranteed that master has validated at least once somewhere.
>     I.e. no need to ask on the mailing list ?does master validate for you
>     right now??
>   * It is now ok to do changes that are ?obviously correct? (comment
>     changes, removing dead code, code reformatting) without having
>     to validate manually, which _saves developer time_ (our most precious
>     resource).
>
> Downsides:
>   * When two commits are racing for master, one will be rejected for
>     being a non-fast-forward commit. The user will then have to merge
>     or rebase and try again.
>     But: The same would be true if he was validating locally (unless he
>     does not validate the merge/rebase, in which case we are again where
>     we don?t want to be: Unvalidated versions in master.)
>
>
> Is this something you would what, or could live with?
>
> If it is technically feasible (given our hardware constraints,
> repository structure and git?s feature) is a different question, which
> needs to be discussed afterwards.
>
> Greetings,
> Joachim
>
>
>
> ? Might not be possible transparently
> (http://stackoverflow.com/questions/21362833), but for the sake of
> argument and workflow design, assume it was.
> ? As an approximation: The committer of the latest patch.
>
> PS: I?m also considering (but not pushing hard) for a stronger variant
> as follows. We do not need to discuss that now and should, if at all,
> start the with the proposal above. I?m just adding it to show where this
> is going ...
>
> Stronger proposal
> ~~~~~~~~~~~~~~~~~
>
>          Every commit in master needs to be validated!
> I tend to make sure that all patches on my branch validate individually
> (git rebase -i -x "./validate" is a great tool here, you should use it!
> ). Contributors who do not want to go through that trouble should then
> use "git merge --squash" to produce a single commit from their branch.
>
> This would make the git history more useful for things like bitsecting.
>
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From marlowsd at gmail.com  Sat Feb  8 17:07:43 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 08 Feb 2014 09:07:43 -0800
Subject: Support for glibc 2.12 in 7.8 RC2
In-Reply-To: <CACYs5Ab3Okr3DhFvi2HXbhjqo-kYQ0Asi9jKT6v9Wh-5T7CatA@mail.gmail.com>
References: <CA+ZOas+-1spbmNkJvXF-K8EAdVB7-M6YX2HgQu2BjKPZgXTrLA@mail.gmail.com>
 <CACYs5Ab3Okr3DhFvi2HXbhjqo-kYQ0Asi9jKT6v9Wh-5T7CatA@mail.gmail.com>
Message-ID: <52F6645F.9010108@gmail.com>

These are just the binary builds, you can bootstrap it on your own 
system to support whatever glibc version you have.

Cheers,
Simon

On 07/02/2014 18:05, Ryan Newton wrote:
> Yes, this is a really annoying issue on RHEL, which includes many
> supercomputers.
>
> Sent from my phone.
>
> On Feb 7, 2014 1:35 PM, "Rob Stewart" <robstewart57 at gmail.com
> <mailto:robstewart57 at gmail.com>> wrote:
>
>     Hi,
>
>     The 7.8 RC1 status page [1] states RC1 requires glibc 2.15, and that
>     RC2 will support glibc 2.13 to target Debian 7. CentOS 6 packages
>     glibc 2.12 and this will be the glibc version in the CentOS 6
>     lifetime.
>
>     Is there a possibility of stretching lower bounded support in RC2 down
>     to glibc 2.12? This would allow all CentOS users using any of the 6.*
>     releases to use 7.8, I think.
>
>     [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC1
>
>     --
>     Rob
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From mail at joachim-breitner.de  Sat Feb  8 18:19:34 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 08 Feb 2014 18:19:34 +0000
Subject: Pre-Master checks (Was: Nightlies)
In-Reply-To: <52F66075.6070000@gmail.com>
References: <52E4714B.5060905@fuuzetsu.co.uk> <1390734969.2515.6.camel@kirk>
 <CAEs96n0i0nQ+yqCq4rmCh4cR8Ph_cAH1eoQ7WhitEUOcTKACDQ@mail.gmail.com>
 <CAEs96n3Aj_qtmPVKsO34WOrbfntduyoo0Y-ggbJVJjCjWSj+Vw@mail.gmail.com>
 <1390816044.2549.3.camel@kirk>
 <59543203684B2244980D7E4057D5FBC148761B86@DB3EX14MBXC312.europe.corp.microsoft.com>
 <1391506898.2719.23.camel@kirk> <52F66075.6070000@gmail.com>
Message-ID: <1391883574.2539.29.camel@kirk>

Hi,

Am Samstag, den 08.02.2014, 08:51 -0800 schrieb Simon Marlow:
> The system should try to rebase and re-validate automatically in this 
> case.  I think this is pretty important - otherwise pushes can fail for 
> random reasons that are no fault of the developer.
> 
> Actually I'd even go so far as to say that if the rebase succeeds 
> without conflicts then the push should go ahead.  Yes this can introduce 
> bugs, but since a validate takes ~30 minutes at a certain rate of 
> commits it becomes impossible to push anything if the tree must be 
> validated and fast-forwarded to push.

I?d actually prefer that behavior; I just didn?t want to put it in the
proposal because people might be much too scared by the prospect of
patches entering master that no human eye has seen so far ? but after
someone suggested the same to me in private, and you now on the list, I
guess it would be a viable.

> Also, bear in mind that since this stands between a developer and 
> getting their changes in, it really must work, all the time.  Be careful 
> what you're signing up for :-)  My feeling is that as a first step this 
> system should be treated as a validation service: we don't force people 
> to use it if they don't want to, so that we can see how well it works 
> over time and developers can gradually migrate to using it.  On that 
> basis I'd be really happy to see it, and possibly to rely on it more 
> over time.

Correct: If I were to implement this (which has to wait for
http://hackage.haskell.org/trac/ghc/ticket/8545 to be reasonably
reliable) I?d set it up first as _alternative_ way to push, inviting
validate-lazy developers to use it instead of master. And if it works
great, we can consider making it mandatory (or at least the default).


So there seems to be a consensus here that this is a worthwhile feature.
Great!

Is there a roadmap for #8545?


Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140208/c9473944/attachment.sig>

From karel.gardas at centrum.cz  Sun Feb  9 21:11:47 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sun,  9 Feb 2014 22:11:47 +0100
Subject: [PATCH] fix compilation on Solaris 10 with GNU C 3.4.3
Message-ID: <1391980307-24131-1-git-send-email-karel.gardas@centrum.cz>

This patch fixes compilation on Solaris 10 platform which provides
GNU C 3.4.3 by default by removing unsupported -ftree-vectorize option.
This may penalize Solaris 11, where GNU C 4.6.2 is provided but current
cabal does not support OSes version detection and Solaris 10 is still
supported (by Oracle) and will be at least till 2021 so let's support it
too.
---
 primitive.cabal | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/primitive.cabal b/primitive.cabal
index b819e03..666a8f2 100644
--- a/primitive.cabal
+++ b/primitive.cabal
@@ -44,7 +44,9 @@ Library
   Install-Includes: primitive-memops.h
   includes: primitive-memops.h
   c-sources: cbits/primitive-memops.c
-  cc-options: -O3 -ftree-vectorize -fomit-frame-pointer -Wall
+  cc-options: -O3 -fomit-frame-pointer -Wall
+  if !os(solaris)
+      cc-options: -ftree-vectorize
   if arch(i386) || arch(x86_64)
       cc-options: -msse2
 
-- 
1.8.1.4


From karel.gardas at centrum.cz  Sun Feb  9 21:12:49 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sun,  9 Feb 2014 22:12:49 +0100
Subject: [PATCH 1/2] add --with-ar and --with-ranlib configure parameters
Message-ID: <1391980369-24173-1-git-send-email-karel.gardas@centrum.cz>

Both --with-ar and --with-ranlib are usable on non-GNU/Linux systems
where GNU tools are usually installed (or possible to install), but
not into standard location nor with standard name. Tested on Solaris 10.
---
 configure.ac    | 15 +++++++++++++++
 mk/config.mk.in |  1 +
 2 files changed, 16 insertions(+)

diff --git a/configure.ac b/configure.ac
index e7fbc7f..244fcc0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -486,6 +486,21 @@ FP_ARG_WITH_PATH_GNU_PROG([NM], [nm], [nm])
 NmCmd="$NM"
 AC_SUBST([NmCmd])
 
+dnl ** Which ar to use?
+dnl --------------------------------------------------------------
+FP_ARG_WITH_PATH_GNU_PROG([AR], [ar], [ar])
+ArCmd="$AR"
+fp_prog_ar="$AR"
+AC_SUBST([ArCmd])
+
+dnl ** Which ranlib to use?
+dnl --------------------------------------------------------------
+FP_ARG_WITH_PATH_GNU_PROG([RANLIB], [ranlib], [ranlib])
+RanlibCmd="$RANLIB"
+RANLIB="$RanlibCmd"
+AC_SUBST([RanlibCmd])
+
+
 # Note: we may not have objdump on OS X, and we only need it on Windows (for DLL checks)
 case $HostOS_CPP in
 cygwin32|mingw32)
diff --git a/mk/config.mk.in b/mk/config.mk.in
index b3d6995..8c0eb49 100644
--- a/mk/config.mk.in
+++ b/mk/config.mk.in
@@ -650,6 +650,7 @@ DTRACE			= @DtraceCmd@
 
 LD = @LdCmd@
 NM = @NmCmd@
+AR = @ArCmd@
 OBJDUMP = @ObjdumpCmd@
 
 LLC = @LlcCmd@
-- 
1.8.1.4


From karel.gardas at centrum.cz  Sun Feb  9 21:13:07 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sun,  9 Feb 2014 22:13:07 +0100
Subject: [PATCH 2/2] use detected GNU sed on expression where Solaris' fails.
Message-ID: <1391980387-24212-1-git-send-email-karel.gardas@centrum.cz>

We set SED make variable to configure detected GNU sed command for quite
some time now, but surprisingly it is not used in other makefiles. Anyway,
this patch fixes a real issue on Solaris 10 where distributed Sun/Oracle
sed is not able to cope with required expression, but GNU sed is.
The patch is minimal to lower the risk of breakage, but the other approach
of fixing all occurrences of `sed' to `$(SED)' is of course also possible.
---
 rules/build-dependencies.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules/build-dependencies.mk b/rules/build-dependencies.mk
index 79350c0..896efa8 100644
--- a/rules/build-dependencies.mk
+++ b/rules/build-dependencies.mk
@@ -53,7 +53,7 @@ endif
 #     Foo.dyn_o Foo.o : Foo.hs
 # lines, and create corresponding hi-rule lines
 #     <dollar>(eval <dollar>(call hi-rule,Foo.dyn_hi Foo.hi : %hi: %o Foo.hs))
-	sed '/hs$$$$/ p                                      ; \
+	$(SED) '/hs$$$$/ p                                      ; \
 	     /hs$$$$/ s/o /hi /g                             ; \
 	     /hs$$$$/ s/:/ : %hi: %o /                       ; \
 	     /hs$$$$/ s/^/$$$$(eval $$$$(call hi-rule,/      ; \
-- 
1.8.1.4


From karel.gardas at centrum.cz  Mon Feb 10 07:32:31 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Mon, 10 Feb 2014 08:32:31 +0100
Subject: make binary-dist on Solaris 10.
Message-ID: <52F8808F.2040305@centrum.cz>


Folks,

I'm trying to kind of resurrect Solaris 10 support. Got to `make 
binary-dist' already but now this fails with:

cd bindistprep && "/usr/sfw/bin/gtar" hcf - -T ../bindist-list | bzip2 
-c > ../bindistprep/ghc-7.8.20140130-i386-unknown-solaris2.tar.bz2
/usr/sfw/bin/gtar: ghc-7.8.20140130/compiler/stage2/doc: Cannot stat: No 
such file or directory
/usr/sfw/bin/gtar: Error exit delayed from previous errors
mv bindistprep/*.tar.bz2 .

I'd just like to ask here, any idea what tool is responsible for 
generating this doc content in compiler's stage2 dir? My idea is that 
some tool(s) is missing on Solaris 10, configure detects this, general 
build is fine then, but bindist counts with the `doc' dir populated. So 
just let me know into what direction I shall look...

Thanks!
Karel


From carter.schonwald at gmail.com  Mon Feb 10 07:46:39 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 10 Feb 2014 02:46:39 -0500
Subject: make binary-dist on Solaris 10.
In-Reply-To: <52F8808F.2040305@centrum.cz>
References: <52F8808F.2040305@centrum.cz>
Message-ID: <CAHYVw0ygZT+Tb-+v9QYX7ZNLXiNOgic+GzLise4o2fO3XsxE8g@mail.gmail.com>

could be worth throwing a ticket on track for this.

Likewise, for the patches your hacking out, could you also put them on trac
TOO? Hard to make sure core ghc devs can keep track of those patches
otherwise (let along have a centralized log of the discussion)


On Mon, Feb 10, 2014 at 2:32 AM, Karel Gardas <karel.gardas at centrum.cz>wrote:

>
> Folks,
>
> I'm trying to kind of resurrect Solaris 10 support. Got to `make
> binary-dist' already but now this fails with:
>
> cd bindistprep && "/usr/sfw/bin/gtar" hcf - -T ../bindist-list | bzip2 -c
> > ../bindistprep/ghc-7.8.20140130-i386-unknown-solaris2.tar.bz2
> /usr/sfw/bin/gtar: ghc-7.8.20140130/compiler/stage2/doc: Cannot stat: No
> such file or directory
> /usr/sfw/bin/gtar: Error exit delayed from previous errors
> mv bindistprep/*.tar.bz2 .
>
> I'd just like to ask here, any idea what tool is responsible for
> generating this doc content in compiler's stage2 dir? My idea is that some
> tool(s) is missing on Solaris 10, configure detects this, general build is
> fine then, but bindist counts with the `doc' dir populated. So just let me
> know into what direction I shall look...
>
> Thanks!
> Karel
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140210/f0cd0ace/attachment.html>

From mail at joachim-breitner.de  Mon Feb 10 10:50:40 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 10 Feb 2014 10:50:40 +0000
Subject: Extending fold/build fusion
In-Reply-To: <CAOGQyFsFxRQY--KVpZBJOgY3ZHxwb3Oxgk5T=03Ofj8FPBi4wg@mail.gmail.com>
References: <CAOGQyFsnEsvS47+PaMSZvWkPOPsjYfmbuC6Bfm02r-VX6t6-Dw@mail.gmail.com>
 <1390932396.2641.46.camel@kirk>
 <CAOGQyFup3pZ_H_9f148WK5-LucpfSCe0XPg=PgYxDdR4Q0aOLw@mail.gmail.com>
 <1391159897.3184.10.camel@kirk>
 <CAOGQyFsFxRQY--KVpZBJOgY3ZHxwb3Oxgk5T=03Ofj8FPBi4wg@mail.gmail.com>
Message-ID: <1392029440.7172.2.camel@kirk>

Dear Takano,

did you manage to apply fold/build fusion to the standard libraries, and
run nofib? 

I guess your starting point should be
http://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources
and then you can start changing libraries/base. Best if you create two
working copies, one that you do not change and one with your changes.
Then you can run nofib in both:
https://ghc.haskell.org/trac/ghc/wiki/Building/RunningNoFib
and compare the results.

Do you need help with that? Come by #ghc on freenode!

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140210/2ed50474/attachment.sig>

From karel.gardas at centrum.cz  Mon Feb 10 20:33:57 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Mon, 10 Feb 2014 21:33:57 +0100
Subject: make binary-dist on Solaris 10.
In-Reply-To: <52F8808F.2040305@centrum.cz>
References: <52F8808F.2040305@centrum.cz>
Message-ID: <52F937B5.3000804@centrum.cz>


Sorry for making this noise, but this was my mistake. I've build GHC 
with quick flavor set in mk/build.mk and this way nobody can wonder why 
there is no doc generated.

Now, with a little bit of patching (by patches I already provided), I'm 
able to build functional Solaris 10 based binary distribution from RC1.

Karel

On 02/10/14 08:32 AM, Karel Gardas wrote:
>
> Folks,
>
> I'm trying to kind of resurrect Solaris 10 support. Got to `make
> binary-dist' already but now this fails with:
>
> cd bindistprep && "/usr/sfw/bin/gtar" hcf - -T ../bindist-list | bzip2
> -c > ../bindistprep/ghc-7.8.20140130-i386-unknown-solaris2.tar.bz2
> /usr/sfw/bin/gtar: ghc-7.8.20140130/compiler/stage2/doc: Cannot stat: No
> such file or directory
> /usr/sfw/bin/gtar: Error exit delayed from previous errors
> mv bindistprep/*.tar.bz2 .
>
> I'd just like to ask here, any idea what tool is responsible for
> generating this doc content in compiler's stage2 dir? My idea is that
> some tool(s) is missing on Solaris 10, configure detects this, general
> build is fine then, but bindist counts with the `doc' dir populated. So
> just let me know into what direction I shall look...
>
> Thanks!
> Karel
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>


From tkn.akio at gmail.com  Mon Feb 10 23:04:03 2014
From: tkn.akio at gmail.com (Akio Takano)
Date: Tue, 11 Feb 2014 08:04:03 +0900
Subject: Extending fold/build fusion
In-Reply-To: <1392029440.7172.2.camel@kirk>
References: <CAOGQyFsnEsvS47+PaMSZvWkPOPsjYfmbuC6Bfm02r-VX6t6-Dw@mail.gmail.com>
 <1390932396.2641.46.camel@kirk>
 <CAOGQyFup3pZ_H_9f148WK5-LucpfSCe0XPg=PgYxDdR4Q0aOLw@mail.gmail.com>
 <1391159897.3184.10.camel@kirk>
 <CAOGQyFsFxRQY--KVpZBJOgY3ZHxwb3Oxgk5T=03Ofj8FPBi4wg@mail.gmail.com>
 <1392029440.7172.2.camel@kirk>
Message-ID: <CAOGQyFt1RnFX_pv8a=SX9FTQvXqRLGF2-tN38m-3kDt=r++c-Q@mail.gmail.com>

I modified the base library to use foldrW/buildW, with no changes to
foldl yet. nofib showed a very big regression in cryptarithm2, so I'm
looking into it.

Thank you for your help,
Akio

On Mon, Feb 10, 2014 at 7:50 PM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Dear Takano,
>
> did you manage to apply fold/build fusion to the standard libraries, and
> run nofib?

From nicolas.frisby at gmail.com  Tue Feb 11 03:32:15 2014
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Mon, 10 Feb 2014 21:32:15 -0600
Subject: workaround to get both domain-specific errors and also
 multi-modal type inference?
In-Reply-To: <52F53C72.5050305@well-typed.com>
References: <CADfHYo436qCHcPsiG+gS2WcSCn8s6ThsavdmQoiTPQv1tEnW_A@mail.gmail.com>
 <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
 <52F53C72.5050305@well-typed.com>
Message-ID: <CADfHYo4exYoPObt8X7=s8QRh1+NcmxFe2+EDuPruUL0MAp5rdg@mail.gmail.com>

Hi Adam. Thanks very much for the response. I'm sorry if the rest of this
reads negatively -- I'm on my phone and hence perhaps curt. I'm excited
about any dialog here!

(I'll mention that Dimitrios Vytiniotis and Geoffrey Mainland had expressed
low priority interest in these topics about a year ago.)

I agree that this is a difficult problem. I think the eventual solution
deserves far more attention than I can currently allocate. Hence, I was
hoping for a workaround "trick" in the mean time.

It seems to me that such a trick is currently unlikely. So I proposed a
light-weight limited-scope patch. Something along the lines of "don't let
perfect be the enemy of good."

My main concern with the interface you sketched is how we would pattern
match on the demoted Constraint, since Constraint is an open kind. Also,
there's unsafePerformIO et al to somehow preclude. The interface does look
nicer that way, but it would be simpler to stick to type-level computation,
where no "exotic" new mechanisms would be needed.

Maybe there's a middle ground.

> type family GHC.Exts.Message (c :: Constraint) :: Maybe Symbol

GHC would report the result of this family for any unsatisfied constraint
that has a matching instance that returns Just msg.

Perhaps GHC even first replaces skolem type variables with an application
of GHC.Exts.Skolem :: Symbol -> k -> k before checking for instances.

Of course, the Symbol operations are rather anemic at the moment, but I
think improvements there would be valuable as well. Or perhaps Message
could yield a type-level Doc data kind that GHC interprets to build a
String.

Lastly, I think custom constraint solving sounds like a very delicate
language extension, with wide reaching consequences. Unless there's a
strong champion dedicated to extensible custom constraint solving, I hope
the much more modestly scoped issue of custom error messages can be
considered separately for at least one design iteration. I feel like a
near-term implementation is more likely that way.

Thanks again for this conversation!
On Feb 7, 2014 2:05 PM, "Adam Gundry" <adam at well-typed.com> wrote:

> Hi,
>
> Good error messages are a hard problem. That said, I think little tweaks
> like this might make sense. Richard Eisenberg and I were discussing this
> earlier, and we wondered if the following might provide an alternative
> approach:
>
> Suppose a module provides a function
>
>     describeError :: Constraint -> Maybe String
>
> (exact type up for discussion). This could be called by the typechecker
> when reporting errors in other modules, to provide a domain-specific
> error message. Do you think this might work for your use case?
>
> We need to think about how to mark this function as special: one option
> is to provide a built-in typeclass like
>
>     class TypeCheckerPlugin a where
>       describeError :: Constraint -> Maybe String
>
> and look for instances of this class. Interestingly, the class type is
> irrelevant here; we're not interested in solving constraints involving
> this class, just looking at the imported instances when running the
> typechecker. Perhaps using a pragma might be more principled.
>
> This came up in the context of a more general discussion of plugins to
> extend the typechecker. For example, we might consider doing something
> similar to *solve* constraints in a domain-specific way, as well as
> reporting errors.
>
> Sound plausible?
>
> Adam
>
>
> On 30/01/14 21:09, Nicolas Frisby wrote:
> > Also, on the topic of patching GHC for domain-specific error messages,
> > why not add a simple means to emit a custom error message? It would beat
> > piggy-backing on the "no instance" messages as I currently plan to.
> >
> > This seems safe and straight-forward:
> >
> >> -- wired-in, cannot be instantiated
> >> class GHC.Exts.PrintError (msg :: Symbol) (args :: [k])
> >
> > Consider the class C fromy previous email. It's possible these two
> > instances are now sufficient.
> >
> >> instance C a b
> >> instance PrintError ("You used %1 on the left and %2 on the right!" ::
> > Symbol) [a,b] => C a b
> >
> > And let's not forget warnings!
> >
> >> -- wired-in, cannot be instantiated
> >> class GHC.Exts.PrintWarn (msg :: Symbol) (args :: '[k])
> >
> > Thanks again.
> >
> >
> > On Thu, Jan 30, 2014 at 3:07 PM, Nicolas Frisby
> > <nicolas.frisby at gmail.com <mailto:nicolas.frisby at gmail.com>> wrote:
> >
> >     Hi all. I have a question for those savvy to the type-checker's
> >     internal workings.
> >
> >     For uses of the following function, can anyone suggest a means of
> >     forcing GHC to attempt to solve C a b even if a~b fails?
> >
> >     > dslAsTypeOf :: (C a b,a~b) => a -> b -> a
> >     > dslAsTypeOf x _ = x
> >     >
> >     > class C a b -- no methods
> >
> >     Just for concreteness, the following are indicative of the variety
> >     of instances that I expect C to have. (I don't think this actually
> >     affects the question above.)
> >
> >     > instance C DSLType1 DSLType1
> >     > instance C DSLType2 DSLType2
> >     > instance C x y => C (DSLType3 x) (DSLType3 y)
> >     >
> >     > instance IndicativeErrorMessage1 => C DSLType1 DSLType2
> >     > instance IndicativeErrorMessage2 => C DSLType2 (DSLType3 y)
> >     >
> >     > class IndicativeErrorMessage1 -- will never have instances
> >     > class IndicativeErrorMessage2 -- will never have instances
> >
> >     Thank you for your time.
> >
> >     ===================================
> >
> >     Keep reading for the "short story", the "long story", and two ideas
> >     for a small GHC patch that would enable my technique outlined above.
> >
> >     ===== short story =====
> >
> >     The motivation of dslAsTypeOf is to provide improved error messages
> >     when a and b are not equal.
> >
> >     Unfortunately, the user will never see IndicativeErrorMessage. It
> >     appears that GHC does not attempt to solve C a b if a~b fails.
> >     That's understandable, since the solution of C a b almost certainly
> >     depends on the "value" of its arguments...
> >
> >     Hence, the question at the top of this email.
> >
> >     ===== long story =====
> >
> >     A lot of the modern type-level programming capabilities can be put
> >     to great use in creating type systems for embedded domain specific
> >     languages. These type systems can enforce some impressive properties.
> >
> >     However, the error messages you get when one of those property is
> >     not satisfied can be pretty abysmal.
> >
> >     In my particular case, I have a phantom type where the tag carries
> >     all the domain-specific information.
> >
> >     > newtype U (tag :: [Info]) a = U a
> >
> >     and I have an binary operation that requires the tag to be
> >     equivalent for all three types.
> >
> >     > plus :: Num a => U tag a -> U tag a -> U tag a
> >     > plus (U x) (U y) = U $ x + y
> >
> >     This effectively enforces the property I want for U values.
> >     Unfortunately, the error messages can seem dimwitted.
> >
> >     > ill_typed = plus (U 1 :: U [Foo,Bar,Baz] Int)  (U 2 :: U [Foo,Baz]
> >     Int)
> >
> >     The `ill_typed` value gives an error message (in GHC 7.8) saying
> >
> >       Bar : Baz : []      is not equal to       Baz : []
> >
> >     (It's worse in GHC 7.4. I don't have access to a 7.6 at the moment.)
> >
> >     I'd much rather have it say that "Bar is missing from the first
> >     summand's list." And I can define a class that effectively conveys
> >     that information in a "domain-specific error message" which is
> >     actually a "no instance of <IndicativeClassName> tag1 tag2" message.
> >
> >     > friendlier_plus :: (FriendlyEqCheck tag1 tag2 tag3,Num a) => U
> >     tag1 a -> U tag2 a -> U tag3 a
> >
> >     The `friendlier_plus' function gives useful error messages if tag1,
> >     tag2, and tag3 are all fully monomorphic.
> >
> >     However, it does not support inference:
> >
> >     > zero :: Num a => U tag a
> >     > zero = U 0
> >     >
> >     > x = U 4 :: U [Foo,Baz] Int
> >     >
> >     > -- both of these are ill-typed :(
> >     > should_work1 = (friendlier_plus zero x) `asTypeOf` x    -- tag1 is
> >     unconstrained
> >     > should_work2 = friendlier_plus x x     -- tag3 is unconstrained
> >
> >     Neither of those terms type-check, since FriendlyEqCheck can't
> >     determine if the unconstrained `tag' variable is equal to the other
> >     tags.
> >
> >     So, can we get the best of both worlds?
> >
> >     > best_plus ::
> >     >   ( FriendlyEqCheck tag1 tag2 tag3
> >          , tag1 ~ tag2, tag2 ~ tag3, Num a) => U tag1 a -> U tag2 a -> U
> >     tag3 a
> >
> >     No, unfortunately not. Now the `should_work*' functions type-check,
> >     but an ill-typed use of `best_plus' gives the same poor error
> >     message that `plus' would give.
> >
> >     Hence, the question at the top of this email.
> >
> >     ===== two ideas =====
> >
> >     If my question at the top of this email cannot be answered in the
> >     affirmative, perhaps a small patch to GHC would make this sort of
> >     approach a viable lightweight workaround for improving
> >     domain-specific error messages.
> >
> >     (I cannot estimate how difficult this would be to implement in the
> >     type-checker.)
> >
> >     Two alternative ideas.
> >
> >     1) An "ALWAYS_ATTEMPT" PRAGMA that you can place on the class C so
> >     that it is attempted even if a related ~ constraint fails.
> >
> >     2) An OrElse constraint former, offering *very* constrained
> >     back-tracking.
> >
> >     > possibleAsTypeOf :: ((a ~ b) `OrElse` C a b) => a -> b -> a
> >     > possibleAsTypeOf x _ = x
> >
> >     Requirements: C must have no superclasses, no methods, and no
> fundeps.
> >
> >     Specification: If (a~b) fails and (C a b) is satisfiable, then the
> >     original inequality error message would be shown to the user. Else,
> >     C's error message is used.
> >
> >     ===================================
> >
> >     You made it to the bottom of the email! Thanks again.
> >
> >
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140210/89128fbc/attachment-0001.html>

From jpm at cs.uu.nl  Tue Feb 11 09:55:19 2014
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Tue, 11 Feb 2014 09:55:19 +0000
Subject: workaround to get both domain-specific errors and also
 multi-modal type inference?
In-Reply-To: <CADfHYo4exYoPObt8X7=s8QRh1+NcmxFe2+EDuPruUL0MAp5rdg@mail.gmail.com>
References: <CADfHYo436qCHcPsiG+gS2WcSCn8s6ThsavdmQoiTPQv1tEnW_A@mail.gmail.com>
 <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
 <52F53C72.5050305@well-typed.com>
 <CADfHYo4exYoPObt8X7=s8QRh1+NcmxFe2+EDuPruUL0MAp5rdg@mail.gmail.com>
Message-ID: <CA+ZFbn94=x-9dk9bgsuKih3+VTSpFnS_BpQg10=a4JxvCwwbew@mail.gmail.com>

On Tue, Feb 11, 2014 at 3:32 AM, Nicolas Frisby <nicolas.frisby at gmail.com>wrote:

> Hi Adam. Thanks very much for the response. I'm sorry if the rest of this
> reads negatively -- I'm on my phone and hence perhaps curt. I'm excited
> about any dialog here!
>
> (I'll mention that Dimitrios Vytiniotis and Geoffrey Mainland had
> expressed low priority interest in these topics about a year ago.)
>
> I agree that this is a difficult problem. I think the eventual solution
> deserves far more attention than I can currently allocate. Hence, I was
> hoping for a workaround "trick" in the mean time.
>
> It seems to me that such a trick is currently unlikely. So I proposed a
> light-weight limited-scope patch. Something along the lines of "don't let
> perfect be the enemy of good."
>
> My main concern with the interface you sketched is how we would pattern
> match on the demoted Constraint, since Constraint is an open kind. Also,
> there's unsafePerformIO et al to somehow preclude. The interface does look
> nicer that way, but it would be simpler to stick to type-level computation,
> where no "exotic" new mechanisms would be needed.
>
> Maybe there's a middle ground.
>
> > type family GHC.Exts.Message (c :: Constraint) :: Maybe Symbol
>

While I do find this problem very relevant, and think this solution is
going in the right direction,
I'm afraid it's not that simple. Say I have

  type instance Message (MyClass a) = Just ...

How will this behave if the unsatisfied constraint is of the form (C b,
MyClass a)? How about
f (MyClass a), for some f :: Constraint -> Constraint?

Also, isn't it a bit unsatisfying that an instance such as

  type instance Message a = Just ...

would pollute error messages everywhere?...


Cheers,
Pedro


> GHC would report the result of this family for any unsatisfied constraint
> that has a matching instance that returns Just msg.
>
> Perhaps GHC even first replaces skolem type variables with an application
> of GHC.Exts.Skolem :: Symbol -> k -> k before checking for instances.
>
> Of course, the Symbol operations are rather anemic at the moment, but I
> think improvements there would be valuable as well. Or perhaps Message
> could yield a type-level Doc data kind that GHC interprets to build a
> String.
>
> Lastly, I think custom constraint solving sounds like a very delicate
> language extension, with wide reaching consequences. Unless there's a
> strong champion dedicated to extensible custom constraint solving, I hope
> the much more modestly scoped issue of custom error messages can be
> considered separately for at least one design iteration. I feel like a
> near-term implementation is more likely that way.
>
> Thanks again for this conversation!
> On Feb 7, 2014 2:05 PM, "Adam Gundry" <adam at well-typed.com> wrote:
>
>> Hi,
>>
>> Good error messages are a hard problem. That said, I think little tweaks
>> like this might make sense. Richard Eisenberg and I were discussing this
>> earlier, and we wondered if the following might provide an alternative
>> approach:
>>
>> Suppose a module provides a function
>>
>>     describeError :: Constraint -> Maybe String
>>
>> (exact type up for discussion). This could be called by the typechecker
>> when reporting errors in other modules, to provide a domain-specific
>> error message. Do you think this might work for your use case?
>>
>> We need to think about how to mark this function as special: one option
>> is to provide a built-in typeclass like
>>
>>     class TypeCheckerPlugin a where
>>       describeError :: Constraint -> Maybe String
>>
>> and look for instances of this class. Interestingly, the class type is
>> irrelevant here; we're not interested in solving constraints involving
>> this class, just looking at the imported instances when running the
>> typechecker. Perhaps using a pragma might be more principled.
>>
>> This came up in the context of a more general discussion of plugins to
>> extend the typechecker. For example, we might consider doing something
>> similar to *solve* constraints in a domain-specific way, as well as
>> reporting errors.
>>
>> Sound plausible?
>>
>> Adam
>>
>>
>> On 30/01/14 21:09, Nicolas Frisby wrote:
>> > Also, on the topic of patching GHC for domain-specific error messages,
>> > why not add a simple means to emit a custom error message? It would beat
>> > piggy-backing on the "no instance" messages as I currently plan to.
>> >
>> > This seems safe and straight-forward:
>> >
>> >> -- wired-in, cannot be instantiated
>> >> class GHC.Exts.PrintError (msg :: Symbol) (args :: [k])
>> >
>> > Consider the class C fromy previous email. It's possible these two
>> > instances are now sufficient.
>> >
>> >> instance C a b
>> >> instance PrintError ("You used %1 on the left and %2 on the right!" ::
>> > Symbol) [a,b] => C a b
>> >
>> > And let's not forget warnings!
>> >
>> >> -- wired-in, cannot be instantiated
>> >> class GHC.Exts.PrintWarn (msg :: Symbol) (args :: '[k])
>> >
>> > Thanks again.
>> >
>> >
>> > On Thu, Jan 30, 2014 at 3:07 PM, Nicolas Frisby
>> > <nicolas.frisby at gmail.com <mailto:nicolas.frisby at gmail.com>> wrote:
>> >
>> >     Hi all. I have a question for those savvy to the type-checker's
>> >     internal workings.
>> >
>> >     For uses of the following function, can anyone suggest a means of
>> >     forcing GHC to attempt to solve C a b even if a~b fails?
>> >
>> >     > dslAsTypeOf :: (C a b,a~b) => a -> b -> a
>> >     > dslAsTypeOf x _ = x
>> >     >
>> >     > class C a b -- no methods
>> >
>> >     Just for concreteness, the following are indicative of the variety
>> >     of instances that I expect C to have. (I don't think this actually
>> >     affects the question above.)
>> >
>> >     > instance C DSLType1 DSLType1
>> >     > instance C DSLType2 DSLType2
>> >     > instance C x y => C (DSLType3 x) (DSLType3 y)
>> >     >
>> >     > instance IndicativeErrorMessage1 => C DSLType1 DSLType2
>> >     > instance IndicativeErrorMessage2 => C DSLType2 (DSLType3 y)
>> >     >
>> >     > class IndicativeErrorMessage1 -- will never have instances
>> >     > class IndicativeErrorMessage2 -- will never have instances
>> >
>> >     Thank you for your time.
>> >
>> >     ===================================
>> >
>> >     Keep reading for the "short story", the "long story", and two ideas
>> >     for a small GHC patch that would enable my technique outlined above.
>> >
>> >     ===== short story =====
>> >
>> >     The motivation of dslAsTypeOf is to provide improved error messages
>> >     when a and b are not equal.
>> >
>> >     Unfortunately, the user will never see IndicativeErrorMessage. It
>> >     appears that GHC does not attempt to solve C a b if a~b fails.
>> >     That's understandable, since the solution of C a b almost certainly
>> >     depends on the "value" of its arguments...
>> >
>> >     Hence, the question at the top of this email.
>> >
>> >     ===== long story =====
>> >
>> >     A lot of the modern type-level programming capabilities can be put
>> >     to great use in creating type systems for embedded domain specific
>> >     languages. These type systems can enforce some impressive
>> properties.
>> >
>> >     However, the error messages you get when one of those property is
>> >     not satisfied can be pretty abysmal.
>> >
>> >     In my particular case, I have a phantom type where the tag carries
>> >     all the domain-specific information.
>> >
>> >     > newtype U (tag :: [Info]) a = U a
>> >
>> >     and I have an binary operation that requires the tag to be
>> >     equivalent for all three types.
>> >
>> >     > plus :: Num a => U tag a -> U tag a -> U tag a
>> >     > plus (U x) (U y) = U $ x + y
>> >
>> >     This effectively enforces the property I want for U values.
>> >     Unfortunately, the error messages can seem dimwitted.
>> >
>> >     > ill_typed = plus (U 1 :: U [Foo,Bar,Baz] Int)  (U 2 :: U [Foo,Baz]
>> >     Int)
>> >
>> >     The `ill_typed` value gives an error message (in GHC 7.8) saying
>> >
>> >       Bar : Baz : []      is not equal to       Baz : []
>> >
>> >     (It's worse in GHC 7.4. I don't have access to a 7.6 at the moment.)
>> >
>> >     I'd much rather have it say that "Bar is missing from the first
>> >     summand's list." And I can define a class that effectively conveys
>> >     that information in a "domain-specific error message" which is
>> >     actually a "no instance of <IndicativeClassName> tag1 tag2" message.
>> >
>> >     > friendlier_plus :: (FriendlyEqCheck tag1 tag2 tag3,Num a) => U
>> >     tag1 a -> U tag2 a -> U tag3 a
>> >
>> >     The `friendlier_plus' function gives useful error messages if tag1,
>> >     tag2, and tag3 are all fully monomorphic.
>> >
>> >     However, it does not support inference:
>> >
>> >     > zero :: Num a => U tag a
>> >     > zero = U 0
>> >     >
>> >     > x = U 4 :: U [Foo,Baz] Int
>> >     >
>> >     > -- both of these are ill-typed :(
>> >     > should_work1 = (friendlier_plus zero x) `asTypeOf` x    -- tag1 is
>> >     unconstrained
>> >     > should_work2 = friendlier_plus x x     -- tag3 is unconstrained
>> >
>> >     Neither of those terms type-check, since FriendlyEqCheck can't
>> >     determine if the unconstrained `tag' variable is equal to the other
>> >     tags.
>> >
>> >     So, can we get the best of both worlds?
>> >
>> >     > best_plus ::
>> >     >   ( FriendlyEqCheck tag1 tag2 tag3
>> >          , tag1 ~ tag2, tag2 ~ tag3, Num a) => U tag1 a -> U tag2 a -> U
>> >     tag3 a
>> >
>> >     No, unfortunately not. Now the `should_work*' functions type-check,
>> >     but an ill-typed use of `best_plus' gives the same poor error
>> >     message that `plus' would give.
>> >
>> >     Hence, the question at the top of this email.
>> >
>> >     ===== two ideas =====
>> >
>> >     If my question at the top of this email cannot be answered in the
>> >     affirmative, perhaps a small patch to GHC would make this sort of
>> >     approach a viable lightweight workaround for improving
>> >     domain-specific error messages.
>> >
>> >     (I cannot estimate how difficult this would be to implement in the
>> >     type-checker.)
>> >
>> >     Two alternative ideas.
>> >
>> >     1) An "ALWAYS_ATTEMPT" PRAGMA that you can place on the class C so
>> >     that it is attempted even if a related ~ constraint fails.
>> >
>> >     2) An OrElse constraint former, offering *very* constrained
>> >     back-tracking.
>> >
>> >     > possibleAsTypeOf :: ((a ~ b) `OrElse` C a b) => a -> b -> a
>> >     > possibleAsTypeOf x _ = x
>> >
>> >     Requirements: C must have no superclasses, no methods, and no
>> fundeps.
>> >
>> >     Specification: If (a~b) fails and (C a b) is satisfiable, then the
>> >     original inequality error message would be shown to the user. Else,
>> >     C's error message is used.
>> >
>> >     ===================================
>> >
>> >     You made it to the bottom of the email! Thanks again.
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>> >
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140211/eb1ad35f/attachment.html>

From nicolas.frisby at gmail.com  Tue Feb 11 16:10:42 2014
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Tue, 11 Feb 2014 10:10:42 -0600
Subject: workaround to get both domain-specific errors and also
 multi-modal type inference?
In-Reply-To: <CA+ZFbn94=x-9dk9bgsuKih3+VTSpFnS_BpQg10=a4JxvCwwbew@mail.gmail.com>
References: <CADfHYo436qCHcPsiG+gS2WcSCn8s6ThsavdmQoiTPQv1tEnW_A@mail.gmail.com>
 <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
 <52F53C72.5050305@well-typed.com>
 <CADfHYo4exYoPObt8X7=s8QRh1+NcmxFe2+EDuPruUL0MAp5rdg@mail.gmail.com>
 <CA+ZFbn94=x-9dk9bgsuKih3+VTSpFnS_BpQg10=a4JxvCwwbew@mail.gmail.com>
Message-ID: <CADfHYo4GrrgivVv23qbj=5EeVnrsALLa7wqbp3PNjYLLoYeGDA@mail.gmail.com>

On Tue, Feb 11, 2014 at 3:55 AM, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:

> On Tue, Feb 11, 2014 at 3:32 AM, Nicolas Frisby <nicolas.frisby at gmail.com>wrote:
>>
>> > type family GHC.Exts.Message (c :: Constraint) :: Maybe Symbol
>>
> While I do find this problem very relevant, and think this solution is
> going in the right direction,
> I'm afraid it's not that simple. Say I have
>
>   type instance Message (MyClass a) = Just ...
>
> How will this behave if the unsatisfied constraint is of the form (C b,
> MyClass a)? How about
> f (MyClass a), for some f :: Constraint -> Constraint?
>
> Also, isn't it a bit unsatisfying that an instance such as
>
>   type instance Message a = Just ...
>
> would pollute error messages everywhere?...
>

Hi Pedro. Very glad you're joining in.

Thank you for the helpful observations. I see two options.

1) Keep it simple at first. EG An unsatisfied conjunction is decompose into
a list of its unsatisfied conjuncts before ab Message is ever sought.
Similarly, only support matching the head of the unsatisfied constraint, so
the Message pattern would have to match (F (MyClass a)), for whichever F is
your `f'. And so on. Lastly, we might consider allowing type class-like
overlap for instances of the Message family, since it's use-case is so
specific.

These limits each restrict the expressivity but deserve investigation
regarding how much mileage we can get out of them.

2) Or we could design a type-level DSL for querying the "trace" of the
constraint-solver that ended up with this unsatisfied constraint. This
sounds much harder to me, since I'm unfamiliar with the solver and its
internals. But it seems like the way to maximize expressitivity.

-----

I should point out that I think the courageous library designer could
squeeze some of the functionality of (2) out of (1), at the cost of
obfuscation. For example:

> class Constraint a b where -- this is the actual class of interest
>
> data Trace = forall a b. Start a b | ...
>
> instance InternalConstraint (Start a b) a b => Constraint a b
>
> class InternalConstraint trace x y -- all instances are parametric wrt `
trace'
>
> -- I'm assuming Message has range Maybe Doc, where GHC interprets Doc to
build an error message.
> type instance Message (InternalConstraint a b x y) =
>   Just (   Text "While solving Constraint for " <> ShowType a <> Text "
and " <> ShowType b
>         <> Text " the point of failure was " <> ShowType x <> Text " and
" <> ShowType y <> Text "."
>        )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140211/94de443b/attachment.html>

From nicolas.frisby at gmail.com  Tue Feb 11 16:11:13 2014
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Tue, 11 Feb 2014 10:11:13 -0600
Subject: workaround to get both domain-specific errors and also
 multi-modal type inference?
In-Reply-To: <CADfHYo4GrrgivVv23qbj=5EeVnrsALLa7wqbp3PNjYLLoYeGDA@mail.gmail.com>
References: <CADfHYo436qCHcPsiG+gS2WcSCn8s6ThsavdmQoiTPQv1tEnW_A@mail.gmail.com>
 <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
 <52F53C72.5050305@well-typed.com>
 <CADfHYo4exYoPObt8X7=s8QRh1+NcmxFe2+EDuPruUL0MAp5rdg@mail.gmail.com>
 <CA+ZFbn94=x-9dk9bgsuKih3+VTSpFnS_BpQg10=a4JxvCwwbew@mail.gmail.com>
 <CADfHYo4GrrgivVv23qbj=5EeVnrsALLa7wqbp3PNjYLLoYeGDA@mail.gmail.com>
Message-ID: <CADfHYo6kFEuK3iUNzrWqHa=KKrk9E1gDaBhSiScYHDyJFpJy6w@mail.gmail.com>

Are we reaching the point where a wiki page and perhaps (soon) a Trac
ticket would be appropriate?


On Tue, Feb 11, 2014 at 10:10 AM, Nicolas Frisby
<nicolas.frisby at gmail.com>wrote:

> On Tue, Feb 11, 2014 at 3:55 AM, Jos? Pedro Magalh?es <jpm at cs.uu.nl>wrote:
>
>> On Tue, Feb 11, 2014 at 3:32 AM, Nicolas Frisby <nicolas.frisby at gmail.com
>> > wrote:
>>
>>> > type family GHC.Exts.Message (c :: Constraint) :: Maybe Symbol
>>>
>> While I do find this problem very relevant, and think this solution is
>> going in the right direction,
>>  I'm afraid it's not that simple. Say I have
>>
>>   type instance Message (MyClass a) = Just ...
>>
>> How will this behave if the unsatisfied constraint is of the form (C b,
>> MyClass a)? How about
>> f (MyClass a), for some f :: Constraint -> Constraint?
>>
>> Also, isn't it a bit unsatisfying that an instance such as
>>
>>   type instance Message a = Just ...
>>
>> would pollute error messages everywhere?...
>>
>
> Hi Pedro. Very glad you're joining in.
>
> Thank you for the helpful observations. I see two options.
>
> 1) Keep it simple at first. EG An unsatisfied conjunction is decompose
> into a list of its unsatisfied conjuncts before ab Message is ever sought.
> Similarly, only support matching the head of the unsatisfied constraint, so
> the Message pattern would have to match (F (MyClass a)), for whichever F is
> your `f'. And so on. Lastly, we might consider allowing type class-like
> overlap for instances of the Message family, since it's use-case is so
> specific.
>
> These limits each restrict the expressivity but deserve investigation
> regarding how much mileage we can get out of them.
>
> 2) Or we could design a type-level DSL for querying the "trace" of the
> constraint-solver that ended up with this unsatisfied constraint. This
> sounds much harder to me, since I'm unfamiliar with the solver and its
> internals. But it seems like the way to maximize expressitivity.
>
> -----
>
> I should point out that I think the courageous library designer could
> squeeze some of the functionality of (2) out of (1), at the cost of
> obfuscation. For example:
>
> > class Constraint a b where -- this is the actual class of interest
> >
> > data Trace = forall a b. Start a b | ...
> >
> > instance InternalConstraint (Start a b) a b => Constraint a b
> >
> > class InternalConstraint trace x y -- all instances are parametric wrt `
> trace'
> >
> > -- I'm assuming Message has range Maybe Doc, where GHC interprets Doc to
> build an error message.
> > type instance Message (InternalConstraint a b x y) =
> >   Just (   Text "While solving Constraint for " <> ShowType a <> Text "
> and " <> ShowType b
> >         <> Text " the point of failure was " <> ShowType x <> Text " and
> " <> ShowType y <> Text "."
> >        )
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140211/0d73f780/attachment.html>

From eir at cis.upenn.edu  Tue Feb 11 18:13:41 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 11 Feb 2014 13:13:41 -0500
Subject: workaround to get both domain-specific errors and also
 multi-modal type inference?
In-Reply-To: <CADfHYo4GrrgivVv23qbj=5EeVnrsALLa7wqbp3PNjYLLoYeGDA@mail.gmail.com>
References: <CADfHYo436qCHcPsiG+gS2WcSCn8s6ThsavdmQoiTPQv1tEnW_A@mail.gmail.com>
 <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
 <52F53C72.5050305@well-typed.com>
 <CADfHYo4exYoPObt8X7=s8QRh1+NcmxFe2+EDuPruUL0MAp5rdg@mail.gmail.com>
 <CA+ZFbn94=x-9dk9bgsuKih3+VTSpFnS_BpQg10=a4JxvCwwbew@mail.gmail.com>
 <CADfHYo4GrrgivVv23qbj=5EeVnrsALLa7wqbp3PNjYLLoYeGDA@mail.gmail.com>
Message-ID: <8DF85D60-5D55-47E4-B21A-011D35C238B5@cis.upenn.edu>

One potential source of confusion in this thread:

When Adam initially suggested a function (Constraint -> Maybe String), I believe he was referring to constraints as they slosh around within GHC, *not* the kind-level Constraint available with ConstraintKinds. So, the error-reporting function would be written in a separate module from the code it affects, and it would be imported somewhat like Template Haskell does. Then, GHC could call the function when type inference fails. This would make programming the interface much easier and more expressive.

Please correct me if I'm wrong, but it seemed that different people were talking about different solutions!

Richard

On Feb 11, 2014, at 11:10 AM, Nicolas Frisby <nicolas.frisby at gmail.com> wrote:

> On Tue, Feb 11, 2014 at 3:55 AM, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:
> On Tue, Feb 11, 2014 at 3:32 AM, Nicolas Frisby <nicolas.frisby at gmail.com> wrote:
> > type family GHC.Exts.Message (c :: Constraint) :: Maybe Symbol
> 
> While I do find this problem very relevant, and think this solution is going in the right direction,
> I'm afraid it's not that simple. Say I have
> 
>   type instance Message (MyClass a) = Just ...
> 
> How will this behave if the unsatisfied constraint is of the form (C b, MyClass a)? How about
> f (MyClass a), for some f :: Constraint -> Constraint?
> 
> Also, isn't it a bit unsatisfying that an instance such as
> 
>   type instance Message a = Just ...
> 
> would pollute error messages everywhere?...
> 
> Hi Pedro. Very glad you're joining in.
> 
> Thank you for the helpful observations. I see two options.
> 
> 1) Keep it simple at first. EG An unsatisfied conjunction is decompose into a list of its unsatisfied conjuncts before ab Message is ever sought. Similarly, only support matching the head of the unsatisfied constraint, so the Message pattern would have to match (F (MyClass a)), for whichever F is your `f'. And so on. Lastly, we might consider allowing type class-like overlap for instances of the Message family, since it's use-case is so specific.
> 
> These limits each restrict the expressivity but deserve investigation regarding how much mileage we can get out of them.
> 
> 2) Or we could design a type-level DSL for querying the "trace" of the constraint-solver that ended up with this unsatisfied constraint. This sounds much harder to me, since I'm unfamiliar with the solver and its internals. But it seems like the way to maximize expressitivity.
> 
> -----
> 
> I should point out that I think the courageous library designer could squeeze some of the functionality of (2) out of (1), at the cost of obfuscation. For example:
> 
> > class Constraint a b where -- this is the actual class of interest
> > 
> > data Trace = forall a b. Start a b | ...
> > 
> > instance InternalConstraint (Start a b) a b => Constraint a b
> > 
> > class InternalConstraint trace x y -- all instances are parametric wrt `trace'
> > 
> > -- I'm assuming Message has range Maybe Doc, where GHC interprets Doc to build an error message.
> > type instance Message (InternalConstraint a b x y) =
> >   Just (   Text "While solving Constraint for " <> ShowType a <> Text " and " <> ShowType b
> >         <> Text " the point of failure was " <> ShowType x <> Text " and " <> ShowType y <> Text "."
> >        )
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140211/193c764a/attachment-0001.html>

From nicolas.frisby at gmail.com  Tue Feb 11 18:24:21 2014
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Tue, 11 Feb 2014 12:24:21 -0600
Subject: workaround to get both domain-specific errors and also
 multi-modal type inference?
In-Reply-To: <8DF85D60-5D55-47E4-B21A-011D35C238B5@cis.upenn.edu>
References: <CADfHYo436qCHcPsiG+gS2WcSCn8s6ThsavdmQoiTPQv1tEnW_A@mail.gmail.com>
 <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
 <52F53C72.5050305@well-typed.com>
 <CADfHYo4exYoPObt8X7=s8QRh1+NcmxFe2+EDuPruUL0MAp5rdg@mail.gmail.com>
 <CA+ZFbn94=x-9dk9bgsuKih3+VTSpFnS_BpQg10=a4JxvCwwbew@mail.gmail.com>
 <CADfHYo4GrrgivVv23qbj=5EeVnrsALLa7wqbp3PNjYLLoYeGDA@mail.gmail.com>
 <8DF85D60-5D55-47E4-B21A-011D35C238B5@cis.upenn.edu>
Message-ID: <CADfHYo7QY4eMr5Tyxd4_febdt68xgNRu5N6TvOGKM2xa3Wv0wQ@mail.gmail.com>

Thanks for suggesting that; I was only seeing Constraint as in
ConstraintKinds.

I think the gist of my previous concerns doesn't change, though: open type
pattern matching (or some dissatisfying approx of), assuredly pure
functions, etc.
On Feb 11, 2014 12:15 PM, "Richard Eisenberg" <eir at cis.upenn.edu> wrote:

> One potential source of confusion in this thread:
>
> When Adam initially suggested a function (Constraint -> Maybe String), I
> believe he was referring to constraints as they slosh around within GHC,
> *not* the kind-level Constraint available with ConstraintKinds. So, the
> error-reporting function would be written in a separate module from the
> code it affects, and it would be imported somewhat like Template Haskell
> does. Then, GHC could call the function when type inference fails. This
> would make programming the interface much easier and more expressive.
>
> Please correct me if I'm wrong, but it seemed that different people were
> talking about different solutions!
>
> Richard
>
> On Feb 11, 2014, at 11:10 AM, Nicolas Frisby <nicolas.frisby at gmail.com>
> wrote:
>
> On Tue, Feb 11, 2014 at 3:55 AM, Jos? Pedro Magalh?es <jpm at cs.uu.nl>wrote:
>
>> On Tue, Feb 11, 2014 at 3:32 AM, Nicolas Frisby <nicolas.frisby at gmail.com
>> > wrote:
>>>
>>> > type family GHC.Exts.Message (c :: Constraint) :: Maybe Symbol
>>>
>> While I do find this problem very relevant, and think this solution is
>> going in the right direction,
>> I'm afraid it's not that simple. Say I have
>>
>>   type instance Message (MyClass a) = Just ...
>>
>> How will this behave if the unsatisfied constraint is of the form (C b,
>> MyClass a)? How about
>> f (MyClass a), for some f :: Constraint -> Constraint?
>>
>> Also, isn't it a bit unsatisfying that an instance such as
>>
>>   type instance Message a = Just ...
>>
>> would pollute error messages everywhere?...
>>
>
> Hi Pedro. Very glad you're joining in.
>
> Thank you for the helpful observations. I see two options.
>
> 1) Keep it simple at first. EG An unsatisfied conjunction is decompose
> into a list of its unsatisfied conjuncts before ab Message is ever sought.
> Similarly, only support matching the head of the unsatisfied constraint, so
> the Message pattern would have to match (F (MyClass a)), for whichever F is
> your `f'. And so on. Lastly, we might consider allowing type class-like
> overlap for instances of the Message family, since it's use-case is so
> specific.
>
> These limits each restrict the expressivity but deserve investigation
> regarding how much mileage we can get out of them.
>
> 2) Or we could design a type-level DSL for querying the "trace" of the
> constraint-solver that ended up with this unsatisfied constraint. This
> sounds much harder to me, since I'm unfamiliar with the solver and its
> internals. But it seems like the way to maximize expressitivity.
>
> -----
>
> I should point out that I think the courageous library designer could
> squeeze some of the functionality of (2) out of (1), at the cost of
> obfuscation. For example:
>
> > class Constraint a b where -- this is the actual class of interest
> >
> > data Trace = forall a b. Start a b | ...
> >
> > instance InternalConstraint (Start a b) a b => Constraint a b
> >
> > class InternalConstraint trace x y -- all instances are parametric wrt `
> trace'
> >
> > -- I'm assuming Message has range Maybe Doc, where GHC interprets Doc to
> build an error message.
> > type instance Message (InternalConstraint a b x y) =
> >   Just (   Text "While solving Constraint for " <> ShowType a <> Text "
> and " <> ShowType b
> >         <> Text " the point of failure was " <> ShowType x <> Text " and
> " <> ShowType y <> Text "."
> >        )
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140211/c37368d2/attachment.html>

From adam at well-typed.com  Tue Feb 11 18:43:54 2014
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 11 Feb 2014 18:43:54 +0000
Subject: workaround to get both domain-specific errors and also multi-modal
 type inference?
In-Reply-To: <CADfHYo7QY4eMr5Tyxd4_febdt68xgNRu5N6TvOGKM2xa3Wv0wQ@mail.gmail.com>
References: <CADfHYo436qCHcPsiG+gS2WcSCn8s6ThsavdmQoiTPQv1tEnW_A@mail.gmail.com>
 <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
 <52F53C72.5050305@well-typed.com>
 <CADfHYo4exYoPObt8X7=s8QRh1+NcmxFe2+EDuPruUL0MAp5rdg@mail.gmail.com>
 <CA+ZFbn94=x-9dk9bgsuKih3+VTSpFnS_BpQg10=a4JxvCwwbew@mail.gmail.com>
 <CADfHYo4GrrgivVv23qbj=5EeVnrsALLa7wqbp3PNjYLLoYeGDA@mail.gmail.com>
 <8DF85D60-5D55-47E4-B21A-011D35C238B5@cis.upenn.edu>
 <CADfHYo7QY4eMr5Tyxd4_febdt68xgNRu5N6TvOGKM2xa3Wv0wQ@mail.gmail.com>
Message-ID: <52FA6F6A.8070901@well-typed.com>

Thanks for clarifying, Richard, I should have been clearer. "Constraint"
was a poor choice of type without further explanation.

Nicolas, Pedro, thanks for your feedback!

On 11/02/14 18:24, Nicolas Frisby wrote:
> Thanks for suggesting that; I was only seeing Constraint as in
> ConstraintKinds.
> 
> I think the gist of my previous concerns doesn't change, though: open
> type pattern matching (or some dissatisfying approx of), assuredly pure
> functions, etc.

The point of doing it this way - effectively hooking code into GHC - is
that the error-reporting code would work with the GHC internal
representation of constraints, thereby avoiding trouble with open types.
The GHC API can be used to decompose the constraint type. This would
make it much easier to do complex processing than trying to write tricky
functional programs with type families. We might also want the
error-reporting function to live in GHC's TcM monad so it has access to
whatever state it wanted.

Cheers,

Adam

[Resent to ghc-devs from the correct email address.]


> On Feb 11, 2014 12:15 PM, "Richard Eisenberg" <eir at cis.upenn.edu
> <mailto:eir at cis.upenn.edu>> wrote:
> 
>     One potential source of confusion in this thread:
> 
>     When Adam initially suggested a function (Constraint -> Maybe
>     String), I believe he was referring to constraints as they slosh
>     around within GHC, *not* the kind-level Constraint available with
>     ConstraintKinds. So, the error-reporting function would be written
>     in a separate module from the code it affects, and it would be
>     imported somewhat like Template Haskell does. Then, GHC could call
>     the function when type inference fails. This would make programming
>     the interface much easier and more expressive.
> 
>     Please correct me if I'm wrong, but it seemed that different people
>     were talking about different solutions!
> 
>     Richard
> 
>     On Feb 11, 2014, at 11:10 AM, Nicolas Frisby
>     <nicolas.frisby at gmail.com <mailto:nicolas.frisby at gmail.com>> wrote:
> 
>>     On Tue, Feb 11, 2014 at 3:55 AM, Jos? Pedro Magalh?es
>>     <jpm at cs.uu.nl <mailto:jpm at cs.uu.nl>> wrote:
>>
>>         On Tue, Feb 11, 2014 at 3:32 AM, Nicolas Frisby
>>         <nicolas.frisby at gmail.com <mailto:nicolas.frisby at gmail.com>>
>>         wrote:
>>
>>             > type family GHC.Exts.Message (c :: Constraint) :: Maybe
>>             Symbol
>>
>>         While I do find this problem very relevant, and think this
>>         solution is going in the right direction,
>>         I'm afraid it's not that simple. Say I have
>>
>>           type instance Message (MyClass a) = Just ...
>>
>>         How will this behave if the unsatisfied constraint is of the
>>         form (C b, MyClass a)? How about
>>         f (MyClass a), for some f :: Constraint -> Constraint?
>>
>>         Also, isn't it a bit unsatisfying that an instance such as
>>
>>           type instance Message a = Just ...
>>
>>         would pollute error messages everywhere?...
>>
>>
>>     Hi Pedro. Very glad you're joining in.
>>
>>     Thank you for the helpful observations. I see two options.
>>
>>     1) Keep it simple at first. EG An unsatisfied conjunction is
>>     decompose into a list of its unsatisfied conjuncts before ab
>>     Message is ever sought. Similarly, only support matching the head
>>     of the unsatisfied constraint, so the Message pattern would have
>>     to match (F (MyClass a)), for whichever F is your `f'. And so on.
>>     Lastly, we might consider allowing type class-like overlap for
>>     instances of the Message family, since it's use-case is so specific.
>>
>>     These limits each restrict the expressivity but deserve
>>     investigation regarding how much mileage we can get out of them.
>>
>>     2) Or we could design a type-level DSL for querying the "trace" of
>>     the constraint-solver that ended up with this unsatisfied
>>     constraint. This sounds much harder to me, since I'm unfamiliar
>>     with the solver and its internals. But it seems like the way to
>>     maximize expressitivity.
>>
>>     -----
>>
>>     I should point out that I think the courageous library designer
>>     could squeeze some of the functionality of (2) out of (1), at the
>>     cost of obfuscation. For example:
>>
>>     > class Constraint a b where -- this is the actual class of interest
>>     > 
>>     > data Trace = forall a b. Start a b | ...
>>     > 
>>     > instance InternalConstraint (Start a b) a b => Constraint a b
>>     > 
>>     > class InternalConstraint trace x y -- all instances are
>>     parametric wrt `trace'
>>     > 
>>     > -- I'm assuming Message has range Maybe Doc, where GHC
>>     interprets Doc to build an error message.
>>     > type instance Message (InternalConstraint a b x y) =
>>     >   Just (   Text "While solving Constraint for " <> ShowType a
>>     <> Text " and " <> ShowType b
>>     >         <> Text " the point of failure was " <> ShowType x <>
>>     Text " and " <> ShowType y <> Text "."
>>     >        )
>>     _______________________________________________
>>     ghc-devs mailing list
>>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>     http://www.haskell.org/mailman/listinfo/ghc-devs
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From nicolas.frisby at gmail.com  Tue Feb 11 18:55:51 2014
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Tue, 11 Feb 2014 12:55:51 -0600
Subject: workaround to get both domain-specific errors and also
 multi-modal type inference?
In-Reply-To: <52FA6F6A.8070901@well-typed.com>
References: <CADfHYo436qCHcPsiG+gS2WcSCn8s6ThsavdmQoiTPQv1tEnW_A@mail.gmail.com>
 <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
 <52F53C72.5050305@well-typed.com>
 <CADfHYo4exYoPObt8X7=s8QRh1+NcmxFe2+EDuPruUL0MAp5rdg@mail.gmail.com>
 <CA+ZFbn94=x-9dk9bgsuKih3+VTSpFnS_BpQg10=a4JxvCwwbew@mail.gmail.com>
 <CADfHYo4GrrgivVv23qbj=5EeVnrsALLa7wqbp3PNjYLLoYeGDA@mail.gmail.com>
 <8DF85D60-5D55-47E4-B21A-011D35C238B5@cis.upenn.edu>
 <CADfHYo7QY4eMr5Tyxd4_febdt68xgNRu5N6TvOGKM2xa3Wv0wQ@mail.gmail.com>
 <52FA6F6A.8070901@well-typed.com>
Message-ID: <CADfHYo5U+9FE1NS4wRSqCUZSj01duuNTibwSZU=vb19MOcRm8w@mail.gmail.com>

If, when defining the `describeError' method, I wanted to refer to one of
my library's classes from inside a pattern (or guard in the rhs, I
suppose), how would I do that? Via a Template Haskell literal name? Or
would I call the TcM interface for looking up a name?

In my opinion [1], the TcM interface is too user-antagonistic, even for GHC
power-users [2], and moreover would leak implementation details. I would
prefer a more light-weight interface, dedicated to just domain-specific
errors.

That said, it seems that a general interface comparable to the one I have
been hocking could be built atop what you two are proposing and
subsequently marked {-# LANGUAGE Trustworthy #-}. Thumbs up.

[1] - Disclaimer: I've already noted that I'm not familiar with the
type-checker implementation.
[2] - I consider myself a GHC power-user.


On Tue, Feb 11, 2014 at 12:43 PM, Adam Gundry <adam at well-typed.com> wrote:

> Thanks for clarifying, Richard, I should have been clearer. "Constraint"
> was a poor choice of type without further explanation.
>
> Nicolas, Pedro, thanks for your feedback!
>
> On 11/02/14 18:24, Nicolas Frisby wrote:
> > Thanks for suggesting that; I was only seeing Constraint as in
> > ConstraintKinds.
> >
> > I think the gist of my previous concerns doesn't change, though: open
> > type pattern matching (or some dissatisfying approx of), assuredly pure
> > functions, etc.
>
> The point of doing it this way - effectively hooking code into GHC - is
> that the error-reporting code would work with the GHC internal
> representation of constraints, thereby avoiding trouble with open types.
> The GHC API can be used to decompose the constraint type. This would
> make it much easier to do complex processing than trying to write tricky
> functional programs with type families. We might also want the
> error-reporting function to live in GHC's TcM monad so it has access to
> whatever state it wanted.
>
> Cheers,
>
> Adam
>
> [Resent to ghc-devs from the correct email address.]
>
>
> > On Feb 11, 2014 12:15 PM, "Richard Eisenberg" <eir at cis.upenn.edu
> > <mailto:eir at cis.upenn.edu>> wrote:
> >
> >     One potential source of confusion in this thread:
> >
> >     When Adam initially suggested a function (Constraint -> Maybe
> >     String), I believe he was referring to constraints as they slosh
> >     around within GHC, *not* the kind-level Constraint available with
> >     ConstraintKinds. So, the error-reporting function would be written
> >     in a separate module from the code it affects, and it would be
> >     imported somewhat like Template Haskell does. Then, GHC could call
> >     the function when type inference fails. This would make programming
> >     the interface much easier and more expressive.
> >
> >     Please correct me if I'm wrong, but it seemed that different people
> >     were talking about different solutions!
> >
> >     Richard
> >
> >     On Feb 11, 2014, at 11:10 AM, Nicolas Frisby
> >     <nicolas.frisby at gmail.com <mailto:nicolas.frisby at gmail.com>> wrote:
> >
> >>     On Tue, Feb 11, 2014 at 3:55 AM, Jos? Pedro Magalh?es
> >>     <jpm at cs.uu.nl <mailto:jpm at cs.uu.nl>> wrote:
> >>
> >>         On Tue, Feb 11, 2014 at 3:32 AM, Nicolas Frisby
> >>         <nicolas.frisby at gmail.com <mailto:nicolas.frisby at gmail.com>>
> >>         wrote:
> >>
> >>             > type family GHC.Exts.Message (c :: Constraint) :: Maybe
> >>             Symbol
> >>
> >>         While I do find this problem very relevant, and think this
> >>         solution is going in the right direction,
> >>         I'm afraid it's not that simple. Say I have
> >>
> >>           type instance Message (MyClass a) = Just ...
> >>
> >>         How will this behave if the unsatisfied constraint is of the
> >>         form (C b, MyClass a)? How about
> >>         f (MyClass a), for some f :: Constraint -> Constraint?
> >>
> >>         Also, isn't it a bit unsatisfying that an instance such as
> >>
> >>           type instance Message a = Just ...
> >>
> >>         would pollute error messages everywhere?...
> >>
> >>
> >>     Hi Pedro. Very glad you're joining in.
> >>
> >>     Thank you for the helpful observations. I see two options.
> >>
> >>     1) Keep it simple at first. EG An unsatisfied conjunction is
> >>     decompose into a list of its unsatisfied conjuncts before ab
> >>     Message is ever sought. Similarly, only support matching the head
> >>     of the unsatisfied constraint, so the Message pattern would have
> >>     to match (F (MyClass a)), for whichever F is your `f'. And so on.
> >>     Lastly, we might consider allowing type class-like overlap for
> >>     instances of the Message family, since it's use-case is so specific.
> >>
> >>     These limits each restrict the expressivity but deserve
> >>     investigation regarding how much mileage we can get out of them.
> >>
> >>     2) Or we could design a type-level DSL for querying the "trace" of
> >>     the constraint-solver that ended up with this unsatisfied
> >>     constraint. This sounds much harder to me, since I'm unfamiliar
> >>     with the solver and its internals. But it seems like the way to
> >>     maximize expressitivity.
> >>
> >>     -----
> >>
> >>     I should point out that I think the courageous library designer
> >>     could squeeze some of the functionality of (2) out of (1), at the
> >>     cost of obfuscation. For example:
> >>
> >>     > class Constraint a b where -- this is the actual class of interest
> >>     >
> >>     > data Trace = forall a b. Start a b | ...
> >>     >
> >>     > instance InternalConstraint (Start a b) a b => Constraint a b
> >>     >
> >>     > class InternalConstraint trace x y -- all instances are
> >>     parametric wrt `trace'
> >>     >
> >>     > -- I'm assuming Message has range Maybe Doc, where GHC
> >>     interprets Doc to build an error message.
> >>     > type instance Message (InternalConstraint a b x y) =
> >>     >   Just (   Text "While solving Constraint for " <> ShowType a
> >>     <> Text " and " <> ShowType b
> >>     >         <> Text " the point of failure was " <> ShowType x <>
> >>     Text " and " <> ShowType y <> Text "."
> >>     >        )
> >>     _______________________________________________
> >>     ghc-devs mailing list
> >>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> >>     http://www.haskell.org/mailman/listinfo/ghc-devs
> >
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140211/1754d1cd/attachment-0001.html>

From marlowsd at gmail.com  Thu Feb 13 10:07:05 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 13 Feb 2014 10:07:05 +0000
Subject: [commit: ghc] master: Simplify Control Flow Optimisations Cmm
 pass (99c3ed8)
In-Reply-To: <20140201190431.E4B002406B@ghc.haskell.org>
References: <20140201190431.E4B002406B@ghc.haskell.org>
Message-ID: <52FC9949.5040006@gmail.com>

Hi Jan - I'm not sure I agree that the case you removed was superfluous. 
  There are two cases we want to replace a branch to a block with the 
contents of the block itself:

   (1) when the block is referenced only once
   (2) when the block is small enough

The case you removed was (2).  Now, as it happens right now (2) was not 
doing anything interesting because our definition of "small enough" is 
"a single branch", but it could in theory be more liberal.  There used 
to be a function called "okToDuplicate" (removed in one of your earlier 
patches) that made this decision, and our intention was to experiment 
with extending this to allow duplication of code in some cases. 
Shortcutting a branch might be ok if the block only contains a single 
instruction, for example, because then the total number of instructions 
executed is the same (and there are one fewer branches).

Cheers,
Simon

On 01/02/2014 19:04, git at git.haskell.org wrote:
> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : master
> Link       : http://ghc.haskell.org/trac/ghc/changeset/99c3ed81ac53629771b00a0abbe37c989ea45cd6/ghc
>
>> ---------------------------------------------------------------
>
> commit 99c3ed81ac53629771b00a0abbe37c989ea45cd6
> Author: Jan Stolarek <jan.stolarek at p.lodz.pl>
> Date:   Sat Feb 1 18:00:48 2014 +0100
>
>      Simplify Control Flow Optimisations Cmm pass
>
>      It turns out that one of the cases in the optimization pass was
>      a special case of another. I remove that specialization since it
>      does not have impact on compilation time, and the resulting Cmm
>      is identical.
>
>
>> ---------------------------------------------------------------
>
> 99c3ed81ac53629771b00a0abbe37c989ea45cd6
>   compiler/cmm/CmmContFlowOpt.hs |   37 +++++++++----------------------------
>   1 file changed, 9 insertions(+), 28 deletions(-)
>
> diff --git a/compiler/cmm/CmmContFlowOpt.hs b/compiler/cmm/CmmContFlowOpt.hs
> index 52b95a9..4b8ce6f 100644
> --- a/compiler/cmm/CmmContFlowOpt.hs
> +++ b/compiler/cmm/CmmContFlowOpt.hs
> @@ -46,25 +46,20 @@ import Prelude hiding (succ, unzip, zip)
>   -- Note [Control-flow optimisations]
>   -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   --
> --- This optimisation does four things:
> +-- This optimisation does three things:
>   --
>   --   - If a block finishes in an unconditonal branch to another block
>   --     and that is the only jump to that block we concatenate the
>   --     destination block at the end of the current one.
>   --
> ---   - If a block finishes in an unconditional branch, we may be able
> ---     to shortcut the destination block.
> ---
>   --   - If a block finishes in a call whose continuation block is a
>   --     goto, then we can shortcut the destination, making the
>   --     continuation block the destination of the goto - but see Note
>   --     [Shortcut call returns].
>   --
> ---   - For block finishing in conditional branch we try to invert the
> ---     condition and shortcut destination of alternatives.
> ---
>   --   - For any block that is not a call we try to shortcut the
> ---     destination(s).
> +--     destination(s). Additionally, if a block ends with a
> +--     conditional branch we try to invert the condition.
>   --
>   -- Blocks are processed using postorder DFS traversal. A side effect
>   -- of determining traversal order with a graph search is elimination
> @@ -204,11 +199,8 @@ blockConcat splitting_procs g at CmmGraph { g_entry = entry_id }
>           --   (2) remove b' from the map of blocks
>           --   (3) remove information about b' from predecessors map
>           --
> -        -- This guard must be first so that we always eliminate blocks that have
> -        -- only one predecessor. If we had a target block that is both
> -        -- shorcutable and has only one predecessor and attempted to shortcut it
> -        -- first we would make that block unreachable but would not remove it
> -        -- from the graph.
> +        -- Since we know that the block has only one predecessor we call
> +        -- mapDelete directly instead of calling decPreds.
>           --
>           -- Note that we always maintain an up-to-date list of predecessors, so
>           -- we can ignore the contents of shortcut_map
> @@ -221,20 +213,6 @@ blockConcat splitting_procs g at CmmGraph { g_entry = entry_id }
>                , mapDelete b' backEdges )
>
>           -- If:
> -        --   (1) current block ends with unconditional branch to b' and
> -        --   (2) we can shortcut block b'
> -        -- Then:
> -        --   (1) concatenate b' at the end of current block, effectively
> -        --       changing target of uncondtional jump from b' to dest
> -        --   (2) increase number of predecessors of dest by 1
> -        --   (3) decrease number of predecessors of b' by 1
> -        | CmmBranch b' <- last
> -        , Just blk' <- mapLookup b' blocks
> -        , Just dest <- canShortcut blk'
> -        = ( mapInsert bid (splice head blk') blocks, shortcut_map,
> -            decPreds b' $ incPreds dest backEdges )
> -
> -        -- If:
>           --   (1) we are splitting proc points (see Note
>           --       [Shortcut call returns and proc-points]) and
>           --   (2) current block is a CmmCall or CmmForeignCall with
> @@ -263,7 +241,10 @@ blockConcat splitting_procs g at CmmGraph { g_entry = entry_id }
>           --       conditional
>           --   (2) attempt to shortcut all destination blocks
>           --   (3) if new successors of a block are different from the old ones
> -        --       we update the of predecessors accordingly
> +        --       update the of predecessors accordingly
> +        --
> +        -- A special case of this is a situation when a block ends with an
> +        -- unconditional jump to a block that can be shortcut.
>           | Nothing <- callContinuation_maybe last
>           = let oldSuccs = successors last
>                 newSuccs = successors swapcond_last
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>

From mail at joachim-breitner.de  Thu Feb 13 10:21:50 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 13 Feb 2014 10:21:50 +0000
Subject: Overlapping names in GHC: ConLike
Message-ID: <1392286910.2900.13.camel@kirk>

Hi,

while reading some code I noticed that we use the term ?ConLike? for two
different things: From Haskell up to the desugarer, this is a data type
to treat data constructors and pattern synonyms together; afterwards, in
the world of Core, ConLike is an attribute of expression (exprIsConLik)
similar to exprIsHNF.

The former use is newer, introduced by the pattern synonym patch. In the
long run, there is a risk of confusion, maybe we should rename ConLike
module and data type. Any suggestions for a good name?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140213/e40c81f2/attachment.sig>

From austin at well-typed.com  Thu Feb 13 15:53:22 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 13 Feb 2014 09:53:22 -0600
Subject: RC2 status
Message-ID: <CAEs96n38RerYPA_HTKRZVjzS56c=-0iUH+_evYEacudAxGZhXg@mail.gmail.com>

Hello all!

I'm sure some of you are wondering about RC2. Please take a look at
this page, which gives the basic overview:

https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC1

This currently lists all the active tickets filed against RC1. It
lists several categories, but the only one really relevant is 'new'
for those reading.

Most of the bugs in 'new' will be fixed shortly. I will then merge
them (and a lot of others) to 7.8 shortly. This includes #8735, #8736,
#8760, and #8770 (and also #8719 and #8748 in 'patch' status.) After
talking with Simon, I will also cook up a fix for #8754. So it's
closer than it looks!

There are two outliers:

  * #8745 & #8773 - After Richard and Joachim hashed out the details
(fairly quickly,) it seems this will go into 7.8 as well. Richard - I
suspect you will likely commit #8773 soon? Afterwords, I can still
take care of #8745 to enable GND for SafeHaskell, and these can both
be merged. Quite easy.

  * #8696 - this one is the main blocker for RC2. And after I'm done
brushing the other stuff up, it will be my main focus as I haven't had
time to think about it closely. Reid Barton has already been
fantastically helpful with his test case and thoughtful analysis, and
perhaps someone else would look. I'd really appreciate extra eyes to
help diagnose a possible fix or even a patch - the human parallelism
could certainly help.

So that's it: most of these are very basic, and I expect to be done
with many quite soon. The last bit here is the sticky one, so I
encourage people to look if they have a chance, please!

Finally, a quick note:
https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC1 has content
which is generated dynamically. You can automatically make another
ticket appear there by:

 * Setting the version to '7.8.1-rc1'.
 * Setting the milestone to '7.8.1'.

This will make sure it's clearly on my radar. The bugs have slowed
down however, which is a good thing: so I imagine this is quite
representative of the final ones.

Let me know if there are any questions or more importantly if I've
missed anything.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From carter.schonwald at gmail.com  Thu Feb 13 16:48:25 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 13 Feb 2014 11:48:25 -0500
Subject: Overlapping names in GHC: ConLike
In-Reply-To: <1392286910.2900.13.camel@kirk>
References: <1392286910.2900.13.camel@kirk>
Message-ID: <CAHYVw0xN6TdEVoWjd776c4dFPOc9HvAw_JApog_0NPTiK=PX1w@mail.gmail.com>

Caseable? PatternLike?

On Thursday, February 13, 2014, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> while reading some code I noticed that we use the term ?ConLike? for two
> different things: From Haskell up to the desugarer, this is a data type
> to treat data constructors and pattern synonyms together; afterwards, in
> the world of Core, ConLike is an attribute of expression (exprIsConLik)
> similar to exprIsHNF.
>
> The former use is newer, introduced by the pattern synonym patch. In the
> long run, there is a risk of confusion, maybe we should rename ConLike
> module and data type. Any suggestions for a good name?
>
> Greetings,
> Joachim
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de <javascript:;> ?
> http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de <javascript:;>  ? GPG-Key:
> 0x4743206C
>   Debian Developer: nomeata at debian.org <javascript:;>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140213/e28332b8/attachment.html>

From kazu at iij.ad.jp  Fri Feb 14 00:24:49 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Fri, 14 Feb 2014 09:24:49 +0900 (JST)
Subject: RC2 status
In-Reply-To: <CAEs96n38RerYPA_HTKRZVjzS56c=-0iUH+_evYEacudAxGZhXg@mail.gmail.com>
References: <CAEs96n38RerYPA_HTKRZVjzS56c=-0iUH+_evYEacudAxGZhXg@mail.gmail.com>
Message-ID: <20140214.092449.522115974241049137.kazu@iij.ad.jp>

Hi,

> Let me know if there are any questions or more importantly if I've
> missed anything.

Please don't forget #8266. One patch should be applied to Cabal lib.

--Kazu

From johan.tibell at gmail.com  Fri Feb 14 14:52:02 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 14 Feb 2014 15:52:02 +0100
Subject: RC2 status
In-Reply-To: <20140214.092449.522115974241049137.kazu@iij.ad.jp>
References: <CAEs96n38RerYPA_HTKRZVjzS56c=-0iUH+_evYEacudAxGZhXg@mail.gmail.com>
 <20140214.092449.522115974241049137.kazu@iij.ad.jp>
Message-ID: <CAK-tuPY608v6o9MSGZBAsxzOixNsdfXkTa_0cJnvvG5vnOGkrw@mail.gmail.com>

On Fri, Feb 14, 2014 at 1:24 AM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> Hi,
>
> > Let me know if there are any questions or more importantly if I've
> > missed anything.
>
> Please don't forget #8266. One patch should be applied to Cabal lib.
>

The patch is already in the Cabal 1.18 branch. We just need to make a Cabal
release before the GHC release. I'm waiting for the GHC devs to tell me
when they want me to make the release (i.e. when they expect no more Cabal
changes to be needed).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140214/8e0061cf/attachment.html>

From tyler.huffman at tylerh.org  Fri Feb 14 20:53:37 2014
From: tyler.huffman at tylerh.org (Tyler Huffman)
Date: Fri, 14 Feb 2014 13:53:37 -0700
Subject: 7.8.1-candidate fail
In-Reply-To: <201402062150.55164.jan.stolarek@p.lodz.pl>
References: <1391717159.13808.11.camel@one.mechvel.pereslavl.ru>
 <201402062150.55164.jan.stolarek@p.lodz.pl>
Message-ID: <CAMYb46AzG=LfLnMZ_VfKA9VwC7D3OewOp9JF8TxOakCBhNhTYg@mail.gmail.com>

I added a comment in the ticket, but it looks like Debian Squeeze is using
libgmp3-dev 2:4.3.2, which was the same version that I had when I was
running into this issue.

Using an updated version of libgmp3-dev will fix the issue, but I'm not
entirely sure if we need to consider supporting the packages in Debian
Squeeze repository since Debian Wheezy is the new stable distribution, and
it uses libgmp-dev 2:5.0.5. Someone with more intimate knowledge of GHC
development might be able to speak on this issue.


Regards,
Tyler Huffman


On Thu, Feb 6, 2014 at 1:50 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:

> I had the same problem on Debian Squeeze:
>
> https://ghc.haskell.org/trac/ghc/ticket/8666
>
> What is your distro?
>
> CCing ghc-devs.
>
> Janek
>
> Dnia czwartek, 6 lutego 2014, Sergei Meshveliani napisa?:
> > Dear GHC team,
> >
> > I am trying to test    ghc-7.8.20140130-src.tar.bz2
> >
> > I make it from source with   ghc-7.6.3  on Debian Linux (64 bit).
> >
> > ./configure  looks all right.
> >
> > And `make' reports after 40 minutes:
> >
> > -------------------------------------------------------
> > ...
> > ...
> > "inplace/bin/ghc-stage1" -optc-Ilibraries/integer-gmp/.
> > -optc-I'/home/mechvel/g.....
> > ...
> > ...
> > /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation
> > R_X86_64_32 against `__gmpz_sub' can not be used when making a shared
> > object; recompile with -fPIC
> > libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value
> > collect2: ld returned 1 exit status
> > make[1]: ***
> > [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0\
> > -ghc7.8.20140130.so] Error 1
> > -------------------------------------------------------
> >
> >
> > What might this mean? Need I to install a fresher  libgmp ?
> >
> > Thanks,
> >
> > ------
> > Sergei
> >
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140214/ddcbefb8/attachment.html>

From gergo at erdi.hu  Sat Feb 15 02:31:29 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sat, 15 Feb 2014 10:31:29 +0800 (SGT)
Subject: Overlapping names in GHC: ConLike
In-Reply-To: <CAHYVw0xN6TdEVoWjd776c4dFPOc9HvAw_JApog_0NPTiK=PX1w@mail.gmail.com>
References: <1392286910.2900.13.camel@kirk>
 <CAHYVw0xN6TdEVoWjd776c4dFPOc9HvAw_JApog_0NPTiK=PX1w@mail.gmail.com>
Message-ID: <alpine.DEB.2.10.1402151030500.3396@galaxy>

On Thu, 13 Feb 2014, Carter Schonwald wrote:

> Caseable? PatternLike??

The reason I went with ConLike originally (apart from not noticing the 
clash) was that (bidirectional) pattern synonyms can also be used in 
expressions, so they behave like constructors in both contexts.

From carter.schonwald at gmail.com  Sat Feb 15 04:08:13 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 14 Feb 2014 23:08:13 -0500
Subject: Overlapping names in GHC: ConLike
In-Reply-To: <alpine.DEB.2.10.1402151030500.3396@galaxy>
References: <1392286910.2900.13.camel@kirk>
 <CAHYVw0xN6TdEVoWjd776c4dFPOc9HvAw_JApog_0NPTiK=PX1w@mail.gmail.com>
 <alpine.DEB.2.10.1402151030500.3396@galaxy>
Message-ID: <CAHYVw0xvLCa3+zisN6obBf5dHpWxu1DAvefxkD-eN4HSFeACOg@mail.gmail.com>

ConstructorAble ?  (I'm happy to come up with a whole list of candidates).
:-)

On Friday, February 14, 2014, Dr. ERDI Gergo <gergo at erdi.hu> wrote:

> On Thu, 13 Feb 2014, Carter Schonwald wrote:
>
>  Caseable? PatternLike?
>>
>
> The reason I went with ConLike originally (apart from not noticing the
> clash) was that (bidirectional) pattern synonyms can also be used in
> expressions, so they behave like constructors in both contexts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140214/0d063658/attachment.html>

From slyich at gmail.com  Sat Feb 15 13:26:07 2014
From: slyich at gmail.com (slyich at gmail.com)
Date: Sat, 15 Feb 2014 16:26:07 +0300
Subject: [PATCH] compiler/ghc.mk: restore GhcHcOpts variable handling
Message-ID: <1392470767-19464-1-git-send-email-slyich@gmail.com>

From: Sergei Trofimovich <slyfox at gentoo.org>

Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org>
---
 compiler/ghc.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/compiler/ghc.mk b/compiler/ghc.mk
index 4977e28..d902b7f 100644
--- a/compiler/ghc.mk
+++ b/compiler/ghc.mk
@@ -667,9 +667,9 @@ compiler_stage2_CONFIGURE_OPTS += --disable-library-for-ghci
 compiler_stage3_CONFIGURE_OPTS += --disable-library-for-ghci
 
 # after build-package, because that sets compiler_stage1_HC_OPTS:
-compiler_stage1_HC_OPTS += $(GhcStage1HcOpts)
-compiler_stage2_HC_OPTS += $(GhcStage2HcOpts)
-compiler_stage3_HC_OPTS += $(GhcStage3HcOpts)
+compiler_stage1_HC_OPTS += $(GhcHcOpts) $(GhcStage1HcOpts)
+compiler_stage2_HC_OPTS += $(GhcHcOpts) $(GhcStage2HcOpts)
+compiler_stage3_HC_OPTS += $(GhcHcOpts) $(GhcStage3HcOpts)
 
 ifneq "$(BINDIST)" "YES"
 
-- 
1.8.5.2


From slyich at gmail.com  Sat Feb 15 13:30:13 2014
From: slyich at gmail.com (slyich at gmail.com)
Date: Sat, 15 Feb 2014 16:30:13 +0300
Subject: [PATCH] rts: unrust 'libbfd' debug symbols parser
Message-ID: <1392471013-19872-1-git-send-email-slyich@gmail.com>

From: Sergei Trofimovich <slyfox at gentoo.org>

Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org>
---
 configure.ac     |  3 ++-
 rts/Printer.c    | 10 ++++++++--
 rts/RtsStartup.c |  6 ++++++
 3 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index e7fbc7f..e47979c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -801,7 +801,8 @@ fi
 dnl ** check whether this machine has BFD and libiberty installed (used for debugging)
 dnl    the order of these tests matters: bfd needs libiberty
 AC_CHECK_LIB(iberty, xmalloc)
-AC_CHECK_LIB(bfd,    bfd_uncompress_section_contents)
+dnl 'bfd_init' is a rare non-macro in libbfd
+AC_CHECK_LIB(bfd,    bfd_init)
 
 dnl ################################################################
 dnl Check for libraries
diff --git a/rts/Printer.c b/rts/Printer.c
index ca9ca49..ce02b02 100644
--- a/rts/Printer.c
+++ b/rts/Printer.c
@@ -48,6 +48,9 @@ void printPtr( StgPtr p )
     raw = lookupGHCName(p);
     if (raw != NULL) {
         printZcoded(raw);
+        /* it can be just a C symbol, like 'stg_returnToStackTop' */
+        debugBelch("<%s>", raw);
+        debugBelch("[%p]", p);
     } else {
         debugBelch("%p", p);
     }
@@ -794,7 +797,7 @@ static void printZcoded( const char *raw )
    disabling this for now. 
 */
 #ifdef USING_LIBBFD
-
+#include "../mk/config.h" /* silly BFD's requirement */
 #include <bfd.h>
 
 /* Fairly ad-hoc piece of code that seems to filter out a lot of
@@ -863,7 +866,10 @@ extern void DEBUG_LoadSymbols( char *name )
         for( i = 0; i != number_of_symbols; ++i ) {
             symbol_info info;
             bfd_get_symbol_info(abfd,symbol_table[i],&info);
-            /*debugBelch("\t%c\t0x%x      \t%s\n",info.type,(nat)info.value,info.name); */
+            if (0)
+            {
+                debugBelch("\t%c\t0x%x      \t%s\n",info.type,(nat)info.value,info.name);
+            }
             if (isReal(info.type, info.name)) {
                 num_real_syms += 1;
             }
diff --git a/rts/RtsStartup.c b/rts/RtsStartup.c
index aa7306f..5bdef94 100644
--- a/rts/RtsStartup.c
+++ b/rts/RtsStartup.c
@@ -19,6 +19,7 @@
 #include "RtsFlags.h"
 #include "RtsUtils.h"
 #include "Prelude.h"
+#include "Printer.h"    /* DEBUG_LoadSymbols */
 #include "Schedule.h"   /* initScheduler */
 #include "Stats.h"      /* initStats */
 #include "STM.h"        /* initSTM */
@@ -162,6 +163,11 @@ hs_init_ghc(int *argc, char **argv[], RtsConfig rts_config)
                       rts_config.rts_opts_enabled, rts_config.rts_opts, rts_config.rts_hs_main);
     }
 
+#ifdef DEBUG
+    /* load debugging symbols */
+    DEBUG_LoadSymbols((*argv)[0]);
+#endif /* DEBUG */
+
     /* Initialise the stats department, phase 1 */
     initStats1();
 
-- 
1.8.5.2


From slyich at gmail.com  Sat Feb 15 13:52:15 2014
From: slyich at gmail.com (slyich at gmail.com)
Date: Sat, 15 Feb 2014 16:52:15 +0300
Subject: [PATCH] includes/stg/SMP.h: use 'NOSMP' instead of never defined
 'WITHSMP'
Message-ID: <1392472335-24535-1-git-send-email-slyich@gmail.com>

From: Sergei Trofimovich <slyfox at gentoo.org>

Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org>
---
 includes/stg/SMP.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/includes/stg/SMP.h b/includes/stg/SMP.h
index 01663dd..8d819c7 100644
--- a/includes/stg/SMP.h
+++ b/includes/stg/SMP.h
@@ -154,7 +154,7 @@ xchg(StgPtr p, StgWord w)
                           : "r" (w), "r" (p)
                           : "memory"
                           );
-#elif !defined(WITHSMP)
+#elif defined(NOSMP)
     result = *p;
     *p = w;
 #else
@@ -225,7 +225,7 @@ cas(StgVolatilePtr p, StgWord o, StgWord n)
                 : "cc","memory");
 
     return result;
-#elif !defined(WITHSMP)
+#elif defined(NOSMP)
     StgWord result;
     result = *p;
     if (result == o) {
@@ -313,7 +313,7 @@ write_barrier(void) {
     __asm__ __volatile__ ("" : : : "memory");
 #elif arm_HOST_ARCH && !defined(arm_HOST_ARCH_PRE_ARMv7)
     __asm__ __volatile__ ("dmb  st" : : : "memory");
-#elif !defined(WITHSMP)
+#elif defined(NOSMP)
     return;
 #else
 #error memory barriers unimplemented on this architecture
@@ -332,7 +332,7 @@ store_load_barrier(void) {
     __asm__ __volatile__ ("membar #StoreLoad" : : : "memory");
 #elif arm_HOST_ARCH && !defined(arm_HOST_ARCH_PRE_ARMv7)
     __asm__ __volatile__ ("dmb" : : : "memory");
-#elif !defined(WITHSMP)
+#elif defined(NOSMP)
     return;
 #else
 #error memory barriers unimplemented on this architecture
@@ -352,7 +352,7 @@ load_load_barrier(void) {
     __asm__ __volatile__ ("" : : : "memory");
 #elif arm_HOST_ARCH && !defined(arm_HOST_ARCH_PRE_ARMv7)
     __asm__ __volatile__ ("dmb" : : : "memory");
-#elif !defined(WITHSMP)
+#elif defined(NOSMP)
     return;
 #else
 #error memory barriers unimplemented on this architecture
-- 
1.8.5.2


From carter.schonwald at gmail.com  Sat Feb 15 17:54:09 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 15 Feb 2014 12:54:09 -0500
Subject: [PATCH] includes/stg/SMP.h: use 'NOSMP' instead of never defined
 'WITHSMP'
In-Reply-To: <1392472335-24535-1-git-send-email-slyich@gmail.com>
References: <1392472335-24535-1-git-send-email-slyich@gmail.com>
Message-ID: <CAHYVw0w2t04Yd-1f3MvrxuK3_jbbwf82PFvVgzxRYfMWZCP=HA@mail.gmail.com>

Could you open a trac ticket for these patches and post em there? :-)
-Carter

On Saturday, February 15, 2014, <slyich at gmail.com> wrote:

> From: Sergei Trofimovich <slyfox at gentoo.org <javascript:;>>
>
> Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org <javascript:;>>
> ---
>  includes/stg/SMP.h | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/includes/stg/SMP.h b/includes/stg/SMP.h
> index 01663dd..8d819c7 100644
> --- a/includes/stg/SMP.h
> +++ b/includes/stg/SMP.h
> @@ -154,7 +154,7 @@ xchg(StgPtr p, StgWord w)
>                            : "r" (w), "r" (p)
>                            : "memory"
>                            );
> -#elif !defined(WITHSMP)
> +#elif defined(NOSMP)
>      result = *p;
>      *p = w;
>  #else
> @@ -225,7 +225,7 @@ cas(StgVolatilePtr p, StgWord o, StgWord n)
>                  : "cc","memory");
>
>      return result;
> -#elif !defined(WITHSMP)
> +#elif defined(NOSMP)
>      StgWord result;
>      result = *p;
>      if (result == o) {
> @@ -313,7 +313,7 @@ write_barrier(void) {
>      __asm__ __volatile__ ("" : : : "memory");
>  #elif arm_HOST_ARCH && !defined(arm_HOST_ARCH_PRE_ARMv7)
>      __asm__ __volatile__ ("dmb  st" : : : "memory");
> -#elif !defined(WITHSMP)
> +#elif defined(NOSMP)
>      return;
>  #else
>  #error memory barriers unimplemented on this architecture
> @@ -332,7 +332,7 @@ store_load_barrier(void) {
>      __asm__ __volatile__ ("membar #StoreLoad" : : : "memory");
>  #elif arm_HOST_ARCH && !defined(arm_HOST_ARCH_PRE_ARMv7)
>      __asm__ __volatile__ ("dmb" : : : "memory");
> -#elif !defined(WITHSMP)
> +#elif defined(NOSMP)
>      return;
>  #else
>  #error memory barriers unimplemented on this architecture
> @@ -352,7 +352,7 @@ load_load_barrier(void) {
>      __asm__ __volatile__ ("" : : : "memory");
>  #elif arm_HOST_ARCH && !defined(arm_HOST_ARCH_PRE_ARMv7)
>      __asm__ __volatile__ ("dmb" : : : "memory");
> -#elif !defined(WITHSMP)
> +#elif defined(NOSMP)
>      return;
>  #else
>  #error memory barriers unimplemented on this architecture
> --
> 1.8.5.2
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140215/07df6c69/attachment.html>

From slyich at gmail.com  Sat Feb 15 19:38:54 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Sat, 15 Feb 2014 22:38:54 +0300
Subject: [PATCH] compiler/ghc.mk: restore GhcHcOpts variable handling
In-Reply-To: <1392470767-19464-1-git-send-email-slyich@gmail.com>
References: <1392470767-19464-1-git-send-email-slyich@gmail.com>
Message-ID: <20140215223854.0e90ad8d@sf>

On Sat, 15 Feb 2014 16:26:07 +0300
slyich at gmail.com wrote:

> From: Sergei Trofimovich <slyfox at gentoo.org>
> 
> Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org>
> ---
>  compiler/ghc.mk | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

On trac as well:
    https://ghc.haskell.org/trac/ghc/ticket/8787

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140215/7071710c/attachment.sig>

From slyich at gmail.com  Sat Feb 15 19:46:35 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Sat, 15 Feb 2014 22:46:35 +0300
Subject: [PATCH] includes/stg/SMP.h: use 'NOSMP' instead of never
 defined 'WITHSMP'
In-Reply-To: <CAHYVw0w2t04Yd-1f3MvrxuK3_jbbwf82PFvVgzxRYfMWZCP=HA@mail.gmail.com>
References: <1392472335-24535-1-git-send-email-slyich@gmail.com>
 <CAHYVw0w2t04Yd-1f3MvrxuK3_jbbwf82PFvVgzxRYfMWZCP=HA@mail.gmail.com>
Message-ID: <20140215224635.3f27f3ea@sf>

On Sat, 15 Feb 2014 12:54:09 -0500
Carter Schonwald <carter.schonwald at gmail.com> wrote:

> Could you open a trac ticket for these patches and post em there? :-)
> -Carter

Sure! done as:
    https://ghc.haskell.org/trac/ghc/ticket/8789

> On Saturday, February 15, 2014, <slyich at gmail.com> wrote:
> 
> > From: Sergei Trofimovich <slyfox at gentoo.org <javascript:;>>
> >
> > Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org <javascript:;>>

What a funny semicolon quote

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140215/36574459/attachment.sig>

From slyich at gmail.com  Sat Feb 15 19:57:47 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Sat, 15 Feb 2014 22:57:47 +0300
Subject: [PATCH] rts: unrust 'libbfd' debug symbols parser
In-Reply-To: <1392471013-19872-1-git-send-email-slyich@gmail.com>
References: <1392471013-19872-1-git-send-email-slyich@gmail.com>
Message-ID: <20140215225747.7787c12c@sf>

On Sat, 15 Feb 2014 16:30:13 +0300
slyich at gmail.com wrote:

> From: Sergei Trofimovich <slyfox at gentoo.org>
> 
> Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org>
> ---
>  configure.ac     |  3 ++-
>  rts/Printer.c    | 10 ++++++++--
>  rts/RtsStartup.c |  6 ++++++
>  3 files changed, 16 insertions(+), 3 deletions(-)

On trac as well:
    https://ghc.haskell.org/trac/ghc/ticket/8790

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140215/9a2709b5/attachment.sig>

From carter.schonwald at gmail.com  Sat Feb 15 19:59:29 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 15 Feb 2014 14:59:29 -0500
Subject: Overlapping names in GHC: ConLike
In-Reply-To: <CAO7EwMrD7mg+um2dPEjDQCnaPvVyfpN1As9gym3ZJb2auL=EgA@mail.gmail.com>
References: <1392286910.2900.13.camel@kirk>
 <CAHYVw0xN6TdEVoWjd776c4dFPOc9HvAw_JApog_0NPTiK=PX1w@mail.gmail.com>
 <alpine.DEB.2.10.1402151030500.3396@galaxy>
 <CAHYVw0xvLCa3+zisN6obBf5dHpWxu1DAvefxkD-eN4HSFeACOg@mail.gmail.com>
 <CAO7EwMrD7mg+um2dPEjDQCnaPvVyfpN1As9gym3ZJb2auL=EgA@mail.gmail.com>
Message-ID: <CAHYVw0w7YF1o9GFph_7oDg0j_J1YVQLPxY+JDtcKYhokuEPz5A@mail.gmail.com>

BijectionLike, InvertableCon
ReversableConstructor
InvertableLike
Dualable
DualLike
DuelFoil -- I kid

basically something about how patternSynonyms and normal type constructors
have this "bjiective" (ish?) quality






On Fri, Feb 14, 2014 at 11:10 PM, Dr. ?RDI Gerg? <gergo at erdi.hu> wrote:

> Can we force some more elements of that lazy stream?
> On Feb 15, 2014 12:09 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
> wrote:
>
>> ConstructorAble ?  (I'm happy to come up with a whole list of
>> candidates). :-)
>>
>> On Friday, February 14, 2014, Dr. ERDI Gergo <gergo at erdi.hu> wrote:
>>
>>> On Thu, 13 Feb 2014, Carter Schonwald wrote:
>>>
>>>  Caseable? PatternLike?
>>>>
>>>
>>> The reason I went with ConLike originally (apart from not noticing the
>>> clash) was that (bidirectional) pattern synonyms can also be used in
>>> expressions, so they behave like constructors in both contexts.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140215/0d5ef825/attachment-0001.html>

From simonpj at microsoft.com  Mon Feb 17 09:03:13 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 17 Feb 2014 09:03:13 +0000
Subject: [commit: ghc] master: Fix #8754 in a round-about way. (5023c91)
In-Reply-To: <20140217074903.2958C2406B@ghc.haskell.org>
References: <20140217074903.2958C2406B@ghc.haskell.org>
Message-ID: <59543203684B2244980D7E4057D5FBC148786AAB@DB3EX14MBXC308.europe.corp.microsoft.com>

Austin, eek... you really need a Note [Need to initialise the hooks], a significant comment, and an explicit mention of this ticket.  Otherwise someone in 2 yrs time will have no clue why that lonely call to defaultsHook is so important, nor will be confident enough to remove it when the hookery is done better.

I have gotten into habit of writing a Note about virtually any fix.  After all, it is by definition not obvious or we'd have got it right the first time.  And I have too often re-invented the wheel when looking at Note-free code; or thanked the author when I read a Note and thought "ah, *that's* why!".   I wrote up some of this here https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle

I don't think the commit log is enough.  git annotate may or may not lead you to the right comment, depending on how heavily modified that code is.

Thanks

Simon 

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 17 February 2014 07:49
| To: ghc-commits at haskell.org
| Subject: [commit: ghc] master: Fix #8754 in a round-about way. (5023c91)
| 
| Repository : ssh://git at git.haskell.org/ghc
| 
| On branch  : master
| Link       :
| http://ghc.haskell.org/trac/ghc/changeset/5023c91780e90947680fe0640f7564
| a4f6448bea/ghc
| 
| >---------------------------------------------------------------
| 
| commit 5023c91780e90947680fe0640f7564a4f6448bea
| Author: Austin Seipp <austin at well-typed.com>
| Date:   Sun Feb 16 19:10:16 2014 -0600
| 
|     Fix #8754 in a round-about way.
| 
|     For some reason on OS X, it seems like -Bsymbolic (which we use for
|     hooks into the RTS) isn't working, which results in #8754, where
| stats
|     don't work because defaultHooks doesn't initialize the stats flag.
| This
|     seems to work on Linux static/dynamically, but only on OS X
| statically.
| 
|     After talking with Simon, really, the entire hooks thing is a bit
|     fragile. For now, we just work around it (since GHCi is dynamically
|     linked) by calling into the defaultHooks ourselves when GHC starts.
| 
|     Signed-off-by: Austin Seipp <austin at well-typed.com>
| 
| 
| >---------------------------------------------------------------
| 
| 5023c91780e90947680fe0640f7564a4f6448bea
|  ghc/Main.hs |    4 ++++
|  1 file changed, 4 insertions(+)
| 
| diff --git a/ghc/Main.hs b/ghc/Main.hs
| index 868042b..1aa6553 100644
| --- a/ghc/Main.hs
| +++ b/ghc/Main.hs
| @@ -1,4 +1,5 @@
|  {-# OPTIONS -fno-warn-incomplete-patterns -optc-DNON_POSIX_SOURCE #-}
| +{-# LANGUAGE ForeignFunctionInterface #-}
| 
|  -----------------------------------------------------------------------
| ------
|  --
| @@ -76,6 +77,7 @@ import Data.Maybe
| 
|  main :: IO ()
|  main = do
| +   defaultsHook
|     hSetBuffering stdout LineBuffering
|     hSetBuffering stderr LineBuffering
|     GHC.defaultErrorHandler defaultFatalMessager defaultFlushOut $ do @@
| -818,3 +820,5 @@ unknownFlagsErr fs = throwGhcException $ UsageError $
| concatMap oneError fs
|          (case fuzzyMatch f (nub allFlags) of
|              [] -> ""
|              suggs -> "did you mean one of:\n" ++ unlines (map ("  " ++)
| suggs))
| +
| +foreign import ccall safe "defaultsHook" defaultsHook :: IO ()
| 
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-commits

From jan.stolarek at p.lodz.pl  Mon Feb 17 09:46:06 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Mon, 17 Feb 2014 10:46:06 +0100
Subject: 7.8.1-candidate fail
In-Reply-To: <CAMYb46AzG=LfLnMZ_VfKA9VwC7D3OewOp9JF8TxOakCBhNhTYg@mail.gmail.com>
References: <1391717159.13808.11.camel@one.mechvel.pereslavl.ru>
 <201402062150.55164.jan.stolarek@p.lodz.pl>
 <CAMYb46AzG=LfLnMZ_VfKA9VwC7D3OewOp9JF8TxOakCBhNhTYg@mail.gmail.com>
Message-ID: <201402171046.07052.jan.stolarek@p.lodz.pl>

Thanks. I upgraded Squeeze to Wheezy recently just because of that issue, so it's kinda solved for 
me.

Janek

Dnia pi?tek, 14 lutego 2014, Tyler Huffman napisa?:
> I added a comment in the ticket, but it looks like Debian Squeeze is using
> libgmp3-dev 2:4.3.2, which was the same version that I had when I was
> running into this issue.
>
> Using an updated version of libgmp3-dev will fix the issue, but I'm not
> entirely sure if we need to consider supporting the packages in Debian
> Squeeze repository since Debian Wheezy is the new stable distribution, and
> it uses libgmp-dev 2:5.0.5. Someone with more intimate knowledge of GHC
> development might be able to speak on this issue.
>
>
> Regards,
> Tyler Huffman
>
> On Thu, Feb 6, 2014 at 1:50 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> > I had the same problem on Debian Squeeze:
> >
> > https://ghc.haskell.org/trac/ghc/ticket/8666
> >
> > What is your distro?
> >
> > CCing ghc-devs.
> >
> > Janek
> >
> > Dnia czwartek, 6 lutego 2014, Sergei Meshveliani napisa?:
> > > Dear GHC team,
> > >
> > > I am trying to test    ghc-7.8.20140130-src.tar.bz2
> > >
> > > I make it from source with   ghc-7.6.3  on Debian Linux (64 bit).
> > >
> > > ./configure  looks all right.
> > >
> > > And `make' reports after 40 minutes:
> > >
> > > -------------------------------------------------------
> > > ...
> > > ...
> > > "inplace/bin/ghc-stage1" -optc-Ilibraries/integer-gmp/.
> > > -optc-I'/home/mechvel/g.....
> > > ...
> > > ...
> > > /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation
> > > R_X86_64_32 against `__gmpz_sub' can not be used when making a shared
> > > object; recompile with -fPIC
> > > libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad
> > > value collect2: ld returned 1 exit status
> > > make[1]: ***
> > > [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0\
> > > -ghc7.8.20140130.so] Error 1
> > > -------------------------------------------------------
> > >
> > >
> > > What might this mean? Need I to install a fresher  libgmp ?
> > >
> > > Thanks,
> > >
> > > ------
> > > Sergei
> > >
> > > _______________________________________________
> > > Glasgow-haskell-users mailing list
> > > Glasgow-haskell-users at haskell.org
> > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs



From marlowsd at gmail.com  Mon Feb 17 10:22:36 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 17 Feb 2014 10:22:36 +0000
Subject: [commit: packages/base] master: Implement foldl with foldr
 (b63face)
In-Reply-To: <20140210135233.52B0D2406B@ghc.haskell.org>
References: <20140210135233.52B0D2406B@ghc.haskell.org>
Message-ID: <5301E2EC.2010409@gmail.com>

This worries me a bit.  If foldl isn't inlined, I get a less efficient 
version, so it has to be inlined everywhere.  So -O0 code gets worse, 
and binary sizes for -O1+ get bigger - foldl, sum, and product are now 
INLINE.

What I'm arguing is that we should have more flexibility to *not* inline 
things (INLINABLE is much better than INLINE), and when not inlining 
things we should be calling an efficient version of the function.  This 
is why map is not defined in terms of foldr, for instance.

Cheers,
	Simon

On 10/02/2014 13:52, git at git.haskell.org wrote:
> Repository : ssh://git at git.haskell.org/base
>
> On branch  : master
> Link       : http://ghc.haskell.org/trac/ghc/changeset/b63facef165b957183b65604ef99b2b8574747a5/base
>
>> ---------------------------------------------------------------
>
> commit b63facef165b957183b65604ef99b2b8574747a5
> Author: Joachim Breitner <mail at joachim-breitner.de>
> Date:   Tue Jan 28 14:31:05 2014 +0100
>
>      Implement foldl with foldr
>
>      together with the call arity analysis and the following patch (about inlining
>      maximum), we get nice benefits from fusing foldl and foldl' with good
>      producers:
>
>                      Min          -0.1%    -74.5%     -6.8%     -8.3%    -50.0%
>                      Max          +0.2%      0.0%    +38.5%    +38.5%      0.0%
>           Geometric Mean          -0.0%     -4.1%     +7.7%     +7.7%     -0.8%
>
>      Because this depends on a compiler optimisation, we have to watch out for cases
>      where this is not an improvements, and whether they occur in the wild.
>
>
>> ---------------------------------------------------------------
>
> b63facef165b957183b65604ef99b2b8574747a5
>   Data/List.hs |   34 +++++++++-------------------------
>   GHC/List.lhs |   13 +++++++------
>   2 files changed, 16 insertions(+), 31 deletions(-)
>
> diff --git a/Data/List.hs b/Data/List.hs
> index 130ceb2..4796055 100644
> --- a/Data/List.hs
> +++ b/Data/List.hs
> @@ -1,5 +1,5 @@
>   {-# LANGUAGE Trustworthy #-}
> -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-}
> +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-}
>
>   -----------------------------------------------------------------------------
>   -- |
> @@ -989,10 +989,11 @@ unfoldr f b  =
>   -- -----------------------------------------------------------------------------
>
>   -- | A strict version of 'foldl'.
> -foldl'           :: (b -> a -> b) -> b -> [a] -> b
> -foldl' f z0 xs0 = lgo z0 xs0
> -    where lgo z []     = z
> -          lgo z (x:xs) = let z' = f z x in z' `seq` lgo z' xs
> +foldl'           :: forall a b . (b -> a -> b) -> b -> [a] -> b
> +foldl' k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> z `seq` fn (k z v)) (id :: b -> b) xs z0
> +-- Implementing foldl' via foldr is only a good idea if the compiler can optimize
> +-- the resulting code (eta-expand the recursive "go"), so this needs -fcall-arity!
> +-- Also see #7994
>
>   -- | 'foldl1' is a variant of 'foldl' that has no starting value argument,
>   -- and thus must be applied to non-empty lists.
> @@ -1008,32 +1009,15 @@ foldl1' _ []             =  errorEmptyList "foldl1'"
>   -- -----------------------------------------------------------------------------
>   -- List sum and product
>
> -{-# SPECIALISE sum     :: [Int] -> Int #-}
> -{-# SPECIALISE sum     :: [Integer] -> Integer #-}
> -{-# INLINABLE sum #-}
> -{-# SPECIALISE product :: [Int] -> Int #-}
> -{-# SPECIALISE product :: [Integer] -> Integer #-}
> -{-# INLINABLE product #-}
> --- We make 'sum' and 'product' inlinable so that we get specialisations
> --- at other types.  See, for example, Trac #7507.
> -
>   -- | The 'sum' function computes the sum of a finite list of numbers.
>   sum                     :: (Num a) => [a] -> a
>   -- | The 'product' function computes the product of a finite list of numbers.
>   product                 :: (Num a) => [a] -> a
> -#ifdef USE_REPORT_PRELUDE
> +
> +{-# INLINE sum #-}
>   sum                     =  foldl (+) 0
> +{-# INLINE product #-}
>   product                 =  foldl (*) 1
> -#else
> -sum     l       = sum' l 0
> -  where
> -    sum' []     a = a
> -    sum' (x:xs) a = sum' xs (a+x)
> -product l       = prod l 1
> -  where
> -    prod []     a = a
> -    prod (x:xs) a = prod xs (a*x)
> -#endif
>
>   -- -----------------------------------------------------------------------------
>   -- Functions on strings
> diff --git a/GHC/List.lhs b/GHC/List.lhs
> index b7b78c7..e004ded 100644
> --- a/GHC/List.lhs
> +++ b/GHC/List.lhs
> @@ -1,6 +1,6 @@
>   \begin{code}
>   {-# LANGUAGE Trustworthy #-}
> -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-}
> +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-}
>   {-# OPTIONS_HADDOCK hide #-}
>
>   -----------------------------------------------------------------------------
> @@ -178,11 +178,12 @@ filterFB c p x r | p x       = x `c` r
>   -- can be inlined, and then (often) strictness-analysed,
>   -- and hence the classic space leak on foldl (+) 0 xs
>
> -foldl        :: (b -> a -> b) -> b -> [a] -> b
> -foldl f z0 xs0 = lgo z0 xs0
> -             where
> -                lgo z []     =  z
> -                lgo z (x:xs) = lgo (f z x) xs
> +foldl :: forall a b. (b -> a -> b) -> b -> [a] -> b
> +{-# INLINE foldl #-}
> +foldl k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> fn (k z v)) (id :: b -> b) xs z0
> +-- Implementing foldl via foldr is only a good idea if the compiler can optimize
> +-- the resulting code (eta-expand the recursive "go"), so this needs -fcall-arity!
> +-- Also see #7994
>
>   -- | 'scanl' is similar to 'foldl', but returns a list of successive
>   -- reduced values from the left:
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>

From marlowsd at gmail.com  Mon Feb 17 10:22:48 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 17 Feb 2014 10:22:48 +0000
Subject: [commit: packages/base] master: Implement foldl with foldr
 (b63face)
In-Reply-To: <20140210135233.52B0D2406B@ghc.haskell.org>
References: <20140210135233.52B0D2406B@ghc.haskell.org>
Message-ID: <5301E2F8.9040900@gmail.com>

This worries me a bit.  If foldl isn't inlined, I get a less efficient 
version, so it has to be inlined everywhere.  So -O0 code gets worse, 
and binary sizes for -O1+ get bigger - foldl, sum, and product are now 
INLINE.

What I'm arguing is that we should have more flexibility to *not* inline 
things (INLINABLE is much better than INLINE), and when not inlining 
things we should be calling an efficient version of the function.  This 
is why map is not defined in terms of foldr, for instance.

Cheers,
	Simon

On 10/02/2014 13:52, git at git.haskell.org wrote:
> Repository : ssh://git at git.haskell.org/base
>
> On branch  : master
> Link       : http://ghc.haskell.org/trac/ghc/changeset/b63facef165b957183b65604ef99b2b8574747a5/base
>
>> ---------------------------------------------------------------
>
> commit b63facef165b957183b65604ef99b2b8574747a5
> Author: Joachim Breitner <mail at joachim-breitner.de>
> Date:   Tue Jan 28 14:31:05 2014 +0100
>
>      Implement foldl with foldr
>
>      together with the call arity analysis and the following patch (about inlining
>      maximum), we get nice benefits from fusing foldl and foldl' with good
>      producers:
>
>                      Min          -0.1%    -74.5%     -6.8%     -8.3%    -50.0%
>                      Max          +0.2%      0.0%    +38.5%    +38.5%      0.0%
>           Geometric Mean          -0.0%     -4.1%     +7.7%     +7.7%     -0.8%
>
>      Because this depends on a compiler optimisation, we have to watch out for cases
>      where this is not an improvements, and whether they occur in the wild.
>
>
>> ---------------------------------------------------------------
>
> b63facef165b957183b65604ef99b2b8574747a5
>   Data/List.hs |   34 +++++++++-------------------------
>   GHC/List.lhs |   13 +++++++------
>   2 files changed, 16 insertions(+), 31 deletions(-)
>
> diff --git a/Data/List.hs b/Data/List.hs
> index 130ceb2..4796055 100644
> --- a/Data/List.hs
> +++ b/Data/List.hs
> @@ -1,5 +1,5 @@
>   {-# LANGUAGE Trustworthy #-}
> -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-}
> +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-}
>
>   -----------------------------------------------------------------------------
>   -- |
> @@ -989,10 +989,11 @@ unfoldr f b  =
>   -- -----------------------------------------------------------------------------
>
>   -- | A strict version of 'foldl'.
> -foldl'           :: (b -> a -> b) -> b -> [a] -> b
> -foldl' f z0 xs0 = lgo z0 xs0
> -    where lgo z []     = z
> -          lgo z (x:xs) = let z' = f z x in z' `seq` lgo z' xs
> +foldl'           :: forall a b . (b -> a -> b) -> b -> [a] -> b
> +foldl' k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> z `seq` fn (k z v)) (id :: b -> b) xs z0
> +-- Implementing foldl' via foldr is only a good idea if the compiler can optimize
> +-- the resulting code (eta-expand the recursive "go"), so this needs -fcall-arity!
> +-- Also see #7994
>
>   -- | 'foldl1' is a variant of 'foldl' that has no starting value argument,
>   -- and thus must be applied to non-empty lists.
> @@ -1008,32 +1009,15 @@ foldl1' _ []             =  errorEmptyList "foldl1'"
>   -- -----------------------------------------------------------------------------
>   -- List sum and product
>
> -{-# SPECIALISE sum     :: [Int] -> Int #-}
> -{-# SPECIALISE sum     :: [Integer] -> Integer #-}
> -{-# INLINABLE sum #-}
> -{-# SPECIALISE product :: [Int] -> Int #-}
> -{-# SPECIALISE product :: [Integer] -> Integer #-}
> -{-# INLINABLE product #-}
> --- We make 'sum' and 'product' inlinable so that we get specialisations
> --- at other types.  See, for example, Trac #7507.
> -
>   -- | The 'sum' function computes the sum of a finite list of numbers.
>   sum                     :: (Num a) => [a] -> a
>   -- | The 'product' function computes the product of a finite list of numbers.
>   product                 :: (Num a) => [a] -> a
> -#ifdef USE_REPORT_PRELUDE
> +
> +{-# INLINE sum #-}
>   sum                     =  foldl (+) 0
> +{-# INLINE product #-}
>   product                 =  foldl (*) 1
> -#else
> -sum     l       = sum' l 0
> -  where
> -    sum' []     a = a
> -    sum' (x:xs) a = sum' xs (a+x)
> -product l       = prod l 1
> -  where
> -    prod []     a = a
> -    prod (x:xs) a = prod xs (a*x)
> -#endif
>
>   -- -----------------------------------------------------------------------------
>   -- Functions on strings
> diff --git a/GHC/List.lhs b/GHC/List.lhs
> index b7b78c7..e004ded 100644
> --- a/GHC/List.lhs
> +++ b/GHC/List.lhs
> @@ -1,6 +1,6 @@
>   \begin{code}
>   {-# LANGUAGE Trustworthy #-}
> -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-}
> +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-}
>   {-# OPTIONS_HADDOCK hide #-}
>
>   -----------------------------------------------------------------------------
> @@ -178,11 +178,12 @@ filterFB c p x r | p x       = x `c` r
>   -- can be inlined, and then (often) strictness-analysed,
>   -- and hence the classic space leak on foldl (+) 0 xs
>
> -foldl        :: (b -> a -> b) -> b -> [a] -> b
> -foldl f z0 xs0 = lgo z0 xs0
> -             where
> -                lgo z []     =  z
> -                lgo z (x:xs) = lgo (f z x) xs
> +foldl :: forall a b. (b -> a -> b) -> b -> [a] -> b
> +{-# INLINE foldl #-}
> +foldl k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> fn (k z v)) (id :: b -> b) xs z0
> +-- Implementing foldl via foldr is only a good idea if the compiler can optimize
> +-- the resulting code (eta-expand the recursive "go"), so this needs -fcall-arity!
> +-- Also see #7994
>
>   -- | 'scanl' is similar to 'foldl', but returns a list of successive
>   -- reduced values from the left:
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>

From mail at joachim-breitner.de  Mon Feb 17 10:48:04 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 17 Feb 2014 10:48:04 +0000
Subject: [commit: packages/base] master: Implement foldl with foldr
 (b63face)
In-Reply-To: <5301E2F8.9040900@gmail.com>
References: <20140210135233.52B0D2406B@ghc.haskell.org>
 <5301E2F8.9040900@gmail.com>
Message-ID: <1392634084.3558.14.camel@kirk>

Hi,

Am Montag, den 17.02.2014, 10:22 +0000 schrieb Simon Marlow:
> This worries me a bit.  If foldl isn't inlined, I get a less efficient 
> version, so it has to be inlined everywhere.  So -O0 code gets worse, 
> and binary sizes for -O1+ get bigger - foldl, sum, and product are now 
> INLINE.
> 
> What I'm arguing is that we should have more flexibility to *not* inline 
> things (INLINABLE is much better than INLINE), and when not inlining 
> things we should be calling an efficient version of the function.  This 
> is why map is not defined in terms of foldr, for instance.

so you are arguing that we should do what is done for map, i.e. have the
old definition for foldl, make
        foldl k z0 xs = foldr (\v fn z -> fn (k z v)) id xs z0
a RULE [~0] and have another RULE [0] that does 
        foldr (\v fn z -> fn (k z v)) id xs z0 = foldl k z0 xs

Is that right?

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140217/cca40903/attachment-0001.sig>

From roma at ro-che.info  Mon Feb 17 10:56:05 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Mon, 17 Feb 2014 12:56:05 +0200
Subject: [commit: packages/base] master: Implement foldl with foldr
 (b63face)
In-Reply-To: <5301E2F8.9040900@gmail.com>
References: <20140210135233.52B0D2406B@ghc.haskell.org>
 <5301E2F8.9040900@gmail.com>
Message-ID: <20140217105605.GA26392@sniper>

* Simon Marlow <marlowsd at gmail.com> [2014-02-17 10:22:48+0000]
> This worries me a bit.  If foldl isn't inlined, I get a less
> efficient version, so it has to be inlined everywhere.  So -O0 code
> gets worse, and binary sizes for -O1+ get bigger - foldl, sum, and
> product are now INLINE.

Correct me if I'm wrong, but if sum and product are not inlined, they
will be computed using the terrible lazy fold. Isn't this a good reason
to inline them anyway?

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140217/a66c2776/attachment.sig>

From marlowsd at gmail.com  Mon Feb 17 10:56:49 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 17 Feb 2014 10:56:49 +0000
Subject: [commit: packages/base] master: Implement foldl with foldr
 (b63face)
In-Reply-To: <5301E2F8.9040900@gmail.com>
References: <20140210135233.52B0D2406B@ghc.haskell.org>
 <5301E2F8.9040900@gmail.com>
Message-ID: <5301EAF1.5040401@gmail.com>

Ah, I realise it's ok so long as the original definition of foldl/foldl' 
gets optimised to the right thing.  If that's the case just ignore me.

Cheers,
Simon

On 17/02/2014 10:22, Simon Marlow wrote:
> This worries me a bit.  If foldl isn't inlined, I get a less efficient
> version, so it has to be inlined everywhere.  So -O0 code gets worse,
> and binary sizes for -O1+ get bigger - foldl, sum, and product are now
> INLINE.
>
> What I'm arguing is that we should have more flexibility to *not* inline
> things (INLINABLE is much better than INLINE), and when not inlining
> things we should be calling an efficient version of the function.  This
> is why map is not defined in terms of foldr, for instance.
>
> Cheers,
>      Simon
>
> On 10/02/2014 13:52, git at git.haskell.org wrote:
>> Repository : ssh://git at git.haskell.org/base
>>
>> On branch  : master
>> Link       :
>> http://ghc.haskell.org/trac/ghc/changeset/b63facef165b957183b65604ef99b2b8574747a5/base
>>
>>
>>> ---------------------------------------------------------------
>>
>> commit b63facef165b957183b65604ef99b2b8574747a5
>> Author: Joachim Breitner <mail at joachim-breitner.de>
>> Date:   Tue Jan 28 14:31:05 2014 +0100
>>
>>      Implement foldl with foldr
>>
>>      together with the call arity analysis and the following patch
>> (about inlining
>>      maximum), we get nice benefits from fusing foldl and foldl' with
>> good
>>      producers:
>>
>>                      Min          -0.1%    -74.5%     -6.8%
>> -8.3%    -50.0%
>>                      Max          +0.2%      0.0%    +38.5%
>> +38.5%      0.0%
>>           Geometric Mean          -0.0%     -4.1%     +7.7%
>> +7.7%     -0.8%
>>
>>      Because this depends on a compiler optimisation, we have to watch
>> out for cases
>>      where this is not an improvements, and whether they occur in the
>> wild.
>>
>>
>>> ---------------------------------------------------------------
>>
>> b63facef165b957183b65604ef99b2b8574747a5
>>   Data/List.hs |   34 +++++++++-------------------------
>>   GHC/List.lhs |   13 +++++++------
>>   2 files changed, 16 insertions(+), 31 deletions(-)
>>
>> diff --git a/Data/List.hs b/Data/List.hs
>> index 130ceb2..4796055 100644
>> --- a/Data/List.hs
>> +++ b/Data/List.hs
>> @@ -1,5 +1,5 @@
>>   {-# LANGUAGE Trustworthy #-}
>> -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-}
>> +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-}
>>
>>
>> -----------------------------------------------------------------------------
>>
>>   -- |
>> @@ -989,10 +989,11 @@ unfoldr f b  =
>>   --
>> -----------------------------------------------------------------------------
>>
>>
>>   -- | A strict version of 'foldl'.
>> -foldl'           :: (b -> a -> b) -> b -> [a] -> b
>> -foldl' f z0 xs0 = lgo z0 xs0
>> -    where lgo z []     = z
>> -          lgo z (x:xs) = let z' = f z x in z' `seq` lgo z' xs
>> +foldl'           :: forall a b . (b -> a -> b) -> b -> [a] -> b
>> +foldl' k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> z `seq` fn (k z
>> v)) (id :: b -> b) xs z0
>> +-- Implementing foldl' via foldr is only a good idea if the compiler
>> can optimize
>> +-- the resulting code (eta-expand the recursive "go"), so this needs
>> -fcall-arity!
>> +-- Also see #7994
>>
>>   -- | 'foldl1' is a variant of 'foldl' that has no starting value
>> argument,
>>   -- and thus must be applied to non-empty lists.
>> @@ -1008,32 +1009,15 @@ foldl1' _ []             =  errorEmptyList
>> "foldl1'"
>>   --
>> -----------------------------------------------------------------------------
>>
>>   -- List sum and product
>>
>> -{-# SPECIALISE sum     :: [Int] -> Int #-}
>> -{-# SPECIALISE sum     :: [Integer] -> Integer #-}
>> -{-# INLINABLE sum #-}
>> -{-# SPECIALISE product :: [Int] -> Int #-}
>> -{-# SPECIALISE product :: [Integer] -> Integer #-}
>> -{-# INLINABLE product #-}
>> --- We make 'sum' and 'product' inlinable so that we get specialisations
>> --- at other types.  See, for example, Trac #7507.
>> -
>>   -- | The 'sum' function computes the sum of a finite list of numbers.
>>   sum                     :: (Num a) => [a] -> a
>>   -- | The 'product' function computes the product of a finite list of
>> numbers.
>>   product                 :: (Num a) => [a] -> a
>> -#ifdef USE_REPORT_PRELUDE
>> +
>> +{-# INLINE sum #-}
>>   sum                     =  foldl (+) 0
>> +{-# INLINE product #-}
>>   product                 =  foldl (*) 1
>> -#else
>> -sum     l       = sum' l 0
>> -  where
>> -    sum' []     a = a
>> -    sum' (x:xs) a = sum' xs (a+x)
>> -product l       = prod l 1
>> -  where
>> -    prod []     a = a
>> -    prod (x:xs) a = prod xs (a*x)
>> -#endif
>>
>>   --
>> -----------------------------------------------------------------------------
>>
>>   -- Functions on strings
>> diff --git a/GHC/List.lhs b/GHC/List.lhs
>> index b7b78c7..e004ded 100644
>> --- a/GHC/List.lhs
>> +++ b/GHC/List.lhs
>> @@ -1,6 +1,6 @@
>>   \begin{code}
>>   {-# LANGUAGE Trustworthy #-}
>> -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-}
>> +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-}
>>   {-# OPTIONS_HADDOCK hide #-}
>>
>>
>> -----------------------------------------------------------------------------
>>
>> @@ -178,11 +178,12 @@ filterFB c p x r | p x       = x `c` r
>>   -- can be inlined, and then (often) strictness-analysed,
>>   -- and hence the classic space leak on foldl (+) 0 xs
>>
>> -foldl        :: (b -> a -> b) -> b -> [a] -> b
>> -foldl f z0 xs0 = lgo z0 xs0
>> -             where
>> -                lgo z []     =  z
>> -                lgo z (x:xs) = lgo (f z x) xs
>> +foldl :: forall a b. (b -> a -> b) -> b -> [a] -> b
>> +{-# INLINE foldl #-}
>> +foldl k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> fn (k z v)) (id
>> :: b -> b) xs z0
>> +-- Implementing foldl via foldr is only a good idea if the compiler
>> can optimize
>> +-- the resulting code (eta-expand the recursive "go"), so this needs
>> -fcall-arity!
>> +-- Also see #7994
>>
>>   -- | 'scanl' is similar to 'foldl', but returns a list of successive
>>   -- reduced values from the left:
>>
>> _______________________________________________
>> ghc-commits mailing list
>> ghc-commits at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-commits
>>

From mail at joachim-breitner.de  Mon Feb 17 11:03:08 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 17 Feb 2014 11:03:08 +0000
Subject: [commit: packages/base] master: Implement foldl with foldr
 (b63face)
In-Reply-To: <5301EAF1.5040401@gmail.com>
References: <20140210135233.52B0D2406B@ghc.haskell.org>
 <5301E2F8.9040900@gmail.com> <5301EAF1.5040401@gmail.com>
Message-ID: <1392634988.3558.18.camel@kirk>

Hi,

Am Montag, den 17.02.2014, 10:56 +0000 schrieb Simon Marlow:
> Ah, I realise it's ok so long as the original definition of foldl/foldl' 
> gets optimised to the right thing.  If that's the case just ignore me.

they should be. There are cases when the compiler is not smart enough to
produce great code i.e. folding over a list generated from a tree. But
Takano?s proposed fusion extension
(https://github.com/takano-akio/ww-fusion) will likely take care of
that.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140217/897877f1/attachment.sig>

From austin at well-typed.com  Mon Feb 17 12:49:23 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 17 Feb 2014 06:49:23 -0600
Subject: [commit: ghc] master: Fix #8754 in a round-about way. (5023c91)
In-Reply-To: <59543203684B2244980D7E4057D5FBC148786AAB@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <20140217074903.2958C2406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC148786AAB@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAEs96n22uXVLjGJLUaQqW8TVasjFWc8hOjP-e87pT=3QF8CNSg@mail.gmail.com>

Fixed! Thanks for the recommendation. I'll merge this with the 7.8 branch too.

On Mon, Feb 17, 2014 at 3:03 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> Austin, eek... you really need a Note [Need to initialise the hooks], a significant comment, and an explicit mention of this ticket.  Otherwise someone in 2 yrs time will have no clue why that lonely call to defaultsHook is so important, nor will be confident enough to remove it when the hookery is done better.
>
> I have gotten into habit of writing a Note about virtually any fix.  After all, it is by definition not obvious or we'd have got it right the first time.  And I have too often re-invented the wheel when looking at Note-free code; or thanked the author when I read a Note and thought "ah, *that's* why!".   I wrote up some of this here https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle
>
> I don't think the commit log is enough.  git annotate may or may not lead you to the right comment, depending on how heavily modified that code is.
>
> Thanks
>
> Simon
>
> | -----Original Message-----
> | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
> | git at git.haskell.org
> | Sent: 17 February 2014 07:49
> | To: ghc-commits at haskell.org
> | Subject: [commit: ghc] master: Fix #8754 in a round-about way. (5023c91)
> |
> | Repository : ssh://git at git.haskell.org/ghc
> |
> | On branch  : master
> | Link       :
> | http://ghc.haskell.org/trac/ghc/changeset/5023c91780e90947680fe0640f7564
> | a4f6448bea/ghc
> |
> | >---------------------------------------------------------------
> |
> | commit 5023c91780e90947680fe0640f7564a4f6448bea
> | Author: Austin Seipp <austin at well-typed.com>
> | Date:   Sun Feb 16 19:10:16 2014 -0600
> |
> |     Fix #8754 in a round-about way.
> |
> |     For some reason on OS X, it seems like -Bsymbolic (which we use for
> |     hooks into the RTS) isn't working, which results in #8754, where
> | stats
> |     don't work because defaultHooks doesn't initialize the stats flag.
> | This
> |     seems to work on Linux static/dynamically, but only on OS X
> | statically.
> |
> |     After talking with Simon, really, the entire hooks thing is a bit
> |     fragile. For now, we just work around it (since GHCi is dynamically
> |     linked) by calling into the defaultHooks ourselves when GHC starts.
> |
> |     Signed-off-by: Austin Seipp <austin at well-typed.com>
> |
> |
> | >---------------------------------------------------------------
> |
> | 5023c91780e90947680fe0640f7564a4f6448bea
> |  ghc/Main.hs |    4 ++++
> |  1 file changed, 4 insertions(+)
> |
> | diff --git a/ghc/Main.hs b/ghc/Main.hs
> | index 868042b..1aa6553 100644
> | --- a/ghc/Main.hs
> | +++ b/ghc/Main.hs
> | @@ -1,4 +1,5 @@
> |  {-# OPTIONS -fno-warn-incomplete-patterns -optc-DNON_POSIX_SOURCE #-}
> | +{-# LANGUAGE ForeignFunctionInterface #-}
> |
> |  -----------------------------------------------------------------------
> | ------
> |  --
> | @@ -76,6 +77,7 @@ import Data.Maybe
> |
> |  main :: IO ()
> |  main = do
> | +   defaultsHook
> |     hSetBuffering stdout LineBuffering
> |     hSetBuffering stderr LineBuffering
> |     GHC.defaultErrorHandler defaultFatalMessager defaultFlushOut $ do @@
> | -818,3 +820,5 @@ unknownFlagsErr fs = throwGhcException $ UsageError $
> | concatMap oneError fs
> |          (case fuzzyMatch f (nub allFlags) of
> |              [] -> ""
> |              suggs -> "did you mean one of:\n" ++ unlines (map ("  " ++)
> | suggs))
> | +
> | +foreign import ccall safe "defaultsHook" defaultsHook :: IO ()
> |
> | _______________________________________________
> | ghc-commits mailing list
> | ghc-commits at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-commits
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From simonpj at microsoft.com  Tue Feb 18 10:52:55 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 18 Feb 2014 10:52:55 +0000
Subject: Framework failures
Message-ID: <59543203684B2244980D7E4057D5FBC14879C5CE@DB3EX14MBXC308.europe.corp.microsoft.com>

I'm getting framework failures from the perf/ tests.  Example below.  Anyone know what is going on?

Simon

=====> T5837(normal) 1825 of 3901 [0, 0, 11]
cd ./perf/compiler && '/5playpen/simonpj/HEAD-1/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5837.hs  -ftype-function-depth=50 +RTS -V0 -tT5837.comp.stats --machine-readable -RTS  >T5837.comp.stderr 2>&1
Failed to find field:  bytes allocated
*** framework failure for T5837(normal) do_test exception
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140218/3377e484/attachment.html>

From mail at joachim-breitner.de  Tue Feb 18 11:11:02 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 18 Feb 2014 11:11:02 +0000
Subject: Framework failures
In-Reply-To: <59543203684B2244980D7E4057D5FBC14879C5CE@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC14879C5CE@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <1392721862.2706.2.camel@kirk>

Hi,

Am Dienstag, den 18.02.2014, 10:52 +0000 schrieb Simon Peyton Jones:
> I?m getting framework failures from the perf/ tests.  Example below.
> Anyone know what is going on?

ah, it?s not just here.

Something broke "+RTS -t":

$ ghc  +RTS  -t --machine-readable
ghc: no input files
Usage: For basic information, try the `--help' option.
 [("bytes allocated", "124758360")
 ,("num_GCs", "178")
 ,("average_bytes_used", "2766184")
 ,("max_bytes_used", "7785408")
 ,("num_byte_usage_samples", "5")
 ,("peak_megabytes_allocated", "16")
 ,("init_cpu_seconds", "0.00")
 ,("init_wall_seconds", "0.00")
 ,("mutator_cpu_seconds", "0.04")
 ,("mutator_wall_seconds", "0.04")
 ,("GC_cpu_seconds", "0.06")
 ,("GC_wall_seconds", "0.06")
 ]
$ ./inplace/bin/ghc-stage2 +RTS -t --machine-readable
ghc-stage2: no input files
Usage: For basic information, try the `--help' option.

The last changes on the RTS were by Sergei Trofimovich, signed-off by
Austin Seipp ? do you two know what might have caused this?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140218/6742ab49/attachment.sig>

From austin at well-typed.com  Tue Feb 18 11:19:52 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 18 Feb 2014 05:19:52 -0600
Subject: Framework failures
In-Reply-To: <1392721862.2706.2.camel@kirk>
References: <59543203684B2244980D7E4057D5FBC14879C5CE@DB3EX14MBXC308.europe.corp.microsoft.com>
 <1392721862.2706.2.camel@kirk>
Message-ID: <CAEs96n1WO0ohEYEr86Ji=a7fznAUNAKnMdwX+4Sxq=9NZce8tQ@mail.gmail.com>

I know what's wrong. I'm pushing a revert and I'll follow up with the
right fix soon (it was the fix to #8754 of course).

On Tue, Feb 18, 2014 at 5:11 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> Am Dienstag, den 18.02.2014, 10:52 +0000 schrieb Simon Peyton Jones:
>> I?m getting framework failures from the perf/ tests.  Example below.
>> Anyone know what is going on?
>
> ah, it?s not just here.
>
> Something broke "+RTS -t":
>
> $ ghc  +RTS  -t --machine-readable
> ghc: no input files
> Usage: For basic information, try the `--help' option.
>  [("bytes allocated", "124758360")
>  ,("num_GCs", "178")
>  ,("average_bytes_used", "2766184")
>  ,("max_bytes_used", "7785408")
>  ,("num_byte_usage_samples", "5")
>  ,("peak_megabytes_allocated", "16")
>  ,("init_cpu_seconds", "0.00")
>  ,("init_wall_seconds", "0.00")
>  ,("mutator_cpu_seconds", "0.04")
>  ,("mutator_wall_seconds", "0.04")
>  ,("GC_cpu_seconds", "0.06")
>  ,("GC_wall_seconds", "0.06")
>  ]
> $ ./inplace/bin/ghc-stage2 +RTS -t --machine-readable
> ghc-stage2: no input files
> Usage: For basic information, try the `--help' option.
>
> The last changes on the RTS were by Sergei Trofimovich, signed-off by
> Austin Seipp ? do you two know what might have caused this?
>
> Greetings,
> Joachim
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From mail at joachim-breitner.de  Tue Feb 18 11:32:28 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 18 Feb 2014 11:32:28 +0000
Subject: Framework failures
In-Reply-To: <CAEs96n1WO0ohEYEr86Ji=a7fznAUNAKnMdwX+4Sxq=9NZce8tQ@mail.gmail.com>
References: <59543203684B2244980D7E4057D5FBC14879C5CE@DB3EX14MBXC308.europe.corp.microsoft.com>
 <1392721862.2706.2.camel@kirk>
 <CAEs96n1WO0ohEYEr86Ji=a7fznAUNAKnMdwX+4Sxq=9NZce8tQ@mail.gmail.com>
Message-ID: <1392723148.2706.3.camel@kirk>

Hi,

ah, sorry to Sergei then. I guess I stopped considering this commit
after I saw "OS X" in the description.

Greetings,
Joachim 

Am Dienstag, den 18.02.2014, 05:19 -0600 schrieb Austin Seipp:
> I know what's wrong. I'm pushing a revert and I'll follow up with the
> right fix soon (it was the fix to #8754 of course).
> 
> On Tue, Feb 18, 2014 at 5:11 AM, Joachim Breitner
> <mail at joachim-breitner.de> wrote:
> > Hi,
> >
> > Am Dienstag, den 18.02.2014, 10:52 +0000 schrieb Simon Peyton Jones:
> >> I?m getting framework failures from the perf/ tests.  Example below.
> >> Anyone know what is going on?
> >
> > ah, it?s not just here.
> >
> > Something broke "+RTS -t":
> >
> > $ ghc  +RTS  -t --machine-readable
> > ghc: no input files
> > Usage: For basic information, try the `--help' option.
> >  [("bytes allocated", "124758360")
> >  ,("num_GCs", "178")
> >  ,("average_bytes_used", "2766184")
> >  ,("max_bytes_used", "7785408")
> >  ,("num_byte_usage_samples", "5")
> >  ,("peak_megabytes_allocated", "16")
> >  ,("init_cpu_seconds", "0.00")
> >  ,("init_wall_seconds", "0.00")
> >  ,("mutator_cpu_seconds", "0.04")
> >  ,("mutator_wall_seconds", "0.04")
> >  ,("GC_cpu_seconds", "0.06")
> >  ,("GC_wall_seconds", "0.06")
> >  ]
> > $ ./inplace/bin/ghc-stage2 +RTS -t --machine-readable
> > ghc-stage2: no input files
> > Usage: For basic information, try the `--help' option.
> >
> > The last changes on the RTS were by Sergei Trofimovich, signed-off by
> > Austin Seipp ? do you two know what might have caused this?
> >
> > Greetings,
> > Joachim
> >
> > --
> > Joachim ?nomeata? Breitner
> >   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
> >   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
> >   Debian Developer: nomeata at debian.org
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
> 
> 
> 

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140218/fc657bd5/attachment.sig>

From edskodevries at gmail.com  Tue Feb 18 16:08:50 2014
From: edskodevries at gmail.com (Edsko de Vries)
Date: Tue, 18 Feb 2014 16:08:50 +0000
Subject: Build failure of 7.8RC1 on OSX Mountain Lion
Message-ID: <CAETJ90QWPfKXhFhXVEvZAqqPoTFHCCFFWW3-rWfsXHugAA5Q=g@mail.gmail.com>

Possibly I did something wrong (certainly when I tried to build something
very close to RC1 at Austin's request it worked fine), but now I am getting

In file included from rts/sm/Evac.c:21:0:

rts/sm/GCTDecl.h:71:0:
     error: thread-local storage not supported for this target

(Host compiler: ghc 7.6.3, no mk/build.mk, standard ./configure
--prefix=.., make)

Any ideas?

-Edsko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140218/e1b9b438/attachment.html>

From duncan at well-typed.com  Tue Feb 18 16:39:20 2014
From: duncan at well-typed.com (Duncan Coutts)
Date: Tue, 18 Feb 2014 16:39:20 +0000
Subject: patch for eventlog tracing in forkProcess
Message-ID: <1392741560.21806.217.camel@dunky.localdomain>

Hi folks,

This is a bit of code I've had lying around for ages but that I never
properly tested or applied. This snippet is in danger of getting lost so
I'm sending it in and perhaps someone can try it.

There's this TODO in rts/Schedule.c forkProcess():

       // TODO: need to trace various other things in the child
       // like startup event, capabilities, process info etc

The context is that the RTS is doing a fork() and we have the eventlog
turned on. The child process makes is own new eventlog file. So events
we do during the startup of the RTS need to be duplicated here.

      // Trace various things in the child like startup event, capabilities,
      // process info etc. This is all so that the eventlog for the new
      // child process will have same stuff as if it were started standalone.
      traceEventStartup();
      traceCapsetCreate(CAPSET_OSPROCESS_DEFAULT, CapsetTypeOsProcess);
      traceCapsetCreate(CAPSET_CLOCKDOMAIN_DEFAULT, CapsetTypeClockdomain);
      for (i=0; i < n_capabilities; i++) {
          traceCapCreate(cap);
          traceCapsetAssignCap(CAPSET_OSPROCESS_DEFAULT, i);
          traceCapsetAssignCap(CAPSET_CLOCKDOMAIN_DEFAULT, i);
      #if defined(THREADED_RTS)
          traceSparkCounters(cap);
      #endif
      }
      traceWallClockTime();
      traceOSProcessInfo();

To test this you'd want to compare the eventlog in the child with one
you get from a normal startup and see if there's anything odd / missing
etc.

See also ghc-event merge which can merge eventlogs from multiple
processes by aligning to a common wall clock time.

-- 
Duncan Coutts, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/


From eir at cis.upenn.edu  Tue Feb 18 17:35:21 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 18 Feb 2014 12:35:21 -0500
Subject: Build failure of 7.8RC1 on OSX Mountain Lion
In-Reply-To: <CAETJ90QWPfKXhFhXVEvZAqqPoTFHCCFFWW3-rWfsXHugAA5Q=g@mail.gmail.com>
References: <CAETJ90QWPfKXhFhXVEvZAqqPoTFHCCFFWW3-rWfsXHugAA5Q=g@mail.gmail.com>
Message-ID: <47057031-57EB-4712-BBDF-D80A8FEEBCB5@cis.upenn.edu>

Sounds like #8744 (https://ghc.haskell.org/trac/ghc/ticket/8744).

The fix for this has already been merged into the 7.8 branch, but of course, it won't appear in any 7.8RC1 distribution. If you update to the tip of the 7.8 branch, you should hopefully be OK.

Richard

On Feb 18, 2014, at 11:08 AM, Edsko de Vries <edskodevries at gmail.com> wrote:

> Possibly I did something wrong (certainly when I tried to build something very close to RC1 at Austin's request it worked fine), but now I am getting
> 
> In file included from rts/sm/Evac.c:21:0: 
> 
> rts/sm/GCTDecl.h:71:0:
>      error: thread-local storage not supported for this target
> 
> (Host compiler: ghc 7.6.3, no mk/build.mk, standard ./configure --prefix=.., make)
> 
> Any ideas?
> 
> -Edsko
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140218/2998a397/attachment.html>

From jpaugh at gmx.us  Wed Feb 19 11:06:43 2014
From: jpaugh at gmx.us (Jonathan Paugh)
Date: Wed, 19 Feb 2014 06:06:43 -0500
Subject: Idea for improving communication between devs and potential devs
In-Reply-To: <1388791308.69375.YahooMailNeo@web164003.mail.gq1.yahoo.com>
References: <1388782638.65533.YahooMailNeo@web164004.mail.gq1.yahoo.com>
 <87k3eg3dqq.fsf@gmail.com>
 <1388791308.69375.YahooMailNeo@web164003.mail.gq1.yahoo.com>
Message-ID: <53049043.5010909@gmx.us>

Hello. I'm also looking to get more involved with GHC, and Haskell
generally. To that end, nominolo, could you give me a wiki account?
Also, pending this discussion, what permissions would I need to write
blog entries?

https://ghc.haskell.org/trac/ghc/blog

On 01/03/2014 06:21 PM, Howard B. Golden wrote:
> Herbert,
> 
> A revived blog would be great as well, if the Simons and other devs have time to write it. I certainly don't know enough to write it myself, but I can collate what others are talking about and maybe agreeing about on the mailing list. I think what I can produce would work better as wiki entries, rather than a blog, so it can have both a topical and chronological access path, but I am open to the blog approach as well if others will write content too.
> 
> Howard
> 
I would really enjoy reading a description of recent commits -- it'd
give me a fighting chance to understand what's going on. Perhaps with
some concentrated effort and a little time, Howard and I would be able
to write those, since it really comes to down asking the primary devs
the right questions about their work: questions that might even help
them refine the quality a bit, by creating awareness.

However, in the meantime, there's another project Howard and/or I could
embark upon, that's even easier to get started on: Transcribing
everything we learn, to build up a suite of entry-level documentation.

We could write some good, introductory material and post it to the blog.
Both Howard and I have a good perspective of what challenges new comers
may face, so we could definitely make it relevant. Later, it could be
compiled (e.g. a page full of blog links) in the wiki and become the new
dev boot-strap guide.

I have already one good article in mind, "How to get an answer on
ghc-devs". This would consist largely of material from one of January's
threads:
http://www.haskell.org/pipermail/ghc-devs/2014-January/003585.html

<snip>

I'm not exactly sure how much time I can commit to this, but I guess
that's not profoundly unique.

Regards,
Jonathan Paugh


From jpaugh at gmx.us  Wed Feb 19 12:13:14 2014
From: jpaugh at gmx.us (Jonathan Paugh)
Date: Wed, 19 Feb 2014 07:13:14 -0500
Subject: Idea for improving communication between devs and potential devs
In-Reply-To: <1388791308.69375.YahooMailNeo@web164003.mail.gq1.yahoo.com>
References: <1388782638.65533.YahooMailNeo@web164004.mail.gq1.yahoo.com>
 <87k3eg3dqq.fsf@gmail.com>
 <1388791308.69375.YahooMailNeo@web164003.mail.gq1.yahoo.com>
Message-ID: <53049FDA.2070804@gmx.us>

(Apologies for resending this, but my mailer was acting wonky. Also,
apologies for dragging up a fairly old thread.)

Hello. I'm (also) looking to get more involved with GHC, and Haskell
generally. To that end, nominolo, could you give me a wiki account?
Also, pending this discussion, what permissions would I need to write
blog entries?

https://ghc.haskell.org/trac/ghc/blog

On 01/03/2014 06:21 PM, Howard B. Golden wrote:
> Herbert,
> 
> A revived blog would be great as well, if the Simons and other devs have time to write it. I certainly don't know enough to write it myself, but I can collate what others are talking about and maybe agreeing about on the mailing list. I think what I can produce would work better as wiki entries, rather than a blog, so it can have both a topical and chronological access path, but I am open to the blog approach as well if others will write content too.
> 
> Howard
> 
I would really enjoy reading a description of recent commits -- it'd
give me a fighting chance to understand what's going on. Perhaps with
some concentrated effort and a little time, Howard and I would be able
to write those, since it really comes to down asking the primary devs
the right questions about their work: questions that might even help
them refine the quality a bit, by creating awareness.

However, in the meantime, there's another project Howard and/or I could
embark upon, that's even easier to get started on: Transcribing
everything we learn, to build up a suite of entry-level documentation.

We could write some good, introductory material and post it to the blog.
Both Howard and I have a good perspective of what challenges new comers
may face, so we could definitely make it relevant. Later, it could be
compiled (e.g. a page full of blog links) in the wiki and become the new
dev boot-strap guide.

I have already one good article in mind, "How to get an answer on
ghc-devs". This would consist largely of material from one of January's
threads:
http://www.haskell.org/pipermail/ghc-devs/2014-January/003585.html

<snip>

I'm not exactly sure how much time I can commit to this, but I guess
that's not profoundly unique.

Regards,
Jonathan Paugh


From jpaugh at gmx.us  Wed Feb 19 13:25:10 2014
From: jpaugh at gmx.us (Jonathan Paugh)
Date: Wed, 19 Feb 2014 08:25:10 -0500
Subject: workaround to get both domain-specific errors and also multi-modal
 type inference?
In-Reply-To: <52F53C72.5050305@well-typed.com>
References: <CADfHYo436qCHcPsiG+gS2WcSCn8s6ThsavdmQoiTPQv1tEnW_A@mail.gmail.com>
 <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
 <52F53C72.5050305@well-typed.com>
Message-ID: <le2bb7$u7l$1@ger.gmane.org>

On 02/07/2014 03:05 PM, Adam Gundry wrote:
> Hi,
> 
> Good error messages are a hard problem. That said, I think little tweaks
> like this might make sense. Richard Eisenberg and I were discussing this
> earlier, and we wondered if the following might provide an alternative
> approach:
> 
> Suppose a module provides a function
> 
>     describeError :: Constraint -> Maybe String
> 
> (exact type up for discussion). This could be called by the typechecker
> when reporting errors in other modules, to provide a domain-specific
> error message. Do you think this might work for your use case?
> 
> We need to think about how to mark this function as special: one option
> is to provide a built-in typeclass like

Strictly from an API-design point of view, I think having __special__
functions that influence the compiler[0] is a __really__ __bad__ idea.
(Think of __Python__, where even basic language constructs can be
ruthlessly mangled.) How would these special functions behave? Using
type classes *might* make that okay, but what to __avoid__ (IMO) is
having the compiler treat objects/modules/etc differently based on
whether certain values are defined. It leads to in-cohesiveness, and
mal-comprehension.

Would you really want a module/function, etc to behave differently based
on whether some value were in scope when it was defined? Even for
something as benign as error messages? How would you limit the scope of
your changes? Would a type class really cut it, especially with the way
instances are propagated?

This kind of thinking might make more sense if modules were somehow
first-class objects, with a reasonable interface for toying with them
generally. (No comment on whether *that's* a good idea.)

>     class TypeCheckerPlugin a where
>       describeError :: Constraint -> Maybe String
> 
> and look for instances of this class. Interestingly, the class type is
> irrelevant here; we're not interested in solving constraints involving
> this class, just looking at the imported instances when running the
> typechecker. Perhaps using a pragma might be more principled.

I'm not a type-foo master, but wouldn't it be hard to restrict the
effects of a type class-based solution to strictly your own code?
Wouldn't it be easy to have multiple, overlapping instances in various
places? How would we keep from seeing DSL-specific error messages out of
context?

Like I said, I can't talk about this from the perspective of an
implementor, or even a library-designer who might use this feature; I'm
merely a library-user who'd have to deal with it.

[0] I exclude TH, which has a well-defined separation from normal code.
Perhaps one could cook up a good, well-defined API for this, too, but I
have doubts...

Regards,
Jonathan Paugh

> 
> This came up in the context of a more general discussion of plugins to
> extend the typechecker. For example, we might consider doing something
> similar to *solve* constraints in a domain-specific way, as well as
> reporting errors.
> 
> Sound plausible?
> 
> Adam
> 
> 
> On 30/01/14 21:09, Nicolas Frisby wrote:
>> Also, on the topic of patching GHC for domain-specific error messages,
>> why not add a simple means to emit a custom error message? It would beat
>> piggy-backing on the "no instance" messages as I currently plan to.
>>
>> This seems safe and straight-forward:
>>
>>> -- wired-in, cannot be instantiated
>>> class GHC.Exts.PrintError (msg :: Symbol) (args :: [k])
>>
>> Consider the class C fromy previous email. It's possible these two
>> instances are now sufficient.
>>
>>> instance C a b
>>> instance PrintError ("You used %1 on the left and %2 on the right!" ::
>> Symbol) [a,b] => C a b
>>
>> And let's not forget warnings!
>>
>>> -- wired-in, cannot be instantiated
>>> class GHC.Exts.PrintWarn (msg :: Symbol) (args :: '[k])
>>
>> Thanks again.
>>
>>
>> On Thu, Jan 30, 2014 at 3:07 PM, Nicolas Frisby
>> <nicolas.frisby at gmail.com <mailto:nicolas.frisby at gmail.com>> wrote:
>>
>>     Hi all. I have a question for those savvy to the type-checker's
>>     internal workings.
>>
>>     For uses of the following function, can anyone suggest a means of
>>     forcing GHC to attempt to solve C a b even if a~b fails?
>>
>>     > dslAsTypeOf :: (C a b,a~b) => a -> b -> a
>>     > dslAsTypeOf x _ = x
>>     > 
>>     > class C a b -- no methods
>>
>>     Just for concreteness, the following are indicative of the variety
>>     of instances that I expect C to have. (I don't think this actually
>>     affects the question above.)
>>
>>     > instance C DSLType1 DSLType1
>>     > instance C DSLType2 DSLType2
>>     > instance C x y => C (DSLType3 x) (DSLType3 y)
>>     >
>>     > instance IndicativeErrorMessage1 => C DSLType1 DSLType2
>>     > instance IndicativeErrorMessage2 => C DSLType2 (DSLType3 y)
>>     > 
>>     > class IndicativeErrorMessage1 -- will never have instances
>>     > class IndicativeErrorMessage2 -- will never have instances
>>
>>     Thank you for your time.
>>
>>     ===================================
>>
>>     Keep reading for the "short story", the "long story", and two ideas
>>     for a small GHC patch that would enable my technique outlined above.
>>
>>     ===== short story =====
>>
>>     The motivation of dslAsTypeOf is to provide improved error messages
>>     when a and b are not equal.
>>
>>     Unfortunately, the user will never see IndicativeErrorMessage. It
>>     appears that GHC does not attempt to solve C a b if a~b fails.
>>     That's understandable, since the solution of C a b almost certainly
>>     depends on the "value" of its arguments...
>>
>>     Hence, the question at the top of this email.
>>
>>     ===== long story =====
>>
>>     A lot of the modern type-level programming capabilities can be put
>>     to great use in creating type systems for embedded domain specific
>>     languages. These type systems can enforce some impressive properties.
>>
>>     However, the error messages you get when one of those property is
>>     not satisfied can be pretty abysmal.
>>
>>     In my particular case, I have a phantom type where the tag carries
>>     all the domain-specific information.
>>
>>     > newtype U (tag :: [Info]) a = U a
>>
>>     and I have an binary operation that requires the tag to be
>>     equivalent for all three types.
>>
>>     > plus :: Num a => U tag a -> U tag a -> U tag a
>>     > plus (U x) (U y) = U $ x + y
>>
>>     This effectively enforces the property I want for U values.
>>     Unfortunately, the error messages can seem dimwitted.
>>
>>     > ill_typed = plus (U 1 :: U [Foo,Bar,Baz] Int)  (U 2 :: U [Foo,Baz]
>>     Int)
>>
>>     The `ill_typed` value gives an error message (in GHC 7.8) saying
>>
>>       Bar : Baz : []      is not equal to       Baz : []
>>
>>     (It's worse in GHC 7.4. I don't have access to a 7.6 at the moment.)
>>
>>     I'd much rather have it say that "Bar is missing from the first
>>     summand's list." And I can define a class that effectively conveys
>>     that information in a "domain-specific error message" which is
>>     actually a "no instance of <IndicativeClassName> tag1 tag2" message.
>>
>>     > friendlier_plus :: (FriendlyEqCheck tag1 tag2 tag3,Num a) => U
>>     tag1 a -> U tag2 a -> U tag3 a
>>
>>     The `friendlier_plus' function gives useful error messages if tag1,
>>     tag2, and tag3 are all fully monomorphic.
>>
>>     However, it does not support inference:
>>
>>     > zero :: Num a => U tag a
>>     > zero = U 0
>>     > 
>>     > x = U 4 :: U [Foo,Baz] Int
>>     >
>>     > -- both of these are ill-typed :(
>>     > should_work1 = (friendlier_plus zero x) `asTypeOf` x    -- tag1 is
>>     unconstrained
>>     > should_work2 = friendlier_plus x x     -- tag3 is unconstrained
>>
>>     Neither of those terms type-check, since FriendlyEqCheck can't
>>     determine if the unconstrained `tag' variable is equal to the other
>>     tags.
>>
>>     So, can we get the best of both worlds?
>>
>>     > best_plus ::
>>     >   ( FriendlyEqCheck tag1 tag2 tag3
>>          , tag1 ~ tag2, tag2 ~ tag3, Num a) => U tag1 a -> U tag2 a -> U
>>     tag3 a
>>
>>     No, unfortunately not. Now the `should_work*' functions type-check,
>>     but an ill-typed use of `best_plus' gives the same poor error
>>     message that `plus' would give.
>>
>>     Hence, the question at the top of this email.
>>
>>     ===== two ideas =====
>>
>>     If my question at the top of this email cannot be answered in the
>>     affirmative, perhaps a small patch to GHC would make this sort of
>>     approach a viable lightweight workaround for improving
>>     domain-specific error messages.
>>
>>     (I cannot estimate how difficult this would be to implement in the
>>     type-checker.)
>>
>>     Two alternative ideas.
>>
>>     1) An "ALWAYS_ATTEMPT" PRAGMA that you can place on the class C so
>>     that it is attempted even if a related ~ constraint fails.
>>
>>     2) An OrElse constraint former, offering *very* constrained
>>     back-tracking.
>>
>>     > possibleAsTypeOf :: ((a ~ b) `OrElse` C a b) => a -> b -> a
>>     > possibleAsTypeOf x _ = x
>>
>>     Requirements: C must have no superclasses, no methods, and no fundeps.
>>
>>     Specification: If (a~b) fails and (C a b) is satisfiable, then the
>>     original inequality error message would be shown to the user. Else,
>>     C's error message is used.
>>
>>     ===================================
>>
>>     You made it to the bottom of the email! Thanks again.
>>
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
> 
> 



From eir at cis.upenn.edu  Wed Feb 19 15:34:54 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 19 Feb 2014 10:34:54 -0500
Subject: workaround to get both domain-specific errors and also
 multi-modal type inference?
In-Reply-To: <le2bb7$u7l$1@ger.gmane.org>
References: <CADfHYo436qCHcPsiG+gS2WcSCn8s6ThsavdmQoiTPQv1tEnW_A@mail.gmail.com>
 <CADfHYo6FfjCwoSg9KK2v2Ldxi8nw=5Ca1uvKO4nzCegP7pThkw@mail.gmail.com>
 <52F53C72.5050305@well-typed.com> <le2bb7$u7l$1@ger.gmane.org>
Message-ID: <97982879-773B-4786-90BC-DF4D6E6CCD2A@cis.upenn.edu>

Though I favor the approach Adam wrote about (he and I discussed it before his post), I think these are very valid concerns, and would have to be taken into account in the design of any further work in this area.

One observation I would make now is that none of this proposal, as far as I can tell, would change run-time behavior of any program. This proposal concerns only generation of error messages -- correct programs would not notice the feature. Now, you're right to be concerned about the possibility of DSL-specific error messages outside of the DSL! But, my hunch is that it would fairly well-managed, because the DSL-specific messages would be tied to the use of DSL constructs, which would not appear outside of DSL code. That defense is very hand-wavy, and we would want to be more sure that we don't "leak", but I'm not terribly worried about it right now.

I will say that, for better or worse, GHC already has constructs that can affect runtime behavior unexpectedly, particularly {#- RULES #-}.

Richard

On Feb 19, 2014, at 8:25 AM, Jonathan Paugh wrote:

> On 02/07/2014 03:05 PM, Adam Gundry wrote:
>> Hi,
>> 
>> Good error messages are a hard problem. That said, I think little tweaks
>> like this might make sense. Richard Eisenberg and I were discussing this
>> earlier, and we wondered if the following might provide an alternative
>> approach:
>> 
>> Suppose a module provides a function
>> 
>>    describeError :: Constraint -> Maybe String
>> 
>> (exact type up for discussion). This could be called by the typechecker
>> when reporting errors in other modules, to provide a domain-specific
>> error message. Do you think this might work for your use case?
>> 
>> We need to think about how to mark this function as special: one option
>> is to provide a built-in typeclass like
> 
> Strictly from an API-design point of view, I think having __special__
> functions that influence the compiler[0] is a __really__ __bad__ idea.
> (Think of __Python__, where even basic language constructs can be
> ruthlessly mangled.) How would these special functions behave? Using
> type classes *might* make that okay, but what to __avoid__ (IMO) is
> having the compiler treat objects/modules/etc differently based on
> whether certain values are defined. It leads to in-cohesiveness, and
> mal-comprehension.
> 
> Would you really want a module/function, etc to behave differently based
> on whether some value were in scope when it was defined? Even for
> something as benign as error messages? How would you limit the scope of
> your changes? Would a type class really cut it, especially with the way
> instances are propagated?
> 
> This kind of thinking might make more sense if modules were somehow
> first-class objects, with a reasonable interface for toying with them
> generally. (No comment on whether *that's* a good idea.)
> 
>>    class TypeCheckerPlugin a where
>>      describeError :: Constraint -> Maybe String
>> 
>> and look for instances of this class. Interestingly, the class type is
>> irrelevant here; we're not interested in solving constraints involving
>> this class, just looking at the imported instances when running the
>> typechecker. Perhaps using a pragma might be more principled.
> 
> I'm not a type-foo master, but wouldn't it be hard to restrict the
> effects of a type class-based solution to strictly your own code?
> Wouldn't it be easy to have multiple, overlapping instances in various
> places? How would we keep from seeing DSL-specific error messages out of
> context?
> 
> Like I said, I can't talk about this from the perspective of an
> implementor, or even a library-designer who might use this feature; I'm
> merely a library-user who'd have to deal with it.
> 
> [0] I exclude TH, which has a well-defined separation from normal code.
> Perhaps one could cook up a good, well-defined API for this, too, but I
> have doubts...
> 
> Regards,
> Jonathan Paugh
> 
>> 
>> This came up in the context of a more general discussion of plugins to
>> extend the typechecker. For example, we might consider doing something
>> similar to *solve* constraints in a domain-specific way, as well as
>> reporting errors.
>> 
>> Sound plausible?
>> 
>> Adam
>> 
>> 
>> On 30/01/14 21:09, Nicolas Frisby wrote:
>>> Also, on the topic of patching GHC for domain-specific error messages,
>>> why not add a simple means to emit a custom error message? It would beat
>>> piggy-backing on the "no instance" messages as I currently plan to.
>>> 
>>> This seems safe and straight-forward:
>>> 
>>>> -- wired-in, cannot be instantiated
>>>> class GHC.Exts.PrintError (msg :: Symbol) (args :: [k])
>>> 
>>> Consider the class C fromy previous email. It's possible these two
>>> instances are now sufficient.
>>> 
>>>> instance C a b
>>>> instance PrintError ("You used %1 on the left and %2 on the right!" ::
>>> Symbol) [a,b] => C a b
>>> 
>>> And let's not forget warnings!
>>> 
>>>> -- wired-in, cannot be instantiated
>>>> class GHC.Exts.PrintWarn (msg :: Symbol) (args :: '[k])
>>> 
>>> Thanks again.
>>> 
>>> 
>>> On Thu, Jan 30, 2014 at 3:07 PM, Nicolas Frisby
>>> <nicolas.frisby at gmail.com <mailto:nicolas.frisby at gmail.com>> wrote:
>>> 
>>>    Hi all. I have a question for those savvy to the type-checker's
>>>    internal workings.
>>> 
>>>    For uses of the following function, can anyone suggest a means of
>>>    forcing GHC to attempt to solve C a b even if a~b fails?
>>> 
>>>> dslAsTypeOf :: (C a b,a~b) => a -> b -> a
>>>> dslAsTypeOf x _ = x
>>>> 
>>>> class C a b -- no methods
>>> 
>>>    Just for concreteness, the following are indicative of the variety
>>>    of instances that I expect C to have. (I don't think this actually
>>>    affects the question above.)
>>> 
>>>> instance C DSLType1 DSLType1
>>>> instance C DSLType2 DSLType2
>>>> instance C x y => C (DSLType3 x) (DSLType3 y)
>>>> 
>>>> instance IndicativeErrorMessage1 => C DSLType1 DSLType2
>>>> instance IndicativeErrorMessage2 => C DSLType2 (DSLType3 y)
>>>> 
>>>> class IndicativeErrorMessage1 -- will never have instances
>>>> class IndicativeErrorMessage2 -- will never have instances
>>> 
>>>    Thank you for your time.
>>> 
>>>    ===================================
>>> 
>>>    Keep reading for the "short story", the "long story", and two ideas
>>>    for a small GHC patch that would enable my technique outlined above.
>>> 
>>>    ===== short story =====
>>> 
>>>    The motivation of dslAsTypeOf is to provide improved error messages
>>>    when a and b are not equal.
>>> 
>>>    Unfortunately, the user will never see IndicativeErrorMessage. It
>>>    appears that GHC does not attempt to solve C a b if a~b fails.
>>>    That's understandable, since the solution of C a b almost certainly
>>>    depends on the "value" of its arguments...
>>> 
>>>    Hence, the question at the top of this email.
>>> 
>>>    ===== long story =====
>>> 
>>>    A lot of the modern type-level programming capabilities can be put
>>>    to great use in creating type systems for embedded domain specific
>>>    languages. These type systems can enforce some impressive properties.
>>> 
>>>    However, the error messages you get when one of those property is
>>>    not satisfied can be pretty abysmal.
>>> 
>>>    In my particular case, I have a phantom type where the tag carries
>>>    all the domain-specific information.
>>> 
>>>> newtype U (tag :: [Info]) a = U a
>>> 
>>>    and I have an binary operation that requires the tag to be
>>>    equivalent for all three types.
>>> 
>>>> plus :: Num a => U tag a -> U tag a -> U tag a
>>>> plus (U x) (U y) = U $ x + y
>>> 
>>>    This effectively enforces the property I want for U values.
>>>    Unfortunately, the error messages can seem dimwitted.
>>> 
>>>> ill_typed = plus (U 1 :: U [Foo,Bar,Baz] Int)  (U 2 :: U [Foo,Baz]
>>>    Int)
>>> 
>>>    The `ill_typed` value gives an error message (in GHC 7.8) saying
>>> 
>>>      Bar : Baz : []      is not equal to       Baz : []
>>> 
>>>    (It's worse in GHC 7.4. I don't have access to a 7.6 at the moment.)
>>> 
>>>    I'd much rather have it say that "Bar is missing from the first
>>>    summand's list." And I can define a class that effectively conveys
>>>    that information in a "domain-specific error message" which is
>>>    actually a "no instance of <IndicativeClassName> tag1 tag2" message.
>>> 
>>>> friendlier_plus :: (FriendlyEqCheck tag1 tag2 tag3,Num a) => U
>>>    tag1 a -> U tag2 a -> U tag3 a
>>> 
>>>    The `friendlier_plus' function gives useful error messages if tag1,
>>>    tag2, and tag3 are all fully monomorphic.
>>> 
>>>    However, it does not support inference:
>>> 
>>>> zero :: Num a => U tag a
>>>> zero = U 0
>>>> 
>>>> x = U 4 :: U [Foo,Baz] Int
>>>> 
>>>> -- both of these are ill-typed :(
>>>> should_work1 = (friendlier_plus zero x) `asTypeOf` x    -- tag1 is
>>>    unconstrained
>>>> should_work2 = friendlier_plus x x     -- tag3 is unconstrained
>>> 
>>>    Neither of those terms type-check, since FriendlyEqCheck can't
>>>    determine if the unconstrained `tag' variable is equal to the other
>>>    tags.
>>> 
>>>    So, can we get the best of both worlds?
>>> 
>>>> best_plus ::
>>>>  ( FriendlyEqCheck tag1 tag2 tag3
>>>         , tag1 ~ tag2, tag2 ~ tag3, Num a) => U tag1 a -> U tag2 a -> U
>>>    tag3 a
>>> 
>>>    No, unfortunately not. Now the `should_work*' functions type-check,
>>>    but an ill-typed use of `best_plus' gives the same poor error
>>>    message that `plus' would give.
>>> 
>>>    Hence, the question at the top of this email.
>>> 
>>>    ===== two ideas =====
>>> 
>>>    If my question at the top of this email cannot be answered in the
>>>    affirmative, perhaps a small patch to GHC would make this sort of
>>>    approach a viable lightweight workaround for improving
>>>    domain-specific error messages.
>>> 
>>>    (I cannot estimate how difficult this would be to implement in the
>>>    type-checker.)
>>> 
>>>    Two alternative ideas.
>>> 
>>>    1) An "ALWAYS_ATTEMPT" PRAGMA that you can place on the class C so
>>>    that it is attempted even if a related ~ constraint fails.
>>> 
>>>    2) An OrElse constraint former, offering *very* constrained
>>>    back-tracking.
>>> 
>>>> possibleAsTypeOf :: ((a ~ b) `OrElse` C a b) => a -> b -> a
>>>> possibleAsTypeOf x _ = x
>>> 
>>>    Requirements: C must have no superclasses, no methods, and no fundeps.
>>> 
>>>    Specification: If (a~b) fails and (C a b) is satisfiable, then the
>>>    original inequality error message would be shown to the user. Else,
>>>    C's error message is used.
>>> 
>>>    ===================================
>>> 
>>>    You made it to the bottom of the email! Thanks again.
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>> 
>> 
>> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From fuuzetsu at fuuzetsu.co.uk  Thu Feb 20 01:39:45 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Thu, 20 Feb 2014 01:39:45 +0000
Subject: 32-bit Linux perf failures
Message-ID: <53055CE1.5090504@fuuzetsu.co.uk>

Greetings,

I just ran validate with current HEAD
(2b34947b60069e51abfcada9c45a6d7b590f5a2b) and I have quite a few perf
failures. Perhaps these need tweaking? I know that 32-bit numbers were
neglected in the past. The Haddock numbers have been complaining for a
few weeks now but I think everything else is fairly new.

Here is the end of the log:

Unexpected results from:
TEST="T876 T7954 T8766 T1969 T5631 T783 T3294 haddock.Cabal
haddock.compiler haddock.base T3924"

OVERALL SUMMARY for test run started at Thu Feb 20 00:54:28 2014 GMT
 0:18:11 spent to go through
    3903 total tests, which gave rise to
   15265 test cases, of which
   11699 were skipped

      28 had missing libraries
    3469 expected passes
      58 expected failures

       3 caused framework failures
       0 unexpected passes
      11 unexpected failures

Unexpected failures:
   ../../libraries/base/tests  T8766 [stat too good] (normal)
   callarity/perf              T3924 [stat too good] (normal)
   perf/compiler               T1969 [stat too good] (normal)
   perf/compiler               T3294 [stat too good] (normal)
   perf/compiler               T5631 [stat too good] (normal)
   perf/compiler               T783 [stat too good] (normal)
   perf/haddock                haddock.Cabal [stat too good] (normal)
   perf/haddock                haddock.base [stat not good enough] (normal)
   perf/haddock                haddock.compiler [stat too good] (normal)
   perf/should_run             T7954 [stat too good] (normal)
   perf/should_run             T876 [stat too good] (normal)

-- 
Mateusz K.

From karel.gardas at centrum.cz  Thu Feb 20 07:50:36 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Thu, 20 Feb 2014 08:50:36 +0100
Subject: [commit: ghc] master: Update to primitive-0.5.2.1 (47d725f)
In-Reply-To: <20140219222809.8F77B2406B@ghc.haskell.org>
References: <20140219222809.8F77B2406B@ghc.haskell.org>
Message-ID: <5305B3CC.90407@centrum.cz>


Herbert,

thanks for merging this, but this is somehow not working for me. I see 
this patch in ghc repo after ./sync-all pull, but my libraries/primitive 
is still on 5ae8fbb8131ccc934cadd29cc1d17298cfdaef4b commit from 
November 2013

Is there anything special I need to do in order to update git submodules?

Thanks!
Karel

On 02/19/14 11:28 PM, git at git.haskell.org wrote:
> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : master
> Link       : http://ghc.haskell.org/trac/ghc/changeset/47d725f29376fa1be726e913cdf3dd69c46327c2/ghc
>
>> ---------------------------------------------------------------
>
> commit 47d725f29376fa1be726e913cdf3dd69c46327c2
> Author: Herbert Valerio Riedel<hvr at gnu.org>
> Date:   Wed Feb 19 23:26:30 2014 +0100
>
>      Update to primitive-0.5.2.1
>
>      This contains a compile-fix for Solaris
>
>      Signed-off-by: Herbert Valerio Riedel<hvr at gnu.org>
>
>
>> ---------------------------------------------------------------
>
> 47d725f29376fa1be726e913cdf3dd69c46327c2
>   libraries/primitive |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libraries/primitive b/libraries/primitive
> index 5ae8fbb..be63ee1 160000
> --- a/libraries/primitive
> +++ b/libraries/primitive
> @@ -1 +1 @@
> -Subproject commit 5ae8fbb8131ccc934cadd29cc1d17298cfdaef4b
> +Subproject commit be63ee15d961dc1b08bc8853b9ff97708551ef36
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>


From hvriedel at gmail.com  Thu Feb 20 10:00:59 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 20 Feb 2014 11:00:59 +0100
Subject: [commit: ghc] master: Update to primitive-0.5.2.1 (47d725f)
In-Reply-To: <5305B3CC.90407@centrum.cz> (Karel Gardas's message of "Thu, 20
 Feb 2014 08:50:36 +0100")
References: <20140219222809.8F77B2406B@ghc.haskell.org>
 <5305B3CC.90407@centrum.cz>
Message-ID: <87txbuhzms.fsf@gmail.com>

On 2014-02-20 at 08:50:36 +0100, Karel Gardas wrote:
> thanks for merging this, but this is somehow not working for me. I see
> this patch in ghc repo after ./sync-all pull, but my
> libraries/primitive is still on
> 5ae8fbb8131ccc934cadd29cc1d17298cfdaef4b commit from November 2013

because it was reverted by accident; try again now

From mail at joachim-breitner.de  Thu Feb 20 10:40:21 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 20 Feb 2014 11:40:21 +0100
Subject: 32-bit Linux perf failures
In-Reply-To: <53055CE1.5090504@fuuzetsu.co.uk>
References: <53055CE1.5090504@fuuzetsu.co.uk>
Message-ID: <1392892821.2481.6.camel@kirk>

Hi,

Am Donnerstag, den 20.02.2014, 01:39 +0000 schrieb Mateusz Kowalczyk:
> I just ran validate with current HEAD
> (2b34947b60069e51abfcada9c45a6d7b590f5a2b) and I have quite a few perf
> failures. Perhaps these need tweaking? I know that 32-bit numbers were
> neglected in the past. The Haddock numbers have been complaining for a
> few weeks now but I think everything else is fairly new.
> 
> Here is the end of the log:
> 
> Unexpected results from:
> TEST="T876 T7954 T8766 T1969 T5631 T783 T3294 haddock.Cabal
> haddock.compiler haddock.base T3924"

Call arity has improved T1969, T876, T7954, T3294 and T5631 (so the
change for 32bit is expected, just update the numbers to what your
computer says) and T3924 was added by my without 32bit numbers (so add
your numbers, after adding the usual bitness-switch). Also T4267 is
lacking 32-bit numbers.

Generally, you might want to run "git blame" on the all.T-files and see
if there was a recent change to the 64 bit numbers in the same direction
than the change you are observing, and in that case simply update the
numbers accordingly.


Maybe when changing the 64-bit number we should have a way of marking
the i386 as likely out of date, so that the next person on 32bit will
see a message ?Number changed, but that?s expected, so please just
update all.T?.

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140220/4c510b2d/attachment.sig>

From fuuzetsu at fuuzetsu.co.uk  Thu Feb 20 15:26:33 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Thu, 20 Feb 2014 15:26:33 +0000
Subject: 32-bit Linux perf failures
In-Reply-To: <1392892821.2481.6.camel@kirk>
References: <53055CE1.5090504@fuuzetsu.co.uk> <1392892821.2481.6.camel@kirk>
Message-ID: <53061EA9.7010802@fuuzetsu.co.uk>

On 20/02/14 10:40, Joachim Breitner wrote:
> Hi,
> 
> Am Donnerstag, den 20.02.2014, 01:39 +0000 schrieb Mateusz Kowalczyk:
>> I just ran validate with current HEAD
>> (2b34947b60069e51abfcada9c45a6d7b590f5a2b) and I have quite a few perf
>> failures. Perhaps these need tweaking? I know that 32-bit numbers were
>> neglected in the past. The Haddock numbers have been complaining for a
>> few weeks now but I think everything else is fairly new.
>>
>> Here is the end of the log:
>>
>> Unexpected results from:
>> TEST="T876 T7954 T8766 T1969 T5631 T783 T3294 haddock.Cabal
>> haddock.compiler haddock.base T3924"
> 
> Call arity has improved T1969, T876, T7954, T3294 and T5631 (so the
> change for 32bit is expected, just update the numbers to what your
> computer says) and T3924 was added by my without 32bit numbers (so add
> your numbers, after adding the usual bitness-switch). Also T4267 is
> lacking 32-bit numbers.
> 
> Generally, you might want to run "git blame" on the all.T-files and see
> if there was a recent change to the 64 bit numbers in the same direction
> than the change you are observing, and in that case simply update the
> numbers accordingly.
> 
> 
> Maybe when changing the 64-bit number we should have a way of marking
> the i386 as likely out of date, so that the next person on 32bit will
> see a message ?Number changed, but that?s expected, so please just
> update all.T?.
> 
> Greetings,
> Joachim
> 
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

While I technically have the push permissions, I'm not a GHC dev. I feel
like it'd be inappropriate to push in such a ?fix? myself. I can post a
full validate log if that contains information one would need to update
the numbers.

Even if I wanted to, I have no idea how to go about updating the
numbers! Is there a guide of some sort available? I was unable to find
anything.

Thanks

-- 
Mateusz K.

From hvriedel at gmail.com  Thu Feb 20 15:44:47 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 20 Feb 2014 16:44:47 +0100
Subject: 32-bit Linux perf failures
In-Reply-To: <53061EA9.7010802@fuuzetsu.co.uk> (Mateusz Kowalczyk's message of
 "Thu, 20 Feb 2014 15:26:33 +0000")
References: <53055CE1.5090504@fuuzetsu.co.uk> <1392892821.2481.6.camel@kirk>
 <53061EA9.7010802@fuuzetsu.co.uk>
Message-ID: <8738jddc0g.fsf@gmail.com>

On 2014-02-20 at 16:26:33 +0100, Mateusz Kowalczyk wrote:

[...]

> While I technically have the push permissions, I'm not a GHC dev. I feel
> like it'd be inappropriate to push in such a ?fix? myself. I can post a
> full validate log if that contains information one would need to update
> the numbers.

fyi, the relevant information from the validate log are the parts that
looks like:

,----
| =====> T4801(normal) 1527 of 3902 [0, 0, 0] 
| cd ./perf/compiler && '/workspace/GHC/ghc/bindisttest/install   dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T4801.hs   +RTS -V0 -tT4801.comp.stats --machine-readable -RTS -static >T4801.comp.stderr 2>&1
| max_bytes_used value is too high:
|     Expected    max_bytes_used: 22646000 +/-10%
|     Lower bound max_bytes_used: 20381400 
|     Upper bound max_bytes_used: 24910601 
|     Actual      max_bytes_used: 25113136 
| *** unexpected failure for T4801(normal)
`----

> Even if I wanted to, I have no idea how to go about updating the
> numbers! Is there a guide of some sort available? I was unable to find
> anything.

Here's some related information you may have already found yourself
(although it does not explain how to actually update the numbers):

  https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding#Performancetests

The basic idea for updating the numbers though is to find an
explaination for the change, and then update the expected range while
leaving a comment with the previous value, and when it changed, as well
as a note about the reason for the change. You should easily find many
examples of that in the testsuite.

HTH,
 hvr

From austin at well-typed.com  Thu Feb 20 16:04:15 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 20 Feb 2014 10:04:15 -0600
Subject: RC2 release imminent
Message-ID: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>

Hello all,

Just as a quick update, the RC2 release will be soon. I plan on fixing
#8736 and releasing it. #8696 will come shortly with the final
release.

I'll follow up when a source tarball is available, so Pali and Karel
can build binaries.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From pali.gabor at gmail.com  Fri Feb 21 10:49:33 2014
From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=)
Date: Fri, 21 Feb 2014 11:49:33 +0100
Subject: RC2 release imminent
In-Reply-To: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
Message-ID: <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>

2014-02-20 17:04 GMT+01:00 Austin Seipp <austin at well-typed.com>:
> I'll follow up when a source tarball is available, so Pali and Karel
> can build binaries.

Okay.

From ggreif at gmail.com  Fri Feb 21 10:58:42 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Fri, 21 Feb 2014 11:58:42 +0100
Subject: RC2 release imminent
In-Reply-To: <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
Message-ID: <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>

Just for the record :-)

For Hungarian names the order is <lastname> <firstname>,
so one would call him (casually) as G?bor or J?nos (i.e. translated
Gabriel or John)
depending on (his) personal preference.

The funny thing is that Pali (without the accent) is a nickname for
P?l (translated: Paul).
But surely he is never called this way :-)

Keep up the good work, all!

Cheers

    Gabor

On 2/21/14, P?li G?bor J?nos <pali.gabor at gmail.com> wrote:
> 2014-02-20 17:04 GMT+01:00 Austin Seipp <austin at well-typed.com>:
>> I'll follow up when a source tarball is available, so Pali and Karel
>> can build binaries.
>
> Okay.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From pali.gabor at gmail.com  Fri Feb 21 13:03:30 2014
From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=)
Date: Fri, 21 Feb 2014 14:03:30 +0100
Subject: RC2 release imminent
In-Reply-To: <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
Message-ID: <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>

2014-02-21 11:58 GMT+01:00 Gabor Greif <ggreif at gmail.com>:
> The funny thing is that Pali (without the accent) is a nickname for
> P?l (translated: Paul).
> But surely he is never called this way :-)

Well, it does not really matter for me :-)  I am aware I may confuse
non-Hungarians, because I use my name in many different ways, with and
without accents, I do not have a signature in my messages -- so I am
fine whatever I am called until it uniquely determines me.

But yeah, I am Gabor too; but apparently we have a lot of Gabors here
already :-P

From ralph.benzinger at sap.com  Fri Feb 21 16:02:56 2014
From: ralph.benzinger at sap.com (Benzinger, Ralph)
Date: Fri, 21 Feb 2014 16:02:56 +0000
Subject: Runtime error using LLVM bitcode execution
Message-ID: <06032AAF9E11164BB3D2827F725F47985C5C5AB8@DEWDFEMB12B.global.corp.sap>

Hello,

My apologies in advance if this mailing list is not the appropriate
address for posting my problem with the GHC runtime, but it seemed
like the best option on the GHC home page.

I'm trying to execute standalone Haskell functions exported via FFI
and compiled as LLVM bitcode.  Unfortunately, all my efforts yield the
following runtime error:

lu003107:~/hs-bitcode> ./bce_so hsallinone.bc
hs_init complete
hs_add_root complete
hsallinone: internal error: stg_ap_p_ret
    (GHC version 7.6.3 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
0  bce_so               0x0000000000d6b310
1  bce_so               0x0000000000d6b53b
2  bce_so               0x0000000000d6ba1c
3  libpthread.so.0      0x00007f7683298800
4  libc.so.6            0x00007f7682592b35 gsignal + 53
5  libc.so.6            0x00007f7682594111 abort + 385
6  libHSrts-ghc7.6.3.so 0x00007f7683f6ca21 rtsFatalInternalErrorFn + 177
7  libHSrts-ghc7.6.3.so 0x00007f7683f6cce1 barf + 145
8  libHSrts-ghc7.6.3.so 0x00007f7683f8a24a stg_ap_p_info + 130
Stack dump:
0.      Program arguments: ./bce_so hsallinone.bc
Aborted

This is what I do:

I have a function hfun.hs that exports a function

    foreign export ccall hfun :: CInt -> CInt

and a wrapper cmain.c that calls this function:

    #include <HsFFI.h>
    #include "hfun_stub.h"
    extern void __stginit_HFun(void);
    #include <stdio.h>

    int main(int argc, char *argv[])
    {
	hs_init(&argc, &argv);
	printf("hs_init complete\n");

	hs_add_root(__stginit_HFun);
    	printf("hs_add_root complete\n");

    	int i = hfun(42);
    	printf("hfun(42) = %d\n", i);

    	hs_exit();
    	return 0;
    }

To generate a callable bitcode file I use these commands:

    $ ghc -S -keep-llvm-files -keep-tmp-files hfun.hs
    $ llvm-as hfun.ll
    $ cp /tmp/... hfun_stub.c
    $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include hfun_stub.c
    $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include cmain.c
    $ llvm-link cmain.bc hfun_stub.bc hfun.bc -o hsallinone.bc

My main program "bce_so" loads the linked bitcode and feeds it to the
LLVM execution engine.  All required Haskell runtime libraries are
linked dynamically against bce_so.

Could you kindly provide some insight on whether this runtime error is
due to a bug with GHC (unlikely) or rather some negligence in my
setup?  Or does the issue highlight some principal limitation in my
(admittedly somewhat naive) approach of using LLVM -- threading
support, maybe?

Note that compiling hfun.hs/cmain.c into a .so and executing
everything natively using ldload() works flawlessly.

Regards
Ralph

-- 
Pflichtangaben/Mandatory Disclosure Statements:
http://www.sap.com/company/legal/impressum.epx

Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. 

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.


From roma at ro-che.info  Fri Feb 21 16:04:17 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 21 Feb 2014 18:04:17 +0200
Subject: cpphs bug
Message-ID: <20140221160417.GA23721@sniper>

Hi Malcolm,

This appears to be a cpphs bug. For the following code

    #define x (1 == 1)
    #if x
    YES
    #else
    NO
    #endif

cpphs 1.18.1 prints NO, while the expected output (and the output GNU
cpp produces) is YES. If parentheses around 1 == 1 are removed, or if x
is inlined manually, then cpphs correctly prints YES.

This affects GHC 7.8 users in a serious way: GHC 7.8 uses cpphs, and the
above code is a simplified version of macros generated by cabal.

For this reason, for instance, type-eq 0.4.1 cannot be build by GHC 7.8
RC1, despite the proper CPP guards.

Roman

From roma at ro-che.info  Fri Feb 21 16:43:11 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 21 Feb 2014 18:43:11 +0200
Subject: cpphs bug
In-Reply-To: <20140221160417.GA23721@sniper>
References: <20140221160417.GA23721@sniper>
Message-ID: <20140221164311.GA26296@sniper>

Update: that type-eq uses cpphs is its own preference, encoded in its
.cabal file. That means the impact of this bug is lower than I assumed.

Can someone comment on the plans to use cpphs in ghc? I jumped to a
conclusion that this has already happened, but I definitely remember
that it was discussed. What was the conclusion?

* Roman Cheplyaka <roma at ro-che.info> [2014-02-21 18:04:17+0200]
> Hi Malcolm,
> 
> This appears to be a cpphs bug. For the following code
> 
>     #define x (1 == 1)
>     #if x
>     YES
>     #else
>     NO
>     #endif
> 
> cpphs 1.18.1 prints NO, while the expected output (and the output GNU
> cpp produces) is YES. If parentheses around 1 == 1 are removed, or if x
> is inlined manually, then cpphs correctly prints YES.
> 
> This affects GHC 7.8 users in a serious way: GHC 7.8 uses cpphs, and the
> above code is a simplified version of macros generated by cabal.
> 
> For this reason, for instance, type-eq 0.4.1 cannot be build by GHC 7.8
> RC1, despite the proper CPP guards.
> 
> Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140221/2a4039e8/attachment.sig>

From carter.schonwald at gmail.com  Fri Feb 21 17:05:04 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 21 Feb 2014 12:05:04 -0500
Subject: cpphs bug
In-Reply-To: <20140221164311.GA26296@sniper>
References: <20140221160417.GA23721@sniper>
	<20140221164311.GA26296@sniper>
Message-ID: <CAHYVw0xJYN7oz-dqU0PvyoexDfr4TVfye__X6waVRHy2Qbjb_g@mail.gmail.com>

There's actually quite a bit of hacking to make ghc properly support
decoupling the Haskell cpp and c compiler. Nothing has been merged in yet.
 I've some (incomplete) patches with the help of a few other folks, and
Austin might be doing some exploratory also.

The engineering needed to support cpphs is also exactly what's needed to
make the Haskell cpp choice easy to change in the ghc settings files etc

On Friday, February 21, 2014, Roman Cheplyaka <roma at ro-che.info> wrote:

> Update: that type-eq uses cpphs is its own preference, encoded in its
> .cabal file. That means the impact of this bug is lower than I assumed.
>
> Can someone comment on the plans to use cpphs in ghc? I jumped to a
> conclusion that this has already happened, but I definitely remember
> that it was discussed. What was the conclusion?
>
> * Roman Cheplyaka <roma at ro-che.info <javascript:;>> [2014-02-21
> 18:04:17+0200]
> > Hi Malcolm,
> >
> > This appears to be a cpphs bug. For the following code
> >
> >     #define x (1 == 1)
> >     #if x
> >     YES
> >     #else
> >     NO
> >     #endif
> >
> > cpphs 1.18.1 prints NO, while the expected output (and the output GNU
> > cpp produces) is YES. If parentheses around 1 == 1 are removed, or if x
> > is inlined manually, then cpphs correctly prints YES.
> >
> > This affects GHC 7.8 users in a serious way: GHC 7.8 uses cpphs, and the
> > above code is a simplified version of macros generated by cabal.
> >
> > For this reason, for instance, type-eq 0.4.1 cannot be build by GHC 7.8
> > RC1, despite the proper CPP guards.
> >
> > Roman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140221/8689e827/attachment.html>

From malcolm.wallace at me.com  Fri Feb 21 18:37:04 2014
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Fri, 21 Feb 2014 18:37:04 +0000
Subject: cpphs bug
In-Reply-To: <20140221160417.GA23721@sniper>
References: <20140221160417.GA23721@sniper>
Message-ID: <4019A1F4-FE9F-4979-AB1B-3F9E475DF1C8@me.com>


On 21 Feb 2014, at 16:04, Roman Cheplyaka wrote:

> This appears to be a cpphs bug. For the following code
> 
>    #define x (1 == 1)
>    #if x
>    YES
>    #else
>    NO
>    #endif
> 
> cpphs 1.18.1 prints NO, while the expected output (and the output GNU
> cpp produces) is YES.


I acknowledge that this is a bug in cpphs.  It is actually a bit worse than this - the following code also outputs NO with cpphs, when it should clearly be YES:

    #define x   0 == 0
    #if x
    YES
    #else
    NO
    #endif

It is all to do with the recursive expansion of symbols during parsing, where currently we are interpreting the first symbol in the expansion as the intended boolean value, rather than re-parsing the whole expanded expression.  Fixing it will be a little bit more involved than just adding another clause to the parser, but I'm on it.

Regards,
    Malcolm

From karel.gardas at centrum.cz  Sat Feb 22 21:40:39 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sat, 22 Feb 2014 22:40:39 +0100
Subject: SPARC: why it's not registerised anymore?
Message-ID: <53091957.40203@centrum.cz>


Folks,

just out of curiosity I'm building latest GHC on SPARC/Solaris and I've 
noted that current GHCs (7.6 and HEAD) are building unregisterised by 
default. In the history I remember at least some GHC were registerised 
and GHC source code also (still) contains SPARC NCG so I'm curious what 
was the reason behind the switch? Any bug still waiting for a fix? Or 
just code rotted in a way it's not working any more?

Thanks!
Karel

From fuuzetsu at fuuzetsu.co.uk  Sat Feb 22 23:46:02 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sat, 22 Feb 2014 23:46:02 +0000
Subject: Change in rendering of [] in GADTs
Message-ID: <530936BA.7050807@fuuzetsu.co.uk>

While running Haddock tests today, we noticed that the output for a test
with GADTs changed. See the test file in the bottom.

We used to render ?Nil :: Pattern '[]? as ?Pattern []? but it now
renders as ?Pattern `[]`?. The change happened within last 2 days and
I'm guessing it's d3af9807ca8a1db0bc9298ea50895ee9df55edb7 that made the
change.

Should this be something that we fix on Haddock end or should it be left
with the new rendering? I'm unsure whether the previous rendering wasn't
better or not.

The Haddock test suite is not ran as part of GHC validate process so it
the failure slipped by.

The file is:
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE TypeOperators #-}
module AdvanceTypes where

data Pattern :: [*] -> * where
  Nil :: Pattern '[]
  Cons :: Maybe h -> Pattern t -> Pattern (h ': t)

-- 
Mateusz K.

From malcolm.wallace at me.com  Mon Feb 24 09:16:03 2014
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Mon, 24 Feb 2014 09:16:03 +0000
Subject: cpphs bug
In-Reply-To: <4019A1F4-FE9F-4979-AB1B-3F9E475DF1C8@me.com>
References: <20140221160417.GA23721@sniper>
 <4019A1F4-FE9F-4979-AB1B-3F9E475DF1C8@me.com>
Message-ID: <4422F2D7-A087-4286-86E6-4281FF431444@me.com>


>> This appears to be a cpphs bug. For the following code
>> 
>>   #define x (1 == 1)
>>   #if x
>>   YES
>>   #else
>>   NO
>>   #endif
>> 
>> cpphs 1.18.1 prints NO, while the expected output (and the output GNU
>> cpp produces) is YES.
> 
> 
> I acknowledge that this is a bug in cpphs

OK, bug now fixed in version 1.18.2.

Regards,
    Malcolm

From Christian.Maeder at dfki.de  Mon Feb 24 09:49:56 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Mon, 24 Feb 2014 10:49:56 +0100
Subject: SPARC: why it's not registerised anymore?
In-Reply-To: <53091957.40203@centrum.cz>
References: <53091957.40203@centrum.cz>
Message-ID: <530B15C4.6030702@dfki.de>

Hi Karel,

the last version of a registered build (that I know about and worked for 
me) is ghc-7.0.4 (see below). I was not able (or gave up) to build 
ghc-7.2 on sparc.

https://ghc.haskell.org/trac/ghc/ticket/7106#comment:3 for ghc-7.4
says that "Sparc is unregisterised now that the registerised C backend 
has been removed".

Cheers Christian

-bash-3.2$ /home/pub-bkb/ghc/ghc-7.0.4/bin/ghc --info
  [("Project name","The Glorious Glasgow Haskell Compilation System")
  ,("Project version","7.0.4")
  ,("Booter version","7.0.2")
  ,("Stage","2")
  ,("Build platform","sparc-sun-solaris2")
  ,("Host platform","sparc-sun-solaris2")
  ,("Target platform","sparc-sun-solaris2")
  ,("Have interpreter","YES")
  ,("Object splitting","YES")
  ,("Have native code generator","YES")
  ,("Have llvm code generator","YES")
  ,("Support SMP","YES")
  ,("Unregisterised","NO")
  ,("Tables next to code","YES")
  ,("RTS ways","l debug  thr thr_debug thr_l thr_p ")
  ,("Leading underscore","NO")
  ,("Debug on","False")
  ,("LibDir","/home/pub-bkb/ghc/ghc-7.0.4/lib/ghc-7.0.4")
  ,("Global Package 
DB","/home/pub-bkb/ghc/ghc-7.0.4/lib/ghc-7.0.4/package.conf.d")
  ,("C compiler flags","[\"-fno-stack-protector\"]")
  ,("Gcc Linker flags","[]")
  ,("Ld Linker flags","[]")
  ]

Am 22.02.2014 22:40, schrieb Karel Gardas:
>
> Folks,
>
> just out of curiosity I'm building latest GHC on SPARC/Solaris and I've
> noted that current GHCs (7.6 and HEAD) are building unregisterised by
> default. In the history I remember at least some GHC were registerised
> and GHC source code also (still) contains SPARC NCG so I'm curious what
> was the reason behind the switch? Any bug still waiting for a fix? Or
> just code rotted in a way it's not working any more?
>
> Thanks!
> Karel
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>


From carter.schonwald at gmail.com  Tue Feb 25 04:28:13 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 24 Feb 2014 23:28:13 -0500
Subject: would support for kind equalities enable the following example?
Message-ID: <CAHYVw0ysL32MAZAfP3yvLRo95hGn5cMkLzLz-wALJ0vdRMCrNw@mail.gmail.com>

Hey all,

I've a use case in my code where It looks like it might be an example of
something that won't compile until we have type level GADTs

I'm essentially writing a vector api that
allows certain args to be mutable, pure or "dont care". (dont care = that
they're treated as being immutable). I'm using GADTs to model this. (using
GADTs rather than type classes partly because I want to make sure type
inference works out nicely, and partly to see how far i can go while not
adding any new type classes)

data Eff :: * -> * where
    Pure :: Eff ()
    Mut :: s -> Eff s

data EVector  :: * -> * -> * where
    PureVector :: S.Vector el  -> EVector Pure el
    MutVector :: SM.MVector s el -> EVector (Mut s) el

the above doesn't work because DataKinds only works at kind * currently,
however i can defunctionalize it to the following (while making it a tad
less pretty)
and it then works

data Eff = Pure | Mut

data EVector  :: Eff -> * -> * -> * where
    PureVector :: S.Vector el  -> EVector Pure () el
    MutVector :: SM.MVector s el -> EVector Mut s  el


am i correct in thinking that the first example *should* be possible once
we have fancier kind machinery (kind equalities and type level GADTs?)? I
suspect I'll be hitting *A LOT* more examples like the above, and if theres
any ways I can help push this along on the research or engineering side, I
please tell me :)

thanks!
-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140224/72ea4d16/attachment.html>

From carter.schonwald at gmail.com  Tue Feb 25 05:11:32 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 25 Feb 2014 00:11:32 -0500
Subject: would support for kind equalities enable the following example?
In-Reply-To: <CAHYVw0ysL32MAZAfP3yvLRo95hGn5cMkLzLz-wALJ0vdRMCrNw@mail.gmail.com>
References: <CAHYVw0ysL32MAZAfP3yvLRo95hGn5cMkLzLz-wALJ0vdRMCrNw@mail.gmail.com>
Message-ID: <CAHYVw0xWv3quOK0++f+KoQUJUPPDucBXSM-Cmbgh7XKcyD44Nw@mail.gmail.com>

also Ive not been able to find any tickets on Trac for "heres some
motiviating example for higher kinded data kinds", happy to great a feature
request ticket motivated by this code if there sin't one :)


On Mon, Feb 24, 2014 at 11:28 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Hey all,
>
> I've a use case in my code where It looks like it might be an example of
> something that won't compile until we have type level GADTs
>
> I'm essentially writing a vector api that
> allows certain args to be mutable, pure or "dont care". (dont care = that
> they're treated as being immutable). I'm using GADTs to model this. (using
> GADTs rather than type classes partly because I want to make sure type
> inference works out nicely, and partly to see how far i can go while not
> adding any new type classes)
>
> data Eff :: * -> * where
>     Pure :: Eff ()
>     Mut :: s -> Eff s
>
> data EVector  :: * -> * -> * where
>     PureVector :: S.Vector el  -> EVector Pure el
>     MutVector :: SM.MVector s el -> EVector (Mut s) el
>
> the above doesn't work because DataKinds only works at kind * currently,
> however i can defunctionalize it to the following (while making it a tad
> less pretty)
> and it then works
>
> data Eff = Pure | Mut
>
> data EVector  :: Eff -> * -> * -> * where
>     PureVector :: S.Vector el  -> EVector Pure () el
>     MutVector :: SM.MVector s el -> EVector Mut s  el
>
>
> am i correct in thinking that the first example *should* be possible once
> we have fancier kind machinery (kind equalities and type level GADTs?)? I
> suspect I'll be hitting *A LOT* more examples like the above, and if theres
> any ways I can help push this along on the research or engineering side, I
> please tell me :)
>
> thanks!
> -Carter
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140225/63ea519b/attachment.html>

From eir at cis.upenn.edu  Tue Feb 25 11:50:11 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 25 Feb 2014 06:50:11 -0500
Subject: would support for kind equalities enable the following example?
In-Reply-To: <CAHYVw0ysL32MAZAfP3yvLRo95hGn5cMkLzLz-wALJ0vdRMCrNw@mail.gmail.com>
References: <CAHYVw0ysL32MAZAfP3yvLRo95hGn5cMkLzLz-wALJ0vdRMCrNw@mail.gmail.com>
Message-ID: <CF3E4429-874F-4F3D-BD05-5C4650E254DB@cis.upenn.edu>

My question is: why do you want Eff to be a GADT? It's true that GADTs do not promote (currently), which is why your first example doesn't work. (It's not to do with kinds, exactly, but GADTs.) But, I don't quite see a reason for having a GADT there -- generally, when a GADT is really useful, no amount of defunctionalization will be a substitute.

GHC ticket #7961 is a place to make noise about this. My (with co-authors Stephanie Weirich and Justin Hsu) ICFP paper from last year ("System FC with Explicit Kind Equality") is part of the solution, and I was planning on submitting the other part of the solution (type inference!) for ICFP this year. Alas, that won't happen, but I believe I should be able to pull it together for the POPL deadline (July). So, there's somewhat slow but somewhat steady work in this direction, and I'm confident something will make its way into GHC before too long.

Richard

On Feb 24, 2014, at 11:28 PM, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> Hey all, 
> 
> I've a use case in my code where It looks like it might be an example of something that won't compile until we have type level GADTs
> 
> I'm essentially writing a vector api that 
> allows certain args to be mutable, pure or "dont care". (dont care = that they're treated as being immutable). I'm using GADTs to model this. (using GADTs rather than type classes partly because I want to make sure type inference works out nicely, and partly to see how far i can go while not adding any new type classes)
> 
> data Eff :: * -> * where
>     Pure :: Eff () 
>     Mut :: s -> Eff s 
>  
> data EVector  :: * -> * -> * where 
>     PureVector :: S.Vector el  -> EVector Pure el 
>     MutVector :: SM.MVector s el -> EVector (Mut s) el  
> 
> the above doesn't work because DataKinds only works at kind * currently,
> however i can defunctionalize it to the following (while making it a tad less pretty)
> and it then works
> 
> data Eff = Pure | Mut 
> 
> data EVector  :: Eff -> * -> * -> * where 
>     PureVector :: S.Vector el  -> EVector Pure () el 
>     MutVector :: SM.MVector s el -> EVector Mut s  el   
> 
> 
> am i correct in thinking that the first example *should* be possible once we have fancier kind machinery (kind equalities and type level GADTs?)? I suspect I'll be hitting *A LOT* more examples like the above, and if theres any ways I can help push this along on the research or engineering side, I please tell me :) 
> 
> thanks!
> -Carter
> 
> 


From simonpj at microsoft.com  Tue Feb 25 16:18:32 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 25 Feb 2014 16:18:32 +0000
Subject: OverloadedRecordFields
In-Reply-To: <530B04C1.1050408@well-typed.com>
References: <52D9029C.7030500@well-typed.com>
 <59543203684B2244980D7E4057D5FBC1487194AB@DB3EX14MBXC306.europe.corp.microsoft.com>
 <530B04C1.1050408@well-typed.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1487B8AB5@DB3EX14MBXC312.europe.corp.microsoft.com>

Adam

I'm very happy to hear that... good stuff.

I'm under water with ICFP submissions (deadline Sat).  Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day.

So I suggest we plan to merge after 7.8 is out.  

Are the wiki pages up to date? 
Records/OverloadedRecordFields
Records/OverloadedRecordFields/Implementation
Records/OverloadedRecordFields/Plan

The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense

Simon
	
| -----Original Message-----
| From: Adam Gundry [mailto:adam at well-typed.com]
| Sent: 24 February 2014 08:37
| To: Simon Peyton Jones
| Subject: Re: OverloadedRecordFields
| 
| Hi Simon,
| 
| My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of
| last Saturday. Validate on linux x86_64 reports only one failure, the
| haddock.Cabal perf test, which might well be due to my Haddock changes,
| and I will investigate. I'm not sure how to run the Haddock test suite?
| 
| I am keen to get the code reviewed and into HEAD as soon as is
| convenient, but I'm aware these are substantial changes, and don't want
| to rush things. In particular, I would understand if you'd rather hold
| them back until after the 7.8 final release.
| 
| How would you like to proceed?
| 
| Adam
| 
| [1] https://github.com/adamgundry/ghc
| [2] https://github.com/adamgundry/packages-base
| [3] https://github.com/adamgundry/haddock
| 
| 
| On 17/01/14 10:55, Simon Peyton Jones wrote:
| > Yes that sounds ok, thanks.  I'd prefer to have a write-up of what
| goes wrong with the 2-parameter story, so that we don't forget.
| >
| > Simon
| >
| > | -----Original Message-----
| > | From: Adam Gundry [mailto:adam at well-typed.com]
| > | Sent: 17 January 2014 10:15
| > | To: Simon Peyton Jones
| > | Subject: OverloadedRecordFields
| > |
| > | Hi Simon,
| > |
| > | I'm conscious that things have gone off the boil a little wrt
| > | OverloadedRecordFields, partially as a consequence of the delayed
| > | 7.8 release but also my lack of time for other projects since
| > | starting work for Well-Typed. With that in mind, I'd like to propose
| > | a plan to get back on track:
| > |
| > | 1. Revert to the three-parameter story, where we have
| > |
| > |     t ~ FldTy r f => Has r f t
| > |
| > | rather than
| > |
| > |     Has r f.
| > |
| > | The two-parameter version generates significantly worse error
| > | messages, and there are some other unresolved problems, so I'm not
| > | sure it is worth the minor simplification.
| > |
| > | 2. Roll back some of the refactoring that I've struggled to get
| > | right (in particular, trying to make the generated FldTy/UpdTy
| > | axioms implicitTyThings). We can always revisit this in the future
| though.
| > |
| > | 3. Merge HEAD into my branch: I suspect this will be a bit painful
| > | by now, but presumably with 7.8 imminent there won't be many major
| > | changes coming for a while?
| > |
| > | 4. Review the proposed changes with you and fix any show-stopping
| > | problems.
| > |
| > | 5. Merge into HEAD after 7.8 is released.
| > |
| > | Does this sound plausible? I'm happy to Skype if you like.
| > |
| > | Cheers,
| > |
| > | Adam
| > |
| > | P.S. I'm not sure if Andrew Kennedy has mentioned it to you, but
| > | Neil Ghani has got me some funding to work with them both on units
| > | of measure for Haskell. We are still sorting out the details, but I
| > | hope it might be possible to work on some kind of plugin mechanism
| > | for GHC's constraint solver, along the lines that Iavor has been
| > | investigating, if that would be of interest?
| > |
| > | --
| > | Adam Gundry, Haskell Consultant
| > | Well-Typed LLP, http://www.well-typed.com/
| >
| 
| 
| --
| Adam Gundry, Haskell Consultant
| Well-Typed LLP, http://www.well-typed.com/

From adam at well-typed.com  Tue Feb 25 17:42:03 2014
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 25 Feb 2014 17:42:03 +0000
Subject: OverloadedRecordFields
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487B8AB5@DB3EX14MBXC312.europe.corp.microsoft.com>
References: <52D9029C.7030500@well-typed.com>
 <59543203684B2244980D7E4057D5FBC1487194AB@DB3EX14MBXC306.europe.corp.microsoft.com>
 <530B04C1.1050408@well-typed.com>
 <59543203684B2244980D7E4057D5FBC1487B8AB5@DB3EX14MBXC312.europe.corp.microsoft.com>
Message-ID: <530CD5EB.5010807@well-typed.com>

Simon,

On 25/02/14 16:18, Simon Peyton Jones wrote:
> I'm very happy to hear that... good stuff.
> 
> I'm under water with ICFP submissions (deadline Sat).  Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day.
> 
> So I suggest we plan to merge after 7.8 is out.  

Right. I wasn't suggesting to put OverloadedRecordFields in 7.8, just
the 7.9 master branch! But given the potential need to backport fixes
from master to the 7.8 branch, I think it makes sense to wait.


> Are the wiki pages up to date? 
> Records/OverloadedRecordFields
> Records/OverloadedRecordFields/Implementation
> Records/OverloadedRecordFields/Plan
> 
> The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense

They are up to date but I'll go over them and tidy them up. Alas, it
doesn't look like Trac supports redirects...

Adam


> | -----Original Message-----
> | From: Adam Gundry [mailto:adam at well-typed.com]
> | Sent: 24 February 2014 08:37
> | To: Simon Peyton Jones
> | Subject: Re: OverloadedRecordFields
> | 
> | Hi Simon,
> | 
> | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of
> | last Saturday. Validate on linux x86_64 reports only one failure, the
> | haddock.Cabal perf test, which might well be due to my Haddock changes,
> | and I will investigate. I'm not sure how to run the Haddock test suite?
> | 
> | I am keen to get the code reviewed and into HEAD as soon as is
> | convenient, but I'm aware these are substantial changes, and don't want
> | to rush things. In particular, I would understand if you'd rather hold
> | them back until after the 7.8 final release.
> | 
> | How would you like to proceed?
> | 
> | Adam
> | 
> | [1] https://github.com/adamgundry/ghc
> | [2] https://github.com/adamgundry/packages-base
> | [3] https://github.com/adamgundry/haddock
> | 
> | 
> | On 17/01/14 10:55, Simon Peyton Jones wrote:
> | > Yes that sounds ok, thanks.  I'd prefer to have a write-up of what
> | goes wrong with the 2-parameter story, so that we don't forget.
> | >
> | > Simon
> | >
> | > | -----Original Message-----
> | > | From: Adam Gundry [mailto:adam at well-typed.com]
> | > | Sent: 17 January 2014 10:15
> | > | To: Simon Peyton Jones
> | > | Subject: OverloadedRecordFields
> | > |
> | > | Hi Simon,
> | > |
> | > | I'm conscious that things have gone off the boil a little wrt
> | > | OverloadedRecordFields, partially as a consequence of the delayed
> | > | 7.8 release but also my lack of time for other projects since
> | > | starting work for Well-Typed. With that in mind, I'd like to propose
> | > | a plan to get back on track:
> | > |
> | > | 1. Revert to the three-parameter story, where we have
> | > |
> | > |     t ~ FldTy r f => Has r f t
> | > |
> | > | rather than
> | > |
> | > |     Has r f.
> | > |
> | > | The two-parameter version generates significantly worse error
> | > | messages, and there are some other unresolved problems, so I'm not
> | > | sure it is worth the minor simplification.
> | > |
> | > | 2. Roll back some of the refactoring that I've struggled to get
> | > | right (in particular, trying to make the generated FldTy/UpdTy
> | > | axioms implicitTyThings). We can always revisit this in the future
> | though.
> | > |
> | > | 3. Merge HEAD into my branch: I suspect this will be a bit painful
> | > | by now, but presumably with 7.8 imminent there won't be many major
> | > | changes coming for a while?
> | > |
> | > | 4. Review the proposed changes with you and fix any show-stopping
> | > | problems.
> | > |
> | > | 5. Merge into HEAD after 7.8 is released.
> | > |
> | > | Does this sound plausible? I'm happy to Skype if you like.
> | > |
> | > | Cheers,
> | > |
> | > | Adam

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From fuuzetsu at fuuzetsu.co.uk  Tue Feb 25 17:52:15 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Tue, 25 Feb 2014 17:52:15 +0000
Subject: OverloadedRecordFields
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487B8AB5@DB3EX14MBXC312.europe.corp.microsoft.com>
References: <52D9029C.7030500@well-typed.com>
 <59543203684B2244980D7E4057D5FBC1487194AB@DB3EX14MBXC306.europe.corp.microsoft.com>
 <530B04C1.1050408@well-typed.com>
 <59543203684B2244980D7E4057D5FBC1487B8AB5@DB3EX14MBXC312.europe.corp.microsoft.com>
Message-ID: <530CD84F.3010005@fuuzetsu.co.uk>

On 25/02/14 16:18, Simon Peyton Jones wrote:
> Adam
> 
> I'm very happy to hear that... good stuff.
> 
> I'm under water with ICFP submissions (deadline Sat).  Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day.
> 
> So I suggest we plan to merge after 7.8 is out.  
> 
> Are the wiki pages up to date? 
> Records/OverloadedRecordFields
> Records/OverloadedRecordFields/Implementation
> Records/OverloadedRecordFields/Plan
> 
> The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense
> 
> Simon
> 	
> | -----Original Message-----
> | From: Adam Gundry [mailto:adam at well-typed.com]
> | Sent: 24 February 2014 08:37
> | To: Simon Peyton Jones
> | Subject: Re: OverloadedRecordFields
> | 
> | Hi Simon,
> | 
> | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of
> | last Saturday. Validate on linux x86_64 reports only one failure, the
> | haddock.Cabal perf test, which might well be due to my Haddock changes,
> | and I will investigate. I'm not sure how to run the Haddock test suite?

Hi Adam,

I'm seeing that perf failure even without any of your changes. Perhaps
you could try validating without your changes to confirm that the perf
failure happens anyway?

There are two Haddock test-suites of interest: tests ran by GHC to make
sure that appropriate files parse (I updated these just yesterday so
please make sure you're up to date) and Haddock's own test-suite to make
sure that the output we produce is correct. To run Haddock's own tests,
you can use ?cabal test?. You'll need QuickCheck and hspec for this.
Alternatively, to only run the tests ensuring our XHtml output is as
expected, you can run ?cabal test html-test?. This skips the comment
parser tests (which shouldn't be relevant to you) but also doesn't force
you to install the test dependencies I mentioned.

I haven't checked your branch yet but I ask that you add appropriate
test cases in html-test. See the README in the directory for help. You
might want to check the accept.lhs file to help you doing this.

Lastly, note that we have been pushed something into Haddock every day
since Saturday so make sure you're up to date. I'll also be pushing
something today I think.

Thanks


> | 
> | I am keen to get the code reviewed and into HEAD as soon as is
> | convenient, but I'm aware these are substantial changes, and don't want
> | to rush things. In particular, I would understand if you'd rather hold
> | them back until after the 7.8 final release.
> | 
> | How would you like to proceed?
> | 
> | Adam
> | 
> | [1] https://github.com/adamgundry/ghc
> | [2] https://github.com/adamgundry/packages-base
> | [3] https://github.com/adamgundry/haddock
> | 
> | 
> | On 17/01/14 10:55, Simon Peyton Jones wrote:
> | > Yes that sounds ok, thanks.  I'd prefer to have a write-up of what
> | goes wrong with the 2-parameter story, so that we don't forget.
> | >
> | > Simon
> | >
> | > | -----Original Message-----
> | > | From: Adam Gundry [mailto:adam at well-typed.com]
> | > | Sent: 17 January 2014 10:15
> | > | To: Simon Peyton Jones
> | > | Subject: OverloadedRecordFields
> | > |
> | > | Hi Simon,
> | > |
> | > | I'm conscious that things have gone off the boil a little wrt
> | > | OverloadedRecordFields, partially as a consequence of the delayed
> | > | 7.8 release but also my lack of time for other projects since
> | > | starting work for Well-Typed. With that in mind, I'd like to propose
> | > | a plan to get back on track:
> | > |
> | > | 1. Revert to the three-parameter story, where we have
> | > |
> | > |     t ~ FldTy r f => Has r f t
> | > |
> | > | rather than
> | > |
> | > |     Has r f.
> | > |
> | > | The two-parameter version generates significantly worse error
> | > | messages, and there are some other unresolved problems, so I'm not
> | > | sure it is worth the minor simplification.
> | > |
> | > | 2. Roll back some of the refactoring that I've struggled to get
> | > | right (in particular, trying to make the generated FldTy/UpdTy
> | > | axioms implicitTyThings). We can always revisit this in the future
> | though.
> | > |
> | > | 3. Merge HEAD into my branch: I suspect this will be a bit painful
> | > | by now, but presumably with 7.8 imminent there won't be many major
> | > | changes coming for a while?
> | > |
> | > | 4. Review the proposed changes with you and fix any show-stopping
> | > | problems.
> | > |
> | > | 5. Merge into HEAD after 7.8 is released.
> | > |
> | > | Does this sound plausible? I'm happy to Skype if you like.
> | > |
> | > | Cheers,
> | > |
> | > | Adam
> | > |
> | > | P.S. I'm not sure if Andrew Kennedy has mentioned it to you, but
> | > | Neil Ghani has got me some funding to work with them both on units
> | > | of measure for Haskell. We are still sorting out the details, but I
> | > | hope it might be possible to work on some kind of plugin mechanism
> | > | for GHC's constraint solver, along the lines that Iavor has been
> | > | investigating, if that would be of interest?
> | > |
> | > | --
> | > | Adam Gundry, Haskell Consultant
> | > | Well-Typed LLP, http://www.well-typed.com/
> | >
> | 
> | 
> | --
> | Adam Gundry, Haskell Consultant
> | Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


-- 
Mateusz K.

From hvriedel at gmail.com  Tue Feb 25 18:48:00 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 25 Feb 2014 19:48:00 +0100
Subject: OverloadedRecordFields
In-Reply-To: <530CD5EB.5010807@well-typed.com> (Adam Gundry's message of "Tue, 
 25 Feb 2014 17:42:03 +0000")
References: <52D9029C.7030500@well-typed.com>
 <59543203684B2244980D7E4057D5FBC1487194AB@DB3EX14MBXC306.europe.corp.microsoft.com>
 <530B04C1.1050408@well-typed.com>
 <59543203684B2244980D7E4057D5FBC1487B8AB5@DB3EX14MBXC312.europe.corp.microsoft.com>
 <530CD5EB.5010807@well-typed.com>
Message-ID: <87txbnrpun.fsf@gmail.com>

On 2014-02-25 at 18:42:03 +0100, Adam Gundry wrote:

[...]

> They are up to date but I'll go over them and tidy them up. Alas, it
> doesn't look like Trac supports redirects...

actually, it does, but the plugin was just missing; see

 https://ghc.haskell.org/trac/ghc/wiki/WikiMacros#Description

for more details

From gergo at erdi.hu  Wed Feb 26 03:19:01 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Wed, 26 Feb 2014 11:19:01 +0800 (SGT)
Subject: Pretty-printing of type variables (Help needed for #8776)
Message-ID: <alpine.DEB.2.10.1402261108010.4118@galaxy>

Hi,

Ticket #8776 (https://ghc.haskell.org/trac/ghc/ticket/8776) is about the 
output formatting of pattern synonym type signatures. With -dppr-debug, 
the problematic signature looks like this:

(base:GHC.Num.Num{tc 2b} t{tv aQa} [sk],
  ghc-prim:GHC.Classes.Eq{tc 23} t{tv aQb} [sk]) =>
main:Main.P{d rs2} :: main:Main.A{tc rpC} t{tv aQa} [sk] t1{tv aQb} [sk]

The problem is that the two type variables occuring in the provided 
context both have "t" as their user-visible name; even though the second 
one is projected as "t1" in the tau type on the right-hand side.

The code to generate this output is in HsBinds.ppr_sig, using pprPatSynSig 
which just adds the "pattern" keyword and the separating "=>" symbols etc:

ppr_sig (PatSynSig name arg_tys ty prov req)
   = pprPatSynSig (unLoc name) False args (ppr ty) (pprCtx prov) (pprCtx req)
   where
     args = fmap ppr arg_tys

     pprCtx lctx = case unLoc lctx of
         [] -> Nothing
         ctx -> Just (pprHsContextNoArrow ctx)


My guess is that the problem is 'pprHsContextNoArrow' projects individual 
constraints one-by-one and so doesn't notice the name clash on 
't' between the two constraints in the example; whereas 'ppr ty' walks the 
whole right-hand tau type and thus has the opportunity to maintain a set 
of type variable names used.

My question is, where is that logic, and how can I use that in this 
instance? My hope is to be shown a design where I can run 'ppr ty', 
'pprCtx prov' and 'pprCtx req' in the same "naming environment" (I hope 
such a thing exists) so that they use a consistent naming scheme. This 
looks like a problem that must have popped up at a lot of places in GHC 
already and must have an idiomatic solution.

Thanks,
 	Gergo

From carter.schonwald at gmail.com  Wed Feb 26 03:23:11 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 25 Feb 2014 22:23:11 -0500
Subject: would support for kind equalities enable the following example?
In-Reply-To: <CF3E4429-874F-4F3D-BD05-5C4650E254DB@cis.upenn.edu>
References: <CAHYVw0ysL32MAZAfP3yvLRo95hGn5cMkLzLz-wALJ0vdRMCrNw@mail.gmail.com>
 <CF3E4429-874F-4F3D-BD05-5C4650E254DB@cis.upenn.edu>
Message-ID: <CAHYVw0wfzONCFxP0CtZTAN5rXDhXTyCrj8-_UB__zgObLZXTuw@mail.gmail.com>

IN this case i *DO* want the GADT. (but i can't express it)

The reason is simple: one type parameter makes for a less complex API to
educate others about than 2 type parameters. And likewise for 3 vs 4. Etc
etc. Its a human factors thing :)

I do agree in this case that my "defunctionalized" type is equivalent in
type safety, and i'm happy to use it for now.




On Tue, Feb 25, 2014 at 6:50 AM, Richard Eisenberg <eir at cis.upenn.edu>wrote:

> My question is: why do you want Eff to be a GADT? It's true that GADTs do
> not promote (currently), which is why your first example doesn't work.
> (It's not to do with kinds, exactly, but GADTs.) But, I don't quite see a
> reason for having a GADT there -- generally, when a GADT is really useful,
> no amount of defunctionalization will be a substitute.
>
> GHC ticket #7961 is a place to make noise about this. My (with co-authors
> Stephanie Weirich and Justin Hsu) ICFP paper from last year ("System FC
> with Explicit Kind Equality") is part of the solution, and I was planning
> on submitting the other part of the solution (type inference!) for ICFP
> this year. Alas, that won't happen, but I believe I should be able to pull
> it together for the POPL deadline (July). So, there's somewhat slow but
> somewhat steady work in this direction, and I'm confident something will
> make its way into GHC before too long.
>
> Richard
>
> On Feb 24, 2014, at 11:28 PM, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> > Hey all,
> >
> > I've a use case in my code where It looks like it might be an example of
> something that won't compile until we have type level GADTs
> >
> > I'm essentially writing a vector api that
> > allows certain args to be mutable, pure or "dont care". (dont care =
> that they're treated as being immutable). I'm using GADTs to model this.
> (using GADTs rather than type classes partly because I want to make sure
> type inference works out nicely, and partly to see how far i can go while
> not adding any new type classes)
> >
> > data Eff :: * -> * where
> >     Pure :: Eff ()
> >     Mut :: s -> Eff s
> >
> > data EVector  :: * -> * -> * where
> >     PureVector :: S.Vector el  -> EVector Pure el
> >     MutVector :: SM.MVector s el -> EVector (Mut s) el
> >
> > the above doesn't work because DataKinds only works at kind * currently,
> > however i can defunctionalize it to the following (while making it a tad
> less pretty)
> > and it then works
> >
> > data Eff = Pure | Mut
> >
> > data EVector  :: Eff -> * -> * -> * where
> >     PureVector :: S.Vector el  -> EVector Pure () el
> >     MutVector :: SM.MVector s el -> EVector Mut s  el
> >
> >
> > am i correct in thinking that the first example *should* be possible
> once we have fancier kind machinery (kind equalities and type level
> GADTs?)? I suspect I'll be hitting *A LOT* more examples like the above,
> and if theres any ways I can help push this along on the research or
> engineering side, I please tell me :)
> >
> > thanks!
> > -Carter
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140225/db33bc29/attachment-0001.html>

From carter.schonwald at gmail.com  Wed Feb 26 03:49:33 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 25 Feb 2014 22:49:33 -0500
Subject: would support for kind equalities enable the following example?
In-Reply-To: <CAHYVw0wfzONCFxP0CtZTAN5rXDhXTyCrj8-_UB__zgObLZXTuw@mail.gmail.com>
References: <CAHYVw0ysL32MAZAfP3yvLRo95hGn5cMkLzLz-wALJ0vdRMCrNw@mail.gmail.com>
 <CF3E4429-874F-4F3D-BD05-5C4650E254DB@cis.upenn.edu>
 <CAHYVw0wfzONCFxP0CtZTAN5rXDhXTyCrj8-_UB__zgObLZXTuw@mail.gmail.com>
Message-ID: <CAHYVw0zEfDyL-RLw_iaAiDrWpwg74LzCO2Du77eazE=a4Ut=NQ@mail.gmail.com>

Reid Just helped me whack out a solution, it involve something i didn't
even know was possible in haskell

data Eff :: *-> *  where
    Pure :: Eff s
    Mut :: s -> Eff s

data EVector :: Eff * -> * -> *  where
    PureVector :: S.Vector el  -> EVector Pure el
    MutVector :: SM.MVector s e -> EVector (Mut s) el

(the surprising thing was the Eff *, i didn't know we could do that!)
this type checks, but it can be made simpler still!

data Eff s where
    Pure :: Eff s
    Mut :: s -> Eff s

data EVector s el  where
    PureVector :: S.Vector el  -> EVector Pure el
    MutVector :: SM.MVector s e -> EVector (Mut s) el

:)

that said, I do have some more interesting stuff in the works where I hope
to make use of kind level gadts, so i look forward to finding out how that
shakes out!

-Carter




On Tue, Feb 25, 2014 at 10:23 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> IN this case i *DO* want the GADT. (but i can't express it)
>
> The reason is simple: one type parameter makes for a less complex API to
> educate others about than 2 type parameters. And likewise for 3 vs 4. Etc
> etc. Its a human factors thing :)
>
> I do agree in this case that my "defunctionalized" type is equivalent in
> type safety, and i'm happy to use it for now.
>
>
>
>
> On Tue, Feb 25, 2014 at 6:50 AM, Richard Eisenberg <eir at cis.upenn.edu>wrote:
>
>> My question is: why do you want Eff to be a GADT? It's true that GADTs do
>> not promote (currently), which is why your first example doesn't work.
>> (It's not to do with kinds, exactly, but GADTs.) But, I don't quite see a
>> reason for having a GADT there -- generally, when a GADT is really useful,
>> no amount of defunctionalization will be a substitute.
>>
>> GHC ticket #7961 is a place to make noise about this. My (with co-authors
>> Stephanie Weirich and Justin Hsu) ICFP paper from last year ("System FC
>> with Explicit Kind Equality") is part of the solution, and I was planning
>> on submitting the other part of the solution (type inference!) for ICFP
>> this year. Alas, that won't happen, but I believe I should be able to pull
>> it together for the POPL deadline (July). So, there's somewhat slow but
>> somewhat steady work in this direction, and I'm confident something will
>> make its way into GHC before too long.
>>
>> Richard
>>
>> On Feb 24, 2014, at 11:28 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>> > Hey all,
>> >
>> > I've a use case in my code where It looks like it might be an example
>> of something that won't compile until we have type level GADTs
>> >
>> > I'm essentially writing a vector api that
>> > allows certain args to be mutable, pure or "dont care". (dont care =
>> that they're treated as being immutable). I'm using GADTs to model this.
>> (using GADTs rather than type classes partly because I want to make sure
>> type inference works out nicely, and partly to see how far i can go while
>> not adding any new type classes)
>> >
>> > data Eff :: * -> * where
>> >     Pure :: Eff ()
>> >     Mut :: s -> Eff s
>> >
>> > data EVector  :: * -> * -> * where
>> >     PureVector :: S.Vector el  -> EVector Pure el
>> >     MutVector :: SM.MVector s el -> EVector (Mut s) el
>> >
>> > the above doesn't work because DataKinds only works at kind * currently,
>> > however i can defunctionalize it to the following (while making it a
>> tad less pretty)
>> > and it then works
>> >
>> > data Eff = Pure | Mut
>> >
>> > data EVector  :: Eff -> * -> * -> * where
>> >     PureVector :: S.Vector el  -> EVector Pure () el
>> >     MutVector :: SM.MVector s el -> EVector Mut s  el
>> >
>> >
>> > am i correct in thinking that the first example *should* be possible
>> once we have fancier kind machinery (kind equalities and type level
>> GADTs?)? I suspect I'll be hitting *A LOT* more examples like the above,
>> and if theres any ways I can help push this along on the research or
>> engineering side, I please tell me :)
>> >
>> > thanks!
>> > -Carter
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140225/63655d2c/attachment.html>

From marlowsd at gmail.com  Wed Feb 26 08:11:13 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 26 Feb 2014 08:11:13 +0000
Subject: Runtime error using LLVM bitcode execution
In-Reply-To: <06032AAF9E11164BB3D2827F725F47985C5C5AB8@DEWDFEMB12B.global.corp.sap>
References: <06032AAF9E11164BB3D2827F725F47985C5C5AB8@DEWDFEMB12B.global.corp.sap>
Message-ID: <530DA1A1.7040600@gmail.com>

My guess is that this isn't working because GHC needs to post-process 
the assembly generated by LLVM to support tables-next-to-code.  You 
could extract this phase from GHC (it's just one module, in 
compiler/llvmGen/LlvmMangler.hs) and run it as a standalone program.

Cheers,
Simon

On 21/02/2014 16:02, Benzinger, Ralph wrote:
> Hello,
>
> My apologies in advance if this mailing list is not the appropriate
> address for posting my problem with the GHC runtime, but it seemed
> like the best option on the GHC home page.
>
> I'm trying to execute standalone Haskell functions exported via FFI
> and compiled as LLVM bitcode.  Unfortunately, all my efforts yield the
> following runtime error:
>
> lu003107:~/hs-bitcode> ./bce_so hsallinone.bc
> hs_init complete
> hs_add_root complete
> hsallinone: internal error: stg_ap_p_ret
>      (GHC version 7.6.3 for x86_64_unknown_linux)
>      Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
> 0  bce_so               0x0000000000d6b310
> 1  bce_so               0x0000000000d6b53b
> 2  bce_so               0x0000000000d6ba1c
> 3  libpthread.so.0      0x00007f7683298800
> 4  libc.so.6            0x00007f7682592b35 gsignal + 53
> 5  libc.so.6            0x00007f7682594111 abort + 385
> 6  libHSrts-ghc7.6.3.so 0x00007f7683f6ca21 rtsFatalInternalErrorFn + 177
> 7  libHSrts-ghc7.6.3.so 0x00007f7683f6cce1 barf + 145
> 8  libHSrts-ghc7.6.3.so 0x00007f7683f8a24a stg_ap_p_info + 130
> Stack dump:
> 0.      Program arguments: ./bce_so hsallinone.bc
> Aborted
>
> This is what I do:
>
> I have a function hfun.hs that exports a function
>
>      foreign export ccall hfun :: CInt -> CInt
>
> and a wrapper cmain.c that calls this function:
>
>      #include <HsFFI.h>
>      #include "hfun_stub.h"
>      extern void __stginit_HFun(void);
>      #include <stdio.h>
>
>      int main(int argc, char *argv[])
>      {
> 	hs_init(&argc, &argv);
> 	printf("hs_init complete\n");
>
> 	hs_add_root(__stginit_HFun);
>      	printf("hs_add_root complete\n");
>
>      	int i = hfun(42);
>      	printf("hfun(42) = %d\n", i);
>
>      	hs_exit();
>      	return 0;
>      }
>
> To generate a callable bitcode file I use these commands:
>
>      $ ghc -S -keep-llvm-files -keep-tmp-files hfun.hs
>      $ llvm-as hfun.ll
>      $ cp /tmp/... hfun_stub.c
>      $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include hfun_stub.c
>      $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include cmain.c
>      $ llvm-link cmain.bc hfun_stub.bc hfun.bc -o hsallinone.bc
>
> My main program "bce_so" loads the linked bitcode and feeds it to the
> LLVM execution engine.  All required Haskell runtime libraries are
> linked dynamically against bce_so.
>
> Could you kindly provide some insight on whether this runtime error is
> due to a bug with GHC (unlikely) or rather some negligence in my
> setup?  Or does the issue highlight some principal limitation in my
> (admittedly somewhat naive) approach of using LLVM -- threading
> support, maybe?
>
> Note that compiling hfun.hs/cmain.c into a .so and executing
> everything natively using ldload() works flawlessly.
>
> Regards
> Ralph
>

From Christian.Maeder at dfki.de  Wed Feb 26 12:37:26 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Wed, 26 Feb 2014 13:37:26 +0100
Subject: SPARC: why it's not registerised anymore?
In-Reply-To: <530B15C4.6030702@dfki.de>
References: <53091957.40203@centrum.cz> <530B15C4.6030702@dfki.de>
Message-ID: <530DE006.5020504@dfki.de>

On https://ghc.haskell.org/trac/ghc/wiki/Platforms Sparc is still 
wrongly listed as Tier 2 platform with "Reg'd" being "Yes"

Cheers Christian

Am 24.02.2014 10:49, schrieb Christian Maeder:
> Hi Karel,
>
> the last version of a registered build (that I know about and worked for
> me) is ghc-7.0.4 (see below). I was not able (or gave up) to build
> ghc-7.2 on sparc.
>
> https://ghc.haskell.org/trac/ghc/ticket/7106#comment:3 for ghc-7.4
> says that "Sparc is unregisterised now that the registerised C backend
> has been removed".
>
> Cheers Christian
>
> -bash-3.2$ /home/pub-bkb/ghc/ghc-7.0.4/bin/ghc --info
>   [("Project name","The Glorious Glasgow Haskell Compilation System")
>   ,("Project version","7.0.4")
>   ,("Booter version","7.0.2")
>   ,("Stage","2")
>   ,("Build platform","sparc-sun-solaris2")
>   ,("Host platform","sparc-sun-solaris2")
>   ,("Target platform","sparc-sun-solaris2")
>   ,("Have interpreter","YES")
>   ,("Object splitting","YES")
>   ,("Have native code generator","YES")
>   ,("Have llvm code generator","YES")
>   ,("Support SMP","YES")
>   ,("Unregisterised","NO")
>   ,("Tables next to code","YES")
>   ,("RTS ways","l debug  thr thr_debug thr_l thr_p ")
>   ,("Leading underscore","NO")
>   ,("Debug on","False")
>   ,("LibDir","/home/pub-bkb/ghc/ghc-7.0.4/lib/ghc-7.0.4")
>   ,("Global Package
> DB","/home/pub-bkb/ghc/ghc-7.0.4/lib/ghc-7.0.4/package.conf.d")
>   ,("C compiler flags","[\"-fno-stack-protector\"]")
>   ,("Gcc Linker flags","[]")
>   ,("Ld Linker flags","[]")
>   ]
>
> Am 22.02.2014 22:40, schrieb Karel Gardas:
>>
>> Folks,
>>
>> just out of curiosity I'm building latest GHC on SPARC/Solaris and I've
>> noted that current GHCs (7.6 and HEAD) are building unregisterised by
>> default. In the history I remember at least some GHC were registerised
>> and GHC source code also (still) contains SPARC NCG so I'm curious what
>> was the reason behind the switch? Any bug still waiting for a fix? Or
>> just code rotted in a way it's not working any more?
>>
>> Thanks!
>> Karel
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>

From karel.gardas at centrum.cz  Wed Feb 26 12:54:41 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Wed, 26 Feb 2014 13:54:41 +0100
Subject: SPARC: why it's not registerised anymore?
In-Reply-To: <530DE006.5020504@dfki.de>
References: <53091957.40203@centrum.cz> <530B15C4.6030702@dfki.de>
 <530DE006.5020504@dfki.de>
Message-ID: <530DE411.4050006@centrum.cz>


PPC64/Linux is neither registerised now so the table should be fixed...

Karel

On 02/26/14 01:37 PM, Christian Maeder wrote:
> On https://ghc.haskell.org/trac/ghc/wiki/Platforms Sparc is still
> wrongly listed as Tier 2 platform with "Reg'd" being "Yes"
>
> Cheers Christian
>
> Am 24.02.2014 10:49, schrieb Christian Maeder:
>> Hi Karel,
>>
>> the last version of a registered build (that I know about and worked for
>> me) is ghc-7.0.4 (see below). I was not able (or gave up) to build
>> ghc-7.2 on sparc.
>>
>> https://ghc.haskell.org/trac/ghc/ticket/7106#comment:3 for ghc-7.4
>> says that "Sparc is unregisterised now that the registerised C backend
>> has been removed".
>>
>> Cheers Christian
>>
>> -bash-3.2$ /home/pub-bkb/ghc/ghc-7.0.4/bin/ghc --info
>> [("Project name","The Glorious Glasgow Haskell Compilation System")
>> ,("Project version","7.0.4")
>> ,("Booter version","7.0.2")
>> ,("Stage","2")
>> ,("Build platform","sparc-sun-solaris2")
>> ,("Host platform","sparc-sun-solaris2")
>> ,("Target platform","sparc-sun-solaris2")
>> ,("Have interpreter","YES")
>> ,("Object splitting","YES")
>> ,("Have native code generator","YES")
>> ,("Have llvm code generator","YES")
>> ,("Support SMP","YES")
>> ,("Unregisterised","NO")
>> ,("Tables next to code","YES")
>> ,("RTS ways","l debug thr thr_debug thr_l thr_p ")
>> ,("Leading underscore","NO")
>> ,("Debug on","False")
>> ,("LibDir","/home/pub-bkb/ghc/ghc-7.0.4/lib/ghc-7.0.4")
>> ,("Global Package
>> DB","/home/pub-bkb/ghc/ghc-7.0.4/lib/ghc-7.0.4/package.conf.d")
>> ,("C compiler flags","[\"-fno-stack-protector\"]")
>> ,("Gcc Linker flags","[]")
>> ,("Ld Linker flags","[]")
>> ]
>>
>> Am 22.02.2014 22:40, schrieb Karel Gardas:
>>>
>>> Folks,
>>>
>>> just out of curiosity I'm building latest GHC on SPARC/Solaris and I've
>>> noted that current GHCs (7.6 and HEAD) are building unregisterised by
>>> default. In the history I remember at least some GHC were registerised
>>> and GHC source code also (still) contains SPARC NCG so I'm curious what
>>> was the reason behind the switch? Any bug still waiting for a fix? Or
>>> just code rotted in a way it's not working any more?
>>>
>>> Thanks!
>>> Karel
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>


From austin at well-typed.com  Thu Feb 27 00:14:38 2014
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 26 Feb 2014 18:14:38 -0600
Subject: RC2 release imminent
In-Reply-To: <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
Message-ID: <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>

Hello all,

The RC2 source distribution is here:

http://www.haskell.org/ghc/dist/7.8.1-rc2/

Please build from it directly. It matches the HEAD of the ghc-7.8
branch as of now - e9212f0edbd3fddc3836ccded10d036c01d38505

Like last time, please include a link to the bindist, and a
cryptographic hash (md5/sha1) of the tarball so I know it's OK.

Thanks!

On Fri, Feb 21, 2014 at 7:03 AM, P?li G?bor J?nos <pali.gabor at gmail.com> wrote:
> 2014-02-21 11:58 GMT+01:00 Gabor Greif <ggreif at gmail.com>:
>> The funny thing is that Pali (without the accent) is a nickname for
>> P?l (translated: Paul).
>> But surely he is never called this way :-)
>
> Well, it does not really matter for me :-)  I am aware I may confuse
> non-Hungarians, because I use my name in many different ways, with and
> without accents, I do not have a signature in my messages -- so I am
> fine whatever I am called until it uniquely determines me.
>
> But yeah, I am Gabor too; but apparently we have a lot of Gabors here
> already :-P
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Thu Feb 27 00:21:04 2014
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 26 Feb 2014 18:21:04 -0600
Subject: RC2 release imminent
In-Reply-To: <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
Message-ID: <CAEs96n3wGAu6_DPmOtFNUCo0HQZKoh7-XZ=fstpo3Y97topLnA@mail.gmail.com>

Oh, and I'll go ahead and say: as you already probably noticed, we
have XZ file support now. Please don't feel obligated to make a .xz
binary - I will happily repackage it for you.

'make binary-dist' by default will still use a .bz2 output, which will
work just fine when you send it to me.

On Wed, Feb 26, 2014 at 6:14 PM, Austin Seipp <austin at well-typed.com> wrote:
> Hello all,
>
> The RC2 source distribution is here:
>
> http://www.haskell.org/ghc/dist/7.8.1-rc2/
>
> Please build from it directly. It matches the HEAD of the ghc-7.8
> branch as of now - e9212f0edbd3fddc3836ccded10d036c01d38505
>
> Like last time, please include a link to the bindist, and a
> cryptographic hash (md5/sha1) of the tarball so I know it's OK.
>
> Thanks!
>
> On Fri, Feb 21, 2014 at 7:03 AM, P?li G?bor J?nos <pali.gabor at gmail.com> wrote:
>> 2014-02-21 11:58 GMT+01:00 Gabor Greif <ggreif at gmail.com>:
>>> The funny thing is that Pali (without the accent) is a nickname for
>>> P?l (translated: Paul).
>>> But surely he is never called this way :-)
>>
>> Well, it does not really matter for me :-)  I am aware I may confuse
>> non-Hungarians, because I use my name in many different ways, with and
>> without accents, I do not have a signature in my messages -- so I am
>> fine whatever I am called until it uniquely determines me.
>>
>> But yeah, I am Gabor too; but apparently we have a lot of Gabors here
>> already :-P
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From kazu at iij.ad.jp  Thu Feb 27 01:50:23 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Thu, 27 Feb 2014 10:50:23 +0900 (JST)
Subject: RC2 release imminent
In-Reply-To: <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
References: <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
Message-ID: <20140227.105023.1346950217663442675.kazu@iij.ad.jp>

Hi Austin,

> The RC2 source distribution is here:
> 
> http://www.haskell.org/ghc/dist/7.8.1-rc2/

To my quick test, the @rpath problem on Mac has been fixed.
Thank you!

--Kazu

From pali.gabor at gmail.com  Thu Feb 27 07:32:41 2014
From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=)
Date: Thu, 27 Feb 2014 08:32:41 +0100
Subject: RC2 release imminent
In-Reply-To: <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
Message-ID: <CAHnG2Cy-rMdpVAiU3UgF=pVzZOR0eBzzdSU2QVMF4SDzddEydw@mail.gmail.com>

2014-02-27 1:14 GMT+01:00 Austin Seipp <austin at well-typed.com>:
> Like last time, please include a link to the bindist, and a
> cryptographic hash (md5/sha1) of the tarball so I know it's OK.

Here are the FreeBSD builds:

http://haskell.inf.elte.hu/ghc/

Note that I have updated the checksum file and the README too.

From lukexipd at gmail.com  Thu Feb 27 10:51:22 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Thu, 27 Feb 2014 02:51:22 -0800
Subject: RC2 release imminent
In-Reply-To: <CAHnG2Cy-rMdpVAiU3UgF=pVzZOR0eBzzdSU2QVMF4SDzddEydw@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
 <CAHnG2Cy-rMdpVAiU3UgF=pVzZOR0eBzzdSU2QVMF4SDzddEydw@mail.gmail.com>
Message-ID: <CAGo83CguQNEjo0BwKZmHWGhXUSsvxhLNDnZOFVgtpaaJx+Av7g@mail.gmail.com>

Hi Austin,

Here are the GHC iOS builds.
https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140226-arm-apple-ios.tar.bz2
https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140226-arm-apple-ios.tar.bz2.sha1

https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140226-i386-apple-ios.tar.bz2
https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140226-i386-apple-ios.tar.bz2.sha1

Readme is here:
https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md

Cheers!
Luke


On Wed, Feb 26, 2014 at 11:32 PM, P?li G?bor J?nos <pali.gabor at gmail.com>wrote:

> 2014-02-27 1:14 GMT+01:00 Austin Seipp <austin at well-typed.com>:
> > Like last time, please include a link to the bindist, and a
> > cryptographic hash (md5/sha1) of the tarball so I know it's OK.
>
> Here are the FreeBSD builds:
>
> http://haskell.inf.elte.hu/ghc/
>
> Note that I have updated the checksum file and the README too.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140227/e0bb7c48/attachment.html>

From austin at well-typed.com  Thu Feb 27 13:43:20 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 27 Feb 2014 07:43:20 -0600
Subject: RC2 release imminent
In-Reply-To: <CAGo83CguQNEjo0BwKZmHWGhXUSsvxhLNDnZOFVgtpaaJx+Av7g@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
 <CAHnG2Cy-rMdpVAiU3UgF=pVzZOR0eBzzdSU2QVMF4SDzddEydw@mail.gmail.com>
 <CAGo83CguQNEjo0BwKZmHWGhXUSsvxhLNDnZOFVgtpaaJx+Av7g@mail.gmail.com>
Message-ID: <CAEs96n3QgHwgGEq2FjqtmvBqGcPvWpnsYvx=FkupMxzJHQ9ULg@mail.gmail.com>

Thanks all. The 32 bit builds are churning on here, so they should be
done this morning (within the next hour or two).

On Thu, Feb 27, 2014 at 4:51 AM, Luke Iannini <lukexipd at gmail.com> wrote:
> Hi Austin,
>
> Here are the GHC iOS builds.
> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140226-arm-apple-ios.tar.bz2
> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140226-arm-apple-ios.tar.bz2.sha1
>
> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140226-i386-apple-ios.tar.bz2
> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140226-i386-apple-ios.tar.bz2.sha1
>
> Readme is here:
> https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md
>
> Cheers!
> Luke
>
>
> On Wed, Feb 26, 2014 at 11:32 PM, P?li G?bor J?nos <pali.gabor at gmail.com>
> wrote:
>>
>> 2014-02-27 1:14 GMT+01:00 Austin Seipp <austin at well-typed.com>:
>> > Like last time, please include a link to the bindist, and a
>> > cryptographic hash (md5/sha1) of the tarball so I know it's OK.
>>
>> Here are the FreeBSD builds:
>>
>> http://haskell.inf.elte.hu/ghc/
>>
>> Note that I have updated the checksum file and the README too.
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From johan.tibell at gmail.com  Thu Feb 27 14:50:14 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 27 Feb 2014 15:50:14 +0100
Subject: What does the DWARF information generated by your GHC branch look
 like?
Message-ID: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>

Hi!

(I've CCed ghc-devs on this email, as I think the question is of general
interest.)

I enjoyed reading your paper [1] and I have some questions.

 * What does the generated DWARF information look like? For example, will
you fill in the .debug_line section so that standard tools like "perf
report" and gprof can be used on Haskell code? Code pointers would be
appreciated.

 * Does your GHC allow DWARF information to be generated without actually
using any of the RTS (e.g. eventlog) machinery? This would be very useful
if you want to use "report record/report" only, in order to achieve minimal
overhead when that matters. Another way to ask the same question, do you
have a ghc -g flag that has no implication for the runtime settings?

 * Do you generate DW_TAG_subprogram sections in the .debug_info section so
that other tools can figure out the name of Haskell functions?

Cheers,
Johan

1. "Causality of Optimized Haskell: What is burning our cycles?"
http://eprints.whiterose.ac.uk/76448/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140227/a56027bb/attachment.html>

From austin at well-typed.com  Thu Feb 27 16:11:07 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 27 Feb 2014 10:11:07 -0600
Subject: RC2 release imminent
In-Reply-To: <CAEs96n3QgHwgGEq2FjqtmvBqGcPvWpnsYvx=FkupMxzJHQ9ULg@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
 <CAHnG2Cy-rMdpVAiU3UgF=pVzZOR0eBzzdSU2QVMF4SDzddEydw@mail.gmail.com>
 <CAGo83CguQNEjo0BwKZmHWGhXUSsvxhLNDnZOFVgtpaaJx+Av7g@mail.gmail.com>
 <CAEs96n3QgHwgGEq2FjqtmvBqGcPvWpnsYvx=FkupMxzJHQ9ULg@mail.gmail.com>
Message-ID: <CAEs96n0pzmh7QT7j=U6Nde2oPm0afXXaaHfVsXM-5f9rPz-iUQ@mail.gmail.com>

(Resending to list - Sorry Karel, Christian)

Hello all,

Unfortunately - I must ask you to build RC2 again soon. Why? Simon
swooped in and fixed two very nasty bugs last moment - one with a
memory leak for foreign exports, and a rare, subtle code generator
bug. It would be best, of course, not to throw those onto users for
the final release since they should see some stress by users first.

I'll be merging these fixes and making a new tarball soon, and I'll
update you on when the *new* srcdist is available.

Sorry, but thank you again!

On Thu, Feb 27, 2014 at 7:43 AM, Austin Seipp <austin at well-typed.com> wrote:
> Thanks all. The 32 bit builds are churning on here, so they should be
> done this morning (within the next hour or two).
>
> On Thu, Feb 27, 2014 at 4:51 AM, Luke Iannini <lukexipd at gmail.com> wrote:
>> Hi Austin,
>>
>> Here are the GHC iOS builds.
>> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140226-arm-apple-ios.tar.bz2
>> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140226-arm-apple-ios.tar.bz2.sha1
>>
>> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140226-i386-apple-ios.tar.bz2
>> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140226-i386-apple-ios.tar.bz2.sha1
>>
>> Readme is here:
>> https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md
>>
>> Cheers!
>> Luke
>>
>>
>> On Wed, Feb 26, 2014 at 11:32 PM, P?li G?bor J?nos <pali.gabor at gmail.com>
>> wrote:
>>>
>>> 2014-02-27 1:14 GMT+01:00 Austin Seipp <austin at well-typed.com>:
>>> > Like last time, please include a link to the bindist, and a
>>> > cryptographic hash (md5/sha1) of the tarball so I know it's OK.
>>>
>>> Here are the FreeBSD builds:
>>>
>>> http://haskell.inf.elte.hu/ghc/
>>>
>>> Note that I have updated the checksum file and the README too.
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From george.colpitts at gmail.com  Thu Feb 27 23:47:26 2014
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 27 Feb 2014 19:47:26 -0400
Subject: first version of RC2 has problems with lack of dynamic problems at
 least on the Mac
Message-ID: <CAB-d4A4CnSP=WFu5cwVnTTuTCBFnhF0qsZjhs3gAf8efZZGaEg@mail.gmail.com>

Hi

After installing the first version of RC2 I ran into the following problem

 cabal install vector
Resolving dependencies...
Configuring vector-0.10.9.1...
...
[ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
Data/Vector/Fusion/Stream/Monadic.hs,
dist/build/Data/Vector/Fusion/Stream/Monadic.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package primitive-0.5.2.1 ... <command line>: can't load .so/.DLL
for: libHSprimitive-0.5.2.1.dylib (dlopen(libHSprimitive-0.5.2.1.dylib, 9):
image not found)

There seems to be a general problem that the install did not produce any
dynamic libraries at least on the Mac:

 ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
/Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a libHScpphs-1.18.2_p.a

/Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a libHShashable-1.2.1.0_p.a

/Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
HShscolour-1.20.3.o Language libHShscolour-1.20.3.a libHShscolour-1.20.3_p.a

/Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
Data include libHSprimitive-0.5.2.1_p.a

/Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a

/Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a

/Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
Data libHSunordered-containers-0.2.3.3.a
HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140227/16860169/attachment.html>

From george.colpitts at gmail.com  Thu Feb 27 23:53:52 2014
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 27 Feb 2014 19:53:52 -0400
Subject: first version of RC2 has problems with lack of dynamic libraries
 at least on the Mac
Message-ID: <CAB-d4A4nsbibYGLb3GPwNBr_23+h6-m=E04iJfW-C0PFSzjZfA@mail.gmail.com>

corrected subject line


On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts
<george.colpitts at gmail.com>wrote:

> Hi
>
> After installing the first version of RC2 I ran into the following problem
>
>  cabal install vector
> Resolving dependencies...
> Configuring vector-0.10.9.1...
> ...
> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
> Data/Vector/Fusion/Stream/Monadic.hs,
> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... linking ... done.
> Loading package primitive-0.5.2.1 ... <command line>: can't load .so/.DLL
> for: libHSprimitive-0.5.2.1.dylib (dlopen(libHSprimitive-0.5.2.1.dylib, 9):
> image not found)
>
> There seems to be a general problem that the install did not produce any
> dynamic libraries at least on the Mac:
>
>  ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
> HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a libHScpphs-1.18.2_p.a
>
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
> Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a
> libHShashable-1.2.1.0_p.a
>
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
> HShscolour-1.20.3.o Language libHShscolour-1.20.3.a
> libHShscolour-1.20.3_p.a
>
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
> Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
> Data include libHSprimitive-0.5.2.1_p.a
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
> Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
> Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a
>
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
> Data libHSunordered-containers-0.2.3.3.a
> HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140227/125814b8/attachment-0001.html>

From carter.schonwald at gmail.com  Thu Feb 27 23:59:04 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 27 Feb 2014 18:59:04 -0500
Subject: first version of RC2 has problems with lack of dynamic problems
 at least on the Mac
In-Reply-To: <CAB-d4A4CnSP=WFu5cwVnTTuTCBFnhF0qsZjhs3gAf8efZZGaEg@mail.gmail.com>
References: <CAB-d4A4CnSP=WFu5cwVnTTuTCBFnhF0qsZjhs3gAf8efZZGaEg@mail.gmail.com>
Message-ID: <CAHYVw0wDD_z+JUDRRFe3xspp4j5JVVAWMnf+L3EjxaTJ=48-RQ@mail.gmail.com>

I'm doing my own OS X Build of the RC + simonM's gc patch on top right now

i'll report back later :)


On Thu, Feb 27, 2014 at 6:47 PM, George Colpitts
<george.colpitts at gmail.com>wrote:

> Hi
>
> After installing the first version of RC2 I ran into the following problem
>
>  cabal install vector
> Resolving dependencies...
> Configuring vector-0.10.9.1...
> ...
> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
> Data/Vector/Fusion/Stream/Monadic.hs,
> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... linking ... done.
> Loading package primitive-0.5.2.1 ... <command line>: can't load .so/.DLL
> for: libHSprimitive-0.5.2.1.dylib (dlopen(libHSprimitive-0.5.2.1.dylib, 9):
> image not found)
>
> There seems to be a general problem that the install did not produce any
> dynamic libraries at least on the Mac:
>
>  ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
> HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a libHScpphs-1.18.2_p.a
>
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
> Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a
> libHShashable-1.2.1.0_p.a
>
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
> HShscolour-1.20.3.o Language libHShscolour-1.20.3.a
> libHShscolour-1.20.3_p.a
>
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
> Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
> Data include libHSprimitive-0.5.2.1_p.a
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
> Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
> Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a
>
>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
> Data libHSunordered-containers-0.2.3.3.a
> HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140227/bef0c731/attachment.html>

From austin at well-typed.com  Fri Feb 28 00:05:25 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 27 Feb 2014 18:05:25 -0600
Subject: first version of RC2 has problems with lack of dynamic libraries
 at least on the Mac
In-Reply-To: <CAB-d4A4nsbibYGLb3GPwNBr_23+h6-m=E04iJfW-C0PFSzjZfA@mail.gmail.com>
References: <CAB-d4A4nsbibYGLb3GPwNBr_23+h6-m=E04iJfW-C0PFSzjZfA@mail.gmail.com>
Message-ID: <CAEs96n2-MR5neqbhnD+ZRVW30i8C1G_NQi-M=bG1KeoPdUunrA@mail.gmail.com>

I just tested this and cannot reproduce it:

$ cabal install vector
... building ...

$ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/vector-0.10.9.1
Data libHSvector-0.10.9.1-ghc7.8.0.20140226.dylib include libHSvector-0.10.9.1.a

$ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/primitive-0.5.2.1/
Control include libHSprimitive-0.5.2.1.a Data
libHSprimitive-0.5.2.1-ghc7.8.0.20140226.dylib

$ uname -a
Darwin Calcifer.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19
22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64

There is certainly a dylib available for both of these libraries.
You're going to need to be very explicit in what you did to install
GHC, and how. (Did you use the binary distribution I pulled from the
server?)* Unfortunately I'm about to run out the door, and don't have
time for the next few hours closely investigate.

* On another note, I will say that there is not an 'RC2' until I
announce that it is so, to be completely honest. Right this second,
some last minute fixes went into HEAD which will be merged for the
actual RC2. Otherwise I would have released it today. But thank you
for testing anyway!

On Thu, Feb 27, 2014 at 5:53 PM, George Colpitts
<george.colpitts at gmail.com> wrote:
> corrected subject line
>
>
> On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts <george.colpitts at gmail.com>
> wrote:
>>
>> Hi
>>
>> After installing the first version of RC2 I ran into the following problem
>>
>>  cabal install vector
>> Resolving dependencies...
>> Configuring vector-0.10.9.1...
>> ...
>> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
>> Data/Vector/Fusion/Stream/Monadic.hs,
>> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
>> Loading package ghc-prim ... linking ... done.
>> Loading package integer-gmp ... linking ... done.
>> Loading package base ... linking ... done.
>> Loading package primitive-0.5.2.1 ... <command line>: can't load .so/.DLL
>> for: libHSprimitive-0.5.2.1.dylib (dlopen(libHSprimitive-0.5.2.1.dylib, 9):
>> image not found)
>>
>> There seems to be a general problem that the install did not produce any
>> dynamic libraries at least on the Mac:
>>
>>  ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
>> HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a libHScpphs-1.18.2_p.a
>>
>>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
>> Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a
>> libHShashable-1.2.1.0_p.a
>>
>>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
>> HShscolour-1.20.3.o Language libHShscolour-1.20.3.a
>> libHShscolour-1.20.3_p.a
>>
>>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
>> Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
>> Data include libHSprimitive-0.5.2.1_p.a
>>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
>> Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a
>>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
>> Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a
>>
>>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
>> Data libHSunordered-containers-0.2.3.3.a
>> HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From george.colpitts at gmail.com  Fri Feb 28 00:58:32 2014
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 27 Feb 2014 20:58:32 -0400
Subject: first version of RC2 has problems with lack of dynamic libraries
 at least on the Mac
In-Reply-To: <CAEs96n2-MR5neqbhnD+ZRVW30i8C1G_NQi-M=bG1KeoPdUunrA@mail.gmail.com>
References: <CAB-d4A4nsbibYGLb3GPwNBr_23+h6-m=E04iJfW-C0PFSzjZfA@mail.gmail.com>
 <CAEs96n2-MR5neqbhnD+ZRVW30i8C1G_NQi-M=bG1KeoPdUunrA@mail.gmail.com>
Message-ID: <CAB-d4A5twNF7-gWO7b1thko2mWwBJitpaXTz1maGr5TiyXpMRw@mail.gmail.com>

Probably my error, I just wanted to make sure there wasn't a problem that
was missed. Thanks for checking. Sorry for any confusion I caused.

Here are the details of what I did:

I took ghc-7.8.0.20140226-x86_64-apple-darwin-mavericks.tar.bz2 from
http://www.haskell.org/ghc/dist/7.8.1-rc2/ and followed the instructions in
the INSTALL file to install it, i.e.

One possible difference is that my gcc is gcc-4.8 from gnu not gcc from
Apple.

Also my uname output is different than yours:

uname -a
Darwin iMac27-5.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64


Finally I am running XCode 5.2

Is there a to uninstall or clean these RCs?

I'll wait for official notice before trying anything else

I really appreciate all your work and I'm sorry if I caused you any
unnecessary work. I had no problems installing RC1 so may have been
overconfident


On Thu, Feb 27, 2014 at 8:05 PM, Austin Seipp <austin at well-typed.com> wrote:

> I just tested this and cannot reproduce it:
>
> $ cabal install vector
> ... building ...
>
> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/vector-0.10.9.1
> Data libHSvector-0.10.9.1-ghc7.8.0.20140226.dylib include
> libHSvector-0.10.9.1.a
>
> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/primitive-0.5.2.1/
> Control include libHSprimitive-0.5.2.1.a Data
> libHSprimitive-0.5.2.1-ghc7.8.0.20140226.dylib
>
> $ uname -a
> Darwin Calcifer.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19
> 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64
>
> There is certainly a dylib available for both of these libraries.
> You're going to need to be very explicit in what you did to install
> GHC, and how. (Did you use the binary distribution I pulled from the
> server?)* Unfortunately I'm about to run out the door, and don't have
> time for the next few hours closely investigate.
>
> * On another note, I will say that there is not an 'RC2' until I
> announce that it is so, to be completely honest. Right this second,
> some last minute fixes went into HEAD which will be merged for the
> actual RC2. Otherwise I would have released it today. But thank you
> for testing anyway!
>
> On Thu, Feb 27, 2014 at 5:53 PM, George Colpitts
> <george.colpitts at gmail.com> wrote:
> > corrected subject line
> >
> >
> > On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts <
> george.colpitts at gmail.com>
> > wrote:
> >>
> >> Hi
> >>
> >> After installing the first version of RC2 I ran into the following
> problem
> >>
> >>  cabal install vector
> >> Resolving dependencies...
> >> Configuring vector-0.10.9.1...
> >> ...
> >> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
> >> Data/Vector/Fusion/Stream/Monadic.hs,
> >> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
> >> Loading package ghc-prim ... linking ... done.
> >> Loading package integer-gmp ... linking ... done.
> >> Loading package base ... linking ... done.
> >> Loading package primitive-0.5.2.1 ... <command line>: can't load
> .so/.DLL
> >> for: libHSprimitive-0.5.2.1.dylib (dlopen(libHSprimitive-0.5.2.1.dylib,
> 9):
> >> image not found)
> >>
> >> There seems to be a general problem that the install did not produce any
> >> dynamic libraries at least on the Mac:
> >>
> >>  ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
> >> HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a libHScpphs-1.18.2_p.a
> >>
> >>
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
> >> Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a
> >> libHShashable-1.2.1.0_p.a
> >>
> >>
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
> >> HShscolour-1.20.3.o Language libHShscolour-1.20.3.a
> >> libHShscolour-1.20.3_p.a
> >>
> >>
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
> >> Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
> >> Data include libHSprimitive-0.5.2.1_p.a
> >>
> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
> >> Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a
> >>
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
> >> Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a
> >>
> >>
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
> >> Data libHSunordered-containers-0.2.3.3.a
> >> HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a
> >
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140227/b4ce2329/attachment-0001.html>

From austin at well-typed.com  Fri Feb 28 01:04:35 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 27 Feb 2014 19:04:35 -0600
Subject: first version of RC2 has problems with lack of dynamic libraries
 at least on the Mac
In-Reply-To: <CAB-d4A5twNF7-gWO7b1thko2mWwBJitpaXTz1maGr5TiyXpMRw@mail.gmail.com>
References: <CAB-d4A4nsbibYGLb3GPwNBr_23+h6-m=E04iJfW-C0PFSzjZfA@mail.gmail.com>
 <CAEs96n2-MR5neqbhnD+ZRVW30i8C1G_NQi-M=bG1KeoPdUunrA@mail.gmail.com>
 <CAB-d4A5twNF7-gWO7b1thko2mWwBJitpaXTz1maGr5TiyXpMRw@mail.gmail.com>
Message-ID: <CAEs96n3k_GfhOfnBjCAY=Z+=NBQ=_mwgcbvLEE0aeSB4ORUkCw@mail.gmail.com>

Thanks. Another question is what version of Cabal you are using, as it
knows how to build dylibs properly. I'm using cabal 1.18.

To delete the RC, you can just delete the directory it installed into (the
GHC-7.8.xxxxx folder). Also make sure you remove the executables from $PATH

And no worries about any unnecessary work. I'm here to do the release after
all, and feedback is helpful!


On Thursday, February 27, 2014, George Colpitts <george.colpitts at gmail.com>
wrote:

> Probably my error, I just wanted to make sure there wasn't a problem that
> was missed. Thanks for checking. Sorry for any confusion I caused.
>
> Here are the details of what I did:
>
> I took ghc-7.8.0.20140226-x86_64-apple-darwin-mavericks.tar.bz2 from
> http://www.haskell.org/ghc/dist/7.8.1-rc2/ and followed the instructions
> in the INSTALL file to install it, i.e.
>
> One possible difference is that my gcc is gcc-4.8 from gnu not gcc from
> Apple.
>
> Also my uname output is different than yours:
>
> uname -a
> Darwin iMac27-5.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
> 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
>
>
> Finally I am running XCode 5.2
>
> Is there a to uninstall or clean these RCs?
>
> I'll wait for official notice before trying anything else
>
> I really appreciate all your work and I'm sorry if I caused you any
> unnecessary work. I had no problems installing RC1 so may have been
> overconfident
>
>
> On Thu, Feb 27, 2014 at 8:05 PM, Austin Seipp <austin at well-typed.com>wrote:
>
> I just tested this and cannot reproduce it:
>
> $ cabal install vector
> ... building ...
>
> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/vector-0.10.9.1
> Data libHSvector-0.10.9.1-ghc7.8.0.20140226.dylib include
> libHSvector-0.10.9.1.a
>
> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/primitive-0.5.2.1/
> Control include libHSprimitive-0.5.2.1.a Data
> libHSprimitive-0.5.2.1-ghc7.8.0.20140226.dylib
>
> $ uname -a
> Darwin Calcifer.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19
> 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64
>
> There is certainly a dylib available for both of these libraries.
> You're going to need to be very explicit in what you did to install
> GHC, and how. (Did you use the binary distribution I pulled from the
> server?)* Unfortunately I'm about to run out the door, and don't have
> time for the next few hours closely investigate.
>
> * On another note, I will say that there is not an 'RC2' until I
> announce that it is so, to be completely honest. Right this second,
> some last minute fixes went into HEAD which will be merged for the
> actual RC2. Otherwise I would have released it today. But thank you
> for testing anyway!
>
> On Thu, Feb 27, 2014 at 5:53 PM, George Colpitts
> <george.colpitts at gmail.com> wrote:
> > corrected subject line
> >
> >
> > On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts <
> george.colpitts at gmail.com>
> > wrote:
> >>
> >> Hi
> >>
> >> After installing the first version of RC2 I ran into the following
> problem
> >>
> >>  cabal install vector
> >> Resolving dependencies...
> >> Configuring vector-0.10.9.1...
> >> ...
> >> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
> >> Data/Vector/Fusion/Stream/Monadic.hs,
> >> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
> >> Loading package ghc-prim ... linking ... done.
> >> Loading package integer-gmp ... linking ... done.
> >> Loading package base ... linking ... done.
> >> Loading package primitive-0.5.2.1 ... <command line>: can't load
> .so/.DLL
> >> for: libHSprimitive-0.5.2.1.dylib (dlopen(libHSprimitive-0.5.2.1.dylib,
> 9):
> >> image not found)
> >>
> >> There seems to be a general problem that the install did not produce any
> >> dynamic libraries at least on the Mac:
> >>
> >>  ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
> >> HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a libHScpphs-1.18.2_p.a
> >>
> >>
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
> >> Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a
> >> libHShashable-1.2.1.0_p.a
> >>
> >>
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
> >> HShscolour-1.20.3.o Language libHShscolour-1.20.3.a
> >> libHShscolour-1.20.3_p.a
> >>
> >>
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
> >> Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
> >> Data include libHSprimitive-0.5.2.1_p.a
> >>
> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
> >> Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a
> >>
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
> >> Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a
> >>
> >>
> >>
> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
> >> Data libHSunordered-containers-0.2.3.3.a
> >> HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a
> >
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
>
>

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140227/b8be0371/attachment.html>

From george.colpitts at gmail.com  Fri Feb 28 02:16:31 2014
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 27 Feb 2014 22:16:31 -0400
Subject: first version of RC2 has problems with lack of dynamic libraries
 at least on the Mac
In-Reply-To: <CAEs96n3k_GfhOfnBjCAY=Z+=NBQ=_mwgcbvLEE0aeSB4ORUkCw@mail.gmail.com>
References: <CAB-d4A4nsbibYGLb3GPwNBr_23+h6-m=E04iJfW-C0PFSzjZfA@mail.gmail.com>
 <CAEs96n2-MR5neqbhnD+ZRVW30i8C1G_NQi-M=bG1KeoPdUunrA@mail.gmail.com>
 <CAB-d4A5twNF7-gWO7b1thko2mWwBJitpaXTz1maGr5TiyXpMRw@mail.gmail.com>
 <CAEs96n3k_GfhOfnBjCAY=Z+=NBQ=_mwgcbvLEE0aeSB4ORUkCw@mail.gmail.com>
Message-ID: <CAB-d4A7Wx_ROS4WO2CMg_ZTgttuzegFmeRjiHKYFn3W5OSaCDg@mail.gmail.com>

I'm using Cabal-1.18.1.3 and cabal-install version 1.16.0.2


On Thu, Feb 27, 2014 at 9:04 PM, Austin Seipp <austin at well-typed.com> wrote:

> Thanks. Another question is what version of Cabal you are using, as it
> knows how to build dylibs properly. I'm using cabal 1.18.
>
> To delete the RC, you can just delete the directory it installed into (the
> GHC-7.8.xxxxx folder). Also make sure you remove the executables from $PATH
>
> And no worries about any unnecessary work. I'm here to do the release
> after all, and feedback is helpful!
>
>
> On Thursday, February 27, 2014, George Colpitts <george.colpitts at gmail.com>
> wrote:
>
>> Probably my error, I just wanted to make sure there wasn't a problem that
>> was missed. Thanks for checking. Sorry for any confusion I caused.
>>
>> Here are the details of what I did:
>>
>> I took ghc-7.8.0.20140226-x86_64-apple-darwin-mavericks.tar.bz2 from
>> http://www.haskell.org/ghc/dist/7.8.1-rc2/ and followed the instructions
>> in the INSTALL file to install it, i.e.
>>
>> One possible difference is that my gcc is gcc-4.8 from gnu not gcc from
>> Apple.
>>
>> Also my uname output is different than yours:
>>
>> uname -a
>> Darwin iMac27-5.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
>> 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
>>
>>
>> Finally I am running XCode 5.2
>>
>> Is there a to uninstall or clean these RCs?
>>
>> I'll wait for official notice before trying anything else
>>
>> I really appreciate all your work and I'm sorry if I caused you any
>> unnecessary work. I had no problems installing RC1 so may have been
>> overconfident
>>
>>
>> On Thu, Feb 27, 2014 at 8:05 PM, Austin Seipp <austin at well-typed.com>wrote:
>>
>> I just tested this and cannot reproduce it:
>>
>> $ cabal install vector
>> ... building ...
>>
>> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/vector-0.10.9.1
>> Data libHSvector-0.10.9.1-ghc7.8.0.20140226.dylib include
>> libHSvector-0.10.9.1.a
>>
>> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/primitive-0.5.2.1/
>> Control include libHSprimitive-0.5.2.1.a Data
>> libHSprimitive-0.5.2.1-ghc7.8.0.20140226.dylib
>>
>> $ uname -a
>> Darwin Calcifer.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19
>> 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64
>>
>> There is certainly a dylib available for both of these libraries.
>> You're going to need to be very explicit in what you did to install
>> GHC, and how. (Did you use the binary distribution I pulled from the
>> server?)* Unfortunately I'm about to run out the door, and don't have
>> time for the next few hours closely investigate.
>>
>> * On another note, I will say that there is not an 'RC2' until I
>> announce that it is so, to be completely honest. Right this second,
>> some last minute fixes went into HEAD which will be merged for the
>> actual RC2. Otherwise I would have released it today. But thank you
>> for testing anyway!
>>
>> On Thu, Feb 27, 2014 at 5:53 PM, George Colpitts
>> <george.colpitts at gmail.com> wrote:
>> > corrected subject line
>> >
>> >
>> > On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts <
>> george.colpitts at gmail.com>
>> > wrote:
>> >>
>> >> Hi
>> >>
>> >> After installing the first version of RC2 I ran into the following
>> problem
>> >>
>> >>  cabal install vector
>> >> Resolving dependencies...
>> >> Configuring vector-0.10.9.1...
>> >> ...
>> >> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
>> >> Data/Vector/Fusion/Stream/Monadic.hs,
>> >> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
>> >> Loading package ghc-prim ... linking ... done.
>> >> Loading package integer-gmp ... linking ... done.
>> >> Loading package base ... linking ... done.
>> >> Loading package primitive-0.5.2.1 ... <command line>: can't load
>> .so/.DLL
>> >> for: libHSprimitive-0.5.2.1.dylib
>> (dlopen(libHSprimitive-0.5.2.1.dylib, 9):
>> >> image not found)
>> >>
>> >> There seems to be a general problem that the install did not produce
>> any
>> >> dynamic libraries at least on the Mac:
>> >>
>> >>  ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
>> >>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
>> >> HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a
>> libHScpphs-1.18.2_p.a
>> >>
>> >>
>> >>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
>> >> Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a
>> >> libHShashable-1.2.1.0_p.a
>> >>
>> >>
>> >>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
>> >> HShscolour-1.20.3.o Language libHShscolour-1.20.3.a
>> >> libHShscolour-1.20.3_p.a
>> >>
>> >>
>> >>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
>> >> Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
>> >> Data include libHSprimitive-0.5.2.1_p.a
>> >>
>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
>> >> Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a
>> >>
>> >>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
>> >> Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a
>> >>
>> >>
>> >>
>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
>> >> Data libHSunordered-containers-0.2.3.3.a
>> >> HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a
>> >
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>>
>>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140227/b7214725/attachment-0001.html>

From carter.schonwald at gmail.com  Fri Feb 28 02:27:36 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 27 Feb 2014 21:27:36 -0500
Subject: first version of RC2 has problems with lack of dynamic libraries
 at least on the Mac
In-Reply-To: <CAB-d4A7Wx_ROS4WO2CMg_ZTgttuzegFmeRjiHKYFn3W5OSaCDg@mail.gmail.com>
References: <CAB-d4A4nsbibYGLb3GPwNBr_23+h6-m=E04iJfW-C0PFSzjZfA@mail.gmail.com>
 <CAEs96n2-MR5neqbhnD+ZRVW30i8C1G_NQi-M=bG1KeoPdUunrA@mail.gmail.com>
 <CAB-d4A5twNF7-gWO7b1thko2mWwBJitpaXTz1maGr5TiyXpMRw@mail.gmail.com>
 <CAEs96n3k_GfhOfnBjCAY=Z+=NBQ=_mwgcbvLEE0aeSB4ORUkCw@mail.gmail.com>
 <CAB-d4A7Wx_ROS4WO2CMg_ZTgttuzegFmeRjiHKYFn3W5OSaCDg@mail.gmail.com>
Message-ID: <CAHYVw0wdGEsffbwYWSjkK27oZyqDVcRnuwOGK8LiGy6pw3Lp8Q@mail.gmail.com>

you need cabal-install 1.18 or you'll be sad.




On Thu, Feb 27, 2014 at 9:16 PM, George Colpitts
<george.colpitts at gmail.com>wrote:

> I'm using Cabal-1.18.1.3 and cabal-install version 1.16.0.2
>
>
> On Thu, Feb 27, 2014 at 9:04 PM, Austin Seipp <austin at well-typed.com>wrote:
>
>> Thanks. Another question is what version of Cabal you are using, as it
>> knows how to build dylibs properly. I'm using cabal 1.18.
>>
>> To delete the RC, you can just delete the directory it installed into
>> (the GHC-7.8.xxxxx folder). Also make sure you remove the executables from
>> $PATH
>>
>> And no worries about any unnecessary work. I'm here to do the release
>> after all, and feedback is helpful!
>>
>>
>> On Thursday, February 27, 2014, George Colpitts <
>> george.colpitts at gmail.com> wrote:
>>
>>> Probably my error, I just wanted to make sure there wasn't a problem
>>> that was missed. Thanks for checking. Sorry for any confusion I caused.
>>>
>>> Here are the details of what I did:
>>>
>>> I took ghc-7.8.0.20140226-x86_64-apple-darwin-mavericks.tar.bz2 from
>>> http://www.haskell.org/ghc/dist/7.8.1-rc2/ and followed the
>>> instructions in the INSTALL file to install it, i.e.
>>>
>>> One possible difference is that my gcc is gcc-4.8 from gnu not gcc from
>>> Apple.
>>>
>>> Also my uname output is different than yours:
>>>
>>> uname -a
>>> Darwin iMac27-5.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
>>> 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
>>>
>>>
>>> Finally I am running XCode 5.2
>>>
>>> Is there a to uninstall or clean these RCs?
>>>
>>> I'll wait for official notice before trying anything else
>>>
>>> I really appreciate all your work and I'm sorry if I caused you any
>>> unnecessary work. I had no problems installing RC1 so may have been
>>> overconfident
>>>
>>>
>>> On Thu, Feb 27, 2014 at 8:05 PM, Austin Seipp <austin at well-typed.com>wrote:
>>>
>>> I just tested this and cannot reproduce it:
>>>
>>> $ cabal install vector
>>> ... building ...
>>>
>>> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/vector-0.10.9.1
>>> Data libHSvector-0.10.9.1-ghc7.8.0.20140226.dylib include
>>> libHSvector-0.10.9.1.a
>>>
>>> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/primitive-0.5.2.1/
>>> Control include libHSprimitive-0.5.2.1.a Data
>>> libHSprimitive-0.5.2.1-ghc7.8.0.20140226.dylib
>>>
>>> $ uname -a
>>> Darwin Calcifer.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19
>>> 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64
>>>
>>> There is certainly a dylib available for both of these libraries.
>>> You're going to need to be very explicit in what you did to install
>>> GHC, and how. (Did you use the binary distribution I pulled from the
>>> server?)* Unfortunately I'm about to run out the door, and don't have
>>> time for the next few hours closely investigate.
>>>
>>> * On another note, I will say that there is not an 'RC2' until I
>>> announce that it is so, to be completely honest. Right this second,
>>> some last minute fixes went into HEAD which will be merged for the
>>> actual RC2. Otherwise I would have released it today. But thank you
>>> for testing anyway!
>>>
>>> On Thu, Feb 27, 2014 at 5:53 PM, George Colpitts
>>> <george.colpitts at gmail.com> wrote:
>>> > corrected subject line
>>> >
>>> >
>>> > On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts <
>>> george.colpitts at gmail.com>
>>> > wrote:
>>> >>
>>> >> Hi
>>> >>
>>> >> After installing the first version of RC2 I ran into the following
>>> problem
>>> >>
>>> >>  cabal install vector
>>> >> Resolving dependencies...
>>> >> Configuring vector-0.10.9.1...
>>> >> ...
>>> >> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
>>> >> Data/Vector/Fusion/Stream/Monadic.hs,
>>> >> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
>>> >> Loading package ghc-prim ... linking ... done.
>>> >> Loading package integer-gmp ... linking ... done.
>>> >> Loading package base ... linking ... done.
>>> >> Loading package primitive-0.5.2.1 ... <command line>: can't load
>>> .so/.DLL
>>> >> for: libHSprimitive-0.5.2.1.dylib
>>> (dlopen(libHSprimitive-0.5.2.1.dylib, 9):
>>> >> image not found)
>>> >>
>>> >> There seems to be a general problem that the install did not produce
>>> any
>>> >> dynamic libraries at least on the Mac:
>>> >>
>>> >>  ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
>>> >>
>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
>>> >> HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a
>>> libHScpphs-1.18.2_p.a
>>> >>
>>> >>
>>> >>
>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
>>> >> Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a
>>> >> libHShashable-1.2.1.0_p.a
>>> >>
>>> >>
>>> >>
>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
>>> >> HShscolour-1.20.3.o Language libHShscolour-1.20.3.a
>>> >> libHShscolour-1.20.3_p.a
>>> >>
>>> >>
>>> >>
>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
>>> >> Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
>>> >> Data include libHSprimitive-0.5.2.1_p.a
>>> >>
>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
>>> >> Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a
>>> >>
>>> >>
>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
>>> >> Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a
>>> >>
>>> >>
>>> >>
>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
>>> >> Data libHSunordered-containers-0.2.3.3.a
>>> >> HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > ghc-devs mailing list
>>> > ghc-devs at haskell.org
>>>
>>>
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140227/a8a5c1d2/attachment.html>

From george.colpitts at gmail.com  Fri Feb 28 02:37:53 2014
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 27 Feb 2014 22:37:53 -0400
Subject: first version of RC2 has problems with lack of dynamic libraries
 at least on the Mac
In-Reply-To: <CAHYVw0wdGEsffbwYWSjkK27oZyqDVcRnuwOGK8LiGy6pw3Lp8Q@mail.gmail.com>
References: <CAB-d4A4nsbibYGLb3GPwNBr_23+h6-m=E04iJfW-C0PFSzjZfA@mail.gmail.com>
 <CAEs96n2-MR5neqbhnD+ZRVW30i8C1G_NQi-M=bG1KeoPdUunrA@mail.gmail.com>
 <CAB-d4A5twNF7-gWO7b1thko2mWwBJitpaXTz1maGr5TiyXpMRw@mail.gmail.com>
 <CAEs96n3k_GfhOfnBjCAY=Z+=NBQ=_mwgcbvLEE0aeSB4ORUkCw@mail.gmail.com>
 <CAB-d4A7Wx_ROS4WO2CMg_ZTgttuzegFmeRjiHKYFn3W5OSaCDg@mail.gmail.com>
 <CAHYVw0wdGEsffbwYWSjkK27oZyqDVcRnuwOGK8LiGy6pw3Lp8Q@mail.gmail.com>
Message-ID: <CAB-d4A6hcWeMxrXXn=ggT70ATpkKzFs3Nk_RAPpMSXE_yK6PKQ@mail.gmail.com>

I am sad. How do I uninstall the current version I have and install that
version?

Thanks


On Thu, Feb 27, 2014 at 10:27 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> you need cabal-install 1.18 or you'll be sad.
>
>
>
>
> On Thu, Feb 27, 2014 at 9:16 PM, George Colpitts <
> george.colpitts at gmail.com> wrote:
>
>> I'm using Cabal-1.18.1.3 and cabal-install version 1.16.0.2
>>
>>
>> On Thu, Feb 27, 2014 at 9:04 PM, Austin Seipp <austin at well-typed.com>wrote:
>>
>>> Thanks. Another question is what version of Cabal you are using, as it
>>> knows how to build dylibs properly. I'm using cabal 1.18.
>>>
>>> To delete the RC, you can just delete the directory it installed into
>>> (the GHC-7.8.xxxxx folder). Also make sure you remove the executables from
>>> $PATH
>>>
>>> And no worries about any unnecessary work. I'm here to do the release
>>> after all, and feedback is helpful!
>>>
>>>
>>> On Thursday, February 27, 2014, George Colpitts <
>>> george.colpitts at gmail.com> wrote:
>>>
>>>> Probably my error, I just wanted to make sure there wasn't a problem
>>>> that was missed. Thanks for checking. Sorry for any confusion I caused.
>>>>
>>>> Here are the details of what I did:
>>>>
>>>> I took ghc-7.8.0.20140226-x86_64-apple-darwin-mavericks.tar.bz2 from
>>>> http://www.haskell.org/ghc/dist/7.8.1-rc2/ and followed the
>>>> instructions in the INSTALL file to install it, i.e.
>>>>
>>>> One possible difference is that my gcc is gcc-4.8 from gnu not gcc from
>>>> Apple.
>>>>
>>>> Also my uname output is different than yours:
>>>>
>>>> uname -a
>>>> Darwin iMac27-5.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
>>>> 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
>>>>
>>>>
>>>> Finally I am running XCode 5.2
>>>>
>>>> Is there a to uninstall or clean these RCs?
>>>>
>>>> I'll wait for official notice before trying anything else
>>>>
>>>> I really appreciate all your work and I'm sorry if I caused you any
>>>> unnecessary work. I had no problems installing RC1 so may have been
>>>> overconfident
>>>>
>>>>
>>>> On Thu, Feb 27, 2014 at 8:05 PM, Austin Seipp <austin at well-typed.com>wrote:
>>>>
>>>> I just tested this and cannot reproduce it:
>>>>
>>>> $ cabal install vector
>>>> ... building ...
>>>>
>>>> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/vector-0.10.9.1
>>>> Data libHSvector-0.10.9.1-ghc7.8.0.20140226.dylib include
>>>> libHSvector-0.10.9.1.a
>>>>
>>>> $ ls
>>>> /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/primitive-0.5.2.1/
>>>> Control include libHSprimitive-0.5.2.1.a Data
>>>> libHSprimitive-0.5.2.1-ghc7.8.0.20140226.dylib
>>>>
>>>> $ uname -a
>>>> Darwin Calcifer.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19
>>>> 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64
>>>>
>>>> There is certainly a dylib available for both of these libraries.
>>>> You're going to need to be very explicit in what you did to install
>>>> GHC, and how. (Did you use the binary distribution I pulled from the
>>>> server?)* Unfortunately I'm about to run out the door, and don't have
>>>> time for the next few hours closely investigate.
>>>>
>>>> * On another note, I will say that there is not an 'RC2' until I
>>>> announce that it is so, to be completely honest. Right this second,
>>>> some last minute fixes went into HEAD which will be merged for the
>>>> actual RC2. Otherwise I would have released it today. But thank you
>>>> for testing anyway!
>>>>
>>>> On Thu, Feb 27, 2014 at 5:53 PM, George Colpitts
>>>> <george.colpitts at gmail.com> wrote:
>>>> > corrected subject line
>>>> >
>>>> >
>>>> > On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts <
>>>> george.colpitts at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Hi
>>>> >>
>>>> >> After installing the first version of RC2 I ran into the following
>>>> problem
>>>> >>
>>>> >>  cabal install vector
>>>> >> Resolving dependencies...
>>>> >> Configuring vector-0.10.9.1...
>>>> >> ...
>>>> >> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
>>>> >> Data/Vector/Fusion/Stream/Monadic.hs,
>>>> >> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
>>>> >> Loading package ghc-prim ... linking ... done.
>>>> >> Loading package integer-gmp ... linking ... done.
>>>> >> Loading package base ... linking ... done.
>>>> >> Loading package primitive-0.5.2.1 ... <command line>: can't load
>>>> .so/.DLL
>>>> >> for: libHSprimitive-0.5.2.1.dylib
>>>> (dlopen(libHSprimitive-0.5.2.1.dylib, 9):
>>>> >> image not found)
>>>> >>
>>>> >> There seems to be a general problem that the install did not produce
>>>> any
>>>> >> dynamic libraries at least on the Mac:
>>>> >>
>>>> >>  ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
>>>> >>
>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
>>>> >> HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a
>>>> libHScpphs-1.18.2_p.a
>>>> >>
>>>> >>
>>>> >>
>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
>>>> >> Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a
>>>> >> libHShashable-1.2.1.0_p.a
>>>> >>
>>>> >>
>>>> >>
>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
>>>> >> HShscolour-1.20.3.o Language libHShscolour-1.20.3.a
>>>> >> libHShscolour-1.20.3_p.a
>>>> >>
>>>> >>
>>>> >>
>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
>>>> >> Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
>>>> >> Data include libHSprimitive-0.5.2.1_p.a
>>>> >>
>>>> >>
>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
>>>> >> Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a
>>>> >>
>>>> >>
>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
>>>> >> Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a
>>>> >>
>>>> >>
>>>> >>
>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
>>>> >> Data libHSunordered-containers-0.2.3.3.a
>>>> >> HSunordered-containers-0.2.3.3.o
>>>> libHSunordered-containers-0.2.3.3_p.a
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > ghc-devs mailing list
>>>> > ghc-devs at haskell.org
>>>>
>>>>
>>>
>>> --
>>> Regards,
>>>
>>> Austin Seipp, Haskell Consultant
>>> Well-Typed LLP, http://www.well-typed.com/
>>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140227/e3217dcd/attachment-0001.html>

From ralph.benzinger at sap.com  Fri Feb 28 08:48:21 2014
From: ralph.benzinger at sap.com (Benzinger, Ralph)
Date: Fri, 28 Feb 2014 08:48:21 +0000
Subject: Runtime error using LLVM bitcode execution
In-Reply-To: <530DA1A1.7040600@gmail.com>
References: <06032AAF9E11164BB3D2827F725F47985C5C5AB8@DEWDFEMB12B.global.corp.sap>
 <530DA1A1.7040600@gmail.com>
Message-ID: <06032AAF9E11164BB3D2827F725F47985C5C6718@DEWDFEMB12B.global.corp.sap>

Hello Simon,

Thanks for your suggestion!  I ran the LLVM mangler against the hfun.ll file, but it didn't make any changes to the code at all.  (My understanding is that I can leave the hfun_stub alone.)

Am I missing something?

Regards
Ralph


-----Original Message-----
From: Simon Marlow [mailto:marlowsd at gmail.com] 
Sent: Mittwoch, 26. Februar 2014 09:11
To: Benzinger, Ralph; ghc-devs at haskell.org
Subject: Re: Runtime error using LLVM bitcode execution

My guess is that this isn't working because GHC needs to post-process 
the assembly generated by LLVM to support tables-next-to-code.  You 
could extract this phase from GHC (it's just one module, in 
compiler/llvmGen/LlvmMangler.hs) and run it as a standalone program.

Cheers,
Simon

On 21/02/2014 16:02, Benzinger, Ralph wrote:
> Hello,
>
> My apologies in advance if this mailing list is not the appropriate
> address for posting my problem with the GHC runtime, but it seemed
> like the best option on the GHC home page.
>
> I'm trying to execute standalone Haskell functions exported via FFI
> and compiled as LLVM bitcode.  Unfortunately, all my efforts yield the
> following runtime error:
>
> lu003107:~/hs-bitcode> ./bce_so hsallinone.bc
> hs_init complete
> hs_add_root complete
> hsallinone: internal error: stg_ap_p_ret
>      (GHC version 7.6.3 for x86_64_unknown_linux)
>      Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
> 0  bce_so               0x0000000000d6b310
> 1  bce_so               0x0000000000d6b53b
> 2  bce_so               0x0000000000d6ba1c
> 3  libpthread.so.0      0x00007f7683298800
> 4  libc.so.6            0x00007f7682592b35 gsignal + 53
> 5  libc.so.6            0x00007f7682594111 abort + 385
> 6  libHSrts-ghc7.6.3.so 0x00007f7683f6ca21 rtsFatalInternalErrorFn + 177
> 7  libHSrts-ghc7.6.3.so 0x00007f7683f6cce1 barf + 145
> 8  libHSrts-ghc7.6.3.so 0x00007f7683f8a24a stg_ap_p_info + 130
> Stack dump:
> 0.      Program arguments: ./bce_so hsallinone.bc
> Aborted
>
> This is what I do:
>
> I have a function hfun.hs that exports a function
>
>      foreign export ccall hfun :: CInt -> CInt
>
> and a wrapper cmain.c that calls this function:
>
>      #include <HsFFI.h>
>      #include "hfun_stub.h"
>      extern void __stginit_HFun(void);
>      #include <stdio.h>
>
>      int main(int argc, char *argv[])
>      {
> 	hs_init(&argc, &argv);
> 	printf("hs_init complete\n");
>
> 	hs_add_root(__stginit_HFun);
>      	printf("hs_add_root complete\n");
>
>      	int i = hfun(42);
>      	printf("hfun(42) = %d\n", i);
>
>      	hs_exit();
>      	return 0;
>      }
>
> To generate a callable bitcode file I use these commands:
>
>      $ ghc -S -keep-llvm-files -keep-tmp-files hfun.hs
>      $ llvm-as hfun.ll
>      $ cp /tmp/... hfun_stub.c
>      $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include hfun_stub.c
>      $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include cmain.c
>      $ llvm-link cmain.bc hfun_stub.bc hfun.bc -o hsallinone.bc
>
> My main program "bce_so" loads the linked bitcode and feeds it to the
> LLVM execution engine.  All required Haskell runtime libraries are
> linked dynamically against bce_so.
>
> Could you kindly provide some insight on whether this runtime error is
> due to a bug with GHC (unlikely) or rather some negligence in my
> setup?  Or does the issue highlight some principal limitation in my
> (admittedly somewhat naive) approach of using LLVM -- threading
> support, maybe?
>
> Note that compiling hfun.hs/cmain.c into a .so and executing
> everything natively using ldload() works flawlessly.
>
> Regards
> Ralph
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hfun.ll
Type: application/octet-stream
Size: 42784 bytes
Desc: hfun.ll
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/42852ab9/attachment-0001.obj>

From marlowsd at gmail.com  Fri Feb 28 09:42:39 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 28 Feb 2014 09:42:39 +0000
Subject: Runtime error using LLVM bitcode execution
In-Reply-To: <06032AAF9E11164BB3D2827F725F47985C5C6718@DEWDFEMB12B.global.corp.sap>
References: <06032AAF9E11164BB3D2827F725F47985C5C5AB8@DEWDFEMB12B.global.corp.sap>
 <530DA1A1.7040600@gmail.com>
 <06032AAF9E11164BB3D2827F725F47985C5C6718@DEWDFEMB12B.global.corp.sap>
Message-ID: <53105A0F.8020407@gmail.com>

You need to run it against the assembly file (.s) that LLVM generates, 
not the .ll file.

Cheers,
Simon

On 28/02/2014 08:48, Benzinger, Ralph wrote:
> Hello Simon,
>
> Thanks for your suggestion!  I ran the LLVM mangler against the hfun.ll file, but it didn't make any changes to the code at all.  (My understanding is that I can leave the hfun_stub alone.)
>
> Am I missing something?
>
> Regards
> Ralph
>
>
> -----Original Message-----
> From: Simon Marlow [mailto:marlowsd at gmail.com]
> Sent: Mittwoch, 26. Februar 2014 09:11
> To: Benzinger, Ralph; ghc-devs at haskell.org
> Subject: Re: Runtime error using LLVM bitcode execution
>
> My guess is that this isn't working because GHC needs to post-process
> the assembly generated by LLVM to support tables-next-to-code.  You
> could extract this phase from GHC (it's just one module, in
> compiler/llvmGen/LlvmMangler.hs) and run it as a standalone program.
>
> Cheers,
> Simon
>
> On 21/02/2014 16:02, Benzinger, Ralph wrote:
>> Hello,
>>
>> My apologies in advance if this mailing list is not the appropriate
>> address for posting my problem with the GHC runtime, but it seemed
>> like the best option on the GHC home page.
>>
>> I'm trying to execute standalone Haskell functions exported via FFI
>> and compiled as LLVM bitcode.  Unfortunately, all my efforts yield the
>> following runtime error:
>>
>> lu003107:~/hs-bitcode> ./bce_so hsallinone.bc
>> hs_init complete
>> hs_add_root complete
>> hsallinone: internal error: stg_ap_p_ret
>>       (GHC version 7.6.3 for x86_64_unknown_linux)
>>       Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>> 0  bce_so               0x0000000000d6b310
>> 1  bce_so               0x0000000000d6b53b
>> 2  bce_so               0x0000000000d6ba1c
>> 3  libpthread.so.0      0x00007f7683298800
>> 4  libc.so.6            0x00007f7682592b35 gsignal + 53
>> 5  libc.so.6            0x00007f7682594111 abort + 385
>> 6  libHSrts-ghc7.6.3.so 0x00007f7683f6ca21 rtsFatalInternalErrorFn + 177
>> 7  libHSrts-ghc7.6.3.so 0x00007f7683f6cce1 barf + 145
>> 8  libHSrts-ghc7.6.3.so 0x00007f7683f8a24a stg_ap_p_info + 130
>> Stack dump:
>> 0.      Program arguments: ./bce_so hsallinone.bc
>> Aborted
>>
>> This is what I do:
>>
>> I have a function hfun.hs that exports a function
>>
>>       foreign export ccall hfun :: CInt -> CInt
>>
>> and a wrapper cmain.c that calls this function:
>>
>>       #include <HsFFI.h>
>>       #include "hfun_stub.h"
>>       extern void __stginit_HFun(void);
>>       #include <stdio.h>
>>
>>       int main(int argc, char *argv[])
>>       {
>> 	hs_init(&argc, &argv);
>> 	printf("hs_init complete\n");
>>
>> 	hs_add_root(__stginit_HFun);
>>       	printf("hs_add_root complete\n");
>>
>>       	int i = hfun(42);
>>       	printf("hfun(42) = %d\n", i);
>>
>>       	hs_exit();
>>       	return 0;
>>       }
>>
>> To generate a callable bitcode file I use these commands:
>>
>>       $ ghc -S -keep-llvm-files -keep-tmp-files hfun.hs
>>       $ llvm-as hfun.ll
>>       $ cp /tmp/... hfun_stub.c
>>       $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include hfun_stub.c
>>       $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include cmain.c
>>       $ llvm-link cmain.bc hfun_stub.bc hfun.bc -o hsallinone.bc
>>
>> My main program "bce_so" loads the linked bitcode and feeds it to the
>> LLVM execution engine.  All required Haskell runtime libraries are
>> linked dynamically against bce_so.
>>
>> Could you kindly provide some insight on whether this runtime error is
>> due to a bug with GHC (unlikely) or rather some negligence in my
>> setup?  Or does the issue highlight some principal limitation in my
>> (admittedly somewhat naive) approach of using LLVM -- threading
>> support, maybe?
>>
>> Note that compiling hfun.hs/cmain.c into a .so and executing
>> everything natively using ldload() works flawlessly.
>>
>> Regards
>> Ralph
>>

From johan.tibell at gmail.com  Fri Feb 28 10:45:18 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 28 Feb 2014 11:45:18 +0100
Subject: What does the DWARF information generated by your GHC branch look
 like?
In-Reply-To: <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
Message-ID: <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>

On Thu, Feb 27, 2014 at 6:43 PM, Peter Wortmann <scpmw at leeds.ac.uk> wrote:

>
> Johan Tibell wrote:
> > I enjoyed reading your paper [1] and I have some questions.
>
> Thanks! The DWARF patches are currently under review for Trac #3693. Any
> feedback would be very appreciated:
> https://github.com/scpmw/ghc/commits/profiling-import


I haven't had time to look at it all. I added a comment on
https://github.com/scpmw/ghc/commit/bbf6f35d8c341c8aadca1a48657084c007837b21


> >  will you fill in the .debug_line section so that standard tools like
>  > "perf report" and gprof can be used on Haskell code?
>
> Yes, even though from a few quick tests the results of "perf report"
> aren't too useful, as source code links are pretty coarse and jump
> around a lot - especially for optimised Haskell code. There's the option
> to instead annotate with source code links to a generated ".dump-simpl"
> file, which might turn out to be more useful.
>

I think that in general we should be as "standard" (i.e. close to how e.g.
GCC uses DWARF) as possible and put extra information in e.g. .debug_ghc.
That way we maximize the chance that standard tools will do something
sensible.


> > Code pointers would be appreciated.
>
> Is this about how .debug_line information is generated? We take the same
> approach as LLVM (and GCC, I think) and simply annotate the assembly
> with suitable .file & .loc directives. That way we can leave all the
> heavy lifting to the assembler.
>
> Current patch is here:
> https://github.com/scpmw/ghc/commit/c5294576


Makes sense. Thanks.


> >  * Does your GHC allow DWARF information to be generated without
> > actually using any of the RTS (e.g. eventlog) machinery?
>
> The RTS just serves as a DWARF interpreter for its own executable (+
> libraries) in this, so yes, it's fully independent. On the other hand,
> having special code allows us to avoid a few subtleties about Haskell
> code that are hard to communicate to standard debugging tools
> (especially concerning stack tracing).
>

Sounds good. As long as it's possible to use this without the RTS/eventlog
support I be happy. I have profiling needs (e.g. in unordered-containers)
were changes in the <5% are interesting and any extra overhead will skew
the results.


> > Another way to ask the same question, do you have a ghc -g flag that
> > has no implication for the runtime settings?
>
> Right now -g does not affect the RTS at all. We might want to change
> that at some point though so we can get rid of the libdwarf dependency.
>

That sounds good (the don't affect the RTS part). I didn't understand the
libdwarf part.


> >  * Do you generate DW_TAG_subprogram sections in the .debug_info
> > section so that other tools can figure out the name of Haskell
> > functions?
>
> Yes, we are setting the "name" attribute to a suitable Haskell name.
> Sadly, at least GDB seems to ignore it and falls back to the symbol
> name. I investigated this some time ago, and I think the reason was that
> it doesn't recognize the Haskell language ID (which isn't standardized,
> obviously). Simply pretending to be C(++) might fix this, but I would be
> a bit scared of other side-effects.
>

Lets try to get our name standardized and pushed into GDB. It's hopefully
as simple as sending an email to the GDB devs.

Cheers,
Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/df226ddd/attachment.html>

From juhpetersen at gmail.com  Fri Feb 28 13:40:49 2014
From: juhpetersen at gmail.com (Jens Petersen)
Date: Fri, 28 Feb 2014 22:40:49 +0900
Subject: RC2 release imminent
In-Reply-To: <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
Message-ID: <CAEDGBqLRsXbARK=o1D-MYfxkiaQ_sjipNimQYHpXSNcHZkwbow@mail.gmail.com>

2014/02/27 9:14 "Austin Seipp" <austin at well-typed.com>:
> http://www.haskell.org/ghc/dist/7.8.1-rc2/

Thanks! I did a test build for Fedora Rawhide (F21 devel):

http://koji.fedoraproject.org/koji/taskinfo?taskID=6579613

from the txz file (this build is without testsuite and prof).
I haven't had a chance to test it yet.

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/ff3708f1/attachment.html>

From george.colpitts at gmail.com  Fri Feb 28 14:13:46 2014
From: george.colpitts at gmail.com (George Colpitts)
Date: Fri, 28 Feb 2014 10:13:46 -0400
Subject: first version of RC2 has problems with lack of dynamic libraries
 at least on the Mac
In-Reply-To: <CAB-d4A6hcWeMxrXXn=ggT70ATpkKzFs3Nk_RAPpMSXE_yK6PKQ@mail.gmail.com>
References: <CAB-d4A4nsbibYGLb3GPwNBr_23+h6-m=E04iJfW-C0PFSzjZfA@mail.gmail.com>
 <CAEs96n2-MR5neqbhnD+ZRVW30i8C1G_NQi-M=bG1KeoPdUunrA@mail.gmail.com>
 <CAB-d4A5twNF7-gWO7b1thko2mWwBJitpaXTz1maGr5TiyXpMRw@mail.gmail.com>
 <CAEs96n3k_GfhOfnBjCAY=Z+=NBQ=_mwgcbvLEE0aeSB4ORUkCw@mail.gmail.com>
 <CAB-d4A7Wx_ROS4WO2CMg_ZTgttuzegFmeRjiHKYFn3W5OSaCDg@mail.gmail.com>
 <CAHYVw0wdGEsffbwYWSjkK27oZyqDVcRnuwOGK8LiGy6pw3Lp8Q@mail.gmail.com>
 <CAB-d4A6hcWeMxrXXn=ggT70ATpkKzFs3Nk_RAPpMSXE_yK6PKQ@mail.gmail.com>
Message-ID: <CAB-d4A7C9YjL7oSikM0+oPMnmK4J+ZAUvzLCdGpAD_DYq7p_1g@mail.gmail.com>

Thanks for everybody's help. I got the latest versions of cabal, installed
the "early" version of RC2 and then cabal install vector worked


On Thu, Feb 27, 2014 at 10:37 PM, George Colpitts <george.colpitts at gmail.com
> wrote:

> I am sad. How do I uninstall the current version I have and install that
> version?
>
> Thanks
>
>
> On Thu, Feb 27, 2014 at 10:27 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> you need cabal-install 1.18 or you'll be sad.
>>
>>
>>
>>
>> On Thu, Feb 27, 2014 at 9:16 PM, George Colpitts <
>> george.colpitts at gmail.com> wrote:
>>
>>> I'm using Cabal-1.18.1.3 and cabal-install version 1.16.0.2
>>>
>>>
>>> On Thu, Feb 27, 2014 at 9:04 PM, Austin Seipp <austin at well-typed.com>wrote:
>>>
>>>> Thanks. Another question is what version of Cabal you are using, as it
>>>> knows how to build dylibs properly. I'm using cabal 1.18.
>>>>
>>>> To delete the RC, you can just delete the directory it installed into
>>>> (the GHC-7.8.xxxxx folder). Also make sure you remove the executables from
>>>> $PATH
>>>>
>>>> And no worries about any unnecessary work. I'm here to do the release
>>>> after all, and feedback is helpful!
>>>>
>>>>
>>>> On Thursday, February 27, 2014, George Colpitts <
>>>> george.colpitts at gmail.com> wrote:
>>>>
>>>>> Probably my error, I just wanted to make sure there wasn't a problem
>>>>> that was missed. Thanks for checking. Sorry for any confusion I caused.
>>>>>
>>>>> Here are the details of what I did:
>>>>>
>>>>> I took ghc-7.8.0.20140226-x86_64-apple-darwin-mavericks.tar.bz2 from
>>>>> http://www.haskell.org/ghc/dist/7.8.1-rc2/ and followed the
>>>>> instructions in the INSTALL file to install it, i.e.
>>>>>
>>>>> One possible difference is that my gcc is gcc-4.8 from gnu not gcc
>>>>> from Apple.
>>>>>
>>>>> Also my uname output is different than yours:
>>>>>
>>>>> uname -a
>>>>> Darwin iMac27-5.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
>>>>> 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
>>>>>
>>>>>
>>>>> Finally I am running XCode 5.2
>>>>>
>>>>> Is there a to uninstall or clean these RCs?
>>>>>
>>>>> I'll wait for official notice before trying anything else
>>>>>
>>>>> I really appreciate all your work and I'm sorry if I caused you any
>>>>> unnecessary work. I had no problems installing RC1 so may have been
>>>>> overconfident
>>>>>
>>>>>
>>>>> On Thu, Feb 27, 2014 at 8:05 PM, Austin Seipp <austin at well-typed.com>wrote:
>>>>>
>>>>> I just tested this and cannot reproduce it:
>>>>>
>>>>> $ cabal install vector
>>>>> ... building ...
>>>>>
>>>>> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/vector-0.10.9.1
>>>>> Data libHSvector-0.10.9.1-ghc7.8.0.20140226.dylib include
>>>>> libHSvector-0.10.9.1.a
>>>>>
>>>>> $ ls
>>>>> /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/primitive-0.5.2.1/
>>>>> Control include libHSprimitive-0.5.2.1.a Data
>>>>> libHSprimitive-0.5.2.1-ghc7.8.0.20140226.dylib
>>>>>
>>>>> $ uname -a
>>>>> Darwin Calcifer.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19
>>>>> 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64
>>>>>
>>>>> There is certainly a dylib available for both of these libraries.
>>>>> You're going to need to be very explicit in what you did to install
>>>>> GHC, and how. (Did you use the binary distribution I pulled from the
>>>>> server?)* Unfortunately I'm about to run out the door, and don't have
>>>>> time for the next few hours closely investigate.
>>>>>
>>>>> * On another note, I will say that there is not an 'RC2' until I
>>>>> announce that it is so, to be completely honest. Right this second,
>>>>> some last minute fixes went into HEAD which will be merged for the
>>>>> actual RC2. Otherwise I would have released it today. But thank you
>>>>> for testing anyway!
>>>>>
>>>>> On Thu, Feb 27, 2014 at 5:53 PM, George Colpitts
>>>>> <george.colpitts at gmail.com> wrote:
>>>>> > corrected subject line
>>>>> >
>>>>> >
>>>>> > On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts <
>>>>> george.colpitts at gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Hi
>>>>> >>
>>>>> >> After installing the first version of RC2 I ran into the following
>>>>> problem
>>>>> >>
>>>>> >>  cabal install vector
>>>>> >> Resolving dependencies...
>>>>> >> Configuring vector-0.10.9.1...
>>>>> >> ...
>>>>> >> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
>>>>> >> Data/Vector/Fusion/Stream/Monadic.hs,
>>>>> >> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
>>>>> >> Loading package ghc-prim ... linking ... done.
>>>>> >> Loading package integer-gmp ... linking ... done.
>>>>> >> Loading package base ... linking ... done.
>>>>> >> Loading package primitive-0.5.2.1 ... <command line>: can't load
>>>>> .so/.DLL
>>>>> >> for: libHSprimitive-0.5.2.1.dylib
>>>>> (dlopen(libHSprimitive-0.5.2.1.dylib, 9):
>>>>> >> image not found)
>>>>> >>
>>>>> >> There seems to be a general problem that the install did not
>>>>> produce any
>>>>> >> dynamic libraries at least on the Mac:
>>>>> >>
>>>>> >>  ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
>>>>> >>
>>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
>>>>> >> HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a
>>>>> libHScpphs-1.18.2_p.a
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
>>>>> >> Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a
>>>>> >> libHShashable-1.2.1.0_p.a
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
>>>>> >> HShscolour-1.20.3.o Language libHShscolour-1.20.3.a
>>>>> >> libHShscolour-1.20.3_p.a
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
>>>>> >> Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
>>>>> >> Data include libHSprimitive-0.5.2.1_p.a
>>>>> >>
>>>>> >>
>>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
>>>>> >> Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a
>>>>> >>
>>>>> >>
>>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
>>>>> >> Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
>>>>> >> Data libHSunordered-containers-0.2.3.3.a
>>>>> >> HSunordered-containers-0.2.3.3.o
>>>>> libHSunordered-containers-0.2.3.3_p.a
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > ghc-devs mailing list
>>>>> > ghc-devs at haskell.org
>>>>>
>>>>>
>>>>
>>>> --
>>>> Regards,
>>>>
>>>> Austin Seipp, Haskell Consultant
>>>> Well-Typed LLP, http://www.well-typed.com/
>>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/2179a561/attachment.html>

From johan.tibell at gmail.com  Fri Feb 28 15:34:39 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 28 Feb 2014 16:34:39 +0100
Subject: What does the DWARF information generated by your GHC branch look
 like?
In-Reply-To: <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>
 <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
Message-ID: <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>

On Fri, Feb 28, 2014 at 3:15 PM, Peter Wortmann <scpmw at leeds.ac.uk> wrote:

> Johan Tibell wrote:> Lets try to get our name standardized and pushed into
> GDB. It's
> > hopefully as simple as sending an email to the GDB devs.
>
> Strictly speaking standardization is the job of the DWARF format
> committee, which seem to currently be in the process of specifying
> DWARF5[1]. Not quite sure we have a strong enough case, but if we wanted
> our own language ID these would probably be the right people to ask.
>

I just emailed the DWARF discussion mailing list to sort this out.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/2f2e6cb2/attachment.html>

From johan.tibell at gmail.com  Fri Feb 28 15:36:58 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 28 Feb 2014 16:36:58 +0100
Subject: What does the DWARF information generated by your GHC branch look
 like?
In-Reply-To: <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>
 <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
Message-ID: <CAK-tuPbPi3AktBeTYnN93pg1P=2yxC3GPcj=uU3t3vtdjD9CyQ@mail.gmail.com>

Yes another question while I have you on the line. :)

Do we follow the best practices here:
http://wiki.dwarfstd.org/index.php?title=Best_Practices

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/294e9d32/attachment-0001.html>

From austin at well-typed.com  Fri Feb 28 15:51:15 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 28 Feb 2014 09:51:15 -0600
Subject: first version of RC2 has problems with lack of dynamic libraries
 at least on the Mac
In-Reply-To: <CAB-d4A7C9YjL7oSikM0+oPMnmK4J+ZAUvzLCdGpAD_DYq7p_1g@mail.gmail.com>
References: <CAB-d4A4nsbibYGLb3GPwNBr_23+h6-m=E04iJfW-C0PFSzjZfA@mail.gmail.com>
 <CAEs96n2-MR5neqbhnD+ZRVW30i8C1G_NQi-M=bG1KeoPdUunrA@mail.gmail.com>
 <CAB-d4A5twNF7-gWO7b1thko2mWwBJitpaXTz1maGr5TiyXpMRw@mail.gmail.com>
 <CAEs96n3k_GfhOfnBjCAY=Z+=NBQ=_mwgcbvLEE0aeSB4ORUkCw@mail.gmail.com>
 <CAB-d4A7Wx_ROS4WO2CMg_ZTgttuzegFmeRjiHKYFn3W5OSaCDg@mail.gmail.com>
 <CAHYVw0wdGEsffbwYWSjkK27oZyqDVcRnuwOGK8LiGy6pw3Lp8Q@mail.gmail.com>
 <CAB-d4A6hcWeMxrXXn=ggT70ATpkKzFs3Nk_RAPpMSXE_yK6PKQ@mail.gmail.com>
 <CAB-d4A7C9YjL7oSikM0+oPMnmK4J+ZAUvzLCdGpAD_DYq7p_1g@mail.gmail.com>
Message-ID: <CAEs96n0maJNAvJ43TE2SeJf-5Z8LEsDhiYEKo7oYbNW4CWAXZw@mail.gmail.com>

Thanks George. Since this might be confusing for users, I'll add a
note to to the release notes about requiring Cabal 1.18 for GHC to
work properly.

On Fri, Feb 28, 2014 at 8:13 AM, George Colpitts
<george.colpitts at gmail.com> wrote:
> Thanks for everybody's help. I got the latest versions of cabal, installed
> the "early" version of RC2 and then cabal install vector worked
>
>
> On Thu, Feb 27, 2014 at 10:37 PM, George Colpitts
> <george.colpitts at gmail.com> wrote:
>>
>> I am sad. How do I uninstall the current version I have and install that
>> version?
>>
>> Thanks
>>
>>
>> On Thu, Feb 27, 2014 at 10:27 PM, Carter Schonwald
>> <carter.schonwald at gmail.com> wrote:
>>>
>>> you need cabal-install 1.18 or you'll be sad.
>>>
>>>
>>>
>>>
>>> On Thu, Feb 27, 2014 at 9:16 PM, George Colpitts
>>> <george.colpitts at gmail.com> wrote:
>>>>
>>>> I'm using Cabal-1.18.1.3 and cabal-install version 1.16.0.2
>>>>
>>>>
>>>> On Thu, Feb 27, 2014 at 9:04 PM, Austin Seipp <austin at well-typed.com>
>>>> wrote:
>>>>>
>>>>> Thanks. Another question is what version of Cabal you are using, as it
>>>>> knows how to build dylibs properly. I'm using cabal 1.18.
>>>>>
>>>>> To delete the RC, you can just delete the directory it installed into
>>>>> (the GHC-7.8.xxxxx folder). Also make sure you remove the executables from
>>>>> $PATH
>>>>>
>>>>> And no worries about any unnecessary work. I'm here to do the release
>>>>> after all, and feedback is helpful!
>>>>>
>>>>>
>>>>> On Thursday, February 27, 2014, George Colpitts
>>>>> <george.colpitts at gmail.com> wrote:
>>>>>>
>>>>>> Probably my error, I just wanted to make sure there wasn't a problem
>>>>>> that was missed. Thanks for checking. Sorry for any confusion I caused.
>>>>>>
>>>>>> Here are the details of what I did:
>>>>>>
>>>>>> I took ghc-7.8.0.20140226-x86_64-apple-darwin-mavericks.tar.bz2 from
>>>>>> http://www.haskell.org/ghc/dist/7.8.1-rc2/ and followed the instructions in
>>>>>> the INSTALL file to install it, i.e.
>>>>>>
>>>>>> One possible difference is that my gcc is gcc-4.8 from gnu not gcc
>>>>>> from Apple.
>>>>>>
>>>>>> Also my uname output is different than yours:
>>>>>>
>>>>>> uname -a
>>>>>> Darwin iMac27-5.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
>>>>>> 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
>>>>>>
>>>>>>
>>>>>> Finally I am running XCode 5.2
>>>>>>
>>>>>> Is there a to uninstall or clean these RCs?
>>>>>>
>>>>>> I'll wait for official notice before trying anything else
>>>>>>
>>>>>> I really appreciate all your work and I'm sorry if I caused you any
>>>>>> unnecessary work. I had no problems installing RC1 so may have been
>>>>>> overconfident
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 27, 2014 at 8:05 PM, Austin Seipp <austin at well-typed.com>
>>>>>> wrote:
>>>>>>
>>>>>> I just tested this and cannot reproduce it:
>>>>>>
>>>>>> $ cabal install vector
>>>>>> ... building ...
>>>>>>
>>>>>> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/vector-0.10.9.1
>>>>>> Data libHSvector-0.10.9.1-ghc7.8.0.20140226.dylib include
>>>>>> libHSvector-0.10.9.1.a
>>>>>>
>>>>>> $ ls
>>>>>> /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/primitive-0.5.2.1/
>>>>>> Control include libHSprimitive-0.5.2.1.a Data
>>>>>> libHSprimitive-0.5.2.1-ghc7.8.0.20140226.dylib
>>>>>>
>>>>>> $ uname -a
>>>>>> Darwin Calcifer.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19
>>>>>> 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64
>>>>>>
>>>>>> There is certainly a dylib available for both of these libraries.
>>>>>> You're going to need to be very explicit in what you did to install
>>>>>> GHC, and how. (Did you use the binary distribution I pulled from the
>>>>>> server?)* Unfortunately I'm about to run out the door, and don't have
>>>>>> time for the next few hours closely investigate.
>>>>>>
>>>>>> * On another note, I will say that there is not an 'RC2' until I
>>>>>> announce that it is so, to be completely honest. Right this second,
>>>>>> some last minute fixes went into HEAD which will be merged for the
>>>>>> actual RC2. Otherwise I would have released it today. But thank you
>>>>>> for testing anyway!
>>>>>>
>>>>>> On Thu, Feb 27, 2014 at 5:53 PM, George Colpitts
>>>>>> <george.colpitts at gmail.com> wrote:
>>>>>> > corrected subject line
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts
>>>>>> > <george.colpitts at gmail.com>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> Hi
>>>>>> >>
>>>>>> >> After installing the first version of RC2 I ran into the following
>>>>>> >> problem
>>>>>> >>
>>>>>> >>  cabal install vector
>>>>>> >> Resolving dependencies...
>>>>>> >> Configuring vector-0.10.9.1...
>>>>>> >> ...
>>>>>> >> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
>>>>>> >> Data/Vector/Fusion/Stream/Monadic.hs,
>>>>>> >> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
>>>>>> >> Loading package ghc-prim ... linking ... done.
>>>>>> >> Loading package integer-gmp ... linking ... done.
>>>>>> >> Loading package base ... linking ... done.
>>>>>> >> Loading package primitive-0.5.2.1 ... <command line>: can't load
>>>>>> >> .so/.DLL
>>>>>> >> for: libHSprimitive-0.5.2.1.dylib
>>>>>> >> (dlopen(libHSprimitive-0.5.2.1.dylib, 9):
>>>>>> >> image not found)
>>>>>> >>
>>>>>> >> There seems to be a general problem that the install did not
>>>>>> >> produce any
>>>>>> >> dynamic libraries at least on the Mac:
>>>>>> >>
>>>>>> >>  ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
>>>>>> >>
>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
>>>>>> >> HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a
>>>>>> >> libHScpphs-1.18.2_p.a
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
>>>>>> >> Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a
>>>>>> >> libHShashable-1.2.1.0_p.a
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
>>>>>> >> HShscolour-1.20.3.o Language libHShscolour-1.20.3.a
>>>>>> >> libHShscolour-1.20.3_p.a
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
>>>>>> >> Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
>>>>>> >> Data include libHSprimitive-0.5.2.1_p.a
>>>>>> >>
>>>>>> >>
>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
>>>>>> >> Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a
>>>>>> >>
>>>>>> >>
>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
>>>>>> >> Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
>>>>>> >> Data libHSunordered-containers-0.2.3.3.a
>>>>>> >> HSunordered-containers-0.2.3.3.o
>>>>>> >> libHSunordered-containers-0.2.3.3_p.a
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > ghc-devs mailing list
>>>>>> > ghc-devs at haskell.org
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>>
>>>>> Austin Seipp, Haskell Consultant
>>>>> Well-Typed LLP, http://www.well-typed.com/
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>
>>>
>>
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Fri Feb 28 15:53:31 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 28 Feb 2014 09:53:31 -0600
Subject: What does the DWARF information generated by your GHC branch look
 like?
In-Reply-To: <CAK-tuPbPi3AktBeTYnN93pg1P=2yxC3GPcj=uU3t3vtdjD9CyQ@mail.gmail.com>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>
 <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
 <CAK-tuPbPi3AktBeTYnN93pg1P=2yxC3GPcj=uU3t3vtdjD9CyQ@mail.gmail.com>
Message-ID: <CAEs96n0YFBWj_JLW+oqT02FpXUjBqR8Pr9=1JEYm=+=TkyU8gQ@mail.gmail.com>

(Passive note - this conversation looks like Johan talking to himself,
as I suspect Peter is not 'reply all'-ing to the developers list. So
other people may be a tad lost.)

On Fri, Feb 28, 2014 at 9:36 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
> Yes another question while I have you on the line. :)
>
> Do we follow the best practices here:
> http://wiki.dwarfstd.org/index.php?title=Best_Practices
>
> -- Johan
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From johan.tibell at gmail.com  Fri Feb 28 15:55:34 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 28 Feb 2014 16:55:34 +0100
Subject: What does the DWARF information generated by your GHC branch look
 like?
In-Reply-To: <CAEs96n0YFBWj_JLW+oqT02FpXUjBqR8Pr9=1JEYm=+=TkyU8gQ@mail.gmail.com>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>
 <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
 <CAK-tuPbPi3AktBeTYnN93pg1P=2yxC3GPcj=uU3t3vtdjD9CyQ@mail.gmail.com>
 <CAEs96n0YFBWj_JLW+oqT02FpXUjBqR8Pr9=1JEYm=+=TkyU8gQ@mail.gmail.com>
Message-ID: <CAK-tuPaigcVMvPmEMBJzGeoneL42gnUVKKwrEenA+EfVJoPU-A@mail.gmail.com>

On Fri, Feb 28, 2014 at 4:53 PM, Austin Seipp <austin at well-typed.com> wrote:
> (Passive note - this conversation looks like Johan talking to himself,
> as I suspect Peter is not 'reply all'-ing to the developers list. So
> other people may be a tad lost.)

Nope, this is just me having a stream of consciousness discussion. If
you see 2 replies from Peter and 5 emails from me (including this
one), that's it. :)

From roma at ro-che.info  Fri Feb 28 15:57:58 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 28 Feb 2014 17:57:58 +0200
Subject: What does the DWARF information generated by your GHC branch
 look like?
In-Reply-To: <CAEs96n0YFBWj_JLW+oqT02FpXUjBqR8Pr9=1JEYm=+=TkyU8gQ@mail.gmail.com>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>
 <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
 <CAK-tuPbPi3AktBeTYnN93pg1P=2yxC3GPcj=uU3t3vtdjD9CyQ@mail.gmail.com>
 <CAEs96n0YFBWj_JLW+oqT02FpXUjBqR8Pr9=1JEYm=+=TkyU8gQ@mail.gmail.com>
Message-ID: <20140228155758.GA23468@sniper>

Or he's not subscribed to this list and his messages do not come through

* Austin Seipp <austin at well-typed.com> [2014-02-28 09:53:31-0600]
> (Passive note - this conversation looks like Johan talking to himself,
> as I suspect Peter is not 'reply all'-ing to the developers list. So
> other people may be a tad lost.)
> 
> On Fri, Feb 28, 2014 at 9:36 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
> > Yes another question while I have you on the line. :)
> >
> > Do we follow the best practices here:
> > http://wiki.dwarfstd.org/index.php?title=Best_Practices
> >
> > -- Johan
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
> 
> 
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/5e508540/attachment.sig>

From johan.tibell at gmail.com  Fri Feb 28 16:05:31 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 28 Feb 2014 17:05:31 +0100
Subject: What does the DWARF information generated by your GHC branch look
 like?
In-Reply-To: <20140228155758.GA23468@sniper>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>
 <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
 <CAK-tuPbPi3AktBeTYnN93pg1P=2yxC3GPcj=uU3t3vtdjD9CyQ@mail.gmail.com>
 <CAEs96n0YFBWj_JLW+oqT02FpXUjBqR8Pr9=1JEYm=+=TkyU8gQ@mail.gmail.com>
 <20140228155758.GA23468@sniper>
Message-ID: <CAK-tuPZ-vprCfrhX++W99j8sM1FZkJvTkynjfLMG4krdp4JUQg@mail.gmail.com>

On Fri, Feb 28, 2014 at 4:57 PM, Roman Cheplyaka <roma at ro-che.info> wrote:
> Or he's not subscribed to this list and his messages do not come through

Ah yes. From my end I can see that he tried to CC the mailing list,
but I missed that the messages didn't get through.

From scpmw at leeds.ac.uk  Fri Feb 28 16:08:54 2014
From: scpmw at leeds.ac.uk (Peter Wortmann)
Date: Fri, 28 Feb 2014 16:08:54 +0000
Subject: What does the DWARF information generated by your GHC branch
 look like?
In-Reply-To: <20140228155758.GA23468@sniper>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>
 <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
 <CAK-tuPbPi3AktBeTYnN93pg1P=2yxC3GPcj=uU3t3vtdjD9CyQ@mail.gmail.com>
 <CAEs96n0YFBWj_JLW+oqT02FpXUjBqR8Pr9=1JEYm=+=TkyU8gQ@mail.gmail.com>
 <20140228155758.GA23468@sniper>
Message-ID: <1393603734.3893.26.camel@cslin101.csunix.comp.leeds.ac.uk>


Roman Cheplyaka wrote:
> Or he's not subscribed to this list and his messages do not come through

Ah thanks, that's probably it. I accumulated lots of error mails from
the mailing list, which however didn't mention subscribing. Sorry about
the confusion...

Greetings,
  Peter Wortmann




From scpmw at leeds.ac.uk  Fri Feb 28 19:44:27 2014
From: scpmw at leeds.ac.uk (Peter Wortmann)
Date: Fri, 28 Feb 2014 19:44:27 +0000
Subject: What does the DWARF information generated by your GHC branch
 look like?
In-Reply-To: <CAK-tuPbPi3AktBeTYnN93pg1P=2yxC3GPcj=uU3t3vtdjD9CyQ@mail.gmail.com>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>
 <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
 <CAK-tuPbPi3AktBeTYnN93pg1P=2yxC3GPcj=uU3t3vtdjD9CyQ@mail.gmail.com>
Message-ID: <1393616667.3893.62.camel@cslin101.csunix.comp.leeds.ac.uk>


Johan Tibell wrote:
> Do we follow the best practices here: http://wiki.dwarfstd.org/index.php?title=Best_Practices

Not quite sure what exactly you are referring to, here's the current
state:

> For DW_TAG_compilation_unit and DW_TAG_partial_unit DIEs, the name
> attribute should contain the path name of the primary source file from
> which the compilation unit was derived (see Section 3.1.1).

Yes, we do that.

> If the compiler was invoked with a full path name, it is recommended
> to use the path name as given to the compiler, although it is
> considered acceptable to convert the path name to an equivalent path
> where none of the components is a symbolic link.

I am simply using ModLocation for this. The results make sense, even
though I haven't tried crazy symbolic link combinations yet. If we find
something to improve we should probably do it for GHC as a whole.

> combining the compilation directory (see DW_AT_comp_dir) with the
> relative path name.

We set this attribute, albeit simply using getCurrentDirectory. This
might be an oversight, but I couldn't see a location where GHC stores
the "compilation directory" path.

> For modules, subroutines, variables, parameters, constants, types, and
> labels, the DW_AT_name attribute should contain the name of the
> corresponding program object as it appears in the source code

We make a "best effort" to provide a suitable name for every single
procedure. Note that a single function in Haskell might become multiple
subroutines in DWARF - or not appear at all due to in-lining.

> In general, the value of DW_AT_name should be such that a
> fully-qualified name constructed from the DW_AT_name attributes of the
> object and its containing objects will uniquely represent that object
> in a form natural to the source language.

This would probably require us to have a DIE for modules. Not quite sure
how we would approach that.

> The producer may also generate a DW_AT_linkage_name attribute for
> program objects

We do that.

> In many cases, however, it is expensive for a consumer to parse the
> hierarchy, and the presence of the mangled name may be beneficial to
> performance.

This might be the underlying reason why it shows mangled names for
languages with unknown IDs (such as Haskell). We'll see whether Johan's
query to the GDB team brings some light into that.

Greetings,
  Peter Wortmann



From scpmw at leeds.ac.uk  Fri Feb 28 19:49:32 2014
From: scpmw at leeds.ac.uk (Peter Wortmann)
Date: Fri, 28 Feb 2014 19:49:32 +0000
Subject: What does the DWARF information generated by your GHC branch
 look like?
In-Reply-To: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
Message-ID: <1393616972.3893.64.camel@cslin101.csunix.comp.leeds.ac.uk>


[copy of the dropped reply, for anybody interested]

Johan Tibell wrote:
> I enjoyed reading your paper [1] and I have some questions.

Thanks! The DWARF patches are currently under review for Trac #3693. Any
feedback would be very appreciated:
https://github.com/scpmw/ghc/commits/profiling-import

>  * What does the generated DWARF information look like?

So far we generate:
- .debug_info: Information about all generated procedures and blocks.
- .debug_line: Source-code links for all generated code
- .debug_frame: Unwind information for the GHC stack
- .debug_ghc: Everything we can't properly represent as DWARF

>  will you fill in the .debug_line section so that standard tools like
> "perf report" and gprof can be used on Haskell code?

Yes, even though from a few quick tests the results of "perf report"
aren't too useful, as source code links are pretty coarse and jump
around a lot - especially for optimised Haskell code. There's the option
to instead annotate with source code links to a generated ".dump-simpl"
file, which might turn out to be more useful.

> Code pointers would be appreciated.

Is this about how .debug_line information is generated? We take the same
approach as LLVM (and GCC, I think) and simply annotate the assembly
with suitable .file & .loc directives. That way we can leave all the
heavy lifting to the assembler.

Current patch is here:
https://github.com/scpmw/ghc/commit/c5294576

>  * Does your GHC allow DWARF information to be generated without
> actually using any of the RTS (e.g. eventlog) machinery?

The RTS just serves as a DWARF interpreter for its own executable (+
libraries) in this, so yes, it's fully independent. On the other hand,
having special code allows us to avoid a few subtleties about Haskell
code that are hard to communicate to standard debugging tools
(especially concerning stack tracing).

> Another way to ask the same question, do you have a ghc -g flag that
> has no implication for the runtime settings?

Right now -g does not affect the RTS at all. We might want to change
that at some point though so we can get rid of the libdwarf dependency.

>  * Do you generate DW_TAG_subprogram sections in the .debug_info
> section so that other tools can figure out the name of Haskell
> functions?

Yes, we are setting the "name" attribute to a suitable Haskell name.
Sadly, at least GDB seems to ignore it and falls back to the symbol
name. I investigated this some time ago, and I think the reason was that
it doesn't recognize the Haskell language ID (which isn't standardized,
obviously). Simply pretending to be C(++) might fix this, but I would be
a bit scared of other side-effects.

Greetings,
  Peter Wortmann





From simonpj at microsoft.com  Fri Feb 28 21:00:40 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 28 Feb 2014 21:00:40 +0000
Subject: Clean build ASSERT failure
Message-ID: <59543203684B2244980D7E4057D5FBC1487CF716@DB3EX14MBXC306.europe.corp.microsoft.com>

I'm seeing this assertion failure when using the stage1 compiler (built with -DDEBUG) to compile the stage2 compiler.  Is anyone else seeing this?
Simon

ghc-stage1.exe: panic! (the 'impossible' happened)
  (GHC version 7.9.20140227 for i386-unknown-mingw32):
          ASSERT failed!
    file compiler\basicTypes\Demand.lhs line 445
    3
    [U]

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

compiler/ghc.mk:642: recipe for target 'compiler/stage2/build/ParserCore.o' failed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/2c6e605d/attachment.html>

From austin at well-typed.com  Fri Feb 28 22:37:37 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 28 Feb 2014 16:37:37 -0600
Subject: Clean build ASSERT failure
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487CF716@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC1487CF716@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <CAEs96n1UnJ5XJS8fQon-KpDRYXCH_DtxuPHnbStbmekuvf48yQ@mail.gmail.com>

I'm attempting to reproduce this now (but my build isn't finished),
since HEAD builds fine otherwise it seems. I assume you just set
GhcDebugged=YES in build.mk?

On Fri, Feb 28, 2014 at 3:00 PM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> I?m seeing this assertion failure when using the stage1 compiler (built with
> ?DDEBUG) to compile the stage2 compiler.  Is anyone else seeing this?
>
> Simon
>
>
>
> ghc-stage1.exe: panic! (the 'impossible' happened)
>
>   (GHC version 7.9.20140227 for i386-unknown-mingw32):
>
>           ASSERT failed!
>
>     file compiler\basicTypes\Demand.lhs line 445
>
>     3
>
>     [U]
>
>
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
>
>
> compiler/ghc.mk:642: recipe for target 'compiler/stage2/build/ParserCore.o'
> failed
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Fri Feb 28 22:42:54 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 28 Feb 2014 16:42:54 -0600
Subject: first version of RC2 has problems with lack of dynamic libraries
 at least on the Mac
In-Reply-To: <CAEs96n0maJNAvJ43TE2SeJf-5Z8LEsDhiYEKo7oYbNW4CWAXZw@mail.gmail.com>
References: <CAB-d4A4nsbibYGLb3GPwNBr_23+h6-m=E04iJfW-C0PFSzjZfA@mail.gmail.com>
 <CAEs96n2-MR5neqbhnD+ZRVW30i8C1G_NQi-M=bG1KeoPdUunrA@mail.gmail.com>
 <CAB-d4A5twNF7-gWO7b1thko2mWwBJitpaXTz1maGr5TiyXpMRw@mail.gmail.com>
 <CAEs96n3k_GfhOfnBjCAY=Z+=NBQ=_mwgcbvLEE0aeSB4ORUkCw@mail.gmail.com>
 <CAB-d4A7Wx_ROS4WO2CMg_ZTgttuzegFmeRjiHKYFn3W5OSaCDg@mail.gmail.com>
 <CAHYVw0wdGEsffbwYWSjkK27oZyqDVcRnuwOGK8LiGy6pw3Lp8Q@mail.gmail.com>
 <CAB-d4A6hcWeMxrXXn=ggT70ATpkKzFs3Nk_RAPpMSXE_yK6PKQ@mail.gmail.com>
 <CAB-d4A7C9YjL7oSikM0+oPMnmK4J+ZAUvzLCdGpAD_DYq7p_1g@mail.gmail.com>
 <CAEs96n0maJNAvJ43TE2SeJf-5Z8LEsDhiYEKo7oYbNW4CWAXZw@mail.gmail.com>
Message-ID: <CAEs96n0ZO=hA_NiDX+d2MNUL+vCXP=hTw+sjdur1XS0UH6TaYA@mail.gmail.com>

I just committed this release note info to the users guide.

Hopefully nobody else will trip over it. :)

On Fri, Feb 28, 2014 at 9:51 AM, Austin Seipp <austin at well-typed.com> wrote:
> Thanks George. Since this might be confusing for users, I'll add a
> note to to the release notes about requiring Cabal 1.18 for GHC to
> work properly.
>
> On Fri, Feb 28, 2014 at 8:13 AM, George Colpitts
> <george.colpitts at gmail.com> wrote:
>> Thanks for everybody's help. I got the latest versions of cabal, installed
>> the "early" version of RC2 and then cabal install vector worked
>>
>>
>> On Thu, Feb 27, 2014 at 10:37 PM, George Colpitts
>> <george.colpitts at gmail.com> wrote:
>>>
>>> I am sad. How do I uninstall the current version I have and install that
>>> version?
>>>
>>> Thanks
>>>
>>>
>>> On Thu, Feb 27, 2014 at 10:27 PM, Carter Schonwald
>>> <carter.schonwald at gmail.com> wrote:
>>>>
>>>> you need cabal-install 1.18 or you'll be sad.
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 27, 2014 at 9:16 PM, George Colpitts
>>>> <george.colpitts at gmail.com> wrote:
>>>>>
>>>>> I'm using Cabal-1.18.1.3 and cabal-install version 1.16.0.2
>>>>>
>>>>>
>>>>> On Thu, Feb 27, 2014 at 9:04 PM, Austin Seipp <austin at well-typed.com>
>>>>> wrote:
>>>>>>
>>>>>> Thanks. Another question is what version of Cabal you are using, as it
>>>>>> knows how to build dylibs properly. I'm using cabal 1.18.
>>>>>>
>>>>>> To delete the RC, you can just delete the directory it installed into
>>>>>> (the GHC-7.8.xxxxx folder). Also make sure you remove the executables from
>>>>>> $PATH
>>>>>>
>>>>>> And no worries about any unnecessary work. I'm here to do the release
>>>>>> after all, and feedback is helpful!
>>>>>>
>>>>>>
>>>>>> On Thursday, February 27, 2014, George Colpitts
>>>>>> <george.colpitts at gmail.com> wrote:
>>>>>>>
>>>>>>> Probably my error, I just wanted to make sure there wasn't a problem
>>>>>>> that was missed. Thanks for checking. Sorry for any confusion I caused.
>>>>>>>
>>>>>>> Here are the details of what I did:
>>>>>>>
>>>>>>> I took ghc-7.8.0.20140226-x86_64-apple-darwin-mavericks.tar.bz2 from
>>>>>>> http://www.haskell.org/ghc/dist/7.8.1-rc2/ and followed the instructions in
>>>>>>> the INSTALL file to install it, i.e.
>>>>>>>
>>>>>>> One possible difference is that my gcc is gcc-4.8 from gnu not gcc
>>>>>>> from Apple.
>>>>>>>
>>>>>>> Also my uname output is different than yours:
>>>>>>>
>>>>>>> uname -a
>>>>>>> Darwin iMac27-5.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
>>>>>>> 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
>>>>>>>
>>>>>>>
>>>>>>> Finally I am running XCode 5.2
>>>>>>>
>>>>>>> Is there a to uninstall or clean these RCs?
>>>>>>>
>>>>>>> I'll wait for official notice before trying anything else
>>>>>>>
>>>>>>> I really appreciate all your work and I'm sorry if I caused you any
>>>>>>> unnecessary work. I had no problems installing RC1 so may have been
>>>>>>> overconfident
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 27, 2014 at 8:05 PM, Austin Seipp <austin at well-typed.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I just tested this and cannot reproduce it:
>>>>>>>
>>>>>>> $ cabal install vector
>>>>>>> ... building ...
>>>>>>>
>>>>>>> $ ls /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/vector-0.10.9.1
>>>>>>> Data libHSvector-0.10.9.1-ghc7.8.0.20140226.dylib include
>>>>>>> libHSvector-0.10.9.1.a
>>>>>>>
>>>>>>> $ ls
>>>>>>> /Users/a/.cabal/lib/x86_64-osx-ghc-7.8.0.20140226/primitive-0.5.2.1/
>>>>>>> Control include libHSprimitive-0.5.2.1.a Data
>>>>>>> libHSprimitive-0.5.2.1-ghc7.8.0.20140226.dylib
>>>>>>>
>>>>>>> $ uname -a
>>>>>>> Darwin Calcifer.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19
>>>>>>> 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64
>>>>>>>
>>>>>>> There is certainly a dylib available for both of these libraries.
>>>>>>> You're going to need to be very explicit in what you did to install
>>>>>>> GHC, and how. (Did you use the binary distribution I pulled from the
>>>>>>> server?)* Unfortunately I'm about to run out the door, and don't have
>>>>>>> time for the next few hours closely investigate.
>>>>>>>
>>>>>>> * On another note, I will say that there is not an 'RC2' until I
>>>>>>> announce that it is so, to be completely honest. Right this second,
>>>>>>> some last minute fixes went into HEAD which will be merged for the
>>>>>>> actual RC2. Otherwise I would have released it today. But thank you
>>>>>>> for testing anyway!
>>>>>>>
>>>>>>> On Thu, Feb 27, 2014 at 5:53 PM, George Colpitts
>>>>>>> <george.colpitts at gmail.com> wrote:
>>>>>>> > corrected subject line
>>>>>>> >
>>>>>>> >
>>>>>>> > On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts
>>>>>>> > <george.colpitts at gmail.com>
>>>>>>> > wrote:
>>>>>>> >>
>>>>>>> >> Hi
>>>>>>> >>
>>>>>>> >> After installing the first version of RC2 I ran into the following
>>>>>>> >> problem
>>>>>>> >>
>>>>>>> >>  cabal install vector
>>>>>>> >> Resolving dependencies...
>>>>>>> >> Configuring vector-0.10.9.1...
>>>>>>> >> ...
>>>>>>> >> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
>>>>>>> >> Data/Vector/Fusion/Stream/Monadic.hs,
>>>>>>> >> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
>>>>>>> >> Loading package ghc-prim ... linking ... done.
>>>>>>> >> Loading package integer-gmp ... linking ... done.
>>>>>>> >> Loading package base ... linking ... done.
>>>>>>> >> Loading package primitive-0.5.2.1 ... <command line>: can't load
>>>>>>> >> .so/.DLL
>>>>>>> >> for: libHSprimitive-0.5.2.1.dylib
>>>>>>> >> (dlopen(libHSprimitive-0.5.2.1.dylib, 9):
>>>>>>> >> image not found)
>>>>>>> >>
>>>>>>> >> There seems to be a general problem that the install did not
>>>>>>> >> produce any
>>>>>>> >> dynamic libraries at least on the Mac:
>>>>>>> >>
>>>>>>> >>  ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib
>>>>>>> >>
>>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib:
>>>>>>> >> HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a
>>>>>>> >> libHScpphs-1.18.2_p.a
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib:
>>>>>>> >> Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a
>>>>>>> >> libHShashable-1.2.1.0_p.a
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib:
>>>>>>> >> HShscolour-1.20.3.o Language libHShscolour-1.20.3.a
>>>>>>> >> libHShscolour-1.20.3_p.a
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib:
>>>>>>> >> Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a
>>>>>>> >> Data include libHSprimitive-0.5.2.1_p.a
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib:
>>>>>>> >> Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib:
>>>>>>> >> Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib:
>>>>>>> >> Data libHSunordered-containers-0.2.3.3.a
>>>>>>> >> HSunordered-containers-0.2.3.3.o
>>>>>>> >> libHSunordered-containers-0.2.3.3_p.a
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > _______________________________________________
>>>>>>> > ghc-devs mailing list
>>>>>>> > ghc-devs at haskell.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>>
>>>>>> Austin Seipp, Haskell Consultant
>>>>>> Well-Typed LLP, http://www.well-typed.com/
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>
>>>>
>>>
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From johan.tibell at gmail.com  Fri Feb 28 22:48:48 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 28 Feb 2014 23:48:48 +0100
Subject: Ready for Cabal release now?
Message-ID: <CAK-tuPY7wpLQyz0wGS7JqbbXKe-S7giyQ5iToz-p-Y+-YArPCQ@mail.gmail.com>

Hi,

I know we're waiting until the last minute before the Cabal release that
need to go into 7.8. Should I make that release now?

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/daf87444/attachment-0001.html>

From austin at well-typed.com  Fri Feb 28 23:02:53 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 28 Feb 2014 17:02:53 -0600
Subject: Ready for Cabal release now?
In-Reply-To: <CAK-tuPY7wpLQyz0wGS7JqbbXKe-S7giyQ5iToz-p-Y+-YArPCQ@mail.gmail.com>
References: <CAK-tuPY7wpLQyz0wGS7JqbbXKe-S7giyQ5iToz-p-Y+-YArPCQ@mail.gmail.com>
Message-ID: <CAEs96n0jonf2Ssk_G_Jn2CZFhLdTgOt4YBmgfgn_1c_otaKNRQ@mail.gmail.com>

That sounds good to me. I'm setting up the RC2 builds now, so we can
update our Cabal copy to the latest release after that, for the final
release. Right now we're at e97aa58f68519db54de1c62339459ebb88aed069,
which is just ahead of 1.18.1.3.

As Duncan noted to me, we'll also have to do a cabal-install release,
to make sure that it can build with the adjusted version bounds
present in 7.8.

Herbert, Duncan - any other input?

Thanks Johan!


On Fri, Feb 28, 2014 at 4:48 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> Hi,
>
> I know we're waiting until the last minute before the Cabal release that
> need to go into 7.8. Should I make that release now?
>
> -- Johan
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From carter.schonwald at gmail.com  Fri Feb 28 23:19:00 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 28 Feb 2014 18:19:00 -0500
Subject: Ready for Cabal release now?
In-Reply-To: <CAEs96n0jonf2Ssk_G_Jn2CZFhLdTgOt4YBmgfgn_1c_otaKNRQ@mail.gmail.com>
References: <CAK-tuPY7wpLQyz0wGS7JqbbXKe-S7giyQ5iToz-p-Y+-YArPCQ@mail.gmail.com>
 <CAEs96n0jonf2Ssk_G_Jn2CZFhLdTgOt4YBmgfgn_1c_otaKNRQ@mail.gmail.com>
Message-ID: <CAHYVw0zoMTkgSJW_e4_gLau5RUXArkC1Ctw9s-6U5cebADnoCw@mail.gmail.com>

are we going to try to make cabal-install binaries available for tier 1
platforms?


On Fri, Feb 28, 2014 at 6:02 PM, Austin Seipp <austin at well-typed.com> wrote:

> That sounds good to me. I'm setting up the RC2 builds now, so we can
> update our Cabal copy to the latest release after that, for the final
> release. Right now we're at e97aa58f68519db54de1c62339459ebb88aed069,
> which is just ahead of 1.18.1.3.
>
> As Duncan noted to me, we'll also have to do a cabal-install release,
> to make sure that it can build with the adjusted version bounds
> present in 7.8.
>
> Herbert, Duncan - any other input?
>
> Thanks Johan!
>
>
> On Fri, Feb 28, 2014 at 4:48 PM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
> > Hi,
> >
> > I know we're waiting until the last minute before the Cabal release that
> > need to go into 7.8. Should I make that release now?
> >
> > -- Johan
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/7279f2e0/attachment.html>

From austin at well-typed.com  Fri Feb 28 23:46:42 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 28 Feb 2014 17:46:42 -0600
Subject: RC2 release imminent
In-Reply-To: <CAEDGBqLRsXbARK=o1D-MYfxkiaQ_sjipNimQYHpXSNcHZkwbow@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
 <CAEDGBqLRsXbARK=o1D-MYfxkiaQ_sjipNimQYHpXSNcHZkwbow@mail.gmail.com>
Message-ID: <CAEs96n0CTG7EqMGDNu0P3V1Od-AskB8zAdU8XdnfDMnCPiEqSQ@mail.gmail.com>

Hello all,

New source distributions are available here:

http://www.haskell.org/ghc/dist/7.8.1-rc2/

Feel free to build when you get a chance at attach the hashes for the
binary dists. I'll be uploading mine as they happen.

On Fri, Feb 28, 2014 at 7:40 AM, Jens Petersen <juhpetersen at gmail.com> wrote:
> 2014/02/27 9:14 "Austin Seipp" <austin at well-typed.com>:
>> http://www.haskell.org/ghc/dist/7.8.1-rc2/
>
> Thanks! I did a test build for Fedora Rawhide (F21 devel):
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6579613
>
> from the txz file (this build is without testsuite and prof).
> I haven't had a chance to test it yet.
>
> Jens



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From hvr at gnu.org  Thu Feb 27 12:22:33 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Thu, 27 Feb 2014 12:22:33 -0000
Subject: RC2 release imminent
In-Reply-To: <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
 (Austin Seipp's message of "Wed, 26 Feb 2014 18:14:38 -0600")
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
Message-ID: <878uswg2yr.fsf@gnu.org>



On 2014-02-27 at 01:14:38 +0100, Austin Seipp wrote:
> Hello all,
>
> The RC2 source distribution is here:
>
> http://www.haskell.org/ghc/dist/7.8.1-rc2/
>
> Please build from it directly. It matches the HEAD of the ghc-7.8
> branch as of now - e9212f0edbd3fddc3836ccded10d036c01d38505
>
> Like last time, please include a link to the bindist, and a
> cryptographic hash (md5/sha1) of the tarball so I know it's OK.

Fyi (no need to mirror them on www.h.o), here are direct links to Ubuntu
12.04/x86_64 binary .deb's from my Travis-CI PPA (which are expected to
be ABI compatible with later Ubuntu versions up to at least Ubuntu
13.10/x86_64):

 https://launchpad.net/~hvr/+archive/ghc/+files/ghc-7.8.1_7.8.1~rc2-1_amd64.deb

 https://launchpad.net/~hvr/+archive/ghc/+files/ghc-7.8.1-prof_7.8.1~rc2-1_amd64.deb

 https://launchpad.net/~hvr/+archive/ghc/+files/ghc-7.8.1-htmldocs_7.8.1~rc2-1_amd64.deb

They install into /opt/ghc/7.8.1/, therefore you just need to add
/opt/ghc/7.8.1/bin into your search PATH.

Cheers,