- Glasgow-haskell-users

size of interpreted code
by S.D.Mechveliani 06 Jun '01

06 Jun '01

Dear ghc-5.00.1, I wonder: is the interpreted code generally expected to be larger than compiled to .o ? I have certain Foo project which under ghc-4.08 had: compiled Foo + compiled demo examples make Foo-Demo.a of 10Mb, and this all load and run on 32Mb RAM computer inside RAM (probably, 15Mb will remain for heap). With ghc-5.00.1, the compiled Foo.a, Foo.o are each of 7Mb, ghci -package foo ... Prelude> :l T_ loads the interpreted demo examples (importing Foo.o), and this needs more than 45Mb heap. Recalling that ghci does not like strict polymorphic data fields, I add that the compiled part has the strict polymorphic fields like D !a !(a -> a), but the interpreted demo programs do not have strict fields. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: ghc5 --make question
by Simon Marlow 06 Jun '01

06 Jun '01

> Hi, I'm trying to generate automatic makefiles for my project > using --make. > Unluckily it seems ghc prefers .hs over .hi. The programs > require a fair > amount of separate libraries (Tcl/Tk, a Concurrent Haskell Debugger, a > network wrapper,...) which I currently don't have to care much about: > I just have to provide the corresponding top-level .hi and > some .a-files to > the ghc command line for compiling. > > Is there any way to use ghc --make without having to provide > access to all > of the *source* files and make it use the pre-compiled stuff? Yup, you have to put your pre-compiled stuff in a package. It's a bug in 5.00.1 that it requires the source file; I've fixed it properly in the HEAD as part of the library story, but it almost certainly won't be backported. Cheers, Simon

1 0

RE: [GHC5] Creating Socket.PortNumber from Int?
by Simon Marlow 06 Jun '01

06 Jun '01

> Until 5.00 I could use mkPortNumber to get what I want, i.e. > PortNumber (mkPortNumber port) > Now in 5.01, this function now longer exists. > (PortNumber 5) works, but (PortNumber (5::Int)) does not, so I > have to use "fromIntegral" to get it to work again: > PortNumber (fromIntegral (5::Int)) > > I suppose I'm missing something essential here, as there must be a > better way of doing it when passing a variable of type Int. Think of it this way: mkPortNumber has been renamed to fromIntegral, and now supports making port numbers from any integral type, not just Int. I didin't see the need for a special purpose convesion from Int, when fromIntegral does the job in a much more general way. Besides, using fromIntegral as a general-purpose integral converter is becoming standard practice now that we can optimise it well. Cheers, Simon

2 1

ghc5 --make question
by Volker Stolz 06 Jun '01

06 Jun '01

Hi, I'm trying to generate automatic makefiles for my project using --make. Unluckily it seems ghc prefers .hs over .hi. The programs require a fair amount of separate libraries (Tcl/Tk, a Concurrent Haskell Debugger, a network wrapper,...) which I currently don't have to care much about: I just have to provide the corresponding top-level .hi and some .a-files to the ghc command line for compiling. Is there any way to use ghc --make without having to provide access to all of the *source* files and make it use the pre-compiled stuff? -- Abstrakte Syntaxträume. Volker Stolz * stolz(a)i2.informatik.rwth-aachen.de * PGP + S/MIME

1 0

[GHC5] Creating Socket.PortNumber from Int?
by Volker Stolz 06 Jun '01

06 Jun '01

Until 5.00 I could use mkPortNumber to get what I want, i.e. PortNumber (mkPortNumber port) Now in 5.01, this function now longer exists. (PortNumber 5) works, but (PortNumber (5::Int)) does not, so I have to use "fromIntegral" to get it to work again: PortNumber (fromIntegral (5::Int)) I suppose I'm missing something essential here, as there must be a better way of doing it when passing a variable of type Int. -- Abstrakte Syntaxträume. Volker Stolz * stolz(a)i2.informatik.rwth-aachen.de * PGP + S/MIME

1 0

Re: GHC core representation
by Alastair David Reid 05 Jun '01

05 Jun '01

[This is in reply to Andrew Tolmach's mail to the Haskell list. He asked that replies should be sent to ghc-users.] > Many months after the topic was first raised, there is finally a draft > document describing a formal external syntax for GHC's "Core" > intermediate language. Wow! This is very cool - it answers so many questions that I previously had to examine the source code to figure out! Two meta-comments before I go into detailed comments. 1) GHC documentation tends to have a very short half-life. What can be done to minimize this problem? For example can the tables of primops in section 4 be automatically generated? 2) I haven't seriously hacked on GHC or the the GHC frontend for several years so some of the following comments will be a little off. I'm hoping that people who are more up to date will correct me and that their corrections will be useful to anyone like me who used to know GHC but have lost track of the details. OK, onto the detailed comments. 1) GHC identifiers have SrcLocs (filename/linenumber) attached to them. It might be useful to be able to pass those into your parser. (But what are the SrcLoc's used for in Core code? Would they be useful?) 2) The names you use for operations all use the somewhat unreadable Z encoding. I think you should Z-decode these names because: 1) They're a lot more readable. e.g., decode "ZLZmZgZR" = "(->)" 2) It's possible that GHC will get confused if you fail to Z-encode a name. For example, it isn't possible to have the name "Z" in Core because GHC encodes the Haskell identifier "Z" as "ZZ". From memory, the Z encoding is something like this: ZL -> ( ZR -> ) Zm -> - Zg -> > Zl -> < Ze -> = Zc -> : Zp -> . Zxxx -> chr(xxx) where xxx is a sequence of digits 3) The restriction that Main.main have type IO a is unfortunate and, I think, unnecessary. It shouldn't be that hard to change it so that its type is more like: State# RealWorld -> (# State# RealWorld, Void# #) 4) While explaining namespaces, it'd be convenient to point out that you put a % in front of all keywords. Hmmm, I guess this is one reason to use Z-encoded names: % is a legal Haskell identifier. 5) The @a in datatype declarations threw me for a while. Later I saw you using it like BigLambda in an explicitly typed lambda calculus and understood what you were doing. It'd be worth making the connection explicit. 6) An alternative way of defining data constructors would be like this: %data BinTree :: * -> * = { Fork :: %forall a . BinTree a -> BinTree a -> BinTree a; Leaf :: %forall a . a -> BinTree a } That is, specify the actual type of data constructors instead of using Haskell datatype declaration syntax. This makes the language a little easier to specify. Notice that this syntax is a little more liberal than standard Haskell syntax because you could write types like: %data Expr :: * -> * = { Int :: Int -> Expr Int; App :: %forall a, b . Expr (a -> b) -> Expr a -> Expr b; Lam :: %forall a, b . Var a -> Expr b -> Expr (a -> b) } which cannot be expressed using normal Haskell syntax because the result types of each constructor are different. I saw Lennart mention this idea in a talk about 8 years ago and I've always wanted to play with it. :-) On the other hand, you might avoid this generalisation in case GHC does something weird with it. 7) In section 3.6, you say: "Value applications may be of user-defined functions, data constructors or primitives. Application of the latter two sorts need _not_ be saturated." I think you mean "none of these applications need to be saturated although both previously published descriptions of Core required that the latter two be saturated." 8) You say that the list of case alternatives "need not be exhaustive, even if no default is given; it is a disastrous run-time error if a needed case arm is missing." 1) Just how disastrous? Is an exception raised or does the RTS crash? 2) I feel a little uneasy with this design decision. 9) You don't mention the _scc_ operation used for profiling. 10) There's a move on to define %ccall in a more generic way that would apply to calling Java functions, .net functions, etc. This is bound to result in a change of the "ccall" name. It'd be worth adding a Working note to that effect. 11) The discussion of the terms "unboxed", "heap allocated" and "unlifted" (page 9) doesn't seem quite right. I believe it is: Lifted types must be heap allocated. Unlifted types may be heap allocated (e.g., Array#s) or unboxed (not heap allocated) (e.g., Int#). 12) The discussion of operations on MVar# (page 10) says that they take an initial type argument of the form (State# t) for some thread "t". Is this true? Does "t" not have to be RealWorld#? What does it mean if it is not RealWorld#? 13) Are the CCallable and CReturnable classes still there? Blech! [I'm the one who implemented them - I'd hoped they'd gone by now.] 14) If strings are represented by the "address of a C-format string" (section 4.2), how do we represent strings with embedded \0 characters in them? 15) dataToTag#, tagToEnum# and getTag# (section 4.4.1) might be used to implement the to/fromEnum operations but they may also be remnants of GHCi version 0.0 - a metacircular interpreter that was in GHC version 0.18 (or thereabouts). If the latter, someone ought to give them a decent burial. 16) You document unsafeCoerce# but not reallyUnsafePtrEq# :: a -> a -> Bool did someone finally kill that? 17) decodeDouble# and decodeFloat# are used to extract the exponent and mantissa of a floating point number. Ignoring unboxity, it returns an Int (the exponent) and an Integer (the mantissa). Representing that as unboxed types, you get (# Int#, Int#, ByteArray# #) 18) Section 4.4.8 asks what the relationships are between quotient, remainder, div and mod. This ought to be the same as that specified in the Haskell report for their boxed equivalents. 19) Your question about what indexArray# does and what alignment restrictions apply reminds me of a subtlety: When indexing into a ByteArr# or a Addr#, is the index scaled by the size of the object being read/written (as in C) or not? I am pretty sure that the index on an Addr# is not scaled (and the value of the (Addr# + Int#) combination is subject to exactly the same alignment restrictions as imposed by the hardware architecture. I don't recall the story for ByteArr# but a ByteArr# object is always aligned to the nearest 4 (maybe 8) byte boundary. 20) Section 4.4.15 says that takeMVar# and putMVar# "die" if the MVar is empty (respectively, full). 1) What does "die" mean? More generally, how is failure implemented in the primops? Do they raise exceptions? Do they return error codes? Do they call exit? Do they crash the RTS? 2) Are you sure these ops "die"? Their unboxed Haskell brethren will block the thread under the same circumstances. 21) You repeatedly mention the sequential implementation of the RTS. Last time I looked, it wasn't possible to build the RTS with concurrency turned off. If one were to build the GHC RTS with concurrency turned off, I think the concurrency primitives should not be available rather than providing versions that always/mostly fail. Or maybe one could implement non-preemptive "concurrency" in much the same way as we did in Hugs? (Not sure I recommend this route - the interactions between threads and exception handlers in Hugs are somewhat tricky.) -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

1 0

Re: Problems finding modules with GHC 5
by Marcin 'Qrczak' Kowalczyk 05 Jun '01

05 Jun '01

Mon, 04 Jun 2001 18:59:57 -0400, Leon Smith <lps(a)po.cwru.edu> pisze: > Loading package std ... linking ... done. > ghc-5.00.1: can't find module `MArray' ghci Main.hs -package lang -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Problems finding modules with GHC 5
by Leon Smith 04 Jun '01

04 Jun '01

I'm having problems running programs that use modules found in the hslibs libraries. I've tried these with GHC 5.00.1 on both a x86 Linux box on which I compiled GHC from source, and a Sparc box where I installed the precompiled binaries. If I simply try to load my program (which uses MArray), I get: -------- $ ghci Main.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.00.1, For Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package std ... linking ... done. ghc-5.00.1: can't find module `MArray' --------- If I try using the -i option, I get --------- $ ghci -i/usr/local/lib/ghc-5.00.1/imports/lang/ Main.hs ... Loading package std ... linking ... done. ghc-5.00.1: panic! (the `impossible' happened, GHC version 5.00.1): does not exist Action: withFileStatus Reason: No such file or directory Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. ----------- $ ghci -i/usr/local/build/ghc-5.00.1/hslibs/lang/ Main.hs ... Loading package std ... linking ... done. ghc-5.00.1: can't find module `PrelPrim' Finally, if I then try adding the prelude to the path, I get the same panic. If I try to compile my project with GHC, I get link errors. best, leon If I try

1 0

RE: Socket Behaviour
by Steinitz, Dominic J 04 Jun '01

04 Jun '01

Simon, Thanks very much for this. Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

RE: Socket Behaviour
by Simon Marlow 04 Jun '01

04 Jun '01

> Can anyone tell me why the following code doesn't work as > expected? Both the server and client hang. If I run > > server 20000 & > and > client <hostname> 20000 > > the server logfile produces > > [dom@lhrtba8fd85 twotest]$ more log.txt > Thu May 31 14:35:39 BST 2001 > Starting logging > Thu May 31 14:36:08 BST 2001 > Hello world 48 65 6c 6c 6f 20 77 6f 72 6c 64 It only produces this logfile if you kill the client with ^C before killing the server. What's happening is this: the client writes the string "Hello World" to the socket. The server picks it up, but it is waiting for an end of file before returning the string, so it hangs. When you kill the client, the server finally gets EOF and returns Partial "Hello World" from getBuffer. At this point, the server gets a SIGPIPE because it attempts to write to a socket whose other end has disappeared. The default behaviour when receiving a SIGPIPE is to terminate silently (this behaviour has caught me out a couple of times - the documentation for Socket mentions it), so this is what the server does, leaving the logfile that you see above. If you arrange for the server to ignore SIGPIPE, by adding the line installHandler sIGPIPE Ignore Nothing and importing Posix, then you'll see the broken pipe error from the server. Cheers, Simon

1 0