Re: -1796254192 `div` 357566600 == 5 ??

[Marcin 'Qrczak' Kowalczyk]

Thu, 27 Jun 2002 11:44:29 -0400, Dylan Thurston <[EMAIL PROTECTED]> pisze:

> Prelude> -1796254192 `div` 357566600
> 5

Works for me in the cvs version.

Prelude> -1796254192 `div` 357566600
-5

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK

___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: constraints inside classes

[Marcin 'Qrczak' Kowalczyk]

Fri, 22 Feb 2002 12:55:13 -0800, Mark P Jones <[EMAIL PROTECTED]> pisze:

> | class Foo a where
> | f :: Eq a => a -> Bool
> 
> This behavior of Hugs is intentional, and is documented as a non-bug
> on the Hugs web pages:  (right at the end)
> 
>   http://cvs.haskell.org/Hugs/pages/bugsandfeatures.htm
> 
> I don't know how the "non bug" status was determined, but perhaps
> it reflects a view that the real bug is in the language report,
> where a demonstrably unnecessary, and potentially limiting restriction
> is imposed.

It's indeed limiting and IMHO should be removed; I have told about
it some time ago. Here is a stripped-down example where it's necessary:

class Seq s a where
fromList :: [a] -> s a
elem :: Eq a => a -> s a -> Bool

I've seen attempts at expressing such class with features that GHC
allows but they were all wrong.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK

___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Mangler problem building libraries/ with gcc 3.0.4

[Marcin 'Qrczak' Kowalczyk]

Fri, 22 Feb 2002 11:41:58 + (GMT), Nicholas Nethercote <[EMAIL PROTECTED]> pisze:

> I tried building the standard library in libraries/ with gcc 3.0.4;  it
> grinds to a halt at this point:
> 
> Data/Array/Base.hs:1162:
> Warning: foreign declaration uses deprecated non-standard syntax
> ghc-asm: (mangler) still have jump involving %edi!

I confirm. As a workaround I have this in mk/build.mk:

ArrayBase_HC_OPTS = -pgmcgcc-2.95.3 #not needed anymore
PosixTTY_HC_OPTS = -pgmcgcc-2.95.3
Data/Array/Base_HC_OPTS = -pgmcgcc-2.95.3

where gcc-2.95.3 is an old gcc binary (with its files left in
/usr/lib/gcc-lib).

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK

___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: incorrect parsing

[Marcin 'Qrczak' Kowalczyk]

Thu, 3 Jan 2002 17:27:43 -, Simon Marlow <[EMAIL PROTECTED]> pisze:

> I think it would be better to change the syntax to match the text rather
> than the other way around: clearly sections like (++a++b) are desirable.

I would even argue that (a++b++) should mean \x -> a++b++x
Of course Haskell 98 doesn't work this way.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Compiling GHC

[Marcin 'Qrczak' Kowalczyk]

Wed, 5 Dec 2001 21:25:31 +0100 (MET), Josef Svenningsson <[EMAIL PROTECTED]> pisze:

> Linker.c:347: `stg_chk_2' redeclared as different kind of symbol

Use SymX instead of Sym.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: "Unable to find a register to spill in class `SIREG'."

[Marcin 'Qrczak' Kowalczyk]

Mon, 3 Dec 2001 12:54:01 -, Simon Marlow <[EMAIL PROTECTED]> pisze:

> That will likely hurt performance quite a bit (I don't have figures,
> but I guess 10-20%).

I've heard that guessing about performance means nothing compared to
measuring :-)

> Often the cause is some inlining or other optimisations that put
> extra strain on gcc's register allocator, so it is usually best to
> try to track down and avoid these.

7 modules of 52 in qforeign are affected. It's hard to avoid: using
FFI is often enough to cause the problem. It's annoying that the
compiler can't figure out itself how it should compile things and I
must mark modules explicitly, and that what should be marked depends
on versions of compilers and options, so even if it works in some
environment it can break in another.

Is it possible to apply this setting to parts of a module (e.g. parts
using FFI)?. I mean that ghc would do it itself.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: "Unable to find a register to spill in class `SIREG'."

[Marcin 'Qrczak' Kowalczyk]

Thu, 22 Nov 2001 10:09:17 -, Simon Marlow <[EMAIL PROTECTED]> pisze:

> This is an error from the C compiler telling you it ran out of registers
> while compiling the intermediate C.  Try adding the -monly-3-regs
> option, and failing that -monly-2-regs.

With gcc-3.0.2 there are more cases like this. Would making
-monly-3-regs the default be better?

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: problems with Array.elems in ghc-5.02

[Marcin 'Qrczak' Kowalczyk]

Tue, 23 Oct 2001 22:01:07 +0200, Bostjan Slivnik <[EMAIL PROTECTED]> pisze:

>instance Ix Foo where
> range (lo@(Foo _ foos),hi) = (filter ((<=)lo).filter ((>=)hi)) foos
> inRange (Foo lo _,Foo hi _) (Foo f _) = inRange (lo,hi) f
> index _ (Foo f _) = f

This instance doesn't fulfill the law from the Haskell 98 Report
which an implementation is entitled to assume:

range (l,u) !! index (l,u) i == i   -- when i is in range

For example if l = Foo 2 lstOfFoos, u = Foo 5 lstOfFoos, i = l
then range (l,u) !! index (l,u) i = Foo 4 lstOfFoos.

ghc-5.02 makes use of this for more efficient implementations of
various array operations. In particular the range size is computed
as the index of its last element + 1 (if the range is nonempty),
which gives two more than the length returned by range in your case,
so two elements are not initialized by the function array. The function
elems now iterates over the physical array elements instead of going
through range.

Perhaps it's possible to find a hole in the report by supplying
a bogus definition of (==) for indices, so although the law holds
when taken literally, some equal elements are not really equivalent...
I don't know.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ghci: unknown symbol `__ashldi3

[Marcin 'Qrczak' Kowalczyk]

Tue, 9 Oct 2001 10:10:40 +0200 (MET DST), Josef Svenningsson <[EMAIL PROTECTED]> 
pisze:

> Linker.c: At top level:
> Linker.c:369: `__ashldi3' undeclared here (not in a function)

Bring it with Sym, not SymX.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ghci: unknown symbol `__ashldi3

[Marcin 'Qrczak' Kowalczyk]

Fri, 5 Oct 2001 17:31:18 +0200, Ch. A. Herrmann <[EMAIL PROTECTED]> 
pisze:

>> Loading package std ... linking ... 
>/public/packages/programming/ghc-5.02/lib/ghc-5.02/HSstd_cbits.o: unknown symbol 
>`__ashldi3'

I guess you can add the symbol to ghc/rts/Linker.c and recompile ghc
with the runtime using the new Linker.c (i.e. recompile twice).

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: readFile close behaviour

[Marcin 'Qrczak' Kowalczyk]

05 Oct 2001 17:51:45 +0900, Jens Petersen <[EMAIL PROTECTED]> pisze:

> IMHO hugs is doing the right thing here.  Shouldn't ghc also
> close semiclosed handles when all references to them have
> been dropped?

I guess it would close, but garbage collection didn't notice yet that
all references have been dropped.

BTW, it's not necessarily semiclosed: you are throwing away the
contents and it will be open or semiclosed dependent on how much is
read by readFile before returning (perhaps nothing and it's thus open).
If it was semiclosed, the physical handle could be closed immediately.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): Oversize heap check detected. Please try compiling with -O.

[Marcin 'Qrczak' Kowalczyk]

Mon, 1 Oct 2001 09:39:51 +0100, Simon Marlow <[EMAIL PROTECTED]> pisze:

>> Oversize heap check detected.  Please try compiling with -O.

> We *will* get around to fixing it properly, probably sometime in the
> next few months.

It prevents compilation of hslibs/hssource/HsParser now, so I hope
it will be fixed. Fortunately -O helps, but...

<>

Congratulations: this is the largest process ever run on my computer!

That ghc needs huge amounts of memory for large modules is a problem
in itself.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Problem building 4.08.2 from scratch

[Marcin 'Qrczak' Kowalczyk]

Sun, 23 Sep 2001 01:16:51 +0100, Loz <[EMAIL PROTECTED]> pisze:

> I'm trying to build ghc from scratch on a gcc-3.0 athlon system.

Sorry, gcc-3.x is not supported yet by ghc, even in just released
ghc-5.02.

I was getting the same error as you. I guess this is a bug in gcc,
which for a function or two in PrimOps emits frame pointer handling
code despite -fomit-frame-pointer option. It really addresses the
stack using %ebp instead of %esp in these functions!

Despite problems I'm currently using gcc-3.0.1. I have a minimal
portion of gcc-2.95.3 still installed: just /usr/bin/gcc-2.95.3 and
/usr/lib/gcc-lib/i686-pld-linux/2.95.3/{cc1,cpp,include/*,specs},
and the following in fptools/mk/build.mk:

PrimOps_HC_OPTS = -pgmcgcc-2.95.3
ArrayBase_HC_OPTS = -pgmcgcc-2.95.3
PosixTTY_HC_OPTS = -pgmcgcc-2.95.3

because these are the only files which gcc-3.0.1 was unable to compile.
Fortunately mixing gcc versions works in these cases.

ghc-5.02 (but not earlier versions) detects the version of gcc at
configure time and refuses to build if it's gcc-3.x, so I disabled
this check in my local tree.

ghc-5.02 (but not earlier versions) also has a little #ifdefery for gcc
version in its *.h files, to avoid tons of warnings for gcc-3.x which
deprecated its extension of zero-sized arrays at the end of a struct,
and instead recommends the similar ISO C99 feature of flexible arrays
at the end of a struct. Older ghc versions should still work with
gcc-3.x (except a few files which must be compiled using gcc-2.x),
but with tons of warning coming from gcc.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Literate scripts not handled correctly

[Marcin 'Qrczak' Kowalczyk]

Tue, 18 Sep 2001 12:48:45 +0100, Simon Marlow <[EMAIL PROTECTED]> pisze:

> The report states that the unliterate version of the file is
> recovered by "taking only those lines beginning with '>', and
> removing the first character of those lines", which would leave
> the lines indented by a single space, not two.

This has unexpected results when tabs are used. Wouldn't be better
to say that '>' are replaced with spaces?

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: GHC FFI Return Type Bug

[Marcin 'Qrczak' Kowalczyk]

Mon, 10 Sep 2001 05:03:35 -0700, Julian Seward (Intl Vendor) <[EMAIL PROTECTED]> 
pisze:

> If I'm feeling optimistic, late this week; otherwise, sometime
> next week.  We've had some stability problems, but I hope these
> are now solved.

I'm afraid that the bug which causes recompilation to sometimes fail
on AsmCodeGen hasn't been fixed or even reproduced?

It happens non-deterministically and very rarely (three times so
far in several tens of recompilations). But when it happens, all
repeated compilations of this file fail, until I change the heap
size or recompile the whole from scratch. And when it doesn't happen,
by analogy I guess it won't happen without recompilation of everything.

There is another bug I reported which hasn't been fixed:
 doesn't compile with 'Oversize
heap check detected.  Please try compiling with -O.' (the suggestion
helps).

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Unnecessary recompiles in GHCi (was: .o not found)

[Marcin 'Qrczak' Kowalczyk]

Wed, 27 Jun 2001 11:57:06 +0100, Simon Marlow <[EMAIL PROTECTED]> pisze:

> I'm in two minds about what to do.  GHCi's behaviour is safe, but it
> results in random superfluous recompilations if you happen to touch &
> recompile really quickly (this happens in our automatic GHCi tests, for
> example).  Make's behaviour is unsafe, but from the user's point of view
> it is more deterministic (no unnecessary recompilations).

I would choose the make's behavior. It's much more probable that a
compilation will take a second (when a Makefile generates Haskell
source and then compiles it) than that the next version of the file
after previous compilation will come in a second (the next version
comes from a human; I doubt that any Makefile will compile a file,
then modify it, then compile it again into the same object file).

As we are at it, there is another case. Makefiles typically contain
the following rule:

%.hi: %.o
@true

But when .o is newer than .hi, which happens often in ghc, this
rule unnecessarily fires on each make run for each file (as a side
effect, make doesn't say that everything is up to date). I am using
a different rule:

%.hi: %.o
@touch -c $@

The -c option ensures that we will only adjust the timestamp, not
create an empty file if .o is present without .hi by mistake.

If ghc ensured that .o it creates is not newer than .hi, the simpler
rule with @true would work better.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Bug with implicit params and record update

[Marcin 'Qrczak' Kowalczyk]

module Test where
data R = R {f :: Int}
foo:: (?x :: Int) => R -> R
foo r = r {f = ?x}

Test.hs:4:
Could not deduce `?x :: Int' from the context ()
Probable fix:
Add `?x :: Int' to the the type signature of an expression
arising from use of implicit parameter `?x' at Test.hs:4
In the record update: r {f = ?x}
In the definition of `foo': r {f = ?x}

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: package for ghci

[Marcin 'Qrczak' Kowalczyk]

Wed, 30 May 2001 10:48:34 +0400, S.D.Mechveliani <[EMAIL PROTECTED]> pisze:

>ld -r --whole-archive libHSfoo.a -o libHSfoo.o

It should be named HSfoo.o

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: finalizers broken (4.08.2 & 5.00)

[Marcin 'Qrczak' Kowalczyk]

Fri, 25 May 2001 15:22:13 +0100, Simon Marlow <[EMAIL PROTECTED]> pisze:

> It is only really safe to put finalizers on primitive indivisible
> objects (which is why we have addForeignFinalizer, mkWeakIORef,
> and now addMVarFinalizer).

Shouldn't addMVarFinalizer be available through Concurrent instead
of being internal to ghc std libs? It looks like a good choice for
making pure-Haskell objects with finalizers.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ghc linking errors

[Marcin 'Qrczak' Kowalczyk]

Wed, 9 May 2001 13:26:42 -0700 (PDT), Thomas Hallock <[EMAIL PROTECTED]> pisze:

> _Main_main_closure
> ___init_Main

This is because your module has a different name then Main.

> __udivdi3
> __umoddi3
> __cmpdi2
> __fixunsdfdi
> __floatdidf

These symbols should be found in libgcc.a. I don't know why it's not
linked in. Is gcc able to compile & link this program?

unsigned long long i;
int main (void)
{
i = i / 3;
}

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: GMP unboxed number representation

[Marcin 'Qrczak' Kowalczyk]

(The reply went to hugs-bugs and glasgow-haskell-bugs, but in separate
mails because I'm reading glasgow-haskell-bugs through my mail<->news
gateway. Please Cc: replies to a ghc list or me; I'm not subscribed
to hugs-bugs.)

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: GMP unboxed number representation

[Marcin 'Qrczak' Kowalczyk]

Thu, 3 May 2001 20:48:11 +0200, Hans Aberg <[EMAIL PROTECTED]> pisze:

> I am chatting with the GMP (GNU Multi-Precision number library) people
> about "unboxed" (no pointer) representations.

Do you mean storing smaller values directly in the structure?

> What do you experts on such implementations think would be a suitable
> low-level GMP implementation; that is, that would make the use in
> say GHC easier?

GHC does that optimization itself. Its Integer representation is thus:

data Integer
   = S# Int#-- small integers
   | J# Int# ByteArray# -- large integers

It keeps integers in the small variant where possible, switching to
use the gmp variant on overflow.

It's essential that these two variants are visible to ghc, so it
can often generate appropriate dispatching code instead of physical
allocation of these structures.

The Int# in the J# variant corresponds to _mp_size in __mpz_struct, and
the ByteArray# holds the pointer to Haskell heap block which contains:
* a header pointer used by the GC,
* _mp_alloc,
* all the libs pointed to by _mp_d.

Changing the representation in gmp would require massive rewriting
in ghc. I don't know what improvement could be made by the way,
so let me just describe what is currently going on.

Code for primitive versions of (+)::Integer->Integer->Integer etc. has
a comment:
/* ToDo: this is shockingly inefficient */

It creates MP_INT variables, fills them from arguments of Haskell's
J# objects (passed separately):
arg1._mp_alloc= d1->words;
arg1._mp_size = (s1);
arg1._mp_d= (unsigned long int *) (BYTE_ARR_CTS(d1));
arg2._mp_alloc= d2->words;
arg2._mp_size = (s2);
arg2._mp_d= (unsigned long int *) (BYTE_ARR_CTS(d2));
calls the gmp function, and returns the _mp_size of the result together
with its _mp_d-sizeof(two words) on the Haskell stack.

ghc calls mp_set_memory_functions on startup to let gmp allocate
ByteArray#s with appropriate header on the Haskell heap.

ghc's Int# has always the same size as a pointer, either 32 or 64 bits.
The runtime assumes that limbs have this size too, e.g. _mp_alloc here
is just the number of words in the ByteArray#.

There is no provision for turning the J# representation back into S#
if it gets small enough. (If there was, it would not be enough to
check abs(_mp_size)<=1, because mpz with abs(_mp_size)<=1 is able to
represent one bit more than a single Int#, because the sign bit is
stored in the _mp_size's sign.)

I think it's essential to not make the S# case slower, but the
representation of larger numbers could be changed if only somebody
did the huge task of rewriting everything (with #ifdefs for older
gmp). I'm not sure how to integrate gmp's view of optimizing small
integers with ghc's view.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [Fwd: Bug#94739: ./.ghci -- isn't it dangerous?]

[Marcin 'Qrczak' Kowalczyk]

Mon, 30 Apr 2001 13:57:46 +0200, Michael Weber <[EMAIL PROTECTED]> 
pisze:

> If user X writes/modifies ./.ghci, then it gets the ownership of X,
> doesn't it?

No.

[qrczak ~]$ ls -l 1
-rw-rw-rw-1 martabin  3775 kwi 30 15:21 1
[qrczak ~]$ echo foo >1
[qrczak ~]$ ls -l 1
-rw-rw-rw-1 martabin 4 kwi 30 15:40 1
[qrczak ~]$ id -un
qrczak
[qrczak ~]$

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [Fwd: Bug#94739: ./.ghci -- isn't it dangerous?]

[Marcin 'Qrczak' Kowalczyk]

Mon, 30 Apr 2001 12:49:23 +0100, Simon Marlow <[EMAIL PROTECTED]> pisze:

> The problem is that both ~/.ghci and ./.ghci are useful:  I use ~/.ghci
> to do things like :set +s, and define some useful macros.  Whereas
> ./.ghci is great for doing things like:
> 
>:set -iFoo:Bar
>:set -fglasgow-exts
>:load Main

You can implement your policies about ./.ghci in ~/.ghci by
:def readConfig \_ -> do doSomeChecks; readFile ".ghci"
:readConfig

For example enable ./.ghci as long as . is under $HOME.

But it's unsafe when somebody places Prelude.{o,hi} in .
(or IO.* or whatever modules doSomeChecks use).

And it's inconvenient to fit large expressions in a single line,
and local definitions share the namespace with code to be interpreted
interactively.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Syntax for implicit parameters

[Marcin 'Qrczak' Kowalczyk]

Mon, 30 Apr 2001 05:22:13 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:

>   let dynamic
>   ?x = 3
>   ?y = ?y+?x
>   in
>   ...
> 
> * 'dynamic' is a special-id, only significant immediately following
>   a let.

So 'dynamic' triggers the layout rule after 'let' but not in other cases.
Ok, but it's the first time where such thing happens.

I like it better than 'with' but worse than plain 'let'.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Wording of type error

[Marcin 'Qrczak' Kowalczyk]

Sun, 29 Apr 2001 23:47:27 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:

> I also think you are probably right about replacing single-quotes
> with double-quotes.

Maybe, but on haskelldoc@ it emerged that single 'quotes' might be
good for distinguishing code snippets in comments (mostly single words;
larger snippets should be on separate lines and indented) - for an
automatic tool which makes hyperlinks to entities referred to.

Yes, it looks confusing (but unambiguous) when the name ends with '.
OTOH double quotes are used for generic quotations, so perhaps single
quoting ('', not `') could be a universal convention for embedding
language's identifiers in ASCII coded text.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Wording of type error

[Marcin 'Qrczak' Kowalczyk]

Thu, 26 Apr 2001 19:21:27 -0600 (MDT), Alastair Reid <[EMAIL PROTECTED]> pisze:

> 2) The use of ` and ' around the identifier doesn't work too well if
>the identifier ends in a '.  It'd be better to use " since " isn't
>legal in identifiers.  (Of course, you might run into trouble if
>printing a string literal.)

Especially as ` is not really a quote but a grave accent. I'm afraid
I don't have references at hand, but there is an opinion that `this'
way of quoting is a mistake: in ASCII you should use 'this' or "this",
in Unicode you have true quotes available.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Compiling GHC 5.00 under FreeBSD 4.2

[Marcin 'Qrczak' Kowalczyk]

Wed, 18 Apr 2001 22:00:58 +0200 (MET DST), Eelco Dolstra <[EMAIL PROTECTED]> 
pisze:

> The reason is that Readline contains two calls to fileno() with a StgAddr
> argument which should be typecast to FILE * but isn't, and under FreeBSD
> fileno() is defined as a macro, like this:
> 
> #define fileno(p)   ((p)->_file)

Thanks, fixed.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Syntax for implicit parameters

[Marcin 'Qrczak' Kowalczyk]

Wed, 18 Apr 2001 10:41:45 -0700, Erik Meijer <[EMAIL PROTECTED]> pisze:

> As I was not involved in that discussion, why should the keyword
> "with" not be introduced?

There are at least two libraries in hslibs which would like to use
'with' as an identifier.

Foreign currently uses 'withObject', where only 'with' would be
consistent. This function is related to 'withArray' as 'poke' is
related to 'pokeArray'.

XmlCombinators switched -fglasgow-exts off when 'with' was
introduced. One cannot use this function direcly from a code compiled
under -fglasgow-exts.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Syntax for implicit parameters

[Marcin 'Qrczak' Kowalczyk]

Wed, 18 Apr 2001 11:31:07 -0600 (MDT), Alastair Reid <[EMAIL PROTECTED]> pisze:

> Can the GHC people, the Hugs people and the implicit parameter
> designers come to some sort of agreement and implement the result?  

I would like to replace "with" and "dlet" with "let". But SimonPJ said
he won't do it in ghc unless Hugs does it too, and Mark P Jones said
he won't do it in Hugs now (without deep reasons: no people/hours to
do that, and no plans to release next Hugs version this year).

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

RE: ghc-5.00 packaging bug and others

[Marcin 'Qrczak' Kowalczyk]

On Wed, 11 Apr 2001, Julian Seward (Intl Vendor) wrote:

> | There is $i$th in one place in the documentation (sgml is not tex).
> 
> You already committed a fix for this?

No. I'm not sure what is the best markup for this.

-- 
Marcin 'Qrczak' Kowalczyk


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

ghc-5.00 packaging bug and others

[Marcin 'Qrczak' Kowalczyk]

The binary package makes a link ghci-pkg -> ghci-pkg-5.00 instead of
ghc-pkg -> ghc-pkg-5.00.

The postscript documentation renders - and -- in the same way
(i.e. --make looks like -make etc.).

There is $i$th in one place in the documentation (sgml is not tex).

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: green-card in cvs does not compile [low priority]

[Marcin 'Qrczak' Kowalczyk]

Thu, 8 Mar 2001 15:53:19 +0100, Sigbjorn Finne <[EMAIL PROTECTED]> pisze:

> Happy 1.9 (and later) imposes a restriction on the possible types
> a monadic lexer can have,

What restriction?

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Method contexts

[Marcin 'Qrczak' Kowalczyk]

Sat, 10 Feb 2001 19:04:33 +0100, Hannah Schroeter <[EMAIL PROTECTED]> pisze:

> So you can equally say:
> 
> class Eq k => Member c k where
>   member :: c -> k -> Bool
> 
> class Seq c k where -- no member superclass here
>   list :: c -> [k]

This requires listing Member separately in contexts which have Seq
anyway - in other words this requires that the programmer using these
classes knows the class Member, instead of using Seq (and others
which have Member as superclasses too).

This requires listing Eq separately in Member instances.

This requires splitting a class like Member into two when some methods
need different contexts than others.

*Why* to make the restriction that method's context must constrain
at least one type variable quantified in the method's type? What do
we gain by having this restriction? Hugs does not enforce it.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Method contexts

[Marcin 'Qrczak' Kowalczyk]

Sat, 10 Feb 2001 16:36:52 +0100, Hannah Schroeter <[EMAIL PROTECTED]> pisze:

> Somehow I don't understand this. Eq a is required for Member [a] a,

It is not required for Member [a] a, but for the member method.

class Member c k where
member :: Eq k => c -> k -> Bool

instance Member [a] a where
member = flip elem

The above class and instance should be legal. Note that Member [a] a
holds for any a, and the type of member is
member :: (Member c k, Eq k) => c -> k -> Bool

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Method contexts

[Marcin 'Qrczak' Kowalczyk]

Sun, 28 Jan 2001 19:41:15 +0100, Hannah Schroeter <[EMAIL PROTECTED]> pisze:

> Why can't you write:
> 
> class Eq k => Member c k where
>   member :: c -> k -> Bool
> 
> > class Member c a => Seq c a
> 
> instance Eq a => Member [a] a where
>   ...
> 
> > instance Seq [a] a

Because the last instance is then illegal: requires Eq a in the
context, which I obviously don't want.

BTW, there is a bug in the ghc's CVS HEAD. The following program:

class Eq k => Member c k where
member :: c -> k -> Bool
class Member c a => Seq c a where
list :: c -> [a]
instance Eq a => Member [a] a where
member = flip elem
instance Seq [a] a where
list = id
type F = Int -> Int
test:: [F] -> F -> Bool
test = member
main:: IO ()
main = print ((id :: F) == id)

does compile. When the definition of test is removed, there is a
correst error about missing instance Eq (Int -> Int). The use of
member:: [F] -> F -> Bool magically creates this instance!

Unfortunately it does not really allow to compare functions and the
answer is <> :-)

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Method contexts

[Marcin 'Qrczak' Kowalczyk]

Thu, 25 Jan 2001 09:55:08 -0800, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:

>   The HEAD, which will become GHCi 5.0, does not have functional
>   dependencies, and I think they work properly

You meant that it does have them :-)

Indeed it seems to finally work with my collection experiments which
heavily use fundeps. It used to work with Hugs only. Thanks!


Could ghc relax the requirement we talked about some time ago, that
a method context must constrain a type variable which is quantified
there? For example:


class Member c k where
member :: Eq k => c -> k -> Bool

class Member c a => Seq c a

instance Member [a] a where
member s x = x `elem` s

instance Seq [a] a


I see no reason to disallow this, it is needed to express requirements
about sequences specified above, and hugs -98 accepts this.


BTW, ghc prints the type in an unusual way:

The constraint `Eq k' does not mention any of the universally quantified type 
variables
in the type `{Eq k} -> c -> k -> Bool'

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: fptools/configure thinks happy 1.10 < 1.9

[Marcin &#x27;Qrczak' Kowalczyk]

Fri, 26 Jan 2001 14:57:58 +0100, Volker Stolz <[EMAIL PROTECTED]> 
pisze:

> ...is too long for a perl one-liner in configure.

perl -e '@v = map {join "", map {chr} split /\./} @ARGV;
 exit ($v[0] ge $v[1] ? 0 : 1)' 1.10 1.9
# Returns 0, i.e. the second version is at least as high as the first.
# Works for numbers up to 255.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Haskell pattern matching too strict?

[Marcin &#x27;Qrczak' Kowalczyk]

Wed, 10 Jan 2001 14:45:34 + (GMT), Robert F. Pointon <[EMAIL PROTECTED]> pisze:

> The argument that efficency/performance is more important that an
> evaluation mechanism with constant behaviour is a bit worrying...

It's more consistent to always match argument patterns strictly :-P
Efficiency is a side effect.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Haskell pattern matching too strict?

[Marcin &#x27;Qrczak' Kowalczyk]

On Tue, 9 Jan 2001, Robert F. Pointon wrote:

> I agree in general, however in this case there is only one clause so it
> does not need to evaluate to decide which clause to commit to. Ideally
> the compiler should detect this specific situation where there is one
> pattern that always matches.

OTOH evaluation of the argument early may improve performance. Usually
the purpose of writing a pattern in a function's parameter is to use
components of the value in its rhs, such that the value of the rhs is
meaningless without all the components. If the argument matched early,
the compiler can determine that the function is strict and generate more
efficient code for calling it.

In rare cases when the body makes sense without some components of
parameters, you can use lazy patterns or let or functions like head
instead of pattern matching or whatever.

-- 
Marcin 'Qrczak' Kowalczyk


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: modifyIORef in IOExts/hslibs

[Marcin &#x27;Qrczak' Kowalczyk]

Wed, 3 Jan 2001 23:42:51 +0100 (MET), Axel Krauth <[EMAIL PROTECTED]> 
pisze:

> I'm using the IOExts-library and want to use
> modifyIORef instead of updateIORef which is marked as deprecated
> (section 4.14.2 in the hslibs documentation).
> Unfortunately IOExts.hi doesn't export modifyIORef. It only
> exports updateIORef..

In ghc-4.08.1 (the latest released version) it was called updateIORef.
In development versions it is called modifyIORef and updateIORef is
still kept for compatibility.

> Is it safe to use updateIORef meanwhile?

Yes.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: False "duplicate or overlapping instances" message

[Marcin &#x27;Qrczak' Kowalczyk]

Thu, 26 Oct 2000 01:29:38 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:

> a') when trying to solve a constraint, search for all solutions,
> and check that in the end there is only one.
> 
> b') never comlain of overlap when declaring instance declarations;
> instead only complain when solving constraints.

I am worried if the following scenario is possible: There are
two modules. Everything is OK. Now one of them adds an innocent
instance. It is perfectly correct in its context, but it happens that
it triggers an ambiguity in the second module. Still neither module
itself is at fault.

Something like this can even happen now: when they define overlapping
instances. Maybe after this "fix" some of these cases won't trigger
errors immediately, but at some unexpected point in the future,
long after these modules were committed as good?

I don't have a concrete case in mind...

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Program won't go away!

[Marcin &#x27;Qrczak' Kowalczyk]

On Thu, 19 Oct 2000, George Russell wrote:

> > I suspect that your program does the same thing. I.e. that the rest of
> > main is not executed by the main process.
> 
> This is not correct.

Could you send me that program? I cannot imagine any other reason.

-- 
Marcin 'Qrczak' Kowalczyk


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Program won't go away!

[Marcin &#x27;Qrczak' Kowalczyk]

On Thu, 19 Oct 2000, George Russell wrote:

> I don't see what this example has got to do with mine, since it prints
> "Test completed" in the new process, while waiting in the old one.

I suspect that your program does the same thing. I.e. that the rest of
main is not executed by the main process.

-- 
Marcin 'Qrczak' Kowalczyk


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Program won't go away!

[Marcin &#x27;Qrczak' Kowalczyk]

Wed, 18 Oct 2000 16:32:21 +0200, George Russell <[EMAIL PROTECTED]> pisze:

> > In a standalone GHC program, only the main thread is required to
> >   terminate in order for the process to terminate. 
> 
> I have a program (which does some fairly complex things with forking processes,

The above fact applies to threads (module Concurrent), not processes
(module Posix).

In some sense it does apply to processes, but the interface of
forkProcess allows to "continue execution" with the child process,
while the main process (parent) waits somewhere.

> the very last line of the "main" action is:
>   putStrLn "Test completed"
> The program prints "Test completed", but then hangs.

Quite possible. For example (untested):

main = do
pid <- forkProcess
case pid of
Nothing -> return () -- This is the new process.
Just _  -> do
-- This is the old process.
sleep 100; exitWith ExitSuccess
-- This is the new process.
putStrLn "Test completed"

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: type of stToIO

[Marcin &#x27;Qrczak' Kowalczyk]

Thu, 5 Oct 2000 09:25:18 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:

> I discussed this with John Launchbury who pointed out a much
> better type for stToIO
> 
>   stToIO :: (forall s. ST s a) -> IO a
> 
> That avoids exposing RealWorld while preserving soundness.  Better, eh?

Doesn't it prevent returning a value of type STRef RealWorld something
from the computation, which is a perfect IORef something substitute
when we have stToIO?

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: type of stToIO

[Marcin &#x27;Qrczak' Kowalczyk]

On Wed, 4 Oct 2000, Ross Paterson wrote:

> The library documentation says
> 
>   stToIO :: ST s a -> IO a
> 
> but PrelIOBase says
> 
>   stToIO :: ST RealWorld a -> IO a

AFAIR it's a different stToIO than one exported by the end-user module
(IOExts or ST). Sorry, can't check it from here.

> The documented type would be unsafe (as it is in Classic Hugs), so it
> seems necessary to mention the real world in the documentation.

Why is it unsafe? IMHO it is safe.

-- 
Marcin 'Qrczak' Kowalczyk

Re: openFile, process file table full

[Marcin &#x27;Qrczak' Kowalczyk]

Tue, 12 Sep 2000 11:52:42 +0200 (MET DST), Ch. A. Herrmann 
<[EMAIL PROTECTED]> pisze:

>  = do
> system("cp "++name++" newtmp");
> content <- readFile "newtmp"
> system("rm newtmp");
> waitWhileExistsFile "newtmp"
> return content

1. The file will be deleted immediately. On Unix it's possible to
   read it if it was open before, while its name in its directory
   does not exist.

2. readFile does not read the file in background. It returns a string
   that will read the file further when evaluated further.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK

Re: openFile, process file table full

[Marcin &#x27;Qrczak' Kowalczyk]

On Tue, 12 Sep 2000, Jan Kort wrote:

> I can't seem to work around this behaviour, is it possible to
> force readFile to just open a file, read it entirely and close it
> before doing the next open ?

Applying seq to a list only forces its first constructor.
It does not traverse it to the end.

foldr (\_ x -> x) (return ()) string_that_was_read_from_file
should be a better seq substitute (in a monad). When the string
is evaluated to the end, the file should get closed immediately.

Of course IMHO it's a hack and the issue should be resolved by
compilers by providing smarter I/O function implementations...

-- 
Marcin 'Qrczak' Kowalczyk

Re: openFile, process file table full

[Marcin &#x27;Qrczak' Kowalczyk]

Mon, 11 Sep 2000 03:49:05 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:

> > The Haskell's runtime could do something with it: detect the "too many
> > open files" error and try to suck some lazily read files.
> 
> I suppose it could try doing a full GC to detect the dead handles, then
> somehow arrange that the finalizers all run before anything else.  This
> sounds fairly complicated though.

GC should be done before (to avoid sucking dead files), but it's not
enough. In this case handles are not dead because their lazily read
contents are not dead.

The idea is similar to trying to evaluate random thunks when going
out of memory. Bit this applies to a different resource, is safe and
will definitely free resources.

> I'm of the opinion that readFile/hGetContents are useful for small
> programs, but for larger tasks you need to manage your I/O more
> explicitly.

I disagree and think that it's possible and worth to make
readFile/hGetContents more reliable for larger programs too.

As I have said before, hClose on a semi-closed handle should perform
GC and suck the file before closing if the contents are still alive.
This should be easier than automatic "too many open files" recovery;
it applies locally to a single handle. Using such hClose in Jan's case
(and thus reading files immediately) would help in the absence of
"too many open files" recovery.

readFile should behave such that the semantics is as close as possible
to immediate sucking the whole file, but still being lazy most of
the time. Outside I/O laziness never hurts except of performance.
This principle should apply to readFile too.

There is no nice "strict readFile" now. Improved hClose gives not only
that, but allows reading most of the file lazily and deciding at some
point that the file must be closed without the danger of losing end
of its contents.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK

Re: openFile, process file table full

[Marcin &#x27;Qrczak' Kowalczyk]

Mon, 11 Sep 2000 02:10:59 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:

> > xs <- mapM readFile (take 1000 (repeat "tmp"));

> That looks reasonable - there's usually some kind of limit on the
> number of files a process may have open, for example it's 1024 on
> our Linux box, and 64 on our Sparc box.

It's easier to explain than to fix. readFile's laziness strikes again.

This has bitten be once and caused a major redesign. OK, redesign to
a better solution, but it should not be forced that way :-)

The Haskell's runtime could do something with it: detect the "too many
open files" error and try to suck some lazily read files.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK

Re: form of class constraints

[Marcin &#x27;Qrczak' Kowalczyk]

Mon, 07 Aug 2000 14:27:10 -0400, Zhanyong Wan <[EMAIL PROTECTED]> pisze:

> According to the Haskell 98 report, class constraints are of the form C
> (a t1 ... tn), where C is a class, a is a type variable, and t1, ..., tn
> are arbitrary types (including type variables, n >= 0).

This restricton applies to contexts of value declarations. Other
places have other restrictions. In particular class and instance
contexts (things before "=>" in class and instance declarations)
must constrain only type variables (mentioned in the head).

They are conservative rules. GHC and Hugs have various extensions to
permit richer contexts.

> I have no problem with the same code in Hugs.

Only if Hugs was invoked with -98 (non-Haskell98 extensions enabled).
Hugs +98 rejects it. I'm afraid this instance cannot be expressed
in Haskell98.

GHC does accept it if invoked with -fallow-undecidable-instances.
This option permits arbitrary instance contexts, at the cost of making
the type system undecidable (weird instances might let the compiler
go into an infinite loop, detected by having a fixed recursion depth).
This is why it's not the default even with -fglasgow-exts that enables
most of interesting extensions.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTĘPCZA
QRCZAK

StablePtrs and a NCG bug

[Marcin &#x27;Qrczak' Kowalczyk]

module Examples where
import Foreign
f x = return x >>= deRefStablePtr

[qrczak ~/QForeign]$ ghc -c -fglasgow-exts -O -fasm-x86 Examples.hs

panic! (the `impossible' happened):
getRegister(x86,unary primop)
(Prim deRefStablePtrzh Temp(B0StgStablePtr))

Please report it as a compiler bug to [EMAIL PROTECTED]

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/GCS/M d- s+:-- a23 C+++$ UL++>$ P+++ L++>$ E-
  ^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Link-time conflicts

[Marcin &#x27;Qrczak' Kowalczyk]

Mon, 24 Jul 2000 22:16:32 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:

[...]
> we get an executable that dumps core (as the Pretty module in
> `-package text' also defines a data type `Doc').

With correct dependencies in Makefile Pretty should be compiled
before Main. Then GHC should complain about duplicate Pretty.hi.

It currently does not. AFAIR for a while it used to warn, but it has
been turned off because it was getting the same directory multiple
times (spelled differently) and for some reason it was difficult
to fix.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/GCS/M d- s+:-- a23 C+++$ UL++>$ P+++ L++>$ E-
  ^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: What is `AClass'?

[Marcin &#x27;Qrczak' Kowalczyk]

17 Jul 2000 20:12:47 -0700, Martin Pokorny <[EMAIL PROTECTED]> pisze:

> Perhaps I'm still too much the novice to see an error on my part,
> but the code seems to be valid Haskell to me.

It is valid. It's indeed the error in 4.08 others mentioned, occuring
at least when contexts of class methods form a cycle of classes.
Simon Peyton Jones has already fixed it in the CVS version.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/GCS/M d- s+:-- a23 C+++$ UL++>$ P+++ L++>$ E-
  ^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Precision problem

[Marcin &#x27;Qrczak' Kowalczyk]

Mon, 17 Jul 2000 17:51:27 +0200 (CEST), Michael Marte 
<[EMAIL PROTECTED]> pisze:

> When adding the three double numbers 
> 0.7, 0.2, and 0.1, a ghc 4.07-compiled program (compilation flag -O)
> yields 0.. Whatever this string stands for, the number is
> considered to be < 1.0, which breaks my program. What to do?

Use Rational instead of Double.

Or fix the program to not depend on exactness of floating point
computations.

All languages having Double-like floating point type has this problem.
It's not a bug in the language but improper use. Numbers like 0.1
are simply not representable exactly in the binary floating point type.

BTW: the "default default" in Haskell98 is (Integer,Double).
Maybe it should better be (Integer,Rational,Double) instead?

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/GCS/M d- s+:-- a23 C+++$ UL++>$ P+++ L++>$ E-
  ^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Bug with crazy classes

[Marcin &#x27;Qrczak' Kowalczyk]

module Test where

class Lookup c k a where
lookupAll :: Sequence seq a => c -> k -> seq a

class Lookup (s a) Int a => Sequence s a where
foo :: s a


panic! (the `impossible' happened):
AClass .Test.Sequence{-r8,x-}

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/GCS/M d- s+:-- a23 C+++$ UL++>$ P+++ L++>$ E-
  ^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: strange Prelude.chr bug

[Marcin &#x27;Qrczak' Kowalczyk]

Tue, 13 Jun 2000 19:57:18 +0200, Lennart Augustsson <[EMAIL PROTECTED]> pisze:

> > chr :: Int -> Char
> > chr (I# i) | i >=# 0# && i <=# 255# = C# (chr# i)
> >| otherwise = error ("Prelude.chr: bad argument")
> 
> So a Haskell program that (perhaps inadvertently) uses a Unicode character
> will fail with ghc.

...not only because of definition of chr, unfortunately.

> When is ghc going to implement full Haskell? :)

Simon Marlow said on 16 May:

> I agree it should be done.  But not for 4.07; we can start breaking
> the tree as soon as I've forked the 4.07 branch though (hopefully
> today...).

The branch was forked a long time ago. So could we pleeease...?

A question remained unanswered. The report requires Char to be exactly
16 bits. I loudly cry for letting it be >= 16 bits and <= Int, and
implementing 31 or 32 in GHC. But there is a problem:

Oops, ord will have to be allowed to return negative numbers when
the size of Char is equal to the size of Int. Another solution is to
make Char at least one bit less than Int, or also at the same time
no larger than 31 bits. ISO-10646 describes the space of 31 bits,
UTF-8 is able to encode up to 31 bits, so then a UTF-8 encoder would
be portable without worrying about Char values that don't fit, and
a decoder could easily check if a character is representable in Char:
ord maxBound would be guaranteed to be positive.

Choices I see:
- 30 <= Int, 16 <= Char <= 31, Char <  Int
- 30 <= Int, 16 <= Char,   Char <  Int
- 30 <= Int, 16 <= Char,   Char <= Int

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Heap overflow is not catched

[Marcin &#x27;Qrczak' Kowalczyk]

Mon, 12 Jun 2000 20:12:16 +0100, Claus Reinke <[EMAIL PROTECTED]> pisze:

> 1. A thread is either resource-aware or abstracts away the details
> and difficulties of resource management.
> 2. If resource availablity is high, both kinds of threads can allocate
> (in case of memory: implicitly, as usual in functional programs).
> 3. If resource availability is low,
> - resource-aware threads receive an asynchronous exception, 
>but may then proceed to allocate as before 
>(until the resource is actually exhausted)
> - resource-unaware threads block on allocation attempts
> 
> That's it! Not that complicated, is it?

Looks not bad.

Which resource-aware threads will receive the exeption?

How a handler thread can ensure that it has freed enough memory to
unblock threads that are blocked, or that to get an exception again
instead of reaching a hard limit and crashing?

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Heap overflow is not catched

[Marcin &#x27;Qrczak' Kowalczyk]

Mon, 12 Jun 2000 15:01:14 +0100, Claus Reinke <[EMAIL PROTECTED]> pisze:

> For illustration, consider several limits:
[...]
> Rather, when resource R in pool P is low, the threads can be grouped into
[...]

Must it be so complicated? I hope that something sensible will be
possible with rules that are simple and easy to understand...

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Heap overflow is not catched

[Marcin &#x27;Qrczak' Kowalczyk]

Fri, 9 Jun 2000 08:14:13 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:

> And which thread should get the exception?

IMHO the main thread is not a bad choice: simple and deterministic,
a programmer knows where to install the handler (as opposed to "one
that was allocating at the time" and "one that has allocated most"),
consistently terminates the program when no handler was installed
explicitly.

This is a bit different than killing processes in OS, because
* there is a handler that the programmer wants to be called,
* threads cooperate, processes are usually independent and created
  by different users.



For an example of usage, i.e. when out of heap is not fatal, let's
consider a program that maintains a cache of something, and wants
to purge some cache when went out of heap. Seems to work: the main
thread would install a handler around a takeMVar, the handler would
free some cache and loop again.

Another example. Say it's GIMP. I start a computation that I know that
uses a lot of memory, and want to get "sorry, couldn't complete, out
of memory" when needed. This computation might be in any thread. Hmm,
not so nice, because handling cannot be local. Anyway, the computation
could be moved to a separate thread, the main thread would maintain
ThreadIds of such threads, and kill any of them according to some
chosen policy when run out of heap, informing its parent about
the crime instead of the killed thread that would inform about
completion. Modulo fixing some races.

I am looking for examples to see how they could be handled in different
variants. The second example is easier in "one that was allocating
at the time" (assuming that no other threads are working), but the
first is quite impossible then. I might not want to kill anything yet,
freeing some memory by other means. Any more examples?

Borland Pascal has an out of memory handler that AFAIR returns a code
what to do: retry the allocation, abort the program or return a null
pointer.

I don't know how to ensure that the handler will not use too much
memory before it manages to free some.



PS. The default heap limit is 64MB. Shouldn't it depend on physical
memory or user's limits or free memory or such? Or simpler: check an
enviromnent variable for default RTS options.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Heap overflow is not catched

[Marcin &#x27;Qrczak' Kowalczyk]

grepping through sources suggests that nobody tried to implement this,
only the exception constructor exists... OTOH stack overflow works.

import Exception
main:: IO ()
main = print (length (l++l)) `catchAllIO` print
where l = [0::Int ..]

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Problem solved...

[Marcin &#x27;Qrczak' Kowalczyk]

Mon, 5 Jun 2000 20:26:05 +0100, Nick Williams <[EMAIL PROTECTED]> pisze:

> data Cost = Val Integer | Infinity deriving Show

deriving (Eq, Ord, Show) makes right instances in your case.

> instance Ord Cost where
>   Val x < Val y = x   Infinity < Val _ = False
>   Val _ < Infinity = True
>   Infinity < Infinity = False

Default implementation of (<=) uses compare and vice versa. If you
define neither of them, both will loop forever. It's enough to provide
either compare or (<=) in the Ord class, but not (<).

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: mkdependHS (again)

[Marcin &#x27;Qrczak' Kowalczyk]

Thu, 1 Jun 2000 16:20:24 +0100, Marc van Dongen <[EMAIL PROTECTED]> pisze:

> Please ignore my previous email. When used properly mkdependHS *does*
> indeed recognise dependencies in happy input files.

But of course it does not recognize dependencies on output files from
happy when they were not generated, i.e. complains that files could
not be found. Or, as in my case, on output files from my program which
is being built together with the main program, so it cannot be simply
generated before making dependencies.

The effect is that `make depend' does not work after `make clean'.
If dependencies are out of date and I did make clean, I must get to
a fixpoint: make depend (stops when wants the generated file), make
(can fail when gets to wrong dependencies), make depend (now succeeds)
make (now succeeds)... Not nice. And it does not work at all when
dependencies are broken in the directory when the files are generated
(files are spread over 7 directories with their own Makefiles).

I tried to substitute stubs for those two modules for making
dependencies before they are generated, but I gave up.

I'm not sure how an ideal solution should look like. Any ideas?

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: URI.relativeTo type signature in comment (URI -> URI -> URI)

[Marcin &#x27;Qrczak' Kowalczyk]

Thu, 25 May 2000 02:38:06 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:

> You may have found another good bug here.  Could you try this patch in
> ghc/rts?

Seems to work!

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: URI.relativeTo type signature in comment (URI -> URI -> URI)

[Marcin &#x27;Qrczak' Kowalczyk]

Thu, 25 May 2000 02:38:06 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:

> You may have found another good bug here.  Could you try this patch in
> ghc/rts?

I'll try tonight, I don't have compilable GHC sources at the moment.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: URI.relativeTo type signature in comment (URI -> URI -> URI)

[Marcin &#x27;Qrczak' Kowalczyk]

Tue, 23 May 2000 07:03:56 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:

> I believe I've fixed this one now.

Erm, but there must be another bug. Its effect is
fatal error: evacuate: THUNK_SELECTOR: strange selectee 27

The best way to reproduce it that I could found is the following:

Take intro.html and goodies.html from
.
Or add a link to itself at the top of any HTML file of sufficiently
large size (e.g. tens of kB, or hundreds on a very fast processor).

Run haber compiled with the current ghc on one of these files and
hold Enter for a second. BOOM!

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: URI.relativeTo type signature in comment (URI -> URI -> URI)

[Marcin &#x27;Qrczak' Kowalczyk]

Tue, 23 May 2000 07:03:56 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:

> I believe I've fixed this one now.

Yes, thanks!

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: URI.relativeTo type signature in comment (URI -> URI -> URI)

[Marcin &#x27;Qrczak' Kowalczyk]

Mon, 22 May 2000 01:49:17 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:

> > EVACUATED object entered!
> > fatal error: evacuate: THUNK_SELECTOR: strange selectee 27
> > fatal error: resurrectThreads: thread blocked in a strange way
> 
> ooer!  I hope you can find a repeatable example...

Yes, although it's quite big as a bug report.

http://qrczak.ids.net.pl/Haber-0.1.tar.gz

It's Linux.

$ make
$ COLUMNS=70 LINES=25 ./haber bug.html

I could not find a repeatable example which fails on an 80x25 screen
now (this one fails on 128x48 too). It fails with "EVACUATED object
entered!" after half a second. Screen size determines page breaks
and thus messages sent by threads. It's sensitive to subtle details
of execution order.

The problem is probably related to threads. This one happens when a
thread finishes sending rendered contents and exits. When I hold the
down key during the moment when the page is being displayed (which
causes interleaving other messages in a Concurrent.Chan channel etc.),
it sometimes does not fail.

Other crashes are less deterministic. You might play with the browser
and watch various crashes yourself.

To fix terminal state after a crash: stty sane

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

URI.relativeTo type signature in comment (URI -> URI -> URI)

[Marcin &#x27;Qrczak' Kowalczyk]

does not agree with reality (URI -> URI -> Maybe URI).



PS. I am getting the following errors in my web browser written for
assignment. I'll prepare a test version soon.

EVACUATED object entered!
fatal error: evacuate: THUNK_SELECTOR: strange selectee 27
fatal error: resurrectThreads: thread blocked in a strange way

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Universal quantifiers and record selectors

[Marcin &#x27;Qrczak' Kowalczyk]

GHC does not allow selection of (some?) universally quantified record
fields by name.

I guess that selector functions should have foralls lifted one level
up, beyond the record parameter; otherwise they have invalid types,
with forall in the result, and are unusable.


data Q = Q {f :: forall a. a -> a}
g1 = f
g2 x = f x
g3 x y = f x y


qual.hs:3:
Illegal use of `f'
It is applied to too few arguments
so that the result type has for-alls in it
In the right-hand side of a pattern binding: f

qual.hs:4:
Illegal use of `f'
It is applied to too few arguments
so that the result type has for-alls in it
In the right-hand side of an equation for `g2': f x

qual.hs:5:
Couldn't match `forall a. a -> a' against `t -> t1'
Expected type: forall a. a -> a
Inferred type: t -> t1
Probable cause: `f' is applied to too many arguments in the call
(f x y)
In the right-hand side of an equation for `g3': f x y

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: ghc -v always makes gcc-2.95.1 dump core?

[Marcin &#x27;Qrczak' Kowalczyk]

Tue, 16 May 2000 02:03:53 +0200, Sven Panne <[EMAIL PROTECTED]> 
pisze:

> Well, "time" is a builtin in bash and {,t}csh, but not in {,z,k}sh.

time is a builtin in {z,k}sh.

OK, I am installing /usr/bin/time now. I thought time is always
a builtin and "time true | sleep 3" should always report 3.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: ghc -v always makes gcc-2.95.1 dump core?

[Marcin &#x27;Qrczak' Kowalczyk]

> > "Signal 127"?! I don't understand this.

Now I understand, thanks strace. ghc -v tries to execute "time gcc ...",
but perl does not pass the command line to sh if it does not contain
shell metacharacters, tries to interpret it itself, and tries to execute
a program named time which does not exist.

Why it could ever work for anybody?!

One possible fix is to change
system "$Time $str_to_do"
to
system "/bin/sh", "-c", "$Time $str_to_do"
but I am afraid about non-Unix platforms.

BTW, seems that filenames with spaces will not work in ghc.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

ghc -v always makes gcc-2.95.1 dump core?

[Marcin &#x27;Qrczak' Kowalczyk]

"Signal 127"?! I don't understand this.

$ ghc -c -v Main.hs
The Glorious Glasgow Haskell Compilation System, version 4.07

Effective command line: -c -v

Ineffective C pre-processor:
echo '{-# LINE 1 "Main.hs" -}' > /tmp/ghc14489.cpp && cat Main.hs >> 
/tmp/ghc14489.cpp
0.00s real 0.00s user 0.00s system
ghc:compile:Output file Main.o doesn't exist
ghc:recompile:Input file Main.hs newer than Main.o

Haskell compiler:
/usr/local/lib/ghc-4.07/hsc /tmp/ghc14489.cpp  -fignore-interface-pragmas 
-fomit-interface-pragmas -fsimplify [ -fmax-simplifier-iterations4 ]   
-fwarn-overlapping-patterns -fwarn-missing-methods -fwarn-missing-fields 
-fwarn-deprecations -fwarn-duplicate-exports -fhi-version=407 -static 
"-himap=.%.hi:/usr/local/lib/ghc-4.07/imports/std%.hi" "-himap-sep=:"-v 
-hifile=/tmp/ghc14489.hi -olang=asm -ofile=/tmp/ghc14489.s -F=/tmp/ghc14489_stb.c 
-FH=/tmp/ghc14489_stb.h +RTS -H600 -K100
Glasgow Haskell Compiler, version 4.07, for Haskell 98, compiled by GHC version 4.07
0.52s real 0.42s user 0.03s system

Pin on Haskell consistency info:
echo '
.text
hsc.Main.hs.40.0..:' >> /tmp/ghc14489.s
0.00s real 0.00s user 0.00s system
*** New hi file follows...
__interface "Main" Main  where
__export Main main;
import PrelFloat 1 !;
import Prelude 1;
main:: PrelIOBase.IO PrelBase.Z0T ;


ghc: module version unchanged at 1

Replace .hi file, if changed:
cmp -s Main.hi /tmp/ghc14489.hi-new || ( rm -f Main.hi && cp 
/tmp/ghc14489.hi-new Main.hi )
0.00s real 0.00s user 0.00s system

Unix assembler:
gcc -o Main.o -c  -I. -I/usr/local/lib/ghc-4.07/includes /tmp/ghc14489.s
Unix assembler received signal 127 (core dumped)
deleting... /tmp/ghc14489.cpp /tmp/ghc14489.hi /tmp/ghc14489.s /tmp/ghc14489_stb.c 
/tmp/ghc14489_stb.h Main.o

rm -f /tmp/ghc14489*

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Malicious breaking of name mangling

[Marcin &#x27;Qrczak' Kowalczyk]

module A where b_c = ()

module A_b where c = ()

These modules cannot be used in one program.



module Upd where data X = X {frame :: ()}

This module causes a conflict with the symbol Upd_frame_info in the RTS.



Other similar examples can be constructed. Although not very probable
to happen in practice, I see no excuse for GHC :-)

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Blocking I/O & FIFOs

[Marcin &#x27;Qrczak' Kowalczyk]

Testing under Linux showed that after opening a fifo with O_NONBLOCK
we should call select on it before read: it will not say we can read
from it until another process opens it for writing.

And when another process opens it for writing and closes without
writing anything, select says we should read and read returns 0.
Everything fine.

So after opening a fifo we should simply mark the thread as blocked
on read, and the present select mechanism will do the job.

Is it really that simple?

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

RE: Blocking I/O & FIFOs

[Marcin &#x27;Qrczak' Kowalczyk]

On Fri, 12 May 2000, Simon Marlow wrote:

> I think the only recommendation is "don't use FIFOs" - I'm considering
> backing out the fix now.

It is certainly better after a fix, at least for single-threaded programs
which work perfectly.

With native threads (BTW, are they expected to work soon?) it would work
well too.

An inefficient solution is to fork a process that will block and then feed
us through a pipe. Probably too bad to make it built-in, but at least
should work if somebody desperately needs the functionality.

I would be surprised if POSIX overlooked this case. BTW, are POSIX
standards available for free?

-- 
Marcin 'Qrczak' Kowalczyk

Re: Blocking I/O & FIFOs

[Marcin &#x27;Qrczak' Kowalczyk]

Thu, 11 May 2000 06:39:10 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:

> The solution, if you're interested, is to open the file in blocking
> mode and set O_NONBLOCK later on with an fcntl().

It means that waiting for the writer blocks the whole program, right?

(But it's probably better that seeing EOF, and I don't know how to
do it well.)

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: bug in foreign import (for floats)

[Marcin &#x27;Qrczak' Kowalczyk]

Wed, 10 May 2000 17:20:44 +0100, Malcolm Wallace <[EMAIL PROTECTED]> pisze:

> > {-# OPTIONS -#include "the-relevant-header.h" #-}
> > at the very top of the module,
> 
> But (a) I don't have such a header file.

So write one.

> (b) Why can't ghc generate the correct prototype for me?

One cause is that it does not have enough information to write
the original prototype exactly, including types under pointers and
constness. It would be bad to not have the possibility of including
the original C header for some typechecking across languages -
a C compiler will complain when it founds inconsistent prototypes.

There is some work in this direction, to let it deduce more exact
prototypes. There exists a proposal of solution which includes handling
pointer types, but I still don't have any good idea to express const
in Haskell. Help!

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: bug in foreign import (for floats)

[Marcin &#x27;Qrczak' Kowalczyk]

Wed, 10 May 2000 16:03:57 +0100, Malcolm Wallace <[EMAIL PROTECTED]> pisze:

> Ghc did emit a warning:
> /tmp/ghc9891.hc:256: warning: implicit declaration of function `floatToInt'
> but I don't know what it means

The warning actually comes from gcc, and it means what it says: the
function floatToInt was not declared, so according to ISO/ANSI C89
rules it got declared implicitly, with special rules of argument
promotions similar to K&R C. (The new C99 does not permit such implicit
declaration any more BTW, neither does C++.)

> or how to avoid it.

Put
{-# OPTIONS -#include "the-relevant-header.h" #-}
at the very top of the module, or add such option to the ghc
invocation (protecting shell metacharacters).

> It did make me suspect that an implicit float->double promotion
> was happening somewhere, but the obvious tests came to a negative
> conclusion on that.

It's exactly float->double promotion that causes the trouble!
But I have not bothered to test it now, sorry.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Blocking I/O & FIFOs

[Marcin &#x27;Qrczak' Kowalczyk]

Wed, 10 May 2000 07:56:06 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:

> I can't repeat this problem; on both Linux/x86 and Solaris/Sparc
> here the Haskell process will block until another process opens
> the FIFO for writing, and will return EOF after the writing process
> closes the FIFO.

I encountered the problem too a few days ago. It does not wait for
another process to open the fifo, but returns EOF immediately.

It works only when another process opened the fifo for writing before
we opened it for reading.

The problem happens in ghc-4.06 and 4.07. It worked OK in 4.04.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

allocaElem in ghc-4.07

[Marcin &#x27;Qrczak' Kowalczyk]

allocaElem :: Storable a => a -> (Addr -> IO a) -> IO a
should be
allocaElem :: Storable a => a -> (Addr -> IO b) -> IO b
and similarly allocaElems.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

ghc -M and {-# OPTIONS #-}

[Marcin &#x27;Qrczak' Kowalczyk]

1. A module starts with {-# OPTIONS -optc-D_GNU_SOURCE #-}
   and ghc -M produces the following dependency:

Examples.o Examples.ptc-D_GNU_SOURCE : ./QForeign.hi

2. {-# OPTIONS #-} are recognized only at the very beginning of a file.
   This causes problem when C2HS adds a comment at the beginning.
   Maybe {-# OPTIONS #-} should be recognized later too?

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Posix.FileMode

[Marcin &#x27;Qrczak' Kowalczyk]

hslibs/posix/doc/posix.sgml says that FileMode is an instance of Eq
and Integral, but in reality it is not. There is no way of examining
FileModes! I will have to reimplement an interface to stat() myself.

BTW, is it really necessary to have separate {union,intersect}fileModes
and nullFileMode instead of using Bits..{|,&}. and 0?

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Strange runtime error

[Marcin &#x27;Qrczak' Kowalczyk]

Mon, 3 Apr 2000 09:24:06 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:

> It happens when some non-monadic (i.e. unsafe) call tries to print
> something to stderr while some other print to stdout or stderr
> is active.

Wouldn't be desirable to change trace to use some lower-level function
like fputs()?

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Monad.guard

[Marcin &#x27;Qrczak' Kowalczyk]

The context of the type signature of Monad.guard in the comment in
the export list says Monad m, where in reality it's MonadPlus m.

Type signatures really should be allowed in export lists :-)

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Fail: thread killed

[Marcin &#x27;Qrczak' Kowalczyk]

Tue, 21 Mar 2000 02:09:40 -0800, Simon Marlow <[EMAIL PROTECTED]> pisze:

> There's a default exception handler installed on all threads forked
> with forkIO, which prints on stderr any exception caught.  Is that
> your objection?

It's OK for other exceptions, but I thought that killing a thread is
not a symptom of an error. So even if it is modelled as an exception,
IMHO this exception should not cause any error message.

OK, I could catch the exception in the thread to be killed, and
synchronize threads at the beginning to prevent a race when it is
killed before the exception handler is entered, but it does not
look nice.

BTW, is it OK to kill a thread that has already exited?

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Fail: thread killed

[Marcin &#x27;Qrczak' Kowalczyk]

IMHO this program should not print "Fail: thread killed". Removing
the first threadDelay causes the message to disappear. It can be
worked around by catching the exception in the thread to be killed.

import Concurrent

kill:: IO ()
kill = do
result   <- newEmptyMVar
finished <- newMVar ()
t1 <- forkIO $ do
threadDelay 1
takeMVar finished
putMVar result ()
t2 <- forkIO $ do
threadDelay 100
takeMVar finished
putMVar result ()
takeMVar result
killThread t2

main:: IO ()
main = kill >> kill

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: -O2 == crash

[Marcin &#x27;Qrczak' Kowalczyk]

Thu, 9 Mar 2000 01:58:02 -0800, Simon Marlow <[EMAIL PROTECTED]> pisze:

> So the likely candidate would appear to be your gcc - which version
> do you have installed?

2.95.1

With -O -O2-for-C it still crashes. With -O it does not.
With -O2-for-C it does not.

(gdb) bt
#0  0x804932a in Main_zn_fast2 ()
#1  0x500c0444 in ?? ()
#2  0x500c1fa4 in ?? ()
#3  0x468bfc45 in ?? ()
Cannot access memory at address 0x8908468b.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

-O2 == crash

[Marcin &#x27;Qrczak' Kowalczyk]

The following code crashes when compiled with -O2. With -O it does
not crash. Some trivial modifications make the crash go away.


import Array(Array, array, (!))
import Random   (StdGen, newStdGen)
import MonadRWS (RWS(..), tell)

type M = RWS () ([((Int,Int),Float)] -> [((Int,Int),Float)]) StdGen

plot:: Int -> Int -> Float -> M ()
plot x y v = tell (((y,x), v):)

plasma:: Int -> Int -> StdGen -> Array (Int,Int) Float
plasma width height gen = a
where

plasma'  = do
plot 0 0 0
subdivide 0 0 width height
(_,_,pixels) = runRWS plasma' () gen
a= array ((0,0), (height-1,width-1)) (pixels [])

subdivide x1 y1 x2 y2 = let
x   = (x1+x2) `div` 2
y   = (y1+y2) `div` 2
x2w = if x2==width  then 0 else x2
y2w = if y2==height then 0 else y2

mid x1' y1' x' y' x2' y2' = do
plot x' y' ((a!(y1',x1')+a!(y2',x2'))/2)

cl = mid x1 y1 x1 y  x1  y2w
uc = mid x1 y1 x  y1 x2w y1
cc = plot x y 0
dr = subdivide x  y  x2 y2
dl = subdivide x1 y  x  y2
ur = subdivide x  y1 x2 y
ul = subdivide x1 y1 x  y

in sequence_ $ case (x2-x1, y2-y1) of
(1,1) -> []
(1,_) -> [cl]
(_,1) -> [uc,dr,dl]
(_,_) -> [cl,uc,cc,dr,dl,ur,ul]

main:: IO ()
main = do
gen <- newStdGen
print (plasma 1 2 gen)


$ ghc -O2 -fglasgow-exts P.hs -o P
$ ./P
zsh: segmentation fault  ./P
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 4.06

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

lex "1x23" == [("123","")] && reads "1x23" == [(123,"")]

[Marcin &#x27;Qrczak' Kowalczyk]

They should not.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

StablePtr Integer == crash

[Marcin &#x27;Qrczak' Kowalczyk]

Crash.hs:

import FFI
import Monad

stringToInteger:: Addr -> IO (StablePtr Integer)
stringToInteger a = addrToString a >>= makeStablePtr . read

integerToString:: StablePtr Integer -> IO Addr
integerToString sp = deRefStablePtr sp >>= stringToAddr . show

addrToString:: Addr -> IO String
addrToString a = do
c <- peek a
if c == '\0'
then return []
else liftM (c:) $ addrToString (a `plusAddr` 1)

stringToAddr:: String -> IO Addr
stringToAddr s = do
let s' = s++"\0"
a <- malloc (length s')
zipWithM (pokeElemOff a) [0..] s'
return a

mul:: StablePtr Integer -> StablePtr Integer -> IO (StablePtr Integer)
mul a b = do
a' <- deRefStablePtr a
b' <- deRefStablePtr b
makeStablePtr (a' * b')

foreign import "test" main :: IO ()
foreign export stringToInteger :: Addr -> IO (StablePtr Integer)
foreign export integerToString :: StablePtr Integer -> IO Addr
foreign export mul :: StablePtr Integer
   -> StablePtr Integer
   -> IO (StablePtr Integer)


crash.c:

#include 
#include "Crash_stub.h"

void test (void)
{
StgStablePtr a = stringToInteger ("101");
StgStablePtr b = stringToInteger ("102");
StgStablePtr c = mul (a, b);
printf ("%s\n", integerToString (c));
a = stringToInteger ("103");
b = stringToInteger ("104");
c = mul (a, b);
printf ("%s\n", integerToString (c));
}


$ ghc -fglasgow-exts -c Crash.hs
$ ghc -c crash.c
$ ghc -fglasgow-exts Crash.o Crash_stub.o crash.o -o crash
$ ./crash
10302
zsh: segmentation fault  ./crash
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 4.06

With related examples I also get "ARR_WORDS object entered!".
Change two definitions:
stringToInteger a  = do s <- addrToString   a;  makeStablePtr (read s)
integerToString sp = do i <- deRefStablePtr sp; stringToAddr  (show i)

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Strange crashes with ForeignObj + foreign export dynamic

[Marcin &#x27;Qrczak' Kowalczyk]

Crash.hs:

import FFI

main:: IO ()
main = do
f <- exportF $ \x -> do
a <- mallocElem x
poke a x
fo <- makeForeignObj a (return ())
look fo
putStrLn "f"
loop f

foreign export dynamic exportF :: (Int -> IO ()) -> IO Addr
foreign import loop :: Addr -> IO ()
foreign import look :: ForeignObj -> IO ()


crash.c:

#include 
#include 

void loop (void (*f) (int))
{
int i = 0;
while (1)
{
printf ("%d\n", ++i);
f (i);
}
}

void look (int *x) {}


ghc -c -fglasgow-exts Crash.hs crash.c
ghc -fglasgow-exts Crash.o Crash_stub.o crash.o -o crash
./crash

It crashes with a segmentation fault after 617 iterations.

Minor changes to the program (even altering the string printed in f)
change the behavior, including preventing the crash.

Linux, ghc-4.06, gcc-2.95.1.



The story (not part of the bug report).

I've made most of a Haskell<->Perl interface for fun. Closures
are convertible in both directions, Perl values can be created and
examined from the Haskell side, abstract values from each language
can be manipulated in the other one, objects not having cycles across
languages are garbage collected. Unfortunately the first non-trivial
example, a Haskell sorting function of values of arbitrary type,
implemented using Perl's sort builtin, crashes when the sorted list
is big enough for the garbage collection to occur. I could not find
my error nor prove that ghc produces wrong code.

I temporarily gave up and made most of a Haskell<->OCaml interface
instead. Closures are convertible in both directions, OCaml values
can be created and examined from the Haskell side, abstract values
from each language can be manipulated in the other one, objects not
having cycles across languages are garbage collected. Unfortunately
the first non-trivial example, a Haskell sorting function of values
of arbitrary type, implemented using OCaml's Sort.array function,
crashes when the sorted list is big enough...

Arrgh! Fortunately I succeeded in extracting a simple Haskell code
that demonstrates the crash.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: litlits in interface files

[Marcin &#x27;Qrczak' Kowalczyk]

Fri, 25 Feb 2000 13:10:24 +0100, Sven Panne <[EMAIL PROTECTED]> 
pisze:

> It's not clear to me how exactly this should be accomplished via
> foreign import. The (well, *my* :-) basic problem is: How do you
> map about 1000 numerical #defines from C header files (OpenGL/GLUT)
> efficiently to Haskell? Saving some STG state, calling out to C land,
> and restoring some state for accessing every value will definitely
> make my binding about 1-2 orders slower.

IMHO the following should be efficient, calling the function only once,
near the time of the first use (if not, should be fixed):

foreign import aConstant :: Int

#include 
int aConstant (void)
{
return A_CONSTANT;
}

A tool could be helpful in massive generating such functions...

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Result type signatures cause parse errors

[Marcin &#x27;Qrczak' Kowalczyk]

Tue, 22 Feb 2000 11:31:23 +0100, Sven Panne <[EMAIL PROTECTED]> 
pisze:

> > f x :: Int = 4
> 
> You have to write `f (x :: Int) = 4' and use -fglasgow-exts in
> this case.

I meant the *result* type signature. GHC user's manual gives the example:

f (x::a) :: [a] = [x,x,x]

The::a part works, but ::[a] does not. Both work in Hugs.

> > g = case [] of [] :: Int -> 4
> 
> [] is definitely not an Int  :-)

Yes, the syntax as described in GHC user's manual is confusing,
but it's really like this. "::Int" applies to 4.

> Hmm, strange. Given
> 
>h1 = \ x :: Int  -> 11
>h2 = \ x :: Int   y :: Bool  -> 22
>h3 = \(x :: Int) (y :: Bool) -> 33
> 
> h1 and h3 work, h2 does not. I wonder why h1 and h3 *do* work...

In h1 "::Int" applies to 11. But the difference between h1 and
\x -> 11 :: Int
is that the type signature can introduce type variables visible inside
the lambda, just like pattern type signatures.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Result type signatures cause parse errors

[Marcin &#x27;Qrczak' Kowalczyk]

For example:

f x :: Int = 4
g = case [] of [] :: Int -> 4

They work only in lambdas.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: explicit typing after `where'

[Marcin &#x27;Qrczak' Kowalczyk]

Mon, 21 Feb 2000 19:31:33 +0300 (MSK), S.D.Mechveliani <[EMAIL PROTECTED]> pisze:

> factorOverFinField_2::--instance overlaps in ghc-4.06 **
> (Field fF, FactorizationRing (UPol fF))
> =>
> UPol (UPol fF) -> Factorization (UPol (UPol fF))
> 
> factorOverFinField_2  f@(UPol _ a v dA) =
>   if
>  isZero f  then  error $ msg "f = 0\n"
>   else   ...
>  pairs++(factorPrimitive $ canAssoc g)
>   where
>   ...
>   factorPrimitive :: (Field fF, FactorizationRing (UPol fF)) 
>  =>
>  UPol (UPol fF)-> Factorization (UPol (UPol fF))
>   factorPrimitive f = ...

Type variables in type signatures scope only over the signatures
themselves. fF in the signature of factorOverFinField_2 is independent
of fF in factorPrimitive. factorPrimitive would have to have the type
you specified (polymorphic wrt. fF), but your implementation, as the
wonderful error message said, provides only a function which shares
the type of field with factorOverFinField_2, not an independently
polymorphic one.

The only place where a type variable is not universally quantified at
the beginning of the type signature it occures in, is a type signature
of a method in a class definition. It is not possible to express the
type signature of your factorPrimitive in Haskell 98 nor in earlier
versions of Haskell.

GHC and Hugs have an extension of pattern type signatures. Read about
them in The GHC User's guide. Write:

factorOverFinField_2 (f@(UPol _ a v dA) :: UPol (UPol fF)) =

or specify the type (mentioning fF) of a component of f, to give a
name for the fF type which is accessible in type signatures local
to this function. Remove the context from the type signature of
factorPrimitive. The fF type variable is already constrained (even
when you omit the type signature of factorOverFinField_2 - well,
the constraint partially results from its usage in factorPrimitive).
The type signature of factorPrimitive merely mentions fF, it does
not introduce it.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Weak pointers, finalizers and SIGSEGV

[Marcin &#x27;Qrczak' Kowalczyk]

I succeeded in replacing finalized Addrs with ForeignObjs, but probably
weak pointers were the problem (and were really unnecessary). Now it
only sometimes crashes at Ctrl-C. The following progam does so too
(about 1/10 of runs):


import Addr
import Foreign
import IO

main:: IO ()
main = do
hSetBuffering stdout NoBuffering
sequence_ . repeat $ do
fo <- malloc 100 >>= mkForeignObj
addForeignFinalizer fo (putStrLn "finalizer" >> free fo)
putStrLn "x"

foreign import malloc :: Int -> IO Addr
foreign import free   :: ForeignObj -> IO ()


-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Weak pointers, finalizers and SIGSEGV

[Marcin &#x27;Qrczak' Kowalczyk]

The following program causes SIGSEGV after a few thousands of
iterations.

I compile with 'ghc test2.hs -o test2 -fglasgow-exts' by ghc-4.06 on
Linux, gcc-2.95.1, glibc-2.1.2. With ghc-4.04 it crashes too.


import Addr
import Weak

kill:: Addr -> IO ()
kill a = do
w <- mkWeakPtr a Nothing
addFinalizer a $
deRefWeak w >> return ()

main:: IO ()
main = sequence_ . repeat $
malloc 100 >>= kill >> putStrLn "x"

foreign import malloc :: Int -> IO Addr


(Am I using weak pointers and finalizers in a legal way?
I want the finalizer itself not to hold the reference.)

The program is extremely sensitive to details. Even altering the
message printed, or the amount of memory mallocated, or replacing
"a >> b" with "do a; b" changes the behavior. It sometimes crashes
only when I press Ctrl-C. Often it crashes in the function evacuate
trying to access memory at the pointer like 0x50052. I hope you will
be able to reproduce and fix it.

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Wish List (Re: False warning about overlapping patterns)

[Marcin &#x27;Qrczak' Kowalczyk]

Sun, 06 Feb 2000 16:45:06 +0100, Sven Panne <[EMAIL PROTECTED]> 
pisze:

> Hmmm, perhaps I should update my (slightly dormant) Wish List...

http://marutea.pms.informatik.uni-muenchen.de/wishlist/
is inaccessible...

-- 
 __("$ P+++ L++>$ E-
  ^^  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-