Call for talks: Haskell Implementors Workshop 2016, Aug 24, Nara
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) ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Call for talks: Haskell Implementors Workshop 2016, Sep 24 (FIXED), Nara
(...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) ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why upper bound version numbers?
What do you expect will be the distribution of 'soft' and 'hard' upper bounds? In my experience, all upper bounds currently are 'soft' upper bounds. They might become 'hard' upper bounds for a short while after e.g. a GHC release, but in general, if a package maintainer knows that a package fails to work with a certain version of a dependency, they fix it. So it seems to me that this is not so much a choice between 'soft' and 'hard' upper bounds, but a choice on what to do when you can't resolve dependencies in the presence of the current (upper) bounds. Currently, as you say, we give pretty bad error messages. The alternative you propose (just try) currently often gives the same result in my experience: bad error messages, in this case not from the solver, but unintelligible compiler errors in an unknown package. So it seems the solution might just be one of messaging: make the initial resolver error much friendlier, and give a suggestion to use e.g. --allow-newer=foo. The opposite might also be interesting to explore: if installing a dependency (so not something you're developing or explicitly asking for) fails to install and doesn't have an upper bound, suggest something like --constaint=foo wrote: > Right, part of the issue with having dependency solving at the core of your > workflow is that you never really know who's to blame. When running into > this circumstance, either: > > 1) Some maintainer made a mistake. > 2) Some maintainer did not have perfect knowledge of the future and has not > yet updated some upper bounds. Or, upper bounds didn't get retroactively > bumped (usual). > 3) You're asking cabal to do something that can't be done. > 4) There's a bug in the solver. > > So the only thing to do is to say "something went wrong". In a way it is > similar to type inference, it is difficult to give specific, concrete error > messages without making some arbitrary choices about which constraints have > gotten pushed around. > > I think upper bounds could potentially be made viable by having both hard > and soft constraints. Until then, people are putting 2 meanings into one > thing. By having the distinction, I think cabal-install could provide much > better errors than it does currently. This has come up before, I'm not sure > what came of those discussions. My thoughts on how this would work: > > * The dependency solver would prioritize hard constraints, and tell you > which soft constraints need to be lifted. I believe the solver even already > has this. Stack's integration with the solver will actually first try to > get a plan that doesn't override any snapshot versions, by specifying them > as hard constraints. If that doesn't work, it tries again with soft > constraints. > > * "--allow-soft" or something would ignore soft constraints. Ideally this > would be selective on a per package / upper vs lower. > > * It may be worth having the default be "--allow-soft" + be noisy about > which constraints got ignored. Then, you could have a "--pedantic-bounds" > flag that forces following soft bounds. > > I could get behind upper bounds if they allowed maintainers to actually > communicate their intention, and if we had good automation for their > maintenance. As is, putting upper bounds on everything seems to cause more > problems than it solves. > > -Michael > > On Wed, Jun 8, 2016 at 1:31 AM, Ben Lippmeier wrote: >> >> >> On 8 Jun 2016, at 6:19 pm, Reid Barton wrote: >> >>> Suppose you maintain a library that is used by a lot of first year uni >>> students (like gloss). Suppose the next GHC version comes around and your >>> library hasn’t been updated yet because you’re waiting on some dependencies >>> to get fixed before you can release your own. Do you want your students to >>> get a “cannot install on this version” error, or some confusing build error >>> which they don’t understand? >> >> >> This is a popular but ultimately silly argument. First, cabal dependency >> solver error messages are terrible; there's no way a new user would figure >> out from a bunch of solver output about things like "base-4.7.0.2" and >> "Dependency tree exhaustively searched" that the solution is to build with >> an older version of GHC. >> >> >> :-) At least “Dependency tree exhaustively searched” sounds like it’s not >> the maintainer’s problem. I prefer the complaints to say “can you please >> bump the bounds on this package” rather than “your package is broken”. >> >> Ben. >> >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why upper bound version numbers?
I think "hard" upper bounds would come about in situations where a new version of a dependency is released that breaks things in a package, so until the breakage is fixed a hard upper bound is required. Likewise for hard lower bounds. And arguments about "it shouldn't happen with the PVP" don't hold, because it does happen, PVP is a human judgement thing. Alan On Thu, Jun 9, 2016 at 10:01 AM, Erik Hesselink wrote: > What do you expect will be the distribution of 'soft' and 'hard' upper > bounds? In my experience, all upper bounds currently are 'soft' upper > bounds. They might become 'hard' upper bounds for a short while after > e.g. a GHC release, but in general, if a package maintainer knows that > a package fails to work with a certain version of a dependency, they > fix it. > > So it seems to me that this is not so much a choice between 'soft' and > 'hard' upper bounds, but a choice on what to do when you can't resolve > dependencies in the presence of the current (upper) bounds. Currently, > as you say, we give pretty bad error messages. The alternative you > propose (just try) currently often gives the same result in my > experience: bad error messages, in this case not from the solver, but > unintelligible compiler errors in an unknown package. So it seems the > solution might just be one of messaging: make the initial resolver > error much friendlier, and give a suggestion to use e.g. > --allow-newer=foo. The opposite might also be interesting to explore: > if installing a dependency (so not something you're developing or > explicitly asking for) fails to install and doesn't have an upper > bound, suggest something like --constaint=foo > Do you have different experiences regarding the number of 'hard' upper > bounds that exist? > > Regards, > > Erik > > On 8 June 2016 at 22:01, Michael Sloan wrote: > > Right, part of the issue with having dependency solving at the core of > your > > workflow is that you never really know who's to blame. When running into > > this circumstance, either: > > > > 1) Some maintainer made a mistake. > > 2) Some maintainer did not have perfect knowledge of the future and has > not > > yet updated some upper bounds. Or, upper bounds didn't get retroactively > > bumped (usual). > > 3) You're asking cabal to do something that can't be done. > > 4) There's a bug in the solver. > > > > So the only thing to do is to say "something went wrong". In a way it is > > similar to type inference, it is difficult to give specific, concrete > error > > messages without making some arbitrary choices about which constraints > have > > gotten pushed around. > > > > I think upper bounds could potentially be made viable by having both hard > > and soft constraints. Until then, people are putting 2 meanings into one > > thing. By having the distinction, I think cabal-install could provide > much > > better errors than it does currently. This has come up before, I'm not > sure > > what came of those discussions. My thoughts on how this would work: > > > > * The dependency solver would prioritize hard constraints, and tell you > > which soft constraints need to be lifted. I believe the solver even > already > > has this. Stack's integration with the solver will actually first try to > > get a plan that doesn't override any snapshot versions, by specifying > them > > as hard constraints. If that doesn't work, it tries again with soft > > constraints. > > > > * "--allow-soft" or something would ignore soft constraints. Ideally > this > > would be selective on a per package / upper vs lower. > > > > * It may be worth having the default be "--allow-soft" + be noisy about > > which constraints got ignored. Then, you could have a > "--pedantic-bounds" > > flag that forces following soft bounds. > > > > I could get behind upper bounds if they allowed maintainers to actually > > communicate their intention, and if we had good automation for their > > maintenance. As is, putting upper bounds on everything seems to cause > more > > problems than it solves. > > > > -Michael > > > > On Wed, Jun 8, 2016 at 1:31 AM, Ben Lippmeier > wrote: > >> > >> > >> On 8 Jun 2016, at 6:19 pm, Reid Barton wrote: > >> > >>> Suppose you maintain a library that is used by a lot of first year uni > >>> students (like gloss). Suppose the next GHC version comes around and > your > >>> library hasn’t been updated yet because you’re waiting on some > dependencies > >>> to get fixed before you can release your own. Do you want your > students to > >>> get a “cannot install on this version” error, or some confusing build > error > >>> which they don’t understand? > >> > >> > >> This is a popular but ultimately silly argument. First, cabal dependency > >> solver error messages are terrible; there's no way a new user would > figure > >> out from a bunch of solver output about things like "base-4.7.0.2" and > >> "Dependency tree exhaustively searched" that the solution is to build > with > >> an older version of
Re: Why upper bound version numbers?
Sure, I'm just wondering about how this plays out in reality: of people getting unsolvable plans, how many are due to hard upper bounds and how many due to soft upper bounds? We can't reliably tell, of course, since we don't have this distinction currently, but I was trying to get some anecdotal data to add to my own. Erik On 9 June 2016 at 10:07, Alan & Kim Zimmerman wrote: > I think "hard" upper bounds would come about in situations where a new > version of a dependency is released that breaks things in a package, so > until the breakage is fixed a hard upper bound is required. Likewise for > hard lower bounds. > > And arguments about "it shouldn't happen with the PVP" don't hold, because > it does happen, PVP is a human judgement thing. > > Alan > > > On Thu, Jun 9, 2016 at 10:01 AM, Erik Hesselink wrote: >> >> What do you expect will be the distribution of 'soft' and 'hard' upper >> bounds? In my experience, all upper bounds currently are 'soft' upper >> bounds. They might become 'hard' upper bounds for a short while after >> e.g. a GHC release, but in general, if a package maintainer knows that >> a package fails to work with a certain version of a dependency, they >> fix it. >> >> So it seems to me that this is not so much a choice between 'soft' and >> 'hard' upper bounds, but a choice on what to do when you can't resolve >> dependencies in the presence of the current (upper) bounds. Currently, >> as you say, we give pretty bad error messages. The alternative you >> propose (just try) currently often gives the same result in my >> experience: bad error messages, in this case not from the solver, but >> unintelligible compiler errors in an unknown package. So it seems the >> solution might just be one of messaging: make the initial resolver >> error much friendlier, and give a suggestion to use e.g. >> --allow-newer=foo. The opposite might also be interesting to explore: >> if installing a dependency (so not something you're developing or >> explicitly asking for) fails to install and doesn't have an upper >> bound, suggest something like --constaint=foo> >> Do you have different experiences regarding the number of 'hard' upper >> bounds that exist? >> >> Regards, >> >> Erik >> >> On 8 June 2016 at 22:01, Michael Sloan wrote: >> > Right, part of the issue with having dependency solving at the core of >> > your >> > workflow is that you never really know who's to blame. When running >> > into >> > this circumstance, either: >> > >> > 1) Some maintainer made a mistake. >> > 2) Some maintainer did not have perfect knowledge of the future and has >> > not >> > yet updated some upper bounds. Or, upper bounds didn't get >> > retroactively >> > bumped (usual). >> > 3) You're asking cabal to do something that can't be done. >> > 4) There's a bug in the solver. >> > >> > So the only thing to do is to say "something went wrong". In a way it >> > is >> > similar to type inference, it is difficult to give specific, concrete >> > error >> > messages without making some arbitrary choices about which constraints >> > have >> > gotten pushed around. >> > >> > I think upper bounds could potentially be made viable by having both >> > hard >> > and soft constraints. Until then, people are putting 2 meanings into >> > one >> > thing. By having the distinction, I think cabal-install could provide >> > much >> > better errors than it does currently. This has come up before, I'm not >> > sure >> > what came of those discussions. My thoughts on how this would work: >> > >> > * The dependency solver would prioritize hard constraints, and tell you >> > which soft constraints need to be lifted. I believe the solver even >> > already >> > has this. Stack's integration with the solver will actually first try >> > to >> > get a plan that doesn't override any snapshot versions, by specifying >> > them >> > as hard constraints. If that doesn't work, it tries again with soft >> > constraints. >> > >> > * "--allow-soft" or something would ignore soft constraints. Ideally >> > this >> > would be selective on a per package / upper vs lower. >> > >> > * It may be worth having the default be "--allow-soft" + be noisy about >> > which constraints got ignored. Then, you could have a >> > "--pedantic-bounds" >> > flag that forces following soft bounds. >> > >> > I could get behind upper bounds if they allowed maintainers to actually >> > communicate their intention, and if we had good automation for their >> > maintenance. As is, putting upper bounds on everything seems to cause >> > more >> > problems than it solves. >> > >> > -Michael >> > >> > On Wed, Jun 8, 2016 at 1:31 AM, Ben Lippmeier >> > wrote: >> >> >> >> >> >> On 8 Jun 2016, at 6:19 pm, Reid Barton wrote: >> >> >> >>> Suppose you maintain a library that is used by a lot of first year >> >>> uni >> >>> students (like gloss). Suppose the next GHC version comes around and >> >>> your >> >>> library hasn’t been updated yet because you’re waiting on some >> >>> d
Re: Why upper bound version numbers?
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. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why upper bound version numbers?
My five cents: There is discussion/work in Cabal dev about splitting the solver out. [1] I hope that at the end, there will be functionality that you can construct build/install plan by whatever means and use cabal functionality to execute it. Another functionality brought by work on haskell-security is that 01-index.tar.gz is append only file, so it’s “easy” to travel back in time in Hackage history. Combining those one can run an experiment, on how much - existing upper bounds prevent cabal from finding working install-plan; and how this change over time, because of maintainers activity. - non-existing upper bounds prevent found install-plan to compile properly; and how this change over time, because of a) maintainers own activity, b) Hackage trustee activity - other stats Until quantitative report justifying that upper bounds are clearly bad-idea, I would not propose any dramatical changes to how default solver works or Cabal-definition-format spec. With own solvers it would be easy to experiment and provide own metadata. As Hackage Trustee I do see much more full-of-red (failed builds) matrices on matrix.h.h.o than dark green ones (no install plan). Unfortunately only my gut feeling, no hard numbers but, but GHC <7.4/7.6 tends to be often red (because of base ==4.*, or base <5), or there are full lines of red because newer version of dependency causes breakage (which is no upper-bounds) For example. fast-logger introduced new type alias and new functionality in System.Log.FastLogger in minor version 2.4.4 [3]: --- Diff for | 2.4.3 → 2.4.4 | --- + System.Log.FastLogger.Date + type FormattedTime = ByteString + type TimeFormat = ByteString + newTimeCache :: TimeFormat -> IO (IO FormattedTime) + simpleTimeFormat :: TimeFormat + simpleTimeFormat' :: TimeFormat × System.Log.FastLogger + type FastLogger = LogStr -> IO () + LogCallback :: (LogStr -> IO ()) -> (IO ()) -> LogType + LogFile :: FilePath -> BufSize -> LogType + LogFileAutoRotate :: FileLogSpec -> BufSize -> LogType + LogNone :: LogType + LogStderr :: BufSize -> LogType + LogStdout :: BufSize -> LogType + data LogType + type TimedFastLogger = (FormattedTime -> LogStr) -> IO () + newFastLogger :: LogType -> IO (FastLogger, IO ()) + newTimedFastLogger :: (IO FormattedTime) -> LogType -> IO (TimedFastLogger, IO ()) + withFastLogger :: LogType -> (FastLogger -> IO a) -> IO () + withTimedFastLogger :: (IO FormattedTime) -> LogType -> (TimedFastLogger -> IO a) -> IO () × System.Log.FastLogger.File × New: check :: FilePath -> IO () Old: check :: FileLogSpec -> IO () [+ Added] [- Removed] [× Modified] [· Unmodified] And according to PVP you can do it, bumping only minor version. (The change in System.Log.FastLogger.File is breaking change, so it should been major bump, but our example holds even it was 2.4.4 -> 2.5) wai-logger package depends on fast-logger, and broke after new fast-logger release [4] because of: - doesn’t have upper-bounds - import(ed) modules improperly [5] The new version was fixed immediately, so I suspect that whetever the issue were about breakage or restrictive-upper bounds (pinged from Stackage) it would been fixed as fast. Yet now there is still lot’s of red in the matrix [6]. It’s highly unlikely that old versions would be picked by solver, but not impossible, happened to me, ekg-json picked very old aeson version (well again, no bounds there!) and broke. [7] To summarise this example, I’d rather make PRs to relax version bounds, then try to guess what bounds I have to adjust so I get working install plan. And to conclude, - Please setup CI, e.g. using Herbert’s script [8]. It’s very easy! - Have the base bounds restricting GHC’s to ones you test. - Contributing (i.e. to bump version bounds) would be extremely easy for others and you. Herbert is also very fast to make packages for newer (even unreleased version of GHC), so we had ability to test and fix! many packages before GHC-8.0 was officially released making adaptations as early as this year’s January. - Oleg - [1]: https://github.com/haskell/cabal/pull/3222 - [2]: http://matrix.hackage.haskell.org/packages see red-alert tag - [3]: http://hackage.haskell.org/package/fast-logger-2.4.4/docs/System-Log-FastLogger.html - [4]: https://github.com/kazu-yamamoto/logger/issues/88 - [5]: https://wiki.haskell.org/Import_modules_properly - [6]: http://imgur.com/bTYI8KC - [7] https://github.com/tibbe/ekg-json/pull/3 - [8] https://github.com/hvr/multi-ghc-travis > On 09 Jun 2016, at 12:22, Jeremy . wrote: > > 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, on
Re: Harbourmaster is still not building diffs
Matthew Pickering writes: > Since a couple of months ago, harbourmaster no longer builds diffs. > This is quite a large barrier to entry for new contributors as running > ./validate takes a long time. Hi Matthew, Indeed it has been a very long time since Harbormaster has built diffs. The story is this: in the past our Harbormaster infrastructure has been rather brittle due to its reliance on `arc` to apply differentials. With recently work in Phabricator this fragility can now be addressed, but at the cost of reworking some of our existing build infrastructure. Moreover, the new Harbormaster story seems to not have been designed with a public project such as ours in mind, so there are a few security issues which need to be worked out (namely it requires a git repository to which all Phab users can push commits). Getting to this point has unfortunately taken significantly longer than expected to get to this point and it's still not entirely clear how the new Harbormaster roll-out will work. At this point I suspect we ought to just roll back to the previous Harbormaster automation script unless there is a clear path forward with the new infrastructure. Austin, what do you think? Can we set a concrete timeline for bringing Harbormaster back up? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why upper bound version numbers?
On Mon, Jun 6, 2016 at 11:15 PM, Herbert Valerio Riedel wrote: > or even worse silent failures where the code behaves > subtly wrong or different than expected. Testsuites mitigate this to > some degree, but they too are an imperfect solution to this hard > problem. > It seems to me that if you have any thought at all for your library's clients the chances of this happening are pretty insignificant. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why upper bound version numbers?
On June 9, 2016 10:43:00 -0700 David Fox wrote: > It seems to me that if you have any thought at all for your library's > clients the chances of this happening are pretty insignificant. Sadly (IMO), this happens all too frequently. Upward compatibility suffers because most package authors are (naturally) interested in solving their own problems, and they don't get paid to think about others using their package who might be affected by an upward-incompatible change. This is a hard problem to solve unless we can find a way to pay package authors to take the extra time and effort to satisfy their users. Most open source communities are stricter about requiring upward compatibility than the Haskell community is. Howard From: David Fox To: Herbert Valerio Riedel Cc: "ghc-devs@haskell.org" Sent: Thursday, June 9, 2016 10:43 AM Subject: Re: Why upper bound version numbers? On Mon, Jun 6, 2016 at 11:15 PM, Herbert Valerio Riedel wrote: or even worse silent failures where the code behaves >subtly wrong or different than expected. Testsuites mitigate this to >some degree, but they too are an imperfect solution to this hard >problem. > It seems to me that if you have any thought at all for your library's clients the chances of this happening are pretty insignificant. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
cpphs bug with pathnames beginning with more than one slash
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: cpphs bug with pathnames beginning with more than one slash
Hi Dan, FYI, cpphs has a (new) bug tracker in https://github.com/malcolmwallace/cpphs/issues Best, On 9 June 2016 at 16:11, Dan Aloni wrote: > 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 > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > "La información contenida en este correo electrónico está dirigida únicamente > a su destinatario y puede contener información confidencial, material > privilegiado o información protegida por derecho de autor. Está prohibida > cualquier copia, utilización, indebida retención, modificación, difusión, > distribución o reproducción total o parcial. Si usted recibe este mensaje por > error, por favor contacte al remitente y elimínelo. La información aquí > contenida es responsabilidad exclusiva de su remitente por lo tanto la > Universidad EAFIT no se hace responsable de lo que el mensaje contenga." > > "The information contained in this email is addressed to its recipient only > and may contain confidential information, privileged material or information > protected by copyright. Its prohibited any copy, use, improper retention, > modification, dissemination, distribution or total or partial reproduction. > If you receive this message by error, please contact the sender and delete > it. The information contained herein is the sole responsibility of the sender > therefore Universidad EAFIT is not responsible for what the message contains." -- Andrés "La información contenida en este correo electrónico está dirigida únicamente a su destinatario y puede contener información confidencial, material privilegiado o información protegida por derecho de autor. Está prohibida cualquier copia, utilización, indebida retención, modificación, difusión, distribución o reproducción total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elimínelo. La información aquí contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga." "The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains." ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: cpphs bug with pathnames beginning with more than one slash
On Thu, Jun 09, 2016 at 07:44:55PM -0500, Andrés Sicard-Ramírez wrote: > Hi Dan, > > FYI, cpphs has a (new) bug tracker in > > https://github.com/malcolmwallace/cpphs/issues Would be worth linking to it from the docs and main site. I see t there's an open issue there for that :) -- Dan Aloni ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs