Nabble - Haskell - Hugs-Bugs

#86: some record updates reported as ambiguous

2008-10-07T15:28:57Z

#86: some record updates reported as ambiguous
--------------------+-------------------------------------------------------
Reporter: ross | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone:
Component: hugs | Version: 200609
Keywords: |
--------------------+-------------------------------------------------------
Given
{{{
data Foo = Bar { fld :: IO [String] }

g _ = id undefined { fld = e }
where e = return []
}}}
Hugs reports that {{{g}}} has the ambiguous type {{{Monad a => b ->
Foo}}}.

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/86>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: #85: Force Cabal use in-place Hugs when buiding from source

2008-10-03T07:03:48Z

#85: Force Cabal use in-place Hugs when buiding from source
---------------------+------------------------------------------------------
Reporter: guest | Owner: nobody
Type: defect | Status: closed
Priority: major | Milestone:
Component: hugs | Version: current
Resolution: fixed | Keywords:
---------------------+------------------------------------------------------
Changes (by ross):

* status: new => closed
* resolution: => fixed

Comment:

applied, thanks.

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/85#comment:2>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: #85: Force Cabal use in-place Hugs when buiding from source

2008-10-03T03:24:53Z

#85: Force Cabal use in-place Hugs when buiding from source
---------------------+------------------------------------------------------
Reporter: guest | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone:
Component: hugs | Version: current
Resolution: | Keywords:
---------------------+------------------------------------------------------
Comment (by guest):

This ticket has been submitted by Dmitry Golubovsky

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/85#comment:1>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

#85: Force Cabal use in-place Hugs when buiding from source

2008-10-03T03:22:41Z

#85: Force Cabal use in-place Hugs when buiding from source
--------------------+-------------------------------------------------------
Reporter: guest | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone:
Component: hugs | Version: current
Keywords: |
--------------------+-------------------------------------------------------
I have been experimenting with building Hugs from a source tarball on
a computer with no Haskell stuff preinstalled at all.

I noticed that the build fails when running Setup configure for any
package because Cabal cannot find Hugs executable.

OTOH, if there is Hugs installed earlier (on the PATH), output from
Setup configure shows that the previously installed Hugs is used, not
one just built.

This can be easily fixed if proper --with-hugs command line argument
is provided to Setup. This affects two files: libraries/Makefile.in
and libraries/tools/convert_libraries.

Also, if any package installed has configure script invoking runhugs,
this would fail too because in-place runhugs is not on the path. This
is fixed by exporting proper PATH variable from the convert_libraries
script before running Setup configure.

Proposed patch is attached.

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/85>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: #84: Unnecessary "Control stack overflow"

2008-10-02T17:03:36Z

#84: Unnecessary "Control stack overflow"
---------------------+------------------------------------------------------
Reporter: guest | Owner: nobody
Type: defect | Status: closed
Priority: major | Milestone:
Component: hugs | Version: 200609
Resolution: fixed | Keywords: Exception handling
---------------------+------------------------------------------------------
Changes (by ross):

* status: new => closed
* resolution: => fixed

Comment:

Patch applied, thanks.

If exceptions were treated as special normal forms, we'd have to test for
them all over the evaluation logic.

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/84#comment:1>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

#84: Unnecessary "Control stack overflow"

2008-10-02T02:15:24Z

#84: Unnecessary "Control stack overflow"
--------------------------------+-------------------------------------------
Reporter: guest | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone:
Component: hugs | Version: 200609
Keywords: Exception handling |
--------------------------------+-------------------------------------------
I am not terribly familiar with the Hugs source code, but I believe I have
found a bug relating to the interaction between the global variable
`evalDepth` in `machine.c` and the implementation of exception handling.

It seems that `evalDepth` is used to keep track of the recursion depth of
the `eval` function; the first thing `eval` does is increment `evalDepth`
and the last thing it does is decrement it. If `evalDepth` ever gets too
large, Hugs generates a "`Control stack overflow`".

Now consider the function `evalWithNoError` (defined in `machine.c`),
which is called by the primitive `primCatchException` to evaluate an
expression which might cause an exception.

{{{
Cell evalWithNoError(e) /* Evaluate expression, returning
*/
Cell e; { /* NIL if successful, */
Cell caughtEx; /* Exception value if not... */
jmp_buf *oldCatch = evalError;

jmp_buf catcherr[1];
evalError = catcherr;
if (setjmp(catcherr[0])==0) {
eval(e);
caughtEx = NIL;
}
else {
caughtEx = exception;
}

evalError = oldCatch;
return caughtEx;
}
}}}

Notice that `setjmp` is called to save the state; if `eval` happens to
invoke the primitive `throwException` (which calls longjmp) then the
second branch of the of the conditional is taken, and an exception is
returned. The problem is that in such a situation, by calling longjmp,
the `eval` function exits WITHOUT decrementing `evalDepth`. As far as I
can tell, setjmp/longjmp does not save/restore `evalDepth`. The result is
that Hugs often generates "`Control stack overflow`" when evaluating
expressions that throw and catch lots of exceptions. I've attached an
example of such a program -- this program causes no problems at all when
run using GHC.

By manually saving the `evalDepth` before calling `setjmp` and restoring
it when `longjmp` is called, the problem can be fixed. Here is the new
definition of `evalWithNoError`.

{{{
Cell evalWithNoError(e) /* Evaluate expression, returning
*/
Cell e; { /* NIL if successful, */
Cell caughtEx; /* Exception value if not... */
jmp_buf *oldCatch = evalError;
int oldEvalDepth; /* ADDED BY ME */
oldEvalDepth = evalDepth; /* ADDED BY ME */

jmp_buf catcherr[1];
evalError = catcherr;
if (setjmp(catcherr[0])==0) {
eval(e);
caughtEx = NIL;
}
else {
evalDepth = oldEvalDepth; /* ADDED BY ME */
caughtEx = exception;
}

evalError = oldCatch;
return caughtEx;
}
}}}

Of course, I do not know if this is a genuine fix or a broken hack. In
particular, I worry about other side-effects of `eval` that are not undone
when an exception is caught. It is not obvious to me why setjmp and
longjmp are required at all --- why not model an exception as a normal-
form and simply inspect it after an `eval`?

Is there a regression test-suite that I can try --- to gain confidence
that the proposed fix does not break anything?

Matthew Naylor (`mfn@...`).

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/84>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: elem of infinite set of tuple

2008-05-16T02:46:26Z

Hi

This is not the right emailing list for this - its not a bug in Hugs,
just the way Haskell works. I recommend you resend this email to
haskell-cafe -AT- haskell.org - that is a more general list and people
will be happy to help, plus you'll reach a much bigger audience.

Alternatively, hop on to IRC: http://www.haskell.org/haskellwiki/IRC_channel

There people will be happy to answer your questions in real time :)

Thanks

Neil

> I don't know how Haskell should behave on this. Consider this function:
> elemOf (x,y) = (x,y) `elem` [ (a,b) | a <- [0..], b <- [0..] ]
>
> If I try to query elemOf (1,1), the interpreter keeps searching and
> searching but it never makes it. But if I query elemOf (0,1) (or anything as
> long as the first element is 0), it can find it easily. I wonder how Hugs
> handles this.
>
> >From my point of view, instead of starting from (1,0), Hugs starts from
> (0,0), which will never finish since the limit of the second element is
> infinite.
>
> --
> View this message in context: http://www.nabble.com/elem-of-infinite-set-of-tuple-tp17268995p17268995.html
> Sent from the Haskell - Hugs-Bugs mailing list archive at Nabble.com.
>
> _______________________________________________
> Hugs-Bugs mailing list
> Hugs-Bugs@...
> http://www.haskell.org/mailman/listinfo/hugs-bugs
>

_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

elem of infinite set of tuple

2008-05-16T00:24:16Z

I don't know how Haskell should behave on this. Consider this function:
elemOf (x,y) = (x,y) `elem` [ (a,b) | a <- [0..], b <- [0..] ]

If I try to query elemOf (1,1), the interpreter keeps searching and searching but it never makes it. But if I query elemOf (0,1) (or anything as long as the first element is 0), it can find it easily. I wonder how Hugs handles this.

From my point of view, instead of starting from (1,0), Hugs starts from (0,0), which will never finish since the limit of the second element is infinite.

Re: Hugs doesn't know List Difference operator (\\)

2008-05-14T04:44:16Z

On 2008 May 14 Wednesday, leledumbo wrote:
> I'm reading some Haskell Tutorial when I arrive at List Difference
> operator, which is \\. But when I try on Hugs, it responded: ERROR -
> Undefined variable "\\"

Add 'import List' to your program.

Or if you're running the Hugs interpreter with no program, do
Hugs> :l List

_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Hugs doesn't know List Difference operator (\\)

2008-05-14T04:30:36Z

I'm reading some Haskell Tutorial when I arrive at List Difference operator, which is \\. But when I try on Hugs, it responded: ERROR - Undefined variable "\\"

Re: [Haskell-cafe] Bug in Hugs, Haskell behavior question

2008-04-04T20:15:48Z

Derek: yes, I caught this in the language description not long after hitting "send": I had forgotten about that.

But then I anticipated the behavior Ryan shows below, where using a variable that's part of a "strange" pattern will cause an error (I didn't want to check it while driving home--cell phone user/drivers are bad enough!--so thanks, Ryan, for verifying :) ).

In any case, opinions about the behavior aside, there is a Hugs internal error here, so I hope that much is useful.

The strange cases make for interesting academic discussions, at least.

-- Fritz

On Fri 4 Apr 08, at 6:49 pm, Derek Elkins wrote:

Top-level bindings are irrefutable, so 2 = 3 is fine, if vacuous.

On Fri 4 Apr 08, at 6:53 pm, Ryan Ingram wrote:

On 4/4/08, Fritz Ruehr <fruehr@...> wrote:

In fact, even this goes through without a hitch!

2 = 3

This is hilarious.

Maybe bindings that don't actually bind anything should be an error?
Or at least a warning?

In ghci:

Prelude> let 2 = 3
-- no problem
Prelude> let (2,x) = (3,4)
-- no problem
Prelude> x
*** Exception: <interactive>:1:4-16: Irrefutable pattern match failed
for pattern (2,x)

-- ryan

_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Bug in Hugs, Haskell behavior question

2008-04-04T18:34:12Z

In lab the other day I was showing pattern bindings to a student and
broached a limiting case, one with no variables to be bound in the
pattern. I was surprised to find that Hugs crashed when I tried a
pattern binding at top level like this:

(2,[1,4],5) = (2,[1,4],5)

It also crashed on the simpler:

[2] = [2]

On the other hand, this turns out to be acceptable:

2 = 2

In fact, even this goes through without a hitch!

2 = 3

I'm not sure from the language definition yet whether this last
should give an "Unmatched pattern" error, but if it's intended
behavior, it does look a little odd.

Would anyone care to argue for or against allowing this?

In any case, the more structured patterns cause the latest (Sep 06)
Hugs release to crash, with "INTERNAL ERROR: compileGlobalFunction".

(GHC allows the strange "2 = 3" and handles the structured ones fine,
including even "(1,[2,3],4) = (4,[3,37],42)". I haven't checked any
other compilers.)

-- Fritz
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

#83: INTERNAL ERROR: findBtyvsInt

2008-03-30T16:06:32Z

#83: INTERNAL ERROR: findBtyvsInt
--------------------+-------------------------------------------------------
Reporter: guest | Owner: nobody
Type: defect | Status: new
Priority: minor | Milestone:
Component: hugs | Version: 200609
Keywords: |
--------------------+-------------------------------------------------------
{{{
% hugs -98
__ __ __ __ ____ ___ _________________________________________
|| || || || || || ||__ Hugs 98: Based on the Haskell 98 standard
||___|| ||__|| ||__|| __|| Copyright (c) 1994-2005
||---|| ___|| World Wide Web: http://haskell.org/hugs
|| || Bugs: http://hackage.haskell.org/trac/hugs
|| || Version: September 2006 _________________________________________

Hugs mode: Restart with command line option +98 for Haskell 98 mode

Type :? for help
Hugs> case 0 of (_ :: d) -> case 0 of (_ :: e) -> undefined :: d
INTERNAL ERROR: findBtyvsInt
Please report this Hugs bug to http://hackage.haskell.org/trac/hugs
Hugs>
}}}
{{{
% uname -a
FreeBSD glider 7.0-STABLE FreeBSD 7.0-STABLE #1: Sun Mar 16 05:28:34 PDT
2008 root@:/usr/obj/usr/src/sys/GENERIC i386
}}}

I ran into this at random, so it's not a problem for me, but I thought I'd
report it anyway.

James Cook
http://www.falsifian.org/
james.cook@...

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/83>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: 1.0 / 0.0 is not infinite

2008-03-30T07:43:26Z

Hi Henk,

> Hugs> isInfinite $ 1.0 / 0.0
> False

If you look at the library code it isn't entirely surprising:

instance RealFloat Float where
isNaN _ = False
isInfinite _ = False
isDenormalized _ = False
isNegativeZero _ = False
isIEEE _ = False

I guess the fix is to use your version in the isInfinite part. Some of
the others might want fleshing out too. I'm not sure if this is a
Windows only issue, or just a general Hugs thing.

Thanks

Neil
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

1.0 / 0.0 is not infinite

2008-03-29T15:17:38Z

I tried:
Hugs> 1.0 / 0.0
1.#INF

Hugs> isInfinite $ 1.0 / 0.0
False
in WinHugs (Version: Sep 2006)

When the same is entered in GHCi, the result is True, as expected.

The definition of isInfinite in Prelude is:
isInfinite _ = False

An better definition could be as in the following:
Hugs> let isInfinite' x = x == (1.0 / 0.0) in isInfinite' (3.1416 / 0.0)
True

--
Met vriendelijke groet,
Henk-Jan van Tuyl

--
http://functor.bamikanarie.com
http://Van.Tuyl.eu/
--

_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: Gofer 2.30a binary executable won't run on Windows XP Professional Service Pack 2

2008-02-27T04:44:36Z

Hi Benjamin,

Gofer is kind of dead, I'd recommend instead installing WinHugs, and
following one of the many Haskell tutorials out there.

Thanks

Neil

On Wed, Feb 27, 2008 at 12:39 PM, Benjamin L. Russell
<dekudekuplex@...> wrote:

> Since "HUGS" stands for "Haskell User's Gofer System"
> (see
> http://www.websters-dictionary-online.org/definition/Hugs
> for a reference), and HUGS is a later version of
> Gofer, I am sending this inquiry about a problem in
> installing Gofer to this mailing list.
>
> I managed to
> get Gofer 2.28 (see "some haskell FAQ info (occasional
> posting, long"
> (http://www.cse.unsw.edu.au/~dons/haskell-1990-2006/msg00936.html)
> for download information) installed on Windows XP
> Professional
> Service Pack 2, but when I downloaded Gofer 2.30a and
> tried to run bcgofer.exe (either by executing it from
> the Command Prompt, or by double-clicking it in the
> GUI) (there is no GOFER.EXE file in that version), the
> program quit immediately. The same thing happened
> when I tried to run bcgofc.exe.
>
> I was unable to follow instructions in the README.PC
> file for Gofer 2.30a because that file refers to a
> non-existent "GOFER.EXE" file. How can I move a file
> that doesn't exist to the C:\Gofer directory? The
> bundled documentation for Gofer 2.30a seems outdated.
>
> In addition, I tried installing the binary executables
> in 386gofer, but with the same results as with Gofer
> 2.30a; i.e., when I tried to invoke GOFER.EXE, a
> Command Prompt window appeared for a fraction of a
> second, then disappeared.
>
> The user and system environmental variables are both
> set correctly; viz:
>
> EDITLINE: C:\bin\emacs\bin\runemacs.exe +%d %s
> EDITOR: C:\bin\emacs\bin\runemacs.exe
> GO32: emu c:\DJGPP\EMU387\emu387
> GO32TMP: C:\TMP
> GOPHER: C:\GOFER\standard.prelude
> Path: C:\Gofer;<existing path>
>
> I was able to get Gofer 2.28 to run without needing to
> compile anything. Do I need to compile something to
> run Gofer 2.30a?
>
> It seems strange that I can get Gofer 2.28 to work,
> but not Gofer 2.30; what could be wrong?
>
> I am currently reading the paper "Functional
> Programming," by Jeroen Fokker and the Department of
> Computer Science of Utrecht University
> (http://people.cs.uu.nl/jeroen/courses/fp-eng.pdf),
> which uses Gofer. If you could please tell me what I
> need to do to get Gofer 2.30a to work properly, I
> would appreciate it very much.
>
> Benjamin L. Russell
> _______________________________________________
> Hugs-Bugs mailing list
> Hugs-Bugs@...
> http://www.haskell.org/mailman/listinfo/hugs-bugs
>

_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Gofer 2.30a binary executable won't run on Windows XP Professional Service Pack 2

2008-02-27T04:39:11Z

Since "HUGS" stands for "Haskell User's Gofer System"
(see
http://www.websters-dictionary-online.org/definition/Hugs
for a reference), and HUGS is a later version of
Gofer, I am sending this inquiry about a problem in
installing Gofer to this mailing list.

I managed to
get Gofer 2.28 (see "some haskell FAQ info (occasional
posting, long"
(http://www.cse.unsw.edu.au/~dons/haskell-1990-2006/msg00936.html)
for download information) installed on Windows XP
Professional
Service Pack 2, but when I downloaded Gofer 2.30a and
tried to run bcgofer.exe (either by executing it from
the Command Prompt, or by double-clicking it in the
GUI) (there is no GOFER.EXE file in that version), the
program quit immediately. The same thing happened
when I tried to run bcgofc.exe.

I was unable to follow instructions in the README.PC
file for Gofer 2.30a because that file refers to a
non-existent "GOFER.EXE" file. How can I move a file
that doesn't exist to the C:\Gofer directory? The
bundled documentation for Gofer 2.30a seems outdated.

In addition, I tried installing the binary executables
in 386gofer, but with the same results as with Gofer
2.30a; i.e., when I tried to invoke GOFER.EXE, a
Command Prompt window appeared for a fraction of a
second, then disappeared.

The user and system environmental variables are both
set correctly; viz:

EDITLINE: C:\bin\emacs\bin\runemacs.exe +%d %s
EDITOR: C:\bin\emacs\bin\runemacs.exe
GO32: emu c:\DJGPP\EMU387\emu387
GO32TMP: C:\TMP
GOPHER: C:\GOFER\standard.prelude
Path: C:\Gofer;<existing path>

I was able to get Gofer 2.28 to run without needing to
compile anything. Do I need to compile something to
run Gofer 2.30a?

It seems strange that I can get Gofer 2.28 to work,
but not Gofer 2.30; what could be wrong?

I am currently reading the paper "Functional
Programming," by Jeroen Fokker and the Department of
Computer Science of Utrecht University
(http://people.cs.uu.nl/jeroen/courses/fp-eng.pdf),
which uses Gofer. If you could please tell me what I
need to do to get Gofer 2.30a to work properly, I
would appreciate it very much.

Benjamin L. Russell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: #82: Not a Number

2008-02-08T05:10:53Z

#82: Not a Number
----------------------+-----------------------------------------------------
Reporter: guest | Owner: nobody
Type: defect | Status: closed
Priority: minor | Milestone:
Component: hugs | Version: 200609
Resolution: invalid | Keywords:
----------------------+-----------------------------------------------------
Changes (by ross):

* status: new => closed
* resolution: => invalid

Comment:

That is to be expected: factorial 35 is to big to fit in a Float. You'd
get up to 170 if you used Double instead (and old versions of Hugs used
the C double type internally for both types). But a better approach would
be to use another scanl to build the terms of the series incrementally as
Floats or Doubles, before the scanl you're using to get partial sums.

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/82#comment:1>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

#82: Not a Number

2008-02-08T04:52:47Z

#82: Not a Number
--------------------+-------------------------------------------------------
Reporter: guest | Owner: nobody
Type: defect | Status: new
Priority: minor | Milestone:
Component: hugs | Version: 200609
Keywords: |
--------------------+-------------------------------------------------------
My Program was:

{{{
cosineSeries :: Float -> [Float]
cosineSeries x = scanl (cosineSerPartSum x) 1 [1..]

cosineSerPartSum :: Float -> Float -> Integer -> Float
cosineSerPartSum x prev i = prev + ((-1) ^ i) * (x ^ (2 * i)) /
fromIntegral (fak (2 * i))

fak :: Integer -> Integer
fak n = product [1..n]
}}}

My Study Mate is running WinHugs and when he types "cosineSeries 2" he
gets many Numbers....
I am Running hugs98 on a Mac. Im getting something like this:

Main> cosineSeries 2
[1.0,-1.0,-0.3333333,-0.4222222,-0.415873,-0.4161552,-0.4161466,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,-0.4161468,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,çnan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,^C{Interrupted!}

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/82>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Less defaulting with -98

2008-01-13T17:41:20Z

Hi

$ hugs -98
Hugs> []
ERROR - Cannot find "show" function for:
*** Expression : []
*** Of type : [a]

$hugs +98
Hugs> []
[]

It seems that with -98 you don't get the very handy defaulting. Is
this a delibarate decision, or is it just a bug?

Thanks

Neil
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: #44: Hugs does not provide version numbers for installed packages

2008-01-10T13:37:39Z

#44: Hugs does not provide version numbers for installed packages
--------------------------+-------------------------------------------------
Reporter: briansmith | Owner: nobody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: hugs | Version: 200609
Resolution: | Keywords:
--------------------------+-------------------------------------------------
Changes (by guest):

* cc: duncan@... (added)

Comment:

Replying to [comment:2 ross]:

> On the other hand, !InstalledPackageInfo is somewhat GHC-specific, so
perhaps it would be better in both cases to just put in the package
description, augmented with any buildinfo generated by package
configuration.

Is there anything GHC-specific that would cause problems? Some fields can
simply be ignored for hugs. It'd be nice if we could get ghc, nhc and hugs
all using a collection of !InstalledPackageInfo values for the package
database.

In future Cabal will read back the whole !InstalledPackageInfo when
working with ghc so it can do module chasing. It'd be great if we could
include hugs in such a scheme too. Currently Cabal doesn't know anything
about the installed packages for hugs.

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/44#comment:5>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

#81: support --version flag

2008-01-10T13:27:43Z

#81: support --version flag
--------------------+-------------------------------------------------------
Reporter: guest | Owner: nobody
Type: defect | Status: new
Priority: minor | Milestone:
Component: hugs | Version: 200609
Keywords: |
--------------------+-------------------------------------------------------
Discovering hugs's version number is almost impossible and certainly
impractical. The result is that Cabal does not know the hugs version
number.

As far as I can see, the only way to find the version number is to start
hugs, grep the banner and translate textual months into a sensible version
number, then :q to exit hugs again. Note also that hugs considers itself
to be unversioned:

{{{
$ hugs -98 System.Info
__ __ __ __ ____ ___ _________________________________________
|| || || || || || ||__ Hugs 98: Based on the Haskell 98 standard
||___|| ||__|| ||__|| __|| Copyright (c) 1994-2005
||---|| ___|| World Wide Web: http://haskell.org/hugs
|| || Report bugs to: hugs-bugs@...
|| || Version: March 2005 _________________________________________

Hugs mode: Restart with command line option +98 for Haskell 98 mode

Type :? for help
System.Info> compilerVersion
Version {versionBranch = [0,0], versionTags = []}
System.Info>
}}}

Version 0.0 eh?

Most programs support a --version command line flag that spits out the
version number (and sometimes some other (un)helpful information) and then
terminates.

As for the format, I'd suggest:

{{{
hugs --version
Hugs version 2006.9
}}}

That is, a version number that can fit into the Data.Version format.

The reason this is important for Cabal support is that it'd allow Cabal
itself or packages (via configurations) to conditionally enable/disable
support for features depending on the version of hugs.

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/81>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: Garbage printed

2008-01-07T06:32:59Z

Hi Henk,

If you go to File / Options / Runtime / Print garbage collection
messages, you will probably find that is checked. Turn that off and
the messages should stop.

The problem with the previous text being interspersed with the
commands is probably a locking bug. I have tried to eliminate a few
locking bugs in the current HEAD version, but some may still remain. I
really don't know how the setjmp/longjmp, Windows message pump,
multiple threads, locking, timer messages etc. all communicate in
enough detail to be confident the locking is correct - its pretty
hairy!

Thanks

Neil

On 12/22/07, hjgtuyl@... <hjgtuyl@...> wrote:

>
> L.S.,
>
> I tried the following commands:
> [1..] !! 5500000
> [1..] !! 55000000
> in WinHugs; messages about garbage collection are printed. Between the GC
> messages of the second command, parts of the text of the first command are
> repeated, see the attached image.
>
> The reason, that I attached this picture, is that copy/paste to this
> posting resulted in an even bigger mess:
>
> {{Gc:8375486}}Hugs> [1..] !! 5500000
> {{Gc:8375457}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}5500001
> (126500045 reductions, 175998568 cells, 21 garbage collections)
> {{Gc:8375486}}Hugs> [1..] !! 55000000
> {{Gc:8375457}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc
> :8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:837
> 5450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}8568
> cells, 21 garbage collections)
> {{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}
> garbage collections)
> {{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}55000001
> (1265000045 reductions, 1760003519 cells, 210 garbage collections)
> {{Gc:8375486}}Hugs> [1..] !! 5500000
> {{Gc:8375457}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}5500001
> (126500045 reductions, 175998568 cells, 21 garbage collections)
> {{Gc:8375486}}Hugs> [1..] !! 55000000
> {{Gc:8375457}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc
> :8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:837
> 5450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}8568
> cells, 21 garbage collections)
> {{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}
> garbage collections)
> {{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}55000001
> (1265000045 reductions, 1760003519 cells, 210 garbage collections)
>
>
> WinHugs version: Sep 2006
> OS: Windows XP
>
>
> --
> Met vriendelijke groet,
> Henk-Jan van Tuyl
>
>
> --
> http://functor.bamikanarie.com
> http://Van.Tuyl.eu/
> --
>
> _______________________________________________
> Hugs-Bugs mailing list
> Hugs-Bugs@...
> http://www.haskell.org/mailman/listinfo/hugs-bugs
>
>
>

_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Please moderate my mail

2007-12-22T14:41:37Z

I received the following response to my previous e-mail to the Hugs-Bugs
mailing list:
Your mail to 'Hugs-Bugs' with the subject

Garbage printed

Is being held until the list moderator can review it for approval.

The reason it is being held:

Message body is too big: 610887 bytes with a limit of 10 KB

To be sure that my maling gets through, I thougt that it would be best to
send this mailing.

--
Met vriendelijke groet,
Henk-Jan van Tuyl

--
http://functor.bamikanarie.com
http://Van.Tuyl.eu/
--

_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Garbage printed

2007-12-22T14:03:20Z

L.S.,

I tried the following commands:
[1..] !! 5500000
[1..] !! 55000000
in WinHugs; messages about garbage collection are printed. Between the GC
messages of the second command, parts of the text of the first command are
repeated, see the attached image.

The reason, that I attached this picture, is that copy/paste to this
posting resulted in an even bigger mess:

{{Gc:8375486}}Hugs> [1..] !! 5500000
{{Gc:8375457}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}5500001
(126500045 reductions, 175998568 cells, 21 garbage collections)
{{Gc:8375486}}Hugs> [1..] !! 55000000
{{Gc:8375457}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc
:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:837
5450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}8568
cells, 21 garbage collections)
{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}
garbage collections)
{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}55000001
(1265000045 reductions, 1760003519 cells, 210 garbage collections)
{{Gc:8375486}}Hugs> [1..] !! 5500000
{{Gc:8375457}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}5500001
(126500045 reductions, 175998568 cells, 21 garbage collections)
{{Gc:8375486}}Hugs> [1..] !! 55000000
{{Gc:8375457}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc
:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:837
5450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}8568
cells, 21 garbage collections)
{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}
garbage collections)
{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375450}}{{Gc:8375451}}{{Gc:8375450}}{{Gc:8375450}}55000001
(1265000045 reductions, 1760003519 cells, 210 garbage collections)

WinHugs version: Sep 2006
OS: Windows XP

--
Met vriendelijke groet,
Henk-Jan van Tuyl

--
http://functor.bamikanarie.com
http://Van.Tuyl.eu/
--

_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

WinHugsSessionTR.JPG (598K) Download Attachment

Re: #42: WinHugs uninstaller crashes

2007-12-06T23:59:22Z

选择google排名可以让更多潜在客户找到您。从众多google左侧排名的客户实践看来，google排名效果非常理想。网站优化带来的效果是立竿见影的。很多客户做了google左侧排名后，就有很多的客户来电咨询google优化。都说网站优化 SEO 给他们带来了不少的生意！您现在还在为网站优化的事困扰吗？您想要全方位的SEO吗？我们为您提供全方位的google排名服务！如果您有需要网站推广搜索引擎优化请联系我们.

Re: [Hugs] #42: WinHugs uninstaller crashes

2007-12-06T23:52:40Z

同声传译同声翻译同声传译设备文件柜钢管无缝钢管无缝管论文发表台球杆更衣柜数据恢复 RAID数据恢复服务器数据恢复数据恢复

GHC-2 wrote:

#42: WinHugs uninstaller crashes
-------------------------+--------------------------------------------------
Reporter: briansmith | Owner: neil
Type: defect | Status: assigned
Priority: major | Milestone:
Component: winhugs | Version: 200609
Resolution: | Keywords:
-------------------------+--------------------------------------------------
Changes (by neil):

* status: new => assigned

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/42>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@haskell.org
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: [Hugs] #42: WinHugs uninstaller crashes

2007-12-06T23:48:04Z

这个网站很好，觉得里面有很多我们平常生活中不知道的知识，丰富了我们的生活！同声传译同声翻译同声传译设备文件柜钢管无缝钢管无缝管论文发表台球杆更衣柜数据恢复 RAID数据恢复服务器数据恢复数据恢复

Re: [Hugs] #42: WinHugs uninstaller crashes

2007-12-06T23:46:28Z

google排名网络推广台州网络公司台州网站建设台州网页设计网站优化搜索引擎优化 google排名 google排名网站优化 Google左侧排名太阳能真空管预浸布装饰设计装饰五金五金装饰装饰设计数据恢复 RAID数据恢复服务器数据恢复

Fwd: Question

2007-11-27T13:04:06Z

Hi

A user asked:

---------------------------------------------------

I installed WinHugs on a Winodw Xp machine went into settings and set
the search path to be(shown exactly as :set is listing it).

Search path : -P.;{Hugs}\packages\*;c:\haskell

I am keeping my fact.hs files(well my one and only at this time) in c:\haskell.

Hugs> :load fact.hs

ERROR - Unable to open file "fact.hs"

Hugs> :load "c:\haskell\fact.hs"

Fact>

---------------------------------------------------

I realise that that isn't expected to work (the search path appears to
be only for modules not files), but I do wonder why not. An equivalent
feature request is:

:l List -- works fine
:l List.hs -- doesn't

Thanks

Neil
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: #80: A curious stack overflow problem

2007-11-14T00:00:00Z

#80: A curious stack overflow problem
----------------------+-----------------------------------------------------
Reporter: guest | Owner: nobody
Type: defect | Status: closed
Priority: major | Milestone:
Component: hugs | Version: 200609
Resolution: invalid | Keywords:
----------------------+-----------------------------------------------------
Changes (by ross):

* status: new => closed
* resolution: => invalid

Comment:

The behaviour is standard outermost evaluation, driven by the different
properties of min and (||). The same thing happens with ghci, if you make
the first list a bit longer. (The infinite lists make no difference:
singleton lists [1] or [True] give the same effect.)

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/80#comment:1>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

#80: A curious stack overflow problem

2007-11-13T09:56:46Z

#80: A curious stack overflow problem
--------------------+-------------------------------------------------------
Reporter: guest | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone:
Component: hugs | Version: 200609
Keywords: |
--------------------+-------------------------------------------------------
Suppose I define

> natmin :: [Int] -> Int
> natmin = foldr1 min
> where min x y = if x==0 || x<=y then x else y

I would expect the same behaviour from

natmin ([1..10000] ++ [0..])

as from

or ([False | i <- [1..10000]] ++ [True | i <- [1..]])

But the first gives stack overflow, and the second doesn't.

The problem does not exist with GHCi.

Richard Bird
bird@...

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/80>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: #42: WinHugs uninstaller crashes

2007-11-01T13:19:22Z

#42: WinHugs uninstaller crashes
-------------------------+--------------------------------------------------
Reporter: briansmith | Owner: neil
Type: defect | Status: closed
Priority: major | Milestone:
Component: winhugs | Version: 200609
Resolution: duplicate | Keywords:
-------------------------+--------------------------------------------------
Comment (by guest):

Hello, I would like to know if this problem has been resolved as I too
have been having the same problem with uninstalling winhugs. Peter

Replying to [ticket:42 briansmith]:
> I will attach a screenshot of the error.
>
> The error is:
> {{{
> 16 bit MS-DOS Subsystem
> C:\PROGRA~1\WINHUG~1\UNINST~1.EXE
> The NTVDM CPU has encountered an illegal instruction.
> }}}
>
> I am using Windows XP SP2 using NTFS. My "Program Files" directory has
very strict ACL permissions (only Administrators can modify anything).
>
> It seems strange that the uninstaller is a 16-bit console application.

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/42#comment:6>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

Re: #51: The WinHugs uninstaller.exe doesn't work!

2007-11-01T13:18:51Z

#51: The WinHugs uninstaller.exe doesn't work!
-----------------------+----------------------------------------------------
Reporter: guest | Owner: neil
Type: defect | Status: assigned
Priority: critical | Milestone:
Component: winhugs | Version: current
Resolution: | Keywords: setup uninstall
-----------------------+----------------------------------------------------
Comment (by guest):

Hello, I would like to know if this problem (and more importantly the
problem from track 42) has been resolved as I too have been having the
same problem with uninstalling winhugs and I am getting the error message
mentioned in track 42.
http://hackage.haskell.org/trac/hugs/ticket/42

Replying to [ticket:51 guest]:
> Hi guys!
>
> I was trying to uninstall WinHugs in order to install a newer version,
and I found that the uninstaller.exe program doesn't work.
>
> I opened the uninstaller.exe with a hex editor, and I found that it's
not a valid executable file. It's some weird combination of HTML and
executable code. These are the first 15 lines of the uninstaller.exe file:
>
>
> {{{
> <html>
> <head>
> <META HTTP-EQUIV="Content-Type" content="text/html;
charset=Windows-1252">
> </head>
> <body>
> <pre>
> <table width=100% bgcolor=#CFCFE5><tr> <td> <font face=arial size=+3>
> Build Log
> </font></table><table width=* cellspacing=0 cellpadding=0><tr><td
width=0 bgcolor=#EDEDF5> </td><td width=0
bgcolor=#FFFFFF> </td><td width=*><pre>
> <h3>------- Build started: Project: Uninstaller, Configuration:
Release|Win32 -------
> </h3>
> </pre></table><table width=100% bgcolor=#DFDFE5><tr><td><font face=arial
size=+2>
> Command Lines
> </font></table><table width=* cellspacing=0 cellpadding=0><tr><td
width=0 bgcolor=#EDEDF5> </td><td width=0
bgcolor=#FFFFFF> </td><td width=*><pre>Uninstaller - up-to-
date.</pre></table><table width=100% height=20
bgcolor=#CFCFE5><tr><td><font face=arial size=+2>
> </font></table></body></html>
> }}}
>
> I hope this is not difficult to fix.
>
> Greetings,
> -- L e a n d r o < c a f e s o l o [at] g m a i l [dot] c o m >

--
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/51#comment:5>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs