Hello,
Where should I send HaskellDirect bug reports:
1. Bug tracker at sourceforge.net/projects/ghc,
2. This mailing list,
3. Something else?
Best wishes,
Kostya Lukin
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
I suggest you send them to Sigbjorn. His email address is above
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of ? ?? ??
| Sent: 11 September 2003 09:11
| To: [EMAIL PROTECTED]
| Subject: HaskellDirect bugs
|
| Hello,
|
| Where
Lunar
Sigbjorn writes:
Yes, delayed threads were put to sleep with incorrect
thread status in ghc-6.x, which I reckon is the problem here.
Fixed a month or two ago in HEAD.
My guess is that the other Win32 bug reports you've forwarded
run across the same
Gregory Wright wrote:
Hello,
I've fixed it in the darwinports version. I patched the linker to try
to find symbols
with and without a leading underscore. I thought I had sent a note to
the list
but perhaps I overlooked doing so.
The underlying issue is that there are versions of dlcompat
On Thursday, September 11, 2003, at 11:27 AM, Wolfgang Thaller wrote:
Sorry for my silence in the past week.
While your patch should work, I remember seeing C code that uses
function names like foo and _foo in the same way that a Haskell
programmer might use foo and foo', so I had a bad feeling
While your patch should work, I remember seeing C code that uses
function names like foo and _foo in the same way that a Haskell
programmer might use foo and foo', so I had a bad feeling about
automatically trying both.
Could I recommend that you use or adapt the autoconf test
Alastair Reid wrote:
Could I recommend that you use or adapt the autoconf test HUGS_TRY_DYNLINK
(hugs98/src/unic/aclocal.m4 in the same cvs repository that has ghc).
I would recommend against this. :-)
This test generates a C object file to be loaded then tries to load the object
file using one
Hello!
Who supports HaskellDirect now?
Best wishes.
Kostya Lukin
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Sigbjorn Finne, still.
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| On Behalf Of ? ?? ??
| Sent: 11 September 2003 08:17
| To: [EMAIL PROTECTED]
| Subject: Who supports HaskellDirect now?
|
| Hello!
|
| Who supports HaskellDirect now?
|
Things aren't so easy with alpha as gcc rejects the -mieee
flag when GHC
calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order.
Is this when running gcc on the Alpha, or on the bootstrapping host?
Cheers,
Simon
___
simonmar:
Things aren't so easy with alpha as gcc rejects the -mieee
flag when GHC
calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order.
Is this when running gcc on the Alpha, or on the bootstrapping host?
alpha-dec-osf3 bootstrapped quite cleanly today. Using the
On Thu, Sep 11, 2003 at 02:21:29PM +1000, Matt Chapman wrote:
On Thu, Sep 11, 2003 at 02:06:57AM +0100, Ian Lynagh wrote:
Bootstrapping IA64 from x86 (with numerous patches from CVS) looks
like it is working fine, although I am getting
ghc-6.0.1(9371): unaligned access to
On Thu, Sep 11, 2003 at 09:52:07AM +0100, Simon Marlow wrote:
Things aren't so easy with alpha as gcc rejects the -mieee
flag when GHC
calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order.
Is this when running gcc on the Alpha, or on the bootstrapping host?
The
The bootstrapping host.
That is expected, then. I've mentioned before that trying to build the
HC files on the bootstrapping host might not work, because these files
are meant to be built on the target. The same goes for the invocation
of gcc itself: it is using flags designed for use on the
| We at GHC HQ agree, and for future extensions we'll move to
| using separate options to enable them rather than lumping
| everything into -fglasgow-exts. This is starting to happen
| already: we have -farrows, -fwith, -fffi (currently implied
| by -fglasgow-exts).
|
| Of course, if we
Regarding M. P. Jones proposal
to move command-line options to the module space,
I would like to reiterate something from an earlier email:
What if you want to express that overlapping instances are
fine for a certain class C but not for the rest? Recasted
to the module speak of MPJ, would that
[[ -- Apologies for multiple copies of this message -- ]]
COORDINATION 2004
Second Call for Papers
Sixth International Conference on Coordination Models and Languages
24-27 February 2004 -- Pisa, Italy
Hello,
Norman Ramsey and I are looking for examples of where higher-rank
polymorphism and existential types are useful. Can anyone think of
uses besides the following?
Higher-rank types are used in:
- Deforestation
Andrew Gill, John Launchbury, and Simon L. Peyton Jones. 1993. A
Karl-Filip Faxen wrote:
| Yes, things are clearer and I rather like the idea.
| The only thorny issue is that the update function for
| field 'wibble' is formed from but not equal to the
| field name itself.
This could be solved by having an abstract type Field
thusly (*):
type Field r a
Karl-Filip Faxen wrote:
| Yes, things are clearer and I rather like the idea.
| The only thorny issue is that the update function for
| field 'wibble' is formed from but not equal to the
| field name itself.
This could be solved by having an abstract type Field
thusly (*):
[snip]
There is no C-- backend for GHC (search the mailing list and you'll see
Simon asking someone to try to do this :P). GHC either generates code by
itself, or generates normal C code (with -fvia-c or -O2, iirc) and then
uses GCC to compile this.
Ah... for some value of normal! It's very
Mark Jones writes:
As a solution to that problem, the many-command-line-options
scheme described seems quite poor! It's far too tool specific,
not particularly scalable, and somewhat troublesome from a software
engineering perspective. We're not talking about a choice between
two points
OK, I yield!
The HEAD now runs this program. It turned out to be a case of
interchanging two lines of code, which is the kind of fix I like.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ashley Yakeley
| Sent: 07 September 2003 06:57
| To:
I don't mind pointing out that either solution, compiler independent
pragmas or extension import lists, would be great for the Library
Infrastructure Project, since it will save us from having to include
per-file command-line flags in a package configuration database (see
my message to [EMAIL
Mark P Jones writes an interesting suggestion:
...
Hmm, ok, but perhaps you're worrying now about having to enumerate
a verbose list of language features at the top of each module you
write. Isn't that going to detract from readability? This is where
the module system wins big! Just
hello,
it's a pity i don't know how to get my mailer to reply to a few messages
at once :-)
i also like mark's idea. i know that ghc can alredy achive some of that
with the OPTION pragmas, but i think it is nice if we can reuse what is
already in the language rather than making programmers
26 matches
Mail list logo
