- ghc-devs - Haskell.org

Linker.c broken
by Simon Peyton Jones 04 Jul '16

04 Jul '16

Aargh! Windows is broken /again/. Some mess-up in Linker.c. I have not yet tried reverting recent patches. Might someone fix please? It’s really helpful to validate on Windows when making RTS changes. Simon rts\Linker.c: In function 'ghci_find': rts\Linker.c:1482:52: error: error: pointer type mismatch in conditional expression [-Werror] oc->archiveMemberName : oc->fileName); ^ rts\Linker.c:1480:28: error: error: format '%ls' expects argument of type 'wchar_t *', but argument 3 has type 'void *' [-Werror=format=] debugBelch("%p is in %" PATH_FMT, addr, ^ "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-fno-omit-frame-pointer -optc-g -optc-O0 -optc-DRtsWay=\"rts_debug\" -optc-DWINVER=0x06000100 -static -optc-DDEBUG -ticky -DTICKY_TICKY -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -O0 -Wnoncanonical-monad-instances -c rts/RaiseAsync.c -o rts/dist/build/RaiseAsync.debug_o rts\Linker.c:1483:28: error: error: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Werror=format=] debugBelch(", section %d, offset %lx\n", i, ^ In file included from rts\Linker.c:13:0: error: rts\Linker.c: In function 'ocTryLoad': rts\Linker.c:2563:55: error: error: pointer type mismatch in conditional expression [-Werror] oc->archiveMemberName : oc->fileName)); ^ includes\Rts.h:300:53: error: note: in definition of macro 'IF_DEBUG' #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } ^ rts\Linker.c:2561:33: error: error: format '%ls' expects argument of type 'wchar_t *', but argument 2 has type 'void *' [-Werror=format=] IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n", ^ includes\Rts.h:300:53: error: note: in definition of macro 'IF_DEBUG' #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) rts/ghc.mk:255: recipe for target 'rts/dist/build/Linker.debug_o' failed make[1]: *** [rts/dist/build/Linker.debug_o] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 /cygdrive/c/code/HEAD$

8 20

Interruptible exception wormholes kill modularity
by Edward Z. Yang 04 Jul '16

04 Jul '16

In 2010, in the thread "Asynchronous exception wormholes kill modularity" [1], Bas van Dijk observed that 'unblock :: IO a -> IO a' broke modularity, as the sequence of calls 'block . block . unblock $ io' would result in 'io' being run with asynchronous exceptions unblocked, despite the outer 'block' "expecting" that asynchronous exceptions cannot be thrown. I would like to make two claims: 1. The new mask/restore interface is insufficient to "solve" this modularity problem, as *interruptible* operations can still be used to catch asynchronous exceptions. 2. Thus, we should provide an unblock combinator which can be used to catch asynchronous exceptions from a 'mask' (though not an 'uninterruptibleMask')--though it is doubtful if anyone should ever use 'mask' in the first place. Claim 1: Here is some code which reimplements 'unblock': import Control.Exception import Control.Concurrent import Control.Concurrent.MVar unblock :: IO a -> IO a unblock io = do m <- newEmptyMVar _ <- forkIO (io >>= putMVar m) takeMVar m The main idea is that 'takeMVar' is an interruptible operation: when it blocks, the thread can now receive asynchronous exceptions. In general, a thread can unmask exceptions by blocking. Here is a simple test-case: main = do let x = 10000000 -- Just do a bit of work tid <- myThreadId forkIO $ (threadDelay 10000 >> killThread tid) r <- mask $ \restore -> do -- restore $ do -- unblock $ do -- do something non-blocking evaluate (f x []) -- If the exception is delivered in a timely manner, -- shouldn't get here. print r f 0 r = r f n r = f (n-1) (n:r) With both restore and unblock commented, the ThreadKilled exception is delayed; uncommenting either restore or unblock causes the exception to be delivered. This admonition does not apply to uninterruptibleMask, for which there are no interruptible exceptions. Claim 2: Thus, I come to the conclusion that we were wrong to remove 'unblock', and that it is no worse than the ability for interruptible actions to catch asynchronous exceptions. You could very well argue that interruptible actions are a design flaw. Then you should use 'uninterruptibleMask' instead, which effectively removes the concept of interruptibility--and is thus modular. Indeed, Eyal Lotem proposed [2] that 'bracket' should instead use 'uninterruptibleMask', for precisely the reason that it is too easy to reenable asynchronous exceptions in 'mask'. But assuming that interruptible masks are a good idea (Simon Marlow has defended them as "a way avoid reasoning about asynchronous exceptions except at specific points, i.e., where you might block"), there should be an 'unblock' for this type of mask. It should be said that the absence of 'unblock' for 'uninterruptibleMask' only implies that a passed in IO action (e.g., the cleanup action in bracket) does not have access to the exceptions thrown to the current thread; it doesn't actually guarantee uninterruptibility, since the passed in IO action could always raise a normal exception. Haskell's type system is not up to the task of enforcing such invariants. Cheers, Edward [1] https://mail.haskell.org/pipermail/libraries/2010-March/013310.html https://mail.haskell.org/pipermail/libraries/2010-April/013420.html [2] https://mail.haskell.org/pipermail/libraries/2014-September/023675.html P.S. You were CC'ed to this mail because you participated in the original "Asynchronous exception wormholes kill modularity" discussion. P.P.S. I have some speculations about using uninterruptibleMask more frequently: it seems to me that there ought to be a variant of uninterruptibleMask that immediately raises an exception if the "uninterruptible" action blocks. This would probably of great assistance of noticing and eliminating blocking in uninterruptible code.

3 6

Template Haskell determinism
by Bartosz Nitka 02 Jul '16

02 Jul '16

Template Haskell with its ability to do arbitrary IO is non-deterministic by design. You could for example embed the current date in a file. There is however one kind of non-deterministic behavior that you can trigger accidentally. It has to do with how Names are reified. If you take a look at the definition of reifyName you can see that it puts the assigned Unique in a NameU: reifyName :: NamedThing n => n -> TH.Name reifyName thing | isExternalName name = mk_varg pkg_str mod_str occ_str | otherwise = TH.mkNameU occ_str (getKey (getUnique name)) ... NameFlavour which NameU is a constructor of has a default Ord instance, meaning that it ends up comparing the Uniques. The relative ordering of Uniques is not guaranteed to be stable across recompilations [1], so this can lead to ABI-incompatible binaries. This isn't an abstract problem and it actually happens in practice. The microlens package keeps Names in a Set and later turns that set into a list. The results have different orders of TyVars resulting in different ABI hashes and can potentially be optimized differently. I believe it's worth to handle this case in a deterministic way and I have a solution in mind. The idea is to extend NameU (and potentially NameL) with an ordering key. To be more concrete: - | NameU !Int + | NameU !Int !Int This way the Ord instance can use a stable key and the problem reduces to ensuring the keys are stable. To generate stable keys we can use the fact that reify traverses the expressions in the same order every time and sequentially allocate new keys based on traversal order. The way I have it implemented now is to add a new field in TcGblEnv which maps Uniques to allocated keys: + tcg_th_names :: TcRef (UniqFM Int, Int), Then the reifyName and qNewName do the necessary bookkeeping and translate the Uniques on the fly. This is a breaking change and it doesn't fix the problem that NameFlavour is not abstract and leaks the Uniques. It would break at least: - singletons - th-lift - haskell-src-meta - shakespeare - distributed-closure I'd like to get feedback if this is an acceptable solution and if the problem is worth solving. Cheers, Bartosz [1] https://ghc.haskell.org/trac/ghc/wiki/DeterministicBuilds#NondeterministicU…

5 11

Trac Spam
by Ben Gamari 30 Jun '16

30 Jun '16

Hello everyone, As you may have noticed we were hit with another bout of Trac spam today. I've tightened the spam filter up a bit further and things now seem to be once again under control. Of course, tightening up the spam filter may come at a cost. While I've tried my best to setup the filter such that legitimate uses are unimpeded, filtering is more of an art than a science. Please let me know if you find that you are hasseled with excessive CAPTCHAs or even outright rejection. Cheers, - Ben

1 0

topHandler03 failing now
by Edward Z. Yang 30 Jun '16

30 Jun '16

Hey thomie, You recently changed topHandler03 to not ignore output. Unfortunately, on my Arch Linux box this causes the test to fail: --- ./topHandler03.run/topHandler03.stderr.normalised 2016-06-30 10:30:56.423442132 -0700 +++ ./topHandler03.run/topHandler03.run.stderr.normalised 2016-06-30 10:30:56.423442132 -0700 @@ -1 +1 @@ -Terminated +/bin/sh: line 1: 7193 Terminated ./topHandler03 It seems the shell output behavior here varies. Edward

1 0

Trac spam
by Simon Peyton Jones 30 Jun '16

30 Jun '16

If someone could kill this spate of Trac spam, it’d be great. Simon

1 0

Using the GHC API to write an interpreter
by Christopher Done 28 Jun '16

28 Jun '16

I've been pondering how feasible it would be to: * Compile in stages a module with the byte code linker * Keep hold of the Core source * Interpret the Core AST within Haskell * When encountering built-in/primitives (or things from other libraries), we compile that Core term and link it as an HValue and then run it with the arguments expected. So () would be such a HValue, as would be "show" which in interpretable unoptimized Core would take an extra argument for the Show instance. When passing in values to such "foreign" functions it would wrap them up in an interpretive way. This is the hypothetical idea, it seems like it would yield a really trivial way to write a new and interesting interpreter for GHC Haskell without having to re-implement any prim ops, ready to work on regular Haskell code. In my case, I would use this to write an interpreter which: * is not tagless, so we preserve type info * allows top-level names to be redefined * when a function is applied, it checks the type of its arguments Both of these are pretty much necessary for being able to do in-place update of a running program while developing (a la Emacs or Smalltalk), and type tags let us throw a regular Haskell exception of type error, a la deferred type errors. It means in your running program, if you make a mistake or forget to update one part, it doesn't bring the whole program down with an RTS error or a segfault, maybe a handler in a thread (like a server or a video game) throws an exception and the developer just updates their code and tries again. I'd love support for something like this, but I'd rather not have to re-create the world just to add this capability. Because it's really just conceptually regular interpreted GHC Haskell plus type tags and updating, it seems like it should be a small diff. Any input into this? How far away is GHC's current architecture from supporting such a concept? Ciao!

4 7

RE: msys2 64 bit: help help!
by Simon Peyton Jones 28 Jun '16

28 Jun '16

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  installing pactoys-git [#####################] 100% -----Original Message----- From: Tamar Christina [mailto:tamar@zhox.com] Sent: 27 June 2016 09:19 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: ghc-devs(a)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%2fsourceforg…, 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 > > > >

5 9

RE: msys2 64 bit: help help!
by Andrey Mokhov 27 Jun '16

27 Jun '16

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

2 1

msys2 64 bit: help help!
by Simon Peyton Jones 27 Jun '16

27 Jun '16

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

3 2