From kort@wins.uva.nl Thu Feb 1 13:29:34 2001
Date: Thu, 01 Feb 2001 14:29:34 +0100
From: Jan Kort kort@wins.uva.nl
Subject: AW: What does "Compiled code too complex" error message of Hugs
mean?
Laaser Christian wrote:
>
> I never built Hugs on Windows before :-( ...
> and a trial to do so with cygwin/gcc was unsuccessful.
> Have you got a precompiled binary for Win (hugs.exe) with these settings,
> which you could send me / I could download from somewhere?
>
> Christian
>
> > -----Urspr> üngliche Nachricht-----
> > Von: Jan Kort [SMTP:kort@wins.uva.nl]
> > Gesendet am: Mittwoch, 31. Januar 2001 13:34
> > An: Laaser Christian
> > Cc: 'haskell@haskell.org'
> > Betreff: Re: What does "Compiled code too complex" error message of Hugs mean?
> >
> > Laaser Christian wrote:
> > >
> > > When loading some Haskell files with Hugs, I get the error message "Compiled code too complex". However, the compilation with GHC 4.08.1 succeeds.
> > > What does this message mean? What can I do about it?
> > >
> >
> > You can grep for that sentence in "hugs98/src", it will point to the
> > file "machine.c". There you will see it says "if (nextLab>=NUM_FIXUPS) ...".
> > So grep for "NUM_FIXUPS" it will point to the file "prelude.h". I
> > think the default value is 400, you should increase it to 1000 or so.
> > I have it at 10000, but that's probably not necesary in your case
> > and if you increase constants too much starting up Hugs will become
> > slower.
> >
> > Jan
You need one of:
msc: Microsoft Visual C++
bcc32: 32 bit Borland C
win32: 32 bit Borland C, Hugs for Windows
djgpp2: DJGPP2
according to hugs98/Install, but I don't have any of them.
I use Windows for playing games mostly. Maybe NUM_FIXUPS
can be increased a little to say 1000 in the normal
distribution, I don't know how much this would slow
Hugs down ?
Jan
From rob@vulcanmachines.com Thu Feb 1 14:14:18 2001
Date: Thu, 1 Feb 2001 14:14:18 -0000
From: Rob MacAulay rob@vulcanmachines.com
Subject: (no subject)
Hugs January 2001 Beta release, WinHugs, Win2000 service pack 1
Haskell98 mode.
1. Does not appear to auto-load modules.
For example, trying to open Calendar.hs in the demo directory (using the
Open dialogue) produces the message:
ERROR C:\tools\programming\esoteric\hugs98\demos\Calendar.hs - Module
"System" n
ot previously loaded
2. Trying to load a file from the command line
:l demos\calendar
crashes the program.
Note that WinHugs was invoked by double clicking on the executable file in
explorer, rather
than via an icon. The Feb 2000 release works OK.
Regards,
Rob MacAulay
From nordland@cse.ogi.edu Fri Feb 2 19:00:12 2001
Date: Fri, 02 Feb 2001 11:00:12 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: ANNOUNCE: Hugs 98 January 2001 beta
==================================================================
__ __ __ __ ____ ___
|| || || || || || ||__
||___|| ||__|| ||__|| __||
||---|| ___||
|| ||
|| ||
Version: January 2001 beta
==================================================================
Dear all,
I'm pleased to announce the availability of a new beta release
of Hugs98. This is a beta release that aims at giving as many
people as possible a chance to react to the changes and additions
that have recently been incorporated, before the next major version
is released on February 14 2001. A list of the most important
new features looks as follows:
- A Foreign Function Interface closely modelled after the one
provided by GHC.
- Built-in, Hood-like debugging support.
- A new syntax for recursive monad bindings.
- A new GUI under Windows that doesn't consume all CPU time.
See the release notes in the "docs" directory of the distribution
for more information on some of these features.
Send email to hugs-users-request@haskell.org to join the hugs-users
mailing list. Bug reports should be sent to hugs-bugs@haskell.org.
Send email to hugs-bugs-request@haskell.org to subscribe to the
hugs-bugs list.
The home page and download site for Hugs is at
http://www.haskell.org/hugs/
Enjoy,
Johan Nordlander
PS
Please don't confuse this release with latest (January 31) release
of a new version of O'Hugs, the O'Haskell interpreter!
From Philippe.Faes@rug.ac.be Sat Feb 3 19:30:56 2001
Date: Sat, 03 Feb 2001 20:30:56 +0100
From: Philippe Faes Philippe.Faes@rug.ac.be
Subject: hugs bug?
This is a multi-part message in MIME format.
--------------0615D25923120B59FAC69992
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hugs (version februari 2000) keeps reporting unexpected ';' or
unexpected '}' in files that don't even contain those characters. I know
very little about Haskell (I just started to try and study the language)
so my haskell files will probably not be correct. Still with this kind
of messages I have no clue of what to change in my programs. I don't
know if this is a bug, or something I'm doing wrong.
I'm using a Linux2.2 operating system on an i386 processor.
I attached a haskell source file (which is probably not even good
haskell syntax), and the unexpected error message reported by hugs. The
latter file was created typing:
hugs tree.hs > hugserror.txt
Thank you,
Philippe Faes
mailto:Philippe.Faes@rug.ac.be
--------------0615D25923120B59FAC69992
Content-Type: text/plain; charset=us-ascii;
name="hugserror.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="hugserror.txt"
__ __ __ __ ____ ___ _________________________________________
|| || || || || || ||__ 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 _________________________________________
Haskell 98 mode: Restart with command line option -98 to enable extensions
Reading file "/usr/local/share/hugs/lib/Prelude.hs":
Parsing Dependency analysis Type checking Compiling Reading file "tree.hs":
Parsing
ERROR "tree.hs" (line 16): Syntax error in data type definition (unexpected `;', possibly due to bad layout)
Prelude> [Leaving Hugs]
--------------0615D25923120B59FAC69992
Content-Type: text/plain; charset=us-ascii;
name="tree.hs"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="tree.hs"
-- haskell
-- poging tot implementeren van trees en optimal search tree
-- *** tree.hs ***
-- cf cursus G&S p430
-- nieuwe types
type Weight = Float
type Cost = Float
type Failweight = Weight
type Token = Char
-- datastucturen
data Tree = Failnode Weight | Branch Token Tree Tree
data Lijst = [Lijstelem]
data Lijstelem = Le Weight Failweight
-- functies
q :: Int -> Lijst -> Weight
q 0 (Lelm _ fw):ls = fw
q i l:ls | i>0 = q i-1 ls
| i<0 = error "fout in q"
p :: Int -> Lijst -> Weight
c :: Int -> Int -> Lijst -> Weight
c i i _ = 0
c i j l = (w i j l) + zoekmin
w :: Int -> Int -> Lijst -> Weight
w 0 0 [] = error "fout in lijstbewerking in tree.hs"
w i i l = q i
w i j l = (w i j-1 l) + (q j) +(p j)
-- er wordt niet gecontroleerd of i>j; dat zou een fout moeten opleveren
zoekmin :: Int -> Int -> Lijst -> Weight
zoekmin i j l = (c i (zoekroot-1 l) l) + (c (zoekroot l) j l)
zookroot :: Int -> Int -> Lijst -> Int
--moet nog geimplementeerd worden
optboom :: Int -> Int -> Lijst -> Tree
optboom i i l = Failnode (q i)
optboom i j l = Branch (optboom i zoekroot) (zoekroot) (optboom (zoekroot+1) j)
-- deze syntax klopt niet
--------------0615D25923120B59FAC69992--
From nordland@cse.ogi.edu Sat Feb 3 19:55:13 2001
Date: Sat, 03 Feb 2001 11:55:13 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: hugs bug?
Philippe Faes wrote:
>
> Hugs (version februari 2000) keeps reporting unexpected ';' or
> unexpected '}' in files that don't even contain those characters. I know
> very little about Haskell (I just started to try and study the language)
> so my haskell files will probably not be correct. Still with this kind
> of messages I have no clue of what to change in my programs. I don't
> know if this is a bug, or something I'm doing wrong.
> I'm using a Linux2.2 operating system on an i386 processor.
>
> I attached a haskell source file (which is probably not even good
> haskell syntax), and the unexpected error message reported by hugs. The
> latter file was created typing:
> hugs tree.hs > hugserror.txt
>
> Thank you,
>
> Philippe Faes
>
> mailto:Philippe.Faes@rug.ac.be
>
Hi Philippe,
The ';' Hugs complains about is inserted automatically during lexical
analysis, as part of the layout handling process. It marks the end of
one definition, and the beginning of another. Often errors involving
these ghost ';'s indicate that the layout is wrong.
In your case, however, the source of the error is that you're using a
data declaration for defining a type synonym on line 16. Since
[Lijstelem] is not a correct right-hand side for a data declaration, the
lexer assumes that the declaration of Lijst has ended and inserts a ';'.
But since [Lijstelem] isn't a new declaration either, you get the error
you mentioned.
Write
type Lijst = [Lijstelem]
instead, and you'll be fine.
All the best,
Johan
> ------------------------------------------------------------------------
> __ __ __ __ ____ ___ _________________________________________
> || || || || || || ||__ 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 _________________________________________
>
> Haskell 98 mode: Restart with command line option -98 to enable extensions
>
> Reading file "/usr/local/share/hugs/lib/Prelude.hs":
> Parsing Dependency analysis Type checking Compiling Reading file "tree.hs":
> Parsing
> ERROR "tree.hs" (line 16): Syntax error in data type definition (unexpected `;', possibly due to bad layout)
> Prelude> [Leaving Hugs]
>
> ------------------------------------------------------------------------
> -- haskell
> -- poging tot implementeren van trees en optimal search tree
> -- *** tree.hs ***
> -- cf cursus G&S p430
>
> -- nieuwe types
> type Weight = Float
> type Cost = Float
> type Failweight = Weight
> type Token = Char
>
> -- datastucturen
> data Tree = Failnode Weight | Branch Token Tree Tree
>
> data Lijst = [Lijstelem]
> data Lijstelem = Le Weight Failweight
>
> -- functies
> q :: Int -> Lijst -> Weight
> q 0 (Lelm _ fw):ls = fw
> q i l:ls | i>0 = q i-1 ls
> | i<0 = error "fout in q"
>
> p :: Int -> Lijst -> Weight
>
> c :: Int -> Int -> Lijst -> Weight
> c i i _ = 0
> c i j l = (w i j l) + zoekmin
>
> w :: Int -> Int -> Lijst -> Weight
> w 0 0 [] = error "fout in lijstbewerking in tree.hs"
> w i i l = q i
> w i j l = (w i j-1 l) + (q j) +(p j)
> -- er wordt niet gecontroleerd of i>j; dat zou een fout moeten opleveren
>
> zoekmin :: Int -> Int -> Lijst -> Weight
> zoekmin i j l = (c i (zoekroot-1 l) l) + (c (zoekroot l) j l)
>
> zookroot :: Int -> Int -> Lijst -> Int
> --moet nog geimplementeerd worden
>
> optboom :: Int -> Int -> Lijst -> Tree
> optboom i i l = Failnode (q i)
> optboom i j l = Branch (optboom i zoekroot) (zoekroot) (optboom (zoekroot+1) j)
> -- deze syntax klopt niet
From Malcolm.Wallace@cs.york.ac.uk Sun Feb 4 13:33:13 2001
Date: Sun, 4 Feb 2001 13:33:13 +0000
From: Malcolm Wallace Malcolm.Wallace@cs.york.ac.uk
Subject: problem with 30Jan2001 release
The Linux RPM package for the latest beta release of Hugs, on 30th
Jan 2001, won't install on any of my RedHat 6.2 systems. The package
manager complains that the Hugs package has a major version number
greater than 3, and this is somehow not acceptable.
I hope this can be fixed before the 14th Feb full release.
Regards,
Malcolm
From mpringle@sfu.ca Sun Feb 4 22:27:42 2001
Date: Sun, 04 Feb 2001 14:27:42 PST
From: mpringle@sfu.ca mpringle@sfu.ca
Subject: Unrelated question
Does anybody know of a maillist for ML? Sorry to post the message to this
list. I'd rather be using Haskell myself.
cheers,
Micha
From pepeg@lcc.uma.es Mon Feb 5 08:43:52 2001
Date: Mon, 5 Feb 2001 09:43:52 +0100
From: Pepe Gallardo pepeg@lcc.uma.es
Subject: Winhugs bugs
----- Original Message -----
From: "Rob MacAulay" <rob@vulcanmachines.com>
To: <hugs-bugs@haskell.org>
Sent: Thursday, February 01, 2001 3:14 PM
Subject: (no subject)
> Hugs January 2001 Beta release, WinHugs, Win2000 service pack 1
> Haskell98 mode.
>
> 1. Does not appear to auto-load modules.
>
> For example, trying to open Calendar.hs in the demo directory (using the
> Open dialogue) produces the message:
>
> ERROR C:\tools\programming\esoteric\hugs98\demos\Calendar.hs - Module
> "System" n
> ot previously loaded
This is because the options dialog does not work well (will be fixed in the
14th Feb release) and has changed your options, setting off import chasing.
> 2. Trying to load a file from the command line
>
> :l demos\calendar
>
> crashes the program.
>
> Note that WinHugs was invoked by double clicking on the executable file
in
> explorer, rather
> than via an icon. The Feb 2000 release works OK.
Will be fixed too, thanks for the bug. For now, you should load files only
by using the open file dialog box.
Pepe Gallardo
From sigbjorn_finne@hotmail.com Mon Feb 5 14:56:07 2001
Date: Mon, 5 Feb 2001 15:56:07 +0100
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: A pair of editor related changes
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C08F8C.26CC98F0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hi,
great to see that Hugs98 isn't withering, but that new
releases keep coming out. Attached are some diffs that
might be of interest - they fix the following:
* when invoking the editor, cope with filenames containing
spaces (and other icky characters) by escaping them
in double-quotes.
* don't hardwire the location of notepad.exe as the
default editor (and make notepad.exe the default
editor on Win32 platforms, not just with Hugs for
Windows.)
The changes have only been tested on Win2k using MSVC;
the diffs are wrt the Jan 2001 sources.
--sigbjorn
------=_NextPart_000_0007_01C08F8C.26CC98F0
Content-Type: application/octet-stream;
name="editor-patches"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="editor-patches"
*** hugs.c.~1~ Wed Jan 31 07:39:30 2001
--- hugs.c Mon Feb 5 14:39:30 2001
***************
*** 24,27 ****
--- 24,31 ----
#include <stdio.h>
=20
+ #if HAVE_WINDOWS_H
+ #include <windows.h>
+ #endif
+=20
#if HUGS_FOR_WINDOWS
#include "winhugs\WinHugs.h"
***************
*** 258,263 ****
namesUpto =3D 1;
=20
! #if HUGS_FOR_WINDOWS
! hugsEdit =3D =
strCopy(fromEnv("EDITOR","c:\\windows\\notepad.exe"));
#elif SYMANTEC_C
hugsEdit =3D "";
--- 262,289 ----
namesUpto =3D 1;
=20
! #if HUGS_FOR_WINDOWS || HAVE_WINDOWS_H
! #define DEFAULT_EDITOR "\\notepad.exe"
! /*
! * Check first to see if the user has explicitly defined
! * an editor via the environment variable EDITOR..
! */
! hugsEdit =3D strCopy(fromEnv("EDITOR",NULL));
! if (hugsEdit =3D=3D NULL) {
! UINT rc;
! int notePadLen =3D strlen(DEFAULT_EDITOR);
! char* notePadLoc;
! /*
! * Nope, the default editor is used instead. In our case
! * this is 'notepad', which we assume is always residing
! * in the windows directory, so locate it first..
! */
! =20
! notePadLoc =3D _alloca(sizeof(char)*(MAX_PATH + notePadLen + =
1));
! rc =3D GetWindowsDirectory(notePadLoc, MAX_PATH);
! if ( !(rc =3D=3D 0 || rc > MAX_PATH) ) {
! strcat(notePadLoc, DEFAULT_EDITOR);
! hugsEdit =3D strCopy(notePadLoc);
! }
! }
#elif SYMANTEC_C
hugsEdit =3D "";
*** machdep.c.~1~ Wed Jan 31 22:10:38 2001
--- machdep.c Mon Feb 5 15:29:58 2001
***************
*** 1122,1127 ****
he++;
}
! else if (*he=3D=3D's' && (size_t)n>strlen(nm)) {
! strcpy(ec,nm);
rd =3D NULL;
he++;
--- 1122,1131 ----
he++;
}
! else if (*he=3D=3D's' && (size_t)n>(strlen(nm)+2)) {
! /* Protect the filename by putting quotes around it =
*/
! *ec++=3D'\"';
! strcpy(ec,nm); ec +=3D strlen(nm);
! *ec++=3D'\"';
! *ec=3D'\0';
rd =3D NULL;
he++;
***************
*** 1151,1157 ****
=20
if (nm && line=3D=3D0 && n>1) { /* Name, but no line ... =
*/
! *ec++ =3D ' ';
! for (; n>0 && *nm; n--) /* ... just copy file name */
! *ec++ =3D *nm++;
}
=20
--- 1155,1169 ----
=20
if (nm && line=3D=3D0 && n>1) { /* Name, but no line ... =
*/
! *ec++ =3D ' ';=20
! /* Protect the filename by putting quotes around it */
! if (n>0) {
! *ec++ =3D '\"'; n--;
! }
! for (; n>0 && *nm; n--) /* ... just copy file name */
! *ec++ =3D *nm++;
! if (n>0) {
! *ec++ =3D '\"';
! n--;
! }
}
=20
------=_NextPart_000_0007_01C08F8C.26CC98F0--
From jeff@galconn.com Mon Feb 5 16:27:14 2001
Date: Mon, 05 Feb 2001 08:27:14 -0800
From: Jeffrey R. Lewis jeff@galconn.com
Subject: problem with 30Jan2001 release
Malcolm Wallace wrote:
> The Linux RPM package for the latest beta release of Hugs, on 30th
> Jan 2001, won't install on any of my RedHat 6.2 systems. The package
> manager complains that the Hugs package has a major version number
> greater than 3, and this is somehow not acceptable.
>
> I hope this can be fixed before the 14th Feb full release.
The tradition seems to be to have an RPM for each major release, so following that, we should have at least an RPM built on 6.2, and an RPM built on 7.0. Does anyone know why the RPMs are OS version dependent, and/or if it is desireable to build them in an OS version independent way? One guess follows: It would appear that RPM assumes that the software you've built relies on the current versions of system libraries, and so probably gacks if you try to load it on a system w/ earlier libraries. But probably, there's a way to tell it that it's OK to link against older libs as well.
--Jeff
From dirk@TechFak.Uni-Bielefeld.DE Mon Feb 5 17:12:07 2001
Date: Mon, 05 Feb 2001 18:12:07 +0100 (MET)
From: Dirk Evers dirk@TechFak.Uni-Bielefeld.DE
Subject: hugs98-Jan2001beta minor bug during install
Hi,
a minor installation bug in Hugs98January 2001 beta.
The "man" and "man1" dirs are not created if needed by "make install".
/bin/cp ../docs/hugs.1 /vol/hugs/src/hugs98-Jan2001beta/man/man1
cp: cannot create /vol/hugs/src/hugs98-Jan2001beta/man/man1: No such file o=
r
directory
Cheers
Dirk
---
+---------------------------------------------------------------------+
| Dirk Evers Office: M3-120 |
| Technische Fakultaet / AG PI Tel: +49 521 106-2905 |
| Universitaet Bielefeld FAX: +49 521 106-6411 |
| D-33594 Bielefeld e-mail: dirk@TechFak.Uni-Bielefeld.DE |
| Germany URL: http://www.TechFak.Uni-Bielefeld.DE/~dirk/ |
|---------------------------------------------------------------------|
| Die Succulenten / a cappella singing / http://www.succulenten.de |
+---------------------------------------------------------------------+
From Malcolm.Wallace@cs.york.ac.uk Mon Feb 5 18:24:47 2001
Date: Mon, 5 Feb 2001 18:24:47 +0000
From: Malcolm Wallace Malcolm.Wallace@cs.york.ac.uk
Subject: problem with 30Jan2001 release
| > The package
| > manager complains that the Hugs package has a major version number
| > greater than 3, and this is somehow not acceptable.
> Does anyone know why the RPMs are OS version
> dependent, and/or if it is desireable to build them in an OS version
> independent way?
Hmmm, in a flash of inspiration, I realised that maybe the RPM package
format and tools have had a new release. (The "major version number"
in the error message must mean the RPM-version, not the Hugs version.)
In this case I would expect an old RPM (e.g. built on RedHat 6.2)
to unpack cleanly with either of the new or old RPM tools, but an RPM
using the new format to unpack only with the new tool.
So until RedHat 7 becomes more widespread, it should be sufficient to
supply a single old-format RPM?
Regards,
Malcolm
From pepeg@lcc.uma.es Tue Feb 6 12:05:46 2001
Date: Tue, 6 Feb 2001 13:05:46 +0100
From: Pepe Gallardo pepeg@lcc.uma.es
Subject: Some bug fixes for the January release
Here are some bug fixes to the January release of Hugs
****************************************************************************
****
*** BUG ***: HugsHood crashes if the user does not input a valid command
Change the definition of brkCmds in src\hugs.c to this one
****************************************************************************
****
static struct cmd brkCmds[] =
{ {"p", BRK_DISPLAY}
, {"c", BRK_CONTINUE}
, {"s", BRK_SET}
, {"r", BRK_RESET}
, {0,0}
};
****************************************************************************
****
*** BUG ***: The open file dialog in winhugs does not take into account the
current dir.
Change the GetaFileName function in src\winhugs\winhugs.c to this one
****************************************************************************
****
static CHAR* local GetaFileName(HWND hWnd, UINT Mask)
{
#define MAXEXTENSIONS 15
static CHAR Extensions[MAXEXTENSIONS][_MAX_EXT+1];
static OPENFILENAME ofn;
static CHAR szFileName[_MAX_PATH];
CHAR szFile[_MAX_PATH], szFileTitle[_MAX_PATH];
UINT i, j, cbString, n;
CHAR chReplace; /* Separator between different filters in szFilter
*/
CHAR szFilter[300];
char currentDir[_MAX_PATH];
szFile[0] = '\0';
if ((cbString = LoadString(hThisInstance, Mask,
szFilter, sizeof(szFilter))) == 0) {
/* Error */
return NULL;
}
chReplace = szFilter[cbString - 1]; /* Get separator */
/* Get valid extensions for files */
for (n=0, i=0;szFilter[i];) {
while (szFilter[i] != chReplace) i++;
i++;
do {
while (szFilter[i] != '.') i++;
i++;
j=0;
while ((szFilter[i] != ';')&&(szFilter[i] != chReplace)){
Extensions[n][j++] = szFilter[i++];
}
Extensions[n++][j] = (CHAR) 0;
} while (szFilter[i] == ';');
i++;
}
for (;n<MAXEXTENSIONS;n++)
Extensions[n][0] = (CHAR)0;
/* Replace separator with NULL */
for (i = 0; szFilter[i] != '\0'; i++) {
if (szFilter[i] == chReplace)
szFilter[i] = '\0';
}
memset(&ofn, 0, sizeof(OPENFILENAME));
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.hInstance = hThisInstance;
ofn.hwndOwner = hWnd;
ofn.lpstrFilter = szFilter;
ofn.nFilterIndex = 1;
ofn.lpstrFile= szFile;
ofn.nMaxFile = sizeof(szFile);
ofn.lpstrFileTitle = szFileTitle;
ofn.nMaxFileTitle = sizeof(szFileTitle);
ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST | OFN_HIDEREADONLY |
OFN_ENABLEHOOK | OFN_EXPLORER;;
ofn.lpfnHook = (LPOFNHOOKPROC)MakeProcInstance((FARPROC) FileOpenHookProc,
hThisInstance);
GetCurrentDirectory(_MAX_PATH,currentDir);
ofn.lpstrInitialDir = currentDir;
if (GetOpenFileName(&ofn)) {
strcpy(szFileName, ofn.lpstrFile);
return szFileName;
}
else {
return NULL;
}
}
****************************************************************************
****
*** BUG ***: The script manager does not work well when a file is removed
Change the ScriptManDlgProc function in src\winhugs\winhugs.c to this one
****************************************************************************
****
LRESULT CALLBACK ScriptManDlgProc(HWND hDlg, UINT msg,
WPARAM wParam, LPARAM lParam) {
switch (msg) {
case WM_INITDIALOG: {
Int i;
smLoaded = numScripts;
smUpto = 0;
CenterDialogInParent(hDlg);
SetDialogFont (hDlg, hDialogFont);
SendDlgItemMessage(hDlg, LB_SCRIPTS, LB_SETHORIZONTALEXTENT,
(WPARAM)1000, 0L);
SendDlgItemMessage(hDlg, LB_SCRIPTS, WM_SETREDRAW,FALSE,0L);
for (i=0; i<namesUpto; i++)
SmAddScr(hDlg,scriptReal[i]);
SmSelScr(hDlg,0);
SendDlgItemMessage(hDlg,LB_SCRIPTS,LB_SETCURSEL, 0, 0L);
SendDlgItemMessage(hDlg,LB_SCRIPTS,WM_SETREDRAW,TRUE,0L);
return TRUE;
}
case WM_PAINT: {
HDC hDC;
PAINTSTRUCT Ps;
HBITMAP hBitmap;
RECT aRect, DlgRect;
BeginPaint(hDlg, &Ps);
hDC = Ps.hdc;
/* Paint classes Bitmap */
GetWindowRect(hDlg, &DlgRect);
GetWindowRect(GetDlgItem(hDlg, ID_PLACEBITMAP), &aRect);
hBitmap = LoadMappedBitmap(hThisInstance, "SCRIPTMANDLGBMP");
DrawBitmap(hDC, hBitmap,
aRect.left-DlgRect.left-GetSystemMetrics(SM_CXDLGFRAME),
aRect.top-DlgRect.top-GetSystemMetrics(SM_CYDLGFRAME)-GetSystemMetrics(SM_CY
CAPTION));
DeleteObject(hBitmap);
EndPaint(hDlg, &Ps);
}
break;
case WM_COMMAND:
switch (CMDitem(wParam,lParam)) {
case ID_ADDSCRIPT:
if (smUpto>=NUM_SCRIPTS)
MessageBox(hDlg,"Too many script files",
"Add script", MB_ICONEXCLAMATION|MB_OK);
else {
String s = GetaFileName(hDlg,IDS_FILTERFILE);
if (s)
SmAddScr(hDlg,s);
}
return TRUE;
case ID_DELSCRIPT:
if (selScr < 0)
MessageBox(hDlg,"No script file selected",
"Remove script", MB_ICONEXCLAMATION|MB_OK);
else if (selScr == 0)
MessageBox(hDlg,"Cannot remove prelude file",
"Remove script", MB_ICONEXCLAMATION|MB_OK);
else {
Int i;
SendDlgItemMessage(hDlg, LB_SCRIPTS, LB_DELETESTRING,
selScr, 0L);
if (selScr<smLoaded)
smLoaded = selScr;
if (smFile[selScr]) {
free(smFile[selScr]);
smFile[selScr] = 0;
}
for (i=selScr+1; i<smUpto; ++i)
smFile[i-1] = smFile[i];
smUpto--;
SmSelScr(hDlg,-1);
}
return TRUE;
case ID_EDITSCRIPT:
if (selScr >= 0)
DlgSendMessage(hDlg, WM_COMMAND, LB_SCRIPTS, MAKELONG(0,
LBN_DBLCLK));
else
MessageBox(hDlg,"No file selected","Edit",
MB_ICONEXCLAMATION|MB_OK);
return TRUE;
case ID_CLEARSCRIPTS: {
Int i;
for (i=1; i<smUpto; ++i)
if (smFile[i])
free(smFile[i]);
smUpto = smLoaded = 1;
SendDlgItemMessage(hDlg,LB_SCRIPTS,LB_RESETCONTENT,0,0L);
fprintf(stdstr,"%s\n",smFile[0]);
SendDlgItemMessage(hDlg, LB_SCRIPTS, LB_ADDSTRING, 0,
(LONG) (LPSTR) stdstrbuff);
SmSelScr(hDlg,-1);
return TRUE;
}
case LB_SCRIPTS:
switch (CMDdata(wParam,lParam)) {
case LBN_SELCHANGE:
SmSelScr(hDlg,(Int)SendDlgItemMessage(hDlg,
LB_SCRIPTS,
LB_GETCURSEL,
0, 0L));
return TRUE;
case LBN_DBLCLK: {
char buffer[_MAX_PATH];
SendDlgItemMessage(hDlg,
LB_SCRIPTS,
LB_GETTEXT,
selScr,
(LPARAM) (LPSTR) buffer);
setLastEdit((String)buffer,0);
runEditor();
return TRUE;
}
}
break;
case IDOK: {
Int i;
for (i=0; i<namesUpto; i++)
if (scriptName[i]) {
free(scriptName[i]);
free(scriptReal[i]);
}
for (i=0; i<smUpto; i++) {
scriptName[i] = smFile[i];
scriptReal[i] = strCopy(RealPath(scriptName[i]));
smFile[i] = 0;
}
namesUpto = smUpto;
numScripts = smLoaded;
dropScriptsFrom(numScripts-1);
PostMessage(hWndMain,WM_COMMAND,ID_COMPILE,0L);
EndDialog(hDlg,TRUE);
return TRUE;
}
case IDCANCEL: {
Int i;
for (i=0; i<smUpto; i++)
if (smFile[i])
free(smFile[i]);
EndDialog(hDlg, TRUE);
return TRUE;
}
}
break;
}
return FALSE;
}
****************************************************************************
****
*** BUG ***: Winhugs crashes when the user loads an script without providing
the full path
Change the function addScript in src\hugs.c to this one
****************************************************************************
****
static Bool local addScript(fname,len) /* read single script file
*/
String fname; /* name of script file
*/
Long len; { /* length of script file
*/
scriptFile = fname;
#if HUGS_FOR_WINDOWS /* Set clock cursor while loading */
allowBreak();
SetCursor(LoadCursor(NULL, IDC_WAIT));
AddFileToFileNamesMenu(&FilesMenu, RealPath(fname));
#endif
Printf("Reading file \"%s\":\n",fname);
setLastEdit(fname,0);
needsImports = FALSE;
parseScript(fname,len); /* process script file
*/
if (needsImports)
return FALSE;
checkDefns();
typeCheckDefns();
compileDefns();
scriptFile = 0;
preludeLoaded = TRUE;
return TRUE;
}
****************************************************************************
****
*** BUG ***: Winhugs crashes when the user loads an script without providing
the full path
Change the function setLastEdit in src\hugs.c to this one
****************************************************************************
****
static Void local setLastEdit(fname,line)/* keep name of last file to edit
*/
String fname;
Int line; {
if (lastEdit)
free(lastEdit);
lastEdit = strCopy(fname);
lastLine = line;
#if HUGS_FOR_WINDOWS
/* Add file to Edit menu */
if (lastEdit)
AddFileToFileNamesMenu(&EditMenu, RealPath(lastEdit));
#endif
}
****************************************************************************
****
*** BUG ***: Winhugs options dialog does not work well
Change the OPTIONSDLGBOX resource in src\winhugs\winhugs.rc to this one
****************************************************************************
****
OPTIONSDLGBOX DIALOG FIXED IMPURE 14, 24, 313, 241
STYLE DS_MODALFRAME | DS_3DLOOK | DS_FIXEDSYS | WS_POPUP | WS_CAPTION |
WS_SYSMENU
CAPTION "Options"
FONT 8, "Ms Sans Serif"
BEGIN
GROUPBOX " Fl&ags: ",-1,5,5,302,110
CONTROL "&s Print no. reductions/cells after
eval",ID_OP,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,12,19,142,10
CONTROL "&t Print type after evaluation",ID_OP+1,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,12,29,142,10
CONTROL "&f Terminate evaluation on first
error",ID_OP+2,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,12,39,142,10
CONTROL "&g Print no. cells recovered after
gc",ID_OP+3,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,12,49,142,10
CONTROL "&G Generate FFI code for foreign
import",ID_OP+4,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,12,59,142,10
CONTROL "&l Literate scripts as default",ID_OP+5,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,12,69,142,10
CONTROL "&e Warn about errors in literate
scripts",ID_OP+6,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,12,79,142,10
CONTROL "&. Print dots to show progress",ID_OP+7,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,12,89,135,10
CONTROL "&q Print nothing to show progress",ID_OP+8,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,12,99,135,10
CONTROL "&Q Qualify names when printing",ID_OP+9,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,160,19,147,10
CONTROL "&w Always show which files loaded",ID_OP+10,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,160,29,147,10
CONTROL "&k Show kind errors in full",ID_OP+11,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,160,39,147,10
CONTROL "&o Allow overlapping instances",ID_OP+12,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,160,49,147,10
CONTROL "&u Use ""show"" to display results",ID_OP+13,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,160,59,147,10
CONTROL "&i Chase imports while loading
files",ID_OP+14,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,160,69,147,10
CONTROL "&A Auto load files",ID_OP+15,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,160,79,147,10
CONTROL "&m Use multi instance resolution ",ID_OP+16,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,160,89,147,10
LTEXT "Path:",-1,12,129,22,8
EDITTEXT ID_PATH,37,127,183,12,ES_AUTOHSCROLL
LTEXT "Preprocessor filter:",-1,12,143,62,8
EDITTEXT ID_PREPROCESSOR,76,141,144,12,ES_AUTOHSCROLL
LTEXT "Editor:",-1,12,157,25,8
EDITTEXT ID_EDITOR,39,155,181,12,ES_AUTOHSCROLL
LTEXT "Prompt string:",-1,12,171,47,8
EDITTEXT ID_PROMPT,62,169,158,12
LTEXT "Repeat last expression string:",-1,12,185,96,8
EDITTEXT ID_LASTEXPR,111,183,109,12
LTEXT "Set constraint cutoff limit:",-1,12,200,89,8
EDITTEXT ID_CUTOFF,97,197,123,12
LTEXT "Heap size:",-1,12,215,47,8
EDITTEXT ID_HEAPSIZE,52,212,168,12
PUSHBUTTON "Ok",IDOK,256,129,40,14
PUSHBUTTON "Cancel",IDCANCEL,256,150,40,14
GROUPBOX "",-1,5,118,227,112
LTEXT "",ID_PLACEBITMAP,246,188,73,1
END
****************************************************************************
****
*** BUG ***: Winhugs could use a different color while printing observations
Change the printObserve function in src\output.c to this one
****************************************************************************
****
Void printObserve(t)
String t; {
Observe i;
String s;
if (! (i=firstObserve())) return;
printingObservations = TRUE;
outputStream = stdout;
#if HUGS_FOR_WINDOWS
{ INT svColor = SetForeColor(MAGENTA);
#endif
putStr("\n>>>>>>> Observations <<<<<<");
newLine(0);
while(i != NIL){
newLine(0);
s = textToStr(observe(i).tag);
if (*t==0 || strcmp(s,t)==0){
putStr(s);
newLine(2);
if (printObsList(observe(i).head,2,FALSE))
newLine(0);
}
i = nextObserve();
}
newLine(0);
printingObservations = FALSE;
#if HUGS_FOR_WINDOWS
SetForeColor(svColor); }
#endif
}
(¯`·.¸¸.-> pepeg <-.¸¸.·´¯)
From Sven.Panne@informatik.uni-muenchen.de Tue Feb 6 21:21:44 2001
Date: Tue, 06 Feb 2001 22:21:44 +0100
From: Sven Panne Sven.Panne@informatik.uni-muenchen.de
Subject: Some bug fixes for the January release
I don't have a long list of bug fixes at hand, I only want to reiterate
my concerns about the incomplete H98 library support in Hugs, see:
http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/diffs.html#sect9.2
I consider this a rather fundamental omission and a constant source of
porting troubles, so I hoped that these things would be in the next Hugs
release. But given the release date in just a week (IIRC), there's little
hope for this. :-( It's a little bit like having a Java system
without a complete java.lang.* package...
And another thing: On Unix platforms, two files are *always* compiled
without optimizations due to some problems with some compilers, IIRC.
Shouldn't this be autoconf-ed?
Cheers,
Sven
From patrikj@cs.chalmers.se Wed Feb 7 09:17:21 2001
Date: Wed, 7 Feb 2001 10:17:21 +0100 (MET)
From: Patrik Jansson patrikj@cs.chalmers.se
Subject: January beta Observe infinite dictionary bug
-- Bug report for Hugs Version Jan 2001 beta
-- (on SunOS 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-5_10)
import Observe
g p = (>p)
main = observe "hej" g 4 3
{-
Gives an ugly infinite report starting with
hej
{ \ 4 -> flip (default_comparexn (Make.Ord primCmpInteger
(default_compare (Make.Ord primCmpInteger (default_compare (Make.Ord
primCmpInteger
It also pollutes some state somewhere (when I break it with Ctrl-C)
because a following
observe "haj" "Patrik"
produces the same infinite garbage relating to the "hej" observation.
This is a minimalistic example, I ran into it in much bigger programs
(read PolyP) wither other kinds of overloading.
I would guess it has to do with presenting dictionary values.
/Patrik Jansson
PS. I quite like observe when it works.
-}
From sigbjorn_finne@hotmail.com Wed Feb 7 11:51:09 2001
Date: Wed, 7 Feb 2001 12:51:09 +0100
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: ffi patch
This is a multi-part message in MIME format.
------=_NextPart_000_0018_01C09104.A4B4E870
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
The FFI C code generator (enabled via :set +G) emits code
that's not ANSI C compliant (causes problems with MSVC
and 'gcc -pedantic') - attached is a patch that fixes this.
--sigbjorn
------=_NextPart_000_0018_01C09104.A4B4E870
Content-Type: application/octet-stream;
name="ffi-patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="ffi-patch"
*** ffi.c.~1~ Wed Dec 13 10:01:54 2000
--- ffi.c Wed Feb 7 12:46:10 2001
***************
*** 81,88 ****
"static void primControl Args((int));\n"
"static void primControl(what)\n"
! "int what; {\n"
! " switch (what) {\n"
! " case %d:\n", RESET
! );
for(xs=es; nonNull(xs); xs=tl(xs)) {
Name n = hd(xs);
--- 81,93 ----
"static void primControl Args((int));\n"
"static void primControl(what)\n"
! "int what; {\n");
!
! if (nonNull(es)) {
! fprintf(out,
! " switch (what) {\n"
! " case %d:\n", RESET
! );
! }
!
for(xs=es; nonNull(xs); xs=tl(xs)) {
Name n = hd(xs);
***************
*** 97,104 ****
}
}
! fprintf(out,
! " }\n"
! "}\n"
! );
/* Boilerplate initialization function */
--- 102,109 ----
}
}
! if (nonNull(es)) {
! fprintf(out," }\n");
! }
! fprintf(out, "}\n");
/* Boilerplate initialization function */
------=_NextPart_000_0018_01C09104.A4B4E870--
From bf100@doc.ic.ac.uk Wed Feb 7 20:41:54 2001
Date: Wed, 7 Feb 2001 20:41:54 +0000 (GMT)
From: Badrulhisyam Fauzi bf100@doc.ic.ac.uk
Subject: Editor Configuration.
hi there,
this is not a bug really. i just wanna ask how to configure editor for
hugs version jan 2001 beta. i'm running it using ms dos prompt under
windows me.
when i type:
:edit intro.hs
the result is:
ERROR - Hugs is not configured to use an editor
so, how do i configure 'edit' as my editor?
I'll really appreciate any help.
Thanks.
Badrulhisyam Fauzi,
Imperial College, London.
From sigbjorn_finne@hotmail.com Wed Feb 7 21:35:59 2001
Date: Wed, 7 Feb 2001 22:35:59 +0100
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: Editor Configuration.
Badrulhisyam Fauzi <bf100@doc.ic.ac.uk> writes:
>
> hi there,
> this is not a bug really. i just wanna ask how to configure editor for
> hugs version jan 2001 beta. i'm running it using ms dos prompt under
> windows me.
>
> when i type:
>
> :edit intro.hs
>
> the result is:
>
> ERROR - Hugs is not configured to use an editor
>
> so, how do i configure 'edit' as my editor?
Hi,
from within Hugs, you can set the editor you want to use via the
:set -E option, e.g., if you want to use 'notepad', do
Prelude> :s -Enotepad
Prelude> :edit intro.hs
For more info on the -E option and others, see
http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/started.html
hth,
--sigbjorn
I'll really appreciate any help.
Thanks.
Badrulhisyam Fauzi,
Imperial College, London.
From igloo@earth.li Fri Feb 9 22:14:07 2001
Date: Fri, 9 Feb 2001 22:14:07 +0000
From: Ian Lynagh igloo@earth.li
Subject: Word64 patch
--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi all
The Word64 type distributed with hugs (including the latest beta
(Jan 2001) against which this patch was created) appears to be
somewhat lacking in features that might make it useful. The attached
patch makes it an instance of Num, Bits, Integral, Real and Enum.
I haven't looked at the hugs internals where this would probably be
better done, but this is probably the easier fix in the meantime.
There are a few places it goes via Integer - if I get a minute I'll
try to think if any of them can be easily removed.
Warning: This is pretty much untested, but it parsed OK...
Thanks
Ian
--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="Word64.patch"
--- Word.orig.hs Fri Feb 9 21:53:28 2001
+++ Word.hs Fri Feb 9 22:04:47 2001
@@ -292,6 +292,81 @@
instance Read Word64 where
readsPrec p s = [ (integerToW64 x,r) | (x,r) <- readDec s ]
+binop64 :: (Word32 -> Word32 -> Word32) -> Word64 -> Word64 -> Word64
+binop64 f W64{lo = lo_a, hi = hi_a} W64{lo = lo_b, hi = hi_b}
+ = W64{lo = f lo_a lo_b, hi = f hi_a hi_b}
+
+monop64 :: (Word32 -> Word32) -> Word64 -> Word64
+monop64 f W64{lo = lo, hi = hi} = W64{lo = f lo, hi = f hi}
+
+binopi64 :: (Integer -> Integer -> Integer) -> Word64 -> Word64 -> Word64
+binopi64 f a b = fromInteger $ (toInteger a `f` toInteger b) `mod` (2^64)
+
+binoppi64 :: (Integer -> Integer -> (Integer, Integer))
+ -> Word64 -> Word64 -> (Word64, Word64)
+binoppi64 f a b = (fromInteger a', fromInteger b')
+ where (a', b') = toInteger a `f` toInteger b
+
+instance Num Word64 where
+ W64{lo=lo_a,hi=hi_a} + W64{lo=lo_b,hi=hi_b} = W64{lo=lo', hi=hi'}
+ where lo' = lo_a + lo_b
+ hi' = hi_a + hi_b + if lo' < lo_a then 1 else 0
+ W64{lo=lo_a,hi=hi_a} - W64{lo=lo_b,hi=hi_b} = W64{lo=lo', hi=hi'}
+ where lo' = lo_a - lo_b
+ hi' = hi_a - hi_b + if lo' > lo_a then 1 else 0
+ negate x = complement x - 1
+ (*) = binopi64 (*)
+ abs = id
+ signum x = if x == 0 then 0 else 1
+ fromInteger = integerToW64
+ fromInt = integerToW64 . toInteger
+
+instance Bits Word64 where
+ (.&.) = binop64 (.&.)
+ (.|.) = binop64 (.|.)
+ xor = binop64 xor
+ shift w 0 = w
+ shift W64{lo=lo,hi=hi} x
+ | x > 63 = W64{lo = 0, hi = 0 }
+ | x > 31 = W64{lo = 0, hi = shift lo (x-32)}
+ | x > 0 = W64{lo = shift lo x, hi = shift hi x .|. shift lo (x-32)}
+ | x < -63 = W64{lo = 0, hi = 0 }
+ | x < -31 = W64{lo = shift hi (x+32), hi = 0 }
+ | x < 0 = W64{lo = shift lo x .|. shift hi (x+32), hi = shift hi x}
+ rotate x i = shift x i' .|. shift x (i' - 64)
+ where i' = i `mod` 64
+ complement = monop64 complement
+ bit = rotate 1
+ setBit x i = x .|. bit i
+ clearBit x i = x .&. complement (bit i)
+ complementBit x i = x `xor` bit i
+ testBit x i = x .&. bit i > 0
+ bitSize _ = 64
+ isSigned _ = False
+
+instance Integral Word64 where
+ div = binopi64 div
+ quot = binopi64 quot
+ rem = binopi64 rem
+ mod = binopi64 mod
+ quotRem = binoppi64 quotRem
+ divMod = binoppi64 divMod
+ toInteger = w64ToInteger
+ toInt = fromInteger . w64ToInteger
+ even W64{lo = lo, hi = _} = even lo
+
+instance Real Word64 where
+ toRational x = toInteger x % 1
+
+instance Enum Word64 where
+ toEnum = fromInt
+ fromEnum = toInt
+ enumFrom = numericEnumFrom
+ enumFromTo = numericEnumFromTo
+ enumFromThen = numericEnumFromThen
+ enumFromThenTo = numericEnumFromThenTo
+
+
-----------------------------------------------------------------------------
-- End of exported definitions
--
--jI8keyz6grp/JLjh--
From gustav@morpheus.demon.co.uk Fri Feb 9 22:21:45 2001
Date: Fri, 9 Feb 2001 22:21:45 -0000
From: Paul Moore gustav@morpheus.demon.co.uk
Subject: Problem with the new beta
I have just downloaded the new Hugs beta. There is a problem with
the supplied ST module - :load ST gives an error,
...
Reading file "C:\Data\HugsBeta\Hugs98\lib\exts\ST.hs":
Parsing
ERROR C:\Data\HugsBeta\Hugs98\lib\exts\ST.hs:48 - Syntax error
in type expression (unexpected `.')
Paul Moore
From mpj@cse.ogi.edu Sat Feb 10 06:17:49 2001
Date: Fri, 9 Feb 2001 22:17:49 -0800
From: Mark P Jones mpj@cse.ogi.edu
Subject: The ST library requires -98 option (was RE: Problem with the new beta)
Hi Paul,
| I have just downloaded the new Hugs beta. There is a problem with=20
| the supplied ST module - :load ST gives an error,
|=20
| ...
| Reading file "C:\Data\HugsBeta\Hugs98\lib\exts\ST.hs":
| Parsing
| ERROR C:\Data\HugsBeta\Hugs98\lib\exts\ST.hs:48 - Syntax error=20
| in type expression (unexpected `.')
I suspect you are running Hugs in Haskell 98 mode. As it says in
the Hugs manual:
"Note that the ST and LazyST libraries cannot be used when
the interpreter is running in Haskell 98 mode; the type for
runST requires support for rank-2 polymorphism, which is only
available in Hugs mode."
Try starting the interpreter with the command line option -98 if you
want to use the ST library. I know that the error message above isn't
as clear as you might hope, but it is also difficult to do better in
Haskell 98 mode where "forall" is a perfectly legal type variable name,
and not a keyword.
All the best,
Mark
From pepeg@lcc.uma.es Mon Feb 12 13:14:46 2001
Date: Mon, 12 Feb 2001 14:14:46 +0100
From: Pepe Gallardo pepeg@lcc.uma.es
Subject: Corrupted files in winhugs\resource
Some of the files in src\winhugs\resources, in particular,
classesd.bmp
exitbutt.bmp
relobutt.bmp
on the cvs repository are corrupted ! . They were fine in the beta release.
(¯`·.¸¸.-> pepeg <-.¸¸.·´¯)
From jeff@galconn.com Mon Feb 12 16:15:02 2001
Date: Mon, 12 Feb 2001 08:15:02 -0800
From: Jeffrey R. Lewis jeff@galconn.com
Subject: Corrupted files in winhugs\resource
Pepe Gallardo wrote:
> Some of the files in src\winhugs\resources, in particular,
>
> classesd.bmp
> exitbutt.bmp
> relobutt.bmp
>
> on the cvs repository are corrupted ! . They were fine in the beta release.
Those files would appear to not be checked in using the `binary' flag (-kb) - perhaps this is the problem.
--Jeff
From nordland@cse.ogi.edu Mon Feb 12 18:58:16 2001
Date: Mon, 12 Feb 2001 10:58:16 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: Corrupted files in winhugs\resource
Jeffrey R. Lewis" wrote:
>
> Pepe Gallardo wrote:
>
> > Some of the files in src\winhugs\resources, in particular,
> >
> > classesd.bmp
> > exitbutt.bmp
> > relobutt.bmp
> >
> > on the cvs repository are corrupted ! . They were fine in the beta release.
>
> Those files would appear to not be checked in using the `binary' flag (-kb) -
> perhaps this is the problem.
>
> --Jeff
Fortunately the data in these files are still correct. As Jeff suspected the
-kb flags were just missing; this has now been fixed. A cvs update should solve
the problem.
-- Johan
From mpj@cse.ogi.edu Mon Feb 12 19:07:03 2001
Date: Mon, 12 Feb 2001 11:07:03 -0800
From: Mark P Jones mpj@cse.ogi.edu
Subject: AW: What does "Compiled code too complex" error message of Hugs mean?
I know this is more than a week old, but I've been away ... and
now that I'm back, I'd like to clear up a possible misunderstanding
that began with an exchange along the following lines:
| > > When loading some Haskell files with Hugs, I get the error=20
| > > message "Compiled code too complex". However, the compilation=20
| > > with GHC 4.08.1 succeeds. =20
| > > What does this message mean? What can I do about it?
| ...
| > You can grep for that sentence in "hugs98/src", it will point to the
| > file "machine.c". There you will see it says "if =
nextLab>=3DNUM_FIXUPS) ...".
| > So grep for "NUM_FIXUPS" it will point to the file "prelude.h". I
| > think the default value is 400, you should increase it to 1000 or =
so.
| > I have it at 10000, but that's probably not necesary in your case
| > and if you increase constants too much starting up Hugs will become
| > slower.
First of all, an explanation. Inside Hugs, the code for Haskell
functions is translated into a low-level, abstract machine language.
(In today's environment, the way that Java programs are translated
into JVM bytecode is probably a good analogy.) As the machine
language code is generated, the compiler sometimes needs to insert
"jump" instructions to addresses that are not yet known. In this
situation, it instead inserts a dummy address, but adds an entry to
a simple table of "fixups" that will later be filled in with the
correct address. Once the complete section of code has been generated,
Hugs scans over it once again and replaces each unknown address with
the correct value from the fixups table. This process is also quite
commonly described as "back-patching".
The fixups table can contain at most NUM_FIXUPS entries, which, in the
current distribution, is set to 400. Programs that require more entries
than this in a single block of code will lead to the "Compiled code too
complex" error message that you have seen. There is not particular
reason for the choice of 400; this is just a number that seemed to work
ok for most practical purposes. If you get a compiled code too complex
message, it is perhaps a sign that you would benefit from looking at
ways to break your code down into smaller, simpler, and more=20
understandable pieces. More likely, however, you will see this error
with code that was generated automatically, in response to a "deriving"
request on a datatype, or by a tool like a parser generator. In this
case, changing the Haskell code that is generated is not an option.
Increasing the standard setting for NUM_FIXUPS is certainly an option
here. You would have to increase it a great deal for there to be any
impact on the speed with which Hugs starts. In comparison to the
standard heap sizes that people use, the fixups table is a drop in the
ocean. I think Johan has already increased the size for the Feb 2001
distribution that will be out in a couple of days.
The fixups table could be allocated dynamically, and expand on demand.
To understand why Hugs doesn't do it that way already, you need to go
back more than a decade to Gofer, the system from which Hugs was
derived, which was designed to work on an 8086 with segmented memory
and a maximum of 640K. Back in those days, when loading the prelude
took 30 seconds (and it was much smaller then too!), a statically
allocated table made sense because it was slightly faster and because
there wasn't any spare memory for it to expand into anyway, even if
you went to the trouble of dynamically allocating it.
Historical note: If you'd like to see the heart of the machine that
ran those original versions of Gofer, come visit me; it's sitting
here on the desk lamp in my office :-)
All the best,
Mark
From nordland@cse.ogi.edu Thu Feb 15 05:22:47 2001
Date: Wed, 14 Feb 2001 21:22:47 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: ANNOUNCE: Hugs98 Feb 2001
======================================================================
__ __ __ __ ____ ___
|| || || || || || ||__
||___|| ||__|| ||__|| __||
||---|| ___||
|| ||
|| || Version: Feb 2001
======================================================================
Dear all,
I'm pleased to announce the availability of a new release of Hugs98.
This is a major release that incorporates bug fixes as well as several
new features and enhancements that have been developed for Hugs over
the last year. It is announced with the intentions that it will remain
a stable and lightweight implementation of Haskell 98 + extensions
for some considerable time.
A list of the most important new features looks as follows:
- A Foreign Function Interface closely modelled after the one
provided by GHC.
- Built-in, Hood-like debugging support.
- Parallel list comprehensions, a.k.a. zip-comprehensions.
- A new syntax for recursive monad bindings.
- A new GUI under Windows that doesn't consume all CPU time.
- Support for the MacOS platform integrated into the main
distriution.
- Corrections of all bugs reported for the January 2001 beta
release.
See the release notes in the "docs" directory of the distribution
for more information on the new language features.
Send email to hugs-users-request@haskell.org to join the hugs-users
mailing list. Bug reports should be sent to hugs-bugs@haskell.org.
Send email to hugs-bugs-request@haskell.org to subscribe to the
hugs-bugs list.
The home page and download site for Hugs is at
http://www.haskell.org/hugs/
Enjoy,
Johan Nordlander
[Hugs maintainer]
From thiemann@informatik.uni-freiburg.de Wed Feb 14 20:42:12 2001
Date: 14 Feb 2001 21:42:12 +0100
From: Peter Thiemann thiemann@informatik.uni-freiburg.de
Subject: re-exporting imported modules
I have the following problem:
I would like to define a non-standard prelude that redefines only a
few names of the standard prelude. The Haskell report suggests that
the following combination should do the job (BUG2A defines the
non-standard prelude and BUG2B tries to use it):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
module BUG2A (module BUG2A, module Prelude) where
import Prelude hiding (head)
head = "HEAD"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
module BUG2B where
import qualified Prelude
import BUG2A
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unfortunately, loading BUG2B into the Jan2001 beta release gives the
following error message:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ERROR BUG2B.hs - Entity "head" imported from module "BUG2A" already defined in module "Prelude"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>From my understanding of the report, the following BUG2C user module
should also do the job, but it gives the same error message:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
module BUG2C where
import Prelude ()
import BUG2A
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Is this a known problem?
Cheers
-Peter
From koen@cs.chalmers.se Thu Feb 15 09:20:07 2001
Date: Thu, 15 Feb 2001 10:20:07 +0100 (MET)
From: Koen Claessen koen@cs.chalmers.se
Subject: Purity of the stack execution model? (fwd)
Hi!
Somebody posted the following message on
comp.lang.functional. It reports an error when having a main
function which has type "IO [()]", together with using
runhugs.
This is a bug; the Haskell report says that main "must be a
computation of type IO t for some type t".
/Koen.
---------- Forwarded message ----------
Date: Wed, 14 Feb 2001 23:23:50 +0100
From: Tore Lund <tl001@online.no>
Newsgroups: comp.lang.functional
Subject: Re: Purity of the stack execution model?
Markus Mottl wrote:
>
> actions = [putStr "foo", putStr "bar"]
> nl = putStr "\n"
> main = sequence actions >> nl >> mapM (>> nl) (reverse actions)
Maybe some kindly soul could tell me what is the type of main here.
Running the right-hand clause within a "do" construct works fine.
However, if I try the following:
module Main where
actions = [putStr "foo", putStr "bar"]
nl = putStr "\n"
main = sequence actions >> nl >> mapM (>> nl) (reverse actions)
I get this message from runhugs:
Program error: fromDyn failed. Expecting <<IO() >> found <<IO[
Program error: {instShow_v1536_v1601 [instTypeable_v1537 (head
(unsafePerformIO main))]}runhugs: Error occurred
Trying to equip main with various IO types just leads to more errors.
What am I missing please?
*
Moreover, this is admittedly a powerful example of what can be done with
Haskell and monads. Is it possible to write such a program with
comparable ease in, say, SML or OCaml?
--
Tore
From frido@q-software-solutions.com Thu Feb 15 09:44:51 2001
Date: Thu, 15 Feb 2001 10:44:51 +0100
From: Friedrich Dominicus frido@q-software-solutions.com
Subject: hugs98 Februar 2001 release and graphics
Sorry, I do not know whom to ask. But the new version Hugs as of
Feb 2001 does not work with graphics any longer.
It seems that IOResult has changed significantly and so this code here
does not work any longer
safeTry :: IO a -> IO (Either IOError a)
-- safeTry m = m >>= return . Right
safeTry (IO m) = IO $ \ f s ->
case catchError (m Hugs_Error Hugs_Return) of
Just (Hugs_Return a) -> s (Right a)
r -> s (Left (mkErr r))
where
mkErr :: Maybe IOResult -> IOError
-- mkErr (Just Hugs_SuspendThread) = userError "suspended inside
protected code"
mkErr (Just (Hugs_ExitWith e)) = userError "exited inside protected
code"
mkErr (Just (Hugs_Error e)) = e
mkErr Nothing = userError "pattern match failure
inside protected code"
It would be nice if someone could point out what to do, to make those
examples run again. I tried to learn Haskell with the SOE book and I'm
quite helpless if that does not work any longer.
Regards
Friedrich
From sigbjorn_finne@hotmail.com Thu Feb 15 10:09:43 2001
Date: Thu, 15 Feb 2001 11:09:43 +0100
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: Feb 2001 MSI available
Hi,
I've packaged up a Windows Installer (.msi) for people that
want to easily set up and use Hugs98 February 2001 on a
Win32 platform. The MSI can be downloaded from
http://www.dcs.gla.ac.uk/~sof/hugs98.msi (1.4M)
It contains executables (hugs,runhugs and winhugs), libs
(std + win32), docs (html, hlp and pdf) and the demos. The
only thing that's (intentionally) missing is the Hugs98 source
code.
In the unlikely event that your machine doesn't already have
the Windows Installer engine/runtime installed, runtime
redistributables can be downloaded from
http://www.microsoft.com/msdownload/platformsdk/instmsi.htm
--sigbjorn
From sigbjorn_finne@hotmail.com Thu Feb 15 17:07:02 2001
Date: Thu, 15 Feb 2001 18:07:02 +0100
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: Feb 2001 MSI available
I've updated the installer a bit based on quick
feedback from Pepe Gallardo:
* moved user's manual so that WinHugs will find it.
* Haskell source files have been converted over to use
Win32 line terminators, i.e., CRLF.
* The installer will now also create a folder on the
start menu (Programs->Hugs98.)
The URL is the same as the one below.
--sigbjorn
----- Original Message -----
From: "Sigbjorn Finne" <sigbjorn_finne@hotmail.com>
To: "Hugs Bugs" <hugs-bugs@haskell.org>
Cc: <hugs-users@haskell.org>
Sent: Thursday, February 15, 2001 11:09
Subject: Feb 2001 MSI available
> Hi,
>
> I've packaged up a Windows Installer (.msi) for people that
> want to easily set up and use Hugs98 February 2001 on a
> Win32 platform. The MSI can be downloaded from
>
> http://www.dcs.gla.ac.uk/~sof/hugs98.msi (1.4M)
>
> It contains executables (hugs,runhugs and winhugs), libs
> (std + win32), docs (html, hlp and pdf) and the demos. The
> only thing that's (intentionally) missing is the Hugs98 source
> code.
>
> In the unlikely event that your machine doesn't already have
> the Windows Installer engine/runtime installed, runtime
> redistributables can be downloaded from
>
> http://www.microsoft.com/msdownload/platformsdk/instmsi.htm
>
> --sigbjorn
>
>
>
From erwig@cs.orst.edu Thu Feb 15 19:23:05 2001
Date: Thu, 15 Feb 2001 11:23:05 -0800
From: Martin Erwig erwig@cs.orst.edu
Subject: Let in do-expressions
Hi there,
I am trying to use the "let"-notation within do-expressions,
and it seems to me that it does not work correctly. (I am using
Hugs, version February 2000, on Solaris.)
E.g.,
do {x <- [1..9]; let i=1 in do {return ((+i) x)}}
works as expected, but with
do {x <- [1..9]; let i=1; return ((+i) x)}
I get:
ERROR: Syntax error in definition (unexpected symbol "i")
According to the Report (Section 3.14) the latter expression
should be a valid abbreviation of the former, or am I missing
something here? If it is a bug, has it been corrected in the
new version of Hugs?
Thanks,
Martin
From phiho.hoang@home.com Fri Feb 16 03:35:44 2001
Date: Thu, 15 Feb 2001 22:35:44 -0500
From: Phiho Hoang phiho.hoang@home.com
Subject: Hugs98 Feb.2001
This is a multi-part message in MIME format.
------=_NextPart_000_0060_01C0979F.A2504E20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Environment ; Win2K Advanced Server SP1 on PII 233 MHz.
Is the output of 'Calendar' correct ?
__ __ __ __ ____ ___ =
_______________________________________________
|| || || || || || ||__ Hugs 98: Based on the Haskell 98 =
standard
||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001
||---|| ___|| World Wide Web: http://haskell.org/hugs
|| || Report bugs to: hugs-bugs@haskell.org
|| || Version: February 2001 =
_______________________________________________
Haskell 98 mode: Restart with command line option -98 to enable =
extensions
Reading file "F:\hugs98\lib\Prelude.hs":
Hugs session for:
F:\hugs98\lib\Prelude.hs
Type :? for help
Prelude>
Prelude> :l "F:\\hugs98\\demos\\Calendar.hs"
Reading file "F:\hugs98\demos\Calendar.hs":
Reading file "F:\hugs98\demos\Gofer.hs":
Reading file "F:\hugs98\lib\List.hs":
Reading file "F:\hugs98\lib\Maybe.hs":
Reading file "F:\hugs98\lib\List.hs":
Reading file "F:\hugs98\lib\IO.hs":
Reading file "F:\hugs98\lib\Ix.hs":
Reading file "F:\hugs98\lib\IO.hs":
Reading file "F:\hugs98\lib\System.hs":
Reading file "F:\hugs98\demos\Calendar.hs":
Hugs session for:
F:\hugs98\lib\Prelude.hs
F:\hugs98\demos\Gofer.hs
F:\hugs98\lib\Maybe.hs
F:\hugs98\lib\List.hs
F:\hugs98\lib\Ix.hs
F:\hugs98\lib\IO.hs
F:\hugs98\lib\System.hs
F:\hugs98\demos\Calendar.hs
Calendar> cal 2000
" 2000 =
\n
\n =
January
February March \n Su Mo Tu We =
Th Fr Sa Su M
o Tu We Th Fr Sa Su Mo Tu We Th Fr Sa \n 1 =
1 2 3
4 5 1 2 3 4 \n 2 3 4 5 6 7 8 6 7 8 =
9 10 11 12
5 6 7 8 9 10 11 \n 9 10 11 12 13 14 15 13 14 15 16 17 18 19 =
12 13 14 15
16 17 18 \n 16 17 18 19 20 21 22 20 21 22 23 24 25 26 19 20 =
21 22 23 24 25 \
n 23 24 25 26 27 28 29 27 28 29 26 27 28 29 30 31 =
\n 30 31
\n
\n April
May June \n Su Mo Tu We Th Fr Sa =
Su Mo Tu We Th
Fr Sa Su Mo Tu We Th Fr Sa \n 1 1 2 =
3 4 5 6
1 2 3 \n 2 3 4 5 6 7 8 7 8 9 10 11 12 13 =
4 5 6 7
8 9 10 \n 9 10 11 12 13 14 15 14 15 16 17 18 19 20 11 12 =
13 14 15 16 17 \
n 16 17 18 19 20 21 22 21 22 23 24 25 26 27 18 19 20 21 22 23 =
24 \n 23 24 2
5 26 27 28 29 28 29 30 31 25 26 27 28 29 30 \n 30
\n
\n July =
August
September \n Su Mo Tu We Th Fr Sa Su Mo Tu =
We Th Fr Sa S
u Mo Tu We Th Fr Sa \n 1 1 2 3 4 5
1 2 \n 2 3 4 5 6 7 8 6 7 8 9 10 11 12 3 4 =
5 6 7 8 9 \
n 9 10 11 12 13 14 15 13 14 15 16 17 18 19 10 11 12 13 14 15 =
16 \n 16 17 1
8 19 20 21 22 20 21 22 23 24 25 26 17 18 19 20 21 22 23 \n 23 =
24 25 26 27 28
29 27 28 29 30 31 24 25 26 27 28 29 30 \n 30 31
\n
\n October =
November
December \n Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa =
Su Mo Tu We
Th Fr Sa \n 1 2 3 4 5 6 7 1 2 3 4 =
1 2 \
n 8 9 10 11 12 13 14 5 6 7 8 9 10 11 3 4 5 6 7 8 =
9 \n 15 16 1
7 18 19 20 21 12 13 14 15 16 17 18 10 11 12 13 14 15 16 \n 22 =
23 24 25 26 27
28 19 20 21 22 23 24 25 17 18 19 20 21 22 23 \n 29 30 31 =
26 2
7 28 29 30 24 25 26 27 28 29 30 \n
31 \n
\n"
Calendar>
=20
------=_NextPart_000_0060_01C0979F.A2504E20
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Environment ; Win2K Advanced Server SP1 =
on PII 233=20
MHz.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Is the output of 'Calendar' correct =
?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>__ __ __ __ =20
____ ___ =20
_______________________________________________<BR>|| || =
|| ||=20
|| || ||__ Hugs 98: Based on the =
Haskell 98=20
standard<BR>||___|| ||__|| ||__|| __|| =
Copyright=20
(c) 1994-2001<BR>||---|| =
___|| World =
Wide=20
Web: <A=20
href=3D"http://haskell.org/hugs">http://haskell.org/hugs</A><BR>|| &=
nbsp;=20
||  =
; =
=20
Report bugs to: <A=20
href=3D"mailto:hugs-bugs@haskell.org">hugs-bugs@haskell.org</A><BR>||&nbs=
p; =20
|| Version: February 2001 =20
_______________________________________________</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Haskell 98 mode: Restart with command =
line option=20
-98 to enable extensions</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Reading file=20
"F:\hugs98\lib\Prelude.hs":</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Hugs session=20
for:<BR>F:\hugs98\lib\Prelude.hs<BR>Type :? for=20
help<BR>Prelude><BR>Prelude> :l=20
"F:\\hugs98\\demos\\Calendar.hs"<BR>Reading file=20
"F:\hugs98\demos\Calendar.hs":<BR>Reading file=20
"F:\hugs98\demos\Gofer.hs":<BR>Reading file =
"F:\hugs98\lib\List.hs":<BR>Reading=20
file "F:\hugs98\lib\Maybe.hs":<BR>Reading file=20
"F:\hugs98\lib\List.hs":<BR>Reading file =
"F:\hugs98\lib\IO.hs":<BR>Reading file=20
"F:\hugs98\lib\Ix.hs":<BR>Reading file "F:\hugs98\lib\IO.hs":<BR>Reading =
file=20
"F:\hugs98\lib\System.hs":<BR>Reading file=20
"F:\hugs98\demos\Calendar.hs":</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Hugs session=20
for:<BR>F:\hugs98\lib\Prelude.hs<BR>F:\hugs98\demos\Gofer.hs<BR>F:\hugs98=
\lib\Maybe.hs<BR>F:\hugs98\lib\List.hs<BR>F:\hugs98\lib\Ix.hs<BR>F:\hugs9=
8\lib\IO.hs<BR>F:\hugs98\lib\System.hs<BR>F:\hugs98\demos\Calendar.hs<BR>=
Calendar>=20
cal=20
2000<BR>" &nbs=
p;  =
; =20
2000 &nb=
sp; &nbs=
p; =20
\n<BR> &=
nbsp; &n=
bsp; &nb=
sp; &nbs=
p;  =
; =20
\n =20
January<BR> &n=
bsp;=20
February  =
; =20
March =
\n Su Mo=20
Tu We Th Fr Sa Su M<BR>o Tu We Th Fr=20
Sa Su Mo Tu We Th Fr Sa =20
\n  =
; =20
1 =
1 =20
2 3<BR> 4 =20
5 =
=20
1 2 3 4 \n 2 3 =
4 =20
5 6 7 8 6 7 =
8 =20
9 10 11 12<BR>5 6 7 8 9 10 11 =
\n =20
9 10 11 12 13 14 15 13 14 15 16 17 18=20
19 12 13 14 15<BR>16 17 18 \n =
16 17 18=20
19 20 21 22 20 21 22 23 24 25 =
26 =20
19 20 21 22 23 24 25 \<BR>n 23 24 25 26 27 28=20
29 27 28=20
29  =
; =20
26 27 28 29 30 31 \n 30=20
31<BR> &=
nbsp; &n=
bsp; &nb=
sp; &nbs=
p;  =
; =20
\n<BR> &=
nbsp; &n=
bsp; &nb=
sp; &nbs=
p; =20
\n =20
April<BR> =20
May &nbs=
p; =20
June =
\n =20
Su Mo Tu We Th Fr Sa Su Mo Tu We Th<BR>Fr=20
Sa Su Mo Tu We Th Fr Sa =20
\n  =
; =20
1 1 2 =
3 =20
4 5 =20
6<BR> =
1 =20
2 3 \n 2 3 4 5 =
6 =20
7 8 7 8 9 10 11 12=20
13 4 5 6 =
7<BR> 8 9=20
10 \n 9 10 11 12 13 14 =
15 14 15=20
16 17 18 19 20 11 12 13 14 15 16 17 =20
\<BR>n 16 17 18 19 20 21 22 21 22 23 =
24 25=20
26 27 18 19 20 21 22 23 24 \n =
23 24=20
2<BR>5 26 27 28 29 28 29 30=20
31  =
; =20
25 26 27 28 29 30 \n =20
30<BR> &=
nbsp; &n=
bsp; &nb=
sp; &nbs=
p; =20
\n<BR> &=
nbsp; &n=
bsp; &nb=
sp; =20
\n =20
July &nb=
sp; =20
August<BR> &nb=
sp; =20
September \n Su Mo =
Tu We=20
Th Fr Sa Su Mo Tu We Th Fr =
Sa =20
S<BR>u Mo Tu We Th Fr Sa =20
\n  =
; =20
1 =
1 =20
2 3 4 5<BR> 1 2 =20
\n 2 3 4 5 6 7 =20
8 6 7 8 9 10 11=20
12 3 4 5 6 7 =
8 =20
9 \<BR>n 9 10 11 12 13 14 =
15 13=20
14 15 16 17 18 19 10 11 12 13 14 15 16 =20
\n 16 17 1<BR>8 19 20 21 22 20 21 22 =
23 24=20
25 26 17 18 19 20 21 22 23 \n =
23 24 25=20
26 27 28<BR>29 27 28 29 30=20
31 24 25 26 =
27 28 29=20
30 \n 30=20
31<BR> &=
nbsp; &n=
bsp; &nb=
sp; =20
\n<BR> &=
nbsp; &n=
bsp; =20
\n =20
October =
=20
November<BR> =20
December \n =
Su Mo Tu=20
We Th Fr Sa Su Mo Tu We Th Fr =
Sa =20
Su Mo Tu We<BR>Th Fr Sa \n 1 2 =
3 =20
4 5 6 =20
7 =
=20
1 2 3 =20
4 =
=20
1 2 \<BR>n 8 9 10 11 12 13=20
14 5 6 7 8 9 10=20
11 3 4 5 6 7 =
8 =20
9 \n 15 16 1<BR>7 18 19 20 21 =
12 13 14=20
15 16 17 18 10 11 12 13 14 15 16 =
\n 22=20
23 24 25 26 27<BR>28 19 20 21 22 23 24=20
25 17 18 19 20 21 22 23 \n 29 =
30=20
31  =
; =20
26 2<BR>7 28 29 =
30 =20
24 25 26 27 28 29 30 =20
\n<BR> =20
31  =
; =20
\n<BR> &=
nbsp; =20
\n"<BR>Calendar><BR> </FONT></DIV></BODY></HTML>
------=_NextPart_000_0060_01C0979F.A2504E20--
From landauer@apple.com Fri Feb 16 03:49:26 2001
Date: Thu, 15 Feb 2001 19:49:26 -0800
From: Doug Landauer landauer@apple.com
Subject: Hugs98 Feb.2001
On Thursday, February 15, 2001, at 07:35 PM, Phiho Hoang wrote:
> Is the output of 'Calendar' correct ?
I think so -- it's a typing issue. Try saying
putStr (cal 2000)
or, better,
putStr (cal 2001)
:-D oug
From nordland@cse.ogi.edu Fri Feb 16 22:10:42 2001
Date: Fri, 16 Feb 2001 14:10:42 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: hugs98 Februar 2001 release and graphics
Friedrich Dominicus wrote:
>
> Sorry, I do not know whom to ask. But the new version Hugs as of
> Feb 2001 does not work with graphics any longer.
>
> [...]
>
> It would be nice if someone could point out what to do, to make those
> examples run again. I tried to learn Haskell with the SOE book and I'm
> quite helpless if that does not work any longer.
Unfortunately the Hugs Graphics Library (http://haskell.org/graphics/)
is incompatible with a change that was made to the Hugs representation
of the IO monad in order to correct another bug. However, the graphics
library web page also mentions that a fix to the library is under way.
So there' hope...
-- Johan
From nordland@cse.ogi.edu Fri Feb 16 22:42:32 2001
Date: Fri, 16 Feb 2001 14:42:32 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: Let in do-expressions
Martin Erwig wrote:
>
> Hi there,
>
> I am trying to use the "let"-notation within do-expressions,
> and it seems to me that it does not work correctly. (I am using
> Hugs, version February 2000, on Solaris.)
>
> E.g.,
>
> do {x <- [1..9]; let i=1 in do {return ((+i) x)}}
>
> works as expected, but with
>
> do {x <- [1..9]; let i=1; return ((+i) x)}
>
> I get:
>
> ERROR: Syntax error in definition (unexpected symbol "i")
>
> According to the Report (Section 3.14) the latter expression
> should be a valid abbreviation of the former, or am I missing
> something here? If it is a bug, has it been corrected in the
> new version of Hugs?
No, it's not a bug, but an unfortunate consequence of the current
definition of the layout rule. What you've written will be parsed as
do {x <- [1..9]; let {i=1; return ((+i) x)}}
which is clearly incorrect (although the error message isn't very
helpful).
What you probably intended was
do {x <- [1..9]; let {i=1}; return ((+i) x)}
but the layout rule isn't advanced enough to figure this out. The
exact reason is that only one look-ahead is used to determine if
a closing brace should be inserted, but since 'return' is a valid
prefix of a let-definition, the parser has already committed to
parsing more let-bindings when the error is detected.
Note especially that
do {x <- [1..9]; let i=1; in return ((+i) x)}
parses ok.
The problem with this part of the layout rule was discussed on the
haskell list not long ago, see
http://www.mail-archive.com/haskell@haskell.org/msg08099.html
-- Johan
From nordland@cse.ogi.edu Sat Feb 17 04:30:02 2001
Date: Fri, 16 Feb 2001 20:30:02 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: Purity of the stack execution model? (fwd)
Koen Claessen wrote:
>
> Hi!
>
> Somebody posted the following message on
> comp.lang.functional. It reports an error when having a main
> function which has type "IO [()]", together with using
> runhugs.
>
> This is a bug; the Haskell report says that main "must be a
> computation of type IO t for some type t".
>
> /Koen.
>
> [..]
>
> However, if I try the following:
>
> module Main where
> actions = [putStr "foo", putStr "bar"]
> nl = putStr "\n"
> main = sequence actions >> nl >> mapM (>> nl) (reverse actions)
>
> I get this message from runhugs:
>
> Program error: fromDyn failed. Expecting <<IO() >> found <<IO[
> Program error: {instShow_v1536_v1601 [instTypeable_v1537 (head
> (unsafePerformIO main))]}runhugs: Error occurred
This bug, as well as the secondary one that shows up in the aborted error
message above, are now corrected in the CVS repository (but won't be visible
until tomorrow). They are however both too minor to warrant any patch to the
current release. Notice also that it is always possible to circumvent the
bug by defining
main = old_main >> return ()
Anyone who wants to access the Hugs98 cvs repository should point their web
browser to
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/hugs98/
-- Johan
From ashley@semantic.org Mon Feb 19 10:17:16 2001
Date: Mon, 19 Feb 2001 02:17:16 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: Line Break Handling Request
Currently I'm using the MacOS version of Hugs. The Macintosh platform is
undergoing a sort of evolution towards Unix, and text files may either
have traditional MacOS linebreaks (CR) or Unix linebreaks (LF). MacOS
Hugs only works with the former.
I think all platform-versions of Hugs should accept all kinds of
linebreaks:
CR (as MacOS)
LF (as Unix)
CR LF (as Windows)
...as line breaks.
If you ever get around to supporting Unicode, you should also handle
\u2028 and \u2029, but that is a separate issue.
--
Ashley Yakeley, Seattle WA
From haberg@matematik.su.se Mon Feb 19 11:26:00 2001
Date: Mon, 19 Feb 2001 12:26:00 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Line Break Handling Request
At 02:17 -0800 2001/02/19, Ashley Yakeley wrote:
>Currently I'm using the MacOS version of Hugs. The Macintosh platform is
>undergoing a sort of evolution towards Unix, and text files may either
>have traditional MacOS linebreaks (CR) or Unix linebreaks (LF). MacOS
>Hugs only works with the former.
>
>I think all platform-versions of Hugs should accept all kinds of
>linebreaks:
>CR (as MacOS)
>LF (as Unix)
>CR LF (as Windows)
Actually this has already been fixed but not yet released in the form of a
binary. :-)
The reason this binary was not released is that it has some AppleEvent's
handling I felt was experimental, and I could not get the time to check it
out (and no one else it seems).
>If you ever get around to supporting Unicode, you should also handle
>\u2028 and \u2029, but that is a separate issue.
Yes, Unicode is supported by MacOS X, which will be released towards the
end of March. This MacOS X has BSD, so it should be easy to compile as a
command line program.
As for Hugs with GUI MacOS X: I do not know. Depends if people find it
exiting find the time to develop on that platform. (Lack of supercomputer
cycles is the usual human problem I think... :-))
As for Hugs support for Unicode (which may be 16 or 32 bit), I do not know:
Perhaps some of the Hugs developers can inform.
Hans Aberg
From paul@treetop.demon.co.uk Tue Feb 20 16:54:34 2001
Date: Tue, 20 Feb 2001 16:54:34 +0000
From: Paul Johnson paul@treetop.demon.co.uk
Subject: Corrupted files?
I've been trying to download and install Hugs 98. However the .msi
and .hlp files are reported as corrupt. I'm downloading using Netscape
4.7 and installing on NT 4 SR 6 using the installer version 1.2 that you
point to for installing .msi files.
Paul.
--
Paul Johnson | Marconi plc is not responsible for my
opinions. |
+44 1245 242244
+-----------+-----------------------------------------+
Work: <paul.johnson@marconi.com> | You are lost in a twisty maze of
little
Home: <Paul@treetop.demon.co.uk> | standards, all different.
From nordland@cse.ogi.edu Tue Feb 20 21:03:48 2001
Date: Tue, 20 Feb 2001 13:03:48 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: Corrupted files?
Paul Johnson wrote:
>
> I've been trying to download and install Hugs 98. However the .msi
> and .hlp files are reported as corrupt. I'm downloading using Netscape
> 4.7 and installing on NT 4 SR 6 using the installer version 1.2 that you
> point to for installing .msi files.
>
> Paul.
> --
> Paul Johnson | Marconi plc is not responsible for my
> opinions. |
> +44 1245 242244
> +-----------+-----------------------------------------+
> Work: <paul.johnson@marconi.com> | You are lost in a twisty maze of
> little
> Home: <Paul@treetop.demon.co.uk> | standards, all different.
Hi Paul,
We've just discovered that our web server assigns the wrong MIME type to .msi
files, and that's most likely what's causing your troubles. The web server will
of course be fixed, but in the meantime you might want to try the zipped
installer I've also put onto the Hugs downloading page. That format should
download without being correupted by line-feed translations. Then just unzip it
and fire off the installer.
-- Johan
From nordland@cse.ogi.edu Tue Feb 20 23:06:58 2001
Date: Tue, 20 Feb 2001 15:06:58 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: Corrupted files?
Johan Nordlander wrote:
>
> Paul Johnson wrote:
> >
> > I've been trying to download and install Hugs 98. However the .msi
> > and .hlp files are reported as corrupt. I'm downloading using Netscape
> > 4.7 and installing on NT 4 SR 6 using the installer version 1.2 that you
> > point to for installing .msi files.
> >
> > Paul.
> > --
> > Paul Johnson | Marconi plc is not responsible for my
> > opinions. |
> > +44 1245 242244
> > +-----------+-----------------------------------------+
> > Work: <paul.johnson@marconi.com> | You are lost in a twisty maze of
> > little
> > Home: <Paul@treetop.demon.co.uk> | standards, all different.
>
> Hi Paul,
>
> We've just discovered that our web server assigns the wrong MIME type to .msi
> files, and that's most likely what's causing your troubles. The web server will
> of course be fixed, but in the meantime you might want to try the zipped
> installer I've also put onto the Hugs downloading page. That format should
> download without being correupted by line-feed translations. Then just unzip it
> and fire off the installer.
>
> -- Johan
Our web server is now updated to handle .msi files correctly, so I'm removing
the
zipped installer from the Hugs downloading page. Note, though, that you might
have
to configure your browser to handle "application/x-msi" files (extension .msi)
by
saving them to disk
Please report if you encounter any remaining problems.
-- Johan
From schulzs@uni-freiburg.de Wed Feb 21 15:55:05 2001
Date: Wed, 21 Feb 2001 16:55:05 +0100
From: Sebastian Schulz schulzs@uni-freiburg.de
Subject: problems after compiling hugs
Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------158D64630616B9F4EB7B8AF5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi there!
I've just downloaded the sourcepackage of the Feb2001 version. I need to
change the NUM_INSTS variable in the <prelude.h> file, so I did it
before running the ./configure script (in src/unix/ , I'm using
SuseLinux 7.1).
After running the script and installing with "make install" hugs startet
without problems, BUT:
there is no commandline history!! When typing the up-arrow, there appear
only cryptic characters on the sreen.
What is missing?
I've attached the outprint of the ./configure script, not seeing where
the problem is...
thanks
sebastian
--------------158D64630616B9F4EB7B8AF5
Content-Type: text/plain; charset=us-ascii;
name="instmsg"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="instmsg"
bash-2.04# ./configure
creating cache ./config.cache
checking for bison... bison -y
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for perl... perl
checking whether make sets ${MAKE}... yes
checking for hp2ps... 1
checking for diff... /usr/bin/diff
checking whether to use diff -c1 or diff -C 1... /usr/bin/diff -C 1
checking for function_dlopen... no
checking for library_dl... yes
checking for function_shl_load... no
checking for library_dld... no
checking for function_atan... no
checking for library_m... yes
checking for ANSI C header files... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for stdarg.h... yes
checking for stdlib.h... yes
checking for unistd.h... yes
checking for assert.h... yes
checking for ctype.h... yes
checking for string.h... yes
checking for fcntl.h... yes
checking for sgtty.h... yes
checking for termio.h... yes
checking for termios.h... yes
checking for signal.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for sys/ioctl.h... yes
checking for sys/resource.h... yes
checking for sys/param.h... yes
checking for console.h... no
checking for pascal.h... no
checking for Files.h... no
checking for errno.h... yes
checking for stat.h... no
checking for nlist.h... no
checking for ftw.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking for time.h... yes
checking for sys/time.h... yes
checking for float.h... yes
checking for values.h... yes
checking for dos.h... no
checking for conio.h... no
checking for io.h... no
checking for std.h... no
checking for windows.h... no
checking for dlfcn.h... yes
checking for dl.h... no
checking for alloc.h... no
checking for malloc.h... yes
checking for valloc... yes
checking for strcasecmp... yes
checking for _stricmp... no
checking for stricmp... no
checking for strcmpi... no
checking for strcmp... yes
checking for realpath... yes
checking for _fullpath... no
checking for PBHSetVolSync... no
checking for macsystem... no
checking for fgetpos... yes
checking for fsetpos... yes
checking for fseek... yes
checking for ftell... yes
checking for vsnprintf... yes
checking for _vsnprintf... no
checking for snprintf... yes
checking for _snprintf... no
checking for popen... yes
checking for _popen... no
checking for pclose... yes
checking for _pclose... no
checking for sigprocmask... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for _alloca... no
checking for stime... yes
checking for poly... no
checking for working const... yes
checking prototypes... yes
checking for arrays of jmp_bufs... yes
checking labels as values... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking return type of signal handlers... void
checking whether gcc needs -traditional... no
checking for a leading underscore in symbol names
checking for ld... ld
checking size of int... 4
checking size of float... 4
checking size of double... 8
checking size of int*... 4
building large hugs
updating cache ./config.cache
creating ./config.status
creating ../Makefile
creating ../../docs/Makefile
creating ../../docs/hugs.1
creating ../config.h
creating ../options.h
************************************************
*** NOW DO: cd .. followed by make install
************************************************
bash-2.04# cd ..
bash-2.04# make install
gcc -c -g -O2 hugs.c
gcc -c -g -O2 storage.c
gcc -c -g -O2 input.c
gcc -c -g static.c
gcc -c -g type.c
gcc -c -g -O2 subst.c
gcc -c -g compiler.c
gcc -c -g -O2 plugin.c
gcc -c -g -O2 builtin.c
gcc -c -g -O2 machine.c
gcc -c -g -O2 output.c
gcc -c -g -O2 ffi.c
gcc hugs.o storage.o input.o static.o type.o subst.o compiler.o plugin.o builtin.o machine.o output.o ffi.o -lm -ldl -o hugs
gcc -c -g -O2 runhugs.c
gcc -c -g -O2 server.c
gcc runhugs.o server.o storage.o input.o static.o type.o subst.o compiler.o plugin.o builtin.o machine.o output.o ffi.o -lm -ldl -o runhugs
unix/install-sh -d /usr/local/bin
unix/install-sh hugs /usr/local/bin
unix/install-sh runhugs /usr/local/bin
unix/install-sh -d /usr/local/share/hugs/lib
/bin/cp ../lib/*.* /usr/local/share/hugs/lib
unix/install-sh -d /usr/local/share/hugs/lib/hugs
/bin/cp ../lib/hugs/*.* /usr/local/share/hugs/lib/hugs
unix/install-sh -d /usr/local/share/hugs/lib/exts
/bin/cp ../lib/exts/*.* /usr/local/share/hugs/lib/exts
unix/install-sh -d /usr/local/share/hugs/demos
unix/install-sh -d /usr/local/share/hugs/demos/prolog
/bin/cp ../demos/*.* /usr/local/share/hugs/demos
/bin/cp ../demos/prolog/*.* /usr/local/share/hugs/demos/prolog
/bin/cp ../demos/prolog/readme /usr/local/share/hugs/demos/prolog
/bin/cp ../demos/prolog/stdlib /usr/local/share/hugs/demos/prolog
unix/install-sh -d /usr/local/man/man1
/bin/cp ../docs/hugs.1 /usr/local/man/man1
--------------158D64630616B9F4EB7B8AF5--
From sievers@ips.cs.tu-bs.de Wed Feb 21 20:04:07 2001
Date: Wed, 21 Feb 2001 21:04:07 +0100 (MET)
From: Christian Sievers sievers@ips.cs.tu-bs.de
Subject: problems after compiling hugs
Sebastian Schulz wrote:
> there is no commandline history!! When typing the up-arrow, there appear
> only cryptic characters on the sreen.
> bash-2.04# ./configure
Try ./configure --with-readline
Or even better, do ./configure --help
to see all the options you have.
HTH
Christian Sievers
From krijo@cs.chalmers.se Fri Feb 23 09:58:28 2001
Date: Fri, 23 Feb 2001 10:58:28 +0100
From: Kristofer Johannisson krijo@cs.chalmers.se
Subject: ":load System" in mac version of Hugs Feb 2001
Hi,
the macintosh version of Hugs 98 February 2001 gives me an error when I type
":load System":
-----
Prelude> :load System
Reading file "System":
Parsing
ERROR System:1 - Syntax error in declaration (unexpected symbol "d1")
------
Note that it works OK if you type ":load System.hs":
-------
Prelude> :load System.hs
Reading file "Macintosh HD:Applications (Mac OS 9):hugs98:lib:System.hs":
Hugs session for:
Macintosh HD:Applications (Mac OS 9):hugs98:lib:Prelude.hs
Macintosh HD:Applications (Mac OS 9):hugs98:lib:System.hs
--------
You can load other standard things without the ".hs", for instance:
--------
List> :load List
Reading file "Macintosh HD:Applications (Mac OS 9):hugs98:lib:List.hs":
Reading file "Macintosh HD:Applications (Mac OS 9):hugs98:lib:Maybe.hs":
Reading file "Macintosh HD:Applications (Mac OS 9):hugs98:lib:List.hs":
Hugs session for:
Macintosh HD:Applications (Mac OS 9):hugs98:lib:Prelude.hs
Macintosh HD:Applications (Mac OS 9):hugs98:lib:Maybe.hs
Macintosh HD:Applications (Mac OS 9):hugs98:lib:List.hs
-------
/ Kristofer Johannisson
From haberg@matematik.su.se Fri Feb 23 11:13:08 2001
Date: Fri, 23 Feb 2001 12:13:08 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: ":load System" in mac version of Hugs Feb 2001
At 10:58 +0100 2001/02/23, Kristofer Johannisson wrote:
>the macintosh version of Hugs 98 February 2001 gives me an error when I type
>":load System":
>-----
>Prelude> :load System
>Reading file "System":
>Parsing
>ERROR System:1 - Syntax error in declaration (unexpected symbol "d1")
>------
>
>Note that it works OK if you type ":load System.hs":
Yes, I have noticed that problem, and the thing is that none of us (me and
Pablo) could figure out why! :-)
-- One explanation could be that for some reason, Hugs tries to read the
MacOS system file, which on all Mac's is named "System", in which case it
would read some strange garbage.
But since there was no obvious immediate fix, and that one can load using
the full name "System.hs", I guess we will have to live with the problem.
Hans Aberg
* Email: Hans Aberg <mailto:haberg@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
From ger@tzi.de Fri Feb 23 11:29:45 2001
Date: Fri, 23 Feb 2001 12:29:45 +0100
From: George Russell ger@tzi.de
Subject: Reading numbers technicality
I think
main = putStrLn(show ((reads "123.")::[(Int,String)]))
should print [(123,".")] rather than [] as it does in Hugs (Feb2001).
As far as I can work out, from the rather tangled Haskell code in the
Prelude, Hugs is at fault, not the Prelude. Glasgow Haskell 4.08.2 agrees
with me.
Please cc replies to me, as I don't subscribe to this group.
From raubal@geoinfo.tuwien.ac.at Fri Feb 23 12:44:12 2001
Date: Fri, 23 Feb 2001 13:44:12 +0100
From: Martin Raubal raubal@geoinfo.tuwien.ac.at
Subject: hugs & text editor
Hi there!
We have the following problem with the Feb. 2001 version of Hugs: When
having an error and linking Hugs with a text editor, such as UEdit, it used
to be the case that the cursor in the text editor is automatically set to
the line of the error. This does not work with the new version, the cursor
is always at the beginning and one needs to search for the line given in
Hugs.
Any help?
cheers,
martin
Dipl.-Ing. Martin Raubal
Institute for Geoinformation
TU Vienna
Gusshausstr. 27-29, A-1040 Vienna
Tel. (+43 1) 588 01-12716
Fax (+ 43 1) 588 01-12799
http://www.geoinfo.tuwien.ac.at/persons/raubal/raubal.html
From Julian_Seward@muraroa.demon.co.uk Sun Feb 25 00:58:58 2001
Date: Sun, 25 Feb 2001 00:58:58 +0000
From: Julian Seward Julian_Seward@muraroa.demon.co.uk
Subject: Buffer overrun bug in typeClassDefn() in type.c
Greetings, earthlings.
Implausible as it seems, I believe I've found a buffer overrun
in typeClassDefn() in type.c, in the latest (Feb 2001) Hugs.
The problem happens under normal operation -- loading the
Prelude is enough to make it happen.
The problem occurs in the loop beginning
for (; nonNull(mems); mems=tl(mems)) {
Lines 2233 through 2239 are intended to assign to buf the
value "default_" ++ textToStr(name(hd(mems)).text), so to
speak. Unfortunately they only do this correctly on the
first iteration of this loop, because i and j are set to
zero at the start of the function, whereas they should be
zeroed at the start of each trip round the loop. To show
that something is way wrong, try putting
printf("buf is `%s'\n", buf)
immediately after buf[i+j] = '\0'; and watch ever-longer
junk strings being printed out.
I propose adding simply
i = j = 0;
at line 2234. Hugs still seems to load the Prelude correctly,
and, in addition, the buf printouts now seem correct.
How could Hugs ever have worked with this bug?
* The size of buf, FILENAME_MAX, is quite large. This loop
processes default methods for classes; presumably you'd need
a class with a lot of default methods before buf got extended
beyond FILENAME_MAX ?
* The string generated into buf[] is hashed, and that hash value
is used, indirectly, as a unique name for the default method,
so it doesn't actually matter that the wrong-ish string has
been hashed.
J
From promocionesdosmiluno@yahoo.es Sun Feb 25 18:04:34 2001
Date: Sun, 25 Feb 2001 13:04:34 -0500 (EST)
From: promocionesdosmiluno@yahoo.es promocionesdosmiluno@yahoo.es
Subject: Lo mejor de Internet aquí
This is a multi-part message in MIME format.
--Z_MULTI_PART_MAIL_BOUNDAEY_S
Content-Type: text/plain
Content-Transfer-Encoding: base64
VmlzaXRhIGVzdGEgd2ViDQoNCmh0dHA6Ly9NdW5kb0VzcGFueWEucmVkaXJlY2Npb24uY29t
DQoNCiAgICA=
--Z_MULTI_PART_MAIL_BOUNDAEY_S--
From Christian.Laaser@icn.siemens.de Mon Feb 26 14:35:50 2001
Date: Mon, 26 Feb 2001 15:35:50 +0100
From: Laaser Christian Christian.Laaser@icn.siemens.de
Subject: AW: AW: What does "Compiled code too complex" error message of Hu
gs mean?
I installed the new Feb 2001 distribution and I saw that NUM_FIXUPS=20
with value 1000 is only possible for large version of hugs interpreter.
It would be great if I could get this version because the standard =
interpreter
only has a NUM_FIXUPS of 400 and so I get the error message
"Compiled code too complex".
Thank you very much.
Christian=20
> -----Urspr> =FCngliche Nachricht-----
> Von: Mark P Jones [SMTP:mpj@cse.ogi.edu]
> Gesendet am: Montag, 12. Februar 2001 20:07
> An: kort@wins.uva.nl; Laaser Christian
> Cc: hugs-bugs@haskell.org
> Betreff: RE: AW: What does "Compiled code too complex" error message =
of Hugs mean?
>=20
> I know this is more than a week old, but I've been away ... and
> now that I'm back, I'd like to clear up a possible misunderstanding
> that began with an exchange along the following lines:
>=20
> | > > When loading some Haskell files with Hugs, I get the error=20
> | > > message "Compiled code too complex". However, the compilation=20
> | > > with GHC 4.08.1 succeeds. =20
> | > > What does this message mean? What can I do about it?
> | ...
> | > You can grep for that sentence in "hugs98/src", it will point to =
the
> | > file "machine.c". There you will see it says "if =
nextLab>=3DNUM_FIXUPS) ...".
> | > So grep for "NUM_FIXUPS" it will point to the file "prelude.h". I
> | > think the default value is 400, you should increase it to 1000 or =
so.
> | > I have it at 10000, but that's probably not necesary in your case
> | > and if you increase constants too much starting up Hugs will =
become
> | > slower.
>=20
> First of all, an explanation. Inside Hugs, the code for Haskell
> functions is translated into a low-level, abstract machine language.
> (In today's environment, the way that Java programs are translated
> into JVM bytecode is probably a good analogy.) As the machine
> language code is generated, the compiler sometimes needs to insert
> "jump" instructions to addresses that are not yet known. In this
> situation, it instead inserts a dummy address, but adds an entry to
> a simple table of "fixups" that will later be filled in with the
> correct address. Once the complete section of code has been =
generated,
> Hugs scans over it once again and replaces each unknown address with
> the correct value from the fixups table. This process is also quite
> commonly described as "back-patching".
>=20
> The fixups table can contain at most NUM_FIXUPS entries, which, in =
the
> current distribution, is set to 400. Programs that require more =
entries
> than this in a single block of code will lead to the "Compiled code =
too
> complex" error message that you have seen. There is not particular
> reason for the choice of 400; this is just a number that seemed to =
work
> ok for most practical purposes. If you get a compiled code too =
complex
> message, it is perhaps a sign that you would benefit from looking at
> ways to break your code down into smaller, simpler, and more=20
> understandable pieces. More likely, however, you will see this error
> with code that was generated automatically, in response to a =
"deriving"
> request on a datatype, or by a tool like a parser generator. In this
> case, changing the Haskell code that is generated is not an option.
>=20
> Increasing the standard setting for NUM_FIXUPS is certainly an option
> here. You would have to increase it a great deal for there to be any
> impact on the speed with which Hugs starts. In comparison to the
> standard heap sizes that people use, the fixups table is a drop in =
the
> ocean. I think Johan has already increased the size for the Feb 2001
> distribution that will be out in a couple of days.
>=20
> The fixups table could be allocated dynamically, and expand on =
demand.
> To understand why Hugs doesn't do it that way already, you need to go
> back more than a decade to Gofer, the system from which Hugs was
> derived, which was designed to work on an 8086 with segmented memory> =
> and a maximum of 640K. Back in those days, when loading the prelude
> took 30 seconds (and it was much smaller then too!), a statically
> allocated table made sense because it was slightly faster and because
> there wasn't any spare memory for it to expand into anyway, even if
> you went to the trouble of dynamically allocating it.
>=20
> Historical note: If you'd like to see the heart of the machine that
> ran those original versions of Gofer, come visit me; it's sitting
> here on the desk lamp in my office :-)
>=20
> All the best,
> Mark
From reid@cs.utah.edu Mon Feb 26 17:22:07 2001
Date: Mon, 26 Feb 2001 10:22:07 -0700
From: Alastair Reid reid@cs.utah.edu
Subject: AW: What does "Compiled code too complex" error message of Hugs mean?
Laaser Christian writes:
> I installed the new Feb 2001 distribution and I saw that NUM_FIXUPS
> with value 1000 is only possible for large version of hugs interpreter.
> It would be great if I could get this version because the standard
> interpreter
> only has a NUM_FIXUPS of 400 and so I get the error message
> "Compiled code too complex".
Almost every machine in existence uses the large version so I'm a bit surprised
by this report. Can you confirm:
a) That your machine _does not_ use the large version.
(Look at the values of SMALL_HUGS, REGULAR_HUGS and LARGE_HUGS in
hugs98/src/options.h)
b) That changing NUM_FIXUPS to 1000 fixes your problem.
If you are indeed using the regular version, is there any reason why you can't
use the large version?
--
Alastair Reid
From nordland@cse.ogi.edu Tue Feb 27 00:09:55 2001
Date: Mon, 26 Feb 2001 16:09:55 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: hugs & text editor
Martin Raubal wrote:
>
> Hi there!
>
> We have the following problem with the Feb. 2001 version of Hugs: When
> having an error and linking Hugs with a text editor, such as UEdit, it used
> to be the case that the cursor in the text editor is automatically set to
> the line of the error. This does not work with the new version, the cursor
> is always at the beginning and one needs to search for the line given in
> Hugs.
>
> Any help?
>
> cheers,
> martin
Hi Martin,
Can you send me the editor settings you're currently using (will show up in the
third line from the bottom if you type :set at the Hugs command prompt). That
might show the cause of your problem.
-- Johan
From p.turner@computer.org Tue Feb 27 14:11:21 2001
Date: Tue, 27 Feb 2001 09:11:21 -0500
From: Scott Turner p.turner@computer.org
Subject: floating literals rounded too soon
With the Feb 2001 Hugs,
0.1 :: Rational
evaluates to
13421773 % 134217728
rather than
1 % 10
which would be more useful and portable.
--
Scott Turner
p.turner@computer.org http://www.billygoat.org/pkturner
From ok@atlas.otago.ac.nz Wed Feb 28 00:40:39 2001
Date: Wed, 28 Feb 2001 13:40:39 +1300 (NZDT)
From: Richard A. O'Keefe ok@atlas.otago.ac.nz
Subject: Feb2001 hugs98 on MacOS
The February 2001 release of Hugs 98 unpacked fine and seems to run fine
on my PowerMac 7600/120 running Mac OS 8.6
HOWEVER, the characters in the console window are teeny tiny wee characters
indeed. What are they, 8 point? I could live with 10 point, but would
personally rather have 12 point. So what do I do to change the size of
the text in this window?
I poked around in the sources, and discovered that the window is a SIOUX
console. It appears that Hugs does not set any SIOUX options to control
the text size, but I may have missed something.
I wanted to try setting SIOUXSettings.fontsize = 12;
but unfortunately I have CW Pro 2, not CW Pro 5, so cannot use the
XML project file provided, and no instructions for using CW Pro 2
were included.
I would strongly recommend adding a "-fontsize" command line option
that can be put in the Hugs Preferences file.
Come to think of it, a -fontface option so that I can get 'courier'
instead of 'monaco' would be nice too.
From ashley@semantic.org Wed Feb 28 04:05:25 2001
Date: Tue, 27 Feb 2001 20:05:25 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: Bug in Hugs 98 MacOS Feb-2001: Can't drop files on application
Product: Hugs 98 MacOS Feb-2001
To Repro:
In the Finder, drop a haskell source file on the "Hugs 98" application.
Results:
Hugs 98 launches, but doesn't read source file.
Expected:
Hugs 98 to launch, read source file.
The worked OK in previous versions of Hugs 98 (although you couldn't drop
source files on an already-running app).
--
Ashley Yakeley, Seattle WA
From haberg@matematik.su.se Wed Feb 28 11:28:56 2001
Date: Wed, 28 Feb 2001 12:28:56 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Feb2001 hugs98 on MacOS
At 13:40 +1300 2001/02/28, Richard A. O'Keefe wrote:
>The February 2001 release of Hugs 98 unpacked fine and seems to run fine
>on my PowerMac 7600/120 running Mac OS 8.6
>
>HOWEVER, the characters in the console window are teeny tiny wee characters
>indeed. What are they, 8 point? I could live with 10 point, but would
>personally rather have 12 point. So what do I do to change the size of
>the text in this window?
At 20:05 -0800 2001/02/27, Ashley Yakeley wrote:
>Product: Hugs 98 MacOS Feb-2001
>To Repro:
>In the Finder, drop a haskell source file on the "Hugs 98" application.
>Results:
>Hugs 98 launches, but doesn't read source file.
...
>The worked OK in previous versions of Hugs 98 (although you couldn't drop
>source files on an already-running app).
The explanation of these problems is this:
The first joint version I and Pablo MacOS made, happened at right the time
MPJ wrote the last version and then left the Hugs team. So because of that,
the MacOS modification where never written into that version.
Nor has the subsequent Hugs team ever written in those or any later MacOS
versions into the Hugs sources. So what you have in those sources are some
very old MacOS stuff.
Now, it seems, somebody at the Hugs team (Johan?) has tacitly assumed that
these old Mac modifications are OK, and compiled it. But then most of the
later stuff breaks.
So in order to get all the latest MacOS features, one has to take the
latest Hugs Feb 2001 sources, and patch them up with the MacOS Feb 2000
sources.
Fortunately for you, I have just made it, so hopefully you don't have to do
it. :-) Hope it works.
Johan:
I will send the stuff to you, so you can make a new binary distribution,
and perhaps also patch up the current sources.
The stuff I patched up has some experimental AppleEvent's code installed,
so if one does not load a file named Events.hs, bringing it up front by
double-clicking its icon will printout "Receive event error -10", meaning
that the event isn't handled.
But I hope the AppleEvent code will not break anything else.
Hans Aberg
From dduggan@cs.stevens-tech.edu Wed Feb 28 16:00:27 2001
Date: Wed, 28 Feb 2001 11:00:27 -0500
From: Dominic Duggan dduggan@cs.stevens-tech.edu
Subject: please confirm that this is a feature
This is a multi-part message in MIME format.
--------------D346861763080A51FF2DCE83
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I am finishing up revisions on a paper that
has been accepted to JFP, on type-checking
with multi-parameter type classes.
With the following definitions:
| class Foo a b | a -> b where foo :: a -> b -> Int
|
| instance Foo Int Float where foo x y = 0
|
| instance Foo a b => Foo [a] [b] where foo [x] [y] = foo x y
|
| g x y = (foo [x] y) + (foo [y] x)
In our system type-checking fails to terminate when
type-checking "g", but Hugs 98 (Feb 2001) returns
a type.
I assume that this is because of a depth bound in the
type-checker, can you confirm this before I submit
the final version of the paper?
Thanks
--dd
--------------D346861763080A51FF2DCE83
Content-Type: text/x-vcard; charset=us-ascii;
name="dduggan.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dominic Duggan
Content-Disposition: attachment;
filename="dduggan.vcf"
begin:vcard
n:Duggan;Dominic
tel;fax:(201) 216-8249
tel;work:(201) 216-8042
x-mozilla-html:FALSE
url:http://guinness.cs.stevens-tech.edu/~dduggan/index.html
org:Stevens Institute of Technology;Computer Science
version:2.1
email;internet:dduggan@cs.stevens-tech.edu
title:Associate Professor
note:Web page: http://guinness.cs.stevens-tech.edu/~dduggan/index.html
adr;quoted-printable:;;Department of Computer Science=0D=0AStevens Institute of Technology;Hoboken;New Jersey;07030;USA
x-mozilla-cpt:;10656
fn:Dominic Duggan
end:vcard
--------------D346861763080A51FF2DCE83--
From simonpj@microsoft.com Wed Feb 28 16:50:35 2001
Date: Wed, 28 Feb 2001 08:50:35 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: please confirm that this is a feature
GHC infers the type
g :: (Foo [[a]] [b], Foo [[b]] [a]) => [a] -> [b] -> Int
As you imply, if GHC used the instance decl to simplify
the first constraint to Foo [a] b, for example, then the functional
dependency would kick in, and there would be an infinite loop.
But GHC's constraint simplification is (now) lazy, unless forced
to be eager by supplying a type signature.
I think Hugs is the same, and I think that's probably why it
terminates.
Interesting example!
Simon
| -----Original Message-----
| From: Dominic Duggan [mailto:dduggan@cs.stevens-tech.edu]
| Sent: 28 February 2001 16:00
| To: hugs-bugs@haskell.org
| Subject: please confirm that this is a feature
|
|
| I am finishing up revisions on a paper that
| has been accepted to JFP, on type-checking
| with multi-parameter type classes.
| With the following definitions:
|
| | class Foo a b | a -> b where foo :: a -> b -> Int
| |
| | instance Foo Int Float where foo x y = 0
| |
| | instance Foo a b => Foo [a] [b] where foo [x] [y] = foo x y
| |
| | g x y = (foo [x] y) + (foo [y] x)
|
| In our system type-checking fails to terminate when
| type-checking "g", but Hugs 98 (Feb 2001) returns
| a type.
|
| I assume that this is because of a depth bound in the
| type-checker, can you confirm this before I submit
| the final version of the paper?
|
| Thanks
| --dd
|
From nordland@cse.ogi.edu Wed Feb 28 19:58:19 2001
Date: Wed, 28 Feb 2001 11:58:19 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: Feb2001 hugs98 on MacOS
Hans Aberg wrote:
>
> At 13:40 +1300 2001/02/28, Richard A. O'Keefe wrote:
> >The February 2001 release of Hugs 98 unpacked fine and seems to run fine
> >on my PowerMac 7600/120 running Mac OS 8.6
> >
> >HOWEVER, the characters in the console window are teeny tiny wee characters
> >indeed. What are they, 8 point? I could live with 10 point, but would
> >personally rather have 12 point. So what do I do to change the size of
> >the text in this window?
>
> At 20:05 -0800 2001/02/27, Ashley Yakeley wrote:
> >Product: Hugs 98 MacOS Feb-2001
> >To Repro:
> >In the Finder, drop a haskell source file on the "Hugs 98" application.
> >Results:
> >Hugs 98 launches, but doesn't read source file.
> ...
> >The worked OK in previous versions of Hugs 98 (although you couldn't drop
> >source files on an already-running app).
>
> The explanation of these problems is this:
>
> The first joint version I and Pablo MacOS made, happened at right the time
> MPJ wrote the last version and then left the Hugs team. So because of that,
> the MacOS modification where never written into that version.
>
> Nor has the subsequent Hugs team ever written in those or any later MacOS
> versions into the Hugs sources. So what you have in those sources are some
> very old MacOS stuff.
>
> Now, it seems, somebody at the Hugs team (Johan?) has tacitly assumed that
> these old Mac modifications are OK, and compiled it. But then most of the
> later stuff breaks.
So the real story is actually this:
The MacOS specifics in the Hugs Feb2001 version are actually quite new; they are
directly taken from the latest version I got from Hans in December last year.
However, for reasons I'll return to below, many aspects and features of that
version didn't make it into the distribution. This explains the lack of
drag-and-drop launching. The font size problem Richard O'Keefe reports is
however a mystery to me, I'll have to pass on this one for the moment since I'm
not able to recreate the bug.
My main objectives as the Hugs maintainer have been fixing bugs and
incorporating interesting enhancements, while at the same time making sure that
the source base stays maintainable. These objectives aren't always compatible,
and in the Mac Hugs case this essentially means the following:
- The meat of the Mac additions have previously been provided as a separate
source distribution, with a stucture totally different from the main sources.
I've only merged in things that could be transferred to the main repository
without too much effort.
- The AppleEvent handling in Hans' and Pablo's version is indeed interesting,
but it introduces asynchronous concurrency into the interpreter itself,
something which it just isn't built to handle. This is of course unacceptable
for a software package that aims at being stable across multiple platforms,
and the AppleEvent support was therefore edited out. Unfortunately, this also
took away the drag-and-drop facility, which is something that definitely could
be implemented in a safe way. I just simply didn't have time to do that for
the Feb release.
- The Mac sources I was given also contained some stack space management
enhancements which I didn't understand, and which also made the interpreter
crash on a program that ran just fine on the Feb 2000 version of Hugs.
They were hence removed.
- The Mac sources also contained a complete redistribution of MetroWerks'
SIOUX sources, for no apparent reason. If some enhancements were buried
in there somewhere they are now lost as well, since I didn't want to
include code in the distribution that might clash with a standard MacOS
C library. Furthermore, the reliance on a binary-only version of a
library called AEGizmos(modified) is obviously not optimal from a
maintainability point of view, so all such dependencies are also gone.
So this leaves us with a Feb 2001 Hugs that provides what could be called just
basic MacOS support. On the othere hand, the MacOS support that's there is now
fully integrated into the main Hugs source tree. I can see the following ways
forward from the current state:
- Someone (Hans? Pablo? me?) implements the basic AppleEvent handling that's
needed to get back the drag-and-drop functionality. This code should
preferably be self-contained, and should be put in the machugs directory.
Ideally it should continue to respond after hugsmain() has been called,
but only if the Open events can be made to appear as ordinary :load
commands to the intepreter.
- AppleEvent handling on the Haskell level (i.e., Events.hs et. al.) could
preferably be provided by Hans and Pablo as a standalone library that's
only implemented on the Mac (just like the Win32 Graphics lib, although
it has been ported to X-windows as well). However, I must strongly suggest
that whoever undertakes this task will take the time to ensure proper
integration with the Hugs' sequential execution machine. I think Alastair
Reid can be a good source of information on how this is achieved.
- Any other enhacements or suggestions are gratefully received; just bear in
mind that diffs must be relative the Feb 2001 source base in order to
be considered. Together with the other Hugs authors I will also continue to
issue some form of "editor's discretion" when it comes to deciding what the
distributed version of Hugs should look like.
By the way, a new release of Hugs will most likely be put out some time this
spring, to catch up with some bug fixes that have recently been made. So this
is definitely a good time to raise your voice about bugs or features that you
think are missing.
I'll return to the font size problem in an upcoming posting.
All the best,
Johan
From haberg@matematik.su.se Wed Feb 28 21:43:43 2001
Date: Wed, 28 Feb 2001 22:43:43 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Feb2001 hugs98 on MacOS
At 11:58 -0800 2001/02/28, Johan Nordlander wrote:
>The MacOS specifics in the Hugs Feb2001 version are actually quite new;
>they are
>directly taken from the latest version I got from Hans in December last year.
>However, for reasons I'll return to below, many aspects and features of that
>version didn't make it into the distribution. This explains the lack of
>drag-and-drop launching. The font size problem Richard O'Keefe reports is
>however a mystery to me, I'll have to pass on this one for the moment
>since I'm
>not able to recreate the bug.
>
>My main objectives as the Hugs maintainer have been fixing bugs and
>incorporating interesting enhancements, while at the same time making sure
>that
>the source base stays maintainable. These objectives aren't always
>compatible,
>and in the Mac Hugs case this essentially means the following:
>
>- The meat of the Mac additions have previously been provided as a separate
> source distribution, with a stucture totally different from the main
>sources.
> I've only merged in things that could be transferred to the main repository
> without too much effort.
Well, I gave the explanation why: The Hugs team has never before bothered
paying any attention to it at all after MPJ left. You seems to be the first
one. :-)
>- The AppleEvent handling in Hans' and Pablo's version is indeed interesting,
> but it introduces asynchronous concurrency into the interpreter itself,
> something which it just isn't built to handle.
Well, it is not complete asynchronous concurrency, because it stacked, not
separate threads. But you are right, there is a potential for breaks if a
program is executing and global data somehow is shared. (See below for a
possible fix.)
On the other hand, one thing that makes MacOS unique is the presence of
high-level events. And the code is safe if no AppleEvent's are received, or
some unfortunate circumstances described above do not happen.
Anyway, that is what I have on my computer, and I do not have the option
stripping it out. -- Maintaining more than one version is a bother, and I
think that high level events (interprogram communications) and Haskell have
a potential together.
> This is of course unacceptable
> for a software package that aims at being stable across multiple platforms,
> and the AppleEvent support was therefore edited out.
So the stability problems are not all that bad, I think. -- A more prudent
move would be to leave it in, and see if people experience problems. (also
see below for a possible fix.)
After all, there might arrive a thread safe successor to Hugs, GHCi, and
then this input with AppleEvent's experience will be important. -- The
thing is that AppleEvent's are awfully complicated, so you will not find
somebody willing to start working on the topic if the code is stripped out.
> Unfortunately, this also
> took away the drag-and-drop facility, which is something that definitely
>could
> be implemented in a safe way. I just simply didn't have time to do that
>for
> the Feb release.
So the DropUNIX package was eliminated, and AppleEvent's was implemented
from scratch.
>- The Mac sources I was given also contained some stack space management
> enhancements which I didn't understand, and which also made the interpreter
> crash on a program that ran just fine on the Feb 2000 version of Hugs.
> They were hence removed.
Well, the stack check makes sure that Hugs does not bomb due to stack
overflow, so perhaps the problem is elsewhere. -- Perhaps you din't
implement all components correctly in your editing.
Also note that the stack check is not perfect: If you have stripped out the
STACK_CHECK from some recursively functions, or introduced more such
functions, Hugs may still bomb.
But the problem does not become better with the stack check out, it
increases the hazards. -- Without the stack check, the stack will merely
write into the heap until the program or probably the whole computer bombs.
>- The Mac sources also contained a complete redistribution of MetroWerks'
> SIOUX sources, for no apparent reason. If some enhancements were buried
> in there somewhere they are now lost as well, since I didn't want to
> include code in the distribution that might clash with a standard MacOS
> C library. Furthermore, the reliance on a binary-only version of a
> library called AEGizmos(modified) is obviously not optimal from a
> maintainability point of view, so all such dependencies are also gone.
No, all the altered SIOUX sources (the console package) have new names.
However, Metrowerks has substantially altered the SIOUX package CW Pro 5 ->
6, so the complete set of sources will (or may) be needed if one switches
to CW Pro 6.
There is one guy using CW 6 & MacHugs, which is why the stuff is included.
The next step would be to write a whole new GUI, but it is probably better
waiting for MacOS X. -- And I do not have time for that, so let's hear from
any interested candidates.
>So this leaves us with a Feb 2001 Hugs that provides what could be called just
>basic MacOS support.
You actually succeeded in stripping out nearly all the features that makes
the MacOS GUI convenient I think. :-)
> On the othere hand, the MacOS support that's there is now
>fully integrated into the main Hugs source tree.
I hope you will repeat it with the stuff I just sent you: It is the
modified Feb 2001 sources, so you do not have to check what it is doing.
> I can see the following ways
>forward from the current state:
>
>- Someone (Hans? Pablo? me?) implements the basic AppleEvent handling that's
> needed to get back the drag-and-drop functionality. This code should
> preferably be self-contained, and should be put in the machugs directory.
Well, that is the point of integrating the stuff I have sent you:
While the Hugs team somehow did not implement the changes, I started making
the MacOS code & the Hugs kernel source as orthogonal as possible. --
Incidentally, this includes moving out the code that you once wrote from
the Hugs kernel. :-)
> Ideally it should continue to respond after hugsmain() has been called,
> but only if the Open events can be made to appear as ordinary :load
> commands to the intepreter.
Well, this is the behavior of the stuff I sent you. -- Somehow you
succeeded to strip that out.
Specifically, if I recall the details right, if one drops a file onto the
Hugs icon while it is executing, it should {Interrupt} what is executed,
and then :l(oad) the new files.
-- The very point of stripping out the DropUNIX package and implement
AppleEvent's from scratch is to make such thing possible. Once this has
been done, it is not difficult to implement new AppleEvent's features. --
All that is needed someone interested having the time to do it.
And if people experience problems with the receiving of AppleEvent's while
executing, one can always throw in an {Interrupt} to make it safe.
>- AppleEvent handling on the Haskell level (i.e., Events.hs et. al.) could
> preferably be provided by Hans and Pablo as a standalone library that's
> only implemented on the Mac (just like the Win32 Graphics lib, although
> it has been ported to X-windows as well).
Well, the reason it is hard coded was that the Hugs foreign interface was
to primitive.
> However, I must strongly suggest
> that whoever undertakes this task will take the time to ensure proper
> integration with the Hugs' sequential execution machine.
You know, this is not really possible without rebuilding the Hugs kernel
from scratch to be concurrent.
Better to hope that GHCi will be concurrent, and then move the AppleEvent's
code to that version when it becomes available.
> I think Alastair
> Reid can be a good source of information on how this is achieved.
The current implementation was chosen after discussions with Alastair Reid.
It would be simpler for some of the fellows on the current Hugs kernel
development team to: First put in the Mac modifications, and then ask
themselves, "what does this mean for the Hugs kernel".
The modifications needed are not dramatic for a foreign interface: I needed
to be able to convert between lazy and strict strings, and to be able to
implement four new primitives.
One can implement such stuff as a DLL (except that loading plugins under
pre-MacOS X is complicated), but given what was needed it would have been
overkill.
>- Any other enhacements or suggestions are gratefully received; just bear in
> mind that diffs must be relative the Feb 2001 source base in order to
> be considered. Together with the other Hugs authors I will also continue to
> issue some form of "editor's discretion" when it comes to deciding what the
> distributed version of Hugs should look like.
Please do not forget to put up the name of the guy who made the version
(not me, because I may get email about stuff I do not know anything about)
in case you make an independent version :-). Also, it should probably have
a different MacOS creator code, in order to not confuse the MacOS in case
someone uses both versions, and a new icon. I doubt that anybody is running
the "Basic Hugs" in our distribution, so you can take over that one if you
so want. (Its creator code is then registered with Apple, so you do not
have to do it.)
Hans Aberg
From reid@cs.utah.edu Wed Feb 28 22:35:05 2001
Date: Wed, 28 Feb 2001 15:35:05 -0700
From: Alastair Reid reid@cs.utah.edu
Subject: Feb2001 hugs98 on MacOS
> - AppleEvent handling on the Haskell level (i.e., Events.hs et. al.) could
> preferably be provided by Hans and Pablo as a standalone library that's
> only implemented on the Mac (just like the Win32 Graphics lib, although
> it has been ported to X-windows as well). However, I must strongly suggest
> that whoever undertakes this task will take the time to ensure proper
> integration with the Hugs' sequential execution machine. I think Alastair
> Reid can be a good source of information on how this is achieved.
One way of handling events would be to replace the Hugs evaluator with one that
supports preemptive concurrency. This would be a fairly major undertaking and
is perhaps best based on the STG-Hugs base. Since I'm not aware of any effort
to do this and because it's not exactly a Sunday afternoon project, I'll ignore
it in the following.
In the absence of preemptive threads, the standard ways of handling events for
X11 and Win32 are either:
1) Use an event queue to store events which have been delivered to the
application. The application should be written so that it regularily processes
events waiting in the queue. This can be done either using the usual
inside-out event-loop structure found in most X and Windows apps or, if you use
Hugs' cooperative threading can be given a more normal structure (as in the
Hugs Graphics Library).
This approach was popular in the early days (1993 or thereabouts) before ccall,
greencard, the ffi, etc. made it easy to use the second option. The big
problem with this approach is that you can't handle "synchronous events" which
require an immediate response. For example, Win32 has a number of events for
querying the application - things like asking for a preferred window size.
OTOH, it works great with X11 which is based on an asynchronous event model.
2) Events cause direct calls into Haskell code. (It's pretty easy to do this
nowadays using the foreign export dynamic feature of the ffi.) The only trick
here is that, because Hugs doesn't support preemption, events must only be
delivered at certain safe points. For example, the program might contain a
main loop which queries for events, dispatches a call into Haskell code to
handle the event and then returns the result of the event handler to the C
world. Or, if events appear as asynchronous calls into a C thread, the Haskell
program might run with events disabled in most of the code and only enable them
by calling into a C function which enables events, waits for the program to
complete (during which time it is handling events, of course), and then
disables events again.
Again, the library programmer has the choice of exposing this programming model
to the user or of constructing a layer which hides the event dispatch mechanism
from the programmer (as in the Hugs Graphics Library).
This is the approach taken in the Win32 version of the Hugs graphics library,
in my Budgets paper (an Openlook-based implementation of Fudgets) and in most
other GUI's that I know of.
I'm yet to hear of a reason why AppleEvents cannot be dealt with using one of
these approaches (i.e., without requiring substantial internal changes to
Hugs).
--
Alastair Reid
From reid@cs.utah.edu Wed Feb 28 22:47:20 2001
Date: Wed, 28 Feb 2001 15:47:20 -0700
From: Alastair Reid reid@cs.utah.edu
Subject: Feb2001 hugs98 on MacOS
> - Any other enhacements or suggestions are gratefully received; just bear in
> mind that diffs must be relative the Feb 2001 source base in order to
> be considered. Together with the other Hugs authors I will also continue
to
> issue some form of "editor's discretion" when it comes to deciding what the
> distributed version of Hugs should look like.
Some advice to people submitting changes:
Back in the days when I was maintaining Hugs, changes were substantially more
likely to be merged into the main base if they were decomposed into a number of
small, independent changes whose impact and consequences could be understood in
isolation from the other changes.
For example, Hans' stack overflow changes sound like a feature that all Hugs
users could benefit from (i.e., not just MacOS users) but it really needs to be
submitted as a separate set of patches if Johan is to correctly integrate them
and if various individuals around the world are to submit modifications which
make the stack overflow code work on other platforms (Sparcs, x86s, etc.)
--
Alastair Reid
From nordland@cse.ogi.edu Wed Feb 28 23:56:56 2001
Date: Wed, 28 Feb 2001 15:56:56 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: Feb2001 hugs98 on MacOS
Hans,
With all due respect, but here's some reasons why the previous Hugs maintainers
might have been reluctant to let your variant of Hugs into the main source tree:
it's big, it's unstructured, it's a mix of various unrelated features, and it
carries some serious implications to the overall program reliability that I know
no maintainer would accept (read unsafe asynchrony). At the same time it
contains some features that are really nifty under MacOS, for example
drag-and-drop support.
We now have basic MacOS support included in the distribution. What I'm offering
you and anybody else interested is to submit extension proposals, one at a time,
and I'll add them to the main sources if they seem to be useful, well-written,
and free of unwanted side-effects. I'm not interested in buying a whole
package. And if I'm to spend time understanding/fixing (say) a stack-checking
extension, I'd rather do that if it would benefit all Hugs users, not just those
who run the Mac version. The same holds for profiling.
So please see if you can find the time to break down your additions into more
manageable units, that are based on the Feb 2001 sources. I'll seriously
consider each one of them. In their absence I'll probably try to add some
simple drag-and-drop support, but not much more.
All the best,
Johan