Re: release timing

[Carter Schonwald]

to be especially specific, the event manager bug fixes alone are reason for
7.10.2 (though lots of other fixes should needs be happening too )

On Wed, May 6, 2015 at 8:42 PM, Carter Schonwald  wrote:

> I can't speak for others, but having haddock links work for me has been a
> large blocker on migrating my local home dev environment (i realize thats
> more haddock than ghc, but been a blocker for me locally :) )
>
> likewise, https://ghc.haskell.org/trac/ghc/ticket/10317 (the bugfixes for
> multishot event manager)  would be super useful
>
> likewise, https://ghc.haskell.org/trac/ghc/ticket/10236 makes the dwarf
> tooling that much more compelling
>
> thats ignoring a whole host of other fixes and issues that many awesome
> folks have already resolved or are currently in flight.
>
> basically, both at work (me and 2 other members of the engineering team),
> and in my personal work, i'm waiting for 7.10.2 before using ghc 7.10 in
> earnest. :)
>
>
> On Wednesday, May 6, 2015, Mateusz Kowalczyk 
> wrote:
>
>> 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
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: release timing

[Carter Schonwald]

I can't speak for others, but having haddock links work for me has been a
large blocker on migrating my local home dev environment (i realize thats
more haddock than ghc, but been a blocker for me locally :) )

likewise, https://ghc.haskell.org/trac/ghc/ticket/10317 (the bugfixes for
multishot event manager)  would be super useful

likewise, https://ghc.haskell.org/trac/ghc/ticket/10236 makes the dwarf
tooling that much more compelling

thats ignoring a whole host of other fixes and issues that many awesome
folks have already resolved or are currently in flight.

basically, both at work (me and 2 other members of the engineering team),
and in my personal work, i'm waiting for 7.10.2 before using ghc 7.10 in
earnest. :)

On Wednesday, May 6, 2015, Mateusz Kowalczyk 
wrote:

> 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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: release timing

[Akio Takano]

Hi,

On Tue, May 5, 2015 at 8:16 PM, Simon Peyton Jones
 wrote:
> Just to be clear, the issue is this
>
> * For whom is 7.10.2 mission-critical?

I'd like to bring attention to the ticket
https://ghc.haskell.org/trac/ghc/ticket/10380, because I imagine it
affects a lot of people who use sockets. Specifically, it potentially
affects all programs that (1) uses -threaded and (2) does both send
and recv over one socket, simultaneously from multiple threads.

That said, this isn't blocking us because we've decided to patch base ourselves.

Regards,
Takano Akio
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: "Native -XCPP" Proposal

[Andrés Sicard-Ramírez]

Hi Janek,

On 6 May 2015 at 14:55, Jan Stolarek  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

[Jan Stolarek]

> 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  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

[Mateusz Kowalczyk]

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: HCAR DUE SOON: Please help edit!

[George Colpitts]

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  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: RFC: "Native -XCPP" Proposal

[Howard B. Golden]

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

[Brandon Allbery]

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: RFC: "Native -XCPP" Proposal

[Herbert Valerio Riedel]

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

[Kosyrev Serge]

Stephen Paul Weber  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

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal

[Brandon Allbery]

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

[Brandon Allbery]

On Wed, May 6, 2015 at 10:59 AM, Bardur Arantsson 
wrote:

> (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.)
>

Only if you're convinced it will remain 80/20 for the foreseeable future. I
do not want to bet on Linux always being gcc (and dislike the One True
Platform-ism that line of thought encourages).

-- 
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

[Kosyrev Serge]

Sven Panne  writes:
> 2015-05-06 16:21 GMT+02:00 Bardur Arantsson :
>> +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

[Bardur Arantsson]

On 06-05-2015 16:32, Sven Panne wrote:
> 2015-05-06 16:21 GMT+02:00 Bardur Arantsson :
>> +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: [Haskell-cafe] RFC: "Native -XCPP" Proposal

[Sven Panne]

2015-05-06 16:21 GMT+02:00 Bardur Arantsson :
> +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

[Karel Gardas]

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: RFC: "Native -XCPP" Proposal

[Andrés Sicard-Ramírez]

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  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

HCAR DUE SOON: Please help edit!

[Austin Seipp]

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

[Alan & Kim Zimmerman]

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  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

[Mikhail Glushenkov]

On 6 May 2015 at 14:25, Austin Seipp  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

Re: RFC: "Native -XCPP" Proposal

[Austin Seipp]

On Wed, May 6, 2015 at 6:08 AM, Herbert Valerio Riedel
 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

[Jan Stolarek]

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

RFC: "Native -XCPP" Proposal

[Herbert Valerio Riedel]

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: release timing

[Alan & Kim Zimmerman]

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 
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 
> 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: release timing

[Simon Peyton Jones]

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 
mailto: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

RE: Tracking bugs for libraries

[Simon Peyton Jones]

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 
mailto: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

[Herbert Valerio Riedel]

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