Re: Tracking bugs for libraries
Hoopl didn't exist when the page was first created. I'm not sure if it should be considered a core library or not, honestly. If so, then it probably belongs on that page. If not, then it is probably worth documenting more clearly somewhere where its issues are tracked. -Edward On Wed, May 6, 2015 at 1:53 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: As of a couple of months ago, we updated https://wiki.haskell.org/Library_submissions to include the definitive source for where issues should be tracked on a package by package basis for all of the core libraries. As we spread maintainership of these packages around, we found more and more people preferred using github issue tracking to the legacy trac. That makes perfect sense. Thanks for clarifying. However, Hoopl is not included on the wiki page. Is that accidental or intentional omission? Janek There may well wind up with parallel trac items for some items in a separate project issue tracker, but the primary reason for such would be when ghc has to respond to an external change. Most (if not all) of the remaining duplicate issues were pushed out to the corresponding external trackers. As we clear out the remaining issues, we might look at removing these as component selections in the trac. -Edward Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RFC re #10196 GHC 7.10.2: Allow Unicode Lm category for 2nd+ character on in identifiers
Hello *, As you may be aware, GHC 7.10.1 updated its Unicode catalog to version 7.0, thereby causing some subscript symbols to change character properties, thereby causing GHC 7.10.1 to reject some Unicode-subscript characters that GHC 7.8.4 accepted. See https://ghc.haskell.org/trac/ghc/ticket/10196 for specific examples. In order to address this regression, one suggestion is to allow characters in the 'Letter, Modifier' category[1] from the 2nd position on in an identifier. This however may do more than just fix the regression, as it looks from [1] that it would allow many more new identifiers than were previously possible. So, is allowing 'Lm'-chars the the 2nd+ characters in an identifier a sensible change for addressing #10196 or not. If it's a bad idea, are there other suggestions worth considering? [1]: http://www.fileformat.info/info/unicode/category/Lm/list.htm Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: release timing
On the automated build front, there are now nightly builds for 7.10.1 on stackage [1]. Running a stackage instance with 7.10.2 could serve as a good confirmation test prior to release. Alan [1] https://www.stackage.org/nightly/2015-05-05 On Wed, May 6, 2015 at 11:58 AM, Simon Peyton Jones simo...@microsoft.com wrote: Mark Good points but: · If literally no one actually finds the absence of 7.10.2 a problem, we could save a lot of work (for you) by not releasing it! I think it’s reasonable to have some evidence of need before investing the effort (for both GHC and HP) needed for a release. · The tremendous amount of contingent work for HP should be orders of magnitude less for a patch-level release. Remember, there are supposed to be *no API changes*, just bug fixes. So if it worked with 7.10.1, it should work with 7.10.2. That’s why I said “press the button”. Suppose you did just do the automated build with exact same libraries as you currently have for 7.10.1. If that *doesn’t* work, that’s interesting… it’s not supposed to happen. And it would be good to know if it does. So I think there should be precisely zero work for library authors to stay abreast of 7.10.2 Does that help? I’m sure I’m misunderstanding something important – apologies if so. Simon *From:* Mark Lentczner [mailto:mark.lentcz...@gmail.com] *Sent:* 06 May 2015 04:47 *To:* Simon Peyton Jones *Cc:* ghc-devs@haskell.org *Subject:* Re: release timing On Tue, May 5, 2015 at 3:08 AM, Simon Peyton Jones simo...@microsoft.com wrote: *So the current status is that we’ll hold it until someone says “getting 7.10.2 out really matters to me”.* Other things being equal, the longer we wait, the more fixes will be in. This seems like a pretty ad hoc way to release a mature project. While it may be fine for GHC central to be happy living on tip-o-master until such time as someone decides to stamp a tag on it, for anyone with anything that is based on official releases, this sort of radioactive decay model of releasing makes any planning and work scheduling neigh impossible. But does anything stand in the way of pressing the button on the HP build, so that you have a HP 7.10.2 ready to go? You can always press the button again if/when further fixes go in. There is a tremendous amount of contingent work that goes into the libraries that make up the HP. In order for us to beat the bushes and ensure that everything is in shape to ship with the GHC release, we need some sense of when the release is, and preferably a few weeks before hand notice. Asking all the library authors to keep their libraries up-to-date, with numbered releases on Hackage, with tip-o-7.10.2 GHC as it goes is asking too much. Ideally, development would follow a schedule like this: - T -8 weeks - GHC Central announces the date of the next release (T) - T -7 weeks - HP assembles library list, puts maintainers on notice of impending release - T -4 weeks - GHC releases alpha builds, HP team does test builds, notifies library maintainers of needed updates - T -3 weeks - HP releases alpha build - T -2 weeks - GHC releases beta builds - T -1 week - HP releases beta build - T -2 days - GHC releases release candidate - T -1 day - HP releases release candidate - T - GHC HP release at same time I can't imagine mobilizing the volunteer army any faster than that. I, for one, have to plan for weekends off from the family so that I can put out the final release - and these things have to be scheduled. ___ 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: Tracking bugs for libraries
well, according to the page, Hoopl would come under clause (3) of what a “core library” is; GHC depends on it. So yes, it should be in the table. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Edward Kmett Sent: 06 May 2015 07:48 To: Jan Stolarek Cc: ghc-devs@haskell.org Subject: Re: Tracking bugs for libraries Hoopl didn't exist when the page was first created. I'm not sure if it should be considered a core library or not, honestly. If so, then it probably belongs on that page. If not, then it is probably worth documenting more clearly somewhere where its issues are tracked. -Edward On Wed, May 6, 2015 at 1:53 AM, Jan Stolarek jan.stola...@p.lodz.plmailto:jan.stola...@p.lodz.pl wrote: As of a couple of months ago, we updated https://wiki.haskell.org/Library_submissions to include the definitive source for where issues should be tracked on a package by package basis for all of the core libraries. As we spread maintainership of these packages around, we found more and more people preferred using github issue tracking to the legacy trac. That makes perfect sense. Thanks for clarifying. However, Hoopl is not included on the wiki page. Is that accidental or intentional omission? Janek There may well wind up with parallel trac items for some items in a separate project issue tracker, but the primary reason for such would be when ghc has to respond to an external change. Most (if not all) of the remaining duplicate issues were pushed out to the corresponding external trackers. As we clear out the remaining issues, we might look at removing these as component selections in the trac. -Edward Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: release timing
Mark Good points but: · If literally no one actually finds the absence of 7.10.2 a problem, we could save a lot of work (for you) by not releasing it! I think it’s reasonable to have some evidence of need before investing the effort (for both GHC and HP) needed for a release. · The tremendous amount of contingent work for HP should be orders of magnitude less for a patch-level release. Remember, there are supposed to be no API changes, just bug fixes. So if it worked with 7.10.1, it should work with 7.10.2. That’s why I said “press the button”. Suppose you did just do the automated build with exact same libraries as you currently have for 7.10.1. If that doesn’t work, that’s interesting… it’s not supposed to happen. And it would be good to know if it does. So I think there should be precisely zero work for library authors to stay abreast of 7.10.2 Does that help? I’m sure I’m misunderstanding something important – apologies if so. Simon From: Mark Lentczner [mailto:mark.lentcz...@gmail.com] Sent: 06 May 2015 04:47 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: release timing On Tue, May 5, 2015 at 3:08 AM, Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: So the current status is that we’ll hold it until someone says “getting 7.10.2 out really matters to me”. Other things being equal, the longer we wait, the more fixes will be in. This seems like a pretty ad hoc way to release a mature project. While it may be fine for GHC central to be happy living on tip-o-master until such time as someone decides to stamp a tag on it, for anyone with anything that is based on official releases, this sort of radioactive decay model of releasing makes any planning and work scheduling neigh impossible. But does anything stand in the way of pressing the button on the HP build, so that you have a HP 7.10.2 ready to go? You can always press the button again if/when further fixes go in. There is a tremendous amount of contingent work that goes into the libraries that make up the HP. In order for us to beat the bushes and ensure that everything is in shape to ship with the GHC release, we need some sense of when the release is, and preferably a few weeks before hand notice. Asking all the library authors to keep their libraries up-to-date, with numbered releases on Hackage, with tip-o-7.10.2 GHC as it goes is asking too much. Ideally, development would follow a schedule like this: * T -8 weeks - GHC Central announces the date of the next release (T) * T -7 weeks - HP assembles library list, puts maintainers on notice of impending release * T -4 weeks - GHC releases alpha builds, HP team does test builds, notifies library maintainers of needed updates * T -3 weeks - HP releases alpha build * T -2 weeks - GHC releases beta builds * T -1 week - HP releases beta build * T -2 days - GHC releases release candidate * T -1 day - HP releases release candidate * T - GHC HP release at same time I can't imagine mobilizing the volunteer army any faster than that. I, for one, have to plan for weekends off from the family so that I can put out the final release - and these things have to be scheduled. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RFC: Native -XCPP Proposal
Hello *,
As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a traditional mode c-preprocessor.
This has caused several problems in the past, since parsing Haskell code
with a preprocessor mode designed for use with C's tokenizer has caused
already quite some problems[1] in the past. I'd like to see GHC 7.12
adopt an implemntation of `-XCPP` that does not rely on the shaky
system-`cpp` foundation. To this end I've created a wiki page
https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
to describe the actual problems in more detail, and a couple of possible
ways forward. Ideally, we'd simply integrate `cpphs` into GHC
(i.e. plan 2). However, due to `cpp`s non-BSD3 license this should be
discussed and debated since affects the overall-license of the GHC
code-base, which may or may not be a problem to GHC's user-base (and
that's what I hope this discussion will help to find out).
So please go ahead and read the Wiki page... and then speak your mind!
Thanks,
HVR
[1]: ...does anybody remember the issues Haskell packages ( GHC)
encountered when Apple switched to the Clang tool-chain, thereby
causing code using `-XCPP` to suddenly break due to subtly
different `cpp`-semantics?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
One thing to keep in mind is that while cpphs will solve some problems of
system-cpp, it will also
bring problems of its own. I, for one, have run into problems with it when
installing Agda. There
is a very long thread here:
https://lists.chalmers.se/pipermail/agda/2014/006975.html
and twice as more on my private inbox. We've reached no conclusion about the
cause and the only
solution was to use system-cpp.
Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he
would consider
changing the license for the sake of GHC? Or perhaps he could grant a
custom-tailored license to
the GHC project? After all, the project page [1] says: If that's a problem
for you, contact me
to make other arrangements.
Janek
[1] http://projects.haskell.org/cpphs/
Dnia środa, 6 maja 2015, Herbert Valerio Riedel napisał:
Hello *,
As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a traditional mode c-preprocessor.
This has caused several problems in the past, since parsing Haskell code
with a preprocessor mode designed for use with C's tokenizer has caused
already quite some problems[1] in the past. I'd like to see GHC 7.12
adopt an implemntation of `-XCPP` that does not rely on the shaky
system-`cpp` foundation. To this end I've created a wiki page
https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
to describe the actual problems in more detail, and a couple of possible
ways forward. Ideally, we'd simply integrate `cpphs` into GHC
(i.e. plan 2). However, due to `cpp`s non-BSD3 license this should be
discussed and debated since affects the overall-license of the GHC
code-base, which may or may not be a problem to GHC's user-base (and
that's what I hope this discussion will help to find out).
So please go ahead and read the Wiki page... and then speak your mind!
Thanks,
HVR
[1]: ...does anybody remember the issues Haskell packages ( GHC)
encountered when Apple switched to the Clang tool-chain, thereby
causing code using `-XCPP` to suddenly break due to subtly
different `cpp`-semantics?
___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
---
Politechnika Łódzka
Lodz University of Technology
Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
This email contains information intended solely for the use of the individual
to whom it is addressed.
If you are not the intended recipient or if you have received this message in
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
On Wed, May 6, 2015 at 6:08 AM, Herbert Valerio Riedel
hvrie...@gmail.com wrote:
Hello *,
As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a traditional mode c-preprocessor.
This has caused several problems in the past, since parsing Haskell code
with a preprocessor mode designed for use with C's tokenizer has caused
already quite some problems[1] in the past. I'd like to see GHC 7.12
adopt an implemntation of `-XCPP` that does not rely on the shaky
system-`cpp` foundation. To this end I've created a wiki page
https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
to describe the actual problems in more detail, and a couple of possible
ways forward. Ideally, we'd simply integrate `cpphs` into GHC
(i.e. plan 2). However, due to `cpp`s non-BSD3 license this should be
discussed and debated since affects the overall-license of the GHC
code-base, which may or may not be a problem to GHC's user-base (and
that's what I hope this discussion will help to find out).
So please go ahead and read the Wiki page... and then speak your mind!
Thanks for writing this up, btw! It's nice to put the mumblings we've
had for a while down 'on paper'.
Thanks,
HVR
[1]: ...does anybody remember the issues Haskell packages ( GHC)
encountered when Apple switched to the Clang tool-chain, thereby
causing code using `-XCPP` to suddenly break due to subtly
different `cpp`-semantics?
There are two (major) differences I can list, although I can only
provide some specific examples OTTOMH:
1) Clang is more strict wrt language specifications. For example,
GCC is lenient and allows a space between a macro identifier and the
parenthesis denoting a parameter list; so saying 'FOO (x, y)' is valid
with GCC (where FOO is a macro), but not with Clang. Sometimes this
trips up existing code, but I've mostly seen it in GHC itself.
2) The lexing rules for C and Haskell simply are not the same in
general. For example, what should FOO(a' + b') parse to? Well, in
Haskell, 'prime' is a valid component from an identifier and in this
case the parse should be a prime + b prime, but in C the ' character
is identified as beginning the start of a single-character literal,
and a strict preprocessor like Clang's will reject that.
In practice, I think people have mostly just avoided arcane lexer
behaviors that don't work, and the only reason this was never a
problem was because GCC or some variant was always the 'standard' C
compiler GHC could rely on.
___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
--
Regards,
Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
Perhaps it makes sense to scan hackage to find all the different CPP idioms that are actually used in Haskell code, if it is a small/well-defined set it may be worth writing a simple custom preprocessor. Alan On Wed, May 6, 2015 at 3:03 PM, Mikhail Glushenkov the.dead.shall.r...@gmail.com wrote: On 6 May 2015 at 14:25, Austin Seipp aus...@well-typed.com wrote: 2) The lexing rules for C and Haskell simply are not the same in general. One area where this is irritating is that it makes it impossible to use Haskell multiline strings together with CPP. ___ 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: RFC: Native -XCPP Proposal
I want to emphasize that cpphs is actively maintained as it's pointed
out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The
Agda team has found some cpphs bugs which have been *quickly* fixed by
cpphs's author, Malcolm Wallace. Unfortunately I have not been able to
track down the problem mentioned by Janek Stolarek.
On 6 May 2015 at 06:38, Jan Stolarek jan.stola...@p.lodz.pl wrote:
One thing to keep in mind is that while cpphs will solve some problems of
system-cpp, it will also
bring problems of its own. I, for one, have run into problems with it when
installing Agda. There
is a very long thread here:
https://lists.chalmers.se/pipermail/agda/2014/006975.html
and twice as more on my private inbox. We've reached no conclusion about the
cause and the only
solution was to use system-cpp.
Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if
he would consider
changing the license for the sake of GHC? Or perhaps he could grant a
custom-tailored license to
the GHC project? After all, the project page [1] says: If that's a problem
for you, contact me
to make other arrangements.
Janek
[1] http://projects.haskell.org/cpphs/
Dnia środa, 6 maja 2015, Herbert Valerio Riedel napisał:
Hello *,
As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a traditional mode c-preprocessor.
This has caused several problems in the past, since parsing Haskell code
with a preprocessor mode designed for use with C's tokenizer has caused
already quite some problems[1] in the past. I'd like to see GHC 7.12
adopt an implemntation of `-XCPP` that does not rely on the shaky
system-`cpp` foundation. To this end I've created a wiki page
https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
to describe the actual problems in more detail, and a couple of possible
ways forward. Ideally, we'd simply integrate `cpphs` into GHC
(i.e. plan 2). However, due to `cpp`s non-BSD3 license this should be
discussed and debated since affects the overall-license of the GHC
code-base, which may or may not be a problem to GHC's user-base (and
that's what I hope this discussion will help to find out).
So please go ahead and read the Wiki page... and then speak your mind!
Thanks,
HVR
[1]: ...does anybody remember the issues Haskell packages ( GHC)
encountered when Apple switched to the Clang tool-chain, thereby
causing code using `-XCPP` to suddenly break due to subtly
different `cpp`-semantics?
___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
---
Politechnika Łódzka
Lodz University of Technology
Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
This email contains information intended solely for the use of the individual
to whom it is addressed.
If you are not the intended recipient or if you have received this message in
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Andrés
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
Herbert, what about to extend plan (1) to also include cpphs as a bundled option with all cpphs advantages except no more fork/exec as the bundle will be in a form of binary application and not library? Shall I add it? I would not like to make a mess from your page... Thanks, Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
2015-05-06 16:21 GMT+02:00 Bardur Arantsson s...@scientician.net: +1, I'll wager that the vast majority of usages are just for version range checks. The OpenGL-related packages used macros to generate some binding magic (a foreign import plus some helper functions for each API entry), not just range checks. I had serious trouble when Apple switched to clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources had been checked in. :-P Nowadays the binding is generated from the OpenGL XML registry file, so this is not an issue anymore. If there are packages that require more, they could just keep using the system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd want to see real evidence that that's actually worth the effort/complication. Simply relying on the system CPP doesn't work due to the various differences between GCC's CPP and the one from clang, see e.g. https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380. Ignoring the problem doesn't make it go away... ;-) Note that we still need CPP to handle the various calling conventions on the different platforms when the FFI is used, so it's not only range checks, see e.g. https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
On 6 May 2015 at 14:25, Austin Seipp aus...@well-typed.com wrote: 2) The lexing rules for C and Haskell simply are not the same in general. One area where this is irritating is that it makes it impossible to use Haskell multiline strings together with CPP. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
HCAR DUE SOON: Please help edit!
Hi *, (Apologies for the caps lock cruise-control in the title.) After sitting on it for a bit, it dawned on me today that the may HCAR report is due soon - in about two weeks! So, it's that time of the year again, and I'd like you all to take a quick glance at the page and edit some stuff in about what you're all working on, because I can't possibly keep up with it all. :) https://ghc.haskell.org/trac/ghc/wiki/Status/May15 Note that I've already put some boilerplate on the page, but some of it is old, from the last report - but some other things slipped, so maybe it's not old! The best case is you will read this page in 5 minutes and it will look OK. At worst, you may need to tweak a paragraph or write a new one - so please read and contribute! Note: I'll continue editing this page as time goes on, to prepare it for submission. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
On 2015-05-06 at 17:36:05 +0200, Stephen Paul Weber wrote:
As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a traditional mode c-preprocessor.
Yes. This is one of my favourite things in GHC-land -- that an
existing, good-enough, standardised, and widely-deployed solution was
chosen over a NiH reinvention of preprocessing. This allows other
Haskell compilers to support CPP on basically any system (since cpp is
so standard) without much effort, or even if the compiler does not
support {-# LANGUAGE CPP -#} the user can easily run `cpp` over the
source files themselves before feeding the source into the compiler.
Because it is a real `cpp` being used, the developmer must take care
to follow the CPP syntax in the file that will then be transformed
into Haskell by `cpp` in the same way that C, C++, and other
developers have to take extra care (especially around use of # and
end-of-line \) when using `cpp`, but this is the normal state of
affairs for a secondary preprocessor step. As a benefit, the source
code will be processable by standard `cpp` implementations available
for virtually every platform.
In short, the current solution provides a very robust and portable way
to do pre-compile preprocessing, and I like it very much.
The problem I have with that line of argument is that we're using the
so-called 'traditional mode' of `cpp`[1] for which afaik there is no
written down common specification different implementations commit to
adhere to (well, that's because 'traditional mode' refers to some vague
implementation-specific pre-standard cpp semantics).
And how is the developer supposed to take care to follow the
(traditional mode) CPP syntax, if he can't test it easily with all
potentially used (traditional-mode) `cpp`s out there? This already has
led to problems with Clang's cpp vs GCC's cpp.
Moreover, I was under the impression that it's only a matter of time
till `traditional mode` support may be dropped from C compiler
toolchains. Otoh, we can't use an ISO C spec conforming c-preprocessor,
as that would conflict even more heavily w/ Haskell's grammar to the
point of being inpractical.
[1]: https://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
Hi Janek, On 6 May 2015 at 14:55, Jan Stolarek jan.stola...@p.lodz.pl wrote: Yes, and that's what gets me worried. I suppose the problem was somehow related to my locale settings although we were unable to track down the cause. I also recall someone else reported being affected by the same problem. AFIK, the only cpphs-Agda open problem is your problem. I would like to know if anyone else has some problem. If so, I propose to move the discussion to the Agda developers list (agda-...@lists.chalmers.se). Best, -- Andrés ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
I want to emphasize that cpphs is actively maintained as it's pointed
out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The
Agda team has found some cpphs bugs which have been *quickly* fixed by
cpphs's author, Malcolm Wallace.
Yes. It was not my intention to imply in any way that cpphs suffers from
maintanance issues.
Unfortunately I have not been able to track down the problem mentioned by
Janek Stolarek.
Yes, and that's what gets me worried. I suppose the problem was somehow related
to my locale
settings although we were unable to track down the cause. I also recall someone
else reported
being affected by the same problem. So, until that problem is solved I would
say it is a blocker
as it would essentialy make development of GHC impossible for some people.
Janek
On 6 May 2015 at 06:38, Jan Stolarek jan.stola...@p.lodz.pl wrote:
One thing to keep in mind is that while cpphs will solve some problems of
system-cpp, it will also bring problems of its own. I, for one, have run
into problems with it when installing Agda. There is a very long thread
here:
https://lists.chalmers.se/pipermail/agda/2014/006975.html
and twice as more on my private inbox. We've reached no conclusion about
the cause and the only solution was to use system-cpp.
Regarding licensing issues: perhaps we should simply ask Malcolm Wallace
if he would consider changing the license for the sake of GHC? Or perhaps
he could grant a custom-tailored license to the GHC project? After all,
the project page [1] says: If that's a problem for you, contact me to
make other arrangements.
Janek
[1] http://projects.haskell.org/cpphs/
Dnia środa, 6 maja 2015, Herbert Valerio Riedel napisał:
Hello *,
As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a traditional mode c-preprocessor.
This has caused several problems in the past, since parsing Haskell code
with a preprocessor mode designed for use with C's tokenizer has caused
already quite some problems[1] in the past. I'd like to see GHC 7.12
adopt an implemntation of `-XCPP` that does not rely on the shaky
system-`cpp` foundation. To this end I've created a wiki page
https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
to describe the actual problems in more detail, and a couple of possible
ways forward. Ideally, we'd simply integrate `cpphs` into GHC
(i.e. plan 2). However, due to `cpp`s non-BSD3 license this should be
discussed and debated since affects the overall-license of the GHC
code-base, which may or may not be a problem to GHC's user-base (and
that's what I hope this discussion will help to find out).
So please go ahead and read the Wiki page... and then speak your mind!
Thanks,
HVR
[1]: ...does anybody remember the issues Haskell packages ( GHC)
encountered when Apple switched to the Clang tool-chain, thereby
causing code using `-XCPP` to suddenly break due to subtly
different `cpp`-semantics?
___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
---
Politechnika Łódzka
Lodz University of Technology
Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
This email contains information intended solely for the use of the
individual to whom it is addressed. If you are not the intended recipient
or if you have received this message in error, please notify the sender
and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
---
Politechnika Łódzka
Lodz University of Technology
Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
This email contains information intended solely for the use of the individual
to whom it is addressed.
If you are not the intended recipient or if you have received this message in
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: release timing
On 05/05/2015 11:16 AM, Roman Cheplyaka wrote: I'd love to see GHC 7.10.2 once this haddock issue is fixed: https://github.com/haskell/haddock/issues/385 There's a PR for it sitting on GitHub[1]. I did not have time to test it but if you want to go ahead and give it a quick look, I'd be happy to merge it if you give it an OK. [1]: https://github.com/haskell/haddock/pull/386 -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
At the risk of antagonizing some (most? all?) of you, how about... -XCPP stands for the native CPP -XGNUCPP stands for GNU's GCC CPP -XClangCPP stands for Clang's CPP -XCPPHS stands for CPPHS ... with the hope that TH is the future? Howard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
On Wed, May 6, 2015 at 11:36 AM, Stephen Paul Weber singpol...@singpolyma.net wrote: Yes. This is one of my favourite things in GHC-land -- that an existing, good-enough, standardised, and widely-deployed solution was chosen over a NiH reinvention of preprocessing I have to assume my irony detector is broken as well. Or maybe I should just assume that all the world's Linux with gcc is assumed to be forever true and forever reliable by all right-thinking people so let's just sweep the nonissue under the rug because it can oh so obviously never be a real issue Because I had to face this back a couple decades ago, when my employer ported an application written in a 4GL (database language) to SCO Unix. The 4GL assumed cpp was the ever reliable pcc one and broke very badly when SCO used one integrated into its lexer (making it even more tightly wedded to C syntax than clang's). Eventually we replaced its cpp with a wrapper that ran m4 and redid everything else in m4's syntax. Which is why I was always a bit worried about ghc relying on cpp, was unsurprised when clang caused issues, and am rather annoyed that there are people who believe that they can just ignore it because REAL users will always be on Linux with gcc and all them furriners using weird OSes like OS X and FreeBSD can safely be ignored with their not-the-One-True-OS-and-compiler platforms. Additional historical note that I assume True Believers will ignore as meaningless: X11 used to make the same assumption that cpp was always and forever guaranteed to be friendly to non-C and this still shows at times in things like xrdb resource databases. They did accept the inevitable and (mostly) stop abusing it that way, and are now moving away from imake which likewise assumes it's safe to use cpp on Makefiles. (And yes, I encounter the same inability to comprehend or accept change there.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HCAR DUE SOON: Please help edit!
In my opinion it would be great if somebody could add the LLVM work to the Upcoming plans for the next release section Thanks On Wed, May 6, 2015 at 10:27 AM, Austin Seipp aus...@well-typed.com wrote: Hi *, (Apologies for the caps lock cruise-control in the title.) After sitting on it for a bit, it dawned on me today that the may HCAR report is due soon - in about two weeks! So, it's that time of the year again, and I'd like you all to take a quick glance at the page and edit some stuff in about what you're all working on, because I can't possibly keep up with it all. :) https://ghc.haskell.org/trac/ghc/wiki/Status/May15 Note that I've already put some boilerplate on the page, but some of it is old, from the last report - but some other things slipped, so maybe it's not old! The best case is you will read this page in 5 minutes and it will look OK. At worst, you may need to tweak a paragraph or write a new one - so please read and contribute! Note: I'll continue editing this page as time goes on, to prepare it for submission. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ 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: [Haskell-cafe] RFC: Native -XCPP Proposal
Sven Panne svenpa...@gmail.com writes: 2015-05-06 16:21 GMT+02:00 Bardur Arantsson s...@scientician.net: +1, I'll wager that the vast majority of usages are just for version range checks. The OpenGL-related packages used macros to generate some binding magic (a foreign import plus some helper functions for each API entry), not just range checks. So, metaprogramming. The question that comes to mind -- why suffer such a lousy tool as cpp for metaprogramming? Why *shouldn't* TH fill that role? What can be done about it? -- regards, Косырев Серёга ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
On Wed, May 6, 2015 at 11:27 AM, Kosyrev Serge _deepf...@feelingofgreen.ru wrote: Why *shouldn't* TH fill that role? What can be done about it? For one, it's difficult to make it available in cross compilers (granted, work is being done on this) and not available on some platforms (ARM has been a problem, dunno if it currently is). For another, I don't think you can currently control things like imports or LANGUAGE pragmas --- and as TH is currently constructed it's not clear that you could do so, or that you could do so in a way that is sane for users. This is not to say that I like cpp --- I'd like it a lot more if it weren't actually using a C preprocessor that is not actually under our control or guaranteed to be compatible with Haskell --- but it does provide a meta in a different dimension than TH does. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
On 06-05-2015 16:32, Sven Panne wrote: 2015-05-06 16:21 GMT+02:00 Bardur Arantsson s...@scientician.net: +1, I'll wager that the vast majority of usages are just for version range checks. The OpenGL-related packages used macros to generate some binding magic (a foreign import plus some helper functions for each API entry), not just range checks. I had serious trouble when Apple switched to clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources had been checked in. :-P Nowadays the binding is generated from the OpenGL XML registry file, so this is not an issue anymore. Ok, so it's *not* a counterexample :). If there are packages that require more, they could just keep using the system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd want to see real evidence that that's actually worth the effort/complication. Simply relying on the system CPP doesn't work due to the various differences between GCC's CPP and the one from clang, see e.g. https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380. Ignoring the problem doesn't make it go away... ;-) No, but is it worth the effort? (As opposed to workarounds, such as just checking in the preprocessed file as you provided an example of.) Note that we still need CPP to handle the various calling conventions on the different platforms when the FFI is used, so it's not only range checks, see e.g. https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588. Certainly. I'm not saying *everybody* just does range checks, but I'm guessing that it's the majority of CPP users are using it just for that. (I'm not going to be doing any of the work, so this is just armchairing, but this seems like an 80/20 solution would be warranted.) Regards, ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
Stephen Paul Weber singpol...@singpolyma.net writes:
As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a traditional mode c-preprocessor.
Yes. This is one of my favourite things in GHC-land -- that an existing,
good-enough, standardised, and widely-deployed solution was chosen over a NiH
reinvention of preprocessing.
(Note: here I assume that my irony detector is hopelessly broken..)
At the risk of spreading dangerous novelty..
..come on, the C preprocessor *is* a NIH reinvention of proper metaprogramming,
and the word used to denote it (preprocessing) betrays it so badly.
As an example:
http://www.lispworks.com/documentation/HyperSpec/Body/24_abaa.htm
Why can't we make TH be more like that?
--
respectfully,
Косырев Серёга
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
