Closed 0x777 closed 9 years ago
I was having the same problem and your changes fixed it, thank you
https://github.com/NixOS/nixpkgs/pull/7791 fixes the compilation of language-glsl which removes one error on the way to being able to compile elm-compiler with GHC 7.10.
Two errors remain in elm-compiler itself:
src/Parse/Helpers.hs:210:1:
Non type-variable argument in the constraint: Stream s m Char
(Use FlexibleContexts to permit this)
When checking that ‘betwixt’ has the inferred type
betwixt :: forall b s u (m :: * -> *).
Stream s m Char =>
Char -> Char -> ParsecT s u m b -> ParsecT s u m b
src/Parse/Helpers.hs:448:5:
Non type-variable argument in the constraint: Stream s m Char
(Use FlexibleContexts to permit this)
When checking that ‘closeShader’ has the inferred type
closeShader :: forall s u (m :: * -> *) a.
Stream s m Char =>
([Char] -> a) -> ParsecT s u m a
In an equation for ‘shader’:
shader
= do { try (string "[glsl|");
rawSrc <- closeShader id;
case glSource rawSrc of {
Left err -> parserFail . show $ err
Right tipe -> return ... } }
where
closeShader builder = choice [do { ... }, ....]
Oops, I meant to comment on a nixpkgs issue.
Ping? Is there any particular problem preventing this patch from being merged?
Thank you. https://github.com/noteed/language-glsl/pull/9 (i.e. remove pretty
was merged).
Will you release a new version to Hackage?
Yes, I will bump the version and push it to Hackage. Probably tomorrow evening. Sorry for the delay.
I've uploaded language-glsl-0.2.0 to Hackage.
The
pretty
package from version1.1.2.0
started providingText.PrettyPrint.HughesPJClass
which is already provided byprettyclass
. This causes the build to fail on ghc-7.10. However, as far as I understand, there is no need for the package to depend onpretty
.So, to fix this error, either remove the dependency on
pretty
or remove dependency onprettyclass
. As @arbn already provided a PR #9 for the first approach, this PR removes the dependency onprettyclass
aspretty
seems to be more actively developed.P.S I've no understanding on whether the
pretty
package is any better thanprettyclass
in the context oflanguage-glsl
.