June 2016 - ghc-devs - Haskell.org

Call for talks: Haskell Implementors Workshop 2016, Aug 24, Nara
by Edward Z. Yang 09 Jun '16

09 Jun '16

Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016 Nara, Japan, 24 September, 2016 Co-located with ICFP 2016 http://www.icfpconference.org/icfp2016/ Important dates --------------- Proposal Deadline: Monday, 8 August, 2016 Notification: Monday, 22 August, 2016 Workshop: Saturday, 24 September, 2016 The 8th Haskell Implementors' Workshop is to be held alongside ICFP 2016 this year in Nara. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2016. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw16.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Joachim Breitner (Karlsruhe Institut für Technologie) * Duncan Coutts (Well Typed) * Michael Snoyman (FP Complete) * Luite Stegeman (ghcjs) * Niki Vazou (UCSD) * Stephanie Weirich (University of Pennsylvania) * Edward Z. Yang - chair (Stanford University)

1 0

Linux (ELF) Support for "ghc -static -shared"
by Travis Whitaker 08 Jun '16

08 Jun '16

Suppose I have some module Foo with foreign exports. On some platforms I can do something like: ghc -static -shared Foo.o ... The resulting shared library would have the base libraries and the RTS statically linked in. From what I understand this is possible on BSDs because generating PIC is the default there (for making PIEs I'd imagine), and possible on Windows because the dynamic loading process involves some technique that doesn't require PIC. On Linux (at least x86_64) this doesn't work by default since libHSbase, libHSrts et al. are not built with -fPIC unless one specifically asks for it when building GHC. As far as I know this is the only way to get -static -shared to work on this platform. While the use cases for such stand-alone shared libraries might be small niches, I was curious whether or not there was any discussion about potential strategies for making it easier to build them for Linux. At the very least, perhaps a single switch for the configure script or build.mk to make it easier to build GHC+libs with -fPIC on Linux. Another step up might be providing *_PIC.a objects for the base libraries, so that the non-PIC objects are still available for the majority of cases in which PIC is not required. Thanks for your time, Travis Whitaker

2 1

RE: Windows testsuite improved but still a bug
by Simon Peyton Jones 08 Jun '16

08 Jun '16

PS I should add: this is in a branch I’m working on, not HEAD – but up to date with HEAD, and I’m doing nothing that will affect plugins From: Simon Peyton Jones Sent: 08 June 2016 07:04 To: 'ghc-devs(a)haskell.org' <ghc-devs(a)haskell.org> Subject: Windows testsuite improved but still a bug Thomie Thanks for fixing the testsuite on Windows. I still get some new failures Test framework failures: T10294a (normal) T10420 (normal) T11244 (normal) plugins07 (normal) The log file for one of them is below. Oddly, if I subsequently run a single test make TEST=plugins07 it works fine. Maybe something to do with something not being built? Simon =====> plugins07(normal) 2705 of 5154 [0, 8, 0] cd "c:\users\simonpj\appdata\local\temp\ghctest-pk_7er\test spaces\1\2\3\.\plugins\plugins07" && $MAKE -s --no-print-directory -C rule-defining-plugin package.plugins07 TOP=C:/code/HEAD/testsuite setup.exe: does not exist Makefile:12: recipe for target 'package.plugins07' failed make[3]: *** [package.plugins07] Error 1 *** framework failure for plugins07(normal) pre-command failed: 512 cd "c:\users\simonpj\appdata\local\temp\ghctest-pk_7er\test spaces\1\2\3\.\plugins\plugins07" && $MAKE -s --no-print-directory plugins07 </dev/null > plugins07.run.stdout 2> plugins07.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Makefile:16: recipe for target 'plugins07' failed Stderr: <command line>: cannot satisfy -plugin-package rule-defining-plugin (use -v for more information) make[3]: *** [plugins07] Error 1 *** unexpected failure for plugins07(normal)

1 0

Windows testsuite improved but still a bug
by Simon Peyton Jones 08 Jun '16

08 Jun '16

Thomie Thanks for fixing the testsuite on Windows. I still get some new failures Test framework failures: T10294a (normal) T10420 (normal) T11244 (normal) plugins07 (normal) The log file for one of them is below. Oddly, if I subsequently run a single test make TEST=plugins07 it works fine. Maybe something to do with something not being built? Simon =====> plugins07(normal) 2705 of 5154 [0, 8, 0] cd "c:\users\simonpj\appdata\local\temp\ghctest-pk_7er\test spaces\1\2\3\.\plugins\plugins07" && $MAKE -s --no-print-directory -C rule-defining-plugin package.plugins07 TOP=C:/code/HEAD/testsuite setup.exe: does not exist Makefile:12: recipe for target 'package.plugins07' failed make[3]: *** [package.plugins07] Error 1 *** framework failure for plugins07(normal) pre-command failed: 512 cd "c:\users\simonpj\appdata\local\temp\ghctest-pk_7er\test spaces\1\2\3\.\plugins\plugins07" && $MAKE -s --no-print-directory plugins07 </dev/null > plugins07.run.stdout 2> plugins07.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Makefile:16: recipe for target 'plugins07' failed Stderr: <command line>: cannot satisfy -plugin-package rule-defining-plugin (use -v for more information) make[3]: *** [plugins07] Error 1 *** unexpected failure for plugins07(normal)

1 0

Do we need to maintain PrimRep.VecRep?
by Ömer Sinan Ağacan 08 Jun '16

08 Jun '16

I have some code that does things depending on PrimReps of terms and so I have to handle VecRep there. To understand what VecRep exactly is and how to use it I looked at its uses, and all I can find was that we have a wired-in DataCon `vecRepDataCon` which has a type that I thought should have VecRep PrimRep, but when I test in GHCi I see that its PrimRep is PtrRep: λ> map typePrimRep (map dataConRepType (tyConDataCons runtimeRepTyCon)) [PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep] (This DataCon is not exported and only used in runtimeRepTyCon) So I think VecRep may not be in use at the moment. Do we still need to maintain it? What's the use case? Can anyone show me a Core term that has a type whose PrimRep is VecRep? Thanks..

3 5

Testsuite total failure on Windows
by Simon Peyton Jones 07 Jun '16

07 Jun '16

Thomie Is this you working on my show-stopping problem with the tetssuite? sh: line 0: cd: c:/users/simonpj/appdata/local/temp/ghctest-qbd2zw123.T9662: No such file or directory If so, thank you! If not, might you look (email attached). I am so stuck. Even a commit to roll back would be fine. But I don't know where to start. Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 07 June 2016 20:33 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/thomie: Testsuite driver: always quote | opts.testdir (9bee6ef) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/thomie | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell… | rg%2ftrac%2fghc%2fchangeset%2f9bee6ef2fb5c280e061144368d75a0ef947e68c9%2fghc& | data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c511d448661614206dbb808d38f0 | b2182%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=uOhvqGkrC3j2fRIYwTeDZ28%2f | x58jMs5jh1BdUDMiERY%3d | | >--------------------------------------------------------------- | | commit 9bee6ef2fb5c280e061144368d75a0ef947e68c9 | Author: Thomas Miedema <thomasmiedema(a)gmail.com> | Date: Tue Jun 7 15:59:15 2016 +0200 | | Testsuite driver: always quote opts.testdir | | This makes sure the testsuite keeps working when testdir contains | backward slashes. | | | >--------------------------------------------------------------- | | 9bee6ef2fb5c280e061144368d75a0ef947e68c9 | testsuite/driver/runtests.py | 2 +- | testsuite/driver/testlib.py | 42 +++++++++++++++++++------------ | -- | testsuite/tests/cabal/cabal01/Makefile | 2 +- | testsuite/tests/ghci/linking/dyn/all.T | 4 ++-- | testsuite/tests/rename/prog006/Makefile | 2 +- | 5 files changed, 29 insertions(+), 23 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies-harder -- | ignore-space-at-eol --cc 9bee6ef2fb5c280e061144368d75a0ef947e68c9 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c511d448661614206dbb | 808d38f0b2182%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2%2bhPH%2bwQOwvVTE | QdWNZZBmPziSwaudLrYp4DCOGXct8%3d

3 2

Help! Windows build broken in teestsuite
by Simon Peyton Jones 07 Jun '16

07 Jun '16

Aargh! The Windows build is broken again. This time it’s the testsuite. It seems to be trying to run the test in a temp directory, and failing to find the directory. Thomie, could this be something to do with your work on the testsuite? Please fix! Or tell me what to revert. It leaves me stuck. Thanks Simon /cygdrive/c/code/HEAD/testsuite/tests/indexed-types/should_fail$ make TEST=T9662 PYTHON="python" "python" ../../../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=0 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e in_tree_compiler=True -e cleanup=True --rootdir=. --configfile=../../../config/ghc -e 'config.confdir="../../../config"' -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="/cygdrive/c/code/HEAD/testsuite"' --config 'compiler="/cygdrive/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config 'ghc_pkg="/cygdrive/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' --config 'hp2ps="/cygdrive/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/cygdrive/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../../../timeout/install-inplace/bin/timeout.exe"' \ --only=T9662 \ \ \ \ \ \ Timeout is 300 Found 1 .T files... Beginning test run at 06/07/16 07:45:13 GMT Summer Time ====> Scanning ./all.T =====> T9662(normal) 1 of 1 [0, 0, 0] cd c:/users/simonpj/appdata/local/temp/ghctest-qbd2zw\1\2\3\.\T9662 && "C:/code/HEAD/inplace/bin/ghc-stage2.exe" -c T9662.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups -fno-ghci-history > T9662.comp.stderr 2>&1 sh: line 0: cd: c:/users/simonpj/appdata/local/temp/ghctest-qbd2zw123.T9662: No such file or directory

1 0

Proposal: Left-Associative Semigroup Operator Alias in "Data.Semigroup"
by Herbert Valerio Riedel 06 Jun '16

06 Jun '16

Hello! In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>) subtly conflicts with definitions of (<>) in pretty printing APIs, for which the left-associative variant is sometimes desirable. This subtle overloading of (<>) is error-prone, as one has to remember which version of (<>) is currently in scope in order to be able to reason about non-trivial expressions involving this operator. This proposal is an attempt to resolve this unfortunate and confusing situation by completing the `Semigroup`/`Monoid` vocabulary with a standard left-associative alias. Please see https://ghc.haskell.org/trac/ghc/wiki/Proposal/LeftAssocSemigroupOp for more details. Discussion period: 4 weeks

2 1

x86-64 unknown-linux
by Richard Eisenberg 06 Jun '16

06 Jun '16

Hi devs, I would like to download GHC 8 binaries for Arch Linux on an x86-64 architecture. I assume I'm looking for an unknown-linux build, and it looks like what I want is a Tier 1 platform, according to https://ghc.haskell.org/trac/ghc/wiki/Platforms Yet I don't see this release in https://downloads.haskell.org/~ghc/8.0.1/ Can you help? Thanks! Richard

2 2

Why does the LLVM invoke command-line tools instead of using the library?
by Nicola Gigante 05 Jun '16

05 Jun '16

Hi all, while looking at the GHC 8 Trac page I encountered the page about the plans for the improved LLVM backend: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend <https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend> I know nearly nothing about the internals of the GHC backend so I may be asking something trivial, but from reading that page I understand that GHC currently calls LLVM command line tools to optimize and compile the IR, is it right? LLVM is a C++ library, but it also exports a portable and stable C API which I think is already covered by the llvm-general package. So as someone who worked on LLVM in the past, and appreciated its library-based integration-friendly design I’m wondering why is GHC using the command line tools instead of linking to the library? Best Regards, Nicola

2 1