On Tue, Jun 28, 2016 at 12:15 PM, Christopher Done wrote:
> Thanks! It's strange to think there was once no GHCi. This is an interesting
> piece of Haskell implementation history! =)
It was really exciting when ghci showed up. No need to separately
load everything into
Hi Simon,
I’m not sure what’s going on there.
I updated my curl to 7.49.1 and I am experiencing the same silent death
(--version doesn’t even work for me then which is weird).
In any case, downgrading back to 7.48.0 worked for me.
I don’t know how to do that with pacman, so instead maybe try:
Actually I had the command right; copy/paste somehow removed the underscore.
And curl –version does report
curl --version
curl 7.49.1 (x86_64-pc-msys)
so it should not be necessary anyway.
But ./configure still fails with
checking for path to top of build tree... C:/code/HEAD
configure: Checking
Hi Simon,
You’re missing an underscore in the command (there’s one between x86 and 64),
It’s pacman -R mingw-w64-x86_64-curl
This is only needed if curl --version reports anything other than
x86_64-pc-msys.
After that you need to install the normal msys curl with pacman -S curl
You don’t
Friends
I want to thank everyone who has responded - very helpful!
Thanks to your help I am making progress
*I re-installed msys64 from scratch, this time following the
instructions on the GHC wiki rather than the msys2 page. By doing update-core;
then pacman -Su; then pacman -Su
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.
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
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
> 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
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:
>
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 ,
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.
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
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
14 matches
Mail list logo