- Libraries - Haskell.org

RE: Haskell library infrastructure coordinator
by Simon Marlow 29 May '03

29 May '03

> > There should probably be test suites to cover dependencies to ensure > > that all libraries are adequately in sync -- I'm not sure how easy > > this is to do in practice. > > Hmmm. > It's best done as the library is being written because it > could actually help > development and because the author likely has a better idea of what a > function is supposed to do. But test suites are usually > ignored or built > long after the fact. Since quickcheck is quite easy to use, > I wonder what's > missing? Is it infrastructure (a handy driver program and > some make targets) > or some well-worked examples to cut and paste from? Where do > I find examples > of how to quickly add quickcheck to my library? May I plug the GHC testsuite framework here? It's about 1k lines of Python (Makefiles are optional), copes with running tests multiple ways, has concepts of "expected failures" and "unexpected passes", and it generates a nice summary output at the end. It's quite configurable too. Take a look at fptools/testsuite/README in the GHC CVS tree. Cheers, Simon

1 0

RE: Soliciting Comments on DSP Library
by Simon Marlow 29 May '03

29 May '03

Matthew Donadio writes: > Since it's populated, I think my current snapshot is a proposal. Then I'm happy for your library to be the reference for the DSP hierarchy. Unless there are any objections, I'll add that to the list. > Perhaps nodes in the hierarchy should have a Pending for > modules/libraries that are needed and should have a standard interface, > but don't yet. The caveat would be that users should not use the > X.Y.Z.Pending functions directly. So, I would have > > DSP > Pending > Stat > Poly > Matrix It's better to go straight for the final names, rather than have to move modules around in the hierarchy at a later date. The interface can always be marked 'experimental' if it is likely to change. > It may make sense for the FFT library to live outside the DSP tree. > Among DSP practitioners, the terms "FFT" and "DFT" are used almost > interchangeably, but DFT is probably a better name. A proper solution > could be > Numeric > Transform > DFT -- Discrete Fourier Transform > DCT -- Discrete Cosine Transform > DST -- Discrete Sine Transform > DHT -- Discrete Hartley Transform > ... > > Long names could be better to avoid confusion (there are several > transforms that begin with H). I'd go with the longer names. Numeric Transform Fourier Cosine ... 'DiscreteTranform' is a bit of a mouthful, so I'd go with just 'Tranform'. Malcolm Wallace writes: > > The Stat library could really live anywhere. It only > contains functions > > for mean, median, variance, and std. dev. > > I suggest the fuller name 'Statistics', and indeed it does not belong > under DSP. Possibly under Numeric, but maybe at the top level? Agreed. The choice about whether to put Statistics at the top level or not depends on whether it is likely to evolve into a deep hierarchy itself; if not, then Numeric.Statistics should be fine. > > Numeric > > Random > > Generators -- MT19937, DRAND48, ... > > PDF -- Uniform, Normal, Poisson, Rayleigh, ... > > Spectral? -- White, Pink, Red, ... > > PDF = Adobe Portable Document Format? No? Then what? My guess is > Psomething Distribution Function, so how about > Numeric.Random.Distribution? On the subject of acronyms, they don't necessarily have to be unambiguous on their own as long as the meaning is clear from the context. That is, while PDF on its own is ambiguous, Numeric.Random.PDF might not be. In this case there might be better names though - Numeric.Random.Distribution sounds good to me. Cheers, Simon

4 3

Haskell lib for libpcap
by ptucker 29 May '03

29 May '03

Hi all, I am interested in finding a library or some code in Haskell that can parse network packets from a network trace dump file generated by tcpdump (libpcap). Is anyone aware of such a library? Thanks for your help. -- Pete Tucker (503) 748-4057 http://www.cse.ogi.edu/~ptucker

3 2

RE: Haskell library infrastructure coordinator
by Simon Marlow 29 May '03

29 May '03

> Shae Matijs Erisson owns the >haskell-libs< project at > sourceforge.net, and we figured this would be a good platform for the > effort. I just wanted to point out that there's some overlap between what you're doing in the haskell-libs project, and what's going on here on the libraries list. It's best not to duplicate effort if we can avoid it. > The idea is to set-up a CVS repository, which contains the > following directories: > > - hslibs > > Here do the actual source codes live, using a directory layout > complying to the hierarchical library structure, for example: > > - Text > - Data > - Foobar > > The contents is by-approval-only: We have a name registry for the hierarchy, and an (albeit informal) approval policy, here: http://www.haskell.org/~simonmar/libraries/libraries.html I don't quite understand the purpose of the hslibs libraries: are you providing a replacement set of libraries, or a complementary set? I believe it's important that there be one place which lists (a) which names in the hierarchy correspond to existing libraries, and (b) where to get an implementation of those libraries. > These libraries serve as a quasi-extension of the libraries shipped > with ghc/hugs/nhc98. Ideally, everybody would be able to use them > by just checking out this directory and adding it to the compiler's > search path. Just adding to the search path in GHC is unlikely to work - you really want to hook into the package system, and you'll need a build system of some kind. Cheers, Simon

3 2

RE: Haskell library infrastructure coordinator
by Simon Peyton-Jones 28 May '03

28 May '03

Peter | I wanted to write up a proposal regarding the organization of a | >central< library infrastructure for weeks Terrific! | ... So I guess now is the time to do or die. No, no, absolutely not! The idea is *not* that the coordinator goes into a corner and produces something that s/he imposes on the rest of us. The idea is that s/he asks for ideas, makes proposals, and moderates the process of melding those ideas into a design we can all support. Step 1 : identify coordinator Step 2 : propose designs, discuss, evolve consensus Step 3 : implement My message only concerned step 1. Yours is about step 2. Which is excellent, but it *isn't* do-or-die time for step 2. Simon

3 3

RE: Soliciting Comments on DSP Library
by Simon Marlow 27 May '03

27 May '03

> There are currently four libraries in the snapshot: DSP, Matrix, Poly, > and Stat. I would like to add these to the official namespace, and > would like to know where they should live. Would you like to submit a proposal - or does the library snapshot you posted constitute a proposal? Would anyone else interested in DSPs care to comment on possible names for these libraries? In the current hierarchy design we have: Numeric DSP FastFourierTransform Noise Oscillator but given the size of your DSP library, perhaps moving it to the top level would be justified? The other question to ask is whether this is will be *the* DSP library, or whether there are other competing designs. If there are multiple designs, then the pattern we usually follow is to do something similar to the Text.PrettyPrint hierarchy, where we have Text.PrettyPrint.HughesPJ, Text.PrettyPrint.Wadler and so on. > Everything is GPL. I don't really care one way or another about this, > but there is some code that I don't claim copyright to, and > some derived > code that inherits the GPL. In particular, MT19932.hs and > Roots.hs have > different copyright holders, and the original code was GPL. FFT.hs, > FFTHard.hs, and PFA.hs have some derived code, so they have to inherit > the GPL. I have to consult with the author, but IIRCookbook.lhs is a > derived work, and I have a feeling that the license on this > will be PD. There is no problem with GPL code, but we must be careful with dependencies. Any code (library or otherwise) which depends on your library will potentially be required to be GPL'd too, so the license needs to be prominently displayed. Cheers, Simon

4 4

mkstemp in Haskell
by Martin Sjögren 27 May '03

27 May '03

Dear list. I needed a function for creating temporary files. Since I couldn't find one in the standard library, I just hacked one up using the ffi. It's in the haskell-libs cvs [1]. I've got an icky import of GHC.Handle to get openFd, any way I could get rid of it? (fdToHandle isn't enough) [1] http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/haskell-libs/libs… /Martin PS: I slapped an LGPL license on it, if that's a problem, it's negotiable. -- Martin Sjögren sjogren(a)debian.org -- marvin(a)dum.chalmers.se GPG key: http://www.mdstud.chalmers.se/~md9ms/gpg.html let hello = "hello" : hello in putStr (unlines hello)

4 6

Re: Automake/Autoconf
by Alain Cremieux 23 May '03

23 May '03

Thank you for your answers, Alastair and Manuel. I played with the "Ports" configure.in, and will do the same with the gtk+hs one. If you can send me your work-in-progress, Alastair, I'll study it to. Thanks, Alain

1 0

Automake/Autoconf
by Alain Cremieux 21 May '03

21 May '03

Hi, I would like to know if there exists some kind of template / sample to create a 'configure.in' for a Haskell library ? The user manual for automake seems impressive to me, I'd rather copy/modify some existing code. Thanks, Alain

3 2

RE: Converting things to and from binary
by Simon Marlow 21 May '03

21 May '03

> (2) the York Binary library uses the IO monad, and presumably > various variables within a BinHandle, to keep track of state. > I think this is unnecessary, for example I don't think the > process of converting a value to a byte array should really > have to go through IO. We are supposed to be functional > programmers after all. When writing to a BinMem it would be possible to avoid the IO monad, and use something like the ST monad instead. However, I'm not sure it's worth making this generalisation, since it would necessarily complicate the library quite a bit. Do you have an application where being in the IO monad to do this stuff isn't possible, or is inconvenient? Cheers, Simon

4 8