RE: msys2 64 bit: help help!

[lonetiger]

Hi Simon,

I think the two issues might be related. From what I can tell magit invokes 
some msys utilies at startup such as cygdrive to normalize paths 
https://github.com/magit/magit/issues/2284 . The msys AD issue would affect all 
of these tools and so each of them would be quite slow to run.

I would indeed try the AD fix first and see how the rest behave.

This issue is well documented at the Cygwin FAQ as well 
https://cygwin.com/faq/faq.html#faq.using.startup-slow if you’re interested in 
what’s 
Going on. Basically what it’s saying is that you can cache your user 
information (username etc) locally instead of having it query the server 
everytime.

If this doesn’t solve the magit problem as well, then try issuing a normal git 
command, if that’s slow as well then run strace on it and it should give
You an idea of what’s taking so long.

Kind Regards,
Tamar

From: Simon Peyton Jones via 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!

[Simon Michael]

On 6/28/16 5:50 AM, Simon Peyton Jones via ghc-devs wrote:

I have another issue.  I'm using 'magit' (in emacs) to drive git.  But it gives 
half-minute delays to do anything at all.  There are lots of people complaining 
about it (googlable) but no solutions I can see.  Do I have to give up magit?

It used to be fine in earlier versions.

Just at the moment it's Much Much More Serious.  Even opening a file in emacs 
(nothing to do with git or (ostensibly) magit, takes nearly a minute!!  In the 
process manager I can see lots of git activity -- just when I open a file in 
ordinary emacs!


Hi Simon,

I've never seen that behaviour, but if it's not active directory/network 
related, might you have enabled some add-on that eg tries to show a 
file's VCS status in the modeline ?


Here are some things you may have already tried:

- restart emacs

- restart emacs with --no-init-file, then gradually evaluate your 
.emacs.d/init.el (and more specifically, any  magit/vcs-related 
customizations) while testing magit performance.


- close unnecessary open buffers visiting files in the current git repo. 
This might be contributing, in my setup it makes a big difference.
I do C-x C-b s m to sort open buffers by mode, n/p to move to the 
haskell buffers, d to mark them deleted, x to do it.


- look for and turn off costly magit settings, in M-x customize-group 
magit. I'm sorry that I don't know/remember which ones are costly. I 
would be suspicious of the two auto revert options and the Magit 
Extensions -> Magit Auto Revert group, and magit's hooks (Magit Modes -> 
*Hook).


___
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]

Have you tried specifying an absolute path for the git executable that magit 
uses, to avoid the overhead of traversing the environment for each call? (M-x 
customize-var RET magit-git-executable RET)
I’m pretty sure it’s not that, because in the task manager I see stuck 
‘git.exe’ consuming zero cycles with a child process of ‘comhost’ (I think).   
Then it completes and another one is born.   But I’ll give it a try anyway, 
thanks

I’m still utterly baffled about why emacs is invoking git when I simply open a 
file (Ctrl-X f).

Simon

From: Luite Stegeman [mailto:stege...@gmail.com]
Sent: 28 June 2016 14:09
To: Simon Peyton Jones <simo...@microsoft.com>; David Macek 
<david.mace...@gmail.com>; ta...@zhox.com; John Wiegley <jo...@newartisans.com>
Cc: ghc-devs@haskell.org
Subject: Re: msys2 64 bit: help help!

Have you tried specifying an absolute path for the git executable that magit 
uses, to avoid the overhead of traversing the environment for each call? (M-x 
customize-var RET magit-git-executable RET)
On Tue, Jun 28, 2016 at 2:51 PM Simon Peyton Jones via ghc-devs 
<ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote:
David, Tamar

I have another issue.  I'm using 'magit' (in emacs) to drive git.  But it gives 
half-minute delays to do anything at all.  There are lots of people complaining 
about it (googlable) but no solutions I can see.  Do I have to give up magit?

It used to be fine in earlier versions.

Just at the moment it's Much Much More Serious.  Even opening a file in emacs 
(nothing to do with git or (ostensibly) magit, takes nearly a minute!!  In the 
process manager I can see lots of git activity -- just when I open a file in 
ordinary emacs!

I have utterly no idea why this might be.  I'm adding John Wiegley, my Emacs 
Friend

Thanks

Simon

|  -Original Message-
|  From: David Macek 
[mailto:david.mace...@gmail.com<mailto:david.mace...@gmail.com>]
|  Sent: 28 June 2016 13:20
|  To: Simon Peyton Jones 
<simo...@microsoft.com<mailto:simo...@microsoft.com>>; 
ta...@zhox.com<mailto:ta...@zhox.com>
|  Cc: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
|  Subject: Re: msys2 64 bit: help help!
|
|  On 27. 6. 2016 23:33, Simon Peyton Jones via ghc-devs wrote:
|  > 1.  I just left the machine for 10-15 mins and lo! the shell windows
|  opened up. It just took a lng time.
|
|  I could be something with Active Directory. Cygwin (upon which is
|  MSYS2 based) integrates with AD, but there are numerous (google-able)
|  reports of huge slowdowns related to this.
|
|  > At this point, starting a new shell no longer took a long time.  It
|  all seemed to be working.
|
|  Also don't forget to exclude `C:\msys64` from any anti-virus scans.
|
|
|  > 2.  I then ran pacman -Syuu as instructed on the installation page:
|  
https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fsourceforge.net%2fp%2fmsys2%2fwiki%2fMSYS2%2520installation%2f=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c031c5d465f0b4cc6a15308d39f55747e%7c72f988bf86f141af91ab2d7cd011db47%7c1=goH1Vv4K8YPMneu383XT0gMLIxFlDQLbYAxvAElHb9U%3d>
|
|  I'm afraid you misread the instructions. You should run `update-core`
|  first to upgrade to the newer pacman that handles `pacman -Syuu`
|  correctly. (New installer packages with an up-to-date pacman are
|  planned.)
|
|  > 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.
|
|  They might. See below.
|
|  > 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?
|
|  If the post-install script for `filesystem` were able to run, it would
|  inform you that `*_shell.bat` are deprecated and were removed. I see
|  you have `msys2-launcher-git` installed -- you can then use
|  `C:\msys64\mingw64.exe` (and even pin it to the taskbar).
|
|  > 4. As you mention, I then tried msys2_shell.cmd.  It worked -- with
|  a noticeable delay of 5 seconds or so.
|
|  May still be AD-related.
|
|  > * should I worry about all those install errs
|
|  I recommend staying on the safe side and nuke the installation.
|  Alternatively, reinstall the packages that had failures (`pacman -S
|  gcc-libs gettext gmp ...`).
|
|  > * how can I debug what's happening with
|  >   that long delay
|
|  `/etc/nsswitch.conf` allows for some configuration. See
|  
<https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcygwin.com%2fcygwin-ug-net%2fntsec.html%23ntsec-mapping-nsswitch-=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c031c5d

Re: msys2 64 bit: help help!

[David Macek]

> I have another issue.  I'm using 'magit' (in emacs) to drive git.  But it 
> gives half-minute delays to do anything at all.  There are lots of people 
> complaining about it (googlable) but no solutions I can see.  Do I have to 
> give up magit?

I've read about it too, but I don't remember seeing any solutions.

I don't use magit nor emacs, but I have two ideas:

a) Try `mingw-w64-x86_64-emacs` (through pacman) with `mingw-w64-x86_64-git` 
(download[2] or through pacman[1]). This should work around any performance 
issues coming from the POSIX emulation layer. The downside is that I have no 
idea whether this combination works well currently (or at all).

b) `git config core.fscache true`. I'm not sure if this option is supported 
under Cygwin.


[1] 
[2] 

-- 
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: msys2 64 bit: help help!

[Luite Stegeman]

Have you tried specifying an absolute path for the git executable that
magit uses, to avoid the overhead of traversing the environment for each
call? (M-x customize-var RET magit-git-executable RET)

On Tue, Jun 28, 2016 at 2:51 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> David, Tamar
>
> I have another issue.  I'm using 'magit' (in emacs) to drive git.  But it
> gives half-minute delays to do anything at all.  There are lots of people
> complaining about it (googlable) but no solutions I can see.  Do I have to
> give up magit?
>
> It used to be fine in earlier versions.
>
> Just at the moment it's Much Much More Serious.  Even opening a file in
> emacs (nothing to do with git or (ostensibly) magit, takes nearly a
> minute!!  In the process manager I can see lots of git activity -- just
> when I open a file in ordinary emacs!
>
> I have utterly no idea why this might be.  I'm adding John Wiegley, my
> Emacs Friend
>
> Thanks
>
> Simon
>
> |  -Original Message-
> |  From: David Macek [mailto:david.mace...@gmail.com]
> |  Sent: 28 June 2016 13:20
> |  To: Simon Peyton Jones <simo...@microsoft.com>; ta...@zhox.com
> |  Cc: ghc-devs@haskell.org
> |  Subject: Re: msys2 64 bit: help help!
> |
> |  On 27. 6. 2016 23:33, Simon Peyton Jones via ghc-devs wrote:
> |  > 1.  I just left the machine for 10-15 mins and lo! the shell windows
> |  opened up. It just took a lng time.
> |
> |  I could be something with Active Directory. Cygwin (upon which is
> |  MSYS2 based) integrates with AD, but there are numerous (google-able)
> |  reports of huge slowdowns related to this.
> |
> |  > At this point, starting a new shell no longer took a long time.  It
> |  all seemed to be working.
> |
> |  Also don't forget to exclude `C:\msys64` from any anti-virus scans.
> |
> |
> |  > 2.  I then ran pacman -Syuu as instructed on the installation page:
> |  https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
> |
> |  I'm afraid you misread the instructions. You should run `update-core`
> |  first to upgrade to the newer pacman that handles `pacman -Syuu`
> |  correctly. (New installer packages with an up-to-date pacman are
> |  planned.)
> |
> |  > 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.
> |
> |  They might. See below.
> |
> |  > 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?
> |
> |  If the post-install script for `filesystem` were able to run, it would
> |  inform you that `*_shell.bat` are deprecated and were removed. I see
> |  you have `msys2-launcher-git` installed -- you can then use
> |  `C:\msys64\mingw64.exe` (and even pin it to the taskbar).
> |
> |  > 4. As you mention, I then tried msys2_shell.cmd.  It worked -- with
> |  a noticeable delay of 5 seconds or so.
> |
> |  May still be AD-related.
> |
> |  > * should I worry about all those install errs
> |
> |  I recommend staying on the safe side and nuke the installation.
> |  Alternatively, reinstall the packages that had failures (`pacman -S
> |  gcc-libs gettext gmp ...`).
> |
> |  > * how can I debug what's happening with
> |  >   that long delay
> |
> |  `/etc/nsswitch.conf` allows for some configuration. See
> |  <https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-
> |  pwdgrp>.
> |
> |  > * Should I nuke the start menu shortcuts that
> |  >   the msys64 installer so carefully installed
> |  >   in favour of msys2_shell.cmd?
> |
> |  Yes or see above. Note that you might need `msys2_shell.cmd -mingw64`
> |  instead (not sure if it matters for GHC).
> |
> |  --
> |  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!

[lonetiger]

Hi Simon,

To test if it’s AD try (in case my other email didn’t get through):

➢ 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.

Cheers,
Tamar

From: Simon Peyton Jones via 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!

[Simon Peyton Jones via ghc-devs]

David, Tamar

I have another issue.  I'm using 'magit' (in emacs) to drive git.  But it gives 
half-minute delays to do anything at all.  There are lots of people complaining 
about it (googlable) but no solutions I can see.  Do I have to give up magit?

It used to be fine in earlier versions.

Just at the moment it's Much Much More Serious.  Even opening a file in emacs 
(nothing to do with git or (ostensibly) magit, takes nearly a minute!!  In the 
process manager I can see lots of git activity -- just when I open a file in 
ordinary emacs!

I have utterly no idea why this might be.  I'm adding John Wiegley, my Emacs 
Friend

Thanks

Simon

|  -Original Message-
|  From: David Macek [mailto:david.mace...@gmail.com]
|  Sent: 28 June 2016 13:20
|  To: Simon Peyton Jones <simo...@microsoft.com>; ta...@zhox.com
|  Cc: ghc-devs@haskell.org
|  Subject: Re: msys2 64 bit: help help!
|  
|  On 27. 6. 2016 23:33, Simon Peyton Jones via ghc-devs wrote:
|  > 1.  I just left the machine for 10-15 mins and lo! the shell windows
|  opened up. It just took a lng time.
|  
|  I could be something with Active Directory. Cygwin (upon which is
|  MSYS2 based) integrates with AD, but there are numerous (google-able)
|  reports of huge slowdowns related to this.
|  
|  > At this point, starting a new shell no longer took a long time.  It
|  all seemed to be working.
|  
|  Also don't forget to exclude `C:\msys64` from any anti-virus scans.
|  
|  
|  > 2.  I then ran pacman -Syuu as instructed on the installation page:
|  https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
|  
|  I'm afraid you misread the instructions. You should run `update-core`
|  first to upgrade to the newer pacman that handles `pacman -Syuu`
|  correctly. (New installer packages with an up-to-date pacman are
|  planned.)
|  
|  > 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.
|  
|  They might. See below.
|  
|  > 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?
|  
|  If the post-install script for `filesystem` were able to run, it would
|  inform you that `*_shell.bat` are deprecated and were removed. I see
|  you have `msys2-launcher-git` installed -- you can then use
|  `C:\msys64\mingw64.exe` (and even pin it to the taskbar).
|  
|  > 4. As you mention, I then tried msys2_shell.cmd.  It worked -- with
|  a noticeable delay of 5 seconds or so.
|  
|  May still be AD-related.
|  
|  > * should I worry about all those install errs
|  
|  I recommend staying on the safe side and nuke the installation.
|  Alternatively, reinstall the packages that had failures (`pacman -S
|  gcc-libs gettext gmp ...`).
|  
|  > * how can I debug what's happening with
|  >   that long delay
|  
|  `/etc/nsswitch.conf` allows for some configuration. See
|  <https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-
|  pwdgrp>.
|  
|  > * Should I nuke the start menu shortcuts that
|  >   the msys64 installer so carefully installed
|  >   in favour of msys2_shell.cmd?
|  
|  Yes or see above. Note that you might need `msys2_shell.cmd -mingw64`
|  instead (not sure if it matters for GHC).
|  
|  --
|  David Macek

___
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]

David, Tamar

Thanks for your help.  I'm a bit further forward.

|  > 1.  I just left the machine for 10-15 mins and lo! the shell windows
|  opened up. It just took a lng time.
|  
|  I could be something with Active Directory. Cygwin (upon which is
|  MSYS2 based) integrates with AD, but there are numerous (google-able)
|  reports of huge slowdowns related to this.

|  > 4. As you mention, I then tried msys2_shell.cmd.  It worked -- with
|  a noticeable delay of 5 seconds or so.
|
|  May still be AD-related.

Let's suppose it is AD.  Do you have any idea what I can do about it?


|  If the post-install script for `filesystem` were able to run, it would
|  inform you that `*_shell.bat` are deprecated and were removed. I see
|  you have `msys2-launcher-git` installed -- you can then use
|  `C:\msys64\mingw64.exe` (and even pin it to the taskbar).

OK... so forget msys2_shell.cmd and use mingw64.exe instead.  I'll try that.

|  > * how can I debug what's happening with
|  >   that long delay
|  
|  `/etc/nsswitch.conf` allows for some configuration. See
|  .

OK.. I see that page. Now what?  What might I do with nsswitch.conf that might 
help fix or give insight?

Simon

___
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 23:33, Simon Peyton Jones via ghc-devs wrote:
> 1.  I just left the machine for 10-15 mins and lo! the shell windows opened 
> up. It just took a lng time.

I could be something with Active Directory. Cygwin (upon which is MSYS2 based) 
integrates with AD, but there are numerous (google-able) reports of huge 
slowdowns related to this. 

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

Also don't forget to exclude `C:\msys64` from any anti-virus scans.


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

I'm afraid you misread the instructions. You should run `update-core` first to 
upgrade to the newer pacman that handles `pacman -Syuu` correctly. (New 
installer packages with an up-to-date pacman are planned.)

> 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.

They might. See below.

> 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?

If the post-install script for `filesystem` were able to run, it would inform 
you that `*_shell.bat` are deprecated and were removed. I see you have 
`msys2-launcher-git` installed -- you can then use `C:\msys64\mingw64.exe` (and 
even pin it to the taskbar).

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

May still be AD-related.

> * should I worry about all those install errs

I recommend staying on the safe side and nuke the installation. Alternatively, 
reinstall the packages that had failures (`pacman -S gcc-libs gettext gmp 
...`). 

> * how can I debug what's happening with 
>   that long delay

`/etc/nsswitch.conf` allows for some configuration. See 
.

> * Should I nuke the start menu shortcuts that
>   the msys64 installer so carefully installed
>   in favour of msys2_shell.cmd?

Yes or see above. Note that you might need `msys2_shell.cmd -mingw64` instead 
(not sure if it matters for GHC).

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

\usr\bin\pacman.exe: *** fatal error - 
cyg   heap base mismatch detected - 
0x180326400/0x18033A400.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.
32712616 [main] pacman 6424 fork: child -1 - forked process 9128 died 
unexpected   ly, retry 0, exit code 0xC142, 
errno 11
error: could not fork a new process (Resource temporarily unavailable)
Optional dependencies for wget
ca-certificates: HTTPS downloads [installed]
(40/40) installing pactoys-git [#] 100%


-Original Message-
From: Tamar Christina [mailto:ta...@zhox.com] 
Sent: 27 June 2016 09:19
To: Simon Peyton Jones <simo...@microsoft.com>
Cc: ghc-devs@haskell.org
Subject: Re: msys2 64 bit: help help!

Hi Simon,

Did you install it to the default location (C:\Msys64) or to a location with 
spaces in the path?

The Msys2 stuff is quite particular about spaces in the path.

If that's not the case, then in the install location of msys2 you should find 3 
batch files (mingw32.bat, mingw64.bat and msys2_shell.bat)

If you only have the msys2_shell.bat use that one instead of mingw64.bat (msys2 
in an update will change the shortcuts so I am not sure if the update was done 
already on your install).

Open a command-line window and run that batch file. It should then show you the 
error without closing the window.

alternatively, you can try starting bash in cmd instead of mitty, using "set 
MSYSTEM=MINGW64 && E:\msys64 E:\msys64\usr\bin\bash --login" replacing the path 
with your install path. 

Let me know if these don't work.

Kind Regards,
Tamar

3 batch files 
 On Mon, 27 Jun 2016 10:01:28 +0200 Simon Peyton Jones  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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fsourceforge.net%2fp%2fmsys2%2fwiki%2fMSYS2%2520installation%2f=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c2801115a7b2e43ebd2da08d39e63ba89%7c72f988bf86f141af91ab2d7cd011db47%7c1=qXzbQdt3AGrhl3oL48tbGsUgpz%2b6q9uCCMrlfn145Wg%3d,
>  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: 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

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