There's something very suspicious here, but it might be a
bug we know about.
Did you build ghc yourself, from sources? Did you
bootstrap using itself? And finally, exactly what
version of gcc do you have?
J
| -Original Message-
| From: Pixel [mailto:[EMAIL PROTECTED]]
| Sent:
According to the GHC libraries manual, 6.2.1: The Handle
returned by connectTo and
accept is unbuffered by default. However, with such a
handle and hPutStrLn,
I am getting buffering, even when use IO.hSetBuffering to
NoBuffering. When I
put in an explicit hFlush after the
Julian Seward (Intl Vendor) [EMAIL PROTECTED] writes:
% ghci
[...]
Loading package std ... linking ...
/usr/lib/ghc-5.02.2/HSstd.o: unknown symbol `stg_gc_l1'
ghc-5.02.2: panic! (the `impossible' happened, GHC version 5.02.2):
can't load package `std'
[...]
There's
Yes, Sigbjorn is of course right. Disregard my msg ...
J
| Did you bootstrap using itself?
|
| no, that is the pb. Sigbjorn Finne gave the explaination:
|
| GHCi doesn't load the RTS package (nor GMP),
| as they're both baked into the binary. My guess is that
| you've built ghci
I realize that my use of the API was incredibly naïve and
that I should
have been using h* methods with the handle returned from
connectTo. But
it is connectTo that is failing as described.
It fails interactively too with ghci, and regardless of using Server
http or PortNumber 80.
Julian Seward (Intl Vendor) wrote:
| ghc.exe: panic! (the `impossible' happened, GHC version 5.02.1):
| Oversize heap check detected. Please try compiling with -O.
| [...]
Upgrade to 5.02.2, wherein this oversized-heap-check entertainment
is fixed.
Many thanks, Julian! I
I wrote:
I have now upgraded to 5.02.2, which gives me an entirely different
show-stopper bug when using -prof -auto-all:
---begin compilation output
[...output of succesfully compiling a bunch of library modules]
ghc -c -package lang -package concurrent
I don't believe there's a bug in here, only perhaps in
the way the Socket functions are used:
main = withSocketsDo $ do
d - connectTo host port -- (1)
sendTo host port GET / HTTP/1.0\r\n\r\n; -- (2)
response - recvFrom host port; -- (3)
putStrLn response
where
host =
Okay, one quick question:
what do i have to import to get newAddrArray#, readAddrArray#, etc.?
GlaExts (package lang) is currently the right place to get these from.
And, secondly, a correction to the documentation:
under the Allocation section (7.2.14.1), It says:
newCharArray#
On Saturday 12 January 2002 07:31, Ashley Yakeley wrote:
At 2002-01-11 06:18, Jorge Adriano wrote:
The whole problem is with passing the 'r' as a parameter, which is
precisly what I'm trying to avoid.
You could always pass it implicitly (using -fglasgow-exts):
Thanks, at first it seemed to
On 25-Jan-2002, Hal Daume III [EMAIL PROTECTED] wrote:
consider the following definition:
class C a where foo :: a - Int
instance C Bool where foo _ = 5
I can then say:
bar :: C a = a - Int
bar (x :: a) = foo (undefined :: a)
But not:
bar :: C a = a - Int
bar x = foo
Jens Petersen [EMAIL PROTECTED] writes:
Dominic Cooney [EMAIL PROTECTED] writes:
sendTo host port GET / HTTP/1.0\r\n\r\n;
Hmmm, I was trying something more like (under Linux):
do
h - connectTo host port
hPutStrLn h GET / HTTP/1.0\n
response -
| I can then say:
|
| bar :: C a = a - Int
| bar (x :: a) = foo (undefined :: a)
|
| But not:
|
| bar :: C a = a - Int
| bar x = foo (undefined :: a)
|
| because it tries to use a new scope for the type variable a and
| doesn't unify it with the one in the type spec. Why
I've just been looking at using cpp in Haskell scripts and I am rather
confused. I can't see anything in the report which gives
special meaning
to # in the surrounding text of literate scripts, yet if I put such
things in (both cpp directives and random things) both nhc98 and ghc
give me
Just before Section D.1 there is the sentence
When inferring the context for the derived instances, type synonyms must
be expanded out first.
I don't understand it. Which type synonyms need expansion? All the u_n
are type variables.
Besides, this would make deriving even more horrible than it
Has anyone written an efficient purely-functional
implementation of unification (for type checking)? If
not, what makes it difficult to solve the problem in that
way?
David Feuer
This message has been brought to you by the letter alpha and the number pi.
Greetings.
In section 4.1 of Haskell Report for 98:
It is indicated that (-) has kind * - *- * and
t1 - t2 is equivalent to type (-) t1 t2
Does this make (-) a type constructor? Is this an attempt to unify
functions and data types?
Thanks
___
From: Cagdas Ozgenc [EMAIL PROTECTED]
Greetings.
In section 4.1 of Haskell Report for 98:
It is indicated that (-) has kind * - *- * and
t1 - t2 is equivalent to type (-) t1 t2
Does this make (-) a type constructor? Is this an
attempt to unify
functions and data types?
(-) is
David Feuer wrote:
Has anyone written an efficient purely-functional
implementation of unification (for type checking)?
Well, if you have ever used hbc or nhc, you have used type checkers
containing purely functional implementations of unification. Purely
functional unification can be
From: Thomas Hallgren [EMAIL PROTECTED]
David Feuer wrote:
Has anyone written an efficient purely-functional
implementation of unification (for type checking)?
Well, if you have ever used hbc or nhc, you have used
type checkers
containing purely functional implementations of
Any thumb rule for using arrays? I'm expecting access to be
O(1), it is right?
In GHC, yes.
Need to have a set of data, and I just want to get random
elements from that
Set, arrays seem like a good solution... am I right?
If you're building it once and doing lots of access, then
21 matches
Mail list logo
