Hi,
just noticed your Q re: Makefiles - this is a classic case of
not having set the environment variable MAKE_MODE to UNIX.
GNU make on Win32 needs it set so to operate in 'unix' mode as
opposed to DOS mode.
hth
--sigbjorn
Hi,
first time poster, long time listener :-) Possibly a known one, but the
NCG in 4.08.1 doesn't emit suitably decorated names when calling
out to 'foreign import'ed functions that use the stdcall calling convention,
e.g.,
sof$ cat foo.hs
module Foo { foreign import stdcall decorateMe :: IO
isn't right in 4.08 (or the CVS repo.) If the assumption is that ForeignObj
cannot be mutated once created (which looks like being the case now since
writeForeignObj is marked as deprecated), the defn should be something like:
makeForeignObj :: Addr - Addr - IO ForeignObj
makeForeignObj adr
.
--sigbjorn
-Original Message-
From: Martijn [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 31, 2000 10:09
To: Sigbjorn Finne
Subject: RE: Socket.hs problem under Windows 2000
Hi Sigbjorn,
I'm sorry to bother you again, but in my eyes you're the
socket Guru, so if
anyone
Ketil Malde [EMAIL PROTECTED] writes:
Incredibly tiny nit, but in the final section about compiling stubs,
I believe you mean -fPIC as the gcc option (the documentation says
-fPCI, which isn't something gcc recognizes).
Thanks, fixed.
You might also want to point out that debian packages
Volker Stolz [EMAIL PROTECTED] writes:
My happy is 1.10, everything fresh from cvs:
---
checking for happy... /home/stolz/Linux/haskell/ghc-4.08.1/bin/happy
checking for version of happy...
Happy version 1.9 or later is required to compile GHC.
---
And in a sense, it is right. I'd really
Martin Norbck [EMAIL PROTECTED] writes:
Hi!
a :: Show c = c - Integer
a err = if b 0 then error (show err) else 1
b :: Integer
b = a "dummy"
This program (although it doesn't do much good), type checks perfectly
in hugs. (I have a larger version which actually does some good as
"T.J. Brown" [EMAIL PROTECTED] writes:
I'm trying to write a program (in C) that calls a
function that is implemented in Haskell.
...
The problem I'm seeing is that depending
on the size of the buffer, the program segmentation
faults. I don't see any obvious reason that this is
happening
I'm able to reproduce this here too -- forwarded
to glasgow-haskell-bugs; I'm no longer involved
debugging GHC bits.
--sigbjorn
- Original Message -
From: "T.J. Brown" [EMAIL PROTECTED]
To: "Sigbjorn Finne" [EMAIL PROTECTED]
Sent: Monday, February 12, 20
The problem is indeed that the wrong __init_Foo is being passed to
startupHaskell.
No, that's not it. I've been able to repro this with __init_ConvertProxy
too - did you test it? (This is with 4.08.1 on a Win2k box.)
--sigbjorn
___
[EMAIL PROTECTED] writes:
There seems to be a problem in the gc parser in the cvs (updated two
minutes ago; see the output below). I am using ghc-4.08.1 and
happy1.9. I do not need gc myself at the moment, but I am happy to
try any magic spells you give me in case it's a problem with my
Mike Thomas [EMAIL PROTECTED] writes:
After compiling the HDirect 0.17 sources using GHC 4.08.2 and the latest
Cygwin internet distribution (some small mods made to deal with Cygwin
B20isms in the C source code):
dlltool --output-lib liburlmon.a --def urlmon.def --dllname urlmon.dll
Hi,
I've checked in a fix for this to the CVS repo (was
bitten by the very same problem here), so hopefully
a release of ghc-win32 will have that fix included at
some stage.
--sigbjorn
Krasimir Angelov [EMAIL PROTECTED] writes:
Problem while I use Dynamic libraries from C side.
Prims.o,
Defining an app-local version of defaultsHook() is currently
not possible using just a binary distribution. i.e., to do something
interesting inside of defaultsHook(), you need to side-effect
RtsFlags (which has type RTS_FLAGS). RTS_FLAGS is
defined in RtsFlags.h, which is not to be found in a
Reuben Thomas [EMAIL PROTECTED] writes:
BUG 2: Under Windows 98 Sigbjorn's example Win32 hello world program
displays but then hangs when the window close icon is clicked. Works OK
under NT, and can be closed under Windows 98 by ^C in the terminal
window.
I'm unable to repro this
I've had this very change sitting on my disk for quite a while;
now checked in. Unless further testing uncovers anything
really bad, 5.02 should have it included.
--sigbjorn
- Original Message -
From: Reuben Thomas [EMAIL PROTECTED]
To: Moore, Paul [EMAIL PROTECTED]
Cc: [EMAIL
hi,
you're running into trouble with some expeditious hacks that were
put into TclHaskell to make it work with ghc-4.xx. The following
change will make it compile with ghc-5.xx - have Check.h now
contain:
extern StgTSO *run_queue_hd;
#if __GLASGOW_HASKELL__ = 408
extern StgTSO *MainTSO; /*
Yuck. If this isn't enough to convince people that hsc2hs is not
an appropriate tool (at least in the context of the Prelude
and hslibs/), than I don't know what is.
It commits to a particular platform at too early a stage -- details
of C header files are often best left toC source files
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* alltogether).
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 PrelIO,
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
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
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, 2001 15:42
Subject: HDirect (CVS version) - some bugs
Hi
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
Yes, non-interactive uses of the Win32 library appear to
be in a non-working state (at least with my copy of ghc-5.02,
don't know if there's been any stealth updates to the installer
binary.)
As a stop-gap measure, replace ghc-5.02's libHSwin32.a
(after having saved it away) with the one
To make this panic go away, try adding the option
"-fvia-C" to your GHC
command line.
(GHC could give a better error msg here, and
indicate that you have to
use -fvia-C with code that (still) uses
_casm_.)
hth
--sigbjorn
- Original Message -
From:
Monique Louise
To:
Nothing deep going on, the profiling interface files for the 'util'
package are simply just missing from the 5.02 distribution.
--sigbjorn
- Original Message -
From: P Jensen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October 12, 2001 14:00
Subject: GHC-5.02/Win32: problems
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
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:
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 tells me
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
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
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 issue
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:
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 =
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'
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
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
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 in order to
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, February 15,
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 not
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
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 subject)
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 using
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
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 17:26
Subject: Re: External Core front-end in GHC 5.03
On Wed
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'
ghc-5.03: panic!
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, 2002
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 with GHC 5.04
Hi again,
I have run
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]
To: [EMAIL PROTECTED]
Cc: Stephen
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
its argument
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 external
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 starting from
an external Core file (hint :-))
It actually
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 [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday
Oops, while trivial, I forgot to include the main.c test
wrapper:
foo$ cat main.c
#include stdio.h
extern int invokeCmd(char* cmd);
int main() {
printf(%d\n, invokeCmd(uname));
return 0;
}
--sigbjorn
- Original Message -
From: Sigbjorn Finne [EMAIL PROTECTED]
To: [EMAIL
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: Sigbjorn Finne [EMAIL PROTECTED]; Claus
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 catch =
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: [EMAIL
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
[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 ??)
okay, after giving myself a day to recover from the frustration,
I've given it fresh try today
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
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
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, 2003 12:53
Subject: Re: GHCi bug - the impossible happened loading
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
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.
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,
it looks as if you're running into a GNU ld/BFD
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
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 -pgmac:\\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
[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 directory.
- Original Message -
From: Simon Marlow [EMAIL
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
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
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: loop
Prelude 123
Fail: thread
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 PROTECTED]
Cc:
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: glasgow-haskell-bugs@haskell.org
Sent: Thursday, January 13, 2005 07:41
Subject:
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 false = print
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: glasgow-haskell-bugs@haskell.org
Sent: Tuesday, April 26, 2005
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: glasgow-haskell-bugs@haskell.org
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
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]
Cc: glasgow-haskell-bugs@haskell.org
Sent: Wednesday, May 18, 2005 23:09
Subject: Re[2]: Feature
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
to confusion about the layout of 'struct
dirent'.
- Original Message -
From: Sigbjorn Finne [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: glasgow-haskell-bugs@haskell.org
Sent: Monday, August 08, 2005 10:38
Subject: Re: getDirectoryContents fails in GHC 6.5 snapshots,works in GHC
6.4.1
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
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
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
, but I don't
think that's the case here.
--sigbjorn
- Original Message -
From: Alastair Reid [EMAIL PROTECTED]
To: Sigbjorn Finne [EMAIL PROTECTED]
Cc: glasgow-haskell-bugs@haskell.org
Sent: Monday, August 22, 2005 06:16
Subject: RE: Undefined symbols on new install of ghc 6.2.2
Thanks
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've rolled an MSI
test installer
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
.
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: Sigbjorn Finne [EMAIL PROTECTED]
Cc
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]; glasgow-haskell-bugs@haskell.org
Sent: Friday, December 16, 2005 08:13
Subject: RE: Bug in cvs head ghci
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
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
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:
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
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:
-
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 access to Vista, the output resulting
from 'ghc -v Hello.hs' would help narrowing this down a bit...I
[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 --
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
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
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 Finne
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
201 - 300 of 408 matches
Mail list logo
