RE: Missed beta reductions

2018-03-26 Thread David Feuer 
Hmmm. So you think maybe it's doing something like (roughly; I don't have the 
exact case in front of me)
(\p q -> f p (g p q)) this that
==> beta reduce
let  p = this  q = thatin f p (g p q)
==> inline q
let  p = thisin f p (g p that)?
I tried marking the "this" in question INLINE CONLIKE [0]. Shouldn't that tell 
GHC that duplicating it is fine? I really want to see it for RULES.

David FeuerWell-Typed, LLP
 Original message From: Simon Peyton Jones 
 Date: 3/26/18  7:14 PM  (GMT-05:00) To: David Feuer 
, ghc-devs@haskell.org Subject: RE: Missed beta 
reductions 
GHC always beta-reduces.

It does not always inline.   For that: -ddump-inlinings

Simon

From: ghc-devs  On Behalf Of David Feuer
Sent: 26 March 2018 23:59
To: ghc-devs@haskell.org
Subject: Missed beta reductions

What's the best way to find spots where GHC saw a redex and choose not to beta 
reduce? Is there a flag for that? It could be useful when trying to figure out 
why rules aren't firing.


David Feuer
Well-Typed, LLP
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Missed beta reductions

2018-03-26 Thread Simon Peyton Jones via ghc-devs 
GHC always beta-reduces.

It does not always inline.   For that: -ddump-inlinings

Simon

From: ghc-devs  On Behalf Of David Feuer
Sent: 26 March 2018 23:59
To: ghc-devs@haskell.org
Subject: Missed beta reductions

What's the best way to find spots where GHC saw a redex and choose not to beta 
reduce? Is there a flag for that? It could be useful when trying to figure out 
why rules aren't firing.


David Feuer
Well-Typed, LLP
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Missed beta reductions

2018-03-26 Thread David Feuer 
What's the best way to find spots where GHC saw a redex and choose not to beta 
reduce? Is there a flag for that? It could be useful when trying to figure out 
why rules aren't firing.

David FeuerWell-Typed, LLP___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Question about indirectees of BLACKHOLE closures

2018-03-26 Thread Ben Gamari 
Simon Marlow  writes:

> The raise closure is declared to be a THUNK:
>
> https://phabricator.haskell.org/diffusion/GHC/browse/master/rts/Exception.cmm;60e29dc2611f5c1a01cfd9a870841927847a7b74$424
>
> Another example of this is when an asynchronous exception is thrown, and we
> update all the thunks/BLACKHOLEs pointed to by the update frames to point
> to new thunks (actually AP_STACK closures) representing the frozen state of
> evaluation of those thunks.  For this, see rts/RaiseAsync.c.
>
This thread has answered a number of interesting questions. It would be
a shame if these answers vanished into the abyss of the ghc-devs
archives.

Omer, do you think you could make sure that the discussion here is
summarized in a Note (or ensure that the relevant notes reference one
another, if they already exist)?

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: Updating Phabricator

2018-03-26 Thread Ben Gamari 
Ben Gamari  writes:

> Ben Gamari  writes:
>
>> Hello everyone,
>>
>> In around 90 minutes I will start a Phabricator upgrade. It has been a
>> few months since the last update so it may take up 30 minutes or so.
>> I'll send a message before starting.
>>
> I'll begin the upgrade in about 10 minutes.
>
The update is finished. As always, let me know if anything seems amiss.

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: Updating Phabricator

2018-03-26 Thread Ben Gamari 
Ben Gamari  writes:

> Hello everyone,
>
> In around 90 minutes I will start a Phabricator upgrade. It has been a
> few months since the last update so it may take up 30 minutes or so.
> I'll send a message before starting.
>
I'll begin the upgrade in about 10 minutes.

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

Updating Phabricator

2018-03-26 Thread Ben Gamari 
Hello everyone,

In around 90 minutes I will start a Phabricator upgrade. It has been a
few months since the last update so it may take up 30 minutes or so.
I'll send a message before starting.

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: Windows

2018-03-26 Thread Phyx 
On Mon, Mar 26, 2018 at 11:08 AM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> One other thing. The instructions at
>
> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
>
> say to set PATH thus
>
>
>
> export PATH=/mingw64/bin:\$PATH
>
>
>
> But
>
>- in the installation tree I got from msys, *there IS no
>c:/mingw64/bin*.
>- I have a root directory c:/msys64.
>
>
These are correct, the instructions are written from the point of view of a
msys2 environment and not the Windows one.
So /mingw64 refers to an msys2 path not a windows path. In windows the /
would indeed be interpreted to %HOMEDRIVE%/mingw64
but in msys2 this refers to what the msy2 filesystem has been mounted to.
This is usually C:\msys64.

Tamar@Yelow ~/ghc2> cygpath -w /mingw64/bin/
E:\msys64\mingw64\bin\

the msys2 tool cygpath converts between the two usually on demand. but you
can query it for paths.
What the instructions intended was for you to modify your msys2
environment, not your Windows one, as generally putting
Cygwin derived programs on your global windows path is not advisable.


>
>-
>- Most binaries (eg *bash*, *find*) seem to be in c:/mingw64/usr/bin
>
> Yes, any binary that is a posix port, e.g. depends on newlib crt instead
of the Microsoft runtime goes into the usual /usr/bin folder. This would
include core-utils,
make etc.


>
>-
>- But there is also c:/msys64/mingw64/bin, which (perhaps as a result
>of the pacman step) has lots more stuf like *ar*, *cc*, etc.
>
> This folder is meant to contain native ports, e.g. programs that have been
"ported" to work on Windows using a standard windows runtime. These have no
dependencies on
newlib/Cygwin. This is the distinctions between these two folders.


>-
>
>
>
> All very confusing.  For now I have put both c:/msys64/usr/bin and
> c:/msys64/mingw64/bin in my path.   That seems to work, but is clearly not
> what the instructions say.
>

The instruction could be somewhat clearer here, but they are intended to
only affect your msys2 installation, and never your global Windows system.


>
>
> Thanks
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Shao, Cheng
> *Sent:* 26 March 2018 10:59
> *To:* ghc-devs@haskell.org
> *Subject:* Re: Windows
>
>
>
> Hi Simon,
>
>
>
> If the build environment is managed by an MSYS2 installation, then the
> MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It
> can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".
>
>
>
> On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> Making it part of the error message would be v helpful.
>
> I have added a section to "Troubleshooting" on
> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
>
> But it should really be part of the instructions higher up to sa
> export MSYSTEM=MINGW64
>
> Might someone do that?  I wasn't quite sure where
>
> Simon
>
>
> |  -Original Message-
> |  From: ghc-devs  On Behalf Of Ben Gamari
> |  Sent: 24 March 2018 16:42
> |  To: Gabor Greif ; loneti...@gmail.com
> |  Cc: ghc-devs@haskell.org
> |  Subject: Re: Windows
> |
> |  Gabor Greif  writes:
> |
> |  > Just an idea...
> |  >
> |  > could this hint be part of the `configure` error message?
> |  >
> |  Indeed. See D4526.
> |
> |  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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Windows

2018-03-26 Thread Simon Peyton Jones via ghc-devs 
I would personally avoid the use of mintty because of how it implements pty

OK thanks.

If I remember correctly you have a setup where you use bash directly in emacs.

Correct

In which case you just need To set the environment variables and add 
/mingw64/bin to your path.

But set which envt variables to what, precisely?

As I say in another email, c:/mingw64 doesn’t exist.   c:/msys64 does, and 
c:/msys64/mingw64.  Very confusing!

Thanks

Simon


From: loneti...@gmail.com 
Sent: 26 March 2018 11:09
To: Simon Peyton Jones ; Shao, Cheng 
; ghc-devs@haskell.org
Subject: RE: Windows

“C:\msys64\msys2_shell.cmd -mingw64 -mintty”

Won’t work for you as it spawns a new process using mintty as your terminal 
emulator.
If I remember correctly you have a setup where you use bash directly in emacs. 
In which case you just need
To set the environment variables and add /mingw64/bin to your path.

I would personally avoid the use of mintty because of how it implements pty. 
Lots of interactive programs don’t work
Correctly under it, including ghci where we need specific hacks to work around 
some of it’s issues https://github.com/mintty/mintty/issues/56.

From: Simon Peyton Jones via ghc-devs
Sent: Monday, March 26, 2018 11:03
To: Shao, Cheng; 
ghc-devs@haskell.org
Subject: RE: Windows

If the build environment is managed by an MSYS2 installation, then the MinGW64 
shell startup script automatically sets up "MSYSTEM" for you. It can be 
launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".
Well I just followed the Method A instructions at
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" 
just once, after installing?  Or repeatedly?  Or that I should somehow us it as 
my main shell?  And what does that commend actually do?
Sorry to be dense

Simon

From: ghc-devs 
> On Behalf 
Of Shao, Cheng
Sent: 26 March 2018 10:59
To: ghc-devs@haskell.org
Subject: Re: Windows

Hi Simon,

If the build environment is managed by an MSYS2 installation, then the MinGW64 
shell startup script automatically sets up "MSYSTEM" for you. It can be 
launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".

On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs 
> wrote:
Making it part of the error message would be v helpful.

I have added a section to "Troubleshooting" on
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

But it should really be part of the instructions higher up to sa
export MSYSTEM=MINGW64

Might someone do that?  I wasn't quite sure where

Simon

|  -Original Message-
|  From: ghc-devs 
> On Behalf 
Of Ben Gamari
|  Sent: 24 March 2018 16:42
|  To: Gabor Greif >; 
loneti...@gmail.com
|  Cc: ghc-devs@haskell.org
|  Subject: Re: Windows
|
|  Gabor Greif > writes:
|
|  > Just an idea...
|  >
|  > could this hint be part of the `configure` error message?
|  >
|  Indeed. See D4526.
|
|  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: Windows

2018-03-26 Thread Simon Peyton Jones via ghc-devs 
Running “C:\msys64\msys2_shell.cmd -mingw64 -mintty" has the same effect as 
clicking on the "MinGW-w64 Win64 Shell" shortcut. It is the proper way to start 
an mingw64 shell.

Interesting.  Most shells are started by ‘make’.   I think it uses the SHELL 
envt variable to decide what to start.  Currently I have that set to

  *   c:/msys64/usr/bin/bash
Are you saying that I should put

  *   C:\msys64\msys2_shell.cmd -mingw64 -mintty
into my SHELL envt variable?

(Also: I always a shell within emacs, rather that an msys window, and it uses 
SHELL to decide what to run.)

Also: is this related to the
export MSYSTEM=MINGW64
question?

Thanks

Simon

From: ghc-devs  On Behalf Of Shao, Cheng
Sent: 26 March 2018 11:07
To: ghc-devs@haskell.org
Subject: Re: Windows

Hi Simon,

Running “C:\msys64\msys2_shell.cmd -mingw64 -mintty" has the same effect as 
clicking on the "MinGW-w64 Win64 Shell" shortcut. It is the proper way to start 
an mingw64 shell. If you have run "pacman -S" to update the MSYS2 packages 
before, then the old shortcuts setup by the MSYS2 installer may cease to 
function, and you can put a new shortcut on your desktop with that command.

On Mon, Mar 26, 2018 at 6:02 PM, Simon Peyton Jones 
> wrote:
If the build environment is managed by an MSYS2 installation, then the MinGW64 
shell startup script automatically sets up "MSYSTEM" for you. It can be 
launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".
Well I just followed the Method A instructions at
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" 
just once, after installing?  Or repeatedly?  Or that I should somehow us it as 
my main shell?  And what does that commend actually do?
Sorry to be dense

Simon

From: ghc-devs 
> On Behalf 
Of Shao, Cheng
Sent: 26 March 2018 10:59
To: ghc-devs@haskell.org
Subject: Re: Windows

Hi Simon,

If the build environment is managed by an MSYS2 installation, then the MinGW64 
shell startup script automatically sets up "MSYSTEM" for you. It can be 
launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".

On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs 
> wrote:
Making it part of the error message would be v helpful.

I have added a section to "Troubleshooting" on
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

But it should really be part of the instructions higher up to sa
export MSYSTEM=MINGW64

Might someone do that?  I wasn't quite sure where

Simon

|  -Original Message-
|  From: ghc-devs 
> On Behalf 
Of Ben Gamari
|  Sent: 24 March 2018 16:42
|  To: Gabor Greif >; 
loneti...@gmail.com
|  Cc: ghc-devs@haskell.org
|  Subject: Re: Windows
|
|  Gabor Greif > writes:
|
|  > Just an idea...
|  >
|  > could this hint be part of the `configure` error message?
|  >
|  Indeed. See D4526.
|
|  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: Windows

2018-03-26 Thread lonetiger 
“C:\msys64\msys2_shell.cmd -mingw64 -mintty”

Won’t work for you as it spawns a new process using mintty as your terminal 
emulator.
If I remember correctly you have a setup where you use bash directly in emacs. 
In which case you just need
To set the environment variables and add /mingw64/bin to your path.

I would personally avoid the use of mintty because of how it implements pty. 
Lots of interactive programs don’t work
Correctly under it, including ghci where we need specific hacks to work around 
some of it’s issues https://github.com/mintty/mintty/issues/56.

From: Simon Peyton Jones via ghc-devs
Sent: Monday, March 26, 2018 11:03
To: Shao, Cheng; ghc-devs@haskell.org
Subject: RE: Windows

If the build environment is managed by an MSYS2 installation, then the MinGW64 
shell startup script automatically sets up "MSYSTEM" for you. It can be 
launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".
Well I just followed the Method A instructions at 
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" 
just once, after installing?  Or repeatedly?  Or that I should somehow us it as 
my main shell?  And what does that commend actually do?
Sorry to be dense

Simon

From: ghc-devs  On Behalf Of Shao, Cheng
Sent: 26 March 2018 10:59
To: ghc-devs@haskell.org
Subject: Re: Windows

Hi Simon,

If the build environment is managed by an MSYS2 installation, then the MinGW64 
shell startup script automatically sets up "MSYSTEM" for you. It can be 
launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".

On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs 
 wrote:
Making it part of the error message would be v helpful.

I have added a section to "Troubleshooting" on
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

But it should really be part of the instructions higher up to sa
        export MSYSTEM=MINGW64

Might someone do that?  I wasn't quite sure where

Simon

|  -Original Message-
|  From: ghc-devs  On Behalf Of Ben Gamari
|  Sent: 24 March 2018 16:42
|  To: Gabor Greif ; loneti...@gmail.com
|  Cc: ghc-devs@haskell.org
|  Subject: Re: Windows
|
|  Gabor Greif  writes:
|
|  > Just an idea...
|  >
|  > could this hint be part of the `configure` error message?
|  >
|  Indeed. See D4526.
|
|  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: Windows

2018-03-26 Thread Simon Peyton Jones via ghc-devs 
One other thing. The instructions at
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
say to set PATH thus

export PATH=/mingw64/bin:\$PATH

But

  *   in the installation tree I got from msys, there IS no c:/mingw64/bin.
  *   I have a root directory c:/msys64.
  *   Most binaries (eg bash, find) seem to be in c:/mingw64/usr/bin
  *   But there is also c:/msys64/mingw64/bin, which (perhaps as a result of 
the pacman step) has lots more stuf like ar, cc, etc.

All very confusing.  For now I have put both c:/msys64/usr/bin and 
c:/msys64/mingw64/bin in my path.   That seems to work, but is clearly not what 
the instructions say.

Thanks

Simon

From: ghc-devs  On Behalf Of Shao, Cheng
Sent: 26 March 2018 10:59
To: ghc-devs@haskell.org
Subject: Re: Windows

Hi Simon,

If the build environment is managed by an MSYS2 installation, then the MinGW64 
shell startup script automatically sets up "MSYSTEM" for you. It can be 
launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".

On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs 
> wrote:
Making it part of the error message would be v helpful.

I have added a section to "Troubleshooting" on
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

But it should really be part of the instructions higher up to sa
export MSYSTEM=MINGW64

Might someone do that?  I wasn't quite sure where

Simon

|  -Original Message-
|  From: ghc-devs 
> On Behalf 
Of Ben Gamari
|  Sent: 24 March 2018 16:42
|  To: Gabor Greif >; 
loneti...@gmail.com
|  Cc: ghc-devs@haskell.org
|  Subject: Re: Windows
|
|  Gabor Greif > writes:
|
|  > Just an idea...
|  >
|  > could this hint be part of the `configure` error message?
|  >
|  Indeed. See D4526.
|
|  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: Windows

2018-03-26 Thread Shao, Cheng 
Hi Simon,

Running “C:\msys64\msys2_shell.cmd -mingw64 -mintty" has the same effect as
clicking on the "MinGW-w64 Win64 Shell" shortcut. It is the proper way to
start an mingw64 shell. If you have run "pacman -S" to update the MSYS2
packages before, then the old shortcuts setup by the MSYS2 installer may
cease to function, and you can put a new shortcut on your desktop with that
command.

On Mon, Mar 26, 2018 at 6:02 PM, Simon Peyton Jones 
wrote:

> If the build environment is managed by an MSYS2 installation, then the
> MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It
> can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".
>
> Well I just followed the Method A instructions at
>
> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
>
>
>
> Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64
> -mintty" just once, after installing?  Or repeatedly?  Or that I should
> somehow us it as my main shell?  And what does that commend actually do?
>
> Sorry to be dense
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Shao, Cheng
> *Sent:* 26 March 2018 10:59
> *To:* ghc-devs@haskell.org
> *Subject:* Re: Windows
>
>
>
> Hi Simon,
>
>
>
> If the build environment is managed by an MSYS2 installation, then the
> MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It
> can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".
>
>
>
> On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> Making it part of the error message would be v helpful.
>
> I have added a section to "Troubleshooting" on
> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
>
> But it should really be part of the instructions higher up to sa
> export MSYSTEM=MINGW64
>
> Might someone do that?  I wasn't quite sure where
>
> Simon
>
>
> |  -Original Message-
> |  From: ghc-devs  On Behalf Of Ben Gamari
> |  Sent: 24 March 2018 16:42
> |  To: Gabor Greif ; loneti...@gmail.com
> |  Cc: ghc-devs@haskell.org
> |  Subject: Re: Windows
> |
> |  Gabor Greif  writes:
> |
> |  > Just an idea...
> |  >
> |  > could this hint be part of the `configure` error message?
> |  >
> |  Indeed. See D4526.
> |
> |  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: Windows

2018-03-26 Thread Simon Peyton Jones via ghc-devs 
If the build environment is managed by an MSYS2 installation, then the MinGW64 
shell startup script automatically sets up "MSYSTEM" for you. It can be 
launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".
Well I just followed the Method A instructions at
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" 
just once, after installing?  Or repeatedly?  Or that I should somehow us it as 
my main shell?  And what does that commend actually do?
Sorry to be dense

Simon

From: ghc-devs  On Behalf Of Shao, Cheng
Sent: 26 March 2018 10:59
To: ghc-devs@haskell.org
Subject: Re: Windows

Hi Simon,

If the build environment is managed by an MSYS2 installation, then the MinGW64 
shell startup script automatically sets up "MSYSTEM" for you. It can be 
launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".

On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs 
> wrote:
Making it part of the error message would be v helpful.

I have added a section to "Troubleshooting" on
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

But it should really be part of the instructions higher up to sa
export MSYSTEM=MINGW64

Might someone do that?  I wasn't quite sure where

Simon

|  -Original Message-
|  From: ghc-devs 
> On Behalf 
Of Ben Gamari
|  Sent: 24 March 2018 16:42
|  To: Gabor Greif >; 
loneti...@gmail.com
|  Cc: ghc-devs@haskell.org
|  Subject: Re: Windows
|
|  Gabor Greif > writes:
|
|  > Just an idea...
|  >
|  > could this hint be part of the `configure` error message?
|  >
|  Indeed. See D4526.
|
|  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: Windows

2018-03-26 Thread Shao, Cheng 
Hi Simon,

If the build environment is managed by an MSYS2 installation, then the
MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It
can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".

On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Making it part of the error message would be v helpful.
>
> I have added a section to "Troubleshooting" on
> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
>
> But it should really be part of the instructions higher up to sa
> export MSYSTEM=MINGW64
>
> Might someone do that?  I wasn't quite sure where
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs  On Behalf Of Ben Gamari
> |  Sent: 24 March 2018 16:42
> |  To: Gabor Greif ; loneti...@gmail.com
> |  Cc: ghc-devs@haskell.org
> |  Subject: Re: Windows
> |
> |  Gabor Greif  writes:
> |
> |  > Just an idea...
> |  >
> |  > could this hint be part of the `configure` error message?
> |  >
> |  Indeed. See D4526.
> |
> |  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: Windows

2018-03-26 Thread Simon Peyton Jones via ghc-devs 
Making it part of the error message would be v helpful.

I have added a section to "Troubleshooting" on 
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

But it should really be part of the instructions higher up to sa
export MSYSTEM=MINGW64

Might someone do that?  I wasn't quite sure where

Simon

|  -Original Message-
|  From: ghc-devs  On Behalf Of Ben Gamari
|  Sent: 24 March 2018 16:42
|  To: Gabor Greif ; loneti...@gmail.com
|  Cc: ghc-devs@haskell.org
|  Subject: Re: Windows
|  
|  Gabor Greif  writes:
|  
|  > Just an idea...
|  >
|  > could this hint be part of the `configure` error message?
|  >
|  Indeed. See D4526.
|  
|  Cheers,
|  
|  - Ben

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

RE: Curious demand in a function parameter

2018-03-26 Thread Simon Peyton Jones via ghc-devs 
|  but clearly `y` is not used on all code paths, so I don't understand
|  why we have a strict demand here.

Why is f strict in y?

Consider

factorial n acc
  | n <0 = error "bad arg"
  | n==1 = acc
  | otherwise = factorial (n-1) (n*acc)

Is this strict in 'acc'.  GHC says "yes" because it's MUCH more efficient to be 
strict in 'acc'; and we don’t to the thrown off by the error case.

Also, formally, is  (factorial n bottom) equal to bottom? Yes, even if n<0, 
because error returns bottom.


---

|  Interestingly, when I try to make GHC generate a worker and a wrapper
|  for this function to make the program fail by evaluating `y` eagerly I
|  somehow got a lazy demand on `y`:

That's a little more surprising to me, but as Sebastian point out you have now 
written a function that ALWAYS returns bottom.  That's not a very interesting 
function!  And GHC doesn't make much effort to optimise it.  I have not looked 
into why GHC doesn't eta-expand guaranteed-bottom functions, but I bet there's 
a note about it.  And I don't care much!

Simon


|  -Original Message-
|  From: ghc-devs  On Behalf Of Ömer Sinan
|  Agacan
|  Sent: 25 March 2018 08:14
|  To: ghc-devs 
|  Subject: Curious demand in a function parameter
|  
|  Hi,
|  
|  In this program
|  
|  {-# LANGUAGE MagicHash #-}
|  
|  module Lib where
|  
|  import Control.Exception
|  import GHC.Exts
|  import GHC.IO
|  
|  data Err = Err
|deriving (Show)
|  instance Exception Err
|  
|  f :: Int -> Int -> IO Int
|  f x y | x > 0 = IO (raiseIO# (toException Err))
|| y > 0 = return 1
|| otherwise = return 2
|  
|  when I compile this with 8.4 -O2 I get a strict demand on `y`:
|  
|  f :: Int -> Int -> IO Int
|  [GblId,
|   Arity=3,
|   Str=,
|   ...]
|  
|  but clearly `y` is not used on all code paths, so I don't understand
|  why we have a strict demand here.
|  
|  I found this example in the comments around `raiseIO#`:
|  
|  -- raiseIO# needs to be a primop, because exceptions in the IO
|  monad
|  -- must be *precise* - we don't want the strictness analyser
|  turning
|  -- one kind of bottom into another, as it is allowed to do in pure
|  code.
|  --
|  -- But we *do* want to know that it returns bottom after
|  -- being applied to two arguments, so that this function is strict
|  in y
|  -- f x y | x>0   = raiseIO blah
|  --   | y>0   = return 1
|  --   | otherwise = return 2
|  
|  However it doesn't explain why we want be strict on `y`.
|  
|  Interestingly, when I try to make GHC generate a worker and a wrapper
|  for this function to make the program fail by evaluating `y` eagerly I
|  somehow got a lazy demand on `y`:
|  
|  {-# LANGUAGE MagicHash #-}
|  
|  module Main where
|  
|  import Control.Exception
|  import GHC.Exts
|  import GHC.IO
|  
|  data Err = Err
|deriving (Show)
|  instance Exception Err
|  
|  f :: Int -> Int -> IO Int
|  f x y | x > 0 = IO (raiseIO# (toException Err))
|| y > 0 = f x (y - 1)
|| otherwise = f (x - 1) y
|  
|  main = f 1 undefined
|  
|  I was thinking that this program should fail with "undefined" instead
|  of "Err", but the demand I got for `f` became:
|  
|  f :: Int -> Int -> IO Int
|  [GblId,
|   Arity=2,
|   Str=,
|   ...]
|  
|  which makes sense to me. But I don't understand how my changes can
|  change `y`s demand, and why the original demand is strict rather than
|  lazy. Could anyone give me some pointers?
|  
|  Thanks
|  
|  Ömer
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs=02%7C01%7Csimonpj%40microsoft.com%7C79b17f4f38684f15c4a308d5
|  9220339a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365755894481854
|  06=T7ZJjz%2Bek5CFAUYtt9CmEkRLIml0OAj8yEU5fTsuFC0%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Question about indirectees of BLACKHOLE closures

2018-03-26 Thread Simon Marlow 
The raise closure is declared to be a THUNK:

https://phabricator.haskell.org/diffusion/GHC/browse/master/rts/Exception.cmm;60e29dc2611f5c1a01cfd9a870841927847a7b74$424

Another example of this is when an asynchronous exception is thrown, and we
update all the thunks/BLACKHOLEs pointed to by the update frames to point
to new thunks (actually AP_STACK closures) representing the frozen state of
evaluation of those thunks.  For this, see rts/RaiseAsync.c.

Cheers
Simon

On 24 March 2018 at 19:27, Ömer Sinan Ağacan  wrote:

> Hi Rahul,
>
> I'm still confused. The code that walks the stack and updates UPDATE_FRAMEs
> only makes indirections point to the "raise" closure, not to thunks or
> anything
> else (I also don't understand why this is needed but I guess that's another
> topic). I still don't see how can a BLACKHOLE point to a THUNK.
>
> Ömer
>
> 2018-03-23 18:51 GMT+03:00 Rahul Muttineni :
> > Hi Omer,
> >
> > As per my understanding, a BLACKHOLE can point to a THUNK when an
> exception
> > is thrown. An exception walks up the stack and overwrites the blackholes
> > pointed to by the update frames as it walks with an stg_raise closure.
> That
> > way, if any concurrent thread happens to evaluate a thunk that was
> walked,
> > it'll evaluate the thunk which will blow up as well thereby throwing the
> > exception on the other thread(s) too.
> >
> > Definition of stg_raise:
> > https://github.com/ghc/ghc/blob/ba5797937e575ce6119de6c07703e9
> 0dda2557e8/rts/Exception.cmm#L424-L427
> >
> > raiseExceptionHelper dealing with update frames:
> > https://github.com/ghc/ghc/blob/d9d463289fe20316cff12a8f0dbf41
> 4db678fa72/rts/Schedule.c#L2864-L2875
> >
> > In general, yes, you can think that a BLACKHOLE will point to a non-THUNK
> > object assuming that everything went right.
> >
> > Hope that helps,
> > Rahul
> >
> > On Fri, Mar 23, 2018 at 5:48 PM, Ömer Sinan Ağacan  >
> > wrote:
> >>
> >> Thanks Simon, that's really helpful.
> >>
> >> A few more questions:
> >>
> >> As far as I understand the difference between
> >>
> >> - BLACKHOLE pointing to a TSO
> >> - BLACKHOLE pointing to a BLOCKING_QUEUE
> >>
> >> is that in the former we don't yet have any threads blocked by the
> >> BLACKHOLE
> >> whereas in the latter we have and the blocking queue holds all those
> >> blocked
> >> threads. Did I get this right?
> >>
> >> Secondly, can a BLACKHOLE point to a THUNK? I'd expect no, because we
> >> BLACKHOLE
> >> a closure when we're done evaluating it (assuming no eager blackholing),
> >> and
> >> evaluation usually happens up to WHNF.
> >>
> >> Thanks,
> >>
> >> Ömer
> >>
> >> 2018-03-20 18:27 GMT+03:00 Simon Marlow :
> >> > Added comments: https://phabricator.haskell.org/D4517
> >> >
> >> > On 20 March 2018 at 14:58, Simon Marlow  wrote:
> >> >>
> >> >> Hi Omer,
> >> >>
> >> >> On 20 March 2018 at 13:05, Ömer Sinan Ağacan 
> >> >> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> I've been looking at BLACKHOLE closures and how the indirectee field
> >> >>> is
> >> >>> used
> >> >>> and I have a few questions:
> >> >>>
> >> >>> Looking at evacuate for BLACKHOLE closures:
> >> >>>
> >> >>> case BLACKHOLE:
> >> >>> {
> >> >>> StgClosure *r;
> >> >>> const StgInfoTable *i;
> >> >>> r = ((StgInd*)q)->indirectee;
> >> >>> if (GET_CLOSURE_TAG(r) == 0) {
> >> >>> i = r->header.info;
> >> >>> if (IS_FORWARDING_PTR(i)) {
> >> >>> r = (StgClosure *)UN_FORWARDING_PTR(i);
> >> >>> i = r->header.info;
> >> >>> }
> >> >>> if (i == _TSO_info
> >> >>> || i == _WHITEHOLE_info
> >> >>> || i == _BLOCKING_QUEUE_CLEAN_info
> >> >>> || i == _BLOCKING_QUEUE_DIRTY_info) {
> >> >>> copy(p,info,q,sizeofW(StgInd),gen_no);
> >> >>> return;
> >> >>> }
> >> >>> ASSERT(i != _IND_info);
> >> >>> }
> >> >>> q = r;
> >> >>> *p = r;
> >> >>> goto loop;
> >> >>> }
> >> >>>
> >> >>> It seems like indirectee can be a TSO, WHITEHOLE,
> >> >>> BLOCKING_QUEUE_CLEAN,
> >> >>> BLOCKING_QUEUE_DIRTY, and it can't be IND. I'm wondering what does
> it
> >> >>> mean for
> >> >>> a BLACKHOLE to point to a
> >> >>>
> >> >>> - TSO
> >> >>> - WHITEHOLE
> >> >>> - BLOCKING_QUEUE_CLEAN
> >> >>> - BLOCKING_QUEUE_DIRTY
> >> >>
> >> >>
> >> >> That sounds right to me.
> >> >>
> >> >>>
> >> >>> Is this documented somewhere or otherwise could someone give a few
> >> >>> pointers on
> >> >>> where to look in the code?
> >> >>
> >> >>
> >> >> Unfortunately I don't think we have good documentation for this, but
> >> >> you
> >> >> should look at the comments around messageBlackHole in Messages.c.
> >> >>
> >> >>>
> >> >>> Secondly, I also looked at the BLACKHOLE entry code, and it seems
> like
> >> >>>