- Glasgow-haskell-users

FW: Installing syb(-0.1.03) package in head version of Haskell
by Simon Peyton-Jones 24 Feb '10

24 Feb '10

Friends Can anyone help Kathleen out? She has a cabal-install issue. I think she's on a Mac. Many thanks Simon From: Kathleen Fisher [mailto:kathleen.fisher@gmail.com] Sent: 16 February 2010 22:54 To: Simon Peyton-Jones Subject: Fwd: Installing syb(-0.1.03) package in head version of Haskell Hi Simon, I'm trying to get the PADS file we were working on compiling under the HEAD version of Haskell, but I'm having trouble getting the Data.Generics module to install. I sent the question below to the libraries(a)haskell.org<mailto:libraries@haskell.org> last week, but I haven't seen any replies. Is that the right address? Or is there a different place to ask such questions? Thanks for any pointers! Kathleen Begin forwarded message: From: Kathleen Fisher <kathleen.fisher(a)gmail.com<mailto:kathleen.fisher@gmail.com>> Date: February 11, 2010 2:28:20 PM PST To: libraries(a)haskell.org<mailto:libraries@haskell.org> Subject: Installing syb(-0.1.03) package in head version of Haskell Hi all, I'm trying to get a program that uses the Data.Generics module to compile under the head version of GHC, but I am having trouble getting the syb package installed. I believe I am using the most recent version of cabal: kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/.cabal/bin/cabal --version cabal-install version 0.8.0 using version 1.8.0.1 of the Cabal library When I ask cabal to install the syb package, I get the following error: kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/.cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc Resolving dependencies... Downloading mtl-1.1.0.2... Configuring mtl-1.1.0.2... Preprocessing library mtl-1.1.0.2... ... Registering syb-0.1.0.3... cabal: ghc-pkg: <stdin>: hGetContents: invalid argument (invalid UTF-8 byte sequence) cabal: Error: some packages failed to install: language-c-quote-0.1 depends on syb-0.1.0.3 which failed to install. syb-0.1.0.3 failed during the building phase. The exception was: exit: ExitFailure 1 The full trace is included below. Here's the version information for the ghc I am running. Kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/sw/ghc-head/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 6.13.20100210 The cabal website suggests sending questions to this list... Any suggestions for how to fix this problem? Kathleen kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/.cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc Resolving dependencies... Downloading mtl-1.1.0.2... Configuring mtl-1.1.0.2... Preprocessing library mtl-1.1.0.2... Building mtl-1.1.0.2... ...stuff deleted... src/Data/Generics.hs:40:1: Warning: The import of `Prelude' is redundant except perhaps to import instances from `Prelude' To import instances alone, use: import Prelude() Registering syb-0.1.0.3... cabal: ghc-pkg: <stdin>: hGetContents: invalid argument (invalid UTF-8 byte sequence) cabal: Error: some packages failed to install: language-c-quote-0.1 depends on syb-0.1.0.3 which failed to install. syb-0.1.0.3 failed during the building phase. The exception was: exit: ExitFailure 1

8 16

create a DLL when using Gtk2hs
by Paqui Lucio 24 Feb '10

24 Feb '10

Hi, I am trying to generate a DLL for a Haskell program that imports Graphics.UI.Gtk from the Gtk2hs package. I have try to use the files .o that are in the Gtk2hs folder created by the package installer, but it does not work. Does somebody knows, how to generate a DLL when this package is used? Thanks in advance, Paqui --------------------------------- Paqui Lucio Dpto de LSI Facultad de Informática Paseo Manuel de Lardizabal, 1 20080-San Sebastián SPAIN --------------------------------- e-mail: paqui.lucio(a)ehu.es Tfn: (+34) (9)43 015049 Fax: (+34) (9)43 015590 Web: http://www.sc.ehu.es/paqui ---------------------------------

1 0

GHC FFI stub files
by Tyson Whitehead 24 Feb '10

24 Feb '10

I'm writing a perl module that interfaces some haskell code and its a bit of a pain because both perl and ghc have their own custom build system. Is there a way to get ghc to give you the gcc/as/ld options (library paths, include paths, flags, etc) required for the FFI stub files it generates? The best I've come up with so far is to extract them from GHC by telling it to use a "capture the arguments" command as the compiler and linker. Thanks! -Tyson (I could also tell the perl build system that ghc is c compiler, assembler, and linker, but then I need to do a bunch of wrapping with -optc and friends)

2 1

Shared GHC libraries and the runtime system
by Tyson Whitehead 23 Feb '10

23 Feb '10

I was working on a shared library that loads up the GHC runtime (via hs_init) and have been running into a bunch of undefined stg symbols. A bit of digging and it seems that GHC doesn't embed - the dependency libHSrts-ghc6.12.1.so, and - the associated rpath /usr/lib/ghc-6.12.1 into shared libraries that it builds. Thus, if your main executable isn't GHC generated (and hence has these), you run into unresolved symbols. I can work around this by manually adding them myself. Is there any reason GHC can't put this information by default into shared libraries though? Thanks! -Tyson PS: Further digging into the various shared libraries packaged with GHC (Debian GHC package 6.12.1-2) reveal that they are actually missing - the dependency libHSrts-ghc6.12.1.so, and - all rpaths (i.e., there are absolutely no rpaths in any of them) $ objdump -p /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.1.so ... Dynamic Section: NEEDED libHSinteger-gmp-0.2.0.0-ghc6.12.1.so NEEDED libgmp.so.3 NEEDED libHSghc-prim-0.2.0.0-ghc6.12.1.so NEEDED libc.so.6 SONAME libHSbase-4.2.0.0-ghc6.12.1.so ...

4 4

integer-simple by default
by Greg Fitzgerald 23 Feb '10

23 Feb '10

Static linking to GMP on Windows is sending me towards a bunch of red tape at work. What can I do to make integer-simple the default integer library for GHC? Need anything more than test suite and performance metrics? Any date planned for the 6.12.2 release? Thanks, Greg

8 15

Re: Quasi quoting
by Dave Bayer 22 Feb '10

22 Feb '10

Perhaps I missed this or I'm missing something, but seeing a mention of quasiquoting on another thread, I reread this entire thread just now before posting. If by "stealing syntax" we mean that the odd programmer who writes illegiblelinenoisewithoutspaceshastoaddtheoddspacehereandthere, then fine, sorry about the long post which you may freely ignore. What I read when I see "stealing syntax" is that a proposal makes some prior code impossible to write. Please clarify. I have no trouble distinguishing visually between the following forms [hex| 1.fffffp+1023 |] [ hex | hex <- [ 0..8 ] ] for two different reasons: [1] I'd never leave out the spaces for the list comprehension, while I'd always leave out the spaces for quasiquoting. [2] It's completely obvious to a human reader that the first form can't be a list comprehension, because of the trailing |] which would be a parse error. Let's recall that indentation-based parsing like we use in Haskell, Python was once radical, and still jars some people. Spaces are already significant for everyone, this just leans on them a bit more. A Lisp programmer would have no issues distinguishing these forms, because [hex| is a single token for the Lisp programmer. A freshman parser for quasiquoting would get this right by accident, failing to catch the quasiquoting that used spaces, falling correctly through to the list comprehension. More generally, humans always resolve ambiguity by parsing several ways in parallel, and accepting the highest priority parse that succeeds. I always expect computer languages to work this way, and my heart is always broken. Why can't Haskell evolve in this direction, as proposals like this increase its code density? Reading "Coders at Work", all of my coding zombie masters abandoned Lisp (as I did) because code density is a Good Thing. It's a mild nuisance to wait on the closing |] to decide, but only a mild nuisance. This reminds me of heredocs, where a traditional (e.g. Perl) heredoc help prog = <<“EOF” Usage: “prog” input output “prog” -h original input output EOF looks like it's stealing syntax, but there is utterly no issue at all, if one waits till the end to resolve the ambiguity, giving priority to a correct heredoc. (I need to wait till the end in any case to steal the indent.) Somehow this was never accepted as a reasonable idea in the heredoc thread either, yet I took this from working code that my custom literate preprocessor handles without incident. So what am I missing? Require no spaces to open quasiquoting, and/or require |] to close quasiquoting, falling through to whatever else Haskell will accept if these conditions aren't met? Then it remains possible to code any list comprehension. On Jan 31, 2010, at 10:50 PM, Simon Peyton-Jones wrote: > So the proposed change will make things *more* uniform, by grabbing every > "[blah|" as lexeme. On Feb 1, 2010, at 1:43 AM, Malcolm Wallace wrote: > I am not myself a TH or QQ user, but it has always bothered me slightly that the syntax for them steals some valid list comprehensions. On Feb 22, 2010, at 5:15 AM, Simon Peyton-Jones wrote: > Or, alternatively, use quasiquoting > > [hex| 1.fffffp+1023 |]

1 0

Re: Removing/deprecating -fvia-c
by Don Stewart 21 Feb '10

21 Feb '10

davidterei: > > I've been looking at some of these cases and seeing how the LLVM > back-end performs. My general impression from benchmarking the LLVM > back-end in the past has been that it generally performs with similar > characteristics as the C code generator (that is, where the C code > generator stood out compared to the NCG, so did LLVM). > > (On x86-32/Mac OS X 10.5, had some issues getting x64 working at moment): > > ./zipWith3_viac 0.72s > ./zipWith3_fasm 0.65s > ./zipWith3_llvm 0.38s Those are great numbers! I've added llvm support to ghc-core (if you compile with -fllvm, ghc-core will display the core and assembly in the pager, syntax highlighted). Unfortunately, llvm.org is down, so I can't apply patches to my llvm install at the moment, but I have managed to compile a fair few things on x86_64 -- they don't run though :-) What's the status of the x86_64 llvm backend, do you know, and are there ways to tune the optimizations that llvm applies? Should we just be using the llvm binding package on Hackage? -- Do

1 0

Confusion about GHC and GMP
by Greg Fitzgerald 20 Feb '10

20 Feb '10

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#BinaryDropinRepl… I assume that "INTEGER_LIBRARY=integer-foo" is an option when compiling GHC itself and not when using GHC, correct? If so, what version of GHC was this added? 6.10, 6.12, HEAD? Lastly, I'm confused about GHC's posted license, should it actually be LGPL so long as it statically links GMP? Aren't there a number of companies releasing binaries that were compiled with GHC? Thanks, Greg

2 3

ghc rts selection and third party libraries
by John Lask 19 Feb '10

19 Feb '10

Hello I hope someone can provide some guidance on how I can solve a certain problem. I have a library that taps into the ghc c rts: specifically when the rts is single threaded I am pumping events in via: stg_pending_events, when the threaded rts is used I use sendIOManagerEvent. i.e. I have two versions of the library with the same api. The problem with this is that either library is only good for one context: either threaded rts or not, and the user needs to select the appropriate library to use depending on the use context. What I want to be able to do is to have ghc automatically select the compiled library version to link in depending on the which rts option is selected: "-thread" or not does any one have any ideas?

3 6

Removing/deprecating -fvia-c
by Ian Lynagh 18 Feb '10

18 Feb '10

Hi all, We are planning to remove the -fvia-c way of compiling code (unregisterised compilers will continue to compile via C only, but registerised compilers will only use the native code generator). We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in 6.16. Simon Marlow has recently fixed FP performance for modern x86 chips in the native code generator in the HEAD. That was the last reason we know of to prefer via-C to the native code generators. But before we start the removal process, does anyone know of any other problems with the native code generators that need to be fixed first? Thanks Ian

11 19