- Glasgow-haskell-users

You can now register a trac user for yourself
by Ian Lynagh 23 Nov '07

23 Nov '07

Hi all, It is now possible to register a new user account for yourself on the GHC trac. To do so, make sure you are logged out and then click the "register" link at the top-right, or go to this URL: http://hackage.haskell.org/trac/ghc/register Making your own account preferred over using the guest account, as it means we know who to contact if we have a query about a bug report you make, e.g. if we are unable to reproduce it. Thanks Ian

4 4

Windows overlapped IO
by Felix Martini 22 Nov '07

22 Nov '07

I have made a prototype for overlapped IO that works with a modified version of Takano Akio's SSC library. I have been trying to add it to GHC's IO implementation but there are some issues. Instead of file descriptors windows handles are needed. The GHC handle implementation is currently based around fd's and many functions would need a separate windows API version. In some cases there is no simple conversion of existing functionality like the binary/text modes. An additional complication is that Haskell handles can be a lot of things other than files. Finally, a threaded rts is needed for the worker pool that processes the IO completions, so the current single threaded IO support must also remain. So for now i am focusing on testing and improving the prototype with a separate IO library. Best regards, Felix

2 2

ghci changing 'm' to 'g'
by Greg Fitzgerald 22 Nov '07

22 Nov '07

Running 6.8.1 on Windows XP, typing 'main' while ":r" is still processing causes the 'm' in 'main' to morph to a 'g'. > :r [1 of 2] Compiling Language.QidlTypeLibrary.Parser ( Language/QidlTypeLibrary/Parser.hs, interpreted ) Ok, modules loaded: Main, Language.QidlTypeLibrary.Parser. > main <interactive>:1:0: Not in scope: `gain' Thanks, Greg

6 8

[Fwd: Re: suggestion: add a .ehs file type]
by Richard Giraud 22 Nov '07

22 Nov '07

A pre-processor is a great idea. Template Haskell and Cabal make it possible to extend the language by adding all kinds of funky pre-processing (via Cabal hooks) and compile-time calculations. It wouldn't be too difficult to add a package-specific .ehs file type with the desired behavior. I'm currently using this combo to work around the TH limitation of not being able to generate import statements. A Cabal hook looks in a directory to find what .hs files are present, spits out an intermediate file that imports all of these files, and Cabal compiles the generated file into the final program. I think that the biggest limitation of this setup is managing the files if multiple stages of pre-processing are performed. Richard -------- Original Message -------- Subject: Re: suggestion: add a .ehs file type Date: Thu, 22 Nov 2007 10:19:57 +0000 From: Lennart Augustsson <lennart(a)augustsson.net> To: Simon Marlow <simonmarhaskell(a)gmail.com> CC: Alex Jacobson <alex(a)alexjacobson.com>, glasgow-haskell-users(a)haskell.org References: <47434E64.1070206(a)alexjacobson.com> <200711202239.57672.g9ks157k(a)acme.softbase.org> <474354D4.7010307(a)alexjacobson.com> <4743F6B4.9050505(a)gmail.com> <47447B2B.8090206(a)alexjacobson.com> <47454879.8040003(a)gmail.com> Or use a preprocessor that inserts a LANGUAGE pragma. :) On Nov 22, 2007 9:14 AM, Simon Marlow <simonmarhaskell(a)gmail.com <mailto:simonmarhaskell@gmail.com>> wrote: Alex Jacobson wrote: > In any case, I'm pretty sure the correct answer is not 50 language > pragmas with arbitrary spellings for various language features at the > top of each source file. You probably won't like any of these, but there are many ways to avoid writing out all the pragmas at the top of each file. 1. Use Cabal's extensions field. 2. Use CPP MyExtensions.h : {-# LANGUAGE TemplateHaskell, FlexibleInstances, OverlappingInstances, UndecidableInstances, CPP, ScopedTypeVariables, PatternSignatures, GADTs, PolymorphicComponents, FlexibleContexts, MultiParamTypeClasses, DeriveDataTypeable, PatternGuards #-} MyModule.hs: {-# LANGUAGE CPP #-} #include "MyExtensions.h" 3. Use a shell alias alias ghce='ghc -XTemplateHaskell -XFlexibleInstances ...' 4. use a script wrapper for GHC #!/bin/sh exec ghc -XTemplateHaskell -XFlexibleInstances ... $* I'm sure there are more... Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

if-them_else
by Serge D. Mechveliani 22 Nov '07

22 Nov '07

Dear GHC developers, when compiling the function f x = if x them False else True ghc-8.8.1 reports: " parse error on input `else' ". When there is a large expession after `them', it is sometimes difficult to locate a typo. Why does not it report " parsing if-then-else: cannot find `then' " ? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 3

GHC 6.8.1 and HDirect
by Fernand 21 Nov '07

21 Nov '07

Hi dear fellow ghc users, I simply wanted to let people know that I apparently succeeded in compiling a patched version of HDirect with GHC 6.8.1 (with typelibs support). At least, I could compile some of the examples and had very simple test programs launch/connect to Word and Excel using automation. I lack time to really clean up the library (I did not made any Cabal patch and currently directly link with the « .a » and « .o » of the various modules), but feel free to contact me if you need some help to use hdirect with GHC 6.8.1. Sincerely yours, sL

1 0

ghc 6.8.1 windows link issue ?
by Fernand 21 Nov '07

21 Nov '07

Dear all, Giving a try to GHC 6.8.1 under Windows, I stumble upon the following issue (yes, I'm struggling with HDirect), which did not occur with the 6.6 version : the linking phase of my project fails with $ C:/ghc/ghc-6.8.1/bin/ghc -o ihc.exe -fglasgow-exts -static -fvia-C -Rghc-timing -Wall -recomp AbsHUtils.o AbstractH.o Attribute.o Bag.o [... lots of files, among which we have CoreUtils.o ...] CoreUtils.o(.text+0x15066):ghc2436_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' CoreUtils.o(.text+0x150b0):ghc2436_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' CoreUtils.o(.text+0x1ac23):ghc2436_0.hc: undefined reference to `__stginit_containerszm0zi1zi0zi0_DataziGraph_' IDLUtils.o(.text+0x6026):ghc768_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' IDLUtils.o(.text+0x6070):ghc768_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' IDLUtils.o(.text+0xc607):ghc768_0.hc: undefined reference to `__stginit_containerszm0zi1zi0zi0_DataziGraph_' collect2: ld returned 1 exit status Indeed, that symbol is undefined in the CoreUtils file : $ nm CoreUtils.o | grep strongl U _containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure As far as I understand, this is a reference to the Data.Graph function stronglyConnComp (which can be seen in the « containers-0.1.0.0/Data/Graph.hi » interface file ; according to the haddock documentation of GHC, that function is indeed in the Data.Graph module, which is imported by the CoreUtils.lhs file). What is strange to me is that $ nm libHSghc.a | grep strongl gives : 00000598 D _ghczm6zi8zi1_Digraph_stronglyConnComp_closure which could explain why that function is not found. May be I'm looking at the wrong file, I don't know much of the linking and name-mangling process at hand here (Digraph vs. DataziGraph ?). What I do not understand is what causes that issue, which seems to only concern the Data.Graph module so far. Hopes this makes sense to you, Sincerely yours, Samuel

2 3

Re: [Haskell] recursive deriving
by Duncan Coutts 21 Nov '07

21 Nov '07

On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote: > When you want automated deriving of show/read etc., you need all the > components of your type also to be instances of show/read but you won't > want to *require* them to be automatically generated verions. > > Standalone deriving does the wrong thing here. Standalone deriving > should not cause an overlapping instance error if someone derives an > instance manually. Instead, the manually derived instance should be > treated as more specific and win out. > > The other part of this problem is that you can't do automatic recursive > deriving and this results in a ridiculous amount of boilerplate. I know > some people have a theory that they want to avoid accidentally creating > instances for things that shouldn't have them, but the solution to that > is probably to add some declaration for types that prohibits automatic > deriving for those types. The 99% case is that automatic deriving is ok. > > Proposed syntax: > > derive instance Show T recursively > data T = T no-deriving (Ord,Eq) I would expect that if the data constructor for T is not exported then standalone deriving should not work. However this appears not to be the case which breaks module abstraction. Foo.hs: module Foo ( T, t ) where data T = T t = T Bar.hs: import Foo deriving instance Eq T $ ghci Bar.hs -XStandaloneDeriving [1 of 2] Compiling Bar ( Bar.hs, interpreted ) [2 of 2] Compiling Main ( Baz.hs, interpreted ) Ok, modules loaded: Bar, Main. *Main> t == t True You could write that Eq instance by hand since they do not have access to the T constructor, then StandaloneDeriving should not be able to so either. I think it's a design flaw in standalone deriving. Does anyone else agree? Should we file a bug report? Duncan

3 2

Exposed module still hidden, why?
by Greg Fitzgerald 21 Nov '07

21 Nov '07

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 "C:\ghc\ghc-6.8.1\package.conf". That package.conf file has the 'exposed' set to True for that file. Why does GHC still think the package is hidden? ...\haddock-0.8>runhaskell Setup.lhs configure Configuring haddock-0.8... ...\haddock-0.8>runhaskell Setup.lhs build Preprocessing executables for haddock-0.8... shift/reduce conflicts: 5 Building haddock-0.8... src/Main.hs:49:7: Could not find module `System.Directory': it is a member of package directory-1.0.0.0, which is hidden ...\haddock-0.8>ghc-pkg list C:/ghc/ghc-6.8.1\package.conf: Cabal-1.2.2.0, HUnit-1.2.0.0, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, Win32-2.1.0.0, array-0.1.0.0, base-3.0.0.0, bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.0, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.1), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.1, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, xhtml-3000.0.2.1 Thanks, Greg

4 3

ANNOUNCE: Important bug fix for regex-pcre ByteStrings.
by ChrisK 21 Nov '07

21 Nov '07

Greetings, There are new version 0.82 and 0.93 of regex-posix. If you use regex-posix with Data.ByteString then you should upgrade to obtain a fix for a crash error. There are new version of regex-pcre available on hackage and the two darcs repositories: http://darcs.haskell.org/packages/regex-pcre/ for "stable" version 0.82 and http://darcs.haskell.org/packages/regex-unstable/regex-pcre/ for "unstable" version 0.93 The new version regex-pcre-0.82 replaces the broken version 0.81 The new version regex-pcre-0.93 replaces the broken version 0.92 I apologize for the error. I took the address of the ByteString to give to the pcre library by using unsafeUseAsCStringLen. I had not appreciated that this can return a null pointer for an empty ByteString. My code caught this null pointer and reported it, however, and so a good error message sent in by a user allowed me to quickly find and hopefully fix it. For version 0.92 the error also applied to Lazy ByteStrings. In case anyone is curious, the fixed code checks the pointer returned by unsafeUseAsCStringLen and replaces a null pointer to a non-null pointer to a private private bytestring "myEmpty" with the length set to 0 by "trim": > {-# INLINE asCStringLen #-} > asCStringLen :: ByteString -> (CStringLen -> IO a) -> IO a > asCStringLen s op = B.unsafeUseAsCStringLen s checked > where checked cs@(ptr,_) | ptr == nullPtr = B.unsafeUseAsCStringLen myEmpty (op . trim) > | otherwise = op cs > myEmpty = B.pack [0] > trim (ptr,_) = (ptr,0) This fix is motivated by desiring to ensure asCStringLen never passes a null pointer to "op" and that no memory copy operations are used. The safe "useAsCString(Len)" do not appear capable of returning a null pointer. Only "unsafeUseAsCString(Len)" on an empty bytestring might return a null pointer. -- Chris

1 0