September 2002 - Glasgow-haskell-users

Packages (again)
by Koen Claessen 09 Sep '02

09 Sep '02

Hi all, Now, I am almost done with trying to install this package I am working on. But, somehow, I can't get it to work for both ghc and ghci. I have the following simplified situation: * a Haskell module, Foo.hs * a C file, foo.c * a C library that foo.c needs, /path/to/libs/libbar.so (I only have a .so version of the library.) I configured the package file as follows: >>> Package { name = "foo", import_dirs = ["FooPath"], source_dirs = ["FooPath"], library_dirs = ["FooPath"], hs_libraries = ["HSFoo"], extra_libraries = [], include_dirs = [], c_includes = [], package_deps = [], extra_ghc_opts = ["-L/path/to/libs", "-lbar"], extra_cc_opts = [], extra_ld_opts = [] } <<< (adding the linker flags to ld_opts does not make a difference for the rest of the story) To make everything work with ghc, I do the following: * gcc -c foo.c -o foo.o * ghc -c Foo.hs -o Foo.o * ar -rsv libHSFoo.a foo.o Foo.o Now, I can compile programs with "ghc -package foo". Great! However, when I try ghci, it does not work. So, first, I make a .o version of libHSFoo.a: * gld -r --whole-archive -o HSFoo.o libHSFoo.a But, when I start "ghci -package foo", it does not find the library libbar! It does not even find it when I say "ghci -L/path/to/libs -lbar -package foo"! No worries, we can make ghci read a .so file instead: * rm HSFoo.o * gcc -shared Foo.o foo.o -L/path/to/libs -lbar -o libHSFoo.so Starting ghci now loads libHSFoo.so, and everything works wonderfully. Sadly, when I try to compile something with ghc now, it tries to load the .so version too (instead of the .a version) and gets mad at me. What should I do? /Koen.

1 0

RE: Hierarchical modules (was: Packages)
by Simon Marlow 09 Sep '02

09 Sep '02

> Simon Marlow wrote: > > | > - I can add my own packages, can I add my own modules to > | > the hierarchy? > | > | Yes, a package can contain hierarchical modules. > > So how do I add a hierarchical module? Suppose you want to have a package containing module Foo.Bar.Baz. You make a package spec containing the line import_dirs=["D"], for some directory D, and you put Baz.hi in D/Foo/Bar/Baz.hi. Cheers, Simon

1 0

RE: Packages
by Simon Marlow 09 Sep '02

09 Sep '02

> I have two questions, related to packages. > > 1) What is the relationship between the new and cool > hierarchical module structure and packages? Packages used to > be a way of avoiding name clashes on module level, but that > role has been taken over by the new module system. There are still two reasons for packages to exist: - they are a useful unit of distribution - they reduce link times and GHCi startup time compared to having all your libraries always linked in A separate question is whether you should have to say explicitly '-package foo' on the command line in order to get access to package foo. Simon & I have discussed this and come up with the following conclusion: - package which contain hierarchical modules should be marked 'auto' in the package config. - any package marked 'auto' is always available when using ghc --make and GHCi. The compiler can infer which packages are actually used and link them in as required (I believe the machinery for this is in place as part of Simon's Template Haskell work). - packages not marked 'auto' have to be specified on the command line. - for "one-shot" compilation, i.e. without --make, we can either require you to specify the 'auto' packages, or just link them all in. I'm not sure which I prefer. > Several sub-questions: > > - I can add my own packages, can I add my own modules to > the hierarchy? Yes, a package can contain hierarchical modules. > - Can the package system be complete taken over by the > module system? I.e. relating certain .a, .so, .dll files > and compiler flags with certain parts of the module > hierarchy? That's essentially what the package system does. Every interface file currently contains the name of the package to which it belongs. We *also* separate packages in the file system, but that isn't necessary. > 2) I am trying to install my own package. I do not have > write access to GHC's package.conf. So, I make my own. But: > > >>> > [cth/Yahu] -: more yahu.conf > [Package > {name = "yahu", > import_dirs = ["/users/cs/koen/Code/Ghc/Yahu"], > source_dirs = [], > library_dirs = ["/users/cs/koen/Code/Ghc/Yahu"], > hs_libraries = [], > extra_libraries = [], > include_dirs = [], > c_includes = [], > package_deps = [], > extra_ghc_opts = [], > extra_cc_opts = [], > extra_ld_opts = ["-lyahu"], > framework_dirs = [], > extra_frameworks = []}] > [cth/Yahu] -: ghc --package-conf yahu.conf -package yahu --make Test > ghc-5.04: unknown package name: yahu > <<< The -package-conf option only has one dash. Due to the way GHC parses options, the missing package is reported before the unrecognised flag. It's regrettably confusing, I know. Cheers, Simon

2 1

RE: Packages (again)
by Simon Marlow 09 Sep '02

09 Sep '02

> Does anyone know how to create .a files for use with > packages? I have the following situation: > > A directory 'PACK' with a number of ghc-generated object > (.o) files. > > When I do the following: > > $ ghc Test.o PACK/*.o -o Test > > everything works fine. However, when I say: > > $ cd PACK > $ ar -rvs libPack.a *.o > $ cd .. > > And then do the following: > > $ ghc Test.o -LPACK -lPack -o Test > > GHC starts complaining about "warning: type and size of > dynamic symbol `<ModuleName>_<FunctionName>_closure' are not > defined". These are precisely the functions that the module > Test is using. Do you by any chance also have a libPack.so lying around? Cheers, Simon

2 1

Packages (again)
by Koen Claessen 09 Sep '02

09 Sep '02

Dear all, Does anyone know how to create .a files for use with packages? I have the following situation: A directory 'PACK' with a number of ghc-generated object (.o) files. When I do the following: $ ghc Test.o PACK/*.o -o Test everything works fine. However, when I say: $ cd PACK $ ar -rvs libPack.a *.o $ cd .. And then do the following: $ ghc Test.o -LPACK -lPack -o Test GHC starts complaining about "warning: type and size of dynamic symbol `<ModuleName>_<FunctionName>_closure' are not defined". These are precisely the functions that the module Test is using. The above generates an executable, but results in a segmentation fault. Naturally, libPack.a cannot be used for a package either. (Getting the same results.) What am I doing wrong? I am doing all this with ghc5.04 on SunOS4. Thanks, /Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen Chalmers University, Gothenburg, Sweden.

1 0

Packages
by Koen Claessen 09 Sep '02

09 Sep '02

Dear all, I have two questions, related to packages. 1) What is the relationship between the new and cool hierarchical module structure and packages? Packages used to be a way of avoiding name clashes on module level, but that role has been taken over by the new module system. Several sub-questions: - I can add my own packages, can I add my own modules to the hierarchy? - Can the package system be complete taken over by the module system? I.e. relating certain .a, .so, .dll files and compiler flags with certain parts of the module hierarchy? 2) I am trying to install my own package. I do not have write access to GHC's package.conf. So, I make my own. But: >>> [cth/Yahu] -: more yahu.conf [Package {name = "yahu", import_dirs = ["/users/cs/koen/Code/Ghc/Yahu"], source_dirs = [], library_dirs = ["/users/cs/koen/Code/Ghc/Yahu"], hs_libraries = [], extra_libraries = [], include_dirs = [], c_includes = [], package_deps = [], extra_ghc_opts = [], extra_cc_opts = [], extra_ld_opts = ["-lyahu"], framework_dirs = [], extra_frameworks = []}] [cth/Yahu] -: ghc --package-conf yahu.conf -package yahu --make Test ghc-5.04: unknown package name: yahu <<< What is going on? Thanks, /Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen Chalmers University, Gothenburg, Sweden.

1 0

Half Price Cigarettes and Tobacco
by Sales Department 07 Sep '02

07 Sep '02

Dear Sir or Madam In the past you have requested information on discounted products. We hope that you find this of interest. If you are not a smoker, and find this email offensive, we sincerely apologise! We will be only too happy to take you off our mailing list. If you are a smoker, however, and are fed up with paying high prices for your cigarettes and tobacco, take a look at what we have to offer by clicking on this link. http://www.smokersunited.co.uk/?S=15&ID=2 We can send you, legally, by registered air mail, direct to your door, 4 cartons of cigarettes or 40 pouches of rolling tobacco (all brands are available) from only 170 Euros - about 105 pounds - fully inclusive of postage and packing. Why pay more? To remove yourself from our mailing list, please click below mailto:smokersclub@terra.es Yours faithfully. Smokers United http://www.smokersunited.co.uk/?S=15&ID=2 xay1y

1 0

Re: default class method types... (unification)
by MR K P SCHUPKE 06 Sep '02

06 Sep '02

ah - of course... so if I have an instance instance A m m where f = id all works well! I still have a problem though - perhaps it is also possible to avoid... I am trying to define a parametric continuation monad transformer (from a paper by Ralf Hinze...) however the functions as given have type errors... in particular the following (which is similar to the simple case I just gave) class (Monad tm,MonadT (t tm)) => MonadT t tm where up ::tm ta -> t tm ta down :: t tm a -> tm ta we define the type for our parametric continuation: data ContT ans m a = CT ((a -> m ans) -> m ans) instance Monad m => MonadT (ContT ans) m where up m = CT $ \kappa -> m >>= kappa down (CT m) = m return however this gives a unification error (less polymorphic than expected) for the definition of down (that `a' is unified with `ans')?? Regards, Keean Schupke. Martin Norbäck wrote: >fre 2002-09-06 klockan 15.01 skrev MR K P SCHUPKE: > >>If I have a class: >> >>class A m n where >> f :: m a -> n a >> >>I can declare instances >> >>instance A Maybe Maybe where >> f = id >> >>instance A [] [] where >> f = id >> >>but if I try and put a default method: >> f = id >> >>I get a unification error (less polymorphic than expected).This seems >>a little odd - is there a work around for this? >> > >Because that default method only works when m=n, which it's not in the >general case. >

1 0

default class method types... (unification)
by MR K P SCHUPKE 06 Sep '02

06 Sep '02

If I have a class: class A m n where f :: m a -> n a I can declare instances instance A Maybe Maybe where f = id instance A [] [] where f = id but if I try and put a default method: f = id I get a unification error (less polymorphic than expected).This seems a little odd - is there a work around for this? Regards, Keean Schupke, Department of Electrical & Electronic Engineering, Imperial College London.

2 1

RE: Why does GHC replace implicit tabs by spaces
by Simon Marlow 06 Sep '02

06 Sep '02

> I am a bit surprised that GHC replaces " Hallo" > (I used a tab > here - used not coded ('\t').) > by " Hallo". (GHC > replaced the > tab by 8 spaces.) > Is this a bug? Hugs keeps the tab. > (See the attached code, and output from Hugs and GHC. I am > using ghc-5.04 and WinNT.) Both Hugs & GHC are wrong. Literal tabs aren't valid inside a string literal according to Haskell 98; if you want a tab, use '\t'. Cheers, Simon

1 0