August 2006 - Glasgow-haskell-users

Windows API - GetLastError woes
by Esa Ilari Vuokko 29 Aug '06

29 Aug '06

Hi, My "use case" is in Win32-package, where we simply call a FFI imported call and on failures call GetLastError to get extended error code. GetLastError of course only works on same OS thread and contains sensible results only before next Windows API call. It's much like C/posix errno. So, we *must* call GetLastError in the same OS thread, and there must not be any Windows API calls in between, including those caused by, say, rts' memory allocation or calls to lock mutexes. Unless the error code is saved via Get/SetLastError. Also, I'd like not to run the code in a another OS thread (and that won't fix the rts-caused Windows API calls), because the calls are supposed to be fast, and OS-level context switch isn't fast. Is this problem real, or did I miss some magic feature of rts? The only way to solve this problem seems to be to wrap all calls in C-functions that take care of reading GetLastError. Not that it's impossible, just very annoying. Best regards, --Esa Ilari Vuokko

4 4

6.6 Release Candidate delayed
by Simon Marlow 29 Aug '06

29 Aug '06

We previously announced that there would be a release candidate of 6.6 out on 25 August. However, we are experiencing some stability problems with the current 6.6 sources on some platforms, so the 6.6 RC is delayed until we can straighten things out. On x86/Linux and x86_64/Linux things seem relatively stable though, so if you felt brave enough to have a go with the current snapshot on one of those platforms, please go ahead. Snapshots as usual can be grabbed from http://www.haskell.org/ghc/dist/current/dist/ and the release notes (still subject to changes before the release) are here: http://www.haskell.org/ghc/dist/current/docs/users_guide/release-6-6.html Cheers, The GHC Team

1 0

using ghc with make
by Frederik Eaton 26 Aug '06

26 Aug '06

Hi all, I have a project which currently uses Cabal, and I would like to switch to using a plain Makefile. I have two examples of projects that use Makefiles, darcs and jhc, but they both appear to hand-code the list of dependencies for executables. The "-M" option to ghc should let us do this automatically, but either because of a deficiency in GHC or in GNU Make, that looks to be impossible or difficult. Does anyone have experience with this? Since I'm not using the multi-compiler features of Cabal, I think it shouldn't be too hard to get the project-specific part of my Makefile down to the size of the .cabal file. Many thanks, Frederik P.S. I want to use 'make' rather than Cabal because: - I want to be able to rebuild specific targets, rather than building everything every time - I want better dependency inference, for instance I don't want to relink every executable every time I do a build (I think this is fixed in newer versions of ghc, but not the one I use) - I ultimately want to be able to use a more sophisticated build system than Cabal's. GNU Make is a good first start, because it allows me to run several jobs simultaneously, for instance potentially utilizing multiple processors. In the future, I want to write a build system that does result caching as well. There are a lot of tricks that can be done in build systems, so in general I think it would be good to have a build system which is separable from the domain-specific configuration and compiler logic, rather than coupling them as Cabal and "ghc --make" do. The compile / fix compiler errors cycle is an important part of the development process for me, and so I want recompilation to go as quickly as possible. By the way, the GHC user manual claims that using --make is much faster than using a Makefile, but in a test on a small program, the difference was not significant (16 seconds vs. 18 seconds). Furthermore, some build systems are able to combine targets, e.g. running "ghc -c Bar.hs -c Foo.hs" instead of "ghc -c Bar.hs; ghc -c Foo.hs", which should eliminate the already small difference. -- http://ofb.net/~frederik/

9 23

A registerised mips-linux port of GHC
by Thiemo Seufer 25 Aug '06

25 Aug '06

Hello All, I currently try to get a ghc port on mips-linux going. I understand Igloo does the same ATM, and things look promising so far. However, the port is currently unregisterised, and I would like to improve it a bit. A registerised port seems to be achievable with a moderate amount of work. I looked a bit around in the code, and have now a few questions: - The example of other ports suggests the useful maximum of general purpose registers for GHC is 8. I also presume that unmentioned registers aren't touched by haskell code. Is this correct? - The comments in the source suggest that callee-saved registers are preferable, without further explanation. I would expect a mix of caller- and callee-saved registers to be potentially better. Any advice on this? - The mips ABI defines 8 (or 9 when including the frame pointer) registers as callee-saved, and more than 9 caller-saved temporaries. With four registers taken for stack/heap pointers this leaves a 5/3 split of callee-saved/caller-saved registers, if all my assumptions above are ok. Are there other considerations to take into account for the register layout? Thiemo

3 7

`let' for comprehension
by Serge D. Mechveliani 25 Aug '06

25 Aug '06

Who can advise, please, is this for sure that the program \ x -> [f y | y <- g x] is not more expensive in computation than \ x -> let ys = g x in [f y | y <- ys] ? May the difference depend on Haskell implementation? (I suspect that compilers convert one of these programs to another). Thank you in advance for explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Packages in GHC 6.6
by Simon Marlow 25 Aug '06

25 Aug '06

Here is what I propose to do regarding the libraries we ship with GHC 6.6. Comments are appreciated, since we need to finalise this story before the release candidate at the end of this week. For a while we have had the goal of devolving as many of the libraries that ship with GHC as possible. With Cabal, this is now possible: you can download GHC and then install 3rd-party packages with little hassle, or upgrade libraries that came with your GHC installation. So the days of the monolithic GHC+libraries installations should perhaps come to an end. On the other hand, it's often quite useful to be able to install a single distribution and get a comprehensive set of libraries. The folks who package GHC for the deeply package-based OSs like Debian, Gentoo and *BSD would like GHC to come with a minimal set of libraries and install the others as separate packages. Another consideration is that it's useful for our nightly builds to build as many libraries as possible, so we can help catch bitrot. However, the default GHC build now takes a very long time mostly due to the huge set of libraries, and most people building GHC don't need to build eg. OpenGL by default. What's more, the maintainers of many of these libraries would like to be able to make releases independently of GHC. So here's what I propose: - A "GHC source tree" will contain a core set of packages. This is what you will get if you download ghc-6.6-src.tar.bz2, or do "sh darcs-all get" in a darcs repo. The core packages are: base, haskell98, template-haskell, readline, stm, Cabal, unix, Win32 plus hopefully regex-base and regex-posix if I integrate them this week. These are the packages required to bootstrap GHC, or those with deep GHC dependencies (template-haskell & stm). - The core packages will have a stable API across patchlevel releases of GHC (perhaps with the exception of Cabal). We will fork the darcs repos of the core packages where necessary. - A source tree can optionally be populated with more packages, which will be included in the build as normal. At the moment, the only packages you can add in this way are: ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi, fgl, haskell-src, html, mtl, network, parsec, time, xhtml because we're still using GHC's build system to build packages rather than Cabal. When we switch to using Cabal to build packages inside a GHC build, then it will be possible to populate the tree with any Cabal package. Possibly we could also distribution an "extra libs" source bundle containing these packages. - We will continue to build all these packages in the nightly builds. (but perhaps build failures in optional packages should not break the whole build). - darcs-all will have an option to grab the optional packages (all the packages in the list above). - Gentoo, Debian etc. will include only the core packages with GHC, the others will become separate entities. - We will continue to bundle the .tar.bz2 binary distributions, and the Windows installer, with all the optional packages. Perhaps there could also be minimal installers containing just the core packages. - We may have to change the set of core packages in the future, if GHC accumulates more dependencies for example. Any comments, or suggestions? Cheers, Simon

6 16

Re: Packages in GHC 6.6
by Krasimir Angelov 25 Aug '06

25 Aug '06

I wrote simple tool that I am using to build MSI installer for Visual Haskell. It will not be so hard to extend it to support Cabal. After that it will be easy to prepare an installer for GHC with optional libraries. Don't expect it to be ready for 6.6 release! Cheers, Krasimir On 8/22/06, Jason Dagit <dagit(a)eecs.oregonstate.edu> wrote: > [snipped] > For the windows installer, I imagine this working something like the > cygwin or ms office installer. There could be a screen listing all > the libraries and the installer itself comes in two flavors, either > contains only the minimum (and uses the network to grab any > additional) or the installer contains everything and lets the user > select which packages to install (defaulting to everything).

3 5

Data.Generics vs. Template Haskell
by Vyacheslav Akhmechet 24 Aug '06

24 Aug '06

I am trying to figure out where these two libraries stand in relation to each other and which one is preferred to do generic programming in Haskell. I understand that their goals often intersect but couldn't find any good comparisons. Could someone point me in the right direction? Thanks, - Slava Akhmechet

4 3

Re: Data.Generics vs. Template Haskell
by Vyacheslav Akhmechet 24 Aug '06

24 Aug '06

---------- Forwarded message ---------- From: Vyacheslav Akhmechet <coffeemug(a)gmail.com> Date: Aug 24, 2006 5:35 PM Subject: Re: Data.Generics vs. Template Haskell To: Bulat Ziganshin <Bulat.Ziganshin(a)gmail.com> Ok, so there are two aspects that I can see here. One such aspect is ability to "reflect" on types (at runtime or compile time). An example of that is creating an automatic mapping from relational databases to haskell newtypes. Another aspect is being able to get an a representation of Haskell code AST in terms of Haskell datatypes in order to be able to process Haskell ASTs in Haskell. As far as I can see the first aspect is a subset of the second because all Haskell types are known at compile time. If this is the case, why the need for two libraries (I am not counting DriFT because it looks like it hasn't been maintained for a long time)? Or am I missing something? Additionally, which one is more maintained and has the most potential to become standard (whether de facto or real) in the future? On 8/24/06, Bulat Ziganshin <bulat.ziganshin(a)gmail.com> wrote: > Hello Vyacheslav, > > Thursday, August 24, 2006, 11:51:46 PM, you wrote: > > > I am trying to figure out where these two libraries stand in relation > > to each other and which one is preferred to do generic programming in > > Haskell. I understand that their goals often intersect but couldn't > > find any good comparisons. Could someone point me in the right > > direction? > > search for "generics" on hswiki, you should find a lot of papers. in > particular, there is a new paper that compares many different > approaches to generic programming. in particular, TH is not g.p. > tools, it's just a universal Haskell code generator whcih can be used > to solve particular tasks in this area. but to solve general problem > of defining traversal function what has some general case and a nu,ber > of type-specific cases TH is not very appropriate > > TH (and DriFT) are widely used to generate instances like the haskell > compiler itself generates instances for Eq/Show/... and TH, > unlike many g.p. tools does it at compile-time. using TH, you also get > access to field/constructor names > > summary: if your task fits into the features provided by g.p. tools, > you will gain a much time using them. if your task need compile-time > code generation (so that generic program will be no slower than > hand-written one) or you need some advanced features which your g.p. > tool doesn't provide - welcome to TH with all its programming > oddities. development of TH routines for g.p. is an order of magnitude > slower (at least!) than doing the same with specialized tool > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > >

1 0

RE: Packages in GHC 6.6
by Simon Marlow 24 Aug '06

24 Aug '06

On 24 August 2006 11:20, Henning Thielemann wrote: > On Tue, 22 Aug 2006, Simon Marlow wrote: > >> - A source tree can optionally be populated with more packages, >> which will be included in the build as normal. At the moment, >> the only packages you can add in this way are: >> >> ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi, >> fgl, haskell-src, html, mtl, network, parsec, time, xhtml >> >> because we're still using GHC's build system to build packages >> rather than Cabal. When we switch to using Cabal to build >> packages inside a GHC build, then it will be possible to populate >> the tree with any Cabal package. >> >> Possibly we could also distribution an "extra libs" source >> bundle containing these packages. > > Just a question: Will it still be possible to have an Haddock index of > _all_ installed libraries without hassle? I know haddock supports > this, but how easy will it be to achieve that? Since the distributions we build with the nightly builds will have all the libraries, the Haddock docs in the distributions we ship will have complete integrated indices. This means that making a minimal distribution in a build tree that has everything is not just a matter of removing stuff, also the Haddock index must be rebuilt, and the package database needs to have the extra packages removed too. Thanks for reminding me about this! I'm not sure we'll ship minimal binary installers for 6.6 yet, it depends whether we get to it before the release date. Cheers, Simon

4 3