Bug: GPF WinXP GHCi 6.4
GHC 6.4 Final Release - tried the sample code for
Graphics.HGL, i.e.
module Main where {
import Graphics.HGL;
main :: IO ();
main = runGraphics $
withWindow_ "Hello World Window" (300, 200) $ \ w - do
drawInWindow w $ text (100, 100) "Hello World"
drawInWindow w $ ellipse (100, 80) (200, 180)
getKey w;
}
WindowsXP Home.
First attempt in GHCi is as below. Retrying main causes a GPF error
box.
c:\tempghci Main
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Compiling Main ( Main.hs, interpreted )
Ok, modules loaded: Main.
*Main main
Loading package Win32-1.0 ... interactive: Not x86 PEi386
ghc.exe: panic! (the `impossible' happened, GHC version 6.4):
loadObj: failed
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
*Main main
Loading package Win32-1.0 ... linking ...
c:\temp
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
loop performance bug
Hi,
This sort of code runs very slowly when compared to the equivalent in C:
{-# OPTIONS -fglasgow-exts #-}
module Main where
import Data.Array.MArray
import Data.Array.IO
data Pos = Pos !Int !Int
deriving (Eq, Ord, Ix)
main = test1
test1 :: IO ()
test1 = do
(arr :: IOUArray Pos Bool) - newArray_ (Pos 0 0, Pos 99 99)
sequence_ [ sequence_ [ writeArray arr (Pos y x) False
| y - [0..99]
, x - [0..99] ]
| _ - [0..] ]
Timing:
$ ghc --make -O2 SpeedTest.hs -o speedtest-hs
$ time ./speedtest-hs
real0m10.968s
user0m10.952s
sys 0m0.005s
Comparing to an 'equivalent' C program:
int main () {
char arr[100][100];
int n,x,y;
for (n = 0; n != 1; n++)
for (y = 0; y != 100; y++)
for (x = 0; x != 100; x++)
arr[y][x] = 0;
}
$ gcc -O2 speedtest.c -o speedtest-c
$ time ./speedtest-c
real0m0.129s
user0m0.123s
sys 0m0.000s
Now parhaps this is unfair sice the Haskell program is written in terms
of lists. So lets write it using explicit looping and no lists.
{-# INLINE doFromTo #-}
-- do the action for [from..to] ,ie it's inclusive.
doFromTo :: Int - Int - (Int - IO ()) - IO ()
doFromTo from to action =
let loop n | n to = return ()
| otherwise = do action n
loop (n+1)
in loop from
test2 :: IO ()
test2 = do
(arr :: IOUArray Pos Bool) - newArray_ (Pos 0 0, Pos 99 99)
doFromTo 0 $ \_ -
doFromTo 0 99 $ \y -
doFromTo 0 99 $ \x -
writeArray arr (Pos y x) False
Timing:
$ ghc --make -O2 SpeedTest.hs -o speedtest-hs
$ time ./speedtest-hs
real0m7.942s
user0m7.936s
sys 0m0.001s
So not much better really. :-(
If there's way to write loops that is faster I'd dearly like to know.
I initially assumed that the second version would run fast since there
is no obvious need for any memory allocations (which is the usual
culprit).
Duncan
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: FW: ghc, linux
Yong Luo [EMAIL PROTECTED] writes: I installed a very old version of GHC in the same laptop in 2001 and it was working well (no matter how big the program was). Now, I upgraded it to version 6.2.2, but it becomes very slow and asks more Memory or Space. Well, if you are using mainly standard Haskell'98 code, i.e. almost no language extensions, you could try a smaller compiler like nhc98. Regards, Malcolm ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1163215 ] internal error: scavenge_mark_stack:
Bugs item #1163215, was opened at 2005-03-14 20:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1163215group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gour (ggd) Assigned to: Nobody/Anonymous (nobody) Summary: internal error: scavenge_mark_stack: Initial Comment: Hi! I 'patched' ghc-6.4 source with the latest Adjustor.c on the hope to get FFI support under amd64. However, attempt to compile gtk2hs gives: [...] make[2]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' if test -f glib/glib.precomp; then :; else make glib/glib.precomp; fi; make[2]: Entering directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' /var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7/tools/c2hs/c2hsLocal +RTS -H300m -M350m -RTS -C-I/usr/include/glib-2.0 -C-I/usr/lib/glib-2.0/include --cppopts='-include config.h' --precomp=glib/glib.precomp glib-object.h elapsed time: 0.00 (start) elapsed time: 0.00 (about to parse headder) elapsed time: 3.11 (about to serialise header) c2hsLocal: internal error: scavenge_mark_stack: unimplemented/strange closure type -1780819864 @ 0x2a95dad118 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ make[2]: *** [glib/glib.precomp] Error 254 make[2]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' make[1]: *** [glib/System/Glib/Types.hs] Error 2 make[1]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' ghc-6.4: can't find file `glib/System/Glib/Types.hs' make: *** [glib/libHSglib_a.deps] Error 1 make: *** Deleting file `glib/libHSglib_a.deps' Sincerely, Gour -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1163215group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: loop performance bug
On Mon, 2005-03-14 at 13:41 +, Duncan Coutts wrote: Hi, This sort of code runs very slowly when compared to the equivalent in C: [snip] BTW These timings were for ghc 6.2.2 My version of ghc 6.3 (CVS from about a month or two ago) gave slightly beter timings on both loop version. My version of ghc 6.5 (CVS head from a week or two ago) gave much worse timings on the first test and slightly better timings on the second test (better than both 6.2.2 and 6.3) I've not got the released 6.4 version on my machine yet. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: loop performance bug
Hi,
On Mon, 14 Mar 2005 13:41:06 +, Duncan Coutts
[EMAIL PROTECTED] wrote:
This sort of code runs very slowly when compared to the equivalent in C:
I'm afraid the kind of array processing code you posted will always be
slower than the C equivalent. Haskell only has safe array meaning
that every operation checks the array bounds and that's going to cost
you in situations like these. But I do agree that the timings you
showed are overly bad. Let's see what we can do about it.
A first hint is to never try to guess what kind of code ghc generates.
If you're in need of performance you need to look at some lower level
code. I recommend the -fext-core flag to produce external core, a
sort-of-readable output of ghc's internal representation of the
program. One can learn a lot from that.
{-# OPTIONS -fglasgow-exts #-}
module Main where
import Data.Array.MArray
import Data.Array.IO
data Pos = Pos !Int !Int
deriving (Eq, Ord, Ix)
main = test1
test1 :: IO ()
test1 = do
(arr :: IOUArray Pos Bool) - newArray_ (Pos 0 0, Pos 99 99)
sequence_ [ sequence_ [ writeArray arr (Pos y x) False
| y - [0..99]
, x - [0..99] ]
| _ - [0..] ]
Timing:
$ ghc --make -O2 SpeedTest.hs -o speedtest-hs
$ time ./speedtest-hs
real0m10.968s
user0m10.952s
sys 0m0.005s
I'm very much surprised that this program was slower than the one
without arrays. Since all lists are produced and consumed with good
producers and consumers (as in section 7.10.3 in the User's Guide)
they should really go away. This seems to be a real bug.
[C program deleted]
{-# INLINE doFromTo #-}
-- do the action for [from..to] ,ie it's inclusive.
doFromTo :: Int - Int - (Int - IO ()) - IO ()
doFromTo from to action =
let loop n | n to = return ()
| otherwise = do action n
loop (n+1)
in loop from
test2 :: IO ()
test2 = do
(arr :: IOUArray Pos Bool) - newArray_ (Pos 0 0, Pos 99 99)
doFromTo 0 $ \_ -
doFromTo 0 99 $ \y -
doFromTo 0 99 $ \x -
writeArray arr (Pos y x) False
Timing:
$ ghc --make -O2 SpeedTest.hs -o speedtest-hs
$ time ./speedtest-hs
real0m7.942s
user0m7.936s
sys 0m0.001s
So not much better really. :-(
If there's way to write loops that is faster I'd dearly like to know.
I initially assumed that the second version would run fast since there
is no obvious need for any memory allocations (which is the usual
culprit).
Oh, there are still reasons for memory allocations. You use an
algebraic data type to index the arrays. That is also going to kill
performance. If we look at the external core we can clearly see that
the indexing with the Pos data type is adding overhead. So to improve
we can write the program in a lower level style like this:
test3 :: IO ()
test3 = do
(arr :: IOUArray Int Bool) - newArray_ (0,100*100-1)
doFromTo 0 $ \_ -
doFromTo 0 99 $ \y -
doFromTo 0 99 $ \x -
writeArray arr (x*(y+1)) False
This gave me a factor two speedup compared to test2.
Well, if we stare some more at the external core generated from ghc we
will see that there is still a lot of junk in the inner loop. Many of
these things I don't know what they're doing there. I'm sure the
implementors can explain what's going on there.
HTH
/Josef
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: loop performance bug
We can make it a little faster by not doing bound checks: test4 :: IO () test4 = do (arr :: IOUArray Int Bool) - newArray_ (0,100*100-1) doFromTo 0 $ \_ - doFromTo 0 99 $ \y - doFromTo 0 99 $ \x - unsafeWrite arr (x*(y+1)) False Timings (compiled with -O2): test1: 12.6s test2: 8.5s test3: 1.9s test4: 1.3s -- Friendly, Lemmih ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: loop performance bug
On Tue, 15 Mar 2005 02:06:06 +0100, Lemmih [EMAIL PROTECTED] wrote: We can make it a little faster by not doing bound checks: test4 :: IO () test4 = do (arr :: IOUArray Int Bool) - newArray_ (0,100*100-1) doFromTo 0 $ \_ - doFromTo 0 99 $ \y - doFromTo 0 99 $ \x - unsafeWrite arr (x*(y+1)) False Timings (compiled with -O2): test1: 12.6s test2: 8.5s test3: 1.9s test4: 1.3s A small update making the test more fair: test5 :: IO () test5 = do (arr :: IOUArray Int Int) - newArray_ (0,100*100-1) doFromTo 0 $ \_ - doFromTo 0 99 $ \y - doFromTo 0 99 $ \x - unsafeWrite arr (x*(y+1)) 0 I previously though that Bools were optimized away, guess I was wrong. test5: 0.8s -- Friendly, Lemmih ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: loop performance bug
This one might go even faster again.
Essentially due to Don Stewart but removes the bound checks and uses
Int as an index.
-
module Main
where
import Data.Array.MArray
import Data.Array.IO
import Data.Array.Base
import GHC.Base
import GHC.IOBase
forn a n | n =# 1# = return ()
| otherwise= fory a 0# forn a (n +# 1#)
fory a y | y =# 100# = return ()
| otherwise= forx a y 0# fory a (y +# 1#)
forx a y x | x =# 100# = return ()
| otherwise= do unsafeWrite a (I# ((y *# 100#) +# x))
False
forx a y (x +# 1#)
main :: IO ()
main = do
(arr :: IOUArray Int Bool) - newArray_ (0, 100*100-1)
forn arr 0#
-
I started working on one in which even the IO`s were unboxed. It didn't
get any appreciable speed-up though. It looks like this:
-
forn :: IOUArray Int Bool - Int# - IO ()
forn a n = IO $ forn' a n
where
forn' :: IOUArray Int Bool - Int# - State# RealWorld
- (# State# RealWorld, () #)
forn' a 1# s = (# s, () #)
forn' a n s =
case fory' a 0# s of
(# s2, _ #) - forn' a (n +# 1#) s2
fory' :: IOUArray Int Bool - Int# - State# RealWorld
- (# State# RealWorld, () #)
fory' a 100# s = (# s, () #)
fory' a y s =
case forx' a y 0# s of
(# s2, _ #) - fory' a (y +# 1#) s2
forx' :: IOUArray Int Bool - Int# - Int# - State# RealWorld
- (# State# RealWorld, () #)
forx' a y 100# s = (# s, () #)
forx' a y x s =
case unIO (unsafeWrite a (I# ((y *# 100#) +# x)) False) of {
writeArray' -
case writeArray' s of {
(# s2, _ #) - forx' a y (x +# 1#) s2 }}
main :: IO ()
main = do
(arr :: IOUArray Int Bool) - newArray_ (0, 100*100-1)
forn arr 0#
-
The called to unIO is an explicit unboxing of the result of
unsafeWrite. You could probably speed this up even more by finding out
how unsafeWrite was implemented and tweaking it a bit.
Of course, who wants to write code like this? I certainly don't. And I
also believe that you shouldn't have to to get good performance. I see
the performance of Haskell arrays as a serious problem that still
requires, despite much research, more attention.
Sean
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: loop performance bug
On Tue, 2005-03-15 at 01:39 +0100, Josef Svenningsson wrote: Hi, On Mon, 14 Mar 2005 13:41:06 +, Duncan Coutts [EMAIL PROTECTED] wrote: This sort of code runs very slowly when compared to the equivalent in C: I'm afraid the kind of array processing code you posted will always be slower than the C equivalent. Haskell only has safe array meaning that every operation checks the array bounds and that's going to cost you in situations like these. True, True. I'm not being quite fair. For some programs I have switched to unsafe indexing (and manual array offset calculation) for a 25% or so performnce boost. (I did this for a rewrite of our ICFP'04 ant simulator and got the runtime down from ~5min to ~20sec. The main performance improvement was due to switching from finite maps of structs to structs of mutable unboxed arrays. The unsafe array indexing saved an additional 5 sec or so.) But I do agree that the timings you showed are overly bad. Let's see what we can do about it. As you indicate, the bounds checking is not really the significant factor here. A first hint is to never try to guess what kind of code ghc generates. If you're in need of performance you need to look at some lower level code. I recommend the -fext-core flag to produce external core, a sort-of-readable output of ghc's internal representation of the program. One can learn a lot from that. Although when I do I don't necessarily understand what I see! I see 'let' (ie allocating forms) where I would have hoped there would not be but it doesn't help me to figure out why the code I've written ends up producing allocations. Simon M previously recommended: Since you're interested in allocation, you might be better off with -ddump-prep rather than -ddump-simpl: the former has all the allocation made into explicit 'let' expressions ready for code generation. I'm very much surprised that this program was slower than the one without arrays. You mean the one without lists. Since all lists are produced and consumed with good producers and consumers (as in section 7.10.3 in the User's Guide) they should really go away. This seems to be a real bug. This is what Simon M thought when I brought this up previously. He suggested I use explicit recursion (which I thought I was doing with my second version though it doesn't do much better!) [C program deleted] Good riddence! :-) I initially assumed that the second version would run fast since there is no obvious need for any memory allocations (which is the usual culprit). Oh, there are still reasons for memory allocations. You use an algebraic data type to index the arrays. That is also going to kill performance. If we look at the external core we can clearly see that the indexing with the Pos data type is adding overhead. So to improve we can write the program in a lower level style like this: I was hoping that if the array reading was inlined that the calculation of the index would also be inlined and so the Pos constructor need never be allocated. test3 :: IO () test3 = do (arr :: IOUArray Int Bool) - newArray_ (0,100*100-1) doFromTo 0 $ \_ - doFromTo 0 99 $ \y - doFromTo 0 99 $ \x - writeArray arr (x*(y+1)) False This gave me a factor two speedup compared to test2. So the Pos is really being allocated each time. I guess this would be the same with (,) (,,) etc. Well, if we stare some more at the external core generated from ghc we will see that there is still a lot of junk in the inner loop. Many of these things I don't know what they're doing there. I'm sure the implementors can explain what's going on there. Hope so. :-) Even if we use unsafeWriteArray with manual array offset calculation we're still a few orders of magnitude off where we'd like to be. It's the loop itself I think that is the problem rather than whetever we're doing inside it. /Josef BTW have you thought about picking up hIDE development again? I might go back to it after Gtk2Hs hits version 1.0 Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: loop performance bug
On Tue, 2005-03-15 at 02:06 +0100, Lemmih wrote: We can make it a little faster by not doing bound checks: test4 :: IO () test4 = do (arr :: IOUArray Int Bool) - newArray_ (0,100*100-1) doFromTo 0 $ \_ - doFromTo 0 99 $ \y - doFromTo 0 99 $ \x - unsafeWrite arr (x*(y+1)) False Timings (compiled with -O2): test1: 12.6s test2: 8.5s test3: 1.9s that was test3 that Josef gave? He only got double performance. You get quad performance improvement. test4: 1.3s Nice, my GUI visualiser now runs almost 25% faster (using test4 style vs previous test2 style loops). It can now generate enough X traffic to make the X server take 25% cpu time whereas previously it only got X doing 15-20%. I realised there was a performance bug when I commented out the Sim.step from the inner loop and found that the visuliser speed only doubled, but sommenting out the loops entirely gave the expected order or magnitude speed increase. It seemed the majority of the time was being spent in loop overhead! :-( Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Broken Cabal
Hello, I am not sure if this is the correct place to report this problem, but there is a bug in the Cabal distributed with GHC. I used the simplest possible Setup.hs file as shown in the documentation. All the modules in my library are in a directory Monad, e.g. Monad/State.hs, Monad/Reader.hs, etc. When I type: runhaskell Setup.lhs sdist I get a source tar-ball but when I extract the files I get the following: monadLib-1.2.2/ monadLib-1.2.2/nad/ monadLib-1.2.2/nad/BackT.hs monadLib-1.2.2/nad/ExceptT.hs monadLib-1.2.2/nad/Reader.hs Notice that the Mo part of the directory name is missing. -Iavor ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: loop performance bug
duncan.coutts: This sort of code runs very slowly when compared to the equivalent in C: This example uses unboxing and primops over Lemmih's and seems to run a bit faster: Lemmih's loops: ./a.out 1.35s user 0.00s system 99% cpu 1.359 total This code: ./a.out 0.99s user 0.00s system 98% cpu 1.008 total C: ./a.out 0.14s user 0.00s system 101% cpu 0.138 total import GHC.Base import GHC.IOBase import GHC.Prim import GHC.Pack data M = M (MutableByteArray# RealWorld) main = do (M a) - IO $ \s - case newByteArray# (4#*#100#*#100#) s of (# s',ar #) - (# s',M ar #) doFromTo 0 $ \_ - doFromTo 0 99 $ \y - doFromTo 0 99 $ \x - do IO $ \s - case writeIntArray# (unsafeCoerce# a) (x *# (y +# 1#)) s of s' - (# s', () #) doFromTo (I# from) (I# to) action = do let loop n | n # to = return () | otherwise = action n loop (n+#1#) loop from Changing the index calculation (x *# (y +# 1#) to a constant halves the runtime, again, though that may not be very useful information ;) -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ANNOUNCE: GHC version 6.4
Simon Marlow [EMAIL PROTECTED] wrote: = The (Interactive) Glasgow Haskell Compiler -- version 6.4 = The GHC Team is delighted to announce a new major release of GHC. Some issues: 1. ghc -M complains about multiply-defined Main modules. entered as http://sourceforge.net/tracker/index.php?func=detailaid=1162736group_i d=8032atid=108032 2. What's up with Warning: orphan instances? 3. I notice show for rationals now does 3%2 instead of 3 % 2. Probably better, though it does break one of my tests... 4. It looks like Data.FiniteMap has been renamed Data.Map, or something. There's no Data.Map at http://haskell.org/haddock/libraries/, do these need to be updated? 5. Apparently a bunch of stuff is in different pacakges, such as mtl. Is there documentation about what's in what package? Perhaps Haddock should show packages or something? I'm not yet familiar enough with Cabal to know what the best way of doing this is. -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC version 6.4
| = | The (Interactive) Glasgow Haskell Compiler -- version 6.4 | | = | 2. What's up with Warning: orphan instances? I believe I forgot do document the -fwarn-orphans flag. But info is here: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compila tion.html#orphan-modules Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fedora packages of new GHC and Hugs releases
Hugs98-Mar2005 and ghc-6.4 are available in the Fedora Haskell package repositories for a couple of days now for i386 and x86_64. (nhc98 coming shortly.) For more information about Fedora Haskell see http://haskell.org/fedora/. Jens ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Fedora packages of new GHC and Hugs releases
On 14 March 2005 11:38, Jens Petersen wrote: Hugs98-Mar2005 and ghc-6.4 are available in the Fedora Haskell package repositories for a couple of days now for i386 and x86_64. (nhc98 coming shortly.) For more information about Fedora Haskell see http://haskell.org/fedora/. Are your GHC x86_64 RPMs registerised, or unregisterised? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fedora packages of new GHC and Hugs releases
Simon Marlow wrote: On 14 March 2005 11:38, Jens Petersen wrote: Hugs98-Mar2005 and ghc-6.4 are available in the Fedora Haskell package repositories for a couple of days now for i386 and x86_64. (nhc98 coming shortly.) Are your GHC x86_64 RPMs registerised, or unregisterised? It is a registerised build, bootstrapped from your snap binary some days ago. Jens ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
TH libraries and linking.
Greetings, I've recently been playing around with using TH to generate FFI bindings. The resulting code is in general very concise, more maintainable and far less error-prone than the hand-written counterpart. But increased code bloat ascends out of all this happiness. The binding is required to link with both template-haskell and the library which generates the FFI code, so any binary using the generated binding would get a few hundred kilobytes added which strictly aren't necessary (am I wrong here?). This can be unacceptable for small bindings. One could perhaps get around this cheap by changing the TH pretty printer to output valid Haskell instead of just pretty Haskell (I'm specifically talking about a misplaced 'where' in instance declarations). Then one could use the TH library just like a normal preprocessor. I'm no expert so there's probably difficulties which I can't see. -- Friendly, Lemmih ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.4
= The (Interactive) Glasgow Haskell Compiler -- version 6.4 = A Mac OS X installer package for Mac OS 10.3 (Panther) is available at http://www.uni-graz.at/imawww/haskell/GHC-6.4.pkg.zip I just found a problem with my package: I accidentally included '/usr/local/bin/runhugs' in the package (which obviously has no business there). I have replaced the package with a fixed version. I apologize if this has messed up anyone's hugs installation. I've also made the double-clickable launcher icons work correctly with directory names that contain spaces. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Re: ANNOUNCE: GHC version 6.4
Simon Marlow [EMAIL PROTECTED] wrote: = The (Interactive) Glasgow Haskell Compiler -- version 6.4 = The GHC Team is delighted to announce a new major release of GHC. Some issues: 1. ghc -M complains about multiply-defined Main modules. entered as http://sourceforge.net/tracker/index.php?func=detailaid=1162736group_i d=8032atid=108032 2. What's up with Warning: orphan instances? 3. I notice show for rationals now does 3%2 instead of 3 % 2. Probably better, though it does break one of my tests... 4. It looks like Data.FiniteMap has been renamed Data.Map, or something. There's no Data.Map at http://haskell.org/haddock/libraries/, do these need to be updated? 5. Apparently a bunch of stuff is in different pacakges, such as mtl. Is there documentation about what's in what package? Perhaps Haddock should show packages or something? I'm not yet familiar enough with Cabal to know what the best way of doing this is. -- Ashley Yakeley, Seattle WA ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] RE: ANNOUNCE: GHC version 6.4
On 14 March 2005 10:45, Ashley Yakeley wrote: 1. ghc -M complains about multiply-defined Main modules. entered as http://sourceforge.net/tracker/index.php?func=detailaid=1162736group_ i d=8032atid=108032 We'll look into this. A first approximation answer is you can't do that with the 6.4 implementation of -M. Sorry. 4. It looks like Data.FiniteMap has been renamed Data.Map, or something. There's no Data.Map at http://haskell.org/haddock/libraries/, do these need to be updated? The right place for library documentation is http://haskell.org/ghc/docs/latest/html/libraries I should probably make the version you're looking at into a link to avoid confusion. 5. Apparently a bunch of stuff is in different pacakges, such as mtl. Is there documentation about what's in what package? Perhaps Haddock should show packages or something? I'm not yet familiar enough with Cabal to know what the best way of doing this is. The contents page for the libraries lists the package name for each module. It's not ideal - it would be nice to be able to filter the contents page by package, but I haven't got around to implementing that. Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] announce: wxhaskell 0.9
Benjamin Franksen wrote: On Friday 25 February 2005 19:14, Daan Leijen wrote: Announcement: wxHaskell version 0.9 Could you (or anyone else) please give me a summary on how exactly I have to patch the makefile[.lib] so that I can compile this ghc-6.4? I found the discussion a bit confusing, because there were so many different issues... Hi Ben, I am working on a fresh release of wxHaskell that can be used with ghc 6.4. As you know, there are some issues with the changed dependency output of ghc6.4 that are not quite trivially solved. If you can't wait for the new release, try to contact Georg Martius who has succeeded compiling it with a pre-release of ghc 6.4. All the best, Daan. Thanx, Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] update a text control in wxHaskell by received message
Hi, I want to update a text control in wxHaskell with a message received over a socket. Unfortunately, the documentation is rather sparse and I haven't yet been able to find out how to create an event and then set the widget text with the string received. Can somebody give me a hint? Thanks, Bernd ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] RE: ANNOUNCE: GHC version 6.4
4. It looks like Data.FiniteMap has been renamed Data.Map, or something. There's no Data.Map at http://haskell.org/haddock/libraries/, do these need to be updated? The right place for library documentation is http://haskell.org/ghc/docs/latest/html/libraries I should probably make the version you're looking at into a link to avoid confusion. Data.Map appears to be broken from there too. I get some sort of page with a menu as if the html file is a directory containing only the items HTML and using both of which are broken links, and then [an internal server error occured]. - Cale ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] instance Bounded Double
John Meacham (Sun, Mar 13, 2005 at 08:08:56PM -0800): On Sun, Mar 13, 2005 at 11:08:26PM +, Thomas Davie wrote: [...] We could define maxBound as (2^(mantisa_space))^(2^(exponent_space)) and min bound pretty similarly... But I'm sure that everyone will agree that this is a horrible hack. 2 cent: module Float_bounds ( max_float , min_float , min_pos_float , max_neg_float ) where d = 1 :: Double f = 1 :: Float max_float x = encodeFloat (radix ^ mant - 1) (expo - mant) where radix = floatRadix x mant = floatDigits x expo = snd $ floatRange x min_pos_float x = encodeFloat (1) (expo - mant) where radix = floatRadix x mant = floatDigits x expo = fst $ floatRange x min_float x = - max_float x max_neg_float x = - min_pos_float x Regards -- Stefan Karrmann ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: GHC version 6.4
= The (Interactive) Glasgow Haskell Compiler -- version 6.4 = A Mac OS X installer package for Mac OS 10.3 (Panther) is available at http://www.uni-graz.at/imawww/haskell/GHC-6.4.pkg.zip I just found a problem with my package: I accidentally included '/usr/local/bin/runhugs' in the package (which obviously has no business there). I have replaced the package with a fixed version. I apologize if this has messed up anyone's hugs installation. I've also made the double-clickable launcher icons work correctly with directory names that contain spaces. Cheers, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] invalid character encoding
I've got some gzip (and Ian Lynagh's Inflate) code that breaks under the new hugs with: handle: IO.getContents: protocol error (invalid character encoding) What is going on, and how can I fix it? Thanks, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
