Re: process library broken on Windows

[Michael Snoyman]

I didn't read closely enough: I see now that it's a warning, not an error.
I initially didn't export that constructor since it's only present on
Windows for API compatibility, but will never be used. Since this is just
the internals module, I can export it, but my preference would in fact be
to leave it as-is with the warning. Two alternatives:

1. Create a new hidden module that creates and exports the type
constructor, just to hide the warning. I'm -1 on that, since that's extra
compile time everyone has to endure just for warning avoidance.
2. base could export CGid for Windows (currently, it does not).

On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman  wrote:

> I'll look into this. I just made a new release of process, and was certain
> I tested on Windows, but perhaps something changed between that commit and
> release.
>
> On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones 
> wrote:
>
>> I’m getting this on HEAD in te ‘
>>
>> libraries\process\System\Process\Internals.hs:106:16: warning:
>>
>> Defined but not used: data constructor ‘CGid’
>>
>> Indeed it looks as if CGId(..) should be exported, else createProcess is
>> unusuable.  This looks like the right change.  Would someone like to check
>> and make the change
>>
>> Simon
>>
>> diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs
>>
>> index 5575ac4..3e23ad5 100644
>>
>> --- a/System/Process/Internals.hs
>>
>> +++ b/System/Process/Internals.hs
>>
>> @@ -37,6 +37,8 @@ module System.Process.Internals (
>>
>> #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__)
>>
>>  pPrPr_disableITimers, c_execvpe,
>>
>>  ignoreSignal, defaultSignal,
>>
>> +#else
>>
>> +CGid(..), GroupID, UserID,
>>
>> #endif
>>
>>  withFilePathException, withCEnvironment,
>>
>>  translate,
>>
>> ___
>> 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: process library broken on Windows

[Michael Snoyman]

On Mon, Nov 2, 2015 at 5:57 AM, Simon Peyton Jones 
wrote:

> Aha.  It would be great to say all that in the source code!!  It’s very
> non-obvious that you not want people ever to construct a CGId on Windows.
> After all, it has a newtype definition!
>
>
>

Good call, I'll update with some comments (though see refactoring comments
below).


> Could you declare it differently?
>
> data CGId   -- No constructors
>
>
Certainly we could. Then the question would be "why does the Windows code
look so different?" There are lots of colors to this bikeshed, and I don't
have any particular affinity to any of them. If you'd prefer it looked that
way, I can make that change. I initially erred with making the code as
similar to the POSIX code as possible.


>
>
> Also if so, why does the Windows-specific foreign import of
> c_runInteractiveProcess (lin 440-is) pas a Ptr CGId? You’d just told me
> that we can never create one.
>
>

The Windows-specific foreign import is on line ~533, and does not include
those arguments.


>
>
> Also,
>
> · It’d help to comment the #else on line 456 as being “else if
> not windows”
>
> · The #endifs on line 546 or thereabouts are mis-labelled.  at
> the moment the second says “GLASGOW_HASKELL” but actually it’s the first
>
>

Agreed that the code is fairly difficult to follow with the nested ifdefs.
However, instead of trying to salvage that, it's probably worth a
refactoring to put the Windows and POSIX code into separate modules and
then just import those conditionally.


>
>
> I have no opinion about the best solution; I’d just like it to compile and
> preferably warning free since that is our default policy.  Or add a –Wwarn
> at the top.
>
>
If you're looking for a short-term solution, I can add -Wwarn to the top
until some kind of refactoring takes place.


>
>
> thanks
>
>
>
> Simon
>
>
>
>
>
> *From:* michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] *On
> Behalf Of *Michael Snoyman
> *Sent:* 02 November 2015 13:42
>
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: process library broken on Windows
>
>
>
> That's the goal; it's a feature that does not work on Windows, only on
> non-Windows systems (setuid/setgid for a child process). For POSIX systems,
> CGid is exported from base, and can be used. On Windows, the data type is
> present to give the same signature, but the constructor itself is not
> exported to prevent using the feature. An argument could be made for other
> approaches:
>
>
>
> 1. Expose the constructor, allowing users to set a value, and that value
> will be ignored
>
> 2. Make the fields themselves conditional on the OS being used
>
>
>
> I don't think there's a strong argument in any direction for this.
>
>
>
> On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones 
> wrote:
>
> I’m puzzled.   Internals.hs defines a newtype
>
>
>
> newtype CGid = CGid Word32
>
>
>
> A value of this type is needed to fill in the child_group field of
> CreateProcess.  If you don’t export it, you could never initialise this
> field to anything other than Nothing, so why do you have it?
>
>
>
> Looks to me as if the warning has nailed a real bug
>
>
>
> Simon
>
>
>
> *From:* michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] *On
> Behalf Of *Michael Snoyman
> *Sent:* 02 November 2015 13:34
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: process library broken on Windows
>
>
>
> I didn't read closely enough: I see now that it's a warning, not an error.
> I initially didn't export that constructor since it's only present on
> Windows for API compatibility, but will never be used. Since this is just
> the internals module, I can export it, but my preference would in fact be
> to leave it as-is with the warning. Two alternatives:
>
>
>
> 1. Create a new hidden module that creates and exports the type
> constructor, just to hide the warning. I'm -1 on that, since that's extra
> compile time everyone has to endure just for warning avoidance.
>
> 2. base could export CGid for Windows (currently, it does not).
>
>
>
> On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman 
> wrote:
>
> I'll look into this. I just made a new release of process, and was certain
> I tested on Windows, but perhaps something changed between that commit and
> release.
>
>
>
> On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones 
> wrote:
>
> I’m getting this on HEAD in te ‘
>
> libraries\process\System\Process\Internals.hs:106:16: warning:
>
> Defined but not used: data constructor ‘CGid’
>
> Indeed it looks as if CGId(..) should be exported, else createProcess is
> unusuable.  This looks like the right change.  Would someone like to check
> and make the change
>
> Simon
>
> diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs
>
> index 5575ac4..3e23ad5 100644
>
> --- a/System/Process/Internals.hs
>
> +++ 

Re: Better calling conventions for strict functions (bang patterns)?

[Ryan Newton]

Thanks Simon for linking that issue!  Does the patch linked there

already
cover what you suggested in your last mail?  I think no, it's a more
limited change, but I'm having trouble understanding exactly what.

I've also got one really basic question -- was it decided long ago that all
these stack limit checks are cheaper than having a guard page at the end of
each stack and faulting to grow the stack?  (I couldn't find a place that
this rationale was described on wiki.)

Best,
  -Ryan


On Sun, Nov 1, 2015 at 10:05 AM, Simon Marlow  wrote:

> Yes, I think we can probably do a better job of compiling case
> expressions.  The current compilation strategy optimises for code size, but
> at the expense of performance in the fast path.  We can tweak this
> tradeoff, perhaps under the control of a flag.
>
> Ideally the sequence should start by assuming that the closure is already
> evaluated, e.g.
>
>  loop:
>tag = R2 & 7;
>if (tag == 1) then // code for []
>else if (tag == 2) then // code for (:)
>else evaluate; jump back to loop
>
> The nice thing is that now that we don't need proc points, "loop" is just
> a label that we can directly jump to.  Unfortunately this only works when
> using the NCG, not with LLVM, because LLVM requires proc points, so we
> might need to fall back to a different strategy for LLVM.
>
> Similar topics came up here: https://ghc.haskell.org/trac/ghc/ticket/8905
> and I think there was another ticket but I can't find it now.
>
> Cheers
> Simon
>
> On 23/10/2015 19:00, Ryan Newton wrote:
>
>>  1. Small tweaks: The CMM code above seems to be /betting/ than the
>> thunk is unevaluated, because it does the stack check and stack
>> write /before/ the predicate test that checks if the thunk is
>> evaluated (if(R1 & 7!= 0) gotoc3aO; elsegotoc3aP;).  With a
>> bang-pattern function, couldn't it make the opposite bet?  That
>> is, branch on whether the thunk is evaluated first, and then the
>> wasted computation is only a single correctly predicted branch
>> (and a read of a tag that we need to read anyway).
>>
>> Oh, a small further addition would be needed for this tweak.  In the
>> generated code above "Sp = Sp + 8;" happens /late/, but I think it could
>> happen right after the call to the thunk.  In general, does it seem
>> feasible to separate the slowpath from fastpath as in the following
>> tweak of the example CMM?
>>
>>
>> *  // Skip to the chase if it's already evaluated:*
>> *  start:*
>> *  if (R2 & 7 != 0) goto fastpath; else goto slowpath;*
>> *
>> *
>> *  slowpath:   // Formerly c3aY*
>> *  if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0;*
>> *  c3aZ:*
>> *  // nop*
>> *  R1 = PicBaseReg + foo_closure;*
>> *  call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8;*
>> *  c3b0:*
>> *  I64[Sp - 8] = PicBaseReg + block_c3aO_info;*
>> *  R1 = R2;*
>> *  Sp = Sp - 8;*
>>
>> *  call (I64[R1])(R1) returns to fastpath, args: 8, res: 8, upd: 8;*
>> *  // Sp bump moved to here so it's separate from "fastpath"*
>> *  Sp = Sp + 8;*
>> *
>> *
>> *  fastpath: // Formerly c3aO*
>> *  if (R1 & 7 >= 2) goto c3aW; else goto c3aX;*
>> *  c3aW:*
>> *  R1 = P64[R1 + 6] & (-8);*
>> *  call (I64[R1])(R1) args: 8, res: 0, upd: 8;*
>> *  c3aX:*
>> *  R1 = PicBaseReg + lvl_r39S_closure;*
>> *  call (I64[R1])(R1) args: 8, res: 0, upd: 8;*
>>
>>
>>
>>
>>
>> ___
>> 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: process library broken on Windows

[Simon Peyton Jones]

Aha.  It would be great to say all that in the source code!!  It’s very 
non-obvious that you not want people ever to construct a CGId on Windows.  
After all, it has a newtype definition!

Could you declare it differently?
data CGId   -- No constructors

Also if so, why does the Windows-specific foreign import of 
c_runInteractiveProcess (lin 440-is) pas a Ptr CGId? You’d just told me that we 
can never create one.

Also,

· It’d help to comment the #else on line 456 as being “else if not 
windows”

· The #endifs on line 546 or thereabouts are mis-labelled.  at the 
moment the second says “GLASGOW_HASKELL” but actually it’s the first

I have no opinion about the best solution; I’d just like it to compile and 
preferably warning free since that is our default policy.  Or add a –Wwarn at 
the top.

thanks

Simon


From: michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] On Behalf Of 
Michael Snoyman
Sent: 02 November 2015 13:42
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: process library broken on Windows

That's the goal; it's a feature that does not work on Windows, only on 
non-Windows systems (setuid/setgid for a child process). For POSIX systems, 
CGid is exported from base, and can be used. On Windows, the data type is 
present to give the same signature, but the constructor itself is not exported 
to prevent using the feature. An argument could be made for other approaches:

1. Expose the constructor, allowing users to set a value, and that value will 
be ignored
2. Make the fields themselves conditional on the OS being used

I don't think there's a strong argument in any direction for this.

On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones 
> wrote:
I’m puzzled.   Internals.hs defines a newtype

newtype CGid = CGid Word32

A value of this type is needed to fill in the child_group field of 
CreateProcess.  If you don’t export it, you could never initialise this field 
to anything other than Nothing, so why do you have it?

Looks to me as if the warning has nailed a real bug

Simon

From: michael.snoy...@gmail.com 
[mailto:michael.snoy...@gmail.com] On Behalf 
Of Michael Snoyman
Sent: 02 November 2015 13:34
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: process library broken on Windows

I didn't read closely enough: I see now that it's a warning, not an error. I 
initially didn't export that constructor since it's only present on Windows for 
API compatibility, but will never be used. Since this is just the internals 
module, I can export it, but my preference would in fact be to leave it as-is 
with the warning. Two alternatives:

1. Create a new hidden module that creates and exports the type constructor, 
just to hide the warning. I'm -1 on that, since that's extra compile time 
everyone has to endure just for warning avoidance.
2. base could export CGid for Windows (currently, it does not).

On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman 
> wrote:
I'll look into this. I just made a new release of process, and was certain I 
tested on Windows, but perhaps something changed between that commit and 
release.

On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones 
> wrote:
I’m getting this on HEAD in te ‘

libraries\process\System\Process\Internals.hs:106:16: warning:

Defined but not used: data constructor ‘CGid’
Indeed it looks as if CGId(..) should be exported, else createProcess is 
unusuable.  This looks like the right change.  Would someone like to check and 
make the change
Simon

diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs

index 5575ac4..3e23ad5 100644

--- a/System/Process/Internals.hs

+++ b/System/Process/Internals.hs

@@ -37,6 +37,8 @@ module System.Process.Internals (

#if !defined(mingw32_HOST_OS) && !defined(__MINGW32__)

 pPrPr_disableITimers, c_execvpe,

 ignoreSignal, defaultSignal,

+#else

+CGid(..), GroupID, UserID,

#endif

 withFilePathException, withCEnvironment,

 translate,

___
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: process library broken on Windows

[Simon Peyton Jones]

I’m puzzled.   Internals.hs defines a newtype

newtype CGid = CGid Word32

A value of this type is needed to fill in the child_group field of 
CreateProcess.  If you don’t export it, you could never initialise this field 
to anything other than Nothing, so why do you have it?

Looks to me as if the warning has nailed a real bug

Simon

From: michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] On Behalf Of 
Michael Snoyman
Sent: 02 November 2015 13:34
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: process library broken on Windows

I didn't read closely enough: I see now that it's a warning, not an error. I 
initially didn't export that constructor since it's only present on Windows for 
API compatibility, but will never be used. Since this is just the internals 
module, I can export it, but my preference would in fact be to leave it as-is 
with the warning. Two alternatives:

1. Create a new hidden module that creates and exports the type constructor, 
just to hide the warning. I'm -1 on that, since that's extra compile time 
everyone has to endure just for warning avoidance.
2. base could export CGid for Windows (currently, it does not).

On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman 
> wrote:
I'll look into this. I just made a new release of process, and was certain I 
tested on Windows, but perhaps something changed between that commit and 
release.

On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones 
> wrote:
I’m getting this on HEAD in te ‘

libraries\process\System\Process\Internals.hs:106:16: warning:

Defined but not used: data constructor ‘CGid’
Indeed it looks as if CGId(..) should be exported, else createProcess is 
unusuable.  This looks like the right change.  Would someone like to check and 
make the change
Simon

diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs

index 5575ac4..3e23ad5 100644

--- a/System/Process/Internals.hs

+++ b/System/Process/Internals.hs

@@ -37,6 +37,8 @@ module System.Process.Internals (

#if !defined(mingw32_HOST_OS) && !defined(__MINGW32__)

 pPrPr_disableITimers, c_execvpe,

 ignoreSignal, defaultSignal,

+#else

+CGid(..), GroupID, UserID,

#endif

 withFilePathException, withCEnvironment,

 translate,

___
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: Better calling conventions for strict functions (bang patterns)?

[Simon Marlow]

On 02/11/2015 06:37, Ryan Newton wrote:

Thanks Simon for linking that issue!  Does the patch linked there

 already
cover what you suggested in your last mail?  I think no, it's a more
limited change, but I'm having trouble understanding exactly what.

I've also got one really basic question -- was it decided long ago that
all these stack limit checks are cheaper than having a guard page at the
end of each stack and faulting to grow the stack?  (I couldn't find a
place that this rationale was described on wiki.)


Stacks would be immovable, and you need to arrange that you have enough 
address space to grow the stack if necessary, just like OS threads. 
Thus it's not really feasible on 32-bit platforms, and we would have to 
keep the existing stack-chunk mechanism for those platforms.  Right now 
stacks start at 1k and are really cheap; they'd be somewhat more 
expensive under this scheme: at least 4K and a couple of mmap() calls.


Stack chunks have another benefit: we can track whether each chunk is 
dirty separately, and only traverse dirty chunks in the GC.  I don't 
think you'd be able to do this with contiguous stacks and no stack checks.


Cheers
Simon




Best,
   -Ryan


On Sun, Nov 1, 2015 at 10:05 AM, Simon Marlow > wrote:

Yes, I think we can probably do a better job of compiling case
expressions.  The current compilation strategy optimises for code
size, but at the expense of performance in the fast path.  We can
tweak this tradeoff, perhaps under the control of a flag.

Ideally the sequence should start by assuming that the closure is
already evaluated, e.g.

  loop:
tag = R2 & 7;
if (tag == 1) then // code for []
else if (tag == 2) then // code for (:)
else evaluate; jump back to loop

The nice thing is that now that we don't need proc points, "loop" is
just a label that we can directly jump to.  Unfortunately this only
works when using the NCG, not with LLVM, because LLVM requires proc
points, so we might need to fall back to a different strategy for LLVM.

Similar topics came up here:
https://ghc.haskell.org/trac/ghc/ticket/8905 and I think there was
another ticket but I can't find it now.

Cheers
Simon

On 23/10/2015 19:00, Ryan Newton wrote:

  1. Small tweaks: The CMM code above seems to be /betting/
than the
 thunk is unevaluated, because it does the stack check
and stack
 write /before/ the predicate test that checks if the
thunk is
 evaluated (if(R1 & 7!= 0) gotoc3aO; elsegotoc3aP;).  With a
 bang-pattern function, couldn't it make the opposite
bet?  That
 is, branch on whether the thunk is evaluated first, and
then the
 wasted computation is only a single correctly predicted
branch
 (and a read of a tag that we need to read anyway).

Oh, a small further addition would be needed for this tweak.  In the
generated code above "Sp = Sp + 8;" happens /late/, but I think
it could
happen right after the call to the thunk.  In general, does it seem
feasible to separate the slowpath from fastpath as in the following
tweak of the example CMM?


*  // Skip to the chase if it's already evaluated:*
*  start:*
*  if (R2 & 7 != 0) goto fastpath; else goto slowpath;*
*
*
*  slowpath:   // Formerly c3aY*
*  if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0;*
*  c3aZ:*
*  // nop*
*  R1 = PicBaseReg + foo_closure;*
*  call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8;*
*  c3b0:*
*  I64[Sp - 8] = PicBaseReg + block_c3aO_info;*
*  R1 = R2;*
*  Sp = Sp - 8;*

*  call (I64[R1])(R1) returns to fastpath, args: 8, res: 8,
upd: 8;*
*  // Sp bump moved to here so it's separate from "fastpath"*
*  Sp = Sp + 8;*
*
*
*  fastpath: // Formerly c3aO*
*  if (R1 & 7 >= 2) goto c3aW; else goto c3aX;*
*  c3aW:*
*  R1 = P64[R1 + 6] & (-8);*
*  call (I64[R1])(R1) args: 8, res: 0, upd: 8;*
*  c3aX:*
*  R1 = PicBaseReg + lvl_r39S_closure;*
*  call (I64[R1])(R1) args: 8, res: 0, upd: 8;*





___
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: process library broken on Windows

[Michael Snoyman]

That's the goal; it's a feature that does not work on Windows, only on
non-Windows systems (setuid/setgid for a child process). For POSIX systems,
CGid is exported from base, and can be used. On Windows, the data type is
present to give the same signature, but the constructor itself is not
exported to prevent using the feature. An argument could be made for other
approaches:

1. Expose the constructor, allowing users to set a value, and that value
will be ignored
2. Make the fields themselves conditional on the OS being used

I don't think there's a strong argument in any direction for this.

On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones 
wrote:

> I’m puzzled.   Internals.hs defines a newtype
>
>
>
> newtype CGid = CGid Word32
>
>
>
> A value of this type is needed to fill in the child_group field of
> CreateProcess.  If you don’t export it, you could never initialise this
> field to anything other than Nothing, so why do you have it?
>
>
>
> Looks to me as if the warning has nailed a real bug
>
>
>
> Simon
>
>
>
> *From:* michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] *On
> Behalf Of *Michael Snoyman
> *Sent:* 02 November 2015 13:34
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: process library broken on Windows
>
>
>
> I didn't read closely enough: I see now that it's a warning, not an error.
> I initially didn't export that constructor since it's only present on
> Windows for API compatibility, but will never be used. Since this is just
> the internals module, I can export it, but my preference would in fact be
> to leave it as-is with the warning. Two alternatives:
>
>
>
> 1. Create a new hidden module that creates and exports the type
> constructor, just to hide the warning. I'm -1 on that, since that's extra
> compile time everyone has to endure just for warning avoidance.
>
> 2. base could export CGid for Windows (currently, it does not).
>
>
>
> On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman 
> wrote:
>
> I'll look into this. I just made a new release of process, and was certain
> I tested on Windows, but perhaps something changed between that commit and
> release.
>
>
>
> On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones 
> wrote:
>
> I’m getting this on HEAD in te ‘
>
> libraries\process\System\Process\Internals.hs:106:16: warning:
>
> Defined but not used: data constructor ‘CGid’
>
> Indeed it looks as if CGId(..) should be exported, else createProcess is
> unusuable.  This looks like the right change.  Would someone like to check
> and make the change
>
> Simon
>
> diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs
>
> index 5575ac4..3e23ad5 100644
>
> --- a/System/Process/Internals.hs
>
> +++ b/System/Process/Internals.hs
>
> @@ -37,6 +37,8 @@ module System.Process.Internals (
>
> #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__)
>
>  pPrPr_disableITimers, c_execvpe,
>
>  ignoreSignal, defaultSignal,
>
> +#else
>
> +CGid(..), GroupID, UserID,
>
> #endif
>
>  withFilePathException, withCEnvironment,
>
>  translate,
>
>
>
> ___
> 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: process library broken on Windows

[Simon Marlow]

-Wwarn shouldn't really be in source code.  Since it's an Internals 
module, I would just export it.  Maybe add a {-# WARNING #-} to 
discourage people from using it.


Cheers
Simon

On 02/11/2015 06:14, Michael Snoyman wrote:



On Mon, Nov 2, 2015 at 5:57 AM, Simon Peyton Jones
> wrote:

Aha.  It would be great to say all that in the source code!!  It’s
very non-obvious that you not want people ever to construct a CGId
on Windows.  After all, it has a newtype definition!

__


Good call, I'll update with some comments (though see refactoring
comments below).

__

Could you declare it differently?

 data CGId   -- No constructors

__


Certainly we could. Then the question would be "why does the Windows
code look so different?" There are lots of colors to this bikeshed, and
I don't have any particular affinity to any of them. If you'd prefer it
looked that way, I can make that change. I initially erred with making
the code as similar to the POSIX code as possible.

__

Also if so, why does the Windows-specific foreign import of
c_runInteractiveProcess (lin 440-is) pas a Ptr CGId? You’d just told
me that we can never create one.

__



The Windows-specific foreign import is on line ~533, and does not
include those arguments.

__

Also, 

__·__It’d help to comment the #else on line 456 as being “else if
not windows”

__·__The #endifs on line 546 or thereabouts are mis-labelled.  at
the moment the second says “GLASGOW_HASKELL” but actually it’s the
first

__



Agreed that the code is fairly difficult to follow with the nested
ifdefs. However, instead of trying to salvage that, it's probably worth
a refactoring to put the Windows and POSIX code into separate modules
and then just import those conditionally.

__

I have no opinion about the best solution; I’d just like it to
compile and preferably warning free since that is our default
policy.  Or add a –Wwarn at the top.

__


If you're looking for a short-term solution, I can add -Wwarn to the top
until some kind of refactoring takes place.

__

thanks

__ __

Simon

__ __

__ __

*From:*michael.snoy...@gmail.com 
[mailto:michael.snoy...@gmail.com
] *On Behalf Of *Michael Snoyman
*Sent:* 02 November 2015 13:42


*To:* Simon Peyton Jones
*Cc:* ghc-devs@haskell.org 
*Subject:* Re: process library broken on Windows

__ __

That's the goal; it's a feature that does not work on Windows, only
on non-Windows systems (setuid/setgid for a child process). For
POSIX systems, CGid is exported from base, and can be used. On
Windows, the data type is present to give the same signature, but
the constructor itself is not exported to prevent using the feature.
An argument could be made for other approaches:

__ __

1. Expose the constructor, allowing users to set a value, and that
value will be ignored

2. Make the fields themselves conditional on the OS being used

__ __

I don't think there's a strong argument in any direction for this.

__ __

On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones
> wrote:

I’m puzzled.   Internals.hs defines a newtype



newtype CGid = CGid Word32



A value of this type is needed to fill in the child_group field
of CreateProcess.  If you don’t export it, you could never
initialise this field to anything other than Nothing, so why do
you have it?



Looks to me as if the warning has nailed a real bug



Simon



*From:*michael.snoy...@gmail.com

[mailto:michael.snoy...@gmail.com
] *On Behalf Of *Michael Snoyman
*Sent:* 02 November 2015 13:34
*To:* Simon Peyton Jones
*Cc:* ghc-devs@haskell.org 
*Subject:* Re: process library broken on Windows



I didn't read closely enough: I see now that it's a warning, not
an error. I initially didn't export that constructor since it's
only present on Windows for API compatibility, but will never be
used. Since this is just the internals module, I can export it,
but my preference would in fact be to leave it as-is with the
warning. Two alternatives:



1. Create a new hidden module that creates and exports the type
constructor, just to hide the warning. I'm -1 on that, since
that's extra compile time everyone has to 

Re: Better calling conventions for strict functions (bang patterns)?

[Simon Marlow]

Sorry, forgot to respond to your other point:

On 02/11/2015 06:37, Ryan Newton wrote:

Thanks Simon for linking that issue!  Does the patch linked there

 already
cover what you suggested in your last mail?  I think no, it's a more
limited change, but I'm having trouble understanding exactly what.


Correct, it's a more limited change.  I don't have a working 
implementation of the scheme I described, it needs some reorganisation 
in the codeGen if I remember correctly.


Something I think we should do is to have a gcc-like -Os flag that we 
could use as a hint in cases where we have a code-size vs speed tradeoff 
like this, there are a handful of places we could use that.


Cheers
Simon



I've also got one really basic question -- was it decided long ago that
all these stack limit checks are cheaper than having a guard page at the
end of each stack and faulting to grow the stack?  (I couldn't find a
place that this rationale was described on wiki.)

Best,
   -Ryan


On Sun, Nov 1, 2015 at 10:05 AM, Simon Marlow > wrote:

Yes, I think we can probably do a better job of compiling case
expressions.  The current compilation strategy optimises for code
size, but at the expense of performance in the fast path.  We can
tweak this tradeoff, perhaps under the control of a flag.

Ideally the sequence should start by assuming that the closure is
already evaluated, e.g.

  loop:
tag = R2 & 7;
if (tag == 1) then // code for []
else if (tag == 2) then // code for (:)
else evaluate; jump back to loop

The nice thing is that now that we don't need proc points, "loop" is
just a label that we can directly jump to.  Unfortunately this only
works when using the NCG, not with LLVM, because LLVM requires proc
points, so we might need to fall back to a different strategy for LLVM.

Similar topics came up here:
https://ghc.haskell.org/trac/ghc/ticket/8905 and I think there was
another ticket but I can't find it now.

Cheers
Simon

On 23/10/2015 19:00, Ryan Newton wrote:

  1. Small tweaks: The CMM code above seems to be /betting/
than the
 thunk is unevaluated, because it does the stack check
and stack
 write /before/ the predicate test that checks if the
thunk is
 evaluated (if(R1 & 7!= 0) gotoc3aO; elsegotoc3aP;).  With a
 bang-pattern function, couldn't it make the opposite
bet?  That
 is, branch on whether the thunk is evaluated first, and
then the
 wasted computation is only a single correctly predicted
branch
 (and a read of a tag that we need to read anyway).

Oh, a small further addition would be needed for this tweak.  In the
generated code above "Sp = Sp + 8;" happens /late/, but I think
it could
happen right after the call to the thunk.  In general, does it seem
feasible to separate the slowpath from fastpath as in the following
tweak of the example CMM?


*  // Skip to the chase if it's already evaluated:*
*  start:*
*  if (R2 & 7 != 0) goto fastpath; else goto slowpath;*
*
*
*  slowpath:   // Formerly c3aY*
*  if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0;*
*  c3aZ:*
*  // nop*
*  R1 = PicBaseReg + foo_closure;*
*  call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8;*
*  c3b0:*
*  I64[Sp - 8] = PicBaseReg + block_c3aO_info;*
*  R1 = R2;*
*  Sp = Sp - 8;*

*  call (I64[R1])(R1) returns to fastpath, args: 8, res: 8,
upd: 8;*
*  // Sp bump moved to here so it's separate from "fastpath"*
*  Sp = Sp + 8;*
*
*
*  fastpath: // Formerly c3aO*
*  if (R1 & 7 >= 2) goto c3aW; else goto c3aX;*
*  c3aW:*
*  R1 = P64[R1 + 6] & (-8);*
*  call (I64[R1])(R1) args: 8, res: 0, upd: 8;*
*  c3aX:*
*  R1 = PicBaseReg + lvl_r39S_closure;*
*  call (I64[R1])(R1) args: 8, res: 0, upd: 8;*





___
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: process library broken on Windows

[Michael Snoyman]

I'll look into this. I just made a new release of process, and was certain
I tested on Windows, but perhaps something changed between that commit and
release.

On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones 
wrote:

> I’m getting this on HEAD in te ‘
>
> libraries\process\System\Process\Internals.hs:106:16: warning:
>
> Defined but not used: data constructor ‘CGid’
>
> Indeed it looks as if CGId(..) should be exported, else createProcess is
> unusuable.  This looks like the right change.  Would someone like to check
> and make the change
>
> Simon
>
> diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs
>
> index 5575ac4..3e23ad5 100644
>
> --- a/System/Process/Internals.hs
>
> +++ b/System/Process/Internals.hs
>
> @@ -37,6 +37,8 @@ module System.Process.Internals (
>
> #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__)
>
>  pPrPr_disableITimers, c_execvpe,
>
>  ignoreSignal, defaultSignal,
>
> +#else
>
> +CGid(..), GroupID, UserID,
>
> #endif
>
>  withFilePathException, withCEnvironment,
>
>  translate,
>
> ___
> 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: [ANNOUNCE] GHC 7.10.3 release candidate 1

[George Colpitts]

Will there be a Mac release candidate also?

Thanks
George


On Mon, Nov 2, 2015 at 12:03 PM, Ben Gamari  wrote:

>
> We are pleased to announce the first (and hopefully only) release
> candidate for GHC 7.10.3:
>
> https://downloads.haskell.org/~ghc/7.10.3-rc1/
>
> This includes the source tarball and bindists for 64-bit and 32-bit
> modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs
> have an accompanying SHA256SUMS file signed by my GPG key id
> (0x97DB64AD). As always, our content delivery network tends to be a bit
> slow on the uptake. If you see an empty directory at this URL just add a
> few superfluous slashes to the end; this is typically enough to fool it.
>
> The 7.10.2 release was well-behaved save a couple notable bugs; while we
> have merged a good number of bug fixes in 7.10.3 they were were
> largely low risk and so we expect that this release should be
> similiarly stable.
>
> The one exception to this is an upgrade of the Windows compiler
> toolchain to GCC 5.2. Windows users have been long suffering at the hand
> of our old toolchain (e.g. lack of response file support, #8596, and
> lack of SEH support) so we expect that this change should fix far more
> than breaks.
>
> We plan to make the 7.10.3 release sometime next week.
>
> Please test this as much as possible; bugs are much cheaper if we find
> them before the release and this will ideally be the last release of the
> 7.10 series.
>
> Happy testing,
>
> - 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: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Joachim Breitner]

Hi,

Am Montag, den 02.11.2015, 13:21 -0500 schrieb Richard Eisenberg:
> Personally, I would love delaying announcements such as these until
> binaries are available, at least for Linux, Mac, and Windows.

it’s a release candidate, announced on the developer mailing list.
Isn’t such a mail a requirement for those wo build the various binaries
to get active in the first place? Or is all done by Ben these days.

I’m happy to get the announcement as quickly as possible, as I was
waiting for the source tarball :-)

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Richard Eisenberg]

Personally, I would love delaying announcements such as these until binaries 
are available, at least for Linux, Mac, and Windows.

Richard

On Nov 2, 2015, at 1:18 PM, George Colpitts  wrote:

> Will there be a Mac release candidate also?
> 
> Thanks
> George
> 
> 
> On Mon, Nov 2, 2015 at 12:03 PM, Ben Gamari  wrote:
> 
> We are pleased to announce the first (and hopefully only) release
> candidate for GHC 7.10.3:
> 
> https://downloads.haskell.org/~ghc/7.10.3-rc1/
> 
> This includes the source tarball and bindists for 64-bit and 32-bit
> modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs
> have an accompanying SHA256SUMS file signed by my GPG key id
> (0x97DB64AD). As always, our content delivery network tends to be a bit
> slow on the uptake. If you see an empty directory at this URL just add a
> few superfluous slashes to the end; this is typically enough to fool it.
> 
> The 7.10.2 release was well-behaved save a couple notable bugs; while we
> have merged a good number of bug fixes in 7.10.3 they were were
> largely low risk and so we expect that this release should be
> similiarly stable.
> 
> The one exception to this is an upgrade of the Windows compiler
> toolchain to GCC 5.2. Windows users have been long suffering at the hand
> of our old toolchain (e.g. lack of response file support, #8596, and
> lack of SEH support) so we expect that this change should fix far more
> than breaks.
> 
> We plan to make the 7.10.3 release sometime next week.
> 
> Please test this as much as possible; bugs are much cheaper if we find
> them before the release and this will ideally be the last release of the
> 7.10 series.
> 
> Happy testing,
> 
> - 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

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

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Ben Gamari]

Páli Gábor János  writes:

> 2015-11-02 19:27 GMT+01:00 Joachim Breitner :
>> Isn’t such a mail a requirement for those wo build the various binaries
>> to get active in the first place?
>
> I think that would require at least an accessible source tarball in
> the first place :-)  But apparently there are no files under the
> specified directory.
>
It may appear that way but this is merely an unfortunate side-effect of
our content delivery network. Try adding some extra `/` characters to
the URL, e.g.,

https://downloads.haskell.org/~ghc/7.10.3-rc1//

This is usually enough to fool the CDN info refreshing.

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: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Páli Gábor János]

2015-11-02 19:27 GMT+01:00 Joachim Breitner :
> Isn’t such a mail a requirement for those wo build the various binaries
> to get active in the first place?

I think that would require at least an accessible source tarball in
the first place :-)  But apparently there are no files under the
specified directory.

Cheers,
Gábor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Ben Gamari]

Joachim Breitner  writes:

> Hi,
>
> Am Montag, den 02.11.2015, 13:21 -0500 schrieb Richard Eisenberg:
>> Personally, I would love delaying announcements such as these until
>> binaries are available, at least for Linux, Mac, and Windows.
>
> it’s a release candidate, announced on the developer mailing list.
> Isn’t such a mail a requirement for those wo build the various binaries
> to get active in the first place? Or is all done by Ben these days.
>
The Windows and Linux builds are done by me. The Mac situation is a bit
more complicated as neither Austin nor I have access to an OS X machine.
We are working on getting access to such a machine, but this takes time.

Ideally, the first-tier platforms are supposed[1] to have a sponsor who
is able to work with us to produce the builds and keep track of
platform-specific issues. Sadly OS X has lacked such a person for some
time. We've perhaps not broadcast the need for such a person loudly
enough which is largely my fault. Regardless, it would be extremely
helpful if someone familiar with OS X could step up to fill this role.

To be clear, we certainly won't be cutting a 7.10.3 release until we
know that the release candidate has been adequately tested on OS X.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Platforms


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

[ANNOUNCE] GHC 7.10.3 release candidate 1

[Ben Gamari]

We are pleased to announce the first (and hopefully only) release
candidate for GHC 7.10.3:

https://downloads.haskell.org/~ghc/7.10.3-rc1/

This includes the source tarball and bindists for 64-bit and 32-bit
modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs
have an accompanying SHA256SUMS file signed by my GPG key id
(0x97DB64AD). As always, our content delivery network tends to be a bit
slow on the uptake. If you see an empty directory at this URL just add a
few superfluous slashes to the end; this is typically enough to fool it.

The 7.10.2 release was well-behaved save a couple notable bugs; while we
have merged a good number of bug fixes in 7.10.3 they were were
largely low risk and so we expect that this release should be
similiarly stable.

The one exception to this is an upgrade of the Windows compiler
toolchain to GCC 5.2. Windows users have been long suffering at the hand
of our old toolchain (e.g. lack of response file support, #8596, and
lack of SEH support) so we expect that this change should fix far more
than breaks.

We plan to make the 7.10.3 release sometime next week.

Please test this as much as possible; bugs are much cheaper if we find
them before the release and this will ideally be the last release of the
7.10 series.

Happy testing,

- 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: process library broken on Windows

[Michael Snoyman]

I'd rather not change the public API (even though it's an internal module)
in a way we'll later undo to avoid a warning, when the code cleanup should
achieve the goal without making that modification. I've pushed my changes
to the less-cpp branch, if anyone wants to play with the changes thus far.
I've also modified the Travis build to use -Wall -Werror, and added an
AppVeyor Windows build that similarly uses -Werror.

On Mon, Nov 2, 2015 at 6:44 AM, Simon Marlow  wrote:

> -Wwarn shouldn't really be in source code.  Since it's an Internals
> module, I would just export it.  Maybe add a {-# WARNING #-} to discourage
> people from using it.
>
> Cheers
> Simon
>
> On 02/11/2015 06:14, Michael Snoyman wrote:
>
>>
>>
>> On Mon, Nov 2, 2015 at 5:57 AM, Simon Peyton Jones
>> > wrote:
>>
>> Aha.  It would be great to say all that in the source code!!  It’s
>> very non-obvious that you not want people ever to construct a CGId
>> on Windows.  After all, it has a newtype definition!
>>
>> __
>>
>>
>> Good call, I'll update with some comments (though see refactoring
>> comments below).
>>
>> __
>>
>> Could you declare it differently?
>>
>>  data CGId   -- No constructors
>>
>> __
>>
>>
>> Certainly we could. Then the question would be "why does the Windows
>> code look so different?" There are lots of colors to this bikeshed, and
>> I don't have any particular affinity to any of them. If you'd prefer it
>> looked that way, I can make that change. I initially erred with making
>> the code as similar to the POSIX code as possible.
>>
>> __
>>
>> Also if so, why does the Windows-specific foreign import of
>> c_runInteractiveProcess (lin 440-is) pas a Ptr CGId? You’d just told
>> me that we can never create one.
>>
>> __
>>
>>
>>
>> The Windows-specific foreign import is on line ~533, and does not
>> include those arguments.
>>
>> __
>>
>> Also, 
>>
>> __·__It’d help to comment the #else on line 456 as being “else if
>> not windows”
>>
>> __·__The #endifs on line 546 or thereabouts are mis-labelled.  at
>> the moment the second says “GLASGOW_HASKELL” but actually it’s the
>> first
>>
>> __
>>
>>
>>
>> Agreed that the code is fairly difficult to follow with the nested
>> ifdefs. However, instead of trying to salvage that, it's probably worth
>> a refactoring to put the Windows and POSIX code into separate modules
>> and then just import those conditionally.
>>
>> __
>>
>> I have no opinion about the best solution; I’d just like it to
>> compile and preferably warning free since that is our default
>> policy.  Or add a –Wwarn at the top.
>>
>> __
>>
>>
>> If you're looking for a short-term solution, I can add -Wwarn to the top
>> until some kind of refactoring takes place.
>>
>> __
>>
>> thanks
>>
>> __ __
>>
>> Simon
>>
>> __ __
>>
>> __ __
>>
>> *From:*michael.snoy...@gmail.com 
>> [mailto:michael.snoy...@gmail.com
>> ] *On Behalf Of *Michael Snoyman
>> *Sent:* 02 November 2015 13:42
>>
>>
>> *To:* Simon Peyton Jones
>> *Cc:* ghc-devs@haskell.org 
>> *Subject:* Re: process library broken on Windows
>>
>> __ __
>>
>> That's the goal; it's a feature that does not work on Windows, only
>> on non-Windows systems (setuid/setgid for a child process). For
>> POSIX systems, CGid is exported from base, and can be used. On
>> Windows, the data type is present to give the same signature, but
>> the constructor itself is not exported to prevent using the feature.
>> An argument could be made for other approaches:
>>
>> __ __
>>
>> 1. Expose the constructor, allowing users to set a value, and that
>> value will be ignored
>>
>> 2. Make the fields themselves conditional on the OS being used
>>
>> __ __
>>
>> I don't think there's a strong argument in any direction for this.
>>
>> __ __
>>
>> On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones
>> > wrote:
>>
>> I’m puzzled.   Internals.hs defines a newtype
>>
>> 
>>
>> newtype CGid = CGid Word32
>>
>> 
>>
>> A value of this type is needed to fill in the child_group field
>> of CreateProcess.  If you don’t export it, you could never
>> initialise this field to anything other than Nothing, so why do
>> you have it?
>>
>> 
>>
>> Looks to me as if the warning has nailed a real bug
>>
>> 
>>
>> Simon
>>
>> 
>>
>> *From:*michael.snoy...@gmail.com
>> 
>> [mailto:michael.snoy...@gmail.com
>>

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Austin Seipp]

Yeah, I really need to work a trigger into the downloads machine so
that we can clear the CDN cache when we upload/update files... It's
about a mile down my TODO list though (since it bites somewhat rarely
for these cases) - so anyone who wants to do a little JSON API
chatting with Fastly should talk to me. :)

On Mon, Nov 2, 2015 at 2:49 PM, Ben Gamari  wrote:
> Páli Gábor János  writes:
>
>> 2015-11-02 19:27 GMT+01:00 Joachim Breitner :
>>> Isn’t such a mail a requirement for those wo build the various binaries
>>> to get active in the first place?
>>
>> I think that would require at least an accessible source tarball in
>> the first place :-)  But apparently there are no files under the
>> specified directory.
>>
> It may appear that way but this is merely an unfortunate side-effect of
> our content delivery network. Try adding some extra `/` characters to
> the URL, e.g.,
>
> https://downloads.haskell.org/~ghc/7.10.3-rc1//
>
> This is usually enough to fool the CDN info refreshing.
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Austin Seipp]

Yeah, so in the past Tier 1 platforms (OS X, Win, Lin, FreeBSD) are
always available, but I rarely (if ever) held up RCs for anything
besides that. I do have a list of people to alert, though... (Karel
takes care of Solaris for example as time permits).

Even then, I wasn't always the one doing the builds... Gabor takes
care of FreeBSD for me. And Mark was doing the OS X builds before,
because he had an excellent test farm that allowed him to test a
release across an array of OS X versions.

Right now we're working on getting a Mac. I'll have short-term access
to one by tomorrow thankfully, and be getting a new machine soon. So
hopefully this won't be a problem going forward, although some
knowledge transfer from Mark might be in order. :)

On Mon, Nov 2, 2015 at 12:27 PM, Joachim Breitner
 wrote:
> Hi,
>
> Am Montag, den 02.11.2015, 13:21 -0500 schrieb Richard Eisenberg:
>> Personally, I would love delaying announcements such as these until
>> binaries are available, at least for Linux, Mac, and Windows.
>
> it’s a release candidate, announced on the developer mailing list.
> Isn’t such a mail a requirement for those wo build the various binaries
> to get active in the first place? Or is all done by Ben these days.
>
> I’m happy to get the announcement as quickly as possible, as I was
> waiting for the source tarball :-)
>
> Greetings,
> Joachim
>
>
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • http://www.joachim-breitner.de/
>   Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs