- Glasgow-haskell-users

ByteString-backed Handles, and another couple of questions
by Bryan O'Sullivan 16 Dec '09

16 Dec '09

Hi, Simon - I just added support to Data.Text for your new Unicode-based Handle implementation, and I'd like to write some tests. The natural way to do this would be to create Handles that will write to, and read from, ByteStrings. Does any such code exist at the moment? I don't see it in base or bytestring, though all the necessary abstractions appear to be present. Also, the place I hooked into the new I/O machinery was at the next level up from CharBuffer. Because the implementation of CharBuffer isn't abstract, I had no opportunity to put a text array in there, so there's an extra amount of copying that happens when going from byte buffer to char buffer to Text. It's a bit of a shame, but I don't see a way around it at the moment. Would you be interested in trying to remove that extra copy, or is the current interface set in stone? Many thanks for your great work on this, Bryan.

3 4

Porting to DragonFly BSD
by Colin Adams 15 Dec '09

15 Dec '09

When GHC 6.12.1 is released, I'm going to have a go at porting it to DragonFly BSD (32-bit incarnation). Is the porting page on the wikiup-to-date? -- Colin Adams Preston, Lancashire, ENGLAND

9 19

RE: ANNOUNCE: GHC version 6.12.1
by Jost Berthold 15 Dec '09

15 Dec '09

Luca, to use Control.Parallel, you need to download and install two packages, deepseq and parallel, from hackage.haskell.org. Most likely this will work with cabal, or you just download the two tarballs . The reason is, when packaging "parallel", this package has been removed from the GHC core libraries. BTW I am unsure whether this is at all clever, since it needs specific GHC support (at least for now - am I right here?) In addition, be informed that Control.Parallel.Strategies has been heavily restructured just last month (splitting it into deepseq and parallel is one of the changes, but not the most fundamental). If you want to try examples from GpH publications, you will certainly have some problems. parallel-1.x versions containing the original definitions are on hackage as well and should work for experiments. Cheers Jost Berthold PS: Loading Control.Parallel into ghci is a handy debugging procedure for the sequential parts of your program without any hassle, but if you do not compile and link your program, it will not use any parallelism (and run slow anyway). > From: Luca Ciciriello <luca_ciciriello(a)hotmail.com> > Subject: RE: ANNOUNCE: GHC version 6.12.1 > To: <marco-oweber(a)gmx.de>, <glasgow-haskell-users(a)haskell.org> > Message-ID: <SNT128-W3217F8C02C7EAA2723E4339A890(a)phx.gbl> > Content-Type: text/plain; charset="iso-8859-1" > > > Installed 6.12.1 on MacOS X 10.6Now I'm unable to load in GHCi of that > modules containing "import Control.Parallel"I'm missing something? > Luca > >> From: marco-oweber(a)gmx.de >> To: glasgow-haskell-users(a)haskell.org >> Date: Mon, 14 Dec 2009 15:24:48 +0100 >> Subject: RE: ANNOUNCE: GHC version 6.12.1 >> >> Excerpts from Luca Ciciriello's message of Mon Dec 14 15:12:45 +0100 >> 2009: >> > I've the 6.10.4 version installed on my MacOS X 10.6 OS. Have I to >> uninstall >> > this version of GHC before installing the Mac .pkg for the 6.12.1? >> >> Hi Luca, >> >> You should be able to get some hints by looking at where ghc is >> installed. >> >> By default ghc puts its libraries into directory which contains the ghc >> release name. So libs can be installed at the same time. >> There are also ghc(i)-pkg-$GHC_VERSION executables. >> So it should be possible. However I don't know about Mac details. >> >> But maybe someone else can give you a more accurate answer. >> >> Sincerly >> Marc Weber

6 6

Re: Porting to DragonFly BSD
by Colin Paul Adams 15 Dec '09

15 Dec '09

>>>>> "Karel" == Karel Gardas <karel.gardas(a)centrum.cz> writes: Karel> Seeing DragonFly BSD and `make' together with your make Karel> error messages rings an alarm here with a suggestion to use Karel> GNU make. That's a good alarm you have :-) gmake works much better. Thanks. -- Colin Adams Preston Lancashire

1 0

Initial ghc-6.12 + hackage build results
by Duncan Coutts 14 Dec '09

14 Dec '09

All, I've tried building 1324 out of the ~1700 packages from hackage using ghc-6.10.4 and ghc-6.12.0. This is the subset of packages that I could build in one go. Compared to the subset that I could build with ghc-6.10.4, I had to chuck out 125 packages because their build dependency constraints precluded them from building with ghc-6.12. Of the remaining 1324 packages, 113 packages that built OK previously now do not build. Amongst that 113, the ones that cause most knock-on failures are: (16,"packedstring-0.1.0.1") (12,"MissingH-1.1.0.1") (11,"syb-with-class-0.5.1") (6,"uvector-0.1.0.5") (3,"stringtable-atom-0.0.6") (3,"bindings-common-1.3.4") (3,"binary-strict-0.4.6") (3,"base64-string-0.1") packedstring fails because it needs base 4, but only says "build-depends: base", so cabal uses its compatibility tricks and builds it against base 3. It should specify "build-depends: base == 4.*". I need to investigate MissingH further. It failed because a dependency of its non-buildable test program was not found. That should not have been a problem. syb-with-class has type errors, I'm guessing due to changes in template-haskell package uvector does not compile because of the changes in GHC's Handle implementation. stringtable-atom now fails with a type error for reasons I don't quite understand: src/StringTable/AtomMap.hs:320:0: Occurs check: cannot construct the infinite type: a = (Int, a) When generalising the type(s) for `findMax' Perhaps some change in a containers function? bindings-common and c2hs fail because the CLDouble FFI type has been removed. binary-strict fails because the export of Control.Applicative.many now clashes with a local definition. base64-string fails because it sets -Werror in it's .cabal file (a practise which has been banned for some time for just this reason). Of the remaining 113: 2 failed at the configure step: MissingH-1.1.0.1 -- this needs investigation, I smell a cabal bug lax-0.1.0.0 52 failed at the build step (including those singled out above): ArrayRef-0.1.3.1 -- ghc Handle changes Boolean-0.0.0 -- name clash with Control.Applicative.<* CCA-0.1.1 -- TH changes, missing Lift instances ChasingBottoms-1.2.4 -- name clash with Data.Sequence.partition ChristmasTree-0.1.2 -- TH changes (Name vs TyVarBndr) HCodecs-0.1 -- Data.Array.Diff disappeared HList-0.2 -- change in GADT syntax (context) MonadLab-0.0.2 -- Some API change, not immediately obvious base64-string-0.1 -- described above binary-strict-0.4.6 -- described above bindings-common-1.3.4 -- described above bindings-gsl-0.1.1.6 -- CLDouble bloomfilter-1.2.6 -- declaration of a type or class operator `:*' bytestringparser-0.3 -- -Werror c2hs-0.16.0 -- CLDouble cabal2arch-0.6 -- Cabal API changes cabal2doap-0.2 -- Cabal API changes compact-map-2008.11.9 -- GHC Handle changes conjure-0.1 -- Data.Array.Diff disappeared flock-0.1 -- -Werror fail gtk2hs-cast-gtk-0.10.1.2-- type error, not immediately obvious hask-home-2009.3.18 -- Cabal lib API changes hgalib-0.2 -- Data.Array.Diff disappeared hircules-0.3.92 -- ambiguity GHC.IO.liftIO vs C.M.State.liftIO hnop-0.1 -- -Werror fail hommage-0.0.5 -- GHC.IO changes hxt-filter-8.3.0 -- name clash System.IO.utf8 and local name ideas-0.5.8 -- A pattern match on a GADT requires -XGADT ieee-0.6 -- CLDouble ivor-0.1.9 -- 'rec' now a keyword loch-0.2 -- -Werror fail nano-hmac-0.2.0 -- -Werror fail nanocurses-1.5.2 -- package specifies non-existant config.h (which used to accidentally pick up ghc's config.h) this happens because the package needs to run ./configure but does not say so. network-fancy-0.1.4 -- GHC Handle changes pkggraph-0.1 -- Cabal lib API changes plugins-1.4.1 -- Cabal lib API changes posix-realtime-0.0.0.1 -- type of internal IOError constructor printf-mauke-0.3 -- CLDouble pugs-HsSyck-0.41 -- mdo syntax removed? random-fu-0.0.3 -- type error, not immediately obvious rdtsc-1.1.1 -- -Werror fail repr-0.3.1 -- same as random-fu safe-lazy-io-0.1 -- GHC Handle changes sendfile-0.5 -- GHC Handle changes sessions-2008.7.18 -- needs -XTypeOperators stringtable-atom-0.0.6 -- described above syb-with-class-0.5.1 -- described above type-settheory-0.1.2 -- TH lib API changes uu-parsinglib-2.3.0 -- scoped type var changes? uuagc-0.9.12 -- 'rec' now a keyword uvector-0.1.0.5 -- GHC Handle changes word24-0.1.0 -- Not in scope: `divZeroError' The remaining 59 are knock-on failures, ie packages that depended on one of the failed packages. Duncan

1 0

Re: [Haskell-cafe] Hint causes GHCi linker error under Windows
by Daniel Gorín 14 Dec '09

14 Dec '09

Hi, Martin Do you have a complete example one can use to reproduce this behavior? (preferably a short one! :P) In any case, I'm resending your message to the glasgow-haskell-users list to see if a ghc guru recognize the error message. It is strange that the problem only manifests on Windows.... Daniel On Dec 11, 2009, at 7:04 AM, Martin Hofmann wrote: > The following hint code causes GHCi to crash under Windows: > >> runInterpreter $ loadModules ["SomeModule.hs"] > > The error message is: > > GHCi runtime linker: fatal error: I found a duplicate definition for > symbol _hs_gtWord64 whilst processing object file > C:\Programme\Haskell Platform\2009.2.0.2\ghc-prim-0.1.0.0 > HSghc-prim-0.1.0.o > This could be caused by: > * Loading two different object files which export the same symbol > * Specifying the same object file twice on the GHCi command line > * An incorrect `package.conf' entry, causing some object to be > loaded twice. > GHCi cannot safely continue in this situation. Exiting now. Sorry. > > The problem does not occur under Unix or with a compiled program. IMHO > hint tries to start a second instance of GHCi which is not > allowed/possible under Windows. If this is the case a more telling > error > message would be helpful. > > I used the Haskell Platform, version 2009.2.0.2 under Windows XP. My > package.conf is: > > C:/Programme/Haskell Platform/2009.2.0.2\package.conf: > Cabal-1.6.0.3, GHood-0.0.3, GLUT-2.1.1.2, HTTP-4000.0.6, > HUnit-1.2.0.3, MonadCatchIO-mtl-0.2.0.0, OpenGL-2.2.1.1, > QuickCheck-1.2.0.0, Win32-2.2.0.0, ansi-terminal-0.5.0, > ansi-wl-pprint-0.5.1, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, > bimap-0.2.4, bytestring-0.9.1.4, cgi-3001.1.7.1, > containers-0.2.0.1, cpphs-1.9, directory-1.0.0.3, (dph-base-0.3), > (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), > (dph-prim-seq-0.3), (dph-seq-0.3), extensible-exceptions-0.1.1.0, > fgl-5.4.2.2, filepath-1.1.0.2, (ghc-6.10.4), ghc-mtl-1.0.1.0, > ghc-paths-0.1.0.6, ghc-prim-0.1.0.0, haddock-2.4.2, > haskeline-0.6.2.2, haskell-src-1.0.1.3, haskell-src-exts-1.3.4, > haskell98-1.0.1.0, hint-0.3.2.1, hpc-0.5.0.3, html-1.0.1.2, > integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.4, old-locale-1.0.0.1, > old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1, > parsec-2.1.0.1, pointless-haskell-0.0.1, pretty-1.0.1.0, > process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2, > regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, > syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4, > utf8-string-0.3.6, xhtml-3000.2.0.1, zlib-0.5.0.0 > > Thanks, > > Martin > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

2 2

Running GHC 6.10.* on OpenBSD
by Thanos Tsouanas 12 Dec '09

12 Dec '09

Hello list. Up to now I've only used binary versions of GHC, but since my operating system's (OpenBSD) version of GHC is lagging behind (currently at 6.6.1), I need to update it. I tried using my system's ghc-6.6.1 to compile ghc-6.10.4 but it failed due to haskeline not being installed (and trying to install it also failed). I managed (woohoo!) to compile 6.8.3 using 6.6.1, but I could still not use 6.8.3 to compile 6.10.4. Even though I have installed haskeline using cabal in 6.8.3, the making of 6.10.4 breaks with the (weird?) message: cabal-bin: At least the following dependencies are missing: haskeline -any On the same machine (it's a laptop), I also have a partition with ubuntu linux installed (which has ghc-6.10.4 installed). So I thought I should try cross compiling, following the instrucions at the Porting wiki page. But this also failed at the first steps, with the complaint: GHC configuration does not support differing host/target (i.e. cross-compiling). Any suggestions / website links? Also, I understand what --host and --target are supposed to be, but I'm not clear on --build. Is there a more detailed document on building GHC, other than the Porting wiki? Thanks. P.S. I don't really use the ubuntu linux partition, so if there is an easier alternative that needs to install another system, I can do it over ubuntu's partition. -- Thanos Tsouanas http://mpla.math.uoa.gr/~thanos/

4 7

Re: Running GHC 6.10.* on OpenBSD
by Thanos Tsouanas 12 Dec '09

12 Dec '09

On Sat, Dec 12, 2009 at 10:22 AM, Karel Gardas <karel.gardas(a)centrum.cz> wrote: > Thanos Tsouanas wrote: >> Hello list. >> >> Up to now I've only used binary versions of GHC, but since >> my operating system's (OpenBSD) version of GHC is >> lagging behind (currently at 6.6.1), I need to update it. >> I tried using my system's ghc-6.6.1 to compile ghc-6.10.4 >> but it failed due to haskeline not being installed (and trying >> to install it also failed). > > Hello, > > it's already a long time since I installed ghc-6.10.3.20090530 on my > OpenBSD/amd64, but IIRC I really used system provided compiler and IIRC > I somehow managed to first install everything what's required on system > provided 6.6.1 to compile 6.10. I'm not sure if I went step by step > 6.6.1->6.8.3->6.10.3 as you try. Anyway I'm writing just to let you know > that it was somehow possible in the past and that you shall perhaps > concentrate on why it fails on your box. IMHO cross-compilation is no go > in this case since I hope I'm right assuming this is not supported in > 6.10, but was fixed in 6.12 again. Perhaps you are right, I should stay on my system instead of cross compiling. In any case, I could wait to crosscompile 6.12 once it's officially out. > In the worst case I can provide you my binary if your platform is the > same, but it's 300MB unpacked tree so it'll take some time to pack and > upload somewhere for you. Thanks a lot, but unfortunately I'm on OpenBSD/i386. Cheers. -- Thanos Tsouanas http://mpla.math.uoa.gr/~thanos/

1 0

Formal semantics for Core?
by Matthijs Kooijman 10 Dec '09

10 Dec '09

Hi All, I was wondering if there are any formal semantics defined for GHC's core language? I'm working with some core to core rewriting passes for which I'd like to verify the soundness, but that would require some formal definition of the Core semantics of sorts... Gr. Matthijs

4 4

Fwd: FFI and ghci
by Patrick LeBoutillier 07 Dec '09

07 Dec '09

Hi, I sent this question to haskell-cafe, realizing later that perhaps this list is a better place for it. Patrick ---------- Forwarded message ---------- From: Patrick LeBoutillier <patrick.leboutillier(a)gmail.com> Date: Fri, Dec 4, 2009 at 2:09 PM Subject: FFI and ghci To: Haskell Cafe <haskell-cafe(a)haskell.org> Hi all, I have a small FFI-based library that I like to test like this: $ ghci -I../c -L../c/.libs -lmlp t.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading object (dynamic) mlp ... done final link ... done [1 of 9] Compiling MLP ( MLP.hs, interpreted ) [2 of 9] Compiling MLP.Error ( MLP/Error.hs, interpreted ) [3 of 9] Compiling MLP.Context ( MLP/Context.hs, interpreted ) [4 of 9] Compiling MLP.Runtime ( MLP/Runtime.hs, interpreted ) [5 of 9] Compiling MLP.Object ( MLP/Object.hs, interpreted ) [6 of 9] Compiling MLP.Type ( MLP/Type.hs, interpreted ) [7 of 9] Compiling MLP.Value ( MLP/Value.hs, interpreted ) [8 of 9] Compiling MLP.Language ( MLP/Language.hs, interpreted ) [9 of 9] Compiling Main ( t.hs, interpreted ) Ok, modules loaded: MLP, MLP.Object, Main, MLP.Runtime, MLP.Context, MLP.Error, MLP.Value, MLP.Type, MLP.Language. *Main> main Note: Inside libmlp.so, another shared object is loaded using dlopen(). When running this test program I get some sporadic segmentation faults, which seem to always occur at entrypoint to the shared object that is loaded with dlopen(). But when I compile it with ghc, i.e. $ ghc --make -I../c -L../c/.libs -lmlp t.hs I can't reproduce crash. Can anyone see why this could be happening? It's quite possible that there is really a bug in the C code, but if someone knows about a bug or something in ghci that can cause this behaviour I can stop looking... Thanks a lot, Patrick -- ===================== Patrick LeBoutillier Rosemère, Québec, Canada

2 1