Re: msys2 64 bit: help help!

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? > > [...] > >

RE: msys2 64 bit: help help!

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

RE: msys2 64 bit: help help!

Tamar Thank you! Yes, it's in c:/msys64 Since I wrote more odd things have happened. 1. I just left the machine for 10-15 mins and lo! the shell windows opened up. It just took a lng time. At this point, starting a new shell no longer took a long time. It all seemed to be working. 2.

Re: Using the GHC API to write an interpreter

On 27 June 2016 at 13:31, Christopher Done wrote: > On 27 June 2016 at 10:01, Simon Marlow wrote: > > On 26 June 2016 at 11:28, Christopher Done wrote: > >> > >> I've been pondering how feasible it would be to: > >> > >> * Compile

Re: Using the GHC API to write an interpreter

On 27 June 2016 at 10:01, Simon Marlow wrote: > On 26 June 2016 at 11:28, Christopher Done wrote: >> >> I've been pondering how feasible it would be to: >> >> * Compile in stages a module with the byte code linker >> * Keep hold of the Core source >> *

Re: Using the GHC API to write an interpreter

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

Re: msys2 64 bit: help help!

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:

Re: msys2 64 bit: help help!

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

Re: Using the GHC API to write an interpreter

On 26 June 2016 at 11:28, Christopher Done wrote: > I've been pondering how feasible it would be to: > > * Compile in stages a module with the byte code linker > * Keep hold of the Core source > * Interpret the Core AST within Haskell > Interestingly, the first

msys2 64 bit: help help!

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:

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

I believe I've just fixed this. I think it was non-deterministic in some way that I don't fully understand, but hopefully I've made it deterministic now. https://phabricator.haskell.org/rGHC7843c71c7e48cdba115bef422184e855ede23a67 On 24 June 2016 at 15:12, Simon Peyton Jones via ghc-devs <

Re: [commit: ghc] master: Accept new (lower) allocations for T7257 (15641b0)

Yes, it was the sizeExpr fix. It validated locally and on Travis, but I'm guessing it was right on the boundary. On 22 June 2016 at 22:37, Bartosz Nitka wrote: > Appears to be: > a47b62cb3685 Second attempt to fix sizeExpr > >