- Glasgow-haskell-users

RE: Bools are not unboxed
by Simon Peyton-Jones 04 Oct '04

04 Oct '04

| > for :: Int -> IO () -> IO () | > for 0 _ = return () | > for n x = x >> for (n - 1) x Good example (allocates lots of silly thunks). I'd come across this before, and fixed the HEAD, but the 6.2 branch is still doing badly. We'll try to fix that. | Playing with the code generated by ghc is a great way to waste time | for me. Wait until you have found the RULES-pragma :-) In general, GHC's optimiser should behave predictably; small changes in the source program should not have big effects. Of course, sometimes they do, and for good reason. But not always; I'm keen to identify cases where the optimiser does a poor/unpredictable job, and fix them. So please let me know when that happens. The more you can boil down a program, and identify the culprit, as Carsten did so accurately in this case, the more likely I am to fix it. At the other end of the spectrum "this 1000 line program goes slower than I expect" is less helpful :-) Incidentally, GHC does use pre-allocated True and False booleans. Simon

1 0

hWaitForInput and timeouts
by Peter Simons 03 Oct '04

03 Oct '04

Hi, I have another I/O problem. I need to time out when a Handle blocks forever. I am using hWaitForInput anyway, so that shouldn't be a problem, but the documentation says that using this feature will block all IO threads? Is it much work to fix this? I _could_ forkIO a racer thread myself, of course, but it feels wrong to do that around a function that has an explicit timeout argument. :-) Peter

1 0

Bools are not unboxed
by Tomasz Zielonka 03 Oct '04

03 Oct '04

Hello! I was playing with monadic looping a'la replicateM_ and I created this function: for :: Int -> IO () -> IO () for 0 _ = return () for n x = x >> for (n - 1) x Compiled with -O2, it is really fast and makes no unnecessary allocations. Tested with this main main = for 10000000 (return ()) it gives the following stats <<ghc: 1024 bytes, 0 GCs, 0/0 avg/max bytes residency (0 samples), 1M in use, 0,00 INIT (0,00 elapsed), 0,33 MUT (0,33 elapsed), 0,00 GC (0,00 elapsed) :ghc>> Cool! ( this is still 10 times slower than g++ -O3, but a similar pure function is only 3 times slower, and I am satisfied with such results (at this moment ;) ) Unfortunately, the program I was playing with could call 'for' with negative n, for which it was supposed to make 0 iterations, and this version definitely makes too many iterations. So I made another version: for :: Int -> IO () -> IO () for n x | n > 0 = x >> for (n - 1) x | otherwise = return () To my surprise, it was much slower and made many allocations: <<ghc: 240927488 bytes, 920 GCs, 1036/1036 avg/max bytes residency (1 samples), 1M in use, 0,00 INIT (0,00 elapsed), 2,48 MUT (2,50 elapsed), 0,04 GC (0,05 elapsed) :ghc>> I checked in -ddump-simpl that Ints are getting unboxed in both versions. Then I noticed the cause: GHC.Prim.<# returns a boxed, heap allocated Bool, and so do other primitive comparison operators. Would it be difficult to add Bool unboxing to GHC? Maybe it would suffice to use preallocated False and True? Best regards, Tom -- .signature: Too many levels of symbolic links

2 3

RE: Is there a non-blocking version of hGetArray?
by Simon Marlow 03 Oct '04

03 Oct '04

On 01 October 2004 08:45, Peter Simons wrote: > I am a happy user of hGetBufNonBlocking, but I have come to > realize that mutable arrays are nicer to work with than > pointers, so I have considered using hGetArray instead. I > do, however, depend on the fact that the function returns as > soon as it has read data -- even if less than requested --, > like hGetBufNonBlocking does. > > Is there currently a way to achieve this? Not currently, but I could probably implement the equivalent (hGetArrayNonBlocking). > Am I right assuming that hGetBuf and hGetArray do not differ > much performance-wise? Hopefully not. > One of the reasons I am curious about using mutable arrays > is because of Data.Array.Base.unsafeRead, which seems to be > a *lot* faster than accessing the memory through a pointer. > Is there anything comparable for pointer access? I'm surprised if pointer access to memory is slower than unsafeRead. Could you post some code that we can peer at? Cheers, Simon

3 4

Re: BeOS port
by Waldemar Kornewald 03 Oct '04

03 Oct '04

Hi, is it possible to use a simpler build system for GHC? :) Could someone please have a look at the build logs? http://zeus.mpg.goe.net/~tuvok/logs Note that I got the same errors when building on Linux! I also ported some .c files. You can find the source here: http://zeus.mpg.goe.net/~tuvok/ghc-6.2.1-beos-src.zip When I manually went into the ghc folder and ran make the .c files were compiled successfully. Then, I had problems with the mangler, but that was a bug in Perl, I think. I commented out: die "Prologue junk?: $p\n" if $p =~ /^\s+[^\s\.]/; and it worked fine. That is must be a bug in Perl because running this check in some other script does not fail. The next error was that my shell did not understand the script for "Ways". I just commented it out and it began looping and always saying that it tries to compile ways, then it restarts the whole makefile and begins with gmp and so on...never ending. Could somebody please install a freeware version of BeOS on his computer and try to fix what is broken? I think fixing the build scripts is beyond my capabilities. Thank you very much. Bye, Waldemar Kornewald

2 1

RE: Using packages in ghci
by Simon Marlow 02 Oct '04

02 Oct '04

On 01 October 2004 10:37, Adrian Hey wrote: > Where does ghci look for .hi files from packages? (I doesn't seem to > be the same place as ghc). AFAICT it expects to find them relative to > the current directory, and I can only get it to work by cding to > the appropriate directory *before* invoking ghci (doing this from > within ghci seems to really mess things up). > > But I guess this isn't what's supposed to happen because this > solution will only work with one package. > > My package entry looks like this.. > > Package > {name = "Data.Tree.AVL", > auto = True, > import_dirs = ["/home/adrian/HaskellLibs/Data.Tree.AVL/pkg"], > source_dirs = [], > library_dirs = ["/home/adrian/HaskellLibs/Data.Tree.AVL/pkg"], > hs_libraries = ["Data.Tree.AVL"], > extra_libraries = [], > include_dirs = [], > c_includes = [], > package_deps = ["base", "Data.COrdering"], > extra_ghc_opts = [], > extra_cc_opts = [], > extra_ld_opts = [], > framework_dirs = [], > extra_frameworks = []} > > Is there something missing here? Looks fine - GHCi is supposed to look in the directories in import_dirs for .hi files. What does ghci -v tell you? Cheers, SImon

2 1

BeOS port
by Waldemar Kornewald 02 Oct '04

02 Oct '04

Hi, is there someone doing a BeOS port of GHC? If not, I would like to try it (if not too time-consuming). What problems did you run into when porting GHC to FreeBSD or any other POSIX platform? Why do you not offer .hc packages of different builds (FreeBSD and/or Linux)? I could use them as a very good starting point. Or could anyone please create a zip with those files generated from such a build? Thank you very much. Bye, Waldemar Kornewald

3 3

symbol __stg_split_marker' is already defined
by John Goerzen 02 Oct '04

02 Oct '04

Hi, I am trying to build ghc 6.2.1 for AIX. I successfully bootstrapped an unregisterised ghc-inplace from an i386 Linux box today. I am now trying to build a real ghc on AIX. I've had endless trouble, and finally decided to put this in mk/build.mk: GhcUnregisterised = YES GhcWithNativeCodeGen = NO GhcWithInterpreter = NO That made things run much smoother. In fact, it made it to libraries/base. Now I get this: rm -f GHC/Base.o; if [ ! -d GHC/Base_split ]; then mkdir GHC/Base_split; else /o pt/freeware/bin/find GHC/Base_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -package-name base -O -Rghc-timing -split-objs -c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi /tmp/ghc82602.hc:2593: warning: this decimal constant is unsigned only in ISO C9 0 /tmp/ghc82602.s: Assembler messages: /tmp/ghc82602.s:128: Error: symbol `__stg_split_marker' is already defined /tmp/ghc82602.s:287: Error: symbol `__stg_split_marker' is already defined /tmp/ghc82602.s:448: Error: symbol `__stg_split_marker' is already defined And about a hundred more. Ideas? Oh, BTW, I had to put a script named gcc on my path. It says this: exec /usr/local/bin/gcc -mpowerpc -maix32 -mminimal-toc "$@" Otherwise, it trips all over itself whenever it encounters assembly (it's a powerpc cpu but gcc generates power code by default). And the link fails (toc overflow -- mminimal-toc fixes that.) The system: AIX 5.1L PowerPC64 CPU (running in 32-bit mode) GCC 3.3.2 GHC 6.2.1 Thanks, John Goerzen

2 1

Re: BeOS port
by Waldemar Kornewald 02 Oct '04

02 Oct '04

Waldemar Kornewald wrote: > In my Linux build there is a file Arrow.hs, but in my BeOS build this > file (and all others) are missing. How are these files generated and why > are they not generated in BeOS? Please forget this. Those files exist on both systems, but unfortunately they are not built. Someone told me on #haskell that he had the same problems when building on a threaded system (which BeOS is). Is that a general GHC problem? Bye, Waldemar Kornewald

2 1

RE: Registering packages
by Simon Marlow 01 Oct '04

01 Oct '04

On 22 September 2004 21:37, Geoff C wrote: > Howdy, > > I am trying to set up GHC with wxHaskell and run a couple of samples > in Win2K Professional. > > I have GHC in c:\Program Files\ghc-6.2.1\ > and wxHaskell in c:\Program Files\wxhaskell-0,8\ > > The setup batch file for wxHaskell could not register the packages, or > copy the DLL to the system32 directory. I manually copied the DLL, > and tried to register the packages with GHC. I set the PATH > environment variable to include the GHC directory. > > I am typing the following commands and the command prompt: > > ghc-pkg -u -i "c:\progra~1\wxhaskell-0.8\bin\wxcore.pkg" > ghc-pkg -u -i "c:\progra~1\wxhaskell-0.8\bin\wx.pkg" > > Each time, I get an error 'Unable to expand variable "wxhlibdir"' when > the program is trying to expand embedded variables. > > I went ahead and put GHC in my program file directory because I did > not intend to use cygwin (which I understand has a problem with spaces > in file/dir names). Usually, however, using "Progra~1" instead of > "Program Files" allows programs which don't like spaces to run. Could > this be the problem? Looks like wxHaskell needs to set an environment variable when installing the package, but because you did it by hand you didn't have this environment variable set. Why didn't the normal wxHaskell install work for you? Cheers, Simon

2 1