Bug#562610: filed upstream
After a discussion with Julien Cristau (Debian maintainer), Markus Kuhn (xorg maintainer) and Constantine Stathopoulos (designer of the glyph), I realize that incorrect was wrong: the form is used occasionally in modern Greek print and often in handwriting. However I still think the more common print form should be used. I have reported this as xorg bug 25810: https://bugs.freedesktop.org/show_bug.cgi?id=25810 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562610: xfonts-base: incorrect glyph for U+03BB GREEK SMALL LETTER LAMDA in misc fixed fonts
Package: xfonts-base Version: 1:1.0.0-6 Severity: normal -- System Information: The following fonts have an incorrect glyph for U+03BB GREEK SMALL LETTER LAMDA. It seems the glyph was obtained by inverting the glyph for U+0079 LATIN SMALL LETTER Y. That would be close for the variant of 'y' that uses a diagonal line, but that's not the one used in these fonts. -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso10646-1 -misc-fixed-bold-r-normal--13-120-75-75-c-80-iso10646-1 -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso10646-1 -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso10646-1 -misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso10646-1 -misc-fixed-medium-o-normal--13-120-75-75-c-70-iso10646-1 -misc-fixed-medium-o-normal--13-120-75-75-c-80-iso10646-1 -misc-fixed-medium-o-semicondensed--13-120-75-75-c-60-iso10646-1 -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso10646-1 -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1 -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1 -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso10646-1 -misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1 -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 -misc-fixed-medium-r-normal--6-60-75-75-c-40-iso10646-1 -misc-fixed-medium-r-normal--7-70-75-75-c-50-iso10646-1 -misc-fixed-medium-r-normal--8-80-75-75-c-50-iso10646-1 -misc-fixed-medium-r-normal--9-90-75-75-c-60-iso10646-1 -misc-fixed-medium-r-semicondensed--12-110-75-75-c-60-iso10646-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 See the Unicode code chart (http://www.unicode.org/charts/PDF/U0370.pdf) for how it should look. Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.31.6 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xfonts-base depends on: ii xfonts-utils 1:7.5+1X Window System font utility progr xfonts-base recommends no packages. Versions of packages xfonts-base suggests: ii xfs 1:1.0.8-6 X font server ii xserver-xorg-core [xserver] 2:1.6.5-1 Xorg X server - core server -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#442073: hugs: Crashes when using ByteString and cpphs
This is caused by a bug in cpphs, which is used in preparing the
libraries for Hugs. Simple test case:
% cat test
{-
#if 1
foo
#else
bar
#endif
-}
% cpphs --noline test
{-
#if 1
foo
#else
-}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422170: hugs: Text.Regex gone!
On Thu, May 03, 2007 at 07:54:41PM -0500, John Goerzen wrote: Package: hugs Version: 98.200609.21-5 Severity: grave Justification: renders package unusable This breaks compatibility with a ton of packages. I have tried to find this in some package, but can't. The lack of it means that I can't build quite a bit of software for Hugs. As noted on the Hugs download page, this module was removed from the underlying base Haskell library package and replaced with non-portable regex-* packages. The only way forward is for the regex-* packages to be made portable and packaged separately. I think you've set the severity of this bug too high: renders package unusable is just not true. I would say it has a major effect on the usability of a package, without rendering it completely unusable to everyone, i.e. important. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417325: incorrect haddock locations reported by ghc-pkg
Package: ghc6 Version: 6.6-3 % ghc-pkg field base haddock-interfaces haddock-interfaces: /usr/share/ghc-6.6/html/libraries/base/base.haddock % ghc-pkg field base haddock-html haddock-html: /usr/share/ghc-6.6/html/libraries/base but ghc6-doc contains /usr/share/doc/ghc6-doc/html/libraries/base/base.haddock.gz /usr/share/doc/ghc6-doc/html/libraries/base/*.html and similarly for other packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402476: hugs98: FTBS on powerpc
On Mon, Dec 11, 2006 at 12:26:21AM +, Ross Paterson wrote: I know nothing of powerpc asm, but the GHC code is identical to the Hugs code except that it has r instead of g: __asm__ volatile (dcbf 0,%0\n\tsync\n\ticbi 0,%0 : : r (p)); Moreover this change in the GHC code was made on 4th Jan 2003 with the comment Darwin: Replace g constraint by r in inline assembly, otherwise it won't compile without -O So I'm applying this to the upstream code. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396787: hugs98: new upstream version of Hugs 98 available
On Fri, Nov 03, 2006 at 03:21:49AM +0100, Arjan Oosting wrote: Since you already have a separate package for HaXml-1.13.2, you probably don't want to have it bundled (it's the same version, anyway). I could do that indeed. But hugs does not ship the same version, the bundled version is the development version 1.17. Any reason why this is done? Ah, so it is. The pattern with Hugs has been to ship with snapshots of all library packages from CVS or darcs, but the intention is to move to using released tarballs once packages start releasing independently. Might as well do that with HaXml now. As for GLUT: it's fine on arm, i386, mips, mipsel, powerpc and sparc, but fails with undefined symbol: glutStrokeMonoRoman on alpha, amd64, hppa, ia64, m68k and s390. In freeglut-2.4.0 I find struct freeglutStrokeFont glutStrokeMonoRoman ; extern void* glutStrokeMonoRoman; which certainly looks wrong. BTW could you remove the debian dir again when the next version of hugs is released? Right now the diff.gz of the Debian source packages becoms quite ugly. Sure. It was only intended as a temporary measure. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396787: hugs98: new upstream version of Hugs 98 available
Arjan, Thanks for picking this up. I was the one who did the debian/ directory -- no-one else seemed to be interested in packaging Hugs for Debian at the time. I sent Isaac an early version but got no response. Sorry it discouraged you. On a quick look though I only noticed a couple of minor things: In the patched libraries/tools/convert_libraries, ALUT is listed twice. Since you already have a separate package for HaXml-1.13.2, you probably don't want to have it bundled (it's the same version, anyway). Cheers, Ross -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390854: hugs: SEGV instead of Control stack overflow in many ocassions
On Tue, Oct 03, 2006 at 01:03:59PM +0200, Tomas Janousek wrote: It crashes with let test x = test x + 1 in test 1 but does not with let test x = 1 + test x in test 1 The same applies for factorial calculation like: crash: let fac x = fac (x - 1) * x in fac (-1) stack overflow: let fac x = x * fac (x - 1) in fac (-1) It's a documented bug (Other bugs in Hugs in the User's Guide): the former versions overflow the C stack (SEGV), while the latter overflow the Hugs stack (nice error message). More recent versions of Hugs (March and September 2006, neither packaged for Debian) are better at avoiding overflowing the C stack (e.g. they say Control stack overflow for all four of these examples). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347172: hugs: add runhaskell?
On Sun, Jan 08, 2006 at 11:09:48PM -0800, Isaac Jones wrote: Package: hugs Version: 98.200503.08-4 Severity: wishlist from an email between me ian: Should I add a runhaskell script to the hugs package? Yes. If so, what priority should I install it at? I suggest 5620050308 5 == hugs 6 == stable (CVS snapshot would use 3) 20050308 == date Can you give me a pointer to info about installing priorities like that? Something like update-alternatives /usr/bin/runhaskell runhaskell /usr/bin/runhugs 5620050308 in postinst and update-alternatives --remove runhaskell /usr/bin/runhugs in prerm. You might like to generate the postinst so the date is filled in automagically. runhugs needs -98 to run Cabal scripts, so you may need a wrapper. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336201: acknowledged by developer (Bug#336201: fixed in hugs98 98.200503.08-4)
On Thu, Nov 03, 2005 at 12:13:23PM +0100, Laurent Bonnaud wrote: hugs98 (98.200503.08-4) unstable; urgency=low . * Added buid-depends on gzip (Closes: #336201). Thank you for this new version ! Unfortunately it does not fix my problem. In fact gzip was already installed on my system. The dependency on gzip was unnecessary, as gzip is an essential package. gzip -9v /users/info/profs/bonnaud/hugs98-98.200503.08/debian/tmp/hugs/usr/share/doc/hugs/changelog.Debian gzip: gzip: No such file or directory /users/info/profs/bonnaud/hugs98-98.200503.08/debian/tmp/hugs/usr/share/doc/hugs/changelog.Debian: 65.6% -- replaced with /users/info/profs/bonnaud/hugs98-98.200503.08/debian/tmp/hugs/usr/share/doc/hugs/changelog.Debian.gz make: *** [debian/binary-arch.stamp] Error 1 Build command 'cd hugs98-98.200503.08 dpkg-buildpackage -b -uc' failed. E: Child process failed Do you have a private version of gzip? It seems to be adding gzip to the command line of /bin/gzip. (Does gzip -9v foo produce this message?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336201: acknowledged by developer (Bug#336201: fixed in hugs98 98.200503.08-4)
On Thu, Nov 03, 2005 at 04:37:25PM +0100, Laurent Bonnaud wrote: The only non-standard thing I have in my environment that is related to gzip is this variable: GZIP=--best OK, that's the problem. hugs98/debian/rules uses a variable GZIP, and when you make it an environment variable, the setting in rules goes into the environment and confuses gzip. So hugs98/debian/rules needs to use something else. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334337: hugs segfault if Show class in instancied but show method not defined.
On Mon, Oct 17, 2005 at 11:52:56AM +0200, Bill Allombert wrote: It looks like hugs segfault if you instance Show but not define a show method and then implicitly use it: Let foo.hs = ---8- module Fibo where type Quad = (Integer,Integer) newtype Gauss = Karl Quad instance Eq Gauss where Karl (a,b) == Karl (c,d) = a == c b == d instance Show Gauss where ---8- in $ hugs fibo3.hs Type :? for help Fibo Karl (1,2) zsh: segmentation fault hugs fibo3.hs This is an instance of Hugs segfaulting on some infinite computations (here show - showsPrec - show). You can do the same thing with an empty Eq instance or just let f x = g x + 1; g x = f x + 2 in f 3 The general problem is documented in the User's Guide, but I believe it's fixed in CVS version (src/machine.c 1.25 and src/prelude.h 1.79 if anyone's interested in backporting). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271124: hugs98: needs Build-Conflicts with byacc
On Fri, Sep 09, 2005 at 08:28:23PM -0400, Thomas Dickey wrote: I see byacc is checked for in the hugs98 configure script, but parser.y doesn't contain any bison-specific junk. Any idea why byacc is being picked on here? Haskell has a wierd rule that an implicit close brace should be inserted if an illegal token is encountered where an implicit close brace would be permitted, e.g. at the final ')' in scanl f q xs = q : (case xs of [] - [] x:xs - scanl f (f q x) xs) parser.y implements this with using a trick with the error non-terminal (see the productions for end), and for some reason this doesn't work with byacc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305831: mbrtowc() fails for vi_VN.tcvn
On Mon, Apr 25, 2005 at 01:07:54AM +0900, GOTO Masanori wrote: At Fri, 22 Apr 2005 12:14:53 +0100, Ross Paterson wrote: According to the spec, mbrtowc(wc, buf, 1, st) should either return 1 and set wc, or return 0, (size_t)-1 or (size_t)-2. In this locale it returns either 0 or 1, but doesn't always set wc in the latter case, It works OK when I changed this source as follows. Sorry, the subject line was a bit broad -- I didn't mean to imply any more than a failure in this specific usage pattern. (In iconvdata/tcvn5712-1.c, this decoding is treated as stateful, but I don't think it should be.) It has five combined character: http://www.informatik.uni-leipzig.de/~duc/software/misc/tcvn.txt TCVN5712:1993 is very weird encodings, because 0xb0..0xb4 are postposing combined character. This means even if we read the first character, we cannot decide output character until we read the 2nd character. I know -- I just thought that one could have, e.g. mbrtowc(wc, a , 1, st) return (size_t)-2 mbrtowc(wc, a , 2, st) return 1 (though getwc would have to push the extra byte back onto the stream, I guess) Just wishlist, of course, stateless encodings are easier to work with, and this is the only stateful one in Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305831: mbrtowc() fails for vi_VN.tcvn
Package: locales
Version: 2.3.2.ds1-20
Severity: normal
According to the spec, mbrtowc(wc, buf, 1, st) should either return 1
and set wc, or return 0, (size_t)-1 or (size_t)-2. In this locale it
returns either 0 or 1, but doesn't always set wc in the latter case,
as the following test program shows. I believe it should be returning
(size_t)-2 (incomplete encoding) for (most) letters, and setting wc in
all the other cases (except \0).
(In iconvdata/tcvn5712-1.c, this decoding is treated as stateful, but
I don't think it should be.)
This behaviour sends readline into an infinite loop in this locale.
-- cut here --
#include stdio.h
#include wchar.h
#include locale.h
#include sys/types.h
main() {
int c;
mbstate_t st;
char buf[1];
size_t size;
wchar_t wc;
setlocale(LC_CTYPE, vi_VN.tcvn);
for (c = 0; c = 0xff; c++) {
wc = 0xbaad;
buf[0] = c;
memset(st, 0, sizeof(st));
size = mbrtowc(wc, buf, 1, st);
printf(c = 0x%02x, size = %u, wc = U+%04X\n, c, size, wc);
}
return 0;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299702: Hugs98-2005 shouldn't go into sarge yet
On Thu, Apr 21, 2005 at 03:56:50PM +0100, Ian Lynagh wrote: That shouldn't be necessary -- all the locales in Debian agree with C on ASCII-only text. Ah, that would be convenient. I've just done a quick test and they all seem OK except vi_VN.TCVN (both with latest CVS and the release): There was a small bug in Hugs, but I think this locale is broken (#305831). cpphs currently accepts 8-bit chars in filenames being #included, as does cpp; maybe you will argue that making use of that is foolish, but nevertheless I think I would rather drop the ability to compile with hugs in order to keep its behaviour consistent. Do you mean #include's in the source file, which is read in text mode? It is currently, but with new hugs I think it should really be being read in binary mode and cpphs then do its own line ending magic. I would have thought that cpp input was text -- does cpphs really do anything with crlf's? Anyway, full compatibility with a GHC-compiled version isn't possible (which was you point) so I guess dropping the cpphs/hugs combination seems reasonable, as you have ghc or nhc98 on all archs. It's a tradeoff, I just don't think it's a grave bug. The severity of Debian bug 299702 is just the mechanism used to keep the package out of testing. I meant that I appreciate that you've been worried about the filename issue for some time, but that it wouldn't justify keeping Hugs out on its own. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303271: LANGUAGE: CPP pragma broken with ghc
The LANGUAGE: CPP pragma doesn't appear to get passed on to ghc, though
it does appear to work with Hugs.
Pragmas should be interpreted by the compiler, not Cabal, and the
LANGUAGE pragma is not yet supported by GHC.
Hugs is treated differently because the source file must be preprocessed
before Hugs sees it.
The following should work with GHC 6.2 and 6.4, and Hugs Mar2005:
{-# OPTIONS -cpp #-}
{-# LANGUAGE CPP #-}
though OPTIONS is deprecated in favour of OPTIONS_GHC in 6.4.
(Indeed just the first line is enough for both GHC and Hugs.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299702: Hugs98-2005 shouldn't go into sarge yet
Ian Lynagh [EMAIL PROTECTED] writes: We're not sure the new hugs should go into sarge without matching new ghc/nhc98 due to library changes. We also need to check these changes don't cause any breakage elsewhere. What incompatibilities with GHC 6.2 and nhc98 1.16 have you discovered that weren't present in 200311? I know of: Library changes (also present in GHC 6.4 and nhc98 1.18): * instance Integral CTime removed (#299568): avoid fromIntegral on this type. * Show andFunctor instances added for FiniteMap: can be worked around using cpp. * System.IO no longer re-exports System.IO.Error: need to tweak imports a little. Hugs only: * locale-based encoding of character I/O (#299570): use binary I/O for binary data. * locale-based encoding of filenames and environment variables in H98 libs: a loss when these are binary or in an unknown encoding, but a gain for users who use their locale's encoding (and H98 specifies these as String, not [Word8]). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299570: [Haskell-cafe] invalid character encoding
On Sun, Mar 20, 2005 at 04:34:12AM +, Ian Lynagh wrote: On Sun, Mar 20, 2005 at 01:33:44AM +, [EMAIL PROTECTED] wrote: On Sat, Mar 19, 2005 at 07:14:25PM +, Ian Lynagh wrote: Is there anything LC_CTYPE can be set to that will act like C/POSIX but accept 8-bit bytes as chars too? en_GB.iso88591 (or indeed any .iso88591 locale) will match the old behaviour (and the GHC behaviour). This works for me with en_GB.iso88591 (or en_GB), but not en_US.iso88591 (or en_US). My /etc/locale.gen contains: en_GB ISO-8859-1 en_GB.ISO-8859-15 ISO-8859-15 en_GB.UTF-8 UTF-8 So is there anything that /always/ works? Since systems may have no locale other than C/POSIX, no. Yes, I don't see how to avoid this when using mbtowc() to do the conversion: it makes no distinction between a bad byte sequence and an incomplete one. Perhaps you could use mbrtowc instead? Indeed. Thanks for pointing it out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299570: [Haskell-cafe] invalid character encoding
On Wed, Mar 16, 2005 at 03:54:19AM +, Ian Lynagh wrote: Do you have a list of functions which behave differently in the new release to how they did in the previous release? (I'm not interested in changes that will affect only whether something compiles, not how it behaves given it compiles both before and after). I got lost in the negatives here. It affects all Haskell 98 primitives that do character I/O, or that exchange C strings with the C library. It doesn't affect functions added by the hierarchical libraries, i.e. those functions are safe only with the ASCII subset. (There is a vague plan to make Foreign.C.String conform to the FFI spec, which mandates locale-based encoding, and thus would change all those, but it's still up in the air.) Finally, the hugs behaviour seems a little odd to me. The below shows 4 cases where iconv complains when asked to convert utf8 to utf8, but hugs only gives an error in one of them. In the others it just truncates the input. Is this really correct? It also seems to behave the same for me regardless of whether I export LC_CTYPE to en_GB.UTF-8 or C. It's a bug: an unrecognized encoding at the end of the input was being ignored instead of triggering the exception. Now fixed in CVS (rev. 1.14 of src/char.c if anyone's backporting). It was an accident of this example that the behaviour in all locales was the same. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299777: README.Debian is out of date
Package: hugs Version: 98.200503.08-1 Severity: normal The Hugs module extension policy described in README.Debian doesn't fit with the new Cabal world -- see section 3.6 of the User's Guide. Also, there is no longer a GreenCard.h (now there is HsFFI.h). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299568: hugs: CTime incompatibility with new version
This code worked in the previous version of Hugs. It seems that CTime is no longer Integral, but I don't know why. This was a deliberate library change, affecting all Haskell implementations. See rev. 1.22 in http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Foreign/C/Types.hs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299570: [Haskell-cafe] invalid character encoding
On Mon, Mar 14, 2005 at 07:38:09PM -0600, John Goerzen wrote: I've got some gzip (and Ian Lynagh's Inflate) code that breaks under the new hugs with: handle: IO.getContents: protocol error (invalid character encoding) What is going on, and how can I fix it? A Haskell 98 Handle is a character stream, and doesn't support binary I/O. This would have bitten you sooner or later on systems that do CRLF conversion, but Hugs is now much stricter, because character streams now use the encoding determined by the current locale (for the C locale, that means ASCII only). You can select binary I/O using the openBinaryFile and hSetBinaryMode functions from System.IO. After that, the Chars you get from that Handle are actually bytes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299570: [Haskell-cafe] invalid character encoding
On Tue, Mar 15, 2005 at 08:12:48AM -0600, John Goerzen wrote: [...] but Hugs is now much stricter, because character streams now use the encoding determined by the current locale (for the C locale, that means ASCII only). Hmm, this seems to be completely undocumented. It's mentioned in the release history in the User's Guide, which refers to section 3.3 for (some) more details. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299568: hugs: CTime incompatibility with new version
On Tue, Mar 15, 2005 at 08:07:19AM -0600, John Goerzen wrote: On Tue, Mar 15, 2005 at 10:25:42AM +, Ross Paterson wrote: This code worked in the previous version of Hugs. It seems that CTime is no longer Integral, but I don't know why. This was a deliberate library change, affecting all Haskell implementations. See rev. 1.22 in http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Foreign/C/Types.hs Couldn't it also be an Integral, using the round . realToFrac to implement it? That was Sven Panne, but ... You could use round . realToFrac to implement toInteger, but types in Integral are supposed to be, well, integral, and time_t need not be. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
