- ghc-devs - Haskell.org

Why upper bound version numbers?
by Dominick Samperi 10 Jun '16

10 Jun '16

Why would a package developer want to upper bound the version number for packages like base? For example, the clash package requires base >= 4.2 && base <= 4.3 Consequently, it refuses to install with the latest ghc provided with the Haskell Platform (8.0.1). Does this mean that assuming that future versions of the platform will remain backwards compatible with prior versions is unsafe? Thanks, Dominick

12 19

cpphs bug with pathnames beginning with more than one slash
by Dan Aloni 10 Jun '16

10 Jun '16

Hi Malcolm, If we pass pathnames starting with more than one slash to '-include', cpphs generates invalid output. These are valid UNIX pathnames. I've tested with version 1.20.1 on Linux. Example: $ touch empty.hs $ cpphs --cpp -include //dev/null empty.hs #line 1 "test.hs" #line 1 " #line 2 "test.hs" #line 1 "test.hs" If I remove the extra '/', I get a good output: $ touch empty.hs $ cpphs --cpp -include /dev/null empty.hs #line 1 "test.hs" #line 1 "/dev/null" #line 2 "test.hs" #line 1 "test.hs" Thanks. -- Dan Aloni

2 2

Re: Why upper bound version numbers?
by Jeremy . 09 Jun '16

09 Jun '16

Versions of package dependencies can be categorised into 5 sets: D1) Versions which the maintainer has tested and found to work D2) Versions which the maintainer has not tested but expects to work D3) Versions which the maintainer has tested and found to not work D4) Versions which the maintainer has not tested but expects to not work D5) Everything else Cabal, however, only knows of 3 sets: C1) Versions which satisfy build-depends C2) Versions which satisfy build-depends with --allow-newer C3) Everything else The problem arises from the fact that the D sets to not map well onto the C sets, even after combining D1&D2 and D3&D4. Perhaps this could be solved with a new .cabal property, breaks-with. The solver will then prefer packages in this order: 1) Versions that satisfy build-depends 2) Versions that are not in breaks-with, unless a flag such as --strict-build-depends is applied This may also lead to clearer build-depends, as instead of multiple ranges with gaps to skip know broken versions, build-depends can list a single range, and breaks-with can list the bad versions.

2 1

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

09 Jun '16

(...and now with the right date in the subject line!) 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

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