Re: Talking with the compiler
Hello Simon, Am 18.01.2004 um 11:31 schrieb Ketil Malde: [EMAIL PROTECTED] (Hans Nikolaus Beck) writes: in order to build a programming environement, it would be nice to ask the GHC about symbols etc found in a given Haskell program. I suppose a programming environment could talk to GHCi (which provides commands like :type, :info, :browse to explore the currently defined symbols)? I've look shortly at the GHCi documentation. So I think it would be possible to include a GHC engine into a IDE application by redirecting input and output from GHCi to pipes (I rembemer that emacs used something similar for doing it's compile stuff). But that's hardcore UNIX, I've forgot how to do that :-((( sm For the Visual Studio plugin we're going to need to talk to GHCi. We sm plan to do this by designing an appropriate API for GHCi and calling it sm directly; you *could* do it by talking over a pipe, but it's going to be sm a lot of work (and slow). If you want to do this, please talk to us sm about what API you'd like to see, and we can hopefully implement sm something that will be generally useful. we need exactly such a thing for the typebrowser that we are building on top of the theory presented in our ICFP'03 paper. The browser is not going to interact with the compiler, it just needs to gobble up the environment of a given module to get going. Clearly, we would like to spare ourselves the royal pain to implement the module system and all that. At the present stage, the most useful functionality for us would be: 1. Make GHC load a module and then dump the entire symbol table of the current module (all accessible symbols (qualified and unqualified), classes, instances, typings), in some external representation. That external representation might be XML where you just use the names of the types and constructors inside of GHC. (I actually started to hack this up, but it would be nice to have a declared standard for such a representation. Yes, it could be automated using drift, but not all the constructors and fields are interesting outside of GHC, so you want to have intelligent shortcuts. Example: information about which fields in a record type are banged does not matter if you are just interested in typing.) It would be even nicer, if there was a way to have GHC ignore all definitions in the current module and just construct the imported environment. As far as I've seen the datastructures inside GHC allow for that. 2. How about making the annotated syntax tree available in an XML format adapted from the datatypes of the GHC parser? BTW, does Language.Haskell.Parser.parseModule already perform infix resolution? Of course, a library API would be useful, too, but the internal structure of GHC's symbol table is sufficiently complicated that you may not want to expose it. Instead, you'd like some way to look up the information attached to a (qualified) symbol in the current module's scope and get the result in a simple format, i.e., probably not using GHC's internal datatypes. -Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
fun with sockets (ghc-5.04.1)
Hi, I'm running into a problem using server code (running on a UNIX domain socket) that I basically snatched from Simon Marlow's web server: ++ mainLoop sock defUser getMs = do putStrLn Accepting connections... installHandler sigPIPE Ignore Nothing loop (0::Int) where loop n = do (connection, peerAddress) - accept sock h - socketToHandle connection ReadWriteMode forkIO ( (talk n getMs defUser h `finally` goodBye n h) `Exception.catch` (\e - putStrLn (Exception: ++ show e)) ) loop (n+1) goodBye n h = do putStrLn (show n ++ : finished) hClose h ++ After processing a random number of connections, the server dies with Fail: invalid argument Action: accept Reason: Invalid argument after finishing the last connection. For the record, here is the code that is executed for each connection: ++ talk n getMs user h = do hSetBuffering h LineBuffering putStrLn (show n ++ : ) str - hGetLine h lstr - hGetLine h putStrLn (...: ++ lstr) -- last output before core dump let msglength = read (takeWhile isDigit (drop 1 lstr)) rawmsg - hGetContents h putStrLn (Got ++ show (length msg) ++ characters) ++ The machine is Linux kailua 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown The problem seems to go away if I switch to INET sockets, so I'm also including my initialization code: ++ withSocketsDo $ do sock - socket AF_UNIX Stream 0 bindSocket sock (SockAddrUnix path) listen sock maxListenQueue getMs - initializeAll mainLoop sock defUser getMs ++ -Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sockets (ghc-5.04.1)
Volker, I only saw your answer today since it was filed in my Haskell-mailing-list folder. Indeed, I've moved on to import Network.Socket and then duplicated part of my code. One thing that I found annoying was that the Protocol argument of Network.Socket.socket is not well specified. The type Protocol is abstract, but is a member of class Read. However, the Read syntax is nowhere specified. So I tried do sock - socket AF_UNIX Stream (read 0) which works, but I'm sure that more informative strings work, too. -Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
sockets (ghc-5.04.1)
Hi, I have a program that uses INET sockets and I wanted to change it to use Unix domain sockets. Here is the relevant code: import Network withSocketsDo $ do sock - listenOn portID (h, hostname, portnumber) - accept sock while this code works fine with portID = PortNumber (toEnum 9099) I get an error message when running it with portID = UnixSocket /home/thiemann/.socket Fail: user error Reason: accept: can't peform accept on socket in status Bound The file is still created with the right permissions: srw---1 thiemann users 0 Jan 14 22:48 /home/thiemann/.socket= Since there is not much that I can do in the Network module, it looks like there is a problem in its implementation? BTW, I'm running ghc-5.04.1 on this machine: [kailua] 108 uname -a Linux kailua 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown It would be very convenient if I could use Unix sockets as they save me from implementing an authentication protocol. -Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: openFile and threads
Hi, one thing that I gleaned from Matthias's strace output is the fcntl system calls to obtain the locks. They are not really needed for my application and could be avoided using the POSIX library. However, this does not seem to be a big issue just from the cost of the system calls, because there is no noticeable difference between Matthias's C programs. But it sounds like in your case you need to open lots of (small?) files. What do you do with the contents of the files? Yes, the files are small. They typically contain less than 10 words. These words are key words and the Select program selects file names based on boolean expressions formed from the key words. What I'm actually doing is implementing a data base for email messages, where these file names are the primary keys for the messages. Each message is represented by two files of the same name (but in different directories), the data file containing the raw message, and the meta data file that just contains a list of key words. Keeping the meta data in this way allows for smooth interaction with file synchronization across several computers. So it's necessary that each set of key words resides in its own file. I have created a web page with a little more argumentation about it: http://www.informatik.uni-freiburg.de/~thiemann/MailStore The downloadables may be a bit out of date, but you get the idea. Hope that helps. -Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
openFile and threads
Folks,
here is the piece of code that takes most of the time in a program I
have:
f6 = {-# SCC f6 #-}\gumd -
let fileName = usermetadir ++ gumd in
catch (do h - {-# SCC f6.1 #-} openFile fileName ReadMode
str - {-# SCC f6.2 #-} hGetLine h
_ - {-# SCC f6.2a #-} hClose h
return $ {-# SCC f6.3 #-} words str)
(const $ return [])
Profiling yields this output:
individualinherited
COST CENTRE MODULE no.entries %time %alloc %time %alloc
f6 MailStore 346 577 0.03.587.5 85.1
f6.3 MailStore 351 0 0.09.9 0.09.9
f6.2a MailStore 350 0 0.00.7 0.00.7
f6.2 MailStore 349 0 0.07.5 0.07.5
f6.1 MailStore 347 0 87.5 63.587.5 63.5
If I read this correctly, openFile performs 63.5% of all allocations
and takes 87.5% of the runtime.
Now I'm wondering about ways to cut that down:
1. How can I avoid the allocations inside of openFile?
2. Would it help to call f6 in different threads? That is, does a
thread yield when it calls an IO function?
Any help appreciated.
-Peter
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc -M
Folks, after using ghc --make happily in a project for a while I am switching to using Makefiles since I have a number of Main programs in the same directory that share a lot of modules. Now, since ghc -M does such a great job at gobbling up the dependencies, I wonder if it was not possible to extend its functionality a little bit so that it also determines the .o files that are required to link a Main program. I could imagine something like an -optdep-Main and then the program name. -Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
