- Glasgow-haskell-users

RE: runInteractiveProcess is broken
by Simon Marlow 18 May '05

18 May '05

I can't repeat this, it works here: *Main> test1 ExitSuccess *Main> test2 Just ExitSuccess (after changing /usr/bin/sleep to /bin/sleep). The only thing I can think of is that you somehow have a SIGCHLD handler that calls wait(), but I don't see where that can be happening. GHC doesn't have any other mechanism for calling wait(), so I don't understand how the zombies are disappearing before waitForProcess is called. Maybe run it through strace and send us the output? Cheers, Simon On 26 October 2004 19:00, Peter Simons wrote: > Neither of these functions returns the return code of the > external process as promised: > > import System.IO hiding ( catch, try ) > import System.Process > import Control.Concurrent > > sleep :: Int -> IO () > sleep n = threadDelay (abs(n) * 1000000) > > test1 :: IO () > test1 = do > (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] > Nothing Nothing sleep 5 > rc <- waitForProcess pid > print rc > > -- *Main> test1 > -- *** Exception: waitForProcess: does not exist (No child > processes) > > test2 :: IO () > test2 = do > (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] > Nothing Nothing sleep 5 > rc <- getProcessExitCode pid > print rc > > -- *Main> test2 > -- Nothing > > I'm using the ghc from CVS-HEAD on Linux/x86. > > Peter > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

Parser for Glasgow Extensions?
by mcnster 18 May '05

18 May '05

Hello there, Has anyone written a version of libraries/haskell-src/Language/Haskell/Parser.ly (and friends) to parse the language plus Glasgow extensions? I have code with | <- guards that the current parser barfs on. - the mcnster -

2 1

RE: runghc, ".hs" suffix
by Simon Marlow 18 May '05

18 May '05

I'm working on this. It's not trivial because GHC assumes all over the place that the suffix on a file determines how it should be compiled, but I've now implemented something similar to gcc's -x flag. Cheers, Simon On 14 May 2005 20:04, Frederik Eaton wrote: > (moving to a separate thread) > > Also, how hard would it be to make it so that runghc doesn't require > script file names to end with ".hs"? Some people like to keep their > executable names language-neutral. > > Frederik > > On Wed, May 11, 2005 at 10:55:03AM +0100, Simon Marlow wrote: >> On 11 May 2005 07:37, Frederik Eaton wrote: >> >>> It looks like runghc is exiting with status 0 if there is a >>> problem. Shouldn't this be non-zero? >>> >>> $ runghc -V >>> The Glorious Glasgow Haskell Compilation System, version 6.4 $ >>> runghc /dev/null; echo $? Could not find module `/dev/null': >>> use -v to see a list of the files searched for >>> (one of the roots of the dependency analysis) >>> >>> <interactive>:1:76: >>> Failed to load interface for `Main': >>> Could not find module `Main': >>> it is not a module in the current program, or in any known >>> package. 0 >> >> It turns out I fixed this bug after 6.4, but later the fix was >> accidentally reverted. So thanks for reporting this again, it'll >> work properly in 6.4.1. >> >> Cheers, >> Simon >> > > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

2 1

RE: Re[2]: Unicode source files
by Simon Marlow 17 May '05

17 May '05

On 13 May 2005 11:37, Bulat Ziganshin wrote: > Thursday, May 05, 2005, 1:56:12 PM, you wrote: > >>> it is true what to support unicode source files only StringBuffer >>> implementation must be changed? > >> It depends whether you want to support several different encodings, >> or just UTF-8. If we only want to support UTF-8, then we can keep >> the StringBuffer in UTF-8 and also FastStrings. (or you could >> re-encode the other encodings into UTF-8). > > srcParseErr contains call to "stepOnBy (-len)", and doing this will be > hard with UTF-8. although we can save pointer(s) to positions of > previous chars or even just reparse from scratch entire buffer - > printing source errors is not so frequent task. of course, it will be > great to just save this position for us :) I don't think that's a problem - instead of storing last_len in the lexer state we just store the actual number of bytes (or the StringBuffer). >> The question is what Alex should see for a unicode character: Alex >> currently assumes that characters are in the range 0-255 (you need a >> fixed range in order to generate the lexer tables). One possibility >> is to map all Unicode upper-case characters to a single character >> code for Alex, and similarly for the other classes of character. > > i don't know anything about Alex intrinsics, and can only say that any > solution is better to do INSIDE Alex, so other programs using it will > also get Unicode support The right thing to do as far as Alex is concerned is to collapse the full Char range onto a smaller number of character classes which are then lexed using the standard DFA lexer. Alex could figure out the required character classes automatically. However, a simpler solution for GHC would be to essentially do this by hand, since we already know what the character classes for Haskell are (upper case, lower case, digit etc.), and we already have some code that determines character classes for Unicode characters (GHC.Unicode). So for example you map upper-case unicode character onto 0xfe, lower-case onto 0xfd, and so on. > ... if this problem is just about changing charType in Ctype.lhs - we > can > use some sort of hack. for example, use current scheme until there is > some char greater than (chr 255). in this moment we create array for > classification of chars 256-65535. all chars greater than (chr 65535) > is > better to recognize with calls to appropriate functions, i think We could use a combination of Ctype and GHC.Unicode to find character classes. > btw, Ruby supports writing numbers in form 1_200_000. how about adding > this feature to GHC? ;) I'm not keen on that. We don't tend to introduce features that break Haskell 98 compatibility unless they're quite compelling - and this is only a small change. It would introduce another way that code written for GHC would gratuitously fail to compile with another compiler. This kind of change is best left until the next major revision of the language. Cheers, Simon

2 1

RE: ghc-6.4 fPIC compilation problem on amd64
by Simon Marlow 17 May '05

17 May '05

On 13 May 2005 23:11, ariep(a)xs4all.nl wrote: >> That's a new one on me. Does your 6.2.2 build otherwise work, i.e. >> can you build & run programs with it? > > ghc won't even compile a 'main = putStrLn "hello world"' program: > >> # ghc --make Main.hs >> Chasing modules from: Main.hs >> Compiling Main ( Main.hs, Main.o ) >> Linking ... >> > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/b in/ld: > Main.o: relocation R_X86_64_32 against `__stginit_Main_' can not be > used when making a shared object; recompile with -fPIC >> Main.o: could not read symbols: Bad value >> collect2: ld returned 1 exit status > > :( Then it looks like your 6.2.2 is broken, or perhaps incompatible with some other tools you have locally. I suggest re-installing (I believe Gentoo has a ghc-bin package that you can install from scratch). Cheers, Simon

1 0

ANN: SearchPath 0.5 and Request for https module URLs
by S. Alexander Jacobson 17 May '05

17 May '05

At Simon Marlow's suggestion, I have implemented Internet import chasing. You wrap your compiler/interpreter call with "searchpath", pass the correct parameters and it will find all your module imports, if they are not local, it will look them up in Internet module directories you specify, retrieve the relevant modules, put them on your path and then run your compiler/interpeter with the appropriate commandline options. e.g. searchpath ghc MyModule.hs OtherModule -isomeDir --internet localModules.map -iotherdir --internet https://hackage.org/modules.map -iotherDir2 -cache cache will result in the download of all the modules it can find each directory and execute: ghc MyModule.hs OtherModule -isomeDir --icache/internet1 -iotherdir -icache/internet2 -iotherDir2 Mapfiles have the form: #comment HAppS http://happs.org #comment *.*.HaXml.* http://www.cs.york.ac.uk/fp/darcs/HaXml/src #another comment Simon, I am now handling import chasing, Haskell extensions, literate haskell, latex haskell, and HTTPS URLs (via curl). It works with the ghc command line, except that it doesn't handle multiple directories passed on the same -i. (Can someone tell me what the official path separator is for ghc -i?). It doesn't yet work with other compilers/interpreters, but should be easy to adapt. It does not handle package files right now. Request: This will work better as people expose their modules via http(s). If your modules are visible this way, please email me a baseURL. Location: http://happs.org/SearchPath.hs -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

1 0

`Dumatel' software announcement
by Serge D. Mechveliani 16 May '05

16 May '05

A N N O U N C E M E N T D u m a t e l a prover program based on equational reasoning, Version 1.02 is available, together with its source program and manual book, at the following addresses: http://www.botik.ru/~mechvel/papers.html click at `dumatel' (Russian site), ftp.botik.ru/pub/local/Mechveliani/dumatel/ (same site), http://www.haskell.org/dumatel/distrib/ (USA site) Dumatel-1.02 is --------------- a prover based on many-sorted term rewriting (TRW) and equational reasoning. It is a program package written in a purely functional, `lazy' language Haskell. It is presented as a library of functions and data structures. To use Dumatel-1.02, user needs to be familiar with Haskell programming. What it has. Abilities ---------------------- * TRW interpreter `reduce', subdued to an explicitly given partial term ordering parameter. * `Unfailing' Knuth-Bendix completion methods ukb, ukbb, where the latter method extends the former with a certain specialized completion for the Boolean connectives. * The inductive prover `prove', including also the refutation procedure for the predicate calculus, using ukbb. The prover reasons about equational specifications, transforming them dynamically. * So far, it is able to solve in a real time only simple problems, and not all of them. Examples of successful proof: (1) Prove list |-inductive- forall Xs ((reverse reverse Xs) = Xs), where "reverse" is defined recursively via the list concatenation "+", and "+" defined recursively via ":" (`cons'). (2) naturalNumbers |-inductive- forall [n, m] (n+m = m+n), where "+" is defined via the "successor" operator by the equations [n+0 = 0, n+(s m) = s (n+m)]. Example of failure: (3) naturalNumbers |-inductive- forall [n, m] (n*m = m*n), where the multiplication "*" is defined in (2) via "+": [n*0 = 0, n*(s m) = n + n*m]. See the book.ps for further information. Ports: Dumatel-1.02 was tested under ghc-6.2.2, Linux. ------ Manual (`book'): see dm/book.ps contained in the distribution. --------------- Remarks are welcome: mechvel(a)botik.ru -------------------- Serge Mechveliani, Program Systems Institute, 152020, Pereslavl-Zalessky, Russia. e-mail mechvel(a)botik.ru http://www.botik.ru/~mechvel

1 0

runghc, ".hs" suffix
by Frederik Eaton 14 May '05

14 May '05

(moving to a separate thread) Also, how hard would it be to make it so that runghc doesn't require script file names to end with ".hs"? Some people like to keep their executable names language-neutral. Frederik On Wed, May 11, 2005 at 10:55:03AM +0100, Simon Marlow wrote: > On 11 May 2005 07:37, Frederik Eaton wrote: > > > It looks like runghc is exiting with status 0 if there is a problem. > > Shouldn't this be non-zero? > > > > $ runghc -V > > The Glorious Glasgow Haskell Compilation System, version 6.4 > > $ runghc /dev/null; echo $? > > Could not find module `/dev/null': > > use -v to see a list of the files searched for > > (one of the roots of the dependency analysis) > > > > <interactive>:1:76: > > Failed to load interface for `Main': > > Could not find module `Main': > > it is not a module in the current program, or in any known > > package. 0 > > It turns out I fixed this bug after 6.4, but later the fix was > accidentally reverted. So thanks for reporting this again, it'll work > properly in 6.4.1. > > Cheers, > Simon >

1 0

RE: ghc-6.4 fPIC compilation problem on amd64
by ariep＠xs4all.nl 13 May '05

13 May '05

> That's a new one on me. Does your 6.2.2 build otherwise work, i.e. can > you build & run programs with it? ghc won't even compile a 'main = putStrLn "hello world"' program: | # ghc --make Main.hs | Chasing modules from: Main.hs | Compiling Main ( Main.hs, Main.o ) | Linking ... | /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: Main.o: relocation R_X86_64_32 against `__stginit_Main_' can not be used when making a shared object; recompile with -fPIC | Main.o: could not read symbols: Bad value | collect2: ld returned 1 exit status :( Greetings, Arie

1 0

Fwd: Re[2]: Unicode source files
by Bulat Ziganshin 13 May '05

13 May '05

Sorry, Simon, are you received this message? This is a forwarded message From: Bulat Ziganshin <bulatz(a)HotPOP.com> To: "Simon Marlow" <simonmar(a)microsoft.com> Date: Thursday, May 05, 2005, 10:13:37 PM Subject: Unicode source files ===8<==============Original message text=============== Hello Simon, Thursday, May 05, 2005, 1:56:12 PM, you wrote: >> it is true what to support unicode source files only StringBuffer >> implementation must be changed? SM> It depends whether you want to support several different encodings, or SM> just UTF-8. If we only want to support UTF-8, then we can keep the SM> StringBuffer in UTF-8 and also FastStrings. (or you could re-encode the SM> other encodings into UTF-8). srcParseErr contains call to "stepOnBy (-len)", and doing this will be hard with UTF-8. although we can save pointer(s) to positions of previous chars or even just reparse from scratch entire buffer - printing source errors is not so frequent task. of course, it will be great to just save this position for us :) making FastString UTF-8-enabled would be great. it needs changes in lengthFS, indexFS and may be cmpFS (can the UTF-8 chars be compared with just memcmp?). also i don't know about hPutFS. win32 console works in either oem or ansi 8-bit encoding SM> The question is what Alex should see for a unicode character: Alex SM> currently assumes that characters are in the range 0-255 (you need a SM> fixed range in order to generate the lexer tables). One possibility is SM> to map all Unicode upper-case characters to a single character code for SM> Alex, and similarly for the other classes of character. i don't know anything about Alex intrinsics, and can only say that any solution is better to do INSIDE Alex, so other programs using it will also get Unicode support ... if this problem is just about changing charType in Ctype.lhs - we can use some sort of hack. for example, use current scheme until there is some char greater than (chr 255). in this moment we create array for classification of chars 256-65535. all chars greater than (chr 65535) is better to recognize with calls to appropriate functions, i think btw, Ruby supports writing numbers in form 1_200_000. how about adding this feature to GHC? ;) Lexer.x: @decimal = $digit [$digit \_]* @octal = [$octit \_]+ @hexadecimal = [$hexit \_]+ StringBuffer.lhs: parseInteger :: StringBuffer -> Int -> Integer -> (Char->Int) -> Integer parseInteger buf len radix to_int = go 0 0 where go i x | i == len = x | otherwise = case (lookAhead buf i) of '_' -> go (i+1) x c -> go (i+1) (x * radix + toInteger (to_int c)) -- Best regards, Bulat mailto:bulatz@HotPOP.com ===8<===========End of original message text=========== -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0