Re: Readline in GHC-4.02
George Russell wrote: > Has anyone got this combination to work? This is not easily possible with 4.02, because the RTS and the FFI have changed. Some days ago, I sent a patch to the triple-S-team which re-enables Readline in the 4.03 from the CVS repository. If you feel an urgent need for command line editing, check it out... cvs -d :ext:[EMAIL PROTECTED]:/cvs co fpconfig cd fptools cvs co ghc > I've tried quite hard on sparc-solaris, adding the lines : > > GhcLibsWithReadline = YES > ReadlineIncludePath = [...] That's still the magic incantation. [To the Master of Makefiles (tm) at Cambridge: If ReadlineIncludePath is empty, ghc gets a lonely -I flag, munching away the next flag. The cbits/ghcReadline.[ch] are superfluous.] > HAVE_READLINE = YES > [...] Not necessary anymore. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Re: greencard again (what about haskell98?)
[EMAIL PROTECTED] wrote: > I did not manage to compile the hs-file generated by green-card with > ghc-4.02 yet. The output is: > > > bla.hs:54:11: parse error on input: "`" > [...] You have to use the -fglasgow-exts option if your Haskell code or the Green-Card-generated code contains _casm_ (which is the case if the target is ghc). The error message above comes from the lexer complaining about lit-lits, i.e. the stuff between ``...'', when the flag is missing. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
greencard again (what about haskell98?)
Hi again,
I did not manage to compile the hs-file generated by green-card with
ghc-4.02 yet. The output is:
> bla.hs:54:11: parse error on input: "`"
the code:
> mkPE :: Int -> IO Int
> mkPE arg1 =
> _casm_ ``do {int arg1;int res1; -- <:)> this is line 54
> arg1 = (int)%0;
> do {res1 = mkPE(arg1);
>
> %r = (int)(res1);} while(0);} while(0);'' arg1
> >>= \ res1 ->
> (return (res1))
this compiles perfectly well with 4.01. Also, green-card itself does
not compile with 4.02. Should I use haskell-1.4 (ie ghc-4.01) only or
do I miss something?
-Matthias
--
Max-Planck-Institut für Informatik
[EMAIL PROTECTED]
http://www.mpi-sb.mpg.de/~fis
Re: Threads in GHC's RTS
"Manuel M. T. Chakravarty" wrote: > > Michael Hobbs <[EMAIL PROTECTED]> wrote, > > > I don't think that these three FFI types are enough to cover *all* of > > the bases regarding callbacks, blocking, and thread-safety. > > My point here is that, in the RTS, "unsafe", "safe", and > "threadsafe" is enough. The rest is a problem of the > libraries and library bindings. Okay, I can agree to that. :) I thought that you were trying to make a swiss-army-knife, which would enable one to specify every type of behaviour that he would like a foreign function to conform to. > Following the reverse naming scheme of the FFI paper: > > unsafe - the RTS makes no special provisions and just >calls the C function (this means the function >must be well-behaved: no re-entry into the >Haskell scheduler and no blocking if you >don't want to block the whole Haskell system) > safe - the RTS cleans things up, to allow the called >function to re-enter the Haskell scheduler (but >if the function blocks, the whole Haskell >evaluation still blocks) > threadsafe - the RTS executes the foreign call in a > (or supersafe) seperate OS thread (the function can do what >it likes) > > The label does NOT describe a property of the function, but > it describes the strategy of the RTS. For "safe" calls, the > RTS plays safe, for "threadsafe" calls it plays supersafe. > > Manuel So what you have is increasing levels of "safety"? The first one is completely unsafe; it could royally screw up the RTS if it invoked a Haskell callback. The second is more safe; but it may cause the entire RTS to block. And the third is completely safe; nothing it can do will affect the Haskell RTS (within reason). Perhaps we should have a fourth level of safety, where it spawns a new OS process? Ha ha, only [slightly] serious. This works for me, as long as I can still get barrier synchronization like we [Manuel and myself] discussed earlier, but that's another issue. I do think that the use of the word, "safe", is unfortunate though. It seems to be too overloaded. - Michael Hobbs
Re: greencard example does not compile
Sven Panne <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > [...] > > > %fun mirror :: Polar -> Polar > > > %call (< polarToCart / cartToPolar > (int x) (int y)) > > > %code x = -x; > > > % y = -y; > > > %result (< polarToCart / cartToPolar > (int x) (int y)) > > The variable names x and y are not "local enough", so you should try: > > [...] Yes, it works. Thanks! -Matthias -- Max-Planck-Institut für Informatik [EMAIL PROTECTED] http://www.mpi-sb.mpg.de/~fis
Re: greencard example does not compile
[EMAIL PROTECTED] wrote: > > data Polar = P Int Int deriving Show > > > > polarToCart :: Polar -> (Int, Int) > > polarToCart (P a b) = (a, b) > > > > cartToPolar :: (Int, Int) -> Polar > > cartToPolar (a, b) = P a b > > > > %fun mirror :: Polar -> Polar > > %call (< polarToCart / cartToPolar > (int x) (int y)) > > %code x = -x; > > % y = -y; > > %result (< polarToCart / cartToPolar > (int x) (int y)) > > the error is this: > > > [...] > > > > End of search list. > > [...]/2.8.1/cc1 /tmp/cca32238.i -quiet -dumpbase ghc32227.c -O -Wimplicit >-version -fomit-frame-pointer -fno-defer-pop -o ghc32227.s > > GNU C version 2.8.1 (i586-pc-linux-gnu) compiled by GNU C version 2.8.1. > > /tmp/ghc32227.hc:479: redeclaration of `x' > > /tmp/ghc32227.hc:479: `x' previously declared here > > /tmp/ghc32227.hc:479: redeclaration of `y' > > /tmp/ghc32227.hc:479: `y' previously declared here I believe that greencard may not be smart enough to realize that the input variable names are the same as the output variable names. Thus, it redeclares the same variable names twice. Try: > %fun mirror :: Polar -> Polar > %call (< polarToCart / cartToPolar > (int x) (int y)) > %code x_inv = -x; > % y_inv = -y; > %result (< polarToCart / cartToPolar > (int x_inv) (int y_inv)) - Michael Hobbs
Re: greencard example does not compile
[EMAIL PROTECTED] wrote: > [...] > > %fun mirror :: Polar -> Polar > > %call (< polarToCart / cartToPolar > (int x) (int y)) > > %code x = -x; > > % y = -y; > > %result (< polarToCart / cartToPolar > (int x) (int y)) The variable names x and y are not "local enough", so you should try: %fun mirror :: Polar -> Polar %call (< polarToCart / cartToPolar > (int x) (int y)) %code a = -x; % b = -y; %result (< polarToCart / cartToPolar > (int a) (int b)) Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Re: greencard example does not compile
On Fri, 16 Apr 1999 [EMAIL PROTECTED] wrote: > (Btw, does anybody know why ghc4.02 complains about comments starting > with a character different from space (like in ``--:: type'')? This is > certainly not intended, is it?) Last I heard this was a deliberate feature of Haskell 98 so you can define, e.g., -->, -->--, etc as operators. I think a `--' now only starts a comment if its can't be parsed as part of a longer symbol (e.g., "--< Comment >" doesnt work but "--comment" or "-- comment" do.) ___cheers,_dave__ email: [EMAIL PROTECTED] "Someday, even toasters will have www.cs.bris.ac.uk/~tweed/pi.htm monads in them thanks to Haskell." work tel: (0117) 954-5253 M P Jones (allegedly)
greencard example does not compile
Hi, I am playing with greencard a little bit and failed to compile the examples in the documentation. I am using ghc-4.01 (4-02 refuses to compile greencard) and GNU CPP version 2.8.1 (i386 GNU/Linux with ELF). We I make ghc eat the following code (in module Main with a trivial main function): > data Polar = P Int Int deriving Show > > polarToCart :: Polar -> (Int, Int) > polarToCart (P a b) = (a, b) > > cartToPolar :: (Int, Int) -> Polar > cartToPolar (a, b) = P a b > > %fun mirror :: Polar -> Polar > %call (< polarToCart / cartToPolar > (int x) (int y)) > %code x = -x; > % y = -y; > %result (< polarToCart / cartToPolar > (int x) (int y)) the error is this: > [...] > > End of search list. > [...]/2.8.1/cc1 /tmp/cca32238.i -quiet -dumpbase ghc32227.c -O -Wimplicit -version >-fomit-frame-pointer -fno-defer-pop -o ghc32227.s > GNU C version 2.8.1 (i586-pc-linux-gnu) compiled by GNU C version 2.8.1. > /tmp/ghc32227.hc:479: redeclaration of `x' > /tmp/ghc32227.hc:479: `x' previously declared here > /tmp/ghc32227.hc:479: redeclaration of `y' > /tmp/ghc32227.hc:479: `y' previously declared here Is this a problem with gcc? Or should I use ghc3 instead of 4? Also, I did not figure out how to keep ghc from ignoring the ``-keep-hc-file-too option''. Is it because the hc file is corrupted that ghc does not want me to look at it? I would really like to get this running, the greencard idea looks very convenient. thanks for any hints, -Matthias (Btw, does anybody know why ghc4.02 complains about comments starting with a character different from space (like in ``--:: type'')? This is certainly not intended, is it?)
