- Glasgow-haskell-users

4th Cabal-1.1.6 release candiate
by Duncan Coutts 07 Oct '06

07 Oct '06

Hi all, I've put up a tarball for the fourth 1.16 Cabal release candidate: http://www.haskell.org/cabal/release/cabal-1.1.5.9.4/cabal-1.1.5.9.4.tar.gz I had been hoping that this would be the final RC. One bug I've uncovered is that building the haddock docs for HUnit when cpphs is installed fails. This is because the Distribution.PreProcess.Unlit.unlit code produces incorrect output for Test/HUnit/Lang.lhs. I could do with some help in fixing this. One can reproduce it with: cd libraries/HUnit cpphs -OLang.lhs Test/HUnit/Lang.lhs --noline --strip -D__GLASGOW_HASKELL__=605 -D__HADDOCK__ ghc -e 'interact (Distribution.PreProcess.Unlit.unlit "Lang.lhs")' < Lang.lhs > Lang.hs compare this with: ghc -E Lang.lhs -o Lang.hspp and try: diff Lang.hspp Lang.hs Cabal's unlit code is incorrectly dropping whitespace and actual tokens. See especially the last part of that file. I think this needs fixing asap since the cpphs code path gets used in preference to the ghc -E path if cpphs is installed. In this example the symptoms are not too bad as it seems only to be affecting haddock, but I fear it may break more seriously in other packages. Duncan

1 0

building GHC (head) on windows MINGW: HsRegexPosixConfig.h: No such file or directory
by Rene de Visser 05 Oct '06

05 Oct '06

Hello, What do I need to install for the regex library support on MINGW? It looks like the regex library needs the posix library, and in my MINGW / MSYS installation I don't find one (and neither does configure). Rene.

3 3

core lib attempt#2: problem with hard-wired module names for classes in GHC
by Bulat Ziganshin 05 Oct '06

05 Oct '06

Hello glasgow-haskell-users, i'm now trying to rewrite GHC.* in more portable fashion, "boxifying" all the definitions in hope that smart compiler will unbox them itself of course, i'm using -fno-implicit-prelude and have found some more things that still hard-wired into compiler: 'c' syntax creates GHC.Base.Char instead of Char [a..b] requires instance of GHC.Enum.Enum it will be great to fix this (i will make ticket), but that is not show-stopper the problem that i'd imagined is how this new cool base library can be used with existing GHC version? of course, users will not use -fno-implicit-prelude, so their apps will expect that Enum class is defined in GHC.Enum and no other place. or it can just re-export class defined in some other module, say Core.Enum? even more problems with GHC.Base mpdule which should define both some hard-wired types and classes what means that we can't move out of this package some intermediate code (at least, without using recursive modules) about core library attempt#2 - the main problem in bootstrapping Haskell libs (for any compiler) is the expressiveness problem - for example, in order to define "instance Show Int", you need to use '/' operation which is defined in Integral class that in turn requires Show instance. GHC solves this problem by omitting use of classes in low-level modules and switching to the # operations. this perfectly works, but don't compatible with other compilers. what are other possible solutions? 1) lift all the # operations to the corresponding operations on boxed types and change low-level modules so they work with these un-classified but boxed operations, so the following: GHC.Base: divInt (I# a) (I# b) | gtInt# a b = mulInt# a b turns into: GHC.Base: gtInt (I# a) (I# b) = gtInt# a b mulInt (I# a) (I# b) = mulInt# a b Core.Base: divInt a b | gtInt a b = mulInt a b 2) another solution is to bring together definitions of Show/Enum/Num/Integral classes and their Int/Integer instances in one large module. after all, by the limiting it to only Int/Integer instances, its size should be reasonable. This will allow to use "natural" definitions (i.e. use '*' and '>' operators), although i fear that this can produce slower code. in particular, this can create circular dictionary dependencies (i.e. Show Int instance depends on Num Int and vice versa, which, according to my experience, prevents inlining of all methods (!) in both classes; although my experience was with parameterized instances (i.e. like Show [a] <=> Num [a]), so may be it will be not a problem here) it seems that integer literals in Hugs completely don't work before introduction of fromInteger operation. so it seems that the second way is the only really possible one :) it will be great to hear critics before i will invest time in implementing second plan. as a first result, i plan to refactor GHC.Base, Show, Enum, Num, Real modules into somewhat implementing the same facilities but compatible with Hugs. i think that this will make a solid foundation for future co-development of core lib -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 3

Controlling -fno-unit-at-a-time
by Ravi Nanavati 05 Oct '06

05 Oct '06

If I understand the way things work, GHC decides whether or not to emit the -fno-unit-at-a-time flag in -fvia-C compilation based on whether or not the gcc used when compiling GHC supported the flag or not. I'm running into trouble using precompiled GHC snapshots (that were compiled on machines whose gcc supports -fno-unit-at-a-time) on a machine whose gcc doesn't support it (a gcc 3.2 version, I believe). Is there any way force GHC to not emit the flag (short of recompiling from source)? Thanks, - Ravi

4 3

Bad interface file error with GHC RC2
by Krasimir Angelov 05 Oct '06

05 Oct '06

When I tried to build VSHaskell with the RC2 version of GHC I got the following error: src\lib\Registry.hsc:30:0: Bad interface file: C:\Program Files\Haskell\comlib-0.1\ghc-6.5.20061001/Com Dll.hi Something is amiss; requested module comlib-0.1:ComDll differs from nam e found in the interface file comlib:ComDll Am I doing something wrong or it is a bug? The COM library is built using Cabal. Cheers, Krasimir

4 6

testing 6.6-pre-2
by Serge D. Mechveliani 05 Oct '06

05 Oct '06

Concerning Ian's call for testing of ghc-6.6-pre-reslease-II: I have tested it on my projects DoCon-2.09 and Dumatel-1.06, it looks all right. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

GHC Under Wine
by Robert Marlow 05 Oct '06

05 Oct '06

Hi all I've succeeded in getting GHC to run under wine. I wrote a small guide on how to do it here: http://www.haskell.org/haskellwiki/GHCUnderWine So far it seems to work fairly well. I'll update the above page as I run into problems. (My interest in running GHC under wine is that I wanted to compile windows binaries but have no copy of MS Windows to do it under. Wine seems to be a viable solution for this). -- Robert Marlow <bobstopper(a)bobturf.org>

1 0

Re[2]: [Haskell-cafe] Re: [Haskell] Re: compiler-independent core libraries infrastructure
by Bulat Ziganshin 03 Oct '06

03 Oct '06

Hello John, (i'm moving thread to the ghc-users where this discussion continues in ghc-related aspects) Thursday, September 28, 2006, 3:30:09 AM, you wrote: >> So, just to confirm in my mind what you are proposing: >> >> Compiler/Version specific Core: >> >> Yhc.Core, Hugs.Core, GHC.Core .... >> >> With a different version for each compiler version. Tied intimately to >> the compiler. > A large issue with this, is that what needs to be tied intimately to the > complier is very different for different compilers. for instance > Data.Typeable and Data.Dynamic are fairly portableish haskell on ghc, > but are primitives provided by the compiler in jhc as a very simple > example. module JHC.Dynamic: .... module Data.Dynamic: #ifdef JHC import JHC.Dynamic #else -- make portable definitions #endif in general, compiler-specific code should go into *hc-core libraries while the "default implementations" into the common core package i have experience of multi-OS development. it is not the solution to write program tied to API of some OS or two and then make complex translation layer for all other OSes. instead, i select the common subset of APIs and try to use only it. if that's impossible, i make the translation layers that gives OS-neutral names to common functionality and masks OS-specific details > It leads to the current mess with the jhc libraries where it has bits > and pieces of base. I can't just use base as is, because it implements a > lot that jhc needs to implement natively or expects things that GHC.* > provides, but Jhc.* doesn't, or at least provides with a different > interface/semantics (and #ifdefs or tieing jhc's development with the > fptools repos are not acceptable solutions) However, a lot of stuff > depends on libraries provided by base, so I can't just ignore it. > so I end up syncing some code from base, modifying some, having a big > mess that is somewhat tricky to maintain. yes, jhc will get the largest benefit if this project succeeds - and even partial success will mean that jhc may get some better libraries than now. i don't imagine that i can develop some theoretical scheme in which each compiler will fit - vice versa, the plan is to look at all the compilers that are worth to support (now it's ghc, hugs, nhc, yhc and jhc) and realize what the common API for all them may be. if support for one more original compiler will be added in future to Core then API may need to change again. > In any case, haskell-prime will clean this up some by giving a more > complete compiler-provided set of libraries, and it looks like the > fptools repos are moving in the right direction with modularization. i don't understand how H' will help jhc - with any library report you will need to implement it yourself :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

Core package: attempt #1
by Bulat Ziganshin 03 Oct '06

03 Oct '06

Hello glasgow-haskell-users, i've uploaded my first attempt to define Core package as http://www.haskell.org/bz/core20061003.tar.gz you should use -fno-implicit-prelude to compile it with GHC. it also compiles with Hugs, although zeroInt and other constant definitions are definitely wrong :) it's impossible to define them before fromInteger arrived! as you can see, compiler-specific definitions are very short here, much of code is in compiler-independent modules. i hope that adding yhc and jhc support should be rather simple of course, it's just proof-of-concept implementation and it shows me that Igloo was not too wrong ;) - it's really hard to define anything in absence of type classes with at least Int/Integer instances of them so now i want to try another way, that is rather like GHC.* actual implementation - define rather large Core.Base module that will contain all the base classes together with Int/Integer implementations so that all the circular dependencies will be satisfied so while my original proposal was to use Core.* modules as "equalizer" which implements the same class-less interface for all compilers (Int, eqInt, addInt...) - now i will add to Core.* implementation of base classes which will make "equalizing" a much easier (look, for example, how i implemented now divInt in Core.Int) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

GHC on MacOS
by Simon Peyton-Jones 03 Oct '06

03 Oct '06

Folks Quite a few of you are using GHC on MacOS -- for example, there were lots of Macs at the GHC Hackathon earlier this month. However, we don't have access to a machine running MacOS, so it's pretty difficult for us to deal with bug reports. So this message is to ask: a) Can anyone give us remote access to a Mac? b) Does anyone feel able to help look after GHC's Mac port? Simon, Simon, and Ian

6 7