(no subject)
unexpected space leak
what does it mean when ghci says: WARNING: ignoring polymorphic case in interpreted mode. Possibly due to strict polymorphic/functional constructor args. Your program may leak space unexpectedly. -- Hal Daume III "Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Concurrent and Posix libraries...
Hi, I want to use a thread in concurrent haskell to manage a posix fork/exec/wait. I expected the test code attached below to output "recovering result" once, instead I get "recovering result" twice. Can anyone shed some light on whats going wrong? (ghci 5.02.1 x86 linux) Thanks /Marcus > module Test where > import Concurrent > import Posix > main = do > mv <- newEmptyMVar > forkIO $ do x <- forkProcess > case x of > Nothing -> do > executeFile "sleep" True ["2"] Nothing > error "oops" > Just pid -> > getProcessStatus True False pid > putMVar mv () > print "recovering result" > takeMVar mv ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc-5.02.2
"in due course" is a native English way of saying "I'm not quite sure" :-) We are planning a release before Christmas. Whether we will actually get it out in the next 3 days remains to be seen, but if not then it'll be early in the new year. Simon | -Original Message- | From: Sven Eric Panitz [mailto:[EMAIL PROTECTED]] | Sent: 19 December 2001 10:41 | To: [EMAIL PROTECTED] | Subject: ghc-5.02.2 | | | | Some time ago Simon Peyton-Jones posted on this list: | 'We will do 5.02.2 in due course' | | Being not a native English speaker, I am not sure about all | subleties of the English language; I wonder what time frame | 'in due course' indicates? Are there any concrete plans, when | ghc-5.02.2 will be available? | | (otherwise I might seek the thrill of compiling ghc from cvs | sources ...) | | | hope this does not sound too much like nagging | | Sven Eric | | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimization and GCC?
Wed, 19 Dec 2001 09:56:36 +0100, Till Doerges <[EMAIL PROTECTED]> pisze:
> /u/joe/built/lib/ghc-5.00.2/includes/Regs.h:255: warning: call-clobbered register
>used for global register variable
I don't know about this one.
> /tmp/ghc15733.hc:5391: warning: deprecated initialization of zero-length array
> /tmp/ghc15733.hc:5391: warning: (near initialization for `Main_main_closure.payload')
This is already fixed in CVS.
ghc3 is not officially supported yet. Nevertheless I'm using it at home
and it can successfully compile almost everything from ghc on ix86.
This is my mk/build.mk - I'm compiling three files with gcc-2.95.3:
ProjectsToBuild = glafp-utils ghc hslibs happy
PrimOps_HC_OPTS = -pgmcgcc-2.95.3
ArrayBase_HC_OPTS = -pgmcgcc-2.95.3
PosixTTY_HC_OPTS = -pgmcgcc-2.95.3
This was for gcc-3.0.1 and ghc a few weeks ago. I'll see if it's better
now, with gcc-3.0.2. The problem with PrimOps looked like gcc bug,
as if it ignored -fomit-frame-pointer for this file.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-5.02.2
Some time ago Simon Peyton-Jones posted on this list: 'We will do 5.02.2 in due course' Being not a native English speaker, I am not sure about all subleties of the English language; I wonder what time frame 'in due course' indicates? Are there any concrete plans, when ghc-5.02.2 will be available? (otherwise I might seek the thrill of compiling ghc from cvs sources ...) hope this does not sound too much like nagging Sven Eric ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc image size
At 10:51 19/12/2001 +0200, you wrote: > >> Why is executable size a barrier? 1.64 megabytes (that's the size of > >> the executable I built with GHC most recently) of disk space costs less > >> than half a cent. > > AL> I don't like this argument. Can I go to a computer store, pay a cent, > AL> and get a hard disk with space 1.64 megabytes or more? Until then, I > AL> can't believe that 1.64 megabytes of disk space costs less than half a > AL> cent. > >1 year ago I bought 20Gb for 200$. That will be 200/(20*1024) = 0.009765625 >dollars per megabyte. Pretty much less than half a cent. I don't think it is about how much memory or hard disk space cost. If it is possible to reduce the footprint of any software without reducing efficiency than this is certainly worthwhile. I believe that there is a more scientific issue behind this, as was correctly pointed out by Albert. It should be investigated why the executable is so large, and then considering whether it can be done in a better way. Just throwing more hardware at things does not mean that they are better and certainly seems a very short sighted option. Maybe there is a genuine problem there and the executable cannot be any smaller, in which case this is good to know (and might initiate some nice research). If it can be done smaller, what is wrong with doing it? Stephan Stephan Reiff-Marganiec Research Fellow Department of Computing Science; University of Stirling email: [EMAIL PROTECTED]tel: 01786 46 7448 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: converting to & from unboxed types
> > I'm sure this is common knowledge but I can't find it > anywhere in the ghc > docs. How do you take, say, an Integer and "unbox" it and > get an Int# or > something? import GlaExts unbox :: Int -> Int# unbox (I# i) = i box :: Int# -> Int box i = I# i Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc image size
> Mike Gunter <[EMAIL PROTECTED]> writes: > > > Why is executable size a barrier? 1.64 megabytes (that's > the size of > > the executable I built with GHC most recently) of disk > space costs less > > than half a cent. > > I don't like this argument. Can I go to a computer store, pay a cent, > and get a hard disk with space 1.64 megabytes or more? Until then, I > can't believe that 1.64 megabytes of disk space costs less than half a > cent. > > When a compiler does not perform as good as other compilers (e.g., in > terms of generated code size), it is important to ask: Why does it > happen? Is there anything we can do to improve it? Being critical is > the first step towards progress. (Of course these questions should be > asked in a constructive rather than whining way.) Why would anyone > optimize code for time --- a second of electricity and labour cost > less than a cent... Of course, we're always looking for ways to reduce the size of binaries. But the situation might not be as bad as you think; firstly, don't forget to strip the binary if you're worried about disk space, since the symbol table in a GHC-generated binary can be quite large (it doesn't affect the runtime or anything else, though). The subject of shared libraries has come up several times in the past - take a look through the archives for some of the previous discussions. The upshot is that shared libraries wouldn't really buy much unless you really need to save the disk space: in all other considerations, static linking comes out better. Unfortunately GHC-compiled libraries are very tightly coupled, which means it's unlikely you'd be able to swap out a shared library for a newer version unless it was compiled with *exactly* the same compiler and set of libraries as the old version. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc image size
>> Why is executable size a barrier? 1.64 megabytes (that's the size of >> the executable I built with GHC most recently) of disk space costs less >> than half a cent. AL> I don't like this argument. Can I go to a computer store, pay a cent, AL> and get a hard disk with space 1.64 megabytes or more? Until then, I AL> can't believe that 1.64 megabytes of disk space costs less than half a AL> cent. 1 year ago I bought 20Gb for 200$. That will be 200/(20*1024) = 0.009765625 dollars per megabyte. Pretty much less than half a cent. -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Optimization and GCC?
Hello everybody,
I've got some trouble compiling haskell-code on a sparc system. As
soon as I use the option '-O', ghc starts spilling messages like
these:
--- snip ---
[...]
/u/joe/built/lib/ghc-5.00.2/includes/Regs.h:255: warning: call-clobbered register used
for global register variable
[...]
/tmp/ghc15733.hc:5391: warning: deprecated initialization of zero-length array
/tmp/ghc15733.hc:5391: warning: (near initialization for `Main_main_closure.payload')
[...]
--- snap ---
The 2nd type occurs way more often, but it doesn't look really
bad. What I'm more worried about is the first. To use an already used
register? Perhaps anyone could explain these messages to me?
It seems, however, that the code produced is okay.
Things get worse, if I try to use gcc for code-generation. The
messages *seem* to remain the same. Invocation of ghc is basically the
same as above, w/ '-fvia-C -O2-for-C' added:
--- snip ---
mai00dqr@userv1:~/Diplom/cls/src> make
/u/joe/built/bin/ghc-5.00.2 -O -fvia-C -O2-for-C -cpp -DBEGIN_GHC_ONLY='-}'
-DEND_GHC_ONLY='{-' -DBEGIN_HUGS_ONLY='{-' -DEND_HUGS_ONLY='-}' -package text -package
util -i../lib/parsec-250101 -i/u/joe/built/lib/ghc-5.00.2/imports -lncurses --make
Main -o cls
ghc-5.00.2: chasing modules from: Main
[...]
--- snap ---
The code generated now definitely is not okay:
--- snip ---
mai00dqr@userv1:~/Diplom/cls/src> ./cls
Segmentation Fault
--- snap ---
Here's what I'm using:
--- snip ---
mai00dqr@userv1:~> gcc --version
3.0.2
mai00dqr@userv1:~> uname -a
SunOS userv1 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-80
--- snap ---
Is the segmentation fault perhaps related to an interoperability
between ghc and the latest gcc-versions? On a Linux-machine using the
same ghc-version but gcc-2.96 '-O -fvia-C -O2-for-C' doesn't cause
any problems (neither does it cause any messages like the above ones).
If it is a problem related to the version of gcc, how do I tell ghc
which version to use? I only know how to do that on the commandline.
Any hints would be greatly appreciated.
Bye -- Till
--
e-mail: reverse(net dot doerges at till) | ENCRYPTED |
pgp/gpg: keys via keyserver or my homepage | MAIL IS |
www: http://www.doerges.net | WELCOME! |
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
