December 2002 - Hugs-Users

Hugs, Mac OS X 10.1.5, and pathnames
by Hamilton Richards 20 Feb '03

20 Feb '03

In OS X, pathnames have two distinct syntaxes. The GUI uses the pre-X syntax, in which a pathname begins with a volume name and the separator is `:', as in Macintosh HD:Users:ham:Documents:whatever.hs In the Darwin (i.e., unix) command-line "underworld", a pathname begins with /Volumes, spaces are escaped with `\', and the separator is `/', as in /Volumes/Macintosh\ HD/Users/ham/Documents/whatever.hs When you drag a file icon onto the command line, Terminal does the right thing-- it converts the pathname from the GUI syntax to the Darwin syntax, and utilities such as more work just as they should. Hugs, however, doesn't do so well. For example, Prelude> :l /Volumes/Macintosh\ HD/Users/ham/Documents/whatever.hs Reading file "/Volumes/Macintosh\": ERROR "/Volumes/Macintosh\" - Unable to open file "/Volumes/Macintosh\" Quoting the pathname changes the problem, but doesn't cure it: Prelude> :l "/Volumes/Macintosh\ HD/Users/ham/Documents/whatever.hs" ERROR - Missing `\' terminating string literal gap Apparently what's confusing Hugs is the `\', because removing it cures the problem: Prelude> :l "/Volumes/Macintosh HD/Users/ham/Documents/whatever.hs" Reading file "/Volumes/Macintosh HD/Users/ham/Documents/whatever.hs": Is this problem unavoidable, or is it just an oversight? Thanks, --Ham -- ------------------------------------------------------------------ Hamilton Richards Department of Computer Sciences Senior Lecturer Mail Code C0500 512-471-9525 The University of Texas at Austin Taylor Hall 5.138 Austin, Texas 78712-1188 ham(a)cs.utexas.edu hrichrds(a)swbell.net ------------------------------------------------------------------

4 4

call china 6.2¢ www.callez.com
by promotion＠callez.com 31 Dec '02

31 Dec '02

1 0

hugs ffi - question thats been bugging me for some time
by R. Legere 30 Dec '02

30 Dec '02

In docs/ffi-notes.txt, I find the following: ------------------------------------------------------------ o foreign export static is not implemented. You can code around this by writing: foreign import dynamic foo_dynamic :: Addr -> (A -> B -> C) foreign label foo_addr :: Addr foo = foo_dynamic foo_addr instead of: foreign import foo :: A -> B -> C ------------------------------------------------------------------------- Does anyone understand what this is saying? I can't grok it. The work around presented here seems to have nothing to do with foriegn export static. It looks like a workaround to not having foreign IMPORT static. (Which we of course dont need a workaround for :)). Is something extremely tricky going on or am i just dense? Anyway, just curious, I have not had any trouble working around by passing pointers to the C-side using foreign export dynamic. I have just wondered about this for a long long time :)

3 6

Hugs and TCP
by Maarten Koopmans 27 Dec '02

27 Dec '02

Hi, Congrats on the new hugs release! What has always been holding me back is the lack of tcp support in Hugs. Is that available in this release? --Maarten

3 2

Implementing type classes in Hugs - question
by Stephen Milborrow 27 Dec '02

27 Dec '02

I have a question about partial evaluation of type classes in Hugs. Consider the function inc99 :: Int->Int inc99 x = x + 99::Int which compiles to the SC inc99 _1 = Prelude.+ Prelude.v28 _1 (Prelude.fromInt Prelude.v28 99) where (the compiler generated dictionary) v28 basically implements "instance Num Int" and has the definition v28 = let _1 = Prelude.v24; -- (==) resolves to primEqInt _2 = Prelude.v40; -- (/=) _3 = Prelude.primPlusInt; -- (+) resolves to primPlusInt _4 = Prelude.primMinusInt; -- (-) resolves to primMinusInt _5 = Prelude.primMulInt; -- etc _6 = Prelude.primNegInt; _7 = Prelude.absReal Prelude.v28 Prelude.v26; _8 = Prelude.signumReal Prelude.v28 Prelude.v28 Prelude.v26; _9 = Prelude.primIntegerToInt; _10 = Prelude.Make.Num _1 _2 _3 _4 _5 _6 _7 _8 _9 Prelude.v1202; in _10; My question is: why doesn't Hugs partially evaluate the inc99 SC (before code generation) to yield the following definition? inc99 _1 = Prelude.primPlusInt _1 99 Doing so seems straightforward and would obviously avoid extra evil evals evolving evanescent heap expressions at run time. My main references are listed below and they imply that the above partial evaluation takes place (in Gofer, at least): John Peterson and Mark Jones: Implementing Type Classes, 1993 Mark Jones: Partial Evaluation for Dictionary-free Overloading, 1993 Is it simply that this kind of specialization was never implemented in Hugs? Or is the above transformation not as straightfoward as it seems?

2 1

ABD G��menlik/Green Card 2003 y�l� kay�tlar�m�z ba�lam��t�r...
by G��MENL�K/ABD 27 Dec '02

27 Dec '02

1 0

Event does not match Event -- Solved
by b.i.mills＠massey.ac.nz 12 Dec '02

12 Dec '02

Thanks for the advice, I have it running now. Tom was right about the structure of the imports, and Sigbjorn's advice helped me sort out the right configuration. Regards, Bruce.

1 0

Event does not match Event
by b.i.mills＠massey.ac.nz 12 Dec '02

12 Dec '02

I am trying to write an event driven application in Haskell, to run under Hugs. The following is an extract ... -- just define any sort of handling process (Key a b) = putChar 'a' process (Button a b c) = putChar 'a' process (MouseMove a) = putChar 'a' process (Resize) = putChar 'a' Now I check the type of the following ... process :: Event -> IO () getEvent :: Window -> IO Event openWindow "a" (100,100) :: IO Window So I try ... (openWindow "a" (100,100)) >>= getEvent >>= process And get the following error ... ERROR - Type error in application *** Expression : openWindow "a" (100,100) >>= getEvent >>= process *** Term : openWindow "a" (100,100) >>= getEvent *** Type : IO Event *** Does not match : IO Event Say what? I suspect, perhaps a compatability problem, since I detect the presence of two different versions of getEvent, one of type Window -> IO Event, and the other of type Events -> IO Event. But I can't figure out the right configuration, and that error message makes no sense to me. I even went and got a cup of coffee ... but I still get the same error message. <sigh> Regards, Bruce (IIMS/CS Massey at Albany).

3 2

A Faster whatIs
by Stephen Milborrow 09 Dec '02

09 Dec '02

Hello everyone: I made some changes to the Hugs sources which give small runtime speed gains. The results are in the table below. The gains are minor, but I thought some people in the group might be interested. WHATIS WHATIS1 FHEAP Speed Increase (percent) gamteb 8 9 5 parser 6 8 gcfail prolog 9 9 2 queens 10 13 4 Extra BSS memory (kBytes) 24 24 0 Nbr source lines changed 50 144 41 ---Notes On The Table The table headings WHATIS, WHATIS1, and FHEAP refer to three different sets of changes. WHATIS and WHATIS1 are described below. FHEAP was an experiment that simply used a fixed size heap (an array instead of a malloc) and is impractical because it rules out use of the Hugs -h flag. The (motley) collection of test programs are from nofib. I timed runhugs for each program without command line flags, except that for queens I used -h1000000. Different programs would probably give different results: the usual caveats apply. These programs were just the nofib ones I had at hand. I compiled with MSC 5.0 Service Pack 3 using modified Nov 2002 Hugs sources. I ran the timing tests on a Windows 98 machine. ---Strategy I wanted to see what speed gains could be achieved by taking a worm's eye view of the code, with no changes to fundamental algorithms. I also wanted to make changes that would be limited to just a few places in the code -- a minimal force approach. To start off, I ran the MSC profiler. This confirmed that whatIs() is a candidate for optimization, as already noted in Mark's Gopher implementation document and in comments in storage.c. But the profiler showed a few other hotspots too. (An interesting thing to do is sort the profiler results on execution line-count, which immediately tells you which are the most executed lines in the program.) ---WHATIS Change To reduce the time spent in whatIs, I created a byte array whatCode of whatIs codes. I then created a whatIs macro which replaces the whatIs function: #define whatIs(c) (isPair(c)? \ (isTag(fst(c)) ? fst(c) : AP ) : \ whatCode[c]) Negative indexing into whatCode is prevented by the isPair. To keep the size of whatCode reasonable, I had to reduce the range of unboxed ints -- the bigger the range, the bigger the whatCode array. I settled on a range of 2048 i.e. ints between -1023 and 1024 are unboxed, all others are boxed. The extra boxing will actually slow down execution of certain Haskell programs, but as far as I can tell the majority of real Hugs programs would be unaffected. Increasing this range to, say, 10 000 would increase memory usage by 10 000 bytes -- nothing really when you consider that the memory footprint of winhugs is about 10 MBytes. This change yields the speed improvements under the WHATIS column in the table. ---WHATIS1 Change IsTag is defined as #define isTag(c) (TAGMIN<=(c) && (c)<SPECMIN) I reduced the cost of IsTag slightly by changing defines in storage.h so that only box-cell-tags are in the range 1 to 0x7f. (I shifted special cell values down to start at 0x80). I then defined variants for IsTag and friends: #define isTag1(c) (((c) & TAG_MASK) == 0) #define whatIs1(c) (isPair(c)? \ (isTag1(fst(c))? fst(c) : AP ) : \ whatCode[c]) #define isAp1(c) (isPair(c) && !isTag1(fst(c))) whatIs1 is a faster version of whatIs, with the "bug" that it will return the wrong value if fst(c) is NIL. When used in several places as a replacement for whatIs, it gains us a few speed percentage points as shown in the WHATIS1 column above. WHATIS1 sits on top of WHATIS so the gains attributable to WHATIS1 alone are the differences between the percentages in the two columns. ---Another Candidate Another candidate for this kind of optimization is the line in eval(): if (!isCfun(n) && (ar=name(n).arity)<=(sp-base)) {... This is one of the most executed lines in the entire program. If the stored arity of Cfun's was offset by a largish number, say 10000, then the above test against isCfun wouldn't be needed. This change would introduce inefficiencies elsewhere (we would have to un-offset the stored arity before using it elsewhere) but the net effect would probably be a speed gain. I shied away from this change because it would require ubiquitous (though easy) code changes. ---Final Comments Optimizing code written by Mark Jones is a challenge. It becomes a little less daunting if we change the rules by allowing ourselves to waste some memory in the pursuit of speed, and to introduce some ugliness into the code. Even so, the speed improvements I got were small. If anyone is interested, I would be happy to send the sources. They are modified Nov 2002 sources with all the changes demarcated by #define's. Six files changed. I would be interested to know what results these changes give on other machines. --- Stephen Milborrow

3 6

RE: A Faster whatIs
by Simon Marlow 02 Dec '02

02 Dec '02

> > Hello everyone: I made some changes to the Hugs sources which give > > small runtime speed gains. > > I think you're the first person to look at optimizing Hugs in quite a > while. Great stuff! > > I toyed with changing whatIs a few years ago. Instead of your > table-based approach, I was thinking of using a bitwise encoding. My > idea was to use one bit to select int/not int and that everything else > would be interpreted as a triple of the form: > > (WhatisTag,ModuleId,Index) > > Where, for example, the WhatisTag is 5 bits, the ModuleId is 10 bits > and the Index is 16 bits (the numbers will probably need tweaked > somewhat). So, each module would have its own set of tables for > storing names, types, etc. In the Hugs-alike compiler I was working on a few years ago (never got around to finishing it) I used the following representation: a 'cell' is either boxed or unboxed, according to bit zero (0 == a heap reference), and an unboxed word consists of 7 bits of "tag" (bits 1-8), and 24 bits of data. Applications and list cells are just pairs (like Hugs), but everything else has a "box" tag in the first word. The heap stored variable-width objects unlike Hugs which only has pairs, but I don't think that's relevant. I think this is pretty similar to what you suggested above, Alastair. The appropriate macros are: #define IsRef(c) (((c) & 1) == 0) #define IsBox(c) (((c) & 1) && TagOf(c) >= BoxedThings) #define IsApp(c) (IsRef(c) && !IsBox(Fst(c))) #define MkValue(c) ((uint)(c) << 8) #define ValueOf(c) ((uint)(c) >> 8) #define TagOf(c) ((c) & 0xff) #define whatIs(c) (IsRef(c) ? (IsBox(Fst(c)) ? Fst(c) : Ap) : TagOf(c)) I remember testing various representations at the time, and this one turned out to be pretty good. Cheers, Simon

1 0