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
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'
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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):
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
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
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
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
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
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
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
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
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
26 matches
Mail list logo
