May 2001 - Glasgow-haskell-users

Socket Behaviour
by Steinitz, Dominic J 31 May '01

31 May '01

Can anyone tell me why the following code doesn't work as expected? Both the server and client hang. If I run server 20000 & and client <hostname> 20000 the server logfile produces [dom@lhrtba8fd85 twotest]$ more log.txt Thu May 31 14:35:39 BST 2001 Starting logging Thu May 31 14:36:08 BST 2001 Hello world 48 65 6c 6c 6f 20 77 6f 72 6c 64 so it looks like the hPutStrLn to the socket never completes. On the client side, "Hello world" gets sent but the hGetLine never completes. Client do sh <- connectTo host port hPutStr sh "Hello world" hFlush sh x <- hGetLine sh putStrLn x Server socket <- listenOn port (sh,host,portid) <- accept socket let loop = do b <- getBuffer sh 16 case b of Full msg -> do logMessage ofh (hexedMessage msg) loop Partial msg -> do logMessage ofh (hexedMessage msg) hPutStrLn sh "Finishing Logging" hFlush sh logMessage ofh "Finishing logging" hClose ofh in loop Dominic. Here's the full code: module Main (main) where import System import IO import Time import Socket import Char main :: IO () main = do prog <- getProgName args <- getArgs if (length args /= 1) then do putStrLn ("Use: " ++ prog ++ " <port>") exitWith (ExitFailure (-1)) else return () let port = read (args !! 0) :: Int in server (PortNumber (mkPortNumber port)) -- The server function creates a socket to listen on the port and -- loops to log messages. server :: PortID -> IO () server port = do ofh <- openFile "log.txt" WriteMode logMessage ofh "Starting logging" socket <- listenOn port (sh,host,portid) <- accept socket let loop = do b <- getBuffer sh 16 case b of Full msg -> do logMessage ofh (hexedMessage msg) loop Partial msg -> do logMessage ofh (hexedMessage msg) hPutStrLn sh "Finishing Logging" hFlush sh logMessage ofh "Finishing logging" hClose ofh in loop data Buffer = Full String | Partial String getBuffer :: Handle -> Int -> IO Buffer getBuffer h n = if (n <= 0) then return (Full "") else do x <- try (hGetChar h) case x of Right c -> do xs <- getBuffer h (n-1) case xs of Full cs -> return (Full (c:cs)) Partial cs -> return (Partial (c:cs)) Left e -> if isEOFError e then return (Partial "") else ioError e logMessage :: Handle -> String -> IO () logMessage hd msg = do clock <- getClockTime calendar <- toCalendarTime clock hPutStrLn hd ((calendarTimeToString calendar) ++ "\n" ++ msg) hFlush hd showHex :: Char -> String showHex x = let y = ord x in hexDigit (y `div` 16):hexDigit (y `mod` 16):[] hexDigit :: Int -> Char hexDigit x | (0 <= x) && (x <= 9) = chr(ord '0' + x) | (10 <= x) && (x <=16) = chr(ord 'a' + (x-10)) | otherwise = error "Outside hexadecimal range" hexedMessage :: String -> String hexedMessage msg = (map toPrint msg) ++ " " ++ unwords (map showHex msg) toPrint :: Char -> Char toPrint x = if ((isAscii x) && (not (isControl x))) then x else '.' module Main(main) where import System import IO import Socket main :: IO () main = do prog <- getProgName args <- getArgs if (length args /= 2) then do putStrLn ("Use: " ++ prog ++ " <host> <port>") exitWith (ExitFailure (-1)) else return () let host = args !! 0 port = read (args !! 1) :: Int in client host (PortNumber (mkPortNumber port)) client :: Hostname -> PortID -> IO () client host port = do sh <- connectTo host port hPutStr sh "Hello world" hFlush sh x <- hGetLine sh putStrLn x ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

RE: extending --make
by Simon Marlow 31 May '01

31 May '01

> I have a whish for the GHC `making' possibilities. > > ghc-5* -package-name --make > > is said trying to replace Makefile. But it is half-successful. > * First, it needs -ohi option working > (to move .hi -s to chosen directory). I've added a -hidir option which should do the right thing. > * Second, could GHC provide options for creating libraries, > adding to library? This might make it easier to build a library from Haskell files, but it would also be duplicating functionality that is already available. I don't see it as a priority, I'm afraid. > Explanation. > With ghc-4, I used Makefile and -odir, -ohi options to provide > the project installation. > Makefile contained > (1) > the project directory tree description, > variables holding the list of names for the .hs, .hi, .o files, > rules to convert .hs --> .o, and such. > Also it contained the library creation part: > (2) > foo: $(objectFiles) > ar -q export/libHSfoo.a `ls export/*.o` > ranlib export/libHSfoo.a > rm -f `ls export/*.o` So you can use the same makefile, but you can replace part (1) with a single rule which uses --make. Cheers, Simon

1 0

RE: package for ghci
by Simon Marlow 31 May '01

31 May '01

> The user (myself) thinks at this: > "HSmypkg" in package specification --> <prefix?>HSmypkg.a > <prefix?>HSmypkg.o > in the library directory. I've clarified this in the documentation, thanks for the comments. Cheers, Simon

1 0

extending --make
by S.D.Mechveliani 31 May '01

31 May '01

Hello, I have a whish for the GHC `making' possibilities. ghc-5* -package-name --make is said trying to replace Makefile. But it is half-successful. * First, it needs -ohi option working (to move .hi -s to chosen directory). * Second, could GHC provide options for creating libraries, adding to library? Explanation. With ghc-4, I used Makefile and -odir, -ohi options to provide the project installation. Makefile contained (1) the project directory tree description, variables holding the list of names for the .hs, .hi, .o files, rules to convert .hs --> .o, and such. Also it contained the library creation part: (2) foo: $(objectFiles) ar -q export/libHSfoo.a `ls export/*.o` ranlib export/libHSfoo.a rm -f `ls export/*.o` ------------------- Now, with ghc-5, I apply ghc -package-name foo -odir export ... --make .. The part (1) cancels due to --make. Further, as ghc-5 observes in the package specification library_dirs = [".../export"] hs_libraries = ["libHSfoo"], then, it can understand what library file is to be created - on demand. If ghc -c provided also the options like -addto-lib -a, -addto-lib -o, ... then it could `make' for the given package _with_ adding to library. So, GHC would be able to simplify Makefile to package setting. The matter is that Makefile has a strange language, far from Haskell. Also why the Haskell user has to study library creation with `ar', `ranlib, `ld'? This, and Makefile look rather like a system hackering. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

package for ghci
by S.D.Mechveliani 31 May '01

31 May '01

To my question on packages for ghci Simon Marlow <simonmar(a)microsoft.com> responds >> 5. ar -q libHSfoo.a *.o >> ld -r --whole-archive libHSdocon.a -o libHSdocon.o > Here's your problem: you named the output libHSdocon.o, but GHCi is > looking for HSfoo.o (because that's the name you gave in the package > spec). > > ld -r --whole-archive libHSfoo.a -o libHSfoo.o > > [..] Thank you. The matter was indeed in the name. And it was due to the `lib' prefix, not due to `docon'. Because there was a typo in my letter: ...--whole-archive libHSfdocon.a ... while in real experiment it was ...--whole-archive libHSfoo.a ... And I doubt whether the GHC implementation agrees at this point with the GHC User's guide. Section 4.11.2 says ---------------------------------------------- A package specification looks like this: Package {name = "mypkg" hs_libraries = ["HSmypkg"] ... } ... hs_libraries A list of libraries containing Haskell code for this package, with the .a or .dll suffix omitted. On Unix, the `lib' prefix is also omitted. extra_libraries ... ---------------------------------------------- The user (myself) thinks at this: "HSmypkg" in package specification --> <prefix?>HSmypkg.a <prefix?>HSmypkg.o in the library directory. But " `lib' is also omitted " - similarly as `.a'. Hence, the library directory should contain libHSmypkg.a libHSmypkg.o Now, ghci -package-mypkg sees "HSmypkg" in package specification but searches for the file HSmypkg.o. It adds `.o', but skips `lib'. On the other hand, `.o' has different status, it is separated by period. So I wonder. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Poll: System.exitWith behaviour
by Simon Marlow 30 May '01

30 May '01

The current behaviour of System.exitWith doesn't really make sense in a concurrent environment. The current semantics is to: - halt the current thread - run all finalizers (concurrently with any other currently running threads) - stop the system as soon as all finalizers have finished. One high-priority problem we also have is that a program which calls System.exitWith from inside GHCi will shut down the whole system. Here's my current proposal: - introduce a new exception constructor: ExitException ExitCode - System.exitWith causes (ExitException code) to be raised in the current thread. - If this exception propogates to the top of the thread, then the main thread is also sent (ExitException code). This only happens for a standalone executable (ie. one which was started by PrelMain.mainIO). - If this exception propogates to the top of the main thread, then the system is shut down as before - all finalizers are run to completion, then we exit. For GHCi, we can obviously catch the ExitException exception and recover, and there is no main thread in this case. An alternative is just to omit the third point and let the programmer handle propagation of the ExitException to the main thread. This is somewhat consistent with our current policy of leaving these kind of decisions up to the programmer: we currently don't implement any kind of process hierarchy, and there is no requirement for child threads to complete before the program exits, for example. Cheers, Simon

5 5

RE: Evacuated Object
by Simon Marlow 30 May '01

30 May '01

> I'm experimenting with GHC (5.00.1) on RedHat Linux 7.1, it's foreign > function interface (using .hsc files) and the SDL graphics > library (v1.2). > The curious thing is that the following code: > > main = sdlInit [sdlVideo[ > sdlQuit > > can be loaded into GHCi and executed as many times as I like, however, > if I then carry on and edit the module containing main, and > then perform a > reload (:r), I sometimes get an "EVACUATED object entered!" > message and GHC > crashes on me: Great bug! I managed to reproduce it here (except that I get a plain seg fault not a GC panic), and it turns out to be an obscure bug in the native code generator that only shows up with GHCi. Compiling the program with -fvia-C works around it. Many thanks for the report. Cheers, Simon

1 0

RE: package for ghci
by Simon Marlow 30 May '01

30 May '01

> 5. ar -q libHSfoo.a *.o > ld -r --whole-archive libHSdocon.a -o libHSdocon.o Here's your problem: you named the output libHSdocon.o, but GHCi is looking for HSfoo.o (because that's the name you gave in the package spec). True, the documentation doesn't give explicit instructions for building a package from start to finish. I'll add something for a future release. Cheers, Simon

1 0

package for ghci
by S.D.Mechveliani 30 May '01

30 May '01

To my questions on the package creation for ghci -package >> ... >> How should look a package for this? Simon Marlow <simonmar(a)microsoft.com> writes > The "package" consists of libraries, .hi files, and a package > specification. Which bit did you mean? I meant all the three + a whole story of its correct arrangement - to illustrate it on the given example of a single module project. But as you said, my scheme of action in mainly correct. So, let us go further. >> Is it created manually or by ghc -package-name ... ? >> ... >> For I have an impression that the ghc-5.00 User's guide cannot >> help in this situation. > The user's guide says, about -package-name: > > This option is added to the command line when compiling a > module that is destined to be part of package foo. If this > flag is omitted then the default package Main is assumed. > > seems fairly clear to me... which part are you confused about? I expected that the user would not need to (1) move .hi, .o files manually to /t/export, collecting them from all the project directories (2) archivate manually *.o to .a library, (maybe) (3) create manually the structure Package {...}. Note that the application project forces the user to do all this manually to install the project. I hoped -package-name --make would do (1) and (2). This fragment of User's Guide does not reject such hope. > Which parts of the documentation aren't being helpful to you? > [..] It looks that a newbie would not find out the needed order of action: 1. package specification, 2. ghc-pkg ... 3. ghc --make ..., 4. moving files and archivating to library. Does the Guide specify such order? Is it clear from the Guide which of these points can be done automatically? Where it is explained how to create a library .a from *.o ? A naive functional programmer would not know this, maybe, this is a system hacker's territory (?). I may mistake, this is only my impression. >> Then, after creating manually /t/export/libHSfoo.a >> and converting it by >> ld -r --whole-archive libHSfoo.a -o libHSfoo.o >> [..] >> >> it still does not work. ghci -package foo >> yields >> Loading package foo ... can't find .o or .so/.DLL for: HSfoo >> (libHSfoo.so: cannot open shared object file: No such file > It looks like there may be a problem with your package spec. > Could you list the contents of p.txt that you used to create the > package? I would reproduce the whole (short) story. ------------------------------------------------------- /home/mechvel/t/A.hs contains module A where a = 'a' and is one file project to build a package foo to reside in the directory /home/mechvel/t/export/ /home/mechvel/u/Main.hs imitates the user work with the package foo. It contains module Main where import A main = putStr ['b', a, '\n'] 1. Apply ghc-pkg -a < p.txt with p.txt containing Package {name = "foo", import_dirs = ["/home/mechvel/t/export" ], source_dirs = [], library_dirs = ["/home/mechvel/t/export" ], hs_libraries = ["HSfoo"], extra_libraries = ["HSfoo"], include_dirs = [], c_includes = [], package_deps = [], extra_ghc_opts = [], extra_cc_opts = [], extra_ld_opts = [] } 2. Test it with ghc-pkg -l 3. cd ~/t ghc -package-name foo --make A 4. mv *.hi *.o export/ cd export 5. ar -q libHSfoo.a *.o ld -r --whole-archive libHSdocon.a -o libHSdocon.o ----------------------------------------------------------- cd ~/t ghci -package foo ... Loading package std ... linking ... done. Loading package foo ... ghc-5.00.1: can't find .o or .so/.DLL for: HSfoo (libHSfoo.so: cannot open shared object file: No such file or directory) Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

ghc-5.00.1 compiling with pw32 for win32.
by hooh pxw 30 May '01

30 May '01

Hi, i am new comer/bie. --*PW32 the Posix-over-Win32 layer*-- http://sourceforge.net/projects/pw32 PW32 is primarily C runtime library for Win32 aiming to POSIX compliance. Its main concerns are effeciency and support even for low-end Win9x systems. Also, PW32 is collection of ported software, aiming to be GNU (etc.) distribution for Win32. LGPL. i have no time to test. if this work, tell me. sorry my lazy cut/paste. global funny thing? no *.hi file errors. ignore below message... __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/

1 0