January 2003 - Glasgow-haskell-users

Re: ghc/cygwin filename resolution issue.
by George Russell 29 Jan '03

29 Jan '03

Alex wrote [snip] > 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. [snip] The UniForM/HTk distribution includes the attached very simple Haskell98 program, which is compiled and run during the ./configure stage. This program transforms stdin to stdout, globally replacing the string "#PWD" with whatever GHC thinks the current directory is called. This program is used in various ways; in particular ./configure uses it to set a variable GHCTOP corresponding to GHC's name for the top of the source distribution, which is then what gets passed to GHC. The program is also used for various unholy tricks involving package config files, which also of course need the Windows name. Fortunately GHC doesn't mind if some slashes are the wrong way; thus if GHCTOP is "C:\foo\bar\uni", then I can refer to "C:\foo\bar\uni\baz" as $GHCTOP/baz, as it would be on Unix. {- This program converts stdin to stdout. It replaces all occurrences of the string "#PWD" in stdin with the current directory in which it is executed, C escaped. The string "#pwd" is similarly replaced, except that it is not escaped. Everything else is left unchanged. If an argument is supplied, this is used instead of the current directory. The program occupies an unusual place in the UniForM sources; it is not part of the main sources, but is only used during building (see suffix.mk) and is compiled during configuration. Since it only uses completely standard Haskell 98, this ought to be pretty easy. We do things this way rather than with some sort of script so that this will work even in the extremely hostile environment of Windows (with no cygwin). Also, using GHC's getCurrentDirectory means we get at what GHC thinks the current directory is (IE the Windows file name) rather than what it is in cygwin's Unix world. -} module Main (main) where import Directory import System main :: IO () main = do input <- getContents args <- getArgs toInsert <- case args of [arg] -> return arg [] -> getCurrentDirectory let escapeString s = let withQuotes @ ('\"':rest) = show s in take (length rest - 1) rest quoted = escapeString toInsert transform [] = [] transform ('#':'P':'W':'D':rest) = quoted ++ transform rest transform ('#':'p':'w':'d':rest) = toInsert ++ transform rest transform (c:rest) = c:transform rest putStr . transform $ input

1 0

RE: ghc/cygwin filename resolution issue.
by Simon Marlow 29 Jan '03

29 Jan '03

> {another candidate for the ghc faq?-} By all means - or possibly the section of the Building Guide devoted to Win32 builds. Would anyone like to write a concise description of the filename issues on Windows/cygwin/GHC for the docs? I'm certainly not an expert here, but I believe the problems stem from trying to use pathnames that have special meaning to cygwin tools. GHC is not built with cygwin (at least not by default) so there's no special pathname processing going on except that '/' is accepted instead of '\', IIRC. I don't think you have to install cygwin in C:\. At least, my installation is under C:\cygwin, and I'm pretty sure it worked to build GHC last time I tried. Cheers, Simon

1 0

RE: forcing a haskell object to WHNF from C
by Simon Marlow 29 Jan '03

29 Jan '03

> This might seem like a strange thing to do, but ... > > Presume I have a HaskellObj in some C code. I know that it is a thunk. > I want to force it to _WHNF_ . > > Should/can I use rts_eval()? > > Any pointers on what this does (start new threads, cause > garbage collection > ...) would be appreciated. I can (and have) gone over the > code but a more > high level description would be helpful. > > Or perhaps there is another/better way. > > In essence I want a C version of seq (perhaps I can call to Haskell to > perform a seq on it, but I think this might be overkill). > > A lightweight solution would be nice. rts_eval() is the right way to do it, but it isn't particularly lightweight: it creates a new thread to do the evaluation. I imagine you could have a special-purpose thread that you keep around purely for doing these evaluations, if efficiency is important to you. Cheers, Simon

1 0

GHC doesn't compile under cygwin
by Chris Clearwater 28 Jan '03

28 Jan '03

Hi, today I installed cygwin and downloaded the GHC source, however during compilation I get the errors: test: 504: unknown operand test: 500: unknown operand test: 504: unknown operand In addition,I get many Error [127] (ignored) and Error [1] (ignored) before finally quiting with the unknown operand errors. Attached is the configure output, confiure log and make output. Thanks in advance for any help.

1 0

ghc/cygwin filename resolution issue.
by Alex Ferguson 28 Jan '03

28 Jan '03

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.

3 2

RE: Profiling trouble
by Simon Marlow 28 Jan '03

28 Jan '03

> With 5.04 I get almost the same, look: > > COST CENTRE MODULE %time %alloc > > showData1 Main 87.1 89.2 > ncEps Epsilon 3.6 3.4 > cutAbove4 Tcsa 2.6 1.2 > > > individual inherited > COST CENTRE MODULE no. entries %time > %alloc %time %alloc > > MAIN MAIN 1 0 0.0 > 0.0 100.0 100.0 > main Main 165 0 0.1 > 0.0 100.0 100.0 > [...] > showData Main 173 1 0.0 > 0.0 91.5 92.1 > showData2 Main 178 0 0.0 > 0.0 0.0 0.0 > showData3 Main 177 0 0.0 > 0.0 0.0 0.0 > showData4 Main 176 0 0.1 > 0.1 0.1 0.1 > showData5 Main 175 0 0.0 > 0.0 0.3 0.3 > myShow Main 200 9453 0.3 > 0.3 0.3 0.3 > showData1 Main 174 0 87.1 > 89.2 91.1 91.7 > cutAbove Tcsa 181 0 0.0 > 0.0 2.6 1.2 > cutAbove2 Tcsa 199 1 0.0 > 0.0 0.0 0.0 > cutAbove3 Tcsa 193 27 0.0 > 0.0 0.0 0.0 > cutAbove4 Tcsa 182 0 2.6 > 1.2 2.6 1.2 > spinSelect Tcsa 180 1 0.0 > 0.0 0.0 0.0 > getStates Tcsa 179 1 0.9 > 1.0 1.4 1.2 > incrementalBase Fermion 189 1 0.4 > 0.2 0.5 0.2 > fermionNumber Fermion 192 77664 0.1 > 0.0 0.1 0.0 > mergeUp Boson 184 6 0.0 > 0.0 0.0 0.0 > allTowers Boson 183 0 0.0 > 0.0 0.0 0.0 > inModule Boson 185 17 0.0 > 0.0 0.0 0.0 > [...] It looks from the profile that the showData1 cost centre has widened in scope to encompass some extra code. This may be because of incorrect transformations made by the compiler (transformations in the presence of cost-centre annotations have to be done very carefully, and I'm sure the compiler currently has bugs in this area). If you could send us a smaller example that displays the problem, we'll be happy to look into it. Cheers, Simon

2 2

RE: problem using ffi with profiling
by Simon Marlow 27 Jan '03

27 Jan '03

> Sure. The relevant files look like: [... snipped ...] -prof automatically turns on -fvia-C (because the native code generator can't generate code for profiling), so I'm guessing that -prof is a red herring and you'll get the same result if you just turn on -fvia-C. When compiling with the native code generator, any include files specified in FFI declarations or with -#include options are ignored. Perhaps you need to add an appropriate -I flag to the command line so the C compiler can find the header files? Cheers, Simon

2 1

RE: problem using ffi with profiling
by Simon Marlow 27 Jan '03

27 Jan '03

> I'm having difficulty compiling something with profiling which uses > ffi. It compiles fine without profiling, but not with: ... > Any idea why there would be a difference? Not sure. Could you send the output with -v? Cheers, Simon

2 1

RE: Profiling trouble
by Simon Marlow 27 Jan '03

27 Jan '03

> Please help me understanding GHC 5.02.2 profiling output! Please upgrade your version of GHC - lots of bugs have been fixed in later versions. ... > cutStates = {-# SCC "showData1" #-} > getStates params ... > My question: showData1 is a single function call, how can it > still have such a big individual share? Where is the > program spending its time? Sorry if it is a trivial > question, functional profiling is new to me. The answer is that I don't know, from your program it does indeed look like showData1 should be showing the cost of doing the call, nothing more. Try with a newer version of GHC and see if you get the same results. Cheers, Simon

2 1

RE: incremental linking?
by Simon Marlow 27 Jan '03

27 Jan '03

> [Simon] might be worth adding to the docs (title: linking > times on Suns, > Sun's ld vs GNU ld; explanation: see previous mails)? See http://www.haskell.org/ghc/docs/latest/html/users_guide/faq.html specifically the last question. Cheers, Simon

1 0