Windows is still broken

[Simon Peyton Jones via ghc-devs]

Simon, Windows is still broken.
Do you want me to revert both patches, or will you?
Simon


"inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror 
-optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes 
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return 
-optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs 
-optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist 
-optc-Iincludes/dist-derivedconstants/header 
-optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build 
-optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common 
-optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 
-optc-fomit-frame-pointer -optc-g -optc-fno-omit-frame-pointer -optc-g -optc-O0 
-optc-DRtsWay=\"rts_thr_debug\" -optc-DWINVER=0x06000100 -static 
-optc-DTHREADED_RTS -optc-DDEBUG  -O0 -H64m -Wall 
-fllvm-fill-undef-with-garbage-Werror -Iincludes -Iincludes/dist 
-Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header 
-Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint  -i 
-irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen 
-Irts/dist/build/./autogen   -O2 -O0-Wnoncanonical-monad-instances  
-c rts/Linker.c -o rts/dist/build/Linker.thr_debug_o



In file included from rts\Linker.c:13:0: error:

rts\Linker.c: In function 'ocTryLoad':



rts\Linker.c:2566:55: error:

 error: pointer type mismatch in conditional expression [-Werror]

 oc->archiveMemberName : oc->fileName));

   ^



includes\Rts.h:300:53: error:

 note: in definition of macro 'IF_DEBUG'

 #define IF_DEBUG(c,s)  if (RtsFlags.DebugFlags.c) { s; }

 ^



rts\Linker.c:2564:33: error:

 error: format '%ls' expects argument of type 'wchar_t *', but argument 2 
has type 'void *' [-Werror=format=]

 IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n",

 ^



includes\Rts.h:300:53: error:

 note: in definition of macro 'IF_DEBUG'

 #define IF_DEBUG(c,s)  if (RtsFlags.DebugFlags.c) { s; }

 ^

cc1.exe: all warnings being treated as errors

`gcc.exe' failed in phase `C Compiler'. (Exit code: 1)

rts/ghc.mk:255: recipe for target 'rts/dist/build/Linker.debug_o' failed

make[1]: *** [rts/dist/build/Linker.debug_o] Error 1

make[1]: *** Waiting for unfinished jobs



In file included from rts\Linker.c:13:0: error:

rts\Linker.c: In function 'ocTryLoad':



rts\Linker.c:2566:55: error:

 error: pointer type mismatch in conditional expression [-Werror]

 oc->archiveMemberName : oc->fileName));

   ^



includes\Rts.h:300:53: error:

 note: in definition of macro 'IF_DEBUG'

 #define IF_DEBUG(c,s)  if (RtsFlags.DebugFlags.c) { s; }

 ^



rts\Linker.c:2564:33: error:

 error: format '%ls' expects argument of type 'wchar_t *', but argument 2 
has type 'void *' [-Werror=format=]

 IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n",

 ^



includes\Rts.h:300:53: error:

 note: in definition of macro 'IF_DEBUG'

 #define IF_DEBUG(c,s)  if (RtsFlags.DebugFlags.c) { s; }

 ^

cc1.exe: all warnings being treated as errors

`gcc.exe' failed in phase `C Compiler'. (Exit code: 1)

rts/ghc.mk:255: recipe for target 'rts/dist/build/Linker.thr_debug_o' failed

make[1]: *** [rts/dist/build/Linker.thr_debug_o] Error 1

Makefile:129: recipe for target 'all' failed

make: *** [all] Error 2

/cygdrive/c/code/HEAD$ git log -2 rts/Linker.c

commit 01f449f4ffd2c4f23bfe5698b9f1b98a86276900

Author: Simon Marlow 

Date:   Mon Jul 4 10:56:04 2016 +0100



Fix 32-bit build failures



commit 6377757918c1e7f63638d6f258cad8d5f02bb6a7

Author: Simon Marlow 

Date:   Wed Jun 29 21:50:18 2016 +0100



Linker: some extra debugging / logging
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Phyx]

I don't think you can do it in validate.mk,

Only
https://github.com/ghc/ghc/blob/master/testsuite/driver/runtests.py#L144
here as far as I know. I also constantly have to watch out I don't commit
it though

On Mon, Jul 4, 2016, 13:56 Simon Peyton Jones  wrote:

> Let’s re-enable it.   Or: how can I selectively re-enable it for in my
> validate.mk?
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Phyx
> *Sent:* 04 July 2016 13:05
> *To:* Erik de Castro Lopo ; ghc-devs <
> ghc-devs@haskell.org>
> *Subject:* Re: Linker.c broken
>
>
>
> There used to be a bug in the msys2 runtime which made certain processes
> hang on exit in a non deterministic way.
>
> So the parallel runs was disabled. I was looking into it but haven't been
> able to reproduce it at all in months now since either upgrading msys2 or
> Windows (to Windows 10).
>
> We have a ticket with more information on it and what I found back then,
> but haven't been able to progress.
>
> It might be that they've just fixed it in the mean time.
>
>
>
> On Mon, Jul 4, 2016, 12:58 Erik de Castro Lopo 
> wrote:
>
> Phyx wrote:
>
> > I can build and validate in about an hour myself using 9 jobs on a core
> i7.
> > If I revert the change in the testsuite preventing parallel runs for
> > Windows
>
> Oh dear, why is that?
>
> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Linker.c broken

[Simon Peyton Jones via ghc-devs]

Let’s re-enable it.   Or: how can I selectively re-enable it for in my 
validate.mk?

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Phyx
Sent: 04 July 2016 13:05
To: Erik de Castro Lopo ; ghc-devs 
Subject: Re: Linker.c broken


There used to be a bug in the msys2 runtime which made certain processes hang 
on exit in a non deterministic way.

So the parallel runs was disabled. I was looking into it but haven't been able 
to reproduce it at all in months now since either upgrading msys2 or Windows 
(to Windows 10).

We have a ticket with more information on it and what I found back then, but 
haven't been able to progress.

It might be that they've just fixed it in the mean time.

On Mon, Jul 4, 2016, 12:58 Erik de Castro Lopo 
> wrote:
Phyx wrote:

> I can build and validate in about an hour myself using 9 jobs on a core i7.
> If I revert the change in the testsuite preventing parallel runs for
> Windows

Oh dear, why is that?

Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Ben Gamari]

Simon Marlow  writes:

> If parallel tests now work on Windows, could it be enabled by default?
>
I seem to remember trying this last summer and ran into trouble. That
being said, it would be worth trying again. I've fired up another build;
we'll see how it goes.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Phyx]

There used to be a bug in the msys2 runtime which made certain processes
hang on exit in a non deterministic way.

So the parallel runs was disabled. I was looking into it but haven't been
able to reproduce it at all in months now since either upgrading msys2 or
Windows (to Windows 10).

We have a ticket with more information on it and what I found back then,
but haven't been able to progress.

It might be that they've just fixed it in the mean time.

On Mon, Jul 4, 2016, 12:58 Erik de Castro Lopo  wrote:

> Phyx wrote:
>
> > I can build and validate in about an hour myself using 9 jobs on a core
> i7.
> > If I revert the change in the testsuite preventing parallel runs for
> > Windows
>
> Oh dear, why is that?
>
> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Erik de Castro Lopo]

Phyx wrote:

> I can build and validate in about an hour myself using 9 jobs on a core i7.
> If I revert the change in the testsuite preventing parallel runs for
> Windows

Oh dear, why is that?

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Simon Marlow]

If parallel tests now work on Windows, could it be enabled by default?

On 4 July 2016 at 12:48, Phyx  wrote:

> I can build and validate in about an hour myself using 9 jobs on a core
> i7. If I revert the change in the testsuite preventing parallel runs for
> Windows.
>
> Tamar
>
> On Mon, Jul 4, 2016, 12:26 Ben Gamari  wrote:
>
>> "Boespflug, Mathieu"  writes:
>>
>> > On 4 July 2016 at 12:36, Ben Gamari  wrote:
>> >> Simon Marlow  writes:
>> >>
>> >>> I will fix it, sorry about this.  Unfortunately I can't really add a
>> >>> Windows validate into my workflow because it would mean rebooting my
>> laptop
>> >>> into Windows and not doing anything else for several hours.  We need
>> some
>> >>> CI support for Windows - Ben/Austin any thoughts on this?
>> >>>
>> >> I agree; this would be great. I have a Windows machine which I'd be
>> >> happy setup as a builder although I'm afraid it's behind NAT, so
>> >> integration with Harbormaster may require some tunneling.
>> >
>> > Just a suggestion - the easiest and most reliable would probably be to
>> > simply use Appveyor for this. They offer a hosted and fully managed CI
>> > service very similar to Travis CI - only difference being it runs
>> > tests on Windows boxes. And just like Travis CI, it's free!
>> >
>> > The advantage of a hosted CI service is that no one except Appveyor
>> > need to worry about keeping the build bot highly available.
>> >
>> > Only downside is their machines in the free tier can be a bit slow.
>> > But that's a problem that can be iterated on as the need arises.
>> >
>> I've noticed that several of the core libraries rely on Appveyor with
>> good results. However, I had assumed that GHC would exceed the maximum
>> build time of their free tier since the build takes a few hours on my
>> Windows box. It seems that Appveyor has a one-hour build duration limit,
>> similar to Travis.
>>
>> Cheers,
>>
>> - Ben
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Phyx]

I can build and validate in about an hour myself using 9 jobs on a core i7.
If I revert the change in the testsuite preventing parallel runs for
Windows.

Tamar

On Mon, Jul 4, 2016, 12:26 Ben Gamari  wrote:

> "Boespflug, Mathieu"  writes:
>
> > On 4 July 2016 at 12:36, Ben Gamari  wrote:
> >> Simon Marlow  writes:
> >>
> >>> I will fix it, sorry about this.  Unfortunately I can't really add a
> >>> Windows validate into my workflow because it would mean rebooting my
> laptop
> >>> into Windows and not doing anything else for several hours.  We need
> some
> >>> CI support for Windows - Ben/Austin any thoughts on this?
> >>>
> >> I agree; this would be great. I have a Windows machine which I'd be
> >> happy setup as a builder although I'm afraid it's behind NAT, so
> >> integration with Harbormaster may require some tunneling.
> >
> > Just a suggestion - the easiest and most reliable would probably be to
> > simply use Appveyor for this. They offer a hosted and fully managed CI
> > service very similar to Travis CI - only difference being it runs
> > tests on Windows boxes. And just like Travis CI, it's free!
> >
> > The advantage of a hosted CI service is that no one except Appveyor
> > need to worry about keeping the build bot highly available.
> >
> > Only downside is their machines in the free tier can be a bit slow.
> > But that's a problem that can be iterated on as the need arises.
> >
> I've noticed that several of the core libraries rely on Appveyor with
> good results. However, I had assumed that GHC would exceed the maximum
> build time of their free tier since the build takes a few hours on my
> Windows box. It seems that Appveyor has a one-hour build duration limit,
> similar to Travis.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Boespflug, Mathieu]

True. Worth a try asking them what limits they're willing to lift for
a high profile open source project like GHC, I think.
--
Mathieu Boespflug
Founder at http://tweag.io.


On 4 July 2016 at 13:26, Ben Gamari  wrote:
> "Boespflug, Mathieu"  writes:
>
>> On 4 July 2016 at 12:36, Ben Gamari  wrote:
>>> Simon Marlow  writes:
>>>
 I will fix it, sorry about this.  Unfortunately I can't really add a
 Windows validate into my workflow because it would mean rebooting my laptop
 into Windows and not doing anything else for several hours.  We need some
 CI support for Windows - Ben/Austin any thoughts on this?

>>> I agree; this would be great. I have a Windows machine which I'd be
>>> happy setup as a builder although I'm afraid it's behind NAT, so
>>> integration with Harbormaster may require some tunneling.
>>
>> Just a suggestion - the easiest and most reliable would probably be to
>> simply use Appveyor for this. They offer a hosted and fully managed CI
>> service very similar to Travis CI - only difference being it runs
>> tests on Windows boxes. And just like Travis CI, it's free!
>>
>> The advantage of a hosted CI service is that no one except Appveyor
>> need to worry about keeping the build bot highly available.
>>
>> Only downside is their machines in the free tier can be a bit slow.
>> But that's a problem that can be iterated on as the need arises.
>>
> I've noticed that several of the core libraries rely on Appveyor with
> good results. However, I had assumed that GHC would exceed the maximum
> build time of their free tier since the build takes a few hours on my
> Windows box. It seems that Appveyor has a one-hour build duration limit,
> similar to Travis.
>
> Cheers,
>
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Ben Gamari]

"Boespflug, Mathieu"  writes:

> On 4 July 2016 at 12:36, Ben Gamari  wrote:
>> Simon Marlow  writes:
>>
>>> I will fix it, sorry about this.  Unfortunately I can't really add a
>>> Windows validate into my workflow because it would mean rebooting my laptop
>>> into Windows and not doing anything else for several hours.  We need some
>>> CI support for Windows - Ben/Austin any thoughts on this?
>>>
>> I agree; this would be great. I have a Windows machine which I'd be
>> happy setup as a builder although I'm afraid it's behind NAT, so
>> integration with Harbormaster may require some tunneling.
>
> Just a suggestion - the easiest and most reliable would probably be to
> simply use Appveyor for this. They offer a hosted and fully managed CI
> service very similar to Travis CI - only difference being it runs
> tests on Windows boxes. And just like Travis CI, it's free!
>
> The advantage of a hosted CI service is that no one except Appveyor
> need to worry about keeping the build bot highly available.
>
> Only downside is their machines in the free tier can be a bit slow.
> But that's a problem that can be iterated on as the need arises.
>
I've noticed that several of the core libraries rely on Appveyor with
good results. However, I had assumed that GHC would exceed the maximum
build time of their free tier since the build takes a few hours on my
Windows box. It seems that Appveyor has a one-hour build duration limit,
similar to Travis.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Boespflug, Mathieu]

On 4 July 2016 at 12:36, Ben Gamari  wrote:
> Simon Marlow  writes:
>
>> I will fix it, sorry about this.  Unfortunately I can't really add a
>> Windows validate into my workflow because it would mean rebooting my laptop
>> into Windows and not doing anything else for several hours.  We need some
>> CI support for Windows - Ben/Austin any thoughts on this?
>>
> I agree; this would be great. I have a Windows machine which I'd be
> happy setup as a builder although I'm afraid it's behind NAT, so
> integration with Harbormaster may require some tunneling.

Just a suggestion - the easiest and most reliable would probably be to
simply use Appveyor for this. They offer a hosted and fully managed CI
service very similar to Travis CI - only difference being it runs
tests on Windows boxes. And just like Travis CI, it's free!

The advantage of a hosted CI service is that no one except Appveyor
need to worry about keeping the build bot highly available.

Only downside is their machines in the free tier can be a bit slow.
But that's a problem that can be iterated on as the need arises.

Best,

--
Mathieu Boespflug
Founder at http://tweag.io.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Erik de Castro Lopo]

Ben Gamari wrote:

> Indeed; and I think it would also be worthwhile also setting up at least
> a nightly build validating 32-bit Linux.

If its not integrated with the CI, I'm not sure how useful that is.

As you  may remember I have a Jenkins instance. Once a day it polls git and
if there are new commits sicen the last time it was polled, it builds the
following:

   Arch OS   BuildFlavour
   x86_64   linuxperf
   x86_64   darwin   perf
   x86_64   linuxperf-llvm
   x86_64   linuxdevel2/unregisterised
   x86_64   linuxdevel2 with Clang
   x86_64   Linuxperf
   powerpc  linuxdevel2
   powerpc  linuxdevel2/unregisterised
   armhflinuxdevel2
   armhflinuxdevel2/unregisterised

as well as cross-compiling from x86_64/linux to armhf/linux and arm64/linux.

This does catche the ocassional problem but when something shows up but fixing 
them
is a bigger problem. FOr example, I simply have not had time to look at :

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

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Ben Gamari]

Erik de Castro Lopo  writes:

> Simon Marlow wrote:
>
>> I will fix it, sorry about this.  Unfortunately I can't really add a
>> Windows validate into my workflow because it would mean rebooting my laptop
>> into Windows and not doing anything else for several hours.
>
> Even building as 32 bit would have shaken out a bug in the format specifiers
> to the debugBelch statement.
>
> Are you on Linux? I use a 32 bit debian chroot on my otherwise 64 bit Debian
> system.
>
Indeed; and I think it would also be worthwhile also setting up at least
a nightly build validating 32-bit Linux.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Ben Gamari]

Simon Marlow  writes:

> I will fix it, sorry about this.  Unfortunately I can't really add a
> Windows validate into my workflow because it would mean rebooting my laptop
> into Windows and not doing anything else for several hours.  We need some
> CI support for Windows - Ben/Austin any thoughts on this?
>
I agree; this would be great. I have a Windows machine which I'd be
happy setup as a builder although I'm afraid it's behind NAT, so
integration with Harbormaster may require some tunneling.

On that note, how is the Harbormaster effort going, Austin? It appears
that Differentials are still not being built. Is there anything I can do
to help here?

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Erik de Castro Lopo]

Simon Marlow wrote:

> It was actually intentional.  The patch validated on Travis:
> https://travis-ci.org/simonmar/ghc/builds/141572355 and I didn't think it
> was worth having it reviewed (but if you want to review all linker patches
> I'd be happy to put them on Phabricator in the future).

I *try* (time permitting) to review all linker patches. I've just started
a new job (coding Haskell) but it means I've got a bit less time to hack
on GHC.

I have a Phab rule to notify me on all patches that touch Linker.c. I try
to look at all of them, but sometimes they have been accepted by others
and committed before I even look at them. For the ones that are nor accepted
and committed before I get to them, I often test them on PowerPC or Arm and
I'm also willing to keep on doing this (time permitting).

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Simon Marlow]

On 4 July 2016 at 09:45, Erik de Castro Lopo  wrote:

> Simon Marlow wrote:
>
> > I will fix it, sorry about this.  Unfortunately I can't really add a
> > Windows validate into my workflow because it would mean rebooting my
> laptop
> > into Windows and not doing anything else for several hours.
>
> Even building as 32 bit would have shaken out a bug in the format
> specifiers
> to the debugBelch statement.
>
> Are you on Linux? I use a 32 bit debian chroot on my otherwise 64 bit
> Debian
> system.
>

Building on 32-bit would flush out some bugs, but not others. Yes I could
use a chroot, or a VM, and I could have Windows in a VM.  But what about OS
X? In fact validate on a single platform already ties up my machine for an
hour, so the more platforms we have to validate the less practical it is to
make small changes.  I think more automation is the only good solution to
this.

So, I rely on CI for most of my commits, whether it's Phabricator (now
fixed!) or Travis.


> > We need some CI support for Windows - Ben/Austin any thoughts on this?
>
> That would be an improvement, but it doesn't help for other OSes like Aix
> and Solaris or other CPUs.
>
> I also noticed that patch bypassed Phabricator. I assume that was a
> mistake. I've
> done it myself. We need to be particularly careful with the RTS code
> because
> its so fragile. It needs to be build and tested on a wide variety of
> systems.
>

It was actually intentional.  The patch validated on Travis:
https://travis-ci.org/simonmar/ghc/builds/141572355 and I didn't think it
was worth having it reviewed (but if you want to review all linker patches
I'd be happy to put them on Phabricator in the future).

Cheers
Simon



> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Erik de Castro Lopo]

Simon Marlow wrote:

> I will fix it, sorry about this.  Unfortunately I can't really add a
> Windows validate into my workflow because it would mean rebooting my laptop
> into Windows and not doing anything else for several hours.

Even building as 32 bit would have shaken out a bug in the format specifiers
to the debugBelch statement.

Are you on Linux? I use a 32 bit debian chroot on my otherwise 64 bit Debian
system.

> We need some CI support for Windows - Ben/Austin any thoughts on this?

That would be an improvement, but it doesn't help for other OSes like Aix
and Solaris or other CPUs.

I also noticed that patch bypassed Phabricator. I assume that was a mistake. 
I've
done it myself. We need to be particularly careful with the RTS code because
its so fragile. It needs to be build and tested on a wide variety of systems.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker.c broken

[Simon Marlow]

I will fix it, sorry about this.  Unfortunately I can't really add a
Windows validate into my workflow because it would mean rebooting my laptop
into Windows and not doing anything else for several hours.  We need some
CI support for Windows - Ben/Austin any thoughts on this?

On 4 July 2016 at 09:28, Simon Peyton Jones  wrote:

> That was it.
>
> Simon M: would you care to fix? Or should I push a revert?
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> |  Edward Z. Yang
> |  Sent: 02 July 2016 01:02
> |  To: ghc-devs 
> |  Subject: Re: Linker.c broken
> |
> |  I'm guessing it's:
> |
> |  commit 6377757918c1e7f63638d6f258cad8d5f02bb6a7
> |  Author: Simon Marlow 
> |  Date:   Wed Jun 29 21:50:18 2016 +0100
> |
> |  Linker: some extra debugging / logging
> |
> |  which added ghci_find.
> |
> |  Edward
> |
> |  Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-07-01
> |  18:51:20 -0400:
> |  > Aargh!  Windows is broken /again/.   Some mess-up in Linker.c.
> |  > I have not yet tried reverting recent patches.  Might someone fix
> |  please?
> |  > It’s really helpful to validate on Windows when making RTS changes.
> |  > Simon
> |  >
> |  >
> |  >
> |  > rts\Linker.c: In function 'ghci_find':
> |  >
> |  >
> |  >
> |  > rts\Linker.c:1482:52: error:
> |  >
> |  >  error: pointer type mismatch in conditional expression [-
> |  Werror]
> |  >
> |  >   oc->archiveMemberName : oc-
> |  >fileName);
> |  >
> |  > ^
> |  >
> |  >
> |  >
> |  > rts\Linker.c:1480:28: error:
> |  >
> |  >  error: format '%ls' expects argument of type 'wchar_t *', but
> |  argument 3 has type 'void *' [-Werror=format=]
> |  >
> |  >  debugBelch("%p is in %" PATH_FMT, addr,
> |  >
> |  > ^
> |  >
> |  > "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -
> |  optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-
> |  Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-
> |  Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-
> |  Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-
> |  Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-
> |  Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -
> |  optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-
> |  Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-
> |  frame-pointer -optc-g -optc-fno-omit-frame-pointer -optc-g -optc-O0 -
> |  optc-DRtsWay=\"rts_debug\" -optc-DWINVER=0x06000100 -static -optc-
> |  DDEBUG -ticky -DTICKY_TICKY  -O0 -H64m -Wall -fllvm-fill-undef-with-
> |  garbage-Werror -Iincludes -Iincludes/dist -Iincludes/dist-
> |  derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -
> |  Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint  -i -
> |  irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -
> |  Irts/dist/build/./autogen   -O2 -O0-Wnoncanonical-monad-
> |  instances  -c rts/RaiseAsync.c -o rts/dist/build/RaiseAsync.debug_o
> |  >
> |  >
> |  >
> |  > rts\Linker.c:1483:28: error:
> |  >
> |  >  error: format '%lx' expects argument of type 'long unsigned
> |  int', but argument 3 has type 'long long unsigned int' [-
> |  Werror=format=]
> |  >
> |  >  debugBelch(", section %d, offset %lx\n", i,
> |  >
> |  > ^
> |  >
> |  >
> |  >
> |  > In file included from rts\Linker.c:13:0: error:
> |  >
> |  > rts\Linker.c: In function 'ocTryLoad':
> |  >
> |  >
> |  >
> |  > rts\Linker.c:2563:55: error:
> |  >
> |  >  error: pointer type mismatch in conditional expression [-
> |  Werror]
> |  >
> |  >  oc->archiveMemberName : oc-
> |  >fileName));
> |  >
> |  >^
> |  >
> |  >
> |  >
> |  > includes\Rts.h:300:53: error:
> |  >
> |  >  note: in definition of macro 'IF_DEBUG'
> |  >
> |  >  #define IF_DEBUG(c,s)  if (RtsFlags.DebugFlags.c) { s; }
> |  >
> |  >  ^
> |  >
> |  >
> |  >
> |  > rts\Linker.c:2561:33: error:
> |  >
> |  >  error: format '%ls' expects argument of type 'wchar_t *', but
> |  argument 2 has type 'void *' [-Werror=format=]
> |  >
> |  >  IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n",
> |  >
> |  >  ^
> |  >
> |  >
> |  >
> |  > includes\Rts.h:300:53: error:
> |  >
> |  >  note: in definition of macro 'IF_DEBUG'
> |  >
> |  >  #define IF_DEBUG(c,s)  if (RtsFlags.DebugFlags.c) { s; }
> |  >
> |  >  ^
> |  >
> |  > cc1.exe: all warnings 

Re: Linker.c broken

[Erik de Castro Lopo]

Simon Peyton Jones via ghc-devs wrote:

> rts\Linker.c:1480:28: error:
> 
>  error: format '%ls' expects argument of type 'wchar_t *', but argument 3 
> has type 'void *' [-Werror=format=]
> 
>  debugBelch("%p is in %" PATH_FMT, addr,

I get an error on code from this commit on arm/linux.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Linker.c broken

[Simon Peyton Jones via ghc-devs]

That was it.

Simon M: would you care to fix? Or should I push a revert?

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Edward Z. Yang
|  Sent: 02 July 2016 01:02
|  To: ghc-devs 
|  Subject: Re: Linker.c broken
|  
|  I'm guessing it's:
|  
|  commit 6377757918c1e7f63638d6f258cad8d5f02bb6a7
|  Author: Simon Marlow 
|  Date:   Wed Jun 29 21:50:18 2016 +0100
|  
|  Linker: some extra debugging / logging
|  
|  which added ghci_find.
|  
|  Edward
|  
|  Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-07-01
|  18:51:20 -0400:
|  > Aargh!  Windows is broken /again/.   Some mess-up in Linker.c.
|  > I have not yet tried reverting recent patches.  Might someone fix
|  please?
|  > It’s really helpful to validate on Windows when making RTS changes.
|  > Simon
|  >
|  >
|  >
|  > rts\Linker.c: In function 'ghci_find':
|  >
|  >
|  >
|  > rts\Linker.c:1482:52: error:
|  >
|  >  error: pointer type mismatch in conditional expression [-
|  Werror]
|  >
|  >   oc->archiveMemberName : oc-
|  >fileName);
|  >
|  > ^
|  >
|  >
|  >
|  > rts\Linker.c:1480:28: error:
|  >
|  >  error: format '%ls' expects argument of type 'wchar_t *', but
|  argument 3 has type 'void *' [-Werror=format=]
|  >
|  >  debugBelch("%p is in %" PATH_FMT, addr,
|  >
|  > ^
|  >
|  > "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -
|  optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-
|  Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-
|  Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-
|  Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-
|  Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-
|  Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -
|  optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-
|  Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-
|  frame-pointer -optc-g -optc-fno-omit-frame-pointer -optc-g -optc-O0 -
|  optc-DRtsWay=\"rts_debug\" -optc-DWINVER=0x06000100 -static -optc-
|  DDEBUG -ticky -DTICKY_TICKY  -O0 -H64m -Wall -fllvm-fill-undef-with-
|  garbage-Werror -Iincludes -Iincludes/dist -Iincludes/dist-
|  derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -
|  Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint  -i -
|  irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -
|  Irts/dist/build/./autogen   -O2 -O0-Wnoncanonical-monad-
|  instances  -c rts/RaiseAsync.c -o rts/dist/build/RaiseAsync.debug_o
|  >
|  >
|  >
|  > rts\Linker.c:1483:28: error:
|  >
|  >  error: format '%lx' expects argument of type 'long unsigned
|  int', but argument 3 has type 'long long unsigned int' [-
|  Werror=format=]
|  >
|  >  debugBelch(", section %d, offset %lx\n", i,
|  >
|  > ^
|  >
|  >
|  >
|  > In file included from rts\Linker.c:13:0: error:
|  >
|  > rts\Linker.c: In function 'ocTryLoad':
|  >
|  >
|  >
|  > rts\Linker.c:2563:55: error:
|  >
|  >  error: pointer type mismatch in conditional expression [-
|  Werror]
|  >
|  >  oc->archiveMemberName : oc-
|  >fileName));
|  >
|  >^
|  >
|  >
|  >
|  > includes\Rts.h:300:53: error:
|  >
|  >  note: in definition of macro 'IF_DEBUG'
|  >
|  >  #define IF_DEBUG(c,s)  if (RtsFlags.DebugFlags.c) { s; }
|  >
|  >  ^
|  >
|  >
|  >
|  > rts\Linker.c:2561:33: error:
|  >
|  >  error: format '%ls' expects argument of type 'wchar_t *', but
|  argument 2 has type 'void *' [-Werror=format=]
|  >
|  >  IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n",
|  >
|  >  ^
|  >
|  >
|  >
|  > includes\Rts.h:300:53: error:
|  >
|  >  note: in definition of macro 'IF_DEBUG'
|  >
|  >  #define IF_DEBUG(c,s)  if (RtsFlags.DebugFlags.c) { s; }
|  >
|  >  ^
|  >
|  > cc1.exe: all warnings being treated as errors
|  >
|  > `gcc.exe' failed in phase `C Compiler'. (Exit code: 1)
|  >
|  > rts/ghc.mk:255: recipe for target 'rts/dist/build/Linker.debug_o'
|  failed
|  >
|  > make[1]: *** [rts/dist/build/Linker.debug_o] Error 1
|  >
|  > make[1]: *** Waiting for unfinished jobs
|  >
|  > Makefile:129: recipe for target 'all' failed
|  >
|  > make: *** [all] Error 2
|  >
|  > /cygdrive/c/code/HEAD$
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  

Re: Interruptible exception wormholes kill modularity

[Simon Marlow]

On 2 July 2016 at 17:25, Edward Z. Yang  wrote:

> Excerpts from Simon Marlow's message of 2016-07-02 05:58:14 -0400:
> > > Claim 1: Here is some code which reimplements 'unblock':
> > >
> > > import Control.Exception
> > > import Control.Concurrent
> > > import Control.Concurrent.MVar
> > >
> > > unblock :: IO a -> IO a
> > > unblock io = do
> > > m <- newEmptyMVar
> > > _ <- forkIO (io >>= putMVar m)
> > > takeMVar m
> > >
> > >
> > This isn't really an implementation of unblock, because it doesn't enable
> > fully-asynchronous exceptions inside io.  If a stack overflow occurs, it
> > won't be thrown, for example.  Also, io will not be interrupted by an
> > asynchronous exception thrown to the current thread.
>
> Oh, that's true. I suppose you could work around this by passing
> on an asynchronous exception to a child thread that is unmasked
> using forkIOWithUnmask, although maybe you would consider that
> cheating?
>

Yes, you can use forkIOWithUnmask as a way to break out of mask.  Perhaps
for that reason it should have "unsafe" in the name, but I think it's hard
to use it by accident.

I actually do agree with you that the "modularity" provided by mask isn't
really useful.  But my reasoning is a bit different.

The caller of mask is saying "I want asynchronous exceptions to only occur
at known places.".  Those known places are interruptible operations, and
library code (because we can't know whether library code performs an
interruptible operation or not).  From the point of view of the caller of
mask, they cannot tell the difference between library code that invokes an
interruptible operation, and library code that calls "unblock".  So it
would be perfectly fine to provide an "unblock" that re-enables fully
asynchronous exceptions.

(indeed I think this was kind of what I had in mind with the original
block/unblock, but I didn't articulate the argument clearly enough when
everyone was asking for "mask")

However, things are a bit different with uninterruptibleMask.  Here the
caller is saying "I don't expect to see *any* asynchronous exceptions,
either in my code or from library code".  So clearly an unblock cannot undo
an uninterruptibleMask.

Having said all this, I don't think the current API is necessarily bad, it
just provides more guarantees than we really need, and perhaps it's a bit
less efficient than it could be, due to the need to pass the IO action to
mask.  But we would still need to do this for uninterruptibleMask, and
having the API of uninterruptibleMask be the same as mask is good.


> We already have a way to allow asynchronous exceptions to be thrown within
> > a mask, it's called allowInterrupt:
> >
> http://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Exception.html#v:allowInterrupt
>
> Well, it's different, right?  allowInterrupt allows asynchronous
> exceptions to
> be thrown at a specific point of execution; unblock allows asynchronous
> exceptions to be thrown at any point while the inner IO action is
> executing.  I don't see why you would allow the former without the
> latter.
>

Ok, so the point I was trying to make was that the idea of blocking to
allow asynchronous exceptions to be thrown inside a mask is fully
sanctioned, and we made an API for it.  But you're quite right that it's
not exactly the same as unblock.


> > > You could very well argue that interruptible actions are a design flaw.
> > >
> >
> > I disagree - it's impossible to define withMVar without interruptible
> mask.
>
> What about this version of withMVar using uninterruptible? (Assume
> no other producers.)
>
> withMVarUninterruptible :: MVar a -> (a -> IO b) -> IO b
> withMVarUninterruptible m io =
>   uninterruptibleMask $ \restore -> do
> a <- restore (takeMVar m)
> b <- restore (io a) `onException` putMVar m a
> putMVar m a
> return b
>
> I don't think it is quite right, as there is race between when
> takeMVar unblocks, and when the uninterruptible mask is restored.
> But perhaps the primary utility of interruptible masks is to
> let you eliminate this race.
>

Exactly!  This race condition is the reason for interruptible operations.

[snip]

>
> Edward
>

Cheers
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Moving ArgumentsDo forward

[Akio Takano]

Hi Andrew,

On 6 June 2016 at 16:37, Andrew Gibiansky  wrote:
> As the author of the proposal and extension, I'd like to clarify that the
> change was abandoned per se because of how controversial the change was. [0]
> [1] [2]

Thank you for the clarification. I hope you don't mind that I pick up
your proposal and use your code as a starting point.

>
> This is not to say that we should not continue to discuss this change, but
> if we do so, make sure that you first read through the previous discussion
> -- it was quite extensive!
>
> Specifically, I became unconvinced that it was worth the effort to make as
> an extension, given the reasons against it (mainly, extra work for GHC,
> hindent, haskell-src-exts, etc etc); I think this along with a few other
> things (trailing commas!) could make a significant improvement to cosmetic
> Haskell syntax, but perhaps one extension per character is a bit much for
> that. That said I have no idea how else a mythical Haskell' could get a
> cleaned up syntax if not through first being implemented as a GHC extension.

I actually found the response from people at haskell-cafe rather
encouraging. To me a 50% support seems high enough to justify an
implementation.

>
> Finally, you may be interested in ghc-reskin [3], which was a (slightly
> tongue-in-cheek) response to a lot of the discussion caused by this
> extension last time, and could potentially be made into a production-ready
> tool / Haskell' syntax if anyone cared strongly to do so.

Thank you. Unfortunately for my uses a separate preprocessor probably
would have too much overhead.

>
> [0]
> https://www.reddit.com/r/haskell/comments/447bnw/does_argument_do_have_a_future/
> [1]
> https://mail.haskell.org/pipermail/haskell-cafe/2015-September/121217.html
> [2] https://ghc.haskell.org/trac/ghc/ticket/10843
> [3] https://github.com/gibiansky/ghc-reskin
>
> Best,
> Andrew
>
> On Wed, Jun 1, 2016 at 3:26 PM Akio Takano  wrote:
>>
>> Hi Bardur,
>>
>> On 2 June 2016 at 00:09, Bardur Arantsson  wrote:
>> > On 06/01/2016 01:48 PM, Akio Takano wrote:
>> >> Hi,
>> >>
>> >> Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would
>> >> love to see in GHC. It's a small syntactic extension that allows do,
>> >> case, if and lambda blocks as function arguments, without parentheses.
>> >> However, its differential revision [1] has been abandoned, citing a
>> >> mixed response from the community. A message [2] on the ticket
>> >> summarizes a thread in haskell-cafe on this topic.
>> >>
>> >> I, for one, think adding this extension is worthwhile, because a
>> >> significant number of people support it. Also, given how some people
>> >> seem to feel ambivalent about this change, I believe actually allowing
>> >> people to try it makes it clearer whether it is a good idea.
>> >>
>> >> Thus I'm wondering: is there any chance that this gets merged? If so,
>> >> I'm willing to work on whatever is remaining to get the change merged.
>> >>
>> >
>> > What's changed since it was last discussed?
>>
>> Nothing has really changed. I'm just trying to argue that the current
>> level of community support is good enough to justify an
>> implementation.
>>
>> Please note that the previous Differential revision was abandoned by
>> the author. It was *not* rejected due to a lack of support. Hence my
>> question: if properly implemented, does this feature have any chance
>> of getting merged in, or is it regarded too controversial?
>>
>> > I don't think the objections
>> > were centered in the implementation, so I don't see what "whatever is
>> > remaining to get the change merged" would be.
>>
>> I'm referring the points mentioned in the review comments in the
>> Differential revision. For example this change needs an update to the
>> User's Guide.
>>
>> >
>> > AFAICT at best it's a *very* small improvement[1] and fractures Haskell
>> > syntax even more around extensions -- tooling etc. will need to
>> > understand even *more* syntax extensions[2].
>>
>> I disagree that this is a small improvement, but I don't intend to
>> debate this here. As you said, nothing has really changed since it was
>> discussed before, and a lot of reasons for implementing this extension
>> have been already pointed out. I don't have anything to add.
>>
>> Regarding tooling, my understanding is that most tools that need to
>> understand Haskell (this includes ghc-mod and hdevtools) use either
>> the GHC API or haskell-src-exts, so I don't think this extension would
>> need changes in many places.
>>
>> Regards,
>> Takano Akio
>>
>> >
>> > Regards,
>> >
>> > [1] If you grant that it is indeed an improvment, which I, personally,
>> > don't think it is.
>> >
>> > [2] I think most people agree that this is something that should perhaps
>> > be handled by something like
>> > https://github.com/haskell/haskell-ide-engine so that it would only need
>> > to be implemented once, but there's not even 

Re: Moving ArgumentsDo forward

[Akio Takano]

Hi Simon,

I'm sorry about the late reply.

On 2 June 2016 at 07:19, Simon Peyton Jones  wrote:
> Akio
>
> Thanks for bringing back the ArgumentsDo question.
>
> My personal take on it is similar to Bardur:
>
>> AFAICT at best it's a *very* small improvement[1] and fractures
>> Haskell syntax even more around extensions -- tooling etc. will need
>> to understand even *more* syntax extensions[2].
>
> The benefit to me seems slight.  The cost is also modest, but it is not zero 
> (see below), even given a complete implementation.  ANY feature carries a 
> cost that is borne by every subsequent implementor, in perpetuity.

I understand your concern. I think this extension is worthwhile, but
of course this should be ultimately decided on by people who actually
maintain GHC.

>
> So I am a bit reluctant.
>
> These things are a judgement call, and we don't have a good process for 
> making that decision.  A few of us have been talking about putting forward a 
> better process; it'll be a few weeks.
>
> Meanwhile, what to do about ArgumentDo?  You say
>
> |  I disagree that this is a small improvement, but I don't intend to
> |  debate this here. As you said, nothing has really changed since it was
> |  discussed before, and a lot of reasons for implementing this extension
> |  have been already pointed out. I don't have anything to add.
>
> Is there a wiki page that describes the proposal, and lists the "lot of 
> reasons" why it would be a good thing?  And lists any disadvantages?  I'm not 
> just erecting obstacles: the trouble with email is that it is long and 
> discursive, so it's really hard to find all the relevant messages, and even 
> if you do each message only makes sense if you read the long sequence.

I made a wiki page: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo

>
> One question I have is this.  Presumably
> f do stmts
> will be represented as
> HsApp (HsVar f) (HsDo ...stmts...)
> And should print without parens -- they are signalled by HsPar.  So what about
> (HsApp (HsVar f) (HsDo ...stmts1..)) (HsDo ..stmts2..)
> How does that pretty-print. I suppose it should be
> f do stmts1
> do stmts2
> That is, it must use layout.  But at the moment the pretty printer doesn't do 
> that.

It looks like the pretty printer always prints curly braces around do
statements (ppr_do_stmts in hsSyn/HsExpr.hs), so perhaps this is not
an issue?

- Akio
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs