GHC 6 on sparc-*-*
Hey all, I've packaged up two sparc ports. Binary distributions of GHC 6.0.1 with profiling, for: sparc-unknown-openbsd3.4 ftp://ftp.cse.unsw.edu.au/pub/users/dons/ghc/6.0.1/ghc-6.0.1-sparc-unknown-openbsd.tgz sparc-sun-solaris2.6 ftp://ftp.cse.unsw.edu.au/pub/users/dons/ghc/6.0.1/ghc-6.0.1-sparc-sun-solaris2.6.tgz Maybe SimonM can add them to the 6.1 page.. Cheers, Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Fri, Sep 12, 2003 at 10:59:05AM +0100, Simon Marlow wrote: Looks like you need some mangler support now... Am I right in thinking that by just putting GhcUnregisterised=YES SplitObjs=NO in mk/build.mk every time you build GHC it ought to not only work on arches with bit-rotted mangler support but also those with none attempted? Where work means compiles the same set of programs, but the result (as well as the compilation) will be slower? Starting with a reg compiler producing reg code and iterating a standard configure/make/make install with 6.0.1 gives these numbers on x86: 70m5.850s 86m27.550s 86m26.350s so it looks like this is about 25% slower, although I don't know how much it will vary by architecture. This isn't purely testing GHC of course, but I think it's probably pretty close. This seems better than no GHC at all for unsupported arch/OS combinations, and I unfortunately don't have the time to learn the details of what needs to be done and all the assembly languages and calling conventions that Debian supports. It would also mean that anyone who does want to try to get it working registerised on an arch could skip the cross-porting stage. Incidentally, it looks to me like the comment # NOTE: this is not the same as building the compiler itself # unregisterised. That's done by either (a) bootstrapping with a # compiler that was built with GhcUnregisterised=YES, or (b) # bootstrapping with a compiler that has way 'u' libraries, and the # flag '-unreg' is added to GhcHcOpts above. about GhcUnregisterised in mk/config.mk is outdated given the 2-stage building process that is now the default? Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Circular Instance Declarations
On Thu, 11 Sep 2003, Simon Peyton-Jones wrote:
OK, I yield!
The HEAD now runs this program. It turned out to be a case of
interchanging two lines of code, which is the kind of fix I like.
Simon
Cool! Yet another domain where haskell handles infinities quite happily.
Thanks.
Hopefully I'll have some code to contribute soon.
Brandon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ashley Yakeley
| Sent: 07 September 2003 06:57
| To: [EMAIL PROTECTED]
| Subject: Circular Instance Declarations
|
| When -fallow-undecidable-instances is switched on, is there any reason
| why circular instances are forbidden? For instance:
|
| module CircularInsts where
| {
| data D r = ZeroD | SuccD (r (D r));
|
| instance (Eq (r (D r))) = Eq (D r) where
| {
| ZeroD == ZeroD = True;
| (SuccD a) == (SuccD b) = a == b;
| _ == _ = False;
| };
|
| newtype C a = MkC a deriving Eq;
|
| equalDC :: D C - D C - Bool;
| equalDC = (==);
| }
|
| When I compile this, I get this:
|
| $ ghc -fglasgow-exts -fallow-undecidable-instances -c
CircularInsts.hs
| CircularInsts.hs:2:
| Context reduction stack overflow; size = 21
| Use -fcontext-stack20 to increase stack size to (e.g.) 20
| `Eq (C (D C))' arising from use of `==' at CircularInsts.hs:16
| `Eq (D C)' arising from use of `==' at CircularInsts.hs:16
| `Eq (C (D C))' arising from use of `==' at CircularInsts.hs:16
| `Eq (D C)' arising from use of `==' at CircularInsts.hs:16
|
| Would it be reasonable for the compiler to check back through the
stack
| and allow the circularity? It will just create an ordinary recursive
| function.
|
| --
| Ashley Yakeley, Seattle WA
|
| ___
| Haskell mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: lexer puzzle
Dnia nie 14. wrzenia 2003 01:04, Derek Elkins napisa: A... A (constructor), then ... (operator). This is how I understand Haskell 98 lexing rules. My first thought was that it should produce, A.. ., as in (.) (A..), but obviously that would be wrong as A.. must be a function and therefore to be passed to (.) it would need to be (A..). Argh, I was wrong. It's A.. (qualified operator), then . (operator). So it's syntax error recognized during parsing. I take this to mean the (..) function from the Prelude module. .. is a reserved operator, used for ranges. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
YAHT Problem
Hello, I am going through YAHT again, using galeon and redhat 7.3.Galeon is apparently using xpdf to diaplay the tutorial. There are some things that are not displayed. For example, in 3.1 Arithmetic, on about the sixth line, it says : For instance, the number is an _expression_ (its value is ).Does anyone have an idea why I'm not seeing the number and its value, and how I can fix this? Thank you. Sincerely, Mark Get your free e-mail address at http://felinemail.zzn.com__http://www.zzn.com ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: An IO Question from a Newbie
Brandon Michael Moore wrote: Hal was pretty terse, so I'll explain why switching to putStrLn will help. stdout is line buffered. At least by default (see hSetBuffering). That means output will only be flushed to the screen once a newline is written. Your prompt wasn't printed because it didn't have a newline, so it was buffered until the second print provided one (read from the user, by way of s). This is hardly specific to Haskell. Try this C program: But there's one significant difference between C and Haskell, which is applicable in the case of Matt's program. In C, any line-buffered output streams are automatically flushed when a read from an unbuffered or line-buffered stream can't be satisfied from its buffer. Also, it seemed fairly clear from Matt's original message that: a) he didn't want to have to force a new-line (he noted that doing so eliminated the problem), and b) he understood the concept of flushing, but presumably didn't know how to do it in Haskell. While we're on the subject, I'll point out a couple of other differences between the buffering in ANSI C's stdio library and Haskell's: 1. In Haskell, you can change the buffering mode at any point; in C, you have to change it before any data is read from or written to the stream, otherwise the behaviour is undefined. 2. For an input stream which is associated with a tty, changing the buffering mode may also change the terminal settings (setting it to unbuffered disables canonical mode while setting it to line-buffered or fully-buffered enables it). -- Glynn Clements [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: An IO Question from a Newbie
On Sun, 14 Sep 2003, Glynn Clements wrote: Brandon Michael Moore wrote: Hal was pretty terse, so I'll explain why switching to putStrLn will help. stdout is line buffered. At least by default (see hSetBuffering). That means output will only be flushed to the screen once a newline is written. Your prompt wasn't printed because it didn't have a newline, so it was buffered until the second print provided one (read from the user, by way of s). This is hardly specific to Haskell. Try this C program: But there's one significant difference between C and Haskell, which is applicable in the case of Matt's program. In C, any line-buffered output streams are automatically flushed when a read from an unbuffered or line-buffered stream can't be satisfied from its buffer. Interesting. I didn't know this. Maybe we should match this behaviour, or provide a write-string-and-flush function. It seems like this issue is causing an undue amound of trouble. Also, it seemed fairly clear from Matt's original message that: a) he didn't want to have to force a new-line (he noted that doing so eliminated the problem), and I should note here that there is a gnu readline binding distributed with GHC. It's undocumented, but it seems to follow the C API pretty closely, and you can make a decent interface using only two of the functions. b) he understood the concept of flushing, but presumably didn't know how to do it in Haskell. While we're on the subject, I'll point out a couple of other differences between the buffering in ANSI C's stdio library and Haskell's: 1. In Haskell, you can change the buffering mode at any point; in C, you have to change it before any data is read from or written to the stream, otherwise the behaviour is undefined. 2. For an input stream which is associated with a tty, changing the buffering mode may also change the terminal settings (setting it to unbuffered disables canonical mode while setting it to line-buffered or fully-buffered enables it). -- Glynn Clements [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
zlib binding providing Handle to compressed file.
I've just created a binding to the gzopen function of zlib which causes it
to create a Handle. The code currently only supports ReadMode and
WriteMode, and hFileSize won't work properly when reading a file. In fact,
pretty much nothing but plain old reading and writing will work, but such
is life.
Anyhow in case anyone is interested, I'm attaching the code. It creates a
pipe using pipe(2) and spawns a thread to pass the data between the pipe
and gzread or gzwrite. It's not pretty, but it's better than any other
solution I could think of. Suggestions or criticisms are welcome.
--
David Roundy
http://www.abridgegame.org/darcs
\begin{code}
module Zlib ( gzOpenFile, gzWriteFile, gzReadFile ) where
import IO
import System.IO ( hGetBuf, hPutBuf )
import Control.Concurrent ( forkIO )
import Monad ( when )
import Foreign.C.String ( CString, withCString )
import Foreign.Marshal.Array ( mallocArray, withArray, peekArray )
import Foreign.Marshal.Alloc ( free )
import Foreign.Ptr ( Ptr )
import Data.Word
import GHC.Handle ( openFd )
fdToReadHandle fd fn = openFd fd Nothing fn ReadMode False False
fdToWriteHandle fd fn = openFd fd Nothing fn WriteMode False False
gzOpenFile :: FilePath - IOMode - IO Handle
gzWriteFile :: FilePath - String - IO ()
gzOpenFile f ReadMode =
withCString f $ \fstr - withCString rb $ \rb- do
gzf - c_gzopen fstr rb
withArray [0,0] $ \fds - do
err - c_pipe fds
when (err /= 0) $ error Pipe problem!
[infd,outfd] - peekArray 2 fds
writeH - fdToWriteHandle (fromIntegral outfd) f
buf - mallocArray 1024
forkIO $ gzreader gzf writeH buf
fdToReadHandle (fromIntegral infd) f
where gzreader gzf h buf =
do done - hIsClosed h
if done
then do c_gzclose gzf
free buf
hClose h
else do l - c_gzread gzf buf 1024
hPutBuf h buf l
if l 1024
then do free buf
c_gzclose gzf
hClose h
else gzreader gzf h buf
gzOpenFile f WriteMode =
withCString f $ \fstr - withCString wb $ \wb- do
gzf - c_gzopen fstr wb
withArray [0,0] $ \fds - do
err - c_pipe fds
when (err /= 0) $ error Pipe problem!
[infd,outfd] - peekArray 2 fds
readH - fdToReadHandle (fromIntegral infd) f
buf - mallocArray 1024
forkIO $ gzwriter gzf readH buf
fdToWriteHandle (fromIntegral outfd) f
where gzwriter gzf h buf =
do done - hIsEOF h
if done
then do c_gzclose gzf
free buf
hClose h
else do l - hGetBuf h buf 1024
c_gzwrite gzf buf l
gzwriter gzf h buf
gzWriteFile f s = do h - gzOpenFile f WriteMode
hPutStr h s
hClose h
gzReadFile f s = do h - gzOpenFile f WriteMode
hGetContents h
foreign import ccall unsafe static unistd.h pipe c_pipe
:: Ptr Int - IO Int
foreign import ccall unsafe static unistd.h read c_read
:: Ptr Word8 - Int - IO Int
foreign import ccall unsafe static zlib.h gzopen c_gzopen
:: CString - CString - IO (Ptr ())
foreign import ccall unsafe static zlib.h gzclose c_gzclose
:: Ptr () - IO ()
foreign import ccall unsafe static zlib.h gzread c_gzread
:: Ptr () - Ptr Word8 - Int - IO Int
foreign import ccall unsafe static zlib.h gzwrite c_gzwrite
:: Ptr () - Ptr Word8 - Int - IO ()
\end{code}
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: threaded red-black tree
On Sun, 2003-09-14 at 21:48, Lex Stein wrote: Hi, No one responded to my question several weeks ago about a purely functional implementation of a threaded, red-black tree. I'm not sure what you mean by threaded. By simply ignoring that word, I come up with the following solution :-) There is a purely functional implementation of a red-black tree in the MetaPRL system (www.metaprl.org), written in OCaml. For the latest CVS version of this red-black tree code, go to http://cvs.metaprl.org:12000/cvsweb/metaprl/libmojave/stdlib/ (look at lm_map.ml and lm_set.ml). Carl Witty ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
