Florian Lorenzen schrieb:
I'm trying to run the following program on Solaris 10 with GHC 6.4.1
(6.4.2 does not really work under Solaris 10 right now).
What did you try out with ghc-6.4.2? ghc-6.4.2 does not work _because_
of -threaded. And this inability certainly applies to ghc-6.4.1 as well.
Christian Maeder schrieb:
Your example works for me.
It seemed to work for me even for ghc-6.4.1 (on a sparc)!
-bash-3.00$ ./try
this
is
a
test
-bash-3.00$ ./try
try: waitForProcess: interrupted (Interrupted system call)
Several times trying using ghc-6.4.2 also revealed errors:
-bash-3.00$
On 23 June 2006 17:43, Caio Marcelo wrote:
On 6/23/06, Simon Marlow [EMAIL PROTECTED] wrote:
What did I do wrong?
Did you changed the Judy/Map.hs code to not use Dummy (see below)? The
code I commited is the version with the workaround.
Anyway, I'm going to darcs pull and recompile GHC
Simon Peyton-Jones wrote:
Simon and I have been thinking about fixing this, and we think we
might actually do so for GHC 6.6. Your message provoked us to write
up the design. It's here
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
Feedback welcome
It's worth reading the old threads;
Brian Hulley wrote:
import Gtk/Widget.Button -- instead of grafting
In all cases I think it would be an absolute disaster to allow
modules to be imported without an explicit package id because this
would defeat the whole purpose of having a simple per-package
namespace for modules and
On Mon, Jun 26, 2006 at 04:20:16PM +0100, Brian Hulley wrote:
I don't think this solves the whole problem. Suppose M1 needs to use A.B.C
from P1 *and* A.B.C from P2
For a simple example of a case where this might arise, suppose M1 is the
migration module for data (stored in a database,
Simon,
We covered this extensively in the Cabal vs Haskell thread starting
here: http://www.haskell.org//pipermail/libraries/2005-April/003607.html
You concluded it by saying on April 22:
And this observation points towards a simpler solution: rather than
invisibly pre-pend the package
