- Hugs-Bugs - Haskell.org

[Hugs-bugs] Re: Enum Int problem
by Alastair Reid 18 Aug '04

18 Aug '04

[copied to hugs-bugs] You shouldn't hope to get any useful results from Int after an arithmetic overflow since the Haskell report explicitly says that the results are unspecified. If you want predictable results, you should use Integer or Foreign.Int32. The latter is part of the foreign interface extension which is implemented by nhc, ghc and Hugs. I believe that Hugs is giving a correct answer in this case in that nothing strange happens until after the overflow occurs. Of course the answer is not _useful_ but, as I said, you shouldn't expect useful results after an overflow occurs. I think that GHC may be giving an incorrect answer because I think the 0 should appear in the list but it would take a very careful examination of how the Haskell report specifies the Enum Int instance to be sure. -- Alastair Reid ps When I say 'after an overflow', what I mean is that the value of X is undefined if the value of X depends on the value of Y and Y overflowed. On Friday 13 August 2004 19:39, you wrote: > Using GHC 6.2.1 interpreter, the fragment [minBound :: Int, 0 ..] returns > [-2147483648]. > > Using Hugs, the returned value is the infinite list [-2147483648, 0, > -2147483648, 0, ...]. > > However, I would expect to get [-2147483648, 0]. Similar problems occur > with the other arithmetic sequence functions for Int when the increment is > greater than what is representable in the type.

1 0

[Hugs-bugs] new C preprocessor breaks hugs' build process
by Paul Stoeber 13 Aug '04

13 Aug '04

bash-2.03$ cat old infix 5 \\ bash-2.03$ cat -vet old infix 5 \\ $ $ bash-2.03$ cat new infix 5 \\ -- bash-2.03$ cpp-2.95 old # 1 "old" infix 5 \\ bash-2.03$ cpp-2.95 new # 1 "new" infix 5 \\ -- bash-2.03$ cpp-3.4.1 old # 1 "old" # 1 "<built-in>" # 1 "<command line>" # 1 "old" old:1:10: warning: backslash and newline separated by space infix 5 \ bash-2.03$ cpp-3.4.1 new # 1 "new" # 1 "<built-in>" # 1 "<command line>" # 1 "new" infix 5 \\ -- bash-2.03$ The new behavior is documented in cpp.info of the gcc-3.4.1 distribution. Line 212 of hugs98-Nov2003/fptools/libraries/base/Data/List.hs expects the old behavior.

1 0

[Hugs-bugs] WinHugs: Error messages stays forever
by Henk-Jan.van.Tuyl＠hotpop.com 17 Jun '04

17 Jun '04

L.S., After giving the commands: :l Monad :a Monad the message: ERROR "C:\PROGRAM FILES\HUGS98/libraries\Monad.hs" - Module "Monad" already loaded repeats at every expression I want to have evaluated: putStrLn "Festina lente" results in ERROR "C:\PROGRAM FILES\HUGS98/libraries\Monad.hs" - Module "Monad" already loaded System: Windows 98 Hugs version: Nov 2003 Best regards, Henk-Jan van Tuyl

1 0

[Hugs-bugs] :find command can not find foldl'
by hjgtuyl＠chello.nl 13 Jun '04

13 Jun '04

L.S., When I give the command: :find foldl' in Hugs (Version Nov 2003), I receive the message: ERROR - No current definition for name "foldl'" When I give the command: :find foldl the editor appears, with the definition of foldl in view. Greetings, Henk-Jan van Tuyl -- -------------------------------------------------------------------- Festina Lente Hasten Slowly Haast U langzaam Eile langsam Skynd dig langsomt Affrettati lentamente Spěchej pomalu Skynda långsamt Desiderius Erasmus --------------------------------------------------------------------

2 1

RE: [Hugs-bugs] problems building on Solaris
by herington, dean 01 Jun '04

01 Jun '04

> -----Original Message----- > From: Alastair Reid [mailto:alastair@reid-consulting-uk.ltd.uk] > Sent: Tuesday, June 01, 2004 10:27 AM > To: herington, dean > Subject: Re: [Hugs-bugs] problems building on Solaris > > > It looks as though you want to use one of: > > '-r' > or > '-Dy -G' > > I think both of these are equally likely to work. Hugs needs > something it can > load with dlopen and one part of the page says this means it > must be a shared > library (so use -Dy -G) but Sigbjorn Finne used to strongly > believe that all > that was wanted was a relocatable object file (so use -r). '-r' is what configure chose, but it didn't work for me. '-dy -G' (note: lower-case 'd') did work! Thanks! > > Other flags you might play with are: > > -z combreloc > Make loading a little faster. > > -z defs > I think this would catch errors sooner. > > but I don't think they will improve the chances of it > working, so try -r and > '-dy -G' first. > > -- > Alastair > > ps The problem is not Hugs+Solaris but Hugs+SunOS ld (instead > of gcc ld).

3 2

RE: [Hugs-bugs] problems building on Solaris
by herington, dean 01 Jun '04

01 Jun '04

After a hiatus, I'm back trying to get Hugs built for Solaris. I never had a reply to the message attached below. Can anyone help? One newly noticed bit of puzzlement: configure yields: /* C compiler invocation use to build a dynamically loadable library. * Typical value: "gcc -shared" * Must evaluate to a literal C string. */ #define MKDLL_CMD "gcc -g -r" but I can't find any mention of "-r" for gcc on Sparc. Dean > -----Original Message----- > From: hugs-bugs-bounces(a)haskell.org > [mailto:hugs-bugs-bounces@haskell.org] On Behalf Of herington, dean > Sent: Thursday, April 08, 2004 10:03 AM > To: 'Alastair Reid'; hugs-bugs(a)haskell.org > Subject: RE: [Hugs-bugs] problems building on Solaris > > > > -----Original Message----- > > From: hugs-bugs-bounces(a)haskell.org > > [mailto:hugs-bugs-bounces@haskell.org] On Behalf Of Alastair Reid > > Sent: Wednesday, April 07, 2004 6:21 PM > > To: hugs-bugs(a)haskell.org > > Subject: Re: [Hugs-bugs] problems building on Solaris > > > > > > Looks like it's trying to put a value bigger than 22 bits > > (about 4 million) > > into a 22 bit slot. If so, you need to persuade your C > > compiler to use > > bigger slots. Maybe the compiler/assembler/linker has a 'big > > binary' flag > > you can supply? > > > > What compiler are you using? (grep MKDLL_CMD src/config.h) > > > > If you see a plausible flag to use, tweak MKDLL_CMD in src/config.h > > to try it and let us know if it works. > > > > -- > > Alastair Reid > > I'm using: > GNU C version 3.2.2 (sparc-sun-solaris2.8) > compiled by GNU C version 3.2.2. > /usr/ccs/bin/as: Sun WorkShop 6 update 2 Compiler Common 6.2 > Solaris_9_CBE > 2001/04/02 > ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.343 > on: > SunOS lca1071 5.9 Generic sun4u sparc > > I don't see any switches in any of these tools' man pages for "big > binaries". > > Dean > > P.S. Please confirm my understanding of the error. It > appears that Hugs is > trying to compile the Network/BSD module (to a shared object > BSD.so) when > dynamic linking fails, and that the erroneous BSD.so is > produced anyway. > > Compiling ../../hugsdir/libraries/Network/BSD.hs > runhugs: Error occurred > ERROR "../../hugsdir/libraries/Network/BSD.hs" - Error while > importing DLL > "/emc/dheringt/hugs98-Nov2003/hugsdir/libraries/Network/BSD.so": > ld.so.1: ../ffihugs: fatal: relocation error: R_SPARC_WDISP22: file > /emc/dheringt/hugs98-Nov2003/hugsdir/libraries/Network/BSD.so: symbol > _cerror: value 0x20c5d4 does not fit > > > > > On Wednesday 07 April 2004 20:13, herington, dean wrote: > > > In trying to build Hugs using > > > > > <http://cvs.haskell.org/Hugs/downloads/Nov2003> > /hugs98-Nov2003.tar.gz> > > > > > http://cvs.haskell.org/Hugs/downloads/Nov2003/hugs98-Nov2003.t > ar.gz for > > Solaris (SunOS lca1071 5.9 Generic sun4u sparc), I get > fatal relocation > > errors. Any idea of what's wrong? > > > > ... > > > > relocation error: R_SPARC_WDISP22: file > > > /emc/dheringt/hugs98-Nov2003/hugsdir/libraries/Network/BSD.so: symbol > > _cerror: value 0x20c5d4 does not fit > _______________________________________________ > Hugs-Bugs mailing list > Hugs-Bugs(a)haskell.org > http://www.haskell.org/mailman/listinfo/hugs-bugs > _______________________________________________ > Hugs-Bugs mailing list > Hugs-Bugs(a)haskell.org > http://www.haskell.org/mailman/listinfo/hugs-bugs >

2 1

[Hugs-bugs] Re: [Haskell] Bug in experimental Unicode support for Hugs?
by Ross Paterson 28 May '04

28 May '04

On Fri, May 28, 2004 at 01:20:32PM +0100, Graham Klyne wrote: > I've noticed a discrepancy in by version of Hugs with experimental Unicode > support enabled, based on the 20040109 codebase. It's exemplified by this: > > [[ > Main> '\x10ffff' > '\1114111' > Main> maxBound::Char > '\255' > Main> > ]] > > It appears that this value is hardcoded in Hugs/Prelude.hs, rather than > obtained from the runtime environment in some way. I think you're using an old version of Hugs/Prelude.hs. You need to copy the new versions of files in libraries/Hugs from the source bundle to wherever Hugs is looking for them (-q will tell you where).

1 0

[Hugs-bugs] broken links
by Paul Hudak 27 May '04

27 May '04

Dear Hugs maintainers -- There are several links that are broken on the Nov2002 download page at http://cvs.haskell.org/Hugs/pages/downloading-Nov2002.htm. These are important to me because the current release of Hugs is compatible with the graphics library used in my book (SOE), so for now I have been pointing people to the Nov2002 release. Two of the links I know how to fix: cvs.haskell.org/Hugs/downloads/GraphicsLib.msi should be cvs.haskell.org/Hugs/downloads/Nov2002/GraphicsLib.msi and cvs.haskell.org/Hugs/downloads/SOE.msi should be cvs.haskell.org/Hugs/downloads/Nov2002/SOE.msi But several of the others (involving sources, Unix, and Linux) I don't know how to fix. I would appreciate it if you could update these links, expecially the two above. Thanks, -Paul Hudak -- Professor Paul Hudak Chair, Dept of Computer Science Office: (203) 432-1235 Yale University FAX: (203) 432-0593 P.O. Box 208285 email: paul.hudak(a)yale.edu New Haven, CT 06520-8285 WWW: www.cs.yale.edu/~hudak

1 0

[Hugs-bugs] Re: Setting Search Path doesn't persist in WinHugs
by Greg Ballinger 05 May '04

05 May '04

AHA, I found the problem. When starting the WinHugs.exe file directly in C:\Program Files\Hugs98 it does use the persisted search path. However when starting it via the shortcuts installed in the Windows Start Menu system it does not. Evidently the shortcut in the menu uses an empty -P option when starting WinHugs. Sigbjorn Finne told me "I'll fix this in the next release, but creating your own shortcuts sounds like the simplest way out." For those unfamiliar with creating Windows shortcuts, an easy way to do this is: 1) navigate to the WinHugs.exe file, 2) right-click, 3) select Send to desktop (Create shortcut). 4) drag or copy the shortcut to wherever you want it. If you wish to set WinHugs command line options in your shortcut 1) right-click on the shortcut after you have created it 2) select Properties 3) Type your selected command line options at the end of target line Example: "C:\Program Files\Hugs98\winhugs.exe" +t will cause WinHugs to display the result and type of each expression entered at the Hugs prompt: Hope this is helpful and not too elementary. --Greg Ballinger

1 0

[Hugs-bugs] Re: [Hugs-users] Setting Search Path doesn't persist in WinHugs
by Sigbjorn Finne 26 Apr '04

26 Apr '04

Hi, odd, I'm unable to reproduce this here -- path settings are persisted OK in the Registry (this is with an account that lacks Admin privs), and I'm able to see them when restarting. There's three reasons why the default search path settings will be used: - the -P setting makes the Prelude module invisible; the interpreter issues a warning when this happens. - an empty -P setting is used to reset the path upon startup. - the environment variable IGNORE_USER_REGISTRY is set. What WinHugs version are you using? --sigbjorn ----- Original Message ----- From: "Greg Ballinger" <gregb(a)netrox.net> To: <hugs-users(a)haskell.org> Sent: Friday, April 23, 2004 23:15 Subject: [Hugs-users] Setting Search Path doesn't persist in WinHugs > I've made many attempts to add a directory to the search path using :set -P > using different strings such as > -P: {Home}/Haskell and > -P;"C:\Documents and Settings\Greg\My Documents\Haskell" > > All have worked during the current WInHugs session (Yes, I created the Home > environment variable). When I look in the HKEY-CURRENT-USER registry, the > information is saved in the option string: > -s -t -g -G -l -. +q -Q -w -k -o -O +u -I -T -A +R -H +98 -h250000 -p"%s> " > -r"$$" > -P".:{Hugs}/libraries:{Hugs}/oldlib:{Hugs}/libraries/win32:{Home}/Haskell" > -S".hs;.lhs" -E"C:\\Program Files\\UltraEdit\\UEDIT32.EXE" -c40 > > However, when I quit and restart WinHugs it only loads the default search path > : -P.:{Hugs}/libraries:{Hugs}/oldlib:{Hugs}/libraries/win32 > > At this point I need to update the search path every time I start WinHugs. > Does anyone have a helpful suggestion? I noticed some discussion back in > 2001 about how easy/dangerous it was to change the registry but apparently > nothing related to my particular issue. By the way my editor setting > persists with no problem. > > On a possibly related note, the documentation states that the installer > sets options in the HKEY-LOCAL-MACHINE but when I checked those registry > entries all I found were placeholders with no values set. > > Thank you for your assistance! > > --Greg Ballinger >

1 0