- Libraries - Haskell.org

on when to build ghci libs in cabal
by Isaac Jones 08 Aug '05

08 Aug '05

Henning Günther and Duncan Coutts / the Gentoo team have sent me a patch to move creation of ghci libs to the build phase rather than the register phase. It makes more sense there and should be somewhat better for debian and gentoo. Though Duncan points out that maybe some ppl want to build the ghci libs during register because it could save room in a binary distribution (like debian and rpm). Any opinions here? Also, I noticed the "FIXME" that mentions the -x flag is only supported on some platforms; what effect will this have on platforms that don't support it? Will they be broken during build? What about platforms where we know the ghci libs don't work, like MacOS; will this patch cause building to break? The patch adds a couple extra configure options, --enable-library-for-ghci / --disable-library-for-ghci. I'm sorta thinking of just having one option "--disable-interpreter-libs" or something to make this seem more generic, though at the moment, it still only makes sense for a combo compiler / interpreter build (that is, --ghc). I'll be happy to add this to the manual once we settle on a flag. Do we ever really need to disable it anyway? peace, isaac

4 4

RE: package description fields
by Simon Marlow 08 Aug '05

08 Aug '05

On 04 August 2005 08:24, Krasimir Angelov wrote: > I would like to propose more Unix like directory layout for Windows > i.e.: > > executables: %ProgramFiles%\<pkg-name>\bin > libraries: %ProgramFiles%\<pkg-name>\lib > data files: %ProgramFiles%\<pkg-name>\data > > The advantage is that if you have a lot of libraries and data files > then it is easier to find out the executable files. Happy, Alex and > Haddock already use layout like in the Ross's proposal but I found it > very inconvenient because usually I am building them together with > ghc. The problem is that when I do make install in the fptools > directory then ghc is installed in ${prefix}/bin but the above tools > are installed in ${prefix}. Usually then ${prefix} directory isn't > included in the PATH and this makes them inaccessible. I can move them > to ${prefix}/bin but then I have to move all other template files too. > It would be nice if we had more consistent directory layout. Your complaint here seems to be that the default layout of Happy, Alex and Haddock is different from that of GHC on Windows, which makes it harder to combine all these tools in a single package. As far as Cabal is concerned, I think the defaults are fine. However, I do think we should allow the default $bindir/$libdir/$datadir to be overridden (I know this has been discussed before). On Windows, an application often finds its files relative to the location of the executable, so the values of $bindir/$libdir/$datadir need to be passed to the program at build time, perhaps via CPP symbols. So, I suggest we have: --bindir=<dir> --libdir=<dir> --datadir=<dir> where the values of these would be directories relative to $prefix (or absolute? relative to $prefix seems nicer). And when processing with CPP, Cabal would pass -DBINDIR=<dir> -DLIBDIR=<dir> -DDATADIR=<dir>. Using this, Krasimir could configure Happy, Alex and Haddock to use a layout compatible with GHC, whereas the defaults would reamin as they are. Cheers, Simon

2 1

cabal release?
by Isaac Jones 08 Aug '05

08 Aug '05

I would like to make a Cabal release Real Soon Now, version 1.0.2. There are always more changes that would be good to get in, but we have to release sometime. This is just a minor release, and it's not being released with a compiler like the 1.0 release, so it doesn't need to be "perfect". We haven't exactly been releasing early and often, but in that spirit, let's get the many changes since 1.0 out into the wild. Here's a summary from the changelog: * Handles recursive modules for GHC 6.2 and GHC 6.4. * Added "setup test" command (Used with UserHook) * implemented handling of _stub.{c,h,o} files * Added support for profiling * Changed install prefix of libraries (pref/pkgname-version to prefix/pkgname-version/compname-version) * Added pattern guards as a language extension * Moved some functionality to Language.Haskell.Extension * Register / unregister .bat files for windows * Exposed more of the API * Added support for the hide-all-packages flag in GHC > 6.4 * Several bug fixes Oh, and though it's not a big change from Cabal's perspective, there are some changes that are necessary to get Hackage out the door. Does anyone know of any: - critical bugs that we shouldn't release without fixing - interface changes that are so horrible that we shouldn't release without fixing them I'm a bit concerned about the different release cycles that Cabal and the compilers will be following, but I think that if we are careful with version numbers we'll be OK :) peace, isaac

4 10

RE: Cabal should use the minimum version that satisfies thedependencies, not the maximum
by Simon Marlow 08 Aug '05

08 Aug '05

On 08 August 2005 07:45, Brian Smith wrote: > Let's say we have multiple versions of a package installed: > a-1.0 > a-1.0.1 > a-1.1 > a-2.0 > and that we have the following Build-Depends in a package description: > Build-Depends: a >= 1.0 > > Now, when I configure, Cabal will choose a-2.0 as the package to build > with. However, it makes more sense to choose a-1.0 by default instead. I don't agree, there is just as much potential for breakage with this choice, and it will cause problems if someone is trying to upgrade their system incrementally. If I have both a-1.0 and a-2.0 installed, I probably don't want any new dependencies on a-1.0, because I want to delete it at some point. > * Currently, if we change the program to require a feature that is in > a-2.0, but not in a-1.0, then the build will succeed for _us_, but it > will fail unexpectedly for someone else that has only a-1.0. However, > if Cabal instead chose the minimum version available, then, _our_ > build would fail, and we would know that we need to either remove the > dependency on the a-2.0 feature or increase the version specified in > Build-depends. Conversely, if the author builds with a-1.0, and the recipient builds with a-2.0 and version 2.0 is not backwards compatible, then the package will break. If the package depends on a-1.0 rather than a>=1.0, then it should say so. > * a-2.0 is not guarenteed to be 100% backwards-compatible with a-1.0. > Even a-1.0.1 is not guarenteed to be backwards-compatible. So, if the > original author was really testing with a-1.0, then we are more likely > to run into problems with a-2.0 (or even a-1.0.1) than a-1.0. This is true, but most people will not have multiple versions of a package installed. Furthermore, we'd like to discover problems early, and this just hides the bug in the dependency specification. Cheers, Simon

1 0

Cabal should use the minimum version that satisfies the dependencies, not the maximum
by Brian Smith 08 Aug '05

08 Aug '05

Let's say we have multiple versions of a package installed: a-1.0 a-1.0.1 a-1.1 a-2.0 and that we have the following Build-Depends in a package description: Build-Depends: a >= 1.0 Now, when I configure, Cabal will choose a-2.0 as the package to build with. However, it makes more sense to choose a-1.0 by default instead. * Currently, if we change the program to require a feature that is in a-2.0, but not in a-1.0, then the build will succeed for _us_, but it will fail unexpectedly for someone else that has only a-1.0. However, if Cabal instead chose the minimum version available, then, _our_ build would fail, and we would know that we need to either remove the dependency on the a-2.0 feature or increase the version specified in Build-depends. * a-2.0 is not guarenteed to be 100% backwards-compatible with a-1.0. Even a-1.0.1 is not guarenteed to be backwards-compatible. So, if the original author was really testing with a-1.0, then we are more likely to run into problems with a-2.0 (or even a-1.0.1) than a-1.0. We might say that a-1.0.1 is probably a bugfix for a-1.0 that does not change the API for the package. But, we can only guess about that; maybe a-1.1 is a bugfix release too, but probably not. Furthermore, it might be the case that the library/program in question is not affected by the bugs in a-1.0, in which case it is okay to use a-1.0 even if a-1.0.1 is available. And, if it is affected, then the Build-depends should be changed to a >= 1.0.1 anyway. Practically, a package author will often want his package to work with the minimum versions of its dependencies AND the maximum versions at the same time. To support this, we might want to add a flag to "configure" that says "choose the maximum versions instead of the minimum versions" which would result in the the current behavior. This would allow the package author to build and test his package twice, once with its minimum dependencies (by omitting the flag), and once with the latest versions (by including the flag). - Brian

2 1

dropWhileRev
by Henning Thielemann 07 Aug '05

07 Aug '05

Is this function worth to be added to Data.List? {-| Remove the longest suffix of elements satisfying the predicate. In contrast to 'reverse . dropWhile p . reverse' this works for infinite lists, too. -} dropWhileRev :: (a -> Bool) -> [a] -> [a] dropWhileRev p = foldr (\x xs -> if p x && null xs then [] else x:xs) []

3 3

Re: Foreign language parsers
by Dimitry Golubovsky 05 Aug '05

05 Aug '05

Dominic, You wrote: ========================== Has anyone looked at positioning foreign language parsing modules in the standard libs, or specifying a common framework or contract for such modules? ========================== I wrote up a proposal earlier on this list how to extend Cabal to integrate hsffig (and I believe tools like c2hs might be integrated the same way, if not integrated already). As for "library use", one of the future directions of hsffig development may be adding a wrapper around its parser to represent parsing results as a collection of items, with possiblilty to run queries over it such as: - get the list of constants whose name matches a regexp - get the name of the enumeration containing the given constant etc. This might help develop custom wrappers, like one John Goerzen developed for openldap. -- Dimitry Golubovsky Anywhere on the Web

1 0

Cabal proposal: user-configurable prefixes (thinking of HSFFIG integration as a preprocessor)
by Dimitry Golubovsky 03 Aug '05

03 Aug '05

I have been thinking how HSFFIG (Isaac once suggested this) could be integrated with Cabal as a preprocessor. The problem is, external library header file might be located arbitrarily, up to the decision of local system maintainer. I am proposing to extend the "setup configure" command. Currently, one may invoke: setup configure --with-alex=/path/to/alex/installed/bin/alex If however a .cabal file contained stanzas like this: user-prefix-key: mylib user-prefix-default: /usr/local/lib user-prefix-help: The library absolutely necessary to build this package and the cabal program was appropriately modified (I realize this may be hard) then it would become possible to run: setup configure --with-mylib=/path/to/the/location/of/mylib/installed and setup-configure --help would mention --with-mylib as one of the possible configuration options. Then if someone is installing a package requiring this library, and its installation is not done in standard way, it is up to that person to locate the library. Going further, this "mylib" token might become a part of the `extra-lib-dirs' field: extra-lib-dirs: $mylib to be substituted with whatever the user specifies as --with-mylib. And then a new field needs to be added to the .cabal file format: extra-include-dirs: $mylib/../include because a library may be installed anywhere, but relative position of its include files and the library itself is unlikely to vary. This extra-include-dirs will be used by the wrapper for HSFFIG, so that these tokens will be passed to the C preprocessor telling where to look for headers. And then HSFFIG may be fit in the preprocessors framework of Cabal. Suppose we have a file MYLIB.h in the directory where other source files are placed. Then, having defined HSFFIG as a preprocessor for .h suffix (I will have to write a replacement of the HSFFIG main program so that the module name will match the header name without postfixing with "_H"), MYLIB.h will be converted to MYLIB.hs (or more files if the splitter is applied) MYLIB.h will contain then just this #include <mylib.h> assuming that the library's include file is mylib.h. As the extra-include-dirs will be passed properly to the C preprocessor, the library include file will be found correctly. PS I understand, this may be hard to implement and I am ready to help with coding if there is interest in such an integration. -- Dimitry Golubovsky Anywhere on the Web

1 0

Announce: HSFFIG 1.0 Stable Release
by Dimitry Golubovsky 01 Aug '05

01 Aug '05

Dear List Subscribers, I am pleased to announce the first stable release of HSFFIG, yet another tool for autogeneration of FFI bindings from C include files. The project is now hosted at Sourceforge: http://hsffig.sourceforge.net Downloads page: http://www.sourceforge.net/projects/hsffig Darcs repo: darcs get http://hsffig.sourceforge.net/repos/hsffig-1.0 Tutorial: http://www.haskell.org/hawiki/HsffigTutorial The wiki page "HsffigExamples" has been separated from the Tutorial. If anybody has an interesting example of using HSFFIG please update the page with code samples. Brief summary of changes: - The distribution is now cabalized. Please read the INSTALL file. - The multiparameter class and combinators to access members of structures/unions are moved to separate library. It is necessary to specify -package HSFFIG when compiling applications. Thanks to everybody who participated in discussions related to HSFFIG on this list, and privately. This helped me with implelentation of some features and gave some ideas for future improvement. Debian, RPM, and other packagers: if you create a HSFFIG package please let me know the package URL so I can update the Freshmeat project information page, and the project homepage. For any problems related to this project feel free to contact me. -- Dimitry Golubovsky

1 0

RE: [Haskell] runProcess with out=err
by Simon Marlow 01 Aug '05

01 Aug '05

On 28 July 2005 14:35, Ian Lynagh wrote: > With the below code (compiled by ghc) I get > "a.out: thread blocked indefinitely". > > Changing the second (Just hout) to Nothing makes it run as expected. > > If I dup fdout to get an fderr and then try to also convert that to > a handle then I get "a.out: openFile: resource busy (file is locked)". > > Is there a way to write this with stdout and stderr going to the same > handle? > > ------------------- > module Main (main) where > > import System.Posix (openFd, defaultFileFlags, stdFileMode, > OpenMode(ReadOnly, WriteOnly), fdToHandle) > import System.Process (runProcess, waitForProcess) > > main :: IO () > main = exec "echo" ["foo"] "in" "out" > > exec :: String -> [String] -> FilePath -> FilePath -> IO () > exec c args inp out > = do fdin <- openFd inp ReadOnly Nothing defaultFileFlags > fdout <- openFd out WriteOnly (Just stdFileMode) > defaultFileFlags hin <- fdToHandle fdin > hout <- fdToHandle fdout > ph <- runProcess c args Nothing Nothing > (Just hin) (Just hout) (Just hout) > waitForProcess ph >>= print This bug was fixed in rev. 1.12 of System.Process.Internals, and has been merged into the 6.4 branch. Cheers, Simon

1 0