December 2005 - Glasgow-haskell-users

utf8 strings: memory optimization and case-ignoring comparision
by Bulat Ziganshin 14 Dec '05

14 Dec '05

Hello glasgow-haskell-users, i use utf8-packed strings in my program and have to ask 2 questions about them: 1. i need function to do case-ignoring comparision of such strings. stricmp is not appropriate because it don't know about utf8. can be the existing Unicode support in Data.Char used for these or can the appropriate support will be added? 2. what is the most memory-efficient representaion for such strings? now i use John Meacham's library (http://repetae.net/john/repos/jhc/PackedString.hs) which declares: newtype PackedString = PS (UArray Int Word8) but this uses two Ints just to hold index bounds: data UArray i e = UArray !i !i ByteArray# i want to use just memory ptr and put NUL at the end of array (my strings never contain NUL chars). but what type i must use for this ptr? ByteArray/ByteArray#, ForeignPtr, StablePtr, Ptr?? and which function i must use to quickly allocate memory i need? my packed strings will be only unpacked and passed to "unsafe" C functions: stricmp, strcpy, strcat; i plan to not use any other operations -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

RE: Preparing a Registered hc-file-bundle (Was Bootstrapping withHC files)
by Simon Marlow 14 Dec '05

14 Dec '05

On 13 December 2005 18:58, Andrew Walrond wrote: > Well, I gave it a blast anyway. All went well creating the hc files > until the last command: > >> $ make hc-file-bundle Project=Ghc > > at which point it failed with > > tar czf ghc-6.4.1-x86_64-unknown-linux-hc.tar.gz `cat hc-files-to-go` > tar: ghc-6.4.1/ghc/rts/AutoApply_thr.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/AutoApply_thr_p.hc: Cannot stat: No such file > or directory > tar: ghc-6.4.1/ghc/rts/AutoApply_debug.hc: Cannot stat: No such file > or directory > tar: Error exit delayed from previous errors > make: *** [hc-file-bundle] Error 2 Yes, these are harmless. They are caused by the fact that AutoApply.cmm is auto-generated in several different ways (AutoApply_thr.cmm, AutoApply_debug.cmm etc.), and the .hc files for these are named AutoApply_thr.thr_hc, AutoAPply_debug.debug_hc, and so on. The Makefile code for hc-bundle doesn't know about this special case. > Googling suggests this might be harmless, so I tried bootstrapping on > the target machine using the created tarball, but that failed with > > /bin/ld: cannot find -lghccompat > collect2: ld returned 1 exit status > make[1]: *** [stage1/ghc-6.4.1] Error 1 > make: *** [all] Error 1 > make: Leaving directory > `/home/andrew/test/ghc/bs/target/ghc-6.4.1/ghc' Please send us a full log of the build. libghccompat.a should be in ghc/lib/compat, and it should be built quite early on. Cheers, Simon

1 0

RE: Preparing a Registered hc-file-bundle (Was Bootstrapping with HCfiles)
by Simon Marlow 14 Dec '05

14 Dec '05

On 13 December 2005 11:05, Andrew Walrond wrote: > On the HOST > ----------------- > > Unpack src tree, and cd into it. > > Configure with necessary options > $ ./configure --prefix=... > > Section 10.2.1'Cross-compiling to produce an unregisterised GHC' in > the build manual suggests creating an mk/build.mk with following > contents: GhcUnregisterised = YES > GhcLibHcOpts = -O -fvia-C -keep-hc-files > GhcRtsHcOpts = -keep-hc-files > GhcLibWays = > SplitObjs = NO > GhcWithNativeCodeGen = NO > GhcWithInterpreter = NO > GhcStage1HcOpts = -O > GhcStage2HcOpts = -O -fvia-C -keep-hc-files > SRC_HC_OPTS += -H32m > GhcBootLibs = YES > Reading between the lines somewhat, for a full registered version we > might need something like > GhcUnregisterised = NO > GhcLibHcOpts = -O -fvia-C -keep-hc-files > GhcRtsHcOpts = -keep-hc-files > GhcLibWays = > SplitObjs = NO > GhcWithNativeCodeGen = YES > GhcWithInterpreter = YES > GhcStage1HcOpts = -O > GhcStage2HcOpts = -O -fvia-C -keep-hc-files > SRC_HC_OPTS += -H32m > GhcBootLibs = YES > Advice on this bit gratefully received! This should be fine, except that you can leave out some of it - you probably want the default settings for GhcWithNativeCodeGen and GhcWithInterpreter, and the GhcUnregisterised should default to NO. > The manual next suggests copying some target generated include files > into the host ghc source, but since they are the same I guess we can > ignore that bit. > > Now building exactly as described in the manual: > > $ pushd glafp-utils && make boot && make && popd > $ pushd ghc && make boot && make && popd > > Manual suggests the build might fail in RTS, but probably not for our > registered version ? building the RTS should work, yes. > $ pushd libraries && make boot && make && popd > $ pushd ghc/compiler && make boot stage=2 && make stage=2 && popd > > $ pushd ghc/lib/compat > $ make clean > $ rm .depend > $ make boot UseStage1=YES > $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' > $ popd > $ pushd ghc/utils > $ make clean > $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' > $ popd > $ make hc-file-bundle Project=Ghc > > That should provide us with our hc-file-bundle, *-hc.tar.gz > > On the TARGET > -------------------- > > Unpack src tree, unpack the hc file bundle on top of it. > Cd into the src tree. > > Now it should be a simple matter of > $ distrib/hc-build --prefix=dir > $ make install Looks good! Cheers, Simon

1 0

Preparing a Registered hc-file-bundle (Was Bootstrapping with HC files)
by Andrew Walrond 13 Dec '05

13 Dec '05

Ok, so now we know its possible! Now the question is how to create and use a _registered_ hc file bundle. The Build manual describes the process of cross compiling an _unregistered_ hc file bundle, but has nothing to say about creating the simpler registered hc file bundle for the purpose of bootstrapping GHC on an equivalent supported platform but without a preinstalled ghc. So, reading between the lines a little, here is what I propose trying. Please take a look, and give me your thoughts if you think I am on the wrong track! HOST: Has ghc, happy, alex installed. TARGET: Same as host, but without ghc, happy alex. On the HOST ----------------- Unpack src tree, and cd into it. Configure with necessary options $ ./configure --prefix=... Section 10.2.1'Cross-compiling to produce an unregisterised GHC' in the build manual suggests creating an mk/build.mk with following contents: GhcUnregisterised = YES GhcLibHcOpts = -O -fvia-C -keep-hc-files GhcRtsHcOpts = -keep-hc-files GhcLibWays = SplitObjs = NO GhcWithNativeCodeGen = NO GhcWithInterpreter = NO GhcStage1HcOpts = -O GhcStage2HcOpts = -O -fvia-C -keep-hc-files SRC_HC_OPTS += -H32m GhcBootLibs = YES Reading between the lines somewhat, for a full registered version we might need something like GhcUnregisterised = NO GhcLibHcOpts = -O -fvia-C -keep-hc-files GhcRtsHcOpts = -keep-hc-files GhcLibWays = SplitObjs = NO GhcWithNativeCodeGen = YES GhcWithInterpreter = YES GhcStage1HcOpts = -O GhcStage2HcOpts = -O -fvia-C -keep-hc-files SRC_HC_OPTS += -H32m GhcBootLibs = YES Advice on this bit gratefully received! The manual next suggests copying some target generated include files into the host ghc source, but since they are the same I guess we can ignore that bit. Now building exactly as described in the manual: $ pushd glafp-utils && make boot && make && popd $ pushd ghc && make boot && make && popd Manual suggests the build might fail in RTS, but probably not for our registered version ? $ pushd libraries && make boot && make && popd $ pushd ghc/compiler && make boot stage=2 && make stage=2 && popd $ pushd ghc/lib/compat $ make clean $ rm .depend $ make boot UseStage1=YES $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' $ popd $ pushd ghc/utils $ make clean $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' $ popd $ make hc-file-bundle Project=Ghc That should provide us with our hc-file-bundle, *-hc.tar.gz On the TARGET -------------------- Unpack src tree, unpack the hc file bundle on top of it. Cd into the src tree. Now it should be a simple matter of $ distrib/hc-build --prefix=dir $ make install Any comments/suggestions before I give it a try? Thanks for all help so far, and in anticipation of more! Andrew Walrond

1 1

RE: GHC wish list.
by Simon Marlow 13 Dec '05

13 Dec '05

Hi Lemmih, Might be a good idea to add these as feature requests: http://hackage.haskell.org/trac/ghc/newticket?type=feature+request Cheers, Simon On 13 December 2005 15:17, Lemmih wrote: > I've been using the GHC library in hIDE and HASP for some time now and > there are a few things I'd love to see implemented: > > * Changeable lexer/parser (just like DynFlags.log_action) > Not very important but it would be convenient in HASP. > * Cabalization of the library. > Not having a profiling version of the library and not being able to > rebuild it easily is a bit limiting. > * GHCi compatibility. > hIDE is currently using ghc-api[1] because the real library exports > symbols that clashes with GHCi.

1 0

GHC wish list.
by Lemmih 13 Dec '05

13 Dec '05

Hiya, I've been using the GHC library in hIDE and HASP for some time now and there are a few things I'd love to see implemented: * Changeable lexer/parser (just like DynFlags.log_action) Not very important but it would be convenient in HASP. * Cabalization of the library. Not having a profiling version of the library and not being able to rebuild it easily is a bit limiting. * GHCi compatibility. hIDE is currently using ghc-api[1] because the real library exports symbols that clashes with GHCi. -- Friendly, Lemmih [1] ghc-api: http://scannedinavian.com/~lemmih/ghc-api

1 0

RE: Bootstrapping with HC files
by Simon Marlow 13 Dec '05

13 Dec '05

On 12 December 2005 18:21, Andrew Walrond wrote: > 3) Why don't you guys supply hc tarballs for bootstrapping on common > platforms? They would seem to be rather more versatile than the usual > rpms and binary tarballs. A couple of reasons, neither of which is very convincing: 1. the HC files are sensitive to platform differences, so I'm not sure that HC files generated for one flavour of Linux would necessarily work on other flavours, for example. 2. building from HC files isn't well supported, and tends to be rather fragile, so we don't like to encourage it. The reason it isn't well supported is just lack of time. Cheers, Simon

1 0

RE: Bootstrapping with HC files
by Simon Marlow 13 Dec '05

13 Dec '05

On 12 December 2005 22:47, Donald Bruce Stewart wrote: > andrew: >> I run a source based linux distro called Heretix, and I want to make >> a ghc package which will install with or without an existing ghc. At >> the moment, we supply a binary-ghc package, whch is a prerequisite >> of the from-source ghc package. >> >> It seems to me that I can prepare HC tarballs for my target >> platforms (x86, x86_64) which will remove the need for the >> ghc-binary package. My questions: >> >> 1) Can I produce 'registered' hc files? The build manual bangs on >> about cross compiling unregistered hc files, which isn't really what >> I need. >> >> 2) Would a ghc built from registered hgc files every bit as good and >> complete as a normally bootstrapped ghc? > > Yes, the OpenBSD versions of GHC build from registerised .hc tar > balls. It's fast. > > If you're interested in this path, check out: > http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ That port is for 6.2.2 - do you have a 6.4.1 port too? Many thanks for keeping the .hc bootstrapping route working, BTW. It's a great help. Cheers, SImon

1 0

Bootstrapping with HC files
by Andrew Walrond 13 Dec '05

13 Dec '05

I run a source based linux distro called Heretix, and I want to make a ghc package which will install with or without an existing ghc. At the moment, we supply a binary-ghc package, whch is a prerequisite of the from-source ghc package. It seems to me that I can prepare HC tarballs for my target platforms (x86, x86_64) which will remove the need for the ghc-binary package. My questions: 1) Can I produce 'registered' hc files? The build manual bangs on about cross compiling unregistered hc files, which isn't really what I need. 2) Would a ghc built from registered hgc files every bit as good and complete as a normally bootstrapped ghc? If 1) and 2) then 3) Why don't you guys supply hc tarballs for bootstrapping on common platforms? They would seem to be rather more versatile than the usual rpms and binary tarballs. Thanks in advance! Andrew Walrond

4 5

Project options for GHC
by Iavor Diatchki 12 Dec '05

12 Dec '05

Hello, I have been using the .ghci file with GHCi to set global options for my project and I find it very useful. The kind of options I put there are: where to put .hi/.o files, what warnings to produce, where to look for code. etc. It works great. I was thinking that it would be very convenient to have the same ability when using 'ghc --make', because at the moment I have a number of the same options duplicated in my Makefile. Also, often I find myslef wanting to compile just one file (and all of its dependents), because GHCi tends to be a bit slow at compiling things, but is quite fast at loading object code. I can do this using 'ghc --make', but I also need to specify all the additional project options. I realize that I can achieve what I want with a little shell script, but a ghc-supported configuration file would be more portable and simpler to use. -Iavor

2 1