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

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

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"

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

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

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

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

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

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

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

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

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

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