Re: msys2 64 bit: help help!

[Phyx]

Hi Simon, Andrey


> > 3. After this step, starting a shell failed altogether with
> "c:/msys64/mingw64_shell.bat is
> > not recognised as an internal or external command". And sure enough,
> there is no such file.
> > Presumably it existed in step 1.  So perhaps step 2 deleted it?
> > [...]
> > 4. As you mention, I then tried msys2_shell.cmd.  It worked -- with a
> noticeable delay of 5
> > seconds or so.
>
> I've also just got a new Win10 laptop and had the same issue with missing
> mingw64_shell.bat during msys2 install. I solved it by creating mingw64.bat
> with the following contents:
>
> msys2_shell.cmd -mingw64 -mintty
>
> I deleted all old shortcuts and use this script instead. Everything seems
> to work fine -- can build GHC.
>
>
Yes this is correct, the msys2 team has decided to "streamline" all their
different batch files to launch msys from 4 to 1, hence the only remaining
one is msys2_shell.cmd which accepts arguments of which shell to open and
using which console host.

Unfortunately this is done via their upgrade-core script and doesn't know
how to remove the installer shortcuts, so you end up with dead shortcuts.

> 1.  I just left the machine for 10-15 mins and lo! the shell windows
opened up. It just took a lng time.
>
> At this point, starting a new shell no longer took a long time.  It all
seemed to be working.

First launch should be finishing setting up the environment so will take
slightly longer, but shouldn't have taken that long. Could this be AV
related?
I always add an exception to the AV (or the build in windows defender) for
the msys2 folder to prevent it from scanning files continuously. Especially
building GHC this can slow things down considerably depending on the AV.


> 2.  I then ran pacman -Syuu as instructed on the installation page:
https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
>
> The log of what happened is below.  There are numerous failures involving
Cygwin, which I do not have installed, at least not so far as I know.   I
do not know if these failures matter.

These instructions are basically telling it to upgrade the world. They are
however a bit wrong, https://github.com/Alexpux/MSYS2-packages/issues/373

msys2 is derived from Cygwin so it inherits much of the problems of Cygwin.
The msys2 runtime is the Cygwin runtime with patches added which is why the
errors mention Cygwin.

The issue is that the msys2-runtime has been upgraded by "pacman -Syuu" at
which point a new "Cygwin" dll has been downloaded. However all
Cygwin/msys2 runtimes share the same
address space and thus you can't have multiple versions of the same runtime
loaded at once. This is why subsequent calls to anything relying on the
msys2 runtime will fail with a weird
fork error. The solution is to just close all open msys2 window and re-open.

Our own instructions page
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows breaks
this down in a few steps to avoid this issue. 1) first update the packages
and 2) only after that update the msys-core files.
But you will still need to restart the shell.

> * should I worry about all those install errs


No they're perfectly fine and expected. I would however re-run the pacman
-Syu to make sure all packages were updated, now that the runtime has been
updated already it shouldn't be updated again

and you shouldn't see any fork errors.


> * how can I debug what's happening with

>  that long delay


If it's only startup and not executing of other commands or bash completion
then my bet would be AV software. If bash completion is slow or commands
like ls as well

you may be hitting a long standing issue some computers have in which the
domain controller is being hit for every invocation of commands, causing a
slowdown https://github.com/Alexpux/MSYS2-packages/issues/138 , Solution 2
from https://gist.github.com/k-takata/9b8d143f0f3fef5abdab seems to fix it
for most people.


* Should I nuke the start menu shortcuts that

  the msys64 installer so carefully installed

  in favour of msys2_shell.cmd?


Yes, these are now dead. you need to use msys2_shell.cmd but also pass
it -mingw64
so it knows what shell to start. mintty is supposed to be the default, but
in case that changes you can also pass it -mintty as well to be sure it
doesn't change.



I am working on a script to automate this setup, hopefully that would make
it easier next time!


Cheers,

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

RE: msys2 64 bit: help help!

[Andrey Mokhov]

Hi Simon,

> 3. After this step, starting a shell failed altogether with 
> "c:/msys64/mingw64_shell.bat is
> not recognised as an internal or external command". And sure enough, there is 
> no such file.
> Presumably it existed in step 1.  So perhaps step 2 deleted it?
> [...]
> 4. As you mention, I then tried msys2_shell.cmd.  It worked -- with a 
> noticeable delay of 5
> seconds or so.

I've also just got a new Win10 laptop and had the same issue with missing 
mingw64_shell.bat during msys2 install. I solved it by creating mingw64.bat 
with the following contents:

msys2_shell.cmd -mingw64 -mintty

I deleted all old shortcuts and use this script instead. Everything seems to 
work fine -- can build GHC.

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

RE: msys2 64 bit: help help!

[Simon Peyton Jones via ghc-devs]

Tamar

Thank you!  Yes, it's in c:/msys64

Since I wrote more odd things have happened.

1.  I just left the machine for 10-15 mins and lo! the shell windows opened up. 
It just took a lng time.

At this point, starting a new shell no longer took a long time.  It all seemed 
to be working.

2.  I then ran pacman -Syuu as instructed on the installation page: 
https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/

The log of what happened is below.  There are numerous failures involving 
Cygwin, which I do not have installed, at least not so far as I know.   I do 
not know if these failures matter.

3. After this step, starting a shell failed altogether with 
"c:/msys64/mingw64_shell.bat is not recognised as an internal or external 
command". And sure enough, there is no such file. Presumably it existed in step 
1.  So perhaps step 2 deleted it?

4. As you mention, I then tried msys2_shell.cmd.  It worked -- with a 
noticeable delay of 5 seconds or so.

So I'm less stuck than before but

* should I worry about all those install errs
* how can I debug what's happening with 
  that long delay
* Should I nuke the start menu shortcuts that
  the msys64 installer so carefully installed
  in favour of msys2_shell.cmd?

Thanks

Simon





pacman -Syuu
:: Synchronising package databases...
 mingw32  277.4 KiB   501K/s 00:01 [#] 100%
 mingw32.sig   96.0   B  0.00B/s 00:00 [#] 100%
 mingw64  277.0 KiB   481K/s 00:01 [#] 100%
 mingw64.sig   96.0   B  0.00B/s 00:00 [#] 100%
 msys 134.9 KiB  2014K/s 00:00 [#] 100%
 msys.sig  96.0   B  0.00B/s 00:00 [#] 100%
:: Starting full system upgrade...
:: Replace repman-git with msys/pactoys-git? [Y/n] y
resolving dependencies...
looking for conflicting packages...

Packages (41) bash-completion-2.3-1  bsdcpio-3.2.0-1  bsdtar-3.2.0-1
  coreutils-8.25-1  crypt-1.3-1  curl-7.49.1-1  file-5.25-1
  filesystem-2016.05-3  gcc-libs-5.3.0-3  gettext-0.19.7-3
  gmp-6.1.0-2  gnupg-1.4.20-1  grep-2.22-3  gzip-1.7-1
  heimdal-libs-1.5.3-9  libarchive-3.2.0-1  libasprintf-0.19.7-3
  libassuan-2.4.2-1  libcrypt-1.3-1  libcurl-7.49.1-1
  libexpat-2.1.1-1  libgettextpo-0.19.7-3  libgpg-error-1.21-1
  libgpgme-1.6.0-1  libintl-0.19.7-3  liblzma-5.2.2-1
  libnettle-3.2-1  libopenssl-1.0.2.h-1  libssh2-1.7.0-1
  mintty-1~2.2.3-1  mpfr-3.1.4-1
  msys2-launcher-git-0.3.29.4028b6c-1  msys2-runtime-2.5.1-1
  ncurses-6.0.20160220-1  openssl-1.0.2.h-1
  pacman-5.0.1.6403.520736d-1  pactoys-git-r1.e58a7ac-1
  rebase-4.4.2-1  repman-git-r23.87bf865-1 [removal]  wget-1.17.1-3
  xz-5.2.2-1

Total Download Size:24.85 MiB
Total Installed Size:  124.28 MiB
Net Upgrade Size:6.09 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages ...
 msys2-runtime-2.5.1... 2.2 MiB   912K/s 00:03 [#] 100%
 bash-completion-2.3...   184.1 KiB  4.50M/s 00:00 [#] 100%
 gcc-libs-5.3.0-3-x86_64  783.6 KiB  1818K/s 00:00 [#] 100%
 libintl-0.19.7-3-x86_64   25.6 KiB  3.13M/s 00:00 [#] 100%
 libgettextpo-0.19.7...   110.7 KiB  3.60M/s 00:00 [#] 100%
 libasprintf-0.19.7-...11.8 KiB  1686K/s 00:00 [#] 100%
 gettext-0.19.7-3-x86_64 1524.1 KiB  1774K/s 00:01 [#] 100%
 liblzma-5.2.2-1-x86_6476.6 KiB  6.23M/s 00:00 [#] 100%
 gmp-6.1.0-2-x86_64   369.2 KiB  2.03M/s 00:00 [#] 100%
 libnettle-3.2-1-x86_64   101.1 KiB  5.20M/s 00:00 [#] 100%
 coreutils-8.25-1-x86_642.2 MiB  1794K/s 00:01 [#] 100%
 ncurses-6.0.2016022...  1147.2 KiB  1833K/s 00:01 [#] 100%
 bsdcpio-3.2.0-1-x86_64   747.1 KiB  2.08M/s 00:00 [#] 100%
 bsdtar-3.2.0-1-x86_64785.4 KiB  1879K/s 00:00 [#] 100%
 libcrypt-1.3-1-x86_64 13.5 KiB  1692K/s 00:00 [#] 100%
 crypt-1.3-1-x86_6413.9 KiB  1979K/s 00:00 [#] 100%
 libopenssl-1.0.2.h-...   803.0 KiB  1921K/s 00:00 [#] 100%
 heimdal-libs-1.5.3-...   592.7 KiB  1976K/s 00:00 [#] 100%
 openssl-1.0.2.h-1-x...  1354.4 KiB  1929K/s 00:01 [#] 100%
 gzip-1.7-1-x86_64 97.0 KiB  3.16M/s 00:00 [#] 100%
 libssh2-1.7.0-1-x86_64   170.7 KiB  2.69M/s 00:00 [#] 100%
 libexpat-2.1.1-1-x86_64   56.9 KiB  3.27M/s 00:00 [#] 100%
 libcurl-7.49.1-1-x86_64  191.1 KiB  1855K/s 00:00 [#] 100%
 curl-7.49.1-1-x86_64 608.4 KiB   627K/s 00:01 

Re: Using the GHC API to write an interpreter

[Simon Marlow]

On 27 June 2016 at 13:31, Christopher Done  wrote:

> On 27 June 2016 at 10:01, Simon Marlow  wrote:
> > On 26 June 2016 at 11:28, Christopher Done  wrote:
> >>
> >> I've been pondering how feasible it would be to:
> >>
> >> * Compile in stages a module with the byte code linker
> >> * Keep hold of the Core source
> >> * Interpret the Core AST within Haskell
> >
> > Interestingly, the first implementation of GHCi was a Core interpreter,
> but
> > it ran into a lot of problems.  For starters it would have unsafeCoerce
> > everywhere.  Support for unboxed values is very very difficult.
>
> What year is that implementation from? I wouldn't mind taking a look
> for it in the GHC repo history.
>
>
I think around here is a good place to start looking:
https://phabricator.haskell.org/rGHCbca9dd54c2b39638cb4638aaccf6015a104a1df5#021fe2a9

Cheers
Simon


> >> * is not tagless, so we preserve type info
> >
> > Not sure what you mean here.  Your interpreter would be running on top of
> > the same RTS with the same data representation, so it would have to use
> the
> > same tagging and representation conventions as the rest of GHC
>
> That's true, if a value comes from a compiled RTS function with a
> polymorphic type then I don't know what its real type is to marshal it
> properly. Drat.
>
> >> * allows top-level names to be redefined
> >
> > This you could do with the extisting byte-code interpreter, by instead of
> > linking Names directly you link to some runtime Name-lookup function.
> You
> > would probably want to revert all CAFs when the code changes too; this is
> > currently not implemented for byte code.
>
> Right, I considered this but without the type information it's going
> to blow up if I change the arity of a function or a data type or
> whatever.
>
> >> * when a function is applied, it checks the type of its arguments
> >
> > Aha, but what if the arguments come from compiled code?  GHC doesn't
> carry
> > type information around at runtime, except that it is possible
> reconstruct
> > types in a limited kind of way (this is what the GHC debugger does).
>
> Indeed, from compiled code e.g. id then id (undefined :: Foo) would
> come back as something unidentifiable as being of type Foo. That's the
> flaw in my plan.
>
> Looks like the current interpreter would have to be extended to
> support this or a whole new one re-implementing all the primitives like
> in GHCJS.
>
> Thanks!
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Using the GHC API to write an interpreter

[Christopher Done]

On 27 June 2016 at 10:01, Simon Marlow  wrote:
> On 26 June 2016 at 11:28, Christopher Done  wrote:
>>
>> I've been pondering how feasible it would be to:
>>
>> * Compile in stages a module with the byte code linker
>> * Keep hold of the Core source
>> * Interpret the Core AST within Haskell
>
> Interestingly, the first implementation of GHCi was a Core interpreter, but
> it ran into a lot of problems.  For starters it would have unsafeCoerce
> everywhere.  Support for unboxed values is very very difficult.

What year is that implementation from? I wouldn't mind taking a look
for it in the GHC repo history.

>> * is not tagless, so we preserve type info
>
> Not sure what you mean here.  Your interpreter would be running on top of
> the same RTS with the same data representation, so it would have to use the
> same tagging and representation conventions as the rest of GHC

That's true, if a value comes from a compiled RTS function with a
polymorphic type then I don't know what its real type is to marshal it
properly. Drat.

>> * allows top-level names to be redefined
>
> This you could do with the extisting byte-code interpreter, by instead of
> linking Names directly you link to some runtime Name-lookup function.  You
> would probably want to revert all CAFs when the code changes too; this is
> currently not implemented for byte code.

Right, I considered this but without the type information it's going
to blow up if I change the arity of a function or a data type or
whatever.

>> * when a function is applied, it checks the type of its arguments
>
> Aha, but what if the arguments come from compiled code?  GHC doesn't carry
> type information around at runtime, except that it is possible reconstruct
> types in a limited kind of way (this is what the GHC debugger does).

Indeed, from compiled code e.g. id then id (undefined :: Foo) would
come back as something unidentifiable as being of type Foo. That's the
flaw in my plan.

Looks like the current interpreter would have to be extended to
support this or a whole new one re-implementing all the primitives like
in GHCJS.

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

Re: Using the GHC API to write an interpreter

[Christopher Done]

On 27 June 2016 at 04:11, Edward Z. Yang  wrote:
> I don't understand what the bytecode format has to do here. Since
> your suggestion is to just store Core you can just compile to object
> code.

True, I could compile to either as long as I can link it dynamically.

> > Any input into this? How far away is GHC's current architecture from
> > supporting such a concept?
>
> Well, if you are going to support update you need to make sure that the
> tag information is more elaborate than what GHC currently supports
> (a type would just be a Name, which is going to get reused when you
> recompile.)

Indeed -- like in GHCi when you redefine a named thing, I'd hope to
implement an incrementing Name[n] versioning for names. But Core's AST
is trivial so it'd be easy to make this kind of transformation.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: msys2 64 bit: help help!

[Luke Iannini]

Congrats Simon : )

I use precisely the same machine!

While I haven't run into that particular problem, I do use an alternative
console that might provide a workaround in case you keep running into
trouble:
http://cmder.net/

My setup log is here, which explains how to use Cmder with MSYS2:
https://gist.github.com/lukexi/e634067f1d7e3a629988#cmder

All the best
Luke


On Mon, Jun 27, 2016 at 1:21 AM, David Macek 
wrote:

> On 27. 6. 2016 10:01, Simon Peyton Jones via ghc-devs wrote:
> > Friends, esp Tamar,
> >
> > I am in happy possession of a new Surface Book, running Windows 10,
> which is delightful – except that I can’t make the msys64 installation
> work, which is crucial for GHC.  Can any of you help?
> >
> > ·I install it from here:
> https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/, which seems
> to be the canonical place.  The actual 64-bit exe seems to be
> msys2-x86_64-20160205.exe.
> >
> > ·Installation goes fine
> >
> > ·But when I launch the “MinGW-w54 Win64 shell” from the Start
> menu, the screen flashes as if it is briefly putting up a window, but then
> the window disappears.
> >
> > ·Each time I do this the task manager shows that there is
> another running ‘mintty.exe’.   But it has no visible window
> >
> >
> >
> > Does anyone have any idea what I can do or how I can investigate?  I
> can’t do any GHC development without this!
>
> Hi.
>
> Please try `C:\msys64\usr\bin\mintty.exe -h always -` (incl. the trailing
> dash). You can also try `C:\msys64\usr\bin\bash.exe -li` in case the
> culprit is really mintty.
>
>
> --
> David Macek
>
>
> ___
> 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: msys2 64 bit: help help!

[David Macek]

On 27. 6. 2016 10:01, Simon Peyton Jones via ghc-devs wrote:
> Friends, esp Tamar,
> 
> I am in happy possession of a new Surface Book, running Windows 10, which is 
> delightful – except that I can’t make the msys64 installation work, which is 
> crucial for GHC.  Can any of you help?
> 
> ·I install it from here: 
> https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/, which seems to be 
> the canonical place.  The actual 64-bit exe seems to be 
> msys2-x86_64-20160205.exe.
> 
> ·Installation goes fine
> 
> ·But when I launch the “MinGW-w54 Win64 shell” from the Start menu, 
> the screen flashes as if it is briefly putting up a window, but then the 
> window disappears.
> 
> ·Each time I do this the task manager shows that there is another 
> running ‘mintty.exe’.   But it has no visible window
> 
>  
> 
> Does anyone have any idea what I can do or how I can investigate?  I can’t do 
> any GHC development without this!

Hi.

Please try `C:\msys64\usr\bin\mintty.exe -h always -` (incl. the trailing 
dash). You can also try `C:\msys64\usr\bin\bash.exe -li` in case the culprit is 
really mintty.


-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Using the GHC API to write an interpreter

[Simon Marlow]

On 26 June 2016 at 11:28, Christopher Done  wrote:

> I've been pondering how feasible it would be to:
>
> * Compile in stages a module with the byte code linker
> * Keep hold of the Core source
> * Interpret the Core AST within Haskell
>

Interestingly, the first implementation of GHCi was a Core interpreter, but
it ran into a lot of problems.  For starters it would have unsafeCoerce
everywhere.  Support for unboxed values is very very difficult.

> * When encountering built-in/primitives (or things from other libraries),
> we compile that Core term and link it as an HValue and then run it with the
> arguments expected. So () would be such a HValue, as would be "show" which
> in interpretable unoptimized Core would take an extra argument for the Show
> instance. When passing in values to such "foreign" functions it would wrap
> them up in an interpretive way.
>
> This is the hypothetical idea, it seems like it would yield a really
> trivial way to write a new and interesting interpreter for GHC Haskell
> without having to re-implement any prim ops, ready to work on regular
> Haskell code.
>
> In my case, I would use this to write an interpreter which:
>
> * is not tagless, so we preserve type info
>
Not sure what you mean here.  Your interpreter would be running on top of
the same RTS with the same data representation, so it would have to use the
same tagging and representation conventions as the rest of GHC

> * allows top-level names to be redefined
>
This you could do with the extisting byte-code interpreter, by instead of
linking Names directly you link to some runtime Name-lookup function.  You
would probably want to revert all CAFs when the code changes too; this is
currently not implemented for byte code.

> * when a function is applied, it checks the type of its arguments
>
Aha, but what if the arguments come from compiled code?  GHC doesn't carry
type information around at runtime, except that it is possible reconstruct
types in a limited kind of way (this is what the GHC debugger does).

Cheers
Simon

> Both of these are pretty much necessary for being able to do in-place
> update of a running program while developing (a la Emacs or Smalltalk), and
> type tags let us throw a regular Haskell exception of type error, a la
> deferred type errors. It means in your running program, if you make a
> mistake or forget to update one part, it doesn't bring the whole program
> down with an RTS error or a segfault, maybe a handler in a thread (like a
> server or a video game) throws an exception and the developer just updates
> their code and tries again.
>
> I'd love support for something like this, but I'd rather not have to
> re-create the world just to add this capability. Because it's really just
> conceptually regular interpreted GHC Haskell plus type tags and updating,
> it seems like it should be a small diff.
>
> Any input into this? How far away is GHC's current architecture from
> supporting such a concept?
>
> Ciao!
>
> ___
> 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

msys2 64 bit: help help!

[Simon Peyton Jones via ghc-devs]

Friends, esp Tamar,

I am in happy possession of a new Surface Book, running Windows 10, which is 
delightful - except that I can't make the msys64 installation work, which is 
crucial for GHC.  Can any of you help?


*I install it from here: 
https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/, which seems to be 
the canonical place.  The actual 64-bit exe seems to be 
msys2-x86_64-20160205.exe.

*Installation goes fine

*But when I launch the "MinGW-w54 Win64 shell" from the Start menu, the 
screen flashes as if it is briefly putting up a window, but then the window 
disappears.

*Each time I do this the task manager shows that there is another 
running 'mintty.exe'.   But it has no visible window

Does anyone have any idea what I can do or how I can investigate?  I can't do 
any GHC development without this!

Thanks

Simon

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

Re: [Diffusion] [Build Failed] rGHCbb84ee44e30e: Improve pretty-printing of Avail

[Simon Marlow]

I believe I've just fixed this.  I think it was non-deterministic in some
way that I don't fully understand, but hopefully I've made it deterministic
now.

https://phabricator.haskell.org/rGHC7843c71c7e48cdba115bef422184e855ede23a67

On 24 June 2016 at 15:12, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> These failures are odd.  One is this change in T8761 which I'm sure is not
> my fault.  I saw that simonmar did some hFlush thing -- could that be it?
>
> Simon
>
>
> +++ ./T8761.run/T8761.comp.stderr.normalised2016-06-24
> 15:00:22.975083533 +0100
> @@ -1,3 +1,7 @@
> +pattern Q1 x1_0 x2_1 x3_2 <- ((x1_0, x2_1), [x3_2], _, _)
> +pattern x1_0 Q2 x2_1 = ((x1_0, x2_1))
> +pattern Q3 {qx3, qy3, qz3} <- ((qx3, qy3), [qz3]) where
> +  Q3 qx3 qy3 qz3 = ((qx3, qy3), [qz3])
>  T8761.hs:(16,1)-(39,13): Splicing declarations
>  do { [qx1, qy1, qz1] <- mapM
>(/ i -> newName $ "x" ++ show i) [1, 2, 3];
> @@ -119,10 +123,6 @@
>  pattern Pup x <- MkUnivProv x
>  pattern Puep :: forall a. forall b. Show b => a -> b -> (ExProv, a)
>  pattern Puep x y <- (MkExProv y, x)
> -pattern Q1 x1_0 x2_1 x3_2 <- ((x1_0, x2_1), [x3_2], _, _)
> -pattern x1_0 Q2 x2_1 = ((x1_0, x2_1))
> -pattern Q3 {qx3, qy3, qz3} <- ((qx3, qy3), [qz3]) where
> -  Q3 qx3 qy3 qz3 = ((qx3, qy3), [qz3])
>  pattern T8761.P :: GHC.Types.Bool
>  pattern T8761.Pe :: () => forall (a0_0 :: *) . a0_0 -> T8761.Ex
>  pattern T8761.Pu :: forall (a0_0 :: *) . a0_0 -> a0_0
>
> |  -Original Message-
> |  From: nore...@phabricator.haskell.org
> |  [mailto:nore...@phabricator.haskell.org]
> |  Sent: 24 June 2016 14:50
> |  To: Simon Peyton Jones 
> |  Subject: [Diffusion] [Build Failed] rGHCbb84ee44e30e: Improve pretty-
> |  printing of Avail
> |
> |  Harbormaster failed to build B10226: rGHCbb84ee44e30e: Improve pretty-
> |  printing of Avail!
> |
> |  BRANCHES
> |master, wip/rae
> |
> |  USERS
> |simonpj (Author)
> |
> |  COMMIT
> |https://phabricator.haskell.org/rGHCbb84ee44e30e
> |
> |  EMAIL PREFERENCES
> |https://phabricator.haskell.org/settings/panel/emailpreferences/
> |
> |  To: simonpj, Harbormaster
> ___
> 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: [commit: ghc] master: Accept new (lower) allocations for T7257 (15641b0)

[Simon Marlow]

Yes, it was the sizeExpr fix.  It validated locally and on Travis, but I'm
guessing it was right on the boundary.

On 22 June 2016 at 22:37, Bartosz Nitka  wrote:

> Appears to be:
> a47b62cb3685 Second attempt to fix sizeExpr
>
> https://perf.haskell.org/ghc/#revision/9d62d09a6c399c98491b7a63a7a1366c89fcf5db
>
> 2016-06-22 22:24 GMT+01:00 Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org>:
>
>> Does anyone know what made T7257 better?
>>
>> Simon
>>
>> | -Original Message-
>> | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of
>> | g...@git.haskell.org
>> | Sent: 22 June 2016 22:08
>> | To: ghc-comm...@haskell.org
>> | Subject: [commit: ghc] master: Accept new (lower) allocations for T7257
>> | (15641b0)
>> |
>> | Repository : ssh://g...@git.haskell.org/ghc
>> |
>> | On branch  : master
>> | Link   :
>> |
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.hask
>> | ell.org
>> %2ftrac%2fghc%2fchangeset%2f15641b07f1d3ccb5f35b4f31539ecceb5fb38
>> | c17%2fghc=01%7c01%7csimonpj%40064d.mgd.microsoft.com
>> %7c32fafc88b758
>> | 43148b2a08d39ae1ea3f%7c72f988bf86f141af91ab2d7cd011db47%7c1=eLrMob
>> | XyWHA691jI3t4pf0CbGybfrVqptmkpTDdtDI8%3d
>> |
>> | >---
>> |
>> | commit 15641b07f1d3ccb5f35b4f31539ecceb5fb38c17
>> | Author: Simon Marlow 
>> | Date:   Wed Jun 22 20:54:59 2016 +0100
>> |
>> | Accept new (lower) allocations for T7257
>> |
>> |
>> | >---
>> |
>> | 15641b07f1d3ccb5f35b4f31539ecceb5fb38c17
>> |  testsuite/tests/perf/should_run/all.T | 3 ++-
>> |  1 file changed, 2 insertions(+), 1 deletion(-)
>> |
>> | diff --git a/testsuite/tests/perf/should_run/all.T
>> | b/testsuite/tests/perf/should_run/all.T
>> | index caf4eff..3cb6f8e 100644
>> | --- a/testsuite/tests/perf/should_run/all.T
>> | +++ b/testsuite/tests/perf/should_run/all.T
>> | @@ -276,9 +276,10 @@ test('T7257',
>> |[(wordsize(32), 989850664, 10),
>> |  # expected value: 1246287228 (i386/Linux)
>> |  # 2016-04-06: 989850664 (i386/Linux) no idea
>> | what happened
>> | -   (wordsize(64), 1654893248, 5)]),
>> | +   (wordsize(64), 1414893248, 5)]),
>> |  # 2012-09-21: 1774893760 (amd64/Linux)
>> |  # 2015-11-03: 1654893248 (amd64/Linux)
>> | +# 2016-06-22: 1414893248 (amd64/Linux, sizeExpr
>> | fix)
>> |stats_num_field('peak_megabytes_allocated',
>> |[(wordsize(32), 217, 5),
>> |  # 2012-10-08: 217 (x86/Linux)
>> |
>> | ___
>> | ghc-commits mailing list
>> | ghc-comm...@haskell.org
>> |
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.has
>> | kell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>> | commits=01%7c01%7csimonpj%40064d.mgd.microsoft.com
>> %7c32fafc88b75843
>> | 148b2a08d39ae1ea3f%7c72f988bf86f141af91ab2d7cd011db47%7c1=RftvNpBH
>> | H7bw53EdhgnsdV%2f6M2LNgFVB1t7gCwOTT7A%3d
>> ___
>> 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