msys2 64 bit: help help!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

msys2 64 bit: help help!

GHC - devs mailing list

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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:

My setup log is here, which explains how to use Cmder with MSYS2:

All the best
Luke


On Mon, Jun 27, 2016 at 1:21 AM, David Macek <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: msys2 64 bit: help help!

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
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 loooong 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_64    76.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_64    2.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_64    785.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_64        13.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 [#####################] 100%
 file-5.25-1-x86_64       396.5 KiB   352K/s 00:01 [#####################] 100%
 filesystem-2016.05-...    36.3 KiB  1297K/s 00:00 [#####################] 100%
 gnupg-1.4.20-1-x86_64   1026.9 KiB  1927K/s 00:01 [#####################] 100%
 grep-2.22-3-x86_64       230.3 KiB  2.29M/s 00:00 [#####################] 100%
 libarchive-3.2.0-1-...   743.4 KiB  2.09M/s 00:00 [#####################] 100%
 mintty-1~2.2.3-1-x86_64  147.2 KiB  4.64M/s 00:00 [#####################] 100%
 mpfr-3.1.4-1-x86_64      238.5 KiB  1099K/s 00:00 [#####################] 100%
 msys2-launcher-git-...    28.5 KiB  2037K/s 00:00 [#####################] 100%
 xz-5.2.2-1-x86_64        142.5 KiB  3.87M/s 00:00 [#####################] 100%
 pacman-5.0.1.6403.5...     6.8 MiB  1776K/s 00:04 [#####################] 100%
 rebase-4.4.2-1-x86_64    236.4 KiB  1487K/s 00:00 [#####################] 100%
 libgpg-error-1.21-1...   103.8 KiB  3.38M/s 00:00 [#####################] 100%
 libassuan-2.4.2-1-x...    91.7 KiB  4.71M/s 00:00 [#####################] 100%
 libgpgme-1.6.0-1-x86_64  175.7 KiB  4.09M/s 00:00 [#####################] 100%
 wget-1.17.1-3-x86_64     570.7 KiB  2.04M/s 00:00 [#####################] 100%
 pactoys-git-r1.e58a...    27.7 KiB  3.00M/s 00:00 [#####################] 100%
(40/40) checking keys in keyring                   [#####################] 100%
(40/40) checking package integrity                 [#####################] 100%
(40/40) loading package files                      [#####################] 100%
(40/40) checking for file conflicts                [#####################] 100%
(41/41) checking available disk space              [#####################] 100%
warning: could not get file information for mingw32/
warning: could not get file information for mingw32/bin/
warning: could not get file information for mingw32/etc/
warning: could not get file information for mingw32/include/
warning: could not get file information for mingw32/lib/
warning: could not get file information for mingw32/share/
warning: could not get file information for mingw64/
warning: could not get file information for mingw64/bin/
warning: could not get file information for mingw64/etc/
warning: could not get file information for mingw64/include/
warning: could not get file information for mingw64/lib/
warning: could not get file information for mingw64/share/
warning: could not get file information for opt/
warning: could not get file information for mingw32.exe
warning: could not get file information for mingw32.ini
warning: could not get file information for mingw64.exe
warning: could not get file information for mingw64.ini
warning: could not get file information for msys2.exe
warning: could not get file information for msys2.ini
warning: could not get file information for autorebasebase1st.bat
:: Processing package changes...
(1/1) removing repman-git                          [#####################] 100%
( 1/40) upgrading msys2-runtime                    [#####################] 100%
( 2/40) upgrading bash-completion                  [#####################] 100%
( 3/40) upgrading gcc-libs                         [#####################] 100%
      3 [main] pacman (8492) C:\msys64\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.
      0 [main] pacman 6424 fork: child -1 - forked process 8492 died unexpectedl                                   y, retry 0, exit code 0xC0000142, errno 11
error: could not fork a new process (Resource temporarily unavailable)
( 4/40) upgrading libintl                          [#####################] 100%
( 5/40) upgrading libgettextpo                     [#####################] 100%
( 6/40) upgrading libasprintf                      [#####################] 100%
( 7/40) upgrading gettext                          [#####################] 100%
      1 [main] pacman (700) C:\msys64\usr\bin\pacman.exe: *** fatal error - cygh                                   eap 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.
1793360 [main] pacman 6424 fork: child -1 - forked process 700 died unexpectedly                                   , retry 0, exit code 0xC0000142, errno 11
error: could not fork a new process (Resource temporarily unavailable)
( 8/40) upgrading liblzma                          [#####################] 100%
( 9/40) upgrading gmp                              [#####################] 100%
      1 [main] pacman (3128) C:\msys64\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.
1942064 [main] pacman 6424 fork: child -1 - forked process 3128 died unexpectedl                                   y, retry 0, exit code 0xC0000142, errno 11
error: could not fork a new process (Resource temporarily unavailable)
(10/40) upgrading libnettle                        [#####################] 100%
(11/40) upgrading coreutils                        [#####################] 100%
      1 [main] pacman (3376) C:\msys64\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.
4846481 [main] pacman 6424 fork: child -1 - forked process 3376 died unexpectedl                                   y, retry 0, exit code 0xC0000142, errno 11
error: could not fork a new process (Resource temporarily unavailable)
(12/40) upgrading ncurses                          [#####################] 100%
(13/40) upgrading bsdcpio                          [#####################] 100%
(14/40) upgrading bsdtar                           [#####################] 100%
(15/40) upgrading libcrypt                         [#####################] 100%
(16/40) upgrading crypt                            [#####################] 100%
(17/40) upgrading libopenssl                       [#####################] 100%
(18/40) upgrading heimdal-libs                     [#####################] 100%
(19/40) upgrading openssl                          [#####################] 100%
(20/40) upgrading gzip                             [#####################] 100%
      1 [main] pacman (1752) C:\msys64\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.
24726165 [main] pacman 6424 fork: child -1 - forked process 1752 died unexpected                                   ly, retry 0, exit code 0xC0000142, errno 11
error: could not fork a new process (Resource temporarily unavailable)
(21/40) upgrading libssh2                          [#####################] 100%
(22/40) upgrading libexpat                         [#####################] 100%
(23/40) upgrading libcurl                          [#####################] 100%
(24/40) upgrading curl                             [#####################] 100%
(25/40) upgrading file                             [#####################] 100%
(26/40) upgrading filesystem                       [#####################] 100%
      1 [main] pacman (6260) C:\msys64\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.
27083623 [main] pacman 6424 fork: child -1 - forked process 6260 died unexpected                                   ly, retry 0, exit code 0xC0000142, errno 11
error: could not fork a new process (Resource temporarily unavailable)
(27/40) upgrading gnupg                            [#####################] 100%
      1 [main] pacman (852) C:\msys64\usr\bin\pacman.exe: *** fatal error - cygh                                   eap 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.
27485279 [main] pacman 6424 fork: child -1 - forked process 852 died unexpectedl                                   y, retry 0, exit code 0xC0000142, errno 11
error: could not fork a new process (Resource temporarily unavailable)
(28/40) upgrading grep                             [#####################] 100%
      2 [main] pacman (3868) C:\msys64\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.
27800784 [main] pacman 6424 fork: child -1 - forked process 3868 died unexpected                                   ly, retry 0, exit code 0xC0000142, errno 11
error: could not fork a new process (Resource temporarily unavailable)
(29/40) upgrading libarchive                       [#####################] 100%
(30/40) upgrading mintty                           [#####################] 100%
(31/40) upgrading mpfr                             [#####################] 100%
      1 [main] pacman (4728) C:\msys64\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.
28144605 [main] pacman 6424 fork: child -1 - forked process 4728 died unexpected                                   ly, retry 0, exit code 0xC0000142, errno 11
error: could not fork a new process (Resource temporarily unavailable)
(32/40) upgrading msys2-launcher-git               [#####################] 100%
(33/40) upgrading xz                               [#####################] 100%
(34/40) upgrading pacman                           [#####################] 100%
(35/40) upgrading rebase                           [#####################] 100%
(36/40) installing libgpg-error                    [#####################] 100%
(37/40) installing libassuan                       [#####################] 100%
      1 [main] pacman (4672) C:\msys64\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.
31924467 [main] pacman 6424 fork: child -1 - forked process 4672 died unexpected                                   ly, retry 0, exit code 0xC0000142, errno 11
error: could not fork a new process (Resource temporarily unavailable)
(38/40) installing libgpgme                        [#####################] 100%
      1 [main] pacman (5432) C:\msys64\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.
32015724 [main] pacman 6424 fork: child -1 - forked process 5432 died unexpected                                   ly, retry 0, exit code 0xC0000142, errno 11
error: could not fork a new process (Resource temporarily unavailable)
(39/40) installing wget                            [#####################] 100%
      1 [main] pacman (9128) C:\msys64\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 0xC0000142, 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:[hidden email]]
Sent: 27 June 2016 09:19
To: Simon Peyton Jones <[hidden email]>
Cc: [hidden email]
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?
>  
> &middot;        I install it from here:  https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fsourceforge.net%2fp%2fmsys2%2fwiki%2fMSYS2%2520installation%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c2801115a7b2e43ebd2da08d39e63ba89%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qXzbQdt3AGrhl3oL48tbGsUgpz%2b6q9uCCMrlfn145Wg%3d, which seems to be the canonical place.  The actual 64-bit exe seems to be msys2-x86_64-20160205.exe.
> &middot;        Installation goes fine
> &middot;        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.
> &middot;        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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: msys2 64 bit: help help!

Andrey Mokhov
In reply to this post by GHC - devs mailing list
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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 loooong 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: msys2 64 bit: help help!

David Macek
In reply to this post by GHC - devs mailing list
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 loooong 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: msys2 64 bit: help help!

GHC - devs mailing list
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 loooong 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
|  <https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-
|  pwdgrp>.

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: msys2 64 bit: help help!

GHC - devs mailing list
In reply to this post by David Macek
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:[hidden email]]
|  Sent: 28 June 2016 13:20
|  To: Simon Peyton Jones <[hidden email]>; [hidden email]
|  Cc: [hidden email]
|  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 loooong 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: msys2 64 bit: help help!

Phyx
In reply to this post by GHC - devs mailing list

 

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: [hidden email]
Sent: Tuesday, June 28, 2016 13:47
To: [hidden email]; [hidden email]
Cc: [hidden email]
Subject: RE: msys2 64 bit: help help!

 

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

|  <https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-

|  pwdgrp>.

 

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

[hidden email]

http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

 


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: msys2 64 bit: help help!

Luite Stegeman
In reply to this post by GHC - devs mailing list
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 <[hidden email]> 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:[hidden email]]
|  Sent: 28 June 2016 13:20
|  To: Simon Peyton Jones <[hidden email]>; [hidden email]
|  Cc: [hidden email]
|  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 loooong 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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] <https://github.com/git-for-windows/git/wiki/Install-inside-MSYS2-proper>
[2] <https://git-for-windows.github.io/>

--
David Macek


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: msys2 64 bit: help help!

GHC - devs mailing list
In reply to this post by 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) 

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:[hidden email]]
Sent: 28 June 2016 14:09
To: Simon Peyton Jones <[hidden email]>; David Macek <[hidden email]>; [hidden email]; John Wiegley <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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:[hidden email]]
|  Sent: 28 June 2016 13:20
|  To: Simon Peyton Jones <[hidden email]>; [hidden email]
|  Cc: [hidden email]
|  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 loooong 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: msys2 64 bit: help help!

Simon Michael
In reply to this post by GHC - devs mailing list
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: msys2 64 bit: help help!

Phyx
In reply to this post by GHC - devs mailing list

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: [hidden email]
Sent: Tuesday, June 28, 2016 16:00
To: [hidden email]; [hidden email]; [hidden email]; [hidden email]
Cc: [hidden email]
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) 

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:[hidden email]]
Sent: 28 June 2016 14:09
To: Simon Peyton Jones <[hidden email]>; David Macek <[hidden email]>; [hidden email]; John Wiegley <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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:[hidden email]]
|  Sent: 28 June 2016 13:20
|  To: Simon Peyton Jones <[hidden email]>; [hidden email]
|  Cc: [hidden email]
|  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 loooong 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

 


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs