I closed the previous ticket and opened another with a simple reproducer
attached. It consists
of just two source files, and shows that when a trivial library is
installed by stack and compiled
using ghc, there are problems, but if everything is compiled using ghci
there are no problems.
https://gi
Thanks, that does indeed look dynamically linked.
Could you also paste on the ticket the contents of hR.buildinfo?
Cheers,
Tamar
Sent from my Mobile
On Mon, Mar 27, 2023, 15:18 Dominick Samperi wrote:
> Yes, everything else stays the same, including x <- r_NilValue.
>
> I opened a ticket her
Yes, everything else stays the same, including x <- r_NilValue.
I opened a ticket here where more details are provided
https://gitlab.haskell.org/ghc/ghc/-/issues/23183
After initializing an R instance, if you fetch R_NilValue and
peek at its value (using FFI peek) you get a bad address. But if
Hi,
I'm missing some details here here as I'm having trouble following the
flow.
What provides the symbol for that import? As in where does R_NilValue come
from? As in, how is it defined. Are you linking against a library or C
sources?
When you say you replace the trace statement, do you keep th
Thanks Ben, I'll see what I can do to reliably reproduce and open a ticket.
One theory I'm investigating is that this might have something to do
with my anti-virus software (AVG), since it sometimes interacts with
Windows in strange ways (for example, an extra instance of a terminal app
pops up, t
This sounds like a bug. Could you open a ticket, ideally with a fairly
standalone reproducer?
Cheer,
- Ben
On March 25, 2023 6:49:09 PM EDT, Dominick Samperi wrote:
>Hello,
>FFI code that used to work now fails under Windows (still seems to work
>under Ubuntu), and I wonder if anybody has see
Andreas Klebinger writes:
> Hi devs,
>
> it seems the windows build is broken. (Can't build stage2 locally).
>
> Quickest way to reproduce is a validate of master.
>
> It also happens on CI: https://gitlab.haskell.org/ghc/ghc/-/jobs/270248
>
> I remember ben mentioning something along the lines o
Simon Peyton Jones via ghc-devs writes:
> Both Tamar and Omer are right.
>
> * Not doing CI on Windows is bad. It means that bugs get introduced,
> and not discovered until later. This is Tamer’s point, and it is
> valid.
> * Holding up MRs because a failures in Windows CI that is unr
Ömer Sinan Ağacan writes:
>> Now we have rewritten the CI and it's pointing out actual issues in the
>> compiler. And your suggestion is well let's just ignore it.
>
> When is the last time Windows CI caught an actual bug? All I see is random
> system failures [1, 2, 3].
>
> It must be catching *
Ömer Sinan Ağacan writes:
> Hi Ben,
>
> Can we please disable Windows CI? I've spent more time fighting the CI than
> doing useful work this week, it's really frustrating.
>
Yes, this recent spate is issues indeed took too long to solve.
Unfortunately this particular issue took quite a while to i
bug.
How hard would it be to do that? Do we even know what the problem is?
Simon
From: ghc-devs On Behalf Of Phyx
Sent: 17 January 2020 06:49
To: Ömer Sinan Ağacan
Cc: ghc-devs
Subject: Re: Windows testsuite failures
Oh I spent a non-insignificant amount of time back in the phabricator days
On Fri, Jan 17, 2020 at 7:02 AM Ömer Sinan Ağacan
wrote:
> > Now we have rewritten the CI and it's pointing out actual issues in the
> > compiler. And your suggestion is well let's just ignore it.
>
> When is the last time Windows CI caught an actual bug? All I see is random
> system failures [1,
> Now we have rewritten the CI and it's pointing out actual issues in the
> compiler. And your suggestion is well let's just ignore it.
When is the last time Windows CI caught an actual bug? All I see is random
system failures [1, 2, 3].
It must be catching *some* bugs, but that's a rare event in
Oh I spent a non-insignificant amount of time back in the phabricator days
to make the CI stable. Now because people were committing to master
directly without going through CI it was always a cat and mouse game and I
gave up eventually.
Now we have rewritten the CI and it's pointing out actual is
We release more often than once in 6 months.
We clearly have no idea how to test on Windows. If you know how to do it then
feel free to submit a MR. Otherwise blocking every MR indefinitely is worse than
testing Windows less frequently.
Ömer
Phyx , 17 Oca 2020 Cum, 09:10 tarihinde şunu yazdı:
>
Sure because only testing once every 6 months is a very very good idea...
Sent from my Mobile
On Fri, Jan 17, 2020, 06:03 Ömer Sinan Ağacan wrote:
> Hi Ben,
>
> Can we please disable Windows CI? I've spent more time fighting the CI than
> doing useful work this week, it's really frustrating.
>
Hi Ben,
Can we please disable Windows CI? I've spent more time fighting the CI than
doing useful work this week, it's really frustrating.
Since we have no idea how to fix it maybe we should test Windows only before a
release, manually (and use bisect in case of regressions).
Ömer
Ben Gamari , 1
Just to make this clear it's not my intention to blame anyone or point
fingers.
Given the resources at hand I think Phyx and you have done an amazing job
so far to keep things working!
The core of the issue is that if someone sits down and installs a
"stable" GHC today he
will either get a versio
Phyx writes:
> Hi Andreas,
>
> GHC 8.6.4 not supporting profiling libs was the first thing mentioned in
> the release email
>
> - A regression resulting in segmentation faults on Windows introduced
>by the fix for #16071 backported in 8.6.3. This fix has been reverted,
>meaning that 8.6.
Hi Andreas,
GHC 8.6.4 not supporting profiling libs was the first thing mentioned in
the release email
- A regression resulting in segmentation faults on Windows introduced
by the fix for #16071 backported in 8.6.3. This fix has been reverted,
meaning that 8.6.4 is once again susceptible t
Hi Simon,
That's still a lot more than I expect. Is this just with a validate run and
not re-running the failed tests?
My guess is re-running that list of failing tests should significantly
reduce the amount.
There does seem to be an issue with threading lately, but I am not sure
where it lies.
I
rt LANG=en_GB.UTF-8
>>
>>
>>
>> Progress!
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Phyx
>> *Sent:* 06 December 2018 23:43
>> *To:* Simon Peyton Jones
>> *Cc:* ghc-devs@haskell.org Devs
>> *Subject:* R
Hi Roland,
Thanks for looking into thiis,
> To fix the issue on Windows, the compiler and the plugin should use the
same buffer for stdout.
I'm not convinced that they're not. I'm guessing the answer lies in why
your messages have a different
ordering, but I don't know why off the top of my head
t; its efficacy by running one test rather than 6,000 of them? In which case,
> which one?
>
>
> Thanks
>
>
>
> Simon
>
>
>
>
>
> *From:* Phyx
> *Sent:* 02 December 2018 20:43
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org Devs
om: Phyx
Sent: 02 December 2018 20:43
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org Devs
Subject: Re: Windows test failures
Hi Simon,
That's a bit better (still need to figure out why the recent threading issues,
but one problem at a time :) )
From that list T10672_x64 is one I'm looking
Hi Tamar,
WINDOWS===On Windows I did the following changes before running the
'plugin09' test: 1.) In the compiler (HscMain.hs), just before calling
the plugin function 'parsedPlugin', I set BufferMode of the file stdout
to LineBuffering. 2.) At the same place, I write a message to stdout
with
Hi Roland,
Thanks for looking into these.
> I looked into the testcases 'plugins09', 'plugins10' and 'plugins11' and
found the following: GHC-Windows uses BufferMode 'BlockBuffering Nothing',
however, GHC-Linux uses 'LineBuffering'.
Ah, yes, this isn't technically a Linux vs Windows thing, GHC w
Hi Tamar,
I looked into the testcases 'plugins09', 'plugins10' and 'plugins11'
and found the following: GHC-Windows uses BufferMode 'BlockBuffering
Nothing', however, GHC-Linux uses 'LineBuffering'.
If I add an 'import System.IO' and the line 'liftIO $ hSetBuffering
stdout LineBuffer' as first line
n-recomp-test.hs,
> plugin-recomp-test.o ) [Plugin forced recompilation]
>
> Stderr ( plugin-recomp-impure ):
>
> Simple Plugin Passes Queried
>
> Got options:
>
> Simple Plugin Pass Run
>
> Simple Plugin Passes Queried
>
> Access violation in generated code when
st.hs,
> plugin-recomp-test.o ) [Plugin forced recompilation]
>
> Stderr ( plugin-recomp-impure ):
>
> Simple Plugin Passes Queried
>
> Got options:
>
> Simple Plugin Pass Run
>
> Simple Plugin Passes Queried
>
> Access violation in generated code when reading 0xa824
C:\code\HEAD\inplace\bin\ghc-
> stage2.exe+0x1ab49ec
>
> make[1]: *** [Makefile:99: plugin-recomp-impure] Error 11
> *** unexpected failure for plugin-recomp-impure(normal)
> => plugin-recomp-flags(normal) 21 of 21 [0, 9, 1]
> cd "plugins/plugin-recomp-flags.run&qu
ted results from:
TEST="T10672_x64 T14452 T3307 T4006 environment001 plugin-recomp-impure
plugin-recomp-pure plugins09 plugins10 plugins11"
SUMMARY for test run started at Fri Nov 30 21:07:17 2018 GMTST
0:26:45 spent to go through
21 total tests, which gave rise to
36 test
Hi,
I'm the author of test T14452. This is test #2 in the list of failing
tests of Simon. I looked into it and found, indeed, this test is broken
under Windows. Under Windows we get quotes around the -O3 ("-O3") but
not under Linux.
I'll reopen Trac ticket #14452 and prepare a patch with an improv
Hi Simon,
Could you try rerunning those failing tests with make TEST? No threads? I
have been trying to clean up the testsuite and there should be only 3
failing tests, two plugin tests with bad stdout and T10672_x64 which I am
looking into.
I have however noticed that the testsuite has become in
ken, so
> that they don’t pollute the testsuite output?
>
>
> Simon
>
>
>
>
>
> *From:* loneti...@gmail.com
> *Sent:* 24 September 2018 07:13
>
>
> *To:* Simon Peyton Jones
> *Subject:* RE: Windows testsuite failures
>
>
>
Tamar
Thank you, that’s great!
For the ones that need more work, can we mark them as expect-broken, so that
they don’t pollute the testsuite output?
Simon
From: loneti...@gmail.com
Sent: 24 September 2018 07:13
To: Simon Peyton Jones
Subject: RE: Windows testsuite failures
Hi Simon,
I
Hi Simon,
Thanks for the email. I haven't been building head much as I'm working on
top of some older commits. From a quick look it seems like the plugin ones
are probably testisms, the plugins aren't found so likely a missing path
entry somewhere.
The linker ones are are weird, I'll need to take
Jones
Cc: ghc-devs
Subject: Re: Windows: cannot create here-doc
Hi Simon,
This one is very strange, from the error and the fact that it continues it
looks like whatever TEMP and TMP
are pointing to are not always available or some locking issue is going on.
I would try running ProcMon
https
Hi Simon,
This one is very strange, from the error and the fact that it continues it
looks like whatever TEMP and TMP
are pointing to are not always available or some locking issue is going on.
I would try running ProcMon
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon and
filteri
y.
>
The instruction could be somewhat clearer here, but they are intended to
only affect your msys2 installation, and never your global Windows system.
>
>
> Thanks
>
>
>
> Simon
>
>
>
> *From:* ghc-devs *On Behalf Of *Shao, Cheng
> *Sent:* 26 March 2018 10:
variables to what, precisely?
As I say in another email, c:/mingw64 doesn’t exist. c:/msys64 does, and
c:/msys64/mingw64. Very confusing!
Thanks
Simon
From: loneti...@gmail.com
Sent: 26 March 2018 11:09
To: Simon Peyton Jones ; Shao, Cheng
; ghc-devs@haskell.org
Subject: RE: Windows
“C
is this related to the
export MSYSTEM=MINGW64
question?
Thanks
Simon
From: ghc-devs On Behalf Of Shao, Cheng
Sent: 26 March 2018 11:07
To: ghc-devs@haskell.org
Subject: Re: Windows
Hi Simon,
Running “C:\msys64\msys2_shell.cmd -mingw64 -mintty" has the same effect as
clicki
via ghc-devs
Sent: Monday, March 26, 2018 11:03
To: Shao, Cheng; ghc-devs@haskell.org
Subject: RE: Windows
If the build environment is managed by an MSYS2 installation, then the MinGW64
shell startup script automatically sets up "MSYSTEM" for you. It can be
launched like
to work, but is clearly not what
the instructions say.
Thanks
Simon
From: ghc-devs On Behalf Of Shao, Cheng
Sent: 26 March 2018 10:59
To: ghc-devs@haskell.org
Subject: Re: Windows
Hi Simon,
If the build environment is managed by an MSYS2 installation, then the MinGW64
shell startup script
ing that I should run “C:\msys64\msys2_shell.cmd -mingw64
> -mintty" just once, after installing? Or repeatedly? Or that I should
> somehow us it as my main shell? And what does that commend actually do?
>
> Sorry to be dense
>
>
>
> Simon
>
>
>
> *From:* g
From: ghc-devs On Behalf Of Shao, Cheng
Sent: 26 March 2018 10:59
To: ghc-devs@haskell.org
Subject: Re: Windows
Hi Simon,
If the build environment is managed by an MSYS2 installation, then the MinGW64
shell startup script automatically sets up "MSYSTEM" for you. It can be
launc
instructions higher up to sa
> export MSYSTEM=MINGW64
>
> Might someone do that? I wasn't quite sure where
>
> Simon
>
> | -Original Message-
> | From: ghc-devs On Behalf Of Ben Gamari
> | Sent: 24 March 2018 16:42
> | To: Gabor Greif ; loneti.
o that? I wasn't quite sure where
Simon
| -Original Message-
| From: ghc-devs On Behalf Of Ben Gamari
| Sent: 24 March 2018 16:42
| To: Gabor Greif ; loneti...@gmail.com
| Cc: ghc-devs@haskell.org
| Subject: Re: Windows
|
| Gabor Greif writes:
|
| > Just an idea...
|
Gabor Greif writes:
> Just an idea...
>
> could this hint be part of the `configure` error message?
>
Indeed. See D4526.
Cheers,
- Ben
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/c
Just an idea...
could this hint be part of the `configure` error message?
Gabor
On 3/23/18, loneti...@gmail.com wrote:
> Hi Simon,
>
> You need
>
> export MSYSTEM=MINGW64
>
> in your bash profile.
>
> Regards,
> Tamar
>
> From: Simon Peyton Jones via ghc-devs
> Sent: Friday, March 23, 2018 22:
Hi Simon,
You need
export MSYSTEM=MINGW64
in your bash profile.
Regards,
Tamar
From: Simon Peyton Jones via ghc-devs
Sent: Friday, March 23, 2018 22:21
To: ghc-devs@haskell.org
Subject: Windows
I’ve just got a new laptop (the old one’s hard disk died) so I’m trying to get
to the point of be
Yes thanks Doug… testing now
From: loneti...@gmail.com [mailto:loneti...@gmail.com]
Sent: 08 February 2018 00:17
To: Douglas Wilson ; Simon Peyton Jones
Cc: ghc-devs
Subject: RE: Windows build broken -- help!
I’ve pushed the commit. Thanks Doug!
From: Douglas Wilson<mailto:douglas.
I’ve pushed the commit. Thanks Doug!
From: Douglas Wilson
Sent: Wednesday, February 7, 2018 23:33
To: Simon Peyton Jones
Cc: ghc-devs
Subject: Re: Windows build broken -- help!
Hi Simon,
The first patch you quoted half-fixed this.
the patch here:
https://phabricator.haskell.org/D4392
should
Hi Simon,
The first patch you quoted half-fixed this.
the patch here:
https://phabricator.haskell.org/D4392
should fix whole-fix it. (It at least validates green on windows)
On Thu, Feb 8, 2018 at 12:18 PM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:
> PS Presumably it’s the
PS Presumably it's these commits
commit 00f1a4ab80b201ce15c509126f89c5a108786f32
Author: Douglas Wilson
Date: Tue Feb 6 17:27:32 2018 -0500
rts: fix some barf format specifiers.
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie,
e?
Thanks
From: Phyx [mailto:loneti...@gmail.com]
Sent: 04 October 2017 13:30
To: Simon Peyton Jones ; ghc-devs@haskell.org
Subject: Re: Windows build broken
Hi Simon,
You seem to be in an msys shell instead of a mingw-64 shell (they have
different startup shortcuts). We don't support the m
Phyx writes:
> Hi Simon,
>
> You seem to be in an msys shell instead of a mingw-64 shell (they have
> different startup shortcuts). We don't support the msys shell as we only
> want to compile for native windows.
>
> You should use the shortcut marked mingw-64.
>
> Alternatively to get you going
Hi Simon,
You seem to be in an msys shell instead of a mingw-64 shell (they have
different startup shortcuts). We don't support the msys shell as we only
want to compile for native windows.
You should use the shortcut marked mingw-64.
Alternatively to get you going in aclocal.m4 remove line 112.
You can just leave it reverted, could you also push it?
Yes ok. I’m sorry to push you back to the drawing board ☹.
Simon
From: loneti...@gmail.com [mailto:loneti...@gmail.com]
Sent: 29 June 2017 09:37
To: Simon Peyton Jones ; ghc-devs
Subject: RE: Windows broken
Oops, sorry, didn’t notice it
the drawing
board for this one.
Thanks,
Tamar
From: Simon Peyton Jones
Sent: Thursday, June 29, 2017 09:10
To: loneti...@gmail.com; ghc-devs
Subject: RE: Windows broken
Tamar
Aha! It’s you! Reverting this commit fixes it
git revert d6cecde585b0980ed8e0050c5a1d315789fb6356
[master af9f0f4
.3.0/../../../../x86_64-w64-mingw32/include
End of search list.
GNU C11 (Rev2, Built by MSYS2 project) version 6.3.0 (x86_64-w64-mingw32)
compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version
3.1.5-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=10
/c/code/HEAD$ find inplace/mingw -name 'libwinpthread-1.dll'
inplace/mingw/bin/libwinpthread-1.dll
The same thing happens, but with a popup alert window, if I use ‘strace gcc …’.
What now?
Simon
From: loneti...@gmail.com [mailto:loneti...@gmail.com]
Sent: 29 June 2017 02:38
To: Simon Pe
Hi Simon,
What happens when you try to compile that simple test with the bundled gcc?
Could you also run it through strace, this will force msys2 not to swallow
errors from the OS.
Should you get an exception dialog then rm -rf inplace/mingw and rerun
configure (I assume you’re on a recent rev
Ryan Trinkle writes:
> I would strongly urge that any new tarballs be released under new names,
> and that the old tarballs be kept in place. Changing existing tarball URLs
> silently causes breakage for Nix, and, I would imagine, for any other build
> systems that are particularly concerned wit
Phyx writes:
> We have discussed a few options on what to do, but haven't gotten a
> conclusion/concensus yet.
>
Tamar and I have discussed this on IRC in the passed. I tend to agree
that we will need to, at the very least, put out a new 8.0.2. I'm not
sure about 7.10. Moreover, there is reported
I would strongly urge that any new tarballs be released under new names,
and that the old tarballs be kept in place. Changing existing tarball URLs
silently causes breakage for Nix, and, I would imagine, for any other build
systems that are particularly concerned with reproducibility. Nix package
We have discussed a few options on what to do, but haven't gotten a
conclusion/concensus yet.
Last we talked one option was presented to just re-tar the 7.10.3 and 8.0.2
tarballs with the fix. The gcc wrapper does not affect code generation of
the compiler, it's just there to correct paths that ar
Yikes that sounds bad!
I just wanted to raise awareness and offer myself to do guided grunt work (if
there is any) to push out a hotfix/inplace patch release for GHC 8.0.2.
Help would be fantastic. Phyx, Ben, etc: do we have a plan?
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org]
Also note that a minimal patch already exists which will ship in GHC 8.2:
https://git.haskell.org/ghc.git/commitdiff/018ac7f4b2f7345e28d21fb1f99b44dbc79f6e85
It's 'just' a matter of packaging that up in a hotfix.
On Tue, Apr 4, 2017 at 10:12 AM, Sebastian Graf wrote:
> Hi,
>
> when the Creators
…
.section .eh_frame,"a",@progbits
Simon
From: Phyx [mailto:loneti...@gmail.com]
Sent: 09 March 2017 16:38
To: Simon Peyton Jones ; ghc-devs@haskell.org
Subject: Re: Windows build failing in a new way
Hi Simon,
As of this morning the Windows build was working fine
https://github.c
Ben Gamari writes:
> loneti...@gmail.com writes:
>
>> Ah great,
>>
>> Triples again.. I still wonder why it is suddenly an issue. We haven’t
>> touched the .m4 file in a while and no one changed libffi either
>> right? This is just like last time the normalization bit us. Causing
>> days of broke
loneti...@gmail.com writes:
> Ah great,
>
> Triples again.. I still wonder why it is suddenly an issue. We haven’t
> touched the .m4 file in a while and no one changed libffi either
> right? This is just like last time the normalization bit us. Causing
> days of broken builds on different targets
were interested in.
Why do we do the normalization? It doesn’t seem to give us any benefits at
all.. Maybe we should stop doing it after the branch for 8.4?
From: Ben Gamari
Sent: Thursday, March 9, 2017 18:51
To: Phyx; Simon Peyton Jones; ghc-devs@haskell.org
Subject: Re: Windows build failing in
Phyx writes:
> My CI server is also reproducing it while I also haven't been able to
> locally. Weird indeed.
>
Ahhh, I just noticed that Reid stumbled upon the culprit yesterday. See
[1].
Cheers,
- Ben
[1] https://phabricator.haskell.org/rGHCe901ed1c5d66
signature.asc
Description: PGP sign
My CI server is also reproducing it while I also haven't been able to
locally. Weird indeed.
On Thu, 9 Mar 2017, 17:36 Ben Gamari, wrote:
> Simon Peyton Jones via ghc-devs writes:
>
> > My windows build is more broken than usual. I can't even build a GHC.
> > Please, could someone fix this? I
Simon Peyton Jones via ghc-devs writes:
> My windows build is more broken than usual. I can't even build a GHC.
> Please, could someone fix this? I'm getting desperate.
This is very odd; Harbormaster is also seeing it but I've been unable to
reproduce locally. It seems that the libffi build is
Checking again, I think something else is wrong I'll have to check later.
Sorry, but that commit above is still good. If you are really stuck use
that one.
Tamar
On Thu, 9 Mar 2017, 17:11 Phyx, wrote:
> That said, running the build on HEAD it seems that the template haskell
> stuff committed to
That said, running the build on HEAD it seems that the template haskell
stuff committed today has broken the build again. I'd suggest checking out
the commit in my previous email which is just a few hours old. And cleaning
ghc-tarballs. As the error you seem to be getting is local.
On Thu, 9 Mar 2
Hi Simon,
As of this morning the Windows build was working fine
https://github.com/Mistuke/GhcWindowsBuild/commit/aa6906b2535224721d8b049cee3edcd938c3e951
those are my nightly logs for last night at commit a02b80f
That error seems to be coming from gcc and not ghc. We did update the crt
and maybe
| Subject: RE: Windows build broken again
|
| Simon Peyton Jones via ghc-devs writes:
|
| > Windows build still broken. Please please could someone fix?
| > It's something to do with the testsuite Python script
|
| This is #13375. I have a fix in D3289. It's currently validatin
Simon Peyton Jones via ghc-devs writes:
> The Windows build is broken again. Here's the tail of the log
>
Yes, I opened a ticket (#13375) about this earlier. Running,
"C:/msys64/home/ben/ghc/inplace/bin/ghc-pkg.exe" recache
is sufficient to work around the issue it seems.
Cheers,
- Ben
This last email was the first one I’ve received from you.
From: Ben Gamari
Sent: Tuesday, March 7, 2017 18:50
To: Phyx; David Macek; simo...@microsoft.com; ghc-devs@haskell.org
Subject: Re: Windows build broken again
Phyx writes:
> https://ghc.haskell.org/trac/ghc/ticket/13375
>
Are
Phyx writes:
> https://ghc.haskell.org/trac/ghc/ticket/13375
>
Are people not receiving my messages pointing out this ticket? I've
mentioned it twice now but I get the impression that these messages
aren't being seen.
Cheers,
- Ben
signature.asc
Description: PGP signature
___
Simon Peyton Jones via ghc-devs writes:
> Windows build still broken. Please please could someone fix?
> It's something to do with the testsuite Python script
This is #13375. I have a fix in D3289. It's currently validating.
Cheers,
- Ben
signature.asc
Description: PGP signature
___
https://ghc.haskell.org/trac/ghc/ticket/13375
On Tue, 7 Mar 2017, 08:05 David Macek, wrote:
> On 4. 3. 2017 22:01, Simon Peyton Jones via ghc-devs wrote:
> > Exception: stderr from command:
> ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"', 'dump']
>
> Pinpointing the failure. I guess `ghc-pkg dump` i
On 4. 3. 2017 22:01, Simon Peyton Jones via ghc-devs wrote:
> Exception: stderr from command: ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"',
> 'dump']
Pinpointing the failure. I guess `ghc-pkg dump` is not supposed to write to
stderr, but it does. Unfortunately, the test driver doesn't seem to tell
Windows build still broken. Please please could someone fix?
It's something to do with the testsuite Python script
Thanks
Simo[n
From: Simon Peyton Jones
Sent: 04 March 2017 21:01
To: ghc-devs@haskell.org
Subject: Windows build broken again
The Windows build is broken again. Here's the tail of
I can't fix that (no windows) but I just broke all the builds with a -Werror
mistake and I can fix that one...
David FeuerWell-Typed, LLP
Original message From: Simon Peyton Jones via ghc-devs
Date: 2/28/17 7:07 PM (GMT-05:00) To:
ghc-devs@haskell.org Subject: Windows build
Please set your "time" submodule to the "ghc" branch. It should always
represent a stable release.
-- Ashley
On Wed, 2017-02-22 at 14:13 +, Phyx wrote:
> The package has been fixed already but the submodule hasn't been
> updated. For a quick fix just cd into libraries/time and checkout
> master
eryone is busy.
If someone felt able to step up to doing it, it'd be great.
Simon
| -Original Message-
| From: Kosyrev Serge [mailto:skosy...@ptsecurity.com]
| Sent: 22 February 2017 14:18
| To: Simon Peyton Jones
| Subject: Re: Windows build broken
|
| Simon,
|
| It pains
Tonight is fine – thank you!
From: Phyx [mailto:loneti...@gmail.com]
Sent: 22 February 2017 14:47
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Windows build broken
Head of ghc is broken not head of time. Ghc is currently set to 6e202ed while
head is 4eb06c0. So checking out
>
>
>
> *From:* Phyx [mailto:loneti...@gmail.com]
> *Sent:* 22 February 2017 14:14
> *To:* Simon Peyton Jones ; ghc-devs@haskell.org
> *Cc:* Ashley Yakeley
> *Subject:* Re: Windows build broken
>
>
>
> The package has been fixed already but the submodule hasn
: Ashley Yakeley
Subject: Re: Windows build broken
The package has been fixed already but the submodule hasn't been updated. For a
quick fix just cd into libraries/time and checkout master.
I was hesitant to push the new submodule since we hadn't branched yet for 8.2
On Wed, 22 Feb 2
The package has been fixed already but the submodule hasn't been updated.
For a quick fix just cd into libraries/time and checkout master.
I was hesitant to push the new submodule since we hadn't branched yet for
8.2
On Wed, 22 Feb 2017, 14:09 Simon Peyton Jones via ghc-devs, <
ghc-devs@haskell.o
Hi Simon,
Thanks for the update, I can reproduce a similar failure on the build bot and
one of my own machines. I’m looking into what might be causing it, I have
something I want to try but not
Sure yet it will solve it.
I don’t need more information atm as I can reproduce the race condition b
Simon Peyton Jones via ghc-devs writes:
> Windows build is broken in a new way.
> When I run validate I end up with sh.exe processes that consume a full CPU
> forever. See the process log below.
>
> Note that these are not GHC processes: they are shells! I have no conception
> of what they a
Simon Peyton Jones via ghc-devs writes:
> I'm getting irreproducible validate failures on Windows. Here's the output:
>
What commit are you on? The plugins issues I've seen before but I
believe the "Errno 17" issues we recently fixed.
Cheers,
- Ben
signature.asc
Description: PGP signature
_
Hi Simon,
For the tests what Ben’s email forgot to say was that the build system doesn’t
pick up on changes to Timeout.
So you’d need to nuke it to get the fixes for timing related things: rm -rf
testsuite/timeout/dist && rm -rf testsuite/timeout/install-inplace
And rerun the tests should fix
)
| -Original Message-
| From: Ben Gamari [mailto:b...@well-typed.com]
| Sent: 17 November 2016 15:24
| To: Simon Peyton Jones
| Subject: RE: windows build
|
| Simon Peyton Jones writes:
|
| > OK thank you.
| >
| > Meanwhile, what about the RTS error?
|
| A fix has been merged fo
Simon Peyton Jones via ghc-devs writes:
> Sigh. The Simon PJ Windows Buildbot reports
>
Yes, my apologies for this one. I'm currently in the process of getting
this one fixed in D2700. Unfortunately my own Windows machine is having
hardware issues so I progress has been a bit slow. I hope to hav
1 - 100 of 218 matches
Mail list logo
