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
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
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"
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
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
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
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
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
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
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
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
(...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 Contributions
ACM SIGPLAN Haskell Implementors' Workshop
http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016
Nara, Japan, 24 September, 2016
Co-located with ICFP 2016
13 matches
Mail list logo