- Glasgow-haskell-users

HOpenAL and Haskore
by Juan Rodríguez Hortalá 24 Sep '06

24 Sep '06

Hello everybody, I have a suggestion and a question. The first is about Haskore, I think it would be cool if it could be included in the distribution of GHC. And the later is about HOpenAL. Some information is found in http://www.haskell.org/HOpenGL/newAPI/index.html , on the entry for Sound, but I wonder if there is some tutorial or additional documentation anywhere. Because in http://www.haskell.org/communities/11-2005/html/report.html it is said that "The OpenAL and ALUT packages have not been released yet, but they are already usable and almost feature-complete", and the are supplied with GHC, so maybe I could start learning HOpenAL right now. I have searched for the HOpenAL home page in http://haskell.org/haskellwiki/Libraries_and_tools/Music_and_sound and in google but I haven't found it. Can anybody help me? Thanks in advance -- ________________________________________________________________________ Juan Rodríguez Hortalá

2 1

Re: User preferences lost between Hugs upgrades on Windows
by Claus Reinke 24 Sep '06

24 Sep '06

[some possibly shared hugs/ghci concerns] > The settings on Windows are stored under a registry key for each > specific release. This means that if you install WinHugs, carefully > set up everything, then upgrade, you loose all your settings. part of the reason was also to enable multiple independent versions of Hugs to be installed, I think? So: a) shouldn't there be a way from within Hugs (or GHCi) to export/import settings? b) shouldn't there be an installation option checking for compatible old settings and offering to copy them? c) given the move towards cabal, shouldn't there be a way for new Hugs/GHC installs to take over existing library install setups (provided that the libraries sources haven't been removed, and that the rebuild is possible with the new Haskell implementation)? while on the subject of user preferences, does the current round of Hugs/GHC releases on Windows do away with that "we take over the handling of Haskell files, no matter what the user wanted"? - it's a pain to have Hugs and GHCi compete with each other on this - I don't want either to be the default handler for .hs/.lhs files; not only do I tend to have several versions of Haskell implementations installed at any time (usually including 2 ghcs), I want Haskell files to open in my favourite editor, not in any of those Haskell implementations (and no, going via WinHugs :e is not an option, eg when browsing files from some darcs repo on the web) any chance of Haskell implementations being less greedy and more cooperative on Windows this time round?-) cheers, claus

2 3

6.6 strikes me again :)
by Bulat Ziganshin 22 Sep '06

22 Sep '06

Hello glasgow-haskell-users, attached module compiles fine with ghc 6.4.2, hugs 2003+, but not with my ghc 6.5 snapshot. it says: 66.hs:9:0: Illegal instance declaration for `Stream m (StringReader r)' (the Coverage Condition fails for one of the functional dependencies) In the instance declaration for `Stream m (StringReader r)' -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 3

Data.FiniteMap
by Duncan Coutts 20 Sep '06

20 Sep '06

Is it too late to ask that Data.FiniteMap not die just yet? There are a number of progs/libs that this affects. It's not that people do not want to use the new Data.Map, but people are worried about having to drop support for earlier compilers. Data.Map only appeared in 6.4 iirc. So this forces packages to drop support for 5.04, 6.0 and 6.2. Perhaps 5.04 and 6.0 are not so important, but many people still use 6.2.2, particularly institutions, which tend to be slow to upgrade. I think there is a wrapper somewhere that provides the old Data.FiniteMap in terms of the Data.Map implementation. Could we use something like that in base for at least one more release? By the time of 6.8 I think people will be less concerned as 6.2 will be quite old by that time. Duncan

6 7

Update to Replacement GMP page
by Peter Tanski 20 Sep '06

20 Sep '06

Hello all, I made another update to the notes on Replacing GMP, at http:// hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes . It's pretty basic and you'd probably find it shabby, but comments, modifications appreciated. I am still in the throes of trying to *portably* beat GMP for speed and accuracy. (The portability problem comes in when I may no longer rely on Altivec/SSE/3DNow! support on other processors and need to optimise in pure C.) -Pete

1 0

small errors in ghc 6.6
by Bulat Ziganshin 20 Sep '06

20 Sep '06

Hello glasgow-haskell-users, i've put my hands on the ghc 6.6/mingw32 dated 1st september (http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-…) overall, compilation of my 5 kloc application was fine. on the 6.2->6.4 transition, i was bitten by two API changes, but this time all APIs and language features i used remains stable. it's great! the most funny part was that parallel arrays are still work :))) nevertheless, i've captured several minor problems: 1. ghc +RTS -A10m aborts with the message: ghc.exe: getMBlocks: VirtualAlloc MEM_COMMIT failed: The parameter is incorrect. although i guess that it was already fixed since 1st September. btw, how about adding using various RTS switches to ghc as test cases? GHC is very large program and any problems with RTS flags would be captured in this way 2. ghc compilation don't includes directory where Rts.h, Stg.h and similar files resides, "$(GHC)\lib\i386-unknown-mingw32\include" on my installation. it results in failing of via-C compilation, compilation of *stub.c files, and inclusion of "Typeable.h". i was going around this problem by using -I switch. it's possible that it's just packaging problem. again - isn't it possible to catch this problem by testsuite? imho, that this error was not catched means that windows version isn't really tested by anyone? how about trying to build various packages on mingw32 version as test before releasing 6.6? 3. ghc 6.6 includes smart relinking capability which don't relink exe file if it already exists and .hs source files was not changed. that's great but ignores other .o files that can be also linked to program, for example those that was compiled from C sources: gcc -c -o a.o a.c ghc --make Main.hs a.o this command incorrectly don't relinks executable if a.c was changed but Main.hs wasn't -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 4

one more typo
by Bulat Ziganshin 19 Sep '06

19 Sep '06

Hello glasgow-haskell-users, 7.4.10 of user guide say: -- f and g assume that 'a' is already in scope f = \(x::Int, y) -> x g (x::a) = x seems that f definition should contain 'a' -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Change Data.Bits.rotate to rotate Integer (unbounded) types
by Peter Tanski 19 Sep '06

19 Sep '06

Welcome back! Since Data.Bits is not defined in the Haskell 1998 standard, are we free to change the implementation of Data.Bits? if we are free to change the implementation of Data.Bits, would it be all right to change the operation of rotate, rotateL and rotateR over unbounded types (to my knowledge, currently only Integer)? I would like to change rotate, rotateL and rotateR to actually rotate (not shift) Integers. -Pete

4 6

Help with unregisterised build
by Peter Tanski 16 Sep '06

16 Sep '06

Hello Jeremy, I don't know if anyone has gotten back to you on this yet. I have not myself done an unregisterised build of GHC before, but I thought you should at least hear something. The people who know about this all seem to be at the ICFP programme that has been going on since Thursday; they should be back next week. In the meantime, some work has been done recently on the way GHC puts out assembler--not quite the same problem as a multiply-defined-symbol error--but you might consider grabbing darcs and trying to build from the HEAD branch. See <http://hackage.haskell.org/trac/ghc/wiki/Building/ GettingTheSources>. -Pete Jeremy Wazny wrote: > I've attempted to build an installation of GHC which uses > unregisterised libraries, but have not had much success. I am new to > GHC's build system and would be grateful for some advice. > > I'm trying to build the 6.4.2 source distribution on an x86 linux > machine, using GHC 6.4.2 (the "Generic Linux with glibc2.3" version on > the download page.) The target is the same machine. > > I've created a mk/build.mk file containing just the line: > > GhcUnregisterised = YES > > which, according to the comment in mk/config.mk, ought to build the > unregisterised libraries that I'm after (and use them by default.) > > I run configure as follows: > > ./configure --prefix="$HOME"/ghc_u > > and then simply "make". > > After some time, the build fails with the following: > > ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude > -"#include" HsBase.h -funbox-strict-fields -ignore-package base -O > Rghc-timing -fgenerics -fgenerics -split-objs -c GHC/Base.lhs -o > GHC/Base.o -ohi GHC/Base.hi > /tmp/ghc4237.s: Assembler messages: > /tmp/ghc4237.s:17: Error: symbol `__stg_split_marker' is already > defined > /tmp/ghc4237.s:29: Error: symbol `__stg_split_marker' is already > defined > /tmp/ghc4237.s:41: Error: symbol `__stg_split_marker' is already > defined > /tmp/ghc4237.s:53: Error: symbol `__stg_split_marker' is already > defined > > .... This goes on for a while ... > > <<ghc: 124912780 bytes, 12 GCs, 808164/1513632 avg/max bytes residency > (2 samples), 19M in use, 0.00 INIT (0.00 elapsed), 0.59 MUT (2.39 > elapsed), 0.10 GC (0.09 elapsed) :ghc>> > make[2]: *** [GHC/Base.o] Error 1 > make[1]: *** [all] Error 1 > make[1]: Leaving directory > `/mnt/raid/home/jeremyrw/src/src/ghc-6.4.2/libraries' > make: *** [build] Error 1 > > > I've also tried with the following build.mk > (I was guessing the -fvia-C might avoid the above assembler problem.): > > GhcUnregisterised = YES > GhcLibHcOpts = -O -fvia-C > > but it fails in the same way. > > I'm not sure what to do at this point. > Am I missing something in the build.mk? > > Is there likely to be anything else that needs to be tweaked? > > Has anybody had any success with this sort of thing before?

1 0

Build failures in packages built with GHC 6.6
by Duncan Coutts 14 Sep '06

14 Sep '06

Hi folks, Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell packages with the latest GHC 6.6 RC snapshot. Here is his report of what failed, and how: http://www.haskell.org/~gentoo/gentoo-haskell/projects/GHC-6.5-failures.html You'll note that there are some common ones, like Data.FiniteMap going away and the old API in Data.Set disappearing. There seemed to be several programs which used the old lang or text packages. The change in the array bounds api broke some things. Text.Regex moved into a different package. Most of these look fairly trivial. Class instance changes broke a couple packages, which might be a bit more tricky to fix. One Cabal api change broke one package, again easily fixable. We made some Cabal modules that had been private by convention properly private (ei Distribution.Compat.*). This broke lhs2tex. I'm not sure exactly what Cabal scripts should be using for portable file path handling since Setup.hs modules are not supposed to have external dependencies on other packages (otherwise there's a chicken and egg problem with compiling Setup.hs). Advice here would be apreciated, I could let Distribution.Compat.FilePath remain public in this release and seek a better solution for the next release. BTW, you can see the complete set of Gentoo's Haskell packages here: http://www.haskell.org/~gentoo/gentoo-haskell/ (mostly under dev-haskell/) Gentoo users & developers can use this package collection as a portage overlay. Duncan (wearing his Cabal release manager hat and his Gentoo hat)

4 5