From rsx at bluewin.ch Sat Dec 1 07:08:04 2018 From: rsx at bluewin.ch (Roland Senn) Date: Sat, 01 Dec 2018 08:08:04 +0100 Subject: Windows test failures In-Reply-To: References: Message-ID: <1543648084.2924.1.camel@bluewin.ch> For T14452  there is a patch ( https://phabricator.haskell.org/D5398) ready for review..    Roland Am Freitag, den 30.11.2018, 21:49 +0000 schrieb Simon Peyton Jones via ghc-devs: > At the end of the first test run it would have given a list of tests > that failed and a line saying TEST=".... List of tests..." >   > Copy that line and at the root of the checkout do >   > make TEST=".... List of tests..."  test -C testsuite/tests >   > (that's uppercase C). This will run everything using one thread. :)  >   > OK, done.  Results below. >   > Simon >   >   > /c/code/HEAD$ make TEST="T10420 T10672_x64 T13385 T14452 T15815 T3307 > T3319 T4006 TH_scopedTvs environment001 plugin-recomp-change plugin- > recomp-flags plugin-recomp-impure plugin-recomp-pure plugins07 >  plugins09 plugins10 plugins11 plugins13 plugins14 print017"  test -C > testsuite/tests > make: Entering directory '/c/code/HEAD/testsuite/tests' > PYTHON="python3" "python3" ../driver/runtests.py  -e > "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package- > db -rtsopts  -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never >  -fno-diagnostics-show-caret -Werror=compat -dno-debug-output'" -e > config.compiler_debugged=False -e ghc_with_native_codegen=True -e > config.have_vanilla=True -e config.have_dynamic=False -e > config.have_profiling=False -e ghc_with_threaded_rts=True -e > ghc_with_dynamic_rts=False >  -e config.have_interp=True -e config.unregisterised=False -e > config.have_gdb=False -e config.have_readelf=True -e > config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e > ghc_with_smp=True -e ghc_with_llvm=False -e windows=True -e > darwin=False -e >  config.in_tree_compiler=True -e config.cleanup=True -e > config.local=True --rootdir=. --config-file=../config/ghc -e > 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' > -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e > 'config.timeout=int() >  or config.timeout' -e 'config.exeext=".exe"' -e > 'config.top="/c/code/HEAD/testsuite"' --config > 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config > 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' > --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' >  --config 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' > --config 'timeout_prog="../timeout/install-inplace/bin/timeout.exe"' > -e "config.stage=2"   --rootdir=../../libraries/Win32/tests  -- > rootdir=../../libraries/array/tests  -- > rootdir=../../libraries/base/tests  >  --rootdir=../../libraries/binary/tests  -- > rootdir=../../libraries/bytestring/tests  -- > rootdir=../../libraries/containers/tests  -- > rootdir=../../libraries/deepseq/tests  -- > rootdir=../../libraries/directory/tests  -- > rootdir=../../libraries/filepath/tests  -- > rootdir=../../libraries/ghc-compact/tests  >  --rootdir=../../libraries/ghc-heap/tests  -- > rootdir=../../libraries/ghc-prim/tests  -- > rootdir=../../libraries/haskeline/tests  -- > rootdir=../../libraries/hpc/tests  -- > rootdir=../../libraries/pretty/tests  -- > rootdir=../../libraries/process/tests  -- > rootdir=../../libraries/stm/tests  >  --rootdir=../../libraries/template-haskell/tests  -- > rootdir=../../libraries/text/tests \ >        --only=T10420  --only=T10672_x64  --only=T13385  -- > only=T14452  --only=T15815  --only=T3307  --only=T3319  --only=T4006  > --only=TH_scopedTvs  --only=environment001  --only=plugin-recomp- > change  >  --only=plugin-recomp-flags  --only=plugin-recomp-impure  -- > only=plugin-recomp-pure  --only=plugins07  --only=plugins09  -- > only=plugins10  --only=plugins11  --only=plugins13  --only=plugins14  > --only=print017 \ >        \ >        \ >        \ >        \ >        \ >         > Timeout is 300 > 0 > Found 398 .T files... > Beginning test run at Fri Nov 30 21:07:17 2018 GMTST > ====> Scanning ./ado/all.T > ====> Scanning ./annotations/should_compile/all.T > ====> Scanning ./annotations/should_compile/T13818/all.T > …lots more “Scanning” lines… > ====> Scanning ../../libraries/ghc-heap/tests/all.T > ====> Scanning ../../libraries/hpc/tests/fork/test.T--- > driver/T14452.run/T14452.stdout.normalised       2018-11-30 > 21:07:36.565566000 +0000 > +++ driver/T14452.run/T14452.run.stdout.normalised       2018-11-30 > 21:07:36.567569500 +0000 > @@ -1 +1 @@ > --O3 > +"-O3" > --- libraries/base/tests/T4006.run/T4006.stdout.normalised       > 2018-11-30 21:15:19.867313900 +0000 > +++ libraries/base/tests/T4006.run/T4006.run.stdout.normalised       > 2018-11-30 21:15:19.870787900 +0000 > @@ -1,2 +1,2 @@ > It works here > -                                > > +                                 > --- > libraries/base/tests/IO/environment001.run/environment001.stdout.norm > alised       2018-11-30 21:16:00.645817500 +0000 > +++ > libraries/base/tests/IO/environment001.run/environment001.run.stdout. > normalised       2018-11-30 21:16:00.654738900 +0000 > @@ -1,7 +1,8 @@ > -          > -Test 1: 3 > -    > -Test 2: 1 > +         > +         > +Test 1: 9 > +       > +Test 2: 3 >        ! > Test 3: 3 > ["a","b"] >   > ====> Scanning ../../libraries/hpc/tests/function/test.T > ====> Scanning ../../libraries/hpc/tests/function2/test.T > ====> Scanning ../../libraries/hpc/tests/ghc_ghci/test.T > ====> Scanning ../../libraries/hpc/tests/raytrace/test.T > ====> Scanning ../../libraries/hpc/tests/raytrace/tixs/test.T > ====> Scanning ../../libraries/hpc/tests/simple/test.T > ====> Scanning ../../libraries/hpc/tests/simple/tixs/test.T > ====> Scanning ../../libraries/process/tests/all.T > ====> Scanning ../../libraries/process/tests/T9775/all.T > ====> Scanning ../../libraries/stm/tests/all.T > ====> Scanning ../../libraries/template-haskell/tests/all.T > =====> T14452(normal) 1 of 21 [0, 0, 0] > cd "driver/T14452.run" && $MAKE -s --no-print-directory T14452  > > Actual stdout output differs from expected: > diff -uw "driver/T14452.run/T14452.stdout.normalised" > "driver/T14452.run/T14452.run.stdout.normalised" > *** unexpected failure for T14452(normal) > =====> T13385(ghci) 2 of 21 [0, 1, 0] > cd "ghci/scripts/T13385.run" && HC="/c/code/HEAD/inplace/bin/ghc- > stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db > -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never >  -fno-diagnostics-show-caret -Werror=compat -dno-debug-output > -XRebindableSyntax" "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -- > interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS > -fghci-leak-check -dcore-lint -dcmm-lint -no-user-package-db -rtsopts >  -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XRebindableSyntax  < T13385.script > =====> print017(ghci) 3 of 21 [0, 1, 0] > cd "ghci.debugger/scripts/print017.run" && > HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- > specialisations -fshow-warning-groups >  -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output " "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -- > interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS > -fghci-leak-check -dcore-lint -dcmm-lint -no-user-package-db >  -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output   -ignore-dot-ghci< print017.script > =====> print017(ghci-ext) 3 of 21 [0, 1, 0] > cd "ghci.debugger/scripts/print017.run" && > HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- > specialisations -fshow-warning-groups >  -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output " "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -- > interactive -v0 -ignore-dot-ghci -fno-ghci-history -fexternal- > interpreter +RTS -I0.1 -RTS -dcore-lint -dcmm-lint -no-user-package- > db >  -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output   -ignore-dot-ghci< print017.script > =====> plugin-recomp-change(normal) 4 of 21 [0, 1, 0] > cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print- > directory -C plugin-recomp package.plugins01 > TOP=/c/code/HEAD/testsuite > cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print- > directory plugin-recomp-change  > > =====> T10672_x64(normal) 5 of 21 [0, 1, 0] > cd "rts/T10672/T10672_x64.run" && $MAKE -s --no-print-directory > T10672_x64  > > Timeout happened...killed process "cd "rts/T10672/T10672_x64.run" && > $MAKE -s --no-print-directory T10672_x64  "... >   > Wrong exit code for T10672_x64()(expected 0 , actual 99 ) > *** unexpected failure for T10672_x64(normal) > =====> TH_scopedTvs(normal) 6 of 21 [0, 2, 0] > cd "th/TH_scopedTvs.run" &&  "/c/code/HEAD/inplace/bin/ghc- > stage2.exe" -c TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user- > package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning- > groups -fdiagnostics-color=never >  -fno-diagnostics-show-caret -Werror=compat -dno-debug-output > -XTemplateHaskell -package template-haskell -v0 > =====> TH_scopedTvs(ext-interp) 6 of 21 [0, 2, 0] > cd "th/TH_scopedTvs.run" &&  "/c/code/HEAD/inplace/bin/ghc- > stage2.exe" -c TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user- > package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning- > groups -fdiagnostics-color=never >  -fno-diagnostics-show-caret -Werror=compat -dno-debug-output > -XTemplateHaskell -package template-haskell -fexternal-interpreter > -v0 > =====> T3319(normal) 7 of 21 [0, 2, 0] > cd "th/T3319.run" &&  "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- > warn-missed-specialisations -fshow-warning-groups -fdiagnostics- > color=never >  -fno-diagnostics-show-caret -Werror=compat -dno-debug-output > -XTemplateHaskell -package template-haskell -ddump-splices -v0 > =====> T3319(ext-interp) 7 of 21 [0, 2, 0] > cd "th/T3319.run" &&  "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- > warn-missed-specialisations -fshow-warning-groups -fdiagnostics- > color=never >  -fno-diagnostics-show-caret -Werror=compat -dno-debug-output > -XTemplateHaskell -package template-haskell -fexternal-interpreter > -ddump-splices -v0 > =====> T15815(normal) 8 of 21 [0, 2, 0] > cd "th/T15815.run" &&  "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -- > make  T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- > color=never >  -fno-diagnostics-show-caret -Werror=compat -dno-debug-output > -XTemplateHaskell -package template-haskell -v0 -static > =====> T15815(ext-interp) 8 of 21 [0, 2, 0] > cd "th/T15815.run" &&  "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -- > make  T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- > color=never >  -fno-diagnostics-show-caret -Werror=compat -dno-debug-output > -XTemplateHaskell -package template-haskell -fexternal-interpreter > -v0 -static > =====> T4006(normal) 9 of 21 [0, 2, 0] > cd "libraries/base/tests/T4006.run" &&  > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -o T4006 T4006.hs -dcore- > lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- > specialisations -fshow-warning-groups >  -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output  > > cd "libraries/base/tests/T4006.run" && ./T4006  > > Actual stdout output differs from expected: > diff -uw "libraries/base/tests/T4006.run/T4006.stdout.normalised" > "libraries/base/tests/T4006.run/T4006.run.stdout.normalised" > *** unexpected failure for T4006(normal) > =====> T3307(normal) 10 of 21 [0, 3, 0] > cd "libraries/base/tests/IO/T3307.run" && $MAKE -s --no-print- > directory T3307-test  > > Wrong exit code for T3307()(expected 0 , actual 2 ) > Stdout ( T3307 ): > Test 1 > [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175 > ,180] > Ni hao > Test 2 > [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175 > ,180] > Ni hao > Test 3 > [99,104,105,110,101,115,101,45,102,105,108,101,45,23567,35828] > Stderr ( T3307 ): > *** framework failure for T3307(normal) 'latin-1' codec can't encode > characters in position 24-25: ordinal not in range(256) > > =====> environment001(normal) 11 of 21 [0, 3, 1] > cd "libraries/base/tests/IO/environment001.run" && $MAKE -s --no- > print-directory environment001-test  > > Actual stdout output differs from expected: > diff -uw > "libraries/base/tests/IO/environment001.run/environment001.stdout.nor > malised" > "libraries/base/tests/IO/environment001.run/environment001.run.stdout > .normalised" > *** unexpected failure for environment001(normal) > =====> plugins07(normal) 12 of 21 [0, 4, 1] > cd "plugins/plugins07.run" && $MAKE -s --no-print-directory -C rule- > defining-plugin package.plugins07 TOP=/c/code/HEAD/testsuite > cd "plugins/plugins07.run" && $MAKE -s --no-print-directory > plugins07  > > =====> plugins09(normal) 13 of 21 [0, 4, 1] > cd "plugins/plugins09.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins09 TOP=/c/code/HEAD/testsuite > cd "plugins/plugins09.run" && $MAKE -s --no-print-directory > plugins09  > > Actual stdout output differs from expected: > diff -uw "plugins/plugins09.run/plugins09.stdout.normalised" > "plugins/plugins09.run/plugins09.run.stdout.normalised"--- > plugins/plugins09.run/plugins09.stdout.normalised       2018-11-30 > 21:17:20.709370700 >  +0000 > +++ plugins/plugins09.run/plugins09.run.stdout.normalised       2018- > 11-30 21:17:20.711314000 +0000 > @@ -1,9 +0,0 @@ > -parsePlugin(a,b) > -interfacePlugin: Prelude > -interfacePlugin: GHC.Float > -interfacePlugin: GHC.Base > -typeCheckPlugin (rn) > -interfacePlugin: GHC.Types > -typeCheckPlugin (tc) > -interfacePlugin: GHC.Integer.Type > -interfacePlugin: GHC.Natural > --- plugins/plugins10.run/plugins10.stdout.normalised       2018-11- > 30 21:17:57.644357800 +0000 > +++ plugins/plugins10.run/plugins10.run.stdout.normalised       2018- > 11-30 21:17:57.646078700 +0000 > @@ -1,21 +0,0 @@ > -parsePlugin() > -interfacePlugin: Prelude > -interfacePlugin: Language.Haskell.TH > -interfacePlugin: Language.Haskell.TH.Quote > -interfacePlugin: GHC.Float > -interfacePlugin: GHC.Base > -interfacePlugin: Language.Haskell.TH.Syntax > -typeCheckPlugin (rn) > -interfacePlugin: GHC.Types > -typeCheckPlugin (tc) > -interfacePlugin: GHC.Integer.Type > -interfacePlugin: GHC.Natural > -parsePlugin(a) > -typeCheckPlugin (rn) > -interfacePlugin: Language.Haskell.TH.Lib.Internal > -metaPlugin: return [] > -metaPlugin: quoteExp stringify "x" > -interfacePlugin: GHC.CString > -typeCheckPlugin (rn) > -typeCheckPlugin (rn) > -typeCheckPlugin (tc) >   > *** unexpected failure for plugins09(normal) > =====> plugins10(normal) 14 of 21 [0, 5, 1] > cd "plugins/plugins10.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins10 TOP=/c/code/HEAD/testsuite > cd "plugins/plugins10.run" && $MAKE -s --no-print-directory > plugins10  > > Actual stdout output differs from expected: > diff -uw "plugins/plugins10.run/plugins10.stdout.normalised" > "plugins/plugins10.run/plugins10.run.stdout.normalised" > *** unexpected failure for plugins10(normal) > =====> plugins11(normal) 15 of 21 [0, 6, 1] > cd "plugins/plugins11.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins11 TOP=/c/code/HEAD/testsuite > cd "plugins/plugins11.run" && $MAKE -s --no-print-directory > plugins11  > > Timeout happened...killed process "cd "plugins/plugins11.run" && > $MAKE -s --no-print-directory plugins11  "... >   > Wrong exit code for plugins11()(expected 0 , actual 99 ) > *** unexpected failure for plugins11(normal) > =====> plugins13(normal) 16 of 21 [0, 7, 1] > cd "plugins/plugins13.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins13 TOP=/c/code/HEAD/testsuite > cd "plugins/plugins13.run" && $MAKE -s --no-print-directory > plugins13  > > =====> plugins14(normal) 17 of 21 [0, 7, 1] > cd "plugins/plugins14.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins14 TOP=/c/code/HEAD/testsuite > cd "plugins/plugins14.run" && $MAKE -s --no-print-directory > plugins14  > > =====> T10420(normal) 18 of 21 [0, 7, 1] > cd "plugins/T10420.run" && $MAKE -s --no-print-directory -C rule- > defining-plugin package.T10420 TOP=/c/code/HEAD/testsuite > cd "plugins/T10420.run" && $MAKE -s --no-print-directory T10420  > > =====> plugin-recomp-pure(normal) 19 of 21 [0, 7, 1] > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory > -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory > plugin-recomp-pure  > > Timeout happened...killed process "cd "plugins/plugin-recomp- > pure.run" && $MAKE -s --no-print-directory plugin-recomp-pure  "... >   > Wrong exit code for plugin-recomp-pure()(expected 0 , actual 99 ) > Stdout ( plugin-recomp-pure ): > [1 of 1] Compiling Main             ( plugin-recomp-test.hs, plugin- > recomp-test.o ) > Stderr ( plugin-recomp-pure ): > Simple Plugin Passes Queried > Got options:  > Simple Plugin Pass Run > *** unexpected failure for plugin-recomp-pure(normal) > =====> plugin-recomp-impure(normal) 20 of 21 [0, 8, 1] > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print- > directory -C plugin-recomp package.plugins01 > TOP=/c/code/HEAD/testsuite > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print- > directory plugin-recomp-impure  > > Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) > Stdout ( plugin-recomp-impure ): > [1 of 1] Compiling Main             ( plugin-recomp-test.hs, plugin- > recomp-test.o ) > Linking plugin-recomp-test.exe ... > [1 of 1] Compiling Main             ( plugin-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 reading 0xa824 >   > Attempting to reconstruct a stack trace... >   >    Frame     Code address > * 0x49adab0 0x1eb49ec 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" && $MAKE -s --no-print-directory > -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory > plugin-recomp-flags  > > Traceback (most recent call last): >   File "/c/code/HEAD/testsuite/driver/testlib.py", line 824, in > test_common_work >     do_test(name, way, func, args, files) >   File "/c/code/HEAD/testsuite/driver/testlib.py", line 910, in > do_test >     result = func(*[name,way] + args) >   File "/c/code/HEAD/testsuite/driver/testlib.py", line 993, in > run_command >     return simple_run( name, '', override_options(cmd), '' ) >   File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in > simple_run >     dump_stderr(name) >   File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in > dump_stderr >     print(str) > UnicodeEncodeError: 'latin-1' codec can't encode characters in > position 24-25: ordinal not in range(256) >   > Unexpected 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 cases, of which >       11 were skipped >   >        0 had missing libraries >       15 expected passes >        0 expected failures >   >        1 caused framework failures >        0 caused framework warnings >        0 unexpected passes >        9 unexpected failures >        0 unexpected stat failures >   > Unexpected failures: >    driver/T14452.run                           T14452 [bad stdout] > (normal) >    rts/T10672/T10672_x64.run                   T10672_x64 [bad exit > code] (normal) >    libraries/base/tests/T4006.run              T4006 [bad stdout] > (normal) >    libraries/base/tests/IO/environment001.run  environment001 [bad > stdout] (normal) >    plugins/plugins09.run                       plugins09 [bad stdout] > (normal) >    plugins/plugins10.run                       plugins10 [bad stdout] > (normal) >    plugins/plugins11.run                       plugins11 [bad exit > code] (normal) >    plugins/plugin-recomp-pure.run              plugin-recomp-pure > [bad exit code] (normal) >    plugins/plugin-recomp-impure.run            plugin-recomp-impure > [bad exit code] (normal) >   > Framework failures: >    libraries/base/tests/IO/T3307.run  T3307 [normal] ('latin-1' codec > can't encode characters in position 24-25: ordinal not in range(256)) >   > Appending 0 stats to git notes. > make: *** [../mk/test.mk:342: test] Error 1 > make: Leaving directory '/c/code/HEAD/testsuite/tests' > /c/code/HEAD$ >   >   > > > > From: Phyx > > > Sent: 30 November 2018 11:58 > > To: Simon Peyton Jones > > Subject: Re: Windows test failures > > >   > At the end of the first test run it would have given a list of tests > that failed and a line saying TEST=".... List of tests..." > >   > > > Copy that line and at the root of the checkout do > > >   > > > make TEST=".... List of tests..."  test -C testsuite/tests > > >   > > > (that's uppercase C). This will run everything using one thread. :)  > > >   > > > Should give a good starting point as to what's wrong.  > > >   > > > Kind regards,  > > > Tamar  > > > On Fri, Nov 30, 2018, 10:30 Simon Peyton Jones > wrote: > > > > > So I just say >                make TEST > is that right? >   > Or is it > >                make THREADS=1 >   > or what?  Sorry to be dim >   > > > > From: Phyx > > > Sent: 30 November 2018 08:05 > > To: Simon Peyton Jones > > Cc: ghc-devs > > Subject: Re: Windows test failures > > > > > > > > >   > 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 increasingly > unstable under threads for some reason.  > > >   > > > I also haven't run trunk yet since last week so they could be new..  > > >   > > > But rerunning the fails with no threads should give a better idea.  > > >   > > > Regards,  > > > Tamar > > > On Fri, Nov 30, 2018, 07:46 Simon Peyton Jones via ghc-devs @haskell.org> wrote: > > > > > Ben, Phyx, and other CI folk > ‘sh validate –fast’ still gives a lot of failures on Window.  The > output is below. I would be so good to get this to zero! > (another minor thing is that it would be great to eliminate the long > path at the beginning – this is platform independent – I have to > delete manually many times each day. > Thanks > Simon > Unexpected passes: >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/rts/T9405.run  T9405 [unexpected] (normal) >   > Unexpected failures: >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/driver/T14452.run                           T14452 [bad > stdout] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci/linking/ghcilink001.run                ghcilink001 [bad > exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci/prog010/ghci.prog010.run               ghci.prog010 [bad > exit code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci/scripts/ghci050.run                    ghci050 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci/should_run/T14963a.run                 T14963a [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/print012.run          print012 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/print016.run          print016 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/break019.run          break019 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/break028.run          break028 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/dynbrk002.run         dynbrk002 [bad > exit code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/T2740.run             T2740 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/indexed-types/should_fail/T7102a.run        T7102a [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugin-recomp-change.run            plugin-recomp- > change [bad exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/rts/T10672/T10672_x64.run                   T10672_x64 [bad > exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/th/TH_spliceGuard.run                       TH_spliceGuard > [exit code non-0] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/th/TH_overlaps.run                          TH_overlaps [exit > code non-0] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/th/T5886.run                                T5886 [exit code > non-0] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/th/T10697_decided_3.run                     T10697_decided_3 > [exit code non-0] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/th/T11629.run                               T11629 [exit code > non-0] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/libraries/base/tests/T4006.run              T4006 [bad stdout] > (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/libraries/base/tests/IO/environment001.run  environment001 > [bad stdout] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci/should_run/T15633b.run                 T15633b [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugins07.run                       plugins07 [bad > exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugins09.run                       plugins09 [bad > stdout] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugins10.run                       plugins10 [bad > stdout] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugins11.run                       plugins11 [bad > stdout] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/T10420.run                          T10420 [bad exit > code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugin-recomp-pure.run              plugin-recomp-pure > [bad exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugin-recomp-impure.run            plugin-recomp- > impure [bad exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugin-recomp-flags.run             plugin-recomp- > flags [bad exit code] (normal) >   > Framework failures: >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/perf/compiler/MultiLayerModules.run  MultiLayerModules > [runTest] (Unhandled exception during cleanup: Unable to remove > folder '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   >  spaces/perf/compiler/MultiLayerModules.run': [Errno 13] Permission > denied: '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/perf/compiler/MultiLayerModules.run' > Unable to start current test.) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/libraries/base/tests/IO/T3307.run    T3307 [normal] ('latin-1' > codec can't encode characters in position 24-25: ordinal not in > range(256)) >   > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > > > > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Sat Dec 1 12:23:57 2018 From: chrisdone at gmail.com (Christopher Done) Date: Sat, 1 Dec 2018 12:23:57 +0000 Subject: Writing a simple Core evaluator, having trouble with name lookups In-Reply-To: References: <87woouy8dk.fsf@smart-cactus.org> <87r2f2xw9e.fsf@smart-cactus.org> Message-ID: I think what Csaba means is that we can have e.g. * GHC invocation 1 * ghc-prim: * MyModule.foo has Unique 123 * OtherModule.bar has Unique 124 * GHC invocation 2 * base: * MyMod.mu has Unique 123 * OtherMod.zot has Unique 124 For a unique reference then, we just need: * ghc-prim:MyMobile.foo+123 * ghc-prim:OtherModule.bar+124 * base:MyMod.mu+123 * base:OtherMod.zot+124 For any local lookup this is reliable. If the lookup fails, a lookup without the Unique works for cross-module lookups. From csaba.hruska at gmail.com Sat Dec 1 12:42:01 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Sat, 1 Dec 2018 13:42:01 +0100 Subject: Writing a simple Core evaluator, having trouble with name lookups In-Reply-To: References: <87woouy8dk.fsf@smart-cactus.org> <87r2f2xw9e.fsf@smart-cactus.org> Message-ID: The package name + module name is always unique in every Haskell program, module names can not be duplicated in a package and package names are unique also. There are 2 kinds of identifiers, local and exported. You can construct a whole program unique name for: - exported identifier with combining the package name + module name + occurence name (without the unique value) - local identifier with combining the package name + module name + occurence name + unique (what is unique per invocation) It is safe because only the exported names can appear in an external expression and those do not contain the GHC's unique value. Just think about how the object code linker deals with GHC symbols. Cheers, Csaba On Sat, Dec 1, 2018 at 1:23 PM Christopher Done wrote: > I think what Csaba means is that we can have e.g. > > * GHC invocation 1 > * ghc-prim: > * MyModule.foo has Unique 123 > * OtherModule.bar has Unique 124 > * GHC invocation 2 > * base: > * MyMod.mu has Unique 123 > * OtherMod.zot has Unique 124 > > For a unique reference then, we just need: > > * ghc-prim:MyMobile.foo+123 > * ghc-prim:OtherModule.bar+124 > * base:MyMod.mu+123 > * base:OtherMod.zot+124 > > For any local lookup this is reliable. If the lookup fails, a lookup > without the Unique works for cross-module lookups. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Sat Dec 1 15:03:00 2018 From: chrisdone at gmail.com (Christopher Done) Date: Sat, 1 Dec 2018 15:03:00 +0000 Subject: Writing a simple Core evaluator, having trouble with name lookups In-Reply-To: References: <87woouy8dk.fsf@smart-cactus.org> <87r2f2xw9e.fsf@smart-cactus.org> Message-ID: Regarding classes, Csaba, did you have to deal with dictionaries at the STG level? I'm finding that at the Core level, methods don't generate code, so I have to generate them myself. But then I have to know more about classes than I might ideally not want to. For example, I've noticed that if a class has only one method, then the dictionary for an instance doesn't actually seem to construct a record, but makes a special case and just refers to the single method. So my evaluator failed on this. If I add one more method to the class, then things work properly. Example: module Demo (demo) where class Person a where person :: a -> Int wibble :: a -> Int instance Person X where person unusedarg = 5 wibble _ = 9 data X = X demo = person X This produces chris at precision:~/Work/chrisdone/prana$ sh scripts/compiledemo.sh [1 of 1] Compiling Demo ( Demo.hs, Demo.o ) Writing main_Demo.prana Eval: ((main:Demo.person main:Demo.$fPersonX) main:Demo.X) Eval: (main:Demo.person main:Demo.$fPersonX) Eval: main:Demo.person Done: main:Demo.person[Method]0 Eval: main:Demo.$fPersonX <---- here is the dictionary, and you can see what it refers to below: Eval: ((main:Demo.C:Person main:Demo.$cperson) main:Demo.$cwibble) <-- this is the two methods Eval: (main:Demo.C:Person main:Demo.$cperson) Eval: main:Demo.C:Person Done: (main:Demo.C:Person[Con] ) Done: (main:Demo.C:Person[Con] main:Demo.$cperson) Done: (main:Demo.C:Person[Con] main:Demo.$cpersonmain:Demo.$cwibble) Done: (main:Demo.C:Person[Con] main:Demo.$cpersonmain:Demo.$cwibble) Eval: main:Demo.$cperson Eval: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Eval: (ghc-prim:GHC.Types.I# 5) Eval: ghc-prim:GHC.Types.I# Done: (ghc-prim:GHC.Types.I#[Con] ) Done: (ghc-prim:GHC.Types.I#[Con] 5) Done: (ghc-prim:GHC.Types.I#[Con] 5) ConWHNF (Id {idStableName = "ghc-prim:GHC.Types.I#", idUnique = Unique 3891110078048108563, idCategory = DataCat}) [LitE (Int 5)] That's great. But if I delete the wibble method: Eval: ((main:Demo.person main:Demo.$fPersonX) main:Demo.X) Eval: (main:Demo.person main:Demo.$fPersonX) Eval: main:Demo.person Done: main:Demo.person[Method]0 Eval: main:Demo.$fPersonX <- the dictionary Eval: main:Demo.$cperson <-- evaluates to simply the person method, instead of a data constructor Eval: main:Demo.$cperson Eval: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Which results in a runtime type error: prana: TypeError (NotAnInstanceDictionary (Id {idStableName = "main:Demo.person", idUnique = Unique 8214565720323785170, idCategory = ValCat}) (LamWHNF (Id {idStableName = "main:Demo.unusedarg", idUnique = Unique 6989586621679011036, idCategory = ValCat}) (AppE (VarE (Id {idStableName = "ghc-prim:GHC.Types.I#", idUnique = Unique 3891110078048108563, idCategory = DataCat})) (LitE (Int 5))))) I could ignore the fact that I got a function instead of a dictionary, and then evaluation proceeds OK: Eval: ((main:Demo.person main:Demo.$fPersonX) main:Demo.X) Eval: (main:Demo.person main:Demo.$fPersonX) Eval: main:Demo.person Done: main:Demo.person[Method]0 Eval: main:Demo.$fPersonX Eval: main:Demo.$cperson Eval: main:Demo.$cperson Eval: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) Eval: (ghc-prim:GHC.Types.I# 5) Eval: ghc-prim:GHC.Types.I# Done: (ghc-prim:GHC.Types.I#[Con] ) Done: (ghc-prim:GHC.Types.I#[Con] 5) Done: (ghc-prim:GHC.Types.I#[Con] 5) ConWHNF (Id {idStableName = "ghc-prim:GHC.Types.I#", idUnique = Unique 3891110078048108563, idCategory = DataCat}) [LitE (Int 5)] But this feels a bit less structured. I want, for example, to be able to update definitions at runtime, so runtime type-errors will be a thing sometimes. I feel like this kind of thing would make some confusing runtime type errors. And what other class-specific oddities should I have to handle? I haven't gotten to dictionaries with superclasses yet, that'll require more handling so I'll probably need more knowledge of classes anyway. So I'm wondering whether at the STG phase all classes have been abstracted away and we really do only deal with lambdas, lets and cases? I didn't see any class-specific code in your project. I only chose Core because I wanted to stay as close to the original Haskell source as possible, and have a very simple evaluation model, but perhaps STG is the easier choice. Cheers On Sat, 1 Dec 2018 at 12:42, Csaba Hruska wrote: > > The package name + module name is always unique in every Haskell program, module names can not be duplicated in a package and package names are unique also. > There are 2 kinds of identifiers, local and exported. > You can construct a whole program unique name for: > > exported identifier with combining the package name + module name + occurence name (without the unique value) > local identifier with combining the package name + module name + occurence name + unique (what is unique per invocation) > > It is safe because only the exported names can appear in an external expression and those do not contain the GHC's unique value. > Just think about how the object code linker deals with GHC symbols. > > Cheers, > Csaba > > On Sat, Dec 1, 2018 at 1:23 PM Christopher Done wrote: >> >> I think what Csaba means is that we can have e.g. >> >> * GHC invocation 1 >> * ghc-prim: >> * MyModule.foo has Unique 123 >> * OtherModule.bar has Unique 124 >> * GHC invocation 2 >> * base: >> * MyMod.mu has Unique 123 >> * OtherMod.zot has Unique 124 >> >> For a unique reference then, we just need: >> >> * ghc-prim:MyMobile.foo+123 >> * ghc-prim:OtherModule.bar+124 >> * base:MyMod.mu+123 >> * base:OtherMod.zot+124 >> >> For any local lookup this is reliable. If the lookup fails, a lookup >> without the Unique works for cross-module lookups. From csaba.hruska at gmail.com Sat Dec 1 15:25:36 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Sat, 1 Dec 2018 16:25:36 +0100 Subject: Writing a simple Core evaluator, having trouble with name lookups In-Reply-To: References: <87woouy8dk.fsf@smart-cactus.org> <87r2f2xw9e.fsf@smart-cactus.org> Message-ID: That's right there are some missing bindings at the core level, those will be generated by *corePrepPgm* function. STG is a low level version of core and it contains all code that is required for execution. Classes are represented as nodes (dictionary) at STG level. E.g. here is my custom STG data type which I export: https://github.com/grin-tech/ghc-grin/blob/master/ghc-dump-core/GhcDump_StgAst.hs In my opinion GHC core has lots of internal coding convention. Cheers On Sat, Dec 1, 2018 at 4:02 PM Christopher Done wrote: > Regarding classes, > > Csaba, did you have to deal with dictionaries at the STG level? I'm > finding that at the Core level, methods don't generate code, so I have > to generate them myself. But then I have to know more about classes > than I might ideally not want to. > > For example, I've noticed that if a class has only one method, then > the dictionary for an instance doesn't actually seem to construct a > record, but makes a special case and just refers to the single method. > So my evaluator failed on this. If I add one more method to the class, > then things work properly. Example: > > module Demo (demo) where > class Person a where > person :: a -> Int > wibble :: a -> Int > instance Person X where > person unusedarg = 5 > wibble _ = 9 > data X = X > demo = person X > > This produces > > chris at precision:~/Work/chrisdone/prana$ sh scripts/compiledemo.sh > [1 of 1] Compiling Demo ( Demo.hs, Demo.o ) > Writing main_Demo.prana > Eval: ((main:Demo.person main:Demo.$fPersonX) main:Demo.X) > Eval: (main:Demo.person main:Demo.$fPersonX) > Eval: main:Demo.person > Done: main:Demo.person[Method]0 > Eval: main:Demo.$fPersonX <---- here is the dictionary, and you > can see what it refers to below: > Eval: ((main:Demo.C:Person main:Demo.$cperson) > main:Demo.$cwibble) <-- this is the two methods > Eval: (main:Demo.C:Person main:Demo.$cperson) > Eval: main:Demo.C:Person > Done: (main:Demo.C:Person[Con] ) > Done: (main:Demo.C:Person[Con] main:Demo.$cperson) > Done: (main:Demo.C:Person[Con] main:Demo.$cpersonmain:Demo.$cwibble) > Done: (main:Demo.C:Person[Con] main:Demo.$cpersonmain:Demo.$cwibble) > Eval: main:Demo.$cperson > Eval: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Eval: (ghc-prim:GHC.Types.I# 5) > Eval: ghc-prim:GHC.Types.I# > Done: (ghc-prim:GHC.Types.I#[Con] ) > Done: (ghc-prim:GHC.Types.I#[Con] 5) > Done: (ghc-prim:GHC.Types.I#[Con] 5) > ConWHNF (Id {idStableName = "ghc-prim:GHC.Types.I#", idUnique = Unique > 3891110078048108563, idCategory = DataCat}) [LitE (Int 5)] > > That's great. But if I delete the wibble method: > > Eval: ((main:Demo.person main:Demo.$fPersonX) main:Demo.X) > Eval: (main:Demo.person main:Demo.$fPersonX) > Eval: main:Demo.person > Done: main:Demo.person[Method]0 > Eval: main:Demo.$fPersonX <- the dictionary > Eval: main:Demo.$cperson <-- evaluates to simply the person > method, instead of a data constructor > Eval: main:Demo.$cperson > Eval: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > > Which results in a runtime type error: > > prana: TypeError (NotAnInstanceDictionary (Id {idStableName = > "main:Demo.person", idUnique = Unique 8214565720323785170, idCategory > = ValCat}) (LamWHNF (Id {idStableName = "main:Demo.unusedarg", > idUnique = Unique 6989586621679011036, idCategory = ValCat}) (AppE > (VarE (Id {idStableName = "ghc-prim:GHC.Types.I#", idUnique = Unique > 3891110078048108563, idCategory = DataCat})) (LitE (Int 5))))) > > I could ignore the fact that I got a function instead of a dictionary, > and then evaluation proceeds OK: > > Eval: ((main:Demo.person main:Demo.$fPersonX) main:Demo.X) > Eval: (main:Demo.person main:Demo.$fPersonX) > Eval: main:Demo.person > Done: main:Demo.person[Method]0 > Eval: main:Demo.$fPersonX > Eval: main:Demo.$cperson > Eval: main:Demo.$cperson > Eval: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Done: (\main:Demo.unusedarg -> (ghc-prim:GHC.Types.I# 5)) > Eval: (ghc-prim:GHC.Types.I# 5) > Eval: ghc-prim:GHC.Types.I# > Done: (ghc-prim:GHC.Types.I#[Con] ) > Done: (ghc-prim:GHC.Types.I#[Con] 5) > Done: (ghc-prim:GHC.Types.I#[Con] 5) > ConWHNF (Id {idStableName = "ghc-prim:GHC.Types.I#", idUnique = Unique > 3891110078048108563, idCategory = DataCat}) [LitE (Int 5)] > > But this feels a bit less structured. I want, for example, to be able > to update definitions at runtime, so runtime type-errors will be a > thing sometimes. I feel like this kind of thing would make some > confusing runtime type errors. And what other class-specific oddities > should I have to handle? > > I haven't gotten to dictionaries with superclasses yet, that'll > require more handling so I'll probably need more knowledge of classes > anyway. > > So I'm wondering whether at the STG phase all classes have been > abstracted away and we really do only deal with lambdas, lets and > cases? I didn't see any class-specific code in your project. > > I only chose Core because I wanted to stay as close to the original > Haskell source as possible, and have a very simple evaluation model, > but perhaps STG is the easier choice. > > Cheers > On Sat, 1 Dec 2018 at 12:42, Csaba Hruska wrote: > > > > The package name + module name is always unique in every Haskell > program, module names can not be duplicated in a package and package names > are unique also. > > There are 2 kinds of identifiers, local and exported. > > You can construct a whole program unique name for: > > > > exported identifier with combining the package name + module name + > occurence name (without the unique value) > > local identifier with combining the package name + module name + > occurence name + unique (what is unique per invocation) > > > > It is safe because only the exported names can appear in an external > expression and those do not contain the GHC's unique value. > > Just think about how the object code linker deals with GHC symbols. > > > > Cheers, > > Csaba > > > > On Sat, Dec 1, 2018 at 1:23 PM Christopher Done > wrote: > >> > >> I think what Csaba means is that we can have e.g. > >> > >> * GHC invocation 1 > >> * ghc-prim: > >> * MyModule.foo has Unique 123 > >> * OtherModule.bar has Unique 124 > >> * GHC invocation 2 > >> * base: > >> * MyMod.mu has Unique 123 > >> * OtherMod.zot has Unique 124 > >> > >> For a unique reference then, we just need: > >> > >> * ghc-prim:MyMobile.foo+123 > >> * ghc-prim:OtherModule.bar+124 > >> * base:MyMod.mu+123 > >> * base:OtherMod.zot+124 > >> > >> For any local lookup this is reliable. If the lookup fails, a lookup > >> without the Unique works for cross-module lookups. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From klebinger.andreas at gmx.at Sat Dec 1 21:00:21 2018 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Sat, 01 Dec 2018 22:00:21 +0100 Subject: Considerations for Control flow hint implementation. In-Reply-To: References: <5C0120D7.1010608@gmx.at> Message-ID: <5C02F665.7090801@gmx.at> Thank your for the feedback Simon! This indeed seems like the way to go. I tried that and adding weights to core this way only added 0.1% allocations on average for -O2. Cheers, Andreas Simon Peyton Jones schrieb: > > Alternative 1: Putting the weights directly into the case alternative > tuple > > Rather than putting it in the tuple, you could put it in the AltCon > > type Alt b = (AltCon, [b], Expr b) > > data AltCon = DataAlt Freq DataCon | LitAlt Freq Literal | DEFAULT Freq > > My guess is that a lot more current code pattern matches on those > triples than pattern matches on the AltCon itself. And AltCon isn't > used for anything else > > Simon > > *From:*ghc-devs *On Behalf Of *Andreas > Klebinger > *Sent:* 30 November 2018 11:37 > *To:* ghc-devs at haskell.org > *Subject:* Considerations for Control flow hint implementation. > > Hello Devs, > > I've started thinking about the implementation of > https://github.com/ghc-proposals/ghc-proposals/pull/182 recently. (Add > control flow hint pragmas.) > > For this purpose I've rebased *D4327 *"WIP: Add likelyhood to > alternatives from stg onwards" which already does a lot of the work at > the Cmm/Stg level. > > The issue I ask you for feedback now is how to best attach branch > weights to case alternatives in core. > > My prefered approach would be to expand core data types to include > them unconditionally. > While this is quite far reaching in the amount of code it touches it > would be rather straight forward to implement: > > Alternative 1: Putting the weights directly into the case alternative > tuple: > + It it's trivial to check which places manipulate case alternatives > as they will initially fail to compile. > + It's very mechanical, almost all use sites won't actually change the > weight. > + It's easy to keep this working going forward as any new > optimizations can't "forget" they have to consider them. > - It will introduce a cost in compiler performance. > - New optimization who don't have to care about branchweights still > have to at least pipe them through. > - While syntactically heavy in terms of real complexity it's a simply > approach. > > Alternative 2: Putting the weights into the case constructor. > + Might give better compiler performance as I expect us to rebuild > cases less often than alternatives. > - Seems kind of clunky. > - Weaker coupling between case alternatives and their weights. > > Or we could use ticks: > + There is some machinery already there > + Can be turned off for -O0 > + Can be ignored when convenient. > - Can be ignored when convenient. > - Very weak coupling between case alternatives and their weights. > - The existing machinery doesn't exactly match the needs of this. > - We would have to extend tick semantics to a degree where complexity > might grow too large > for me to successfully implement this. > - If new optimizations end up just removing these ticks because they > are allowed to then > the whole exercise becomes rather pointless. > - Makes it harder to ensure all relevant code paths in GHC are > actually updated. > > In particular there is currently no tick category which can stick to > case alternatives but just get's removed in case > it get's in the way of optimizations. > The closest match is SoftScope which allows ticks to be floated up, > something that could impact performance quite badly > in this case. As then we might float something intended to mark a > branch as unlikely into another branch that is actually > along the hot path. > > I think the core variant(s) mostly stand and fall with the actual > compile time impact. For -O0 the impact > would be negligible as the compile time is already dominated by > codegen and typechecking. For the rest > it's hard to say. > > So I'm looking for feedback on this. Maybe you have other suggestions > I haven't considered? > How much compile time cost increase would be acceptable for what kind > of performance boost? > > Cheers, > Andreas Klebinger > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sat Dec 1 21:18:27 2018 From: ben at well-typed.com (Ben Gamari) Date: Sat, 01 Dec 2018 16:18:27 -0500 Subject: Moving to GitLab... Message-ID: <87pnulx7xd.fsf@smart-cactus.org> tl;dr. Have a look at [1], feel free to submit merge requests, issues, comments, code review, etc. Some documentation describing a few common tasks can be found here[2]. However, be aware that we this is not the final instance and will be cleared before the final migration in around two weeks. Hello everyone, A few weeks ago I wrote to this list proposing that we consider moving GHC's development infrastructure to GitLab. While the original proposal provided a small test instance to play with, it wasn't complete enough to use in earnest. Today I would like to announce the availability of https://gitlab.staging.haskell.org for your perusal and usage. While this is not the final migrated instance, it does have all of the features that one can expect from the final migration. These include, * a full import of Trac tickets (as of last week), including attachments * continuous integration via CircleCI * mirrors of all boot libraries * the ability to login using GitHub credentials There are a few issues that we are still working on sorting out: * the timestamps associated with ticket open and close events aren't quite right * some milestone changes aren't properly imported * CircleCI currently fails on forks (this should be resolved shortly) * we currently don't import Trac Wiki pages All of these issues have either already been resolved in the import tool or are in-progress. # The plan moving forward The goal of this instance is to allow contributors to gain experience using GitLab and identify potential friction points. Towards that end, please do make good use of it. In particular we are interested in identifying: * workflows that will become harder under GitLab (and ways that we could improve these) * remaining issues in the Trac import * areas lacking in documentation Please do let us know if you encounter any of the above. Ultimately the goal remains to cut over to GitLab on December 18. This will require that we bring down this instance for roughly a day to seed it with a new import. Note that we will not make any attempt to preserve any comments, merge requests, or issues created on this instance. Cheers, - Ben [1] https://gitlab.staging.haskell.org/ghc/ghc [2] https://gitlab.staging.haskell.org/ghc/ghc/wikis/home -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From csaba.hruska at gmail.com Sat Dec 1 21:37:31 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Sat, 1 Dec 2018 22:37:31 +0100 Subject: typePrimRep invariants In-Reply-To: References: Message-ID: I've got the answer at #ghc irc channel. With resultIsLevPoly it is possible to filter out the problematic types. Regards, Csaba On Fri, Nov 30, 2018 at 11:08 PM Csaba Hruska wrote: > Is this problem related to the following? > >> {- Note [Error and friends have an "open-tyvar" forall] >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 'error' and 'undefined' have types >> error :: forall (v :: RuntimeRep) (a :: TYPE v). String -> a >> undefined :: forall (v :: RuntimeRep) (a :: TYPE v). a >> Notice the runtime-representation polymorphism. This ensures that >> "error" can be instantiated at unboxed as well as boxed types. >> This is OK because it never returns, so the return type is irrelevant. >> >> > > On Fri, Nov 30, 2018 at 10:47 PM Csaba Hruska > wrote: > >> Hi, >> >> I'd like to export the PrimRep of every binder and data con from Haskell >> modules. >> >> I have a modified GHC 8.6 which serializes the PrimRep for every binder >> during the compilation. It uses the *typePrimRep* function. When my >> customised GHC compiles the base library it always thows the following >> error for the *libraries/base/GHC/Err.hs* >> >> module. >> >> 1. Does that mean that there is hidden requirement for typePrimRep >> input? >> 2. If so what are the restrictions? >> 3. Can you see anything in the Err module source code that could not >> be a proper input for typePrimRep function? >> >> >> Thanks, >> Csaba >> >> "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O >> -Wall -this-unit-id base-4.12.0.0 -hide-all-packages -i >> -ilibraries/base/. -ilibraries/base/dist-install/build >> -Ilibraries/base/dist-install/build >> -ilibraries/base/dist-install/build/./autogen >> -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include >> -Ilibraries/base/dist-install/build/include >> -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include >> -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id >> ghc-prim-0.5.3 -package-id integer-gmp-1.0.2.0 -package-id rts >> -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 >> -O2 -haddock -no-user-package-db -rtsopts -Wno-trustworthy-safe >> -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir >> libraries/base/dist-install/build -hidir libraries/base/dist-install/build >> -stubdir libraries/base/dist-install/build -split-sections -dynamic-too -c >> libraries/base/./GHC/Err.hs -o libraries/base/dist-install/build/GHC/Err.o >> -dyno libraries/base/dist-install/build/GHC/Err.dyn_o >> ghc-stage1: panic! (the 'impossible' happened) >> (GHC version 8.6.2 for x86_64-unknown-linux): >> runtimeRepPrimRep >> typePrimRep (a_a1ML :: TYPE r_a1MK) >> r_a1MK >> Call stack: >> CallStack (from HasCallStack): >> callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in >> ghc:Outputable >> pprPanic, called at compiler/simplStg/RepType.hs:358:5 in >> ghc:RepType >> >> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >> >> libraries/base/ghc.mk:4: recipe for target >> 'libraries/base/dist-install/build/GHC/Err.o' failed >> make[1]: *** [libraries/base/dist-install/build/GHC/Err.o] Error 1 >> Makefile:122: recipe for target 'all' failed >> make: *** [all] Error 2 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndmitchell at gmail.com Sun Dec 2 16:14:03 2018 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun, 2 Dec 2018 16:14:03 +0000 Subject: [Haskell] Treatment of unknown pragmas In-Reply-To: References: <8736t5n5kc.fsf@smart-cactus.org> <87zhvdln5l.fsf@smart-cactus.org> Message-ID: Hi all, I've just released HLint 2.1.11 which supports three different forms of pragma as per https://github.com/ndmitchell/hlint#ignoring-hints, so you can write: * {-# ANN module "HLint: ignore Eta reduce" #-} * {-# HLINT ignore "Eta reduce" #-} * {- HLINT ignore "Eta reduce" -} The last two are new to this version of HLint. ANN is a serious performance penalty, {-# HLINT #-} triggers a GHC warning, and {- HLINT -} gets highlighted as a comment - so people get to pick their downside. I will probably remove documentation of the ANN variant at some point, since it's got serious the most serious downsides. I have no intention to support a {-@ HLINT @-} or similar syntax, because everything that might sensibly be used is taken, and even if it gets adopted universally, I suspect HLINT will account for 80%+ instances, making it still the "weird HLINT syntax". My preference is still to have GHC not give warnings on HLINT, but assuming that's still infeasible, I'll probably see about getting all the Haskell syntax highlighters to add special support for {- HLINT -}... Thanks, Neil On Sun, Oct 28, 2018 at 3:04 PM Artem Pelenitsyn wrote: > > Hello Daniel, > > Annotations API was discussed earlier in this thread. Main points against are: > > Neil: > Significant compilation performance penalty and extra recompilation. ANN pragmas is what HLint currently uses. > > Brandon: > The problem with ANN is it's part of the plugins API, and as such does things like compiling the expression into the program in case a plugin generates code using its value, plus things like recompilation checking end up assuming plugins are in use and doing extra checking. Using it as a compile-time pragma is actually fairly weird from that standpoint. > > -- > Best, Artem > On Sat, 27 Oct 2018 at 22:12 Daniel Wagner wrote: >> >> I don't have a really strong opinion, but... isn't this (attaching string-y data to source constructs) pretty much exactly what GHC's annotation pragma is for? >> ~d >> >> On Tue, Oct 16, 2018 at 3:14 PM Ben Gamari wrote: >>> >>> Vladislav Zavialov writes: >>> >>> > What about introducing -fno-warn-pragma=XXX? People who use HLint will >>> > add -fno-warn-pragma=HLINT to their build configuration. >>> > >>> A warning flag is an interesting way to deal with the issue. On the >>> other hand, it's not great from an ergonomic perspective; afterall, this >>> would mean that all users of HLint (and any other tool requiring special >>> pragmas) include this flag in their build configuration. A typical >>> Haskell project already needs too much such boilerplate, in my opinion. >>> >>> I think it makes a lot of sense to have a standard way for third-parties >>> to attach string-y information to Haskell source constructs. While it's >>> not strictly speaking necessary to standardize the syntax, doing >>> so minimizes the chance that tools overlap and hopefully reduces >>> the language ecosystem learning curve. >>> >>> Cheers, >>> >>> - Ben >>> _______________________________________________ >>> >>> Haskell mailing list >>> Haskell at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >> >> _______________________________________________ >> Haskell mailing list >> Haskell at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From chessai1996 at gmail.com Sun Dec 2 20:25:21 2018 From: chessai1996 at gmail.com (Daniel Cartwright) Date: Sun, 2 Dec 2018 15:25:21 -0500 Subject: [GHC] #15777: Ordering of code in file affects compilation In-Reply-To: <061.976ec2ad6b2d44a0f4ae13887ce73991@haskell.org> References: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> <061.976ec2ad6b2d44a0f4ae13887ce73991@haskell.org> Message-ID: Wow, that's a useful bit of information. Thank you! On Sun, Dec 2, 2018, 3:22 PM GHC #15777: Ordering of code in file affects compilation > -------------------------------------+------------------------------------- > Reporter: chessai | Owner: (none) > Type: bug | Status: closed > Priority: normal | Milestone: 8.6.2 > Component: Compiler | Version: 8.6.1 > Resolution: duplicate | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: GHC rejects | Unknown/Multiple > valid program | Test Case: > Blocked By: | Blocking: > Related Tickets: #12088 | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by RyanGlScott): > > One other trick worth noting (that I learned recently from #15561) is that > open and closed type families behave differently in SCC analysis, so > turning `Rep` into a closed type family actually makes this typecheck. > That is to say, the following compiles: > > {{{#!hs > {-# LANGUAGE MagicHash #-} > {-# LANGUAGE UnboxedTuples #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeInType #-} > > -- | Conversion between unlifted and lifted datatypes > module Packed.Levity > ( -- * Types > Rep > , Levity(..) > ) where > > import Data.Kind (Type) > import GHC.Types (TYPE, RuntimeRep(..), Int(..), Word(..)) > import GHC.Exts (Int#, Word#, ByteArray#) > > class Levity (a :: Type) where > type Unlifted a :: TYPE (Rep a) > box :: Unlifted a -> a > unbox :: a -> Unlifted a > > instance Levity Int where > type Unlifted Int = Int# > box = I# > unbox (I# i) = i > > instance Levity Word where > type Unlifted Word = Word# > box = W# > unbox (W# w) = w > > instance Levity Stuff where > type Unlifted Stuff = Stuff# > box = stuff# > unbox = unStuff# > > type family Rep (a :: Type) :: RuntimeRep where > Rep Int = IntRep > Rep Word = WordRep > Rep Stuff = TupleRep '[ 'IntRep, 'IntRep ] > > type Stuff# = (# Int#, Int# #) > > data Stuff = Stuff Int# Int# > > stuff# :: (# Int#, Int# #) -> Stuff > stuff# (# x, y #) = Stuff x y > > unStuff# :: Stuff -> (# Int#, Int# #) > unStuff# (Stuff x y) = (# x, y #) > }}} > > You may not be able to get away with making `Rep` a closed type family in > the actual program that you're writing, but I thought I'd point it out > nonetheless, since I was myself unaware of this fact until today. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Sun Dec 2 20:42:31 2018 From: lonetiger at gmail.com (Phyx) Date: Sun, 2 Dec 2018 20:42:31 +0000 Subject: Windows test failures In-Reply-To: References: Message-ID: 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 at already, seems to have something to do with the libstdc++ destructors. Plugins 09 and 10 are the other two I know about, but haven't had time to look at them yet. Frankly I know too little about plugins to make an accurate determination here, but the input files are empty yet it expects output, so I don't know what it's supposed to do here. If someone who knows more about plugins can chime in that would save some time. The segfaulting plugin I haven't triaged yet. Now the remaining failures aside from T14452 that Roland is taking care of, seem to have to do with your locale in your console. You seem to be running the tests in a console that has latin-1 locale? So some unicode characters fail encoding/decoding. If it's a Windows shell you can change it to utf-8 using "chcp 65001", if it's an msys2 shell, what does "locale" return? For reference mine is $ locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_ALL= If it does say latin1 you can change it with export LANG=en_GB.UTF-8 This should fix more of the tests. The reason I don't mark the remaining tests as expect fail yet is because I haven't had the time to triage them, so I don't know their severity and last time there were a few nasty issues hidden in them. Unfortunately I won't have time to look at them till next weekend. Thanks, Tamar On Fri, Nov 30, 2018 at 9:49 PM Simon Peyton Jones wrote: > At the end of the first test run it would have given a list of tests that > failed and a line saying TEST=".... List of tests..." > > > > Copy that line and at the root of the checkout do > > > > make TEST=".... List of tests..." test -C testsuite/tests > > > > (that's uppercase C). This will run everything using one thread. :) > > > > OK, done. Results below. > > > > Simon > > > > > > /c/code/HEAD$ make TEST="T10420 T10672_x64 T13385 T14452 T15815 T3307 > T3319 T4006 TH_scopedTvs environment001 plugin-recomp-change > plugin-recomp-flags plugin-recomp-impure plugin-recomp-pure plugins07 > plugins09 plugins10 plugins11 plugins13 plugins14 print017" test -C > testsuite/tests > > make: Entering directory '/c/code/HEAD/testsuite/tests' > > PYTHON="python3" "python3" ../driver/runtests.py -e > "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db > -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output'" -e config.compiler_debugged=False -e > ghc_with_native_codegen=True -e config.have_vanilla=True -e > config.have_dynamic=False -e config.have_profiling=False -e > ghc_with_threaded_rts=True -e ghc_with_dynamic_rts=False -e > config.have_interp=True -e config.unregisterised=False -e > config.have_gdb=False -e config.have_readelf=True -e > config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e > ghc_with_smp=True -e ghc_with_llvm=False -e windows=True -e darwin=False -e > config.in_tree_compiler=True -e config.cleanup=True -e config.local=True > --rootdir=. --config-file=../config/ghc -e > 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e > 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() > or config.timeout' -e 'config.exeext=".exe"' -e > 'config.top="/c/code/HEAD/testsuite"' --config > 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config > 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' > --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config > 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config > 'timeout_prog="../timeout/install-inplace/bin/timeout.exe"' -e > "config.stage=2" --rootdir=../../libraries/Win32/tests > --rootdir=../../libraries/array/tests > --rootdir=../../libraries/base/tests > --rootdir=../../libraries/binary/tests > --rootdir=../../libraries/bytestring/tests > --rootdir=../../libraries/containers/tests > --rootdir=../../libraries/deepseq/tests > --rootdir=../../libraries/directory/tests > --rootdir=../../libraries/filepath/tests > --rootdir=../../libraries/ghc-compact/tests > --rootdir=../../libraries/ghc-heap/tests > --rootdir=../../libraries/ghc-prim/tests > --rootdir=../../libraries/haskeline/tests > --rootdir=../../libraries/hpc/tests > --rootdir=../../libraries/pretty/tests > --rootdir=../../libraries/process/tests > --rootdir=../../libraries/stm/tests > --rootdir=../../libraries/template-haskell/tests > --rootdir=../../libraries/text/tests \ > > --only=T10420 --only=T10672_x64 --only=T13385 --only=T14452 > --only=T15815 --only=T3307 --only=T3319 --only=T4006 > --only=TH_scopedTvs --only=environment001 --only=plugin-recomp-change > --only=plugin-recomp-flags --only=plugin-recomp-impure > --only=plugin-recomp-pure --only=plugins07 --only=plugins09 > --only=plugins10 --only=plugins11 --only=plugins13 --only=plugins14 > --only=print017 \ > > \ > > \ > > \ > > \ > > \ > > > > Timeout is 300 > > 0 > > Found 398 .T files... > > Beginning test run at Fri Nov 30 21:07:17 2018 GMTST > > ====> Scanning ./ado/all.T > > ====> Scanning ./annotations/should_compile/all.T > > ====> Scanning ./annotations/should_compile/T13818/all.T > > …lots more “Scanning” lines… > > ====> Scanning ../../libraries/ghc-heap/tests/all.T > > ====> Scanning ../../libraries/hpc/tests/fork/test.T--- > driver/T14452.run/T14452.stdout.normalised 2018-11-30 > 21:07:36.565566000 +0000 > > +++ driver/T14452.run/T14452.run.stdout.normalised 2018-11-30 > 21:07:36.567569500 +0000 > > @@ -1 +1 @@ > > --O3 > > +"-O3" > > --- libraries/base/tests/T4006.run/T4006.stdout.normalised > 2018-11-30 21:15:19.867313900 +0000 > > +++ libraries/base/tests/T4006.run/T4006.run.stdout.normalised > 2018-11-30 21:15:19.870787900 +0000 > > @@ -1,2 +1,2 @@ > > It works here > > - > > + > > --- > libraries/base/tests/IO/environment001.run/environment001.stdout.normalised > 2018-11-30 21:16:00.645817500 +0000 > > +++ > libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised > 2018-11-30 21:16:00.654738900 +0000 > > @@ -1,7 +1,8 @@ > > - > > -Test 1: 3 > > - > > -Test 2: 1 > > + > > + > > +Test 1: 9 > > + > > +Test 2: 3 > > ! > > Test 3: 3 > > ["a","b"] > > > > ====> Scanning ../../libraries/hpc/tests/function/test.T > > ====> Scanning ../../libraries/hpc/tests/function2/test.T > > ====> Scanning ../../libraries/hpc/tests/ghc_ghci/test.T > > ====> Scanning ../../libraries/hpc/tests/raytrace/test.T > > ====> Scanning ../../libraries/hpc/tests/raytrace/tixs/test.T > > ====> Scanning ../../libraries/hpc/tests/simple/test.T > > ====> Scanning ../../libraries/hpc/tests/simple/tixs/test.T > > ====> Scanning ../../libraries/process/tests/all.T > > ====> Scanning ../../libraries/process/tests/T9775/all.T > > ====> Scanning ../../libraries/stm/tests/all.T > > ====> Scanning ../../libraries/template-haskell/tests/all.T > > =====> T14452(normal) 1 of 21 [0, 0, 0] > > cd "driver/T14452.run" && $MAKE -s --no-print-directory T14452 > > Actual stdout output differs from expected: > > diff -uw "driver/T14452.run/T14452.stdout.normalised" > "driver/T14452.run/T14452.run.stdout.normalised" > > *** unexpected failure for T14452(normal) > > =====> T13385(ghci) 2 of 21 [0, 1, 0] > > cd "ghci/scripts/T13385.run" && > HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output -XRebindableSyntax" > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 > -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XRebindableSyntax < T13385.script > > =====> print017(ghci) 3 of 21 [0, 1, 0] > > cd "ghci.debugger/scripts/print017.run" && > HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output " > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 > -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -ignore-dot-ghci< print017.script > > =====> print017(ghci-ext) 3 of 21 [0, 1, 0] > > cd "ghci.debugger/scripts/print017.run" && > HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output " > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 > -ignore-dot-ghci -fno-ghci-history -fexternal-interpreter +RTS -I0.1 -RTS > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -ignore-dot-ghci< print017.script > > =====> plugin-recomp-change(normal) 4 of 21 [0, 1, 0] > > cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory > plugin-recomp-change > > =====> T10672_x64(normal) 5 of 21 [0, 1, 0] > > cd "rts/T10672/T10672_x64.run" && $MAKE -s --no-print-directory > T10672_x64 > > Timeout happened...killed process "cd "rts/T10672/T10672_x64.run" && $MAKE > -s --no-print-directory T10672_x64 "... > > > > Wrong exit code for T10672_x64()(expected 0 , actual 99 ) > > *** unexpected failure for T10672_x64(normal) > > =====> TH_scopedTvs(normal) 6 of 21 [0, 2, 0] > > cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell -v0 > > =====> TH_scopedTvs(ext-interp) 6 of 21 [0, 2, 0] > > cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -fexternal-interpreter -v0 > > =====> T3319(normal) 7 of 21 [0, 2, 0] > > cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -ddump-splices -v0 > > =====> T3319(ext-interp) 7 of 21 [0, 2, 0] > > cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -fexternal-interpreter -ddump-splices -v0 > > =====> T15815(normal) 8 of 21 [0, 2, 0] > > cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make > T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell -v0 -static > > =====> T15815(ext-interp) 8 of 21 [0, 2, 0] > > cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make > T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -fexternal-interpreter -v0 -static > > =====> T4006(normal) 9 of 21 [0, 2, 0] > > cd "libraries/base/tests/T4006.run" && > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -o T4006 T4006.hs -dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output > > cd "libraries/base/tests/T4006.run" && ./T4006 > > Actual stdout output differs from expected: > > diff -uw "libraries/base/tests/T4006.run/T4006.stdout.normalised" > "libraries/base/tests/T4006.run/T4006.run.stdout.normalised" > > *** unexpected failure for T4006(normal) > > =====> T3307(normal) 10 of 21 [0, 3, 0] > > cd "libraries/base/tests/IO/T3307.run" && $MAKE -s --no-print-directory > T3307-test > > Wrong exit code for T3307()(expected 0 , actual 2 ) > > Stdout ( T3307 ): > > Test 1 > > [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] > > Ni hao > > Test 2 > > [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] > > Ni hao > > Test 3 > > [99,104,105,110,101,115,101,45,102,105,108,101,45,23567,35828] > > Stderr ( T3307 ): > > *** framework failure for T3307(normal) 'latin-1' codec can't encode > characters in position 24-25: ordinal not in range(256) > > =====> environment001(normal) 11 of 21 [0, 3, 1] > > cd "libraries/base/tests/IO/environment001.run" && $MAKE -s > --no-print-directory environment001-test > > Actual stdout output differs from expected: > > diff -uw > "libraries/base/tests/IO/environment001.run/environment001.stdout.normalised" > "libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised" > > *** unexpected failure for environment001(normal) > > =====> plugins07(normal) 12 of 21 [0, 4, 1] > > cd "plugins/plugins07.run" && $MAKE -s --no-print-directory -C > rule-defining-plugin package.plugins07 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins07.run" && $MAKE -s --no-print-directory plugins07 > > =====> plugins09(normal) 13 of 21 [0, 4, 1] > > cd "plugins/plugins09.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins09 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins09.run" && $MAKE -s --no-print-directory plugins09 > > Actual stdout output differs from expected: > > diff -uw "plugins/plugins09.run/plugins09.stdout.normalised" > "plugins/plugins09.run/plugins09.run.stdout.normalised"--- > plugins/plugins09.run/plugins09.stdout.normalised 2018-11-30 > 21:17:20.709370700 +0000 > > +++ plugins/plugins09.run/plugins09.run.stdout.normalised 2018-11-30 > 21:17:20.711314000 +0000 > > @@ -1,9 +0,0 @@ > > -parsePlugin(a,b) > > -interfacePlugin: Prelude > > -interfacePlugin: GHC.Float > > -interfacePlugin: GHC.Base > > -typeCheckPlugin (rn) > > -interfacePlugin: GHC.Types > > -typeCheckPlugin (tc) > > -interfacePlugin: GHC.Integer.Type > > -interfacePlugin: GHC.Natural > > --- plugins/plugins10.run/plugins10.stdout.normalised 2018-11-30 > 21:17:57.644357800 +0000 > > +++ plugins/plugins10.run/plugins10.run.stdout.normalised 2018-11-30 > 21:17:57.646078700 +0000 > > @@ -1,21 +0,0 @@ > > -parsePlugin() > > -interfacePlugin: Prelude > > -interfacePlugin: Language.Haskell.TH > > -interfacePlugin: Language.Haskell.TH.Quote > > -interfacePlugin: GHC.Float > > -interfacePlugin: GHC.Base > > -interfacePlugin: Language.Haskell.TH.Syntax > > -typeCheckPlugin (rn) > > -interfacePlugin: GHC.Types > > -typeCheckPlugin (tc) > > -interfacePlugin: GHC.Integer.Type > > -interfacePlugin: GHC.Natural > > -parsePlugin(a) > > -typeCheckPlugin (rn) > > -interfacePlugin: Language.Haskell.TH.Lib.Internal > > -metaPlugin: return [] > > -metaPlugin: quoteExp stringify "x" > > -interfacePlugin: GHC.CString > > -typeCheckPlugin (rn) > > -typeCheckPlugin (rn) > > -typeCheckPlugin (tc) > > > > *** unexpected failure for plugins09(normal) > > =====> plugins10(normal) 14 of 21 [0, 5, 1] > > cd "plugins/plugins10.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins10 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins10.run" && $MAKE -s --no-print-directory plugins10 > > Actual stdout output differs from expected: > > diff -uw "plugins/plugins10.run/plugins10.stdout.normalised" > "plugins/plugins10.run/plugins10.run.stdout.normalised" > > *** unexpected failure for plugins10(normal) > > =====> plugins11(normal) 15 of 21 [0, 6, 1] > > cd "plugins/plugins11.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins11 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins11.run" && $MAKE -s --no-print-directory plugins11 > > Timeout happened...killed process "cd "plugins/plugins11.run" && $MAKE -s > --no-print-directory plugins11 "... > > > > Wrong exit code for plugins11()(expected 0 , actual 99 ) > > *** unexpected failure for plugins11(normal) > > =====> plugins13(normal) 16 of 21 [0, 7, 1] > > cd "plugins/plugins13.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins13 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins13.run" && $MAKE -s --no-print-directory plugins13 > > =====> plugins14(normal) 17 of 21 [0, 7, 1] > > cd "plugins/plugins14.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins14 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins14.run" && $MAKE -s --no-print-directory plugins14 > > =====> T10420(normal) 18 of 21 [0, 7, 1] > > cd "plugins/T10420.run" && $MAKE -s --no-print-directory -C > rule-defining-plugin package.T10420 TOP=/c/code/HEAD/testsuite > > cd "plugins/T10420.run" && $MAKE -s --no-print-directory T10420 > > =====> plugin-recomp-pure(normal) 19 of 21 [0, 7, 1] > > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory > plugin-recomp-pure > > Timeout happened...killed process "cd "plugins/plugin-recomp-pure.run" && > $MAKE -s --no-print-directory plugin-recomp-pure "... > > > > Wrong exit code for plugin-recomp-pure()(expected 0 , actual 99 ) > > Stdout ( plugin-recomp-pure ): > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) > > Stderr ( plugin-recomp-pure ): > > Simple Plugin Passes Queried > > Got options: > > Simple Plugin Pass Run > > *** unexpected failure for plugin-recomp-pure(normal) > > =====> plugin-recomp-impure(normal) 20 of 21 [0, 8, 1] > > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory > plugin-recomp-impure > > Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) > > Stdout ( plugin-recomp-impure ): > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) > > Linking plugin-recomp-test.exe ... > > [1 of 1] Compiling Main ( plugin-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 reading 0xa824 > > > > Attempting to reconstruct a stack trace... > > > > Frame Code address > > * 0x49adab0 0x1eb49ec 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" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory > plugin-recomp-flags > > Traceback (most recent call last): > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 824, in > test_common_work > > do_test(name, way, func, args, files) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 910, in do_test > > result = func(*[name,way] + args) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 993, in run_command > > return simple_run( name, '', override_options(cmd), '' ) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in simple_run > > dump_stderr(name) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in > dump_stderr > > print(str) > > UnicodeEncodeError: 'latin-1' codec can't encode characters in position > 24-25: ordinal not in range(256) > > > > Unexpected 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 cases, of which > > 11 were skipped > > > > 0 had missing libraries > > 15 expected passes > > 0 expected failures > > > > 1 caused framework failures > > 0 caused framework warnings > > 0 unexpected passes > > 9 unexpected failures > > 0 unexpected stat failures > > > > Unexpected failures: > > driver/T14452.run T14452 [bad stdout] (normal) > > rts/T10672/T10672_x64.run T10672_x64 [bad exit code] > (normal) > > libraries/base/tests/T4006.run T4006 [bad stdout] (normal) > > libraries/base/tests/IO/environment001.run environment001 [bad stdout] > (normal) > > plugins/plugins09.run plugins09 [bad stdout] > (normal) > > plugins/plugins10.run plugins10 [bad stdout] > (normal) > > plugins/plugins11.run plugins11 [bad exit code] > (normal) > > plugins/plugin-recomp-pure.run plugin-recomp-pure [bad > exit code] (normal) > > plugins/plugin-recomp-impure.run plugin-recomp-impure [bad > exit code] (normal) > > > > Framework failures: > > libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec > can't encode characters in position 24-25: ordinal not in range(256)) > > > > Appending 0 stats to git notes. > > make: *** [../mk/test.mk:342: test] Error 1 > > make: Leaving directory '/c/code/HEAD/testsuite/tests' > > /c/code/HEAD$ > > > > > > *From:* Phyx > *Sent:* 30 November 2018 11:58 > *To:* Simon Peyton Jones > *Subject:* Re: Windows test failures > > > > At the end of the first test run it would have given a list of tests that > failed and a line saying TEST=".... List of tests..." > > > > Copy that line and at the root of the checkout do > > > > make TEST=".... List of tests..." test -C testsuite/tests > > > > (that's uppercase C). This will run everything using one thread. :) > > > > Should give a good starting point as to what's wrong. > > > > Kind regards, > > Tamar > > On Fri, Nov 30, 2018, 10:30 Simon Peyton Jones > wrote: > > So I just say > > make TEST > > is that right? > > > > Or is it > > make THREADS=1 > > > > or what? Sorry to be dim > > > > *From:* Phyx > *Sent:* 30 November 2018 08:05 > *To:* Simon Peyton Jones > *Cc:* ghc-devs > *Subject:* Re: Windows test failures > > > > 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 increasingly unstable > under threads for some reason. > > > > I also haven't run trunk yet since last week so they could be new.. > > > > But rerunning the fails with no threads should give a better idea. > > > > Regards, > > Tamar > > On Fri, Nov 30, 2018, 07:46 Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > Ben, Phyx, and other CI folk > > ‘sh validate –fast’ still gives a lot of failures on Window. The output > is below. I would be so good to get this to zero! > > (another minor thing is that it would be great to eliminate the long path > at the beginning – this is platform independent – I have to delete manually > many times each day. > > Thanks > > Simon > > Unexpected passes: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/rts/T9405.run T9405 [unexpected] (normal) > > > > Unexpected failures: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/driver/T14452.run T14452 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/linking/ghcilink001.run ghcilink001 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit > code] (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/scripts/ghci050.run ghci050 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/should_run/T14963a.run T14963a [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit > code] (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/indexed-types/should_fail/T7102a.run T7102a [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-change.run plugin-recomp-change > [bad exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/TH_spliceGuard.run TH_spliceGuard [exit > code non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/TH_overlaps.run TH_overlaps [exit code > non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T5886.run T5886 [exit code non-0] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T10697_decided_3.run T10697_decided_3 [exit > code non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T11629.run T11629 [exit code non-0] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/T4006.run T4006 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/IO/environment001.run environment001 [bad > stdout] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/should_run/T15633b.run T15633b [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins07.run plugins07 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins09.run plugins09 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins10.run plugins10 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins11.run plugins11 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/T10420.run T10420 [bad exit code] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad > exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-impure.run plugin-recomp-impure > [bad exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-flags.run plugin-recomp-flags [bad > exit code] (normal) > > > > Framework failures: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run MultiLayerModules [runTest] > (Unhandled exception during cleanup: Unable to remove folder > '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run': [Errno 13] Permission denied: > '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run' > > Unable to start current test.) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec > can't encode characters in position 24-25: ordinal not in range(256)) > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Sun Dec 2 20:43:22 2018 From: lonetiger at gmail.com (Phyx) Date: Sun, 2 Dec 2018 20:43:22 +0000 Subject: Windows test failures In-Reply-To: <1543648084.2924.1.camel@bluewin.ch> References: <1543648084.2924.1.camel@bluewin.ch> Message-ID: Thanks Roland, I've reviewed the patch in Phab. Cheers, Tamar On Sat, Dec 1, 2018 at 7:08 AM Roland Senn wrote: > For T14452 there is a patch ( https://phabricator.haskell.org/D5398) > ready for review.. > > Roland > > Am Freitag, den 30.11.2018, 21:49 +0000 schrieb Simon Peyton Jones via > ghc-devs: > > At the end of the first test run it would have given a list of tests that > failed and a line saying TEST=".... List of tests..." > > > > Copy that line and at the root of the checkout do > > > > make TEST=".... List of tests..." test -C testsuite/tests > > > > (that's uppercase C). This will run everything using one thread. :) > > > > OK, done. Results below. > > > > Simon > > > > > > /c/code/HEAD$ make TEST="T10420 T10672_x64 T13385 T14452 T15815 T3307 > T3319 T4006 TH_scopedTvs environment001 plugin-recomp-change > plugin-recomp-flags plugin-recomp-impure plugin-recomp-pure plugins07 > plugins09 plugins10 plugins11 plugins13 plugins14 print017" test -C > testsuite/tests > > make: Entering directory '/c/code/HEAD/testsuite/tests' > > PYTHON="python3" "python3" ../driver/runtests.py -e > "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db > -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output'" -e config.compiler_debugged=False -e > ghc_with_native_codegen=True -e config.have_vanilla=True -e > config.have_dynamic=False -e config.have_profiling=False -e > ghc_with_threaded_rts=True -e ghc_with_dynamic_rts=False -e > config.have_interp=True -e config.unregisterised=False -e > config.have_gdb=False -e config.have_readelf=True -e > config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e > ghc_with_smp=True -e ghc_with_llvm=False -e windows=True -e darwin=False -e > config.in_tree_compiler=True -e config.cleanup=True -e config.local=True > --rootdir=. --config-file=../config/ghc -e > 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e > 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() > or config.timeout' -e 'config.exeext=".exe"' -e > 'config.top="/c/code/HEAD/testsuite"' --config > 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config > 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' > --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config > 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config > 'timeout_prog="../timeout/install-inplace/bin/timeout.exe"' -e > "config.stage=2" --rootdir=../../libraries/Win32/tests > --rootdir=../../libraries/array/tests > --rootdir=../../libraries/base/tests > --rootdir=../../libraries/binary/tests > --rootdir=../../libraries/bytestring/tests > --rootdir=../../libraries/containers/tests > --rootdir=../../libraries/deepseq/tests > --rootdir=../../libraries/directory/tests > --rootdir=../../libraries/filepath/tests > --rootdir=../../libraries/ghc-compact/tests > --rootdir=../../libraries/ghc-heap/tests > --rootdir=../../libraries/ghc-prim/tests > --rootdir=../../libraries/haskeline/tests > --rootdir=../../libraries/hpc/tests > --rootdir=../../libraries/pretty/tests > --rootdir=../../libraries/process/tests > --rootdir=../../libraries/stm/tests > --rootdir=../../libraries/template-haskell/tests > --rootdir=../../libraries/text/tests \ > > --only=T10420 --only=T10672_x64 --only=T13385 --only=T14452 > --only=T15815 --only=T3307 --only=T3319 --only=T4006 > --only=TH_scopedTvs --only=environment001 --only=plugin-recomp-change > --only=plugin-recomp-flags --only=plugin-recomp-impure > --only=plugin-recomp-pure --only=plugins07 --only=plugins09 > --only=plugins10 --only=plugins11 --only=plugins13 --only=plugins14 > --only=print017 \ > > \ > > \ > > \ > > \ > > \ > > > > Timeout is 300 > > 0 > > Found 398 .T files... > > Beginning test run at Fri Nov 30 21:07:17 2018 GMTST > > ====> Scanning ./ado/all.T > > ====> Scanning ./annotations/should_compile/all.T > > ====> Scanning ./annotations/should_compile/T13818/all.T > > …lots more “Scanning” lines… > > ====> Scanning ../../libraries/ghc-heap/tests/all.T > > ====> Scanning ../../libraries/hpc/tests/fork/test.T--- > driver/T14452.run/T14452.stdout.normalised 2018-11-30 > 21:07:36.565566000 +0000 > > +++ driver/T14452.run/T14452.run.stdout.normalised 2018-11-30 > 21:07:36.567569500 +0000 > > @@ -1 +1 @@ > > --O3 > > +"-O3" > > --- libraries/base/tests/T4006.run/T4006.stdout.normalised > 2018-11-30 21:15:19.867313900 +0000 > > +++ libraries/base/tests/T4006.run/T4006.run.stdout.normalised > 2018-11-30 21:15:19.870787900 +0000 > > @@ -1,2 +1,2 @@ > > It works here > > - > > + > > --- > libraries/base/tests/IO/environment001.run/environment001.stdout.normalised > 2018-11-30 21:16:00.645817500 +0000 > > +++ > libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised > 2018-11-30 21:16:00.654738900 +0000 > > @@ -1,7 +1,8 @@ > > - > > -Test 1: 3 > > - > > -Test 2: 1 > > + > > + > > +Test 1: 9 > > + > > +Test 2: 3 > > ! > > Test 3: 3 > > ["a","b"] > > > > ====> Scanning ../../libraries/hpc/tests/function/test.T > > ====> Scanning ../../libraries/hpc/tests/function2/test.T > > ====> Scanning ../../libraries/hpc/tests/ghc_ghci/test.T > > ====> Scanning ../../libraries/hpc/tests/raytrace/test.T > > ====> Scanning ../../libraries/hpc/tests/raytrace/tixs/test.T > > ====> Scanning ../../libraries/hpc/tests/simple/test.T > > ====> Scanning ../../libraries/hpc/tests/simple/tixs/test.T > > ====> Scanning ../../libraries/process/tests/all.T > > ====> Scanning ../../libraries/process/tests/T9775/all.T > > ====> Scanning ../../libraries/stm/tests/all.T > > ====> Scanning ../../libraries/template-haskell/tests/all.T > > =====> T14452(normal) 1 of 21 [0, 0, 0] > > cd "driver/T14452.run" && $MAKE -s --no-print-directory T14452 > > Actual stdout output differs from expected: > > diff -uw "driver/T14452.run/T14452.stdout.normalised" > "driver/T14452.run/T14452.run.stdout.normalised" > > *** unexpected failure for T14452(normal) > > =====> T13385(ghci) 2 of 21 [0, 1, 0] > > cd "ghci/scripts/T13385.run" && > HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output -XRebindableSyntax" > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 > -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XRebindableSyntax < T13385.script > > =====> print017(ghci) 3 of 21 [0, 1, 0] > > cd "ghci.debugger/scripts/print017.run" && > HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output " > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 > -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -ignore-dot-ghci< print017.script > > =====> print017(ghci-ext) 3 of 21 [0, 1, 0] > > cd "ghci.debugger/scripts/print017.run" && > HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output " > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 > -ignore-dot-ghci -fno-ghci-history -fexternal-interpreter +RTS -I0.1 -RTS > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -ignore-dot-ghci< print017.script > > =====> plugin-recomp-change(normal) 4 of 21 [0, 1, 0] > > cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory > plugin-recomp-change > > =====> T10672_x64(normal) 5 of 21 [0, 1, 0] > > cd "rts/T10672/T10672_x64.run" && $MAKE -s --no-print-directory > T10672_x64 > > Timeout happened...killed process "cd "rts/T10672/T10672_x64.run" && $MAKE > -s --no-print-directory T10672_x64 "... > > > > Wrong exit code for T10672_x64()(expected 0 , actual 99 ) > > *** unexpected failure for T10672_x64(normal) > > =====> TH_scopedTvs(normal) 6 of 21 [0, 2, 0] > > cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell -v0 > > =====> TH_scopedTvs(ext-interp) 6 of 21 [0, 2, 0] > > cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -fexternal-interpreter -v0 > > =====> T3319(normal) 7 of 21 [0, 2, 0] > > cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -ddump-splices -v0 > > =====> T3319(ext-interp) 7 of 21 [0, 2, 0] > > cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -fexternal-interpreter -ddump-splices -v0 > > =====> T15815(normal) 8 of 21 [0, 2, 0] > > cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make > T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell -v0 -static > > =====> T15815(ext-interp) 8 of 21 [0, 2, 0] > > cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make > T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -fexternal-interpreter -v0 -static > > =====> T4006(normal) 9 of 21 [0, 2, 0] > > cd "libraries/base/tests/T4006.run" && > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -o T4006 T4006.hs -dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output > > cd "libraries/base/tests/T4006.run" && ./T4006 > > Actual stdout output differs from expected: > > diff -uw "libraries/base/tests/T4006.run/T4006.stdout.normalised" > "libraries/base/tests/T4006.run/T4006.run.stdout.normalised" > > *** unexpected failure for T4006(normal) > > =====> T3307(normal) 10 of 21 [0, 3, 0] > > cd "libraries/base/tests/IO/T3307.run" && $MAKE -s --no-print-directory > T3307-test > > Wrong exit code for T3307()(expected 0 , actual 2 ) > > Stdout ( T3307 ): > > Test 1 > > [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] > > Ni hao > > Test 2 > > [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] > > Ni hao > > Test 3 > > [99,104,105,110,101,115,101,45,102,105,108,101,45,23567,35828] > > Stderr ( T3307 ): > > *** framework failure for T3307(normal) 'latin-1' codec can't encode > characters in position 24-25: ordinal not in range(256) > > =====> environment001(normal) 11 of 21 [0, 3, 1] > > cd "libraries/base/tests/IO/environment001.run" && $MAKE -s > --no-print-directory environment001-test > > Actual stdout output differs from expected: > > diff -uw > "libraries/base/tests/IO/environment001.run/environment001.stdout.normalised" > "libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised" > > *** unexpected failure for environment001(normal) > > =====> plugins07(normal) 12 of 21 [0, 4, 1] > > cd "plugins/plugins07.run" && $MAKE -s --no-print-directory -C > rule-defining-plugin package.plugins07 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins07.run" && $MAKE -s --no-print-directory plugins07 > > =====> plugins09(normal) 13 of 21 [0, 4, 1] > > cd "plugins/plugins09.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins09 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins09.run" && $MAKE -s --no-print-directory plugins09 > > Actual stdout output differs from expected: > > diff -uw "plugins/plugins09.run/plugins09.stdout.normalised" > "plugins/plugins09.run/plugins09.run.stdout.normalised"--- > plugins/plugins09.run/plugins09.stdout.normalised 2018-11-30 > 21:17:20.709370700 +0000 > > +++ plugins/plugins09.run/plugins09.run.stdout.normalised 2018-11-30 > 21:17:20.711314000 +0000 > > @@ -1,9 +0,0 @@ > > -parsePlugin(a,b) > > -interfacePlugin: Prelude > > -interfacePlugin: GHC.Float > > -interfacePlugin: GHC.Base > > -typeCheckPlugin (rn) > > -interfacePlugin: GHC.Types > > -typeCheckPlugin (tc) > > -interfacePlugin: GHC.Integer.Type > > -interfacePlugin: GHC.Natural > > --- plugins/plugins10.run/plugins10.stdout.normalised 2018-11-30 > 21:17:57.644357800 +0000 > > +++ plugins/plugins10.run/plugins10.run.stdout.normalised 2018-11-30 > 21:17:57.646078700 +0000 > > @@ -1,21 +0,0 @@ > > -parsePlugin() > > -interfacePlugin: Prelude > > -interfacePlugin: Language.Haskell.TH > > -interfacePlugin: Language.Haskell.TH.Quote > > -interfacePlugin: GHC.Float > > -interfacePlugin: GHC.Base > > -interfacePlugin: Language.Haskell.TH.Syntax > > -typeCheckPlugin (rn) > > -interfacePlugin: GHC.Types > > -typeCheckPlugin (tc) > > -interfacePlugin: GHC.Integer.Type > > -interfacePlugin: GHC.Natural > > -parsePlugin(a) > > -typeCheckPlugin (rn) > > -interfacePlugin: Language.Haskell.TH.Lib.Internal > > -metaPlugin: return [] > > -metaPlugin: quoteExp stringify "x" > > -interfacePlugin: GHC.CString > > -typeCheckPlugin (rn) > > -typeCheckPlugin (rn) > > -typeCheckPlugin (tc) > > > > *** unexpected failure for plugins09(normal) > > =====> plugins10(normal) 14 of 21 [0, 5, 1] > > cd "plugins/plugins10.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins10 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins10.run" && $MAKE -s --no-print-directory plugins10 > > Actual stdout output differs from expected: > > diff -uw "plugins/plugins10.run/plugins10.stdout.normalised" > "plugins/plugins10.run/plugins10.run.stdout.normalised" > > *** unexpected failure for plugins10(normal) > > =====> plugins11(normal) 15 of 21 [0, 6, 1] > > cd "plugins/plugins11.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins11 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins11.run" && $MAKE -s --no-print-directory plugins11 > > Timeout happened...killed process "cd "plugins/plugins11.run" && $MAKE -s > --no-print-directory plugins11 "... > > > > Wrong exit code for plugins11()(expected 0 , actual 99 ) > > *** unexpected failure for plugins11(normal) > > =====> plugins13(normal) 16 of 21 [0, 7, 1] > > cd "plugins/plugins13.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins13 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins13.run" && $MAKE -s --no-print-directory plugins13 > > =====> plugins14(normal) 17 of 21 [0, 7, 1] > > cd "plugins/plugins14.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins14 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins14.run" && $MAKE -s --no-print-directory plugins14 > > =====> T10420(normal) 18 of 21 [0, 7, 1] > > cd "plugins/T10420.run" && $MAKE -s --no-print-directory -C > rule-defining-plugin package.T10420 TOP=/c/code/HEAD/testsuite > > cd "plugins/T10420.run" && $MAKE -s --no-print-directory T10420 > > =====> plugin-recomp-pure(normal) 19 of 21 [0, 7, 1] > > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory > plugin-recomp-pure > > Timeout happened...killed process "cd "plugins/plugin-recomp-pure.run" && > $MAKE -s --no-print-directory plugin-recomp-pure "... > > > > Wrong exit code for plugin-recomp-pure()(expected 0 , actual 99 ) > > Stdout ( plugin-recomp-pure ): > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) > > Stderr ( plugin-recomp-pure ): > > Simple Plugin Passes Queried > > Got options: > > Simple Plugin Pass Run > > *** unexpected failure for plugin-recomp-pure(normal) > > =====> plugin-recomp-impure(normal) 20 of 21 [0, 8, 1] > > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory > plugin-recomp-impure > > Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) > > Stdout ( plugin-recomp-impure ): > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) > > Linking plugin-recomp-test.exe ... > > [1 of 1] Compiling Main ( plugin-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 reading 0xa824 > > > > Attempting to reconstruct a stack trace... > > > > Frame Code address > > * 0x49adab0 0x1eb49ec 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" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory > plugin-recomp-flags > > Traceback (most recent call last): > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 824, in > test_common_work > > do_test(name, way, func, args, files) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 910, in do_test > > result = func(*[name,way] + args) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 993, in run_command > > return simple_run( name, '', override_options(cmd), '' ) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in simple_run > > dump_stderr(name) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in > dump_stderr > > print(str) > > UnicodeEncodeError: 'latin-1' codec can't encode characters in position > 24-25: ordinal not in range(256) > > > > Unexpected 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 cases, of which > > 11 were skipped > > > > 0 had missing libraries > > 15 expected passes > > 0 expected failures > > > > 1 caused framework failures > > 0 caused framework warnings > > 0 unexpected passes > > 9 unexpected failures > > 0 unexpected stat failures > > > > Unexpected failures: > > driver/T14452.run T14452 [bad stdout] (normal) > > rts/T10672/T10672_x64.run T10672_x64 [bad exit code] > (normal) > > libraries/base/tests/T4006.run T4006 [bad stdout] (normal) > > libraries/base/tests/IO/environment001.run environment001 [bad stdout] > (normal) > > plugins/plugins09.run plugins09 [bad stdout] > (normal) > > plugins/plugins10.run plugins10 [bad stdout] > (normal) > > plugins/plugins11.run plugins11 [bad exit code] > (normal) > > plugins/plugin-recomp-pure.run plugin-recomp-pure [bad > exit code] (normal) > > plugins/plugin-recomp-impure.run plugin-recomp-impure [bad > exit code] (normal) > > > > Framework failures: > > libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec > can't encode characters in position 24-25: ordinal not in range(256)) > > > > Appending 0 stats to git notes. > > make: *** [../mk/test.mk:342: test] Error 1 > > make: Leaving directory '/c/code/HEAD/testsuite/tests' > > /c/code/HEAD$ > > > > > > *From:* Phyx > *Sent:* 30 November 2018 11:58 > *To:* Simon Peyton Jones > *Subject:* Re: Windows test failures > > > > At the end of the first test run it would have given a list of tests that > failed and a line saying TEST=".... List of tests..." > > > > Copy that line and at the root of the checkout do > > > > make TEST=".... List of tests..." test -C testsuite/tests > > > > (that's uppercase C). This will run everything using one thread. :) > > > > Should give a good starting point as to what's wrong. > > > > Kind regards, > > Tamar > > On Fri, Nov 30, 2018, 10:30 Simon Peyton Jones > wrote: > > So I just say > > make TEST > > is that right? > > > > Or is it > > make THREADS=1 > > > > or what? Sorry to be dim > > > > *From:* Phyx > *Sent:* 30 November 2018 08:05 > *To:* Simon Peyton Jones > *Cc:* ghc-devs > *Subject:* Re: Windows test failures > > > > 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 increasingly unstable > under threads for some reason. > > > > I also haven't run trunk yet since last week so they could be new.. > > > > But rerunning the fails with no threads should give a better idea. > > > > Regards, > > Tamar > > On Fri, Nov 30, 2018, 07:46 Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > Ben, Phyx, and other CI folk > > ‘sh validate –fast’ still gives a lot of failures on Window. The output > is below. I would be so good to get this to zero! > > (another minor thing is that it would be great to eliminate the long path > at the beginning – this is platform independent – I have to delete manually > many times each day. > > Thanks > > Simon > > Unexpected passes: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/rts/T9405.run T9405 [unexpected] (normal) > > > > Unexpected failures: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/driver/T14452.run T14452 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/linking/ghcilink001.run ghcilink001 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit > code] (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/scripts/ghci050.run ghci050 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/should_run/T14963a.run T14963a [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit > code] (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/indexed-types/should_fail/T7102a.run T7102a [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-change.run plugin-recomp-change > [bad exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/TH_spliceGuard.run TH_spliceGuard [exit > code non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/TH_overlaps.run TH_overlaps [exit code > non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T5886.run T5886 [exit code non-0] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T10697_decided_3.run T10697_decided_3 [exit > code non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T11629.run T11629 [exit code non-0] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/T4006.run T4006 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/IO/environment001.run environment001 [bad > stdout] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/should_run/T15633b.run T15633b [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins07.run plugins07 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins09.run plugins09 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins10.run plugins10 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins11.run plugins11 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/T10420.run T10420 [bad exit code] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad > exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-impure.run plugin-recomp-impure > [bad exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-flags.run plugin-recomp-flags [bad > exit code] (normal) > > > > Framework failures: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run MultiLayerModules [runTest] > (Unhandled exception during cleanup: Unable to remove folder > '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run': [Errno 13] Permission denied: > '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run' > > Unable to start current test.) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec > can't encode characters in position 24-25: ordinal not in range(256)) > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsx at bluewin.ch Mon Dec 3 15:34:58 2018 From: rsx at bluewin.ch (Roland Senn) Date: Mon, 03 Dec 2018 16:34:58 +0100 Subject: Windows test failures In-Reply-To: References: Message-ID: <1543851298.2411.1.camel@bluewin.ch> 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 in the do block of the function '.../testuite/tests/plugins/simple- plugin/Simple/SourcePlugin.hs:parsedPlugin' then all 3 tests pass successfully on Windows! I don't know anything about the "Why" and "Where" in the GHC IO module on Windows, so I'm unable to come up with a patch. Regards   Roland PS: I can't say anything about the tests 'plugin-recomp-pure' and 'plugin-recomp-impure' as these tests run successfully on my (slow) Windows box. Am Sonntag, den 02.12.2018, 20:42 +0000 schrieb Phyx: > 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 at already, seems to > have something to do with the libstdc++ destructors. > Plugins 09 and 10 are the other two I know about, but haven't had > time to look at them yet. Frankly I know too little about plugins to > make an accurate determination here, but the input files are empty > yet it expects output, so I don't know what it's supposed to do > here.  If someone who knows more about plugins can chime in that > would save some time. > > The segfaulting plugin I haven't triaged yet. Now the remaining > failures aside from T14452 that Roland is taking care of, seem to > have to do with your locale in your console.  You seem to be running > the > tests in a console that has latin-1 locale? So some unicode > characters fail encoding/decoding. > > If it's a Windows shell you can change it to utf-8 using "chcp  > 65001", if it's an msys2 shell, what does "locale" return? > > For reference mine is > > $ locale > LANG=en_GB.UTF-8 > LC_CTYPE="en_GB.UTF-8" > LC_NUMERIC="en_GB.UTF-8" > LC_TIME="en_GB.UTF-8" > LC_COLLATE="en_GB.UTF-8" > LC_MONETARY="en_GB.UTF-8" > LC_MESSAGES="en_GB.UTF-8" > LC_ALL= > > If it does say latin1 you can change it with > > export  > LANG=en_GB.UTF-8  > > This should fix more of the tests. > > The reason I don't mark the remaining tests as expect fail yet is > because I haven't had the time to triage them, so I don't know their > severity and > last time there were a few nasty issues hidden in them. > > Unfortunately I won't have time to look at them till next weekend. > > Thanks, > Tamar > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnguyen1 at brynmawr.edu Mon Dec 3 17:09:11 2018 From: mnguyen1 at brynmawr.edu (My Nguyen) Date: Mon, 3 Dec 2018 17:09:11 +0000 Subject: Cabal not updated after rebase? In-Reply-To: References: Message-ID: Hi all, I've finished quite a big rebase and was trying to rebuild, but it failed with: ghc-cabal: Encountered missing dependencies: Cabal ==2.5.* I then tried applying my patch on a fresh checkout of GHC and found the reason: libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:119:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Binary.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Binary differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Binary (if these names look the same, try again with -dppr-debug) | 119 |import Distribution.Compat.Binary (Binary (..)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:120:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Semigroup.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Semigroup differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Semigroup (if these names look the same, try again with -dppr-debug) | 120 |import Distribution.Compat.Semigroup (Semigroup (..), gmappend, gmempty) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:141:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Stack.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Stack differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Stack (if these names look the same, try again with -dppr-debug) | 141 |import Distribution.Compat.Stack | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm sure I did `git module update`; I even `git clean` everything and `make` from fresh but somehow the cabal still isn't updated. Can anyone help me on why this is happening and how to fix it? Thanks so much, My -------------- next part -------------- An HTML attachment was scrubbed... URL: From krz.gogolewski at gmail.com Mon Dec 3 19:46:35 2018 From: krz.gogolewski at gmail.com (Krzysztof Gogolewski) Date: Mon, 3 Dec 2018 20:46:35 +0100 Subject: Cabal not updated after rebase? In-Reply-To: References: Message-ID: Hi, Does `git clean -fdx .` in libraries/Cabal help? git clean doesn't go into submodules. -Krzysztof On Mon, Dec 3, 2018 at 6:09 PM My Nguyen wrote: > Hi all, > > > I've finished quite a big rebase and was trying to rebuild, but it failed > with: > > ghc-cabal: Encountered missing dependencies: > Cabal ==2.5.* > > I then tried applying my patch on a fresh checkout of GHC and found the > reason: > > *libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:119:1:**error:* > > * Bad interface file: > libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Binary.hi* > > * Something is amiss; requested module > Cabal-2.4.0.1:Distribution.Compat.Binary differs from name found in the > interface file Cabal-2.5.0.0:Distribution.Compat.Binary (if these names > look the same, try again with -dppr-debug)* > > * |* > > *119 |**import Distribution.Compat.Binary (Binary (..))* > > * |** ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^* > > > *libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:120:1:**error:* > > * Bad interface file: > libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Semigroup.hi* > > * Something is amiss; requested module > Cabal-2.4.0.1:Distribution.Compat.Semigroup differs from name found in the > interface file Cabal-2.5.0.0:Distribution.Compat.Semigroup (if these names > look the same, try again with -dppr-debug)* > > * |* > > *120 |**import Distribution.Compat.Semigroup (Semigroup (..), gmappend, > gmempty)* > > * |** > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^* > > > *libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:141:1:**error:* > > * Bad interface file: > libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Stack.hi* > > * Something is amiss; requested module > Cabal-2.4.0.1:Distribution.Compat.Stack differs from name found in the > interface file Cabal-2.5.0.0:Distribution.Compat.Stack (if these names look > the same, try again with -dppr-debug)* > > * |* > > *141 |**import Distribution.Compat.Stack* > > * |** ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^* > > > I'm sure I did `git module update`; I even `git clean` everything and > `make` from fresh but somehow the cabal still isn't updated. Can anyone > help me on why this is happening and how to fix it? > > > Thanks so much, > > My > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnguyen1 at brynmawr.edu Mon Dec 3 20:13:51 2018 From: mnguyen1 at brynmawr.edu (My Nguyen) Date: Mon, 3 Dec 2018 20:13:51 +0000 Subject: Cabal not updated after rebase? In-Reply-To: References: , Message-ID: Hello, Thanks for the suggestion. Unfortunately, the problem persists :(! My ________________________________ From: Krzysztof Gogolewski Sent: Monday, December 3, 2018 2:46 PM To: My Nguyen Cc: ghc-devs at haskell.org Subject: Re: Cabal not updated after rebase? Hi, Does `git clean -fdx .` in libraries/Cabal help? git clean doesn't go into submodules. -Krzysztof On Mon, Dec 3, 2018 at 6:09 PM My Nguyen > wrote: Hi all, I've finished quite a big rebase and was trying to rebuild, but it failed with: ghc-cabal: Encountered missing dependencies: Cabal ==2.5.* I then tried applying my patch on a fresh checkout of GHC and found the reason: libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:119:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Binary.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Binary differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Binary (if these names look the same, try again with -dppr-debug) | 119 |import Distribution.Compat.Binary (Binary (..)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:120:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Semigroup.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Semigroup differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Semigroup (if these names look the same, try again with -dppr-debug) | 120 |import Distribution.Compat.Semigroup (Semigroup (..), gmappend, gmempty) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:141:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Stack.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Stack differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Stack (if these names look the same, try again with -dppr-debug) | 141 |import Distribution.Compat.Stack | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm sure I did `git module update`; I even `git clean` everything and `make` from fresh but somehow the cabal still isn't updated. Can anyone help me on why this is happening and how to fix it? Thanks so much, My _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Tue Dec 4 00:02:57 2018 From: lonetiger at gmail.com (Phyx) Date: Tue, 4 Dec 2018 00:02:57 +0000 Subject: Windows test failures In-Reply-To: <1543851298.2411.1.camel@bluewin.ch> References: <1543851298.2411.1.camel@bluewin.ch> Message-ID: 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 will always default to LineBuffering for terminals and BlockBuffering for anything else. The issue is that msys2 terminals have std handles that are backed by files instead of pipes. This is an artifact of how they try to emulate posix shells, See https://github.com/msys2/msys2/wiki/Porting#standard-streams-in-mintty. This means that when GHC runs inside an msys2 program such as bash it'll always default to BlockBuffering. > I don't know anything about the "Why" and "Where" in the GHC IO module on Windows, so I'm unable to come up with a patch. The above said the handles should be getting flushed when the finalizers are run, but these aren't 100% guaranteed so if the tests rely on this then your solution (to force buffer mode to LineBuffering) sounds like perfectly adequate. Could you put a patch up with that? My new I/O manager takes a different approach to determine the buffer mode, but I still have some kinks to work out before posting it. > PS: I can't say anything about the tests 'plugin-recomp-pure' and 'plugin-recomp-impure' as these tests run successfully on my (slow) Windows box. These don't fail for me or harbormaster either, so if Simon is able to consistently reproduce these then I'll have to ask him for a core dump so I can take a look. Thanks again, I appreciate the help! Regards, Tamar On Mon, Dec 3, 2018 at 3:34 PM Roland Senn wrote: > 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 in the do block of the function > '.../testuite/tests/plugins/simple-plugin/Simple/SourcePlugin.hs:parsedPlugin' > then all 3 tests pass successfully on Windows! > > I don't know anything about the "Why" and "Where" in the GHC IO module on > Windows, so I'm unable to come up with a patch. > > Regards > Roland > > PS: I can't say anything about the tests 'plugin-recomp-pure' and > 'plugin-recomp-impure' as these tests run successfully on my (slow) Windows > box. > > Am Sonntag, den 02.12.2018, 20:42 +0000 schrieb Phyx: > > 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 at already, seems to have > something to do with the libstdc++ destructors. > Plugins 09 and 10 are the other two I know about, but haven't had time to > look at them yet. Frankly I know too little about plugins to make an > accurate determination here, but the input files are empty > yet it expects output, so I don't know what it's supposed to do here. If > someone who knows more about plugins can chime in that would save some time. > > The segfaulting plugin I haven't triaged yet. Now the remaining failures > aside from T14452 that Roland is taking care of, seem to have to do with > your locale in your console. You seem to be running the > tests in a console that has latin-1 locale? So some unicode characters > fail encoding/decoding. > > If it's a Windows shell you can change it to utf-8 using "chcp 65001", if > it's an msys2 shell, what does "locale" return? > > For reference mine is > > $ locale > LANG=en_GB.UTF-8 > LC_CTYPE="en_GB.UTF-8" > LC_NUMERIC="en_GB.UTF-8" > LC_TIME="en_GB.UTF-8" > LC_COLLATE="en_GB.UTF-8" > LC_MONETARY="en_GB.UTF-8" > LC_MESSAGES="en_GB.UTF-8" > LC_ALL= > > If it does say latin1 you can change it with > > export LANG=en_GB.UTF-8 > > This should fix more of the tests. > > The reason I don't mark the remaining tests as expect fail yet is because > I haven't had the time to triage them, so I don't know their severity and > last time there were a few nasty issues hidden in them. > > Unfortunately I won't have time to look at them till next weekend. > > Thanks, > Tamar > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Tue Dec 4 01:26:32 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 3 Dec 2018 17:26:32 -0800 Subject: Cabal not updated after rebase? In-Reply-To: References: Message-ID: <1ED9BF98-185D-43D5-AFEF-374C1D6D4C6D@cs.brynmawr.edu> Did you change the Cabal submodule at all in your work? Maybe it's out of sync somehow... What happens if you build GHC without including your changes? Does it work? > On Dec 3, 2018, at 12:13 PM, My Nguyen wrote: > > Hello, > > Thanks for the suggestion. Unfortunately, the problem persists :(! > > My > > From: Krzysztof Gogolewski > Sent: Monday, December 3, 2018 2:46 PM > To: My Nguyen > Cc: ghc-devs at haskell.org > Subject: Re: Cabal not updated after rebase? > > Hi, > > Does `git clean -fdx .` in libraries/Cabal help? git clean doesn't go into submodules. > > -Krzysztof > > On Mon, Dec 3, 2018 at 6:09 PM My Nguyen > wrote: > Hi all, > > I've finished quite a big rebase and was trying to rebuild, but it failed with: >>> ghc-cabal: Encountered missing dependencies: >>> Cabal ==2.5.* > I then tried applying my patch on a fresh checkout of GHC and found the reason: > > > libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:119:1:error: > Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Binary.hi > Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Binary differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Binary (if these names look the same, try again with -dppr-debug) > | > 119 |import Distribution.Compat.Binary (Binary (..)) > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:120:1:error: > Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Semigroup.hi > Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Semigroup differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Semigroup (if these names look the same, try again with -dppr-debug) > | > 120 |import Distribution.Compat.Semigroup (Semigroup (..), gmappend, gmempty) > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:141:1:error: > Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Stack.hi > Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Stack differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Stack (if these names look the same, try again with -dppr-debug) > | > 141 |import Distribution.Compat.Stack > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > I'm sure I did `git module update`; I even `git clean` everything and `make` from fresh but somehow the cabal still isn't updated. Can anyone help me on why this is happening and how to fix it? > > Thanks so much, > My > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.hallahan at yale.edu Tue Dec 4 02:10:48 2018 From: william.hallahan at yale.edu (Bill Hallahan) Date: Mon, 3 Dec 2018 21:10:48 -0500 Subject: GHC (API?) question: GHC Core for Base libraries Message-ID: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> Hi, I'm writing a program analyzer that operates on GHC Core. Currently, I'm using the GHC API to get Core from .hs files. I'd like to be able to run this analysis on the standard libraries that come with GHC, which requires getting those as Core. Unfortunately, the build process for these libraries is not entirely straightforward, and relies on a make script. I eventually came up with the plan of writing a GHC plugin, which, rather than performing any optimizations, would simply run the analysis, and then print the results out to a file. I was able to write the plugin successfully, and test it on several files that were not from the base library. Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that the make script would call the plugin. I ended up with the following: GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -v The two package databases are to get to (1) the GHC API and (2) the plugin ("hplugin") itself. With this I get an error message, which I have not been able to find a way to resolve: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o : not built for interactive use - can't load plugins (HPlugin.Plugin) make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 make: *** [all] Error 2 So I'm now wondering (an answer to either of these two questions would be helpful): (1) Is this a viable path? That is, is it possible to use a plugin when building Base? If so, does anyone know what I might be doing wrong/what could be causing this error message? (2) Is there some other better/easier way I could get Core representations of the standard libraries? I guess, in theory, it must be possible to compile the standard libraries with the GHC API, but I have no idea how/where to look to figure out how? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mnguyen1 at brynmawr.edu Tue Dec 4 02:27:12 2018 From: mnguyen1 at brynmawr.edu (My Nguyen) Date: Tue, 4 Dec 2018 02:27:12 +0000 Subject: Cabal not updated after rebase? In-Reply-To: <1ED9BF98-185D-43D5-AFEF-374C1D6D4C6D@cs.brynmawr.edu> References: , <1ED9BF98-185D-43D5-AFEF-374C1D6D4C6D@cs.brynmawr.edu> Message-ID: I did not touch Cabal at all, but somehow `git status` in libraries/Cabal is telling me there’s a detached HEAD? I built GHC with a fresh checkout from github, and it worked. But after applying my patch, it doesn’t work anymore. ________________________________ From: Richard Eisenberg Sent: Monday, December 3, 2018 8:26 PM To: My Nguyen Cc: Krzysztof Gogolewski; ghc-devs at haskell.org Subject: Re: Cabal not updated after rebase? Did you change the Cabal submodule at all in your work? Maybe it's out of sync somehow... What happens if you build GHC without including your changes? Does it work? On Dec 3, 2018, at 12:13 PM, My Nguyen > wrote: Hello, Thanks for the suggestion. Unfortunately, the problem persists :(! My ________________________________ From: Krzysztof Gogolewski > Sent: Monday, December 3, 2018 2:46 PM To: My Nguyen Cc: ghc-devs at haskell.org Subject: Re: Cabal not updated after rebase? Hi, Does `git clean -fdx .` in libraries/Cabal help? git clean doesn't go into submodules. -Krzysztof On Mon, Dec 3, 2018 at 6:09 PM My Nguyen > wrote: Hi all, I've finished quite a big rebase and was trying to rebuild, but it failed with: ghc-cabal: Encountered missing dependencies: Cabal ==2.5.* I then tried applying my patch on a fresh checkout of GHC and found the reason: libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:119:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Binary.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Binary differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Binary (if these names look the same, try again with -dppr-debug) | 119 |import Distribution.Compat.Binary (Binary (..)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:120:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Semigroup.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Semigroup differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Semigroup (if these names look the same, try again with -dppr-debug) | 120 |import Distribution.Compat.Semigroup (Semigroup (..), gmappend, gmempty) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:141:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Stack.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Stack differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Stack (if these names look the same, try again with -dppr-debug) | 141 |import Distribution.Compat.Stack | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm sure I did `git module update`; I even `git clean` everything and `make` from fresh but somehow the cabal still isn't updated. Can anyone help me on why this is happening and how to fix it? Thanks so much, My _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Tue Dec 4 02:34:54 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 3 Dec 2018 18:34:54 -0800 Subject: Cabal not updated after rebase? In-Reply-To: References: <1ED9BF98-185D-43D5-AFEF-374C1D6D4C6D@cs.brynmawr.edu> Message-ID: <063D3406-1D8B-4964-98E0-BDD7CA2FB0E8@cs.brynmawr.edu> Detached HEADs are normal with submodules. (I suppose sentences like that would have gotten me executed several centuries ago...) When I look at https://github.com/mynguyenbmc/ghc/compare/93a3f9070d5d69ad6a28fe94ccccd20c54609698...wip/kind-app , which is, I believe, the difference between GHC HEAD and your branch, I see that the Cabal submodule has changed. I imagine you didn't mean to do this. (This has happened to me with an ill-timed `git add -u` while rebasing. Perhaps that's what caused the trouble for you, too.) To fix, you can manually `git checkout abcdefabcdef` each erroneously changed submodule to point to the right commit from HEAD. Then, `git add` each submodule in the ghc repo (i.e. not inside any submodule) and try again. I hope this helps! Richard > On Dec 3, 2018, at 6:27 PM, My Nguyen wrote: > > I did not touch Cabal at all, but somehow `git status` in libraries/Cabal is telling me there’s a detached HEAD? > > I built GHC with a fresh checkout from github, and it worked. But after applying my patch, it doesn’t work anymore. > From: Richard Eisenberg > Sent: Monday, December 3, 2018 8:26 PM > To: My Nguyen > Cc: Krzysztof Gogolewski; ghc-devs at haskell.org > Subject: Re: Cabal not updated after rebase? > > Did you change the Cabal submodule at all in your work? Maybe it's out of sync somehow... > > What happens if you build GHC without including your changes? Does it work? > >> On Dec 3, 2018, at 12:13 PM, My Nguyen > wrote: >> >> Hello, >> >> Thanks for the suggestion. Unfortunately, the problem persists :(! >> >> My >> >> From: Krzysztof Gogolewski > >> Sent: Monday, December 3, 2018 2:46 PM >> To: My Nguyen >> Cc: ghc-devs at haskell.org >> Subject: Re: Cabal not updated after rebase? >> >> Hi, >> >> Does `git clean -fdx .` in libraries/Cabal help? git clean doesn't go into submodules. >> >> -Krzysztof >> >> On Mon, Dec 3, 2018 at 6:09 PM My Nguyen > wrote: >> Hi all, >> >> I've finished quite a big rebase and was trying to rebuild, but it failed with: >>>> ghc-cabal: Encountered missing dependencies: >>>> Cabal ==2.5.* >> I then tried applying my patch on a fresh checkout of GHC and found the reason: >> >> >> libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:119:1:error: >> Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Binary.hi >> Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Binary differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Binary (if these names look the same, try again with -dppr-debug) >> | >> 119 |import Distribution.Compat.Binary (Binary (..)) >> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:120:1:error: >> Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Semigroup.hi >> Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Semigroup differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Semigroup (if these names look the same, try again with -dppr-debug) >> | >> 120 |import Distribution.Compat.Semigroup (Semigroup (..), gmappend, gmempty) >> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:141:1:error: >> Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Stack.hi >> Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Stack differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Stack (if these names look the same, try again with -dppr-debug) >> | >> 141 |import Distribution.Compat.Stack >> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >> I'm sure I did `git module update`; I even `git clean` everything and `make` from fresh but somehow the cabal still isn't updated. Can anyone help me on why this is happening and how to fix it? >> >> Thanks so much, >> My >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.shao at tweag.io Tue Dec 4 03:09:40 2018 From: cheng.shao at tweag.io (Shao, Cheng) Date: Tue, 4 Dec 2018 11:09:40 +0800 Subject: GHC (API?) question: GHC Core for Base libraries In-Reply-To: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> References: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> Message-ID: Hi, Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is a good example of using a vanilla ghc installation to compile standard libraries like base. On Tue, Dec 4, 2018, 10:11 AM Bill Hallahan wrote: > Hi, > > I'm writing a program analyzer that operates on GHC Core. Currently, I'm > using the GHC API to get Core from .hs files. I'd like to be able to run > this analysis on the standard libraries that come with GHC, which requires > getting those as Core. > > Unfortunately, the build process for these libraries is not entirely > straightforward, and relies on a make script. I eventually came up with > the plan of writing a GHC plugin, which, rather than performing any > optimizations, would simply run the analysis, and then print the results > out to a file. I was able to write the plugin successfully, and test it on > several files that were *not* from the base library. > > Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that > the make script would call the plugin. I ended up with the following: > > GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d > -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d > -package hplugin -fplugin HPlugin.Plugin -v > > The two package databases are to get to (1) the GHC API and (2) the plugin > ("hplugin") itself. With this I get an error message, which I have not > been able to find a way to resolve: > > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O > -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i > -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build > -ilibraries/ghc-prim/dist-install/build/autogen > -Ilibraries/ghc-prim/dist-install/build > -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. > -optP-include > -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h > -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db > /usr/local/lib/ghc-8.0.2/package.conf.d -package-db > /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package > hplugin -fplugin HPlugin.Plugin -no-user-package-db -rtsopts > -Wno-trustworthy-safe -Wno-deprecated-flags > -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build > -hidir libraries/ghc-prim/dist-install/build -stubdir > libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c > libraries/ghc-prim/./GHC/Types.hs -o > libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno > libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o > : not built for interactive use - can't load plugins > (HPlugin.Plugin) > make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 > make: *** [all] Error 2 > > So I'm now wondering (an answer to either of these two questions would be > helpful): > (1) Is this a viable path? That is, is it possible to use a plugin when > building Base? If so, does anyone know what I might be doing wrong/what > could be causing this error message? > (2) Is there some other better/easier way I could get Core representations > of the standard libraries? I guess, in theory, it must be possible to > compile the standard libraries with the GHC API, but I have no idea > how/where to look to figure out how? > > Thanks, > Bill > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Dec 4 04:10:23 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 3 Dec 2018 23:10:23 -0500 Subject: GHC (API?) question: GHC Core for Base libraries In-Reply-To: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> References: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> Message-ID: The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work. On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan wrote: > Hi, > > I'm writing a program analyzer that operates on GHC Core. Currently, I'm > using the GHC API to get Core from .hs files. I'd like to be able to run > this analysis on the standard libraries that come with GHC, which requires > getting those as Core. > > Unfortunately, the build process for these libraries is not entirely > straightforward, and relies on a make script. I eventually came up with > the plan of writing a GHC plugin, which, rather than performing any > optimizations, would simply run the analysis, and then print the results > out to a file. I was able to write the plugin successfully, and test it on > several files that were *not* from the base library. > > Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that > the make script would call the plugin. I ended up with the following: > > GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d > -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d > -package hplugin -fplugin HPlugin.Plugin -v > > The two package databases are to get to (1) the GHC API and (2) the plugin > ("hplugin") itself. With this I get an error message, which I have not > been able to find a way to resolve: > > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O > -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i > -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build > -ilibraries/ghc-prim/dist-install/build/autogen > -Ilibraries/ghc-prim/dist-install/build > -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. > -optP-include > -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h > -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db > /usr/local/lib/ghc-8.0.2/package.conf.d -package-db > /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package > hplugin -fplugin HPlugin.Plugin -no-user-package-db -rtsopts > -Wno-trustworthy-safe -Wno-deprecated-flags > -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build > -hidir libraries/ghc-prim/dist-install/build -stubdir > libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c > libraries/ghc-prim/./GHC/Types.hs -o > libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno > libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o > : not built for interactive use - can't load plugins > (HPlugin.Plugin) > make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 > make: *** [all] Error 2 > > So I'm now wondering (an answer to either of these two questions would be > helpful): > (1) Is this a viable path? That is, is it possible to use a plugin when > building Base? If so, does anyone know what I might be doing wrong/what > could be causing this error message? > (2) Is there some other better/easier way I could get Core representations > of the standard libraries? I guess, in theory, it must be possible to > compile the standard libraries with the GHC API, but I have no idea > how/where to look to figure out how? > > Thanks, > Bill > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsx at bluewin.ch Tue Dec 4 11:52:33 2018 From: rsx at bluewin.ch (Roland Senn) Date: Tue, 04 Dec 2018 12:52:33 +0100 Subject: Windows test failures In-Reply-To: References: <1543851298.2411.1.camel@bluewin.ch> Message-ID: <1543924353.2529.1.camel@bluewin.ch> 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 the text "COMPILER About to call plugin parse" and the result of the buffer-mode query. 3.) In the plugin, in the function parsedPlugin, I query and print (to stdout) the buffer mode. 4.) I added the heading PLUGIN to the normal parse message issued by the parsedPlugin function 5.) In the compiler (HscMain.hs) just after returning from the plugin, I print the line "COMPILER Returning from plugin parse" to stdout. 6.) In the  plugin function interfaceLoadPlugin' that is called much later, I flush stdout, and add the heading "PLUGIN". This gives the following interesting result:  COMPILER About to call plugin parse: LineBuffering COMPILER Returning from plugin parse PLUGIN Buffermode: BlockBuffering Nothing PLUGIN parsePlugin(a,b) PLUGIN interfacePlugin: Prelude ... The output lines do not appear in the sequence they were produced!!The plugin doesn't see/inherit the BlockBuffer mode (LineBuffering) set by the compiler!! This is a strong indication, that there are two different buffers for stdout. One in the compiler and another one in the plugin.At the end of the processing, the buffer in the compiler is automatically flushed, however the buffer in the plugin never gets flushed! LINUX=====I did a similar test in Linux, however, here I set the buffer mode to 'Blockmode Nothing' and I didn't do a manual flush in the plugin. I got the following result:  COMPILER About to call plugin parse: Buffering mode: BlockBuffering Nothing PLUGIN Buffering: BlockBuffering Nothing PLUGIN parsePlugin(a,b) COMPILER Returning from plugin parse PLUGIN interfacePlugin: Prelude ... Here the lines are in the same order as they were produced.The setting of the Buffering mode is inherited by the plugin. I think, on Linux the compiler and the plugin share the same buffer. To fix the issue on Windows, the compiler and the plugin should use the same buffer for stdout.However I don't know whether this is possible / difficult / easy?What's your opinion? Many thanks and kind regards   Roland Here are my changes for Windows in code: Change in HscMain the line "import System.IO (fixIO)" to "import System.IO" Last lines of function HscMain.hs:hscParse'             -- apply parse transformation of plugins            let applyPluginAction p opts                  = parsedResultAction p opts mod_summary            liftIO $ hSetBuffering stdout LineBuffering            mode <- liftIO $ hGetBuffering stdout            liftIO $ putStrLn ("COMPILER About to call plugin parse: " ++ show mode)            rsxresult <- withPlugins dflags applyPluginAction res            liftIO $ putStrLn "COMPILER Returning from plugin parse"            return rsxresult New code for function SourcePlugin.hs:parsedPlugin parsedPlugin opts _ pm  = do       mode <- liftIO $ hGetBuffering stdout       liftIO $ putStrLn $ "PLUGIN Buffermode: " ++ show mode       liftIO $ putStrLn $ "PLUGIN parsePlugin(" ++ intercalate "," opts ++ ")"       return pm New code for function SourcePlugin.hs:interfaceLoadPlugin' interfaceLoadPlugin' :: [CommandLineOption] -> ModIface -> IfM lcl ModIfaceinterfaceLoadPlugin' _ iface  = do liftIO $ putStrLn $ "PLUGIN interfacePlugin: "                              ++ (showSDocUnsafe $ ppr $ mi_module iface)       liftIO $ hFlush stdout       return iface Am Dienstag, den 04.12.2018, 00:02 +0000 schrieb Phyx: > 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 will > always default to LineBuffering for terminals and BlockBuffering for > anything else. The issue is that msys2 terminals have std handles > that are backed by files instead of pipes. This is an artifact of how > they try to emulate posix shells, See https://github.com/msys2/msys2/ > wiki/Porting#standard-streams-in-mintty.   > This means that when GHC runs inside an msys2 program such as bash > it'll always default to BlockBuffering. > > > > >  > I don't know anything about the "Why" and "Where" in the GHC IO > module on Windows, so I'm unable to come up with a patch.  > > The above said the handles should be getting flushed when the > finalizers are run, but these aren't 100% guaranteed so if the tests > rely on this then your solution (to force buffer mode to > LineBuffering) sounds like perfectly adequate.  Could you put a patch > up with that? > > My new I/O manager takes a different approach to determine the buffer > mode, but I still have some kinks to work out before posting it. > > >  > PS: I can't say anything about the tests 'plugin-recomp-pure' and  > 'plugin-recomp-impure' as these tests run successfully on my (slow)  > Windows box.  > > These don't fail for me or harbormaster either, so if Simon is able > to consistently reproduce these then I'll have to ask him for a core > dump so I can take a look. > > Thanks again, > I appreciate the help! > > Regards, > Tamar > > > On Mon, Dec 3, 2018 at 3:34 PM Roland Senn wrote: > > 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 in the do block of the function > > '.../testuite/tests/plugins/simple- > > plugin/Simple/SourcePlugin.hs:parsedPlugin' then all 3 tests pass > > successfully on Windows! > > > > I don't know anything about the "Why" and "Where" in the GHC IO > > module on Windows, so I'm unable to come up with a patch. > > > > Regards > >    Roland > > > > > > PS: I can't say anything about the tests 'plugin-recomp-pure' and > > 'plugin-recomp-impure' as these tests run successfully on my (slow) > > Windows box. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnguyen1 at brynmawr.edu Tue Dec 4 15:24:21 2018 From: mnguyen1 at brynmawr.edu (My Nguyen) Date: Tue, 4 Dec 2018 15:24:21 +0000 Subject: Cabal not updated after rebase? In-Reply-To: <063D3406-1D8B-4964-98E0-BDD7CA2FB0E8@cs.brynmawr.edu> References: <1ED9BF98-185D-43D5-AFEF-374C1D6D4C6D@cs.brynmawr.edu> , <063D3406-1D8B-4964-98E0-BDD7CA2FB0E8@cs.brynmawr.edu> Message-ID: Thank you so much Richard - it worked! And you are right, I had a `git add -u` at some point. This is what happens when I don’t review my changes closely! I had no idea I made changes to libraries/Cabal and such. Anyways, the diff is on Phab again, D5229. Hope to see feedback :) My ________________________________ From: Richard Eisenberg Sent: Monday, December 3, 2018 9:35 PM To: My Nguyen Cc: Krzysztof Gogolewski; ghc-devs at haskell.org Subject: Re: Cabal not updated after rebase? Detached HEADs are normal with submodules. (I suppose sentences like that would have gotten me executed several centuries ago...) When I look at https://github.com/mynguyenbmc/ghc/compare/93a3f9070d5d69ad6a28fe94ccccd20c54609698...wip/kind-app, which is, I believe, the difference between GHC HEAD and your branch, I see that the Cabal submodule has changed. I imagine you didn't mean to do this. (This has happened to me with an ill-timed `git add -u` while rebasing. Perhaps that's what caused the trouble for you, too.) To fix, you can manually `git checkout abcdefabcdef` each erroneously changed submodule to point to the right commit from HEAD. Then, `git add` each submodule in the ghc repo (i.e. not inside any submodule) and try again. I hope this helps! Richard On Dec 3, 2018, at 6:27 PM, My Nguyen > wrote: I did not touch Cabal at all, but somehow `git status` in libraries/Cabal is telling me there’s a detached HEAD? I built GHC with a fresh checkout from github, and it worked. But after applying my patch, it doesn’t work anymore. ________________________________ From: Richard Eisenberg > Sent: Monday, December 3, 2018 8:26 PM To: My Nguyen Cc: Krzysztof Gogolewski; ghc-devs at haskell.org Subject: Re: Cabal not updated after rebase? Did you change the Cabal submodule at all in your work? Maybe it's out of sync somehow... What happens if you build GHC without including your changes? Does it work? On Dec 3, 2018, at 12:13 PM, My Nguyen > wrote: Hello, Thanks for the suggestion. Unfortunately, the problem persists :(! My ________________________________ From: Krzysztof Gogolewski > Sent: Monday, December 3, 2018 2:46 PM To: My Nguyen Cc: ghc-devs at haskell.org Subject: Re: Cabal not updated after rebase? Hi, Does `git clean -fdx .` in libraries/Cabal help? git clean doesn't go into submodules. -Krzysztof On Mon, Dec 3, 2018 at 6:09 PM My Nguyen > wrote: Hi all, I've finished quite a big rebase and was trying to rebuild, but it failed with: ghc-cabal: Encountered missing dependencies: Cabal ==2.5.* I then tried applying my patch on a fresh checkout of GHC and found the reason: libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:119:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Binary.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Binary differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Binary (if these names look the same, try again with -dppr-debug) | 119 |import Distribution.Compat.Binary (Binary (..)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:120:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Semigroup.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Semigroup differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Semigroup (if these names look the same, try again with -dppr-debug) | 120 |import Distribution.Compat.Semigroup (Semigroup (..), gmappend, gmempty) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:141:1:error: Bad interface file: libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Stack.hi Something is amiss; requested module Cabal-2.4.0.1:Distribution.Compat.Stack differs from name found in the interface file Cabal-2.5.0.0:Distribution.Compat.Stack (if these names look the same, try again with -dppr-debug) | 141 |import Distribution.Compat.Stack | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm sure I did `git module update`; I even `git clean` everything and `make` from fresh but somehow the cabal still isn't updated. Can anyone help me on why this is happening and how to fix it? Thanks so much, My _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.hallahan at yale.edu Tue Dec 4 18:37:20 2018 From: william.hallahan at yale.edu (Bill Hallahan) Date: Tue, 4 Dec 2018 13:37:20 -0500 Subject: GHC (API?) question: GHC Core for Base libraries In-Reply-To: References: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> Message-ID: > Joachim Breitner's veggies(https://github.com/nomeata/veggies ) project is a good example of using a vanilla ghc installation to compile standard libraries like base. Thanks Cheng, this looks interesting and helpful! I'm still trying to understand it fully, but it seems like the important pieces for building base are in the boot and Setup scripts? > The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work. Thanks Brandon. Is there a recommended/documented way to build base with a stage 2 compiler? I haven't been able to find anything about this on the wiki. > On Dec 3, 2018, at 11:10 PM, Brandon Allbery wrote: > > The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work. > > On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan > wrote: > Hi, > > I'm writing a program analyzer that operates on GHC Core. Currently, I'm using the GHC API to get Core from .hs files. I'd like to be able to run this analysis on the standard libraries that come with GHC, which requires getting those as Core. > > Unfortunately, the build process for these libraries is not entirely straightforward, and relies on a make script. I eventually came up with the plan of writing a GHC plugin, which, rather than performing any optimizations, would simply run the analysis, and then print the results out to a file. I was able to write the plugin successfully, and test it on several files that were not from the base library. > > Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk , so that the make script would call the plugin. I ended up with the following: > > GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -v > > The two package databases are to get to (1) the GHC API and (2) the plugin ("hplugin") itself. With this I get an error message, which I have not been able to find a way to resolve: > > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o > : not built for interactive use - can't load plugins (HPlugin.Plugin) > make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 > make: *** [all] Error 2 > > So I'm now wondering (an answer to either of these two questions would be helpful): > (1) Is this a viable path? That is, is it possible to use a plugin when building Base? If so, does anyone know what I might be doing wrong/what could be causing this error message? > (2) Is there some other better/easier way I could get Core representations of the standard libraries? I guess, in theory, it must be possible to compile the standard libraries with the GHC API, but I have no idea how/where to look to figure out how? > > Thanks, > Bill > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From allbery.b at gmail.com Tue Dec 4 19:16:14 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 4 Dec 2018 14:16:14 -0500 Subject: GHC (API?) question: GHC Core for Base libraries In-Reply-To: References: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> Message-ID: It's more complicated than that, because unless your'e just doing some transient experimentation this will bite you over and over. What you'll want to do is check the stage during compilation (it should be available as macros via the CPP extension) and disable the plugin for stage 1. Then (I think; it's even worse if not...) use the base built during stage 2. The comlication there being that it may use the stage 1 compiler to build the stage 2 base. In this case, you probably can't e.g. get this integrated into ghc, because it has to be possible to get it in stage 1 and ideally stage 2 (some platforms can't do stage 2 builds yet; ARM at least used to be in this category, hence e.g. no ghci or TH). Which places limits on what features can be used in the base package. On Tue, Dec 4, 2018 at 1:37 PM Bill Hallahan wrote: > Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is > a good example of using a vanilla ghc installation to compile standard > libraries like base. > > Thanks Cheng, this looks interesting and helpful! I'm still trying to > understand it fully, but it seems like the important pieces for building > base are in the boot and Setup scripts? > > The problem here is that you're using a stage 1 build, and stage 1 lacks > support for the bytecode backend used by TH, plugins, ghci, etc. A base > build with a stage 2 compiler should work. > > Thanks Brandon. Is there a recommended/documented way to build base with > a stage 2 compiler? I haven't been able to find anything about this on the > wiki. > > On Dec 3, 2018, at 11:10 PM, Brandon Allbery wrote: > > The problem here is that you're using a stage 1 build, and stage 1 lacks > support for the bytecode backend used by TH, plugins, ghci, etc. A base > build with a stage 2 compiler should work. > > On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan > wrote: > >> Hi, >> >> I'm writing a program analyzer that operates on GHC Core. Currently, I'm >> using the GHC API to get Core from .hs files. I'd like to be able to run >> this analysis on the standard libraries that come with GHC, which requires >> getting those as Core. >> >> Unfortunately, the build process for these libraries is not entirely >> straightforward, and relies on a make script. I eventually came up with >> the plan of writing a GHC plugin, which, rather than performing any >> optimizations, would simply run the analysis, and then print the results >> out to a file. I was able to write the plugin successfully, and test it on >> several files that were *not* from the base library. >> >> Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that >> the make script would call the plugin. I ended up with the following: >> >> GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d >> -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d >> -package hplugin -fplugin HPlugin.Plugin -v >> >> The two package databases are to get to (1) the GHC API and (2) the >> plugin ("hplugin") itself. With this I get an error message, which I have >> not been able to find a way to resolve: >> >> "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O >> -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i >> -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build >> -ilibraries/ghc-prim/dist-install/build/autogen >> -Ilibraries/ghc-prim/dist-install/build >> -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. >> -optP-include >> -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h >> -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db >> /usr/local/lib/ghc-8.0.2/package.conf.d -package-db >> /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package >> hplugin -fplugin HPlugin.Plugin -no-user-package-db -rtsopts >> -Wno-trustworthy-safe -Wno-deprecated-flags >> -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build >> -hidir libraries/ghc-prim/dist-install/build -stubdir >> libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c >> libraries/ghc-prim/./GHC/Types.hs -o >> libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno >> libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o >> : not built for interactive use - can't load plugins >> (HPlugin.Plugin) >> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 >> make: *** [all] Error 2 >> >> So I'm now wondering (an answer to either of these two questions would be >> helpful): >> (1) Is this a viable path? That is, is it possible to use a plugin when >> building Base? If so, does anyone know what I might be doing wrong/what >> could be causing this error message? >> (2) Is there some other better/easier way I could get Core >> representations of the standard libraries? I guess, in theory, it must be >> possible to compile the standard libraries with the GHC API, but I have no >> idea how/where to look to figure out how? >> >> Thanks, >> Bill >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > > > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.shao at tweag.io Tue Dec 4 21:10:34 2018 From: cheng.shao at tweag.io (Shao, Cheng) Date: Wed, 5 Dec 2018 05:10:34 +0800 Subject: GHC (API?) question: GHC Core for Base libraries In-Reply-To: References: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> Message-ID: Indeed, the boot.sh script is likely what you are looking for. To compile `base` and retrieve Core for it, you just need to set up an empty package database, use the Setup.hs script in base to compile it, and load your plugin via "--ghc-option=.." provided to `Setup configure`. On Wed, Dec 5, 2018 at 2:37 AM Bill Hallahan wrote: > > Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is a good example of using a vanilla ghc installation to compile standard libraries like base. > > Thanks Cheng, this looks interesting and helpful! I'm still trying to understand it fully, but it seems like the important pieces for building base are in the boot and Setup scripts? > > The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work. > > Thanks Brandon. Is there a recommended/documented way to build base with a stage 2 compiler? I haven't been able to find anything about this on the wiki. > > On Dec 3, 2018, at 11:10 PM, Brandon Allbery wrote: > > The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work. > > On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan wrote: >> >> Hi, >> >> I'm writing a program analyzer that operates on GHC Core. Currently, I'm using the GHC API to get Core from .hs files. I'd like to be able to run this analysis on the standard libraries that come with GHC, which requires getting those as Core. >> >> Unfortunately, the build process for these libraries is not entirely straightforward, and relies on a make script. I eventually came up with the plan of writing a GHC plugin, which, rather than performing any optimizations, would simply run the analysis, and then print the results out to a file. I was able to write the plugin successfully, and test it on several files that were not from the base library. >> >> Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that the make script would call the plugin. I ended up with the following: >> >> GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -v >> >> The two package databases are to get to (1) the GHC API and (2) the plugin ("hplugin") itself. With this I get an error message, which I have not been able to find a way to resolve: >> >> "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o >> : not built for interactive use - can't load plugins (HPlugin.Plugin) >> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 >> make: *** [all] Error 2 >> >> So I'm now wondering (an answer to either of these two questions would be helpful): >> (1) Is this a viable path? That is, is it possible to use a plugin when building Base? If so, does anyone know what I might be doing wrong/what could be causing this error message? >> (2) Is there some other better/easier way I could get Core representations of the standard libraries? I guess, in theory, it must be possible to compile the standard libraries with the GHC API, but I have no idea how/where to look to figure out how? >> >> Thanks, >> Bill >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From carter.schonwald at gmail.com Wed Dec 5 19:18:28 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 5 Dec 2018 14:18:28 -0500 Subject: how do i set -intree-gmp for hadrian builds? Message-ID: I'm looking at the docs presently, and that seems to be missing .. and its pretty important for mac builds, -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Dec 6 10:09:47 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 6 Dec 2018 10:09:47 +0000 Subject: Residency profiles Message-ID: Simon, Ben, Omer As you'll see in comments 55-72 of https://ghc.haskell.org/trac/ghc/ticket/9476, Sebastian has been a bit flummoxed by the task of measure residency profiles; that is, how much data is truly live during execution. A major GC measures that, but we are vulnerable to exactly when it happens (even with -G1) and that can lead to irreproducible results. I think what we want is a way to trigger GC at very regular intervals, after (say) each 10kbytes or 100kbytes or 1Mbyte of allocation. That might be expensive, but we'd get reproducible results. I don't think that is possible right now - see the ticket - but it would be easy enough to do wouldn't it? Just give only 10k or 100k or 1M to the allocator when setting it running again. Would you consider this? Or are we just missing something obvious? Needless to say, we want to do all this with full optimisation on, no cost-centre profiling. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Dec 6 10:35:11 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 6 Dec 2018 10:35:11 +0000 Subject: Guidelines for respectful communication Message-ID: Friends As many of you will know, I have been concerned for several years about the standards of discourse in the Haskell community. I think things have improved since the period that drove me to write my Respect email, but it's far from secure. We discussed this at a meeting of the GHC Steering Committee at ICFP in September, and many of us have had related discussions since. Arising out of that conversation, the GHC Steering Committee has decided to adopt these Guidelines for respectful communication We are not trying to impose these guidelines on members of the Haskell community generally. Rather, we are adopting them for ourselves, as a signal that we seek high standards of discourse in the Haskell community, and are willing to publicly hold ourselves to that standard, in the hope that others may choose to follow suit. We are calling them "guidelines for respectful communication" rather than a "code of conduct", because we want to encourage good communication, rather than focus on bad behaviour. Richard Stallman's recent post about the new GNU Kind Communication Guidelines expresses the same idea. Meanwhile, the Stack community is taking a similar approach. Our guidelines are not set in stone; you can comment here. Perhaps they can evolve so that other Haskell committees (or even individuals) feel able to adopt them. The Haskell community is such a rich collection of intelligent, passionate, and committed people. Thank you -- I love you all! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From omer at well-typed.com Thu Dec 6 11:15:13 2018 From: omer at well-typed.com (=?UTF-8?Q?=c3=96mer_Sinan_A=c4=9facan?=) Date: Thu, 6 Dec 2018 14:15:13 +0300 Subject: Residency profiles In-Reply-To: References: Message-ID: Hi, > I think what we want is a way to trigger GC at very regular intervals, after > (say) each 10kbytes or 100kbytes or 1Mbyte of allocation. That might be > expensive, but we’d get reproducible results. If we could fix the nursery size to 10kb that'd trigger a GC in every 10kb of allocation (you could still allocate large objects as those are not allocated in the nursery, but perhaps that's not a problem in your benchmarks). Then by setting -G1 you could turn all GCs to major GCs (because first generation is always collected). Note that because each capability has its own nursery you may want to set the nursery size to alloc_per_gc / num_of_caps if you need more than one capability. > I don’t think that is possible right now – see the ticket – but it would be > easy enough to do wouldn’t it? Just give only 10k or 100k or 1M to the > allocator when setting it running again. Right. A parameter for fixing the nursery size would be easy to implement, I think. Just a new flag, then in GC.c:resize_nursery() use the flag as the nursery size. "Max. residency" is really hard to measure (need to do very frequent GCs), perhaps a better question to ask is "residency when the program is in state S". This is also hard to measure if your program is threaded or have other non-determinism, but this lets you decide when to measure residency. Currently we can't tell the GC to print residency stats, but perhaps we could implement a variant of `performGC` that prints residency after the GC. So in your program you could add `performGCPrintStats` after every iteration or step etc. Not sure how useful this would be, but just an idea.. On 6.12.2018 13:09, Simon Peyton Jones wrote: > Simon, Ben, Omer > > As you’ll see in comments 55-72 of https://ghc.haskell.org/trac/ghc/ticket/9476, > Sebastian has been a bit flummoxed by the task of measure residency profiles; > that is, how much data is truly live during execution. > > A major GC measures that, but we are vulnerable to exactly when it happens (even > with -G1) and that can lead to irreproducible results. > > I think what we want is a way to trigger GC at very regular intervals, after > (say) each 10kbytes or 100kbytes or 1Mbyte  of allocation.  That might be > expensive, but we’d get reproducible results. > > I don’t think that is possible right now – see the ticket – but it would be easy > enough to do wouldn’t it?  Just give only 10k or 100k or 1M to the allocator > when setting it running again. > > Would you consider this?  Or are we just missing something obvious? > > Needless to say, we want to do all this with full optimisation on, no > cost-centre profiling. > > Thanks > > Simon > -- Ömer Sinan Ağacan, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England From marlowsd at gmail.com Thu Dec 6 11:22:02 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 6 Dec 2018 11:22:02 +0000 Subject: Residency profiles In-Reply-To: References: Message-ID: On Thu, 6 Dec 2018 at 11:15, Ömer Sinan Ağacan wrote: > Hi, > > > I think what we want is a way to trigger GC at very regular intervals, > after > > (say) each 10kbytes or 100kbytes or 1Mbyte of allocation. That might > be > > expensive, but we’d get reproducible results. > > If we could fix the nursery size to 10kb that'd trigger a GC in every 10kb > of > allocation (you could still allocate large objects as those are not > allocated in > the nursery, but perhaps that's not a problem in your benchmarks). Then by > setting -G1 you could turn all GCs to major GCs (because first generation > is > always collected). Note that because each capability has its own nursery > you may > want to set the nursery size to alloc_per_gc / num_of_caps if you need > more than > one capability. > > > I don’t think that is possible right now – see the ticket – but it > would be > > easy enough to do wouldn’t it? Just give only 10k or 100k or 1M to the > > allocator when setting it running again. > > Right. A parameter for fixing the nursery size would be easy to implement, > I > think. Just a new flag, then in GC.c:resize_nursery() use the flag as the > nursery size. > It's possible that +RTS -A100k -F1 would do what you want. It would keep the 2-generation setup, with a fixed nursery size, and -F1 would ensure that every collection is a major one. I haven't tested this, but if it doesn't work, it should! Cheers Simon > > "Max. residency" is really hard to measure (need to do very frequent GCs), > perhaps a better question to ask is "residency when the program is in > state S". > This is also hard to measure if your program is threaded or have other > non-determinism, but this lets you decide when to measure residency. > Currently > we can't tell the GC to print residency stats, but perhaps we could > implement a > variant of `performGC` that prints residency after the GC. So in your > program > you could add `performGCPrintStats` after every iteration or step etc. Not > sure > how useful this would be, but just an idea.. > > On 6.12.2018 13:09, Simon Peyton Jones wrote: > > Simon, Ben, Omer > > > > As you’ll see in comments 55-72 of > https://ghc.haskell.org/trac/ghc/ticket/9476, > > Sebastian has been a bit flummoxed by the task of measure residency > profiles; > > that is, how much data is truly live during execution. > > > > A major GC measures that, but we are vulnerable to exactly when it > happens (even > > with -G1) and that can lead to irreproducible results. > > > > I think what we want is a way to trigger GC at very regular intervals, > after > > (say) each 10kbytes or 100kbytes or 1Mbyte of allocation. That might > be > > expensive, but we’d get reproducible results. > > > > I don’t think that is possible right now – see the ticket – but it would > be easy > > enough to do wouldn’t it? Just give only 10k or 100k or 1M to the > allocator > > when setting it running again. > > > > Would you consider this? Or are we just missing something obvious? > > > > Needless to say, we want to do all this with full optimisation on, no > > cost-centre profiling. > > > > Thanks > > > > Simon > > > > -- > Ömer Sinan Ağacan, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com > > Registered in England & Wales, OC335890 > 118 Wymering Mansions, Wymering Road, London W9 2NF, England > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Dec 6 11:52:38 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 6 Dec 2018 11:52:38 +0000 Subject: Residency profiles In-Reply-To: References: Message-ID: | Right. A parameter for fixing the nursery size would be easy to implement, | I think. Just a new flag, then in GC.c:resize_nursery() use the flag as the | nursery size. Super! That would be v useful. | "Max. residency" is really hard to measure (need to do very frequent GCs), | perhaps a better question to ask is "residency when the program is in state | S". Actually, Sebastian simply wants to see an accurate, reproducible residency profile, and doing frequent GCs might well be an acceptable cost. Simon From simonpj at microsoft.com Thu Dec 6 14:17:52 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 6 Dec 2018 14:17:52 +0000 Subject: Windows test failures In-Reply-To: References: Message-ID: Hi Tamar Thanks for working on this. if it's an msys2 shell, what does "locale" return? It’s a shell running inside emacs. Here’s what locale returns /c/tmp$ locale LANG=en_GB LC_CTYPE="en_GB" LC_NUMERIC="en_GB" LC_TIME="en_GB" LC_COLLATE="en_GB" LC_MONETARY="en_GB" LC_MESSAGES="en_GB" LC_ALL= Does that help at all? I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test 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 at 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 at already, seems to have something to do with the libstdc++ destructors. Plugins 09 and 10 are the other two I know about, but haven't had time to look at them yet. Frankly I know too little about plugins to make an accurate determination here, but the input files are empty yet it expects output, so I don't know what it's supposed to do here. If someone who knows more about plugins can chime in that would save some time. The segfaulting plugin I haven't triaged yet. Now the remaining failures aside from T14452 that Roland is taking care of, seem to have to do with your locale in your console. You seem to be running the tests in a console that has latin-1 locale? So some unicode characters fail encoding/decoding. If it's a Windows shell you can change it to utf-8 using "chcp 65001", if it's an msys2 shell, what does "locale" return? For reference mine is $ locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_ALL= If it does say latin1 you can change it with export LANG=en_GB.UTF-8 This should fix more of the tests. The reason I don't mark the remaining tests as expect fail yet is because I haven't had the time to triage them, so I don't know their severity and last time there were a few nasty issues hidden in them. Unfortunately I won't have time to look at them till next weekend. Thanks, Tamar On Fri, Nov 30, 2018 at 9:49 PM Simon Peyton Jones > wrote: At the end of the first test run it would have given a list of tests that failed and a line saying TEST=".... List of tests..." Copy that line and at the root of the checkout do make TEST=".... List of tests..." test -C testsuite/tests (that's uppercase C). This will run everything using one thread. :) OK, done. Results below. Simon /c/code/HEAD$ make TEST="T10420 T10672_x64 T13385 T14452 T15815 T3307 T3319 T4006 TH_scopedTvs environment001 plugin-recomp-change plugin-recomp-flags plugin-recomp-impure plugin-recomp-pure plugins07 plugins09 plugins10 plugins11 plugins13 plugins14 print017" test -C testsuite/tests make: Entering directory '/c/code/HEAD/testsuite/tests' PYTHON="python3" "python3" ../driver/runtests.py -e "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output'" -e config.compiler_debugged=False -e ghc_with_native_codegen=True -e config.have_vanilla=True -e config.have_dynamic=False -e config.have_profiling=False -e ghc_with_threaded_rts=True -e ghc_with_dynamic_rts=False -e config.have_interp=True -e config.unregisterised=False -e config.have_gdb=False -e config.have_readelf=True -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=True -e ghc_with_llvm=False -e windows=True -e darwin=False -e config.in_tree_compiler=True -e config.cleanup=True -e config.local=True --rootdir=. --config-file=../config/ghc -e 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/c/code/HEAD/testsuite"' --config 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../timeout/install-inplace/bin/timeout.exe"' -e "config.stage=2" --rootdir=../../libraries/Win32/tests --rootdir=../../libraries/array/tests --rootdir=../../libraries/base/tests --rootdir=../../libraries/binary/tests --rootdir=../../libraries/bytestring/tests --rootdir=../../libraries/containers/tests --rootdir=../../libraries/deepseq/tests --rootdir=../../libraries/directory/tests --rootdir=../../libraries/filepath/tests --rootdir=../../libraries/ghc-compact/tests --rootdir=../../libraries/ghc-heap/tests --rootdir=../../libraries/ghc-prim/tests --rootdir=../../libraries/haskeline/tests --rootdir=../../libraries/hpc/tests --rootdir=../../libraries/pretty/tests --rootdir=../../libraries/process/tests --rootdir=../../libraries/stm/tests --rootdir=../../libraries/template-haskell/tests --rootdir=../../libraries/text/tests \ --only=T10420 --only=T10672_x64 --only=T13385 --only=T14452 --only=T15815 --only=T3307 --only=T3319 --only=T4006 --only=TH_scopedTvs --only=environment001 --only=plugin-recomp-change --only=plugin-recomp-flags --only=plugin-recomp-impure --only=plugin-recomp-pure --only=plugins07 --only=plugins09 --only=plugins10 --only=plugins11 --only=plugins13 --only=plugins14 --only=print017 \ \ \ \ \ \ Timeout is 300 0 Found 398 .T files... Beginning test run at Fri Nov 30 21:07:17 2018 GMTST ====> Scanning ./ado/all.T ====> Scanning ./annotations/should_compile/all.T ====> Scanning ./annotations/should_compile/T13818/all.T …lots more “Scanning” lines… ====> Scanning ../../libraries/ghc-heap/tests/all.T ====> Scanning ../../libraries/hpc/tests/fork/test.T--- driver/T14452.run/T14452.stdout.normalised 2018-11-30 21:07:36.565566000 +0000 +++ driver/T14452.run/T14452.run.stdout.normalised 2018-11-30 21:07:36.567569500 +0000 @@ -1 +1 @@ --O3 +"-O3" --- libraries/base/tests/T4006.run/T4006.stdout.normalised 2018-11-30 21:15:19.867313900 +0000 +++ libraries/base/tests/T4006.run/T4006.run.stdout.normalised 2018-11-30 21:15:19.870787900 +0000 @@ -1,2 +1,2 @@ It works here - + --- libraries/base/tests/IO/environment001.run/environment001.stdout.normalised 2018-11-30 21:16:00.645817500 +0000 +++ libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised 2018-11-30 21:16:00.654738900 +0000 @@ -1,7 +1,8 @@ - -Test 1: 3 - -Test 2: 1 + + +Test 1: 9 + +Test 2: 3 ! Test 3: 3 ["a","b"] ====> Scanning ../../libraries/hpc/tests/function/test.T ====> Scanning ../../libraries/hpc/tests/function2/test.T ====> Scanning ../../libraries/hpc/tests/ghc_ghci/test.T ====> Scanning ../../libraries/hpc/tests/raytrace/test.T ====> Scanning ../../libraries/hpc/tests/raytrace/tixs/test.T ====> Scanning ../../libraries/hpc/tests/simple/test.T ====> Scanning ../../libraries/hpc/tests/simple/tixs/test.T ====> Scanning ../../libraries/process/tests/all.T ====> Scanning ../../libraries/process/tests/T9775/all.T ====> Scanning ../../libraries/stm/tests/all.T ====> Scanning ../../libraries/template-haskell/tests/all.T =====> T14452(normal) 1 of 21 [0, 0, 0] cd "driver/T14452.run" && $MAKE -s --no-print-directory T14452 Actual stdout output differs from expected: diff -uw "driver/T14452.run/T14452.stdout.normalised" "driver/T14452.run/T14452.run.stdout.normalised" *** unexpected failure for T14452(normal) =====> T13385(ghci) 2 of 21 [0, 1, 0] cd "ghci/scripts/T13385.run" && HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XRebindableSyntax" "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XRebindableSyntax < T13385.script =====> print017(ghci) 3 of 21 [0, 1, 0] cd "ghci.debugger/scripts/print017.run" && HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output " "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -ignore-dot-ghci< print017.script =====> print017(ghci-ext) 3 of 21 [0, 1, 0] cd "ghci.debugger/scripts/print017.run" && HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output " "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 -ignore-dot-ghci -fno-ghci-history -fexternal-interpreter +RTS -I0.1 -RTS -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -ignore-dot-ghci< print017.script =====> plugin-recomp-change(normal) 4 of 21 [0, 1, 0] cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory plugin-recomp-change =====> T10672_x64(normal) 5 of 21 [0, 1, 0] cd "rts/T10672/T10672_x64.run" && $MAKE -s --no-print-directory T10672_x64 Timeout happened...killed process "cd "rts/T10672/T10672_x64.run" && $MAKE -s --no-print-directory T10672_x64 "... Wrong exit code for T10672_x64()(expected 0 , actual 99 ) *** unexpected failure for T10672_x64(normal) =====> TH_scopedTvs(normal) 6 of 21 [0, 2, 0] cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -v0 =====> TH_scopedTvs(ext-interp) 6 of 21 [0, 2, 0] cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 =====> T3319(normal) 7 of 21 [0, 2, 0] cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -ddump-splices -v0 =====> T3319(ext-interp) 7 of 21 [0, 2, 0] cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -ddump-splices -v0 =====> T15815(normal) 8 of 21 [0, 2, 0] cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -v0 -static =====> T15815(ext-interp) 8 of 21 [0, 2, 0] cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 -static =====> T4006(normal) 9 of 21 [0, 2, 0] cd "libraries/base/tests/T4006.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -o T4006 T4006.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "libraries/base/tests/T4006.run" && ./T4006 Actual stdout output differs from expected: diff -uw "libraries/base/tests/T4006.run/T4006.stdout.normalised" "libraries/base/tests/T4006.run/T4006.run.stdout.normalised" *** unexpected failure for T4006(normal) =====> T3307(normal) 10 of 21 [0, 3, 0] cd "libraries/base/tests/IO/T3307.run" && $MAKE -s --no-print-directory T3307-test Wrong exit code for T3307()(expected 0 , actual 2 ) Stdout ( T3307 ): Test 1 [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] Ni hao Test 2 [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] Ni hao Test 3 [99,104,105,110,101,115,101,45,102,105,108,101,45,23567,35828] Stderr ( T3307 ): *** framework failure for T3307(normal) 'latin-1' codec can't encode characters in position 24-25: ordinal not in range(256) =====> environment001(normal) 11 of 21 [0, 3, 1] cd "libraries/base/tests/IO/environment001.run" && $MAKE -s --no-print-directory environment001-test Actual stdout output differs from expected: diff -uw "libraries/base/tests/IO/environment001.run/environment001.stdout.normalised" "libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised" *** unexpected failure for environment001(normal) =====> plugins07(normal) 12 of 21 [0, 4, 1] cd "plugins/plugins07.run" && $MAKE -s --no-print-directory -C rule-defining-plugin package.plugins07 TOP=/c/code/HEAD/testsuite cd "plugins/plugins07.run" && $MAKE -s --no-print-directory plugins07 =====> plugins09(normal) 13 of 21 [0, 4, 1] cd "plugins/plugins09.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins09 TOP=/c/code/HEAD/testsuite cd "plugins/plugins09.run" && $MAKE -s --no-print-directory plugins09 Actual stdout output differs from expected: diff -uw "plugins/plugins09.run/plugins09.stdout.normalised" "plugins/plugins09.run/plugins09.run.stdout.normalised"--- plugins/plugins09.run/plugins09.stdout.normalised 2018-11-30 21:17:20.709370700 +0000 +++ plugins/plugins09.run/plugins09.run.stdout.normalised 2018-11-30 21:17:20.711314000 +0000 @@ -1,9 +0,0 @@ -parsePlugin(a,b) -interfacePlugin: Prelude -interfacePlugin: GHC.Float -interfacePlugin: GHC.Base -typeCheckPlugin (rn) -interfacePlugin: GHC.Types -typeCheckPlugin (tc) -interfacePlugin: GHC.Integer.Type -interfacePlugin: GHC.Natural --- plugins/plugins10.run/plugins10.stdout.normalised 2018-11-30 21:17:57.644357800 +0000 +++ plugins/plugins10.run/plugins10.run.stdout.normalised 2018-11-30 21:17:57.646078700 +0000 @@ -1,21 +0,0 @@ -parsePlugin() -interfacePlugin: Prelude -interfacePlugin: Language.Haskell.TH -interfacePlugin: Language.Haskell.TH.Quote -interfacePlugin: GHC.Float -interfacePlugin: GHC.Base -interfacePlugin: Language.Haskell.TH.Syntax -typeCheckPlugin (rn) -interfacePlugin: GHC.Types -typeCheckPlugin (tc) -interfacePlugin: GHC.Integer.Type -interfacePlugin: GHC.Natural -parsePlugin(a) -typeCheckPlugin (rn) -interfacePlugin: Language.Haskell.TH.Lib.Internal -metaPlugin: return [] -metaPlugin: quoteExp stringify "x" -interfacePlugin: GHC.CString -typeCheckPlugin (rn) -typeCheckPlugin (rn) -typeCheckPlugin (tc) *** unexpected failure for plugins09(normal) =====> plugins10(normal) 14 of 21 [0, 5, 1] cd "plugins/plugins10.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins10 TOP=/c/code/HEAD/testsuite cd "plugins/plugins10.run" && $MAKE -s --no-print-directory plugins10 Actual stdout output differs from expected: diff -uw "plugins/plugins10.run/plugins10.stdout.normalised" "plugins/plugins10.run/plugins10.run.stdout.normalised" *** unexpected failure for plugins10(normal) =====> plugins11(normal) 15 of 21 [0, 6, 1] cd "plugins/plugins11.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins11 TOP=/c/code/HEAD/testsuite cd "plugins/plugins11.run" && $MAKE -s --no-print-directory plugins11 Timeout happened...killed process "cd "plugins/plugins11.run" && $MAKE -s --no-print-directory plugins11 "... Wrong exit code for plugins11()(expected 0 , actual 99 ) *** unexpected failure for plugins11(normal) =====> plugins13(normal) 16 of 21 [0, 7, 1] cd "plugins/plugins13.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins13 TOP=/c/code/HEAD/testsuite cd "plugins/plugins13.run" && $MAKE -s --no-print-directory plugins13 =====> plugins14(normal) 17 of 21 [0, 7, 1] cd "plugins/plugins14.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins14 TOP=/c/code/HEAD/testsuite cd "plugins/plugins14.run" && $MAKE -s --no-print-directory plugins14 =====> T10420(normal) 18 of 21 [0, 7, 1] cd "plugins/T10420.run" && $MAKE -s --no-print-directory -C rule-defining-plugin package.T10420 TOP=/c/code/HEAD/testsuite cd "plugins/T10420.run" && $MAKE -s --no-print-directory T10420 =====> plugin-recomp-pure(normal) 19 of 21 [0, 7, 1] cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory plugin-recomp-pure Timeout happened...killed process "cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory plugin-recomp-pure "... Wrong exit code for plugin-recomp-pure()(expected 0 , actual 99 ) Stdout ( plugin-recomp-pure ): [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-recomp-test.o ) Stderr ( plugin-recomp-pure ): Simple Plugin Passes Queried Got options: Simple Plugin Pass Run *** unexpected failure for plugin-recomp-pure(normal) =====> plugin-recomp-impure(normal) 20 of 21 [0, 8, 1] cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory plugin-recomp-impure Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) Stdout ( plugin-recomp-impure ): [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-recomp-test.o ) Linking plugin-recomp-test.exe ... [1 of 1] Compiling Main ( plugin-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 reading 0xa824 Attempting to reconstruct a stack trace... Frame Code address * 0x49adab0 0x1eb49ec 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" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory plugin-recomp-flags Traceback (most recent call last): File "/c/code/HEAD/testsuite/driver/testlib.py", line 824, in test_common_work do_test(name, way, func, args, files) File "/c/code/HEAD/testsuite/driver/testlib.py", line 910, in do_test result = func(*[name,way] + args) File "/c/code/HEAD/testsuite/driver/testlib.py", line 993, in run_command return simple_run( name, '', override_options(cmd), '' ) File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in simple_run dump_stderr(name) File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in dump_stderr print(str) UnicodeEncodeError: 'latin-1' codec can't encode characters in position 24-25: ordinal not in range(256) Unexpected 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 cases, of which 11 were skipped 0 had missing libraries 15 expected passes 0 expected failures 1 caused framework failures 0 caused framework warnings 0 unexpected passes 9 unexpected failures 0 unexpected stat failures Unexpected failures: driver/T14452.run T14452 [bad stdout] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) libraries/base/tests/T4006.run T4006 [bad stdout] (normal) libraries/base/tests/IO/environment001.run environment001 [bad stdout] (normal) plugins/plugins09.run plugins09 [bad stdout] (normal) plugins/plugins10.run plugins10 [bad stdout] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) Framework failures: libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec can't encode characters in position 24-25: ordinal not in range(256)) Appending 0 stats to git notes. make: *** [../mk/test.mk:342: test] Error 1 make: Leaving directory '/c/code/HEAD/testsuite/tests' /c/code/HEAD$ From: Phyx > Sent: 30 November 2018 11:58 To: Simon Peyton Jones > Subject: Re: Windows test failures At the end of the first test run it would have given a list of tests that failed and a line saying TEST=".... List of tests..." Copy that line and at the root of the checkout do make TEST=".... List of tests..." test -C testsuite/tests (that's uppercase C). This will run everything using one thread. :) Should give a good starting point as to what's wrong. Kind regards, Tamar On Fri, Nov 30, 2018, 10:30 Simon Peyton Jones > wrote: So I just say make TEST is that right? Or is it make THREADS=1 or what? Sorry to be dim From: Phyx > Sent: 30 November 2018 08:05 To: Simon Peyton Jones > Cc: ghc-devs > Subject: Re: Windows test failures 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 increasingly unstable under threads for some reason. I also haven't run trunk yet since last week so they could be new.. But rerunning the fails with no threads should give a better idea. Regards, Tamar On Fri, Nov 30, 2018, 07:46 Simon Peyton Jones via ghc-devs > wrote: Ben, Phyx, and other CI folk ‘sh validate –fast’ still gives a lot of failures on Window. The output is below. I would be so good to get this to zero! (another minor thing is that it would be great to eliminate the long path at the beginning – this is platform independent – I have to delete manually many times each day. Thanks Simon Unexpected passes: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T9405.run T9405 [unexpected] (normal) Unexpected failures: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/driver/T14452.run T14452 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/linking/ghcilink001.run ghcilink001 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/scripts/ghci050.run ghci050 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T14963a.run T14963a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/indexed-types/should_fail/T7102a.run T7102a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_spliceGuard.run TH_spliceGuard [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_overlaps.run TH_overlaps [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T5886.run T5886 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T10697_decided_3.run T10697_decided_3 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T11629.run T11629 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/T4006.run T4006 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/IO/environment001.run environment001 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T15633b.run T15633b [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins07.run plugins07 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins09.run plugins09 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins10.run plugins10 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins11.run plugins11 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/T10420.run T10420 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) Framework failures: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run MultiLayerModules [runTest] (Unhandled exception during cleanup: Unable to remove folder '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run': [Errno 13] Permission denied: '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run' Unable to start current test.) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec can't encode characters in position 24-25: ordinal not in range(256)) _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.pelenitsyn at gmail.com Thu Dec 6 15:07:21 2018 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Thu, 6 Dec 2018 10:07:21 -0500 Subject: References for GHC usage of multiple capabilities Message-ID: Hello devs, I've been working on a short survey devoted to a topic of multithreading inside the GHC compiler and runtime. So far I was mostly looking at the following three papers [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, and S. L. Peyton Jones. Gum: A portable parallel implementation of Haskell. PLDI ’96 [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a shared-memory multiprocessor. Haskell ’05 [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime support for multicore Haskell. ICFP ’09 Can you suggest any other papers adding insights on how GHC uses multiple capabilities for anything from GC to the implementation of Parallel/Concurrent Haskell? Perhaps, something more recent than the above, but preferably published in academic venues. The survey is meant to be of interest for systems folks. Therefore, I'm not paying so much attention to the programming model and how it is used in programs. -- Best wishes, Artem -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Thu Dec 6 15:46:56 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 06 Dec 2018 10:46:56 -0500 Subject: References for GHC usage of multiple capabilities In-Reply-To: References: Message-ID: <87k1kmwtck.fsf@smart-cactus.org> Artem Pelenitsyn writes: > Hello devs, > > I've been working on a short survey devoted to a topic of multithreading > inside the GHC compiler and runtime. So far I was mostly looking at the > following three papers > > [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, and S. > L. Peyton Jones. Gum: A portable parallel implementation of Haskell. PLDI > ’96 > > [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a > shared-memory multiprocessor. Haskell ’05 > > [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime support for > multicore Haskell. ICFP ’09 > > Can you suggest any other papers adding insights on how GHC uses multiple > capabilities for anything from GC to the implementation of > Parallel/Concurrent Haskell? Perhaps, something more recent than the above, > but preferably published in academic venues. > Here are a few others but I may have missed a few: * Parallel Generational-Copying Garbage Collection with a Block-Structured Heap (Simon Marlow, Tim Harris, Roshan P. James, Simon Peyton Jones) In ISMM '08: Proceedings of the 7th international symposium on Memory management, Tucson, Arizona, ACM, June 2008 * Concurrent Haskell, Simon Peyton Jones, Andrew Gordon, Sigbjorn Finne. * Composable Memory Transactions, Tim Harris, Simon Marlow, Simon Peyton-Jones, and Maurice Herlihy. In Proceedings of the tenth ACM SIGPLAN symposium on Principles and practice of parallel programming (PPoPP '05) * Transactional Memory with Data Invariants, Tim Harris and Simon Peyton Jones. In TRANSACT '06 Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From sgraf1337 at gmail.com Thu Dec 6 16:21:17 2018 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Thu, 6 Dec 2018 17:21:17 +0100 Subject: Residency profiles In-Reply-To: References: Message-ID: Hey, thanks, all! Measuring with `-A1M -F1` delivers much more reliable residency numbers. `-F` doesn't seem to be documented. From reading `rts/RtsFlags.c` and `rts/sm/GC.c` I gather that it's the factor by which to multiply the number of live bytes by to get the new old gen size? So effectively, the old gen will 'overflow' on every minor GC, neat! Greetings Sebastian Am Do., 6. Dez. 2018 um 12:52 Uhr schrieb Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org>: > | Right. A parameter for fixing the nursery size would be easy to > implement, > | I think. Just a new flag, then in GC.c:resize_nursery() use the flag as > the > | nursery size. > > Super! That would be v useful. > > | "Max. residency" is really hard to measure (need to do very frequent > GCs), > | perhaps a better question to ask is "residency when the program is in > state > | S". > > Actually, Sebastian simply wants to see an accurate, reproducible > residency profile, and doing frequent GCs might well be an acceptable > cost. > > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Thu Dec 6 19:52:48 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 6 Dec 2018 19:52:48 +0000 Subject: Residency profiles In-Reply-To: References: Message-ID: It is documented! https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_control.html#rts-flag--F%20%E2%9F%A8factor%E2%9F%A9 On Thu, 6 Dec 2018 at 16:21, Sebastian Graf wrote: > Hey, > > thanks, all! Measuring with `-A1M -F1` delivers much more reliable > residency numbers. > `-F` doesn't seem to be documented. From reading `rts/RtsFlags.c` and > `rts/sm/GC.c` I gather that it's the factor by which to multiply the number > of live bytes by to get the new old gen size? > So effectively, the old gen will 'overflow' on every minor GC, neat! > > Greetings > Sebastian > > Am Do., 6. Dez. 2018 um 12:52 Uhr schrieb Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org>: > >> | Right. A parameter for fixing the nursery size would be easy to >> implement, >> | I think. Just a new flag, then in GC.c:resize_nursery() use the flag >> as the >> | nursery size. >> >> Super! That would be v useful. >> >> | "Max. residency" is really hard to measure (need to do very frequent >> GCs), >> | perhaps a better question to ask is "residency when the program is in >> state >> | S". >> >> Actually, Sebastian simply wants to see an accurate, reproducible >> residency profile, and doing frequent GCs might well be an acceptable >> cost. >> >> Simon >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Thu Dec 6 23:43:19 2018 From: lonetiger at gmail.com (Phyx) Date: Thu, 6 Dec 2018 23:43:19 +0000 Subject: Windows test failures In-Reply-To: References: Message-ID: Hi Simon, > Does that help at all? > > I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test its efficacy by running one test rather than 6,000 of them? In which case, which one? Yes, "en_GB" doesn't seem to be a unicode locale, one test you can try to check is T3307,so make TEST="T3307" -C testsuite/tests/ I tried using your "en_GB" locale and the test failed for me too then. Kind regards, Tamar On Thu, Dec 6, 2018 at 2:17 PM Simon Peyton Jones wrote: > Hi Tamar > > > > Thanks for working on this. > > > > if it's an msys2 shell, what does "locale" return? > > > > It’s a shell running inside emacs. Here’s what locale returns > > /c/tmp$ locale > > LANG=en_GB > > LC_CTYPE="en_GB" > > LC_NUMERIC="en_GB" > > LC_TIME="en_GB" > > LC_COLLATE="en_GB" > > LC_MONETARY="en_GB" > > LC_MESSAGES="en_GB" > > LC_ALL= > > > > Does that help at all? > > > > I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test > 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 at 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 at already, seems to have > something to do with the libstdc++ destructors. > > Plugins 09 and 10 are the other two I know about, but haven't had time to > look at them yet. Frankly I know too little about plugins to make an > accurate determination here, but the input files are empty > > yet it expects output, so I don't know what it's supposed to do here. If > someone who knows more about plugins can chime in that would save some time. > > > > The segfaulting plugin I haven't triaged yet. Now the remaining failures > aside from T14452 that Roland is taking care of, seem to have to do with > your locale in your console. You seem to be running the > > tests in a console that has latin-1 locale? So some unicode characters > fail encoding/decoding. > > > > If it's a Windows shell you can change it to utf-8 using "chcp 65001", if > it's an msys2 shell, what does "locale" return? > > > > For reference mine is > > > > $ locale > LANG=en_GB.UTF-8 > LC_CTYPE="en_GB.UTF-8" > LC_NUMERIC="en_GB.UTF-8" > LC_TIME="en_GB.UTF-8" > LC_COLLATE="en_GB.UTF-8" > LC_MONETARY="en_GB.UTF-8" > LC_MESSAGES="en_GB.UTF-8" > LC_ALL= > > > > If it does say latin1 you can change it with > > > > export LANG=en_GB.UTF-8 > > > > This should fix more of the tests. > > > > The reason I don't mark the remaining tests as expect fail yet is because > I haven't had the time to triage them, so I don't know their severity and > > last time there were a few nasty issues hidden in them. > > > > Unfortunately I won't have time to look at them till next weekend. > > > > Thanks, > > Tamar > > > > On Fri, Nov 30, 2018 at 9:49 PM Simon Peyton Jones > wrote: > > At the end of the first test run it would have given a list of tests that > failed and a line saying TEST=".... List of tests..." > > > > Copy that line and at the root of the checkout do > > > > make TEST=".... List of tests..." test -C testsuite/tests > > > > (that's uppercase C). This will run everything using one thread. :) > > > > OK, done. Results below. > > > > Simon > > > > > > /c/code/HEAD$ make TEST="T10420 T10672_x64 T13385 T14452 T15815 T3307 > T3319 T4006 TH_scopedTvs environment001 plugin-recomp-change > plugin-recomp-flags plugin-recomp-impure plugin-recomp-pure plugins07 > plugins09 plugins10 plugins11 plugins13 plugins14 print017" test -C > testsuite/tests > > make: Entering directory '/c/code/HEAD/testsuite/tests' > > PYTHON="python3" "python3" ../driver/runtests.py -e > "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db > -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output'" -e config.compiler_debugged=False -e > ghc_with_native_codegen=True -e config.have_vanilla=True -e > config.have_dynamic=False -e config.have_profiling=False -e > ghc_with_threaded_rts=True -e ghc_with_dynamic_rts=False -e > config.have_interp=True -e config.unregisterised=False -e > config.have_gdb=False -e config.have_readelf=True -e > config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e > ghc_with_smp=True -e ghc_with_llvm=False -e windows=True -e darwin=False -e > config.in_tree_compiler=True -e config.cleanup=True -e config.local=True > --rootdir=. --config-file=../config/ghc -e > 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e > 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() > or config.timeout' -e 'config.exeext=".exe"' -e > 'config.top="/c/code/HEAD/testsuite"' --config > 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config > 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' > --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config > 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config > 'timeout_prog="../timeout/install-inplace/bin/timeout.exe"' -e > "config.stage=2" --rootdir=../../libraries/Win32/tests > --rootdir=../../libraries/array/tests > --rootdir=../../libraries/base/tests > --rootdir=../../libraries/binary/tests > --rootdir=../../libraries/bytestring/tests > --rootdir=../../libraries/containers/tests > --rootdir=../../libraries/deepseq/tests > --rootdir=../../libraries/directory/tests > --rootdir=../../libraries/filepath/tests > --rootdir=../../libraries/ghc-compact/tests > --rootdir=../../libraries/ghc-heap/tests > --rootdir=../../libraries/ghc-prim/tests > --rootdir=../../libraries/haskeline/tests > --rootdir=../../libraries/hpc/tests > --rootdir=../../libraries/pretty/tests > --rootdir=../../libraries/process/tests > --rootdir=../../libraries/stm/tests > --rootdir=../../libraries/template-haskell/tests > --rootdir=../../libraries/text/tests \ > > --only=T10420 --only=T10672_x64 --only=T13385 --only=T14452 > --only=T15815 --only=T3307 --only=T3319 --only=T4006 > --only=TH_scopedTvs --only=environment001 --only=plugin-recomp-change > --only=plugin-recomp-flags --only=plugin-recomp-impure > --only=plugin-recomp-pure --only=plugins07 --only=plugins09 > --only=plugins10 --only=plugins11 --only=plugins13 --only=plugins14 > --only=print017 \ > > \ > > \ > > \ > > \ > > \ > > > > Timeout is 300 > > 0 > > Found 398 .T files... > > Beginning test run at Fri Nov 30 21:07:17 2018 GMTST > > ====> Scanning ./ado/all.T > > ====> Scanning ./annotations/should_compile/all.T > > ====> Scanning ./annotations/should_compile/T13818/all.T > > …lots more “Scanning” lines… > > ====> Scanning ../../libraries/ghc-heap/tests/all.T > > ====> Scanning ../../libraries/hpc/tests/fork/test.T--- > driver/T14452.run/T14452.stdout.normalised 2018-11-30 > 21:07:36.565566000 +0000 > > +++ driver/T14452.run/T14452.run.stdout.normalised 2018-11-30 > 21:07:36.567569500 +0000 > > @@ -1 +1 @@ > > --O3 > > +"-O3" > > --- libraries/base/tests/T4006.run/T4006.stdout.normalised > 2018-11-30 21:15:19.867313900 +0000 > > +++ libraries/base/tests/T4006.run/T4006.run.stdout.normalised > 2018-11-30 21:15:19.870787900 +0000 > > @@ -1,2 +1,2 @@ > > It works here > > - > > + > > --- > libraries/base/tests/IO/environment001.run/environment001.stdout.normalised > 2018-11-30 21:16:00.645817500 +0000 > > +++ > libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised > 2018-11-30 21:16:00.654738900 +0000 > > @@ -1,7 +1,8 @@ > > - > > -Test 1: 3 > > - > > -Test 2: 1 > > + > > + > > +Test 1: 9 > > + > > +Test 2: 3 > > ! > > Test 3: 3 > > ["a","b"] > > > > ====> Scanning ../../libraries/hpc/tests/function/test.T > > ====> Scanning ../../libraries/hpc/tests/function2/test.T > > ====> Scanning ../../libraries/hpc/tests/ghc_ghci/test.T > > ====> Scanning ../../libraries/hpc/tests/raytrace/test.T > > ====> Scanning ../../libraries/hpc/tests/raytrace/tixs/test.T > > ====> Scanning ../../libraries/hpc/tests/simple/test.T > > ====> Scanning ../../libraries/hpc/tests/simple/tixs/test.T > > ====> Scanning ../../libraries/process/tests/all.T > > ====> Scanning ../../libraries/process/tests/T9775/all.T > > ====> Scanning ../../libraries/stm/tests/all.T > > ====> Scanning ../../libraries/template-haskell/tests/all.T > > =====> T14452(normal) 1 of 21 [0, 0, 0] > > cd "driver/T14452.run" && $MAKE -s --no-print-directory T14452 > > Actual stdout output differs from expected: > > diff -uw "driver/T14452.run/T14452.stdout.normalised" > "driver/T14452.run/T14452.run.stdout.normalised" > > *** unexpected failure for T14452(normal) > > =====> T13385(ghci) 2 of 21 [0, 1, 0] > > cd "ghci/scripts/T13385.run" && > HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output -XRebindableSyntax" > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 > -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XRebindableSyntax < T13385.script > > =====> print017(ghci) 3 of 21 [0, 1, 0] > > cd "ghci.debugger/scripts/print017.run" && > HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output " > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 > -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -ignore-dot-ghci< print017.script > > =====> print017(ghci-ext) 3 of 21 [0, 1, 0] > > cd "ghci.debugger/scripts/print017.run" && > HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output " > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 > -ignore-dot-ghci -fno-ghci-history -fexternal-interpreter +RTS -I0.1 -RTS > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -ignore-dot-ghci< print017.script > > =====> plugin-recomp-change(normal) 4 of 21 [0, 1, 0] > > cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory > plugin-recomp-change > > =====> T10672_x64(normal) 5 of 21 [0, 1, 0] > > cd "rts/T10672/T10672_x64.run" && $MAKE -s --no-print-directory > T10672_x64 > > Timeout happened...killed process "cd "rts/T10672/T10672_x64.run" && $MAKE > -s --no-print-directory T10672_x64 "... > > > > Wrong exit code for T10672_x64()(expected 0 , actual 99 ) > > *** unexpected failure for T10672_x64(normal) > > =====> TH_scopedTvs(normal) 6 of 21 [0, 2, 0] > > cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell -v0 > > =====> TH_scopedTvs(ext-interp) 6 of 21 [0, 2, 0] > > cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -fexternal-interpreter -v0 > > =====> T3319(normal) 7 of 21 [0, 2, 0] > > cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -ddump-splices -v0 > > =====> T3319(ext-interp) 7 of 21 [0, 2, 0] > > cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -fexternal-interpreter -ddump-splices -v0 > > =====> T15815(normal) 8 of 21 [0, 2, 0] > > cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make > T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell -v0 -static > > =====> T15815(ext-interp) 8 of 21 [0, 2, 0] > > cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make > T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -XTemplateHaskell -package template-haskell > -fexternal-interpreter -v0 -static > > =====> T4006(normal) 9 of 21 [0, 2, 0] > > cd "libraries/base/tests/T4006.run" && > "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -o T4006 T4006.hs -dcore-lint > -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output > > cd "libraries/base/tests/T4006.run" && ./T4006 > > Actual stdout output differs from expected: > > diff -uw "libraries/base/tests/T4006.run/T4006.stdout.normalised" > "libraries/base/tests/T4006.run/T4006.run.stdout.normalised" > > *** unexpected failure for T4006(normal) > > =====> T3307(normal) 10 of 21 [0, 3, 0] > > cd "libraries/base/tests/IO/T3307.run" && $MAKE -s --no-print-directory > T3307-test > > Wrong exit code for T3307()(expected 0 , actual 2 ) > > Stdout ( T3307 ): > > Test 1 > > [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] > > Ni hao > > Test 2 > > [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] > > Ni hao > > Test 3 > > [99,104,105,110,101,115,101,45,102,105,108,101,45,23567,35828] > > Stderr ( T3307 ): > > *** framework failure for T3307(normal) 'latin-1' codec can't encode > characters in position 24-25: ordinal not in range(256) > > =====> environment001(normal) 11 of 21 [0, 3, 1] > > cd "libraries/base/tests/IO/environment001.run" && $MAKE -s > --no-print-directory environment001-test > > Actual stdout output differs from expected: > > diff -uw > "libraries/base/tests/IO/environment001.run/environment001.stdout.normalised" > "libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised" > > *** unexpected failure for environment001(normal) > > =====> plugins07(normal) 12 of 21 [0, 4, 1] > > cd "plugins/plugins07.run" && $MAKE -s --no-print-directory -C > rule-defining-plugin package.plugins07 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins07.run" && $MAKE -s --no-print-directory plugins07 > > =====> plugins09(normal) 13 of 21 [0, 4, 1] > > cd "plugins/plugins09.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins09 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins09.run" && $MAKE -s --no-print-directory plugins09 > > Actual stdout output differs from expected: > > diff -uw "plugins/plugins09.run/plugins09.stdout.normalised" > "plugins/plugins09.run/plugins09.run.stdout.normalised"--- > plugins/plugins09.run/plugins09.stdout.normalised 2018-11-30 > 21:17:20.709370700 +0000 > > +++ plugins/plugins09.run/plugins09.run.stdout.normalised 2018-11-30 > 21:17:20.711314000 +0000 > > @@ -1,9 +0,0 @@ > > -parsePlugin(a,b) > > -interfacePlugin: Prelude > > -interfacePlugin: GHC.Float > > -interfacePlugin: GHC.Base > > -typeCheckPlugin (rn) > > -interfacePlugin: GHC.Types > > -typeCheckPlugin (tc) > > -interfacePlugin: GHC.Integer.Type > > -interfacePlugin: GHC.Natural > > --- plugins/plugins10.run/plugins10.stdout.normalised 2018-11-30 > 21:17:57.644357800 +0000 > > +++ plugins/plugins10.run/plugins10.run.stdout.normalised 2018-11-30 > 21:17:57.646078700 +0000 > > @@ -1,21 +0,0 @@ > > -parsePlugin() > > -interfacePlugin: Prelude > > -interfacePlugin: Language.Haskell.TH > > > -interfacePlugin: Language.Haskell.TH.Quote > > -interfacePlugin: GHC.Float > > -interfacePlugin: GHC.Base > > -interfacePlugin: Language.Haskell.TH.Syntax > > -typeCheckPlugin (rn) > > -interfacePlugin: GHC.Types > > -typeCheckPlugin (tc) > > -interfacePlugin: GHC.Integer.Type > > -interfacePlugin: GHC.Natural > > -parsePlugin(a) > > -typeCheckPlugin (rn) > > -interfacePlugin: Language.Haskell.TH.Lib.Internal > > -metaPlugin: return [] > > -metaPlugin: quoteExp stringify "x" > > -interfacePlugin: GHC.CString > > -typeCheckPlugin (rn) > > -typeCheckPlugin (rn) > > -typeCheckPlugin (tc) > > > > *** unexpected failure for plugins09(normal) > > =====> plugins10(normal) 14 of 21 [0, 5, 1] > > cd "plugins/plugins10.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins10 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins10.run" && $MAKE -s --no-print-directory plugins10 > > Actual stdout output differs from expected: > > diff -uw "plugins/plugins10.run/plugins10.stdout.normalised" > "plugins/plugins10.run/plugins10.run.stdout.normalised" > > *** unexpected failure for plugins10(normal) > > =====> plugins11(normal) 15 of 21 [0, 6, 1] > > cd "plugins/plugins11.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins11 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins11.run" && $MAKE -s --no-print-directory plugins11 > > Timeout happened...killed process "cd "plugins/plugins11.run" && $MAKE -s > --no-print-directory plugins11 "... > > > > Wrong exit code for plugins11()(expected 0 , actual 99 ) > > *** unexpected failure for plugins11(normal) > > =====> plugins13(normal) 16 of 21 [0, 7, 1] > > cd "plugins/plugins13.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins13 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins13.run" && $MAKE -s --no-print-directory plugins13 > > =====> plugins14(normal) 17 of 21 [0, 7, 1] > > cd "plugins/plugins14.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins14 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins14.run" && $MAKE -s --no-print-directory plugins14 > > =====> T10420(normal) 18 of 21 [0, 7, 1] > > cd "plugins/T10420.run" && $MAKE -s --no-print-directory -C > rule-defining-plugin package.T10420 TOP=/c/code/HEAD/testsuite > > cd "plugins/T10420.run" && $MAKE -s --no-print-directory T10420 > > =====> plugin-recomp-pure(normal) 19 of 21 [0, 7, 1] > > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory > plugin-recomp-pure > > Timeout happened...killed process "cd "plugins/plugin-recomp-pure.run" && > $MAKE -s --no-print-directory plugin-recomp-pure "... > > > > Wrong exit code for plugin-recomp-pure()(expected 0 , actual 99 ) > > Stdout ( plugin-recomp-pure ): > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) > > Stderr ( plugin-recomp-pure ): > > Simple Plugin Passes Queried > > Got options: > > Simple Plugin Pass Run > > *** unexpected failure for plugin-recomp-pure(normal) > > =====> plugin-recomp-impure(normal) 20 of 21 [0, 8, 1] > > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory > plugin-recomp-impure > > Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) > > Stdout ( plugin-recomp-impure ): > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) > > Linking plugin-recomp-test.exe ... > > [1 of 1] Compiling Main ( plugin-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 reading 0xa824 > > > > Attempting to reconstruct a stack trace... > > > > Frame Code address > > * 0x49adab0 0x1eb49ec 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" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory > plugin-recomp-flags > > Traceback (most recent call last): > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 824, in > test_common_work > > do_test(name, way, func, args, files) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 910, in do_test > > result = func(*[name,way] + args) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 993, in run_command > > return simple_run( name, '', override_options(cmd), '' ) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in simple_run > > dump_stderr(name) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in > dump_stderr > > print(str) > > UnicodeEncodeError: 'latin-1' codec can't encode characters in position > 24-25: ordinal not in range(256) > > > > Unexpected 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 cases, of which > > 11 were skipped > > > > 0 had missing libraries > > 15 expected passes > > 0 expected failures > > > > 1 caused framework failures > > 0 caused framework warnings > > 0 unexpected passes > > 9 unexpected failures > > 0 unexpected stat failures > > > > Unexpected failures: > > driver/T14452.run T14452 [bad stdout] (normal) > > rts/T10672/T10672_x64.run T10672_x64 [bad exit code] > (normal) > > libraries/base/tests/T4006.run T4006 [bad stdout] (normal) > > libraries/base/tests/IO/environment001.run environment001 [bad stdout] > (normal) > > plugins/plugins09.run plugins09 [bad stdout] > (normal) > > plugins/plugins10.run plugins10 [bad stdout] > (normal) > > plugins/plugins11.run plugins11 [bad exit code] > (normal) > > plugins/plugin-recomp-pure.run plugin-recomp-pure [bad > exit code] (normal) > > plugins/plugin-recomp-impure.run plugin-recomp-impure [bad > exit code] (normal) > > > > Framework failures: > > libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec > can't encode characters in position 24-25: ordinal not in range(256)) > > > > Appending 0 stats to git notes. > > make: *** [../mk/test.mk:342 > : > test] Error 1 > > make: Leaving directory '/c/code/HEAD/testsuite/tests' > > /c/code/HEAD$ > > > > > > *From:* Phyx > *Sent:* 30 November 2018 11:58 > *To:* Simon Peyton Jones > *Subject:* Re: Windows test failures > > > > At the end of the first test run it would have given a list of tests that > failed and a line saying TEST=".... List of tests..." > > > > Copy that line and at the root of the checkout do > > > > make TEST=".... List of tests..." test -C testsuite/tests > > > > (that's uppercase C). This will run everything using one thread. :) > > > > Should give a good starting point as to what's wrong. > > > > Kind regards, > > Tamar > > On Fri, Nov 30, 2018, 10:30 Simon Peyton Jones > wrote: > > So I just say > > make TEST > > is that right? > > > > Or is it > > make THREADS=1 > > > > or what? Sorry to be dim > > > > *From:* Phyx > *Sent:* 30 November 2018 08:05 > *To:* Simon Peyton Jones > *Cc:* ghc-devs > *Subject:* Re: Windows test failures > > > > 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 increasingly unstable > under threads for some reason. > > > > I also haven't run trunk yet since last week so they could be new.. > > > > But rerunning the fails with no threads should give a better idea. > > > > Regards, > > Tamar > > On Fri, Nov 30, 2018, 07:46 Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > Ben, Phyx, and other CI folk > > ‘sh validate –fast’ still gives a lot of failures on Window. The output > is below. I would be so good to get this to zero! > > (another minor thing is that it would be great to eliminate the long path > at the beginning – this is platform independent – I have to delete manually > many times each day. > > Thanks > > Simon > > Unexpected passes: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/rts/T9405.run T9405 [unexpected] (normal) > > > > Unexpected failures: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/driver/T14452.run T14452 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/linking/ghcilink001.run ghcilink001 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit > code] (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/scripts/ghci050.run ghci050 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/should_run/T14963a.run T14963a [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit > code] (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/indexed-types/should_fail/T7102a.run T7102a [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-change.run plugin-recomp-change > [bad exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/TH_spliceGuard.run TH_spliceGuard [exit > code non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/TH_overlaps.run TH_overlaps [exit code > non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T5886.run T5886 [exit code non-0] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T10697_decided_3.run T10697_decided_3 [exit > code non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T11629.run T11629 [exit code non-0] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/T4006.run T4006 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/IO/environment001.run environment001 [bad > stdout] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/should_run/T15633b.run T15633b [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins07.run plugins07 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins09.run plugins09 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins10.run plugins10 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins11.run plugins11 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/T10420.run T10420 [bad exit code] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad > exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-impure.run plugin-recomp-impure > [bad exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-flags.run plugin-recomp-flags [bad > exit code] (normal) > > > > Framework failures: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run MultiLayerModules [runTest] > (Unhandled exception during cleanup: Unable to remove folder > '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run': [Errno 13] Permission denied: > '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run' > > Unable to start current test.) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec > can't encode characters in position 24-25: ordinal not in range(256)) > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Dec 6 23:50:45 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 6 Dec 2018 23:50:45 +0000 Subject: Windows test failures In-Reply-To: References: Message-ID: Aha! Yes, in libraries/base/tests, I find that make TEST=T3307 fails; but succeeds with export LANG=en_GB.UTF-8 Progress! Simon From: Phyx Sent: 06 December 2018 23:43 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Devs Subject: Re: Windows test failures Hi Simon, > Does that help at all? > > I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test its efficacy by running one test rather than 6,000 of them? In which case, which one? Yes, "en_GB" doesn't seem to be a unicode locale, one test you can try to check is T3307,so make TEST="T3307" -C testsuite/tests/ I tried using your "en_GB" locale and the test failed for me too then. Kind regards, Tamar On Thu, Dec 6, 2018 at 2:17 PM Simon Peyton Jones > wrote: Hi Tamar Thanks for working on this. if it's an msys2 shell, what does "locale" return? It’s a shell running inside emacs. Here’s what locale returns /c/tmp$ locale LANG=en_GB LC_CTYPE="en_GB" LC_NUMERIC="en_GB" LC_TIME="en_GB" LC_COLLATE="en_GB" LC_MONETARY="en_GB" LC_MESSAGES="en_GB" LC_ALL= Does that help at all? I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test 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 at 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 at already, seems to have something to do with the libstdc++ destructors. Plugins 09 and 10 are the other two I know about, but haven't had time to look at them yet. Frankly I know too little about plugins to make an accurate determination here, but the input files are empty yet it expects output, so I don't know what it's supposed to do here. If someone who knows more about plugins can chime in that would save some time. The segfaulting plugin I haven't triaged yet. Now the remaining failures aside from T14452 that Roland is taking care of, seem to have to do with your locale in your console. You seem to be running the tests in a console that has latin-1 locale? So some unicode characters fail encoding/decoding. If it's a Windows shell you can change it to utf-8 using "chcp 65001", if it's an msys2 shell, what does "locale" return? For reference mine is $ locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_ALL= If it does say latin1 you can change it with export LANG=en_GB.UTF-8 This should fix more of the tests. The reason I don't mark the remaining tests as expect fail yet is because I haven't had the time to triage them, so I don't know their severity and last time there were a few nasty issues hidden in them. Unfortunately I won't have time to look at them till next weekend. Thanks, Tamar On Fri, Nov 30, 2018 at 9:49 PM Simon Peyton Jones > wrote: At the end of the first test run it would have given a list of tests that failed and a line saying TEST=".... List of tests..." Copy that line and at the root of the checkout do make TEST=".... List of tests..." test -C testsuite/tests (that's uppercase C). This will run everything using one thread. :) OK, done. Results below. Simon /c/code/HEAD$ make TEST="T10420 T10672_x64 T13385 T14452 T15815 T3307 T3319 T4006 TH_scopedTvs environment001 plugin-recomp-change plugin-recomp-flags plugin-recomp-impure plugin-recomp-pure plugins07 plugins09 plugins10 plugins11 plugins13 plugins14 print017" test -C testsuite/tests make: Entering directory '/c/code/HEAD/testsuite/tests' PYTHON="python3" "python3" ../driver/runtests.py -e "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output'" -e config.compiler_debugged=False -e ghc_with_native_codegen=True -e config.have_vanilla=True -e config.have_dynamic=False -e config.have_profiling=False -e ghc_with_threaded_rts=True -e ghc_with_dynamic_rts=False -e config.have_interp=True -e config.unregisterised=False -e config.have_gdb=False -e config.have_readelf=True -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=True -e ghc_with_llvm=False -e windows=True -e darwin=False -e config.in_tree_compiler=True -e config.cleanup=True -e config.local=True --rootdir=. --config-file=../config/ghc -e 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/c/code/HEAD/testsuite"' --config 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../timeout/install-inplace/bin/timeout.exe"' -e "config.stage=2" --rootdir=../../libraries/Win32/tests --rootdir=../../libraries/array/tests --rootdir=../../libraries/base/tests --rootdir=../../libraries/binary/tests --rootdir=../../libraries/bytestring/tests --rootdir=../../libraries/containers/tests --rootdir=../../libraries/deepseq/tests --rootdir=../../libraries/directory/tests --rootdir=../../libraries/filepath/tests --rootdir=../../libraries/ghc-compact/tests --rootdir=../../libraries/ghc-heap/tests --rootdir=../../libraries/ghc-prim/tests --rootdir=../../libraries/haskeline/tests --rootdir=../../libraries/hpc/tests --rootdir=../../libraries/pretty/tests --rootdir=../../libraries/process/tests --rootdir=../../libraries/stm/tests --rootdir=../../libraries/template-haskell/tests --rootdir=../../libraries/text/tests \ --only=T10420 --only=T10672_x64 --only=T13385 --only=T14452 --only=T15815 --only=T3307 --only=T3319 --only=T4006 --only=TH_scopedTvs --only=environment001 --only=plugin-recomp-change --only=plugin-recomp-flags --only=plugin-recomp-impure --only=plugin-recomp-pure --only=plugins07 --only=plugins09 --only=plugins10 --only=plugins11 --only=plugins13 --only=plugins14 --only=print017 \ \ \ \ \ \ Timeout is 300 0 Found 398 .T files... Beginning test run at Fri Nov 30 21:07:17 2018 GMTST ====> Scanning ./ado/all.T ====> Scanning ./annotations/should_compile/all.T ====> Scanning ./annotations/should_compile/T13818/all.T …lots more “Scanning” lines… ====> Scanning ../../libraries/ghc-heap/tests/all.T ====> Scanning ../../libraries/hpc/tests/fork/test.T--- driver/T14452.run/T14452.stdout.normalised 2018-11-30 21:07:36.565566000 +0000 +++ driver/T14452.run/T14452.run.stdout.normalised 2018-11-30 21:07:36.567569500 +0000 @@ -1 +1 @@ --O3 +"-O3" --- libraries/base/tests/T4006.run/T4006.stdout.normalised 2018-11-30 21:15:19.867313900 +0000 +++ libraries/base/tests/T4006.run/T4006.run.stdout.normalised 2018-11-30 21:15:19.870787900 +0000 @@ -1,2 +1,2 @@ It works here - + --- libraries/base/tests/IO/environment001.run/environment001.stdout.normalised 2018-11-30 21:16:00.645817500 +0000 +++ libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised 2018-11-30 21:16:00.654738900 +0000 @@ -1,7 +1,8 @@ - -Test 1: 3 - -Test 2: 1 + + +Test 1: 9 + +Test 2: 3 ! Test 3: 3 ["a","b"] ====> Scanning ../../libraries/hpc/tests/function/test.T ====> Scanning ../../libraries/hpc/tests/function2/test.T ====> Scanning ../../libraries/hpc/tests/ghc_ghci/test.T ====> Scanning ../../libraries/hpc/tests/raytrace/test.T ====> Scanning ../../libraries/hpc/tests/raytrace/tixs/test.T ====> Scanning ../../libraries/hpc/tests/simple/test.T ====> Scanning ../../libraries/hpc/tests/simple/tixs/test.T ====> Scanning ../../libraries/process/tests/all.T ====> Scanning ../../libraries/process/tests/T9775/all.T ====> Scanning ../../libraries/stm/tests/all.T ====> Scanning ../../libraries/template-haskell/tests/all.T =====> T14452(normal) 1 of 21 [0, 0, 0] cd "driver/T14452.run" && $MAKE -s --no-print-directory T14452 Actual stdout output differs from expected: diff -uw "driver/T14452.run/T14452.stdout.normalised" "driver/T14452.run/T14452.run.stdout.normalised" *** unexpected failure for T14452(normal) =====> T13385(ghci) 2 of 21 [0, 1, 0] cd "ghci/scripts/T13385.run" && HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XRebindableSyntax" "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XRebindableSyntax < T13385.script =====> print017(ghci) 3 of 21 [0, 1, 0] cd "ghci.debugger/scripts/print017.run" && HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output " "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -ignore-dot-ghci< print017.script =====> print017(ghci-ext) 3 of 21 [0, 1, 0] cd "ghci.debugger/scripts/print017.run" && HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output " "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 -ignore-dot-ghci -fno-ghci-history -fexternal-interpreter +RTS -I0.1 -RTS -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -ignore-dot-ghci< print017.script =====> plugin-recomp-change(normal) 4 of 21 [0, 1, 0] cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory plugin-recomp-change =====> T10672_x64(normal) 5 of 21 [0, 1, 0] cd "rts/T10672/T10672_x64.run" && $MAKE -s --no-print-directory T10672_x64 Timeout happened...killed process "cd "rts/T10672/T10672_x64.run" && $MAKE -s --no-print-directory T10672_x64 "... Wrong exit code for T10672_x64()(expected 0 , actual 99 ) *** unexpected failure for T10672_x64(normal) =====> TH_scopedTvs(normal) 6 of 21 [0, 2, 0] cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -v0 =====> TH_scopedTvs(ext-interp) 6 of 21 [0, 2, 0] cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 =====> T3319(normal) 7 of 21 [0, 2, 0] cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -ddump-splices -v0 =====> T3319(ext-interp) 7 of 21 [0, 2, 0] cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -ddump-splices -v0 =====> T15815(normal) 8 of 21 [0, 2, 0] cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -v0 -static =====> T15815(ext-interp) 8 of 21 [0, 2, 0] cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 -static =====> T4006(normal) 9 of 21 [0, 2, 0] cd "libraries/base/tests/T4006.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -o T4006 T4006.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "libraries/base/tests/T4006.run" && ./T4006 Actual stdout output differs from expected: diff -uw "libraries/base/tests/T4006.run/T4006.stdout.normalised" "libraries/base/tests/T4006.run/T4006.run.stdout.normalised" *** unexpected failure for T4006(normal) =====> T3307(normal) 10 of 21 [0, 3, 0] cd "libraries/base/tests/IO/T3307.run" && $MAKE -s --no-print-directory T3307-test Wrong exit code for T3307()(expected 0 , actual 2 ) Stdout ( T3307 ): Test 1 [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] Ni hao Test 2 [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] Ni hao Test 3 [99,104,105,110,101,115,101,45,102,105,108,101,45,23567,35828] Stderr ( T3307 ): *** framework failure for T3307(normal) 'latin-1' codec can't encode characters in position 24-25: ordinal not in range(256) =====> environment001(normal) 11 of 21 [0, 3, 1] cd "libraries/base/tests/IO/environment001.run" && $MAKE -s --no-print-directory environment001-test Actual stdout output differs from expected: diff -uw "libraries/base/tests/IO/environment001.run/environment001.stdout.normalised" "libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised" *** unexpected failure for environment001(normal) =====> plugins07(normal) 12 of 21 [0, 4, 1] cd "plugins/plugins07.run" && $MAKE -s --no-print-directory -C rule-defining-plugin package.plugins07 TOP=/c/code/HEAD/testsuite cd "plugins/plugins07.run" && $MAKE -s --no-print-directory plugins07 =====> plugins09(normal) 13 of 21 [0, 4, 1] cd "plugins/plugins09.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins09 TOP=/c/code/HEAD/testsuite cd "plugins/plugins09.run" && $MAKE -s --no-print-directory plugins09 Actual stdout output differs from expected: diff -uw "plugins/plugins09.run/plugins09.stdout.normalised" "plugins/plugins09.run/plugins09.run.stdout.normalised"--- plugins/plugins09.run/plugins09.stdout.normalised 2018-11-30 21:17:20.709370700 +0000 +++ plugins/plugins09.run/plugins09.run.stdout.normalised 2018-11-30 21:17:20.711314000 +0000 @@ -1,9 +0,0 @@ -parsePlugin(a,b) -interfacePlugin: Prelude -interfacePlugin: GHC.Float -interfacePlugin: GHC.Base -typeCheckPlugin (rn) -interfacePlugin: GHC.Types -typeCheckPlugin (tc) -interfacePlugin: GHC.Integer.Type -interfacePlugin: GHC.Natural --- plugins/plugins10.run/plugins10.stdout.normalised 2018-11-30 21:17:57.644357800 +0000 +++ plugins/plugins10.run/plugins10.run.stdout.normalised 2018-11-30 21:17:57.646078700 +0000 @@ -1,21 +0,0 @@ -parsePlugin() -interfacePlugin: Prelude -interfacePlugin: Language.Haskell.TH -interfacePlugin: Language.Haskell.TH.Quote -interfacePlugin: GHC.Float -interfacePlugin: GHC.Base -interfacePlugin: Language.Haskell.TH.Syntax -typeCheckPlugin (rn) -interfacePlugin: GHC.Types -typeCheckPlugin (tc) -interfacePlugin: GHC.Integer.Type -interfacePlugin: GHC.Natural -parsePlugin(a) -typeCheckPlugin (rn) -interfacePlugin: Language.Haskell.TH.Lib.Internal -metaPlugin: return [] -metaPlugin: quoteExp stringify "x" -interfacePlugin: GHC.CString -typeCheckPlugin (rn) -typeCheckPlugin (rn) -typeCheckPlugin (tc) *** unexpected failure for plugins09(normal) =====> plugins10(normal) 14 of 21 [0, 5, 1] cd "plugins/plugins10.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins10 TOP=/c/code/HEAD/testsuite cd "plugins/plugins10.run" && $MAKE -s --no-print-directory plugins10 Actual stdout output differs from expected: diff -uw "plugins/plugins10.run/plugins10.stdout.normalised" "plugins/plugins10.run/plugins10.run.stdout.normalised" *** unexpected failure for plugins10(normal) =====> plugins11(normal) 15 of 21 [0, 6, 1] cd "plugins/plugins11.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins11 TOP=/c/code/HEAD/testsuite cd "plugins/plugins11.run" && $MAKE -s --no-print-directory plugins11 Timeout happened...killed process "cd "plugins/plugins11.run" && $MAKE -s --no-print-directory plugins11 "... Wrong exit code for plugins11()(expected 0 , actual 99 ) *** unexpected failure for plugins11(normal) =====> plugins13(normal) 16 of 21 [0, 7, 1] cd "plugins/plugins13.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins13 TOP=/c/code/HEAD/testsuite cd "plugins/plugins13.run" && $MAKE -s --no-print-directory plugins13 =====> plugins14(normal) 17 of 21 [0, 7, 1] cd "plugins/plugins14.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins14 TOP=/c/code/HEAD/testsuite cd "plugins/plugins14.run" && $MAKE -s --no-print-directory plugins14 =====> T10420(normal) 18 of 21 [0, 7, 1] cd "plugins/T10420.run" && $MAKE -s --no-print-directory -C rule-defining-plugin package.T10420 TOP=/c/code/HEAD/testsuite cd "plugins/T10420.run" && $MAKE -s --no-print-directory T10420 =====> plugin-recomp-pure(normal) 19 of 21 [0, 7, 1] cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory plugin-recomp-pure Timeout happened...killed process "cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory plugin-recomp-pure "... Wrong exit code for plugin-recomp-pure()(expected 0 , actual 99 ) Stdout ( plugin-recomp-pure ): [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-recomp-test.o ) Stderr ( plugin-recomp-pure ): Simple Plugin Passes Queried Got options: Simple Plugin Pass Run *** unexpected failure for plugin-recomp-pure(normal) =====> plugin-recomp-impure(normal) 20 of 21 [0, 8, 1] cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory plugin-recomp-impure Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) Stdout ( plugin-recomp-impure ): [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-recomp-test.o ) Linking plugin-recomp-test.exe ... [1 of 1] Compiling Main ( plugin-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 reading 0xa824 Attempting to reconstruct a stack trace... Frame Code address * 0x49adab0 0x1eb49ec 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" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory plugin-recomp-flags Traceback (most recent call last): File "/c/code/HEAD/testsuite/driver/testlib.py", line 824, in test_common_work do_test(name, way, func, args, files) File "/c/code/HEAD/testsuite/driver/testlib.py", line 910, in do_test result = func(*[name,way] + args) File "/c/code/HEAD/testsuite/driver/testlib.py", line 993, in run_command return simple_run( name, '', override_options(cmd), '' ) File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in simple_run dump_stderr(name) File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in dump_stderr print(str) UnicodeEncodeError: 'latin-1' codec can't encode characters in position 24-25: ordinal not in range(256) Unexpected 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 cases, of which 11 were skipped 0 had missing libraries 15 expected passes 0 expected failures 1 caused framework failures 0 caused framework warnings 0 unexpected passes 9 unexpected failures 0 unexpected stat failures Unexpected failures: driver/T14452.run T14452 [bad stdout] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) libraries/base/tests/T4006.run T4006 [bad stdout] (normal) libraries/base/tests/IO/environment001.run environment001 [bad stdout] (normal) plugins/plugins09.run plugins09 [bad stdout] (normal) plugins/plugins10.run plugins10 [bad stdout] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) Framework failures: libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec can't encode characters in position 24-25: ordinal not in range(256)) Appending 0 stats to git notes. make: *** [../mk/test.mk:342: test] Error 1 make: Leaving directory '/c/code/HEAD/testsuite/tests' /c/code/HEAD$ From: Phyx > Sent: 30 November 2018 11:58 To: Simon Peyton Jones > Subject: Re: Windows test failures At the end of the first test run it would have given a list of tests that failed and a line saying TEST=".... List of tests..." Copy that line and at the root of the checkout do make TEST=".... List of tests..." test -C testsuite/tests (that's uppercase C). This will run everything using one thread. :) Should give a good starting point as to what's wrong. Kind regards, Tamar On Fri, Nov 30, 2018, 10:30 Simon Peyton Jones > wrote: So I just say make TEST is that right? Or is it make THREADS=1 or what? Sorry to be dim From: Phyx > Sent: 30 November 2018 08:05 To: Simon Peyton Jones > Cc: ghc-devs > Subject: Re: Windows test failures 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 increasingly unstable under threads for some reason. I also haven't run trunk yet since last week so they could be new.. But rerunning the fails with no threads should give a better idea. Regards, Tamar On Fri, Nov 30, 2018, 07:46 Simon Peyton Jones via ghc-devs > wrote: Ben, Phyx, and other CI folk ‘sh validate –fast’ still gives a lot of failures on Window. The output is below. I would be so good to get this to zero! (another minor thing is that it would be great to eliminate the long path at the beginning – this is platform independent – I have to delete manually many times each day. Thanks Simon Unexpected passes: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T9405.run T9405 [unexpected] (normal) Unexpected failures: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/driver/T14452.run T14452 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/linking/ghcilink001.run ghcilink001 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/scripts/ghci050.run ghci050 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T14963a.run T14963a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/indexed-types/should_fail/T7102a.run T7102a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_spliceGuard.run TH_spliceGuard [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_overlaps.run TH_overlaps [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T5886.run T5886 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T10697_decided_3.run T10697_decided_3 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T11629.run T11629 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/T4006.run T4006 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/IO/environment001.run environment001 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T15633b.run T15633b [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins07.run plugins07 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins09.run plugins09 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins10.run plugins10 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins11.run plugins11 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/T10420.run T10420 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) Framework failures: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run MultiLayerModules [runTest] (Unhandled exception during cleanup: Unable to remove folder '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run': [Errno 13] Permission denied: '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run' Unable to start current test.) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec can't encode characters in position 24-25: ordinal not in range(256)) _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Thu Dec 6 23:55:58 2018 From: lonetiger at gmail.com (Phyx) Date: Thu, 6 Dec 2018 23:55:58 +0000 Subject: Windows test failures In-Reply-To: <1543924353.2529.1.camel@bluewin.ch> References: <1543851298.2411.1.camel@bluewin.ch> <1543924353.2529.1.camel@bluewin.ch> Message-ID: 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. if the plugins use the stdout caf then it should be using the same CharBuffer. You can verify this by doing something like cbuf <- readIORef haCharBuffer stdout summaryBuffer cbuf putStrLn $ "buffer: " ++ show cbuf at the places you check the buffer mode. > However I don't know whether this is possible / difficult / easy? > What's your opinion? On Tue, Dec 4, 2018 at 11:52 AM Roland Senn wrote: > 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 the text "COMPILER > About to call plugin parse" and the result of the buffer-mode query. > 3.) In the plugin, in the function parsedPlugin, I query and print (to > stdout) the buffer mode. > 4.) I added the heading PLUGIN to the normal parse message issued by the > parsedPlugin function > 5.) In the compiler (HscMain.hs) just after returning from the plugin, I > print the line "COMPILER Returning from plugin parse" to stdout. > 6.) In the plugin function interfaceLoadPlugin' that is called much > later, I flush stdout, and add the heading "PLUGIN". > > This gives the following interesting result: > > COMPILER About to call plugin parse: LineBuffering > COMPILER Returning from plugin parse > PLUGIN Buffermode: BlockBuffering Nothing > PLUGIN parsePlugin(a,b) > PLUGIN interfacePlugin: Prelude > ... > > The output lines do not appear in the sequence they were produced!! > The plugin doesn't see/inherit the BlockBuffer mode (LineBuffering) set by > the compiler!! > > This is a strong indication, that *there are two different buffers for > stdout*. One in the compiler and another one in the plugin. > At the end of the processing, the buffer in the compiler is automatically > flushed, however the buffer in the plugin never gets flushed! > > LINUX > ===== > I did a similar test in Linux, however, here I set the buffer mode to > 'Blockmode Nothing' and I didn't do a manual flush in the plugin. I got the > following result: > > COMPILER About to call plugin parse: Buffering mode: BlockBuffering > Nothing > PLUGIN Buffering: BlockBuffering Nothing > PLUGIN parsePlugin(a,b) > COMPILER Returning from plugin parse > PLUGIN interfacePlugin: Prelude > ... > > Here the lines are in the same order as they were produced. > The setting of the Buffering mode is inherited by the plugin. > > I think, on Linux the compiler and the plugin share the same buffer. > > To fix the issue on Windows, the compiler and the plugin should use the > same buffer for stdout. > However I don't know whether this is possible / difficult / easy? > What's your opinion? > > Many thanks and kind regards > Roland > > Here are my changes for Windows in code: > > Change in HscMain the line "import System.IO (fixIO)" to "import System.IO > " > > Last lines of function HscMain.hs:hscParse' > > -- apply parse transformation of plugins > let applyPluginAction p opts > = parsedResultAction p opts mod_summary > liftIO $ hSetBuffering stdout LineBuffering > mode <- liftIO $ hGetBuffering stdout > liftIO $ putStrLn ("COMPILER About to call plugin parse: " ++ > show mode) > rsxresult <- withPlugins dflags applyPluginAction res > liftIO $ putStrLn "COMPILER Returning from plugin parse" > return rsxresult > > New code for function SourcePlugin.hs:parsedPlugin > > parsedPlugin opts _ pm > = do > mode <- liftIO $ hGetBuffering stdout > liftIO $ putStrLn $ "PLUGIN Buffermode: " ++ show mode > liftIO $ putStrLn $ "PLUGIN parsePlugin(" ++ intercalate "," opts > ++ ")" > return pm > > New code for function SourcePlugin.hs:interfaceLoadPlugin' > > interfaceLoadPlugin' :: [CommandLineOption] -> ModIface -> IfM lcl ModIface > interfaceLoadPlugin' _ iface > = do liftIO $ putStrLn $ "PLUGIN interfacePlugin: " > ++ (showSDocUnsafe $ ppr $ mi_module iface) > liftIO $ hFlush stdout > return iface > > > > Am Dienstag, den 04.12.2018, 00:02 +0000 schrieb Phyx: > > 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 will always > default to LineBuffering for terminals and BlockBuffering for anything > else. The issue is that msys2 terminals have std handles that are backed by > files instead of pipes. This is an artifact of how they try to emulate > posix shells, See > https://github.com/msys2/msys2/wiki/Porting#standard-streams-in-mintty. > This means that when GHC runs inside an msys2 program such as bash it'll > always default to BlockBuffering. > > > I don't know anything about the "Why" and "Where" in the GHC IO module > on Windows, so I'm unable to come up with a patch. > > The above said the handles should be getting flushed when the finalizers > are run, but these aren't 100% guaranteed so if the tests rely on this then > your solution (to force buffer mode to LineBuffering) sounds like perfectly > adequate. Could you put a patch up with that? > > My new I/O manager takes a different approach to determine the buffer > mode, but I still have some kinks to work out before posting it. > > > PS: I can't say anything about the tests 'plugin-recomp-pure' and > 'plugin-recomp-impure' as these tests run successfully on my (slow) Windows > box. > > These don't fail for me or harbormaster either, so if Simon is able to > consistently reproduce these then I'll have to ask him for a core dump so I > can take a look. > > Thanks again, > I appreciate the help! > > Regards, > Tamar > > On Mon, Dec 3, 2018 at 3:34 PM Roland Senn wrote: > > 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 in the do block of the function > '.../testuite/tests/plugins/simple-plugin/Simple/SourcePlugin.hs:parsedPlugin' > then all 3 tests pass successfully on Windows! > > I don't know anything about the "Why" and "Where" in the GHC IO module on > Windows, so I'm unable to come up with a patch. > > Regards > Roland > > PS: I can't say anything about the tests 'plugin-recomp-pure' and > 'plugin-recomp-impure' as these tests run successfully on my (slow) Windows > box. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Fri Dec 7 00:06:49 2018 From: lonetiger at gmail.com (Phyx) Date: Fri, 7 Dec 2018 00:06:49 +0000 Subject: Windows test failures In-Reply-To: References: Message-ID: forgot to copy in ghc-devs. On Fri, Dec 7, 2018 at 12:05 AM Phyx wrote: > Ah great, > > Normally an msys2 .profile will contain the following line > > # Set user-defined locale > export LANG=$(locale -uU) > > which would attach ".UTF-8" to the user's current locale. > I'm guessing when you run it from emacs the profile isn't loaded (probably > because bash isn't being called with --login) or something in bashrc or > profile is overwriting this. > > Setting this should bring the test failures down more. > > Which leaves only these tests > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad > exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-impure.run plugin-recomp-impure > [bad exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-flags.run plugin-recomp-flags [bad > exit code] (normal) > > as the remaining unexplained ones. > > Do these still fail for you? > > Cheers, > Tamar > > > On Thu, Dec 6, 2018 at 11:50 PM Simon Peyton Jones > wrote: > >> Aha! Yes, in libraries/base/tests, I find that make TEST=T3307 fails; >> but succeeds with >> >> >> >> export LANG=en_GB.UTF-8 >> >> >> >> Progress! >> >> >> >> Simon >> >> >> >> *From:* Phyx >> *Sent:* 06 December 2018 23:43 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org Devs >> *Subject:* Re: Windows test failures >> >> >> >> Hi Simon, >> >> >> >> > Does that help at all? >> >> > >> >> > I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test >> its efficacy by running one test rather than 6,000 of them? In which case, >> which one? >> >> >> >> Yes, "en_GB" doesn't seem to be a unicode locale, one test you can try to >> check is T3307,so make TEST="T3307" -C testsuite/tests/ >> >> >> >> I tried using your "en_GB" locale and the test failed for me too then. >> >> >> >> Kind regards, >> >> Tamar >> >> >> >> On Thu, Dec 6, 2018 at 2:17 PM Simon Peyton Jones >> wrote: >> >> Hi Tamar >> >> >> >> Thanks for working on this. >> >> >> >> if it's an msys2 shell, what does "locale" return? >> >> >> >> It’s a shell running inside emacs. Here’s what locale returns >> >> /c/tmp$ locale >> >> LANG=en_GB >> >> LC_CTYPE="en_GB" >> >> LC_NUMERIC="en_GB" >> >> LC_TIME="en_GB" >> >> LC_COLLATE="en_GB" >> >> LC_MONETARY="en_GB" >> >> LC_MESSAGES="en_GB" >> >> LC_ALL= >> >> >> >> Does that help at all? >> >> >> >> I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test >> 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 at 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 at already, seems to have >> something to do with the libstdc++ destructors. >> >> Plugins 09 and 10 are the other two I know about, but haven't had time to >> look at them yet. Frankly I know too little about plugins to make an >> accurate determination here, but the input files are empty >> >> yet it expects output, so I don't know what it's supposed to do here. If >> someone who knows more about plugins can chime in that would save some time. >> >> >> >> The segfaulting plugin I haven't triaged yet. Now the remaining failures >> aside from T14452 that Roland is taking care of, seem to have to do with >> your locale in your console. You seem to be running the >> >> tests in a console that has latin-1 locale? So some unicode characters >> fail encoding/decoding. >> >> >> >> If it's a Windows shell you can change it to utf-8 using "chcp 65001", if >> it's an msys2 shell, what does "locale" return? >> >> >> >> For reference mine is >> >> >> >> $ locale >> LANG=en_GB.UTF-8 >> LC_CTYPE="en_GB.UTF-8" >> LC_NUMERIC="en_GB.UTF-8" >> LC_TIME="en_GB.UTF-8" >> LC_COLLATE="en_GB.UTF-8" >> LC_MONETARY="en_GB.UTF-8" >> LC_MESSAGES="en_GB.UTF-8" >> LC_ALL= >> >> >> >> If it does say latin1 you can change it with >> >> >> >> export LANG=en_GB.UTF-8 >> >> >> >> This should fix more of the tests. >> >> >> >> The reason I don't mark the remaining tests as expect fail yet is because >> I haven't had the time to triage them, so I don't know their severity and >> >> last time there were a few nasty issues hidden in them. >> >> >> >> Unfortunately I won't have time to look at them till next weekend. >> >> >> >> Thanks, >> >> Tamar >> >> >> >> On Fri, Nov 30, 2018 at 9:49 PM Simon Peyton Jones >> wrote: >> >> At the end of the first test run it would have given a list of tests that >> failed and a line saying TEST=".... List of tests..." >> >> >> >> Copy that line and at the root of the checkout do >> >> >> >> make TEST=".... List of tests..." test -C testsuite/tests >> >> >> >> (that's uppercase C). This will run everything using one thread. :) >> >> >> >> OK, done. Results below. >> >> >> >> Simon >> >> >> >> >> >> /c/code/HEAD$ make TEST="T10420 T10672_x64 T13385 T14452 T15815 T3307 >> T3319 T4006 TH_scopedTvs environment001 plugin-recomp-change >> plugin-recomp-flags plugin-recomp-impure plugin-recomp-pure plugins07 >> plugins09 plugins10 plugins11 plugins13 plugins14 print017" test -C >> testsuite/tests >> >> make: Entering directory '/c/code/HEAD/testsuite/tests' >> >> PYTHON="python3" "python3" ../driver/runtests.py -e >> "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db >> -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups >> -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat >> -dno-debug-output'" -e config.compiler_debugged=False -e >> ghc_with_native_codegen=True -e config.have_vanilla=True -e >> config.have_dynamic=False -e config.have_profiling=False -e >> ghc_with_threaded_rts=True -e ghc_with_dynamic_rts=False -e >> config.have_interp=True -e config.unregisterised=False -e >> config.have_gdb=False -e config.have_readelf=True -e >> config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e >> ghc_with_smp=True -e ghc_with_llvm=False -e windows=True -e darwin=False -e >> config.in_tree_compiler=True -e config.cleanup=True -e config.local=True >> --rootdir=. --config-file=../config/ghc -e >> 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e >> 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() >> or config.timeout' -e 'config.exeext=".exe"' -e >> 'config.top="/c/code/HEAD/testsuite"' --config >> 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config >> 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' >> --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config >> 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config >> 'timeout_prog="../timeout/install-inplace/bin/timeout.exe"' -e >> "config.stage=2" --rootdir=../../libraries/Win32/tests >> --rootdir=../../libraries/array/tests >> --rootdir=../../libraries/base/tests >> --rootdir=../../libraries/binary/tests >> --rootdir=../../libraries/bytestring/tests >> --rootdir=../../libraries/containers/tests >> --rootdir=../../libraries/deepseq/tests >> --rootdir=../../libraries/directory/tests >> --rootdir=../../libraries/filepath/tests >> --rootdir=../../libraries/ghc-compact/tests >> --rootdir=../../libraries/ghc-heap/tests >> --rootdir=../../libraries/ghc-prim/tests >> --rootdir=../../libraries/haskeline/tests >> --rootdir=../../libraries/hpc/tests >> --rootdir=../../libraries/pretty/tests >> --rootdir=../../libraries/process/tests >> --rootdir=../../libraries/stm/tests >> --rootdir=../../libraries/template-haskell/tests >> --rootdir=../../libraries/text/tests \ >> >> --only=T10420 --only=T10672_x64 --only=T13385 --only=T14452 >> --only=T15815 --only=T3307 --only=T3319 --only=T4006 >> --only=TH_scopedTvs --only=environment001 --only=plugin-recomp-change >> --only=plugin-recomp-flags --only=plugin-recomp-impure >> --only=plugin-recomp-pure --only=plugins07 --only=plugins09 >> --only=plugins10 --only=plugins11 --only=plugins13 --only=plugins14 >> --only=print017 \ >> >> \ >> >> \ >> >> \ >> >> \ >> >> \ >> >> >> >> Timeout is 300 >> >> 0 >> >> Found 398 .T files... >> >> Beginning test run at Fri Nov 30 21:07:17 2018 GMTST >> >> ====> Scanning ./ado/all.T >> >> ====> Scanning ./annotations/should_compile/all.T >> >> ====> Scanning ./annotations/should_compile/T13818/all.T >> >> …lots more “Scanning” lines… >> >> ====> Scanning ../../libraries/ghc-heap/tests/all.T >> >> ====> Scanning ../../libraries/hpc/tests/fork/test.T--- >> driver/T14452.run/T14452.stdout.normalised 2018-11-30 >> 21:07:36.565566000 +0000 >> >> +++ driver/T14452.run/T14452.run.stdout.normalised 2018-11-30 >> 21:07:36.567569500 +0000 >> >> @@ -1 +1 @@ >> >> --O3 >> >> +"-O3" >> >> --- libraries/base/tests/T4006.run/T4006.stdout.normalised >> 2018-11-30 21:15:19.867313900 +0000 >> >> +++ libraries/base/tests/T4006.run/T4006.run.stdout.normalised >> 2018-11-30 21:15:19.870787900 +0000 >> >> @@ -1,2 +1,2 @@ >> >> It works here >> >> - >> >> + >> >> --- >> libraries/base/tests/IO/environment001.run/environment001.stdout.normalised >> 2018-11-30 21:16:00.645817500 +0000 >> >> +++ >> libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised >> 2018-11-30 21:16:00.654738900 +0000 >> >> @@ -1,7 +1,8 @@ >> >> - >> >> -Test 1: 3 >> >> - >> >> -Test 2: 1 >> >> + >> >> + >> >> +Test 1: 9 >> >> + >> >> +Test 2: 3 >> >> ! >> >> Test 3: 3 >> >> ["a","b"] >> >> >> >> ====> Scanning ../../libraries/hpc/tests/function/test.T >> >> ====> Scanning ../../libraries/hpc/tests/function2/test.T >> >> ====> Scanning ../../libraries/hpc/tests/ghc_ghci/test.T >> >> ====> Scanning ../../libraries/hpc/tests/raytrace/test.T >> >> ====> Scanning ../../libraries/hpc/tests/raytrace/tixs/test.T >> >> ====> Scanning ../../libraries/hpc/tests/simple/test.T >> >> ====> Scanning ../../libraries/hpc/tests/simple/tixs/test.T >> >> ====> Scanning ../../libraries/process/tests/all.T >> >> ====> Scanning ../../libraries/process/tests/T9775/all.T >> >> ====> Scanning ../../libraries/stm/tests/all.T >> >> ====> Scanning ../../libraries/template-haskell/tests/all.T >> >> =====> T14452(normal) 1 of 21 [0, 0, 0] >> >> cd "driver/T14452.run" && $MAKE -s --no-print-directory T14452 >> >> Actual stdout output differs from expected: >> >> diff -uw "driver/T14452.run/T14452.stdout.normalised" >> "driver/T14452.run/T14452.run.stdout.normalised" >> >> *** unexpected failure for T14452(normal) >> >> =====> T13385(ghci) 2 of 21 [0, 1, 0] >> >> cd "ghci/scripts/T13385.run" && >> HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint >> -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations >> -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret >> -Werror=compat -dno-debug-output -XRebindableSyntax" >> "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 >> -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check >> -dcore-lint -dcmm-lint -no-user-package-db -rtsopts >> -fno-warn-missed-specialisations -fshow-warning-groups >> -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat >> -dno-debug-output -XRebindableSyntax < T13385.script >> >> =====> print017(ghci) 3 of 21 [0, 1, 0] >> >> cd "ghci.debugger/scripts/print017.run" && >> HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint >> -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations >> -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret >> -Werror=compat -dno-debug-output " >> "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 >> -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check >> -dcore-lint -dcmm-lint -no-user-package-db -rtsopts >> -fno-warn-missed-specialisations -fshow-warning-groups >> -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat >> -dno-debug-output -ignore-dot-ghci< print017.script >> >> =====> print017(ghci-ext) 3 of 21 [0, 1, 0] >> >> cd "ghci.debugger/scripts/print017.run" && >> HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint >> -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations >> -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret >> -Werror=compat -dno-debug-output " >> "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 >> -ignore-dot-ghci -fno-ghci-history -fexternal-interpreter +RTS -I0.1 -RTS >> -dcore-lint -dcmm-lint -no-user-package-db -rtsopts >> -fno-warn-missed-specialisations -fshow-warning-groups >> -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat >> -dno-debug-output -ignore-dot-ghci< print017.script >> >> =====> plugin-recomp-change(normal) 4 of 21 [0, 1, 0] >> >> cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory -C >> plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite >> >> cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory >> plugin-recomp-change >> >> =====> T10672_x64(normal) 5 of 21 [0, 1, 0] >> >> cd "rts/T10672/T10672_x64.run" && $MAKE -s --no-print-directory >> T10672_x64 >> >> Timeout happened...killed process "cd "rts/T10672/T10672_x64.run" && >> $MAKE -s --no-print-directory T10672_x64 "... >> >> >> >> Wrong exit code for T10672_x64()(expected 0 , actual 99 ) >> >> *** unexpected failure for T10672_x64(normal) >> >> =====> TH_scopedTvs(normal) 6 of 21 [0, 2, 0] >> >> cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c >> TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts >> -fno-warn-missed-specialisations -fshow-warning-groups >> -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat >> -dno-debug-output -XTemplateHaskell -package template-haskell -v0 >> >> =====> TH_scopedTvs(ext-interp) 6 of 21 [0, 2, 0] >> >> cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c >> TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts >> -fno-warn-missed-specialisations -fshow-warning-groups >> -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat >> -dno-debug-output -XTemplateHaskell -package template-haskell >> -fexternal-interpreter -v0 >> >> =====> T3319(normal) 7 of 21 [0, 2, 0] >> >> cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c >> T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts >> -fno-warn-missed-specialisations -fshow-warning-groups >> -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat >> -dno-debug-output -XTemplateHaskell -package template-haskell >> -ddump-splices -v0 >> >> =====> T3319(ext-interp) 7 of 21 [0, 2, 0] >> >> cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c >> T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts >> -fno-warn-missed-specialisations -fshow-warning-groups >> -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat >> -dno-debug-output -XTemplateHaskell -package template-haskell >> -fexternal-interpreter -ddump-splices -v0 >> >> =====> T15815(normal) 8 of 21 [0, 2, 0] >> >> cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make >> T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts >> -fno-warn-missed-specialisations -fshow-warning-groups >> -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat >> -dno-debug-output -XTemplateHaskell -package template-haskell -v0 -static >> >> =====> T15815(ext-interp) 8 of 21 [0, 2, 0] >> >> cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make >> T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts >> -fno-warn-missed-specialisations -fshow-warning-groups >> -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat >> -dno-debug-output -XTemplateHaskell -package template-haskell >> -fexternal-interpreter -v0 -static >> >> =====> T4006(normal) 9 of 21 [0, 2, 0] >> >> cd "libraries/base/tests/T4006.run" && >> "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -o T4006 T4006.hs -dcore-lint >> -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations >> -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret >> -Werror=compat -dno-debug-output >> >> cd "libraries/base/tests/T4006.run" && ./T4006 >> >> Actual stdout output differs from expected: >> >> diff -uw "libraries/base/tests/T4006.run/T4006.stdout.normalised" >> "libraries/base/tests/T4006.run/T4006.run.stdout.normalised" >> >> *** unexpected failure for T4006(normal) >> >> =====> T3307(normal) 10 of 21 [0, 3, 0] >> >> cd "libraries/base/tests/IO/T3307.run" && $MAKE -s --no-print-directory >> T3307-test >> >> Wrong exit code for T3307()(expected 0 , actual 2 ) >> >> Stdout ( T3307 ): >> >> Test 1 >> >> [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] >> >> Ni hao >> >> Test 2 >> >> [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] >> >> Ni hao >> >> Test 3 >> >> [99,104,105,110,101,115,101,45,102,105,108,101,45,23567,35828] >> >> Stderr ( T3307 ): >> >> *** framework failure for T3307(normal) 'latin-1' codec can't encode >> characters in position 24-25: ordinal not in range(256) >> >> =====> environment001(normal) 11 of 21 [0, 3, 1] >> >> cd "libraries/base/tests/IO/environment001.run" && $MAKE -s >> --no-print-directory environment001-test >> >> Actual stdout output differs from expected: >> >> diff -uw >> "libraries/base/tests/IO/environment001.run/environment001.stdout.normalised" >> "libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised" >> >> *** unexpected failure for environment001(normal) >> >> =====> plugins07(normal) 12 of 21 [0, 4, 1] >> >> cd "plugins/plugins07.run" && $MAKE -s --no-print-directory -C >> rule-defining-plugin package.plugins07 TOP=/c/code/HEAD/testsuite >> >> cd "plugins/plugins07.run" && $MAKE -s --no-print-directory plugins07 >> >> =====> plugins09(normal) 13 of 21 [0, 4, 1] >> >> cd "plugins/plugins09.run" && $MAKE -s --no-print-directory -C >> simple-plugin package.plugins09 TOP=/c/code/HEAD/testsuite >> >> cd "plugins/plugins09.run" && $MAKE -s --no-print-directory plugins09 >> >> Actual stdout output differs from expected: >> >> diff -uw "plugins/plugins09.run/plugins09.stdout.normalised" >> "plugins/plugins09.run/plugins09.run.stdout.normalised"--- >> plugins/plugins09.run/plugins09.stdout.normalised 2018-11-30 >> 21:17:20.709370700 +0000 >> >> +++ plugins/plugins09.run/plugins09.run.stdout.normalised >> 2018-11-30 21:17:20.711314000 +0000 >> >> @@ -1,9 +0,0 @@ >> >> -parsePlugin(a,b) >> >> -interfacePlugin: Prelude >> >> -interfacePlugin: GHC.Float >> >> -interfacePlugin: GHC.Base >> >> -typeCheckPlugin (rn) >> >> -interfacePlugin: GHC.Types >> >> -typeCheckPlugin (tc) >> >> -interfacePlugin: GHC.Integer.Type >> >> -interfacePlugin: GHC.Natural >> >> --- plugins/plugins10.run/plugins10.stdout.normalised 2018-11-30 >> 21:17:57.644357800 +0000 >> >> +++ plugins/plugins10.run/plugins10.run.stdout.normalised >> 2018-11-30 21:17:57.646078700 +0000 >> >> @@ -1,21 +0,0 @@ >> >> -parsePlugin() >> >> -interfacePlugin: Prelude >> >> -interfacePlugin: Language.Haskell.TH >> >> >> -interfacePlugin: Language.Haskell.TH.Quote >> >> -interfacePlugin: GHC.Float >> >> -interfacePlugin: GHC.Base >> >> -interfacePlugin: Language.Haskell.TH.Syntax >> >> -typeCheckPlugin (rn) >> >> -interfacePlugin: GHC.Types >> >> -typeCheckPlugin (tc) >> >> -interfacePlugin: GHC.Integer.Type >> >> -interfacePlugin: GHC.Natural >> >> -parsePlugin(a) >> >> -typeCheckPlugin (rn) >> >> -interfacePlugin: Language.Haskell.TH.Lib.Internal >> >> -metaPlugin: return [] >> >> -metaPlugin: quoteExp stringify "x" >> >> -interfacePlugin: GHC.CString >> >> -typeCheckPlugin (rn) >> >> -typeCheckPlugin (rn) >> >> -typeCheckPlugin (tc) >> >> >> >> *** unexpected failure for plugins09(normal) >> >> =====> plugins10(normal) 14 of 21 [0, 5, 1] >> >> cd "plugins/plugins10.run" && $MAKE -s --no-print-directory -C >> simple-plugin package.plugins10 TOP=/c/code/HEAD/testsuite >> >> cd "plugins/plugins10.run" && $MAKE -s --no-print-directory plugins10 >> >> Actual stdout output differs from expected: >> >> diff -uw "plugins/plugins10.run/plugins10.stdout.normalised" >> "plugins/plugins10.run/plugins10.run.stdout.normalised" >> >> *** unexpected failure for plugins10(normal) >> >> =====> plugins11(normal) 15 of 21 [0, 6, 1] >> >> cd "plugins/plugins11.run" && $MAKE -s --no-print-directory -C >> simple-plugin package.plugins11 TOP=/c/code/HEAD/testsuite >> >> cd "plugins/plugins11.run" && $MAKE -s --no-print-directory plugins11 >> >> Timeout happened...killed process "cd "plugins/plugins11.run" && $MAKE -s >> --no-print-directory plugins11 "... >> >> >> >> Wrong exit code for plugins11()(expected 0 , actual 99 ) >> >> *** unexpected failure for plugins11(normal) >> >> =====> plugins13(normal) 16 of 21 [0, 7, 1] >> >> cd "plugins/plugins13.run" && $MAKE -s --no-print-directory -C >> simple-plugin package.plugins13 TOP=/c/code/HEAD/testsuite >> >> cd "plugins/plugins13.run" && $MAKE -s --no-print-directory plugins13 >> >> =====> plugins14(normal) 17 of 21 [0, 7, 1] >> >> cd "plugins/plugins14.run" && $MAKE -s --no-print-directory -C >> simple-plugin package.plugins14 TOP=/c/code/HEAD/testsuite >> >> cd "plugins/plugins14.run" && $MAKE -s --no-print-directory plugins14 >> >> =====> T10420(normal) 18 of 21 [0, 7, 1] >> >> cd "plugins/T10420.run" && $MAKE -s --no-print-directory -C >> rule-defining-plugin package.T10420 TOP=/c/code/HEAD/testsuite >> >> cd "plugins/T10420.run" && $MAKE -s --no-print-directory T10420 >> >> =====> plugin-recomp-pure(normal) 19 of 21 [0, 7, 1] >> >> cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory -C >> plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite >> >> cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory >> plugin-recomp-pure >> >> Timeout happened...killed process "cd "plugins/plugin-recomp-pure.run" && >> $MAKE -s --no-print-directory plugin-recomp-pure "... >> >> >> >> Wrong exit code for plugin-recomp-pure()(expected 0 , actual 99 ) >> >> Stdout ( plugin-recomp-pure ): >> >> [1 of 1] Compiling Main ( plugin-recomp-test.hs, >> plugin-recomp-test.o ) >> >> Stderr ( plugin-recomp-pure ): >> >> Simple Plugin Passes Queried >> >> Got options: >> >> Simple Plugin Pass Run >> >> *** unexpected failure for plugin-recomp-pure(normal) >> >> =====> plugin-recomp-impure(normal) 20 of 21 [0, 8, 1] >> >> cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory -C >> plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite >> >> cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory >> plugin-recomp-impure >> >> Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) >> >> Stdout ( plugin-recomp-impure ): >> >> [1 of 1] Compiling Main ( plugin-recomp-test.hs, >> plugin-recomp-test.o ) >> >> Linking plugin-recomp-test.exe ... >> >> [1 of 1] Compiling Main ( plugin-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 reading 0xa824 >> >> >> >> Attempting to reconstruct a stack trace... >> >> >> >> Frame Code address >> >> * 0x49adab0 0x1eb49ec 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" && $MAKE -s --no-print-directory -C >> plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite >> >> cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory >> plugin-recomp-flags >> >> Traceback (most recent call last): >> >> File "/c/code/HEAD/testsuite/driver/testlib.py", line 824, in >> test_common_work >> >> do_test(name, way, func, args, files) >> >> File "/c/code/HEAD/testsuite/driver/testlib.py", line 910, in do_test >> >> result = func(*[name,way] + args) >> >> File "/c/code/HEAD/testsuite/driver/testlib.py", line 993, in >> run_command >> >> return simple_run( name, '', override_options(cmd), '' ) >> >> File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in >> simple_run >> >> dump_stderr(name) >> >> File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in >> dump_stderr >> >> print(str) >> >> UnicodeEncodeError: 'latin-1' codec can't encode characters in position >> 24-25: ordinal not in range(256) >> >> >> >> Unexpected 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 cases, of which >> >> 11 were skipped >> >> >> >> 0 had missing libraries >> >> 15 expected passes >> >> 0 expected failures >> >> >> >> 1 caused framework failures >> >> 0 caused framework warnings >> >> 0 unexpected passes >> >> 9 unexpected failures >> >> 0 unexpected stat failures >> >> >> >> Unexpected failures: >> >> driver/T14452.run T14452 [bad stdout] >> (normal) >> >> rts/T10672/T10672_x64.run T10672_x64 [bad exit code] >> (normal) >> >> libraries/base/tests/T4006.run T4006 [bad stdout] (normal) >> >> libraries/base/tests/IO/environment001.run environment001 [bad >> stdout] (normal) >> >> plugins/plugins09.run plugins09 [bad stdout] >> (normal) >> >> plugins/plugins10.run plugins10 [bad stdout] >> (normal) >> >> plugins/plugins11.run plugins11 [bad exit code] >> (normal) >> >> plugins/plugin-recomp-pure.run plugin-recomp-pure [bad >> exit code] (normal) >> >> plugins/plugin-recomp-impure.run plugin-recomp-impure [bad >> exit code] (normal) >> >> >> >> Framework failures: >> >> libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec >> can't encode characters in position 24-25: ordinal not in range(256)) >> >> >> >> Appending 0 stats to git notes. >> >> make: *** [../mk/test.mk:342 >> : >> test] Error 1 >> >> make: Leaving directory '/c/code/HEAD/testsuite/tests' >> >> /c/code/HEAD$ >> >> >> >> >> >> *From:* Phyx >> *Sent:* 30 November 2018 11:58 >> *To:* Simon Peyton Jones >> *Subject:* Re: Windows test failures >> >> >> >> At the end of the first test run it would have given a list of tests that >> failed and a line saying TEST=".... List of tests..." >> >> >> >> Copy that line and at the root of the checkout do >> >> >> >> make TEST=".... List of tests..." test -C testsuite/tests >> >> >> >> (that's uppercase C). This will run everything using one thread. :) >> >> >> >> Should give a good starting point as to what's wrong. >> >> >> >> Kind regards, >> >> Tamar >> >> On Fri, Nov 30, 2018, 10:30 Simon Peyton Jones >> wrote: >> >> So I just say >> >> make TEST >> >> is that right? >> >> >> >> Or is it >> >> make THREADS=1 >> >> >> >> or what? Sorry to be dim >> >> >> >> *From:* Phyx >> *Sent:* 30 November 2018 08:05 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs >> *Subject:* Re: Windows test failures >> >> >> >> 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 increasingly >> unstable under threads for some reason. >> >> >> >> I also haven't run trunk yet since last week so they could be new.. >> >> >> >> But rerunning the fails with no threads should give a better idea. >> >> >> >> Regards, >> >> Tamar >> >> On Fri, Nov 30, 2018, 07:46 Simon Peyton Jones via ghc-devs < >> ghc-devs at haskell.org> wrote: >> >> Ben, Phyx, and other CI folk >> >> ‘sh validate –fast’ still gives a lot of failures on Window. The output >> is below. I would be so good to get this to zero! >> >> (another minor thing is that it would be great to eliminate the long path >> at the beginning – this is platform independent – I have to delete manually >> many times each day. >> >> Thanks >> >> Simon >> >> Unexpected passes: >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/rts/T9405.run T9405 [unexpected] (normal) >> >> >> >> Unexpected failures: >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/driver/T14452.run T14452 [bad stdout] >> (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/ghci/linking/ghcilink001.run ghcilink001 [bad exit >> code] (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit >> code] (ghci) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/ghci/scripts/ghci050.run ghci050 [bad exit code] >> (ghci) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/ghci/should_run/T14963a.run T14963a [bad exit code] >> (ghci) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] >> (ghci) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] >> (ghci) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] >> (ghci) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] >> (ghci) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit >> code] (ghci) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] >> (ghci) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/indexed-types/should_fail/T7102a.run T7102a [bad exit code] >> (ghci) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/plugins/plugin-recomp-change.run plugin-recomp-change >> [bad exit code] (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit >> code] (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/th/TH_spliceGuard.run TH_spliceGuard [exit >> code non-0] (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/th/TH_overlaps.run TH_overlaps [exit code >> non-0] (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/th/T5886.run T5886 [exit code non-0] >> (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/th/T10697_decided_3.run T10697_decided_3 [exit >> code non-0] (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/th/T11629.run T11629 [exit code non-0] >> (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/libraries/base/tests/T4006.run T4006 [bad stdout] >> (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/libraries/base/tests/IO/environment001.run environment001 [bad >> stdout] (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/ghci/should_run/T15633b.run T15633b [bad exit code] >> (ghci) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/plugins/plugins07.run plugins07 [bad exit >> code] (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/plugins/plugins09.run plugins09 [bad stdout] >> (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/plugins/plugins10.run plugins10 [bad stdout] >> (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/plugins/plugins11.run plugins11 [bad stdout] >> (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/plugins/T10420.run T10420 [bad exit code] >> (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad >> exit code] (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/plugins/plugin-recomp-impure.run plugin-recomp-impure >> [bad exit code] (normal) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/plugins/plugin-recomp-flags.run plugin-recomp-flags [bad >> exit code] (normal) >> >> >> >> Framework failures: >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/perf/compiler/MultiLayerModules.run MultiLayerModules [runTest] >> (Unhandled exception during cleanup: Unable to remove folder >> '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/perf/compiler/MultiLayerModules.run': [Errno 13] Permission denied: >> '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/perf/compiler/MultiLayerModules.run' >> >> Unable to start current test.) >> >> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test >> spaces/libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec >> can't encode characters in position 24-25: ordinal not in range(256)) >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Dec 7 02:06:54 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 6 Dec 2018 21:06:54 -0500 Subject: Cmm Memory Model (Understanding #15449) In-Reply-To: <87bm68ymb7.fsf@smart-cactus.org> References: <87bm68ymb7.fsf@smart-cactus.org> Message-ID: Awesome summary by Ben! theres also some crazy hijinks needed currently to do compare and swap style stuff see https://hackage.haskell.org/package/atomic-primops-0.8.2/docs/Data-Atomics.html for some discussion. (i'm not sure what the current state of the world is on CAS tech) On Thu, Nov 29, 2018 at 9:45 AM Ben Gamari wrote: > Travis Whitaker writes: > > > Hello GHC Devs, > > > > I'm trying to get my head around ticket #15449 ( > > https://ghc.haskell.org/trac/ghc/ticket/15449). This gist of things is > that > > GHC generates incorrect aarch64 code that causes memory corruption in > > multithreaded programs run on out-of-order machines. User trommler > > discovered that similar issues are present on PowerPC, and indeed ARMv7 > and > > PowerPC support the same types of load/store reorderings. The LLVM code > > emitted by GHC may be incorrect with respect to LLVM's memory model, but > > this isn't a problem on architectures with minimal reordering like x86. > > > Thank you for picking this up! > > > I had initially thought that GHC simply wasn't emitting the appropriate > > LLVM fences; there's an elephant-gun-approach here ( > > https://github.com/TravisWhitaker/ghc/commits/ghc843-wip/T15449) that > > guards each atomic operation with a full barrier. I still believe that > GHC > > is omitting necessary LLVM fences, but this change is insufficient to fix > > the behavior of the test case (which is simply GHC itself compiling a > test > > package with '-jN', N > 1). > > > > It seems there's a long and foggy history of the Cmm memory model. Edward > > Yang discusses this a bit in his post here ( > > > http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/ > ) > > and issues similar to #15449 have plagued GHC in the past, like #12469 ( > > https://ghc.haskell.org/trac/ghc/ticket/12469). Worryingly, GHC only has > > MO_WriteBarrier, whereas PowerPC and ARMv7 really need read, write, and > > full memory barriers. On ARM an instruction memory barrier might be > > required as well, but I don't know enough about STG/Cmm to say for sure, > > and it'd likely be LLVM's responsibility to emit that anyway. > > > In my opinion GHC's current memory model story is quite unsustainable. As > you point out, we currently have a limited selection of plain barriers > and a few atomic operations, none of which are adequately documented > given the subtlety they involve. > > I think we would at this point be foolish not to take advantage of the > research that has been done in this area by moving to C11-style > acquire/release semantics wherever possible. While following through on > this is not a small task, these semantics are both well defined and > easier to reason about intuitively. We might also be able to benefit > from the wealth of model checking tools that are now available for this > formalism. > > Ulan Degenbaev (CC'd) and I discussed him possibly picking up the task > of moving to C11 atomics a few weeks ago. > > > I'm hoping that someone with more tribal knowledge than I might be able > to > > give me some pointers with regards to the following areas: > > > > > > - Does STG itself have anything like a memory model? My intuition says > > 'definitely not', but given that STG expressions may contain Cmm > operations > > (via StgCmmPrim), there may be STG-to-STG transformations that need > to care > > about the target machine's memory model. > > As far as I know, it has nothing formally, or even informally, defined. > That being said, relatively few of our primops make any guarantees about > their operation in a concurrent setting. The cases that I can think of > include `casArray#`, `atomicModifyIORef#`, `atomic{Read,Write}*Array#` > and the STM operations. > > > - With respect to Cmm, what reorderings does GHC perform? What are the > > relevant parts of the compiler to begin studying? > > As far as I know, very few. We only perform a handful of optimizations > on C--. These include, > > * Sinking of assignments (see compiler/cmm/CmmSink.hs); see > CmmSink.conflicts for what commutation we allow. We notably don't > allow sinking of any memory assignments past calls (including > primops) > > * Simple constant folding (see CmmOpt.cmmMachOpFoldM) > > * Common block elimination (see CmmCommonBlockElim) > > * Some simple control-flow optimisation (see CmmContFlowOpt) > > > - Are the LLVM atomics that GHC emits correct with respect to the LLVM > > memory model? As it stands now LLVM fences are only emitted for > > MO_WriteBarrier. Without fences accompanying the atomics, it seems > the LLVM > > compiler could float dependent loads/stores past atomic operations. > > Frankly, I would be surprised if they are correct. Few people have > really looked at GHC's memory ordering properties and even fewer have > looked at those of the LLVM backend. > > > - Why is MO_WriteBarrier the only provided memory barrier? My hunch is > > that it's because this is the only sort of barrier required on x86, > which > > only allows loads to be reordered with older stores, but perhaps I'm > > missing something? Is it plausible that Cmm simply needs additional > barrier > > primitives to target these weaker memory models? Conversely, is there > some > > property of Cmm that let's us get away without read barriers at all? > > > Note that there are a few others defined in SMP.h (namely > store_load_barrier and load_load_barrier). However, see the discussion > above. My understanding is that there were just very few formalisms for > reasoning about weak memory models when this code was written. The > literature now contains a much better understanding of this field but > GHC has yet to catch up. > > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Fri Dec 7 08:25:53 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 7 Dec 2018 08:25:53 +0000 Subject: Cmm Memory Model (Understanding #15449) In-Reply-To: References: Message-ID: FWIW, my main reference at the time when this stuff was implemented was this page by Doug Lea: http://gee.cs.oswego.edu/dl/jmm/cookbook.html As Ben says, things have evolved a lot since then. I'm not an expert at all, but I know from experience that getting this stuff right is really hard. Even on x86 we had a tough time figuring out where to put this barrier: https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2FWSDeque.c$135-137 My understanding of the current memory model is this: - we give no guarantees about ordering between non-atomic IORef operations, except that: doing things in parallel shouldn't segfault". So if a processor can see a pointer in an IORef, it can safely follow the pointer and find the memory it points to correctly initialized. This may require barriers on some architectures, but not x86(_64) as I understand it. - MVar operations and atomicModifyIORef are full barriers. Or something. Cheers Simon On Thu, 29 Nov 2018 at 04:44, Travis Whitaker wrote: > Hello GHC Devs, > > I'm trying to get my head around ticket #15449 ( > https://ghc.haskell.org/trac/ghc/ticket/15449). This gist of things is > that GHC generates incorrect aarch64 code that causes memory corruption in > multithreaded programs run on out-of-order machines. User trommler > discovered that similar issues are present on PowerPC, and indeed ARMv7 and > PowerPC support the same types of load/store reorderings. The LLVM code > emitted by GHC may be incorrect with respect to LLVM's memory model, but > this isn't a problem on architectures with minimal reordering like x86. > > I had initially thought that GHC simply wasn't emitting the appropriate > LLVM fences; there's an elephant-gun-approach here ( > https://github.com/TravisWhitaker/ghc/commits/ghc843-wip/T15449) that > guards each atomic operation with a full barrier. I still believe that GHC > is omitting necessary LLVM fences, but this change is insufficient to fix > the behavior of the test case (which is simply GHC itself compiling a test > package with '-jN', N > 1). > > It seems there's a long and foggy history of the Cmm memory model. Edward > Yang discusses this a bit in his post here ( > http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/) > and issues similar to #15449 have plagued GHC in the past, like #12469 ( > https://ghc.haskell.org/trac/ghc/ticket/12469). Worryingly, GHC only has > MO_WriteBarrier, whereas PowerPC and ARMv7 really need read, write, and > full memory barriers. On ARM an instruction memory barrier might be > required as well, but I don't know enough about STG/Cmm to say for sure, > and it'd likely be LLVM's responsibility to emit that anyway. > > I'm hoping that someone with more tribal knowledge than I might be able to > give me some pointers with regards to the following areas: > > > - Does STG itself have anything like a memory model? My intuition says > 'definitely not', but given that STG expressions may contain Cmm operations > (via StgCmmPrim), there may be STG-to-STG transformations that need to care > about the target machine's memory model. > - With respect to Cmm, what reorderings does GHC perform? What are the > relevant parts of the compiler to begin studying? > - Are the LLVM atomics that GHC emits correct with respect to the LLVM > memory model? As it stands now LLVM fences are only emitted for > MO_WriteBarrier. Without fences accompanying the atomics, it seems the LLVM > compiler could float dependent loads/stores past atomic operations. > - Why is MO_WriteBarrier the only provided memory barrier? My hunch is > that it's because this is the only sort of barrier required on x86, which > only allows loads to be reordered with older stores, but perhaps I'm > missing something? Is it plausible that Cmm simply needs additional barrier > primitives to target these weaker memory models? Conversely, is there some > property of Cmm that let's us get away without read barriers at all? > > > Naturally, if I've got any of this wrong or are otherwise barking up the > wrong tree, please let me know. > > Thanks for all your efforts! > > Travis Whitaker > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Dec 7 14:58:23 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 7 Dec 2018 14:58:23 +0000 Subject: framework failure Message-ID: I'm getting this Framework failures: . ./perf/should_run/all.T [] (name 'stats_num_field' is not defined) I think it comes from this: commit fb669f51b3f2cae79511ac3d1c43939d951b1f69 Author: Tobias Decking Date: Thu Dec 6 15:32:18 2018 -0500 Add fusion rules for the zipWith functions in base (#15263) Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Dec 7 15:11:11 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 07 Dec 2018 10:11:11 -0500 Subject: framework failure In-Reply-To: References: Message-ID: <87r2etv0c4.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > I'm getting this > > Framework failures: > > . ./perf/should_run/all.T [] (name 'stats_num_field' is not defined) > I think it comes from this: > > commit fb669f51b3f2cae79511ac3d1c43939d951b1f69 > > Author: Tobias Decking > > Date: Thu Dec 6 15:32:18 2018 -0500 > > Add fusion rules for the zipWith functions in base (#15263) > Yes, it looks like that is the culprit. Looking back at the validation log from when merged this patch, it appears that I observed this too but simply overlooked it. Sorry about that! Fix coming. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From haskelier.artem at gmail.com Fri Dec 7 16:11:14 2018 From: haskelier.artem at gmail.com (Artem Pelenitsyn) Date: Fri, 7 Dec 2018 11:11:14 -0500 Subject: References for GHC usage of multiple capabilities In-Reply-To: <87k1kmwtck.fsf@smart-cactus.org> References: <87k1kmwtck.fsf@smart-cactus.org> Message-ID: Thanks for heads up, Ben! This is useful stuff to take into account. I also wonder how is this list (mine ++ yours) is relevant to what GHC actually has these days. But maybe that's harder to answer quickly. -- Best wishes, Artem On Thu, Dec 6, 2018 at 10:47 AM Ben Gamari wrote: > Artem Pelenitsyn writes: > > > Hello devs, > > > > I've been working on a short survey devoted to a topic of multithreading > > inside the GHC compiler and runtime. So far I was mostly looking at the > > following three papers > > > > [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, and > S. > > L. Peyton Jones. Gum: A portable parallel implementation of Haskell. > PLDI > > ’96 > > > > [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a > > shared-memory multiprocessor. Haskell ’05 > > > > [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime support > for > > multicore Haskell. ICFP ’09 > > > > Can you suggest any other papers adding insights on how GHC uses multiple > > capabilities for anything from GC to the implementation of > > Parallel/Concurrent Haskell? Perhaps, something more recent than the > above, > > but preferably published in academic venues. > > > Here are a few others but I may have missed a few: > > * Parallel Generational-Copying Garbage Collection with a > Block-Structured Heap (Simon Marlow, Tim Harris, Roshan P. James, Simon > Peyton Jones) In ISMM '08: Proceedings of the 7th international symposium > on Memory management, Tucson, Arizona, ACM, June 2008 > * Concurrent Haskell, Simon Peyton Jones, Andrew Gordon, Sigbjorn Finne. > * Composable Memory Transactions, Tim Harris, Simon Marlow, Simon > Peyton-Jones, and Maurice Herlihy. In Proceedings of the tenth ACM SIGPLAN > symposium on Principles and practice of parallel programming (PPoPP '05) > * Transactional Memory with Data Invariants, Tim Harris and Simon Peyton > Jones. In TRANSACT '06 > > Cheers, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Fri Dec 7 17:00:28 2018 From: amindfv at gmail.com (Tom Murphy) Date: Fri, 7 Dec 2018 17:00:28 +0000 Subject: References for GHC usage of multiple capabilities In-Reply-To: References: <87k1kmwtck.fsf@smart-cactus.org> Message-ID: There's also "Mio: A High-Performance Multicore IO Manager for GHC" http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf On 12/7/18, Artem Pelenitsyn wrote: > Thanks for heads up, Ben! This is useful stuff to take into account. I also > wonder how is this list (mine ++ yours) is relevant to what GHC actually > has these days. But maybe that's harder to answer quickly. > > -- > Best wishes, > Artem > > > > > On Thu, Dec 6, 2018 at 10:47 AM Ben Gamari wrote: > >> Artem Pelenitsyn writes: >> >> > Hello devs, >> > >> > I've been working on a short survey devoted to a topic of >> > multithreading >> > inside the GHC compiler and runtime. So far I was mostly looking at the >> > following three papers >> > >> > [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, and >> S. >> > L. Peyton Jones. Gum: A portable parallel implementation of Haskell. >> PLDI >> > ’96 >> > >> > [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a >> > shared-memory multiprocessor. Haskell ’05 >> > >> > [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime support >> for >> > multicore Haskell. ICFP ’09 >> > >> > Can you suggest any other papers adding insights on how GHC uses >> > multiple >> > capabilities for anything from GC to the implementation of >> > Parallel/Concurrent Haskell? Perhaps, something more recent than the >> above, >> > but preferably published in academic venues. >> > >> Here are a few others but I may have missed a few: >> >> * Parallel Generational-Copying Garbage Collection with a >> Block-Structured Heap (Simon Marlow, Tim Harris, Roshan P. James, Simon >> Peyton Jones) In ISMM '08: Proceedings of the 7th international symposium >> on Memory management, Tucson, Arizona, ACM, June 2008 >> * Concurrent Haskell, Simon Peyton Jones, Andrew Gordon, Sigbjorn Finne. >> * Composable Memory Transactions, Tim Harris, Simon Marlow, Simon >> Peyton-Jones, and Maurice Herlihy. In Proceedings of the tenth ACM >> SIGPLAN >> symposium on Principles and practice of parallel programming (PPoPP '05) >> * Transactional Memory with Data Invariants, Tim Harris and Simon Peyton >> Jones. In TRANSACT '06 >> >> Cheers, >> >> - Ben >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > From a.pelenitsyn at gmail.com Fri Dec 7 18:23:59 2018 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Fri, 7 Dec 2018 13:23:59 -0500 Subject: References for GHC usage of multiple capabilities In-Reply-To: References: <87k1kmwtck.fsf@smart-cactus.org> Message-ID: Thanks, Tom! I didn't realize that this one was merged into GHC. I wonder if the work presented on Haskell Symposium this year about a libuv-based I/O manager (https://dl.acm.org/citation.cfm?id=3242759) will go somewhere… -- Best, Artem On Fri, 7 Dec 2018 at 12:00 Tom Murphy wrote: > There's also "Mio: A High-Performance Multicore IO Manager for GHC" > > http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf > > On 12/7/18, Artem Pelenitsyn wrote: > > Thanks for heads up, Ben! This is useful stuff to take into account. I > also > > wonder how is this list (mine ++ yours) is relevant to what GHC actually > > has these days. But maybe that's harder to answer quickly. > > > > -- > > Best wishes, > > Artem > > > > > > > > > > On Thu, Dec 6, 2018 at 10:47 AM Ben Gamari wrote: > > > >> Artem Pelenitsyn writes: > >> > >> > Hello devs, > >> > > >> > I've been working on a short survey devoted to a topic of > >> > multithreading > >> > inside the GHC compiler and runtime. So far I was mostly looking at > the > >> > following three papers > >> > > >> > [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, > and > >> S. > >> > L. Peyton Jones. Gum: A portable parallel implementation of Haskell. > >> PLDI > >> > ’96 > >> > > >> > [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a > >> > shared-memory multiprocessor. Haskell ’05 > >> > > >> > [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime > support > >> for > >> > multicore Haskell. ICFP ’09 > >> > > >> > Can you suggest any other papers adding insights on how GHC uses > >> > multiple > >> > capabilities for anything from GC to the implementation of > >> > Parallel/Concurrent Haskell? Perhaps, something more recent than the > >> above, > >> > but preferably published in academic venues. > >> > > >> Here are a few others but I may have missed a few: > >> > >> * Parallel Generational-Copying Garbage Collection with a > >> Block-Structured Heap (Simon Marlow, Tim Harris, Roshan P. James, Simon > >> Peyton Jones) In ISMM '08: Proceedings of the 7th international > symposium > >> on Memory management, Tucson, Arizona, ACM, June 2008 > >> * Concurrent Haskell, Simon Peyton Jones, Andrew Gordon, Sigbjorn > Finne. > >> * Composable Memory Transactions, Tim Harris, Simon Marlow, Simon > >> Peyton-Jones, and Maurice Herlihy. In Proceedings of the tenth ACM > >> SIGPLAN > >> symposium on Principles and practice of parallel programming (PPoPP '05) > >> * Transactional Memory with Data Invariants, Tim Harris and Simon > Peyton > >> Jones. In TRANSACT '06 > >> > >> Cheers, > >> > >> - Ben > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Dec 7 22:49:10 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 07 Dec 2018 23:49:10 +0100 Subject: nofib output difference In-Reply-To: <0c4a719c6a4c0a547a643f12339e6111d13604c0.camel@joachim-breitner.de> References: <08dbfd27b35817f86200b5c5565df372801b8703.camel@joachim-breitner.de> <874lbzzzla.fsf@smart-cactus.org> <0c4a719c6a4c0a547a643f12339e6111d13604c0.camel@joachim-breitner.de> Message-ID: <0f95cbed95a3411cd4648178ecacac7903ffe7bb.camel@joachim-breitner.de> Hi, now it fail building nofib with a different error: ==nofib== compress: time to compile Uncompress follows... /home/nomeata/logs/ghc-tmp-REV/inplace/bin/ghc-stage2 -O2 -Wno-tabs -Rghc-timing -H32m -hisuf hi -rtsopts -c Uncompress.hs -o Uncompress.o Decode.hs:25:1: error: Main.hs:16:1: error: Encode.hs:9:1: error:Uncompress.hs:15:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 25 | import Defaults | ^^^^^^^^^^^^^^^ Decode.hs:26:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 16 | import Defaults | ^^^^^^^^^^^^^^^ Main.hs:17:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 9 | import Defaults | ^^^^^^^^^^^^^^^ Encode.hs:10:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 15 | import Defaults | ^^^^^^^^^^^^^^^ Uncompress.hs:16:1: error: Could not find module ‘BinConv’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 26 | import BinConv | ^^^^^^^^^^^^^^ Could not find module ‘BinConv’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 17 | import BinConv -- binary conversion routines | ^^^^^^^^^^^^^^ Main.hs:18:1: error: Could not find module ‘PTTrees’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 10 | import PTTrees | ^^^^^^^^^^^^^^ Could not find module ‘BinConv’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 16 | import BinConv -- binary conversion routines | ^^^^^^^^^^^^^^ Uncompress.hs:17:1: error: Could not find module ‘Encode’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 18 | import Encode -- coding routine | ^^^^^^^^^^^^^ Could not find module ‘Decode’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 17 | import Decode -- decoding routines | ^^^^^^^^^^^^^ -- Joachim “nomeata” Breitner mail at joachim-breitner.de https://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Sat Dec 8 01:43:37 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 07 Dec 2018 20:43:37 -0500 Subject: [ANNOUNCE] GHC 8.6.3 is now available Message-ID: <878t10vlmk.fsf@smart-cactus.org> Hello everyone, The GHC team is very happy to announce the availability of GHC 8.6.3, a bugfix release in the GHC 8.6 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.6.3 The 8.6 release fixes several regressions present in 8.6.2 including: - A code generation bug resulting in segmentations faults in some programs (#15892) - Darwin binary distributions are now correctly built against an in-tree GMP (#15404) - Three bugs leading to linker failures on Windows (#15105, #15894, #15934) - A bug leading to programs with deep stacks crashing when run with retainer profiling enabled (#14758) - A bug resulting in potential heap corruption during stable name allocation (#15906) - Plugins are now loaded during GHCi sessions (#15633) As a few of these issues are rather serious users are strongly encouraged to upgrade. See Trac [1] for a full list of issues resolved in this release. Note that this release ships with one significant but long-standing bug (#14251): Calls to functions taking both Float# and Double# may result in incorrect code generation when compiled using the LLVM code generator. This is not a new issue, it has existed as long as the LLVM code generator has existed; however, changes in code generation in 8.6 made it more likely that user code using only lifted types will trigger it. Happy compiling! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.3&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 483 bytes Desc: not available URL: From yotam2206 at gmail.com Sat Dec 8 11:29:42 2018 From: yotam2206 at gmail.com (Yotam Ohad) Date: Sat, 8 Dec 2018 13:29:42 +0200 Subject: Understanding bind in template haskell Message-ID: Hi, In the function DsMeta.repE there is a format being repeated: For example in: repE e@(ExplicitTuple _ es boxed) | not (all tupArgPresent es) = notHandled "Tuple sections" (ppr e) | isBoxed boxed = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es] ; repTup xs } | otherwise = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es] ; repUnboxedTup xs } There is `(dL->L _ (Present _ e)) <- es`. I don't understand how this type checks correctly. If I'll try to do data Foo a = Foo a runQ [| Foo b <- Foo 1 |] in ghciI get an error. What is the difference? Yotam -------------- next part -------------- An HTML attachment was scrubbed... URL: From klebinger.andreas at gmx.at Sat Dec 8 14:44:41 2018 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Sat, 08 Dec 2018 15:44:41 +0100 Subject: nofib output difference Message-ID: <5C0BD8D9.9030103@gmx.at> I fear that one is my fault. This should fix it: https://phabricator.haskell.org/D5426 I did not want to add a large binary file to the repo so instead compress generated the out file during boot. Which used to work well on my box. However make boot also creates the dependency files that guarantee the proper build order. Turns out sometimes we end up trying to build the compress executable before building the dependency file, so the build fails. I've just gave in to storing the output file in the repo now. From sgraf1337 at gmail.com Sun Dec 9 10:11:51 2018 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Sun, 9 Dec 2018 11:11:51 +0100 Subject: Residency profiles In-Reply-To: References: Message-ID: Ah, I was only looking at `+RTS --help`, not the users guide. Silly me. Am Do., 6. Dez. 2018 um 20:53 Uhr schrieb Simon Marlow : > It is documented! > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_control.html#rts-flag--F%20%E2%9F%A8factor%E2%9F%A9 > > On Thu, 6 Dec 2018 at 16:21, Sebastian Graf wrote: > >> Hey, >> >> thanks, all! Measuring with `-A1M -F1` delivers much more reliable >> residency numbers. >> `-F` doesn't seem to be documented. From reading `rts/RtsFlags.c` and >> `rts/sm/GC.c` I gather that it's the factor by which to multiply the number >> of live bytes by to get the new old gen size? >> So effectively, the old gen will 'overflow' on every minor GC, neat! >> >> Greetings >> Sebastian >> >> Am Do., 6. Dez. 2018 um 12:52 Uhr schrieb Simon Peyton Jones via ghc-devs >> : >> >>> | Right. A parameter for fixing the nursery size would be easy to >>> implement, >>> | I think. Just a new flag, then in GC.c:resize_nursery() use the flag >>> as the >>> | nursery size. >>> >>> Super! That would be v useful. >>> >>> | "Max. residency" is really hard to measure (need to do very frequent >>> GCs), >>> | perhaps a better question to ask is "residency when the program is in >>> state >>> | S". >>> >>> Actually, Sebastian simply wants to see an accurate, reproducible >>> residency profile, and doing frequent GCs might well be an acceptable >>> cost. >>> >>> Simon >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Mon Dec 10 05:29:31 2018 From: mgsloan at gmail.com (Michael Sloan) Date: Sun, 9 Dec 2018 21:29:31 -0800 Subject: Understanding bind in template haskell In-Reply-To: References: Message-ID: Hi Yotam, Template Haskell expression quotes must start with either `[|` or `[e|`, but instead these start with `[e |` - note the space. They are list comprehensions which filter to just the elements of `es` that match the `(dL -> L _ (Present _ e))`. Also, the `dL -> ...` portion is a view pattern that is equivalent to `id`, since since the arguments are already wrapped in `L`. For something like `runQ [| Foo b <- Foo 1 |]` to work, there'd need to be a quotation for `Stmt`, but there are only quotations for `Exp` / `[Dec]` / `Type` / `Pat`. I hope that's helpful! -Michael On Sat, Dec 8, 2018 at 3:30 AM Yotam Ohad wrote: > > Hi, > In the function DsMeta.repE there is a format being repeated: > For example in: > > repE e@(ExplicitTuple _ es boxed) > | not (all tupArgPresent es) = notHandled "Tuple sections" (ppr e) > | isBoxed boxed = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es] > ; repTup xs } > | otherwise = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es] > ; repUnboxedTup xs } > > There is `(dL->L _ (Present _ e)) <- es`. I don't understand how this type checks correctly. > If I'll try to do > > data Foo a = Foo a > runQ [| Foo b <- Foo 1 |] > > in ghciI get an error. What is the difference? > > Yotam > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From marlowsd at gmail.com Mon Dec 10 08:11:30 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 10 Dec 2018 08:11:30 +0000 Subject: Residency profiles In-Reply-To: References: Message-ID: https://phabricator.haskell.org/D5428 On Sun, 9 Dec 2018 at 10:12, Sebastian Graf wrote: > Ah, I was only looking at `+RTS --help`, not the users guide. Silly me. > > Am Do., 6. Dez. 2018 um 20:53 Uhr schrieb Simon Marlow >: > >> It is documented! >> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_control.html#rts-flag--F%20%E2%9F%A8factor%E2%9F%A9 >> >> On Thu, 6 Dec 2018 at 16:21, Sebastian Graf wrote: >> >>> Hey, >>> >>> thanks, all! Measuring with `-A1M -F1` delivers much more reliable >>> residency numbers. >>> `-F` doesn't seem to be documented. From reading `rts/RtsFlags.c` and >>> `rts/sm/GC.c` I gather that it's the factor by which to multiply the number >>> of live bytes by to get the new old gen size? >>> So effectively, the old gen will 'overflow' on every minor GC, neat! >>> >>> Greetings >>> Sebastian >>> >>> Am Do., 6. Dez. 2018 um 12:52 Uhr schrieb Simon Peyton Jones via >>> ghc-devs : >>> >>>> | Right. A parameter for fixing the nursery size would be easy to >>>> implement, >>>> | I think. Just a new flag, then in GC.c:resize_nursery() use the flag >>>> as the >>>> | nursery size. >>>> >>>> Super! That would be v useful. >>>> >>>> | "Max. residency" is really hard to measure (need to do very frequent >>>> GCs), >>>> | perhaps a better question to ask is "residency when the program is >>>> in state >>>> | S". >>>> >>>> Actually, Sebastian simply wants to see an accurate, reproducible >>>> residency profile, and doing frequent GCs might well be an acceptable >>>> cost. >>>> >>>> Simon >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Dec 11 02:15:14 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 10 Dec 2018 21:15:14 -0500 Subject: are ghc commits only getting make fast test'd on OSX? In-Reply-To: <875zw4vhu2.fsf@smart-cactus.org> References: <875zw4vhu2.fsf@smart-cactus.org> Message-ID: yeah, this turned out to be the dwarf issue i think, On Fri, Dec 7, 2018 at 10:05 PM Ben Gamari wrote: > Sorry for the latency, I'm currently working through a few weeks of > email backlog. > > > Carter Schonwald writes: > > > thats the only explanation of why i see soooo many test suite failues of > a > > GHC RELEASE when i do make test ... > > > It's hard to comment without knowing more about what specific failures > you are seeing. > > > why do we not have a full ./validate run on each tier one platform as > part > > of some official release check list? > > > We do. All of the Tier 1 platforms have go through full validation. You > can see this yourself by looking at .circleci/config.yml. > > > DO WE HAVE a checklist for releases? if not, we should, this shouldn't be > > happening > > Yes, we do. It is here [1]. > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/MakingReleases > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Dec 12 14:09:39 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 12 Dec 2018 14:09:39 +0000 Subject: Windows failures Message-ID: Tamar Things are getting better. Here's my list of testsuite failure on Windows, based on last night's HEAD. Still 16 failures. Simon Unexpected failures: plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) th/T10596.run T10596 [exit code non-0] (normal) th/TH_spliceE1.run TH_spliceE1 [exit code non-0] (ext-interp) th/TH_PromotedList.run TH_PromotedList [exit code non-0] (ext-interp) libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins10.run plugins10 [bad stdout] (normal) plugins/plugins11.run plugins11 [bad stdout] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Thu Dec 13 06:09:56 2018 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 13 Dec 2018 07:09:56 +0100 Subject: Post-spec optimisation, wen and where Message-ID: Hi devs, I am wondering where the optimisation (e.g. simplified) of specialised dictionaries is taking place. In my case -ddump-spec shows unoptimised, but -ddump-simpl-iterations shows already optimised dictionaries (float-out already happened). I searched yesterday, but to no avail. Thanks, Gabor -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Dec 13 08:37:17 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 13 Dec 2018 08:37:17 +0000 Subject: Post-spec optimisation, wen and where In-Reply-To: References: Message-ID: I’m afraid I don’t understand the question. Can you show a small test case and make your question concrete? Simon From: ghc-devs On Behalf Of Gabor Greif Sent: 13 December 2018 06:10 To: ghc-devs Subject: Post-spec optimisation, wen and where Hi devs, I am wondering where the optimisation (e.g. simplified) of specialised dictionaries is taking place. In my case -ddump-spec shows unoptimised, but -ddump-simpl-iterations shows already optimised dictionaries (float-out already happened). I searched yesterday, but to no avail. Thanks, Gabor -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Thu Dec 13 09:10:10 2018 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 13 Dec 2018 10:10:10 +0100 Subject: Post-spec optimisation, wen and where In-Reply-To: References: Message-ID: Sure. It happens in https://gitlab.staging.haskell.org/ghc/ghc/blob/master/compiler/simplCore/SimplCore.hs#L225 When full laziness is enabled, then after Specialising there is a float-out pass. The normal simplification passes are later, at line 254. This is the reason why I see already optimised core with -ddump-simpl-iterations. The issue disappears when I compile with -fno-full-laziness. So I answered my own question. Now on to figuring out why some silly float-outs are happening. (This is related to https://ghc.haskell.org/trac/ghc/ticket/16039, btw.) Cheers and thanks, Gabor On 12/13/18, Simon Peyton Jones wrote: > I’m afraid I don’t understand the question. Can you show a small test case > and make your question concrete? > > Simon > > From: ghc-devs On Behalf Of Gabor Greif > Sent: 13 December 2018 06:10 > To: ghc-devs > Subject: Post-spec optimisation, wen and where > > Hi devs, > > I am wondering where the optimisation (e.g. simplified) of specialised > dictionaries is taking place. In my case -ddump-spec shows unoptimised, but > -ddump-simpl-iterations shows already optimised dictionaries (float-out > already happened). > > I searched yesterday, but to no avail. > > Thanks, > > Gabor > From sgraf1337 at gmail.com Fri Dec 14 15:07:50 2018 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Fri, 14 Dec 2018 16:07:50 +0100 Subject: Better perf Message-ID: Hey, when going through Simon-nofib-notes, I stumbled over this thread from March 2017, when I hadn't yet subscribed to this list: https://mail.haskell.org/pipermail/ghc-devs/2017-March/013887.html. Joachim and Simon were trying to pin-point seemingly random regressions and improvements of ~5% to `binary-trees`. It's hard to say in retrospect, but I suspect this is the same effect I experienced in #15333 and I'm about to fix in #15999, e.g. that small changes to allocations lead to big, uncorrelated jumps in runtime performance due to GC. Just wanted to record this here for posterity. Cheers Sebastian Hi, > > Am Dienstag, den 07.03.2017, 22:55 +0000 schrieb Simon Peyton Jones via > ghc-devs: > >* > But: binary-trees runtime increases by 5%. > *> >* David: might you look to see if there is any obvious reason for this > *>* regression? We could just accept it, but it's always good to know > *>* why, and to document it. > * > Turns out that my commit > Add rule mapFB c (λx.x) = c > fixed that regression:https://perf.haskell.org/ghc/#revision/2fa44217c1d9722227297eefb0d6c6aed7e128ca > > Maybe there is just a performance cliff there, and these jumps don’t > really mean anything. > > Greetings, > Joachim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Sat Dec 15 08:48:23 2018 From: sylvain at haskus.fr (Sylvain Henry) Date: Sat, 15 Dec 2018 09:48:23 +0100 Subject: Fwd: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70) In-Reply-To: <20181215004947.9E57A3ABA8@ghc.haskell.org> References: <20181215004947.9E57A3ABA8@ghc.haskell.org> Message-ID: Hi Ben, I've just noticed that when you commit a diff from phab (as below), you are assigned both as committer and *author* (see also here https://git.haskell.org/ghc.git/commitdiff/a1c0b70638949a73bbd404c11797f2edf28f5965). Reviewers and subscribers to the phab diff are indicated in the commit message but not the author (here Ingo Blechschmidt "iblech"). I'm worried that if the Phabricator instance goes down we won't be able to retrieve commit authors. And also that they are not credited appropriately (cf git shortlog -sne). (By the way, I've also noticed that .mailmap contents isn't up to date: `git shortlog -se | cut -f2 | cut -d'<' -f1 | uniq -d` isn't empty. Maybe you could add a check in a script somewhere to ensure that it stays empty when you push a commit?). Regards, Sylvain -------- Forwarded Message -------- Subject: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70) Date: Sat, 15 Dec 2018 00:49:47 +0000 (UTC) From: git at git.haskell.org Reply-To: ghc-devs at haskell.org To: ghc-commits at haskell.org Repository : ssh://git at git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/a1c0b70638949a73bbd404c11797f2edf28f5965/ghc > --------------------------------------------------------------- commit a1c0b70638949a73bbd404c11797f2edf28f5965 Author: Ben Gamari Date: Fri Dec 14 11:10:56 2018 -0500 Use https links in user-facing startup and error messages I consider myself lucky that in my circle of friends, `http` urls (as opposed to `https` urls) are frowned upon in that we generally apologize in the rase cases that we share an `http` url. This pull request changes `http` links into their `https` analogues in the following places: * In the GHCI startup message (and parts of the User's Guide, where there are verbatim transcripts of GHCi sessions). * In a couple of error messages, asking the user to report a bug. (I also took the liberty to change a single space before the reportabug url into two spaces, harmonizing this occurence with the others.) I'm not trying to start a war. I just had a moment to spare and felt like preparing this diff. Merge or don't merge as you wish! Reviewers: bgamari, erikd, simonmar Subscribers: goldfire, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5450 > --------------------------------------------------------------- a1c0b70638949a73bbd404c11797f2edf28f5965 compiler/typecheck/TcTyClsDecls.hs | 2 +- compiler/utils/Panic.hs | 2 +- docs/users_guide/ghci.rst | 4 ++-- ghc/GHCi/UI.hs | 2 +- rts/RtsMessages.c | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/compiler/typecheck/TcTyClsDecls.hs b/compiler/typecheck/TcTyClsDecls.hs index cc9779a..71899a1 100644 --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -3609,7 +3609,7 @@ checkValidRoles tc report_error doc = addErrTc $ vcat [text "Internal error in role inference:", doc, - text "Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug"] + text "Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug"] {- ************************************************************************ diff --git a/compiler/utils/Panic.hs b/compiler/utils/Panic.hs index 03f095b..4f0f3b1 100644 --- a/compiler/utils/Panic.hs +++ b/compiler/utils/Panic.hs @@ -168,7 +168,7 @@ showGhcException exception showString "panic! (the 'impossible' happened)\n" . showString (" (GHC version " ++ cProjectVersion ++ " for " ++ TargetPlatform_NAME ++ "):\n\t") . s . showString "\n\n" - . showString "Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n" + . showString "Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\n" throwGhcException :: GhcException -> a diff --git a/docs/users_guide/ghci.rst b/docs/users_guide/ghci.rst index 49a96ca..f468e80 100644 --- a/docs/users_guide/ghci.rst +++ b/docs/users_guide/ghci.rst @@ -37,7 +37,7 @@ command ``ghci``: .. code-block:: none $ ghci - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help Prelude> There may be a short pause while GHCi loads the prelude and standard @@ -2052,7 +2052,7 @@ by using the :ghc-flag:`-package ⟨pkg⟩` flag: .. code-block:: none $ ghci -package readline - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package readline-1.0 ... linking ... done. Prelude> diff --git a/ghc/GHCi/UI.hs b/ghc/GHCi/UI.hs index ae8ba02..13275f8 100644 --- a/ghc/GHCi/UI.hs +++ b/ghc/GHCi/UI.hs @@ -162,7 +162,7 @@ defaultGhciSettings = ghciWelcomeMsg :: String ghciWelcomeMsg = "GHCi, version " ++ cProjectVersion ++ - ": http://www.haskell.org/ghc/ :? for help" + ": https://www.haskell.org/ghc/ :? for help" ghciCommands :: [Command] ghciCommands = map mkCmd [ diff --git a/rts/RtsMessages.c b/rts/RtsMessages.c index 053805e..a90962e 100644 --- a/rts/RtsMessages.c +++ b/rts/RtsMessages.c @@ -172,7 +172,7 @@ rtsFatalInternalErrorFn(const char *s, va_list ap) #endif fprintf(stderr, "\n"); fprintf(stderr, " (GHC version %s for %s)\n", ProjectVersion, xstr(HostPlatform_TYPE)); - fprintf(stderr, " Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n"); + fprintf(stderr, " Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\n"); fflush(stderr); } #if defined(mingw32_HOST_OS) _______________________________________________ ghc-commits mailing list ghc-commits at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Dec 15 16:30:44 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 15 Dec 2018 11:30:44 -0500 Subject: Fwd: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70) In-Reply-To: References: <20181215004947.9E57A3ABA8@ghc.haskell.org> Message-ID: <87efaisqfi.fsf@smart-cactus.org> Sylvain Henry writes: > Hi Ben, > > I've just noticed that when you commit a diff from phab (as below), you > are assigned both as committer and *author* (see also here > https://git.haskell.org/ghc.git/commitdiff/a1c0b70638949a73bbd404c11797f2edf28f5965). > Yes, this is very unfortunate. It is a known quirk of arc land that it sometimes fails to properly attribute patches; it only happens occasionally and I haven't been able to identify the precise cause. I generally look for this improper attribution and resolve it manually but it seems I missed this one. > Reviewers and subscribers to the phab diff are indicated in the commit > message but not the author (here Ingo Blechschmidt "iblech"). I'm > worried that if the Phabricator instance goes down we won't be able to > retrieve commit authors. And also that they are not credited > appropriately (cf git shortlog -sne). > Yes, this is a concern. Unfortunately there is little that can be done now. Thankfully we will soon be free of this issue. > (By the way, I've also noticed that .mailmap contents isn't up to date: > `git shortlog -se | cut -f2 | cut -d'<' -f1 | uniq -d` isn't empty. > Maybe you could add a check in a script somewhere to ensure that it > stays empty when you push a commit?). > This is something I intend to do after the GitLab transition, yes. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mail at joachim-breitner.de Sat Dec 15 16:48:00 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 15 Dec 2018 17:48:00 +0100 Subject: Fwd: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70) In-Reply-To: References: <20181215004947.9E57A3ABA8@ghc.haskell.org> Message-ID: Hi, heh, I was confused: The commit message text did not read like Ben’s voice… but that explains it. Anyways, thanks Ingo for the patch! Contributor attribution is important, to foster motivation. Maybe we should use git-replace to fix the commit description with the correct author line? Cheers, Joachim Am Samstag, den 15.12.2018, 09:48 +0100 schrieb Sylvain Henry: > Hi Ben, > I've just noticed that when you commit a diff from phab (as below), you are assigned both as committer and *author* (see also here https://git.haskell.org/ghc.git/commitdiff/a1c0b70638949a73bbd404c11797f2edf28f5965). > Reviewers and subscribers to the phab diff are indicated in the commit message but not the author (here Ingo Blechschmidt "iblech"). I'm worried that if the Phabricator instance goes down we won't be able to retrieve commit authors. And also that they are not credited appropriately (cf git shortlog -sne). > (By the way, I've also noticed that .mailmap contents isn't up to date: `git shortlog -se | cut -f2 | cut -d'<' -f1 | uniq -d` isn't empty. Maybe you could add a check in a script somewhere to ensure that it stays empty when you push a commit?). > Regards, > Sylvain > > > -------- Forwarded Message -------- > Subject: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70) > Date: Sat, 15 Dec 2018 00:49:47 +0000 (UTC) > From: git at git.haskell.org > Reply-To: ghc-devs at haskell.org > To: ghc-commits at haskell.org > > > Repository : ssh://git at git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/a1c0b70638949a73bbd404c11797f2edf28f5965/ghc > > > --------------------------------------------------------------- > > commit a1c0b70638949a73bbd404c11797f2edf28f5965 > Author: Ben Gamari > Date: Fri Dec 14 11:10:56 2018 -0500 > > Use https links in user-facing startup and error messages > I consider myself lucky that in my circle of friends, `http` urls (as > opposed to `https` urls) are frowned upon in that we generally > apologize in the rase cases that we share an `http` url. > This pull request changes `http` links into their `https` analogues in > the following places: > * In the GHCI startup message (and parts of the User's Guide, where > there are verbatim transcripts of GHCi sessions). > * In a couple of error messages, asking the user to report a bug. > (I also took the liberty to change a single space before the reportabug > url into two spaces, harmonizing this occurence with the others.) > I'm not trying to start a war. I just had a moment to spare and felt > like preparing this diff. Merge or don't merge as you wish! > Reviewers: bgamari, erikd, simonmar > Subscribers: goldfire, rwbarton, carter > Differential Revision: https://phabricator.haskell.org/D5450 > > > > --------------------------------------------------------------- > > a1c0b70638949a73bbd404c11797f2edf28f5965 > compiler/typecheck/TcTyClsDecls.hs | 2 +- > compiler/utils/Panic.hs | 2 +- > docs/users_guide/ghci.rst | 4 ++-- > ghc/GHCi/UI.hs | 2 +- > rts/RtsMessages.c | 2 +- > 5 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/compiler/typecheck/TcTyClsDecls.hs b/compiler/typecheck/TcTyClsDecls.hs > index cc9779a..71899a1 100644 > --- a/compiler/typecheck/TcTyClsDecls.hs > +++ b/compiler/typecheck/TcTyClsDecls.hs > @@ -3609,7 +3609,7 @@ checkValidRoles tc > report_error doc > = addErrTc $ vcat [text "Internal error in role inference:", > doc, > - text "Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug"] > + text "Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug"] > {- > ************************************************************************ > diff --git a/compiler/utils/Panic.hs b/compiler/utils/Panic.hs > index 03f095b..4f0f3b1 100644 > --- a/compiler/utils/Panic.hs > +++ b/compiler/utils/Panic.hs > @@ -168,7 +168,7 @@ showGhcException exception > showString "panic! (the 'impossible' happened)\n" > . showString (" (GHC version " ++ cProjectVersion ++ " for " ++ TargetPlatform_NAME ++ "):\n\t") > . s . showString "\n\n" > - . showString "Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n" > + . showString "Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\n" > throwGhcException :: GhcException -> a > diff --git a/docs/users_guide/ghci.rst b/docs/users_guide/ghci.rst > index 49a96ca..f468e80 100644 > --- a/docs/users_guide/ghci.rst > +++ b/docs/users_guide/ghci.rst > @@ -37,7 +37,7 @@ command ``ghci``: > .. code-block:: none > $ ghci > - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help > + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help > Prelude> > There may be a short pause while GHCi loads the prelude and standard > @@ -2052,7 +2052,7 @@ by using the :ghc-flag:`-package ⟨pkg⟩` flag: > .. code-block:: none > $ ghci -package readline > - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help > + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Loading package readline-1.0 ... linking ... done. > Prelude> > diff --git a/ghc/GHCi/UI.hs b/ghc/GHCi/UI.hs > index ae8ba02..13275f8 100644 > --- a/ghc/GHCi/UI.hs > +++ b/ghc/GHCi/UI.hs > @@ -162,7 +162,7 @@ defaultGhciSettings = > ghciWelcomeMsg :: String > ghciWelcomeMsg = "GHCi, version " ++ cProjectVersion ++ > - ": http://www.haskell.org/ghc/ :? for help" > + ": https://www.haskell.org/ghc/ :? for help" > ghciCommands :: [Command] > ghciCommands = map mkCmd [ > diff --git a/rts/RtsMessages.c b/rts/RtsMessages.c > index 053805e..a90962e 100644 > --- a/rts/RtsMessages.c > +++ b/rts/RtsMessages.c > @@ -172,7 +172,7 @@ rtsFatalInternalErrorFn(const char *s, va_list ap) > #endif > fprintf(stderr, "\n"); > fprintf(stderr, " (GHC version %s for %s)\n", ProjectVersion, xstr(HostPlatform_TYPE)); > - fprintf(stderr, " Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n"); > + fprintf(stderr, " Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\n"); > fflush(stderr); > } > #if defined(mingw32_HOST_OS) > > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at smart-cactus.org Sat Dec 15 18:13:19 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 15 Dec 2018 13:13:19 -0500 Subject: Fwd: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70) In-Reply-To: References: <20181215004947.9E57A3ABA8@ghc.haskell.org> Message-ID: <87bm5mslok.fsf@smart-cactus.org> Joachim Breitner writes: > Hi, > > heh, I was confused: The commit message text did not read like Ben’s > voice… but that explains it. Anyways, thanks Ingo for the patch! > > Contributor attribution is important, to foster motivation. Maybe we > should use git-replace to fix the commit description with the correct > author line? > Agreed. I did push a git note amending the commit message to attribute the change to Ingo. However, I had no idea that git-replace was a thing. It looks to be perfect for patching up this sort of mishap. I'll push a replacement. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From matthewtpickering at gmail.com Sat Dec 15 19:10:48 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 15 Dec 2018 19:10:48 +0000 Subject: Fwd: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70) In-Reply-To: <87efaisqfi.fsf@smart-cactus.org> References: <20181215004947.9E57A3ABA8@ghc.haskell.org> <87efaisqfi.fsf@smart-cactus.org> Message-ID: I was under the impression this happened if someone made a diff by the web UI rather than using arc. Could that be the case here? Matt On Sat, Dec 15, 2018 at 4:31 PM Ben Gamari wrote: > > Sylvain Henry writes: > > > Hi Ben, > > > > I've just noticed that when you commit a diff from phab (as below), you > > are assigned both as committer and *author* (see also here > > https://git.haskell.org/ghc.git/commitdiff/a1c0b70638949a73bbd404c11797f2edf28f5965). > > > Yes, this is very unfortunate. It is a known quirk of arc land > that it sometimes fails to properly attribute patches; it only happens > occasionally and I haven't been able to identify the precise cause. > I generally look for this improper attribution and resolve it manually > but it seems I missed this one. > > > Reviewers and subscribers to the phab diff are indicated in the commit > > message but not the author (here Ingo Blechschmidt "iblech"). I'm > > worried that if the Phabricator instance goes down we won't be able to > > retrieve commit authors. And also that they are not credited > > appropriately (cf git shortlog -sne). > > > Yes, this is a concern. Unfortunately there is little that can be done now. > Thankfully we will soon be free of this issue. > > > (By the way, I've also noticed that .mailmap contents isn't up to date: > > `git shortlog -se | cut -f2 | cut -d'<' -f1 | uniq -d` isn't empty. > > Maybe you could add a check in a script somewhere to ensure that it > > stays empty when you push a commit?). > > > This is something I intend to do after the GitLab transition, yes. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Sat Dec 15 19:54:57 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 15 Dec 2018 14:54:57 -0500 Subject: Fwd: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70) In-Reply-To: References: <20181215004947.9E57A3ABA8@ghc.haskell.org> <87efaisqfi.fsf@smart-cactus.org> Message-ID: <874lbesgz6.fsf@smart-cactus.org> Matthew Pickering writes: > I was under the impression this happened if someone made a diff by the > web UI rather than using arc. Could that be the case here? > That is certainly one way that this can happen. However, judging by the fact that Phab correctly displays the context of the diff, I don't believe this is the cause here. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From lonetiger at gmail.com Sun Dec 16 13:47:56 2018 From: lonetiger at gmail.com (Phyx) Date: Sun, 16 Dec 2018 13:47:56 +0000 Subject: Windows failures In-Reply-To: References: Message-ID: 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 hope to get a few of my outstanding patches upstream in the next two weeks and will take a look at the failures a bit more in depth after that. I am also not quite sure why the plugin-recomp tests seem to consistently fail for you, I can't seem to reproduce it and don't see it on harbormaster either. When it fails does it give any output? Kind regards, Tamar On Wed, Dec 12, 2018 at 2:09 PM Simon Peyton Jones wrote: > Tamar > > Things are getting better. Here’s my list of testsuite failure on > Windows, based on last night’s HEAD. Still 16 failures. > > Simon > > Unexpected failures: > > plugins/plugin-recomp-change.run plugin-recomp-change [bad exit > code] (normal) > > rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) > > simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) > > th/T10596.run T10596 [exit code non-0] (normal) > > th/TH_spliceE1.run TH_spliceE1 [exit code non-0] > (ext-interp) > > th/TH_PromotedList.run TH_PromotedList [exit code non-0] > (ext-interp) > > libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) > > plugins/plugins07.run plugins07 [bad exit code] (normal) > > plugins/plugins09.run plugins09 [bad exit code] (normal) > > plugins/plugins10.run plugins10 [bad stdout] (normal) > > plugins/plugins11.run plugins11 [bad stdout] (normal) > > plugins/T10420.run T10420 [bad exit code] (normal) > > plugins/T10294a.run T10294a [bad exit code] (normal) > > plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] > (normal) > > plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit > code] (normal) > > plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] > (normal) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Dec 17 05:29:00 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 17 Dec 2018 00:29:00 -0500 Subject: GitLab migration status Message-ID: <871s6gsovc.fsf@smart-cactus.org> TL;DR. Given somewhat slower-than-expected progress on the Trac import I suggest that we implement a pared-down migration on Tuesday. See "The Plan" below. Hello everyone, Over the last few weeks we have been hard at work preparing the migration to GitLab. Currently the following things are ready: * Hosting of GHC's repositories and those of its mirrors have been prepared. * Continuous integration has been configured for GHC. All-in-all the GitLab migration has been quite timely since we were recently notified by CircleCI of billing changes which will soon make it quite difficult for us to continue using their services (see the thread on ghc-devops for details). Thankfully, moving CI to GitLab has been mostly painless and has even enabled us to introduce testing of platforms which were previously inaccessible to us under CircleCI. * The various linters which previously ran via `arc lint` and gitolite post-receive hooks have been ported to CI jobs. * The Trac ticket migration is looking good although there are still a significant number of details which need to be sorted out. * The Wiki migration is in a similar state. Over the past weeks we have been in constant contact with GitLab's FOSS outreach group, who have been quite helpful in getting the eyes of GitLab employees on the issues affecting our transition. Thanks to especially to David Planella for his help so far. Unfortunately, there is one issue in particular [1] which is currently blocking the Trac migration. From my discussions with GitLab's upstream it sounds like it may be possible for them to prioritize a fix in the short-term. However, our aggressive migration timeline is a fair bit faster than GitLab's development cycle and consequently this certainly won't happen before our planned migration on Tuesday. # The Plan Given what remains to be done in the Trac migration I believe it would be a mistake to move ahead with the full migration as planned. However, in the interest of re-gaining functional continuous integration of patches as soon as possible I propose that we move ahead with moving code review on Tuesday. The plan would be as follows: 1. We setup the final gitlab.haskell.org instance tomorrow; since the Trac migration will not be run will need to create new accounts on instance. 2. We begin officially accepting merge requests on this fresh GitLab instance on Tuesday. At this point gitlab.haskell.org:ghc/ghc will become GHC's official upstream repository. 3. We allow a week of transition time where new Differentials will continue to be accepted via Phabricator. 4. After this transition period we place Phabricator in read-only mode. 5. When we are confident in the Trac migration (likely after the new year) we move ahead with importing tickets and the wiki Previously I was skeptical of any plan that involved running the Trac migration against a live GitLab instance. However, further reflection I believe such a migration is safe and feasible. Moreover, given the constraints set upon us by the impending CircleCI changes, I think this is our best option to ensure continuity of CI. Thoughts? Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/46980 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From marlowsd at gmail.com Mon Dec 17 08:03:25 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 17 Dec 2018 08:03:25 +0000 Subject: [GHC DevOps Group] GitLab migration status In-Reply-To: <871s6gsovc.fsf@smart-cactus.org> References: <871s6gsovc.fsf@smart-cactus.org> Message-ID: Hi Ben - this sounds good, a couple of questions: - What about the performance issue we noticed last week? - What will happen to Phabricator diffs that are still mid-review? It would be a shame to have to move them to gitlab and interrupt the review trail. Can't we just shut Phabricator to new diffs but keep the possibility of working on existing ones? Cheers Simon On Mon, 17 Dec 2018 at 05:29, Ben Gamari wrote: > TL;DR. Given somewhat slower-than-expected progress on the Trac import I > suggest that we implement a pared-down migration on Tuesday. > See "The Plan" below. > > > Hello everyone, > > Over the last few weeks we have been hard at work preparing the > migration to GitLab. Currently the following things are ready: > > * Hosting of GHC's repositories and those of its mirrors have been > prepared. > > * Continuous integration has been configured for GHC. > > All-in-all the GitLab migration has been quite timely since we were > recently notified by CircleCI of billing changes which will soon make > it quite difficult for us to continue using their services (see the > thread on ghc-devops for details). > > Thankfully, moving CI to GitLab has been mostly painless and has > even enabled us to introduce testing of platforms which were > previously inaccessible to us under CircleCI. > > * The various linters which previously ran via `arc lint` and gitolite > post-receive hooks have been ported to CI jobs. > > * The Trac ticket migration is looking good although there are still a > significant number of details which need to be sorted out. > > * The Wiki migration is in a similar state. > > Over the past weeks we have been in constant contact with GitLab's FOSS > outreach group, who have been quite helpful in getting the eyes of > GitLab employees on the issues affecting our transition. Thanks to > especially to David Planella for his help so far. > > Unfortunately, there is one issue in particular [1] which is currently > blocking the Trac migration. From my discussions with GitLab's upstream > it sounds like it may be possible for them to prioritize a fix in the > short-term. However, our aggressive migration timeline is a fair bit > faster than GitLab's development cycle and consequently this certainly > won't happen before our planned migration on Tuesday. > > > # The Plan > > Given what remains to be done in the Trac migration I believe it would > be a mistake to move ahead with the full migration as planned. However, > in the interest of re-gaining functional continuous integration of > patches as soon as possible I propose that we move ahead with moving > code review on Tuesday. > > The plan would be as follows: > > 1. We setup the final gitlab.haskell.org instance tomorrow; since the > Trac migration will not be run will need to create new accounts on > instance. > > 2. We begin officially accepting merge requests on this fresh GitLab > instance on Tuesday. At this point gitlab.haskell.org:ghc/ghc will > become GHC's official upstream repository. > > 3. We allow a week of transition time where new Differentials will > continue to be accepted via Phabricator. > > 4. After this transition period we place Phabricator in read-only mode. > > 5. When we are confident in the Trac migration (likely after the new > year) we move ahead with importing tickets and the wiki > > Previously I was skeptical of any plan that involved running the Trac > migration against a live GitLab instance. However, further reflection > I believe such a migration is safe and feasible. Moreover, given the > constraints set upon us by the impending CircleCI changes, I think this > is our best option to ensure continuity of CI. > > Thoughts? > > Cheers, > > - Ben > > > [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/46980 > _______________________________________________ > Ghc-devops-group mailing list > Ghc-devops-group at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.jakobi at googlemail.com Mon Dec 17 08:17:18 2018 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Mon, 17 Dec 2018 09:17:18 +0100 Subject: [GHC DevOps Group] GitLab migration status In-Reply-To: <871s6gsovc.fsf@smart-cactus.org> References: <871s6gsovc.fsf@smart-cactus.org> Message-ID: Hi Ben, in my experience Gitlab has been extremely slow at showing commit diffs to the point that it gives up and returns a 502: https://gitlab.staging.haskell.org/ghc/ghc/issues/15944 Is this possibly related to any resource constraints on our instance? Cheers, Simon Am Mo., 17. Dez. 2018 um 06:29 Uhr schrieb Ben Gamari : > TL;DR. Given somewhat slower-than-expected progress on the Trac import I > suggest that we implement a pared-down migration on Tuesday. > See "The Plan" below. > > > Hello everyone, > > Over the last few weeks we have been hard at work preparing the > migration to GitLab. Currently the following things are ready: > > * Hosting of GHC's repositories and those of its mirrors have been > prepared. > > * Continuous integration has been configured for GHC. > > All-in-all the GitLab migration has been quite timely since we were > recently notified by CircleCI of billing changes which will soon make > it quite difficult for us to continue using their services (see the > thread on ghc-devops for details). > > Thankfully, moving CI to GitLab has been mostly painless and has > even enabled us to introduce testing of platforms which were > previously inaccessible to us under CircleCI. > > * The various linters which previously ran via `arc lint` and gitolite > post-receive hooks have been ported to CI jobs. > > * The Trac ticket migration is looking good although there are still a > significant number of details which need to be sorted out. > > * The Wiki migration is in a similar state. > > Over the past weeks we have been in constant contact with GitLab's FOSS > outreach group, who have been quite helpful in getting the eyes of > GitLab employees on the issues affecting our transition. Thanks to > especially to David Planella for his help so far. > > Unfortunately, there is one issue in particular [1] which is currently > blocking the Trac migration. From my discussions with GitLab's upstream > it sounds like it may be possible for them to prioritize a fix in the > short-term. However, our aggressive migration timeline is a fair bit > faster than GitLab's development cycle and consequently this certainly > won't happen before our planned migration on Tuesday. > > > # The Plan > > Given what remains to be done in the Trac migration I believe it would > be a mistake to move ahead with the full migration as planned. However, > in the interest of re-gaining functional continuous integration of > patches as soon as possible I propose that we move ahead with moving > code review on Tuesday. > > The plan would be as follows: > > 1. We setup the final gitlab.haskell.org instance tomorrow; since the > Trac migration will not be run will need to create new accounts on > instance. > > 2. We begin officially accepting merge requests on this fresh GitLab > instance on Tuesday. At this point gitlab.haskell.org:ghc/ghc will > become GHC's official upstream repository. > > 3. We allow a week of transition time where new Differentials will > continue to be accepted via Phabricator. > > 4. After this transition period we place Phabricator in read-only mode. > > 5. When we are confident in the Trac migration (likely after the new > year) we move ahead with importing tickets and the wiki > > Previously I was skeptical of any plan that involved running the Trac > migration against a live GitLab instance. However, further reflection > I believe such a migration is safe and feasible. Moreover, given the > constraints set upon us by the impending CircleCI changes, I think this > is our best option to ensure continuity of CI. > > Thoughts? > > Cheers, > > - Ben > > > [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/46980 > _______________________________________________ > Ghc-devops-group mailing list > Ghc-devops-group at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Dec 17 15:14:31 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 17 Dec 2018 10:14:31 -0500 Subject: [GHC DevOps Group] GitLab migration status In-Reply-To: References: <871s6gsovc.fsf@smart-cactus.org> Message-ID: <87woo8qj71.fsf@smart-cactus.org> Simon Jakobi via ghc-devs writes: > Hi Ben, > > in my experience Gitlab has been extremely slow at showing commit diffs to > the point that it gives up and returns a 502: > https://gitlab.staging.haskell.org/ghc/ghc/issues/15944 > > Is this possibly related to any resource constraints on our instance? > Yes, I have also noticed the general slowness of our instance. Last week I identified the cause as being the fact that it is being hosted on an AArch64 box, which apparently isn't a configuration that is very well supported by the Ruby interpreter's optimised implementation. The same instance running on x86_64 is much more responsive [1]. Cheers, - Ben [1] https://gitlab.staging2.haskell.org/ghc/ghc/merge_requests/11 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Mon Dec 17 15:52:42 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 17 Dec 2018 10:52:42 -0500 Subject: [GHC DevOps Group] GitLab migration status In-Reply-To: References: <871s6gsovc.fsf@smart-cactus.org> Message-ID: <87sgywqhfb.fsf@smart-cactus.org> Simon Marlow writes: > Hi Ben - this sounds good, a couple of questions: > > - What about the performance issue we noticed last week? I identified the problem as being the ARM environment which the staging instance is running on. The final instance will run on x86_64. > - What will happen to Phabricator diffs that are still mid-review? It would > be a shame to have to move them to gitlab and interrupt the review trail. > Can't we just shut Phabricator to new diffs but keep the possibility of > working on existing ones? > Of course. That is perhaps a better path forward. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rae at cs.brynmawr.edu Tue Dec 18 03:25:06 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 17 Dec 2018 22:25:06 -0500 Subject: [GHC DevOps Group] GitLab migration status In-Reply-To: <87sgywqhfb.fsf@smart-cactus.org> References: <871s6gsovc.fsf@smart-cactus.org> <87sgywqhfb.fsf@smart-cactus.org> Message-ID: <92A44AB2-ACCB-4A24-A17D-FBC4CE305B06@cs.brynmawr.edu> > On Dec 17, 2018, at 10:52 AM, Ben Gamari wrote: > >> >> - What will happen to Phabricator diffs that are still mid-review? It would >> be a shame to have to move them to gitlab and interrupt the review trail. >> Can't we just shut Phabricator to new diffs but keep the possibility of >> working on existing ones? >> > Of course. That is perhaps a better path forward. I second this notion, that we stop accepting new diffs on Phab but continue to work with existing diffs until they are merged or abandoned (depending on how resource-intensive it is to do this). Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Dec 18 18:33:34 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 18 Dec 2018 13:33:34 -0500 Subject: [GHC DevOps Group] GitLab migration status In-Reply-To: References: <871s6gsovc.fsf@smart-cactus.org> Message-ID: Hey simon! I actually did some digging. And it looks like currently gitlab basically does a git diff of the two branches and does that computation on every page reload. 1). There currently is no caching —- some of the folks on the Haskell infra team could help perhaps but they need to be given access to the setup for that to happen. 2) the complexity of the git diff is linear in the commit history length between the two branches being compared Some of these things could be mitigated easily, but I spoke with one of the folks on the Haskell infra team and it sounds like ultimately either patching the gitlab gitaly server or providing a more efficient api compatible replacement are what would be needed. On Mon, Dec 17, 2018 at 3:18 AM Simon Jakobi via ghc-devs < ghc-devs at haskell.org> wrote: > Hi Ben, > > in my experience Gitlab has been extremely slow at showing commit diffs to > the point that it gives up and returns a 502: > https://gitlab.staging.haskell.org/ghc/ghc/issues/15944 > > Is this possibly related to any resource constraints on our instance? > > Cheers, > Simon > > Am Mo., 17. Dez. 2018 um 06:29 Uhr schrieb Ben Gamari >: > >> TL;DR. Given somewhat slower-than-expected progress on the Trac import I >> suggest that we implement a pared-down migration on Tuesday. >> See "The Plan" below. >> >> >> Hello everyone, >> >> Over the last few weeks we have been hard at work preparing the >> migration to GitLab. Currently the following things are ready: >> >> * Hosting of GHC's repositories and those of its mirrors have been >> prepared. >> >> * Continuous integration has been configured for GHC. >> >> All-in-all the GitLab migration has been quite timely since we were >> recently notified by CircleCI of billing changes which will soon make >> it quite difficult for us to continue using their services (see the >> thread on ghc-devops for details). >> >> Thankfully, moving CI to GitLab has been mostly painless and has >> even enabled us to introduce testing of platforms which were >> previously inaccessible to us under CircleCI. >> >> * The various linters which previously ran via `arc lint` and gitolite >> post-receive hooks have been ported to CI jobs. >> >> * The Trac ticket migration is looking good although there are still a >> significant number of details which need to be sorted out. >> >> * The Wiki migration is in a similar state. >> >> Over the past weeks we have been in constant contact with GitLab's FOSS >> outreach group, who have been quite helpful in getting the eyes of >> GitLab employees on the issues affecting our transition. Thanks to >> especially to David Planella for his help so far. >> >> Unfortunately, there is one issue in particular [1] which is currently >> blocking the Trac migration. From my discussions with GitLab's upstream >> it sounds like it may be possible for them to prioritize a fix in the >> short-term. However, our aggressive migration timeline is a fair bit >> faster than GitLab's development cycle and consequently this certainly >> won't happen before our planned migration on Tuesday. >> >> >> # The Plan >> >> Given what remains to be done in the Trac migration I believe it would >> be a mistake to move ahead with the full migration as planned. However, >> in the interest of re-gaining functional continuous integration of >> patches as soon as possible I propose that we move ahead with moving >> code review on Tuesday. >> >> The plan would be as follows: >> >> 1. We setup the final gitlab.haskell.org instance tomorrow; since the >> Trac migration will not be run will need to create new accounts on >> instance. >> >> 2. We begin officially accepting merge requests on this fresh GitLab >> instance on Tuesday. At this point gitlab.haskell.org:ghc/ghc will >> become GHC's official upstream repository. >> >> 3. We allow a week of transition time where new Differentials will >> continue to be accepted via Phabricator. >> >> 4. After this transition period we place Phabricator in read-only mode. >> >> 5. When we are confident in the Trac migration (likely after the new >> year) we move ahead with importing tickets and the wiki >> >> Previously I was skeptical of any plan that involved running the Trac >> migration against a live GitLab instance. However, further reflection >> I believe such a migration is safe and feasible. Moreover, given the >> constraints set upon us by the impending CircleCI changes, I think this >> is our best option to ensure continuity of CI. >> >> Thoughts? >> >> Cheers, >> >> - Ben >> >> >> [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/46980 >> _______________________________________________ >> Ghc-devops-group mailing list >> Ghc-devops-group at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Dec 18 22:40:08 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 18 Dec 2018 23:40:08 +0100 Subject: GitLab migration status In-Reply-To: <871s6gsovc.fsf@smart-cactus.org> References: <871s6gsovc.fsf@smart-cactus.org> Message-ID: Hi, Am Montag, den 17.12.2018, 00:29 -0500 schrieb Ben Gamari: > 2. We begin officially accepting merge requests on this fresh GitLab > instance on Tuesday. At this point gitlab.haskell.org:ghc/ghc will > become GHC's official upstream repository. I guess this works only because GitLab has a different name (number) space for merge requests and issues, so creating MRs does not create collisions with the issues merged later … so yay :-) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From chrisdone at gmail.com Wed Dec 19 10:31:28 2018 From: chrisdone at gmail.com (Christopher Done) Date: Wed, 19 Dec 2018 10:31:28 +0000 Subject: How to use Data.Compact.Serialize Message-ID: Hi, On the docs for Data.Compact.Serialize it says: http://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact-Serialize.html > Our binary representation contains direct pointers to the info tables > of objects in the region. This means that the info tables of the > receiving process must be laid out in exactly the same way as from the > original process; in practice, this means using static linking, using > the exact same binary and turning off ASLR. It seems to me that in order to use this module in any practical way (i.e. write to file from one process, and then a later run of the process reads it), you need to know a special way to build your binary which isn't fully described here. What flags, for example, should be passed to GHC to make this viable? * Turning off ASLR on Linux is done by writing 0 to /proc/sys/kernel/randomize_va_space, which applies to all programs. That's not the most isolated way to deploy an app, but I discovered that you can set this per process here: https://askubuntu.com/a/507954 * To compile GHC programs statically, use -optl-static -optl-pthread. So in total the example would be: $ stack build compact compact-0.1.0.1: download compact-0.1.0.1: configure compact-0.1.0.1: build compact-0.1.0.1: copy/register Example file from docs: $ cat main.hs {-# LANGUAGE TypeApplications #-} import System.Environment import Data.Compact import Data.Compact.Serialize main = do arg:_ <- getArgs case arg of "write" -> do orig_c <- compact ("I want to serialize this", True) writeCompact @(String, Bool) "somefile" orig_c "read" -> do res <- unsafeReadCompact @(String, Bool) "somefile" case res of Left err -> fail err Right c -> print (getCompact c) Compiling statically: $ stack ghc -- -optl-static -optl-pthread main.hs [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ... [...hundred more warnings like this ...] Check that it's static: $ ldd main not a dynamic executable Write the file: $ setarch `uname -m` -R ./main write Read the file: $ setarch `uname -m` -R ./main read ("I want to serialize this",True) Can a GHC dev confirm that this is the proper way to do this? If so, I'll contribute this little example as documentation to the compact package. Cheers From chrisdone at gmail.com Wed Dec 19 10:33:29 2018 From: chrisdone at gmail.com (Christopher Done) Date: Wed, 19 Dec 2018 10:33:29 +0000 Subject: How to use Data.Compact.Serialize In-Reply-To: References: Message-ID: I forgot to address the fact that libc never statically links things like name server libraries. Therefore would GHC devs recommend using a musl-based build e.g. on Alpine Linux? Cheers On Wed, 19 Dec 2018 at 10:31, Christopher Done wrote: > > Hi, > > On the docs for Data.Compact.Serialize it says: > > http://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact-Serialize.html > > Our binary representation contains direct pointers to the info tables > > of objects in the region. This means that the info tables of the > > receiving process must be laid out in exactly the same way as from the > > original process; in practice, this means using static linking, using > > the exact same binary and turning off ASLR. > > It seems to me that in order to use this module in any practical way > (i.e. write to file from one process, and then a later run of the > process reads it), you need to know a special way to build your binary > which isn't fully described here. What flags, for example, should be > passed to GHC to make this viable? > > * Turning off ASLR on Linux is done by writing 0 to > /proc/sys/kernel/randomize_va_space, which applies to all > programs. That's not the most isolated way to deploy an app, but I > discovered that you can set this per process here: > https://askubuntu.com/a/507954 > * To compile GHC programs statically, use -optl-static -optl-pthread. > > So in total the example would be: > > $ stack build compact > compact-0.1.0.1: download > compact-0.1.0.1: configure > compact-0.1.0.1: build > compact-0.1.0.1: copy/register > > Example file from docs: > > $ cat main.hs > {-# LANGUAGE TypeApplications #-} > import System.Environment > import Data.Compact > import Data.Compact.Serialize > main = do > arg:_ <- getArgs > case arg of > "write" -> do > orig_c <- compact ("I want to serialize this", True) > writeCompact @(String, Bool) "somefile" orig_c > "read" -> do > res <- unsafeReadCompact @(String, Bool) "somefile" > case res of > Left err -> fail err > Right c -> print (getCompact c) > > Compiling statically: > > $ stack ghc -- -optl-static -optl-pthread main.hs > [1 of 1] Compiling Main ( main.hs, main.o ) > Linking main ... > [...hundred more warnings like this ...] > > Check that it's static: > > $ ldd main > not a dynamic executable > > Write the file: > > $ setarch `uname -m` -R ./main write > > Read the file: > > $ setarch `uname -m` -R ./main read > ("I want to serialize this",True) > > Can a GHC dev confirm that this is the proper way to do this? If so, > I'll contribute this little example as documentation to the compact package. > > Cheers From chrisdone at gmail.com Wed Dec 19 10:50:06 2018 From: chrisdone at gmail.com (Christopher Done) Date: Wed, 19 Dec 2018 10:50:06 +0000 Subject: GHC (API?) question: GHC Core for Base libraries In-Reply-To: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> References: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> Message-ID: Hi Bill, I use a different approach, using docker, and that's to use a patched `Main.hs` (https://github.com/chrisdone/prana/commits/master/ghc-8.0/Main.hs) and compile GHC with that patched file. It's a little unorthodox but has so far been highly effective. Here is a repo of a core interpreter I've been dabbling with: https://github.com/chrisdone/prana Here I have a Dockerfile that copies my edited version of `Main.hs` and builds base, ghc-prim and integer-gmp together into an isolated package database: https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L56-L114 My Main.hs writes a .prana file for every module. At the end of the Dockerfile, I export that to a .tar.gz archive: https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L113 Then I have a set of scripts https://github.com/chrisdone/prana/tree/master/scripts To build the image, and one to copy the libraries to the current directory under `libraries/`. Hope that's of some help! From chrisdone at gmail.com Wed Dec 19 10:58:20 2018 From: chrisdone at gmail.com (Christopher Done) Date: Wed, 19 Dec 2018 10:58:20 +0000 Subject: GHC (API?) question: GHC Core for Base libraries In-Reply-To: References: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> Message-ID: Here is the simplest possible way to print core in the Main.hs, by the way: https://github.com/chrisdone/prana/commit/1303c7bb385a95eef7bb4752997897455853ca72#diff-28e5b5a88ae58fa953c1ad5ab5a7bfe0 That's taking GHC 8.0's Main.hs and patching it. On Wed, 19 Dec 2018 at 10:50, Christopher Done wrote: > > Hi Bill, > > I use a different approach, using docker, and that's to use a patched > `Main.hs` (https://github.com/chrisdone/prana/commits/master/ghc-8.0/Main.hs) > and compile GHC with that patched file. It's a little unorthodox but > has so far been highly effective. > > Here is a repo of a core interpreter I've been dabbling with: > https://github.com/chrisdone/prana > > Here I have a Dockerfile that copies my edited version of `Main.hs` > and builds base, ghc-prim and integer-gmp together into an isolated > package database: > https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L56-L114 > > My Main.hs writes a .prana file for every module. At the end of the > Dockerfile, I export that to a .tar.gz archive: > https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L113 > > Then I have a set of scripts > https://github.com/chrisdone/prana/tree/master/scripts > To build the image, and one to copy the libraries to the current > directory under `libraries/`. > > Hope that's of some help! From william.hallahan at yale.edu Wed Dec 19 23:26:46 2018 From: william.hallahan at yale.edu (Bill Hallahan) Date: Wed, 19 Dec 2018 18:26:46 -0500 Subject: GHC (API?) question: GHC Core for Base libraries In-Reply-To: References: <4DA9DA91-A504-46B6-A166-0499DDA57CC2@yale.edu> Message-ID: <258042E2-8997-4358-A97E-568ADC276C6B@yale.edu> Thanks! That's an interesting approach. I hadn't considered just patching GHC. > On Dec 19, 2018, at 5:58 AM, Christopher Done wrote: > > Here is the simplest possible way to print core in the Main.hs, by the way: > > https://github.com/chrisdone/prana/commit/1303c7bb385a95eef7bb4752997897455853ca72#diff-28e5b5a88ae58fa953c1ad5ab5a7bfe0 > > That's taking GHC 8.0's Main.hs and patching it. > On Wed, 19 Dec 2018 at 10:50, Christopher Done wrote: >> >> Hi Bill, >> >> I use a different approach, using docker, and that's to use a patched >> `Main.hs` (https://github.com/chrisdone/prana/commits/master/ghc-8.0/Main.hs) >> and compile GHC with that patched file. It's a little unorthodox but >> has so far been highly effective. >> >> Here is a repo of a core interpreter I've been dabbling with: >> https://github.com/chrisdone/prana >> >> Here I have a Dockerfile that copies my edited version of `Main.hs` >> and builds base, ghc-prim and integer-gmp together into an isolated >> package database: >> https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L56-L114 >> >> My Main.hs writes a .prana file for every module. At the end of the >> Dockerfile, I export that to a .tar.gz archive: >> https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L113 >> >> Then I have a set of scripts >> https://github.com/chrisdone/prana/tree/master/scripts >> To build the image, and one to copy the libraries to the current >> directory under `libraries/`. >> >> Hope that's of some help! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From me at ara.io Thu Dec 20 15:22:57 2018 From: me at ara.io (Ara Adkins) Date: Thu, 20 Dec 2018 15:22:57 +0000 Subject: GitLab Migration Message-ID: Hey All, Sorry for my confusion, but I'm a bit unclear as to when we're meant to start working against the GHC repo on the gitlab.haskell.org instance. I had in mind that the cutover was intended to be the 18th, but going on there it still appears as if it's mirrored from git.haskell.org. Can somebody clarify this for me? Best, _ara -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Thu Dec 20 17:40:59 2018 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 20 Dec 2018 18:40:59 +0100 Subject: GitLab Migration In-Reply-To: References: Message-ID: (To: Ben added directly) Yes, https://gitlab.haskell.org/ghc/ghc still seems to mirror https://:*****@git.haskell.org/ghc, so the cutover is not complete yet. OTOH, the Gitlab instance allowed me to merge a request (which did not work yesterday), so /something/ has changed. The interesting consequence is now that https://gitlab.haskell.org/ghc/ghc fails to sync with its master. Another thing missing is to redirect the github mirror (https://github.com/ghc/ghc), too. Cheers, Gabor On 12/20/18, Ara Adkins wrote: > Hey All, > > Sorry for my confusion, but I'm a bit unclear as to when we're meant to > start working against the GHC repo on the gitlab.haskell.org instance. I > had in mind that the cutover was intended to be the 18th, but going on > there it still appears as if it's mirrored from git.haskell.org. Can > somebody clarify this for me? > > Best, > _ara > From a.pelenitsyn at gmail.com Thu Dec 20 17:46:03 2018 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Thu, 20 Dec 2018 12:46:03 -0500 Subject: References for GHC usage of multiple capabilities In-Reply-To: References: <87k1kmwtck.fsf@smart-cactus.org> Message-ID: Thank you all for the feedback again! I managed to make use of only basic papers in time. The result is here: github repo: https://github.com/ulysses4ever/CS7600-Survey-Paper current PDF: https://github.com/ulysses4ever/CS7600-Survey-Paper/releases/download/v1.0.0/CS7600__Survey_Paper.pdf -- Best, Artem On Fri, 7 Dec 2018 at 13:23 Artem Pelenitsyn wrote: > Thanks, Tom! I didn't realize that this one was merged into GHC. I wonder > if the work presented on Haskell Symposium this year about a libuv-based > I/O manager (https://dl.acm.org/citation.cfm?id=3242759) will go > somewhere… > > -- > Best, Artem > > On Fri, 7 Dec 2018 at 12:00 Tom Murphy wrote: > >> There's also "Mio: A High-Performance Multicore IO Manager for GHC" >> >> http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf >> >> On 12/7/18, Artem Pelenitsyn wrote: >> > Thanks for heads up, Ben! This is useful stuff to take into account. I >> also >> > wonder how is this list (mine ++ yours) is relevant to what GHC actually >> > has these days. But maybe that's harder to answer quickly. >> > >> > -- >> > Best wishes, >> > Artem >> > >> > >> > >> > >> > On Thu, Dec 6, 2018 at 10:47 AM Ben Gamari >> wrote: >> > >> >> Artem Pelenitsyn writes: >> >> >> >> > Hello devs, >> >> > >> >> > I've been working on a short survey devoted to a topic of >> >> > multithreading >> >> > inside the GHC compiler and runtime. So far I was mostly looking at >> the >> >> > following three papers >> >> > >> >> > [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, >> and >> >> S. >> >> > L. Peyton Jones. Gum: A portable parallel implementation of Haskell. >> >> PLDI >> >> > ’96 >> >> > >> >> > [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a >> >> > shared-memory multiprocessor. Haskell ’05 >> >> > >> >> > [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime >> support >> >> for >> >> > multicore Haskell. ICFP ’09 >> >> > >> >> > Can you suggest any other papers adding insights on how GHC uses >> >> > multiple >> >> > capabilities for anything from GC to the implementation of >> >> > Parallel/Concurrent Haskell? Perhaps, something more recent than the >> >> above, >> >> > but preferably published in academic venues. >> >> > >> >> Here are a few others but I may have missed a few: >> >> >> >> * Parallel Generational-Copying Garbage Collection with a >> >> Block-Structured Heap (Simon Marlow, Tim Harris, Roshan P. James, Simon >> >> Peyton Jones) In ISMM '08: Proceedings of the 7th international >> symposium >> >> on Memory management, Tucson, Arizona, ACM, June 2008 >> >> * Concurrent Haskell, Simon Peyton Jones, Andrew Gordon, Sigbjorn >> Finne. >> >> * Composable Memory Transactions, Tim Harris, Simon Marlow, Simon >> >> Peyton-Jones, and Maurice Herlihy. In Proceedings of the tenth ACM >> >> SIGPLAN >> >> symposium on Principles and practice of parallel programming (PPoPP >> '05) >> >> * Transactional Memory with Data Invariants, Tim Harris and Simon >> Peyton >> >> Jones. In TRANSACT '06 >> >> >> >> Cheers, >> >> >> >> - Ben >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> > >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at ara.io Thu Dec 20 17:46:28 2018 From: me at ara.io (Ara Adkins) Date: Thu, 20 Dec 2018 17:46:28 +0000 Subject: GitLab Migration In-Reply-To: References: Message-ID: <955D1666-10B8-4930-8938-402DAFF4A2E1@ara.io> How curious! Some clarification would definitely be appreciated. _ara > On 20 Dec 2018, at 17:40, Gabor Greif wrote: > > (To: Ben added directly) > > Yes, https://gitlab.haskell.org/ghc/ghc still seems to mirror > https://:*****@git.haskell.org/ghc, so the cutover is not complete > yet. > > OTOH, the Gitlab instance allowed me to merge a request (which did not > work yesterday), so /something/ has changed. The interesting > consequence is now that > https://gitlab.haskell.org/ghc/ghc fails to sync with its master. > > Another thing missing is to redirect the github mirror > (https://github.com/ghc/ghc), too. > > Cheers, > > Gabor > >> On 12/20/18, Ara Adkins wrote: >> Hey All, >> >> Sorry for my confusion, but I'm a bit unclear as to when we're meant to >> start working against the GHC repo on the gitlab.haskell.org instance. I >> had in mind that the cutover was intended to be the 18th, but going on >> there it still appears as if it's mirrored from git.haskell.org. Can >> somebody clarify this for me? >> >> Best, >> _ara >> From carter.schonwald at gmail.com Thu Dec 20 18:17:30 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 20 Dec 2018 13:17:30 -0500 Subject: How to use Data.Compact.Serialize In-Reply-To: References: Message-ID: 1) I’m not sure if anyone’s actually shared example programs where repeated executions of the same binary will fail to handle loading a compact heap in. If you can cook up a small example that runs reproducible in a way that layout is an issue due to asle, please share! 2) if aslr can actually trigger an issue, we should improve compact heaps so that this does happen! At least when the same binary is used for both reading and writing processes. On Wed, Dec 19, 2018 at 5:33 AM Christopher Done wrote: > I forgot to address the fact that libc never statically links things > like name server libraries. > > Therefore would GHC devs recommend using a musl-based build e.g. on > Alpine Linux? > > Cheers > On Wed, 19 Dec 2018 at 10:31, Christopher Done > wrote: > > > > Hi, > > > > On the docs for Data.Compact.Serialize it says: > > > > > http://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact-Serialize.html > > > Our binary representation contains direct pointers to the info tables > > > of objects in the region. This means that the info tables of the > > > receiving process must be laid out in exactly the same way as from the > > > original process; in practice, this means using static linking, using > > > the exact same binary and turning off ASLR. > > > > It seems to me that in order to use this module in any practical way > > (i.e. write to file from one process, and then a later run of the > > process reads it), you need to know a special way to build your binary > > which isn't fully described here. What flags, for example, should be > > passed to GHC to make this viable? > > > > * Turning off ASLR on Linux is done by writing 0 to > > /proc/sys/kernel/randomize_va_space, which applies to all > > programs. That's not the most isolated way to deploy an app, but I > > discovered that you can set this per process here: > > https://askubuntu.com/a/507954 > > * To compile GHC programs statically, use -optl-static -optl-pthread. > > > > So in total the example would be: > > > > $ stack build compact > > compact-0.1.0.1: download > > compact-0.1.0.1: configure > > compact-0.1.0.1: build > > compact-0.1.0.1: copy/register > > > > Example file from docs: > > > > $ cat main.hs > > {-# LANGUAGE TypeApplications #-} > > import System.Environment > > import Data.Compact > > import Data.Compact.Serialize > > main = do > > arg:_ <- getArgs > > case arg of > > "write" -> do > > orig_c <- compact ("I want to serialize this", True) > > writeCompact @(String, Bool) "somefile" orig_c > > "read" -> do > > res <- unsafeReadCompact @(String, Bool) "somefile" > > case res of > > Left err -> fail err > > Right c -> print (getCompact c) > > > > Compiling statically: > > > > $ stack ghc -- -optl-static -optl-pthread main.hs > > [1 of 1] Compiling Main ( main.hs, main.o ) > > Linking main ... > > [...hundred more warnings like this ...] > > > > Check that it's static: > > > > $ ldd main > > not a dynamic executable > > > > Write the file: > > > > $ setarch `uname -m` -R ./main write > > > > Read the file: > > > > $ setarch `uname -m` -R ./main read > > ("I want to serialize this",True) > > > > Can a GHC dev confirm that this is the proper way to do this? If so, > > I'll contribute this little example as documentation to the compact > package. > > > > Cheers > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Fri Dec 21 16:37:24 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 21 Dec 2018 16:37:24 +0000 Subject: Notifications from GitLab Message-ID: I am not receiving any emails from gitlab despite modifying the notification settings to indicate I want to be notified of all new diffs posted. Is anyone else getting notification emails? How can I debug this? Cheers, Matt From ben at smart-cactus.org Fri Dec 21 16:55:51 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 21 Dec 2018 11:55:51 -0500 Subject: GitLab Migration In-Reply-To: References: Message-ID: <87muoyq0od.fsf@smart-cactus.org> Ara Adkins writes: > Hey All, > > Sorry for my confusion, but I'm a bit unclear as to when we're meant to > start working against the GHC repo on the gitlab.haskell.org instance. I > had in mind that the cutover was intended to be the 18th, but going on > there it still appears as if it's mirrored from git.haskell.org. Can > somebody clarify this for me? > Sorry for the confusion. I have been reluctant to formally announce the cut-over until CI is green but this has taken a fair bit longer than anticipated due to the long CI cycle time. Nevertheless people have started submitting MRs against the GitLab instance and you are more than welcome to do so. As far as the official upstream repository, indeed gitlab.haskell.org/ghc/ghc is still mirroring git.haskell.org/ghc. This will change when I formally announce the switchover. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From me at ara.io Fri Dec 21 17:24:59 2018 From: me at ara.io (Ara Adkins) Date: Fri, 21 Dec 2018 17:24:59 +0000 Subject: GitLab Migration In-Reply-To: <87muoyq0od.fsf@smart-cactus.org> References: <87muoyq0od.fsf@smart-cactus.org> Message-ID: Perfect. Thanks for the clarification Ben! _ara > On 21 Dec 2018, at 16:55, Ben Gamari wrote: > > Ara Adkins writes: > >> Hey All, >> >> Sorry for my confusion, but I'm a bit unclear as to when we're meant to >> start working against the GHC repo on the gitlab.haskell.org instance. I >> had in mind that the cutover was intended to be the 18th, but going on >> there it still appears as if it's mirrored from git.haskell.org. Can >> somebody clarify this for me? >> > Sorry for the confusion. I have been reluctant to formally announce the > cut-over until CI is green but this has taken a fair bit longer than > anticipated due to the long CI cycle time. Nevertheless people have > started submitting MRs against the GitLab instance and you are more than > welcome to do so. > > As far as the official upstream repository, indeed > gitlab.haskell.org/ghc/ghc is still mirroring git.haskell.org/ghc. This > will change when I formally announce the switchover. > > Cheers, > > - Ben > From ggreif at gmail.com Fri Dec 21 19:05:08 2018 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 21 Dec 2018 20:05:08 +0100 Subject: GitLab Migration (CI heads-up) Message-ID: Hi Ben, I was wondering why my pull request (merely to trigger a bit more of CI than what I have at my local disposal) was suddenly failing (1), when it worked in a previous incarnation (2). It turns out that either CI or the entire tree is broken since (3) being the last sound one. Looks like x86-64 is affected on the linux platform only. Darwin seems to work, i386 too, and my PR (2) has been validated for PPC64le recently. So this is just a heads up that there is something fishy with github->CircleCI (at least). Cheers, Gabor (1) https://circleci.com/gh/ghc/ghc/tree/pull/242 (2) https://circleci.com/gh/ghc/ghc/tree/pull/224 (3) https://circleci.com/gh/ghc/ghc/tree/pull/239 On 12/21/18, Ben Gamari wrote: > Ara Adkins writes: > >> Hey All, >> >> Sorry for my confusion, but I'm a bit unclear as to when we're meant to >> start working against the GHC repo on the gitlab.haskell.org instance. I >> had in mind that the cutover was intended to be the 18th, but going on >> there it still appears as if it's mirrored from git.haskell.org. Can >> somebody clarify this for me? >> > Sorry for the confusion. I have been reluctant to formally announce the > cut-over until CI is green but this has taken a fair bit longer than > anticipated due to the long CI cycle time. Nevertheless people have > started submitting MRs against the GitLab instance and you are more than > welcome to do so. > > As far as the official upstream repository, indeed > gitlab.haskell.org/ghc/ghc is still mirroring git.haskell.org/ghc. This > will change when I formally announce the switchover. > > Cheers, > > - Ben > > From carter.schonwald at gmail.com Sat Dec 22 01:03:09 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 21 Dec 2018 20:03:09 -0500 Subject: Notifications from GitLab In-Reply-To: References: Message-ID: ... did they setup email? On Fri, Dec 21, 2018 at 11:38 AM Matthew Pickering < matthewtpickering at gmail.com> wrote: > I am not receiving any emails from gitlab despite modifying the > notification settings to indicate I want to be notified of all new > diffs posted. > > Is anyone else getting notification emails? How can I debug this? > > Cheers, > > Matt > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Dec 22 03:02:48 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 21 Dec 2018 22:02:48 -0500 Subject: Notifications from GitLab In-Reply-To: References: Message-ID: <87h8f6p8kr.fsf@smart-cactus.org> Matthew Pickering writes: > I am not receiving any emails from gitlab despite modifying the > notification settings to indicate I want to be notified of all new > diffs posted. > > Is anyone else getting notification emails? How can I debug this? > Whoops, I forgot to reenable it after disabling it during setup to avoid spurious email. This should now be fixed. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Sat Dec 22 04:34:22 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 21 Dec 2018 23:34:22 -0500 Subject: GitLab Migration (CI heads-up) In-Reply-To: References: Message-ID: <87d0pup4c6.fsf@smart-cactus.org> Gabor Greif writes: > Hi Ben, > Hi Gabor, > I was wondering why my pull request (merely to trigger a bit more of > CI than what I have at my local disposal) was suddenly failing (1), > when it worked in a previous incarnation (2). > > It turns out that either CI or the entire tree is broken since (3) > being the last sound one. > Indeed CircleCI recently revised their billing policies and consequently we have lost the ability to use the large instance sizes which we were previously using for our builds. Sadly GHC builds do not reliably finish on the instances we still do have access to due to memory and build time constraints. It appears that this may be the cause of the failures in your build (1). This billing change was the reason why I have been moving our CI infrastructure to GitLab. Unfortunately in the chaos it looks like I neglected to forward the ghc-devops thread describing the situation [2] to ghc-devs. Sorry for the confusion! I'm going to draft a summary email describing the state of the GitLab transition right now. Cheers, - Ben [2] https://mail.haskell.org/pipermail/ghc-devops-group/2018-December/000273.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Sat Dec 22 05:12:46 2018 From: ben at well-typed.com (Ben Gamari) Date: Sat, 22 Dec 2018 00:12:46 -0500 Subject: GitLab transition status Message-ID: <87a7kyp2k5.fsf@smart-cactus.org> Hello everyone, Over the past week we have been busily pushing ahead with the GitLab transition. While the original plan was to switch the upstream repository to the GitLab on last Tuesday, I have been too preoccupied pushing through the last mile of continuous integration stabilization to write the documentation that would make such a switch possible. Consequently, GitLab's ghc/ghc repository is still mirroring git.haskell.org. Continuous integration via GitLab pipelines is now very nearly green [1]. Once this happens I will send an email with final migration instructions and disable mirroring, signalling that the GitLab repository is the official upstream. After we migrate the upstream all code entering `master` will be merged via merge request, ensuring that no further breakage in CI. It would be greatly appreciated if those with commit rights could refrain from pushing unnecessary changes until the migration is finalized. I have had to fix a few breakages this week, each of which costs a few hours in effort and build time. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/pipelines/444 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ggreif at gmail.com Sat Dec 22 07:23:46 2018 From: ggreif at gmail.com (Gabor Greif) Date: Sat, 22 Dec 2018 08:23:46 +0100 Subject: GitLab Migration (CI heads-up) In-Reply-To: <87d0pup4c6.fsf@smart-cactus.org> References: <87d0pup4c6.fsf@smart-cactus.org> Message-ID: Hi Ben, thanks for the explanation, that indeed makes sense. I suspected some runaway optimisation, since the GHC seemed to crash on the same small set of sources. On a related note, even after rebasing to master, the linter of ghc/ghc!10 doesn't appear to kick in, blocking (and timing out) the test pipeline: https://gitlab.haskell.org/ggreif/ghc/pipelines/428 It looks like there are no "lint" runners available. Cheers and thanks, Gabor On 12/22/18, Ben Gamari wrote: > Gabor Greif writes: > >> Hi Ben, >> > Hi Gabor, > >> I was wondering why my pull request (merely to trigger a bit more of >> CI than what I have at my local disposal) was suddenly failing (1), >> when it worked in a previous incarnation (2). >> >> It turns out that either CI or the entire tree is broken since (3) >> being the last sound one. >> > Indeed CircleCI recently revised their billing policies and consequently > we have lost the ability to use the large instance sizes which we were > previously using for our builds. Sadly GHC builds do not reliably finish > on the instances we still do have access to due to memory and build time > constraints. It appears that this may be the cause of the failures in > your build (1). > > This billing change was the reason why I have been moving our CI > infrastructure to GitLab. Unfortunately in the chaos it looks like I > neglected to forward the ghc-devops thread describing the situation [2] > to ghc-devs. Sorry for the confusion! > > I'm going to draft a summary email describing the state of the GitLab > transition right now. > > Cheers, > > - Ben > > > [2] > https://mail.haskell.org/pipermail/ghc-devops-group/2018-December/000273.html > From ggreif at gmail.com Sat Dec 22 09:08:19 2018 From: ggreif at gmail.com (Gabor Greif) Date: Sat, 22 Dec 2018 10:08:19 +0100 Subject: GitLab Migration (CI heads-up) In-Reply-To: References: <87d0pup4c6.fsf@smart-cactus.org> Message-ID: (following-up own mail) This seems resolved too. I have submitted my branch into the main repo, and now the pipeline is executing :-) Still, do we want running pipelines for external contributors too? Gabor On 12/22/18, Gabor Greif wrote: > Hi Ben, > > thanks for the explanation, that indeed makes sense. I suspected some > runaway optimisation, since the GHC seemed to crash on the same small > set of sources. > > On a related note, even after rebasing to master, the linter of > ghc/ghc!10 doesn't appear to kick in, blocking (and timing out) the > test pipeline: https://gitlab.haskell.org/ggreif/ghc/pipelines/428 > > It looks like there are no "lint" runners available. > > Cheers and thanks, > > Gabor > > On 12/22/18, Ben Gamari wrote: >> Gabor Greif writes: >> >>> Hi Ben, >>> >> Hi Gabor, >> >>> I was wondering why my pull request (merely to trigger a bit more of >>> CI than what I have at my local disposal) was suddenly failing (1), >>> when it worked in a previous incarnation (2). >>> >>> It turns out that either CI or the entire tree is broken since (3) >>> being the last sound one. >>> >> Indeed CircleCI recently revised their billing policies and consequently >> we have lost the ability to use the large instance sizes which we were >> previously using for our builds. Sadly GHC builds do not reliably finish >> on the instances we still do have access to due to memory and build time >> constraints. It appears that this may be the cause of the failures in >> your build (1). >> >> This billing change was the reason why I have been moving our CI >> infrastructure to GitLab. Unfortunately in the chaos it looks like I >> neglected to forward the ghc-devops thread describing the situation [2] >> to ghc-devs. Sorry for the confusion! >> >> I'm going to draft a summary email describing the state of the GitLab >> transition right now. >> >> Cheers, >> >> - Ben >> >> >> [2] >> https://mail.haskell.org/pipermail/ghc-devops-group/2018-December/000273.html >> > From ben at well-typed.com Sat Dec 22 15:19:36 2018 From: ben at well-typed.com (Ben Gamari) Date: Sat, 22 Dec 2018 10:19:36 -0500 Subject: Linker speed on GHC Message-ID: <874lb5pp1a.fsf@smart-cactus.org> Hi Tamar, I have recently been looking quite a bit at our continuous integration due to the transition to GitLab and have found that the Windows builder is almost always the rate-limiting step. Builds routinely take three hours or more, with much of the time being spent in the bfd linker. I am working to add more builders but ultimately there is only so much that we can do with the resources we have, especially given that Windows VM instances are essentially twice the cost of their Linux counterparts due to Windows licensing fees. I know in the past you have thought about ld performance on Windows. Has there been any development on this front? Is there anything obvious we can do to improve the situation? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Sat Dec 22 15:26:34 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 22 Dec 2018 10:26:34 -0500 Subject: GitLab Migration (CI heads-up) In-Reply-To: References: <87d0pup4c6.fsf@smart-cactus.org> Message-ID: <871s69popk.fsf@smart-cactus.org> Gabor Greif writes: > (following-up own mail) > > This seems resolved too. I have submitted my branch into the main > repo, and now the pipeline is executing :-) > > Still, do we want running pipelines for external contributors too? > Indeed we do. Small oversight on my part; now fixed. Thanks! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Sat Dec 22 16:39:57 2018 From: ben at well-typed.com (Ben Gamari) Date: Sat, 22 Dec 2018 11:39:57 -0500 Subject: Linker speed on GHC In-Reply-To: <874lb5pp1a.fsf@smart-cactus.org> References: <874lb5pp1a.fsf@smart-cactus.org> Message-ID: <87tvj5o6qv.fsf@smart-cactus.org> Ben Gamari writes: > Hi Tamar, > > I have recently been looking quite a bit at our continuous integration > due to the transition to GitLab and have found that the Windows builder > is almost always the rate-limiting step. Builds routinely take three > hours or more, with much of the time being spent in the bfd linker. > > I am working to add more builders but ultimately there is only so much > that we can do with the resources we have, especially given that Windows > VM instances are essentially twice the cost of their Linux counterparts > due to Windows licensing fees. > > I know in the past you have thought about ld performance on Windows. Has > there been any development on this front? Is there anything obvious we > can do to improve the situation? > I have done a bit of investigation and it looks like GCC 9 will ship with `-fuse-ld=lld` support. Phyx, I seem to recall that you have tried LLD on Windows in the past. Do you recall how that went? Anyways, I have opened a GHC ticket to track this issue (#16084). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ggreif at gmail.com Sun Dec 23 14:29:45 2018 From: ggreif at gmail.com (Gabor Greif) Date: Sun, 23 Dec 2018 15:29:45 +0100 Subject: GitLab Migration (CI heads-up) In-Reply-To: <871s69popk.fsf@smart-cactus.org> References: <87d0pup4c6.fsf@smart-cactus.org> <871s69popk.fsf@smart-cactus.org> Message-ID: Yeah, it starts now, thanks! However it won't terminate due to a restrictive time limit of 60 mins. Can we have 120? Gabor On 12/22/18, Ben Gamari wrote: > Gabor Greif writes: > >> (following-up own mail) >> >> This seems resolved too. I have submitted my branch into the main >> repo, and now the pipeline is executing :-) >> >> Still, do we want running pipelines for external contributors too? >> > Indeed we do. Small oversight on my part; now fixed. > > Thanks! > > Cheers, > > - Ben > From matthewtpickering at gmail.com Sun Dec 23 14:47:11 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 23 Dec 2018 14:47:11 +0000 Subject: GitLab Migration (CI heads-up) In-Reply-To: References: <87d0pup4c6.fsf@smart-cactus.org> <871s69popk.fsf@smart-cactus.org> Message-ID: Gabor, you can configure this yourself. 1. Go to https://gitlab.haskell.org/ggreif/ghc/settings/ci_cd 2. Expand the top drop-down "General pipelines" 3. Set the timeout to 6h On Sun, Dec 23, 2018 at 2:30 PM Gabor Greif wrote: > > Yeah, it starts now, thanks! > > However it won't terminate due to a restrictive time limit of 60 mins. > Can we have 120? > > Gabor > > On 12/22/18, Ben Gamari wrote: > > Gabor Greif writes: > > > >> (following-up own mail) > >> > >> This seems resolved too. I have submitted my branch into the main > >> repo, and now the pipeline is executing :-) > >> > >> Still, do we want running pipelines for external contributors too? > >> > > Indeed we do. Small oversight on my part; now fixed. > > > > Thanks! > > > > Cheers, > > > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Sun Dec 23 17:06:18 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 23 Dec 2018 12:06:18 -0500 Subject: GitLab Migration (CI heads-up) In-Reply-To: References: <87d0pup4c6.fsf@smart-cactus.org> <871s69popk.fsf@smart-cactus.org> Message-ID: <87h8f4npff.fsf@smart-cactus.org> Gabor Greif writes: > Yeah, it starts now, thanks! > > However it won't terminate due to a restrictive time limit of 60 mins. > Can we have 120? > I have actually changed the default to six hours since Windows builds tend to easily eat through three hours at least. I've made this change on your fork. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From a.pelenitsyn at gmail.com Sun Dec 23 20:01:09 2018 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Sun, 23 Dec 2018 15:01:09 -0500 Subject: Current Stable Release = 8.6.2 on haskell.org Message-ID: Hello devs, I assume, the version of the current release should be bumped up to 8.6.3 here [1]? [1]: https://www.haskell.org/ghc/download.html -- Best wishes, Artem -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Dec 24 00:08:32 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 23 Dec 2018 19:08:32 -0500 Subject: Current Stable Release = 8.6.2 on haskell.org In-Reply-To: References: Message-ID: <87bm5bokg1.fsf@smart-cactus.org> Artem Pelenitsyn writes: > Hello devs, > > I assume, the version of the current release should be bumped up to 8.6.3 > here [1]? > Yes, quite right. I'll handle this soon. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From iavor.diatchki at gmail.com Mon Dec 24 00:19:41 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun, 23 Dec 2018 16:19:41 -0800 Subject: Current Stable Release = 8.6.2 on haskell.org In-Reply-To: <87bm5bokg1.fsf@smart-cactus.org> References: <87bm5bokg1.fsf@smart-cactus.org> Message-ID: Given that 8.6.3 does not work at all on Windows (seems to hang when TH is involved), we should probably not make it the current stable release. See 16071, I also just run into that and had to revert to 8.6.2. Iavor On Sun, Dec 23, 2018, 4:08 PM Ben Gamari Artem Pelenitsyn writes: > > > Hello devs, > > > > I assume, the version of the current release should be bumped up to 8.6.3 > > here [1]? > > > Yes, quite right. > > I'll handle this soon. > > Cheers, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Dec 24 22:27:14 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 24 Dec 2018 17:27:14 -0500 Subject: Current Stable Release = 8.6.2 on haskell.org In-Reply-To: References: <87bm5bokg1.fsf@smart-cactus.org> Message-ID: On December 23, 2018 7:19:41 PM EST, Iavor Diatchki wrote: >Given that 8.6.3 does not work at all on Windows (seems to hang when TH >is >involved), we should probably not make it the current stable release. >See >16071, I also just run into that and had to revert to 8.6.2. > >Iavor > >On Sun, Dec 23, 2018, 4:08 PM Ben Gamari >> Artem Pelenitsyn writes: >> >> > Hello devs, >> > >> > I assume, the version of the current release should be bumped up to >8.6.3 >> > here [1]? >> > >> Yes, quite right. >> >> I'll handle this soon. >> >> Cheers, >> >> - Ben >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> For the record, the plan here is to revert the regressing patch on ghc-8.6 and cut a small 8.6.4 release. Unfortunately this will mean that profiling will be broken for this release but this is the best we can do at the moment. I've been spent a large fraction of the last several weeks improving our CI story on Windows so future releases should have significantly better coverage on this platform. Cheers, - Ben From haskelier.artem at gmail.com Mon Dec 24 23:04:50 2018 From: haskelier.artem at gmail.com (Artem Pelenitsyn) Date: Mon, 24 Dec 2018 18:04:50 -0500 Subject: Current Stable Release = 8.6.2 on haskell.org In-Reply-To: References: <87bm5bokg1.fsf@smart-cactus.org> Message-ID: Thank you, Ben! Your job is much appreciated! -- Artem On Mon, 24 Dec 2018, 17:27 Ben Gamari, wrote: > On December 23, 2018 7:19:41 PM EST, Iavor Diatchki < > iavor.diatchki at gmail.com> wrote: > >Given that 8.6.3 does not work at all on Windows (seems to hang when TH > >is > >involved), we should probably not make it the current stable release. > >See > >16071, I also just run into that and had to revert to 8.6.2. > > > >Iavor > > > >On Sun, Dec 23, 2018, 4:08 PM Ben Gamari > > >> Artem Pelenitsyn writes: > >> > >> > Hello devs, > >> > > >> > I assume, the version of the current release should be bumped up to > >8.6.3 > >> > here [1]? > >> > > >> Yes, quite right. > >> > >> I'll handle this soon. > >> > >> Cheers, > >> > >> - Ben > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > For the record, the plan here is to revert the regressing patch on ghc-8.6 > and cut a small 8.6.4 release. Unfortunately this will mean that profiling > will be broken for this release but this is the best we can do at the > moment. > > I've been spent a large fraction of the last several weeks improving our > CI story on Windows so future releases should have significantly better > coverage on this platform. > > Cheers, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Dec 27 06:27:40 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 27 Dec 2018 01:27:40 -0500 Subject: Welcome to GitLab! Message-ID: <87a7krscvf.fsf@smart-cactus.org> TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official upstream GHC repository. Various introductory notes are discussed. Let me know if you have any trouble. Also, please do verify the correctness of the email address associated with your Trac account in the next few weeks. It will be used to map users when we transition Trac tickets to GitLab. Hello everyone, I am happy to announce that CI on GHC's GitLab instance [1] is now stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be considered the official upstream repository of GHC. The rest of this email is meant to serve as a brief introduction and status update. It can also be viewed on the GitLab Wiki [2]. [1] https://gitlab.haskell.org/ [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome # Getting started To get started on GitLab you will first want to either create a new account [1] or login with your GitHub credentials [2]. Once you have an account you should add an SSH key [3] so that you can push to your repositories. If you currently have commit rights to GHC notify me (Ben Gamari) of your user name so I can grant you similar rights in GitLab. [1] https://gitlab.haskell.org/users/sign_in [2] https://gitlab.haskell.org/users/auth/github [3] https://gitlab.haskell.org/profile/keys # Updating your development environment You can updated existing working directory (assuming the usual upstream remote name of `origin`) for the new upstream repository location by running the following: git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git git remote set-url --push origin git at gitlab.haskell.org:ghc/ghc This is all that should be necessary; a quick `git pull origin master` should verify that everything is working as expected. # Continuous integration Continuous integration is now provided by GitLab's native continuous integration infrastructure. We currently test a variety of configurations, including many that neither Phabricator nor CircleCI/Appveyor previously tested (see [1] for an example run): * With the make build system: * x86_64/Linux on Fedora 27, Debian 8, and Debian 9 * i386/Linux on Debian 9 * aarch64/Linux on Debian 9 (currently broken due to a variety of issues) * x86_64/Windows * x86_64/Darwin * x86_64/Linux on Debian 9 in a few special configurations: * unregisterised (still a bit fragile due to #16085) * integer-simple * building GHC with -fllvm * With Hadrian: * x86_64/Linux on Debian 9 * x86_64/Windows (currently broken due to #15950) We also run a slightly larger set of jobs on a nightly basis. Note that binary distributions are saved from most builds and are available for download for a few weeks (we may put in place a longer retention policy for some builds in the future). There are admittedly a few kinks that we are still working out, particularly in the case of Windows (specifically the long build times seen on Windows). If you suspect you are seeing spurious build failures do let us know. To make the best use of our limited computational resources our CI builds occur in three stages: * lint: the style and correctness checkers which would previously be run by `arc lint` and `git push` * build: Debian 9 Linux x86_64 built with make and Hadrian * full-build: the remaining configurations If a build fails at an earlier phase no further phases will be run. [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568 # Structuring your merge request With the transition to GitLab GHC is moving to a model similar to that used by GitHub. If you have a Differential on Phabricator we will finish review there. However, please post new patches as merge requests on GitLab. Note that Phabricator and GitLab have quite different models for handling patches. Under Phabricator a Differential is a single patch with no further structure; larger changes can be composed of multiple dependent Differentials. Under GitLab's model a merge request is a git branch consisting of one or more patches. Larger changes can be handled in one of two ways: a. a set of dependent merge requests, each of which to be squashed when merged. b. a single branch with each atomic change made in a single, buildable commit Due to the difficulty of maintaining dependent merge requests, I would recommend that contributors making larger changes use method (b). # Submitting your merge request for review Depending upon whether you have push rights to the GHC repository there are two ways to submit a merge request: * if you have push access you can push a branch directly to git at gitlab.haskell.org:ghc/ghc.git and open merge request. In this case please do follow the usual branch naming conventions: * prefix all branch names with `wip/` * if you are fixing a particular ticket consider using the name `wip/TNNNN` * if not you can create a fork using the "Fork" button on the project page [1] and push your branch there In either case after you have pushed your branch open a merge request against ghc/ghc [2]. [1] https://gitlab.haskell.org/ghc/ghc/forks/new [2] https://gitlab.haskell.org/ghc/ghc/merge_requests/new # Reviewing and merging merge requests As always, all contributors are encouraged to help review proposed changes. If you are unfamiliar with GitLab's review interface please see GitLab's user documentation [1]. Here are a few quick highlights for those who are familiar with GitHub but haven't yet used GitLab: * As with GitHub, GitLab supports both inline and out-of-line comments. * Comments that are actionable (known as "discussions") can be marked as resolved and collapsed. * Comments can be left on both changed and unchanged lines * Revisions of a merge request can be viewed and compared using the two drop-down menus at the top of the Changes tab * Merge requests can require approvals from particular users before considered as mergable * Merge requests can be placed in "merge when CI passes" state, which will cause merge requests to be merged as soon as they are green From this point onward all changes to GHC will be merged via GitLab's merge requests facility and must pass CI before being merged. To ensure that GHC's git history remains linear ghc/ghc will use GitLab's "fast-forward without a merge commit" merge strategy. Consequently you will be asked to rebase merge requests which are not fast-forward merges before merging (a convenient "Rebase" button will appear if the rebase can be carried out without conflicts. [1] https://gitlab.com/help/user/discussions/index.md#discussions # Status of the Trac migration Tobias will be continuing work on the Trac ticket migration after a bit of a holiday break. Hopefully by mid-January we will be able to move forward on this part of the migration; I will share more details about this as they develop. In the meantime, users of Trac should check and possibly update the email address associated with their account [1]. This address will be used to correlate Trac users with their GitLab equivalents so the correctness of this address will be important in preserving attribution information during the Trac import. [1] https://ghc.haskell.org/trac/ghc/prefs # Next steps We are actively working on cleaning up a few remaining issues with CI: * build times are still very long on Windows, despite the fact that we are only building the `quick` build flavour on that platform; consequently GitLab CI Windows builds do sometimes timeout when we are faced with long build queues. * we at times run low on disk space on our Windows builder runners, resulting in occasional spurious build failures * Appveyor builds (which are supposed to supplement the native GitLab builds) rarely seem to finish GitLab upstream has been incredibly supportive of our transition effort and has expressed interest in assisting us with issues that we encounter. Our current requests can be found on our migration effort's tracking ticket [1]. If you find any additional bugs or workflows that could be improved please do let me know and I can raise the matter with GitLab. [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039 # Acknowledgments I would like to acknowledge several parties for their contributions to this effort: * Packet.net and Google X for their generous donation of hosting for continuous integration and web hosting * GitLab and their Open Source program for many productive discussions, their generous support, and the GitLab Ultimate license used by gitlab.haskell.org. * Davean Scies for his help procuring the hosting services that power our continuous integration. * Tweag.io for their offer of help and advice * Matthew Pickering, Alp Mestangullari, Tobias Dammers for their work in setting up the new instance, sorting out the details of the migration, and debugging problems when they arose Finally, thanks to GHC's contributors for their patience during this transition; it has been a long process which has stolen a significant amount of attention from other matters. My apologies we have been a bit less responsive than usual in code review and ticket triage over the past month or two. Regardless, I am hopeful that this wait will be worthwhile. # Final thoughts This is not only a milestone for the GitLab migration but also for GHC itself. For the first time GHC has fully-automated testing, proposed patch CI, and release generation across the full range of Tier 1 configurations it supports, with passing builds in all cases. We are very excited to begin this next chapter of GHC's development and are looking forward to your feedback on how we can further improve our new infrastructure. Onward and upwards! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From alan.zimm at gmail.com Thu Dec 27 08:10:47 2018 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 27 Dec 2018 10:10:47 +0200 Subject: [GHC DevOps Group] Welcome to GitLab! In-Reply-To: <87a7krscvf.fsf@smart-cactus.org> References: <87a7krscvf.fsf@smart-cactus.org> Message-ID: Congratulations, and well done. Changing basic infrastructure is a huge and thankless job. Alan On Thu, 27 Dec 2018 at 08:27, Ben Gamari wrote: > TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official > upstream GHC repository. Various introductory notes are > discussed. Let me know if you have any trouble. > > Also, please do verify the correctness of the email address > associated with your Trac account in the next few weeks. It will > be used to map users when we transition Trac tickets to GitLab. > > > > Hello everyone, > > I am happy to announce that CI on GHC's GitLab instance [1] is now > stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be > considered the official upstream repository of GHC. > > The rest of this email is meant to serve as a brief introduction and > status update. It can also be viewed on the GitLab Wiki [2]. > > [1] https://gitlab.haskell.org/ > [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome > > > # Getting started > > To get started on GitLab you will first want to either create a new account > [1] or login with your GitHub credentials [2]. > > Once you have an account you should add an SSH key [3] so that you can push > to your repositories. If you currently have commit rights to GHC notify me > (Ben Gamari) of your user name so I can grant you similar rights in GitLab. > > > [1] https://gitlab.haskell.org/users/sign_in > [2] https://gitlab.haskell.org/users/auth/github > [3] https://gitlab.haskell.org/profile/keys > > > # Updating your development environment > > You can updated existing working directory (assuming the usual upstream > remote name of `origin`) for the new upstream repository location by > running the following: > > git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git > git remote set-url --push origin git at gitlab.haskell.org:ghc/ghc > > This is all that should be necessary; a quick `git pull origin master` > should verify that everything is working as expected. > > > # Continuous integration > > Continuous integration is now provided by GitLab's native continuous > integration infrastructure. We currently test a variety of > configurations, including many that neither Phabricator nor > CircleCI/Appveyor previously tested (see [1] for an example run): > > * With the make build system: > * x86_64/Linux on Fedora 27, Debian 8, and Debian 9 > * i386/Linux on Debian 9 > * aarch64/Linux on Debian 9 (currently broken due to a variety of > issues) > * x86_64/Windows > * x86_64/Darwin > * x86_64/Linux on Debian 9 in a few special configurations: > * unregisterised (still a bit fragile due to #16085) > * integer-simple > * building GHC with -fllvm > * With Hadrian: > * x86_64/Linux on Debian 9 > * x86_64/Windows (currently broken due to #15950) > > We also run a slightly larger set of jobs on a nightly basis. Note that > binary distributions are saved from most builds and are available for > download for a few weeks (we may put in place a longer retention policy > for some builds in the future). > > There are admittedly a few kinks that we are still working out, > particularly in the case of Windows (specifically the long build times > seen on Windows). If you suspect you are seeing spurious build failures > do let us know. > > To make the best use of our limited computational resources our CI > builds occur in three stages: > > * lint: the style and correctness checkers which would previously be > run by `arc lint` and `git push` > > * build: Debian 9 Linux x86_64 built with make and Hadrian > > * full-build: the remaining configurations > > If a build fails at an earlier phase no further phases will be run. > > > [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568 > > > # Structuring your merge request > > With the transition to GitLab GHC is moving to a model similar to that > used by GitHub. If you have a Differential on Phabricator we will finish > review there. However, please post new patches as merge requests on > GitLab. > > Note that Phabricator and GitLab have quite different models for > handling patches. Under Phabricator a Differential is a single patch > with no further structure; larger changes can be composed of multiple > dependent Differentials. > > Under GitLab's model a merge request is a git branch consisting of > one or more patches. Larger changes can be handled in one of two ways: > > a. a set of dependent merge requests, each of which to be squashed when > merged. > > b. a single branch with each atomic change made in a single, buildable > commit > > Due to the difficulty of maintaining dependent merge requests, I would > recommend that contributors making larger changes use method (b). > > > # Submitting your merge request for review > > Depending upon whether you have push rights to the GHC repository there > are two ways to submit a merge request: > > * if you have push access you can push a branch directly to > git at gitlab.haskell.org:ghc/ghc.git and open merge request. > > In this case please do follow the usual branch naming conventions: > > * prefix all branch names with `wip/` > > * if you are fixing a particular ticket consider using the name > `wip/TNNNN` > > * if not you can create a fork using the "Fork" button on the project > page [1] and push your branch there > > In either case after you have pushed your branch open a merge request > against ghc/ghc [2]. > > [1] https://gitlab.haskell.org/ghc/ghc/forks/new > [2] https://gitlab.haskell.org/ghc/ghc/merge_requests/new > > > # Reviewing and merging merge requests > > As always, all contributors are encouraged to help review proposed > changes. If you are unfamiliar with GitLab's review interface please see > GitLab's user documentation [1]. Here are a few quick highlights for > those who are familiar with GitHub but haven't yet used GitLab: > > * As with GitHub, GitLab supports both inline and out-of-line comments. > > * Comments that are actionable (known as "discussions") can be marked > as resolved and collapsed. > > * Comments can be left on both changed and unchanged lines > > * Revisions of a merge request can be viewed and compared using the > two drop-down menus at the top of the Changes tab > > * Merge requests can require approvals from particular users before > considered as mergable > > * Merge requests can be placed in "merge when CI passes" state, which > will cause merge requests to be merged as soon as they are green > > From this point onward all changes to GHC will be merged via > GitLab's merge requests facility and must pass CI before being merged. > To ensure that GHC's git history remains linear ghc/ghc will use GitLab's > "fast-forward without a merge commit" merge strategy. Consequently you > will be asked to rebase merge requests which are not fast-forward merges > before merging (a convenient "Rebase" button will appear if the rebase > can be carried out without conflicts. > > [1] https://gitlab.com/help/user/discussions/index.md#discussions > > > # Status of the Trac migration > > Tobias will be continuing work on the Trac ticket migration after a bit > of a holiday break. Hopefully by mid-January we will be able to move > forward on this part of the migration; I will share more details about > this as they develop. > > In the meantime, users of Trac should check and possibly update the > email address associated with their account [1]. This address will be > used to correlate Trac users with their GitLab equivalents so the > correctness of this address will be important in preserving attribution > information during the Trac import. > > [1] https://ghc.haskell.org/trac/ghc/prefs > > > # Next steps > > We are actively working on cleaning up a few remaining issues with CI: > > * build times are still very long on Windows, despite the fact that we > are only building the `quick` build flavour on that platform; > consequently GitLab CI Windows builds do sometimes timeout > when we are faced with long build queues. > > * we at times run low on disk space on our Windows builder runners, > resulting in occasional spurious build failures > > * Appveyor builds (which are supposed to supplement the native GitLab > builds) rarely seem to finish > > GitLab upstream has been incredibly supportive of our transition effort > and has expressed interest in assisting us with issues that we > encounter. Our current requests can be found on our migration effort's > tracking ticket [1]. If you find any additional bugs or workflows that > could be improved please do let me know and I can raise the matter with > GitLab. > > [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039 > > > # Acknowledgments > > I would like to acknowledge several parties for their contributions to > this effort: > > * Packet.net and Google X for their generous donation of hosting for > continuous integration and web hosting > > * GitLab and their Open Source program for many productive discussions, > their generous support, and the GitLab Ultimate license used by > gitlab.haskell.org. > > * Davean Scies for his help procuring the hosting services that power > our continuous integration. > > * Tweag.io for their offer of help and advice > > * Matthew Pickering, Alp Mestangullari, Tobias Dammers for their work > in setting up the new instance, sorting out the details of the > migration, and debugging problems when they arose > > Finally, thanks to GHC's contributors for their patience during this > transition; it has been a long process which has stolen a significant > amount of attention from other matters. My apologies we have been a bit > less responsive than usual in code review and ticket triage over the > past month or two. Regardless, I am hopeful that this wait will be > worthwhile. > > > # Final thoughts > > This is not only a milestone for the GitLab migration but also for GHC > itself. For the first time GHC has fully-automated testing, proposed > patch CI, and release generation across the full range of Tier 1 > configurations it supports, with passing builds in all cases. > > We are very excited to begin this next chapter of GHC's development and > are looking forward to your feedback on how we can further improve our > new infrastructure. Onward and upwards! > > Cheers, > > - Ben > _______________________________________________ > Ghc-devops-group mailing list > Ghc-devops-group at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu Dec 27 11:44:30 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 27 Dec 2018 11:44:30 +0000 Subject: Welcome to GitLab! In-Reply-To: <87a7krscvf.fsf@smart-cactus.org> References: <87a7krscvf.fsf@smart-cactus.org> Message-ID: I have a patch on phabricator which has finished review and is ready to merge. https://phabricator.haskell.org/D5458 Should I put it on Gitlab as now all patches should pass CI before being merged? Matt On Thu, Dec 27, 2018 at 6:28 AM Ben Gamari wrote: > > TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official > upstream GHC repository. Various introductory notes are > discussed. Let me know if you have any trouble. > > Also, please do verify the correctness of the email address > associated with your Trac account in the next few weeks. It will > be used to map users when we transition Trac tickets to GitLab. > > > > Hello everyone, > > I am happy to announce that CI on GHC's GitLab instance [1] is now > stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be > considered the official upstream repository of GHC. > > The rest of this email is meant to serve as a brief introduction and > status update. It can also be viewed on the GitLab Wiki [2]. > > [1] https://gitlab.haskell.org/ > [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome > > > # Getting started > > To get started on GitLab you will first want to either create a new account > [1] or login with your GitHub credentials [2]. > > Once you have an account you should add an SSH key [3] so that you can push > to your repositories. If you currently have commit rights to GHC notify me > (Ben Gamari) of your user name so I can grant you similar rights in GitLab. > > > [1] https://gitlab.haskell.org/users/sign_in > [2] https://gitlab.haskell.org/users/auth/github > [3] https://gitlab.haskell.org/profile/keys > > > # Updating your development environment > > You can updated existing working directory (assuming the usual upstream > remote name of `origin`) for the new upstream repository location by > running the following: > > git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git > git remote set-url --push origin git at gitlab.haskell.org:ghc/ghc > > This is all that should be necessary; a quick `git pull origin master` > should verify that everything is working as expected. > > > # Continuous integration > > Continuous integration is now provided by GitLab's native continuous > integration infrastructure. We currently test a variety of > configurations, including many that neither Phabricator nor > CircleCI/Appveyor previously tested (see [1] for an example run): > > * With the make build system: > * x86_64/Linux on Fedora 27, Debian 8, and Debian 9 > * i386/Linux on Debian 9 > * aarch64/Linux on Debian 9 (currently broken due to a variety of > issues) > * x86_64/Windows > * x86_64/Darwin > * x86_64/Linux on Debian 9 in a few special configurations: > * unregisterised (still a bit fragile due to #16085) > * integer-simple > * building GHC with -fllvm > * With Hadrian: > * x86_64/Linux on Debian 9 > * x86_64/Windows (currently broken due to #15950) > > We also run a slightly larger set of jobs on a nightly basis. Note that > binary distributions are saved from most builds and are available for > download for a few weeks (we may put in place a longer retention policy > for some builds in the future). > > There are admittedly a few kinks that we are still working out, > particularly in the case of Windows (specifically the long build times > seen on Windows). If you suspect you are seeing spurious build failures > do let us know. > > To make the best use of our limited computational resources our CI > builds occur in three stages: > > * lint: the style and correctness checkers which would previously be > run by `arc lint` and `git push` > > * build: Debian 9 Linux x86_64 built with make and Hadrian > > * full-build: the remaining configurations > > If a build fails at an earlier phase no further phases will be run. > > > [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568 > > > # Structuring your merge request > > With the transition to GitLab GHC is moving to a model similar to that > used by GitHub. If you have a Differential on Phabricator we will finish > review there. However, please post new patches as merge requests on > GitLab. > > Note that Phabricator and GitLab have quite different models for > handling patches. Under Phabricator a Differential is a single patch > with no further structure; larger changes can be composed of multiple > dependent Differentials. > > Under GitLab's model a merge request is a git branch consisting of > one or more patches. Larger changes can be handled in one of two ways: > > a. a set of dependent merge requests, each of which to be squashed when > merged. > > b. a single branch with each atomic change made in a single, buildable > commit > > Due to the difficulty of maintaining dependent merge requests, I would > recommend that contributors making larger changes use method (b). > > > # Submitting your merge request for review > > Depending upon whether you have push rights to the GHC repository there > are two ways to submit a merge request: > > * if you have push access you can push a branch directly to > git at gitlab.haskell.org:ghc/ghc.git and open merge request. > > In this case please do follow the usual branch naming conventions: > > * prefix all branch names with `wip/` > > * if you are fixing a particular ticket consider using the name > `wip/TNNNN` > > * if not you can create a fork using the "Fork" button on the project > page [1] and push your branch there > > In either case after you have pushed your branch open a merge request > against ghc/ghc [2]. > > [1] https://gitlab.haskell.org/ghc/ghc/forks/new > [2] https://gitlab.haskell.org/ghc/ghc/merge_requests/new > > > # Reviewing and merging merge requests > > As always, all contributors are encouraged to help review proposed > changes. If you are unfamiliar with GitLab's review interface please see > GitLab's user documentation [1]. Here are a few quick highlights for > those who are familiar with GitHub but haven't yet used GitLab: > > * As with GitHub, GitLab supports both inline and out-of-line comments. > > * Comments that are actionable (known as "discussions") can be marked > as resolved and collapsed. > > * Comments can be left on both changed and unchanged lines > > * Revisions of a merge request can be viewed and compared using the > two drop-down menus at the top of the Changes tab > > * Merge requests can require approvals from particular users before > considered as mergable > > * Merge requests can be placed in "merge when CI passes" state, which > will cause merge requests to be merged as soon as they are green > > From this point onward all changes to GHC will be merged via > GitLab's merge requests facility and must pass CI before being merged. > To ensure that GHC's git history remains linear ghc/ghc will use GitLab's > "fast-forward without a merge commit" merge strategy. Consequently you > will be asked to rebase merge requests which are not fast-forward merges > before merging (a convenient "Rebase" button will appear if the rebase > can be carried out without conflicts. > > [1] https://gitlab.com/help/user/discussions/index.md#discussions > > > # Status of the Trac migration > > Tobias will be continuing work on the Trac ticket migration after a bit > of a holiday break. Hopefully by mid-January we will be able to move > forward on this part of the migration; I will share more details about > this as they develop. > > In the meantime, users of Trac should check and possibly update the > email address associated with their account [1]. This address will be > used to correlate Trac users with their GitLab equivalents so the > correctness of this address will be important in preserving attribution > information during the Trac import. > > [1] https://ghc.haskell.org/trac/ghc/prefs > > > # Next steps > > We are actively working on cleaning up a few remaining issues with CI: > > * build times are still very long on Windows, despite the fact that we > are only building the `quick` build flavour on that platform; > consequently GitLab CI Windows builds do sometimes timeout > when we are faced with long build queues. > > * we at times run low on disk space on our Windows builder runners, > resulting in occasional spurious build failures > > * Appveyor builds (which are supposed to supplement the native GitLab > builds) rarely seem to finish > > GitLab upstream has been incredibly supportive of our transition effort > and has expressed interest in assisting us with issues that we > encounter. Our current requests can be found on our migration effort's > tracking ticket [1]. If you find any additional bugs or workflows that > could be improved please do let me know and I can raise the matter with > GitLab. > > [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039 > > > # Acknowledgments > > I would like to acknowledge several parties for their contributions to > this effort: > > * Packet.net and Google X for their generous donation of hosting for > continuous integration and web hosting > > * GitLab and their Open Source program for many productive discussions, > their generous support, and the GitLab Ultimate license used by > gitlab.haskell.org. > > * Davean Scies for his help procuring the hosting services that power > our continuous integration. > > * Tweag.io for their offer of help and advice > > * Matthew Pickering, Alp Mestangullari, Tobias Dammers for their work > in setting up the new instance, sorting out the details of the > migration, and debugging problems when they arose > > Finally, thanks to GHC's contributors for their patience during this > transition; it has been a long process which has stolen a significant > amount of attention from other matters. My apologies we have been a bit > less responsive than usual in code review and ticket triage over the > past month or two. Regardless, I am hopeful that this wait will be > worthwhile. > > > # Final thoughts > > This is not only a milestone for the GitLab migration but also for GHC > itself. For the first time GHC has fully-automated testing, proposed > patch CI, and release generation across the full range of Tier 1 > configurations it supports, with passing builds in all cases. > > We are very excited to begin this next chapter of GHC's development and > are looking forward to your feedback on how we can further improve our > new infrastructure. Onward and upwards! > > Cheers, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From matthewtpickering at gmail.com Thu Dec 27 11:56:10 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 27 Dec 2018 11:56:10 +0000 Subject: Welcome to GitLab! In-Reply-To: <87a7krscvf.fsf@smart-cactus.org> References: <87a7krscvf.fsf@smart-cactus.org> Message-ID: > To ensure that GHC's git history remains linear ghc/ghc will use GitLab's > "fast-forward without a merge commit" merge strategy. Are merge requests squashed before they are merged? It seems that the answer by default is no.. https://gitlab.com/gitlab-org/gitlab-ce/issues/27956 and the reason being that upsteam prefers "Convention over Configuration".. https://about.gitlab.com/handbook/product/#convention-over-configuration However it seems that there is a per-mr option which can be checked if you are diligent to do it for each MR. Some comments indicate that it's possible to implement a webhook to change this behaviour. Matt On Thu, Dec 27, 2018 at 6:28 AM Ben Gamari wrote: > > TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official > upstream GHC repository. Various introductory notes are > discussed. Let me know if you have any trouble. > > Also, please do verify the correctness of the email address > associated with your Trac account in the next few weeks. It will > be used to map users when we transition Trac tickets to GitLab. > > > > Hello everyone, > > I am happy to announce that CI on GHC's GitLab instance [1] is now > stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be > considered the official upstream repository of GHC. > > The rest of this email is meant to serve as a brief introduction and > status update. It can also be viewed on the GitLab Wiki [2]. > > [1] https://gitlab.haskell.org/ > [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome > > > # Getting started > > To get started on GitLab you will first want to either create a new account > [1] or login with your GitHub credentials [2]. > > Once you have an account you should add an SSH key [3] so that you can push > to your repositories. If you currently have commit rights to GHC notify me > (Ben Gamari) of your user name so I can grant you similar rights in GitLab. > > > [1] https://gitlab.haskell.org/users/sign_in > [2] https://gitlab.haskell.org/users/auth/github > [3] https://gitlab.haskell.org/profile/keys > > > # Updating your development environment > > You can updated existing working directory (assuming the usual upstream > remote name of `origin`) for the new upstream repository location by > running the following: > > git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git > git remote set-url --push origin git at gitlab.haskell.org:ghc/ghc > > This is all that should be necessary; a quick `git pull origin master` > should verify that everything is working as expected. > > > # Continuous integration > > Continuous integration is now provided by GitLab's native continuous > integration infrastructure. We currently test a variety of > configurations, including many that neither Phabricator nor > CircleCI/Appveyor previously tested (see [1] for an example run): > > * With the make build system: > * x86_64/Linux on Fedora 27, Debian 8, and Debian 9 > * i386/Linux on Debian 9 > * aarch64/Linux on Debian 9 (currently broken due to a variety of > issues) > * x86_64/Windows > * x86_64/Darwin > * x86_64/Linux on Debian 9 in a few special configurations: > * unregisterised (still a bit fragile due to #16085) > * integer-simple > * building GHC with -fllvm > * With Hadrian: > * x86_64/Linux on Debian 9 > * x86_64/Windows (currently broken due to #15950) > > We also run a slightly larger set of jobs on a nightly basis. Note that > binary distributions are saved from most builds and are available for > download for a few weeks (we may put in place a longer retention policy > for some builds in the future). > > There are admittedly a few kinks that we are still working out, > particularly in the case of Windows (specifically the long build times > seen on Windows). If you suspect you are seeing spurious build failures > do let us know. > > To make the best use of our limited computational resources our CI > builds occur in three stages: > > * lint: the style and correctness checkers which would previously be > run by `arc lint` and `git push` > > * build: Debian 9 Linux x86_64 built with make and Hadrian > > * full-build: the remaining configurations > > If a build fails at an earlier phase no further phases will be run. > > > [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568 > > > # Structuring your merge request > > With the transition to GitLab GHC is moving to a model similar to that > used by GitHub. If you have a Differential on Phabricator we will finish > review there. However, please post new patches as merge requests on > GitLab. > > Note that Phabricator and GitLab have quite different models for > handling patches. Under Phabricator a Differential is a single patch > with no further structure; larger changes can be composed of multiple > dependent Differentials. > > Under GitLab's model a merge request is a git branch consisting of > one or more patches. Larger changes can be handled in one of two ways: > > a. a set of dependent merge requests, each of which to be squashed when > merged. > > b. a single branch with each atomic change made in a single, buildable > commit > > Due to the difficulty of maintaining dependent merge requests, I would > recommend that contributors making larger changes use method (b). > > > # Submitting your merge request for review > > Depending upon whether you have push rights to the GHC repository there > are two ways to submit a merge request: > > * if you have push access you can push a branch directly to > git at gitlab.haskell.org:ghc/ghc.git and open merge request. > > In this case please do follow the usual branch naming conventions: > > * prefix all branch names with `wip/` > > * if you are fixing a particular ticket consider using the name > `wip/TNNNN` > > * if not you can create a fork using the "Fork" button on the project > page [1] and push your branch there > > In either case after you have pushed your branch open a merge request > against ghc/ghc [2]. > > [1] https://gitlab.haskell.org/ghc/ghc/forks/new > [2] https://gitlab.haskell.org/ghc/ghc/merge_requests/new > > > # Reviewing and merging merge requests > > As always, all contributors are encouraged to help review proposed > changes. If you are unfamiliar with GitLab's review interface please see > GitLab's user documentation [1]. Here are a few quick highlights for > those who are familiar with GitHub but haven't yet used GitLab: > > * As with GitHub, GitLab supports both inline and out-of-line comments. > > * Comments that are actionable (known as "discussions") can be marked > as resolved and collapsed. > > * Comments can be left on both changed and unchanged lines > > * Revisions of a merge request can be viewed and compared using the > two drop-down menus at the top of the Changes tab > > * Merge requests can require approvals from particular users before > considered as mergable > > * Merge requests can be placed in "merge when CI passes" state, which > will cause merge requests to be merged as soon as they are green > > From this point onward all changes to GHC will be merged via > GitLab's merge requests facility and must pass CI before being merged. > To ensure that GHC's git history remains linear ghc/ghc will use GitLab's > "fast-forward without a merge commit" merge strategy. Consequently you > will be asked to rebase merge requests which are not fast-forward merges > before merging (a convenient "Rebase" button will appear if the rebase > can be carried out without conflicts. > > [1] https://gitlab.com/help/user/discussions/index.md#discussions > > > # Status of the Trac migration > > Tobias will be continuing work on the Trac ticket migration after a bit > of a holiday break. Hopefully by mid-January we will be able to move > forward on this part of the migration; I will share more details about > this as they develop. > > In the meantime, users of Trac should check and possibly update the > email address associated with their account [1]. This address will be > used to correlate Trac users with their GitLab equivalents so the > correctness of this address will be important in preserving attribution > information during the Trac import. > > [1] https://ghc.haskell.org/trac/ghc/prefs > > > # Next steps > > We are actively working on cleaning up a few remaining issues with CI: > > * build times are still very long on Windows, despite the fact that we > are only building the `quick` build flavour on that platform; > consequently GitLab CI Windows builds do sometimes timeout > when we are faced with long build queues. > > * we at times run low on disk space on our Windows builder runners, > resulting in occasional spurious build failures > > * Appveyor builds (which are supposed to supplement the native GitLab > builds) rarely seem to finish > > GitLab upstream has been incredibly supportive of our transition effort > and has expressed interest in assisting us with issues that we > encounter. Our current requests can be found on our migration effort's > tracking ticket [1]. If you find any additional bugs or workflows that > could be improved please do let me know and I can raise the matter with > GitLab. > > [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039 > > > # Acknowledgments > > I would like to acknowledge several parties for their contributions to > this effort: > > * Packet.net and Google X for their generous donation of hosting for > continuous integration and web hosting > > * GitLab and their Open Source program for many productive discussions, > their generous support, and the GitLab Ultimate license used by > gitlab.haskell.org. > > * Davean Scies for his help procuring the hosting services that power > our continuous integration. > > * Tweag.io for their offer of help and advice > > * Matthew Pickering, Alp Mestangullari, Tobias Dammers for their work > in setting up the new instance, sorting out the details of the > migration, and debugging problems when they arose > > Finally, thanks to GHC's contributors for their patience during this > transition; it has been a long process which has stolen a significant > amount of attention from other matters. My apologies we have been a bit > less responsive than usual in code review and ticket triage over the > past month or two. Regardless, I am hopeful that this wait will be > worthwhile. > > > # Final thoughts > > This is not only a milestone for the GitLab migration but also for GHC > itself. For the first time GHC has fully-automated testing, proposed > patch CI, and release generation across the full range of Tier 1 > configurations it supports, with passing builds in all cases. > > We are very excited to begin this next chapter of GHC's development and > are looking forward to your feedback on how we can further improve our > new infrastructure. Onward and upwards! > > Cheers, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From me at ara.io Thu Dec 27 12:04:10 2018 From: me at ara.io (Ara Adkins) Date: Thu, 27 Dec 2018 12:04:10 +0000 Subject: Welcome to GitLab! In-Reply-To: References: <87a7krscvf.fsf@smart-cactus.org> Message-ID: Congrats to Ben and everybody involved! This has been a long time coming and I’m super excited to see what it means for GHC in the future! _ara On 27 Dec 2018, at 11:56, Matthew Pickering wrote: >> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >> "fast-forward without a merge commit" merge strategy. > > Are merge requests squashed before they are merged? > > It seems that the answer by default is no.. > https://gitlab.com/gitlab-org/gitlab-ce/issues/27956 > > and the reason being that upsteam prefers "Convention over > Configuration".. > https://about.gitlab.com/handbook/product/#convention-over-configuration > > However it seems that there is a per-mr option which can be checked if > you are diligent to do it for each MR. Some comments indicate that > it's possible to implement a webhook to change this behaviour. > > Matt > >> On Thu, Dec 27, 2018 at 6:28 AM Ben Gamari wrote: >> >> TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official >> upstream GHC repository. Various introductory notes are >> discussed. Let me know if you have any trouble. >> >> Also, please do verify the correctness of the email address >> associated with your Trac account in the next few weeks. It will >> be used to map users when we transition Trac tickets to GitLab. >> >> >> >> Hello everyone, >> >> I am happy to announce that CI on GHC's GitLab instance [1] is now >> stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be >> considered the official upstream repository of GHC. >> >> The rest of this email is meant to serve as a brief introduction and >> status update. It can also be viewed on the GitLab Wiki [2]. >> >> [1] https://gitlab.haskell.org/ >> [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome >> >> >> # Getting started >> >> To get started on GitLab you will first want to either create a new account >> [1] or login with your GitHub credentials [2]. >> >> Once you have an account you should add an SSH key [3] so that you can push >> to your repositories. If you currently have commit rights to GHC notify me >> (Ben Gamari) of your user name so I can grant you similar rights in GitLab. >> >> >> [1] https://gitlab.haskell.org/users/sign_in >> [2] https://gitlab.haskell.org/users/auth/github >> [3] https://gitlab.haskell.org/profile/keys >> >> >> # Updating your development environment >> >> You can updated existing working directory (assuming the usual upstream >> remote name of `origin`) for the new upstream repository location by >> running the following: >> >> git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git >> git remote set-url --push origin git at gitlab.haskell.org:ghc/ghc >> >> This is all that should be necessary; a quick `git pull origin master` >> should verify that everything is working as expected. >> >> >> # Continuous integration >> >> Continuous integration is now provided by GitLab's native continuous >> integration infrastructure. We currently test a variety of >> configurations, including many that neither Phabricator nor >> CircleCI/Appveyor previously tested (see [1] for an example run): >> >> * With the make build system: >> * x86_64/Linux on Fedora 27, Debian 8, and Debian 9 >> * i386/Linux on Debian 9 >> * aarch64/Linux on Debian 9 (currently broken due to a variety of >> issues) >> * x86_64/Windows >> * x86_64/Darwin >> * x86_64/Linux on Debian 9 in a few special configurations: >> * unregisterised (still a bit fragile due to #16085) >> * integer-simple >> * building GHC with -fllvm >> * With Hadrian: >> * x86_64/Linux on Debian 9 >> * x86_64/Windows (currently broken due to #15950) >> >> We also run a slightly larger set of jobs on a nightly basis. Note that >> binary distributions are saved from most builds and are available for >> download for a few weeks (we may put in place a longer retention policy >> for some builds in the future). >> >> There are admittedly a few kinks that we are still working out, >> particularly in the case of Windows (specifically the long build times >> seen on Windows). If you suspect you are seeing spurious build failures >> do let us know. >> >> To make the best use of our limited computational resources our CI >> builds occur in three stages: >> >> * lint: the style and correctness checkers which would previously be >> run by `arc lint` and `git push` >> >> * build: Debian 9 Linux x86_64 built with make and Hadrian >> >> * full-build: the remaining configurations >> >> If a build fails at an earlier phase no further phases will be run. >> >> >> [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568 >> >> >> # Structuring your merge request >> >> With the transition to GitLab GHC is moving to a model similar to that >> used by GitHub. If you have a Differential on Phabricator we will finish >> review there. However, please post new patches as merge requests on >> GitLab. >> >> Note that Phabricator and GitLab have quite different models for >> handling patches. Under Phabricator a Differential is a single patch >> with no further structure; larger changes can be composed of multiple >> dependent Differentials. >> >> Under GitLab's model a merge request is a git branch consisting of >> one or more patches. Larger changes can be handled in one of two ways: >> >> a. a set of dependent merge requests, each of which to be squashed when >> merged. >> >> b. a single branch with each atomic change made in a single, buildable >> commit >> >> Due to the difficulty of maintaining dependent merge requests, I would >> recommend that contributors making larger changes use method (b). >> >> >> # Submitting your merge request for review >> >> Depending upon whether you have push rights to the GHC repository there >> are two ways to submit a merge request: >> >> * if you have push access you can push a branch directly to >> git at gitlab.haskell.org:ghc/ghc.git and open merge request. >> >> In this case please do follow the usual branch naming conventions: >> >> * prefix all branch names with `wip/` >> >> * if you are fixing a particular ticket consider using the name >> `wip/TNNNN` >> >> * if not you can create a fork using the "Fork" button on the project >> page [1] and push your branch there >> >> In either case after you have pushed your branch open a merge request >> against ghc/ghc [2]. >> >> [1] https://gitlab.haskell.org/ghc/ghc/forks/new >> [2] https://gitlab.haskell.org/ghc/ghc/merge_requests/new >> >> >> # Reviewing and merging merge requests >> >> As always, all contributors are encouraged to help review proposed >> changes. If you are unfamiliar with GitLab's review interface please see >> GitLab's user documentation [1]. Here are a few quick highlights for >> those who are familiar with GitHub but haven't yet used GitLab: >> >> * As with GitHub, GitLab supports both inline and out-of-line comments. >> >> * Comments that are actionable (known as "discussions") can be marked >> as resolved and collapsed. >> >> * Comments can be left on both changed and unchanged lines >> >> * Revisions of a merge request can be viewed and compared using the >> two drop-down menus at the top of the Changes tab >> >> * Merge requests can require approvals from particular users before >> considered as mergable >> >> * Merge requests can be placed in "merge when CI passes" state, which >> will cause merge requests to be merged as soon as they are green >> >> From this point onward all changes to GHC will be merged via >> GitLab's merge requests facility and must pass CI before being merged. >> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >> "fast-forward without a merge commit" merge strategy. Consequently you >> will be asked to rebase merge requests which are not fast-forward merges >> before merging (a convenient "Rebase" button will appear if the rebase >> can be carried out without conflicts. >> >> [1] https://gitlab.com/help/user/discussions/index.md#discussions >> >> >> # Status of the Trac migration >> >> Tobias will be continuing work on the Trac ticket migration after a bit >> of a holiday break. Hopefully by mid-January we will be able to move >> forward on this part of the migration; I will share more details about >> this as they develop. >> >> In the meantime, users of Trac should check and possibly update the >> email address associated with their account [1]. This address will be >> used to correlate Trac users with their GitLab equivalents so the >> correctness of this address will be important in preserving attribution >> information during the Trac import. >> >> [1] https://ghc.haskell.org/trac/ghc/prefs >> >> >> # Next steps >> >> We are actively working on cleaning up a few remaining issues with CI: >> >> * build times are still very long on Windows, despite the fact that we >> are only building the `quick` build flavour on that platform; >> consequently GitLab CI Windows builds do sometimes timeout >> when we are faced with long build queues. >> >> * we at times run low on disk space on our Windows builder runners, >> resulting in occasional spurious build failures >> >> * Appveyor builds (which are supposed to supplement the native GitLab >> builds) rarely seem to finish >> >> GitLab upstream has been incredibly supportive of our transition effort >> and has expressed interest in assisting us with issues that we >> encounter. Our current requests can be found on our migration effort's >> tracking ticket [1]. If you find any additional bugs or workflows that >> could be improved please do let me know and I can raise the matter with >> GitLab. >> >> [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039 >> >> >> # Acknowledgments >> >> I would like to acknowledge several parties for their contributions to >> this effort: >> >> * Packet.net and Google X for their generous donation of hosting for >> continuous integration and web hosting >> >> * GitLab and their Open Source program for many productive discussions, >> their generous support, and the GitLab Ultimate license used by >> gitlab.haskell.org. >> >> * Davean Scies for his help procuring the hosting services that power >> our continuous integration. >> >> * Tweag.io for their offer of help and advice >> >> * Matthew Pickering, Alp Mestangullari, Tobias Dammers for their work >> in setting up the new instance, sorting out the details of the >> migration, and debugging problems when they arose >> >> Finally, thanks to GHC's contributors for their patience during this >> transition; it has been a long process which has stolen a significant >> amount of attention from other matters. My apologies we have been a bit >> less responsive than usual in code review and ticket triage over the >> past month or two. Regardless, I am hopeful that this wait will be >> worthwhile. >> >> >> # Final thoughts >> >> This is not only a milestone for the GitLab migration but also for GHC >> itself. For the first time GHC has fully-automated testing, proposed >> patch CI, and release generation across the full range of Tier 1 >> configurations it supports, with passing builds in all cases. >> >> We are very excited to begin this next chapter of GHC's development and >> are looking forward to your feedback on how we can further improve our >> new infrastructure. Onward and upwards! >> >> Cheers, >> >> - Ben >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ggreif at gmail.com Thu Dec 27 14:05:47 2018 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 27 Dec 2018 15:05:47 +0100 Subject: Welcome to GitLab! In-Reply-To: References: <87a7krscvf.fsf@smart-cactus.org> Message-ID: Great work, Ben! Thanks for all the hard work setting up this CI. My hopes are high that our contributions' quality and ease will go up. There seem to be a few loose ends that need to be wrapped up, like redirect the mirroring of https://github.com/ghc/ghc/ towards GitLab and possibly switch on mirroring for http://git.haskell.org/ghc.git . Or should we just add a redirect? Should pull requests be blocked on the former? Anyway some readmes need to be adapted for the new world order. Cheers, Gabor On 12/27/18, Ara Adkins wrote: > Congrats to Ben and everybody involved! This has been a long time coming and > I’m super excited to see what it means for GHC in the future! > > _ara > > On 27 Dec 2018, at 11:56, Matthew Pickering > wrote: > >>> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >>> "fast-forward without a merge commit" merge strategy. >> >> Are merge requests squashed before they are merged? >> >> It seems that the answer by default is no.. >> https://gitlab.com/gitlab-org/gitlab-ce/issues/27956 >> >> and the reason being that upsteam prefers "Convention over >> Configuration".. >> https://about.gitlab.com/handbook/product/#convention-over-configuration >> >> However it seems that there is a per-mr option which can be checked if >> you are diligent to do it for each MR. Some comments indicate that >> it's possible to implement a webhook to change this behaviour. >> >> Matt >> >>> On Thu, Dec 27, 2018 at 6:28 AM Ben Gamari wrote: >>> >>> TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official >>> upstream GHC repository. Various introductory notes are >>> discussed. Let me know if you have any trouble. >>> >>> Also, please do verify the correctness of the email address >>> associated with your Trac account in the next few weeks. It will >>> be used to map users when we transition Trac tickets to GitLab. >>> >>> >>> >>> Hello everyone, >>> >>> I am happy to announce that CI on GHC's GitLab instance [1] is now >>> stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be >>> considered the official upstream repository of GHC. >>> >>> The rest of this email is meant to serve as a brief introduction and >>> status update. It can also be viewed on the GitLab Wiki [2]. >>> >>> [1] https://gitlab.haskell.org/ >>> [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome >>> >>> >>> # Getting started >>> >>> To get started on GitLab you will first want to either create a new >>> account >>> [1] or login with your GitHub credentials [2]. >>> >>> Once you have an account you should add an SSH key [3] so that you can >>> push >>> to your repositories. If you currently have commit rights to GHC notify >>> me >>> (Ben Gamari) of your user name so I can grant you similar rights in >>> GitLab. >>> >>> >>> [1] https://gitlab.haskell.org/users/sign_in >>> [2] https://gitlab.haskell.org/users/auth/github >>> [3] https://gitlab.haskell.org/profile/keys >>> >>> >>> # Updating your development environment >>> >>> You can updated existing working directory (assuming the usual upstream >>> remote name of `origin`) for the new upstream repository location by >>> running the following: >>> >>> git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git >>> git remote set-url --push origin git at gitlab.haskell.org:ghc/ghc >>> >>> This is all that should be necessary; a quick `git pull origin master` >>> should verify that everything is working as expected. >>> >>> >>> # Continuous integration >>> >>> Continuous integration is now provided by GitLab's native continuous >>> integration infrastructure. We currently test a variety of >>> configurations, including many that neither Phabricator nor >>> CircleCI/Appveyor previously tested (see [1] for an example run): >>> >>> * With the make build system: >>> * x86_64/Linux on Fedora 27, Debian 8, and Debian 9 >>> * i386/Linux on Debian 9 >>> * aarch64/Linux on Debian 9 (currently broken due to a variety of >>> issues) >>> * x86_64/Windows >>> * x86_64/Darwin >>> * x86_64/Linux on Debian 9 in a few special configurations: >>> * unregisterised (still a bit fragile due to #16085) >>> * integer-simple >>> * building GHC with -fllvm >>> * With Hadrian: >>> * x86_64/Linux on Debian 9 >>> * x86_64/Windows (currently broken due to #15950) >>> >>> We also run a slightly larger set of jobs on a nightly basis. Note that >>> binary distributions are saved from most builds and are available for >>> download for a few weeks (we may put in place a longer retention policy >>> for some builds in the future). >>> >>> There are admittedly a few kinks that we are still working out, >>> particularly in the case of Windows (specifically the long build times >>> seen on Windows). If you suspect you are seeing spurious build failures >>> do let us know. >>> >>> To make the best use of our limited computational resources our CI >>> builds occur in three stages: >>> >>> * lint: the style and correctness checkers which would previously be >>> run by `arc lint` and `git push` >>> >>> * build: Debian 9 Linux x86_64 built with make and Hadrian >>> >>> * full-build: the remaining configurations >>> >>> If a build fails at an earlier phase no further phases will be run. >>> >>> >>> [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568 >>> >>> >>> # Structuring your merge request >>> >>> With the transition to GitLab GHC is moving to a model similar to that >>> used by GitHub. If you have a Differential on Phabricator we will finish >>> review there. However, please post new patches as merge requests on >>> GitLab. >>> >>> Note that Phabricator and GitLab have quite different models for >>> handling patches. Under Phabricator a Differential is a single patch >>> with no further structure; larger changes can be composed of multiple >>> dependent Differentials. >>> >>> Under GitLab's model a merge request is a git branch consisting of >>> one or more patches. Larger changes can be handled in one of two ways: >>> >>> a. a set of dependent merge requests, each of which to be squashed when >>> merged. >>> >>> b. a single branch with each atomic change made in a single, buildable >>> commit >>> >>> Due to the difficulty of maintaining dependent merge requests, I would >>> recommend that contributors making larger changes use method (b). >>> >>> >>> # Submitting your merge request for review >>> >>> Depending upon whether you have push rights to the GHC repository there >>> are two ways to submit a merge request: >>> >>> * if you have push access you can push a branch directly to >>> git at gitlab.haskell.org:ghc/ghc.git and open merge request. >>> >>> In this case please do follow the usual branch naming conventions: >>> >>> * prefix all branch names with `wip/` >>> >>> * if you are fixing a particular ticket consider using the name >>> `wip/TNNNN` >>> >>> * if not you can create a fork using the "Fork" button on the project >>> page [1] and push your branch there >>> >>> In either case after you have pushed your branch open a merge request >>> against ghc/ghc [2]. >>> >>> [1] https://gitlab.haskell.org/ghc/ghc/forks/new >>> [2] https://gitlab.haskell.org/ghc/ghc/merge_requests/new >>> >>> >>> # Reviewing and merging merge requests >>> >>> As always, all contributors are encouraged to help review proposed >>> changes. If you are unfamiliar with GitLab's review interface please see >>> GitLab's user documentation [1]. Here are a few quick highlights for >>> those who are familiar with GitHub but haven't yet used GitLab: >>> >>> * As with GitHub, GitLab supports both inline and out-of-line comments. >>> >>> * Comments that are actionable (known as "discussions") can be marked >>> as resolved and collapsed. >>> >>> * Comments can be left on both changed and unchanged lines >>> >>> * Revisions of a merge request can be viewed and compared using the >>> two drop-down menus at the top of the Changes tab >>> >>> * Merge requests can require approvals from particular users before >>> considered as mergable >>> >>> * Merge requests can be placed in "merge when CI passes" state, which >>> will cause merge requests to be merged as soon as they are green >>> >>> From this point onward all changes to GHC will be merged via >>> GitLab's merge requests facility and must pass CI before being merged. >>> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >>> "fast-forward without a merge commit" merge strategy. Consequently you >>> will be asked to rebase merge requests which are not fast-forward merges >>> before merging (a convenient "Rebase" button will appear if the rebase >>> can be carried out without conflicts. >>> >>> [1] https://gitlab.com/help/user/discussions/index.md#discussions >>> >>> >>> # Status of the Trac migration >>> >>> Tobias will be continuing work on the Trac ticket migration after a bit >>> of a holiday break. Hopefully by mid-January we will be able to move >>> forward on this part of the migration; I will share more details about >>> this as they develop. >>> >>> In the meantime, users of Trac should check and possibly update the >>> email address associated with their account [1]. This address will be >>> used to correlate Trac users with their GitLab equivalents so the >>> correctness of this address will be important in preserving attribution >>> information during the Trac import. >>> >>> [1] https://ghc.haskell.org/trac/ghc/prefs >>> >>> >>> # Next steps >>> >>> We are actively working on cleaning up a few remaining issues with CI: >>> >>> * build times are still very long on Windows, despite the fact that we >>> are only building the `quick` build flavour on that platform; >>> consequently GitLab CI Windows builds do sometimes timeout >>> when we are faced with long build queues. >>> >>> * we at times run low on disk space on our Windows builder runners, >>> resulting in occasional spurious build failures >>> >>> * Appveyor builds (which are supposed to supplement the native GitLab >>> builds) rarely seem to finish >>> >>> GitLab upstream has been incredibly supportive of our transition effort >>> and has expressed interest in assisting us with issues that we >>> encounter. Our current requests can be found on our migration effort's >>> tracking ticket [1]. If you find any additional bugs or workflows that >>> could be improved please do let me know and I can raise the matter with >>> GitLab. >>> >>> [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039 >>> >>> >>> # Acknowledgments >>> >>> I would like to acknowledge several parties for their contributions to >>> this effort: >>> >>> * Packet.net and Google X for their generous donation of hosting for >>> continuous integration and web hosting >>> >>> * GitLab and their Open Source program for many productive discussions, >>> their generous support, and the GitLab Ultimate license used by >>> gitlab.haskell.org. >>> >>> * Davean Scies for his help procuring the hosting services that power >>> our continuous integration. >>> >>> * Tweag.io for their offer of help and advice >>> >>> * Matthew Pickering, Alp Mestangullari, Tobias Dammers for their work >>> in setting up the new instance, sorting out the details of the >>> migration, and debugging problems when they arose >>> >>> Finally, thanks to GHC's contributors for their patience during this >>> transition; it has been a long process which has stolen a significant >>> amount of attention from other matters. My apologies we have been a bit >>> less responsive than usual in code review and ticket triage over the >>> past month or two. Regardless, I am hopeful that this wait will be >>> worthwhile. >>> >>> >>> # Final thoughts >>> >>> This is not only a milestone for the GitLab migration but also for GHC >>> itself. For the first time GHC has fully-automated testing, proposed >>> patch CI, and release generation across the full range of Tier 1 >>> configurations it supports, with passing builds in all cases. >>> >>> We are very excited to begin this next chapter of GHC's development and >>> are looking forward to your feedback on how we can further improve our >>> new infrastructure. Onward and upwards! >>> >>> Cheers, >>> >>> - Ben >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From me at ara.io Thu Dec 27 14:16:39 2018 From: me at ara.io (Ara Adkins) Date: Thu, 27 Dec 2018 14:16:39 +0000 Subject: Welcome to GitLab! In-Reply-To: References: <87a7krscvf.fsf@smart-cactus.org> Message-ID: <17D25AC3-B0D4-4608-BDBE-3E85554664F1@ara.io> Along the lines of things needing to be adapted, are we moving the ghc-commits mailing list over to GL? _ara > On 27 Dec 2018, at 14:05, Gabor Greif wrote: > > Great work, Ben! > > Thanks for all the hard work setting up this CI. My hopes are high > that our contributions' quality and ease will go up. > > There seem to be a few loose ends that need to be wrapped up, like > redirect the mirroring of https://github.com/ghc/ghc/ towards GitLab > and possibly switch on mirroring for http://git.haskell.org/ghc.git . > Or should we just add a redirect? Should pull requests be blocked on the former? > > Anyway some readmes need to be adapted for the new world order. > > Cheers, > > Gabor > >> On 12/27/18, Ara Adkins wrote: >> Congrats to Ben and everybody involved! This has been a long time coming and >> I’m super excited to see what it means for GHC in the future! >> >> _ara >> >> On 27 Dec 2018, at 11:56, Matthew Pickering >> wrote: >> >>>> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >>>> "fast-forward without a merge commit" merge strategy. >>> >>> Are merge requests squashed before they are merged? >>> >>> It seems that the answer by default is no.. >>> https://gitlab.com/gitlab-org/gitlab-ce/issues/27956 >>> >>> and the reason being that upsteam prefers "Convention over >>> Configuration".. >>> https://about.gitlab.com/handbook/product/#convention-over-configuration >>> >>> However it seems that there is a per-mr option which can be checked if >>> you are diligent to do it for each MR. Some comments indicate that >>> it's possible to implement a webhook to change this behaviour. >>> >>> Matt >>> >>>> On Thu, Dec 27, 2018 at 6:28 AM Ben Gamari wrote: >>>> >>>> TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official >>>> upstream GHC repository. Various introductory notes are >>>> discussed. Let me know if you have any trouble. >>>> >>>> Also, please do verify the correctness of the email address >>>> associated with your Trac account in the next few weeks. It will >>>> be used to map users when we transition Trac tickets to GitLab. >>>> >>>> >>>> >>>> Hello everyone, >>>> >>>> I am happy to announce that CI on GHC's GitLab instance [1] is now >>>> stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be >>>> considered the official upstream repository of GHC. >>>> >>>> The rest of this email is meant to serve as a brief introduction and >>>> status update. It can also be viewed on the GitLab Wiki [2]. >>>> >>>> [1] https://gitlab.haskell.org/ >>>> [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome >>>> >>>> >>>> # Getting started >>>> >>>> To get started on GitLab you will first want to either create a new >>>> account >>>> [1] or login with your GitHub credentials [2]. >>>> >>>> Once you have an account you should add an SSH key [3] so that you can >>>> push >>>> to your repositories. If you currently have commit rights to GHC notify >>>> me >>>> (Ben Gamari) of your user name so I can grant you similar rights in >>>> GitLab. >>>> >>>> >>>> [1] https://gitlab.haskell.org/users/sign_in >>>> [2] https://gitlab.haskell.org/users/auth/github >>>> [3] https://gitlab.haskell.org/profile/keys >>>> >>>> >>>> # Updating your development environment >>>> >>>> You can updated existing working directory (assuming the usual upstream >>>> remote name of `origin`) for the new upstream repository location by >>>> running the following: >>>> >>>> git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git >>>> git remote set-url --push origin git at gitlab.haskell.org:ghc/ghc >>>> >>>> This is all that should be necessary; a quick `git pull origin master` >>>> should verify that everything is working as expected. >>>> >>>> >>>> # Continuous integration >>>> >>>> Continuous integration is now provided by GitLab's native continuous >>>> integration infrastructure. We currently test a variety of >>>> configurations, including many that neither Phabricator nor >>>> CircleCI/Appveyor previously tested (see [1] for an example run): >>>> >>>> * With the make build system: >>>> * x86_64/Linux on Fedora 27, Debian 8, and Debian 9 >>>> * i386/Linux on Debian 9 >>>> * aarch64/Linux on Debian 9 (currently broken due to a variety of >>>> issues) >>>> * x86_64/Windows >>>> * x86_64/Darwin >>>> * x86_64/Linux on Debian 9 in a few special configurations: >>>> * unregisterised (still a bit fragile due to #16085) >>>> * integer-simple >>>> * building GHC with -fllvm >>>> * With Hadrian: >>>> * x86_64/Linux on Debian 9 >>>> * x86_64/Windows (currently broken due to #15950) >>>> >>>> We also run a slightly larger set of jobs on a nightly basis. Note that >>>> binary distributions are saved from most builds and are available for >>>> download for a few weeks (we may put in place a longer retention policy >>>> for some builds in the future). >>>> >>>> There are admittedly a few kinks that we are still working out, >>>> particularly in the case of Windows (specifically the long build times >>>> seen on Windows). If you suspect you are seeing spurious build failures >>>> do let us know. >>>> >>>> To make the best use of our limited computational resources our CI >>>> builds occur in three stages: >>>> >>>> * lint: the style and correctness checkers which would previously be >>>> run by `arc lint` and `git push` >>>> >>>> * build: Debian 9 Linux x86_64 built with make and Hadrian >>>> >>>> * full-build: the remaining configurations >>>> >>>> If a build fails at an earlier phase no further phases will be run. >>>> >>>> >>>> [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568 >>>> >>>> >>>> # Structuring your merge request >>>> >>>> With the transition to GitLab GHC is moving to a model similar to that >>>> used by GitHub. If you have a Differential on Phabricator we will finish >>>> review there. However, please post new patches as merge requests on >>>> GitLab. >>>> >>>> Note that Phabricator and GitLab have quite different models for >>>> handling patches. Under Phabricator a Differential is a single patch >>>> with no further structure; larger changes can be composed of multiple >>>> dependent Differentials. >>>> >>>> Under GitLab's model a merge request is a git branch consisting of >>>> one or more patches. Larger changes can be handled in one of two ways: >>>> >>>> a. a set of dependent merge requests, each of which to be squashed when >>>> merged. >>>> >>>> b. a single branch with each atomic change made in a single, buildable >>>> commit >>>> >>>> Due to the difficulty of maintaining dependent merge requests, I would >>>> recommend that contributors making larger changes use method (b). >>>> >>>> >>>> # Submitting your merge request for review >>>> >>>> Depending upon whether you have push rights to the GHC repository there >>>> are two ways to submit a merge request: >>>> >>>> * if you have push access you can push a branch directly to >>>> git at gitlab.haskell.org:ghc/ghc.git and open merge request. >>>> >>>> In this case please do follow the usual branch naming conventions: >>>> >>>> * prefix all branch names with `wip/` >>>> >>>> * if you are fixing a particular ticket consider using the name >>>> `wip/TNNNN` >>>> >>>> * if not you can create a fork using the "Fork" button on the project >>>> page [1] and push your branch there >>>> >>>> In either case after you have pushed your branch open a merge request >>>> against ghc/ghc [2]. >>>> >>>> [1] https://gitlab.haskell.org/ghc/ghc/forks/new >>>> [2] https://gitlab.haskell.org/ghc/ghc/merge_requests/new >>>> >>>> >>>> # Reviewing and merging merge requests >>>> >>>> As always, all contributors are encouraged to help review proposed >>>> changes. If you are unfamiliar with GitLab's review interface please see >>>> GitLab's user documentation [1]. Here are a few quick highlights for >>>> those who are familiar with GitHub but haven't yet used GitLab: >>>> >>>> * As with GitHub, GitLab supports both inline and out-of-line comments. >>>> >>>> * Comments that are actionable (known as "discussions") can be marked >>>> as resolved and collapsed. >>>> >>>> * Comments can be left on both changed and unchanged lines >>>> >>>> * Revisions of a merge request can be viewed and compared using the >>>> two drop-down menus at the top of the Changes tab >>>> >>>> * Merge requests can require approvals from particular users before >>>> considered as mergable >>>> >>>> * Merge requests can be placed in "merge when CI passes" state, which >>>> will cause merge requests to be merged as soon as they are green >>>> >>>> From this point onward all changes to GHC will be merged via >>>> GitLab's merge requests facility and must pass CI before being merged. >>>> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >>>> "fast-forward without a merge commit" merge strategy. Consequently you >>>> will be asked to rebase merge requests which are not fast-forward merges >>>> before merging (a convenient "Rebase" button will appear if the rebase >>>> can be carried out without conflicts. >>>> >>>> [1] https://gitlab.com/help/user/discussions/index.md#discussions >>>> >>>> >>>> # Status of the Trac migration >>>> >>>> Tobias will be continuing work on the Trac ticket migration after a bit >>>> of a holiday break. Hopefully by mid-January we will be able to move >>>> forward on this part of the migration; I will share more details about >>>> this as they develop. >>>> >>>> In the meantime, users of Trac should check and possibly update the >>>> email address associated with their account [1]. This address will be >>>> used to correlate Trac users with their GitLab equivalents so the >>>> correctness of this address will be important in preserving attribution >>>> information during the Trac import. >>>> >>>> [1] https://ghc.haskell.org/trac/ghc/prefs >>>> >>>> >>>> # Next steps >>>> >>>> We are actively working on cleaning up a few remaining issues with CI: >>>> >>>> * build times are still very long on Windows, despite the fact that we >>>> are only building the `quick` build flavour on that platform; >>>> consequently GitLab CI Windows builds do sometimes timeout >>>> when we are faced with long build queues. >>>> >>>> * we at times run low on disk space on our Windows builder runners, >>>> resulting in occasional spurious build failures >>>> >>>> * Appveyor builds (which are supposed to supplement the native GitLab >>>> builds) rarely seem to finish >>>> >>>> GitLab upstream has been incredibly supportive of our transition effort >>>> and has expressed interest in assisting us with issues that we >>>> encounter. Our current requests can be found on our migration effort's >>>> tracking ticket [1]. If you find any additional bugs or workflows that >>>> could be improved please do let me know and I can raise the matter with >>>> GitLab. >>>> >>>> [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039 >>>> >>>> >>>> # Acknowledgments >>>> >>>> I would like to acknowledge several parties for their contributions to >>>> this effort: >>>> >>>> * Packet.net and Google X for their generous donation of hosting for >>>> continuous integration and web hosting >>>> >>>> * GitLab and their Open Source program for many productive discussions, >>>> their generous support, and the GitLab Ultimate license used by >>>> gitlab.haskell.org. >>>> >>>> * Davean Scies for his help procuring the hosting services that power >>>> our continuous integration. >>>> >>>> * Tweag.io for their offer of help and advice >>>> >>>> * Matthew Pickering, Alp Mestangullari, Tobias Dammers for their work >>>> in setting up the new instance, sorting out the details of the >>>> migration, and debugging problems when they arose >>>> >>>> Finally, thanks to GHC's contributors for their patience during this >>>> transition; it has been a long process which has stolen a significant >>>> amount of attention from other matters. My apologies we have been a bit >>>> less responsive than usual in code review and ticket triage over the >>>> past month or two. Regardless, I am hopeful that this wait will be >>>> worthwhile. >>>> >>>> >>>> # Final thoughts >>>> >>>> This is not only a milestone for the GitLab migration but also for GHC >>>> itself. For the first time GHC has fully-automated testing, proposed >>>> patch CI, and release generation across the full range of Tier 1 >>>> configurations it supports, with passing builds in all cases. >>>> >>>> We are very excited to begin this next chapter of GHC's development and >>>> are looking forward to your feedback on how we can further improve our >>>> new infrastructure. Onward and upwards! >>>> >>>> Cheers, >>>> >>>> - Ben >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Thu Dec 27 15:11:09 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 27 Dec 2018 10:11:09 -0500 Subject: Welcome to GitLab! In-Reply-To: References: <87a7krscvf.fsf@smart-cactus.org> Message-ID: <871s63roms.fsf@smart-cactus.org> Matthew Pickering writes: >> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >> "fast-forward without a merge commit" merge strategy. > > Are merge requests squashed before they are merged? > > It seems that the answer by default is no.. > https://gitlab.com/gitlab-org/gitlab-ce/issues/27956 > Indeed there are not. Moreover, in the workflow that I suggest in the email not squashing is the desired behavior since each commit is atomic. > and the reason being that upsteam prefers "Convention over > Configuration".. > https://about.gitlab.com/handbook/product/#convention-over-configuration > > However it seems that there is a per-mr option which can be checked if > you are diligent to do it for each MR. Some comments indicate that > it's possible to implement a webhook to change this behaviour. > I'm not sure there is a reasonable default here; not matter what you choose it will be wrong a good fraction of the time. The current plan is to just ensure that the person who merges an MR considers whether the history it introduces is useful and choose the correct option. I believe this should work fine although I'm happy to reconsider if not. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From matthewtpickering at gmail.com Thu Dec 27 15:29:46 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 27 Dec 2018 15:29:46 +0000 Subject: Welcome to GitLab! In-Reply-To: <871s63roms.fsf@smart-cactus.org> References: <87a7krscvf.fsf@smart-cactus.org> <871s63roms.fsf@smart-cactus.org> Message-ID: Does this mean that the commit message doesn't come from the MR description? If I want to edit the commit message for a description I need to 1. squash the changes locally 2. force push the branch 3. Wait for CI to finish building (even though I just changed the commit message). Matt On Thu, Dec 27, 2018 at 3:11 PM Ben Gamari wrote: > > Matthew Pickering writes: > > >> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's > >> "fast-forward without a merge commit" merge strategy. > > > > Are merge requests squashed before they are merged? > > > > It seems that the answer by default is no.. > > https://gitlab.com/gitlab-org/gitlab-ce/issues/27956 > > > Indeed there are not. Moreover, in the workflow that I suggest in the > email not squashing is the desired behavior since each commit is atomic. > > > and the reason being that upsteam prefers "Convention over > > Configuration".. > > https://about.gitlab.com/handbook/product/#convention-over-configuration > > > > However it seems that there is a per-mr option which can be checked if > > you are diligent to do it for each MR. Some comments indicate that > > it's possible to implement a webhook to change this behaviour. > > > I'm not sure there is a reasonable default here; not matter what you > choose it will be wrong a good fraction of the time. The current plan is > to just ensure that the person who merges an MR considers whether the > history it introduces is useful and choose the correct option. I believe > this should work fine although I'm happy to reconsider if not. > > Cheers, > > - Ben > From me at ara.io Thu Dec 27 15:50:37 2018 From: me at ara.io (Ara Adkins) Date: Thu, 27 Dec 2018 15:50:37 +0000 Subject: Welcome to GitLab! In-Reply-To: <874lazrotu.fsf@smart-cactus.org> References: <87a7krscvf.fsf@smart-cactus.org> <17D25AC3-B0D4-4608-BDBE-3E85554664F1@ara.io> <874lazrotu.fsf@smart-cactus.org> Message-ID: <0B1ABD62-61CA-4A5A-A964-6D004F9D2690@ara.io> Thanks ben! Great to know. CC the list in case anyone else was interested. _ara > On 27 Dec 2018, at 15:06, Ben Gamari wrote: > > Ara Adkins writes: > >> Along the lines of things needing to be adapted, are we moving the >> ghc-commits mailing list over to GL? >> > Yes, although I haven't quite worked out how best to do that yet. In the > meantime I have inverted the mirroring relationship between > git.haskell.org and gitlab.haskell.org such that the old commit > notification continue to fire. > > Cheers, > > - Ben > From ben at well-typed.com Thu Dec 27 16:18:00 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 27 Dec 2018 11:18:00 -0500 Subject: Welcome to GitLab! In-Reply-To: References: <87a7krscvf.fsf@smart-cactus.org> <871s63roms.fsf@smart-cactus.org> Message-ID: <87wonvq6z7.fsf@smart-cactus.org> Matthew Pickering writes: > Does this mean that the commit message doesn't come from the MR description? > Correct. Like GitHub, the commit messages that make it into the version control history are precisely the commit messages of the commits in your branch. > If I want to edit the commit message for a description I need to > > 1. squash the changes locally > 2. force push the branch > 3. Wait for CI to finish building (even though I just changed the > commit message). > This would be a great time to use the "Merge when CI passes" feature. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From a.pelenitsyn at gmail.com Fri Dec 28 07:05:56 2018 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Fri, 28 Dec 2018 10:05:56 +0300 Subject: Current Stable Release = 8.6.2 on haskell.org In-Reply-To: References: <87bm5bokg1.fsf@smart-cactus.org> Message-ID: Also, https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html still points to 8.6.2 -- Best, Artem On Tue, 25 Dec 2018 at 02:05 Artem Pelenitsyn wrote: > Thank you, Ben! Your job is much appreciated! > > -- Artem > > On Mon, 24 Dec 2018, 17:27 Ben Gamari, wrote: > >> On December 23, 2018 7:19:41 PM EST, Iavor Diatchki < >> iavor.diatchki at gmail.com> wrote: >> >Given that 8.6.3 does not work at all on Windows (seems to hang when TH >> >is >> >involved), we should probably not make it the current stable release. >> >See >> >16071, I also just run into that and had to revert to 8.6.2. >> > >> >Iavor >> > >> >On Sun, Dec 23, 2018, 4:08 PM Ben Gamari > > >> >> Artem Pelenitsyn writes: >> >> >> >> > Hello devs, >> >> > >> >> > I assume, the version of the current release should be bumped up to >> >8.6.3 >> >> > here [1]? >> >> > >> >> Yes, quite right. >> >> >> >> I'll handle this soon. >> >> >> >> Cheers, >> >> >> >> - Ben >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> >> For the record, the plan here is to revert the regressing patch on >> ghc-8.6 and cut a small 8.6.4 release. Unfortunately this will mean that >> profiling will be broken for this release but this is the best we can do at >> the moment. >> >> I've been spent a large fraction of the last several weeks improving our >> CI story on Windows so future releases should have significantly better >> coverage on this platform. > > >> >> Cheers, >> >> - Ben >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at ara.io Fri Dec 28 18:04:18 2018 From: me at ara.io (Ara Adkins) Date: Fri, 28 Dec 2018 18:04:18 +0000 Subject: The Trac Wiki and the GitLab Migration Message-ID: <257D0ED5-2307-4178-ACB8-37301F1FC5C3@ara.io> Hey All, I’ve been doing a decent amount of thinking about the GitLab migration and realised that I’d not seen any discussion of what we plan to do with all the information in the Trac Wiki. If there has been some and I’ve missed it I apologise. In essence, I’m wondering what the current plan is! Will we leave it in place, or so we plan to move the content to a wiki on GitLab? Best. _ara From allbery.b at gmail.com Fri Dec 28 18:47:08 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 28 Dec 2018 13:47:08 -0500 Subject: The Trac Wiki and the GitLab Migration In-Reply-To: <257D0ED5-2307-4178-ACB8-37301F1FC5C3@ara.io> References: <257D0ED5-2307-4178-ACB8-37301F1FC5C3@ara.io> Message-ID: The original announcement said wiki migration still has a few hitches to be ironed out, but is generally looking good. On Fri, Dec 28, 2018 at 1:04 PM Ara Adkins wrote: > Hey All, > > I’ve been doing a decent amount of thinking about the GitLab migration and > realised that I’d not seen any discussion of what we plan to do with all > the information in the Trac Wiki. If there has been some and I’ve missed it > I apologise. > > In essence, I’m wondering what the current plan is! Will we leave it in > place, or so we plan to move the content to a wiki on GitLab? > > Best. > _ara > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Dec 28 20:13:02 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 28 Dec 2018 15:13:02 -0500 Subject: The Trac Wiki and the GitLab Migration In-Reply-To: <257D0ED5-2307-4178-ACB8-37301F1FC5C3@ara.io> References: <257D0ED5-2307-4178-ACB8-37301F1FC5C3@ara.io> Message-ID: <87d0plquk6.fsf@smart-cactus.org> Ara Adkins writes: > Hey All, > > I’ve been doing a decent amount of thinking about the GitLab migration > and realised that I’d not seen any discussion of what we plan to do > with all the information in the Trac Wiki. If there has been some and > I’ve missed it I apologise. > > In essence, I’m wondering what the current plan is! Will we leave it > in place, or so we plan to move the content to a wiki on GitLab? > The wiki content will also be moved to GitLab. However, the content in the Wiki tends to use significantly richer markup which has posed trouble for the markup conversion. The conversion will almost certainly require a bit of manual cleanup; we are currently trying to workout the right compromise between manual post-processing and fixing the Trac parser. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From me at ara.io Sat Dec 29 01:01:45 2018 From: me at ara.io (Ara Adkins) Date: Sat, 29 Dec 2018 01:01:45 +0000 Subject: The Trac Wiki and the GitLab Migration In-Reply-To: <87d0plquk6.fsf@smart-cactus.org> References: <257D0ED5-2307-4178-ACB8-37301F1FC5C3@ara.io> <87d0plquk6.fsf@smart-cactus.org> Message-ID: Brilliant. Thanks Ben and Brandon for the quick responses. Ben, if there’s any way I can help wit that migration, even to the point of manual cleanup, do let me know! _ara > On 28 Dec 2018, at 20:13, Ben Gamari wrote: > > Ara Adkins writes: > >> Hey All, >> >> I’ve been doing a decent amount of thinking about the GitLab migration >> and realised that I’d not seen any discussion of what we plan to do >> with all the information in the Trac Wiki. If there has been some and >> I’ve missed it I apologise. >> >> In essence, I’m wondering what the current plan is! Will we leave it >> in place, or so we plan to move the content to a wiki on GitLab? >> > The wiki content will also be moved to GitLab. However, the > content in the Wiki tends to use significantly richer markup which has > posed trouble for the markup conversion. The conversion will almost > certainly require a bit of manual cleanup; we are currently trying to > workout the right compromise between manual post-processing and fixing > the Trac parser. > > Cheers, > > - Ben From djsamperi at gmail.com Sat Dec 29 18:49:41 2018 From: djsamperi at gmail.com (Dominick Samperi) Date: Sat, 29 Dec 2018 13:49:41 -0500 Subject: Type family equation violates injectivity? Message-ID: When I use v8.6.3 of GHC under Ubuntu to install the inline-r package I get the error "Type family equation violates injectivity annotation," and a type variable on the LHS cannot be inferred from the RHS, due to the lack of injectivity (I suppose). On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under Ubuntu) does not have this problem (it has other problems). Has something changed in the latest version of the compiler that might cause this? Possible work-around? FYI, the line that triggers the error is: type instance G.Mutable (W t ty s) = Mutable.W t ty The variable that cannot be inferred is 's'. Thanks, Dominick From carter.schonwald at gmail.com Sat Dec 29 23:16:27 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 29 Dec 2018 18:16:27 -0500 Subject: Type family equation violates injectivity? In-Reply-To: References: Message-ID: were you using the same version of vector in both setups? in the most recent vector release we made mutable type family injective in the vector package for ghc's that support it ... On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi wrote: > When I use v8.6.3 of GHC under Ubuntu to install the inline-r package > I get the error "Type family equation violates injectivity annotation," and > a type variable on the LHS cannot be inferred from the RHS, due to > the lack of injectivity (I suppose). > > On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under > Ubuntu) does not have this problem (it has other problems). > > Has something changed in the latest version of the compiler that might > cause this? Possible work-around? > > FYI, the line that triggers the error is: > type instance G.Mutable (W t ty s) = Mutable.W t ty > > The variable that cannot be inferred is 's'. > > Thanks, > Dominick > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Dec 29 23:48:53 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 29 Dec 2018 18:48:53 -0500 Subject: Type family equation violates injectivity? In-Reply-To: References: Message-ID: so i took a look .. (also the inline-r devs seem to have done a hackage revision so you wont hit that issue in your current setup if you do a cabal update ..) and it seems like the type definitions in inline-r are kinda bogus and you should get them patched ... the MVector type class, and related type families, all assume your mutable type has the last two arguments as the io/state token and then the element type eg basicLength :: v s a -> Int i looked at https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374 and as a point of grounding this chat the injective type familly in question is defined by the follwoing --#if MIN_VERSION_base(4,9,0)type family Mutable (v :: * -> *) = (mv :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * -> *#endif anyways, it looks like the Pure / immutable vector data type in inline-r has a spurious state token argument in its definition that shouldn't be there, OR there need to be two "s" params in inline-r instead of the one heres the full code i linked to in question -- | Mutable R vector. Represented in memory with the same header as 'SEXP' -- nodes. The second type parameter is phantom, reflecting at the type level the -- tag of the vector when viewed as a 'SEXP'. The tag of the vector and the -- representation type are related via 'ElemRep'. data MVector s ty a = MVector { mvectorBase :: {-# UNPACK #-} !(SEXP s ty) , mvectorOffset :: {-# UNPACK #-} !Int32 , mvectorLength :: {-# UNPACK #-} !Int32 } -- | Internal wrapper type for reflection. First type parameter is the reified -- type to reflect. newtype W t ty s a = W { unW :: MVector s ty a } instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t ty) a where data Vector s (ty :: SEXPTYPE) a = Vector { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset :: {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32 } type instance G.Mutable (W t ty s) = Mutable.W t ty Anyways, the fix here is to remove the s param from the Pure version of W and "Sexp Vector" On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald wrote: > were you using the same version of vector in both setups? > > in the most recent vector release we made mutable type family injective > in the vector package for ghc's that support it ... > > On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi > wrote: > >> When I use v8.6.3 of GHC under Ubuntu to install the inline-r package >> I get the error "Type family equation violates injectivity annotation," >> and >> a type variable on the LHS cannot be inferred from the RHS, due to >> the lack of injectivity (I suppose). >> >> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under >> Ubuntu) does not have this problem (it has other problems). >> >> Has something changed in the latest version of the compiler that might >> cause this? Possible work-around? >> >> FYI, the line that triggers the error is: >> type instance G.Mutable (W t ty s) = Mutable.W t ty >> >> The variable that cannot be inferred is 's'. >> >> Thanks, >> Dominick >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Dec 30 00:06:04 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 29 Dec 2018 19:06:04 -0500 Subject: Type family equation violates injectivity? In-Reply-To: References: Message-ID: To be clear : I’m annoyed with myself that this impacted a package that depends on vector, but this does seem to be the case that the newest bug fix release for vector actually revealed a broken design for the vector instances / data types in the inline-r package. To;dr — I suggest patching inline-r to remove the s parameter in its immutable vector data types On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald wrote: > so i took a look .. (also the inline-r devs seem to have done a hackage > revision so you wont hit that issue in your current setup if you do a cabal > update ..) > and it seems like the type definitions in inline-r are kinda bogus and > you should get them patched ... > > the MVector type class, and related type families, all assume your mutable > type has the last two arguments as the io/state token and then the element > type > > eg > basicLength :: v s a -> Int > > > > i looked at > https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374 > and > > > > as a point of grounding this chat > the injective type familly in question is defined by the follwoing > > > --#if MIN_VERSION_base(4,9,0)type family Mutable (v :: * -> *) = (mv :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * -> *#endif > > anyways, it looks like the Pure / immutable vector data type in inline-r > has a spurious state token argument in its definition that shouldn't be > there, OR there need to be two "s" params in inline-r instead of the one > > heres the full code i linked to in question > > > -- | Mutable R vector. Represented in memory with the same header as > 'SEXP' > > -- nodes. The second type parameter is phantom, reflecting at the type > level the > -- tag of the vector when viewed as a 'SEXP'. The tag of the vector and the > -- representation type are related via 'ElemRep'. > data MVector s ty a = MVector > { mvectorBase :: {-# UNPACK #-} !(SEXP s ty) > , mvectorOffset :: {-# UNPACK #-} !Int32 > , mvectorLength :: {-# UNPACK #-} !Int32 > } > -- | Internal wrapper type for reflection. First type parameter is the > reified > -- type to reflect. > newtype W t ty s a = W { unW :: MVector s ty a } > instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t ty) a > where > > data Vector s (ty :: SEXPTYPE) a = Vector > { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset :: {-# > UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32 > } > > > type instance G.Mutable (W t ty s) = Mutable.W t ty > Anyways, the fix here is to remove the s param from the Pure version of W > and "Sexp Vector" > > > > On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> were you using the same version of vector in both setups? >> >> in the most recent vector release we made mutable type family injective >> in the vector package for ghc's that support it ... >> >> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi >> wrote: >> >>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r package >>> I get the error "Type family equation violates injectivity annotation," >>> and >>> a type variable on the LHS cannot be inferred from the RHS, due to >>> the lack of injectivity (I suppose). >>> >>> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under >>> Ubuntu) does not have this problem (it has other problems). >>> >>> Has something changed in the latest version of the compiler that might >>> cause this? Possible work-around? >>> >>> FYI, the line that triggers the error is: >>> type instance G.Mutable (W t ty s) = Mutable.W t ty >>> >>> The variable that cannot be inferred is 's'. >>> >>> Thanks, >>> Dominick >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Dec 30 00:44:40 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 29 Dec 2018 19:44:40 -0500 Subject: Type family equation violates injectivity? In-Reply-To: References: Message-ID: i did some digging to see if theres a simple fix ... but then i realized that the current design they have for inlineR always assumes theres IO available in pure computations ... which they use the s parameter to thread into the pure vector code via reflection tricks so it looks like the "right" way fix this would be to have the MVector data type have both the state token for the the underlying resource AND whatever PrimMonad its running in, rather than smashing them together... especially since the ST monad and friend wont wont have the same state token as the underlying IO resource either way, what seems to be going on is that theres a mutex on which computations talk with the R RTS/instance the haskell code talks to, and theres a little bit of a mismatch in how they handle that .. either way, its not a ghc issue, its a design issue around vector and the api contract as the maintainers understand it vs how the package uses it. (though i repeat: i do think theres an issue in how they factor thestate token stuff ) On Sat, Dec 29, 2018 at 7:06 PM Carter Schonwald wrote: > To be clear : I’m annoyed with myself that this impacted a package that > depends on vector, but this does seem to be the case that the newest bug > fix release for vector actually revealed a broken design for the vector > instances / data types in the inline-r package. > > To;dr — I suggest patching inline-r to remove the s parameter in its > immutable vector data types > > On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> so i took a look .. (also the inline-r devs seem to have done a hackage >> revision so you wont hit that issue in your current setup if you do a cabal >> update ..) >> and it seems like the type definitions in inline-r are kinda bogus and >> you should get them patched ... >> >> the MVector type class, and related type families, all assume your >> mutable type has the last two arguments as the io/state token and then the >> element type >> >> eg >> basicLength :: v s a -> Int >> >> >> >> i looked at >> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374 >> and >> >> >> >> as a point of grounding this chat >> the injective type familly in question is defined by the follwoing >> >> >> --#if MIN_VERSION_base(4,9,0)type family Mutable (v :: * -> *) = (mv :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * -> *#endif >> >> anyways, it looks like the Pure / immutable vector data type in inline-r >> has a spurious state token argument in its definition that shouldn't be >> there, OR there need to be two "s" params in inline-r instead of the one >> >> heres the full code i linked to in question >> >> >> -- | Mutable R vector. Represented in memory with the same header as >> 'SEXP' >> >> -- nodes. The second type parameter is phantom, reflecting at the type >> level the >> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector and >> the >> -- representation type are related via 'ElemRep'. >> data MVector s ty a = MVector >> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty) >> , mvectorOffset :: {-# UNPACK #-} !Int32 >> , mvectorLength :: {-# UNPACK #-} !Int32 >> } >> -- | Internal wrapper type for reflection. First type parameter is the >> reified >> -- type to reflect. >> newtype W t ty s a = W { unW :: MVector s ty a } >> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t ty) a >> where >> >> data Vector s (ty :: SEXPTYPE) a = Vector >> { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset :: >> {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32 >> } >> >> >> type instance G.Mutable (W t ty s) = Mutable.W t ty >> Anyways, the fix here is to remove the s param from the Pure version of W >> and "Sexp Vector" >> >> >> >> On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> were you using the same version of vector in both setups? >>> >>> in the most recent vector release we made mutable type family >>> injective in the vector package for ghc's that support it ... >>> >>> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi >>> wrote: >>> >>>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r package >>>> I get the error "Type family equation violates injectivity annotation," >>>> and >>>> a type variable on the LHS cannot be inferred from the RHS, due to >>>> the lack of injectivity (I suppose). >>>> >>>> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under >>>> Ubuntu) does not have this problem (it has other problems). >>>> >>>> Has something changed in the latest version of the compiler that might >>>> cause this? Possible work-around? >>>> >>>> FYI, the line that triggers the error is: >>>> type instance G.Mutable (W t ty s) = Mutable.W t ty >>>> >>>> The variable that cannot be inferred is 's'. >>>> >>>> Thanks, >>>> Dominick >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Dec 30 16:31:20 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 30 Dec 2018 11:31:20 -0500 Subject: Type family equation violates injectivity? In-Reply-To: References: Message-ID: Looks like the maintainer of the package is aware of the issue and has fixing it on the todo queue On Sat, Dec 29, 2018 at 7:44 PM Carter Schonwald wrote: > i did some digging to see if theres a simple fix ... but then i realized > that the current design they have for inlineR always assumes theres IO > available in pure computations ... which they use the s parameter to thread > into the pure vector code via reflection tricks > > so it looks like the "right" way fix this would be to have the MVector > data type have both the state token for the the underlying resource AND > whatever PrimMonad its running in, rather than smashing them together... > especially since the ST monad and friend wont wont have the same state > token as the underlying IO resource > > either way, what seems to be going on is that theres a mutex on which > computations talk with the R RTS/instance the haskell code talks to, and > theres a little bit of a mismatch in how they handle that .. > > either way, its not a ghc issue, its a design issue around vector and the > api contract as the maintainers understand it vs how the package uses it. > (though i repeat: i do think theres an issue in how they factor thestate > token stuff ) > > On Sat, Dec 29, 2018 at 7:06 PM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> To be clear : I’m annoyed with myself that this impacted a package that >> depends on vector, but this does seem to be the case that the newest bug >> fix release for vector actually revealed a broken design for the vector >> instances / data types in the inline-r package. >> >> To;dr — I suggest patching inline-r to remove the s parameter in its >> immutable vector data types >> >> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> so i took a look .. (also the inline-r devs seem to have done a hackage >>> revision so you wont hit that issue in your current setup if you do a cabal >>> update ..) >>> and it seems like the type definitions in inline-r are kinda bogus and >>> you should get them patched ... >>> >>> the MVector type class, and related type families, all assume your >>> mutable type has the last two arguments as the io/state token and then the >>> element type >>> >>> eg >>> basicLength :: v s a -> Int >>> >>> >>> >>> i looked at >>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374 >>> and >>> >>> >>> >>> as a point of grounding this chat >>> the injective type familly in question is defined by the follwoing >>> >>> >>> --#if MIN_VERSION_base(4,9,0)type family Mutable (v :: * -> *) = (mv :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * -> *#endif >>> >>> anyways, it looks like the Pure / immutable vector data type in inline-r >>> has a spurious state token argument in its definition that shouldn't be >>> there, OR there need to be two "s" params in inline-r instead of the one >>> >>> heres the full code i linked to in question >>> >>> >>> -- | Mutable R vector. Represented in memory with the same header as >>> 'SEXP' >>> >>> -- nodes. The second type parameter is phantom, reflecting at the type >>> level the >>> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector and >>> the >>> -- representation type are related via 'ElemRep'. >>> data MVector s ty a = MVector >>> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty) >>> , mvectorOffset :: {-# UNPACK #-} !Int32 >>> , mvectorLength :: {-# UNPACK #-} !Int32 >>> } >>> -- | Internal wrapper type for reflection. First type parameter is the >>> reified >>> -- type to reflect. >>> newtype W t ty s a = W { unW :: MVector s ty a } >>> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t ty) >>> a where >>> >>> data Vector s (ty :: SEXPTYPE) a = Vector >>> { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset :: >>> {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32 >>> } >>> >>> >>> type instance G.Mutable (W t ty s) = Mutable.W t ty >>> Anyways, the fix here is to remove the s param from the Pure version of >>> W and "Sexp Vector" >>> >>> >>> >>> On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> were you using the same version of vector in both setups? >>>> >>>> in the most recent vector release we made mutable type family >>>> injective in the vector package for ghc's that support it ... >>>> >>>> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi >>>> wrote: >>>> >>>>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r package >>>>> I get the error "Type family equation violates injectivity >>>>> annotation," and >>>>> a type variable on the LHS cannot be inferred from the RHS, due to >>>>> the lack of injectivity (I suppose). >>>>> >>>>> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under >>>>> Ubuntu) does not have this problem (it has other problems). >>>>> >>>>> Has something changed in the latest version of the compiler that might >>>>> cause this? Possible work-around? >>>>> >>>>> FYI, the line that triggers the error is: >>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty >>>>> >>>>> The variable that cannot be inferred is 's'. >>>>> >>>>> Thanks, >>>>> Dominick >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Dec 30 16:40:03 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 30 Dec 2018 11:40:03 -0500 Subject: Phab and trac are gonna stay online in read only mode right? Message-ID: I’m still fuzzy on the long term hosting plans , but I worry that If we don’t keep them online as sort of read only sites with maybe a “look at this new gitlab ” top bar, that a lot of links to stuff will start dying Is there a post wiki / ticket migration plan for this ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Dec 31 17:58:46 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 31 Dec 2018 12:58:46 -0500 Subject: Welcome to GitLab! In-Reply-To: <87wonvq6z7.fsf@smart-cactus.org> References: <87a7krscvf.fsf@smart-cactus.org> <871s63roms.fsf@smart-cactus.org> <87wonvq6z7.fsf@smart-cactus.org> Message-ID: <87d0phpoh8.fsf@smart-cactus.org> Ben Gamari writes: > Matthew Pickering writes: > >> Does this mean that the commit message doesn't come from the MR description? >> > Correct. Like GitHub, the commit messages that make it into the version > control history are precisely the commit messages of the commits in your > branch. > I should note that the ability to specify the commit message when squashing is an open feature request [1]. It's not currently prioritized but I will bring it up with upstream. Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ee/issues/1510 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wolfgang-it at jeltsch.info Mon Dec 31 23:27:33 2018 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Tue, 01 Jan 2019 01:27:33 +0200 Subject: Welcome to GitLab! In-Reply-To: <87a7krscvf.fsf@smart-cactus.org> References: <87a7krscvf.fsf@smart-cactus.org> Message-ID: <1546298853.4750.63.camel@jeltsch.info> Am Donnerstag, den 27.12.2018, 01:27 -0500 schrieb Ben Gamari: > In the meantime, users of Trac should check and possibly update the > email address associated with their account [1].  This address will be > used to correlate Trac users with their GitLab equivalents so the > correctness of this address will be important in preserving > attribution information during the Trac import. > > [1] https://ghc.haskell.org/trac/ghc/prefs Will this correlation also work if I don’t have a GitLab account at the time of migration but later will get a GitLab account that uses the e- mail address I have on Trac? All the best, Wolfgang