- Libraries - Haskell.org

building a helper binary with cabal
by Evan Martin 18 May '08

18 May '08

[resent after subscribing to the list] I'm working on a package that requires building a helper binary as part of its install process. This binary is written in C (with good reason), and on a Debian system would be installed into a path like /usr/lib/myproject/mybinary, because it's only used internally by the main program binary. My setup is up to this point: > gccProgram :: Program > gccProgram = simpleProgram "gcc" > type BuildHook = PackageDescription -> LocalBuildInfo > -> UserHooks -> BuildFlags -> IO () > creplChildBuild :: BuildHook -> BuildHook > creplChildBuild oldhook desc buildinfo hooks flags = do > oldhook desc buildinfo hooks flags > rawSystemProgramConf (buildVerbose flags) gccProgram (buildPrograms flags) > ["child.c", "-o", buildDir buildinfo </> "child", "-ldl"] > buildHooks = simpleUserHooks { > hookedPrograms = [gccProgram], > buildHook = creplChildBuild (buildHook simpleUserHooks) > } > main = defaultMainWithHooks buildHooks However, it's unclear to me how to set up the install rule that would copy that binary into the appropriate place. Any tips? It seems I want to grab the "install" hook, but from there how do I specify where to install the file? There seem to be no helper functions to facilitate installing. (I appreciate that all of this is pretty new. So if it's not possible for me to do what I want, take it as an example of the sort of thing I'd like for Cabal to support...)

2 8

IntMap intersectionWith type is too restrictive
by Scott Dillard 16 May '08

16 May '08

Hi, This is a simple bug report, more or less. The type of Data.IntMap.intersectionWith is too restrictive. Presently (GHC 8.2, http://darcs.haskell.org/packages/containers/Data/) it's declared as (a->b->a) -> IntMap a -> IntMap b -> IntMap a, but if you just remove the type declarations it's inferred as (a->b->c) -> IntMap a -> IntMap b -> IntMap c. Similarly for intersectionWithKey. The more general a->b->c type is also the type of Data.Map.intersectionWith, and it's quite useful, such as (intersectionWith (,)) Scott

2 3

Proposal/Idea: Split up base even further
by Twan van Laarhoven 16 May '08

16 May '08

Hello librarians, Here is an idea to resolve some of the problems that remain with the base package: The problem: Users can not update their version of the 'base' package, since it is tied to Ghc. If a useful new function is added using it requires updating the compiler. On the one hand this puts people off using these new functions. On the other hand it also makes updates to for instance Data.List take way longer to reach the users because we have to wait for the next Ghc release. The proposal: User code should NEVER import the library that is now called 'base', it should provide an internal API only. For example, base can include the modules Internal.Data.List Internal.Control.Monad Internal.IO etc. Which are as minimal and low level as possible, containing just the things that Ghc RELIES on like: - type classes for which instances can be derived (Eq, Ord, etc.) - data types and classes with syntactic sugar (Bool, [], Num, Monad) - low level stuff like IO and ST and primitives In short, everything that is now under Ghc.*, and hopefully less, becomes the new base library. In my opinion half of that can still be moved out, like most of Ghc.List, Ghc.Enum, Ghc.IO and Ghc.Read. The next layer can then consist of many packages like "containers", "control", "numeric", "concurrent", "ioref", "file-io", "foreign", etc. For example the Data.List module imports Internal.Data.List for the basic list data type. It re-exports this, and adds many additional functions that don't belong in the minimal base library. Thoughts? Twan

2 1

Data.Time questions
by Bjorn Buckwalter 14 May '08

14 May '08

Dear all, I've implemented 'ParseTime' and 'Read' instances for 'AbsoluteTime'. Before submitting a patch I want to confirm with you that they belong in 'Data.Time.Format.Parse' as opposed to 'Data.Time.Clock.TAI'. Is this correct? I'm doing work on additional time coordinates of interest to e.g. astrodynamicists. In particular Terrestrial Time (TT = TAI + 32.184 seconds, previously known as Terrestrial Dynamical Time or TDT) and perhaps Geocentric Coordinate Time (TCG) and others. Would you be interested in receiving patches with these rather esoteric time coordinates? If not I'll release them in a new "time-astro" package. Thanks, Bjorn Buckwalter

3 6

Specifying dependencies on Haskell code
by Duncan Coutts 12 May '08

12 May '08

All, In the initial discussions on a common architecture for building applications and libraries one of the goals was to reduce or eliminate untracked dependencies. The aim being that you could reliably deploy a package from one machine to another. We settled on a fairly traditional model, where one specifies the names and versions of packages of Haskell code. An obvious alternative model is embodied in ghc --make and in autoconf style systems where you look in the environment not for packages but rather for specific modules or functions. Both models have passionate advocates. There are of course advantages and disadvantages to each. Both models seem to get implemented as reactions having the other model inflicted on the author. For example the current Cabal model of package names and versions was a reaction to the perceived problem of untracked dependencies with the ghc --make system. One could see implementations such as searchpath and franchise as reactions in the opposite direction. The advantages and disadvantages of specifying dependencies on module names vs package names and versions are mostly inverses. Module name clashes between packages are problematic with one system and not a problem with the other. Moving modules between packages is not a problem for one system and a massive pain for the other. The fact is that both module name and package name + version are being used as proxies to represent some vague combination of required Haskell interface and implementation thereof. Sometimes people intend only to specify an interface and sometimes people really want to specify (partial) semantics (eg to require a version of something including some bug fix / semantic change). In this situation the package version is being used to specify an implementation as a proxy for semantics. Neither are very good ways of identifying an interface or implementation/semantics. Modules do move from one package to another without fundamentally changing. Modules do change interface and semantics without changing name. There is no guarantee about the relationship between a package's version and its interface or semantics though there are some conventions. Another view would be to try and identify the requirements about dependent code more accurately. For example to view modules as functors and look at what interface they require of the modules they import. Then we can say that they depend on any module that provides a superset of that interface. It doesn't help with semantics of course. Dependencies like these are not so compact and easy to write down. I don't have any point here exactly, except that there is no obvious solution. I guess I'd like to provoke a bit of a discussion on this, though hopefully not just rehashing known issues. In particular if people have any ideas about how we could improve either model to address their weak points then that'd be well worth discussing. For example the package versioning policy attempts to tighten the relationship between a package version and changes in its interface and semantics. It still does not help at all with modules moving between packages. Duncan

7 17

Re: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support
by Don Stewart 10 May '08

10 May '08

vigalchin: > so Don you are saying that mqueue and RTsched I should put on Hackage to > avoid putting in the Unix package? Vis-a-vis fsync and fdatasync I have no > choice .. they both IMO belong in Files.hsc. Right, there are two options: 1) put it in a new package. unix-extensions or 2) submit it as a patch to the libraries(a)haskell.org mailing list, and it can be put in the main 'unix' darcs repository, which then gets uploaded to hackage in the next release cycle. It's currently a bug that anyone can (accidentally) release their own versions of the core libraries. Cheers, Don

6 10

Patch: fixed typo in base modules comments
by Andriy Palamarchuk 10 May '08

10 May '08

Replaced "iff" with "if". Please apply. Andriy ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

3 2

Release of unix 2.4.0.0
by Don Stewart 10 May '08

10 May '08

Vasili Galchin did a release of a new version of the unix library. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-2.4.0.0 Hmm :( This is a core package, maintained by libraries@, so shouldn't be being uploaded to hackage by 3rd parties. What can we do? -- Don

2 2

Re: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support
by Don Stewart 10 May '08

10 May '08

vigalchin: > Hello, > > Additional POSIX realtime (POSIX 1003.1b) support has been added: > > 1) MQueue.hsc - POSIX message queues > > Supported FFI bindings for: > > - mq_open > > - mq_close > > - mq_unlink > > - mq_getattributes > > - mq_setattributes > > - mq_send > > Not yet supported bindings: > > - mq_rcv .. still debugging a mysterious problem > > - mq_notify - will support when asynchronous I/O is implemented > > 2) RTsched.hsc - real time scheduling > > Supported bindings for: > > - sched_yield > > - sched_get_param > > - sched_set_param > > - sched _get_scheduler > > - sched_set_scheduler > > - sched_get_priority_min > > - sched_get_priority_max > > Unsupported currently: > > - sched_rr_get_interval - still looking for the TimeSpec data > type in order to get "peek" working > > 3) Files.hsc > > Added bindings for: > > - fsync > > - fdatasync > > I am new to Haskell but would like to make a lot of contributions to > insure Haskell success in the marketplace (of ideas ;^)). I apologize for > any glitches and look for feedback. Very interesting! However... this library is a core package, and maintained by libraries(a)haskell.org, so you should not release it yourself. Instead, submit your patches to libraries@ for inclusion, following the patch submission guide here: http://haskell.org/haskellwiki/How_to_write_a_Haskell_program Where the patches will be tested on other unix platforms, and then encorporated into the main 'unix' repository. Also, as unix .hsc files tend to be a bit fragile, portability wise, it might be a good idea to instead place your patches in a separate library on hackage, rather than patching the 'unix' package directly. We have many other unix-alike packages, so one for message queues, and real time scheduling make sense -- separate from the core 'unix' package (like the mmap package, for example). -- Don

1 0

proposal #2254: have Control.Arrow re-export (>>>) and (<<<)
by Ross Paterson 06 May '08

06 May '08

A previous proposal: http://hackage.haskell.org/trac/ghc/ticket/1773 split the Arrow class, making (>>>) and (<<<) functions in Control.Category. This breaks programs that use Control.Arrow. To avoid some of the breakage, the proposal is that Control.Arrow should re-export (>>>) and (<<<), imported from Control.Category.

6 12