From ger@Informatik.Uni-Bremen.DE Mon Dec 4 16:09:36 2000
Date: Mon, 04 Dec 2000 17:09:36 +0100
From: George Russell ger@Informatik.Uni-Bremen.DE
Subject: The Set type
A minor quibble I know, but every time I use sets I want to add/subtract single elements
to/from them. There is no function provided for doing this, so instead you have to do
union/delete with a singleton set constructed from the element. I appreciate the zeal
of the designer of this module to construct the smallest possible interface (I wish the
same person had designed the standard Prelude) but I think this zeal is overdone.
You do often need to operate with single elements. After all, if you wanted real
hair-shirt minimalism you should get rid of "elementOf" (replace it by
\el set -> isEmptySet (intersect set (singletonSet el)), but no-one would seriously
suggest that - I hope.
From ger@Informatik.Uni-Bremen.DE Mon Dec 4 16:17:42 2000
Date: Mon, 04 Dec 2000 17:17:42 +0100
From: George Russell ger@Informatik.Uni-Bremen.DE
Subject: Or-patterns
Why not steal a good idea from Standard ML/New Jersey now and again? This has
"Or-patterns" which allow you to match against a disjunction of patterns,
EG
fun sleepIn (Date.Sat | Date.Sun) = true
| sleepIn _ = false
Where you have variables in the patterns, you bind only the variables which appear
in all the patterns, and you unify the types accordingly.
Of course you can do without this feature, but I feel it shouldn't be too hard
to implement and for me at least it would be occasionally useful.
From simonpj@microsoft.com Wed Dec 6 15:15:29 2000
Date: Wed, 6 Dec 2000 07:15:29 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Or-patterns
Sensible suggestion
No technical problem, just one more thing to do.
If anyone feels inclined to implement it I'll gladly incorporate
the fruits of their labours in the GHC code base.
Simon
| -----Original Message-----
| From: George Russell [mailto:ger@Informatik.Uni-Bremen.DE]
| Sent: 04 December 2000 16:18
| To: glasgow-haskell-users@haskell.org
| Subject: Or-patterns
|
|
| Why not steal a good idea from Standard ML/New Jersey now and
| again? This has
| "Or-patterns" which allow you to match against a disjunction
| of patterns,
| EG
|
| fun sleepIn (Date.Sat | Date.Sun) = true
| | sleepIn _ = false
|
| Where you have variables in the patterns, you bind only the
| variables which appear
| in all the patterns, and you unify the types accordingly.
|
| Of course you can do without this feature, but I feel it
| shouldn't be too hard
| to implement and for me at least it would be occasionally useful.
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From qrczak@knm.org.pl Wed Dec 6 21:08:06 2000
Date: 6 Dec 2000 21:08:06 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Or-patterns
Mon, 04 Dec 2000 17:17:42 +0100, George Russell <ger@Informatik.Uni-Bremen.DE> pisze:
> Where you have variables in the patterns, you bind only the
> variables which appear in all the patterns, and you unify the
> types accordingly.
Or bind them all (otherwise there would be _ written) and get bottom
in case the matching subpattern did not bind the given variable.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From christian@lescher.de Thu Dec 7 07:35:12 2000
Date: Thu, 07 Dec 2000 08:35:12 +0100
From: Christian Lescher christian@lescher.de
Subject: New InstallShield: no more DLLs
Hi Reuben,
> Besides, I've got some (not so fortunate) news: even after updating binutils and the
> whole cygwin to the latest version, the problem with *statically* linked and
> afterwards stripped DLLs build with GHC remains - the unstripped version works well,
> but the stripped one crashes in some constellations. I will try to make this error
> reproducable and let you know about it. Something is still wrong here - probably with
> cygwin. Maybe this has also got something to do with the dyn. linking problem?
There are some strange things happening that I'm still astonished about. I decided just
to write them down again - perhaps it may help to discover the error of the linking
problem.
As you know, I made some trials with a statically linked DLL build with GHC4.08.1 and the
latest cygwin.
a) When leaving debug information as it is, everything works fine - in all environments I
tested it on (WinNT, Win95; VBA, Delphi, VB - I had no possibility to test it on Win2K
yet).
b) When STRIP-ping away the debug information, the DLL on all PCs I tried it on works
fine with VB and Delphi - but when using it in VBA, it on some PCs crashes when the DLL
is loaded (the loading happens automatically when calling a Haskell function for the
first time) - this also looks like a problem during DLL initialization, it seems as if
DllMain is not even entered.
Did you already try out a statically linked, stripped DLL on Win2K? Do you get the same
error? (If the origin of the error is the same DLL initialization problem as in the
linking problem with EXEs, it may be easier to handle in a hell of a single DLL ...)
Some more strange things occured with the small program we had with catchAllIO / the "hi"
output:
I compiled it in both ways with and without the "-static" option and sent the EXE
binaries to Arjan van Ijzendoorn (who reported the error).
a) When running the EXEs on my PC (Win95), both the statically and the dynamically linked
EXE work well (output: "hi").
b) The same EXE on A.v.I.'s PC with Win2K produced the "famous" application error.
Do you have some idea what's wrong here?
Cheers, Christian
From stolz@I2.Informatik.RWTH-Aachen.DE Thu Dec 7 10:56:09 2000
Date: Thu, 7 Dec 2000 11:56:09 +0100
From: Volker Stolz stolz@I2.Informatik.RWTH-Aachen.DE
Subject: Anyone using SocketPrim.getSocketName?
Is anyone using SocketPrimt.getSocketName?
I try to get the IP of a listening socket (on my side), but
I always get 0. It could be either my fault, SocketPrims fault
(the source is prefilling the buffer with 0!), or the
conversion-functions fault:
> sAddr <- SocketPrim.getSocketName (s#socket)
> local <- case sAddr of
> (SocketPrim.SockAddrInet port host) -> do
> return (show (wordToWord32 host))
> _ -> net#getHostName -- XXX output a warning
> print local
"host" is of type Word, so I need a way of getting it into a string.
host should be 4x8 bit and thus Word32 is the right thing to use?
--
\usepackage[latin1]{inputenc}!
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From stolz@I2.Informatik.RWTH-Aachen.DE Thu Dec 7 12:19:53 2000
Date: Thu, 7 Dec 2000 13:19:53 +0100
From: Volker Stolz stolz@I2.Informatik.RWTH-Aachen.DE
Subject: Anyone using SocketPrim.getSocketName?
Am 07. Dec 2000 um 11:56 MET schrieb Volker Stolz:
> Is anyone using SocketPrimt.getSocketName?
> I try to get the IP of a listening socket (on my side), but
> I always get 0. It could be either my fault, SocketPrims fault
> (the source is prefilling the buffer with 0!), or the
> conversion-functions fault:
Okay, I can construct cases where I get what I want. It seems to
depend on the OS; the SocketPrim implementation works.
--
\usepackage[latin1]{inputenc}!
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From simonpj@microsoft.com Thu Dec 7 17:17:44 2000
Date: Thu, 7 Dec 2000 09:17:44 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Fun with GHC's optimiser
Manuel
OK, I've improved the eta expander so it does a better
job of the code you found.
Try now. On the HEAD. Which should compile OK now, incidentally.
How's your parallel Haskell stuff coming?
Simon
| -----Original Message-----
| From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au]
| Sent: 02 November 2000 13:54
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: RE: Fun with GHC's optimiser
|
|
| Simon Peyton-Jones <simonpj@microsoft.com> wrote,
|
| > I can never resist messages like these, even when I'm meant
| > to be doing other things.
|
| That's good to know ;-)
|
| > It's very helpful when people offer
| > fairly precise performance-bug reports. Thanks!
|
| Thanks for the prompt reply! To SimonM, too.
|
| > | I am wondering whether there is a particular reason why the
| > | optimiser doesn't pull the
| > |
| > | (1) a = NO_CCS PArray! [wild1 mba#];
| >
| > This one is a definite bug. It turns out that the head of the
| > before-ghci-branch doesn't have this bug, so I'm disinclined
| > to investigate it further.
|
| No problem, I can always build a new ghc from CVS.
|
| > | (2) case w of wild3 {
| > | I# e# ->
| > |
| > | As for (2), the loop would be nice and straight if that
| > | unboxing where outside of the loop - as it is, we break the
| > | pipeline once per iteration it seems
| >
| > This one is a bit harder. Basically we want to make a wrapper
| > for a recursive function if it's sure to evaluate its free
| variables.
| >
| > In fact the 'liberate-case' pass (which isn't switched on in 4.08)
| > is meant to do just this. It's in simplCore/LiberateCase.lhs,
| > and it's not very complicated. I've just tried it and it
| doesn't seem
| > to have the desired effect, but I'm sure that's for a boring reason.
| > If anyone would like to fix it, go ahead!
|
| Ok - something for a rainy weekend, I guess...
|
| > Incidentally, you'll find that -ddump-simpl gives you a dump that
| > is pretty close to STG and usually much more readable. Most
| > performance bugs show up there. -dverbose-simpl gives you more
| > clues about what is happening where.
|
| Good to know. I just wasn't sure whether I wouldn't miss
| out on some optimisations.
|
| > | Also if somebody is looking at the attached source, I was
| > | wondering why, when I use the commented out code in
| > | `newPArray', I get a lot worse code (the STG code is in a
| > | comment at the end of the file). In particular, the lambda
| > | abstraction is not inlined, whereas `fill' gets inlined into
| > | the code of which the dump is above. Is it because the
| > | compiler has a lot harder time with explicit recursion than
| > | with fold/build? If so, the right RULES magic should allow
| > | me to do the same for my own recursively defined
| > | combinators, shouldn't it?
| >
| > I couldn't figure out exactly what you meant. The only commented
| > out code is STG code. Maybe send a module with the actual
| > source you are bothered about.
|
| Appended the version of the module where the code is
| activated (it was commented out with --) - you'll find the
| problematic code by searching for (**) in the code. It
| generates
|
| $w$snewPArray
| = \ ww :: Int# w :: Int ->
| case newIntArray# @ RealWorld ww realWorld#
| of wild { (# s2#, mba# #) ->
| case $wsimpleGen
| ww
| (\ i :: Int ->
| case i of wild1 { I# i# ->
| case w of wild2 { I# e# ->
| __coerce (ST RealWorld ())
| (\ s# :: (State# RealWorld) ->
| case writeIntArray# @ RealWorld mba# i# e# s#
| of s2#1 { __DEFAULT ->
| (# s2#1, () #)
| })
| }
| })
| s2#
| of wild1 { (# new_s, r #) ->
| let {
| a :: Int
| a = $wI# ww
| } in (# a, (__coerce ByteArray# mba#) #)
| }
| }
|
| One thing that is not nice is in the lambda abstraction
| based to $wsimpleGen. There is one lambda, then two
| unboxing operations and another lambda for the state
| variables s#. These two nested lambda's become in STG
|
| stg_c1Op =
| NO_CCS[] \r[i]
| case i of wild1 {
| I# i# ->
| case w of wild2 {
| I# e# ->
| let {
| stg_c1Sv =
| NO_CCS[] \r[s#]
| case
| writeIntArray# [mba# i# e# s#] of s2#1 {
| DEFAULT ->
| (#,#) [s2#1 ()]
| };
| } in stg_c1Sv;
| };
| };
|
| So, stg_c1Sv is allocated and immediately entered. I would
| have hoped that the two lambda abstractions are merged into
| something like this:
|
| (\ i :: Int s# :: (State# RealWorld) ->
| case i of wild1 { I# i# ->
| case w of wild2 { I# e# ->
| case writeIntArray# @ RealWorld mba# i# e# s#
| of s2#1 { __DEFAULT -> (# s2#1, () #)
| })
| }
| })
|
| Maybe it is the __coerce, which prevents this from
| happening?
|
| Also, I am wondering why in the case of the
|
| foldr (fill mpa e) (return $ unsafeFreezeMPArray mpa) [0..n-1])
|
| the function `fill' gets inlined into the foldr loop, but in
| the above, the lambda abstraction gets not inlined into
| $wsimpleGen. Maybe it is because $wsimpleGen itself gets
| not inlined...
|
| Cheers,
| Manuel
|
From dirk@TechFak.Uni-Bielefeld.DE Thu Dec 7 18:39:35 2000
Date: Thu, 07 Dec 2000 19:39:35 +0100 (MET)
From: Dirk Evers dirk@TechFak.Uni-Bielefeld.DE
Subject: Beginners profiling question
This message is in MIME format
--_=XFMail.1.3.p0.Solaris:001207193935:15881=_
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
So I have tried profiling the first time...
using ghc-4.08.1 with options -prof -auto-all
runtime option -px
ghcprof and daVinci work like a charm
what I see is
main uses 99.90 % time and space
sat for practical purposes is the only function called from main and
uses ca. 12 % time and space
what am I doing wrong...
Prelude not compiled for profiling?
Thanks in advance
Dirk
---
+---------------------------------------------------------------------+
| Dirk Evers Office: M3-120 |
| Technische Fakultaet / AG PI Tel: +49 521 106-2905 |
| Universitaet Bielefeld FAX: +49 521 106-6411 |
| D-33594 Bielefeld e-mail: dirk@TechFak.Uni-Bielefeld.DE |
| Germany URL: http://www.TechFak.Uni-Bielefeld.DE/~dirk/ |
|---------------------------------------------------------------------|
| Die Succulenten / a cappella singing / http://www.succulenten.de |
+---------------------------------------------------------------------+
--_=XFMail.1.3.p0.Solaris:001207193935:15881=_
Content-Disposition: attachment; filename="satdanglefold.prof"
Content-Transfer-Encoding: base64
Content-Description: satdanglefold.prof
Content-Type: application/octet-stream;
name=satdanglefold.prof; SizeOnDisk=10749
IlRodSBEZWMgIDcgMTk6MDkgMjAwMCIKIjIwIG1zIgoxIDE5NiAiQ0FGIiAiQ2hhciIKMSAxOTUg
IkNBRiIgIk51bWVyaWMiCjEgMTk0ICJ0c3RhY2tpX2RnIiAiRW5lcmd5IgoxIDE5MyAidHN0YWNr
aF9kZyIgIkVuZXJneSIKMSAxOTIgInRvcF9zdGFjayIgIkVuZXJneSIKMSAxOTEgInRlbXAiICJF
bmVyZ3kiCjEgMTkwICJ0IiAiRW5lcmd5IgoxIDE4OSAic3RhY2tfZGciICJFbmVyZ3kiCjEgMTg4
ICJzc19lbmVyZ3kiICJFbmVyZ3kiCjEgMTg3ICJzcl9lbmVyZ3kiICJFbmVyZ3kiCjEgMTg2ICJy
IiAiRW5lcmd5IgoxIDE4NSAibG9nX2ludGVycCIgIkVuZXJneSIKMSAxODQgImtlbHZpbiIgIkVu
ZXJneSIKMSAxODMgImlucHJlZ2lvbiIgIkVuZXJneSIKMSAxODIgImlsX3N0YWNrIiAiRW5lcmd5
IgoxIDE4MSAiaWxfZW50IiAiRW5lcmd5IgoxIDE4MCAiaWxfZW5lcmd5IiAiRW5lcmd5IgoxIDE3
OSAiaWxfYXN5bSIgIkVuZXJneSIKMSAxNzggImhsX3RldHJhIiAiRW5lcmd5IgoxIDE3NyAiaGxf
c3RhY2siICJFbmVyZ3kiCjEgMTc2ICJobF9lbnQiICJFbmVyZ3kiCjEgMTc1ICJobF9lbmVyZ3ki
ICJFbmVyZ3kiCjEgMTc0ICJlIiAiRW5lcmd5IgoxIDE3MyAiZHJfZW5lcmd5IiAiRW5lcmd5Igox
IDE3MiAiZHJfZGFuZ2xlX2RnIiAiRW5lcmd5IgoxIDE3MSAiZHJpX2VuZXJneSIgIkVuZXJneSIK
MSAxNzAgImRsX2VuZXJneSIgIkVuZXJneSIKMSAxNjkgImRsX2RhbmdsZV9kZyIgIkVuZXJneSIK
MSAxNjggImRsaV9lbmVyZ3kiICJFbmVyZ3kiCjEgMTY3ICJicl9lbmVyZ3kiICJFbmVyZ3kiCjEg
MTY2ICJib3Rfc3RhY2siICJFbmVyZ3kiCjEgMTY1ICJibF9lbnQiICJFbmVyZ3kiCjEgMTY0ICJi
bF9lbmVyZ3kiICJFbmVyZ3kiCjEgMTYzICJhc3ltIiAiRW5lcmd5IgoxIDE2MiAiQ0FGIiAiRW5l
cmd5IgoxIDE2MSAidkxUU1ZBIiAiRXhhbXBsZXMiCjEgMTYwICJ0cm5hIiAiRXhhbXBsZXMiCjEg
MTU5ICJzbFJOQSIgIkV4YW1wbGVzIgoxIDE1OCAiczE1bVJOQSIgIkV4YW1wbGVzIgoxIDE1NyAi
cDVhYmMiICJFeGFtcGxlcyIKMSAxNTYgImJzcF90ZXN0MSIgIkV4YW1wbGVzIgoxIDE1NSAiYnNw
X3Rlc3QiICJFeGFtcGxlcyIKMSAxNTQgImJzcF9uYyIgIkV4YW1wbGVzIgoxIDE1MyAiYnNwX21s
IiAiRXhhbXBsZXMiCjEgMTUyICJic3BfbGJsIiAiRXhhbXBsZXMiCjEgMTUxICJic3BfaWwiICJF
eGFtcGxlcyIKMSAxNTAgImJzcF9jaHJpc2IiICJFeGFtcGxlcyIKMSAxNDkgImJzcF9ibCIgIkV4
YW1wbGVzIgoxIDE0OCAiYnNwYSIgIkV4YW1wbGVzIgoxIDE0NyAiYnNwMSIgIkV4YW1wbGVzIgox
IDE0NiAiYnNwIiAiRXhhbXBsZXMiCjEgMTQ1ICJhdHRlbnVhdG9yIiAiRXhhbXBsZXMiCjEgMTQ0
ICJDQUYiICJFeGFtcGxlcyIKMSAxNDMgIkNBRiIgIk1heWJlIgoxIDE0MiAiQ0FGIiAiTGlzdCIK
MSAxNDEgInhfbWlucyIgIk1pbmltdW1zIgoxIDE0MCAieF9taW5pbXVtcyIgIk1pbmltdW1zIgox
IDEzOSAibWlucyIgIk1pbmltdW1zIgoxIDEzOCAibWluaW11bXMiICJNaW5pbXVtcyIKMSAxMzcg
ImVwc2VxIiAiTWluaW11bXMiCjEgMTM2ICJDQUYiICJNaW5pbXVtcyIKMSAxMzUgInRlc3QyZGIi
ICJPdXRwdXQiCjEgMTM0ICJmb3JtYXQiICJPdXRwdXQiCjEgMTMzICJkb3RicmFja2V0IiAiT3V0
cHV0IgoxIDEzMiAiQ0FGIiAiT3V0cHV0IgoxIDEzMSAiQ0FGIiAiSXgiCjEgMTMwICJDQUYiICJB
cnJheSIKMSAxMjkgIn5+fiIgIkNvbWJpbmF0b3IiCjEgMTI4ICJ+fisiICJDb21iaW5hdG9yIgox
IDEyNyAifn4iICJDb21iaW5hdG9yIgoxIDEyNiAiK35+IiAiQ29tYmluYXRvciIKMSAxMjUgIisr
fiIgIkNvbWJpbmF0b3IiCjEgMTI0ICIrKysiICJDb21iaW5hdG9yIgoxIDEyMyAiPCsrKz4iICJD
b21iaW5hdG9yIgoxIDEyMiAiPCsrPiIgIkNvbWJpbmF0b3IiCjEgMTIxICI8Kys9PiIgIkNvbWJp
bmF0b3IiCjEgMTIwICI8KzwiICJDb21iaW5hdG9yIgoxIDExOSAiPCs9Kz4iICJDb21iaW5hdG9y
IgoxIDExOCAiPCs9PiIgIkNvbWJpbmF0b3IiCjEgMTE3ICI8Kz09PiIgIkNvbWJpbmF0b3IiCjEg
MTE2ICI8PDwiICJDb21iaW5hdG9yIgoxIDExNSAiPD0rKz4iICJDb21iaW5hdG9yIgoxIDExNCAi
PD0rPiIgIkNvbWJpbmF0b3IiCjEgMTEzICI8PSs9PiIgIkNvbWJpbmF0b3IiCjEgMTEyICI8PT0r
PiIgIkNvbWJpbmF0b3IiCjEgMTExICI8PT0+IiAiQ29tYmluYXRvciIKMSAxMTAgIi4uLiIgIkNv
bWJpbmF0b3IiCjEgMTA5ICI+Pj4iICJDb21iaW5hdG9yIgoxIDEwOCAifHx8IiAiQ29tYmluYXRv
ciIKMSAxMDcgIndpdGhpbiIgIkNvbWJpbmF0b3IiCjEgMTA2ICJ3aXRoIiAiQ29tYmluYXRvciIK
MSAxMDUgInRvYXJyYXkiICJDb21iaW5hdG9yIgoxIDEwNCAidGFibGUxIiAiQ29tYmluYXRvciIK
MSAxMDMgInRhYmxlIiAiQ29tYmluYXRvciIKMSAxMDIgInN1Y2h0aGF0IiAiQ29tYmluYXRvciIK
MSAxMDEgInNpemVvZiIgIkNvbWJpbmF0b3IiCjEgMTAwICJxIiAiQ29tYmluYXRvciIKMSA5OSAi
cCIgIkNvbWJpbmF0b3IiCjEgOTggImNvbWJpbmU0IiAiQ29tYmluYXRvciIKMSA5NyAiY29tYmlu
ZTMiICJDb21iaW5hdG9yIgoxIDk2ICJjb21iaW5lIiAiQ29tYmluYXRvciIKMSA5NSAiYXhpb20i
ICJDb21iaW5hdG9yIgoxIDk0ICJhdGFibGUiICJDb21iaW5hdG9yIgoxIDkzICJhcCIgIkNvbWJp
bmF0b3IiCjEgOTIgIkNBRiIgIkNvbWJpbmF0b3IiCjEgOTEgInRhZzJjb25fRWJhc2UjIiAiUm5h
SSIKMSA5MCAic3RyMmlucCIgIlJuYUkiCjEgODkgInJuYSIgIlJuYUkiCjEgODggInBhaXIiICJS
bmFJIgoxIDg3ICJudWMiICJSbmFJIgoxIDg2ICJub2Jhc2VwYWlyIiAiUm5hSSIKMSA4NSAibWlu
bG9vcHNpemUiICJSbmFJIgoxIDg0ICJtYXh0YWdfRWJhc2UjIiAiUm5hSSIKMSA4MyAiY29uMnRh
Z19FYmFzZSMiICJSbmFJIgoxIDgyICJjb24ydGFnX0NvbXBvbmVudCMiICJSbmFJIgoxIDgxICJj
b24ydGFnX0NvbXBvbmVudEUjIiAiUm5hSSIKMSA4MCAiYmFzZXBhaXIiICJSbmFJIgoxIDc5ICJD
QUYiICJSbmFJIgoxIDc4ICJDQUYiICJTeXN0ZW0iCjEgNzcgInVsIiAiTWFpbiIKMSA3NiAic3Ry
aXAiICJNYWluIgoxIDc1ICJzdHIiICJNYWluIgoxIDc0ICJzdGFja3BhaXJpbmciICJNYWluIgox
IDczICJzciIgIk1haW4iCjEgNzIgInNhdGhsIiAiTWFpbiIKMSA3MSAic2F0IiAiTWFpbiIKMSA3
MCAic2FkZCIgIk1haW4iCjEgNjkgInJtZGFuZ2xlIiAiTWFpbiIKMSA2OCAicmVzZXRBdHRyIiAi
TWFpbiIKMSA2NyAicmVnaW9uIiAiTWFpbiIKMSA2NiAicmRhbmdsZSIgIk1haW4iCjEgNjUgIm5v
cGFpcndpdGhpbnN0YWNrIiAiTWFpbiIKMSA2NCAibWwiICJNYWluIgoxIDYzICJtaW5zaXplIiAi
TWFpbiIKMSA2MiAibWluQXR0ciIgIk1haW4iCjEgNjEgIm1haW4iICJNYWluIgoxIDYwICJsbWRh
bmdsZSIgIk1haW4iCjEgNTkgImxkYW5nbGUiICJNYWluIgoxIDU4ICJpbmNBdHRyIiAiTWFpbiIK
MSA1NyAiaWx4IiAiTWFpbiIKMSA1NiAiaWxzIiAiTWFpbiIKMSA1NSAiaWxyIiAiTWFpbiIKMSA1
NCAiaWxuIiAiTWFpbiIKMSA1MyAiaWxsIiAiTWFpbiIKMSA1MiAiaF9zIiAiTWFpbiIKMSA1MSAi
aF9sIiAiTWFpbiIKMSA1MCAiaF9rIiAiTWFpbiIKMSA0OSAiaF9pIiAiTWFpbiIKMSA0OCAiaGwi
ICJNYWluIgoxIDQ3ICJoIiAiTWFpbiIKMSA0NiAiZmxhZ1RydWUiICJNYWluIgoxIDQ1ICJmbGFn
RmFsc2UiICJNYWluIgoxIDQ0ICJldWwiICJNYWluIgoxIDQzICJlc2FkZCIgIk1haW4iCjEgNDIg
ImVtcHR5IiAiTWFpbiIKMSA0MSAiZWNhZGQiICJNYWluIgoxIDQwICJkbmlsIiAiTWFpbiIKMSAz
OSAiZGFuZ2xlIiAiTWFpbiIKMSAzOCAiY29uMnRhZ19EbGlzdCMiICJNYWluIgoxIDM3ICJjYWRk
IiAiTWFpbiIKMSAzNiAiYnIiICJNYWluIgoxIDM1ICJibCIgIk1haW4iCjEgMzQgImJhc2UiICJN
YWluIgoxIDMzICJDQUYiICJNYWluIgoxIDMyICJDQUYiICJQcmVsQ29uYyIKMSAzMSAiQ0FGIiAi
UHJlbEZvcmVpZ24iCjEgMzAgIkNBRiIgIlByZWxXZWFrIgoxIDI5ICJDQUYiICJQcmVsSGFuZGxl
IgoxIDI4ICJDQUYiICJQcmVsSU8iCjEgMjcgIkNBRiIgIlByZWxSZWFkIgoxIDI2ICJDQUYiICJQ
cmVsRHluYW1pYyIKMSAyNSAiQ0FGIiAiUHJlbEFkZHIiCjEgMjQgIkNBRiIgIlByZWxBcnIiCjEg
MjMgIkNBRiIgIlByZWxSZWFsIgoxIDIyICJDQUYiICJQcmVsRmxvYXQiCjEgMjEgIkNBRiIgIlBy
ZWxCeXRlQXJyIgoxIDIwICJDQUYiICJQcmVsUGFjayIKMSAxOSAiQ0FGIiAiUHJlbElPQmFzZSIK
MSAxOCAiQ0FGIiAiUHJlbFNUIgoxIDE3ICJDQUYiICJQcmVsRXhjZXB0aW9uIgoxIDE2ICJDQUYi
ICJQcmVsRW51bSIKMSAxNSAiQ0FGIiAiUHJlbFNob3ciCjEgMTQgIkNBRiIgIlByZWxOdW0iCjEg
MTMgIkNBRiIgIlByZWxCYXNlIgoxIDEyICJDQUYiICJQcmVsTWF5YmUiCjEgMTEgIkNBRiIgIlBy
ZWxMaXN0IgoxIDEwICJDQUYiICJQcmVsRXJyIgoxIDkgIkNBRiIgIlByZWxUdXAiCjEgOCAiQ0FG
IiAiUHJlbHVkZSIKMSA3ICJDQUYiICJQcmVsTWFpbiIKMSA2ICJET05UX0NBUkUiICJNQUlOIgox
IDUgIlNVQlNVTUVEIiAiTUFJTiIKMSA0ICJPVkVSSEVBRF9vZiIgIlBST0ZJTElORyIKMSAzICJH
QyIgIkdDIgoxIDIgIlNZU1RFTSIgIk1BSU4iCjEgMSAiTUFJTiIgIk1BSU4iCjIgMSAxIDEKMiA0
NyAyIDE5NiAxCjIgNDggMiAxOTUgMQoyIDQ5IDIgMTYyIDEKMiA1MCAyIDE0NCAxCjIgNTEgMiAx
NDMgMQoyIDUyIDIgMTQyIDEKMiA1MyAyIDEzNiAxCjIgNTQgMiAxMzIgMQoyIDU1IDIgMTMxIDEK
MiA1NiAyIDEzMCAxCjIgNTcgMiA5MiAxCjIgNTggMiA3OSAxCjIgNTkgMiA3OCAxCjIgNjAgMiAz
MyAxCjIgNjEgMiAzMiAxCjIgNjIgMiAzMSAxCjIgNjMgMiAzMCAxCjIgNjQgMiAyOSAxCjIgNjUg
MiAyOCAxCjIgNjYgMiAyNyAxCjIgNjcgMiAyNiAxCjIgNjggMiAyNSAxCjIgNjkgMiAyNCAxCjIg
NzAgMiAyMyAxCjIgNzEgMiAyMiAxCjIgNzIgMiAyMSAxCjIgNzMgMiAyMCAxCjIgNzQgMiAxOSAx
CjIgNzUgMiAxOCAxCjIgNzYgMiAxNyAxCjIgNzcgMiAxNiAxCjIgNzggMiAxNSAxCjIgNzkgMiAx
NCAxCjIgODAgMiAxMyAxCjIgODEgMiAxMiAxCjIgODIgMiAxMSAxCjIgODMgMiAxMCAxCjIgODQg
MiA5IDEKMiA4NSAyIDggMQoyIDg2IDIgNyAxCjIgODcgMiA2IDEKMiA4OCAyIDUgMQoyIDg5IDIg
NCAxCjIgOTAgMiAzIDEKMiA5MSAyIDIgMQoyIDkyIDIgNjEgNjAKMiA5MyAyIDYxIDEKMiA5NCAy
IDcxIDkzCjIgOTUgMiA5NSA5NAoyIDk2IDIgMTEwIDk0CjIgOTcgMiA1MiA5NgoyIDk4IDIgMTE2
IDk0CjIgOTkgMiA5MCA5MwoyIDEwMCAyIDEwOCA5NAoyIDEwMSAyIDEwMCA5NAoyIDEwMiAyIDEw
NCA5NAoyIDEwMyAyIDEwNSA5OQoyIDEwNCAyIDg5IDk5CjIgMTA1IDIgNTAgOTYKMiAxMDYgMiA5
OSA5NAoyIDEwNyAyIDEwMyA5NAoyIDEwOCAyIDQ3IDk2CjIgMTA5IDIgMTA2IDk0CjIgMTEwIDIg
ODAgMTA5CjIgMTExIDIgODggMTEwCjIgMTEyIDIgODcgMTA0CjIgMTEzIDIgMTI4IDk0CjIgMTE0
IDIgMTI2IDk0CjIgMTE1IDIgMzQgOTgKMiAxMTYgMiA3NCAxMDkKMiAxMTcgMiA4OCAxMTYKMiAx
MTggMiA2NSAxMDkKMiAxMTkgMiA3NCAxMTgKMiAxMjAgMiA4OCAxMTkKMiAxMjEgMiA3NCA5NAoy
IDEyMiAyIDg4IDEyMQoyIDEyMyAyIDEyOSA5NAoyIDEyNCAyIDEyNSA5NAoyIDEyNSAyIDM0IDEx
NAoyIDEyNiAyIDEwOSA5NAoyIDEyNyAyIDkzIDk0CjIgMTI4IDIgOTQgOTQKMiAxMjkgMiA2OCAx
MjYKMiAxMzAgMiA1MSA5NgoyIDEzMSAyIDYyIDk0CjIgMTMyIDIgNTggMTI2CjIgMTMzIDIgODYg
NTgKMiAxMzQgMiA4NiAxMDkKMiAxMzUgMiA4MCAxMzQKMiAxMzYgMiA4OCAxMzUKMiAxMzcgMiAx
MDIgOTQKMiAxMzggMiA2NyA5OAoyIDEzOSAyIDEwNyA5NAoyIDE0MCAyIDg2IDEzOQoyIDE0MSAy
IDgwIDE0MAoyIDE0MiAyIDg4IDE0MQoyIDE0MyAyIDY3IDEyNAoyIDE0NCAyIDg4IDExOAoyIDE0
NSAyIDQ5IDk2CjIgMTQ2IDIgNzIgMTA5CjIgMTQ3IDIgNjMgMTQ2CjIgMTQ4IDIgMTAxIDE0Nwoy
IDE0OSAyIDM0IDExMwoyIDE1MCAyIDg2IDE0NgoyIDE1MSAyIDgwIDE1MAoyIDE1MiAyIDg4IDE1
MQoyIDE1MyAyIDY3IDEwOQoyIDE1NCAyIDExMSA5NAoyIDE1NSAyIDY3IDEyMwoyIDE1NiAyIDQy
IDk0CjIgMTU3IDIgNzUgOTgKMiAxNTggMiA0MSA5OAoyIDE1OSAyIDU0IDk4CjIgMTYwIDIgNTUg
OTgKMiAxNjEgMiA0OCA5OAoyIDE2MiAyIDQzIDk4CjIgMTYzIDIgNDAgOTQKMiAxNjQgMiAxNzUg
MTYxCjIgMTY1IDIgMTc2IDE2NAoyIDE2NiAyIDE3NyAxNjQKMiAxNjcgMiAxOTMgMTY2CjIgMTY4
IDIgMTg3IDE2MQoyIDE2OSAyIDE4OSAxNjgKMiAxNzAgMiAxNjMgMTYwCjIgMTcxIDIgMTY2IDE2
MAoyIDE3MiAyIDE5NCAxNzEKMiAxNzMgMiAxODEgMTYwCjIgMTc0IDIgMTkyIDE1OQoyIDE3NSAy
IDE5NCAxNzQKMiAxNzYgMiAxODcgMTU5CjIgMTc3IDIgMTg5IDE3NgoyIDE3OCAyIDE3OCAxNjQK
MiAxNzkgMiAxODMgMTY0CjIgMTgwIDIgNjYgMTU4CjIgMTgxIDIgMTczIDE4MAoyIDE4MiAyIDE3
MiAxODEKMiAxODMgMiAzOSAxNTgKMiAxODQgMiAxNzMgMTgzCjIgMTg1IDIgMTcyIDE4NAoyIDE4
NiAyIDE3MCAxODMKMiAxODcgMiAxNjkgMTg2CjIgMTg4IDIgNTkgMTU3CjIgMTg5IDIgMzYgOTgK
MiAxOTAgMiAxNjcgMTg5CjIgMTkxIDIgMTAxIDE5MAoyIDE5MiAyIDE2NSAxOTAKMiAxOTMgMiAx
ODcgMTg5CjIgMTk0IDIgMTg5IDE5MwoyIDE5NSAyIDczIDk4CjIgMTk2IDIgMzUgOTgKMiAxOTcg
MiAxNjQgMTk2CjIgMTk4IDIgMTAxIDE5NwoyIDE5OSAyIDE2NSAxOTcKMiAyMDAgMiAxODcgMTk2
CjIgMjAxIDIgMTg5IDIwMAoyIDIwMiAyIDE4NyAxOTUKMiAyMDMgMiAxODkgMjAyCjIgMjA0IDIg
NDYgOTQKMiAyMDUgMiAxMTQgOTQKMiAyMDYgMiA0NSA2MAoyIDIwNyAyIDQ1IDEzNwoyIDIwOCAy
IDU3IDk4CjIgMjA5IDIgNTYgOTgKMiAyMTAgMiAxNjMgMjA5CjIgMjExIDIgMTY2IDIwOQoyIDIx
MiAyIDE5NCAyMTEKMiAyMTMgMiAxODEgMjA5CjIgMjE0IDIgMTgxIDIwOAoyIDIxNSAyIDUzIDk4
CjIgMjE2IDIgMTYzIDIxNQoyIDIxNyAyIDE2NiAyMTUKMiAyMTggMiAxOTQgMjE3CjIgMjE5IDIg
MTgxIDIxNQoyIDIyMCAyIDY0IDk4CjIgMjIxIDIgNzYgOTgKMiAyMjIgMiA3MCAyMDUKMiAyMjMg
MiAzNyAyMDUKMiAyMjQgMiAxODggMjIyCjIgMjI1IDIgMTAxIDIyNAoyIDIyNiAyIDM5IDIyMwoy
IDIyNyAyIDYwIDIyMAoyIDIyOCAyIDE2OCAyMjcKMiAyMjkgMiAxNzIgMjI4CjIgMjMwIDIgMTcw
IDIyNwoyIDIzMSAyIDE2OSAyMzAKMiAyMzIgMiA2OSAyMjAKMiAyMzMgMiAxNzEgMjMyCjIgMjM0
IDIgMTY5IDIzMwoyIDIzNSAyIDE3MyAyMzIKMiAyMzYgMiAxNzIgMjM1CjIgMjM3IDIgMTg3IDIy
MAoyIDIzOCAyIDE4OSAyMzcKMiAyMzkgMiAxNzMgMjI2CjIgMjQwIDIgMTcyIDIzOQoyIDI0MSAy
IDE3MCAyMjYKMiAyNDIgMiAxNjkgMjQxCjIgMjQzIDIgNzcgOTgKMiAyNDQgMiAxNzAgMTg4CjIg
MjQ1IDIgMTY5IDI0NAoyIDI0NiAyIDE4NSAxNjUKMiAyNDcgMiAxODUgMjE0CjIgMjQ4IDIgMTg1
IDE5OQo1IDk1NyAxIDEgMCAwIDUgMSA5MyAwIDgzNyAxMjk0MjExMzcgMSA5OSAxIDAgMTkgMSAx
MDQgMSAwIDQ2MSAxIDExMiA1MSAwIDAgMSAxMDMgMSAwIDE5MDAgMSA5NCAxIDggOTgwNDE4IDEg
MjA1IDQ2NzIgMCA1MTM5MiAxIDIyMyAxNzkxIDEgODY5OTggMSAyMjYgMTY0NCAwIDIwMzcyIDEg
MjQxIDExODYgMCA1MjE4NCAxIDI0MiAxMTg2IDAgMjM3MiAxIDIzOSAxMTg2IDAgNTIxODQgMSAy
NDAgMTE4NiAwIDIzNzIgMSAyMjIgMjc4MCAxIDcwNTQ3IDEgMjI0IDI3ODAgMSA0MTcwMCAxIDIy
NSAyNzgwIDAgNTU2MCAxIDIwNCAxIDAgMCAxIDE2MyAyIDAgMCAxIDE1NiAxNTkgMCA0MiAxIDE1
NCA1NjEgMCAzNTk3IDEgMTM5IDE5NzQyIDUgMTUzMjMwNSAxIDE0MCAwIDAgNTkwNzMgMSAxNDEg
MTk2OTEgNiA4NjY0MDQgMSAxNDIgMTk2OTEgMCAwIDEgMTM3IDE4MiAwIDE1MTc4IDEgMjA3IDAg
MCA3MjMzIDEgMTMxIDE3MTIgMCAwIDEgMTI4IDMgMSA2MDg2MDUgMSAxMjcgNzk1MCAzIDQxMzQw
MCAxIDEyNiAxMDc4IDAgNzU0NiAxIDEzMiA5ODEgMCAxODg2IDEgMTI5IDk3IDAgMCAxIDEyNCAz
NjM1IDEgMjA5MTQyIDEgMTQzIDE1ODMgMCA0MTY3IDEgMTIzIDM0MjkgNyAyMTYxNjAzIDEgMTU1
IDEyODEgMCAyNTIwIDEgMTIxIDEzNzggMCA3OTEwMCAxIDEyMiAxNjA0IDAgMCAxIDExNCAxMDIw
NiAzIDUxOTE5MiAxIDEyNSAzNDQxIDAgMjc1MjggMSAxMTMgMTQxMDMgNiA5ODQ1NjMgMSAxNDkg
MjI3NDQgMiAxODE5NTIgMSAxMDkgMTAxNzQgMCAwIDEgMTUzIDcxIDAgMjEzIDEgMTQ2IDk3IDAg
MCAxIDE1MCAwIDAgMjMxIDEgMTUxIDc3IDAgMzM4OCAxIDE1MiA3NyAwIDAgMSAxNDcgMTE3IDAg
MzUxIDEgMTQ4IDExNyAwIDIzNCAxIDEzNCAwIDAgMjkxIDEgMTM1IDk3IDAgNDEwOCAxIDEzNiA5
MiAwIDAgMSAxMTggMTM3OCAwIDEzNjIzIDEgMTQ0IDk3IDAgMCAxIDExOSAxMzc4IDEgMTA3OTcy
IDEgMTIwIDE2MDQgMCAwIDEgMTE2IDQxMzQgMiAzMjM5MTYgMSAxMTcgNDgxMiAwIDAgMSAxMTAg
MTM3OCAyIDU3MzM2IDEgMTExIDEyNzUgMCAwIDEgMTA3IDMgMiAzMDU1NDAgMSAxMDYgMzM3NzEg
MTIgMTE3ODU5MCAxIDEwMiAzIDAgNzM2MyAxIDEwMSAxMjc0MCAxIDExNDY2MCAxIDEwMCAxMTMz
MCAyIDIxNjUxMCAxIDk4IDQ0ODczIDcgODc3NTgxIDEgMjQzIDc1IDAgMTk1MCAxIDIyMSAyNDA0
IDAgMCAxIDIyMCAyNDA0IDIgMTUzNTIxIDEgMjM3IDI0MDQgMSAxMzk0MzIgMSAyMzggMjQwNCAw
IDQ4MDggMSAyMzIgMTI1MyAxIDE2Mjg5IDEgMjM1IDEyNTMgMSA1NTEzMiAxIDIzNiAxMjUzIDAg
MjUwNiAxIDIzMyAxMjUzIDAgNTUxMzIgMSAyMzQgMTI1MyAwIDI1MDYgMSAyMjcgMjQwNCAwIDMx
MTk2IDEgMjMwIDIzNzggMCAxMDQ2MzIgMSAyMzEgMjM3OCAwIDQ3NTYgMSAyMjggMjM3OCAxIDEw
NDYzMiAxIDIyOSAyMzc4IDEgNDc1NiAxIDIxNSA2MTAgMCA0NjM2MCAxIDIxOSA2MTAgMCAwIDEg
MjE3IDYxMCAwIDM1MzgwIDEgMjE4IDYxMCAwIDEyMjAgMSAyMTYgNjEwIDAgMTAzNzAgMSAyMDkg
NDM3IDEgMTgzNTQgMSAyMTMgNDM3IDAgMCAxIDIxMSA0MzcgMCAyNTM0NiAxIDIxMiA0MzcgMCA4
NzQgMSAyMTAgNDM3IDAgNjU1NSAxIDIwOCAzNzM0IDAgMTU2ODI4IDEgMjE0IDc0ODcgMCAxOTAg
MSAyNDcgMTkgMCA1MzIgMSAxOTYgMTM1NSAwIDYwOTc1IDEgMjAwIDEzNTUgMCA3ODU5MCAxIDIw
MSAxMzU1IDAgMjcxMCAxIDE5NyAxMzU1IDAgODEzMCAxIDE5OSAxMzU2IDAgMTAgMSAyNDggMSAw
IDI4IDEgMTk4IDEzNTUgMSAyNzEwIDEgMTk1IDE0NCAwIDM0NTYgMSAyMDIgMTQ0IDAgODM1MiAx
IDIwMyAxNDQgMCAyODggMSAxODkgNjAgMCAyNzAwIDEgMTkzIDYwIDAgMzQ4MCAxIDE5NCA2MCAw
IDEyMCAxIDE5MCA2MCAwIDM2MCAxIDE5MiA2MCAwIDAgMSAxOTEgNjAgMCAxMjAgMSAxNjIgMTE0
NjggMiAxOTQ4MjMgMSAxNjEgNzEgMCAyNDg1IDEgMTY4IDcxIDAgNDExOCAxIDE2OSA3MSAwIDE0
MiAxIDE2NCA3MSAxIDE3MzIgMSAxNzkgNCAwIDQwNCAxIDE3OCA0IDAgMCAxIDE2NiA3MCAwIDQw
NjAgMSAxNjcgNzAgMCAxNDAgMSAxNjUgODAgMCA5MCAxIDI0NiA5IDAgMjUyIDEgMTYwIDc4MCAx
IDU5MjgwIDEgMTczIDc4MCAwIDAgMSAxNzEgNzgwIDAgNDUyNDAgMSAxNzIgNzgwIDAgMTU2MCAx
IDE3MCA3ODAgMSAxMzI2MCAxIDE1OSAyMTA1IDAgOTQ3MjUgMSAxNzYgMjEwNSAxIDEyMjA5MCAx
IDE3NyAyMTA1IDAgNDIxMCAxIDE3NCAyMTA1IDEgMTIyMDkwIDEgMTc1IDIxMDUgMCA0MjEwIDEg
MTU4IDEwOTQ3IDMgNDgxNjY4IDEgMTgzIDQ4NDQgMiA2MDQ1MiAxIDE4NiAzOTAwIDMgMTcxNjAw
IDEgMTg3IDM5MDAgMCA3ODAwIDEgMTg0IDM5MDAgMyAxNzE2MDAgMSAxODUgMzkwMCAwIDc4MDAg
MSAxODAgNjEwMyAxIDM2NjE4IDEgMTgxIDYxMDMgNSAyNjg1MzIgMSAxODIgNjEwMyAxIDEyMjA2
IDEgMTU3IDEwNzk2IDAgMjM3NDk5IDEgMTg4IDEwNzk1IDEgMCAxIDI0NCAxMDI3OSA1IDQ1MjI3
NiAxIDI0NSAxMDI3OSAwIDIwNTU4IDEgMTM4IDgxODAgMiAyMjU2OSAxIDExNSA5NzQzIDMgNzc5
NDQgMSA5NiA5IDAgMTAzNDQgMSAxNDUgOTA0IDAgMCAxIDEzMCA5ODEgMCAwIDEgMTA4IDEzNzgg
MCAwIDEgMTA1IDE2OSAwIDAgMSA5NyAxIDAgMCAxIDk1IDEgMCAwIDEgODggMCAwIDAgMSA4NiAw
IDAgMCAxIDg1IDAgMCAwIDEgODQgMCAwIDAgMSA4MyAwIDAgMCAxIDgyIDAgMCAwIDEgODEgMCAw
IDAgMSA4MCAwIDAgMCAxIDc5IDAgMCAwIDEgNzggMSAwIDMgMSA3NyAwIDAgMCAxIDc2IDAgMCAw
IDEgNzUgMCAwIDAgMSA3NCAwIDAgMCAxIDczIDAgMCAwIDEgNzIgMCAwIDAgMSA3MSAxNyAwIDk1
OTMgMSA3MCAwIDAgMCAxIDY5IDAgMCAwIDEgNjggMCAwIDAgMSA2NyAwIDAgMCAxIDY2IDAgMCAw
IDEgNjUgMCAwIDAgMSA2NCAzIDAgMzcgMSA2MyAwIDAgMCAxIDYyIDAgMCAwIDEgNjEgMCAwIDAg
MSA2MCA0MyAxIDQ0MTI1IDEgMjA2IDEgMCA1IDEgOTIgMSAwIDcgMSA1OSAzIDAgMzM5IDEgNTgg
MTIgMCAxMzYgMSAxMzMgMSAwIDUgMSA1NyAxMiAwIDgwIDEgNTYgMCAwIDAgMSA1NSAwIDAgMCAx
IDU0IDAgMCAwIDEgNTMgMCAwIDAgMSA1MiAwIDAgMCAxIDUxIDAgMCAwIDEgNTAgMCAwIDAgMSA0
OSA3IDAgMjUgMSA0OCAwIDAgMCAxIDQ3IDAgMCAwIDAK
--_=XFMail.1.3.p0.Solaris:001207193935:15881=_--
End of MIME message
From qrczak@knm.org.pl Thu Dec 7 19:31:02 2000
Date: 7 Dec 2000 19:31:02 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Fun with GHC's optimiser
Thu, 7 Dec 2000 09:17:44 -0800, Simon Peyton-Jones <simonpj@microsoft.com> pisze:
> Try now. On the HEAD. Which should compile OK now, incidentally.
But does not work...
../../ghc/compiler/ghc-inplace -recomp -cpp -fglasgow-exts -fvia-C -icheck -O -package lang -package concurrent -package posix -package-name util -I../lang/cbits -I../concurrent/cbits -I../posix/cbits -split-objs -c Unique.lhs -o Unique.o -osuf o
panic! (the `impossible' happened):
mkWWcpr: not a product PrelNum.Integer{-311-}
And also:
ghc-inplace --interactive
[...]
Loading package std ... resolving ... ghc: fatal error: ocResolve_ELF: /home/users/qrczak/cvs/fptools/ghc/driver/../lib/std/HSstd.o: unknown symbol `PrelNum_showSignedInteger_closure'
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From rrt1001@cam.ac.uk Fri Dec 8 10:54:37 2000
Date: Fri, 8 Dec 2000 10:54:37 +0000 (GMT)
From: Reuben Thomas rrt1001@cam.ac.uk
Subject: New InstallShield: no more DLLs
> Did you already try out a statically linked, stripped DLL on Win2K? Do
> you get the same
> error?
Yes, I did, and I didn't get the error. (At least, not after the latest
round of debugging.)
> Do you have some idea what's wrong here?
Only the idea I had before: that something is going wrong during DLL
startup. The best suggestion I've seen is that there's a problem with trying
to use the value of uninitialised pointers, and that when they lie within the
application address space there's no problem, but when they lie outside, an
error is raised. The only guess I have as to why this could be happening (on
our side) is the hack used to allow static initialisers in DLLs.
On the other hand, there is definitely a problem with the linker, which
creates different executables depending on the order in which the libraries
are stored on the disk. I'm not sure whether this is causing problems;
indeed, the fact that the current problem occurs on some machines and not on
others suggests that it is not. It is nevertheless weird, and *can* make the
difference between the problem occurring or not (as it did on my machine).
So it's a sufficient but not necessary cause.
For the moment I'm not investigating this. I will again when I can find the
enthusiasm.
There's one thing that worries me about your message: are you saying that
you can reproduce the problem with a statically linked DLL? I've only ever
had the problem with dynamic DLLs. That's one reason that I've given up on
it for the moment: it is still possible to use DLLs reliably, as far as I'm
concerned. I thought that Arjan only had problems, as I did, with the
dynamically linked version. If this is false, I'd better dig a bit more.
--
http://sc3d.org/rrt/ | impatience, n. the urge to do nothing
From simonpj@microsoft.com Fri Dec 8 13:57:55 2000
Date: Fri, 8 Dec 2000 05:57:55 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Fun with GHC's optimiser
PArrays.$w$snewPArray
= \ ww :: PrelGHC.Int# w :: PrelBase.Int ->
case PrelGHC.newIntArray# @ PrelGHC.RealWorld ww PrelGHC.realWorld#
of wild { (# s2#, mba# #) ->
let {
eta :: PrelBase.Int
__A 0 __C
eta
= PrelBase.$wI# ww
} in
case PrelGHC.-# ww 1 of sat { __DEFAULT ->
case PrelGHC.># 0 sat of wild1 {
PrelBase.True ->
PArrays.$wPArray
@ PrelBase.Int eta (__coerce PrelGHC.ByteArray# mba#);
PrelBase.False ->
case w of w1 { PrelBase.I# ww1 ->
case PrelGHC.writeIntArray# @ PrelGHC.RealWorld mba# 0 ww1
s2#
of s2#1 { __DEFAULT ->
case PrelGHC.-# ww 1 of wild2 {
0 ->
PArrays.$wPArray
@ PrelBase.Int eta (__coerce
PrelGHC.ByteArray# mba#);
__DEFAULT ->
let {
a4 :: (PArrays.PArray PrelBase.Int)
__A 0 __C
a4 =
PArrays.$wPArray
@ PrelBase.Int eta (__coerce
PrelGHC.ByteArray# mba#) } in
__letrec {
$wgo :: (PrelGHC.Int#
-> PrelGHC.State# PrelGHC.RealWorld
-> (PrelGHC.State#
PrelGHC.RealWorld,
PArrays.PArray PrelBase.Int))
__A 2 __C
$wgo
= \ w2 :: PrelGHC.Int# w3 :: (PrelGHC.State#
PrelGHC.RealWorld) ->
case PrelGHC.writeIntArray# @
PrelGHC.RealWorld mba# w2 ww1 w3
of s2#2 { __DEFAULT ->
case PrelGHC.-# ww 1 of sat1 { __DEFAULT
->
case PrelGHC.==# w2 sat1 of wild11 {
PrelBase.True -> (# s2#2, a4 #);
PrelBase.False ->
case PrelGHC.+# w2 1 of sat2 {
__DEFAULT ->
$wgo sat2 s2#2
}
}
}
};
} in case $wgo 1 s2#1 of wild3 { (# ds, r #) -> r
}
}
}
}
}
}
}
| However, we came across one problem (read, lack of
| optimisation on GHC's part), which leads to tedious
| duplication of a lot of code in our array library.
| Basically, GHC does not recognise for tail recursive
| functions when certain arguments (accumulators maintained in
| a loop) can be unboxed. This leads to massive overheads in
| our code. Currently, we circumvent the inefficiency by
| having manually specialised versions of the loops for
| different accumulator types and using RULES to select them
| where appropriate (based on the type information). I will
| send you some example code illustrating the problem soon.
Yes please.
Meanwhile, in the head, if you specify -O2 you'll get better
code for some of your loops, namely the ones that repeatedly
evaluate a free variable every time round the loop. The
loop is duplicated and everything is nice. Here's a tiny example:
g :: Int -> Int
g x = let h 0 = 0
h y = if x==0 then y else h (y+1)
in
h 88
This now compiles to:
LC.g
= \ x :: PrelBase.Int ->
case x of wild { PrelBase.I# x1 ->
case x1 of wild1 {
0 -> PrelBase.$wI# 88;
__DEFAULT ->
__letrec {
$wh :: (PrelGHC.Int# -> PrelBase.Int)
__A 1 __C
$wh
= \ ww :: PrelGHC.Int# ->
case ww of wild2 {
0 -> LC.lit;
__DEFAULT ->
case PrelGHC.+# wild2 1 of sat { __DEFAULT
-> $wh sat }
};
} in $wh 89
}
}
You mentioned something like this before.
The amount of code duplication is controlled by -fliberate-case-threshold20
(say)
The default is set pretty low. And it all only happens with -O2.
All in the HEAD. The pass is call simplCore/LiberateCase.
Simon
From dirk@TechFak.Uni-Bielefeld.DE Fri Dec 8 17:08:33 2000
Date: Fri, 08 Dec 2000 18:08:33 +0100 (MET)
From: Dirk Evers dirk@TechFak.Uni-Bielefeld.DE
Subject: Beginners profiling question
No answer?
Is the question too stupid?
Cheers
Dirk
On 07-Dec-00 Dirk Evers wrote:
>=20
> So I have tried profiling the first time...
>=20
> using ghc-4.08.1 with options -prof -auto-all
> runtime option -px
> ghcprof and daVinci work like a charm
>=20
> what I see is
>=20
> main uses 99.90 % time and space
> sat for practical purposes is the only function called from main and
> uses ca. 12 % time and space
>=20
> what am I doing wrong...
> Prelude not compiled for profiling?
>=20
> Thanks in advance
> Dirk
> ---
> +---------------------------------------------------------------------+
>| Dirk Evers Office: M3-120 |
>| Technische Fakultaet / AG PI Tel: +49 521 106-2905 |
>| Universitaet Bielefeld FAX: +49 521 106-6411 |
>| D-33594 Bielefeld e-mail: dirk@TechFak.Uni-Bielefeld.DE |
>| Germany URL: http://www.TechFak.Uni-Bielefeld.DE/~dirk/ |
>|---------------------------------------------------------------------|
>| Die Succulenten / a cappella singing / http://www.succulenten.de |
> +---------------------------------------------------------------------+
---
+---------------------------------------------------------------------+
| Dirk Evers Office: M3-120 |
| Technische Fakultaet / AG PI Tel: +49 521 106-2905 |
| Universitaet Bielefeld FAX: +49 521 106-6411 |
| D-33594 Bielefeld e-mail: dirk@TechFak.Uni-Bielefeld.DE |
| Germany URL: http://www.TechFak.Uni-Bielefeld.DE/~dirk/ |
|---------------------------------------------------------------------|
| Die Succulenten / a cappella singing / http://www.succulenten.de |
+---------------------------------------------------------------------+
From simonpj@microsoft.com Fri Dec 8 17:33:35 2000
Date: Fri, 8 Dec 2000 09:33:35 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Beginners profiling question
| No answer?
| Is the question too stupid?
not at all. just no one with time to answer today. posting your program
too would be a useful thing to do.
Simon
From simonmar@microsoft.com Mon Dec 11 11:18:20 2000
Date: Mon, 11 Dec 2000 03:18:20 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: Beginners profiling question
> So I have tried profiling the first time...
>
> using ghc-4.08.1 with options -prof -auto-all
> runtime option -px
> ghcprof and daVinci work like a charm
>
> what I see is
>
> main uses 99.90 % time and space
> sat for practical purposes is the only function called from main and
> uses ca. 12 % time and space
>
> what am I doing wrong...
> Prelude not compiled for profiling?
I'm not sure what you're expecting to see - the profile looks reasonable
to me. Why do you think it's wrong?
Ah, perhaps you're worried that the percentages don't add up to 100%:
that's because they're "inherited", i.e. sat's costs form part of the
total costs of main, because main called sat. The daVinci browser has a
button to turn off inherited stats, as I recall.
BTW, we're working on a new profile viewer. Here is a screenshot
showing your profile:
http://research.microsoft.com/~simonmar/pview.jpg
the user interface is little rough at the moment, but you can see the
general idea.
Cheers,
Simon
From dirk@TechFak.Uni-Bielefeld.DE Mon Dec 11 11:36:22 2000
Date: Mon, 11 Dec 2000 12:36:22 +0100 (MET)
From: Dirk Evers dirk@TechFak.Uni-Bielefeld.DE
Subject: Beginners profiling question
On 11-Dec-00 Simon Marlow wrote:
>> So I have tried profiling the first time...
>>=20
>> using ghc-4.08.1 with options -prof -auto-all
>> runtime option -px
>> ghcprof and daVinci work like a charm
>>=20
>> what I see is
>>=20
>> main uses 99.90 % time and space
>> sat for practical purposes is the only function called from main and
>> uses ca. 12 % time and space
>>=20
>> what am I doing wrong...
>> Prelude not compiled for profiling?
>=20
> I'm not sure what you're expecting to see - the profile looks reasonable
> to me. Why do you think it's wrong?
>=20
> Ah, perhaps you're worried that the percentages don't add up to 100%:
> that's because they're "inherited", i.e. sat's costs form part of the
> total costs of main, because main called sat. The daVinci browser has a
> button to turn off inherited stats, as I recall.
Your picture shows that sat uses 12% of the time, and main uses 99% which i=
s
fine because it inherites all time usage. But main really only calls sat, l=
ike
so:
main =3D do
~[rnastr] <- getArgs
print (sat (str2inp rnastr (0::Int)))
str2inp is just a small data conversion routines for sat. So where
does all the time go?
> BTW, we're working on a new profile viewer. Here is a screenshot
> showing your profile:
>=20
> http://research.microsoft.com/~simonmar/pview.jpg
>=20
> the user interface is little rough at the moment, but you can see the
> general idea.
This looks nice!
>=20
> Cheers,
> Simon
>=20
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I will set up a complete example as Simon Peyton-Jones suggested.
Thanks again
Dirk
---
+---------------------------------------------------------------------+
| Dirk Evers Office: M3-120 |
| Technische Fakultaet / AG PI Tel: +49 521 106-2905 |
| Universitaet Bielefeld FAX: +49 521 106-6411 |
| D-33594 Bielefeld e-mail: dirk@TechFak.Uni-Bielefeld.DE |
| Germany URL: http://www.TechFak.Uni-Bielefeld.DE/~dirk/ |
|---------------------------------------------------------------------|
| Die Succulenten / a cappella singing / http://www.succulenten.de |
+---------------------------------------------------------------------+
From simonmar@microsoft.com Mon Dec 11 11:46:05 2000
Date: Mon, 11 Dec 2000 03:46:05 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: Beginners profiling question
> Your picture shows that sat uses 12% of the time, and main
> uses 99% which is
> fine because it inherites all time usage. But main really
> only calls sat, like
> so:
>
> main = do
> ~[rnastr] <- getArgs
> print (sat (str2inp rnastr (0::Int)))
>
> str2inp is just a small data conversion routines for sat. So where
> does all the time go?
Probably in "print". Yes, the Prelude isn't compiled with -auto-all (or
even -auto) by default. We'll probably start doing this when the better
profile viewers come on-line.
Cheers,
Simon
From chak@cse.unsw.edu.au Mon Dec 11 13:41:01 2000
Date: Tue, 12 Dec 2000 00:41:01 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Transitive inlining
In the context of the array library, we stumbled over
another problem. Does GHC transitive inlining across
modules? Let's say, we have the following scenario:
module B (foo) where
{-# INLINE foo #-}
foo .. = ...bar...
{-# INLINE bar #-}
bar .. = ...
module L (baz) where
import B
{#- INLINE baz #-}
baz .. = ...B.foo...
module Main where
import L
main .. = ...L.baz...
GHC in this case inlines the whole expression "...B.foo..."
in `Main', but will it inline the right hand side of `B.bar'
in `Main' (or even of `B.foo')? If the INLINE pragma is
transitive across modules boundaries, one would hope so.
It seems that GHC is not (always?) doing this inlining,
which already for a very simple benchmark costs us a factor
of 5 runtime! (With inlining - enforced by copying
definitions manually into `Main' - the code produced by GHC
is actually a little bit faster than the code for the
corresponding C program).
Cheers,
Manuel
PS: I had problems building GHCi and it seems as if my
message to cvs-ghc@haskell.org doesn't get through
somehow...
From qrczak@knm.org.pl Mon Dec 11 19:08:48 2000
Date: 11 Dec 2000 19:08:48 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Transitive inlining
Tue, 12 Dec 2000 00:41:01 +1100, Manuel M. T. Chakravarty <chak@cse.unsw.edu.au> pisze:
> PS: I had problems building GHCi and it seems as if my
> message to cvs-ghc@haskell.org doesn't get through
> somehow...
Subject: "mail boot" problem
?
I have got it.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From chak@cse.unsw.edu.au Thu Dec 14 07:40:20 2000
Date: Thu, 14 Dec 2000 18:40:20 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Fun with GHC's optimiser
Simon Peyton-Jones <simonpj@microsoft.com> wrote,
> Meanwhile, in the head, if you specify -O2 you'll get better
> code for some of your loops, namely the ones that repeatedly
> evaluate a free variable every time round the loop. The
> loop is duplicated and everything is nice.
[..]
> You mentioned something like this before.
>
> The amount of code duplication is controlled by -fliberate-case-threshold20
> (say)
> The default is set pretty low. And it all only happens with -O2.
It works nicely :-)
In what kind of unit is the number after the
-fliberate-case-threshold option. I really need to use 20
for it to work on the current version of the array code
(where the loop that is to be optimised is much more
involved than the initial example that I posted).
Thanks,
Manuel
From kort@wins.uva.nl Thu Dec 14 14:03:34 2000
Date: Thu, 14 Dec 2000 15:03:34 +0100
From: Jan Kort kort@wins.uva.nl
Subject: C stack
Hi,
I'm trying to write an interface for a C library that
uses a Boehm type garbage collector. So, I need to get
the address of the bottom of the C stack. In a C
application this would look something like:
main()
{
int bottomOfStack;
}
Where "&bottomOfStack" would be the thing I need. So,
I'd want some function like:
bottomOfStack :: IO Addr
Would it be possible at all to make an interface to
a C library that uses Boehm's garbage collection ?
What Boehm's algorithm does is traverse the C stack
at each garbage collect marking all accessible
nodes and then sweeping all unmarked nodes. Would
this cause problems with the C code generated by
ghc ?
Jan
From chak@cse.unsw.edu.au Fri Dec 15 07:24:04 2000
Date: Fri, 15 Dec 2000 18:24:04 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Fun with GHC's optimiser
Simon Peyton-Jones <simonpj@microsoft.com> wrote,
> | However, we came across one problem (read, lack of
> | optimisation on GHC's part), which leads to tedious
> | duplication of a lot of code in our array library.
> | Basically, GHC does not recognise for tail recursive
> | functions when certain arguments (accumulators maintained in
> | a loop) can be unboxed. This leads to massive overheads in
> | our code. Currently, we circumvent the inefficiency by
> | having manually specialised versions of the loops for
> | different accumulator types and using RULES to select them
> | where appropriate (based on the type information). I will
> | send you some example code illustrating the problem soon.
>
> Yes please.
I have found a way of rephrasing the definition so that it
is properly optimised by GHC. However, I think, it should
be possible to do this automatically and it is maybe not
unlike the optimisation done by simplCore/LiberateCase.
The code I would like to write is, for example, the
following
import PrelGHC
import PrelBase
import PrelST
fill :: MutableByteArray# s
-> (acc -> Int)
-> (acc -> acc)
-> Int
-> acc
-> ST s acc
{-# INLINE fill #-}
fill mba# f g (I# n#) start = fill0 0# start
where
fill0 i# acc | i# ==# n# = return acc
| otherwise = do
writeIntArray mba# (I# i#) (f acc)
fill0 (i# +# 1#) (g acc)
writeIntArray :: MutableByteArray# s -> Int -> Int -> ST s ()
{-# INLINE writeIntArray #-}
writeIntArray mba# (I# i#) (I# e#) = ST $ \s# ->
case writeIntArray# mba# i# e# s# of {s2# ->
(# s2#, () #)}
foo mba# n = fill mba# id (+1) 1000 0
The interesting part is the handling of the accumulator.
After inlining `fill' into `foo', it becomes obvious that
the accumulator can be maintained as an unboxed integer.
Unfortunately, it is not obvious to GHC, which generates the
following (this is just the inlined `fill0' loop):
__letrec {
$wfill0 :: (PrelGHC.Int#
-> PrelBase.Int
-> PrelGHC.State# s -> (PrelGHC.State# s, PrelBase.Int))
__A 3 __C
$wfill0
= \ w2 :: PrelGHC.Int#
w3 :: PrelBase.Int
w4 :: (PrelGHC.State# s) ->
case w2 of wild {
1000 -> (# w4, w3 #);
__DEFAULT ->
case w3 of wild1 { PrelBase.I# e# ->
case PrelGHC.writeIntArray# @ s w wild e# w4 of s2# { __DEFAULT ->
case PrelGHC.+# e# 1 of a { __DEFAULT ->
let {
sat :: PrelBase.Int
__A 0 __C
sat
= PrelBase.$wI# a
} in
case PrelGHC.+# wild 1 of sat1 { __DEFAULT ->
$wfill0 sat1 sat s2#
}
}
}
}
};
} in $wfill0 0 Test.lit w1
The accumulator (w3) is unboxed immediately before the
writeIntArray# and its next value put into a box (sat) -
only to be unboxed immediately again in the next loop
iteration.
This would make perfect sense when the definition of `foo'
were
foo mba# n = fill mba# id plus 1000 0
where
plus 0 = error "Die horribly"
plus x = x + 1
I also appreciate that, if the loop is executed zero times,
the initial value of `acc' is not demanded. But this is not
much different to the case handled by simplCore/LiberateCase.
And indeed with a little help, GHC generates much better
code. In the following, I rewrote `fill' to explicitly test
for input values that make the loop execute zero times:
fill mba# f g (I# 0#) start = return start
fill mba# f g (I# n#) start = fill0 0# start
where
fill0 i# acc = do
writeIntArray mba# (I# i#) (f acc)
let i'# = i# +# 1#
acc' = g acc
if i'# ==# n# then return acc' else fill0 i'# acc'
Now, `acc' is guaranteed to be used in each invocation of
`fill0' and GHC generates:
__letrec {
$wfill0 :: (PrelGHC.Int#
-> PrelGHC.Int#
-> PrelGHC.State# s -> (PrelGHC.State# s, PrelBase.Int))
__A 3 __C
$wfill0
= \ w2 :: PrelGHC.Int#
ww :: PrelGHC.Int#
w3 :: (PrelGHC.State# s) ->
case PrelGHC.writeIntArray# @ s w w2 ww w3 of s2# { __DEFAULT ->
case PrelGHC.+# w2 1 of wild {
1000 ->
case PrelGHC.+# ww 1 of a { __DEFAULT ->
let {
a1 :: PrelBase.Int
__A 0 __C
a1
= PrelBase.$wI# a
} in (# s2#, a1 #)
};
__DEFAULT ->
case PrelGHC.+# ww 1 of sat { __DEFAULT -> $wfill0 wild sat s2# }
}
};
} in $wfill0 0 0 w1
A nice tight loop.
However, the initial version of `fill' is the more natural
one to write. I think, it should be possible to derive the
second version (are at least a similar version)
automatically from the initial code. The derivation might
go roughly as follows:
fill mba# f g (I# n#) start = fill0 0# start
where
fill0 i# acc = case i# ==# n# of
True -> return acc
False -> do
writeIntArray mba# (I# i#) (f acc)
fill0 (i# +# 1#) (g acc)
=== {pull case out of fill0 (ie, partial unfolding)}
fill mba# f g (I# n#) start =
case 0# ==# n# of
True -> return start
False -> fill0 0# start
where
fill0 i# acc = do
writeIntArray mba# (I# i#) (f acc)
case (i# +# 1#) ==# n# of
True -> return (g acc)
False -> fill0 (i# +# 1#) (g acc)
This is essentially the recursive variant of a well known
law for while loops:
while p do q;
===
if p then do q while p;
Wouldn't this actually subsume the liberate case rule?
f = \ t -> case v of
V a b -> a : f t
=== {pull out the case}
f = case v of
V a b -> f = \ t -> a : case v of
V a b -> f t
=== {simplification}
f = case v of
V a b -> f = \ t -> a : f t
This might be more complicated to implement, as we only
partially unfold the recursive function, but it also has
more scope.
What do you think?
Cheers,
Manuel
PS: All Core code was generated with the HEAD from two days ago.
From simonmar@microsoft.com Fri Dec 15 10:13:11 2000
Date: Fri, 15 Dec 2000 02:13:11 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: C stack
> Hi,
>
> I'm trying to write an interface for a C library that
> uses a Boehm type garbage collector. So, I need to get
> the address of the bottom of the C stack. In a C
> application this would look something like:
> main()
> {
> int bottomOfStack;
> }
> Where "&bottomOfStack" would be the thing I need. So,
> I'd want some function like:
> bottomOfStack :: IO Addr
>
> Would it be possible at all to make an interface to
> a C library that uses Boehm's garbage collection ?
> What Boehm's algorithm does is traverse the C stack
> at each garbage collect marking all accessible
> nodes and then sweeping all unmarked nodes. Would
> this cause problems with the C code generated by
> ghc ?
I don't forsee any problems with the C stack - the stack pointer stays
static during execution of Haskell code, and only moves when we do a C
call or return to the RTS.
Don't forget to tell the GC to traverse the Haskell heap too - GHC keeps
this in mmapped address space. See fptools/ghc/rts/MBlock.c for the
details.
Cheers,
Simon
From kort@wins.uva.nl Fri Dec 15 16:59:30 2000
Date: Fri, 15 Dec 2000 17:59:30 +0100
From: Jan Kort kort@wins.uva.nl
Subject: C stack
Simon Marlow wrote:
>
> I don't forsee any problems with the C stack - the stack pointer stays
> static during execution of Haskell code, and only moves when we do a C
> call or return to the RTS.
But how do I get the address of the bottom of the stack ? It seems I can
define a C main so I can get the bottom of the stack, but how do I make
it call Haskell's main to start the application ?
>
> Don't forget to tell the GC to traverse the Haskell heap too - GHC keeps
> this in mmapped address space. See fptools/ghc/rts/MBlock.c for the
> details.
Ok, I will do that, it looks like a better idea than working with
ForeignObj and finalizers.
Jan
From shutej@rpi.edu Sat Dec 16 19:34:28 2000
Date: Sat, 16 Dec 2000 14:34:28 -0500
From: Jeremy Shute shutej@rpi.edu
Subject: Having to use -static flag under Win32 with 4.08 & Cygwin 1.1.6
Hi,
I've been perusing the documentation looking for what I've done wrong...
1. I got the latest versions of both Cygwin and GHC.
2. I installed Cygwin on a clean partition, F:
3. I installed GHC in /usr/share/ghc/ (on F:, of course)
4. I copied the Perl binary over to /bin, and pointed the bang in the ghc
script to the location of the binary (I found this a necessary step).
5. I got a little test program from the web:
{--------------------------------------}
module Main where
main = putStrLn "Hello, World!"
{--------------------------------------}
6. Tried to compile said program:
$ ghc main.hs
Output file not specified, defaulting to "main.exe"
gcc: F:/usr/share/ghc/lib/Main.dll_o: No such file or directory
gcc: F:/usr/share/ghc/lib/PrelMain.dll_o: No such file or directory
7. Confirmed that these files exist nowhere on the partition. Messed
around some more to no avail, came across static flag and tried that:
$ rm Main.hi main.o
$ ghc -static main.hs
Output file not specified, defaulting to "main.exe"
$ ./main.exe
Hello, World!
8. Think I'm onto something so look around for an additional installation
step I perhaps did not take, such as building libraries from source shipped
with the distro. Nope, can't find any. I can't imagine why that would even
be necessary, to support Win32 on Alphas maybe?
So alas, here I sit frustrated, waiting for comp.lang.functional, and I
figured I'd try you guys. Has anyone else had this problem? If not,
perhaps you still have an idea of what's going on? This would be much
appreciated...
Jeremy Shute
From simonpj@microsoft.com Mon Dec 18 10:24:16 2000
Date: Mon, 18 Dec 2000 02:24:16 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Transitive inlining
Yes, all the inlining you expect should indeed happen. If
it doesn't can you show us an example?
Simon
| -----Original Message-----
| From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au]
| Sent: 11 December 2000 13:41
| To: glasgow-haskell-users@haskell.org
| Cc: keller@it.uts.edu.au
| Subject: Transitive inlining
|
|
| In the context of the array library, we stumbled over
| another problem. Does GHC transitive inlining across
| modules? Let's say, we have the following scenario:
|
| module B (foo) where
|
| {-# INLINE foo #-}
| foo .. = ...bar...
|
| {-# INLINE bar #-}
| bar .. = ...
|
|
| module L (baz) where
|
| import B
|
| {#- INLINE baz #-}
| baz .. = ...B.foo...
|
|
| module Main where
|
| import L
|
| main .. = ...L.baz...
|
| GHC in this case inlines the whole expression "...B.foo..."
| in `Main', but will it inline the right hand side of `B.bar'
| in `Main' (or even of `B.foo')? If the INLINE pragma is
| transitive across modules boundaries, one would hope so.
|
| It seems that GHC is not (always?) doing this inlining,
| which already for a very simple benchmark costs us a factor
| of 5 runtime! (With inlining - enforced by copying
| definitions manually into `Main' - the code produced by GHC
| is actually a little bit faster than the code for the
| corresponding C program).
|
| Cheers,
| Manuel
|
| PS: I had problems building GHCi and it seems as if my
| message to cvs-ghc@haskell.org doesn't get through
| somehow...
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From simonmar@microsoft.com Mon Dec 18 13:40:24 2000
Date: Mon, 18 Dec 2000 05:40:24 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: C stack
> Simon Marlow wrote:
> >
> > I don't forsee any problems with the C stack - the stack
> pointer stays
> > static during execution of Haskell code, and only moves
> when we do a C
> > call or return to the RTS.
>
> But how do I get the address of the bottom of the stack ? It
> seems I can
> define a C main so I can get the bottom of the stack, but how
> do I make
> it call Haskell's main to start the application ?
Well, you could "foreign export" your top-level Haskell function and
just call it from C. Check out ghc/includes/RtsAPI.c for the API (you
need to call startupHaskell() first and shutdownHaskell() afterward).
Sadly we haven't documented this stuff very well.
Cheers,
Simon
From simonpj@microsoft.com Tue Dec 19 08:46:32 2000
Date: Tue, 19 Dec 2000 00:46:32 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Fun with GHC's optimiser
Manuel
| I have found a way of rephrasing the definition so that it
| is properly optimised by GHC. However, I think, it should
| be possible to do this automatically and it is maybe not
| unlike the optimisation done by simplCore/LiberateCase.
I agree with your example. But I think the way to handle
it is this. Suppose we have
f x y = ....(f ex (C a b))...
where C is a constructor, and where y is scrutinised by a
case expression somewhere in f's body. Then, in this recursive
call to f, we know what y will be, and we could save the case in
the recursive call. So make a specialised version of f, thus:
fs x a b = let y = C a b in (...original body of f...)
Now add a RULE to f, saying
f x (C a b) ===> fs x a b
This is very much the way type specialisation works. Now every
call to f that has a (C a b) argument will benefit. Including
the recursive call to f in fs's RHS, so fs will become the self-recursive
tight loop you want, leaving f as a sort of 'impedence matcher' for
callers elsewhere.
I'll try to find time to implement this.
Simon
From rrt1001@cam.ac.uk Mon Dec 18 13:00:28 2000
Date: Mon, 18 Dec 2000 13:00:28 +0000 (GMT)
From: Reuben Thomas rrt1001@cam.ac.uk
Subject: Having to use -static flag under Win32 with 4.08 & Cygwin 1.1.6
> From: Jeremy Shute [mailto:shutej@rpi.edu]
> I've been perusing the documentation looking for what I've done wrong...
Nothing; the docs aren't quite up-to-date.
> 7. Confirmed that these files exist nowhere on the partition. Messed
> around some more to no avail, came across static flag and tried that:
We don't supply the DLLs any more, because they subtly and rarely don't work
for reasons I don't fully understand (though I've spent a long time trying
to). If you really want them (why?) you'll have to build them.
--
http://sc3d.org/rrt/ | maximiste, n. pessimiste
From simonmar@microsoft.com Wed Dec 20 17:46:25 2000
Date: Wed, 20 Dec 2000 09:46:25 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: ANNOUNCE: Happy version 1.9
ANNOUNCING Happy 1.9 - The LALR(1) Parser Generator for Haskell
-----------------------------------------------------------------
I'm pleased to announce version 1.9 of Happy, the parser generator
system for Haskell. Changes in this version, relative to version 1.8
(the previous full release):
* A grammar may now contain several entry points, allowing
several parsers to share parts of the grammar.
* Some bugfixes.
Happy is available in source form, which can be compiled with GHC
version 4.xx (4.08.1 recommended), and we also provide binaries for
some architectures. The Happy homepage with links to the various
distributions lives at:
http://www.haskell.org/happy/
Please send any bug reports and comments to simonmar@microsoft.com.
From chak@cse.unsw.edu.au Thu Dec 21 11:40:02 2000
Date: Thu, 21 Dec 2000 22:40:02 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: ANNOUNCE: Happy version 1.9
Simon Marlow <simonmar@microsoft.com> wrote,
> ANNOUNCING Happy 1.9 - The LALR(1) Parser Generator for Haskell
> -----------------------------------------------------------------
A RedHat 7.0/i386 rpm package is available at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/happy-1.9-1.i386.rpm
and the matching source rpm at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/happy-1.9-1.src.rpm
Happy Hacking,
Manuel
From simonmar@microsoft.com Thu Dec 21 11:48:09 2000
Date: Thu, 21 Dec 2000 03:48:09 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: The Set type
George Russell wrote:
> A minor quibble I know, but every time I use sets I want to
> add/subtract single elements
> to/from them. There is no function provided for doing this,
> so instead you have to do
> union/delete with a singleton set constructed from the
> element.
Done. Set now has
addToSet :: Ord a => Set a -> a -> Set a
delFromSet :: Ord a => Set a -> a -> Set a
The names and argument order were chosen to be consistent with
FiniteMap, so don't complain :-)
Cheers,
Simon
From rrt1001@cam.ac.uk Thu Dec 21 11:58:42 2000
Date: Thu, 21 Dec 2000 11:58:42 +0000 (GMT)
From: Reuben Thomas rrt1001@cam.ac.uk
Subject: ANNOUNCE: Happy version 1.9
> ANNOUNCING Happy 1.9 - The LALR(1) Parser Generator for Haskell
> -----------------------------------------------------------------
A Windows InstallShield package is available at
http://www.haskell.org/happy/dist/1.9/happy-1-9.exe
--
http://sc3d.org/rrt/ | egrep, n. a bird that debugs bison
From Dominic.J.Steinitz@BritishAirways.com Thu Dec 21 16:30:55 2000
Date: 21 Dec 2000 16:30:55 Z
From: Steinitz, Dominic J Dominic.J.Steinitz@BritishAirways.com
Subject: GHC Command Line Help
I was experimenting with using FiniteMap. The program compiled ok but the linker gave me the following error. What do I need to include on the command line or have I not installed ghc correctly?
[dom@lhrtba8fd85 FiniteMap]$ /usr/bin/ghc -o main test.o -L/usr/lib/ghc-4.08.1 -
lHSlang -lHSdata
/usr/lib/ghc-4.08.1/libHSdata.a(FiniteMap__1.o): In function `__init_FiniteMap':
FiniteMap__1.o(.text+0x16): undefined reference to `__init_GlaExts'
collect2: ld returned 1 exit status
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From Dominic.J.Steinitz@BritishAirways.com Thu Dec 21 16:35:18 2000
Date: 21 Dec 2000 16:35:18 Z
From: Steinitz, Dominic J Dominic.J.Steinitz@BritishAirways.com
Subject: GHC Command Line Help
Sorry. It's obviously -fglasgow-exts. I didn't realise it did things at the linking stage as well as the compilation stage.
Dominic Steinitz
21/12/2000 16:30:15
To: glasgow-haskell-users
cc: Chris.Reade
djrussell
B.Avery
dominic
molyneux
bcc:
Subject: GHC Command Line Help
I was experimenting with using FiniteMap. The program compiled ok but the linker gave me the following error. What do I need to include on the command line or have I not installed ghc correctly?
[dom@lhrtba8fd85 FiniteMap]$ /usr/bin/ghc -o main test.o -L/usr/lib/ghc-4.08.1 -
lHSlang -lHSdata
/usr/lib/ghc-4.08.1/libHSdata.a(FiniteMap__1.o): In function `__init_FiniteMap':
FiniteMap__1.o(.text+0x16): undefined reference to `__init_GlaExts'
collect2: ld returned 1 exit status
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From ger@tzi.de Thu Dec 21 16:41:25 2000
Date: Thu, 21 Dec 2000 17:41:25 +0100
From: George Russell ger@tzi.de
Subject: GHC Command Line Help
"Steinitz, Dominic J" wrote:
>
> I was experimenting with using FiniteMap. The program compiled ok but the linker gave me the following error. What do I need to include on the command line or have I not installed ghc correctly?
>
> [dom@lhrtba8fd85 FiniteMap]$ /usr/bin/ghc -o main test.o -L/usr/lib/ghc-4.08.1 -
> lHSlang -lHSdata
> /usr/lib/ghc-4.08.1/libHSdata.a(FiniteMap__1.o): In function `__init_FiniteMap':
> FiniteMap__1.o(.text+0x16): undefined reference to `__init_GlaExts'
> collect2: ld returned 1 exit status
I suggest using
/usr/bin/ghc -o main test.o -package data -package lang -fglasgow-exts
or something similar (rather than trying to name the libraries directly).
From ger@tzi.de Thu Dec 21 16:54:12 2000
Date: Thu, 21 Dec 2000 17:54:12 +0100
From: George Russell ger@tzi.de
Subject: Generic Classes?
Are Generic classes going to be in 4.08.2, and if not when are they likely
to be in a binary release? I have a potential application, though
I can manage without them for the time being.
From chak@cse.unsw.edu.au Fri Dec 22 06:13:07 2000
Date: Fri, 22 Dec 2000 17:13:07 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Fun with GHC's optimiser
Simon,
> But I think the way to handle
> it is this. Suppose we have
>
> f x y = ....(f ex (C a b))...
>
> where C is a constructor, and where y is scrutinised by a
> case expression somewhere in f's body. Then, in this recursive
> call to f, we know what y will be, and we could save the case in
> the recursive call. So make a specialised version of f, thus:
>
> fs x a b = let y = C a b in (...original body of f...)
>
> Now add a RULE to f, saying
>
> f x (C a b) ===> fs x a b
>
> This is very much the way type specialisation works. Now every
> call to f that has a (C a b) argument will benefit. Including
> the recursive call to f in fs's RHS, so fs will become the self-recursive
> tight loop you want, leaving f as a sort of 'impedence matcher' for
> callers elsewhere.
Sounds like a good idea to me :-)
Cheers,
Manuel
From chak@cse.unsw.edu.au Mon Dec 25 11:11:02 2000
Date: Mon, 25 Dec 2000 22:11:02 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: GHC thinks it is smarter than me [was: RE: Transitive inlining]
Simon Peyton-Jones <simonpj@microsoft.com> wrote,
> Yes, all the inlining you expect should indeed happen. If
> it doesn't can you show us an example?
Meanwhile, I think, the lack of inlining that I saw isn't
connected to modules. Instead, the problem is that GHC
thinks it knows more about my program than I do. More
precisely, it seems to take an INLINE pragma just as an
encouragement rather than a command to inline. In
particular - at least if a function is large enough - it
doesn't inline the function anymore if the function is used
more than once.[1]
This behaviour is a problem for our array library. We need
very aggressive inlining. Would it maybe be possible to
make -O2 interpret INLINE pragmas as obligatory?
Cheers,
Manuel
[1] The function in question actually uses an INLINE 2
pragma - I guess that this doesn't matter.
From chak@cse.unsw.edu.au Mon Dec 25 12:25:15 2000
Date: Mon, 25 Dec 2000 23:25:15 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: GHC thinks it is smarter than me [was: RE: Transitive inlining]
"Manuel M. T. Chakravarty" <chak@cse.unsw.edu.au> wrote,
> Meanwhile, I think, the lack of inlining that I saw isn't
> connected to modules. Instead, the problem is that GHC
> thinks it knows more about my program than I do. More
> precisely, it seems to take an INLINE pragma just as an
> encouragement rather than a command to inline. In
> particular - at least if a function is large enough - it
> doesn't inline the function anymore if the function is used
> more than once.[1]
Actually, the current behaviour - at least, as I understand
it - in combination with modules leads IMHO to rather
inconsistent behaviour. Given a module
module M (foo)
where
{#- INLINE foo #-}
foo = <biggish definition>
GHC will not inline `foo' in
module Main
where
import M
bar = ...foo a...
main = ...foo b...bar...
However, it will inline foo twice in case of
module N (bar)
where
import N
bar = ...foo a...
module Main
where
import M
import N
main = ...foo b...bar...
although it is exactly the same code. In other words, using
many modules leads to larger binaries and faster code.
All this is understandable given that optimisation always
included heuristics. However, for programmer supplied
annotations, I think, it is problematic.
Cheers,
Manuel
From chak@cse.unsw.edu.au Sat Dec 30 13:56:38 2000
Date: Sun, 31 Dec 2000 00:56:38 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: GHC thinks it is smarter than me [was: RE: Transitive inlining]
"Manuel M. T. Chakravarty" <chak@cse.unsw.edu.au> wrote,
[..]
> In
> particular - at least if a function is large enough - it
> doesn't inline the function anymore if the function is used
> more than once.
Moreover, I am wondering which the exact conditions are
under which NOINLINE pragmas are ignored by the compiler.
It seems at least always to be ignored in code like
{-# NOINLINE foo #-}
foo = <some code>
bar .. = ..foo..
If that is the only occurence of `foo', inlining is
certainly always save, but on the other hand if I take the
trouble to add a NOINLINE pragma, I actually mean it. For
example, I sometimes want to see what Core code is produced
for <some code> using -ddump-simpl. The compiler can't know
that, so IMHO it should better just follow my instructions,
instead of trying to be extra smart.
Cheers,
Manuel
From chak@cse.unsw.edu.au Sat Dec 30 07:58:28 2000
Date: Sat, 30 Dec 2000 18:58:28 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: RULES and unfolding
Is there any heuristic in GHC that discourages putting
unfoldings of functions into .hi files if the function
occurs on the right handside of a RULES rule?
I have code, where this seems to be the case. When I remove
the rewrite rule, the function is placed into the .hi file,
but with the rewrite rule, it isn't - despite an INLINE
pragma for that function! Unfortunately, the example is
rather big and I didn't manage to find a small piece of code
showing the same behaviour yet.
This currently bites me in a rule of the form
{-# "" forall ... foo .. bar .. = foobar .. #-}
{-# INLINE foobar #-}
foobar .. = ...
where I want foobar inlined.
Cheers,
Manuel
PS: I do this only because GHC crashes when I place the rhs
of the foobar definition directly into the rhs of the
rule, but again I don't have a small example producing
the bug *sigh*
From chak@cse.unsw.edu.au Sat Dec 30 01:06:25 2000
Date: Sat, 30 Dec 2000 12:06:25 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Lambda dropping in loops
Given a function like
fill 0# mpa = return ()
fill i# mpa = do
let i'# = i# -# 1#
writeMP mpa (I# i'#) e
fill i'# mpa
it would be nice if GHC were to lambda drop it (on the core
level) into
fill i# mpa = fill' i#
where
fill' 0# = return ()
fill' i# = do
let i'# = i# -# 1#
writeMP mpa (I# i'#) e
fill' i'#
as this allows it to subsequently apply the new case
liberation optimisation. By performing the lambda dropping
manually, I have gotten much better code in some performance
sensitive definitions.
Cheers,
Manuel
From simonpj@microsoft.com Sat Dec 30 17:02:55 2000
Date: Sat, 30 Dec 2000 09:02:55 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Generic Classes?
No, not in 4.08.2.
They'll be in our first release of GHCi.
I'm not sure when that will be; Feb I expect.
Simon
| -----Original Message-----
| From: George Russell [mailto:ger@tzi.de]
| Sent: 21 December 2000 16:54
| To: glasgow-haskell-users@haskell.org
| Subject: Generic Classes?
|
|
| Are Generic classes going to be in 4.08.2, and if not when
| are they likely
| to be in a binary release? I have a potential application, though
| I can manage without them for the time being.
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From qrczak@knm.org.pl Sat Dec 30 18:12:48 2000
Date: 30 Dec 2000 18:12:48 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Generic Classes?
Sat, 30 Dec 2000 09:02:55 -0800, Simon Peyton-Jones <simonpj@microsoft.com> pisze:
> They'll be in our first release of GHCi.
What about my old comments about distinguishing "the rest of
constructors" from "contents of the constructor we found", and
"the rest of fields" from "contents of the field we are considering"?
IMHO the current state is wrong. Generic instances should not
*require* that operations are directly propagated to arguements of
constructors and values of fields. What happens when we are on the
level of finding a constructor should be separated from what happens
when we are looking inside its fields. And dually, combining fields
should be separated from looking at the value of a field.
It's simple to fix, modulo performance issues. I consider the fixed
version a very good and usable solution, and the current version an
unusable partially flawed design...
It should be possible to rewrite classes which are derivable now
to use the generic mechanism instead of ad-hockery in the compiler.
Bit it will be possible only after the design is fixed not to confuse
constructors and their arguments, and not to confuse sets of fields
and their contents.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From Sven.Panne@informatik.uni-muenchen.de Sat Dec 30 22:09:01 2000
Date: Sat, 30 Dec 2000 23:09:01 +0100
From: Sven Panne Sven.Panne@informatik.uni-muenchen.de
Subject: Realtime-GC
IIRC there was some activity in the realtime GC area
for GHC (something like experimental support for 4.0x,
but I can't remember exactly). Any progress yet? It
would be quite cool to fly through Quake levels without
those small hiccups. And I'm quite sure there are more
serious applications which would profit from that, too... :-)
Cheers,
Sven
From ger@Informatik.Uni-Bremen.DE Mon Dec 4 16:09:36 2000
From: ger@Informatik.Uni-Bremen.DE (George Russell)
Date: Mon, 04 Dec 2000 17:09:36 +0100
Subject: The Set type
Message-ID: <3A2BC1C0.E7B0A6B0@informatik.uni-bremen.de>
A minor quibble I know, but every time I use sets I want to add/subtract single elements
to/from them. There is no function provided for doing this, so instead you have to do
union/delete with a singleton set constructed from the element. I appreciate the zeal
of the designer of this module to construct the smallest possible interface (I wish the
same person had designed the standard Prelude) but I think this zeal is overdone.
You do often need to operate with single elements. After all, if you wanted real
hair-shirt minimalism you should get rid of "elementOf" (replace it by
\el set -> isEmptySet (intersect set (singletonSet el)), but no-one would seriously
suggest that - I hope.
From ger@Informatik.Uni-Bremen.DE Mon Dec 4 16:17:42 2000
From: ger@Informatik.Uni-Bremen.DE (George Russell)
Date: Mon, 04 Dec 2000 17:17:42 +0100
Subject: Or-patterns
Message-ID: <3A2BC3A6.234543E7@informatik.uni-bremen.de>
Why not steal a good idea from Standard ML/New Jersey now and again? This has
"Or-patterns" which allow you to match against a disjunction of patterns,
EG
fun sleepIn (Date.Sat | Date.Sun) = true
| sleepIn _ = false
Where you have variables in the patterns, you bind only the variables which appear
in all the patterns, and you unify the types accordingly.
Of course you can do without this feature, but I feel it shouldn't be too hard
to implement and for me at least it would be occasionally useful.
From simonpj@microsoft.com Wed Dec 6 15:15:29 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 6 Dec 2000 07:15:29 -0800
Subject: Or-patterns
Message-ID: <74096918BE6FD94B9068105F877C002D013781F9@red-pt-02.redmond.corp.microsoft.com>
Sensible suggestion
No technical problem, just one more thing to do.
If anyone feels inclined to implement it I'll gladly incorporate
the fruits of their labours in the GHC code base.
Simon
| -----Original Message-----
| From: George Russell [mailto:ger@Informatik.Uni-Bremen.DE]
| Sent: 04 December 2000 16:18
| To: glasgow-haskell-users@haskell.org
| Subject: Or-patterns
|
|
| Why not steal a good idea from Standard ML/New Jersey now and
| again? This has
| "Or-patterns" which allow you to match against a disjunction
| of patterns,
| EG
|
| fun sleepIn (Date.Sat | Date.Sun) = true
| | sleepIn _ = false
|
| Where you have variables in the patterns, you bind only the
| variables which appear
| in all the patterns, and you unify the types accordingly.
|
| Of course you can do without this feature, but I feel it
| shouldn't be too hard
| to implement and for me at least it would be occasionally useful.
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From qrczak@knm.org.pl Wed Dec 6 21:08:06 2000
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 6 Dec 2000 21:08:06 GMT
Subject: Or-patterns
References: <3A2BC3A6.234543E7@informatik.uni-bremen.de>
Message-ID:
Mon, 04 Dec 2000 17:17:42 +0100, George Russell pisze:
> Where you have variables in the patterns, you bind only the
> variables which appear in all the patterns, and you unify the
> types accordingly.
Or bind them all (otherwise there would be _ written) and get bottom
in case the matching subpattern did not bind the given variable.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From christian@lescher.de Thu Dec 7 07:35:12 2000
From: christian@lescher.de (Christian Lescher)
Date: Thu, 07 Dec 2000 08:35:12 +0100
Subject: New InstallShield: no more DLLs
References: <3A23FDA3.A994B660@lescher.de>
Message-ID: <3A2F3DAF.ADDD9741@lescher.de>
Hi Reuben,
> Besides, I've got some (not so fortunate) news: even after updating binutils and the
> whole cygwin to the latest version, the problem with *statically* linked and
> afterwards stripped DLLs build with GHC remains - the unstripped version works well,
> but the stripped one crashes in some constellations. I will try to make this error
> reproducable and let you know about it. Something is still wrong here - probably with
> cygwin. Maybe this has also got something to do with the dyn. linking problem?
There are some strange things happening that I'm still astonished about. I decided just
to write them down again - perhaps it may help to discover the error of the linking
problem.
As you know, I made some trials with a statically linked DLL build with GHC4.08.1 and the
latest cygwin.
a) When leaving debug information as it is, everything works fine - in all environments I
tested it on (WinNT, Win95; VBA, Delphi, VB - I had no possibility to test it on Win2K
yet).
b) When STRIP-ping away the debug information, the DLL on all PCs I tried it on works
fine with VB and Delphi - but when using it in VBA, it on some PCs crashes when the DLL
is loaded (the loading happens automatically when calling a Haskell function for the
first time) - this also looks like a problem during DLL initialization, it seems as if
DllMain is not even entered.
Did you already try out a statically linked, stripped DLL on Win2K? Do you get the same
error? (If the origin of the error is the same DLL initialization problem as in the
linking problem with EXEs, it may be easier to handle in a hell of a single DLL ...)
Some more strange things occured with the small program we had with catchAllIO / the "hi"
output:
I compiled it in both ways with and without the "-static" option and sent the EXE
binaries to Arjan van Ijzendoorn (who reported the error).
a) When running the EXEs on my PC (Win95), both the statically and the dynamically linked
EXE work well (output: "hi").
b) The same EXE on A.v.I.'s PC with Win2K produced the "famous" application error.
Do you have some idea what's wrong here?
Cheers, Christian
From stolz@I2.Informatik.RWTH-Aachen.DE Thu Dec 7 10:56:09 2000
From: stolz@I2.Informatik.RWTH-Aachen.DE (Volker Stolz)
Date: Thu, 7 Dec 2000 11:56:09 +0100
Subject: Anyone using SocketPrim.getSocketName?
Message-ID: <20001207115609.A3979@agamemnon.informatik.rwth-aachen.de>
Is anyone using SocketPrimt.getSocketName?
I try to get the IP of a listening socket (on my side), but
I always get 0. It could be either my fault, SocketPrims fault
(the source is prefilling the buffer with 0!), or the
conversion-functions fault:
> sAddr <- SocketPrim.getSocketName (s#socket)
> local <- case sAddr of
> (SocketPrim.SockAddrInet port host) -> do
> return (show (wordToWord32 host))
> _ -> net#getHostName -- XXX output a warning
> print local
"host" is of type Word, so I need a way of getting it into a string.
host should be 4x8 bit and thus Word32 is the right thing to use?
--
\usepackage[latin1]{inputenc}!
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From stolz@I2.Informatik.RWTH-Aachen.DE Thu Dec 7 12:19:53 2000
From: stolz@I2.Informatik.RWTH-Aachen.DE (Volker Stolz)
Date: Thu, 7 Dec 2000 13:19:53 +0100
Subject: Anyone using SocketPrim.getSocketName?
In-Reply-To: <20001207115609.A3979@agamemnon.informatik.rwth-aachen.de>; from stolz@I2.Informatik.RWTH-Aachen.DE on Thu, Dec 07, 2000 at 11:56:09AM +0100
References: <20001207115609.A3979@agamemnon.informatik.rwth-aachen.de>
Message-ID: <20001207131953.A4744@agamemnon.informatik.rwth-aachen.de>
Am 07. Dec 2000 um 11:56 MET schrieb Volker Stolz:
> Is anyone using SocketPrimt.getSocketName?
> I try to get the IP of a listening socket (on my side), but
> I always get 0. It could be either my fault, SocketPrims fault
> (the source is prefilling the buffer with 0!), or the
> conversion-functions fault:
Okay, I can construct cases where I get what I want. It seems to
depend on the OS; the SocketPrim implementation works.
--
\usepackage[latin1]{inputenc}!
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From simonpj@microsoft.com Thu Dec 7 17:17:44 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Thu, 7 Dec 2000 09:17:44 -0800
Subject: Fun with GHC's optimiser
Message-ID: <74096918BE6FD94B9068105F877C002D01378231@red-pt-02.redmond.corp.microsoft.com>
Manuel
OK, I've improved the eta expander so it does a better
job of the code you found.
Try now. On the HEAD. Which should compile OK now, incidentally.
How's your parallel Haskell stuff coming?
Simon
| -----Original Message-----
| From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au]
| Sent: 02 November 2000 13:54
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: RE: Fun with GHC's optimiser
|
|
| Simon Peyton-Jones wrote,
|
| > I can never resist messages like these, even when I'm meant
| > to be doing other things.
|
| That's good to know ;-)
|
| > It's very helpful when people offer
| > fairly precise performance-bug reports. Thanks!
|
| Thanks for the prompt reply! To SimonM, too.
|
| > | I am wondering whether there is a particular reason why the
| > | optimiser doesn't pull the
| > |
| > | (1) a = NO_CCS PArray! [wild1 mba#];
| >
| > This one is a definite bug. It turns out that the head of the
| > before-ghci-branch doesn't have this bug, so I'm disinclined
| > to investigate it further.
|
| No problem, I can always build a new ghc from CVS.
|
| > | (2) case w of wild3 {
| > | I# e# ->
| > |
| > | As for (2), the loop would be nice and straight if that
| > | unboxing where outside of the loop - as it is, we break the
| > | pipeline once per iteration it seems
| >
| > This one is a bit harder. Basically we want to make a wrapper
| > for a recursive function if it's sure to evaluate its free
| variables.
| >
| > In fact the 'liberate-case' pass (which isn't switched on in 4.08)
| > is meant to do just this. It's in simplCore/LiberateCase.lhs,
| > and it's not very complicated. I've just tried it and it
| doesn't seem
| > to have the desired effect, but I'm sure that's for a boring reason.
| > If anyone would like to fix it, go ahead!
|
| Ok - something for a rainy weekend, I guess...
|
| > Incidentally, you'll find that -ddump-simpl gives you a dump that
| > is pretty close to STG and usually much more readable. Most
| > performance bugs show up there. -dverbose-simpl gives you more
| > clues about what is happening where.
|
| Good to know. I just wasn't sure whether I wouldn't miss
| out on some optimisations.
|
| > | Also if somebody is looking at the attached source, I was
| > | wondering why, when I use the commented out code in
| > | `newPArray', I get a lot worse code (the STG code is in a
| > | comment at the end of the file). In particular, the lambda
| > | abstraction is not inlined, whereas `fill' gets inlined into
| > | the code of which the dump is above. Is it because the
| > | compiler has a lot harder time with explicit recursion than
| > | with fold/build? If so, the right RULES magic should allow
| > | me to do the same for my own recursively defined
| > | combinators, shouldn't it?
| >
| > I couldn't figure out exactly what you meant. The only commented
| > out code is STG code. Maybe send a module with the actual
| > source you are bothered about.
|
| Appended the version of the module where the code is
| activated (it was commented out with --) - you'll find the
| problematic code by searching for (**) in the code. It
| generates
|
| $w$snewPArray
| = \ ww :: Int# w :: Int ->
| case newIntArray# @ RealWorld ww realWorld#
| of wild { (# s2#, mba# #) ->
| case $wsimpleGen
| ww
| (\ i :: Int ->
| case i of wild1 { I# i# ->
| case w of wild2 { I# e# ->
| __coerce (ST RealWorld ())
| (\ s# :: (State# RealWorld) ->
| case writeIntArray# @ RealWorld mba# i# e# s#
| of s2#1 { __DEFAULT ->
| (# s2#1, () #)
| })
| }
| })
| s2#
| of wild1 { (# new_s, r #) ->
| let {
| a :: Int
| a = $wI# ww
| } in (# a, (__coerce ByteArray# mba#) #)
| }
| }
|
| One thing that is not nice is in the lambda abstraction
| based to $wsimpleGen. There is one lambda, then two
| unboxing operations and another lambda for the state
| variables s#. These two nested lambda's become in STG
|
| stg_c1Op =
| NO_CCS[] \r[i]
| case i of wild1 {
| I# i# ->
| case w of wild2 {
| I# e# ->
| let {
| stg_c1Sv =
| NO_CCS[] \r[s#]
| case
| writeIntArray# [mba# i# e# s#] of s2#1 {
| DEFAULT ->
| (#,#) [s2#1 ()]
| };
| } in stg_c1Sv;
| };
| };
|
| So, stg_c1Sv is allocated and immediately entered. I would
| have hoped that the two lambda abstractions are merged into
| something like this:
|
| (\ i :: Int s# :: (State# RealWorld) ->
| case i of wild1 { I# i# ->
| case w of wild2 { I# e# ->
| case writeIntArray# @ RealWorld mba# i# e# s#
| of s2#1 { __DEFAULT -> (# s2#1, () #)
| })
| }
| })
|
| Maybe it is the __coerce, which prevents this from
| happening?
|
| Also, I am wondering why in the case of the
|
| foldr (fill mpa e) (return $ unsafeFreezeMPArray mpa) [0..n-1])
|
| the function `fill' gets inlined into the foldr loop, but in
| the above, the lambda abstraction gets not inlined into
| $wsimpleGen. Maybe it is because $wsimpleGen itself gets
| not inlined...
|
| Cheers,
| Manuel
|
From dirk@TechFak.Uni-Bielefeld.DE Thu Dec 7 18:39:35 2000
From: dirk@TechFak.Uni-Bielefeld.DE (Dirk Evers)
Date: Thu, 07 Dec 2000 19:39:35 +0100 (MET)
Subject: Beginners profiling question
Message-ID:
This message is in MIME format
--_=XFMail.1.3.p0.Solaris:001207193935:15881=_
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
So I have tried profiling the first time...
using ghc-4.08.1 with options -prof -auto-all
runtime option -px
ghcprof and daVinci work like a charm
what I see is
main uses 99.90 % time and space
sat for practical purposes is the only function called from main and
uses ca. 12 % time and space
what am I doing wrong...
Prelude not compiled for profiling?
Thanks in advance
Dirk
---
+---------------------------------------------------------------------+
| Dirk Evers Office: M3-120 |
| Technische Fakultaet / AG PI Tel: +49 521 106-2905 |
| Universitaet Bielefeld FAX: +49 521 106-6411 |
| D-33594 Bielefeld e-mail: dirk@TechFak.Uni-Bielefeld.DE |
| Germany URL: http://www.TechFak.Uni-Bielefeld.DE/~dirk/ |
|---------------------------------------------------------------------|
| Die Succulenten / a cappella singing / http://www.succulenten.de |
+---------------------------------------------------------------------+
--_=XFMail.1.3.p0.Solaris:001207193935:15881=_
Content-Disposition: attachment; filename="satdanglefold.prof"
Content-Transfer-Encoding: base64
Content-Description: satdanglefold.prof
Content-Type: application/octet-stream;
name=satdanglefold.prof; SizeOnDisk=10749
IlRodSBEZWMgIDcgMTk6MDkgMjAwMCIKIjIwIG1zIgoxIDE5NiAiQ0FGIiAiQ2hhciIKMSAxOTUg
IkNBRiIgIk51bWVyaWMiCjEgMTk0ICJ0c3RhY2tpX2RnIiAiRW5lcmd5IgoxIDE5MyAidHN0YWNr
aF9kZyIgIkVuZXJneSIKMSAxOTIgInRvcF9zdGFjayIgIkVuZXJneSIKMSAxOTEgInRlbXAiICJF
bmVyZ3kiCjEgMTkwICJ0IiAiRW5lcmd5IgoxIDE4OSAic3RhY2tfZGciICJFbmVyZ3kiCjEgMTg4
ICJzc19lbmVyZ3kiICJFbmVyZ3kiCjEgMTg3ICJzcl9lbmVyZ3kiICJFbmVyZ3kiCjEgMTg2ICJy
IiAiRW5lcmd5IgoxIDE4NSAibG9nX2ludGVycCIgIkVuZXJneSIKMSAxODQgImtlbHZpbiIgIkVu
ZXJneSIKMSAxODMgImlucHJlZ2lvbiIgIkVuZXJneSIKMSAxODIgImlsX3N0YWNrIiAiRW5lcmd5
IgoxIDE4MSAiaWxfZW50IiAiRW5lcmd5IgoxIDE4MCAiaWxfZW5lcmd5IiAiRW5lcmd5IgoxIDE3
OSAiaWxfYXN5bSIgIkVuZXJneSIKMSAxNzggImhsX3RldHJhIiAiRW5lcmd5IgoxIDE3NyAiaGxf
c3RhY2siICJFbmVyZ3kiCjEgMTc2ICJobF9lbnQiICJFbmVyZ3kiCjEgMTc1ICJobF9lbmVyZ3ki
ICJFbmVyZ3kiCjEgMTc0ICJlIiAiRW5lcmd5IgoxIDE3MyAiZHJfZW5lcmd5IiAiRW5lcmd5Igox
IDE3MiAiZHJfZGFuZ2xlX2RnIiAiRW5lcmd5IgoxIDE3MSAiZHJpX2VuZXJneSIgIkVuZXJneSIK
MSAxNzAgImRsX2VuZXJneSIgIkVuZXJneSIKMSAxNjkgImRsX2RhbmdsZV9kZyIgIkVuZXJneSIK
MSAxNjggImRsaV9lbmVyZ3kiICJFbmVyZ3kiCjEgMTY3ICJicl9lbmVyZ3kiICJFbmVyZ3kiCjEg
MTY2ICJib3Rfc3RhY2siICJFbmVyZ3kiCjEgMTY1ICJibF9lbnQiICJFbmVyZ3kiCjEgMTY0ICJi
bF9lbmVyZ3kiICJFbmVyZ3kiCjEgMTYzICJhc3ltIiAiRW5lcmd5IgoxIDE2MiAiQ0FGIiAiRW5l
cmd5IgoxIDE2MSAidkxUU1ZBIiAiRXhhbXBsZXMiCjEgMTYwICJ0cm5hIiAiRXhhbXBsZXMiCjEg
MTU5ICJzbFJOQSIgIkV4YW1wbGVzIgoxIDE1OCAiczE1bVJOQSIgIkV4YW1wbGVzIgoxIDE1NyAi
cDVhYmMiICJFeGFtcGxlcyIKMSAxNTYgImJzcF90ZXN0MSIgIkV4YW1wbGVzIgoxIDE1NSAiYnNw
X3Rlc3QiICJFeGFtcGxlcyIKMSAxNTQgImJzcF9uYyIgIkV4YW1wbGVzIgoxIDE1MyAiYnNwX21s
IiAiRXhhbXBsZXMiCjEgMTUyICJic3BfbGJsIiAiRXhhbXBsZXMiCjEgMTUxICJic3BfaWwiICJF
eGFtcGxlcyIKMSAxNTAgImJzcF9jaHJpc2IiICJFeGFtcGxlcyIKMSAxNDkgImJzcF9ibCIgIkV4
YW1wbGVzIgoxIDE0OCAiYnNwYSIgIkV4YW1wbGVzIgoxIDE0NyAiYnNwMSIgIkV4YW1wbGVzIgox
IDE0NiAiYnNwIiAiRXhhbXBsZXMiCjEgMTQ1ICJhdHRlbnVhdG9yIiAiRXhhbXBsZXMiCjEgMTQ0
ICJDQUYiICJFeGFtcGxlcyIKMSAxNDMgIkNBRiIgIk1heWJlIgoxIDE0MiAiQ0FGIiAiTGlzdCIK
MSAxNDEgInhfbWlucyIgIk1pbmltdW1zIgoxIDE0MCAieF9taW5pbXVtcyIgIk1pbmltdW1zIgox
IDEzOSAibWlucyIgIk1pbmltdW1zIgoxIDEzOCAibWluaW11bXMiICJNaW5pbXVtcyIKMSAxMzcg
ImVwc2VxIiAiTWluaW11bXMiCjEgMTM2ICJDQUYiICJNaW5pbXVtcyIKMSAxMzUgInRlc3QyZGIi
ICJPdXRwdXQiCjEgMTM0ICJmb3JtYXQiICJPdXRwdXQiCjEgMTMzICJkb3RicmFja2V0IiAiT3V0
cHV0IgoxIDEzMiAiQ0FGIiAiT3V0cHV0IgoxIDEzMSAiQ0FGIiAiSXgiCjEgMTMwICJDQUYiICJB
cnJheSIKMSAxMjkgIn5+fiIgIkNvbWJpbmF0b3IiCjEgMTI4ICJ+fisiICJDb21iaW5hdG9yIgox
IDEyNyAifn4iICJDb21iaW5hdG9yIgoxIDEyNiAiK35+IiAiQ29tYmluYXRvciIKMSAxMjUgIisr
fiIgIkNvbWJpbmF0b3IiCjEgMTI0ICIrKysiICJDb21iaW5hdG9yIgoxIDEyMyAiPCsrKz4iICJD
b21iaW5hdG9yIgoxIDEyMiAiPCsrPiIgIkNvbWJpbmF0b3IiCjEgMTIxICI8Kys9PiIgIkNvbWJp
bmF0b3IiCjEgMTIwICI8KzwiICJDb21iaW5hdG9yIgoxIDExOSAiPCs9Kz4iICJDb21iaW5hdG9y
IgoxIDExOCAiPCs9PiIgIkNvbWJpbmF0b3IiCjEgMTE3ICI8Kz09PiIgIkNvbWJpbmF0b3IiCjEg
MTE2ICI8PDwiICJDb21iaW5hdG9yIgoxIDExNSAiPD0rKz4iICJDb21iaW5hdG9yIgoxIDExNCAi
PD0rPiIgIkNvbWJpbmF0b3IiCjEgMTEzICI8PSs9PiIgIkNvbWJpbmF0b3IiCjEgMTEyICI8PT0r
PiIgIkNvbWJpbmF0b3IiCjEgMTExICI8PT0+IiAiQ29tYmluYXRvciIKMSAxMTAgIi4uLiIgIkNv
bWJpbmF0b3IiCjEgMTA5ICI+Pj4iICJDb21iaW5hdG9yIgoxIDEwOCAifHx8IiAiQ29tYmluYXRv
ciIKMSAxMDcgIndpdGhpbiIgIkNvbWJpbmF0b3IiCjEgMTA2ICJ3aXRoIiAiQ29tYmluYXRvciIK
MSAxMDUgInRvYXJyYXkiICJDb21iaW5hdG9yIgoxIDEwNCAidGFibGUxIiAiQ29tYmluYXRvciIK
MSAxMDMgInRhYmxlIiAiQ29tYmluYXRvciIKMSAxMDIgInN1Y2h0aGF0IiAiQ29tYmluYXRvciIK
MSAxMDEgInNpemVvZiIgIkNvbWJpbmF0b3IiCjEgMTAwICJxIiAiQ29tYmluYXRvciIKMSA5OSAi
cCIgIkNvbWJpbmF0b3IiCjEgOTggImNvbWJpbmU0IiAiQ29tYmluYXRvciIKMSA5NyAiY29tYmlu
ZTMiICJDb21iaW5hdG9yIgoxIDk2ICJjb21iaW5lIiAiQ29tYmluYXRvciIKMSA5NSAiYXhpb20i
ICJDb21iaW5hdG9yIgoxIDk0ICJhdGFibGUiICJDb21iaW5hdG9yIgoxIDkzICJhcCIgIkNvbWJp
bmF0b3IiCjEgOTIgIkNBRiIgIkNvbWJpbmF0b3IiCjEgOTEgInRhZzJjb25fRWJhc2UjIiAiUm5h
SSIKMSA5MCAic3RyMmlucCIgIlJuYUkiCjEgODkgInJuYSIgIlJuYUkiCjEgODggInBhaXIiICJS
bmFJIgoxIDg3ICJudWMiICJSbmFJIgoxIDg2ICJub2Jhc2VwYWlyIiAiUm5hSSIKMSA4NSAibWlu
bG9vcHNpemUiICJSbmFJIgoxIDg0ICJtYXh0YWdfRWJhc2UjIiAiUm5hSSIKMSA4MyAiY29uMnRh
Z19FYmFzZSMiICJSbmFJIgoxIDgyICJjb24ydGFnX0NvbXBvbmVudCMiICJSbmFJIgoxIDgxICJj
b24ydGFnX0NvbXBvbmVudEUjIiAiUm5hSSIKMSA4MCAiYmFzZXBhaXIiICJSbmFJIgoxIDc5ICJD
QUYiICJSbmFJIgoxIDc4ICJDQUYiICJTeXN0ZW0iCjEgNzcgInVsIiAiTWFpbiIKMSA3NiAic3Ry
aXAiICJNYWluIgoxIDc1ICJzdHIiICJNYWluIgoxIDc0ICJzdGFja3BhaXJpbmciICJNYWluIgox
IDczICJzciIgIk1haW4iCjEgNzIgInNhdGhsIiAiTWFpbiIKMSA3MSAic2F0IiAiTWFpbiIKMSA3
MCAic2FkZCIgIk1haW4iCjEgNjkgInJtZGFuZ2xlIiAiTWFpbiIKMSA2OCAicmVzZXRBdHRyIiAi
TWFpbiIKMSA2NyAicmVnaW9uIiAiTWFpbiIKMSA2NiAicmRhbmdsZSIgIk1haW4iCjEgNjUgIm5v
cGFpcndpdGhpbnN0YWNrIiAiTWFpbiIKMSA2NCAibWwiICJNYWluIgoxIDYzICJtaW5zaXplIiAi
TWFpbiIKMSA2MiAibWluQXR0ciIgIk1haW4iCjEgNjEgIm1haW4iICJNYWluIgoxIDYwICJsbWRh
bmdsZSIgIk1haW4iCjEgNTkgImxkYW5nbGUiICJNYWluIgoxIDU4ICJpbmNBdHRyIiAiTWFpbiIK
MSA1NyAiaWx4IiAiTWFpbiIKMSA1NiAiaWxzIiAiTWFpbiIKMSA1NSAiaWxyIiAiTWFpbiIKMSA1
NCAiaWxuIiAiTWFpbiIKMSA1MyAiaWxsIiAiTWFpbiIKMSA1MiAiaF9zIiAiTWFpbiIKMSA1MSAi
aF9sIiAiTWFpbiIKMSA1MCAiaF9rIiAiTWFpbiIKMSA0OSAiaF9pIiAiTWFpbiIKMSA0OCAiaGwi
ICJNYWluIgoxIDQ3ICJoIiAiTWFpbiIKMSA0NiAiZmxhZ1RydWUiICJNYWluIgoxIDQ1ICJmbGFn
RmFsc2UiICJNYWluIgoxIDQ0ICJldWwiICJNYWluIgoxIDQzICJlc2FkZCIgIk1haW4iCjEgNDIg
ImVtcHR5IiAiTWFpbiIKMSA0MSAiZWNhZGQiICJNYWluIgoxIDQwICJkbmlsIiAiTWFpbiIKMSAz
OSAiZGFuZ2xlIiAiTWFpbiIKMSAzOCAiY29uMnRhZ19EbGlzdCMiICJNYWluIgoxIDM3ICJjYWRk
IiAiTWFpbiIKMSAzNiAiYnIiICJNYWluIgoxIDM1ICJibCIgIk1haW4iCjEgMzQgImJhc2UiICJN
YWluIgoxIDMzICJDQUYiICJNYWluIgoxIDMyICJDQUYiICJQcmVsQ29uYyIKMSAzMSAiQ0FGIiAi
UHJlbEZvcmVpZ24iCjEgMzAgIkNBRiIgIlByZWxXZWFrIgoxIDI5ICJDQUYiICJQcmVsSGFuZGxl
IgoxIDI4ICJDQUYiICJQcmVsSU8iCjEgMjcgIkNBRiIgIlByZWxSZWFkIgoxIDI2ICJDQUYiICJQ
cmVsRHluYW1pYyIKMSAyNSAiQ0FGIiAiUHJlbEFkZHIiCjEgMjQgIkNBRiIgIlByZWxBcnIiCjEg
MjMgIkNBRiIgIlByZWxSZWFsIgoxIDIyICJDQUYiICJQcmVsRmxvYXQiCjEgMjEgIkNBRiIgIlBy
ZWxCeXRlQXJyIgoxIDIwICJDQUYiICJQcmVsUGFjayIKMSAxOSAiQ0FGIiAiUHJlbElPQmFzZSIK
MSAxOCAiQ0FGIiAiUHJlbFNUIgoxIDE3ICJDQUYiICJQcmVsRXhjZXB0aW9uIgoxIDE2ICJDQUYi
ICJQcmVsRW51bSIKMSAxNSAiQ0FGIiAiUHJlbFNob3ciCjEgMTQgIkNBRiIgIlByZWxOdW0iCjEg
MTMgIkNBRiIgIlByZWxCYXNlIgoxIDEyICJDQUYiICJQcmVsTWF5YmUiCjEgMTEgIkNBRiIgIlBy
ZWxMaXN0IgoxIDEwICJDQUYiICJQcmVsRXJyIgoxIDkgIkNBRiIgIlByZWxUdXAiCjEgOCAiQ0FG
IiAiUHJlbHVkZSIKMSA3ICJDQUYiICJQcmVsTWFpbiIKMSA2ICJET05UX0NBUkUiICJNQUlOIgox
IDUgIlNVQlNVTUVEIiAiTUFJTiIKMSA0ICJPVkVSSEVBRF9vZiIgIlBST0ZJTElORyIKMSAzICJH
QyIgIkdDIgoxIDIgIlNZU1RFTSIgIk1BSU4iCjEgMSAiTUFJTiIgIk1BSU4iCjIgMSAxIDEKMiA0
NyAyIDE5NiAxCjIgNDggMiAxOTUgMQoyIDQ5IDIgMTYyIDEKMiA1MCAyIDE0NCAxCjIgNTEgMiAx
NDMgMQoyIDUyIDIgMTQyIDEKMiA1MyAyIDEzNiAxCjIgNTQgMiAxMzIgMQoyIDU1IDIgMTMxIDEK
MiA1NiAyIDEzMCAxCjIgNTcgMiA5MiAxCjIgNTggMiA3OSAxCjIgNTkgMiA3OCAxCjIgNjAgMiAz
MyAxCjIgNjEgMiAzMiAxCjIgNjIgMiAzMSAxCjIgNjMgMiAzMCAxCjIgNjQgMiAyOSAxCjIgNjUg
MiAyOCAxCjIgNjYgMiAyNyAxCjIgNjcgMiAyNiAxCjIgNjggMiAyNSAxCjIgNjkgMiAyNCAxCjIg
NzAgMiAyMyAxCjIgNzEgMiAyMiAxCjIgNzIgMiAyMSAxCjIgNzMgMiAyMCAxCjIgNzQgMiAxOSAx
CjIgNzUgMiAxOCAxCjIgNzYgMiAxNyAxCjIgNzcgMiAxNiAxCjIgNzggMiAxNSAxCjIgNzkgMiAx
NCAxCjIgODAgMiAxMyAxCjIgODEgMiAxMiAxCjIgODIgMiAxMSAxCjIgODMgMiAxMCAxCjIgODQg
MiA5IDEKMiA4NSAyIDggMQoyIDg2IDIgNyAxCjIgODcgMiA2IDEKMiA4OCAyIDUgMQoyIDg5IDIg
NCAxCjIgOTAgMiAzIDEKMiA5MSAyIDIgMQoyIDkyIDIgNjEgNjAKMiA5MyAyIDYxIDEKMiA5NCAy
IDcxIDkzCjIgOTUgMiA5NSA5NAoyIDk2IDIgMTEwIDk0CjIgOTcgMiA1MiA5NgoyIDk4IDIgMTE2
IDk0CjIgOTkgMiA5MCA5MwoyIDEwMCAyIDEwOCA5NAoyIDEwMSAyIDEwMCA5NAoyIDEwMiAyIDEw
NCA5NAoyIDEwMyAyIDEwNSA5OQoyIDEwNCAyIDg5IDk5CjIgMTA1IDIgNTAgOTYKMiAxMDYgMiA5
OSA5NAoyIDEwNyAyIDEwMyA5NAoyIDEwOCAyIDQ3IDk2CjIgMTA5IDIgMTA2IDk0CjIgMTEwIDIg
ODAgMTA5CjIgMTExIDIgODggMTEwCjIgMTEyIDIgODcgMTA0CjIgMTEzIDIgMTI4IDk0CjIgMTE0
IDIgMTI2IDk0CjIgMTE1IDIgMzQgOTgKMiAxMTYgMiA3NCAxMDkKMiAxMTcgMiA4OCAxMTYKMiAx
MTggMiA2NSAxMDkKMiAxMTkgMiA3NCAxMTgKMiAxMjAgMiA4OCAxMTkKMiAxMjEgMiA3NCA5NAoy
IDEyMiAyIDg4IDEyMQoyIDEyMyAyIDEyOSA5NAoyIDEyNCAyIDEyNSA5NAoyIDEyNSAyIDM0IDEx
NAoyIDEyNiAyIDEwOSA5NAoyIDEyNyAyIDkzIDk0CjIgMTI4IDIgOTQgOTQKMiAxMjkgMiA2OCAx
MjYKMiAxMzAgMiA1MSA5NgoyIDEzMSAyIDYyIDk0CjIgMTMyIDIgNTggMTI2CjIgMTMzIDIgODYg
NTgKMiAxMzQgMiA4NiAxMDkKMiAxMzUgMiA4MCAxMzQKMiAxMzYgMiA4OCAxMzUKMiAxMzcgMiAx
MDIgOTQKMiAxMzggMiA2NyA5OAoyIDEzOSAyIDEwNyA5NAoyIDE0MCAyIDg2IDEzOQoyIDE0MSAy
IDgwIDE0MAoyIDE0MiAyIDg4IDE0MQoyIDE0MyAyIDY3IDEyNAoyIDE0NCAyIDg4IDExOAoyIDE0
NSAyIDQ5IDk2CjIgMTQ2IDIgNzIgMTA5CjIgMTQ3IDIgNjMgMTQ2CjIgMTQ4IDIgMTAxIDE0Nwoy
IDE0OSAyIDM0IDExMwoyIDE1MCAyIDg2IDE0NgoyIDE1MSAyIDgwIDE1MAoyIDE1MiAyIDg4IDE1
MQoyIDE1MyAyIDY3IDEwOQoyIDE1NCAyIDExMSA5NAoyIDE1NSAyIDY3IDEyMwoyIDE1NiAyIDQy
IDk0CjIgMTU3IDIgNzUgOTgKMiAxNTggMiA0MSA5OAoyIDE1OSAyIDU0IDk4CjIgMTYwIDIgNTUg
OTgKMiAxNjEgMiA0OCA5OAoyIDE2MiAyIDQzIDk4CjIgMTYzIDIgNDAgOTQKMiAxNjQgMiAxNzUg
MTYxCjIgMTY1IDIgMTc2IDE2NAoyIDE2NiAyIDE3NyAxNjQKMiAxNjcgMiAxOTMgMTY2CjIgMTY4
IDIgMTg3IDE2MQoyIDE2OSAyIDE4OSAxNjgKMiAxNzAgMiAxNjMgMTYwCjIgMTcxIDIgMTY2IDE2
MAoyIDE3MiAyIDE5NCAxNzEKMiAxNzMgMiAxODEgMTYwCjIgMTc0IDIgMTkyIDE1OQoyIDE3NSAy
IDE5NCAxNzQKMiAxNzYgMiAxODcgMTU5CjIgMTc3IDIgMTg5IDE3NgoyIDE3OCAyIDE3OCAxNjQK
MiAxNzkgMiAxODMgMTY0CjIgMTgwIDIgNjYgMTU4CjIgMTgxIDIgMTczIDE4MAoyIDE4MiAyIDE3
MiAxODEKMiAxODMgMiAzOSAxNTgKMiAxODQgMiAxNzMgMTgzCjIgMTg1IDIgMTcyIDE4NAoyIDE4
NiAyIDE3MCAxODMKMiAxODcgMiAxNjkgMTg2CjIgMTg4IDIgNTkgMTU3CjIgMTg5IDIgMzYgOTgK
MiAxOTAgMiAxNjcgMTg5CjIgMTkxIDIgMTAxIDE5MAoyIDE5MiAyIDE2NSAxOTAKMiAxOTMgMiAx
ODcgMTg5CjIgMTk0IDIgMTg5IDE5MwoyIDE5NSAyIDczIDk4CjIgMTk2IDIgMzUgOTgKMiAxOTcg
MiAxNjQgMTk2CjIgMTk4IDIgMTAxIDE5NwoyIDE5OSAyIDE2NSAxOTcKMiAyMDAgMiAxODcgMTk2
CjIgMjAxIDIgMTg5IDIwMAoyIDIwMiAyIDE4NyAxOTUKMiAyMDMgMiAxODkgMjAyCjIgMjA0IDIg
NDYgOTQKMiAyMDUgMiAxMTQgOTQKMiAyMDYgMiA0NSA2MAoyIDIwNyAyIDQ1IDEzNwoyIDIwOCAy
IDU3IDk4CjIgMjA5IDIgNTYgOTgKMiAyMTAgMiAxNjMgMjA5CjIgMjExIDIgMTY2IDIwOQoyIDIx
MiAyIDE5NCAyMTEKMiAyMTMgMiAxODEgMjA5CjIgMjE0IDIgMTgxIDIwOAoyIDIxNSAyIDUzIDk4
CjIgMjE2IDIgMTYzIDIxNQoyIDIxNyAyIDE2NiAyMTUKMiAyMTggMiAxOTQgMjE3CjIgMjE5IDIg
MTgxIDIxNQoyIDIyMCAyIDY0IDk4CjIgMjIxIDIgNzYgOTgKMiAyMjIgMiA3MCAyMDUKMiAyMjMg
MiAzNyAyMDUKMiAyMjQgMiAxODggMjIyCjIgMjI1IDIgMTAxIDIyNAoyIDIyNiAyIDM5IDIyMwoy
IDIyNyAyIDYwIDIyMAoyIDIyOCAyIDE2OCAyMjcKMiAyMjkgMiAxNzIgMjI4CjIgMjMwIDIgMTcw
IDIyNwoyIDIzMSAyIDE2OSAyMzAKMiAyMzIgMiA2OSAyMjAKMiAyMzMgMiAxNzEgMjMyCjIgMjM0
IDIgMTY5IDIzMwoyIDIzNSAyIDE3MyAyMzIKMiAyMzYgMiAxNzIgMjM1CjIgMjM3IDIgMTg3IDIy
MAoyIDIzOCAyIDE4OSAyMzcKMiAyMzkgMiAxNzMgMjI2CjIgMjQwIDIgMTcyIDIzOQoyIDI0MSAy
IDE3MCAyMjYKMiAyNDIgMiAxNjkgMjQxCjIgMjQzIDIgNzcgOTgKMiAyNDQgMiAxNzAgMTg4CjIg
MjQ1IDIgMTY5IDI0NAoyIDI0NiAyIDE4NSAxNjUKMiAyNDcgMiAxODUgMjE0CjIgMjQ4IDIgMTg1
IDE5OQo1IDk1NyAxIDEgMCAwIDUgMSA5MyAwIDgzNyAxMjk0MjExMzcgMSA5OSAxIDAgMTkgMSAx
MDQgMSAwIDQ2MSAxIDExMiA1MSAwIDAgMSAxMDMgMSAwIDE5MDAgMSA5NCAxIDggOTgwNDE4IDEg
MjA1IDQ2NzIgMCA1MTM5MiAxIDIyMyAxNzkxIDEgODY5OTggMSAyMjYgMTY0NCAwIDIwMzcyIDEg
MjQxIDExODYgMCA1MjE4NCAxIDI0MiAxMTg2IDAgMjM3MiAxIDIzOSAxMTg2IDAgNTIxODQgMSAy
NDAgMTE4NiAwIDIzNzIgMSAyMjIgMjc4MCAxIDcwNTQ3IDEgMjI0IDI3ODAgMSA0MTcwMCAxIDIy
NSAyNzgwIDAgNTU2MCAxIDIwNCAxIDAgMCAxIDE2MyAyIDAgMCAxIDE1NiAxNTkgMCA0MiAxIDE1
NCA1NjEgMCAzNTk3IDEgMTM5IDE5NzQyIDUgMTUzMjMwNSAxIDE0MCAwIDAgNTkwNzMgMSAxNDEg
MTk2OTEgNiA4NjY0MDQgMSAxNDIgMTk2OTEgMCAwIDEgMTM3IDE4MiAwIDE1MTc4IDEgMjA3IDAg
MCA3MjMzIDEgMTMxIDE3MTIgMCAwIDEgMTI4IDMgMSA2MDg2MDUgMSAxMjcgNzk1MCAzIDQxMzQw
MCAxIDEyNiAxMDc4IDAgNzU0NiAxIDEzMiA5ODEgMCAxODg2IDEgMTI5IDk3IDAgMCAxIDEyNCAz
NjM1IDEgMjA5MTQyIDEgMTQzIDE1ODMgMCA0MTY3IDEgMTIzIDM0MjkgNyAyMTYxNjAzIDEgMTU1
IDEyODEgMCAyNTIwIDEgMTIxIDEzNzggMCA3OTEwMCAxIDEyMiAxNjA0IDAgMCAxIDExNCAxMDIw
NiAzIDUxOTE5MiAxIDEyNSAzNDQxIDAgMjc1MjggMSAxMTMgMTQxMDMgNiA5ODQ1NjMgMSAxNDkg
MjI3NDQgMiAxODE5NTIgMSAxMDkgMTAxNzQgMCAwIDEgMTUzIDcxIDAgMjEzIDEgMTQ2IDk3IDAg
MCAxIDE1MCAwIDAgMjMxIDEgMTUxIDc3IDAgMzM4OCAxIDE1MiA3NyAwIDAgMSAxNDcgMTE3IDAg
MzUxIDEgMTQ4IDExNyAwIDIzNCAxIDEzNCAwIDAgMjkxIDEgMTM1IDk3IDAgNDEwOCAxIDEzNiA5
MiAwIDAgMSAxMTggMTM3OCAwIDEzNjIzIDEgMTQ0IDk3IDAgMCAxIDExOSAxMzc4IDEgMTA3OTcy
IDEgMTIwIDE2MDQgMCAwIDEgMTE2IDQxMzQgMiAzMjM5MTYgMSAxMTcgNDgxMiAwIDAgMSAxMTAg
MTM3OCAyIDU3MzM2IDEgMTExIDEyNzUgMCAwIDEgMTA3IDMgMiAzMDU1NDAgMSAxMDYgMzM3NzEg
MTIgMTE3ODU5MCAxIDEwMiAzIDAgNzM2MyAxIDEwMSAxMjc0MCAxIDExNDY2MCAxIDEwMCAxMTMz
MCAyIDIxNjUxMCAxIDk4IDQ0ODczIDcgODc3NTgxIDEgMjQzIDc1IDAgMTk1MCAxIDIyMSAyNDA0
IDAgMCAxIDIyMCAyNDA0IDIgMTUzNTIxIDEgMjM3IDI0MDQgMSAxMzk0MzIgMSAyMzggMjQwNCAw
IDQ4MDggMSAyMzIgMTI1MyAxIDE2Mjg5IDEgMjM1IDEyNTMgMSA1NTEzMiAxIDIzNiAxMjUzIDAg
MjUwNiAxIDIzMyAxMjUzIDAgNTUxMzIgMSAyMzQgMTI1MyAwIDI1MDYgMSAyMjcgMjQwNCAwIDMx
MTk2IDEgMjMwIDIzNzggMCAxMDQ2MzIgMSAyMzEgMjM3OCAwIDQ3NTYgMSAyMjggMjM3OCAxIDEw
NDYzMiAxIDIyOSAyMzc4IDEgNDc1NiAxIDIxNSA2MTAgMCA0NjM2MCAxIDIxOSA2MTAgMCAwIDEg
MjE3IDYxMCAwIDM1MzgwIDEgMjE4IDYxMCAwIDEyMjAgMSAyMTYgNjEwIDAgMTAzNzAgMSAyMDkg
NDM3IDEgMTgzNTQgMSAyMTMgNDM3IDAgMCAxIDIxMSA0MzcgMCAyNTM0NiAxIDIxMiA0MzcgMCA4
NzQgMSAyMTAgNDM3IDAgNjU1NSAxIDIwOCAzNzM0IDAgMTU2ODI4IDEgMjE0IDc0ODcgMCAxOTAg
MSAyNDcgMTkgMCA1MzIgMSAxOTYgMTM1NSAwIDYwOTc1IDEgMjAwIDEzNTUgMCA3ODU5MCAxIDIw
MSAxMzU1IDAgMjcxMCAxIDE5NyAxMzU1IDAgODEzMCAxIDE5OSAxMzU2IDAgMTAgMSAyNDggMSAw
IDI4IDEgMTk4IDEzNTUgMSAyNzEwIDEgMTk1IDE0NCAwIDM0NTYgMSAyMDIgMTQ0IDAgODM1MiAx
IDIwMyAxNDQgMCAyODggMSAxODkgNjAgMCAyNzAwIDEgMTkzIDYwIDAgMzQ4MCAxIDE5NCA2MCAw
IDEyMCAxIDE5MCA2MCAwIDM2MCAxIDE5MiA2MCAwIDAgMSAxOTEgNjAgMCAxMjAgMSAxNjIgMTE0
NjggMiAxOTQ4MjMgMSAxNjEgNzEgMCAyNDg1IDEgMTY4IDcxIDAgNDExOCAxIDE2OSA3MSAwIDE0
MiAxIDE2NCA3MSAxIDE3MzIgMSAxNzkgNCAwIDQwNCAxIDE3OCA0IDAgMCAxIDE2NiA3MCAwIDQw
NjAgMSAxNjcgNzAgMCAxNDAgMSAxNjUgODAgMCA5MCAxIDI0NiA5IDAgMjUyIDEgMTYwIDc4MCAx
IDU5MjgwIDEgMTczIDc4MCAwIDAgMSAxNzEgNzgwIDAgNDUyNDAgMSAxNzIgNzgwIDAgMTU2MCAx
IDE3MCA3ODAgMSAxMzI2MCAxIDE1OSAyMTA1IDAgOTQ3MjUgMSAxNzYgMjEwNSAxIDEyMjA5MCAx
IDE3NyAyMTA1IDAgNDIxMCAxIDE3NCAyMTA1IDEgMTIyMDkwIDEgMTc1IDIxMDUgMCA0MjEwIDEg
MTU4IDEwOTQ3IDMgNDgxNjY4IDEgMTgzIDQ4NDQgMiA2MDQ1MiAxIDE4NiAzOTAwIDMgMTcxNjAw
IDEgMTg3IDM5MDAgMCA3ODAwIDEgMTg0IDM5MDAgMyAxNzE2MDAgMSAxODUgMzkwMCAwIDc4MDAg
MSAxODAgNjEwMyAxIDM2NjE4IDEgMTgxIDYxMDMgNSAyNjg1MzIgMSAxODIgNjEwMyAxIDEyMjA2
IDEgMTU3IDEwNzk2IDAgMjM3NDk5IDEgMTg4IDEwNzk1IDEgMCAxIDI0NCAxMDI3OSA1IDQ1MjI3
NiAxIDI0NSAxMDI3OSAwIDIwNTU4IDEgMTM4IDgxODAgMiAyMjU2OSAxIDExNSA5NzQzIDMgNzc5
NDQgMSA5NiA5IDAgMTAzNDQgMSAxNDUgOTA0IDAgMCAxIDEzMCA5ODEgMCAwIDEgMTA4IDEzNzgg
MCAwIDEgMTA1IDE2OSAwIDAgMSA5NyAxIDAgMCAxIDk1IDEgMCAwIDEgODggMCAwIDAgMSA4NiAw
IDAgMCAxIDg1IDAgMCAwIDEgODQgMCAwIDAgMSA4MyAwIDAgMCAxIDgyIDAgMCAwIDEgODEgMCAw
IDAgMSA4MCAwIDAgMCAxIDc5IDAgMCAwIDEgNzggMSAwIDMgMSA3NyAwIDAgMCAxIDc2IDAgMCAw
IDEgNzUgMCAwIDAgMSA3NCAwIDAgMCAxIDczIDAgMCAwIDEgNzIgMCAwIDAgMSA3MSAxNyAwIDk1
OTMgMSA3MCAwIDAgMCAxIDY5IDAgMCAwIDEgNjggMCAwIDAgMSA2NyAwIDAgMCAxIDY2IDAgMCAw
IDEgNjUgMCAwIDAgMSA2NCAzIDAgMzcgMSA2MyAwIDAgMCAxIDYyIDAgMCAwIDEgNjEgMCAwIDAg
MSA2MCA0MyAxIDQ0MTI1IDEgMjA2IDEgMCA1IDEgOTIgMSAwIDcgMSA1OSAzIDAgMzM5IDEgNTgg
MTIgMCAxMzYgMSAxMzMgMSAwIDUgMSA1NyAxMiAwIDgwIDEgNTYgMCAwIDAgMSA1NSAwIDAgMCAx
IDU0IDAgMCAwIDEgNTMgMCAwIDAgMSA1MiAwIDAgMCAxIDUxIDAgMCAwIDEgNTAgMCAwIDAgMSA0
OSA3IDAgMjUgMSA0OCAwIDAgMCAxIDQ3IDAgMCAwIDAK
--_=XFMail.1.3.p0.Solaris:001207193935:15881=_--
End of MIME message
From qrczak@knm.org.pl Thu Dec 7 19:31:02 2000
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 7 Dec 2000 19:31:02 GMT
Subject: Fun with GHC's optimiser
References: <74096918BE6FD94B9068105F877C002D01378231@red-pt-02.redmond.corp.microsoft.com>
Message-ID:
Thu, 7 Dec 2000 09:17:44 -0800, Simon Peyton-Jones pisze:
> Try now. On the HEAD. Which should compile OK now, incidentally.
But does not work...
../../ghc/compiler/ghc-inplace -recomp -cpp -fglasgow-exts -fvia-C -icheck -O -package lang -package concurrent -package posix -package-name util -I../lang/cbits -I../concurrent/cbits -I../posix/cbits -split-objs -c Unique.lhs -o Unique.o -osuf o
panic! (the `impossible' happened):
mkWWcpr: not a product PrelNum.Integer{-311-}
And also:
ghc-inplace --interactive
[...]
Loading package std ... resolving ... ghc: fatal error: ocResolve_ELF: /home/users/qrczak/cvs/fptools/ghc/driver/../lib/std/HSstd.o: unknown symbol `PrelNum_showSignedInteger_closure'
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From rrt1001@cam.ac.uk Fri Dec 8 10:54:37 2000
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Fri, 8 Dec 2000 10:54:37 +0000 (GMT)
Subject: New InstallShield: no more DLLs
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C60171F31C@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
> Did you already try out a statically linked, stripped DLL on Win2K? Do
> you get the same
> error?
Yes, I did, and I didn't get the error. (At least, not after the latest
round of debugging.)
> Do you have some idea what's wrong here?
Only the idea I had before: that something is going wrong during DLL
startup. The best suggestion I've seen is that there's a problem with trying
to use the value of uninitialised pointers, and that when they lie within the
application address space there's no problem, but when they lie outside, an
error is raised. The only guess I have as to why this could be happening (on
our side) is the hack used to allow static initialisers in DLLs.
On the other hand, there is definitely a problem with the linker, which
creates different executables depending on the order in which the libraries
are stored on the disk. I'm not sure whether this is causing problems;
indeed, the fact that the current problem occurs on some machines and not on
others suggests that it is not. It is nevertheless weird, and *can* make the
difference between the problem occurring or not (as it did on my machine).
So it's a sufficient but not necessary cause.
For the moment I'm not investigating this. I will again when I can find the
enthusiasm.
There's one thing that worries me about your message: are you saying that
you can reproduce the problem with a statically linked DLL? I've only ever
had the problem with dynamic DLLs. That's one reason that I've given up on
it for the moment: it is still possible to use DLLs reliably, as far as I'm
concerned. I thought that Arjan only had problems, as I did, with the
dynamically linked version. If this is false, I'd better dig a bit more.
--
http://sc3d.org/rrt/ | impatience, n. the urge to do nothing
From simonpj@microsoft.com Fri Dec 8 13:57:55 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 8 Dec 2000 05:57:55 -0800
Subject: Fun with GHC's optimiser
Message-ID: <74096918BE6FD94B9068105F877C002D01378248@red-pt-02.redmond.corp.microsoft.com>
PArrays.$w$snewPArray
= \ ww :: PrelGHC.Int# w :: PrelBase.Int ->
case PrelGHC.newIntArray# @ PrelGHC.RealWorld ww PrelGHC.realWorld#
of wild { (# s2#, mba# #) ->
let {
eta :: PrelBase.Int
__A 0 __C
eta
= PrelBase.$wI# ww
} in
case PrelGHC.-# ww 1 of sat { __DEFAULT ->
case PrelGHC.># 0 sat of wild1 {
PrelBase.True ->
PArrays.$wPArray
@ PrelBase.Int eta (__coerce PrelGHC.ByteArray# mba#);
PrelBase.False ->
case w of w1 { PrelBase.I# ww1 ->
case PrelGHC.writeIntArray# @ PrelGHC.RealWorld mba# 0 ww1
s2#
of s2#1 { __DEFAULT ->
case PrelGHC.-# ww 1 of wild2 {
0 ->
PArrays.$wPArray
@ PrelBase.Int eta (__coerce
PrelGHC.ByteArray# mba#);
__DEFAULT ->
let {
a4 :: (PArrays.PArray PrelBase.Int)
__A 0 __C
a4 =
PArrays.$wPArray
@ PrelBase.Int eta (__coerce
PrelGHC.ByteArray# mba#) } in
__letrec {
$wgo :: (PrelGHC.Int#
-> PrelGHC.State# PrelGHC.RealWorld
-> (PrelGHC.State#
PrelGHC.RealWorld,
PArrays.PArray PrelBase.Int))
__A 2 __C
$wgo
= \ w2 :: PrelGHC.Int# w3 :: (PrelGHC.State#
PrelGHC.RealWorld) ->
case PrelGHC.writeIntArray# @
PrelGHC.RealWorld mba# w2 ww1 w3
of s2#2 { __DEFAULT ->
case PrelGHC.-# ww 1 of sat1 { __DEFAULT
->
case PrelGHC.==# w2 sat1 of wild11 {
PrelBase.True -> (# s2#2, a4 #);
PrelBase.False ->
case PrelGHC.+# w2 1 of sat2 {
__DEFAULT ->
$wgo sat2 s2#2
}
}
}
};
} in case $wgo 1 s2#1 of wild3 { (# ds, r #) -> r
}
}
}
}
}
}
}
| However, we came across one problem (read, lack of
| optimisation on GHC's part), which leads to tedious
| duplication of a lot of code in our array library.
| Basically, GHC does not recognise for tail recursive
| functions when certain arguments (accumulators maintained in
| a loop) can be unboxed. This leads to massive overheads in
| our code. Currently, we circumvent the inefficiency by
| having manually specialised versions of the loops for
| different accumulator types and using RULES to select them
| where appropriate (based on the type information). I will
| send you some example code illustrating the problem soon.
Yes please.
Meanwhile, in the head, if you specify -O2 you'll get better
code for some of your loops, namely the ones that repeatedly
evaluate a free variable every time round the loop. The
loop is duplicated and everything is nice. Here's a tiny example:
g :: Int -> Int
g x = let h 0 = 0
h y = if x==0 then y else h (y+1)
in
h 88
This now compiles to:
LC.g
= \ x :: PrelBase.Int ->
case x of wild { PrelBase.I# x1 ->
case x1 of wild1 {
0 -> PrelBase.$wI# 88;
__DEFAULT ->
__letrec {
$wh :: (PrelGHC.Int# -> PrelBase.Int)
__A 1 __C
$wh
= \ ww :: PrelGHC.Int# ->
case ww of wild2 {
0 -> LC.lit;
__DEFAULT ->
case PrelGHC.+# wild2 1 of sat { __DEFAULT
-> $wh sat }
};
} in $wh 89
}
}
You mentioned something like this before.
The amount of code duplication is controlled by -fliberate-case-threshold20
(say)
The default is set pretty low. And it all only happens with -O2.
All in the HEAD. The pass is call simplCore/LiberateCase.
Simon
From dirk@TechFak.Uni-Bielefeld.DE Fri Dec 8 17:08:33 2000
From: dirk@TechFak.Uni-Bielefeld.DE (Dirk Evers)
Date: Fri, 08 Dec 2000 18:08:33 +0100 (MET)
Subject: Beginners profiling question
In-Reply-To:
Message-ID:
No answer?
Is the question too stupid?
Cheers
Dirk
On 07-Dec-00 Dirk Evers wrote:
>=20
> So I have tried profiling the first time...
>=20
> using ghc-4.08.1 with options -prof -auto-all
> runtime option -px
> ghcprof and daVinci work like a charm
>=20
> what I see is
>=20
> main uses 99.90 % time and space
> sat for practical purposes is the only function called from main and
> uses ca. 12 % time and space
>=20
> what am I doing wrong...
> Prelude not compiled for profiling?
>=20
> Thanks in advance
> Dirk
> ---
> +---------------------------------------------------------------------+
>| Dirk Evers Office: M3-120 |
>| Technische Fakultaet / AG PI Tel: +49 521 106-2905 |
>| Universitaet Bielefeld FAX: +49 521 106-6411 |
>| D-33594 Bielefeld e-mail: dirk@TechFak.Uni-Bielefeld.DE |
>| Germany URL: http://www.TechFak.Uni-Bielefeld.DE/~dirk/ |
>|---------------------------------------------------------------------|
>| Die Succulenten / a cappella singing / http://www.succulenten.de |
> +---------------------------------------------------------------------+
---
+---------------------------------------------------------------------+
| Dirk Evers Office: M3-120 |
| Technische Fakultaet / AG PI Tel: +49 521 106-2905 |
| Universitaet Bielefeld FAX: +49 521 106-6411 |
| D-33594 Bielefeld e-mail: dirk@TechFak.Uni-Bielefeld.DE |
| Germany URL: http://www.TechFak.Uni-Bielefeld.DE/~dirk/ |
|---------------------------------------------------------------------|
| Die Succulenten / a cappella singing / http://www.succulenten.de |
+---------------------------------------------------------------------+
From simonpj@microsoft.com Fri Dec 8 17:33:35 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 8 Dec 2000 09:33:35 -0800
Subject: Beginners profiling question
Message-ID: <74096918BE6FD94B9068105F877C002D0137825D@red-pt-02.redmond.corp.microsoft.com>
| No answer?
| Is the question too stupid?
not at all. just no one with time to answer today. posting your program
too would be a useful thing to do.
Simon
From simonmar@microsoft.com Mon Dec 11 11:18:20 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 11 Dec 2000 03:18:20 -0800
Subject: Beginners profiling question
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611578B@TVP-MSG-01.europe.corp.microsoft.com>
> So I have tried profiling the first time...
>
> using ghc-4.08.1 with options -prof -auto-all
> runtime option -px
> ghcprof and daVinci work like a charm
>
> what I see is
>
> main uses 99.90 % time and space
> sat for practical purposes is the only function called from main and
> uses ca. 12 % time and space
>
> what am I doing wrong...
> Prelude not compiled for profiling?
I'm not sure what you're expecting to see - the profile looks reasonable
to me. Why do you think it's wrong?
Ah, perhaps you're worried that the percentages don't add up to 100%:
that's because they're "inherited", i.e. sat's costs form part of the
total costs of main, because main called sat. The daVinci browser has a
button to turn off inherited stats, as I recall.
BTW, we're working on a new profile viewer. Here is a screenshot
showing your profile:
http://research.microsoft.com/~simonmar/pview.jpg
the user interface is little rough at the moment, but you can see the
general idea.
Cheers,
Simon
From dirk@TechFak.Uni-Bielefeld.DE Mon Dec 11 11:36:22 2000
From: dirk@TechFak.Uni-Bielefeld.DE (Dirk Evers)
Date: Mon, 11 Dec 2000 12:36:22 +0100 (MET)
Subject: Beginners profiling question
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611578B@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
On 11-Dec-00 Simon Marlow wrote:
>> So I have tried profiling the first time...
>>=20
>> using ghc-4.08.1 with options -prof -auto-all
>> runtime option -px
>> ghcprof and daVinci work like a charm
>>=20
>> what I see is
>>=20
>> main uses 99.90 % time and space
>> sat for practical purposes is the only function called from main and
>> uses ca. 12 % time and space
>>=20
>> what am I doing wrong...
>> Prelude not compiled for profiling?
>=20
> I'm not sure what you're expecting to see - the profile looks reasonable
> to me. Why do you think it's wrong?
>=20
> Ah, perhaps you're worried that the percentages don't add up to 100%:
> that's because they're "inherited", i.e. sat's costs form part of the
> total costs of main, because main called sat. The daVinci browser has a
> button to turn off inherited stats, as I recall.
Your picture shows that sat uses 12% of the time, and main uses 99% which i=
s
fine because it inherites all time usage. But main really only calls sat, l=
ike
so:
main =3D do
~[rnastr] <- getArgs
print (sat (str2inp rnastr (0::Int)))
str2inp is just a small data conversion routines for sat. So where
does all the time go?
> BTW, we're working on a new profile viewer. Here is a screenshot
> showing your profile:
>=20
> http://research.microsoft.com/~simonmar/pview.jpg
>=20
> the user interface is little rough at the moment, but you can see the
> general idea.
This looks nice!
>=20
> Cheers,
> Simon
>=20
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I will set up a complete example as Simon Peyton-Jones suggested.
Thanks again
Dirk
---
+---------------------------------------------------------------------+
| Dirk Evers Office: M3-120 |
| Technische Fakultaet / AG PI Tel: +49 521 106-2905 |
| Universitaet Bielefeld FAX: +49 521 106-6411 |
| D-33594 Bielefeld e-mail: dirk@TechFak.Uni-Bielefeld.DE |
| Germany URL: http://www.TechFak.Uni-Bielefeld.DE/~dirk/ |
|---------------------------------------------------------------------|
| Die Succulenten / a cappella singing / http://www.succulenten.de |
+---------------------------------------------------------------------+
From simonmar@microsoft.com Mon Dec 11 11:46:05 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 11 Dec 2000 03:46:05 -0800
Subject: Beginners profiling question
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60171F32B@TVP-MSG-01.europe.corp.microsoft.com>
> Your picture shows that sat uses 12% of the time, and main
> uses 99% which is
> fine because it inherites all time usage. But main really
> only calls sat, like
> so:
>
> main = do
> ~[rnastr] <- getArgs
> print (sat (str2inp rnastr (0::Int)))
>
> str2inp is just a small data conversion routines for sat. So where
> does all the time go?
Probably in "print". Yes, the Prelude isn't compiled with -auto-all (or
even -auto) by default. We'll probably start doing this when the better
profile viewers come on-line.
Cheers,
Simon
From chak@cse.unsw.edu.au Mon Dec 11 13:41:01 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 12 Dec 2000 00:41:01 +1100
Subject: Transitive inlining
Message-ID: <20001212004101Y.chak@cse.unsw.edu.au>
In the context of the array library, we stumbled over
another problem. Does GHC transitive inlining across
modules? Let's say, we have the following scenario:
module B (foo) where
{-# INLINE foo #-}
foo .. = ...bar...
{-# INLINE bar #-}
bar .. = ...
module L (baz) where
import B
{#- INLINE baz #-}
baz .. = ...B.foo...
module Main where
import L
main .. = ...L.baz...
GHC in this case inlines the whole expression "...B.foo..."
in `Main', but will it inline the right hand side of `B.bar'
in `Main' (or even of `B.foo')? If the INLINE pragma is
transitive across modules boundaries, one would hope so.
It seems that GHC is not (always?) doing this inlining,
which already for a very simple benchmark costs us a factor
of 5 runtime! (With inlining - enforced by copying
definitions manually into `Main' - the code produced by GHC
is actually a little bit faster than the code for the
corresponding C program).
Cheers,
Manuel
PS: I had problems building GHCi and it seems as if my
message to cvs-ghc@haskell.org doesn't get through
somehow...
From qrczak@knm.org.pl Mon Dec 11 19:08:48 2000
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 11 Dec 2000 19:08:48 GMT
Subject: Transitive inlining
References: <20001212004101Y.chak@cse.unsw.edu.au>
Message-ID:
Tue, 12 Dec 2000 00:41:01 +1100, Manuel M. T. Chakravarty pisze:
> PS: I had problems building GHCi and it seems as if my
> message to cvs-ghc@haskell.org doesn't get through
> somehow...
Subject: "mail boot" problem
?
I have got it.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From chak@cse.unsw.edu.au Thu Dec 14 07:40:20 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 14 Dec 2000 18:40:20 +1100
Subject: Fun with GHC's optimiser
In-Reply-To: <74096918BE6FD94B9068105F877C002D01378248@red-pt-02.redmond.corp.microsoft.com>
References: <74096918BE6FD94B9068105F877C002D01378248@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20001214184020B.chak@cse.unsw.edu.au>
Simon Peyton-Jones wrote,
> Meanwhile, in the head, if you specify -O2 you'll get better
> code for some of your loops, namely the ones that repeatedly
> evaluate a free variable every time round the loop. The
> loop is duplicated and everything is nice.
[..]
> You mentioned something like this before.
>
> The amount of code duplication is controlled by -fliberate-case-threshold20
> (say)
> The default is set pretty low. And it all only happens with -O2.
It works nicely :-)
In what kind of unit is the number after the
-fliberate-case-threshold option. I really need to use 20
for it to work on the current version of the array code
(where the loop that is to be optimised is much more
involved than the initial example that I posted).
Thanks,
Manuel
From kort@wins.uva.nl Thu Dec 14 14:03:34 2000
From: kort@wins.uva.nl (Jan Kort)
Date: Thu, 14 Dec 2000 15:03:34 +0100
Subject: C stack
Message-ID: <3A38D336.B6D397E4@wins.uva.nl>
Hi,
I'm trying to write an interface for a C library that
uses a Boehm type garbage collector. So, I need to get
the address of the bottom of the C stack. In a C
application this would look something like:
main()
{
int bottomOfStack;
}
Where "&bottomOfStack" would be the thing I need. So,
I'd want some function like:
bottomOfStack :: IO Addr
Would it be possible at all to make an interface to
a C library that uses Boehm's garbage collection ?
What Boehm's algorithm does is traverse the C stack
at each garbage collect marking all accessible
nodes and then sweeping all unmarked nodes. Would
this cause problems with the C code generated by
ghc ?
Jan
From chak@cse.unsw.edu.au Fri Dec 15 07:24:04 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 15 Dec 2000 18:24:04 +1100
Subject: Fun with GHC's optimiser
In-Reply-To: <74096918BE6FD94B9068105F877C002D01378248@red-pt-02.redmond.corp.microsoft.com>
References: <74096918BE6FD94B9068105F877C002D01378248@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20001215182404S.chak@cse.unsw.edu.au>
Simon Peyton-Jones wrote,
> | However, we came across one problem (read, lack of
> | optimisation on GHC's part), which leads to tedious
> | duplication of a lot of code in our array library.
> | Basically, GHC does not recognise for tail recursive
> | functions when certain arguments (accumulators maintained in
> | a loop) can be unboxed. This leads to massive overheads in
> | our code. Currently, we circumvent the inefficiency by
> | having manually specialised versions of the loops for
> | different accumulator types and using RULES to select them
> | where appropriate (based on the type information). I will
> | send you some example code illustrating the problem soon.
>
> Yes please.
I have found a way of rephrasing the definition so that it
is properly optimised by GHC. However, I think, it should
be possible to do this automatically and it is maybe not
unlike the optimisation done by simplCore/LiberateCase.
The code I would like to write is, for example, the
following
import PrelGHC
import PrelBase
import PrelST
fill :: MutableByteArray# s
-> (acc -> Int)
-> (acc -> acc)
-> Int
-> acc
-> ST s acc
{-# INLINE fill #-}
fill mba# f g (I# n#) start = fill0 0# start
where
fill0 i# acc | i# ==# n# = return acc
| otherwise = do
writeIntArray mba# (I# i#) (f acc)
fill0 (i# +# 1#) (g acc)
writeIntArray :: MutableByteArray# s -> Int -> Int -> ST s ()
{-# INLINE writeIntArray #-}
writeIntArray mba# (I# i#) (I# e#) = ST $ \s# ->
case writeIntArray# mba# i# e# s# of {s2# ->
(# s2#, () #)}
foo mba# n = fill mba# id (+1) 1000 0
The interesting part is the handling of the accumulator.
After inlining `fill' into `foo', it becomes obvious that
the accumulator can be maintained as an unboxed integer.
Unfortunately, it is not obvious to GHC, which generates the
following (this is just the inlined `fill0' loop):
__letrec {
$wfill0 :: (PrelGHC.Int#
-> PrelBase.Int
-> PrelGHC.State# s -> (PrelGHC.State# s, PrelBase.Int))
__A 3 __C
$wfill0
= \ w2 :: PrelGHC.Int#
w3 :: PrelBase.Int
w4 :: (PrelGHC.State# s) ->
case w2 of wild {
1000 -> (# w4, w3 #);
__DEFAULT ->
case w3 of wild1 { PrelBase.I# e# ->
case PrelGHC.writeIntArray# @ s w wild e# w4 of s2# { __DEFAULT ->
case PrelGHC.+# e# 1 of a { __DEFAULT ->
let {
sat :: PrelBase.Int
__A 0 __C
sat
= PrelBase.$wI# a
} in
case PrelGHC.+# wild 1 of sat1 { __DEFAULT ->
$wfill0 sat1 sat s2#
}
}
}
}
};
} in $wfill0 0 Test.lit w1
The accumulator (w3) is unboxed immediately before the
writeIntArray# and its next value put into a box (sat) -
only to be unboxed immediately again in the next loop
iteration.
This would make perfect sense when the definition of `foo'
were
foo mba# n = fill mba# id plus 1000 0
where
plus 0 = error "Die horribly"
plus x = x + 1
I also appreciate that, if the loop is executed zero times,
the initial value of `acc' is not demanded. But this is not
much different to the case handled by simplCore/LiberateCase.
And indeed with a little help, GHC generates much better
code. In the following, I rewrote `fill' to explicitly test
for input values that make the loop execute zero times:
fill mba# f g (I# 0#) start = return start
fill mba# f g (I# n#) start = fill0 0# start
where
fill0 i# acc = do
writeIntArray mba# (I# i#) (f acc)
let i'# = i# +# 1#
acc' = g acc
if i'# ==# n# then return acc' else fill0 i'# acc'
Now, `acc' is guaranteed to be used in each invocation of
`fill0' and GHC generates:
__letrec {
$wfill0 :: (PrelGHC.Int#
-> PrelGHC.Int#
-> PrelGHC.State# s -> (PrelGHC.State# s, PrelBase.Int))
__A 3 __C
$wfill0
= \ w2 :: PrelGHC.Int#
ww :: PrelGHC.Int#
w3 :: (PrelGHC.State# s) ->
case PrelGHC.writeIntArray# @ s w w2 ww w3 of s2# { __DEFAULT ->
case PrelGHC.+# w2 1 of wild {
1000 ->
case PrelGHC.+# ww 1 of a { __DEFAULT ->
let {
a1 :: PrelBase.Int
__A 0 __C
a1
= PrelBase.$wI# a
} in (# s2#, a1 #)
};
__DEFAULT ->
case PrelGHC.+# ww 1 of sat { __DEFAULT -> $wfill0 wild sat s2# }
}
};
} in $wfill0 0 0 w1
A nice tight loop.
However, the initial version of `fill' is the more natural
one to write. I think, it should be possible to derive the
second version (are at least a similar version)
automatically from the initial code. The derivation might
go roughly as follows:
fill mba# f g (I# n#) start = fill0 0# start
where
fill0 i# acc = case i# ==# n# of
True -> return acc
False -> do
writeIntArray mba# (I# i#) (f acc)
fill0 (i# +# 1#) (g acc)
=== {pull case out of fill0 (ie, partial unfolding)}
fill mba# f g (I# n#) start =
case 0# ==# n# of
True -> return start
False -> fill0 0# start
where
fill0 i# acc = do
writeIntArray mba# (I# i#) (f acc)
case (i# +# 1#) ==# n# of
True -> return (g acc)
False -> fill0 (i# +# 1#) (g acc)
This is essentially the recursive variant of a well known
law for while loops:
while p do q;
===
if p then do q while p;
Wouldn't this actually subsume the liberate case rule?
f = \ t -> case v of
V a b -> a : f t
=== {pull out the case}
f = case v of
V a b -> f = \ t -> a : case v of
V a b -> f t
=== {simplification}
f = case v of
V a b -> f = \ t -> a : f t
This might be more complicated to implement, as we only
partially unfold the recursive function, but it also has
more scope.
What do you think?
Cheers,
Manuel
PS: All Core code was generated with the HEAD from two days ago.
From simonmar@microsoft.com Fri Dec 15 10:13:11 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 15 Dec 2000 02:13:11 -0800
Subject: C stack
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60171F346@TVP-MSG-01.europe.corp.microsoft.com>
> Hi,
>
> I'm trying to write an interface for a C library that
> uses a Boehm type garbage collector. So, I need to get
> the address of the bottom of the C stack. In a C
> application this would look something like:
> main()
> {
> int bottomOfStack;
> }
> Where "&bottomOfStack" would be the thing I need. So,
> I'd want some function like:
> bottomOfStack :: IO Addr
>
> Would it be possible at all to make an interface to
> a C library that uses Boehm's garbage collection ?
> What Boehm's algorithm does is traverse the C stack
> at each garbage collect marking all accessible
> nodes and then sweeping all unmarked nodes. Would
> this cause problems with the C code generated by
> ghc ?
I don't forsee any problems with the C stack - the stack pointer stays
static during execution of Haskell code, and only moves when we do a C
call or return to the RTS.
Don't forget to tell the GC to traverse the Haskell heap too - GHC keeps
this in mmapped address space. See fptools/ghc/rts/MBlock.c for the
details.
Cheers,
Simon
From kort@wins.uva.nl Fri Dec 15 16:59:30 2000
From: kort@wins.uva.nl (Jan Kort)
Date: Fri, 15 Dec 2000 17:59:30 +0100
Subject: C stack
References: <9584A4A864BD8548932F2F88EB30D1C60171F346@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <3A3A4DF2.56505797@wins.uva.nl>
Simon Marlow wrote:
>
> I don't forsee any problems with the C stack - the stack pointer stays
> static during execution of Haskell code, and only moves when we do a C
> call or return to the RTS.
But how do I get the address of the bottom of the stack ? It seems I can
define a C main so I can get the bottom of the stack, but how do I make
it call Haskell's main to start the application ?
>
> Don't forget to tell the GC to traverse the Haskell heap too - GHC keeps
> this in mmapped address space. See fptools/ghc/rts/MBlock.c for the
> details.
Ok, I will do that, it looks like a better idea than working with
ForeignObj and finalizers.
Jan
From shutej@rpi.edu Sat Dec 16 19:34:28 2000
From: shutej@rpi.edu (Jeremy Shute)
Date: Sat, 16 Dec 2000 14:34:28 -0500
Subject: Having to use -static flag under Win32 with 4.08 & Cygwin 1.1.6
Message-ID:
Hi,
I've been perusing the documentation looking for what I've done wrong...
1. I got the latest versions of both Cygwin and GHC.
2. I installed Cygwin on a clean partition, F:
3. I installed GHC in /usr/share/ghc/ (on F:, of course)
4. I copied the Perl binary over to /bin, and pointed the bang in the ghc
script to the location of the binary (I found this a necessary step).
5. I got a little test program from the web:
{--------------------------------------}
module Main where
main = putStrLn "Hello, World!"
{--------------------------------------}
6. Tried to compile said program:
$ ghc main.hs
Output file not specified, defaulting to "main.exe"
gcc: F:/usr/share/ghc/lib/Main.dll_o: No such file or directory
gcc: F:/usr/share/ghc/lib/PrelMain.dll_o: No such file or directory
7. Confirmed that these files exist nowhere on the partition. Messed
around some more to no avail, came across static flag and tried that:
$ rm Main.hi main.o
$ ghc -static main.hs
Output file not specified, defaulting to "main.exe"
$ ./main.exe
Hello, World!
8. Think I'm onto something so look around for an additional installation
step I perhaps did not take, such as building libraries from source shipped
with the distro. Nope, can't find any. I can't imagine why that would even
be necessary, to support Win32 on Alphas maybe?
So alas, here I sit frustrated, waiting for comp.lang.functional, and I
figured I'd try you guys. Has anyone else had this problem? If not,
perhaps you still have an idea of what's going on? This would be much
appreciated...
Jeremy Shute
From simonpj@microsoft.com Mon Dec 18 10:24:16 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 18 Dec 2000 02:24:16 -0800
Subject: Transitive inlining
Message-ID: <74096918BE6FD94B9068105F877C002D0137832C@red-pt-02.redmond.corp.microsoft.com>
Yes, all the inlining you expect should indeed happen. If
it doesn't can you show us an example?
Simon
| -----Original Message-----
| From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au]
| Sent: 11 December 2000 13:41
| To: glasgow-haskell-users@haskell.org
| Cc: keller@it.uts.edu.au
| Subject: Transitive inlining
|
|
| In the context of the array library, we stumbled over
| another problem. Does GHC transitive inlining across
| modules? Let's say, we have the following scenario:
|
| module B (foo) where
|
| {-# INLINE foo #-}
| foo .. = ...bar...
|
| {-# INLINE bar #-}
| bar .. = ...
|
|
| module L (baz) where
|
| import B
|
| {#- INLINE baz #-}
| baz .. = ...B.foo...
|
|
| module Main where
|
| import L
|
| main .. = ...L.baz...
|
| GHC in this case inlines the whole expression "...B.foo..."
| in `Main', but will it inline the right hand side of `B.bar'
| in `Main' (or even of `B.foo')? If the INLINE pragma is
| transitive across modules boundaries, one would hope so.
|
| It seems that GHC is not (always?) doing this inlining,
| which already for a very simple benchmark costs us a factor
| of 5 runtime! (With inlining - enforced by copying
| definitions manually into `Main' - the code produced by GHC
| is actually a little bit faster than the code for the
| corresponding C program).
|
| Cheers,
| Manuel
|
| PS: I had problems building GHCi and it seems as if my
| message to cvs-ghc@haskell.org doesn't get through
| somehow...
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From simonmar@microsoft.com Mon Dec 18 13:40:24 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 18 Dec 2000 05:40:24 -0800
Subject: C stack
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115797@TVP-MSG-01.europe.corp.microsoft.com>
> Simon Marlow wrote:
> >
> > I don't forsee any problems with the C stack - the stack
> pointer stays
> > static during execution of Haskell code, and only moves
> when we do a C
> > call or return to the RTS.
>
> But how do I get the address of the bottom of the stack ? It
> seems I can
> define a C main so I can get the bottom of the stack, but how
> do I make
> it call Haskell's main to start the application ?
Well, you could "foreign export" your top-level Haskell function and
just call it from C. Check out ghc/includes/RtsAPI.c for the API (you
need to call startupHaskell() first and shutdownHaskell() afterward).
Sadly we haven't documented this stuff very well.
Cheers,
Simon
From simonpj@microsoft.com Tue Dec 19 08:46:32 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 19 Dec 2000 00:46:32 -0800
Subject: Fun with GHC's optimiser
Message-ID: <74096918BE6FD94B9068105F877C002D0137837E@red-pt-02.redmond.corp.microsoft.com>
Manuel
| I have found a way of rephrasing the definition so that it
| is properly optimised by GHC. However, I think, it should
| be possible to do this automatically and it is maybe not
| unlike the optimisation done by simplCore/LiberateCase.
I agree with your example. But I think the way to handle
it is this. Suppose we have
f x y = ....(f ex (C a b))...
where C is a constructor, and where y is scrutinised by a
case expression somewhere in f's body. Then, in this recursive
call to f, we know what y will be, and we could save the case in
the recursive call. So make a specialised version of f, thus:
fs x a b = let y = C a b in (...original body of f...)
Now add a RULE to f, saying
f x (C a b) ===> fs x a b
This is very much the way type specialisation works. Now every
call to f that has a (C a b) argument will benefit. Including
the recursive call to f in fs's RHS, so fs will become the self-recursive
tight loop you want, leaving f as a sort of 'impedence matcher' for
callers elsewhere.
I'll try to find time to implement this.
Simon
From rrt1001@cam.ac.uk Mon Dec 18 13:00:28 2000
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Mon, 18 Dec 2000 13:00:28 +0000 (GMT)
Subject: Having to use -static flag under Win32 with 4.08 & Cygwin 1.1.6
In-Reply-To: <74096918BE6FD94B9068105F877C002D01378334@red-pt-02.redmond.corp.microsoft.com>
Message-ID:
> From: Jeremy Shute [mailto:shutej@rpi.edu]
> I've been perusing the documentation looking for what I've done wrong...
Nothing; the docs aren't quite up-to-date.
> 7. Confirmed that these files exist nowhere on the partition. Messed
> around some more to no avail, came across static flag and tried that:
We don't supply the DLLs any more, because they subtly and rarely don't work
for reasons I don't fully understand (though I've spent a long time trying
to). If you really want them (why?) you'll have to build them.
--
http://sc3d.org/rrt/ | maximiste, n. pessimiste
From simonmar@microsoft.com Wed Dec 20 17:46:25 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 20 Dec 2000 09:46:25 -0800
Subject: ANNOUNCE: Happy version 1.9
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60171F366@TVP-MSG-01.europe.corp.microsoft.com>
ANNOUNCING Happy 1.9 - The LALR(1) Parser Generator for Haskell
-----------------------------------------------------------------
I'm pleased to announce version 1.9 of Happy, the parser generator
system for Haskell. Changes in this version, relative to version 1.8
(the previous full release):
* A grammar may now contain several entry points, allowing
several parsers to share parts of the grammar.
* Some bugfixes.
Happy is available in source form, which can be compiled with GHC
version 4.xx (4.08.1 recommended), and we also provide binaries for
some architectures. The Happy homepage with links to the various
distributions lives at:
http://www.haskell.org/happy/
Please send any bug reports and comments to simonmar@microsoft.com.
From chak@cse.unsw.edu.au Thu Dec 21 11:40:02 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 21 Dec 2000 22:40:02 +1100
Subject: ANNOUNCE: Happy version 1.9
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C60171F366@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C60171F366@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20001221224002G.chak@cse.unsw.edu.au>
Simon Marlow wrote,
> ANNOUNCING Happy 1.9 - The LALR(1) Parser Generator for Haskell
> -----------------------------------------------------------------
A RedHat 7.0/i386 rpm package is available at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/happy-1.9-1.i386.rpm
and the matching source rpm at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/happy-1.9-1.src.rpm
Happy Hacking,
Manuel
From simonmar@microsoft.com Thu Dec 21 11:48:09 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 21 Dec 2000 03:48:09 -0800
Subject: The Set type
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60171F369@TVP-MSG-01.europe.corp.microsoft.com>
George Russell wrote:
> A minor quibble I know, but every time I use sets I want to
> add/subtract single elements
> to/from them. There is no function provided for doing this,
> so instead you have to do
> union/delete with a singleton set constructed from the
> element.
Done. Set now has
addToSet :: Ord a => Set a -> a -> Set a
delFromSet :: Ord a => Set a -> a -> Set a
The names and argument order were chosen to be consistent with
FiniteMap, so don't complain :-)
Cheers,
Simon
From rrt1001@cam.ac.uk Thu Dec 21 11:58:42 2000
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Thu, 21 Dec 2000 11:58:42 +0000 (GMT)
Subject: ANNOUNCE: Happy version 1.9
In-Reply-To: <20001221224002G.chak@cse.unsw.edu.au>
Message-ID:
> ANNOUNCING Happy 1.9 - The LALR(1) Parser Generator for Haskell
> -----------------------------------------------------------------
A Windows InstallShield package is available at
http://www.haskell.org/happy/dist/1.9/happy-1-9.exe
--
http://sc3d.org/rrt/ | egrep, n. a bird that debugs bison
From Dominic.J.Steinitz@BritishAirways.com Thu Dec 21 16:30:55 2000
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 21 Dec 2000 16:30:55 Z
Subject: GHC Command Line Help
Message-ID: <"00DEB3A42303F28A*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
I was experimenting with using FiniteMap. The program compiled ok but the linker gave me the following error. What do I need to include on the command line or have I not installed ghc correctly?
[dom@lhrtba8fd85 FiniteMap]$ /usr/bin/ghc -o main test.o -L/usr/lib/ghc-4.08.1 -
lHSlang -lHSdata
/usr/lib/ghc-4.08.1/libHSdata.a(FiniteMap__1.o): In function `__init_FiniteMap':
FiniteMap__1.o(.text+0x16): undefined reference to `__init_GlaExts'
collect2: ld returned 1 exit status
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From Dominic.J.Steinitz@BritishAirways.com Thu Dec 21 16:35:18 2000
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 21 Dec 2000 16:35:18 Z
Subject: GHC Command Line Help
Message-ID: <"00DEB3A4231462B8*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Sorry. It's obviously -fglasgow-exts. I didn't realise it did things at the linking stage as well as the compilation stage.
Dominic Steinitz
21/12/2000 16:30:15
To: glasgow-haskell-users
cc: Chris.Reade
djrussell
B.Avery
dominic
molyneux
bcc:
Subject: GHC Command Line Help
I was experimenting with using FiniteMap. The program compiled ok but the linker gave me the following error. What do I need to include on the command line or have I not installed ghc correctly?
[dom@lhrtba8fd85 FiniteMap]$ /usr/bin/ghc -o main test.o -L/usr/lib/ghc-4.08.1 -
lHSlang -lHSdata
/usr/lib/ghc-4.08.1/libHSdata.a(FiniteMap__1.o): In function `__init_FiniteMap':
FiniteMap__1.o(.text+0x16): undefined reference to `__init_GlaExts'
collect2: ld returned 1 exit status
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From ger@tzi.de Thu Dec 21 16:41:25 2000
From: ger@tzi.de (George Russell)
Date: Thu, 21 Dec 2000 17:41:25 +0100
Subject: GHC Command Line Help
References: <"00DEB3A42303F28A*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Message-ID: <3A4232B5.FD957997@tzi.de>
"Steinitz, Dominic J" wrote:
>
> I was experimenting with using FiniteMap. The program compiled ok but the linker gave me the following error. What do I need to include on the command line or have I not installed ghc correctly?
>
> [dom@lhrtba8fd85 FiniteMap]$ /usr/bin/ghc -o main test.o -L/usr/lib/ghc-4.08.1 -
> lHSlang -lHSdata
> /usr/lib/ghc-4.08.1/libHSdata.a(FiniteMap__1.o): In function `__init_FiniteMap':
> FiniteMap__1.o(.text+0x16): undefined reference to `__init_GlaExts'
> collect2: ld returned 1 exit status
I suggest using
/usr/bin/ghc -o main test.o -package data -package lang -fglasgow-exts
or something similar (rather than trying to name the libraries directly).
From ger@tzi.de Thu Dec 21 16:54:12 2000
From: ger@tzi.de (George Russell)
Date: Thu, 21 Dec 2000 17:54:12 +0100
Subject: Generic Classes?
Message-ID: <3A4235B4.2F753A4E@tzi.de>
Are Generic classes going to be in 4.08.2, and if not when are they likely
to be in a binary release? I have a potential application, though
I can manage without them for the time being.
From chak@cse.unsw.edu.au Fri Dec 22 06:13:07 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 22 Dec 2000 17:13:07 +1100
Subject: Fun with GHC's optimiser
In-Reply-To: <74096918BE6FD94B9068105F877C002D0137837E@red-pt-02.redmond.corp.microsoft.com>
References: <74096918BE6FD94B9068105F877C002D0137837E@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20001222171307D.chak@cse.unsw.edu.au>
Simon,
> But I think the way to handle
> it is this. Suppose we have
>
> f x y = ....(f ex (C a b))...
>
> where C is a constructor, and where y is scrutinised by a
> case expression somewhere in f's body. Then, in this recursive
> call to f, we know what y will be, and we could save the case in
> the recursive call. So make a specialised version of f, thus:
>
> fs x a b = let y = C a b in (...original body of f...)
>
> Now add a RULE to f, saying
>
> f x (C a b) ===> fs x a b
>
> This is very much the way type specialisation works. Now every
> call to f that has a (C a b) argument will benefit. Including
> the recursive call to f in fs's RHS, so fs will become the self-recursive
> tight loop you want, leaving f as a sort of 'impedence matcher' for
> callers elsewhere.
Sounds like a good idea to me :-)
Cheers,
Manuel
From chak@cse.unsw.edu.au Mon Dec 25 11:11:02 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Mon, 25 Dec 2000 22:11:02 +1100
Subject: GHC thinks it is smarter than me [was: RE: Transitive inlining]
In-Reply-To: <74096918BE6FD94B9068105F877C002D0137832C@red-pt-02.redmond.corp.microsoft.com>
References: <74096918BE6FD94B9068105F877C002D0137832C@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20001225221102V.chak@cse.unsw.edu.au>
Simon Peyton-Jones wrote,
> Yes, all the inlining you expect should indeed happen. If
> it doesn't can you show us an example?
Meanwhile, I think, the lack of inlining that I saw isn't
connected to modules. Instead, the problem is that GHC
thinks it knows more about my program than I do. More
precisely, it seems to take an INLINE pragma just as an
encouragement rather than a command to inline. In
particular - at least if a function is large enough - it
doesn't inline the function anymore if the function is used
more than once.[1]
This behaviour is a problem for our array library. We need
very aggressive inlining. Would it maybe be possible to
make -O2 interpret INLINE pragmas as obligatory?
Cheers,
Manuel
[1] The function in question actually uses an INLINE 2
pragma - I guess that this doesn't matter.
From chak@cse.unsw.edu.au Mon Dec 25 12:25:15 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Mon, 25 Dec 2000 23:25:15 +1100
Subject: GHC thinks it is smarter than me [was: RE: Transitive inlining]
In-Reply-To: <20001225221102V.chak@cse.unsw.edu.au>
References: <74096918BE6FD94B9068105F877C002D0137832C@red-pt-02.redmond.corp.microsoft.com>
<20001225221102V.chak@cse.unsw.edu.au>
Message-ID: <20001225232515S.chak@cse.unsw.edu.au>
"Manuel M. T. Chakravarty" wrote,
> Meanwhile, I think, the lack of inlining that I saw isn't
> connected to modules. Instead, the problem is that GHC
> thinks it knows more about my program than I do. More
> precisely, it seems to take an INLINE pragma just as an
> encouragement rather than a command to inline. In
> particular - at least if a function is large enough - it
> doesn't inline the function anymore if the function is used
> more than once.[1]
Actually, the current behaviour - at least, as I understand
it - in combination with modules leads IMHO to rather
inconsistent behaviour. Given a module
module M (foo)
where
{#- INLINE foo #-}
foo =
GHC will not inline `foo' in
module Main
where
import M
bar = ...foo a...
main = ...foo b...bar...
However, it will inline foo twice in case of
module N (bar)
where
import N
bar = ...foo a...
module Main
where
import M
import N
main = ...foo b...bar...
although it is exactly the same code. In other words, using
many modules leads to larger binaries and faster code.
All this is understandable given that optimisation always
included heuristics. However, for programmer supplied
annotations, I think, it is problematic.
Cheers,
Manuel
From chak@cse.unsw.edu.au Sat Dec 30 13:56:38 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Sun, 31 Dec 2000 00:56:38 +1100
Subject: GHC thinks it is smarter than me [was: RE: Transitive inlining]
In-Reply-To: <20001225221102V.chak@cse.unsw.edu.au>
References: <74096918BE6FD94B9068105F877C002D0137832C@red-pt-02.redmond.corp.microsoft.com>
<20001225221102V.chak@cse.unsw.edu.au>
Message-ID: <20001231005638A.chak@cse.unsw.edu.au>
"Manuel M. T. Chakravarty" wrote,
[..]
> In
> particular - at least if a function is large enough - it
> doesn't inline the function anymore if the function is used
> more than once.
Moreover, I am wondering which the exact conditions are
under which NOINLINE pragmas are ignored by the compiler.
It seems at least always to be ignored in code like
{-# NOINLINE foo #-}
foo =
bar .. = ..foo..
If that is the only occurence of `foo', inlining is
certainly always save, but on the other hand if I take the
trouble to add a NOINLINE pragma, I actually mean it. For
example, I sometimes want to see what Core code is produced
for using -ddump-simpl. The compiler can't know
that, so IMHO it should better just follow my instructions,
instead of trying to be extra smart.
Cheers,
Manuel
From chak@cse.unsw.edu.au Sat Dec 30 07:58:28 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Sat, 30 Dec 2000 18:58:28 +1100
Subject: RULES and unfolding
Message-ID: <20001230185828W.chak@cse.unsw.edu.au>
Is there any heuristic in GHC that discourages putting
unfoldings of functions into .hi files if the function
occurs on the right handside of a RULES rule?
I have code, where this seems to be the case. When I remove
the rewrite rule, the function is placed into the .hi file,
but with the rewrite rule, it isn't - despite an INLINE
pragma for that function! Unfortunately, the example is
rather big and I didn't manage to find a small piece of code
showing the same behaviour yet.
This currently bites me in a rule of the form
{-# "" forall ... foo .. bar .. = foobar .. #-}
{-# INLINE foobar #-}
foobar .. = ...
where I want foobar inlined.
Cheers,
Manuel
PS: I do this only because GHC crashes when I place the rhs
of the foobar definition directly into the rhs of the
rule, but again I don't have a small example producing
the bug *sigh*
From chak@cse.unsw.edu.au Sat Dec 30 01:06:25 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Sat, 30 Dec 2000 12:06:25 +1100
Subject: Lambda dropping in loops
Message-ID: <20001230120625H.chak@cse.unsw.edu.au>
Given a function like
fill 0# mpa = return ()
fill i# mpa = do
let i'# = i# -# 1#
writeMP mpa (I# i'#) e
fill i'# mpa
it would be nice if GHC were to lambda drop it (on the core
level) into
fill i# mpa = fill' i#
where
fill' 0# = return ()
fill' i# = do
let i'# = i# -# 1#
writeMP mpa (I# i'#) e
fill' i'#
as this allows it to subsequently apply the new case
liberation optimisation. By performing the lambda dropping
manually, I have gotten much better code in some performance
sensitive definitions.
Cheers,
Manuel
From simonpj@microsoft.com Sat Dec 30 17:02:55 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Sat, 30 Dec 2000 09:02:55 -0800
Subject: Generic Classes?
Message-ID: <74096918BE6FD94B9068105F877C002D0137844C@red-pt-02.redmond.corp.microsoft.com>
No, not in 4.08.2.
They'll be in our first release of GHCi.
I'm not sure when that will be; Feb I expect.
Simon
| -----Original Message-----
| From: George Russell [mailto:ger@tzi.de]
| Sent: 21 December 2000 16:54
| To: glasgow-haskell-users@haskell.org
| Subject: Generic Classes?
|
|
| Are Generic classes going to be in 4.08.2, and if not when
| are they likely
| to be in a binary release? I have a potential application, though
| I can manage without them for the time being.
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From qrczak@knm.org.pl Sat Dec 30 18:12:48 2000
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 30 Dec 2000 18:12:48 GMT
Subject: Generic Classes?
References: <74096918BE6FD94B9068105F877C002D0137844C@red-pt-02.redmond.corp.microsoft.com>
Message-ID:
Sat, 30 Dec 2000 09:02:55 -0800, Simon Peyton-Jones pisze:
> They'll be in our first release of GHCi.
What about my old comments about distinguishing "the rest of
constructors" from "contents of the constructor we found", and
"the rest of fields" from "contents of the field we are considering"?
IMHO the current state is wrong. Generic instances should not
*require* that operations are directly propagated to arguements of
constructors and values of fields. What happens when we are on the
level of finding a constructor should be separated from what happens
when we are looking inside its fields. And dually, combining fields
should be separated from looking at the value of a field.
It's simple to fix, modulo performance issues. I consider the fixed
version a very good and usable solution, and the current version an
unusable partially flawed design...
It should be possible to rewrite classes which are derivable now
to use the generic mechanism instead of ad-hockery in the compiler.
Bit it will be possible only after the design is fixed not to confuse
constructors and their arguments, and not to confuse sets of fields
and their contents.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From Sven.Panne@informatik.uni-muenchen.de Sat Dec 30 22:09:01 2000
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Sat, 30 Dec 2000 23:09:01 +0100
Subject: Realtime-GC
Message-ID: <3A4E5CFD.77E137DA@informatik.uni-muenchen.de>
IIRC there was some activity in the realtime GC area
for GHC (something like experimental support for 4.0x,
but I can't remember exactly). Any progress yet? It
would be quite cool to fly through Quake levels without
those small hiccups. And I'm quite sure there are more
serious applications which would profit from that, too... :-)
Cheers,
Sven
