RE: forcing a haskell object to WHNF from C
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC doesn't compile under cygwin
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. make[1]: Entering directory `/home/lclearwater/ghc-5.04.2/glafp-utils' ===fptools== Recursively making `boot' in mkdependC ltx mkdirhier runstdtest sgmlverb docbook lndir ... PWD = /home/lclearwater/ghc-5.04.2/glafp-utils ==fptools== make boot - --unix -wr; in /home/lclearwater/ghc-5.04.2/glafp-utils/mkdependC ==fptools== make boot - --unix -wr; in /home/lclearwater/ghc-5.04.2/glafp-utils/ltx ==fptools== make boot - --unix -wr; in /home/lclearwater/ghc-5.04.2/glafp-utils/mkdirhier ==fptools== make boot - --unix -wr; in /home/lclearwater/ghc-5.04.2/glafp-utils/runstdtest ==fptools== make boot - --unix -wr; in /home/lclearwater/ghc-5.04.2/glafp-utils/sgmlverb ../../glafp-utils/mkdependC/mkdependC -f .depend -- -O-- sgmlverb.c ==fptools== make boot - --unix -wr; in /home/lclearwater/ghc-5.04.2/glafp-utils/docbook ===fptools== Recursively making `boot' in db2dvi.dir db2html.dir db2pdf.dir db2ps.dir db2rtf.dir ... PWD = /home/lclearwater/ghc-5.04.2/glafp-utils/docbook ==fptools== make boot - --unix - --no-print-directory -r; in /home/lclearwater/ghc-5.04.2/glafp-utils/docbook/db2dvi.dir ==fptools== make boot - --unix - --no-print-directory -r; in /home/lclearwater/ghc-5.04.2/glafp-utils/docbook/db2html.dir ==fptools== make boot - --unix - --no-print-directory -r; in /home/lclearwater/ghc-5.04.2/glafp-utils/docbook/db2pdf.dir ==fptools== make boot - --unix - --no-print-directory -r; in /home/lclearwater/ghc-5.04.2/glafp-utils/docbook/db2ps.dir ==fptools== make boot - --unix - --no-print-directory -r; in /home/lclearwater/ghc-5.04.2/glafp-utils/docbook/db2rtf.dir ===fptools== Finished making `boot' in db2dvi.dir db2html.dir db2pdf.dir db2ps.dir db2rtf.dir ... PWD = /home/lclearwater/ghc-5.04.2/glafp-utils/docbook ==fptools== make boot - --unix -wr; in /home/lclearwater/ghc-5.04.2/glafp-utils/lndir ../../glafp-utils/mkdependC/mkdependC -f .depend -- -O -- lndir.c ===fptools== Finished making `boot' in mkdependC ltx mkdirhier runstdtest sgmlverb docbook lndir ... PWD = /home/lclearwater/ghc-5.04.2/glafp-utils make[1]: Leaving directory `/home/lclearwater/ghc-5.04.2/glafp-utils' make[1]: Entering directory `/home/lclearwater/ghc-5.04.2/glafp-utils'
RE: ghc/cygwin filename resolution issue.
{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
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
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
Re: forcing a haskell object to WHNF from C
Should/can I use rts_eval()? Yes. 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. rts_eval() may cause garbage collection to happen. This means that every HaskellObj value might be invalid after a call to rts_eval (except for the return value). rts_eval starts a new concurrent Haskell thread to do the evaluation. 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). Calls to Haskell are implemented using rts_eval/rts_evalIO too, so writing it in Haskell is the same thing with a little bit more overhead. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
Thanks to all for the replies; Hal's resolution rings a bell, now that I think about it, from Ye Olde Days when cygwin was a ghc pre-req -- just didn't think of it when installing more recently on a new machine. (Install in haste, repent at leisure.) Claus' suggestion about relative paths does the ticket, though: didn't occur to me as the paths were being generated by a configure script, but yes, it was possible to override them, which works as advertised. Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
