- Libraries - Haskell.org

Supported Windows versions (was: Re: unix package)
by Esa Ilari Vuokko 06 Jul '07

06 Jul '07

On 6/30/07, Ian Lynagh <igloo(a)earth.li> wrote: > On Sat, Jun 30, 2007 at 08:01:09PM +0300, Esa Ilari Vuokko wrote: > > > > Indeed. Also, as Win32 maintainer, I am unsure how far we are supporting > > old Windowses. When I tentavily asked some people about it, they thought > > we should continue to support old Windows versions. > > Our (GHC) plan is not to support Win 9x (and Me?) from 6.8 onwards, as > we don't have machines on which test it or debug problems. I don't think > the installers that we make now install a GHC that works on Win 9x, but > I could be wrong. Thanks for info! This also might mean that GHC could be made to exclusively use IO Completion Ports in Windows instead of hacks now in place. Maybe this is a good place to ask for opinions. Anyone have any or know of need to support old Windows versions? I am also curious if someone still writes software for pre-Windows 2000 NTs, as there's some nice API functions in Windows 2000. Thanks, Esa

3 4

Gtk2Hs 0.9.12 release candidate 1 available for testing
by Duncan Coutts 04 Jul '07

04 Jul '07

All, The first release candidate for Gtk2Hs 0.9.12 is now available. (The actual version number is 0.9.11.3) The source tarball and windows installer are available: http://haskell.org/gtk2hs/gtk2hs-0.9.11.3.tar.gz (md5sum 72ae779f8d12c6013787cc735272f723) http://haskell.org/gtk2hs/gtk2hs-0.9.11.3.exe (md5sum e1be8f38d33d76492c078cb66a790db1) Changes since 0.9.11: * ps, pdf and svg cairo backends are now supported * drag & drop support added * can run mainGUI in GHCi after :reload * Graphics.SOE.Gtk now works with threaded rts and GHCi * Windows build now includes OpenGL and SourceView packages * c2hs no longer chokes on some system headers (eg glibc-2.4) * various bug fixes and minor code cleanups * major overhaul of the code generator (will help binding gtk-2.10) Please test this on your platform and report success or failures to the gtk2hs-users list. Reports for less common platforms, processors architectures and older versions of GHC and Gtk+ are particularly appreciated. This release has seen less churn than most, so we expect relatively few build issues. We're expecting more significant changes in the next major release, including support for the new features in Gtk+ 2.10 and 2.12, a simplified signals and properties api which should make for considerably simpler documentation. In the long term we also expect to modularise Gtk2Hs and build each component using Cabal. For testing this release, try building, installing and then run: make installcheck This should build all the demo programs that are appropriate for your configuration. Running a selection of them would be good. Then if you have any other programs that use Gtk2Hs then testing those with this new release would be good. Windows notes: The installer expects GHC 6.6.1. (As always if you need a build for a different version of GHC then that's possible by building from source.) If anyone thinks we should include support for older versions of GHC in the windows installer (eg 6.4.2 or 6.6) then to say so. For example the last Gtk2Hs release included support for both 6.4.2 and 6.6. The windows build now includes the gtkglext and sourceview packages, but not svgcairo as that has pretty heavy dependencies. This makes the download a bit bigger, but on the other hand currently it includes support for only one GHC version, so overall the installer is rather smaller than in the last release. Duncan

1 0

FW: [Haskell-cafe] Sparse documentation
by Simon Peyton-Jones 04 Jul '07

04 Jul '07

A reasonable question from Michael. Can someone who’s more deeply involved in library development answer? Cc haskell-cafe. An easy “here’s how to contribute” wiki page would be great. Michael: I think we are talking about library documentation rather than documentation of GHC’s internals. But your question stands. Thanks Simon From: Michael T. Richter [mailto:ttmrichter@gmail.com] Sent: 04 July 2007 08:24 To: Simon Peyton-Jones Cc: haskell-cafe(a)haskell.org Subject: RE: [Haskell-cafe] Sparse documentation On Wed, 2007-04-07 at 08:03 +0100, Simon Peyton-Jones wrote: | Fortunately, some kind soul has gone through and converted the | documentation to haddock format: | http://hackage.haskell.org/trac/ghc/ticket/1410 | | So it'll all appear in the html docs in the next version. In the mean | time one can look at the haddock comments in the source: | http://darcs.haskell.org/packages/mtl/Control/Monad/ Furthermore, you can always get the GHC HEAD documentation here http://www.haskell.org/ghc/dist/current/docs >From there you can get to Control.Monad, which indeed shows at least some documentation. Simon, if the less-talented among us (like me) want to contribute to GHC's docs -- and especially documenting the libraries -- what's the best way to go about this? I'm not too comfortable with the notion of just going into GHC's guts and Haddocking the comments, contributing patches willy-nilly because I'd not be certain I did the job right, that I explained things correctly where I had to amplify, etc. Is there some kind of documentation team we poor souls could interact with to assist? -- Michael T. Richter <ttmrichter(a)gmail.com<mailto:ttmrichter@gmail.com>> (GoogleTalk: ttmrichter(a)gmail.com) When debugging, novices insert corrective code; experts remove defective code. (Richard Pattis)

1 0

darcs patch: Use filepath rather than System.Directory.Internals
by Ian Lynagh 02 Jul '07

02 Jul '07

Mon Jul 2 10:54:08 BST 2007 Ian Lynagh <igloo(a)earth.li> * Use filepath rather than System.Directory.Internals

1 0

unix package
by Ian Lynagh 01 Jul '07

01 Jul '07

Hi all, Currently the unix package is a mishmash of different solutions to the portability problem. Here are all the ones I've found, along with what I think the best action would be. If this sounds reasonable then I'll start making patches and proposals as appropriate. (for POSIX/SUS, see http://www.opengroup.org/onlinepubs/009695399/) 1) Values outside of the scope of the package, conditionally available: * System.Posix.Signals.Exts.* Propose: Moving modules into a new package, unix-exts perhaps. 2) Things that fall back to probably-reasonable alternatives: * unsetEnv, setEnv * PATH_MAX Propose: Leave as they are. 3) Things falling back to functionality which can cause problems: * The Haskell usleep uses the C usleep (marked Obsolescent) if nanosleep (a Timer extension) isn't available. C's usleep interacts badly with GHC's threaded RTS. Propose: Leave as it is. 4) Things that raise errors at runtime if they are not available, but there is something we could fall back to: * getGroupEntryForID (getgrgid_r, thread-safe extension) * getGroupEntryForName (getgrnam_r, thread-safe extension) Propose: Write fallback code. 5) Things that raise errors at runtime if they are not available, but as far as I can see are required to be available anyway: * _PC_* in System/Posix/Files.hsc * getUserEntryForID (getpwuid) * getUserEntryForName (getpwnam) * grBufSize (sysconf, _SC_GETGR_R_SIZE_MAX) * pwBufSize (sysconf, _SC_GETPW_R_SIZE_MAX) * sysconfWithDefault (sysconf) Propose: Change to using them unconditionally and see if any platforms break. 6) Things depending on optional functionality, conditionally available: * setSymbolicLinkOwnerAndGroup depends on lchown, an XSI extension http://www.opengroup.org/onlinepubs/009695399/functions/lchown.html * RLIMIT_AS (ResourceTotalMemory), RLIM_SAVED_MAX, RLIM_SAVED_CUR (all of the rlimit stuff actually appears to be an XSI extension). Propose: Move to unix-xsi package. 7) Things that raise errors at runtime if they are not available: * getAllGroupEntries (getgrent, XSI extension) * getAllUserEntries (getpwent, setpwent, endpwent, XSI extensions) * Various in DynamicLinker.Prim Propose: Move to unix-xsi package. (for both 6 and 7, an alternative would be to just make them unconditionally used in the unix package; I'm not sure what platforms, if any, this would break on). 8) Things that are implemented only for certain compilers: * forkProcess (GHC-only) Propose: Write implementations for other compilers/interpreters. Thanks Ian

8 9

apfelmus' interface degustation - System.FilePath.Find
by apfelmus 01 Jul '07

01 Jul '07

Chers amis of functionaλ cooking, aujourd'hui, le maître de cuisine is going to criticize System.FilePath.Find http://darcs.serpentine.com/filemanip/dist/doc/html/ /FileManip/System-FilePath-Find.html Is it seasoned too much with Curry and Monads? Pure or diluée with side effects? Apfelmus will tell you! And like every serious cooking critic, le maître thinks no end of himself so he can judge the haddock without eating the compiled meal. Who did not yet have to scan the file buffet for data of his gusto? This is what System.FilePath.Find helps you to do. It basically offers a function find :: RecursionPredicate -> FilterPredicate -> FilePath -> IO [FilePath] to lazily traverse a directory tree filtering out files that do not match the FilterPredicate. The RecursionPredicate decides whether to recurse into or a sub-directory or not (it could be mentioned explicitly that the predicate is only invoked on directories). A variant of find includes user-defined error handling. How to define predicates? Mon dieu! They are to be obtained from a monad FindClause a type FilterPredicate = FindClause Bool which offers operations like extension :: FindClause FilePath (==?) :: Eq a => FindClause a -> a -> FindClause Bool (||?) = liftM2 (||) One example predicate would be (extension ==? ".hs") ||? (extension ==? ".lhs") Cette soupe is much too monadic! In particular, we have the isomorphism (FileInfo -> a) ≅ FindClause a witnessed by the function pair (f,g) = ((`liftM` fileInfo), evalClause) Of course, the encapsulation was made to allow a formulation like extension ==? ".hs" which does not mention the FileInfo parameter. But alas, this can also be achieved more naturally by appealing to the instance Control.Applicative ((->) a) Abstracting the concrete representation away into FindClause hinders reuse of already existing functionality from System.FilePath, although the name "extension" is arguably more succinct than "takeExtension". The monad could make sense if the predicate might involve not only the file status but also looking inside the file. Returning all files with a certain magic number would be such a use case but System.FilePath.Find currently does not offer zis possibilité. Un autre point is that the library offers a function fold that is almost a foldl' over all files in a directory tree, but not quite: here, the fold goes over FileInfos but the list is a simple list of FilePaths. One has to foldM over the latter and get the file infos again to achieve the same effect. Le maître de cuisine thinks that these quirks stem from the fact that the file system lacks a purely functional design. The observation is that given persistence, reading does not need to be monadic. In other words, directory tree traversal might well return a list of files data File = File { contents :: String, status :: FileStatus } with contents and status. More generally, the traversal could be a side-effect-free traversal of a pure data structure. Of course, a purely functional file system needs further research, also due to performance requirements. Another direction of généralisation is that XML data is in principle similar to a file system. Shouldn't both have a common traversal interface? Last but not least, every modern cooking critic includes a Rating: λλλ Le maître awards three λ since the library uses a monad where none should be, but acknowledges that this was for the ability to formulate queries without plumbing the FileInfo-parameter everywhere. Bon appetit, apfelmus

2 3

Data.Map.mapKeys documentation differs from the actual behavior
by Andriy Palamarchuk 30 Jun '07

30 Jun '07

I'm currently improving documentation for Data.Map. mapKeys documentation says: "The size of the result may be smaller if f maps two or more distinct keys to the same new key. In this case the value at the smallest of these keys is retained." However the implementation retains the value of the *largest* key: Prelude Data.Map> let map = fromList [(1,"b"), (2,"a"), (3,"d"), (4,"c")] Prelude Data.Map> mapKeys (\ _ -> 1) map {1:="c"} Prelude Data.Map> mapKeys (\ _ -> 3) map {3:="c"} See http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Map.html#v%… Should I fix the documentation to confirm to the actual function behavior? Thanks, Andriy ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/

2 1

Re: Patch - Control.Monad.Reader documentation
by Andriy Palamarchuk 28 Jun '07

28 Jun '07

Ian, thank you for the review. I fixed the problem and attached the patch to the ticket. The deadline is up and it's ready for commit. Thanks, Andriy ----- Original Message ---- > From: Ian Lynagh <igloo(a)earth.li> > > On Mon, Jun 04, 2007 at 09:10:47PM -0700, Andriy Palamarchuk wrote: > > > > See the ticket for details: > > http://hackage.haskell.org/trac/ghc/ticket/1410 > > Just a small point: > > It would be nice if the "runReader :: r -> a" was indented 4 spaces. > > > Thanks > Ian ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow

2 1

darcs patch: Speed up number printing and remove the need for Array...
by John Meacham 27 Jun '07

27 Jun '07

Fri Jun 8 11:23:53 PDT 2007 John Meacham <john(a)repetae.net> * Speed up number printing and remove the need for Array by using the standard 'intToDigit' routine

2 1

Proposal: fix for getOpt (missing feature)
by Malcolm Wallace 26 Jun '07

26 Jun '07

Proposal: to fix a missing feature in the Haskell implementation of GNU getOpt. Currently, long option names _must_ have two dashes (e.g. --foo), whereas this patch permits a single dash (e.g. -foo) where there is no short option name to be confused with it (e.g. -f).

6 6