Re: Problem with select(2) in single threaded runtime.
On 2014-11-04 at 07:42:11 +0100, Merijn Verstraaten wrote: Worse, it appears the maximum size of time_t is unrelated to the maximum value accepted by select(2). Fwiw, I found the following on http://pubs.opengroup.org/onlinepubs/009695399/functions/pselect.html , | Implementations may place limitations on the maximum timeout interval | supported. All implementations shall support a maximum timeout interval | of at least 31 days. If the timeout argument specifies a timeout | interval greater than the implementation-defined maximum value, the | maximum value shall be used as the actual timeout value. Implementations | may also place limitations on the granularity of timeout intervals. If | the requested timeout interval requires a finer granularity than the | implementation supports, the actual timeout interval shall be rounded up | to the next supported value. ` So I'm a bit surprised you get an EINVAL instead of the timeout being capped to the implementation's max supported value. Was the passed `timeval` structure valid? I.e. is the tv_usec value inside the [0,1e6-1] range? and was tv_sec=0 ? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Major commit to the constraint solver
That's great; I didn't realise that. How can I navigate to the build log. I went to https://travis-ci.org/ghc/ghc/builds clicked on Branch summary, found my branch, clicked on the link for 617 but it didn't show me the build log that you did. (It did have a red button saying 617 failed. Thanks | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Joachim Breitner | Sent: 03 November 2014 18:18 | To: ghc-devs@haskell.org | Subject: Re: Major commit to the constraint solver | | Hi, | | | Am Montag, den 03.11.2014, 17:28 + schrieb Simon Peyton Jones: | I’ve pushed branch wip/new-flatten-skolems-Oct14. (It has some | rebasing near the top.) | | It branches off master some a few days ago; i.e. it is almost | completely up to date. | | Can you try building it? I want to push it to HEAD, but would like | some independent validation first. | | Travis build branches automatically, and is already trying to build | it: | https://travis-ci.org/ghc/ghc/builds/39856856 | | It just finished, but it is not completely happy: | | Actual stderr output differs from expected: | --- /dev/null2014-11-03 17:30:32.067943898 + | +++ ./indexed-types/should_compile/PushedInAsGivens.comp.stderr 2014- | 11-03 18:11:53.225519481 + | @@ -0,0 +1,27 @@ | + | +PushedInAsGivens.hs:10:31: | +Couldn't match expected type ‘a1’ with actual type ‘a’ | + because type variable ‘a1’ would escape its scope | +This (rigid, skolem) type variable is bound by | + the type signature for foo :: (F Int ~ [a1]) = a1 - Int | + at PushedInAsGivens.hs:9:20-44 | +Relevant bindings include | + x :: a1 (bound at PushedInAsGivens.hs:10:17) | + foo :: a1 - Int (bound at PushedInAsGivens.hs:10:13) | + y :: a (bound at PushedInAsGivens.hs:9:5) | + bar :: a - (a, Int) (bound at PushedInAsGivens.hs:9:1) | +In the expression: y | +In the first argument of ‘length’, namely ‘[x, y]’ | + | +PushedInAsGivens.hs:11:15: | +Couldn't match expected type ‘[a]’ with actual type ‘F Int’ | +Relevant bindings include | + y :: a (bound at PushedInAsGivens.hs:9:5) | + bar :: a - (a, Int) (bound at PushedInAsGivens.hs:9:1) | +In the expression: foo y | +In the expression: (y, foo y) | +In the expression: | + let | +foo :: (F Int ~ [a]) = a - Int | +foo x = length [...] | + in (y, foo y) | = T2715(normal) 3281 of 4140 [0, 0, 0] | *** unexpected failure for PushedInAsGivens(normal) | | Actual stdout output differs from expected: | --- ./safeHaskell/check/pkg01/safePkg01.stdout 2014-11-03 | 17:30:57.327803827 + | +++ ./safeHaskell/check/pkg01/safePkg01.run.stdout 2014-11-03 | 18:12:11.178706914 + | @@ -29,17 +29,17 @@ | require own pkg trusted: True | | M_SafePkg6 | -package dependencies: array-0.5.0.1@array_HASH | +package dependencies: array-0.5.0.1 base-4.8.0.0* | trusted: trustworthy | require own pkg trusted: False | | M_SafePkg7 | -package dependencies: array-0.5.0.1@array_HASH | +package dependencies: array-0.5.0.1 base-4.8.0.0* | trusted: safe | require own pkg trusted: False | | M_SafePkg8 | -package dependencies: array-0.5.0.1@array_HASH | +package dependencies: array-0.5.0.1 base-4.8.0.0 | trusted: trustworthy | require own pkg trusted: False | | *** unexpected failure for safePkg01(normal) | | Is there more you want us to do besides what Travis just did for us? | | Greetings, | Joachim | | -- | Joachim “nomeata” Breitner |m...@joachim-breitner.de • http://www.joachim-breitner.de/ |Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F |Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Major commit to the constraint solver
Hi, Am Dienstag, den 04.11.2014, 08:44 + schrieb Simon Peyton Jones: That's great; I didn't realise that. How can I navigate to the build log. I went to https://travis-ci.org/ghc/ghc/builds clicked on Branch summary, found my branch, clicked on the link for 617 but it didn't show me the build log that you did. (It did have a red button saying 617 failed. We build everything twice, once with -DDEBUG and once without. Therefore, at the bottom of the page you were looking at (presumably https://travis-ci.org/ghc/ghc/builds/39856856), there are two links named 617.1 and 617.2. These take you to the build log, e.g. https://travis-ci.org/ghc/ghc/jobs/39856857 But: Travis tries to prettify the logs using plenty of JavaScript, this will easily bring your browser to its knees. So the trick is: After following the link, and while the page is loading, in the top right corner look for the square with the three horizontal lines. This link takes to to a text-only view of the logs, e.g. https://s3.amazonaws.com/archive.travis-ci.org/jobs/39856857/log.txt (The latter is mentioned on https://ghc.haskell.org/trac/ghc/wiki/Travis, but maybe not very visible. I could add a paragraph describing the steps to reach the logs.) By the way, you can usually find your branch on the Build History (https://travis-ci.org/ghc/ghc/builds) directly, if it has been built recently. The column „Commit“ mentions the branch its on. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: [GHC] #9358: Improve flag description in the user guide
|Jan, you said you'd be willing to do this updating before 7.10 | Yes, that's the plan. The question is do I have to make it before the | mid-November feature freeze? | Austin, what's your opinion? Great. Sooner the better. Post freeze Austin has to do merging work, but not impossible. |It's more than a simple on/off thing because the order matters. | Hmm in which cases does it matter? Can you give an example? Well, for example, as you'll see in SimplCore, the -O1 pipeline runs the float-out twice. So just saying float-out is on doesn't tell you all you might want to know. It might be worth translating SimplCore.getCoreToDo into English and putting it in the manual as a rough idea. But maybe that is too much, I'm not sure. (eg it would get out of date) Perhaps just listing what is on by default in -O1 and -O2 would get a long way. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [GHC] #9358: Improve flag description in the user guide
Post freeze Austin has to do merging work Right. I'll do my best to finish this ASAP. Jan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Major commit to the constraint solver
Aha. Yes, I did click on one of those links, and my browser was fine: but the displayed log was simply truncated at 10,000 lines, which removed all the interesting stuff. Moving the tip to the top, just under What does it do?, and giving a bit more navigation info, would be a good plan. thanks Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Joachim Breitner | Sent: 04 November 2014 08:55 | To: ghc-devs@haskell.org | Subject: Re: Major commit to the constraint solver | | Hi, | | | Am Dienstag, den 04.11.2014, 08:44 + schrieb Simon Peyton Jones: | That's great; I didn't realise that. | | How can I navigate to the build log. I went to | https://travis-ci.org/ghc/ghc/builds | clicked on Branch summary, found my branch, clicked on the link | for | 617 but it didn't show me the build log that you did. (It did | have | a red button saying 617 failed. | | We build everything twice, once with -DDEBUG and once without. | Therefore, at the bottom of the page you were looking at (presumably | https://travis-ci.org/ghc/ghc/builds/39856856), | there are two links named 617.1 and 617.2. These take you to the build | log, e.g. https://travis-ci.org/ghc/ghc/jobs/39856857 | | But: Travis tries to prettify the logs using plenty of JavaScript, | this will easily bring your browser to its knees. So the trick is: | After following the link, and while the page is loading, in the top | right corner look for the square with the three horizontal lines. This | link takes to to a text-only view of the logs, e.g. | https://s3.amazonaws.com/archive.travis-ci.org/jobs/39856857/log.txt | | (The latter is mentioned on | https://ghc.haskell.org/trac/ghc/wiki/Travis, but maybe not very | visible. I could add a paragraph describing the steps to reach the | logs.) | | By the way, you can usually find your branch on the Build History | (https://travis-ci.org/ghc/ghc/builds) directly, if it has been built | recently. The column „Commit“ mentions the branch its on. | | Greetings, | Joachim | | | | -- | Joachim “nomeata” Breitner |m...@joachim-breitner.de • http://www.joachim-breitner.de/ |Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F |Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Resurrecting ticky code
We don’t have vectored returns any more, so you can drop that one. For magic eight there are some native-wordsize constants defined already. E.g. see how PrelRules.wordSizeInBits is computed. Thanks to Jan for helping SImon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Mateusz Lenik | Sent: 03 November 2014 17:19 | To: ghc-devs@haskell.org | Subject: Resurrecting ticky code | | Hi *, | | Recently I started working on resurrecting ticky code[1] and got to | the point where I can compile and run bumpHistogram as well as | accompanying code in RTS. | | Work in progress version can be found at [2], but there are few things | remaining to get it working: | | * missing calls to tickyReturnNewCon, tickyUnboxedTupleReturn and |tickyVectoredReturn need to be added. Unfortunately I'm not familiar | with the |code enough to find the right place to insert them. | | * magic eight needs to be replaced by a constant both Haskell and C | files. |Preprocessor macro seems to be the simplest choice here, however I | don't find |it the cleanest way to do it. | | I would be very grateful if someone could take a look and point me | into the right direction. | | | Best, | Mateusz | | 1: https://ghc.haskell.org/trac/ghc/ticket/8308 | 2: https://github.com/mlen/ghc/compare/ticky | | -- | Mateusz Lenik | GPG: B865 E86A D36C 11A5 C1F8 C1D9 AAD4 CEC9 6B94 92C4 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Major commit to the constraint solver
Hi, Am Dienstag, den 04.11.2014, 09:41 + schrieb Simon Peyton Jones: Moving the tip to the top, just under What does it do?, and giving a bit more navigation info, would be a good plan. done: https://ghc.haskell.org/trac/ghc/wiki/Travis#Whatdoesitdo Writing good Wiki pages is much harder than writing compiler code... :-) Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Concrete syntax for pattern synonym type signatures
Here is one principle: for GADTs, the pattern type signature should look like the GADT data constructor. So if we have data S a where S1 :: p - q - S (p,q) S2 :: ...blah... pattern P x y = S1 x y then surely the signature for P should be P :: p - q - S (p,q) The same goes for constraints in the constructor's type. Thus, using your example: | data T a b where | MkT :: (Eq a, Ord b, Show c) = a - (b, b) - c - T a b If I say pattern P x y z = MkT x y z then the signature for P should be identical to that of MkT. --- It gets a bit more interesting when you have nested patterns that instantiate the type. For example, with the same type T, consider pattern P x y z = MkT (x,y) (False,True) [z] the right signature for P must presumably be P :: (Eq (p,q), Show [r]) = p - q - r - T (p,q) Bool We don't need to distinguish 'r' as existential, any more than we do in the original signature for MkT. Note that we must retain the instantiated but un-simplified constraints (Eq (p,b), Show [r]), because when pattern-matching against P, those are the constraints brought into scope. - The general story, for both data constructors and pattern synonyms, is that if the type is D :: forall abc. (C1, C2...) = blah then the constraints (C1, C2...) are - *required* when using D in an expression, - *provided* (i.e. brought into scope) pattern matching against D. The tricky case comes when the pattern synonym involves some constraints that are *required* during *pattern-matching*. A simple example is pattern P1 x = (8, x) Here we *require* a (Num a) dictionary *both* when using P1 in an expression (to build the value 8), *and* when using P in pattern matching (to build a value 8 to compare with the value being matched). I'll call the constraints that are *required* when matching the match-required constraints. The same happens for view patterns: gr :: Ord a = a - a - Maybe a gr v x | x v = Just v | otherwise = Nothing pattern P2 x = (gr 8 - Just x) Here, (Ord a, Num a) are match-required. (P2 is uni-directional, so we can't use P2 in expressions.) We can't give a signature to P1 like this P1 :: forall a. Num a = b - (a,b) because that looks as if (Num a) would be *provided* when pattern matching (see general story above), whereas actually it is required. This is the nub of the problem Gergo is presenting us with. Notice that P1 is bidirectional, and can be used in expressions, where again we *require* (Num a), so P1's term type really is something like (Num a) = b - (a,b). The more I think about this, the more I think we'll just have to bite the bullet and adapt the syntax for constraints in pattern types, to distinguish the match-required and match-provided parts. Suppose we let pattern signatures look like this: pattern P :: forall tvs. (match-provided ; match-required) = tau The ; match-required part is optional, and the match-provided part might be empty. So P1 and P2 would look like this: pattern P1 :: forall a. (; Num a) = b - (a,b) pattern P2 :: forall a. (; Num a, Ord a) = a - a Because the match-required part is optional (and relatively rare) the common case looks just like an ordinary data constructor. None of this addresses the bidirectional/unidirectional question, but that's a pretty separate matter. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 03 November 2014 10:13 | To: GHC Devs | Subject: RFC: Concrete syntax for pattern synonym type signatures | | Background | -- | | As explained on | https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Staticsemantics | the type of a pattern synonym can be fully described with the | following pieces of information: | | * If the pattern synonym is bidirectional | * Universially-bound type variables, and required constraints on them | * The type of the pattern itself, closed over the universially-bound | type variables | * Existentially-bound type variables, and the constraints provided by | them | * The types of the arguments, closed over the universially and | existentially bound type variables | | Here's an example showing all of these axes in action: | | data T a b where | MkT :: (Eq a, Ord b, Show c) = a - (b, b) - c - T a b | | pattern P x y = MkT 5 (y, True) x | | In this case: | | * The name of the pattern synonym is `P` | * The pattern synonym is bidirectional | * The universially-bound tyvars/required constraints are `forall a. | Num a` | * The type of the pattern is `T a Bool` | * The existentially-bound tyvars/provided constraints are | `forall c. (Eq a, Ord Bool, Show c)` | * The type of the arguments are `c` and `Bool`. | | The problem, then, is finding a concrete syntax that captures
Can't install packages with my inplace compiler
When I say cabal install --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2 I get this ghc-stage2: ghc no longer supports single-file style package databases (dist/package.conf.inplace) use 'ghc-pkg init' to create the database with the correct format. Now, this is an old build tree, and I could blow it away entirely, but maybe there is something else going on. What should I do? Thanks (all on Linux) Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Can't install packages with my inplace compiler
Hello Simon, On 2014-11-04 at 11:55:48 +0100, Simon Peyton Jones wrote: When I say cabal install --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2 I get this ghc-stage2: ghc no longer supports single-file style package databases (dist/package.conf.inplace) use 'ghc-pkg init' to create the database with the correct format. Now, this is an old build tree, and I could blow it away entirely, but maybe there is something else going on. What should I do? What does `cabal --version` say? If it doesn't say something like $ cabal --version cabal-install version 1.21.1.0 using version 1.21.1.0 of the Cabal library you probably need a newer one (in which case you should build the `cabal` binary from Git, and to make life easier compile `Cabal` and `cabal-install` with GHC 7.8.x rather than GHC HEAD) Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Can't install packages with my inplace compiler
It says simonpj@cam-05-unx:~/tmp/singletons-1.0$ cabal --version cabal-install version 1.21.0.0 using version 1.21.0.0 of the Cabal library Oddly if I try cabal update; cabal install cabal-install it says: Resolving dependencies... Downloading Cabal-1.20.0.2... so it looks as if it's about to install an *older* version than the one I have already! What now? Thanks SImon | -Original Message- | From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com] | Sent: 04 November 2014 11:20 | To: Simon Peyton Jones | Cc: GHC Devs | Subject: Re: Can't install packages with my inplace compiler | | Hello Simon, | | On 2014-11-04 at 11:55:48 +0100, Simon Peyton Jones wrote: | When I say | | cabal install | --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2 | | I get this | | ghc-stage2: ghc no longer supports single-file style package | databases | (dist/package.conf.inplace) use 'ghc-pkg init' to create the | database | with the correct format. | | Now, this is an old build tree, and I could blow it away entirely, | but | maybe there is something else going on. What should I do? | | What does `cabal --version` say? If it doesn't say something like | |$ cabal --version |cabal-install version 1.21.1.0 |using version 1.21.1.0 of the Cabal library | | you probably need a newer one (in which case you should build the | `cabal` binary from Git, and to make life easier compile `Cabal` and | `cabal-install` with GHC 7.8.x rather than GHC HEAD) | | Cheers, |hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
I had a problem https://github.com/Alexpux/MSYS2-packages/issues/116 with
building msys2-runtime, but debug bash installed successfully.
I uncommented the hook to invoke qtcreator.exe on crashing (your .bat file
needs escaping, puill request pending...), but I'm not quite sure how to
check that it works. I tried building this crasher program with
/usr/bin/gcc:
#include stdio.h
int main() {
char *s = 0;
printf(hi\n);
printf(%s\n, s);
printf(bye\n);
return 0;
}
But running it just prints hi, no indications of a crash or anything,
regardless of the value of the MSYS variable:
$ /usr/bin/gcc -o crash crash.c
$ ./crash.exe
hi
$ echo $?
0
On Tue, Nov 4, 2014 at 1:56 AM, Ray Donnelly mingw.andr...@gmail.com
wrote:
On Tue, Nov 4, 2014 at 12:45 AM, Gintautas Miliauskas
gintautas.miliaus...@gmail.com wrote:
I have a suspicion that the segmentation faults are related to fork
errors,
which appear in logs from time to time. After a few builds fork() errors
become very frequent, and segfaults seem to occur more often. I just ran
the
build (validate.sh) in a loop, and after a while got a bunch of
segfaults in
Makefile rules as basic as rm invocations in the initial make clean,
e.g.:
rm -rf driver/split/dist
driver/split/ghc.mk:19: recipe for target 'clean_driver/split_dist'
failed
make[1]: *** [clean_driver/split_dist] Segmentation fault
Makefile:94: recipe for target 'maintainer-clean' failed
Closing and reopening the msys2 console seems to help - for some time.
Interesting .. how much process spawning do you think happens? On
MSYS2 we run massive builds (bootstrapping builds of GCC for 2 arches
for example), but MSYS2 shares a memory map, so heap corruption could
happen and cause later problems. My recommendation about building
debug bash and msys2-runtime and set
MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|process-id
stands all the more then. You may need to setup path mappings in Qt C
to map from MSYS2 paths to Windows paths. You need to do this as QtC
needs to use the native GDB instead of the MSYS2 one so that QtC and
GDB are in the same pathing namespace.
There may be a way of building msys2-runtime to check for memory
overruns too, perhaps just building it with the 'debug' option will
enable that, I'm not sure ..
On Tue, Nov 4, 2014 at 1:30 AM, Ray Donnelly mingw.andr...@gmail.com
wrote:
On Mon, Nov 3, 2014 at 11:07 PM, Gintautas Miliauskas
gintautas.miliaus...@gmail.com wrote:
+ghc-devs
Hi Ray,
thanks for the feedback. ghc-stage1 is a native application, it is
built
using a host ghc and a mingw gcc bundled with the ghc distribution (in
order
to keep Windows builds more predictable). The thing is, the same
builds
(using make) that were stable on cygwin seem to be crashing on msys2,
even
though the (bundled) gcc used for the build is the same. It could be
that
msys2 is triggering a bug in ghc somehow, but it could be something
going on
in msys2 itself.
The tricky part is that the crashes are rare, one in thousands of ghc
invocations within a make build, and I'm having trouble pinning one
down
to
investigate. I'll try some basic tracing first, but ideas for
something
more
sophisticated would be very helpful.
Ah, ok. I skim read your initial email and applied totally incorrect
weighting to the not very hard to reproduce bit, apologies!
It *should* be possible to setup post-mortem debugging using either Qt
Creator (Tools-Options-Debugger, tick Use Qt Creator for
post-mortem debugging) or Dr. Mingw
(https://github.com/jrfonseca/drmingw). I briefly tested both options:
Qt Creator: It seems there's a bug in its handling of the
-wincrashevent command line which I've just added a note about to the
MINGW-packages todo list since I'd find this feature more than very
useful:
https://github.com/Alexpux/MINGW-packages/blob/master/TODO.md
Dr Mingw: Launching the crashing executable from Windows Explorer, it
launches it and gives me useful information.
Unfortunately, regardless of the debugger used, when invoking the
crashing executable from the mintty commandline, something inhibits
all post mortem debugging. I will ask the mingw-w64 guys if they know
what this is. I guess intrusive dialogs would be annoying, but I'd
like an env. var override for that I think.
There is another possibility, and that's that bash is crashing, which
is an MSYS2 program. We do have a way of hooking into post-mortem
debugging there since Cygwin provided a way and we improved it. If you
check your msys2_shell.bat you'll see:
rem set
MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|process-id
If you remove the rem and make sure the path is correct (it may have
rotted some since I last used it) then hopefully you'll get something
useful. To be really useful, you should rebuild two packages,
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 13:07, Gintautas Miliauskas wrote:
But running it just prints hi, no indications of a crash or anything,
regardless of the value of the MSYS variable:
Either the compiler, or C library is too smart for this. I'd guess your
compiler is working with undefined behavior optimizations, because with my
compiler, I get both hi and bye (or not, when I pass -Og). Try this code:
#include stdio.h
int main() {
printf(hi\n);
((void(*)())(0))();
printf(bye\n);
return 0;
}
--
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-notes
I'm seeing all these build failures, but it builds fine for me. Simon | -Original Message- | From: nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.org] | Sent: 04 November 2014 12:28 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening- | notes | | Harbormaster failed to build B1665: rGHC652a5efe774a: Add flattening- | notes! | | USERS |simonpj (Author) |GHC - Type checker/inferencer (Auditor) | | COMMIT |https://phabricator.haskell.org/rGHC652a5efe774a | | To: simonpj, GHC - Type checker/inferencer ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 1:30, Ray Donnelly wrote: Finally, can anyone else confirm the problem? I'm sorry if I missed it, but I can't find what source version you're using, Gintautas. Release/trunk? -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
I'm working on ghc trunk. You were indeed right, the compiler was probably optimizing out my code. The suggested crasher code works, and qtcreator gets invoked, although I did not manage to set up gdb yet. I think I have an idea of what's going wrong here. hvr@ was right in pointing out that we need to be careful with the PATH. It seems that the bundled gcc is picking up the system-wide DLLs, and bad things happen because of version incompatibilities. That does not explain why rm is crashing, but maybe that's fallout from cross-process damage. I will do some more testing. If this is indeed the cause, then hopefully debugging will not be needed anyway. On Tue, Nov 4, 2014 at 1:57 PM, David Macek david.mace...@gmail.com wrote: On 4. 11. 2014 1:30, Ray Donnelly wrote: Finally, can anyone else confirm the problem? I'm sorry if I missed it, but I can't find what source version you're using, Gintautas. Release/trunk? -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-notes
current master builds fine, but it doesn't validate https://phabricator.haskell.org/harbormaster/build/1678/. The error is: perf/compiler T5631 [stat not good enough] You can see the validate status of all commits on this page: https://phabricator.haskell.org/diffusion/GHC/history/ On Tue, Nov 4, 2014 at 1:39 PM, Simon Peyton Jones simo...@microsoft.com wrote: I'm seeing all these build failures, but it builds fine for me. Simon | -Original Message- | From: nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.org] | Sent: 04 November 2014 12:28 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening- | notes | | Harbormaster failed to build B1665: rGHC652a5efe774a: Add flattening- | notes! | | USERS |simonpj (Author) |GHC - Type checker/inferencer (Auditor) | | COMMIT |https://phabricator.haskell.org/rGHC652a5efe774a | | To: simonpj, GHC - Type checker/inferencer ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-notes
Ah, thanks. I think the commit I was looking at was *before* the major fixup. Sorry Looking one at the end, I do see just the one failure you mention Unexpected stat failures: perf/compiler T5631 [stat not good enough] (normal) But I can’t persuade Phab to show me the build log, and it doesn’t happen for me. So I am stuck once more. Simon From: Thomas Miedema [mailto:thomasmied...@gmail.com] Sent: 04 November 2014 13:40 To: Simon Peyton Jones Cc: GHC Devs Subject: Re: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-notes current master builds fine, but it doesn't validatehttps://phabricator.haskell.org/harbormaster/build/1678/. The error is: perf/compiler T5631 [stat not good enough] You can see the validate status of all commits on this page: https://phabricator.haskell.org/diffusion/GHC/history/ On Tue, Nov 4, 2014 at 1:39 PM, Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: I'm seeing all these build failures, but it builds fine for me. Simon | -Original Message- | From: nore...@phabricator.haskell.orgmailto:nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.orgmailto:nore...@phabricator.haskell.org] | Sent: 04 November 2014 12:28 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening- | notes | | Harbormaster failed to build B1665: rGHC652a5efe774a: Add flattening- | notes! | | USERS |simonpj (Author) |GHC - Type checker/inferencer (Auditor) | | COMMIT |https://phabricator.haskell.org/rGHC652a5efe774a | | To: simonpj, GHC - Type checker/inferencer ___ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 14:14, Gintautas Miliauskas wrote: I'm working on ghc trunk. I'm trying to reproduce your errors, but I failed at ./boot with: Booting . 'autoreconf' is not recognized as an internal or external command, operable program or batch file. Running autoreconf failed with exitcode 256 at ./boot line 163, PKGS line 12. It seems that /mingw64/bin/perl's system(autoreconf) fails to execute because it's passing the command line to cmd, not bash (/usr/bin/autoreconf is a script). Gintautas, do you have mingw-w64-x86_64-perl installed? Can we do something about this, or is boot going to work only in pure msys2 shell? -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Phab and I differ
I built and validated this commit just fine. Phab says Unexpected failures: ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) rts linker_unload [bad exit code] (normal) stranal/should_compile str001 [exit code non-0] (optasm) stranal/should_compile str002 [exit code non-0] (optasm) stranal/should_compile test [exit code non-0] (optasm) but none of them fail for me. I don't know how to see enough of Phab's log to see what it thinks when wrong. (it just shows me 25 lines; clicking on unlimited still only shows 30 lines) | -Original Message- | From: nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.org] | Sent: 04 November 2014 15:32 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC6a1c05f01429: A little | refactoring of HsSplice and friends | | Harbormaster failed to build B1678: rGHC6a1c05f01429: A little | refactoring of HsSplice and friends! | | USERS |simonpj (Author) |GHC - Type checker/inferencer (Auditor) |GHC - Core/System FC (Auditor) |GHC - Renamer (Auditor) |GHC - HsSyn/Parser (Auditor) | | COMMIT |https://phabricator.haskell.org/rGHC6a1c05f01429 | | To: simonpj, GHC - Type checker/inferencer, GHC - Core/System FC, GHC | - Renamer, GHC - HsSyn/Parser ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
I think I have an idea of what's going wrong here. hvr@ was right in pointing out that we need to be careful with the PATH. It seems that the bundled gcc is picking up the system-wide DLLs, and bad things happen because of version incompatibilities. That does not explain why rm is crashing, but maybe that's fallout from cross-process damage. I will do some more testing. If this is indeed the cause, then hopefully debugging will not be needed anyway. Update: even after setting PATH to have the embedded gcc path in the first position to make sure that the right DLLs are, I still got a few segfaults, so this is probably not it. -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
I'm using /usr/bin/perl, and don't have the mingw perl installed. On Tue, Nov 4, 2014 at 4:10 PM, David Macek david.mace...@gmail.com wrote: On 4. 11. 2014 14:14, Gintautas Miliauskas wrote: I'm working on ghc trunk. I'm trying to reproduce your errors, but I failed at ./boot with: Booting . 'autoreconf' is not recognized as an internal or external command, operable program or batch file. Running autoreconf failed with exitcode 256 at ./boot line 163, PKGS line 12. It seems that /mingw64/bin/perl's system(autoreconf) fails to execute because it's passing the command line to cmd, not bash (/usr/bin/autoreconf is a script). Gintautas, do you have mingw-w64-x86_64-perl installed? Can we do something about this, or is boot going to work only in pure msys2 shell? -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Phab and I differ
On 2014-11-04 at 16:38:52 +0100, Simon Peyton Jones wrote: I built and validated this commit just fine. Phab says Unexpected failures: ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) rts linker_unload [bad exit code] (normal) stranal/should_compile str001 [exit code non-0] (optasm) stranal/should_compile str002 [exit code non-0] (optasm) stranal/should_compile test [exit code non-0] (optasm) but none of them fail for me. I don't know how to see enough of Phab's log to see what it thinks when wrong. (it just shows me 25 lines; clicking on unlimited still only shows 30 lines) It seems to me that compiling T3064 may be the culprit, as that seems to eat up an humongous amount of RAM... ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Problem with select(2) in single threaded runtime.
Hi Herbert,
On 4 Nov 2014, at 0:34, Herbert Valerio Riedel hvrie...@gmail.com wrote:
Was the passed `timeval` structure valid? I.e. is the tv_usec value inside
the [0,1e6-1] range? and was tv_sec=0 ?
The simple test I wrote is:
#include stdio.h
#include errno.h
#include string.h
#include limits.h
#include sys/select.h
#include sys/time.h
int main(int argc, char **argv)
{
fd_set set;
FD_ZERO(set);
struct timeval tv;
tv.tv_sec = INT_MAX;
tv.tv_usec = 0;
FD_SET(0, set);
int ret = select(1, set, set, set, tv);
printf(Result %d: %s\n, ret, strerror(errno));
printf(time_t: %lu suseconds_t: %lu\n, sizeof(time_t),
sizeof(suseconds_t));
return 0;
}
This exits with EINVAL for me on OSX, if I replace INT_MAX with 1000, it runs
just fine. The man page on OSX mentions EINVAL for values that exceed the
maximum timeout, so it looks like OSX is not following the spec, then...
Cheers,
Merijn
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Problem with select(2) in single threaded runtime.
On 2014-11-04 at 18:18:44 +0100, Merijn Verstraaten wrote: [...] This exits with EINVAL for me on OSX, if I replace INT_MAX with 1000, it runs just fine. The man page on OSX mentions EINVAL for values that exceed the maximum timeout, so it looks like OSX is not following the spec, then... Btw, I also stumbled over these ancient bug-reports: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=18909 http://gnats.netbsd.org/11287 So it seems that BSD-ish systems have (or had?) this arbitrary 1e8 second limit in combination with the questionable EINVAL response which seems in conflict with the POSIX specification. I'm wondering if there's already an Autoconf test somewhere we could steal for detecting this peculiarity of select() on BSD systems... Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Phab and I differ
Is it possible to get the full build logs on Phab? I just had a testsuite (framework) failure, but I can't see what test caused it! (https://phabricator.haskell.org/harbormaster/build/1686/) Thanks, Richard On Nov 4, 2014, at 10:38 AM, Simon Peyton Jones simo...@microsoft.com wrote: I built and validated this commit just fine. Phab says Unexpected failures: ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) rts linker_unload [bad exit code] (normal) stranal/should_compile str001 [exit code non-0] (optasm) stranal/should_compile str002 [exit code non-0] (optasm) stranal/should_compile test [exit code non-0] (optasm) but none of them fail for me. I don't know how to see enough of Phab's log to see what it thinks when wrong. (it just shows me 25 lines; clicking on unlimited still only shows 30 lines) | -Original Message- | From: nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.org] | Sent: 04 November 2014 15:32 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC6a1c05f01429: A little | refactoring of HsSplice and friends | | Harbormaster failed to build B1678: rGHC6a1c05f01429: A little | refactoring of HsSplice and friends! | | USERS |simonpj (Author) |GHC - Type checker/inferencer (Auditor) |GHC - Core/System FC (Auditor) |GHC - Renamer (Auditor) |GHC - HsSyn/Parser (Auditor) | | COMMIT |https://phabricator.haskell.org/rGHC6a1c05f01429 | | To: simonpj, GHC - Type checker/inferencer, GHC - Core/System FC, GHC | - Renamer, GHC - HsSyn/Parser ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Building head with head
Hi, today I tried to build head with head on os x. The result was: Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ... touch utils/ghc-cabal/dist/build/tmp/ghc-cabal cp utils/ghc-cabal/dist/build/tmp/ghc-cabal inplace/bin/ghc-cabal inplace/bin/ghc-cabal configure libraries/binary dist-boot --with-ghc=/usr/local/bin/ghc --with-ghc-pkg=/usr/local/bin/ghc-pkg --package-db=/Users/angerman/code/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS= -m64 -fno-stack-protector --configure-option=LDFLAGS= -m64 --configure-option=CPPFLAGS= -m64 --gcc-options= -m64 -fno-stack-protector -m64 --constraint binary == 0.7.1.0 --constraint Cabal == 1.21.1.0 --constraint hpc == 0.6.0.2 --constraint bin-package-db == 0.0.0.0 --constraint hoopl == 3.10.0.2 --constraint transformers == 0.4.1.0 --constraint terminfo == 0.4.0.0 --with-gcc=/usr/bin/gcc --configure-option=--with-cc=/usr/bin/gcc --with-ar=/usr/bin/ar --with-alex=/Users/angerman/.cabal/bin/alex --with-happy=/Users/angerman/.cabal/bin/happy inplace/bin/ghc-cabal configure utils/hsc2hs dist --with-ghc=/usr/local/bin/ghc --with-ghc-pkg=/usr/local/bin/ghc-pkg --package-db=/Users/angerman/code/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --disable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS= -m64 -fno-stack-protector--configure-option=LDFLAGS= -m64 --configure-option=CPPFLAGS= -m64 --gcc-options= -m64 -fno-stack-protector -m64 --constraint binary == 0.7.1.0 --constraint Cabal == 1.21.1.0 --constraint hpc == 0.6.0.2 --constraint bin-package-db == 0.0.0.0 --constraint hoopl == 3.10.0.2 --constraint transformers == 0.4.1.0 --constraint terminfo == 0.4.0.0 --with-gcc=/usr/bin/gcc --configure-option=--with-cc=/usr/bin/gcc --with-ar=/usr/bin/ar --with-alex=/Users/angerman/.cabal/bin/alex --with-happy=/Users/angerman/.cabal/bin/happy Configuring hsc2hs-0.67... Configuring binary-0.7.1.0... ghc-cabal: '/usr/local/bin/ghc-pkg' exited with an error: ghc-pkg: ghc no longer supports single-file style package databases (/Users/angerman/code/ghc/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. make[1]: *** [utils/hsc2hs/dist/package-data.mk] Error 1 make[1]: *** Waiting for unfinished jobs ghc-cabal: '/usr/local/bin/ghc-pkg' exited with an error: ghc-pkg: ghc no longer supports single-file style package databases (/Users/angerman/code/ghc/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. make[1]: *** [libraries/binary/dist-boot/package-data.mk] Error 1 Does anyone know what needs to be done to make this work? Best, Moritz ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
Hi. I just built GHC from master (1c35f9f1cb7a293da85d649904ce731a65824cfe) in my somewhat outdated MSYS2. I followed the wiki page with a few exceptions. - I cleared my PATH before running the shell (I left only Windows and System32) - my installation is not up-to-date - I do not have msys2 libtool, automake nor binutils; if the build used any of those, they came from mingw64 or from the host ghc - I had to run boot in pure msys2 shell, because mingw64 perl caused it to fail I saw no segfaults, but I may have missed them. I did not get a ghc.exe, but that may be correct behavior for all I know. My simple test program compiled and ran fine. I saw a lot of warnings during ghc's build though: - checking for DocBook DTD... I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd - something with not finding any implementation of a module out of [ xxx.dylib, xxx, ... ], I think it was in cabal builds - could not find link destionations for: xxx I hope it helps somehow. Maybe your issues come from mixing msys2 and mingw toolchain after all. -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Can't install packages with my inplace compiler
Yeah, that's too old; and there's not been a release of a Cabal which is new enough to do what you want. Try: git clone https://github.com/haskell/cabal cd cabal/Cabal cabal install cd ../cabal-install cabal install Edward Excerpts from Simon Peyton Jones's message of 2014-11-04 03:59:57 -0800: It says simonpj@cam-05-unx:~/tmp/singletons-1.0$ cabal --version cabal-install version 1.21.0.0 using version 1.21.0.0 of the Cabal library Oddly if I try cabal update; cabal install cabal-install it says: Resolving dependencies... Downloading Cabal-1.20.0.2... so it looks as if it's about to install an *older* version than the one I have already! What now? Thanks SImon | -Original Message- | From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com] | Sent: 04 November 2014 11:20 | To: Simon Peyton Jones | Cc: GHC Devs | Subject: Re: Can't install packages with my inplace compiler | | Hello Simon, | | On 2014-11-04 at 11:55:48 +0100, Simon Peyton Jones wrote: | When I say | | cabal install | --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2 | | I get this | | ghc-stage2: ghc no longer supports single-file style package | databases | (dist/package.conf.inplace) use 'ghc-pkg init' to create the | database | with the correct format. | | Now, this is an old build tree, and I could blow it away entirely, | but | maybe there is something else going on. What should I do? | | What does `cabal --version` say? If it doesn't say something like | |$ cabal --version |cabal-install version 1.21.1.0 |using version 1.21.1.0 of the Cabal library | | you probably need a newer one (in which case you should build the | `cabal` binary from Git, and to make life easier compile `Cabal` and | `cabal-install` with GHC 7.8.x rather than GHC HEAD) | | Cheers, |hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Problem with select(2) in single threaded runtime.
On 4 Nov 2014, at 9:32, Herbert Valerio Riedel hvrie...@gmail.com wrote: I'm wondering if there's already an Autoconf test somewhere we could steal for detecting this peculiarity of select() on BSD systems... I googled around for ways to detect this, but I haven't found anything so far. I've been scarred by autotools, to if someone less horrified knows how to do this properly, please chime in :) Cheers, Merijn ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Can't install packages with my inplace compiler
| Yeah, that's too old; and there's not been a release of a Cabal | which is new enough to do what you want. Wow! I'm doing the most basic thing: using Cabal to install a package with a specified GHC. I'll try what you suggest. Duncan: would a release be a good plan? Simon | | Try: | | git clone https://github.com/haskell/cabal | cd cabal/Cabal | cabal install | cd ../cabal-install | cabal install | | Edward | | Excerpts from Simon Peyton Jones's message of 2014-11-04 03:59:57 -0800: | It says | | simonpj@cam-05-unx:~/tmp/singletons-1.0$ cabal --version | cabal-install version 1.21.0.0 | using version 1.21.0.0 of the Cabal library | | | Oddly if I try cabal update; cabal install cabal-install it says: | Resolving dependencies... | Downloading Cabal-1.20.0.2... | | so it looks as if it's about to install an *older* version than the one | I have already! | | What now? | | Thanks | | SImon | | | -Original Message- | | From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com] | | Sent: 04 November 2014 11:20 | | To: Simon Peyton Jones | | Cc: GHC Devs | | Subject: Re: Can't install packages with my inplace compiler | | | | Hello Simon, | | | | On 2014-11-04 at 11:55:48 +0100, Simon Peyton Jones wrote: | | When I say | | | | cabal install | | --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2 | | | | I get this | | | | ghc-stage2: ghc no longer supports single-file style package | | databases | | (dist/package.conf.inplace) use 'ghc-pkg init' to create the | | database | | with the correct format. | | | | Now, this is an old build tree, and I could blow it away entirely, | | but | | maybe there is something else going on. What should I do? | | | | What does `cabal --version` say? If it doesn't say something like | | | |$ cabal --version | |cabal-install version 1.21.1.0 | |using version 1.21.1.0 of the Cabal library | | | | you probably need a newer one (in which case you should build the | | `cabal` binary from Git, and to make life easier compile `Cabal` and | | `cabal-install` with GHC 7.8.x rather than GHC HEAD) | | | | Cheers, | |hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: [commit: ghc] wip/rae: Fix #1476 by making splice patterns work. (eb257c3)
| Unfortunately, splice patterns in brackets still do not work | because we don't run splices in brackets. Without running a pattern | splice, we can't know what variables it binds, so we're stuck. Not just don't but can't!! This isn't a compiler deficiency: the code is not there to run! Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Automating GHC build for Windows
2014-11-03 1:24 GMT+01:00 Gintautas Miliauskas gintautas.miliaus...@gmail.com: Without knowing much about the surrounding code, I would try two things here. [..] 2. Since the error is completely deterministic, you could try freezing evaluation right before the crash ([..] just adding a time delay / console read on the code), and then using a utility app to check which process is keeping the file open, whether it's the same process or something else. I tried this approach and it seems I do not even need to check the environment further: when ghc-cabal.exe stops in writeFileAtomic (waiting for a keypress) and displays the parameters it was called with, it says that the same dist-boot\setup-config.tmp file is about to renamed (to dist-boot\setup-config) twice after each other (perhaps from different threads?)! Note that I do not experience the same when the writeFileAtomic function is called for other files. Well, I guess this can easily cause the problems I have seen so far... I can also imagine that this bug is present on other systems as well, but does not cause any harm (for some reason) so it is basically invisible. However, first it would be nice if somebody else could confirm that it is indeed the case. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
Hi David, ghc should appear as inplace/bin/ghc-stage2.exe after a successful build. The warnings are expected. Did you run make with parallelism? I don't have a smoking gun, but the build seems to be somewhat stable with -j1, while it crashes a lot of the time with -j5 (I have a 4-core CPU). I have only tried a couple of runs with -j1 (takes a while...), so I can't say for sure that non-parallel builds are stable, but 2/2 runs succeeded. Another data point: I ran the validate script in a loop and stored the logs, and most crashes seem to be in rts/, but not all of them. Not sure why. $ grep Segmentation *.log 1.log:make[1]: *** [libraries/base/dist-install/build/Text/Show/Functions.o] Segmentation fault 10.log:make[1]: *** [rts/dist/build/Hpc.o] Segmentation fault 11.log:make[1]: *** [rts/dist/build/RtsFlags.thr_l_o] Segmentation fault 12.log:make[1]: *** [rts/dist/build/sm/GCAux.o] Segmentation fault 13.log:make[1]: *** [rts/dist/build/win32/GetEnv.thr_l_o] Segmentation fault 14.log:make[1]: *** [rts/dist/build/sm/Scav.l_o] Segmentation fault 15.log:make[1]: *** [compiler/stage1/build/RegAlloc/Linear/State.o] Segmentation fault 18.log:make[1]: *** [libraries/filepath/dist-install/build/.depend-v.haskell] Segmentation fault 19.log:make[1]: *** [libraries/base/dist-install/build/.depend-v.haskell] Segmentation fault 4.log:make[1]: *** [rts/dist/build/RtsDllMain.o] Segmentation fault 5.log:make[1]: *** [rts/dist/build/sm/Evac_thr.thr_o] Segmentation fault 6.log:make[1]: *** [rts/dist/build/sm/Scav_thr.thr_l_o] Segmentation fault 7.log:make[1]: *** [rts/dist/build/Linker.thr_debug_o] Segmentation fault 8.log:make[1]: *** [rts/dist/build/sm/Storage.debug_o] Segmentation fault 9.log:make[1]: *** [rts/dist/build/hooks/OutOfHeap.thr_debug_o] Segmentation fault On Tue, Nov 4, 2014 at 7:43 PM, David Macek david.mace...@gmail.com wrote: Hi. I just built GHC from master (1c35f9f1cb7a293da85d649904ce731a65824cfe) in my somewhat outdated MSYS2. I followed the wiki page with a few exceptions. - I cleared my PATH before running the shell (I left only Windows and System32) - my installation is not up-to-date - I do not have msys2 libtool, automake nor binutils; if the build used any of those, they came from mingw64 or from the host ghc - I had to run boot in pure msys2 shell, because mingw64 perl caused it to fail I saw no segfaults, but I may have missed them. I did not get a ghc.exe, but that may be correct behavior for all I know. My simple test program compiled and ran fine. I saw a lot of warnings during ghc's build though: - checking for DocBook DTD... I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd - something with not finding any implementation of a module out of [ xxx.dylib, xxx, ... ], I think it was in cabal builds - could not find link destionations for: xxx I hope it helps somehow. Maybe your issues come from mixing msys2 and mingw toolchain after all. -- David Macek -- ___ Msys2-users mailing list msys2-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/msys2-users -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 23:20, Gintautas Miliauskas wrote: ghc should appear as inplace/bin/ghc-stage2.exe after a successful build. It's there. Did you run make with parallelism? I don't have a smoking gun, but the build seems to be somewhat stable with -j1, while it crashes a lot of the time with -j5 (I have a 4-core CPU). I have only tried a couple of runs with -j1 (takes a while...), so I can't say for sure that non-parallel builds are stable, but 2/2 runs succeeded. Nope. I'll try with -j5. -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
Oh, and David, thanks for your help. It's really appreciated. This issue has been driving me nuts recently, and I don't have a good strategy to root it out... On Tue, Nov 4, 2014 at 11:23 PM, David Macek david.mace...@gmail.com wrote: On 4. 11. 2014 23:20, Gintautas Miliauskas wrote: ghc should appear as inplace/bin/ghc-stage2.exe after a successful build. It's there. Did you run make with parallelism? I don't have a smoking gun, but the build seems to be somewhat stable with -j1, while it crashes a lot of the time with -j5 (I have a 4-core CPU). I have only tried a couple of runs with -j1 (takes a while...), so I can't say for sure that non-parallel builds are stable, but 2/2 runs succeeded. Nope. I'll try with -j5. -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Automating GHC build for Windows
2014-11-04 23:16 GMT+01:00 Páli Gábor János pali.ga...@gmail.com: it says that the same dist-boot\setup-config.tmp file is about to renamed (to dist-boot\setup-config) twice after each other (perhaps from different threads?)! [..] Well, I guess this can easily cause the problems I have seen so far... I can also imagine that this bug is present on other systems as well, but does not cause any harm (for some reason) so it is basically invisible. However, first it would be nice if somebody else could confirm that it is indeed the case. Yeah, for what it is worth, this also happens on my FreeBSD builder too, but it works fine despite of that. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Problems compiling with llvm-3.5.0-2 on ARM
Hi Jarl, I think I just ran into this too for Fedora 22 rawhide on ARM and found your posts... On 30 October 2014 16:11, Jarl Gunnar Flaten jarl.fla...@gmail.com wrote: (cf. reddit thread http://www.reddit.com/r/haskell/comments/2kpsz5/ghc_problem_new_llvm_schedule_reentered_unsafely/ ) I am trying to compile a simple hello world program (test.hs). When compiling I am notified: [1 of 1] Compiling Main ( test.hs, test.o ) You are using a new version of LLVM that hasn't been tested yet! test: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? Isn't working. I'm not familiar enough with neither LLVM nor Haskell to troubleshoot from either of these; I don't even know if the messages are even related. They are related in the sense that llvm-3.5 seems to this problem and it is not officially supported by ghc-7.6 or ghc-7.8 (hence the warning). ghc-7.8 supports 3.4 and 7.6 seems to mostly work with some patches. Can you provide more details on your environment: OS and ghc version etc? I am not sure yet what is causing this: perhaps you could try compiling with -threaded and see if that helps? Jens ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 23:23, David Macek wrote: Nope. I'll try with -j5. So that looks like another successful build. Unless make can ignore the -j argument, I'd say the issue is caused or activated by your configuration. I'm running validate to double check (detected 4 CPUs). Maybe we should work out a precise, minimalistic recipe to replicate the issue (I haven't tried installing clean MSYS2 yet). By the way, have you ruled out anti-virus software (and other BLODApps) as a possible cause? -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Concrete syntax for pattern synonym type signatures
One note on the syntax front, 'pattern type' was mentioned as annoyingly trying to shoehorn the word 'type' in to lean on an existing keyword, even though its about a term level construction rather than a type level one. We do have some perfectly serviceable keywords available to us that indicate a more 'term/pattern' orientation, e.g. 'case' and 'of' come to mind as things that are viable candidates for similar abuse here. I'm just digging through the lexical lego bin for parts. I don't quite know how to put them together to make a nice syntax though. -Edward On Tue, Nov 4, 2014 at 5:32 AM, Simon Peyton Jones simo...@microsoft.com wrote: Here is one principle: for GADTs, the pattern type signature should look like the GADT data constructor. So if we have data S a where S1 :: p - q - S (p,q) S2 :: ...blah... pattern P x y = S1 x y then surely the signature for P should be P :: p - q - S (p,q) The same goes for constraints in the constructor's type. Thus, using your example: | data T a b where | MkT :: (Eq a, Ord b, Show c) = a - (b, b) - c - T a b If I say pattern P x y z = MkT x y z then the signature for P should be identical to that of MkT. --- It gets a bit more interesting when you have nested patterns that instantiate the type. For example, with the same type T, consider pattern P x y z = MkT (x,y) (False,True) [z] the right signature for P must presumably be P :: (Eq (p,q), Show [r]) = p - q - r - T (p,q) Bool We don't need to distinguish 'r' as existential, any more than we do in the original signature for MkT. Note that we must retain the instantiated but un-simplified constraints (Eq (p,b), Show [r]), because when pattern-matching against P, those are the constraints brought into scope. - The general story, for both data constructors and pattern synonyms, is that if the type is D :: forall abc. (C1, C2...) = blah then the constraints (C1, C2...) are - *required* when using D in an expression, - *provided* (i.e. brought into scope) pattern matching against D. The tricky case comes when the pattern synonym involves some constraints that are *required* during *pattern-matching*. A simple example is pattern P1 x = (8, x) Here we *require* a (Num a) dictionary *both* when using P1 in an expression (to build the value 8), *and* when using P in pattern matching (to build a value 8 to compare with the value being matched). I'll call the constraints that are *required* when matching the match-required constraints. The same happens for view patterns: gr :: Ord a = a - a - Maybe a gr v x | x v = Just v | otherwise = Nothing pattern P2 x = (gr 8 - Just x) Here, (Ord a, Num a) are match-required. (P2 is uni-directional, so we can't use P2 in expressions.) We can't give a signature to P1 like this P1 :: forall a. Num a = b - (a,b) because that looks as if (Num a) would be *provided* when pattern matching (see general story above), whereas actually it is required. This is the nub of the problem Gergo is presenting us with. Notice that P1 is bidirectional, and can be used in expressions, where again we *require* (Num a), so P1's term type really is something like (Num a) = b - (a,b). The more I think about this, the more I think we'll just have to bite the bullet and adapt the syntax for constraints in pattern types, to distinguish the match-required and match-provided parts. Suppose we let pattern signatures look like this: pattern P :: forall tvs. (match-provided ; match-required) = tau The ; match-required part is optional, and the match-provided part might be empty. So P1 and P2 would look like this: pattern P1 :: forall a. (; Num a) = b - (a,b) pattern P2 :: forall a. (; Num a, Ord a) = a - a Because the match-required part is optional (and relatively rare) the common case looks just like an ordinary data constructor. None of this addresses the bidirectional/unidirectional question, but that's a pretty separate matter. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 03 November 2014 10:13 | To: GHC Devs | Subject: RFC: Concrete syntax for pattern synonym type signatures | | Background | -- | | As explained on | https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Staticsemantics | the type of a pattern synonym can be fully described with the | following pieces of information: | | * If the pattern synonym is bidirectional | * Universially-bound type variables, and required constraints on them | * The type of the pattern itself, closed over the universially-bound | type variables | * Existentially-bound type variables, and the constraints provided by | them | * The types of the arguments, closed over the
