charset="US-ASCII";
charset="US-ASCII";
charset="US-ASCII";
charset="US-ASCII";
charset="US-ASCII"
Reply-To: [EMAIL PROTECTED]
Date: Wed, 25 Sep 2002 01:19:00 +0300
X-Priority: 3
X-Library: Indy 9.00.10
X-Mailer: Foxmail
Kemoterapinin yan etkileri nedeniyle yorgun ve bi
Hi,
if I enter
ghc -o foo foo.hs
under Windows, is the resulting executable named foo or foo.exe?
(Please send replies not only to the list as I'm not subscribed to it.)
Wolfgang
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www
Hi again.
Thanks for the feedback.
> > The only way I know to make all this work is to use a straightforward
> > Cygwin environment for building (with absolutely no mingw
> > stuff in your
> > path) and use --with-gcc in your configure line. Other
> > things may work,
> > but you're on your own
Title: Chipworks Inside Technology
Be competitive, rank your
technology,
and see what the competition is doing in the following
just
released circuit analysis reports and publications.
Recent
Koen Claessen <[EMAIL PROTECTED]> writes:
> However, I for example have no idea what happens when unsafely
> executing something that throws exceptions, performs a forkIO,
> something that uses MVar's, etc.
I won't dare to try to characterize the difference exactly but you
should expect very dif
Koen
Based on this info, how would you like to write the notes you would like
to see on unsafePerformIO? The starting point is at
http://haskell.cs.yale.edu/ghc/docs/latest/html/base/GHC.IOBase.html#uns
afePerformIO
If you write the notes, we'll check their veracity and add them. We'll
do the
"Dominic Cooney" <[EMAIL PROTECTED]> writes:
>
> I complained late last week that GHC failed to build because ghc-inplace
> couldn't do anything more complicated than print its version number.
>
> I tried again on a clean machine, this time remembering to replace
> Cygwin's sh.exe with bash.exe, a
> | In retrospect I think that unless "configure" is doing something
> really
> | tricky, if you want the Mingw32 "ar" and "ld" to be picked
> up instead
> of the
> | Cygwin equivalents then you must have the Mingw32 bin directory in
> your path
> | ahead of the Cygwin bin directory.
>
> The rig
| In retrospect I think that unless "configure" is doing something
really
| tricky, if you want the Mingw32 "ar" and "ld" to be picked up instead
of the
| Cygwin equivalents then you must have the Mingw32 bin directory in
your path
| ahead of the Cygwin bin directory.
The right thing to do is wha
Actually...
I said in my previous reply:
"Having said that, specifying the C compiler by your method is better as you
never know when a shell script or tool might temporarily modify the path.
(sh and /etc/profile being a known candidate for doing this behind your
back)."
In retrospect I thi
Great! Simon M is going to take a look when he has a moment. Meanwhile I'd like to
encourage those of you who are keen on this stuff [Duncan, Andre?] to write up
(a) how to use it (in SGML, to add to the user manual); see
fptools/ghc/docs/using
(b) how it is im
> But it is a fact that many of us have at least some idea of
> what happens "under the hood" when we use unsafePerformIO.
> This is also described in your paper "Stretching the storage
> manager: weak pointers and stable names in Haskell".
>
> However, I for example have no idea what happens whe
> I ran strace with -ff option. Attached is the trace file. I
> can see many "No
> such file or directory" in the trace. Can you see the problem?
Here's the problem line:
[pid 1514] execve("n/sh", ["/bin/sh", "-c", "gcc Adjustor.c -o
/tmp/ghc1513.s"...], [/* 36 vars */]) = -1 ENOENT (No such
> On our system (Solaris) the interpreter takes all available
> CPU time just
> waiting for input. The problem seems to be restricted to our site and
> to the latest release of ghc (5.04). We really need to fix
> this problem
> since many of us are using SunRays with a shared server. Any
> ide
Hi Simon.
You're the victim of my first sentence which was obfuscated by simultaneous
attempts at humour and a "bad memory" disclaimer - sorry - my wife always
tells me not to make up my own jokes! (Oops.)
"To build yesterday's CVS HEAD (previously autoconfed) using Windows 2000,
GHC 5.04.1, an
Hi,
On our system (Solaris) the interpreter takes all available CPU time just
waiting for input. The problem seems to be restricted to our site and
to the latest release of ghc (5.04). We really need to fix this problem
since many of us are using SunRays with a shared server. Any idea of what
may
Simon Peyton-Jones wrote:
| The actions performed by unsafePerformIO are simply
| done at some entirely unpredictable time, perhaps
| interleaved with actions on the main execution path.
But it is a fact that many of us have at least some idea of
what happens "under the hood" when we use unsa
The actions performed by unsafePerformIO are simply done at some
entirely unpredictable time, perhaps interleaved with actions on the
main execution path.
The formal semantics in the notes doesn't have a good way to express
that because the purely-functional part is given a denotational
semantic
| I tried again on a clean machine, this time remembering to replace
| Cygwin's sh.exe with bash.exe, and mounting C:\mingw as /mingw and
| C:\mingw\include as /mingw/mingw32/include.
You should not need the latter two step, if you use the --with-gcc
option
to configure, as the building guide ad
| make clean; ./configure --build=mingw >& configure.log
PS: I should have said
* Before autoconf, mv ./configure configure-save. (It's not writable
so autoconf fails otherwise.)
* rm config.cache (maybe it's remembering out of date info)
___
Gl
| - Run the following following commands:
|
| export PATH=/cygdrive/c/lang/mingw32/bin::${PATH}
|
| make clean; ./configure --build=mingw >& configure.log
Uh oh. You aren't following the instructions in Section 12.4 of the GHC
building guide!
http://haskell.cs.yale.edu/ghc/docs/latest/
21 matches
Mail list logo
