Well said.
However, until Someone finds the time to write something with a nicer
license, that's a cross we'll have to bear. Otoh, the shelling out approach
for cpp in the mean time has zero issues vs linking to a lgpl or gpl
library. Unless those are organizations that done use Linux or gcc
On 05/19/2015 07:31 AM, Carter Schonwald wrote:
I imagine your ghc build uses gcc to invoke the system assembler and linker
on your Linux servers, :-) and that's gplv3!
That is of no consequence licensing-wise since those are
a) separate programs/executables, thus derived work doesn't enter
On 05/19/2015 08:26 AM, Bardur Arantsson wrote:
On 05/19/2015 07:31 AM, Carter Schonwald wrote:
I imagine your ghc build uses gcc to invoke the system assembler and linker
on your Linux servers, :-) and that's gplv3!
That is of no consequence licensing-wise since those are
a) separate
On 19 May 2015 at 08:26, Bardur Arantsson s...@scientician.net wrote:
On 05/19/2015 07:31 AM, Carter Schonwald wrote:
I imagine your ghc build uses gcc to invoke the system assembler and
linker
on your Linux servers, :-) and that's gplv3!
That is of no consequence licensing-wise since
On 05/19/2015 11:04 AM, Boespflug, Mathieu wrote:
On 19 May 2015 at 08:26, Bardur Arantsson s...@scientician.net wrote:
On 05/19/2015 07:31 AM, Carter Schonwald wrote:
I imagine your ghc build uses gcc to invoke the system assembler and
linker
on your Linux servers, :-) and that's gplv3!
I imagine your ghc build uses gcc to invoke the system assembler and linker
on your Linux servers, :-) and that's gplv3!
On Monday, May 18, 2015, Lars Kuhtz hask...@kuhtz.eu wrote:
I work for PivotCloud. We use Haskell/GHC in our production system on the
server side and on the client side.
To clarify my point more concretely:
Adding cpphs the cli tool to ghc build process / bin dist has no more
licensing implications than does using gcc as a compiler / assembler. Ie
NONE
Using cpphs as a library is Another discussion. But I don't think it's the
one we're having today.
On
Indeed. This is also how we use gcc and the llvm tooling.
If we want the cpp tooling to be available as a library, that's a whole
nother set of needs.
Gmp lgpl I can brush under the rug at work because there's the various
integer simple options, this gets a bit more squirrelly otherwise.
Maybe
Howard B. Golden wrote:
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
Oh please no!
If someone releases a package on Hackage that uses
On 2015-05-06 at 18:53:08 +0200, Howard B. Golden wrote:
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
Assuming this was a serious suggestion,
On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote:
[...]
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
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
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
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
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
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
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.
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 --
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
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
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
___
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
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
23 matches
Mail list logo
