Remi Turk wrote:
[...] When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc
--with-gcc=/usr/local/bin/gcc3
[...]
Slightly off-topic: You don't need --enable-hopengl anymore when compiling
GHC 6.4 or the
CVS HEAD, the OpenGL/GLUT/OpenAL
Georg Martius wrote:
Hi,
Patrick and I found some answers to the questions/problems we encountered.
Finally got the thing to work. (patches appended)
Great!
I have a possible fix:
add -odir out/... to the call of ghc -M. This produces correct paths
for the .o files.
Ok, this makes sense and,
The original code in the makefile.lib replaced
(basename input.hs) with (basename output.o)
and
*.hi with *.o
which is a quite weird approach to the problem. I'am not sure but I
think the new approach is better:
let the .o files be correct through the -odir flag
replace (dir
On Fri, 2005-02-18 at 02:18 +0100, Ralf Laemmel wrote:
Here I assume that you don't _really_ depend on ClassB to be a
superclass of ClassA. (Why would you?)
Ok, here's what the real class head is (or was before I butchered it to
make it work);
class (Data (DictXMLData h) a, XMLNamespace a) =
On 18 February 2005 01:02, Donald Bruce Stewart wrote:
This is a known problem with gcc-2.95.
We came across it back in September.
It was noticed in the nightly builds:
http://www.haskell.org/pipermail/cvs-all/2004-September/035116.html
And then we chased it up:
On 18 February 2005 09:38, Remi Turk wrote:
On Thu, Feb 17, 2005 at 11:29:41AM -, Simon Marlow wrote:
I've noticed gcc 2.95 crashing on my FreeBSD box too. I should
look into whether there's a workaround, otherwise we're hosed on
FreeBSD 4.x.
(though I now assume it probably isn't
I seem to remember that if you define the class:
class DictXMLData h = XMLData h ...
instance (Data d a,XMLNamespace a) = XMLData d where ...
then providing you annotate the instance functions with the relavent
scoped type variables (d and a) then the compiler will infer XMLNamespace
correctly for
Having looked at some of my source code this relies on Data having a
functional dependancy such that:
class Data d a | d - a ...
So it might not work for what you want.
Keean.
Keean Schupke wrote:
I seem to remember that if you define the class:
class DictXMLData h = XMLData h ...
instance
Whoops, I should have tried it first. Amazingly, this seems to works.
But I'm not sure I understand why, a still depends on XMLNamespace,
because of the dictionary instance;
instance (Data (DictXMLData b) a, XMLHook b a, XMLData b a, XMLNamespace
a) = Sat (DictXMLData b a) where
But I guess it's
Simon Marlow wrote:
On 18 February 2005 04:26, Seth Kurtzberg wrote:
At least this proves that it isn't a hardware problem. :)
Seth, you're a bit confused. This error from gcc is a deterministic,
repeatable, crash due to a known bug in gcc 2.95.
You were
Seth Kurtzberg [EMAIL PROTECTED] writes:
Simon, you'll never give up. The crashes are absolutely repeatable.
The fact that I haven't identified a deterministic way to reproduce them
does not in any way imply that a deterministic way to reproduce them
does not exist. And, as I've said,
On 17 February 2005 20:24, Georg Martius wrote:
2. Stub files (@Simon)
The problem I ran into was that the FILE_stub.o files are not placed
at the correct(?) directory according to the position of FILE in the
hierarchical library.
Example:
ghc -c wxcore/src/Graphics/UI/WXCore/Events.hs -o
On 18 February 2005 10:17, Seth Kurtzberg wrote:
Simon, you'll never give up. The crashes are absolutely repeatable.
The fact that I haven't identified a deterministic way to reproduce
them does not in any way imply that a deterministic way to reproduce
them does not exist. And, as I've
When I compile a simple code importing Control.Monad.State with
ghc-6.4.20050217 on Linux I get linking errors:
% cat foo.hs
import Control.Monad.State
main = putStr Hello\n
% ghc foo.hs
foo.o(.text+0x145): In function `__stginit_Main_':
: undefined reference to
Akos Korosmezey wrote:
When I compile a simple code importing Control.Monad.State with
ghc-6.4.20050217 on Linux I get linking errors: [...]
You have to use -package mtl when --make is not used, because mtl (where
Control.Monad.State resides) is not an auto package, for more details see:
I wrote a little data structure with quantified constructors:
module MyModule where
import Data.Generics
import Data.HashTable
data Item = forall a. (Data a) = Leaf Bool a
| forall a. (Data a) = Branch Bool a Int Int
Hi Simon (PJ),
cc Simon (DF),
I rather reckon we are facing a bug here.
The attached minimalised Foo.hs shows the offending code pattern.
With GHC 6.2 we get *** Exception: loop
With GHC 6.4 we get(still waiting for the rest of the string)
The scenario is about class/instance-head-level
It is called gunfold rather than gunfoldl
as you will see when you browse the Data.Generics.Basics.
Also, your gunfold code looks like it will not work.
Here is a simple example for Maybe:
gunfold k z con =
case constrIndex con of
1 - z Nothing -- no children
2 - k (z
Hello
I am having problems with the threaded rts (6.5.20050207)
dying with 'schedule: re-entered unsafely'. The same code
seems to work with 6.2.2 with threaded rts.
The exact error message is:
foo: schedule: re-entered unsafely.
Perhaps a 'foreign import unsafe' should be 'safe'?
I
On 18 February 2005 22:15, Einar Karttunen wrote:
I am having problems with the threaded rts (6.5.20050207)
dying with 'schedule: re-entered unsafely'. The same code
seems to work with 6.2.2 with threaded rts.
The exact error message is:
foo: schedule: re-entered unsafely.
Perhaps a
Hi,
Compiling 6.4.20050217 on Windows according to the book fails pretty early:
snippet
/cygdrive/c/ghc/ghc-6.2.2/bin//ghc -H16m -O -I. -Rghc-timing -I../../../librari
es -fglasgow-exts -no-recomp-c Compat/RawSystem.hs -o Compat/RawSystem.o -o
hi Compat/RawSystem.hi
Simon Marlow wrote:
On 18 February 2005 10:17, Seth Kurtzberg wrote:
Simon, you'll never give up. The crashes are absolutely repeatable.
The fact that I haven't identified a deterministic way to reproduce
them does not in any way imply that a deterministic way to reproduce
them
22 matches
Mail list logo
