From dongen@cs.ucc.ie Wed Nov 1 00:07:54 2000
Date: Wed, 1 Nov 2000 00:07:54 +0000
From: Marc van Dongen dongen@cs.ucc.ie
Subject: Bug Report: Integer to Double conversion
Dear Maintainer(s),
I don't know if this is a known bug.
When converting Integers to floats I get the following:
(fromInteger $ (2::Integer)^128)::Double
Inf.0
Regards,
Marc van Dongen
--
Marc van Dongen, CS Dept | phone: +353 21 4903578
University College Cork, NUIC | Fax: +353 21 4903113
College Road, Cork, Ireland | Email: dongen@cs.ucc.ie
From d.pasechnik@twi.tudelft.nl Thu Nov 9 14:55:04 2000
Date: 09 Nov 2000 14:55:04 +0000
From: Dima Pasechnik d.pasechnik@twi.tudelft.nl
Subject: increasing control stack size?
As I was getting "Control stack overflow" while
attempting to generate large (>1MB) data files using Hugs,
I recompiled Hugs with 10-fold increased value of the corresponding
parameter (was 16K). Then I was able to do the necessary computations.
However, I wonder if it was safe to so, i.e. that this change
didn't break functionality of the Hugs system.
Hugs documentation sounds as if one gets "Control stack overflow" then
it surely must be an infinite recursion; while in my case it's just
concatenation of long (>20K) strings. I guess it would've been nice if
documentation said something more about that, and explained ways of
increasing stack size.
IMHO, some internal Hugs part uses the stack (thus, something that is
not controllable by the command line options) for data that ought to
be held in the heap (whose size is controllable by command line
options)...
Best regards,
Dmitrii Pasechnik
http://ssor.twi.tudelft.nl/~dima/
From lps@po.cwru.edu Fri Nov 10 06:06:11 2000
Date: Fri, 10 Nov 2000 02:06:11 -0400
From: Leon Smith lps@po.cwru.edu
Subject: Internal Type Error
This is a multi-part message in MIME format.
------=_NextPart_000_0137_01C04ABA.CBF3D120
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
I'm using some Multi-parameter Type Classes with the November 1999 version
of Hugs98 on Windows command-line version and getting the following internal
type error:
WinHugs simply chokes and dies.
At one point, the hugs command-line version was accepting the code if I
commented out the function definitions but left the constant data
definition, but after restarting hugs, it seems to always get a internal
type-check error.
__ __ __ __ ____ ___ _________________________________________
|| || || || || || ||__ Hugs 98: Based on the Haskell 98 standard
||___|| ||__|| ||__|| __|| Copyright (c) 1994-1999
||---|| ___|| World Wide Web: http://haskell.org/hugs
|| || Report bugs to: hugs-bugs@haskell.org
|| || Version: November 1999 _________________________________________
Hugs mode: Restart with command line option +98 for Haskell 98 mode
Reading file "C:\LANG\HUGS98\lib\Prelude.hs":
Hugs session for:
C:\LANG\HUGS98\lib\Prelude.hs
Type :? for help
Prelude> :l scripts/error.hs
Reading file "scripts/error.hs":
Type checking
INTERNAL ERROR: findBtyvsInt
Prelude>
best,
leon
------=_NextPart_000_0137_01C04ABA.CBF3D120
Content-Type: application/octet-stream;
name="error.hs"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="error.hs"
class Set set a where
empty :: set a
-- hasElem :: set a -> a -> set a
-- addElem :: set a -> a -> set a
data Ord a => Tree a b =
Leaf a b
| Branch (Tree a b) a (Tree a b)
lookupKey :: Ord a => Tree a b -> a -> (a,b)
lookupKey (Leaf a b) key = (a,b)
lookupKey (Branch l a r) key
| key < a = lookupKey l key
| otherwise = lookupKey r key
addKey :: Ord a => Tree a b -> (a,b) -> Tree a b
addKey n@(Leaf a' _) (a,b)
| a < a' = (Branch (Leaf a b) a' n)
| a == a' = Leaf a b
| otherwise = (Branch n a (Leaf a b))
addKey (Branch l a' r) e@(a,b)
| a < a' = Branch (addKey l e) a' r
| otherwise = Branch l a' (addKey r e)
newtype Ord a => TreeSet a = MkTreeSet (Maybe (Tree a ()))
instance Ord a => Set TreeSet a where
empty = MkTreeSet Nothing
{- hasElem (MkTreeSet Nothing) elt = False
hasElem (MkTreeSet (Just t)) elt = elt == a
where (a,_) = lookupKey t elt
addElem (MkTreeSet Nothing) elt = MkTreeSet $ Just (Leaf elt ())
addElem (MkTreeSet (Just t)) elt = MkTreeSet $ addKey t (elt,())
-}
------=_NextPart_000_0137_01C04ABA.CBF3D120--
From jeff@galconn.com Fri Nov 10 07:42:40 2000
Date: Thu, 09 Nov 2000 23:42:40 -0800
From: Jeffrey R. Lewis jeff@galconn.com
Subject: Internal Type Error
Leon Smith wrote:
> I'm using some Multi-parameter Type Classes with the November 1999 version
> of Hugs98 on Windows command-line version and getting the following internal
> type error:
>
> WinHugs simply chokes and dies.
>
> At one point, the hugs command-line version was accepting the code if I
> commented out the function definitions but left the constant data
> definition, but after restarting hugs, it seems to always get a internal
> type-check error.
> __ __ __ __ ____ ___ _________________________________________
> || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard
> ||___|| ||__|| ||__|| __|| Copyright (c) 1994-1999
> ||---|| ___|| World Wide Web: http://haskell.org/hugs
> || || Report bugs to: hugs-bugs@haskell.org
> || || Version: November 1999 _________________________________________
>
> Hugs mode: Restart with command line option +98 for Haskell 98 mode
>
> Reading file "C:\LANG\HUGS98\lib\Prelude.hs":
>
> Hugs session for:
> C:\LANG\HUGS98\lib\Prelude.hs
> Type :? for help
> Prelude> :l scripts/error.hs
> Reading file "scripts/error.hs":
> Type checking
> INTERNAL ERROR: findBtyvsInt
> Prelude>
This is a known problem with the Nov '99 release. It's fixed in the Feb 2000
release.
--Jeff
From lps@po.cwru.edu Fri Nov 10 07:41:15 2000
Date: Fri, 10 Nov 2000 03:41:15 -0400
From: Leon Smith lps@po.cwru.edu
Subject: Internal Type Error
This is a multi-part message in MIME format.
------=_NextPart_000_0148_01C04AC8.141355E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
I found a minor mistake in the example code, but the same problem remains.
The "real" code is a 2-3-4 Tree which I'd like to use to implement a couple
different things, such as Finite Maps and Sets. It works fine without type
classes.
best,
leon
------=_NextPart_000_0148_01C04AC8.141355E0
Content-Type: application/octet-stream;
name="error.hs"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="error.hs"
class Set set a where
empty :: set a
hasElem :: set a -> a -> set a
addElem :: set a -> a -> set a
data Ord a => Tree a b =
Leaf a b
| Branch (Tree a b) a (Tree a b)
lookupKey :: Ord a => Tree a b -> a -> (a,b)
lookupKey (Leaf a b) key = (a,b)
lookupKey (Branch l a r) key
| key < a = lookupKey l key
| otherwise = lookupKey r key
addKey :: Ord a => Tree a b -> (a,b) -> Tree a b
addKey n@(Leaf a' _) (a,b)
| a < a' = (Branch (Leaf a b) a' n)
| a == a' = Leaf a b
| otherwise = (Branch n a (Leaf a b))
addKey (Branch l a' r) e@(a,b)
| a < a' = Branch (addKey l e) a' r
| otherwise = Branch l a' (addKey r e)
newtype Ord a => TreeSet a = MkTreeSet (Maybe (Tree a ()))
instance (Ord a) => Set TreeSet a where
empty = MkTreeSet Nothing
hasElem (MkTreeSet Nothing) elt = False
hasElem (MkTreeSet (Just t)) elt = elt == a
where (a,_) = lookupKey t elt
addElem (MkTreeSet Nothing) elt = MkTreeSet $ Just (Leaf elt ())
addElem (MkTreeSet (Just t)) elt = MkTreeSet $ Just (addKey t (elt,()))
------=_NextPart_000_0148_01C04AC8.141355E0--
From david.landell@spray.se Fri Nov 10 10:53:13 2000
Date: Fri, 10 Nov 2000 11:53:13 +0100
From: david.landell@spray.se david.landell@spray.se
Subject: Hugs98 under Redhat 7.0
Dear sirs,
I can't get hugs98 to work under my linuxplatform. I have the Red
Hat distirbution 7.0.
The problem is that hugs requires a file called "readline.so.3" and
I have "readline.so.4" on my system. Is there a way to come around
this problem??
Best regards,
David Landell
From tweed@compsci.bristol.ac.uk Fri Nov 10 11:51:56 2000
Date: Fri, 10 Nov 2000 11:51:56 +0000 (GMT)
From: D. Tweed tweed@compsci.bristol.ac.uk
Subject: Hugs98 under Redhat 7.0
On Fri, 10 Nov 2000 david.landell@spray.se wrote:
> Dear sirs,
> I can't get hugs98 to work under my linuxplatform. I have the Red
> Hat distirbution 7.0.
> The problem is that hugs requires a file called "readline.so.3" and
> I have "readline.so.4" on my system. Is there a way to come around
> this problem??
You've probably already checked this but... is there a hugs rpm on the CD
you can use. (I was pleasantly surprised to find Mandrake 7.2 came with
rpms for Hugs, ghc, happy & mercury.)
___cheers,_dave________________________________________________________
www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers
email: tweed@cs.bris.ac.uk | you have, half your time is spent
work tel: (0117) 954-5250 | waiting for compilations to finish.
From tweed@compsci.bristol.ac.uk Fri Nov 10 12:18:07 2000
Date: Fri, 10 Nov 2000 12:18:07 +0000 (GMT)
From: D. Tweed tweed@compsci.bristol.ac.uk
Subject: Hugs98 under Redhat 7.0
On Fri, 10 Nov 2000, D. Tweed wrote:
> On Fri, 10 Nov 2000 david.landell@spray.se wrote:
>
> > Dear sirs,
> > I can't get hugs98 to work under my linuxplatform. I have the Red
> > Hat distirbution 7.0.
> > The problem is that hugs requires a file called "readline.so.3" and
> > I have "readline.so.4" on my system. Is there a way to come around
> > this problem??
>
> You've probably already checked this but... is there a hugs rpm on the CD
> you can use. (I was pleasantly surprised to find Mandrake 7.2 came with
> rpms for Hugs, ghc, happy & mercury.)
Just checked and my Mandrake system has libreadline4 only and the hugs rpm
I installed works, so you could try the mandrake 7.2 hugs rpm. (Go to one
of the mirrors from www.linuxmandrake.com to download st.) Hugs is
entirely C code, so the differing C++ ABIs/libraries shouldn't be an
issue. (Just don't blame me if it don't work :-) )
___cheers,_dave________________________________________________________
www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers
email: tweed@cs.bris.ac.uk | you have, half your time is spent
work tel: (0117) 954-5250 | waiting for compilations to finish.
From reid@cs.utah.edu Fri Nov 10 19:28:08 2000
Date: Fri, 10 Nov 2000 12:28:08 -0700
From: Alastair Reid reid@cs.utah.edu
Subject: increasing control stack size?
> As I was getting "Control stack overflow" while
> attempting to generate large (>1MB) data files using Hugs,
> I recompiled Hugs with 10-fold increased value of the corresponding
> parameter (was 16K). Then I was able to do the necessary computations.
> However, I wonder if it was safe to so, i.e. that this change
> didn't break functionality of the Hugs system.
It should be fine.
The only risk is that, having eliminated the control-stack limit, you might run
into the C-stack limit. This tends to show itself as some kind of segmentation
fault.
> Hugs documentation sounds as if one gets "Control stack overflow" then
> it surely must be an infinite recursion; while in my case it's just
> concatenation of long (>20K) strings.
Well, that is the usual case. When it's not infinite recursion, it's usually
one of:
1) Strange operational behaviour due to laziness.
For example, this expression:
foldl (+) 0 [1..1000000]
would require constant space if strictly evaluated.
(It corresponds to a simple for loop in C.)
When evaluated lazily though, it first builds this thunk:
((((0+1)+2)+3)+...+1000000
(which takes a lot of heap space) and then evaluates it which
requires about 1000000 stack frames.
2) The quadratic concat problem.
Evaluating this:
[1] ++ ([2] ++ ([3] ++ [4]))
takes linear time in the length of the list. (As you'd expect.)
And requires constant stack space.
Evaluating this:
((([1] ++ [2]) ++ [3]) ++ [4]
takes time quadratic in the length of the list
and requires stack space which is linear in the length of the list
(I think - I haven't checked the stack space claim and laziness makes
it hard to just guess.)
The reason for the difference is that ++ takes time proportional to the
length of its first argument. The first version appends a singleton
list onto a bigger list N times. The second version appends an
increasingly long list onto a singleton list N times.
Of course, Haskell defines that ++ associates to the right so the problem
doesn't show up in single expressions. But it appears very rapidly if
you write a recursive function which constructs a list by appending
the result of recursive calls to itself. For example:
data Tree a = Leaf a | Branch (Tree a) (Tree a)
showTree :: Show a => Tree a -> String
showTree (Leaf x) = show x
showTree (Branch l r) = "(" ++ showTree l ++ "," ++ showTree r ++ ")"
run that on big enough a tree and you'll be doing an awful lot of work.
The usual fix is to avoid calling ++ with unbounded size arguments
using an extra argument which you want the result to be appended to.
That is, we define a new function "showTree'" which satisfies this
equation:
showTree' t s = showTree t ++ s
but whose definition is:
showTree' :: Show a => Tree a -> String -> String
showTree' (Leaf x) s = show x ++ r
showTree' (Branch l r) s = "(" ++ showTree' l ("," ++ showTree' r (")" ++
s)
This still calls ++ but the result of showTree' is never used as the first
argument of ++. The result runs in time proportional to the size of the
output and (probably) stack space proportional to the height of the tree.
Simon Peyton Jones' book "Implementing Functional Languages" has a
longer discussion of this in chapter 1. (Many other books discuss it too
and might be more useful to a Haskell user - but that's the one I know.)
Hope this helps,
Alastair Reid
> I guess it would've been nice if
> documentation said something more about that, and explained ways of
> increasing stack size.
>
> IMHO, some internal Hugs part uses the stack (thus, something that is
> not controllable by the command line options) for data that ought to
> be held in the heap (whose size is controllable by command line
> options)...
>
> Best regards,
> Dmitrii Pasechnik
> http://ssor.twi.tudelft.nl/~dima/
>
>
>
>
>
> _______________________________________________
> Hugs-Bugs mailing list
> Hugs-Bugs@haskell.org
> http://www.haskell.org/mailman/listinfo/hugs-bugs
>
From Micha@tiscom.com Wed Nov 15 15:25:35 2000
Date: Wed, 15 Nov 2000 16:25:35 +0100
From: Micha Pringle Micha@tiscom.com
Subject: Quick question
I'd like to make a simple infix expression evaluator.
It should be able to support simple functions, such as *, +, -,/ as well as
simpl recursion.
That is, if I define
G <- 19
H <- G + 6
evaluate G shoulr return 25
Anyone know a good webpage for some info?
cheers,
Micha
__________________________________________
Micha Pringle
Systems Development
TISCOM Systems
Albisriederstrasse 365
CH-8047 Zurich
Switzerland
Tel: +41 (0)1 405 60 80
Fax: +41 (0)1 405 60 99
e-mail: micha.pringle@tiscom.com
__________________________________________
From Micha@tiscom.com Wed Nov 15 15:30:44 2000
Date: Wed, 15 Nov 2000 16:30:44 +0100
From: Micha Pringle Micha@tiscom.com
Subject: Extra uinfo RE: Quick question
I want a web page that has some decent information because I may expand on
my trivial implementation to support additional functions. Thus I want to
start with a good design that can be generalized (which is why I am asking).
Sorry for any confusion.
I'd like to make a simple infix expression evaluator.
It should be able to support simple functions, such as *, +, -,/ as well as
simple recursion.
That is, if I define
G <- 19
H <- G + 6
evaluate G should return 25
Anyone know a good webpage for some info?
cheers,
Micha
__________________________________________
Micha Pringle
Systems Development
TISCOM Systems
Albisriederstrasse 365
CH-8047 Zurich
Switzerland
Tel: +41 (0)1 405 60 80
Fax: +41 (0)1 405 60 99
e-mail: micha.pringle@tiscom.com
__________________________________________
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@haskell.org
http://www.haskell.org/mailman/listinfo/hugs-bugs
From reid@cs.utah.edu Fri Nov 17 18:46:05 2000
Date: Fri, 17 Nov 2000 11:46:05 -0700
From: Alastair Reid reid@cs.utah.edu
Subject: Win32 library on Hugs download page is out of date
The Win32 library on the Hugs download page
http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/downloading.htm
is out of date and bears little resemblance to that in the CVS repository.
This is causing repeated problems for users of the graphics library.
A more current version can be found in
http://haskell.org/graphics/downloads/Win32.zip
Can you please, please, please, replace the old copy with the above?
(Or build your own from the CVS tree. Or just delete the link.)
Thanks,
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From paul.hudak@yale.edu Fri Nov 17 19:21:36 2000
Date: Fri, 17 Nov 2000 14:21:36 -0500
From: Paul Hudak paul.hudak@yale.edu
Subject: Win32 library on Hugs download page is out of date
Yes, please do this soon, if you can, as it is affecting users of my
book! :-)
Thanks, -Paul
Alastair Reid wrote:
> The Win32 library on the Hugs download page
> http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/downloading.htm
> is out of date and bears little resemblance to that in the CVS repository.
> This is causing repeated problems for users of the graphics library.
> A more current version can be found in
> http://haskell.org/graphics/downloads/Win32.zip
> Can you please, please, please, replace the old copy with the above?
> (Or build your own from the CVS tree. Or just delete the link.)
From riaz.ahmad@cwcom.net Sat Nov 18 08:23:50 2000
Date: Sat, 18 Nov 2000 00:23:50 -0800
From: Riaz Ahmad riaz.ahmad@cwcom.net
Subject: (no subject)
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01C050F5.D35449E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello
I've been trying to download the Feb2000 versions for Win32 of Hugs - =
which is OK.
When I unzip and run, the Hugs window opens with a fatal error warning =
saying "could
not load prelude", and subsequently crashes. Any ideas on how I can =
overcome this
and get Hugs to run properly.
I'd welcome any assistance/comments.
Thanks
Riaz Ahmad
------=_NextPart_000_0005_01C050F5.D35449E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial>Hello</FONT></DIV>
<DIV><FONT face=3DArial></FONT> </DIV>
<DIV><FONT face=3DArial>I've been trying to download the Feb2000 =
versions for=20
Win32 of Hugs - which is OK.</FONT></DIV>
<DIV><FONT face=3DArial>When I unzip and run, the Hugs window opens with =
a fatal=20
error warning saying "could</FONT></DIV>
<DIV><FONT face=3DArial>not load prelude", and subsequently crashes. Any =
ideas on=20
how I can overcome this</FONT></DIV>
<DIV><FONT face=3DArial>and get Hugs to run properly.</FONT></DIV>
<DIV><FONT face=3DArial>I'd welcome any =
assistance/comments.</FONT></DIV>
<DIV><FONT face=3DArial>Thanks</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial>Riaz Ahmad</FONT></DIV></BODY></HTML>
------=_NextPart_000_0005_01C050F5.D35449E0--
From Dominic.J.Steinitz@BritishAirways.com Mon Nov 20 09:19:22 2000
Date: 20 Nov 2000 09:19:22 Z
From: Steinitz, Dominic J Dominic.J.Steinitz@BritishAirways.com
Subject: Invalid Page Fault
--PART.BOUNDARY.bawhub1.5661.3a18eca1.0001
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
---------------------- Forwarded by Dominic Steinitz/HEATHROW/BRITISH AIRWAYS/GB on 20/11/2000 09:18 ---------------------------
Dominic Steinitz
19/11/2000 00:27
To: hugs-bugs
cc:
bcc:
Subject: Invalid Page Fault
HUGS caused an invalid page fault in
module HUGS.EXE at 0137:00406d72.
Registers:
EAX=fffd54da CS=0137 EIP=00406d72 EFLGS=00010297
EBX=00000000 SS=013f ESP=006e0000 EBP=007dfbd0
ECX=fffc2f70 DS=013f ESI=fffd54f6 FS=0e17
EDX=00000200 ES=013f EDI=00c14250 GS=0000
Bytes at CS:EIP:
50 e8 e8 00 00 00 8b 15 04 ef 4c 00 83 c4 04 89
Stack dump:
00000020 fffd551a 00406f07 00000002 fffd551e 00406edf fffd551a 00c14250 fffd5524 00406d78 fffd551e 00000040 fffd5539 00406f07 00000004 fffd553d
Here's the session details. c 2 works ok as below but c 80 causes the page fault.
Dominic.
__ __ __ __ ____ ___ _________________________________________
|| || || || || || ||__ Hugs 98: Based on the Haskell 98 standard
||___|| ||__|| ||__|| __|| Copyright (c) 1994-1999
||---|| ___|| World Wide Web: http://haskell.org/hugs
|| || Report bugs to: hugs-bugs@haskell.org
|| || Version: February 2000 _________________________________________
Hugs mode: Restart with command line option +98 for Haskell 98 mode
Reading file "C:\HUGS98\lib\Prelude.hs":
Reading file "C:\My Documents\functional\parser\hugsprob.hs":
Reading file "C:\My Documents\functional\parser\UU_Parsing.hs":
Reading file "C:\My Documents\functional\parser\hugsprob.hs":
Hugs session for:
C:\HUGS98\lib\Prelude.hs
C:\My Documents\functional\parser\UU_Parsing.hs
C:\My Documents\functional\parser\hugsprob.hs
Type :? for help
Main> c 2
([Entry{dN=DN{eN=Just (EmployeeNumber "3729"),ou=Ou "People",o=Organisation "bap
lc.com",dc=DC "pathway"},unitHierarchyCode=Just (UnitHierarchyCode "BAIOMH"),tel
ephoneExtnNumber=Just (TelephoneExtnNumber "27635"),ou'=Ou "People",manager=Just
(Manager DN{eN=Just (EmployeeNumber "652413"),ou=Ou "People",o=Organisation "ba
plc.com",dc=DC "pathway"}),objectClasses=[ObjectClass "top",ObjectClass "person"
,ObjectClass "organizationalPerson",ObjectClass "inetOrgPerson",ObjectClass "pth
wyOrgPerson"]},Entry{dN=DN{eN=Just (EmployeeNumber "3729"),ou=Ou "People",o=Orga
nisation "baplc.com",dc=DC "pathway"},unitHierarchyCode=Just (UnitHierarchyCode
"BAIOMH"),telephoneExtnNumber=Just (TelephoneExtnNumber "27635"),ou'=Ou "People"
,manager=Just (Manager DN{eN=Just (EmployeeNumber "652413"),ou=Ou "People",o=Org
anisation "baplc.com",dc=DC "pathway"}),objectClasses=[ObjectClass "top",ObjectC
lass "person",ObjectClass "organizationalPerson",ObjectClass "inetOrgPerson",Obj
ectClass "pthwyOrgPerson"]}],"",)
(62505 reductions, 124185 cells)
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
--PART.BOUNDARY.bawhub1.5661.3a18eca1.0001
Content-Type: application/octet-stream; name="hugsprob.hs"
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename="hugsprob.hs"
Content-Description: hugsprob.hs
FTBP-Modification-Date: 20 Nov 2000 09:19:00 Z
FTBP-Object-Size: 3732
aW1wb3J0IFVVX1BhcnNpbmcNCg0KaW5zdGFuY2UgU3ltYm9sIENoYXINCg0KZGF0YSBVaWQgPSBV
aWQgU3RyaW5nDQogICBkZXJpdmluZyBTaG93DQoNCmRhdGEgT3UgPSBPdSBTdHJpbmcNCiAgIGRl
cml2aW5nIFNob3cNCg0KZGF0YSBFbXBsb3llZU51bWJlciA9IEVtcGxveWVlTnVtYmVyIFN0cmlu
Zw0KICAgZGVyaXZpbmcgU2hvdw0KDQpkYXRhIE9yZ2FuaXNhdGlvbiA9IE9yZ2FuaXNhdGlvbiBT
dHJpbmcNCiAgIGRlcml2aW5nIFNob3cNCg0KZGF0YSBEQyA9IERDIFN0cmluZw0KICAgZGVyaXZp
bmcgU2hvdw0KDQpkYXRhIEROID0gRE4geyBlTiA6OiBNYXliZSBFbXBsb3llZU51bWJlciwNCiAg
ICAgICAgICAgICAgIG91IDo6IE91LA0KICAgICAgICAgICAgICAgbyAgOjogT3JnYW5pc2F0aW9u
LA0KICAgICAgICAgICAgICAgZGMgOjogREMNCiAgICAgICAgICAgICB9DQogICBkZXJpdmluZyBT
aG93DQoNCmRhdGEgTWFuYWdlciA9IE1hbmFnZXIgRE4NCiAgIGRlcml2aW5nIFNob3cNCg0KZGF0
YSBFbnRyeSA9IEVudHJ5IHsgZE4gOjogRE4sDQogICAgICAgICAgICAgICAgICAgICB1bml0SGll
cmFyY2h5Q29kZSA6OiBNYXliZSBVbml0SGllcmFyY2h5Q29kZSwNCiAgICAgICAgICAgICAgICAg
ICAgIHRlbGVwaG9uZUV4dG5OdW1iZXIgOjogTWF5YmUgVGVsZXBob25lRXh0bk51bWJlciwNCiAg
ICAgICAgICAgICAgICAgICAgIG91JyA6OiBPdSwgbWFuYWdlciA6OiBNYXliZSBNYW5hZ2VyLA0K
ICAgICAgICAgICAgICAgICAgICAgb2JqZWN0Q2xhc3NlcyA6OiBbT2JqZWN0Q2xhc3NdIH0NCiAg
IGRlcml2aW5nIFNob3cNCg0KZGF0YSBPYmplY3RDbGFzcyA9IE9iamVjdENsYXNzIFN0cmluZw0K
ICAgZGVyaXZpbmcgU2hvdw0KDQpkYXRhIFVuaXRIaWVyYXJjaHlDb2RlID0gVW5pdEhpZXJhcmNo
eUNvZGUgU3RyaW5nDQogICBkZXJpdmluZyBTaG93DQoNCnBVbml0SGllcmFyY2h5Q29kZSA9IA0K
ICAgcGFyc2VBdHRyaWJ1dGUgKEp1c3QgLiBVbml0SGllcmFyY2h5Q29kZSkgInVuaXRoaWVyYXJj
aHljb2RlIg0KDQpkYXRhIFRlbGVwaG9uZUV4dG5OdW1iZXIgPSBUZWxlcGhvbmVFeHRuTnVtYmVy
IFN0cmluZw0KICAgZGVyaXZpbmcgU2hvdw0KDQpwVGVsZXBob25lRXh0bk51bWJlciA9IA0KICAg
cGFyc2VBdHRyaWJ1dGUgKEp1c3QgLiBUZWxlcGhvbmVFeHRuTnVtYmVyKSAidGVsZXBob25lZXh0
bm51bWJlciINCg0KcEtleSBbXSA9IHBTdWNjZWVkIFtdDQpwS2V5IChzOnNzKSA9ICg6KSA8JD4g
cFN5bSBzIDwqPiBwS2V5IHNzDQoNCnBTcGFjZXMgPSBwTSAocFN5bSAnICcpIDx8PiBwU3VjY2Vl
ZCBbXQ0KDQpwTSBwID0gbGV0IG1hbnlwID0gKHBTdWNjZWVkIFtdKQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDx8PiAgKDopIDwkPiBwIDwqPiBtYW55cA0KICAgICAgICAgICAgICAgIGlu
ICg6KSA8JD4gcCA8Kj4gbWFueXANCg0KcExvd2VyQ2FzZSA9IHBBbnlPZiBbJ2EnLi4neiddDQpw
VXBwZXJDYXNlID0gcEFueU9mIFsnQScuLidaJ10NCnBEaWdpdCAgICAgPSBwQW55T2YgWycwJy4u
JzknXQ0KcERvdCAgICAgICA9IHBTeW0gJy4nDQoNCnBWYWx1ZSA9IHBNIChwTG93ZXJDYXNlIDx8
PiBwVXBwZXJDYXNlIDx8PiBwRGlnaXQgPHw+IHBEb3QpDQoNCnBOdW1iZXIgPSBwTSBwRGlnaXQN
Cg0KcExEQVBTZXAgPSBwS2V5ICI9IiA8fD4gcEtleSAiOiAiDQoNCnBhcnNlQXR0cmlidXRlIGhB
IGxBID0gaEEgPCQgcEtleSBsQSA8KiBwTERBUFNlcCA8Kj4gcFZhbHVlDQoNCnBPdSA9IHBhcnNl
QXR0cmlidXRlIE91ICJvdSINCg0KcERDID0gcGFyc2VBdHRyaWJ1dGUgREMgImRjIg0KDQpwT3Jn
YW5pc2F0aW9uID0gcGFyc2VBdHRyaWJ1dGUgT3JnYW5pc2F0aW9uICJvIg0KDQpwRW1wbG95ZWVO
dW1iZXIgPSBwYXJzZUF0dHJpYnV0ZSAoSnVzdCAuIEVtcGxveWVlTnVtYmVyKSAiZW1wbG95ZWVO
dW1iZXIiDQoNCnBPYmplY3RDbGFzcyA9IHBhcnNlQXR0cmlidXRlIE9iamVjdENsYXNzICJvYmpl
Y3RjbGFzcyINCg0KcE9iamVjdENsYXNzZXMgPSBwTGlzdFNlcCAocEtleSAiXG4iKSBwT2JqZWN0
Q2xhc3MNCg0KcERuQ29tcG9uZW50cyA9ICAgICBETg0KICAgICAgICAgICAgICAgIDwkPiAocEVt
cGxveWVlTnVtYmVyIDwqIHBTeW0gJywnIGBvcHRgIE5vdGhpbmcpDQogICAgICAgICAgICAgICAg
PCo+IHBPdQ0KICAgICAgICAgICAgICAgIDwqICBwU3ltICcsJw0KICAgICAgICAgICAgICAgIDwq
PiBwT3JnYW5pc2F0aW9uDQogICAgICAgICAgICAgICAgPCogIHBTeW0gJywnDQogICAgICAgICAg
ICAgICAgPCo+IHBEQw0KDQpwRG4gPSAgIHBLZXkgImRuOiAiICo+IHBEbkNvbXBvbmVudHMNCg0K
cE1hbmFnZXIgPSAoSnVzdCAuIE1hbmFnZXIpIDwkIHBLZXkgIm1hbmFnZXIiIDwqIHBMREFQU2Vw
IDwqPiBwRG5Db21wb25lbnRzDQoNCnBFbnRyeSA9ICAgICBFbnRyeSANCiAgICAgICAgIDwkPiBw
RG4gDQogICAgICAgICA8KiAgcFN5bSAnXG4nIA0KICAgICAgICAgPCo+IChwVW5pdEhpZXJhcmNo
eUNvZGUgPCogcFN5bSAnXG4nIGBvcHRgIE5vdGhpbmcpDQogICAgICAgICA8Kj4gKHBUZWxlcGhv
bmVFeHRuTnVtYmVyIDwqIHBTeW0gJ1xuJyBgb3B0YCBOb3RoaW5nKQ0KICAgICAgICAgPCo+IHBP
dSANCiAgICAgICAgIDwqICBwU3ltICdcbicgDQogICAgICAgICA8Kj4gKHBNYW5hZ2VyIDwqIHBT
eW0gJ1xuJyBgb3B0YCBOb3RoaW5nKQ0KICAgICAgICAgPCo+IHBPYmplY3RDbGFzc2VzDQoNCnBF
bnRyaWVzID0gcExpc3RTZXAgKHBLZXkgIlxuXG4iKSBwRW50cnkNCg0Kb2JqZWN0Q2xhc3NUZXN0
MSA9ICJvYmplY3RjbGFzczogdG9wIg0Kb2JqZWN0Q2xhc3NUZXN0MiA9ICJvYmplY3RjbGFzczog
cGVyc29uIg0Kb2JqZWN0Q2xhc3NUZXN0MyA9ICJvYmplY3RjbGFzczogb3JnYW5pemF0aW9uYWxQ
ZXJzb24iDQpvYmplY3RDbGFzc1Rlc3Q0ID0gIm9iamVjdGNsYXNzOiBpbmV0T3JnUGVyc29uIg0K
b2JqZWN0Q2xhc3NUZXN0NSA9ICJvYmplY3RjbGFzczogcHRod3lPcmdQZXJzb24iDQoNCm9iamVj
dENsYXNzVGVzdCA9IGZvbGRyMSAoKCsrKSAuICgrKyJcbiIpKSBbb2JqZWN0Q2xhc3NUZXN0MSwN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2JqZWN0Q2xhc3NU
ZXN0MiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2JqZWN0
Q2xhc3NUZXN0MywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
b2JqZWN0Q2xhc3NUZXN0NCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgb2JqZWN0Q2xhc3NUZXN0NV0NCg0KcjEgPSAiZG46IGVtcGxveWVlTnVtYmVyPTM3Mjks
b3U9UGVvcGxlLG89YmFwbGMuY29tLGRjPXBhdGh3YXkiDQpyMiA9ICJ1bml0aGllcmFyY2h5Y29k
ZTogQkFJT01IIg0KcjMgPSAidGVsZXBob25lZXh0bm51bWJlcjogMjc2MzUiDQpyNCA9ICJvdTog
UGVvcGxlIg0KcjUgPSAibWFuYWdlcjogZW1wbG95ZWVOdW1iZXI9NjUyNDEzLG91PVBlb3BsZSxv
PWJhcGxjLmNvbSxkYz1wYXRod2F5Ig0KDQpyID0gZm9sZHIxICgoKyspIC4gKCsrIlxuIikpIFty
MSxyMixyMyxyNCxyNV0NCnInID0gciArKyAiXG4iICsrIG9iamVjdENsYXNzVGVzdA0KcicnIG4g
PSBmb2xkcjEgKCgrKykgLiAoKysiXG5cbiIpKSAocmVwbGljYXRlIG4gcicpDQoNCmMgbSA9IHBh
cnNlIHBFbnRyaWVzIG51bGwgKHInJyBtKQ0K
--PART.BOUNDARY.bawhub1.5661.3a18eca1.0001--
From koen@cs.chalmers.se Thu Nov 23 14:27:56 2000
Date: Thu, 23 Nov 2000 15:27:56 +0100 (MET)
From: Koen Claessen koen@cs.chalmers.se
Subject: Bug in Dependent Parameters?
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
---559023410-838832689-974989676=:1495
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
I am running "hugs -98" on Solaris, version February 2000.
I get the following strange error message:
>>>
Main> generalZipWith (+) [1,2,3] [3,4,5] :: [Int]
ERROR: Cannot justify constraints in type annotation
*** Expression : generalZipWith (+) [1,2,3] [3,4,5]
*** Type : [Int]
*** Given context : ()
*** Constraints : (Num Int, Num Int, Num Int, Num Int, Num Int, Num Int, Num Int)
<<<
Apart from looking at the program that generates this
message, isn't it a bit strange that it complains about
unjustified constraints of the form "Num Int"? How can this
constraint be unjustified??
When I write all the types explicitly I get the correct
answer:
>>>
Main> generalZipWith (+) ([1,2,3]::[Int]) ([3,4,5]::[Int]) :: [Int]
[4,6,8]
<<<
The program generating this is attached.
Regards,
Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden
---559023410-838832689-974989676=:1495
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="zipper.hs"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SOL.4.21.0011231527560.1495@muppet23.cs.chalmers.se>
Content-Description:
Content-Disposition: attachment; filename="zipper.hs"
DQpjbGFzcyBaaXAgYSBiIHwgYiAtPiBhIHdoZXJlDQogIHppcHBlciA6OiBb
YV0gLT4gYg0KDQppbnN0YW5jZSBaaXAgYSBbYV0gd2hlcmUNCiAgemlwcGVy
IGFzID0gYXMNCg0KaW5zdGFuY2UgWmlwIGEgYiA9PiBaaXAgKHggLT4gYSkg
KFt4XSAtPiBiKSB3aGVyZQ0KICB6aXBwZXIgZnMgYXMgPSB6aXBwZXIgKHpp
cFdpdGggKCQpIGZzIGFzKQ0KDQpnZW5lcmFsWmlwV2l0aCA6OiBaaXAgYSBi
ID0+IGEgLT4gYg0KZ2VuZXJhbFppcFdpdGggZiA9IHppcHBlciAocmVwZWF0
IGYpDQo=
---559023410-838832689-974989676=:1495--
From phoenix@esther.donga.ac.kr Sat Nov 25 12:01:47 2000
Date: Sat, 25 Nov 2000 21:01:47 +0900
From: Wooseok Yang phoenix@esther.donga.ac.kr
Subject: unsubscribe hugs-bugs
dW5zdWJzY3JpYmUgaHVncy1idWdzDQo=
From koen@cs.chalmers.se Wed Nov 29 13:05:51 2000
Date: Wed, 29 Nov 2000 14:05:51 +0100 (MET)
From: Koen Claessen koen@cs.chalmers.se
Subject: ERROR: Too many ForeignObjs open
Hi,
Playing around with H/Direct, I often get the error:
ERROR: Too many ForeignObjs open
I think that in my case, a simple garbage collect would get
rid of a lot of these foreign objects. Is this true? In
other words: would a garbage collect just before this error
is generated help?
Regards,
Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden