May 2006 - Glasgow-haskell-users

Failure building HEAD in libraries/base/Data/ByteString.hs
by Reilly Hayes 15 May '06

15 May '06

I get the following error when trying to bootstrap the 6.5.20060506 snapshot from hc files (registerised): gcc -x c Data/ByteString.hc -o Data/ByteString.raw_s -S -O -fno- defer-pop -fomi t-frame-pointer -mdynamic-no-pic -DDONT_WANT_WIN32_DLL_SUPPORT - mdynamic-no-pi c -D__GLASGOW_HASKELL__=605 -O -mdynamic-no-pic -I/Users/rfh/haskell/ mac/ghc-6. 5.20060506/includes -I/Users/rfh/haskell/mac/ghc-6.5.20060506/ libraries/base/inc lude -I/Users/rfh/haskell/mac/ghc-6.5.20060506/libraries/unix/include -I/Users/r fh/haskell/mac/ghc-6.5.20060506/libraries/parsec/include -I. `echo | sed ' s/^$/-DSTOLEN_X86_REGS=4/'` Data/ByteString.hc: In function 'DataziByteString_zdwccall_entry': Data/ByteString.hc:8631: error: unable to find a register to spill in class 'DIR EG' Data/ByteString.hc:8631: error: this is the insn: (insn 22 45 23 0 (parallel [ (set (reg:SI 2 cx [64]) (unspec:SI [ (mem:BLK (reg:SI 1 dx [orig:66 _cdHE ] [66]) [0 A8]) (reg:QI 0 ax [68]) (const_int 1 [0x1]) (reg:SI 2 cx [67]) ] 20)) (use (reg:SI 19 dirflag)) (clobber (reg:SI 1 dx [orig:66 _cdHE ] [66])) (clobber (reg:CC 17 flags)) ]) 479 {*strlenqi_1} (insn_list:REG_DEP_TRUE 18 (insn_list:REG_DEP_TRUE 19 (insn_list:REG_DEP_TRUE 20 (insn_list:REG_DEP_TRUE 21 (nil))))) (expr_list:REG_UNUSED (reg:CC 17 flags) (expr_list:REG_UNUSED (reg:SI 1 dx [orig:66 _cdHE ] [66]) (expr_list:REG_DEAD (reg:SI 19 dirflag) (expr_list:REG_DEAD (reg:SI 2 cx [67]) (expr_list:REG_DEAD (reg:QI 0 ax [68]) (expr_list:REG_DEAD (reg:SI 1 dx [orig:66 _cdHE ] [66]) (expr_list:REG_UNUSED (reg:CC 17 flags) (expr_list:REG_UNUSED (reg:SI 1 dx [orig:66 _cdH E ] [66]) (nil)))))))))) Data/ByteString.hc:8631: confused by earlier errors, bailing out make[1]: *** [Data/ByteString.raw_s] Error 1 make: *** [all] Error 1 I am insufficiently experienced with the build process to know if this was from an error in creating the .hc file or a problem with the source. I have noticed that the file ByteString.hs seems to be new. I am building the .hc files on 386 linux (Ubuntu breezy badger): linux kernel 2.6.12 ghc-6.5.20060502 is installed gcc is 4.0.2 I am using the registerised .hc files to bootstrap to Max OS X x86 Mac OS X 10.4.6 no ghc installed gcc is 4.0.1 (as included in Xcode) Reilly Hayes

3 9

GHC Hackathon
by Simon Peyton-Jones 12 May '06

12 May '06

Friends, A couple of weeks ago Simon M advertised the possibility that he and I might run a "GHC Hackathon", in Portland, later this year prior to ICFP (Sept 14-16 or thereabouts). The idea is that we'd give an extended tutorial about GHC's glorious innards. Then we'd have some hacking time in which you can pick something which you think GHC could do better, and implement it, with Simon and me wandering causing trouble. (E.g. look at GHC's list of tasks http://hackage.haskell.org/trac/ghc/report/2, but don't limit yourself to those.) We're trying to find out whether anyone would come if we ran it. At the Haskell workshop in Tallinn, around 30 people put up their hand to say they were interested. So far, though, only 11 people responded on the Wiki page. That's on the borderline of whether it's worth doing the preparation and setup it'd need. So if you are the kind of person who's interesting in working on GHC (and the mailing list activity suggests that your numbers have increased sharply over the last 12 months), this message is to encourage you to go to the Wiki page: http://hackage.haskell.org/trac/ghc/wiki/Hackathon Please vote in the little (2-question!) survey, to indicate your interest, and add any comments and suggestions of you own. Excerpts below. Could be fun. Simon ============================ The 2006 GHC hackathon At the 2005 Haskell workshop we were asked to consider running a "GHC hackathon" around ICFP 2006. A surprisingly large number of people in the room indicated that they'd be interested in coming to such a thing. This Wiki page says what we have in mind, and asks you to indicate whether you'd be likely to come, and what sort of meeting you'd like. What we do will depend on what you say. Purpose GHC is used by lots of people, but its implementation is rather over-centralised, even though GHC is a BSD-licensed, open-source project. The biggest obstacle to more people getting involved is that GHC is a big, and hence intimidating, system. The purpose of the GHC hackathon is to give a tutorial in GHC's innards, plus time to work on some projects in a context where there are plenty of people around to help. The objective is to substantially broaden (more numbers) and deepen (more confidence) the community of people who feel they know enough to fix and enhance GHC. We'll suggest some projects, but you're welcome to come along with your own wacky ideas or itches that you want to scratch, and work on them in an environment with a high-bandwidth connection to developers who really know the innards of GHC. You could work on something individual, or in small groups. We anticipate all being in one room, or in a tight group of rooms, so there'd be lots of informal interaction. Also there's a good chance it'll be fun :-) Venue Galois has very kindly agreed to host the meeting. Cost Zero. But you'll have to feed yourself. And you may have to bring a laptop (capable of building GHC). Programme We had in mind the following. One full day of tutorial from Simon & Simon about GHC's glorious innards. Then one or two days of hacking on projects. Timing: The Haskell workshop is on Sunday 17 Sept; ICFP starts the next day. On Saturday is the ML and Erlang workshops. We propose to run the GHC hackathon something like Thurs-Sat 14-16 Sept, so that people who want to go to the ML workshop still can; but those who don't won't have a blank day.

1 0

Parallel GHC on Altix?
by Chad Scherrer 12 May '06

12 May '06

Hi, I'd like to get more involved in parallel programming in Haskell, and I have access to an SGI Altix machine (a shared-memory multiprocessor). Can someone tell me, if I download a 64-bit GHC 6.5 snapshot, to what extent will parallelism "just work"? Specifically, I'm interested in * parallel evaluation strategies * nested data parallelism * forkIO, MVar's, and STM My understanding is that for the 32-bit version, this all works in parallel, but GC is sequential. Is that still the case? Is the 64-bit version in the same state? Finally, is there an estimated date for when 6.6 will be available? I'm happy to experiment with snapshots, but most admins around here are much more comfortable installing an official release of some sort. Thanks! -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

3 5

WordPtr,IntPtr,IntMax,WordMax
by John Meacham 12 May '06

12 May '06

I was curious if ghc could support the following basic types, they will likely just be aliases of existing types. WordPtr uintptr_t WordMax uintmax_t IntPtr intptr_t IntMax intmax_t all these C types are defined by ISO C so should be available, otherwise, they are easy enough to generate in ghcs autoconf script. jhc provides these under these names in Data.Word and Data.Int. they would be useful for writing jhc/ghc portable low level code, and writing 32/64 bit safe code. John -- John Meacham - ⑆repetae.net⑆john⑈

9 18

package net question
by jur 11 May '06

11 May '06

Hello, I've been building the head and in my adaptation i need package net. I added this to the SRC_HC_OPTS, which made at least the haskell compile to hi/o. But when the ghc-6.5 compiler is built I get the complaint that ghc- inplace does not have this package. Funny thing is that when I omit the -package net option, it does compile. What is the cause of all this? Must I reconfigure and build? Is there something else I am missing? I can imagine that it is determined from the SRC_HC_OPTS which packages must be built for ghc-inplace, but maybe there is a different reason. Note that I did not do a rebuild (and I would like to avoid reconfiguring and building since it takes ages on my machine). And before I do it, it would be nice to know that this solves the not overly large problem. So, can anyone tell me? thanks, Jur

2 1

Installation of Visual Haskell
by Allen Brown 10 May '06

10 May '06

I have just installed Visual Haskell as per the instructions at http://www.haskell.org/visualhaskell/. I do not see Visual Haskell among the supported languages on the splash screen. On the other hand, there is a "Haskell Projects" folder under the new projects that can be created and the Visual Haskell documentation is apparent under the documentation tree rooted at "Visual Haskell Help Collection". Finally, if I try to create either a console project or a library project, the respective pop-up error messages The application for project 'C:\Program Files\Visual Haskell\Templates\Projects\Console Application.cabal is not installed. Make sure the application for the project type (.cabal) is installed. The application for project 'C:\Program Files\Visual Haskell\Templates\Projects\Library Package.cabal is not installed. Make sure the application for the project type (.cabal) is installed. ensue. I gather from all of the above that the installation must be incomplete in some fashion. I should also point out 3 (possibly relevant) things about my environment: 1. I am running both Visual Studio 2005 and Visual Studio .Net 2003 (the academic version). 2. I do not have the Visual Studio .Net 2003 documentation installed. (I reinstalled VS .Net 2003 for the sole purpose of running Visual Haskell. So I deemed the documentation unnecessary. In this aspect the installation is incomplete.) 3. I am running standalone versions of both GHC 6.4 and 6.5. Allen L. Brown, Jr., Ph.D. Senior Software Architect Advanced Strategies and Policy (Incubations) Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA +1 425 705-3290 (voice) +1 425 985-8961 (mobile) +1 425 706-7329 (fax) <mailto:allenbr@microsoft.com> allenbr(a)microsoft.com (email)

2 1

HEAD: Problem with compat/cbits/unicode.c
by Reilly Hayes 10 May '06

10 May '06

compat/cbits/unicode.c contains the following line: #if __GLASGOW_HASKELL__ < 604 || (__GLASGOW_HASKELL__==604 && __GHC_PATCHLEVEL__==0) __GHC_PATCHLEVEL__ is set by compat/Makefile to be equal to GhcPatchLevel, which seems to be set to the patch level of the INSTALLED Ghc compiler. If there is no installed Ghc compiler, __GHC_PATCHLEVEL__ is blank and unicode.c fails to compile because && wants another operand. I took the lazy to this by setting GhcPatchLevel in my mk/build.mk file. Reilly Hayes rfh(a)reillyhayes.com

2 1

Unregisterised GHC 6.4.2 on the ARM success -- now what?
by Jeremy Shaw 10 May '06

10 May '06

Hello, I believe I have successfully got an unregisterised version of ghc 6.4.2 compiled for arm/linux. Details: ------- I only had to do a minor bit of hacking -- this bug contains the details of what went wrong: http://hackage.haskell.org/trac/ghc/ticket/762 My target platform is the nokia 770 which runs linux and has an arm9 processor. I compiled ghc using the standard nokia 770 cross-development tools. These consist of a debian-based distro named maemo running inside scratchbox using QEMU to emulate the ARM processor. I have successfully compiled a "hello, world!" program and run the executable on the real nokia 770 device. What Next? ---------- The next step appears to be to registerise the build. I found a document that describes the C calling conventions for the ARM: http://www.arm.com/miscPDFs/8031.pdf I think the next step is to add an ARM section to: ghc/includes/MachRegs.h Is there some sensible method for doing this and testing it before I tackle the other pieces ? Thanks! j.

4 7

HEAD: problems with suffix.mk for registerised hc-boot
by Reilly Hayes 10 May '06

10 May '06

The rules in suffix.mk don't seem to work for building in $(TOP)/ compiler/stage1 when building from .hc files. Make dies complaining that it doesn't know how to build the .o file. The relevant rules are: -------- # with mangling $(odir_)%.raw_s : %.hc $(CC) -x c $< -o $@ -S -O $(HC_BOOT_CC_OPTS) -I. `echo $(patsubst - monly-%-regs, -DSTOLEN_X86_REGS=%, $(filter -monly-%-regs, $ ($*_HC_OPTS))) | sed 's/^$$/-DSTOLEN_X86_REGS=4/'` $(odir_)%.s : %.raw_s $(MANGLER) $< $@ $(patsubst -monly-%-regs, %, $(filter -monly-%- regs, $($*_HC_OPTS))) $(odir_)%.o : %.s $(CC) -c -o $@ $< -------- The problem is that the dependency chain is broken when the source & build directory are different. Assuming that .raw_s and .s files belong in the build directory (stage1, etc), I believe the rules should look like: -------- # with mangling $(odir_)%.raw_s : %.hc $(CC) -x c $< -o $@ -S -O $(HC_BOOT_CC_OPTS) -I. `echo $(patsubst - monly-%-regs, -DSTOLEN_X86_REGS=%, $(filter -monly-%-regs, $ ($*_HC_OPTS))) | sed 's/^$$/-DSTOLEN_X86_REGS=4/'` $(odir_)%.s : $(odir_)%.raw_s $(MANGLER) $< $@ $(patsubst -monly-%-regs, %, $(filter -monly-%- regs, $($*_HC_OPTS))) $(odir_)%.o : $(odir_)%.s $(CC) -c -o $@ $< -------- Reilly Hayes

2 1

Problems building HEAD
by Reilly Hayes 10 May '06

10 May '06

I'm trying to build head (latest try with ghc-6.5.20060429) for my macbook pro (Mac OS X intel) using hc files built on a x86 linux (Ubuntu Breezy Badger). I have the following issues: 1) Issues with bookstrap.mk bootstrap.mk in head contains the following lines TOP_SAVED := $(TOP) TOP:=$(TOP)/ghc include $(TOP)/mk/version.mk include $(TOP)/mk/paths.mk # Reset TOP TOP:=$(TOP_SAVED) However, those files are not at those locations. Looking back at 6.4.2, it seems that they were in those locations in 6.4.2, but that changes in the directory structure mean that the line that sets top to $(TOP)/ghc is obsolete. version.mk is nowhere to be seen, nor is version.mk.in. It looks as if the variables set in this file are now set in config.mk and that version.mk is no longer required. If that's true, I can replace all of the lines above with: include $(TOP)/mk/paths.mk 2) Building the .hc files The building guide says that I can build hc files on another host running on the same platform. The word platform seems to be used to describe architecture in some places and architecture & O/S in others. I have assumed that it means architecture in this case (if we already have a compiler that runs on the same Arch & OS, why are we porting). What the building guide does not do is provide instructions for producing registerized hc files. The recipe I have stumbled onto is this a) Create mk/build.mk and add the following lines: GhcLibHcOpts = -O -fvia-C -keep-hc-files GhcRtsHcOpts = -keep-hc-files GhcStage1HcOpts = -O -fvia-C -keep-hc-files GhcStage2HcOpts = -O -fvia-C -keep-hc-files b) run "./configure" c) run "make" d) I want to run "make hc-file-bundle Project=ghc", but it complains about a few missing files. So first I cd to rts and run "make AutoApply.hc AutoApply_p.hc AutoApply_thr.hc \ AutoApply_thr_p.hc AutoApply_debug.hc AutoApply_thr_debug.hc" e) run "make hc-file-bundle Project=ghc", which works just fine. f) untar the resulting file in the parent directory of ghc-6.5.20060429 on the target machine 3) running the build. I'm following the steps in distrib/hc-build by hand, which work out to: ./configure --enable-hc-boot make -C utils boot all make -C ghc boot make -C libraries boot all GhcBootLibs=YES make -C ghc all Is this all correct? I'm having problems with the build in utils, but by then I've already made enough assumptions about how to fix the build that there's little point in asking the question until I've verified that I haven't messed things up upstream. Reilly Hayes

3 3