Simon Marlow wrote:
On 29/04/2009 01:23, Sigbjorn Finne wrote:
Thanks Simon,
sorry for not noticing your reply amidst the flow of g-h-b ticket
reports
before now. As there is no need to sail that close to the wind of
playing with the delicate linking & loading orders of the CRT and
base
rn
On 4/27/2009 04:58, Simon Marlow wrote:
On 24/04/2009 23:04, Sigbjorn Finne wrote:
I've been experiencing repeated woes over the past 4-5 months
when trying to spin up build trees on Windows with the new build
system. This is happening on the 3-4 boxes that I regularly develop on,
which
/2009 11:38, Sigbjorn Finne wrote:
On 4/25/2009 05:37, Ian Lynagh wrote:
Hi Sigbjorn,
On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote:
I've been experiencing repeated woes over the past 4-5 months
when trying to spin up build trees on Windows with the new build
system.
On 4/25/2009 05:37, Ian Lynagh wrote:
Hi Sigbjorn,
On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote:
I've been experiencing repeated woes over the past 4-5 months
when trying to spin up build trees on Windows with the new build
system.
By "new build system&qu
Hi,
I've been experiencing repeated woes over the past 4-5 months
when trying to spin up build trees on Windows with the new build
system. This is happening on the 3-4 boxes that I regularly develop on,
which leads me to believe that this may not be limited to just me..
The problem is that hsc2h
If you're referring to ghc-pkg-inplace invocations from Cabal, the
same hack was applied in utils/ghc-pkg also.
--sigbjorn
On 3/6/2007 08:46, Simon Marlow wrote:
Ah, so you did, thanks for reminding me. We still need to do
something about ghc-pkg, though.
Cheers,
Simon
Sigbjorn
I added support for generating .bat files (to HEAD, I believe) for these
in-place
wrappers some time ago just to address this issue, so you may want to
look into
dragging those Makefile mods over.
--sigbjorn
On 3/5/2007 08:58, GHC wrote:
#1196: Cabal on Windows doesn't like the in-place GHCs
Ought to (but don't sue me if it doesn't.)
--sigbjorn
Bulat Ziganshin wrote:
Hello Sigbjorn,
Tuesday, October 31, 2006, 10:04:52 PM, you wrote:
is that means that current 6.6 precompiled snapshots like
http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20061031-i386-unknown-mingw32.tar.gz
sh
[Due to a somewhat inconvenient HD meltdown some weeks ago, I lost a bunch
of data/user settings amongst other things, including the password to
GHC's Trac,
hence this lame response directly to the mailing list]
I fixed this one a week or two ago on the 6.6 branch --
http://www.haskell.org/
ocal/Temp/ghc5440_0
C:\sd\satnams\haskell\hello>
-Original Message-
From: Sigbjorn Finne [mailto:[EMAIL PROTECTED]
Sent: 18 October 2006 14:03
To: Satnam Singh
Cc: GHC-bugs list
Subject: Re: ghc-6.6 on Windows Vista: "cannot exec as"
Thanks; for people that don't have acce
Thanks; for people that don't have access to Vista, the output resulting
from 'ghc -v Hello.hs' would help narrowing this down a bit...I hope.
--sigbjorn
Satnam Singh wrote:
I just installed GHC-6.6. on Windows Vista RC1 (using the MSI
installer) but when I compile I get the error:
c:\sd\s
This is a long standing, irksome Win32 timing issue, and is not
GC related (AFAICR, it was reproducible in straight C code).
A better workaround, which was experimented with in STABLE
at some point, is to simply delay the clean up of the files until
the end of hsc2hs's run
--sigbjorn
GHC wrote:
The fix is trivial though (and have been applied to HEAD) --
http://hackage.haskell.org/trac/ghc/ticket/588
--sigbjorn
GHC wrote:
#882: Overflow bug in System.Time
---+
Reporter: simonpj |Owner:
But as long as it's Haskell code consuming all those CPU cycles,
it can't be all bad? :)
If any of you are running into this while invoking "ghci.exe",
you may want to play with using "ghc.exe --interactive" instead
to see if that improves matters. Not using "ghci.exe" avoids
a layer of sub-proce
Hi,
if you desugar the definition that's causing the type error,
perhaps it becomes a little bit clearer what's going on, i.e.,
from
problematic :: MyAnnotatedType Int
problematic = defaultVal{theInt=42,theAnnotation=10}
you expand this to
problematic' = case defaultVal of { MAT a b c -> MAT 4
The previous bug was in the handling of .bss sections for relocatable
object files in the RTS linker -- the fix is included in STABLE. It's
not clear that it would apply in this context though.
I'm not able to reproduce this one with last night's STABLE build.
Perhaps the bug reporter could add d
Yep, reproducible with last night's HEAD build on mingw
(but not STABLE.)
--sigbjorn
- Original Message -
From: "Simon Peyton-Jones" <[EMAIL PROTECTED]>
To: "wld" <[EMAIL PROTECTED]>;
Sent: Friday, December 16, 2005 08:13
Subject: RE: Bug in cvs head ghci
Strange. This does not ha
much sense.
Given the two networking issues you've already come
across, I wouldn't discount the option that this might
be due to a local problem with your networking setup
(WinSock proxy config..?)
--sigbjorn
- Original Message -
From: "Arias" <[EMAIL PROTECTED]>
To
It was intentionally removed (the intention being to remove
heft from the installer) after it had been unintentionally
included for quite a while.
The rule has always been that only tools that GHC depends
upon to operate are bundled with it on the mingw side --
the only exception to that rule has
Hi,
that error message is a bit confusing, to say the least:
getProtocolByName identifies itself as getServiceEntry
when failing. In this case, I'm quite sure, your snippet
fails because (getProtocolByName "tcp") isn't successful.
I've no idea why your /etc/protocols doesn't contain an entry
for
FYI - widening the (testing) audience a bit.
--sigbjorn
- Original Message -
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 22, 2005 13:59
Subject: 6.4.1 win32 candidate installer
With 6.4.1 being close to done, I
en try to link the object file with ghc, but I don't
think that's the case here.
--sigbjorn
- Original Message -
From: "Alastair Reid" <[EMAIL PROTECTED]>
To: "Sigbjorn Finne" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, August 22, 2005 06:16
Subject:
Puzzling; couple of things to check for:
- nm -o c:/ghc/ghc-6.2.2/libHSbase.a | grep 'T ___stginit_Prelude'
is successful.
- the TMPDIR setting appears to be w:/tmp -- make sure that actually
exists & isn't clogged up. Does changing it to "." (or somesuch) alter
the behaviour?
- does an inv
"Simon Marlow" <[EMAIL PROTECTED]> writes:
...
No - read() can always return less than the requested amount of data,
even when not in O_NONBLOCK mode.
Hmm, care to give some details as to why you equate "can" with
"always will" on all platforms?
--sigbjorn
___
"Simon Marlow" <[EMAIL PROTECTED]> writes:
On 11 August 2005 01:18, John Meacham wrote:
Why do we set file descriptors to nonblocking mode anyway if they are
waited on by a select. there shouldn't be a need to use both
It avoids an extra system call per read(), i.e. a single read() instead
of
to confusion about the layout of 'struct
dirent'.
- Original Message -
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Monday, August 08, 2005 10:38
Subject: Re: getDirectoryContents fails in GHC 6.5 snapshots,works in GHC
6.
Main.lhs
*** Exception: C:\temp\bugs\getDirectoryContents:
getDirectoryContents: failed (
No error)
This indicates to me that there is not any problem with my filesystem.
Instead, it seems like it is likely a problem with the linker. Now, I
see what the cause of the problem is:
http://www.haske
Bulat Ziganshin <[EMAIL PROTECTED]> writes:
SF> That's an impressive reduction in size; compressing the
SF> CAB file inside the MSI using the LZW-based compressor
SF> that Microsoft provides with their 'makecab' utility didn't
LZX (very different from LZW, born long ago, in 1984)
btw, while wr
stribution tree is a good
one & plan to do that for the next release. It can then be used
to derive other distribution/installer formats.
--sigbjorn
- Original Message -
From: "Bulat Ziganshin" <[EMAIL PROTECTED]>
To: "Sigbjorn Finne" <[EMAIL PROTECTED
One e-mail regarding this would do.. :)
The 6.4 installer has a UI bug that may prevent you from using
it on a box where you don't have admin privs. Try starting up the installer,
hit Next, followed by Back. That should bring up a dialog letting you choose
whether to perform a user or machine wide
Ditto w/ HEAD -- the compilation error refers to '&stderr'.
For that to work, 'stderr' has to be an lvalue, which is an
unsound assumption (mingw defines it as "&(_iob[STDERR_FILENO])".)
--sigbjorn
- Original Message -
From: "Conal Elliott" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, April 26,
Did you do a 'cvs up' with the -d option to have it create
new directories? ghc/lib/compat/include contains directory.h,
and is a fairly new addition.
--sigbjorn
- Original Message -
From: "David Duke" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, April 26, 2005 06:59
Subject: Build problem from
"Simon Marlow" <[EMAIL PROTECTED]> writes:
...
Prelude> System.system "ls" >>= print
*** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist
(No such fi le or directory)
Prelude> System.Cmd.rawSystem "ls" [] >>= print
_viminfo getname.pl index.html
ExitSuccess
Prelude> System.system
Hi,
8 == ERROR_NOT_ENOUGH_MEMORY, which sounds
reasonable (albeit cryptic) since Win32 has a default user
process size limit of 2Gb.
--sigbjorn
- Original Message -
From: "Andreas Marth" <[EMAIL PROTECTED]>
To:
Sent: Thursday, January 13, 2005 07:41
Subject: misaligned block returned
Hi
Fixed now on the STABLE branch, but 6.2.2 and, at least,
all previous 6.x releases suffer from this embarrassing mem
leak. Thanks for reporting the problem.
--sigbjorn
- Original Message -
From: "Simon Marlow" <[EMAIL PROTECTED]>
To: "Philippa Cowderoy" <[EMAIL PROTECTED]>;
<[EMAIL PROTEC
"Jon Fairbairn" <[EMAIL PROTECTED]> writes:
On 2004-10-29 at 00:50BST Ben Rudiak-Gould wrote:
Jon Fairbairn wrote:
Well, here's a sample session I recorded just now:
C:\>\ghc\ghc-6.2.1\bin\ghci
Prelude> let p = 1 : [2 * x | x <- p, x < 1] in p
[1*** Exception: <>
Prelude> 123
Fail: thre
"Claus Reinke" <[EMAIL PROTECTED]> writes:
...
>
> PS. I never was quite sure why Haskell systems need an installer
> on Windows? There used to be Haskell libraries for accessing
> the registry, so filetype-associations and Start menu entries
> could be done optionally, by a little se
Hi Arjan,
the underlying GNU binutils issue which causes this was
fixed some 9 months ago. I've been using a new mingw
binutils snapshot for a while which includes it -- it's
available from
http://www.mingw.org/download.shtml
(look for binutils-2.15.90-20040222.)
You'll still see the warnin
MessageThanks, tidied up a while back - 6.2.1 includes the fix.
--sigbjorn
- Original Message -
From: herington, dean
To: '[EMAIL PROTECTED]'
Sent: Monday, May 03, 2004 08:07
Subject: heap exhausted error
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interac
I take that partially back, there does seem to be an issue
with "c:/Program Files/" installs; I'll try to look into it.
Still puzzled as to why your c:/ghc/ghc-6.2.1/ fails though.
--sigbjorn
- Original Message -
From: "Sigbjorn Finne" <[EMAIL PROTECTED]
Peter Strand" <[EMAIL PROTECTED]>
To: "GHC users" <[EMAIL PROTECTED]>
Sent: Friday, March 12, 2004 09:33
Subject: Re: Release Candidate for 6.2.1 available
> Sigbjorn Finne wrote:
>
> >An installer for Windows users can now also be found in
> >that direc
I don't have access to a Win9x system right now, but
could you try compiling your example w/ 6.2 as follows:
ghc -o main
main.hs -pgma"c:\\ghc\\ghc-6.2\\gcc.exe -B\"C:\GHC\GHC-6.2\gcc-lib/\""
(minus any line wrapping my e-mail client will no doubt introduce.)
--sigbjorn
- Original Message
Hi,
thanks for the report. The handling of heap overflows
on your platform has been cleaned up in the current
sources, see:
http://haskell.org/pipermail/glasgow-haskell-bugs/2003-October/003699.html
http://haskell.org/pipermail/cvs-ghc/2003-October/018987.html
--sigbjorn
- Original Message
builders on win32.
--sigbjorn
- Original Message -
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: "Pasch, Thomas (ACTGRO)" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, October 24, 2003 15:17
Subject: Re: Overflown relocs in ghci
> Hi,
Hi,
it looks as if you're running into a GNU ld/BFD bug
where it emits bogus PE object files that have more than
0x relocations. The last time I looked this bug still
wasn't fixed in the BFD codebase & there wasn't any
noticeable interest in fixing it when I reported the bug
a year or two ago.
Thanks for the report. That unnecessary copying operation
was removed in HEAD a couple of months back; the upcoming
6.2 release includes the changes.
--sigbjorn
- Original Message -
From: "Abraham Egnor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, October 11, 2003 08:07
S
Hi there,
thanks for pointing this one out -- the CVS version of renameFile now
behaves uniformly across platforms.
--sigbjorn
- Original Message -
From: "Ben Horsfall" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 07, 2003 21:48
Subject: renameFile in GHC 6.0 (Windows)
Sigh, this time with an attachement..
- Original Message -
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: "Simon Peyton-Jones" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, June 23,
I tidied up this aspect of TclHaskell / FranTk as part of a Galois
project a while ago. Attached are the as-is changes needed to
avoid being dependent on RTS internals & stop doing a busy wait.
In addition to these diffs, you also want to comment out the defn of
isOnlyProcess in TclCompatibilityGh
Yes, examples/ie-listen/ in the HDirect distrib demonstrates
how to sink events (from IE, in that particular example.)
--sigbjorn
[btw, the CVS version of HDirect was updated a while ago to
work with current versions of GHC & Hugs.]
- Original Message -
From: "Paul Steckler" <[EMAIL PRO
e" <[EMAIL PROTECTED]>
To: "Simon Peyton-Jones" <[EMAIL PROTECTED]>; "Sigbjorn Finne"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, March 07, 2003 11:06
Subject: getProtocolNumber garbage (was: Network on Win98: failed - socket -
no error ?
Something's up with your WinSock setup on that machine,
I suspect -- works fine on the Win98 box I tested it on.
You may want to investigate whether the 'identical' client
written in C (or some such) behaves as expected on that
box..
The HEAD version of the 'network' package tidies up the
propagat
If you're mixing code compiled and linked with different
versions of binutils / gcc, then you're pretty much on your
own - i.e., I'm assuming you didn't build pdcurses via
'ghc' but 'gcc' & 'ld'/'dllwrap'.
--sigbjorn
- Original Message -
From: "michael vorin" <[EMAIL PROTECTED]>
To: <[EMA
Hi,
thanks for the report. Now fixed.
--sigbjorn
- Original Message -
From: "Dean Herington" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 23, 2002 09:14
Subject: import ambiguity
> With the program:
>
> import Exception
> main = let cat
That would take care of the incompatibility here, but
it's a slippery slope. Should Haskell provide you with
a platform-independent view of filenames and file
systems?
--sigbjorn
- Original Message -
From: "Simon Peyton-Jones" <[EMAIL PROTECTED]>
To: "Sigbjor
This is known behaviour of the MS CRT implementation
of stat() on directories -- trailing slashes will cause it to
report ENOENT.
Undesirable behaviour, you might (reasonably) say, but
the format of FilePaths is left system-specific by Haskell98.
--sigbjorn
- Original Message -
From: "
Oops, while trivial, I forgot to include the main.c test
wrapper:
foo$ cat main.c
#include
extern int invokeCmd(char* cmd);
int main() {
printf("%d\n", invokeCmd("uname"));
return 0;
}
--sigbjorn
- Original Message -----
From: "Sigbjorn Finne" &
ly the only valuable piece
of info to take away from all this.
May I suggest the GHC downloads page drops the claim
that the 5.04.1 RPMs will work under RH7.2?
--sigbjorn
----- Original Message -
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: "Saswat Anand" &l
Hi there,
we've been running into similar problems here on a Redhat 7.2
box using the ghc-5.04.1 RPM (which was built on RedHat 7.3).
The salient line from your strace output is the following one:
[pid 1514] execve("n/sh", ["/bin/sh", "-c", "gcc Adjustor.c
-o /tmp/ghc1513.s"...], [/* 36 vars */
"Kirsten Chevalier" <[EMAIL PROTECTED]> writes:
> On Thu, Sep 05, 2002 at 12:20:27PM -0700, Sigbjorn Finne wrote:
> > To enable type checking of Core, compile with -dcore-lint
> >
>
> Ah, thanks. You'd think it would do that by default when s
To enable type checking of Core, compile with -dcore-lint
--sigbjorn
- Original Message -
From: "Kirsten Chevalier" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 05, 2002 12:05
Subject: External Core typechecker
> GHC doesn't seem to do much typechecking on exte
"Dean Herington" <[EMAIL PROTECTED]> writes:
> >
> > The assumption is that FDs are marked as non-blocking, so this won't
> > be a problem. Do you have a good reason not to have your FDs marked
> > as such?
>
> One reason is complexity. If I mark my FDs with O_NONBLOCK, don't I need
to
> wrap a
"Dean Herington" <[EMAIL PROTECTED]> writes:
>
...
>
> When a thread wants to read from a file descriptor, its logic looks like:
>
> threadWaitRead (fdToInt fd)
> ([char], 1) <- locked (fdRead fd 1)
>
> where `locked` obtains and holds the aforementioned lock for the duration
of
>
n the MS installer with logging turned on. If you
could either send or point me at a copy of the resulting log
file, msi.log, that'd be very helpful in trying to narrow down
the cause of this.
thanks
--sigbjorn
- Original Message -
From: "Sigbjorn Finne" <[EMAIL PROTECTED]&g
Thanks for the report, forwarded to the bugs list.
It should be noted that the installer currently assumes
that you're an administrator on the machine you're
using.
--sigbjorn
- Original Message -
From: "Stephen Eldridge" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 1
Hi,
this appears to be GC-related; forwarded to the
bugs list. Thanks for the report.
--sigbjorn
- Original Message -
From: "Mark Tehver" <[EMAIL PROTECTED]>
To: "Sigbjorn Finne" <[EMAIL PROTECTED]>
Sent: Saturday, July 13, 2002 07:38
Subject: crash w
Hi,
looks as if you're mixing mingw and cygwin object
files. ghc-5.04 is mingw-based, so make sure you
feed in the flag -mno-cygwin to gcc when compiling
.c files.
--sigbjorn
- Original Message -
From: "Mark Tehver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 11, 20
You don't say, but I'm assuming you're using a recent'ish
GHC snapshot. A wibble that prevented the system/standard
RNG from being seeded with a time-varying value was fixed
sometime last week, so 5.04 will have it included.
--sigbjorn
- Original Message -
From: "Ian Lynagh" <[EMAIL PRO
"Koen Claessen" <[EMAIL PROTECTED]> writes:
>
...
>
> However, ghci crashes at start up time! I get the following
> behavior:
>
> >>>
> [lap/bin] -: ./ghci
...
>
> Loading package base ... linking ...
> /d/Work/Packages/Ghc/Install/lib/ghc-5.03/HSbase_cbits.o:
> unknown symbol `_sigaddset'
> g
"Jon Fairbairn" <[EMAIL PROTECTED]> writes:
> > Anyway, a new 5.02.3 installer which I _believe_ works around
> > the problem is available as:
> >
> >http://galois.com/~sof/ghc-5-02-3-1.msi
> >
> > It's a big download (~21M), but if you could try it out & let me
> > know if it improves matt
Hi there,
thanks for the report - Andre reported the same problem a while
ago, but I forgot to respond to him after having tracked down
the cause of the problem (sorry, Andre.)
Anyway, a new 5.02.3 installer which I _believe_ works around
the problem is available as:
http://galois.com/~sof/g
lowed by a re-make in ghc/compiler. That "solves"
the problem for me.
--sigbjorn
- Original Message -
From: "Kirsten Chevalier" <[EMAIL PROTECTED]>
To: "Sigbjorn Finne" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, May 13, 2002 1
A spot of CVS archeology revealed that it was removed as
a primop as part of a NCG overhaul couple of months ago.
Don't know if leaving it out was simply an omission or
if there's something deeper going on.
Anyway, you can approximate the old defn with the following:
module PtrEq where
import G
[moved to glasgow-haskell-bugs]
"Wolfgang Thaller" <[EMAIL PROTECTED]> writes:
>
...
>
> Due too my lack of Perl knowledge, I didn't yet manage to remove the
> jumps from the slow to the fast entry points, and a function called
> __DISCARD__ must be present for linking (it's never called, thou
Hi,
I added Win32 support for these a while ago; the 5.03
snapshot includes it.
--sigbjorn
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 27, 2002 23:37
Subject: IO.hReady, hWaitForInput differ on Linux / Windows
> Hi there,
>
> I'm us
Hi,
looks like a bona fide bug; thanks for reporting it. In order to
be able to fix it, any chance of you sending us that Main.hs?
thanks,
--sigbjorn
- Original Message -
From: "Loffler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 25, 2002 12:47
Subject: (no subj
Hi,
you're making a mountain out of a molehill; couple of
workarounds spring to mind:
* transform the -i path you feed to GHC -M, i.e., something
like
ghc -M -i`cygpath -w -s "c:\Program Files\GreenCard"`/lib/ghc
* post-process the generated dependencies file to insert the double
Strange, the following compiles just fine with
5.02.1 on a Win2k box:
module Foo where { import Pretty ; x y = y Pretty.$+$ y }
--sigbjorn
- Original Message -
From: "Duncan Coutts" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 17, 2002 16:13
Subject: 'Pretty' does
Simon may have gone home for the weekend, so just
to let you know that he's checked in a fix for this
problem in the current CVS sources.
--sigbjorn
- Original Message -
From: "Peter White" <[EMAIL PROTECTED]>
To: "Simon Marlow" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, Febr
"Pasch, Thomas (ACTGRO)" <[EMAIL PROTECTED]> writes:
> $ ghc -package javavm -c Class_java_awt_Component.hs -o
> Class_java_awt_Component.o
> d:\Programme\ghc\ghc-5.02.2\bin\ghc.exe: fatal error: Windows programs can
> only use 256Mb of heap; sorry!
>
> Hello,
>
> is there anything I can change
Hi,
thanks for a fine bug report. The panic you're running
into is something that could be handled more gracefully
by the compiler.
Workaround is simple, just add -fvia-C to your GHC
command-line.
--sigbjorn
btw, I'd encourage you to make your Postgres Haskell
binding available to other Haskel
A test Windows Installer for the 5.03 snapshot release is now
available via
http://galois.com/~sof/ghc-5.03-20020208.msi (25.2M)
Unless I hear of any fatal flaws encountered using it or I
discover glitches while sleeping, it will go up on
haskell.org/ghc/ tomorrow morning (PST).
--sigbjorn
You have to give more details than this; GHC does support
both '/' and '\' as path separator (but, of course, doesn't understand
nonsense like /cygdrive prefixes).
That GHC doesn't depend on cygwin is a feature, not a bug
(but if you want it to, you can compile it up for that 'platform'
instead).
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 = "lo
Hi,
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 using 5.02.1; you need to use 5.02.2
(i.e., do two stage build.) The missing symbol was
introduced in 5.02.2's RTS.
hth
--sigbjorn
- Original Message -
From: "Pixe
"Antony Courtney" <[EMAIL PROTECTED]> writes:
>
...
> Skipping HavenTest( HavenTest.hs, ./HavenTest.o )
> PEi386 object has suspiciously large string table; > 64k relocs?
> ghc.exe: panic! (the `impossible' happened, GHC version 5.02.1):
> loadObj: failed
>
Hi,
this is a known
--with-hc only configures what's used to compile 'generic' Haskell
code (i.e., not the contens of ghc/compiler). (As Simon suggests),
use --with-ghc to control what GHC to to use to compile the
compiler bits, i.e.,
./configure --with-ghc=/usr/local/bin/ghc-5.02.2 \
--with-hc=
Hi,
the current contents of the CVS repository will require a little
bit of work before it is possible to do a cygwin build using
a mingw-based version of GHC (which ghc-5.02.2 is).
If you're content to do a mingw build instead, try running the
configure script with the extra option
--host=i386-
In preparation for a ghc-5.03 snapshot release, a
test installer for Win32 platforms is now available:
http://www.galois.com/~sof/ghc-503.msi (*)
Size: 25.1 Mb.
Please let me know if you run into any problems with it.
thanks,
--sigbjorn
btw, Mike Thomas deserves a special mention for
In preparation for the upcoming release of 5.02.2, I've
made available a test installer for Win32 platforms, in the
hope that any packaging glitches can be caught before it's
too late. The installer is available via
http://www.galois.com/~sof/ghc-502-2.msi (*)
It's big: 21.7 Mb.
Please l
Hi,
yep, it's a bug in SocketPrim.recvFrom - it's busted in 5.02.1, I'm afraid.
It fails to init the 'fromlen' arg before calling recvfrom() + it doesn't
work with connection-oriented sockets (not that the latter is affecting
you here), which is why it fails to unravel the SockAddr once
recvfrom(
Thanks, I've made Hugs98 comply with the Report.
--sigbjorn
- Original Message -
From: "Ian Lynagh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, December 09, 2001 10:43
Subject: --+ not treated as a start of a comment
>
> If I have
>
> foo = 0 --+ 1
>
> then ghc te
Hi,
the bug fixer may have contacted you separately, but for
the benefit of the mailing list and/or you, this one has now
been fixed (i.e., deriving empty datatypes is not permitted).
Thanks for reporting it.
--sigbjorn
- Original Message -
From: "Hal Daume III" <[EMAIL PROTECTED]>
To:
Hi,
thanks for the report. First off, I should say that the 5.02 release
didn't focus on DLL production at all, so I'm not too surprised you're
coming across a gremlin or two.
However, I'm not able to reproduce the break you're experiencing,
my --mk-dll tests break much earlier than that. If you
Hi,
you don't say how you processed that example .gc file with GreenCard,
but I'm guessing you used the '--target ghc' option. If that's the case,
have
a look at
http://www.haskell.org/greencard/type-sig.html#SEC-BODY
which discusses safe vs. unsafe calls -- i.e., in your case you need to
cha
irect doesn't currently handle 'const' qualifiers as well as it
could.
--sigbjorn
- Original Message -
From: "Mike Thomas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Sigbjorn Finne" <[EMAIL PROTECTED]>
Sent: Wednesday, November 07, 20
The native code generator only handles 'foreign import's with a
static target, which is why you're seeing this (HEAD handles
this situation a little bit more gracefully).
Use -fvia-C (or -O, which implicitly does the same thing).
--sigbjorn
- Original Message -
From: "Volker Stolz" <[EM
Hi,
couple of things:
* you don't have to side-effect mk/config.mk{.in} to make
any changes to the definitions in there. Just create your own
mk/build.mk and add definitions of variables you need for
your build tree to work/behave as expected. The build.mk
defns override those in mk/
Simon Marlow <[EMAIL PROTECTED]> writes:
>
> Having just looked at the code, it seems we could recover the
> platform-independentness in the I/O library with just a small amount of
> wrapperage: most of the offending code is in PrelPosix.hsc, with a few
> #const's scattered around PrelHandle and P
"Alastair David Reid" <[EMAIL PROTECTED]> writes:
>
> > So, bringing back the solution of having manually written C wrapper
> > functions which platform-independent Haskell source files will call
> > out to, would be preferable (in short, avoid the use of hsc2hs *or
> > any other extra tool* all
1 - 100 of 660 matches
Mail list logo
