Hello *,
Following up on the Native -XCPP Proposal discussion, it appears that
cpphs' current LGPL+SLE licensing doesn't pose an *objective*
showstopper problem but is rather more of an inconvenience as it causes
argumentation/discussion overhead (which then /may/ actually result in
Haskell being
Based on two different occasions with two different companies (one related
to an acquisition and one to an OEM agreement), my experience is exactly as
laid out by Lars. A LGPL license will raise concerns by the legal team and
it will delay the process because it comes with a certain level of risk
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
Hi Lars,
I'm really not sure that the community has the resources to spare to
reimplement non-trivial pieces of *standalone (non-library)* software
to address perceived but ethereal business problems that are based
on lack of understanding about how IP law works as both you and Carter
point out.
Lars,
which users have an issue? could you please be concrete? Because I frankly
think you are being a bit vague.
gmp on linux platforms is dynamically linked, so it has absolutely zero
implications there. For those wanting to deploy a proprietary appplication
on windows or OSX, they merely need
On 21/05/15 19:07, Herbert Valerio Riedel wrote:
Don't you still have to support -pgmF?
I guess so, unfortunately... so we'd have to keep a legacy code-path for
external cpp processing around, at least in the short run...
I think it’s unfortunate if industrial usage of GHC is supported only
The issue that GMP is LGPL licensed came up a couple of times in discussions at
PivotCloud. Before each product release developers were requested to provided a
list of all third party dependencies along with their licenses. This was given
to the folks who deal with the legal stuff. If they
On 21/05/15 19:07, Herbert Valerio Riedel wrote:
Don't you still have to support -pgmF?
I guess so, unfortunately... so we'd have to keep a legacy code-path for
external cpp processing around, at least in the short run...
It's not just about legacy; -pgmF is used for all sorts of awesome
On 24 May 2015, at 14:15, Roman Cheplyaka wrote:
On 21/05/15 19:07, Herbert Valerio Riedel wrote:
Don't you still have to support -pgmF?
I guess so, unfortunately... so we'd have to keep a legacy code-path for
external cpp processing around, at least in the short run...
It's not just
Hi Yitzchak,
On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote:
[...]
Bardur Arantsson wrote:
I don't see any need for an option. Just bundle cpphs together with GHC
and build/use it as an external program. AFAICT this has absolutely no
licensing implications for GHC, derived from GHC or
Interesting. I'm not completely clear, when you say that your company
distributes binaries to third-parties: do you distribute ghc itself? Or just
the product that has been built by ghc?
Regards,
Malcolm
On 21 May 2015, at 10:16, Yitzchak Gale wrote:
LGPL is well-known and
On 05/21/2015 12:31 PM, Herbert Valerio Riedel wrote:
Hi Yitzchak,
On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote:
[...]
Bardur Arantsson wrote:
I don't see any need for an option. Just bundle cpphs together with GHC
and build/use it as an external program. AFAICT this has
On 21 May 2015, at 15:54, Bardur Arantsson wrote:
fork/exec is almost certainly going to be negligable compared to the
overall compile time anyway. It's not like GHC is fast enough for it to
matter.
Don't count on it. On our Windows desktop machines, fork/exec costs
approximately one third
On 05/21/2015 05:36 PM, Malcolm Wallace wrote:
On 21 May 2015, at 15:54, Bardur Arantsson wrote:
fork/exec is almost certainly going to be negligable compared to the
overall compile time anyway. It's not like GHC is fast enough for it to
matter.
Don't count on it. On our Windows
On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:
Performance isn't (my) motivation for avoiding fork/exec (and the
equivalent on Win32) but rather avoiding the added complexity of
marshalling/IPC with fork/exec, as opposed to simply calling into a
native
On 2015-05-21 at 18:02:57 +0200, Brandon Allbery wrote:
On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:
Performance isn't (my) motivation for avoiding fork/exec (and the
equivalent on Win32) but rather avoiding the added complexity of
marshalling/IPC with
On 2015-05-21 at 16:54:11 +0200, Bardur Arantsson wrote:
[...]
That would be the preferred way from a technical standpoint, as it would
avoid fork/exec and make it easier to integrate the CPP-phase tighter
into the lexer/parser.
fork/exec is almost certainly going to be negligable compared
The license issue is a real concern for any company using
GHC to develop a product whose binaries they distribute to
customers. And it is concern for GHC itself, if we want
GHC to continue to be viewed as a candidate for use in
industry.
The real issue is not whether you can explain why this
On 05/20/2015 03:39 PM, Yitzchak Gale wrote:
[--snip--]
Keeping the license as is seems to be important to Malcolm.
So could we have an option to build GHC without cpphs
and instead use it as a stand-alone external program?
That would make the situation no worse than GMP.
I don't see any need
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
How does your company deal with the Integer type, whose standard implementation
in ghc is via the LGPL'd Gnu multi-precision routines?
Regards,
Malcolm
On 18 May, 2015,at 09:19 PM, Lars Kuhtz hask...@kuhtz.eu wrote:
I work for PivotCloud. We use Haskell/GHC in our production system on
the
.
Regards,
Niklas
Från: malcolm.wallace
Skickat: 2015-05-19 13:11
Till: Lars Kuhtz
Kopia: ghc-devs@haskell.org
Ämne: Re: [Haskell-cafe] RFC: Native -XCPP Proposal
How does your company deal with the Integer type, whose standard implementation
in ghc is via the LGPL'd Gnu multi-precision routines
@haskell.org
Ämne: Re: [Haskell-cafe] RFC: Native -XCPP Proposal
How does your company deal with the Integer type, whose standard implementation
in ghc is via the LGPL'd Gnu multi-precision routines?
Regards,
Malcolm
On 18 May, 2015,at 09:19 PM, Lars Kuhtz hask...@kuhtz.eu wrote:
I work for PivotCloud
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 work for PivotCloud. We use Haskell/GHC in our production system on
the server side and on the client side.
My experience is that any license that contains the string GPL can
cause problems in an corporate context, no matter if it actually is a
legal issue or not.
Folks who are
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.
Hi Wren,
Incidentally, if we really want to pursue the get rid of CPP by
building it into the GHC distro...
In recent years there've been a number of papers on variational
lambda-calculi[1] which essentially serve to embed flag-based
preprocessor conditionals directly into the language
Exactly. My post was an attempt to elicit response from anyone to whom it
matters. There is no point in worrying about hypothetical licensing problems -
let's hear about the real ones.
Regards,
Malcolm
On 7 May 2015, at 22:15, Tomas Carnecky wrote:
That doesn't mean those people don't
On 8 May 2015, at 00:06, Richard A. O'Keefe wrote:
I think it's important that there be *one*
cpp used by Haskell. fpp is under 4 kSLOC
of C, and surely Haskell can do a lot better.
FWIW, cpphs is about 1600 LoC today.
Regards,
Malcolm
___
Hi,
using cpphs is the right way to go!
Rewriting it from scratch may be a good exercise but is (essentially) a
waste of time.
However, always asking Malcolm to get source changes into cpphs would be
annoying.
Therefore it would be great if the sources were just part of the ghc
sources (under
I'm unclear why cpphs needs to be made a dependency of the GHC API and
included as a lib. Could you elaborate? (in the wiki page possibly)
Currently, GHC uses the system preprocessor, as a separate process.
Couldn't we for GHC 7.12 keep to exactly that, save for the fact that by
default GHC would
[Gah, wrong From: email address given the list subscriptions, sorry
for the duplicates.]
I'm unclear why cpphs needs to be made a dependency of the GHC API and
included as a lib. Could you elaborate? (in the wiki page possibly)
Currently, GHC uses the system preprocessor, as a separate process.
Hello,
On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote:
If the intention is to use cpphs as a library, won't the license
affect every program built with the GHC API? That seems to be a high
price to pay.
Yes, every program linking the `ghc` package would be affected by
LGPL+SLE albeit
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
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
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
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
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
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
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
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
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
57 matches
Mail list logo
