Re: runghc printing result of main when main is not IO ()
On Thu, Aug 30, 2007 at 08:33:37AM +0100, Simon Marlow wrote: Tomasz Zielonka wrote: Hello! Consider: $ cat R.hs main = return [()] $ runghc R.hs [()] This was a bit surprising for me, because I thought that runghc mimics the way a compiled program behaves. This doesn't happen with 6.6.1, I believe we fixed it at some point by having runghc perform main return () instead of just main. Great! I'm sorry for not checking with a recent version :-/ Best regards Tomek ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
runghc printing result of main when main is not IO ()
Hello! Consider: $ cat R.hs main = return [()] $ runghc R.hs [()] This was a bit surprising for me, because I thought that runghc mimics the way a compiled program behaves. Best regards Tomek ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Vote for GHC 6.8 bugs!
On Tue, Jul 03, 2007 at 09:28:35AM +0100, Simon Peyton-Jones wrote: We have just instituted a cheap-and-cheerful mechanism for voting. Each bug has a 'cc' field. To vote, just add your email address to the cc field! How should we separate email addresses? Right now people use different characters: space, comma or semicolon. Best regards Tomek ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Tell GHC HQ if you'd like this to unify the context
Hello!
I've got such a compilation error on code that was accepted by an
earlier GHC:
Expr/Names.hs:19:66:
GADT pattern match in non-rigid context for `TypeInt'
Tell GHC HQ if you'd like this to unify the context
In the pattern: TypeInt
In the pattern:
FunctionInfo {fiName = name, fiReturnType = TypeInt}
In the pattern:
Call (FunctionInfo {fiName = name, fiReturnType = TypeInt}) [dyn]
This was in a module which had no {-# OPTIONS_GHC -fglasgow-exts #-}.
I was preparing to file a bug report, but then I noticed that it's
enough to put -fglasgow-exts there to make the code compile.
I am reporting it because it may be confusing to others. Perhaps it
would be a good idea to advise trying -fglasgow-exts in the error
message?
Best regards
Tomasz
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci value printing
On Fri, Apr 27, 2007 at 03:22:26PM +0100, Frederik Eaton wrote: I like the new printing behaviour for (a1), but not for (b1). How do I bind a variable to the result of an IO action without printing that variable? It seems that the value is not printed when there are more than one pattern variables. You can use this to avoid printing: quiet @ x - return 5 I don't know it that's intented. Anyway, I would rather have the old behaviour by default, with the new one switched on by some :set option. Pozdrawiam Tomek ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
On Thu, Sep 28, 2006 at 12:42:50PM +0100, Ian Lynagh wrote: On Thu, Sep 28, 2006 at 09:07:33AM +0200, Tomasz Zielonka wrote: Great! Which snapshot can I use to test this change? Tonight's or later - there isn't one yet. As I wrote in another message to glasgow-haskell-bugs, there are some problems with snapshots (bunzip2 complains about corrupted data). The recent ghc-6.5.20060928-i386-unknown-linux.tar.bz2 has those problems too. I will compile GHC from sources now. Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Broken snapshot archives
On Fri, Sep 29, 2006 at 12:30:10PM +0100, Simon Marlow wrote: Tomasz Zielonka wrote: Some recent GHC snapshot files seem to be broken. Yes, this is due to a long-standing problem with our firewalls that sometimes cause corruption of an SSH connection. I'll try to make it retry or delete the file on failure instead of leaving a broken tarball in place. Try using rsync. It doesn't leave partially transferred files (unless you ask it to do it). The file on the target machine is first created with a different name, and renamed to the final name only if it was transferred successfully. rsync can work over SSH, and in the basic scenario has similar command-line options. Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
On Fri, Sep 29, 2006 at 11:00:25AM +0200, Tomasz Zielonka wrote: I will compile GHC from sources now. The stats seem to be OK now. Thanks! Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
On Thu, Sep 28, 2006 at 01:57:18AM +0100, Ian Lynagh wrote: I've found a machine which had the same problem. I think I've fixed it with Thu Sep 28 00:46:30 BST 2006 Ian Lynagh [EMAIL PROTECTED] * Handle clock_gettime failing Great! Which snapshot can I use to test this change? Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Broken snapshot archives
Hello! Some recent GHC snapshot files seem to be broken. For example with http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060927-i386-unknown-linux.tar.bz2 I get: $ tar jxf ghc-6.5.20060927-i386-unknown-linux.tar.bz2 bzip2: Compressed file ends unexpectedly; perhaps it is corrupted? *Possible* reason follows. bzip2: Inappropriate ioctl for device Input file = (stdin), output file = (stdout) It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
On Wed, Sep 27, 2006 at 09:25:39AM +0100, Simon Marlow wrote: Perhaps clock_gettime() is returning strange results on your system. Could you try compiling with -threaded -debug, and run the program under gdb. When I compile with -threaded -debug, the stats are OK :-/ Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
On Wed, Sep 27, 2006 at 12:06:34PM +0100, Simon Marlow wrote:
When I compile with -threaded -debug, the stats are OK :-/
Ok, maybe try strace?
Nothing suspicious, at least for me. Strace logs attached.
I'll try to compile GHC from sources and put some debugging
prints in the RTS. There aren't too many places where Task's
mut_time field is referenced. I just hope it's not some
other code overwriting this memory.
Best regards
Tomasz
execve(./B, [./B, +RTS, -sstderr], [/* 22 vars */]) = 0
uname({sys=Linux, node=gfs6, ...}) = 0
brk(0) = 0x8082000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xa7f23000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=17489, ...}) = 0
mmap2(NULL, 17489, PROT_READ, MAP_PRIVATE, 3, 0) = 0xa7f1e000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/libm.so.6, O_RDONLY)= 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`3\0\0004\0\0\0`B\2\0\0\0\0\0004\0
\0\10\0(\0\36\0\35\0\6\0\0\0004\0\0\0004\0\0\0004\0\0\0\0\1\0\0\0\1\0\0\5\0\0\0\4\0\0\0\3\0\0\0\370\2\0\370\2\0\370\2\0\23\0\0\0\23\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20=\2\0\20=\2\0\5\0\0\0\0\20\0\0\1\0\0\0\344\2\0\344N\2\0\344N\2\0x\1\0\0\274\1\0\0\6\0\0\0\0\20\0\0\2\0\0\0\370\2\0\370N\2\0\370N\2\0\340\0\0\0\340\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0004\1\0\0004\1\0\0004\1\0\0
\0\0\0
\0\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0R\345td\344\2\0\344N\2\0\344N\2\0\20\1\0\0\20\1\0\0\4\0\0\0\4\0\0\0\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\0\0\0\0]\2\0\0`\1\0\0\216\0\0\0_\1\0\0\205\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\250\0\0\0\0\0\0\0\0\0\0\0N\1\0\0\0\0\0\0A\1\0\0\0\0\0\0\0\0\0\0\370\0\0\0\304\0\0\0\32\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\277\0\0\0\325\0\0\0\371\0\0\0\0\0\0\0\0\0\0\0?\0\0\0\0\0\0\0F\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0)\1\0\0\1\0\0\0\0\0\0\r\1\0\0\0\0\0\0\0\0\0\0,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=149264, ...}) = 0
mmap2(NULL, 151712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xa7ef8000
mmap2(0xa7f1c000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23) = 0xa7f1c000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/libdl.so.2, O_RDONLY) = 3
read(3, [EMAIL PROTECTED]
\0\10\0(\0\33\0\32\0\6\0\0\0004\0\0\0004\0\0\0004\0\0\0\0\1\0\0\0\1\0\0\5\0\0\0\4\0\0\0\3\0\0\0\252\32\0\0\252\32\0\0\252\32\0\0\23\0\0\0\23\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\304\32\0\0\304\32\0\0\5\0\0\0\0\20\0\0\1\0\0\0\324\36\0\0\324.\0\0\324.\0\0|\1\0\0\240\1\0\0\6\0\0\0\0\20\0\0\2\0\0\0\354\36\0\0\354.\0\0\354.\0\0\340\0\0\0\340\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0004\1\0\0004\1\0\0004\1\0\0
\0\0\0
\0\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0R\345td\324\36\0\0\324.\0\0\324.\0\0
\1\0\0
\1\0\0\4\0\0\0\4\0\0\0\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\0\0\0\0A\0\0\0002\0\0\0\35\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0-\0\0\0\r\0\0\0\22\0\0\0\33\0\0\0/\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0$\0\0\0\21\0\0\0\31\0\0\0\17\0\0\0#\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0.\0\0\0\0\0\0\0\16\0\0\0\24\0\0\0\0\0\0\0)\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0001\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9592, ...}) = 0
mmap2(NULL, 12404, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xa7ef4000
mmap2(0xa7ef6000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xa7ef6000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/librt.so.1, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\35\0\0004\0\0\0\274r\0\0\0\0\0\0004\0
\0\t\0(\0\37\0\36\0\6\0\0\0004\0\0\0004\0\0\0004\0\0\0 \1\0\0
\1\0\0\5\0\0\0\4\0\0\0\3\0\0\0\214]\0\0\214]\0\0\214]\0\0\23\0\0\0\23\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\352_\0\0\352_\0\0\5\0\0\0\0\20\0\0\1\0\0\0\320n\0\0\320n\0\0\320n\0\0\270\2\0\0\200\3\0\0\6\0\0\0\0\20\0\0\2\0\0\0\354n\0\0\354n\0\0\354n\0\0\360\0\0\0\360\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0T\1\0\0T\1\0\0T\1\0\0
\0\0\0
\0\0\0\4\0\0\0\4\0\0\0P\345td\240]\0\0\240]\0\0\240]\0\0\\\0\0\0\\\0\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0R\345td\320n\0\0\320n\0\0\320n\0\0$\1\0\0$\1\0\0\4\0\0\0\4\0\0\0\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\0\0\0\0\331\0\0\0~\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
Bogus stats when running SMP programs
Hello! I am getting nonsensical execution statistics (+RTS -Sstderr) when running programs in SMP mode (+RTS -N2). Example: Task 0 (worker) : MUT time: 401572821.14s ( 21.89s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 1 (worker) : MUT time: 296.00s ( 21.90s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 2 (worker) : MUT time: 0.00s ( 21.91s elapsed) GC time: 3.47s ( 3.38s elapsed) Task 3 (worker) : MUT time: 401583421.14s ( 21.91s elapsed) GC time: 0.00s ( 0.00s elapsed) I am using ghc-6.5.20060919-i386-unknown-linux.tar.bz2 on Intel(R) Pentium(R) D CPU 3.20GHz (dual core) with kernel 2.6.16-2-686-smp (Debian 2.6.16-17). Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: weird data corruption
On Thu, Aug 24, 2006 at 01:12:32AM +0100, Frederik Eaton wrote: Do you think that the standard GHC behavior should be for multithreaded programs to produce garbage on stderr? IIUC, even if you switch to LineBuffering on stderr, you'll still get garbage, only less often and in more subtle ways, at least if we don't go beyond what H98 guarantees: line-buffering: the entire buffer is written out whenever a newline is output, the buffer overflows, a flush is issued, or the handle is closed. As you can see, it is still possible that an incomplete line is written when buffer overflows. The safest solution is to make your logging code serialize the log entries, using a mutex, a Chan or whatever - just what you did. C is different because it's not lazy. Usually small lines are printed to stderr; they fit in a single 'write' call and even if there are multiple such calls they usually happen within the same processor timeslice. But this is nothing you can rely on. Of course, it can be enough for simple logging. I think that in the GHC runtime, the default buffering mode for stderr should be line buffering (or perhaps, the same rules as for stdout should apply). I've modified my logging library to pre-evaluate strings with 'seq' and to use locking when writing messages to 'stderr', so it is no longer a problem for me personally; but for new users, for general-purpose use of the compiler, I think changing the stderr buffering mode is the best solution. I seem to remember some people argued that switching stdout to NoBuffering would make things easier for new users. Let's also change stderr buffering mode, as you suggest. Now that's an ideal configuration! ;-) BTW, why didn't use simply change the buffering mode yourself? Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Space leak
On Tue, Dec 27, 2005 at 08:12:20PM +0100, Christian Maeder wrote: Already the following bit exhibits unexpected memory consumption: main = mapM_ print $ take (n * 5) $ drop (n * 3) [1..] n = 10 Dropping the elements is more expensive than printing them. Somehow the dropped elements are kept in memory. I think it's the (succ (succ (succ ...))) thunk. When you change it to [1..] there is no space leak - here every produced element must be examined before producing the next list node or []. Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #638: Patch to make Control.Monad.replicateM_ faster
On Sat, Dec 17, 2005 at 05:26:33PM +0100, Tomasz Zielonka wrote: Are you sure it is really more efficient? I remember that I was amazed that GHC compiled my (sequence_ $ repeat $ ...) code to a really tight loop with no allocations. Hmmm... perhaps no allocations is not surprising with repeat, which simply creates a self-referring list, but still AFAIR the generated code did not create lists at all. Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #638: Patch to make Control.Monad.replicateM_ faster
On Sat, Dec 17, 2005 at 03:58:19PM -, GHC wrote: #638: Patch to make Control.Monad.replicateM_ faster --+- Reporter: ekarttun@cs.helsinki.fi | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base |Version: 6.4.1 Severity: minor| Resolution: Keywords: | Os: Multiple Difficulty: Unknown | Architecture: Multiple --+- Comment (by ekarttun@cs.helsinki.fi): Patch available as http://cs.helsinki.fi/u/ekarttun/haskell/replicateM_.patch Trac does not seem to like me uploading attachments... Are you sure it is really more efficient? I remember that I was amazed that GHC compiled my (sequence_ $ repeat $ ...) code to a really tight loop with no allocations. Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] Project postmortem
On Fri, Dec 02, 2005 at 11:20:54AM -, Simon Marlow wrote: If anyone is interested, this turned out to be a bug in the Network.BSD module, namely that getHostByName isn't thread safe because it is based on the C library function gethostbyname(), which returns data in a single static area. Workarounds are: - do your own mutual exclusion locking around getHostByName and any function that calls it (eg. connectTo). - use Network.Alt (http://www.cs.helsinki.fi/u/ekarttun/network-alt/), which has a thread-safe implementation of getHostByName. - wait for 6.4.2, which will contain a fix for this bug (we don't have a fix committed yet, Einar Karttunen has kindly offered to look into it). Do I understand correctly that another workaround is - don't compile your programs with -threaded ? Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] Project postmortem
On Fri, Dec 02, 2005 at 12:39:25PM -, Simon Marlow wrote: Do I understand correctly that another workaround is - don't compile your programs with -threaded ? No, the bug isn't related to -threaded. It still occurs without -threaded. Let's check that now I understand - so the sequence call gethostbyname read the returned hostent is written in Haskell, and many such sequences can be interleaved when using Concurrent Haskell? Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] mistake in Gentle Introduction
On 9/22/05, Simon Marlow [EMAIL PROTECTED] wrote:
On 22 September 2005 10:05, Christian Maeder wrote: The error message on this is really poor: parse error on input `length' An addition like expecting '(' might be more helpful.
Not easy to do - some significant work on Happy would be required (orrewriting GHC's parser, which is even more unlikely).However we *would* like to do some simple error recovery in the parserat some point.The main reason for doing this is to get better results
from checking partially complete modules in Visual Haskell or hIDE.
How about using the parser made by Arthur Baars, trading speed for better error messages?
Maybe even the speed issue could be solved.
Best regards
Tomasz
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: stdin set to nonblocking mode
On Fri, Aug 12, 2005 at 07:43:56AM -0700, John Meacham wrote: Hmm, care to give some details as to why you equate can with always will on all platforms? Yes. this is guarenteed behavior on pretty much every system. A whole lot of things would break if it were otherwise. if select says a file descriptor can be written to or read from then the next write or read call is guarenteed to not block, no matter what its size. (you just may get a short read or write) However, this next read/write doesn't have to be the one you call right after select - it could be called in another process/thread, which shares the open socket or pipe. Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: the impossible happened
On Mon, May 23, 2005 at 09:38:58AM +0100, Simon Peyton-Jones wrote: This fromJust bug is SourceForge 1177320. The trouble is that we've been unable to reproduce it here. It seems to show up when compiling some large thing, like Darcs or WASH. If anyone would be willing to snapshot a tree exhibiting the bug, and send it to us, we'd love to investigate. Until then we're a bit stuck. It seems that there are not that many uses of fromJust in GHC's sources. I guess that removing them or at least making them report a source location in case of failure (for example using a CPP macro like in darcs) would be an good task for a wannabe GHC hacker. Unfortunately, I can't volunteer at this moment. Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Unused variable warnings when deriving (Data)
Hello!
When I compile the following module with ghc -W -c A.hs I see several
unnecessary warning messages:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.4
$ ghc -no-recomp -W -c A.hs
no location info: Warning: Defined but not used: `k'
no location info: Warning: Defined but not used: `k'
no location info: Warning: Defined but not used: `k'
Adding parameters to data constructors makes the warnings disappear,
example:
data T = A Int | B Char
A.hs ---
{-# OPTIONS -fglasgow-exts #-}
module A where
import Data.Generics
data T = A | B
deriving (Typeable, Data)
-
Best regards
Tomasz
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: environment variables for ghc
On Wed, Mar 09, 2005 at 10:01:40AM -0800, Frederik Eaton wrote: On Wed, Mar 09, 2005 at 05:19:18PM -, Simon Marlow wrote: On 09 March 2005 08:29, Frederik Eaton wrote: Oh, is that the only reason? That's a terrible reason to not have a feature. :) You could just write a 'ghcbug' script which includes all information automatically. See the output of 'perlbug -d' for example. I guess I could write a wrapper to add the options myself ... but is everybody supposed to do this who has a package.conf in their home directory, or some common set of utility modules somewhere? It seems like a fairly common use case that should be well-supported in a standard way out of the box. I was complaing (only to myself) that rsync doesn't allow to put some common options in ~/.rsyncrc or an environment variable. Then I simply added an alias in my .bash_profile: alias rsync='rsync -v --progress' Unfortunately, this is still something that developers would like to know when facing a bug report :) Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: environment variables for ghc
On Wed, Mar 09, 2005 at 11:55:11AM -0800, Frederik Eaton wrote: I am still not convinced that it is a good idea to add such functionality to GHC. Do you want to persuade developers of every program you use to add similar feature? Is the perceived difficulty of that task an argument against improving ghc? No, it's about avoiding unneccesary complexity. I agree that the case you're presenting is indeed more difficult, but I don't think you're doing the estimations right for the one at hand. The cost and annoyance of perhaps tens of thousands of people adding and remembering to maintain wrappers named 'ghc' somewhere in their path to accomplish this simple task (after scrounging in the documentation to find that ghc for some reason fails to be like many other compilers, a nontrivial cost in itself since the lack of environment variables isn't specifically documented) - or simply not doing so, and typing in -package-conf hundreds of times as I have done, because they may not have write access to the main package.conf - I think outweighs the cost of one person, once, adding central support for environment variables, a bit of documentation in the man page, perhaps a ghcbug program if we want super-detailed bug reports... Are you volunteering to be that person? ;-) Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: environment variables for ghc
On Wed, Mar 09, 2005 at 01:12:49PM -0800, Frederik Eaton wrote: Are you volunteering to be that person? ;-) Are you saying that a patch would be accepted? I am not the one to decide. Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Buglet in :info (ghc 6.2.2)
Hello, This happens in GHC 6.2.2: Prelude let lf $$$ lx = zipWith ($) lf lx Prelude :i $$$ -- $$$ is a variable, defined at interactive:1 ($$$) :: forall b b. [b - b] - [b] - [b] Prelude :t ($$$) ($$$) :: forall b b1. [b1 - b] - [b1] - [b] Note the difference in types presented by :info and :type. Also note that in :info there are two 'b' variables between 'forall' and dot. Best regards, Tomasz ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: SegFault caused by some IO+Arrays+GC interaction
On Mon, Jun 28, 2004 at 12:07:32PM +0100, Simon Marlow wrote: Thanks for a superb bug report. This bug appears to be another incarnation of a bug that has been fixed since 6.2.1. I used the 6.2.1 compiler but linked the program against the latest runtime on the 6.2 branch, which is identical except for this single fix, and the crash went away. I am pleased to see that it's already fixed. Anyway, next time I will test with a development version of the compiler before sending a bug report. So you can either wait for 6.2.2 (shouldn't be too long), use a nightly snapshot of the 6.2 branch, or build from source. Or if you have an existing 6.2.1 build locally, I can put together a patch for this fix - let me know. Sure, I'll test the snapshot in a moment. Thanks, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: SegFault caused by some IO+Arrays+GC interaction
On Mon, Jun 28, 2004 at 01:38:42PM +0200, Tomasz Zielonka wrote: On Mon, Jun 28, 2004 at 12:07:32PM +0100, Simon Marlow wrote: So you can either wait for 6.2.2 (shouldn't be too long), use a nightly snapshot of the 6.2 branch, or build from source. Or if you have an existing 6.2.1 build locally, I can put together a patch for this fix - let me know. Sure, I'll test the snapshot in a moment. OK, now it doesn't crash. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
SegFault caused by some IO+Arrays+GC interaction
Hello!
The attached program uses no unsafe operations and yet it segfaults from
time to time. Try it on some file of moderate size, like:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.2.1
$ ghc -O --make Bug -o Bug
Chasing modules from: Bug
Compiling Main ( Bug.hs, Bug.o )
Linking ...
$ ls -l /etc/termcap
-rw-r--r--1 root root 737535 lip 20 2001 /etc/termcap
$ ./Bug /etc/termcap /dev/null
Segmentation fault (core dumped)
$ ./Bug /etc/termcap /dev/null
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.2.1
$ gcc --version
gcc (GCC) 3.3.3
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ uname -a
Linux green.local.gem.pl 2.4.18-10 #1 Wed Aug 7 10:26:48 EDT 2002 i686
unknown
Notice that this program calls performGC after every processed word
and commenting this out seems to eliminate the problem. Perhaps this
is a silly thing to do, but I don't think it should result in SEGV.
If this qualifies as a bug, tell me if I can do anything to help you
nail it down.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
import Data.Array.IO
import Data.Array.Unboxed
import Data.Array.Base
import Data.Array.ST
import Data.Word
import System.IO
import System.IO.Unsafe
import Control.Monad.ST
import Control.Monad
import System.Mem
main :: IO ()
main = do
ws - getArrayWords
(`mapM_` ws) $ \w - do
ioarr - thaw w
putArray ioarr
putStrLn
performGC
putArray :: IOUArray Int Word8 - IO ()
putArray arr = do
when (rangeSize (bounds arr) 0) $ hPutArray stdout arr (rangeSize (bounds arr))
getArrays :: IO [UArray Int Word8]
getArrays = {- unsafeInterleaveIO $ -} do
ioarr - newArray (0, blockSize-1) 0 :: IO (IOUArray Int Word8)
n - hGetArray stdin ioarr blockSize
case n of
0 - do
return []
_ | n 0 - do
arr0 - freeze ioarr
arr -
if n blockSize
then do
return (array (0, n-1) [ (i, arr0 ! i) | i - [0..n-1] ])
else do
return arr0
arrs - getArrays
return (arr : arrs)
where
blockSize :: Int
blockSize = 2 ^ (16 :: Int)
findInArray p arr pos =
loop pos
where
rbound = snd (bounds arr)
loop i | i rbound= Nothing
| p (arr ! i) = Just i
| otherwise = loop $! (i + 1)
getArrayWords :: IO [UArray Int Word8]
getArrayWords = do
blocks - getArrays
return (buildWords 0 blocks)
where
buildWords pos bs =
skipWhiteSpace pos bs $
\pos bs -
case findInBuffers isWhite pos bs of
Just (Right whitePos) -
takeArray pos bs whitePos $
\w pos bs - w : buildWords pos bs
Just (Left charsLeft) -
takeArray pos bs charsLeft $
\w pos bs - [w]
Nothing -
[]
findInBuffers :: (Word8 - Bool) - Int - [UArray Int Word8] - Maybe (Either Int Int)
findInBuffers = findInBuffersAcc 0
where
findInBuffersAcc acc p pos (buf:bufs) =
case findInArray p buf pos of
Just nlPos - Just (Right (acc + nlPos - pos))
Nothing - (findInBuffersAcc $! acc + snd (bounds buf) - pos + 1) p 0 bufs
findInBuffersAcc 0 _ _ [] = Nothing
findInBuffersAcc acc _ _ [] = Just (Left acc)
isWhite :: Word8 - Bool
isWhite c = c == 10 || c == 13 || c == 9 || c == 32
skipWhiteSpace pos (bufs@(b:bs)) cont
| not (isWhite (b ! pos)) = cont pos bufs
| pos == snd (bounds b) = skipWhiteSpace 0 bs cont
| otherwise = (skipWhiteSpace $! (pos+1)) bufs cont
skipWhiteSpace pos [] cont = cont pos []
takeArray pos0 bs0 len cont =
runST (do
marr - newArray (0, len-1) 0 :: ST s (STUArray s Int Word8)
fillArray marr 0 pos0 bs0
)
where
fillArray marr marrPos pos bufs = do
if marrPos == len
then do
arr - freeze marr
return (cont arr pos bufs)
else do
let (b:bs) = bufs
remain = len - marrPos
inThisArray = snd (bounds b) - pos + 1
if inThisArray = remain
then do
copyFromArray b pos marr marrPos inThisArray
fillArray marr (marrPos + inThisArray) 0 bs
else do
-- inThisArray remain
copyFromArray b pos marr marrPos remain
fillArray marr (marrPos + remain) (pos + remain) (b:bs)
copyFromArray src srcPos dst dstPos count
| count 0 = do
Re: ghc-6.2 bug in type inference
On Fri, Feb 06, 2004 at 11:13:57AM +, Malcolm Wallace wrote:
* -fglasgow-exts makes perfectly reasonable Haskell'98 code
invalid, throws up a totally misleading error unrelated to the
cause of the problem, and gives no clue as to what particular
extension is responsible.
That's linear implicit parameters.
Try putting whitespace between % and s.
If you use -fglasgow-exts you have to know almost all language
extensions supported by GHC. Therefore I think that packages shouldn't
implicitly add -fglasgow-exts. It should be sufficient to place
{-# OPTIONS -fglasgow-exts #-} pragma in modules that need these
extensions.
Best regards,
Tomek
--
.signature: Too many levels of symbolic links
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
On Thu, Dec 18, 2003 at 09:53:50PM +0100, Tomasz Zielonka wrote: On Thu, Dec 18, 2003 at 07:44:58PM +0100, George Russell wrote: It seems to work when I change hGetBuf to hGetBufNonBlocking. The name is a bit misleading - the action _does_ wait for some data, but it doesn't wait for all requested bytes. I've made a mistake here. hGetBuf waits for filling the whole Handle's reading buffer (or reaching EOF), even if the buffer contains enough data to satisfy the request. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
On Fri, Dec 19, 2003 at 10:26:02AM -, Simon Marlow wrote: On Thu, Dec 18, 2003 at 09:53:50PM +0100, Tomasz Zielonka wrote: On Thu, Dec 18, 2003 at 07:44:58PM +0100, George Russell wrote: It seems to work when I change hGetBuf to hGetBufNonBlocking. The name is a bit misleading - the action _does_ wait for some data, but it doesn't wait for all requested bytes. I've made a mistake here. hGetBuf waits for filling the whole Handle's reading buffer (or reaching EOF), even if the buffer contains enough data to satisfy the request. I'm a bit lost. Do things work as you expect, or not? Well, I think that it would be better if hGetBuf didn't block if all requested data was already in buffer, but I don't insist on it. However this change of semantics can brake existing programs. In my programs I rather use Data.Array.IO.hGetArray. I was only trying to help George. I am sorry if I only made things more complicated :) Cheers, Simon Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
On Fri, Dec 19, 2003 at 11:39:28AM +0100, Tomasz Zielonka wrote: Well, I think that it would be better if hGetBuf didn't block if all requested data was already in buffer, but I don't insist on it. However this change of semantics can brake existing programs. I am mixing things again: The change of hGetBuf's semantics happened between GHC 6.0 and 6.2. I thinks the semantics in 6.0 is more intuitive. Now we have hGetBufNonBlocking with the old semantics of hGetBuf. Wouldn't it be better to have hGetBuf with old semantics and hGetBufBlocking with the new one? This way we wouldn't break existing programs. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
On Thu, Dec 18, 2003 at 07:44:58PM +0100, George Russell wrote: (b) The server module only gets part of the data. In fact for me it comes to a stop with [239][240][241][242][243Iterating despite there being more data to come. (And despite the fact that the client has done hFlush). I don't know any way of working around (b), so I suspect that means ghc6.2 is unusable for us. What a pity no development snapshot was made for 6.2 shortly before its release, as it might have been possible for me to discover this bug in time for it to be fixed in 6.2.(I did try to test the 6.3 development snapshot but was grounded by the instances bug I've reported elsewhere.) It seems to work when I change hGetBuf to hGetBufNonBlocking. The name is a bit misleading - the action _does_ wait for some data, but it doesn't wait for all requested bytes. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug with (##) operator and -fglasgow-exts, GHC 5.04, 6.0
On Fri, Jun 06, 2003 at 08:00:00PM +1000, Bernard James POPE wrote: Hi all, I seem to remember reading about this before, but I can't find it, so I'm sorry if I'm repeating a known bug report. It seems that -fglasgow-exts has trouble with (##) as an operator: module Main where f ## x = f x main = print $ (##) id True It doesn't like the prefix use of (##). Infix use is fine. The problem goes away without -fglasgow-exts You can write ( ## ) It reminds me of OCaml and its problem with prefix use of * operator. (* is a begining of a comment on OCaml *). Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: higher-order typing errors
Hi!
On Thu, Jan 23, 2003 at 10:28:13AM -, Simon Peyton-Jones wrote:
To get around it, define your own data type:
data MyPr = MyPr (forall a.a-a) (forall a.a-a)
swap1 :: MyPr - MyPr
I played a bit with using highed order polymorphism for this problem,
and have encountered compile errors I don't understand.
The first version doesn't compile - the error is:
Type synonym `F3' should have 1 argument, but has been given 0
In the type: Pair F3 F2
While checking the type signature for `p'
{-# OPTIONS -fglasgow-exts #-}
module T where
type F3 a = a - a - a
type F2 a = a - a
data Pair c1 c2 = Pair (forall a. c1 a) (forall b. c2 b)
swap :: Pair c1 c2 - Pair c2 c1
swap (Pair f g) = Pair g f
f2 :: F2 a
f2 = id
f3 :: F3 a
f3 = const
p :: Pair F3 F2
p = Pair f3 f2
The other version uses newtype instead of type synonyms for F2 and F3.
This one compiles without problems.
{-# OPTIONS -fglasgow-exts #-}
module T2 where
newtype F3 a = F3 (a - a - a)
newtype F2 a = F2 (a - a)
data Pair c1 c2 = Pair (forall a. c1 a) (forall b. c2 b)
swap :: Pair c1 c2 - Pair c2 c1
swap (Pair f g) = Pair g f
f2 :: F2 a
f2 = F2 id
f3 :: F3 a
f3 = F3 const
p :: Pair F3 F2
p = Pair f3 f2
There is probably some restriction I don't know about or haven't
recognized in this particular case. I hope you will enlighten me.
Simon
Best regards,
Tom
--
.signature: Too many levels of symbolic links
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Bug in codeGen/CgRetConv.lhs
Hello!
GHC nicely asked me to report the bug, so here it goes :)
Compiling this code in GHC 5.04.1 and 5.04.2
{-# OPTIONS -fglasgow-exts #-}
module Bug where
type T a = Int - (# Int, Int #)
f :: T a - T a
f t = \x - case t x of r - r
brings the following error message:
ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1):
codeGen/CgRetConv.lhs:83: Non-exhaustive patterns in function
dataReturnConvPrim
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
PS. Orignal code what a bit more complicated - this is the simplified
version.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Small bug in Data.PackedString.splitWithPS
Hi! In GHC 5.04.2 this fails: wordsPS (packString a) Cause: typical off-by-one error in libraries/base/Data/PackedString.hs line 289 first_pos_that_satisfies pred ps len n = case [ m | m - [n..len], pred (ps ! m) ] of ^ here Probably should be: case [ m | m - [n..len-1], pred (ps ! m) ] of Best Regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
