Using GHC 7.8.3 from the latest Haskell Platform on OS X 10.9.4, the
__GLASGOW_HASKELL__ preprocessor symbol is being set to 708 instead of
783. I'd guess I have some stale files lying from previous versions
GHC or HP, but I can't seem to find them. Any clues?
$ cat wtf.hs
{-# LANGUAGE CPP
, “GHC version numbering policy”.
On Fri, Sep 26, 2014 at 11:09 AM, Greg Fitzgerald gari...@gmail.com wrote:
Using GHC 7.8.3 from the latest Haskell Platform on OS X 10.9.4, the
__GLASGOW_HASKELL__ preprocessor symbol is being set to 708 instead of
783. I'd guess I have some stale files lying
On Wed, Dec 12, 2012 at 4:35 AM, Simon Marlow marlo...@gmail.com wrote:
Now, all that LLVM knows is that z was read from Sp[8], it has no more
information about its value.
Are you saying Hoopl can deduce the original form from the CPS-version? Or
that LLVM can't encode the original form? Or
Thank you all for your replies.
On Tue, Dec 11, 2012 at 11:16 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:
And I think there is probably quite a lot that is in reach for C--, but
out of reach for LLVM. Why? Because before we pass the code to LLVM we do
CPS-conversion.
Is there a
I don't know my way around the GHC source tree. How can I get the list of
optimizations implemented with Hoopl? Is there overlap with LLVM's
optimization passes? If so, has anyone compared the implementations at
all? Should one group be stealing ideas from the other? Or apples and
oranges?
Is there any documentation or examples available that shows what needs to be
linked to get a haskell executable to print hello world? Instead of using
GHC to link, I'm interested in using gcc, ar, or link directly. For
starters, what implements the entry point?
$ cat Main.hs
main = print hello
Is there a way for a package.conf file to contain paths that are relative to
the directory containing the .conf file? GHC 6.12.1 chokes on relative
paths. I see the problem is solved for GHC's core libraries with the
$topdir variable. Is there something like a $thisdir we could use in
inplace
As another data point, Python has also re-invented the GMP
wheel, likely for the same licensing reasons. They have
been using a simple implementation of Karatsuba
multiplication for years. I have never heard of anyone
complaining about it
Thanks for the data point.
Looks like they swapped
You can dynamically link libgmp on windows. That might be easier:
Do you know if the dynamic link escape hatch has ever held up in
court? Last time I looked into it, the free software community had
mixed opinions. In any case, giving GMP the boot alleviates any
licensing concerns, makes the
I assume you mean
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#CurrentStatus
in which case, yes.
I assume that INTEGER_LIBRARY=integer-foo is an option when
compiling GHC itself and not when using GHC, correct?
Yes.
Great, thanks for your help Ian. Building GHC with
I wonder if someone might be able to clear a few things up for me
about implementing Integer with GMP. First, is the link below the
most up-to-date information regarding GHC's situation?
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinReplacementforGMP
I assume that
Another minor question is whether -XDoRec is a good
name for the flag. We can't really use -XRecursiveDo
because that's the one we are deprecating!
-XReDo :)
-Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
The instance for Functor (Either ParserError) disappeared. Is that
intentional?
Thanks,
Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Sounds fantastic
I'm using 'prof2dot' on a ~3000 LOC project and it's working well. Visual
quality metrics like this and Haskell Program Coverage makes using Haskell
in the corporate world a little easier to pull off. Zero crash reports
helps too. ;-)
-Greg F
On Tue, Aug 5, 2008 at 1:02
Haddock is no longer able to resolve the names from the standard
libraries.
There should be a new haddock release shortly, which fixes that as well
as an HTML link bug. Or you can get the latest source with darcs
The darcs version fixes the issue. Thanks Ian!
-Greg
abc @=? efg
Loading package HUnit-1.2.0.0 ... linking ... done.
*** Exception: (unknown)
On Dec 3, 2007 7:23 AM, Ian Lynagh [EMAIL PROTECTED] wrote:
This is caused by a change in the HUnit library, from
assertFailure msg = ioError (userError (hunitPrefix ++ msg))
to
abc @=? efg
Loading package HUnit-1.2.0.0 ... linking ... done.
*** Exception: (unknown)
On Dec 3, 2007 7:23 AM, Ian Lynagh [EMAIL PROTECTED] wrote:
This is caused by a change in the HUnit library, from
assertFailure msg = ioError (userError (hunitPrefix ++ msg))
to
assertFailure
Please test as much as possible
One difference between 6.8.1 and 6.8.2 that I see is in running runhaskell
Setup.hs haddock with Haddock 0.8 on Windows XP. Haddock is no longer able
to resolve the names from the standard libraries.
Running Haddock for Xyz-0.1...
Warning: Xyz: the following
On Windows, HUnit's assertions are not working - trace below in ghci 6.8.1and
6.6.1. Can others reproduce? Is this the right place to report bugs?
Should I confirm a bug here and then create a ticket, create a ticket and
that's it, or just mention it here and someone else creates a ticket?
Using GHC 6.8.1 on Windows XP, after having used ghc-pkg to expose '
directory-1.0.0.0', I am getting an error when I build haddock that says the
package is hidden. When I type ghc-pkg list, the package is not in
parenthesis. Typing ghc -v says that it is using the file from
GHC 6.8.1's docs no longer link to the source code in the upper right-hand
corner of each module. Intentional?
http://haskell.org/ghc/docs/latest/html/libraries/
Thanks,
Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
I notice that some of GHC's command-line parameters do not work from within
the OPTIONS_GHC pragma (6.6.1 on Windows). I can see how that makes sense
for some parameters like --make, but what about -i and -v? Is this
intentional or a bug?
Can't specify the include path:
{-# OPTIONS_GHC -iMyDir
each sub-project...have a...Haskell program...building that sub-project
I was trying to build something like this recently but hit a roadblock.
Rather than execute the script in each directory, I wanted to import it as a
module instead. This way you can, for example, pass functions, like a
23 matches
Mail list logo
