ghci patch for review: :set, :show packages, :show languages, :{:}, :browse!

Claus Reinke claus.reinke at talk21.com
Wed Oct 24 20:52:33 EDT 2007


hi again,

there was a fileformat issue in multiline commands and several platform
issues with the tests; updated patch version attached; changes, by test:

> ghci023:  (validated on windows, failed on your platform)

the symptoms suggested that the ':}' wasn't found, due to left-over
dos linefeeds, leading to silent test failure.

on unix, getLine does not eliminate dos linefeeds. ghci commands
are usually preprocessed with removeSpaces, which also removes 
those linefeeds, but i can't do that for multiline commands - spaces 
not eliminated by getLine are likely to be part of the command
that has been spread over multiple lines for readability.

to improve resilience against wrong-platform fileformats, i apply
removeSpaces before testing for ':}', and after merging lines to
form a command; also, missing ':}' no longer fails silently. 

i'm also replacing '\r' by ' ' within the merged command, 
but i'm less sure about whether or not that is the right thing 
to do. if this still isn't sufficient, i suggest dos2unix for this test.

i've also added docs for multiline commands.

> ghci024: (test output is platform- and version-dependent)

i had to stretch the testing framework slightly to compensate for
this. the idea is to record the ghci output when the package is
first loaded, and to use that to construct the stdout to compare 
':show packages' against. that should isolate the test against
both version- and platform-specifics.

the test framework allows for python functions to set up a 
test, but is slightly tricky because the all.T script does not
run in the test directory - one needs to use in_testdir() to
source the test-specific setup function and to generate the
stdout file for the test. (this is my first python code - i'm
only using library functions also used elsewhere in the
framework, so this should be portable, but please check!-).

i've also updated the docs.

> ghci025: (order of :browse is unstable, trac #1799)

Simon fixed the missing space in '-ignore-dot-ghci-dcore-lint',
so the .ghci files should no longer interfere, but other changes
in usage/uniqueIds might.

as an interim solution to get a useful test, i've added a '-s'
option for alphabetically sorted output in :browse and use
that option in the test. this might also be useful on its own,
but i wouldn't want it as the default - names should be sorted
in source or export order. if that still leaves any variations, i
suggest to change the 'normal' in all.T to 'ignore_output'
for this test until #1799 is fixed properly.

there have also been some cosmetic changes to :browse!,
such as grouping items with the same list of possible 
qualifiers, sorting the groups by qualifiers, and indicating
which items from a named module are not yet imported:

    Prelude> :browse! Data.Maybe
    -- not currently imported
    isJust :: Maybe a -> Bool
    isNothing :: Maybe a -> Bool
    fromJust :: Maybe a -> a
    fromMaybe :: a -> Maybe a -> a
    maybeToList :: Maybe a -> [a]
    listToMaybe :: [a] -> Maybe a
    catMaybes :: [Maybe a] -> [a]
    mapMaybe :: (a -> Maybe b) -> [a] -> [b]
    -- imported from Prelude
    Just :: a -> Maybe a
    Nothing :: Maybe a
    data Maybe a = Nothing | Just a
    maybe :: b -> (a -> b) -> Maybe a -> b

(:browse! was already documented)

as before, the patches validate on win/xp (modulo
ThreadDelay001, which hasn't got anything to do with
my patches), with just updated sources; as before, i 
don't know whether that extends to other platforms
(i've tried to remove the platfom issues i knew about, 
but can only test on windows).

some notes about the validate log:

1. i got quite a few warnings, most from docs, other
    non-critical stuff, but this one doesn't look so good:

    Warning: resolving _genericWndProc by linking to _genericWndProc at 16
    Use --enable-stdcall-fixup to disable these warnings
    Use --disable-stdcall-fixup to disable these fixups
    c:\MinGW\bin\ar.exe: creating dist/build/libHSWin32-2.1.a

2. searching the log for users_guide, it seems that
    validate doesn't touch that because make doesn't
    build it? shouldn't that be moved from install to 
    build, as with the man page?

3. speaking of man page: what is that good for in 
    a windows build? unless you want to distribute
    a man pager with ghc? or is that just for validate?

claus

ps: did you know that Dilbert had experience with
     the ghc patch process?-)
http://www.dilbert.com/comics/dilbert/archive/dilbert-20071018.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: claus-ghci-testsuite.patch
Type: application/octet-stream
Size: 114915 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cvs-ghc/attachments/20071025/a53ccb84/claus-ghci-testsuite-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: claus-ghci.patch
Type: application/octet-stream
Size: 44147 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cvs-ghc/attachments/20071025/a53ccb84/claus-ghci-0001.obj


More information about the Cvs-ghc mailing list