Custom Query

Reported by cjs, 5 years ago.

The -main-is option to runghc does not appear to work, at least not when specifying a package name. Create Hello.hs:

    module Hello where
    main = putStrLn "Hello."

and then try to run it:

    runghc -main-is Hello Hello.hs

You will see:

    <interactive>:1:113:
        Failed to load interface for `Main':
          Use -v to see a list of the files searched for.

Reported by cjs, 5 years ago.

When I run the following program on a NetBSD system, it listens on *.4444 for IPv6, not IPv4. This could certainly happen on other operating systems as well, though I've not tested others. Whether it happens or not could even vary from release to release.

import IO
import Network

main = do
    s <- listenOn (PortNumber 4444)
    (h, hostName, portNum) <- Network.accept s
    putStrLn $ "Connection from " ++ hostName ++ ":" ++ show portNum
    hPutStrLn h "Bye!"
    hClose h

I've verified that telnet 127.0.0.1 4444 produces a "connection refused" message, but telnet ::1 4444 connects and displays "Bye!"

I'd go so far to say that this is a bug. At best, one could argue that this behaviour is not entirely intuitive.

I propose that we (re-?)define PortID's PortNumber? constructor to refer only to IPv4 protocol ports, and add a new PortNumber?6 constructor for IPv6 ports.

Another option would be to do force PortNumber? always to bind to IPv4, but not add PortNumber?6. I prefer this less because we should be encouraging the use of IPv6, and because having PortNumber?6 serves as obvious documentation for what PortNumber? and PortNumber?6 do.

A third option would be to attempt to listen on both IPv4 and IPv6, when both are available, but this sort of thing is fraught with many problems, the details of which are much more than I'd want to get into in this bug report.

Reported by cjs, 5 years ago.

Network.Socket exports a PortNum? value constructor. Though there's no haddock documentation to say so, this constructs a value of type PortNumber? by taking a Word16 in *machine* order, i.e., byte-swapped on little-endian machines.

However, PortNumber? is an instance of Num and has a fromIntegral (that converts from a non-byte-swapped int), so when specifying a PortNumber? for a something such as a SockAddrInet?, one should just use an Integral. That is, instead of

SockAddrInet? (PortNum? $ fromIntegral (byteswap 12345)) hostaddr

one should just use

SockAddrInet? 12345 hostaddr

I think that the PortNum? constructor should not be exported; it's difficult to use due to the lack of documentation (and its own nature, really), is not necessary, and worst of all, its existence has mislead at least two programmers I know of to use it when they didn't want or need to.

Reported by cjs, 5 years ago.

Running the attached program on Windows works, because runInteractiveProcess fails. Under Linux and NetBSD, runIntractiveProcess returns (which it probably shouldn't--wouldn't it be nicer if it checked that it had execute access on what it wanted to exec before it forked?) and then at some point in hClose the program silently dies, though returning an error code to the process that spawned it.

Reported by cjs, 5 years ago.

All four versions of hGet for the various Data.ByteString implementations claim that it "[reads] n bytes into a ByteString." This is not always the case. For example, it appears that on EOF less than n bytes are read. The conditions under which it will not succeed in reading n bytes into a ByteString (be it less than n, or it raising some sort of error) should be documented.

Reported by cjs, 5 years ago.

According to section 5.8.4.1 of the Users' Guide, appending a colon to GHC_PACKAGE_PATH should include the system libraries, and this can be verified with ghc-pkg. While the colon does appear to work for ghci (as verified with -v), it does not appear to work for ghc-pkg.

$ echo '[]' > temp.conf
$ export GHC_PACKAGE_PATH=`pwd`/temp.conf:
ghc-pkg list
/home/cjs/temp.conf:
$ 

Reported by cjs, 4 years ago.

Using the ghc 6.1.0 package for libedit2 downloaded from the GHC downloads page, on Ubuntu 8.04.1, attempting to compile an hsc file fails with:

In file included from /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c:1:
/usr/local/lib/ghc-6.10.1/hsc2hs-0.67/template-hsc.h:4:19: error: HsFFI.h: No such file or directory
compiling /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c failed
command was: /usr/bin/gcc -c /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c -o /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.o

I note that the command does not include a -I option. Either running the command by hand with an appropriate -I option, or setting the environment variable CPATH=/usr/local/lib/ghc-6.10.1/include fixes the issue.

Reported by cjs, 4 years ago.

GHC 6.10.3 switched from readline/editline to  Haskeline as the command-line editor in ghci. Unfortunately, this lost a lot of the vi-mode editing functionality, as the version of Haskeline ghci uses had very limited support for vi mode.

This support has been improving quickly in Haskeline's trunk, thanks to vi-mode users using the release and submitting bug reports. When the next version of GHC is released, a new release of Haskeline with all of these updates should be cut, and incorporated into GHC.

Reported by cjs, 4 years ago.

Often in ghci I'd like to interactively debug and play with functions in the where clause of a top-level definition. Currently, this requires one to change the code, lifting the definitions in question to the top level and adding appropriate parameters.

Given a definition such as

top :: Int -> Int
top x = mult 4 - mult 3 + mult 2
    where
        mult n = x * n

it would be nice to type something such as :environment top 2 to put me in an envrionment where mult is available and mult 4 will evaluate to 8. (Obviously this becomes more useful with more complex definitions.)

Reported by cjs, 4 years ago.

Trying to build 6.10.3 using 6.8.2 on an amd64 NetBSD 4.0, I ran into several problems.

1. ./configure --with-gmp-includes=/usr/pkg/include --with-gmp-libraries=/usr/pkg/lib did not work; the build system could not find gmp.h. Changing libraries/Makefile to give the cabal setup command --extra-include-dirs=/usr/pkg/include --extra-lib-dirs=/usr/pkg/lib let it find the include file, but it still couldn't find the library. I finally had to symlink /usr/lib/libgmp.so.3 to /usr/pkg/lib/libgmp.so.3 to get it to compile and link.

2. It seems that the installPackage package triggers some thread issues:

gmake -C installPackage with-stage-2
gmake[3]: Entering directory `/usr/local/ghc/src/ghc-6.10.3/utils/installPackage'
/usr/local/ghc/src/ghc-6.10.3/libraries/cabal-bin /usr/pkg/bin/ghc /usr/local/ghc/src/ghc-6.10.3/libraries/bootstrapping.conf 1.6.0.3 configure --distpref dist-install         \
                           --prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXISTENT \
                           --with-compiler=/usr/local/ghc/src/ghc-6.10.3/ghc/stage2-inplace/ghc --with-hc-pkg=/usr/local/ghc/src/ghc-6.10.3/utils/ghc-pkg/install-inplace/bin/ghc-pkg   --package-db /usr/local/ghc/src/ghc-6.10.3/stage3.package.conf   \
                           --libsubdir='$pkgid' --with-gcc=gcc --with-ld=/usr/bin/ld --hsc2hs-option=-I/usr/pkg/include    --configure-option='--with-gmp-includes=/usr/pkg/include'  --configure-option='--with-gmp-libraries=/usr/pkg/lib' --configure-option=--with-cc="gcc" --with-hsc2hs=/usr/local/ghc/src/ghc-6.10.3/utils/hsc2hs/install-inplace/bin/hsc2hs       \
                           --constraint="Cabal == 1.6.0.3"
Configuring installPackage-1.0...
ghc: Error detected by libpthread: Invalid mutex.
Detected by file "/u/production/nbsd/instance/nbsd/src-4/lib/libpthread/pthread_mutex.c", line 334, function "pthread_mutex_unlock".
See pthread(3) for information.
gmake[3]: *** [with-stage-2] Error 134

Reported by cjs, 4 years ago.

The attached file compiles fine under GHC 6.10. However, under 6.12, it produces the error

BadPun.hs:8:17:
    Conflicting definitions for `pun-right-hand-side'
    In the binding group for: pun-right-hand-side, pun-right-hand-side,
                              pun-right-hand-side

Note that this affects the named field puns only in the where clause of badPun; goodPun, which uses them in the LHS of a top-level definition, does not have this problem.

A possibly interesting additional note is that if you change Record{f1,f2,... to Record{f1=f1,f2,..., you'll find that you get this error message instead:

BadPun.hs:8:23:
    Conflicting definitions for `pun-right-hand-side'
    In the binding group for: f1, pun-right-hand-side,
                              pun-right-hand-side

Changing f2 to f2=f2 as well makes the error go away, presumably because there's now only one pun-right-hand-side defined.

Reported by cjs, 3 years ago.

The attached program generates a warning: "Warning: -#include is deprecated: No longer has any effect". However, if I remove the #include, it fails to compile with:

Fixes.hsc: In function ‘main’:
Fixes.hsc:29: error: ‘SOL_SOCKET’ undeclared (first use in this function)
Fixes.hsc:29: error: (Each undeclared identifier is reported only once
Fixes.hsc:29: error: for each function it appears in.)
Fixes.hsc:29: error: ‘SO_LINGER’ undeclared (first use in this function)
Fixes.hsc:37: error: invalid application of ‘sizeof’ to incomplete type ‘struct linger’ 
Fixes.hsc:40: error: invalid use of undefined type ‘struct linger’
Fixes.hsc:41: error: invalid use of undefined type ‘struct linger’

Evidently it's not quite true that #include no longer has any effect.

Reported by cjs, 3 years ago.

The -Sfilename option to the RTS gives useful GC statistics, but it's hard to correlate these with other events, particularly to see if GC is interrupting critical sections in mutator threads. If the same information were instead logged via the eventlog system (perhaps enabled via a "-lg" option) one could get more insight into the garbage generation and collection behaviour of one's program.

Note that it's probably not necessary also to store the information given at the end of the run with both "-s" and "-S", though it may be interesting to contemplate moving this sort of thing into the eventlog file as well.

Reported by cjs, 3 years ago.

When I call the GC.Exts.traceEvent function (argument: "hello") with event logging enabled (i.e., compiled with -eventlog and run with -ls) my program generates a segmentation fault. Here is the gdb backtrace:

#0  0x00007f3ad6744a2f in vfprintf () from /lib/libc.so.6
#1  0x00007f3ad677039a in vsnprintf () from /lib/libc.so.6
#2  0x00000000004476c4 in postLogMsg (eb=0x8160d0, type=19, 
    msg=0x7f3ad5d7e010 "hello", ap=0x0) at rts/eventlog/EventLog.c:403
#3  0x0000000000447853 in postUserMsg (cap=0x69b780, 
    msg=0x7f3ad5d7e010 "hello") at rts/eventlog/EventLog.c:433
#4  0x000000000043b012 in traceUserMsg (cap=0x69b780, 
    msg=0x7f3ad5d7e010 "hello") at rts/Trace.c:290
#5  0x000000000044e237 in stg_traceEventzh ()
#6  0x0000000000000000 in ?? ()

It's not at all clear to me what could be going wrong here.