- Libraries - Haskell.org

What Cabal stuff is permanent?
by John Goerzen 07 Jun '05

07 Jun '05

I have been using the info at http://www.haskell.org/ghc/docs/latest/html/Cabal/authors.html as my guide to Cabal. I recently added an include-dirs line to my .cabal file, only to find that ghc-pkg would fail to register this package. It appears that include-dirs was placed into the ghc-pkg file, and of course, the relative path doesn't exist at install time and isn't even relevant there. The problem is: the Cabal docs don't say which fields are "permanent" and registered in the package and which aren't. There are many cases where it is not desirable to have fields be "permanent", and this is one such case. I'm not sure how to specify "just search for .h files here at build time of this library" through Cabal. Ideas? -- John

2 3

RE: Inconsistent strictness of Data.Generics.toConstr
by Simon Peyton-Jones 06 Jun '05

06 Jun '05

Yes, surely toConstr should have consistent behaviour on tuples and other single-constructor types. I'm inclined to agree that it should be strict in all cases, and I'll fix Data.Generics.Instances to make it so. Unless someone yells otherwise. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Nils Anders | Danielsson | Sent: 02 June 2005 15:43 | To: libraries(a)haskell.org | Subject: Inconsistent strictness of Data.Generics.toConstr | | Data.Generics.toConstr is non-strict at the unit type (), but the | version derived (under GHC 6.4) for isomorphic types, such as One | below, is strict. | | data One = One deriving (Typeable, Data) | | > toConstr (undefined :: ()) | () | > toConstr (undefined :: One) | *** Exception: Prelude.undefined | | Furthermore toConstr is non-strict for a bunch of other types, see | Data.Generics.Instances. To me it seems reasonable that toConstr | should be strict, since bottom is not a constructor. | | (I'm not just nit-picking, a bug in one of my programs was caused by | me thinking toConstr was strict. The bug was of course easily fixed by | adding a seq, but I'd prefer consistent behaviour of toConstr.) | | -- | /NAD | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

Inconsistent strictness of Data.Generics.toConstr
by Nils Anders Danielsson 02 Jun '05

02 Jun '05

Data.Generics.toConstr is non-strict at the unit type (), but the version derived (under GHC 6.4) for isomorphic types, such as One below, is strict. data One = One deriving (Typeable, Data) > toConstr (undefined :: ()) () > toConstr (undefined :: One) *** Exception: Prelude.undefined Furthermore toConstr is non-strict for a bunch of other types, see Data.Generics.Instances. To me it seems reasonable that toConstr should be strict, since bottom is not a constructor. (I'm not just nit-picking, a bug in one of my programs was caused by me thinking toConstr was strict. The bug was of course easily fixed by adding a seq, but I'd prefer consistent behaviour of toConstr.) -- /NAD

1 0

working Edison, a couple of collection modules, and typing troubles
by Samuel Bronson 27 May '05

27 May '05

Whatever happened to Edison? I want to play with it and the one in the HFL cvs repository won't build for me (and uses flat names). I was trying my hand at writing some collection classes myself and I can't figure out a good typing for map that will let me make Map an instance of my Collection class... I'm attaching what I have so far. I don't much like the head of Mapping. I expect oleg will have some crazy type-system trick up his sleeve. -- Thankful-in-advance-ly yrs, Sam

2 2

Time library comment
by Eric Etheridge 26 May '05

26 May '05

I have read all of the comments on this list over the last half a year regarding the Time library, and I feel I need to comment. (That was a lot of reading!) I write games, and I use Haskell. I don't need a time library to do anything fancy at all, no timezones, no leap seconds, nothing. I only need two things from a Time library: 1. An absolute assurance that some method of determining current time will give me an actual resolution of at most 1-3 milliseconds, without regard for leap seconds or even the user changing the system clock. 2. A way to set an event (OS signal, IO () function, whatever) to happen a certain amount of time in the future, again without regard to leap seconds or gross alteration of the system clock. #1 is very critical to games, because it is desirable to coordinate the display function with the rate of the screen refresh, which can be 85 Hz or higher on high-end machines. Hopefully, you redraw once and only once for each screen refresh. Currently, #2 means writing my own alarm thread and depending on poll and the like, as others have pointed out. Why can't that be a standard function? All of the other functions such as conversion and the like are frivolous for game design, because everything is measured relatively from game start, since the system clock as-is can't be trusted. Don't take this too seriously. Just know that the current method of achieving that kind of resolution requires using GLUT, which means eating up more memory and CPU than necessary. As always, thanks for a wonderful language, libraries, and compilers. - Eric Etheridge __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

Win32 bindings and the GHC6.4 windows distro
by Philippa Cowderoy 24 May '05

24 May '05

I decided to have a play with the win32 bindings in the hierarchical libraries. The attached program built with ghc --make fails to link with these errors: test.o(.text+0x1c2):fake: undefined reference to `GraphicsziWin32ziMisc_messageB ox_closure' test.o(.text+0x255):fake: undefined reference to `__stginit_GraphicsziWin32ziMis c_' test.o(.data+0x3c):fake: undefined reference to `GraphicsziWin32ziMisc_messageBo x_closure' How can I get this to build for now, and is it possible to set up the package that comes with the binary windows distribution so that no fix is needed in the future? -- flippa(a)flippac.org A problem that's all in your head is still a problem. Brain damage is but one form of mind damage.

2 2

Difference Argument Order
by Ashley Yakeley 24 May '05

24 May '05

Which of these argument orders is more intuitive to you? 1. This one makes more sense when considering the function formed by applying one argument: add :: Diff -> Absolute -> Absolute add d a = a + d subtract :: Diff -> Absolute -> Absolute subtract d a = a - d diff :: Absolute -> Absolute -> Diff diff a b = b - a So "add x", "subtract y" and perhaps "diff z" are intuitively useful functions. And we also have "subtract = add . negate". 2. This one is more familiar for the English language and for the standard operators: add :: Absolute -> Diff -> Absolute add a d = a + d subtract :: Absolute -> Diff -> Absolute subtract a d = a - d diff :: Absolute -> Absolute -> Diff diff a b = a - b -- Ashley Yakeley, Seattle WA

4 7

RFC: general sequences
by Ross Paterson 24 May '05

24 May '05

A general implementation of sequences (based on work with Ralf Hinze) can be found at http://www.soi.city.ac.uk/~ross/software/html/Data.Sequence.html http://www.soi.city.ac.uk/~ross/software/Data/Sequence.hs Our experiments indicate that its performance is comparable to (and sometimes better than) the best known persistent implementations(*). Non-persistent implementations are typically faster, but you need to be more careful when using them. I'd like to propose this for base. Comments welcome. (*) or at least it will be when GHC's SPECIALIZE pragma is fixed for polymorphic specializations (SF bug #1019758).

11 32

RE: GHC Win32 ffi functions as implemented for Pugs
by Simon Marlow 23 May '05

23 May '05

On 22 May 2005 23:32, Max Maischein (Corion) wrote: > The file is (live version) : > > http://svn.openfoundry.org/pugs/src/Pugs/Compat.hs > > The implemented wrappers that are functional and not just stubs are > (as of r3680) : > > For System.Environment: > setEnv :: String -> String -> Bool -> IO () > getEnv :: String -> IO (Maybe String) > unsetEnv :: String -> IO () System.Environment.getEnv should work on Win32. For the others, it would possibly make sense to include these in System.Environment, with implementations for both Unix & Win32. > For Posix.Process > getProcessTimes :: IO ProcessTimes > getProcessID :: IO Int Should probably be in System.Win32 somewhere. > The code itself is dual-licensed under the Artistic License and GPL > and thus should be compatible with whatever license GHC uses. Unfortunately we can't take code under that license into our existing packages - the rule is that each package has a single license, and currently all the packages distributed with GHC have a BSD3 license, with the exception of readline. You can start new packages, of course. > Hope you find my code useful, Contributions are always welcome, even if we can't use the code directly. You've pointed out things that the standard libraries lack. Thanks! Cheers, Simon

2 1

Let the key (digest of contents) _be_ the identity (was: hackage, cabal-get, and security)
by Dimitry Golubovsky 23 May '05

23 May '05

This was inspired by the discussion in [Libraries] on how to validate the contents of a distributed package. John Meacham wrote: > The whole idea of tying a key to an > existential identity is flawed, let the key _be_ the identity and all > problems go away. Let me suggest. Why cannot the following simple approach be used as a basis? Consider some "distribution unit", OK, let's call it "Package". It has a property of being distributed independently, say, as a tar ball (or a zip file). Right before packing, a digest may be computed (say MD5 or whatever else, doesn't really matter at this point) on the contents of a directory (with subdirectories) containing the distribution. Then a tar ball file is created in traditional way. The tarball file itself will be named based on the digest: for example, if we have computed a digest d41d8cd98f00b204e9800998ecf8427e then the file will be named "package_d41d8cd98f00b204e9800998ecf8427e.tar.gz". When a developer wishes to announce a new package, he/she supplies this digest-containing name (digest calculated just before creation of the tarball), and a "descriptive" name (say Package Foo version 8 revision 75) will accompany the announce. Such an announce being placed on one (or several) of many web-enabled mailing lists (such as the haskell mailing list for instance, or fm-announce for freshmeat) will soon be indexed by various search engines, so it will be easy to verify (even in some automated way provided that all announce messages are forced to be formatted uniformly) the identity (digest) of a package given its descriptive name. In any ambiguity, priority must be given to the earliest post found (as it was most likely made by the original developer). Someone willing to use a package, locates and downloads the tarball (by its name which contains the digest). It may then be unpacked, the digest produced: if it matches that in the file name, the file is valid, otherwise not. Additionally, size and checksum of the tarball may be also added to the announce message. So the only question I cannot answer (not being a crypto expert) is whether there exists such a digest algorithm that makes it nearly impossible to supply a distribution file with different contents, same size, and same checksum, but after unpacking, yielding the same digest value. With this approach, there is no need to have a centralized storage for packages: the Internet itself becomes such a storage, and the packages database is replaced by existing search engines given we are able to make search requests programmatically (see my earlier post in [Haskell-cafe] on locating Cabal files with Google). So, to locate a package, one searches (googles) for its descriptive name: result will return URLs of all cabal files indexed by the search engine containing such a name. The next step is downloading the cabal file and finding the distribution tarball file name. So, instead of going into cryptography problems, I am suggesting to use the contents of a package for self-validation (via computed digest), and to use the "public record" such as an internet-archived mailing list message to establish a truth about relationship between "descriptive" name (which is human-readable) and "distribution" name (which contains a digest to verify). Implementation of this approach does not need any extra software (except maybe a wrapper around md5sum or like to digest a whole directory with subdirectories) and few other shell scripts. Perhaps a tag needs to be added to cabal file syntax which would contain the digest (if one does not exist, at least I couldn't find it in the documentation at haskell.org/cabal) Distribution file name may be derived from that digest. -- Dimitry Golubovsky Anywhere on the Web

1 0