November 2005 - Cvs-hugs

cvs commit: hugs98/src/winhugs DlgMain.c RtfWindow.c RtfWindow.h
by Neil Mitchell 13 Nov '05

13 Nov '05

neil 2005/11/13 09:18:14 PST Modified files: src/winhugs DlgMain.c RtfWindow.c RtfWindow.h Log: Add proper support for ANSI \b character. The buffering now has a notion of an offset from where it should dump the text, the length of the buffer and the current position in the buffer. This makes QuickCheck work properly. Revision Changes Path 1.14 +1 -0 hugs98/src/winhugs/DlgMain.c 1.8 +37 -20 hugs98/src/winhugs/RtfWindow.c 1.4 +1 -0 hugs98/src/winhugs/RtfWindow.h

1 0

QuickCheck vs WinHugs
by Neil Mitchell 13 Nov '05

13 Nov '05

Hi, The progress display in QuickCheck doesn't work in the latest version of WinHugs. It remains entirely blank until the end, not displaying the number it is on. Having looked at the source code to quickcheck, it is interacting with the WinHugs notion of "\b" very badly. In WinHugs \b is treated as phycially delete the last character that was written out on the console, removing it. QuickCheck seems to expect the behaviour of \b to be move the cursor to the left by one position, but do not erase the text that was to the right of the \b character. What should the correct behaviour be, while the \b character is mentioned in the Haskell report, its behaviour is not. Thanks Neil

2 2

RE: System.Info.os
by Simon Marlow 12 Nov '05

12 Nov '05

On 11 November 2005 12:21, Neil Mitchell wrote: >> mingw32 is the only native Windows build we have right now, but it's >> not inconceivable that we might have an even-more-native build in the >> future, by bypassing mingw32 altogether. > The Windows build might be made using mingw32, but it runs natively > without relying on mingw32, as far as I can tell. It certainly runs on > my windows OS without having mingw32 installed (other than the bits > ghc installes additionally). > > The WinHugs is now a genuinely 100% Windows build, using Visual Studio > - only the libraries are preprocessed under Mingw32. You can tell the difference if you try to foreign import something provided by the mingw32 libraries (eg. libmingwex.a). How does this work with WinHugs? Cheers, Simon

2 1

RE: System.Info.os
by Simon Marlow 11 Nov '05

11 Nov '05

The question is, is there any reason that the program might want to know that it is running on top of "mingw32" rather than plain "Win32". mingw32 does provide more - it has more of a posix-like C library than the basic C runtime that Win32 provides (msvcrt), so there is a difference. mingw32 is the only native Windows build we have right now, but it's not inconceivable that we might have an even-more-native build in the future, by bypassing mingw32 altogether. However, most of the time you just want to know whether you're on Windows vs. everything else, so mingw32 is too specific. I guess I'm saying mingw32 doesn't really do much harm, and it's "correct" in some sense, but we should also have provided #ifdef win32_HOST_OS for those cases when you don't care. Cheers, Simon I'm not sure it wrong, per se, just more specific than you want most of the time. On 11 November 2005 01:37, Neil Mitchell wrote: > I noticed GHC also gets it wrong in this case, with the same result. > It's a bit of a shame, but maybe its too late to change... > > On 11/10/05, Ross Paterson <ross(a)soi.city.ac.uk> wrote: >> On Thu, Nov 10, 2005 at 01:14:34PM +0000, Neil Mitchell wrote: >>> The function System.Info.os on WinHugs returns "mingw32", which is >>> not really true. I guess its because the libraries are compiled >>> using mingw32, since they can't be compiled natively from windows? >>> Is there some way to alter the library build scripts? >> >> As MinGW produces native binaries, "mingw32" isn't an appropriate >> value for os in any case -- it should be "mswin32" or the like, >> whether the Win32 binary was compiled with MSVC or MinGW. However >> "mingw32" is the name used by autoconf, and it's pervasive in the >> libraries. Maybe it should be special-cased in System.Info. >> >> Then again, Cabal uses the values of System.Info.{arch,os} to >> construct the CPP symbols to be defined when preprocessing packages >> for Hugs, and package authors have #ifdef mingw32_HOST_OS all over >> the place. >> >> _______________________________________________ >> Cvs-hugs mailing list >> Cvs-hugs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/cvs-hugs >> > _______________________________________________ > Cvs-hugs mailing list > Cvs-hugs(a)haskell.org > http://www.haskell.org/mailman/listinfo/cvs-hugs

2 1

System.Info.os
by Neil Mitchell 10 Nov '05

10 Nov '05

Hi, The function System.Info.os on WinHugs returns "mingw32", which is not really true. I guess its because the libraries are compiled using mingw32, since they can't be compiled natively from windows? Is there some way to alter the library build scripts? Thanks Neil

2 2

cvs commit: hugs98/src hugs.c
by Ross Paterson 10 Nov '05

10 Nov '05

ross 2005/11/10 06:50:53 PST Modified files: src hugs.c Log: remove :! from the summary printed by :? so that it fits on a 24-line screen. Revision Changes Path 1.146 +4 -2 hugs98/src/hugs.c

1 0

cvs commit: hugs98 Makefile
by Ross Paterson 05 Nov '05

05 Nov '05

ross 2005/11/05 08:56:59 PST Modified files: . Makefile Log: remove debian/control etc under veryclean Revision Changes Path 1.67 +1 -1 hugs98/Makefile

1 0

cvs commit: hugs98 Makefile RPM.mk hugs98/debian changelog compat control.in hugs.README.Debian hugs.doc-base hugs.docs hugs.examples hugs.install hugs.links hugs.manpages hugs.menu hugs.postinst hugs.postrm hugs.preinst hugs.prerm make-control.hs ...
by Ross Paterson 05 Nov '05

05 Nov '05

ross 2005/11/05 08:15:01 PST Modified files: . Makefile RPM.mk Added files: debian changelog compat control.in hugs.README.Debian hugs.doc-base hugs.docs hugs.examples hugs.install hugs.links hugs.manpages hugs.menu hugs.postinst hugs.postrm hugs.preinst hugs.prerm make-control.hs rules Log: experimental Debian packaging with each library package in its own package. Revision Changes Path 1.66 +5 -0 hugs98/Makefile 1.41 +1 -0 hugs98/RPM.mk

1 0

cvs commit: hugs98/libraries/tools convert_libraries
by Ross Paterson 05 Nov '05

05 Nov '05

ross 2005/11/05 05:56:21 PST Modified files: libraries/tools convert_libraries Log: make all packages updatable Revision Changes Path 1.28 +2 -2 hugs98/libraries/tools/convert_libraries

1 0

cvs commit: hugs98 Makefile hugs98/src .cvsignore
by Ross Paterson 05 Nov '05

05 Nov '05

ross 2005/11/05 05:51:40 PST Modified files: . Makefile src .cvsignore Log: simplify by eliminating src/stamp-h.in Revision Changes Path 1.65 +3 -5 hugs98/Makefile 1.10 +0 -1 hugs98/src/.cvsignore

1 0