Re: Profiling trouble
Hello, something interesting turned up again. Setting cut=8 in Show2.hs and running it with ./show +RTS -h -i0.01 gives show: fatal error: main thread has been GC'd It may be silly, since 0.01 1/50, but this error message isn't too helpful. Btw, +RTS -? says: -imsec Time between heap samples (msec, default: 100) which is wrong (time is given in seconds really). One more question: is there a way not to truncate the call stacks? Ie in the hp file I see lines like (144)showData2/showData/ma... 12 and I'd like to see showData2/showData/main or so. Cheers: Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc/cygwin filename resolution issue.
Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some horrible problems with inconistent treatment of filenames, especially when using (gnu, cygwin) make. In a nutshell, make seems to be passing paths such as /usr/local/hmake (etc) to ghc, which is, as I understand it, interpretting these in a manner consistent with windows, but not with cygwin. (i.e., it'd expect the above to be something like: /cygwin/usr/local/hmake, where the root of the cygwin installation is in c:\cygwin. Experimenting with similar arguments to ghc by hand seems to confirm this. Is there a work-around for this, or is using cygwin and ghc together just an out and out bad idea? Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
It's been a while since I've installed GHC on Windows, but I believe back when I did it (5.00 or something), you needed to have cygwin installed in c:\, not c:\cygwin, despite cygwin's protests. I don't know if this has changed, though. - Hal -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Tue, 28 Jan 2003, Alex Ferguson wrote: Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some horrible problems with inconistent treatment of filenames, especially when using (gnu, cygwin) make. In a nutshell, make seems to be passing paths such as /usr/local/hmake (etc) to ghc, which is, as I understand it, interpretting these in a manner consistent with windows, but not with cygwin. (i.e., it'd expect the above to be something like: /cygwin/usr/local/hmake, where the root of the cygwin installation is in c:\cygwin. Experimenting with similar arguments to ghc by hand seems to confirm this. Is there a work-around for this, or is using cygwin and ghc together just an out and out bad idea? Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some
horrible problems with inconistent treatment of filenames, especially
when using (gnu, cygwin) make. In a nutshell, make seems to be passing
paths such as /usr/local/hmake (etc) to ghc, which is, as I understand
it, interpretting these in a manner consistent with windows, but not with
cygwin. (i.e., it'd expect the above to be something like:
/cygwin/usr/local/hmake, where the root of the cygwin installation is in
c:\cygwin. Experimenting with similar arguments to ghc by hand seems to
confirm this.
Is there a work-around for this, or is using cygwin and ghc together just
an out and out bad idea?
{another candidate for the ghc faq?-}
I'd say using absolute paths is a bad idea. cygwin/ghc is my main development
environment, and mostly problem-free. The pure-windows-ghc did cause the
occasional headache with third-party tools, but the problem has so far not been
on the cygwin or ghc side, but always in unwarranted assumptions in the
construction of build processes.
In the examples I've seen of this conflict, the makefiles in question explicitly
forced the use of absolute paths at some point or other. If you absolutely have
to do this, 'cygpath' is your friend, ideally used at the places where those makefiles
insist on doing ROOT=`pwd` or the like.. (if you can't catch the problem there at
the root, you can still try to convert the paths before passing them to ghc proper,
but that might become messy).
The one occasion where this wasn't sufficient to resolve the issue was in the
case of nhc, compiled by ghc, but that was because ghc-compiled executables
also don't know about cygwin paths, and the nhc make system relies on feeding
the generated tools with absolute paths during the make process in a variety of
ways (AFAIR) - not impossible to resolve, but would be a lot of work..
[fiddling with the mount points may lead to other problems - I never saw
a reason to try that]
Cheers,
Claus
$ cygpath --help
Usage: cygpath [-p|--path] (-u|--unix)|(-w|--windows [-s|--short-name]) filename
-a|--absolute output absolute path
-c|--close handle close handle (for use in captured process)
-f|--file fileread file for input path information
-i|--ignore ignore missing argument
-p|--path filename argument is a path
-s|--short-name print Windows short form of filename
-u|--unix print Unix form of filename
-v|--version output version information and exit
-w|--windows print Windows form of filename
-A|--allusers use `All Users' instead of current user for -D, -P
-D|--desktop output `Desktop' directory and exit
-P|--smprograms output Start Menu `Programs' directory and exit
-S|--sysdir output system directory and exit
-W|--windir output `Windows' directory and exit
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
