March 2004 - Haskell - Haskell.org

Socket barfs in thread
by jason feingold 31 Mar '04

31 Mar '04

When I create a socket, listen, and close it, it shuts down cleanly but when I pass the socket to a new thread I get four to six of the following message: awaitRequests: unexpected wait return code 4294967295 These seem to come after the main thread exits. It would seem that the socket has a thread affinity? Should sockets only be used in thread in which they were created? I'm using GHC 6.2.1 on Win2K. Thanks, Jason Feingold --------------------------------- Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time.

1 0

RE: [Haskell] Programming language shootout (completing the Haskell entry)
by Simon Marlow 30 Mar '04

30 Mar '04

> >From: John Hughes <rjmh(a)cs.chalmers.se> > >Actually the cache behaviour of code generated by GHC isn't > at all bad. > >I know because I ran a student project a couple of years ago to > >implement cache-friendly optimisations. The first thing they did was > >cache profiling of some benchmarks, and to our surprise we > discovered > >the cache behaviour of lazy code is already pretty good. You > get a lot > >of structure in the evaluation of lazy code -- it just isn't > evident in > >the source code! > > John, could you describe in some more detail why the code behaved well > w.r.t. cache performance? I think this is interesting, and > what you say is quite counterintuitive. I've done some cache profiling of GHC's code myself, and Nick Nethercote did some very detailed measurements a while back (see his recent post for details). The upshot of what he found is that we could benefit from some prefetching, perhaps on the order of 10-20%. Particularly prefetching in the allocation area during evaluation, to ensure that memory about to be written to is in the cache, and similar techniques during GC could help. However, actually taking advantage of this is quite hard - prefetching instructions aren't standard, and even when they are getting any benefit can depend on cache architecture and other effects which vary between processor families. Getting things wrong often results in a slowdown. It's just too brittle. There are probably other techniques that could help improve cache behaviour, but my feeling is that there aren't any significant wins to be had here; John's comments above appear to back this up too. Cheers, Simon

3 2

Consultant directory
by Mark T.B. Carroll 29 Mar '04

29 Mar '04

I was wondering if it might be a good idea to build up some list of clever Haskell people who would be happy to do consultancy work on advanced techniques. Something along the lines of name, location, contact information, special expertise. I know that there are a couple of companies out there who are willing to do that sort of thing, but sprinkled among university faculty, etc. there must be a whole lot more people out there, often with quite unique expertise regarding how to bend Haskell to various problem domains, who are willing to help out interesting projects but not as their full-time job. Of course, who might volunteer to compile and maintain such a list is another matter, even if it's thought to be a good idea. (-: Perhaps, collating the information would most naturally be part of the HC&A report compilation process, then it could just be copied to a separate web page too. -- Mark (inventing work for people again)

2 2

Final CFP: DALT'04 - Second International Workshop on Declarative Agent Languages and Technologies
by DALT'04 29 Mar '04

29 Mar '04

------------------------------------------------------------- F I N A L C A L L F O R P A P E R S The Second International Workshop on Declarative Agent Languages and Technologies (DALT-2004) http://centria.di.fct.unl.pt/~jleite/dalt04/index.htm submission deadline: April 1st to be held at the The Third International Joint Conference on Autonomous Agents & Multi-Agent Systems (AAMAS 2004) New York, USA July 19th, 2004 Post-proceedings published by Springer ------------------------------------------------------------- ---------- Overview: ---------- Building multi-agent systems still calls for models and technologies that ensure system predictability, enable feature discovery and verification, and accommodate flexibility. Declarative approaches offer to satisfy precisely these properties of large-scale multi-agent systems. Recent advances in the area of computational logics provide a strong foundation for declarative languages and technologies. Equipped with such strong foundation, declarative approaches can enable agents to reason about their interactions and their environment and hence not only establish the required tasks but also handle exceptions that arise in many systems. However, a great effort still has to be done to make formal methods and declarative technologies available to the broader agent community, and to apply theoretical results to enable practical implementation of agent systems. Accordingly, Declarative Agent Languages and Technologies (DALT) workshop aims at bringing together (1) researchers working on formal methods for agent and multi-agent systems design, (2) engineers interested in exploiting the potentials of declarative approaches for specification of agent-based systems, and (3) practitioners exploring the technology issues arising from a declarative representation of systems. Topics of interest include, but are not limited to: Declarative agent communication and coordination languages Declarative approaches to the engineering of agent systems Experimental studies of declarative technologies Industrial and commercial experiences with declarative agent technologies Formal methods for the specification and verification of agent systems Computational logics in multi-agent systems Argumentation and dialectical systems Declarative description of contracts and negotiation issues Lessons learned from the design and implementation of agent systems Declarative paradigms for the combination of heterogeneous agents Constraints and agent systems Declarative policies and security in MAS Knowledge-based and knowledge-intensive MAS Modeling of agent rationality ---------------- Important dates: ---------------- Submission: April 1st, 2004 Notification: May 1st, 2004 Final Version: May 21st, 2004 DALT 2004: July 19th, 2004 ------------ Submission: ------------ Papers should be written in English, formatted according to the Springer LNCS style, and not exceed 16 pages. Paper submission is electronic via the conference home page. ------------ Publication: ------------ A printed volume with the proceedings will be available at the workshop. Authors of papers presented at the workshop will be asked to extend their contributions, possibly incorporating the results of the workshop discussion, to be included in the workshop post-proceedings. Post-proceedings will be published by Springer-Verlag as a volume of the Lecture Notes on Artificial Intelligence (LNAI) series. --------------------- Organizing Committee: --------------------- João Leite (Universidade Nova de Lisboa) Andrea Omicini (Università di Bologna a Cesena) Paolo Torroni (Università di Bologna) PInar Yolum (Vrije Universiteit Amsterdam) ------------------ Program Committee: ------------------ Rafael Bordini, The University of Liverpool, UK Marco Colombetti, Politecnico di Milano, Italy Stefania Costantini, Università degli Studi di L'Aquila, Italy Mehdi Dastani, Universiteit Utrecht, The Netherlands Jürgen Dix, The University of Manchester, UK Michael Fisher, University of Liverpool, UK Mike Huhns, University of South Carolina, USA Catholijn Jonker, Vrije Universiteit Amsterdam, The Netherlands Alessio Lomuscio, King's College, London, UK Viviana Mascardi, DISI, Genova, Italy John Jules Ch. Meyer, Universiteit Utrecht, The Netherlands Charles L. Ortiz, SRI International, Menlo Park, CA, USA Sascha Ossowski, Universidad Rey Juan Carlos, Madrid, Spain Lin Padgham, RMIT University, Australia Luís Moniz Pereira, Universidade Nova de Lisboa, Portugal Jeremy Pitt, Imperial College, London, UK Juan Rodriguez-Aguilar, Spanish Research Council, Spain Fariba Sadri, Imperial College, UK Marek Sergot, Imperial College, UK Onn Shehory, IBM Research Lab in Haifa, Israel Munindar Singh, North Carolina State University, USA Wiebe van der Hoek, The University of Liverpool, UK Wamberto Vasconcelos, University of Aberdeen, UK Michael Winikoff, RMIT University, Australia

1 0

HToolkit HSQL on Windows/GHC
by Clive Brettingham-Moore 29 Mar '04

29 Mar '04

So far no replies on Haskell-Cafe, and I noticed that a similar problem got no responce on htoolkit-users, so here goes: Is there a way to build the HToolkit HSQL library for GHC (6.0.1 when I tried, 6.2.1 now) on windows (particularly MySQL/Windows XP, but I wont say no to postgresql, ODBC & sqlite)? I assume people have tired and [I hope] succeded, but I got lost [I think] in the nasty place between the unix/cygwin libraries in GHC and the Windows focus of the compiled MySQL client library. Since haskell is mainly a hobby for me, and I don't have a lot of free time I haven't dug very deep, but not being able to interface my two of my favourite constructs (functional programming and relational databases) is getting to me. So any takers? C

3 4

RE: [Haskell] COM port IO on a Windows machine?
by Steve Carlisle 28 Mar '04

28 Mar '04

Again, sorry this doesn't help too much on Windows, but your test1 runs just fine on Mac OSX in both GHC and Hugs98. I changed the device to suit, but otherwise it was unchanged. hIsWritable reports True on Hugs98 but False on GHCi, curiously. On Windows, in Hugs98, I get a different error message Program error: <handle>: IO.hGetChar: permission denied but this changed to the same error message as yours when I started experimenting with the mode setting. Nothing I've tried seems to allow this to work. If you don't send first and only read, then it works fine. On Windows GHCi, I can only agree with your findings. At 13:32 23/03/2004 +1030, Peter Pudney wrote: >Thanks, Steve and Axel, for your help. I have got serial port IO working, but >the solution is a bit ugly. My solution (below) works on Windows 2000, >Hugs Nov >2003. It does not work with Windows 2000, GHI 5.04.2. Later tonight I will try >it on Windows ME with the latest versions of GHC and Hugs. > >The aim is to send a '?' character to a device on the serial port "COM2:". The >device waits for a button to be pressed, then sends back a character. The test >script then has to read this character from the serial port and display it. > >I first tried opening "COM2:" in ReadWriteMode, but this did not work with >either GHCi or Hugs. For my second attempt, I open and close the file "COM2:" >in the appropriate mode each time I send or receive a string. Its ugly, but it >works. > >I am still interested in hearing from anyone who can get this working nicely >with GHC. > >My code is below. > > > > > module SerialIO where > > > import IO > > >Attempt 1: > > > test1 :: IO () > > test1 > > = do > > com2 <- openFile "COM2:" ReadWriteMode > > hSetBuffering com2 NoBuffering > > isOpen <- hIsOpen com2 > > isWritable <- hIsWritable com2 > > isReadable <- hIsReadable com2 > > putStrLn $ "hIsOpen = " ++ show isOpen > > putStrLn $ "hIsWritable = " ++ show isWritable > > putStrLn $ "hIsReadable = " ++ show isReadable > > putStrLn "About to send..." > > hPutStrLn com2 "?" > > putStrLn "Reading..." > > c <- hGetChar com2 > > putStrLn [c] > > putStrLn "Hoorah!" > > hClose com2 > >Hugs Nov 2003 sends the character OK, but then... > >Reading... > >Program error: <handle>: IO.hGetChar: does not exist (file does not exist) > > >GHCI 5.04.2 gives hIsWritable = False, then "No such file or directory" >when it >attempts to hPutChar. > > > >Attempt 2: open and close COM2 for each transmission > > > test2 :: IO () > > test2 > > = do > > sendChar '?' > > c <- receiveChar > > putStrLn [c] > > > sendChar :: Char -> IO () > > sendChar c > > = do > > com2 <- openFile "COM2:" WriteMode > > hSetBuffering com2 NoBuffering > > hPutChar com2 '?' > > hClose com2 > > > receiveChar :: IO Char > > receiveChar > > = do > > com2 <- openFile "COM2:" ReadMode > > hSetBuffering com2 NoBuffering > > c <- hGetChar com2 > > return c > > >GHCI fails as before, but Hugs works.

1 0

Haskell type containing no non-_|_ values?
by Janis Voigtlaender 26 Mar '04

26 Mar '04

Hello, probably a trivial question: Is there a type in Haskell that contains only the undefined value _|_? The polymorphic type (forall a. a) has this property, but it seems it cannot be used, e.g., in a tuple: > x :: (Int,(forall a. a)) > x = (3,undefined) leads to errors both in Hugs and GHC. I guess I can help myself out using newtype: > newtype T = T (forall a. a) > x :: (Int,T) > x = (3,undefined) but would like to do without. Is there a way? Thanks, Janis. -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

4 5

2 Professorships + 2 lectureships in Computer Science
by Norman Paterson 25 Mar '04

25 Mar '04

Please pass this message on to anyone you may think may be interested. As part of an ongoing programme of expansion, applications are invited for the following posts in Computer Science. 2 Chairs and 2 Lectureships School of Computer Science University of St Andrews The School currently has 2 professors, 1 reader, 3 senior lecturer, 7 lecturers, and 10 post-doctoral fellows and provides a stimulating environment for research and teaching. It has a Research Selectivity Rating of 5A and an SSR of about 10:1. A new Computer Science building is currently under construction. Detailed information about School can be found at http://www.dcs.st-and.ac.uk/ Ron Morrison Closing date 28-Apr-2004. -- -- Norman Paterson Senior Scientific Officer; Purchase Officer School of Computer Science http://www.dcs.st-and.ac.uk/~norman/ University of St Andrews Tel +44 (0) 1334 463262

1 0

main::[String]->IO() ?
by Steffen Mazanek 24 Mar '04

24 Mar '04

Hello everybody, each time I write an application that makes use of command line arguments I have to copy&paste the code for dealing with these args to my program from a reference implementation, because it is so hard to remember. What do you think about changing the default type of main or providing an alternative, e.g., main_args, just like in C or Java? I think this would simplify everyday-programming a lot. Or are there any severe theoretical (semantical) problems (main is running in the IO monad either way)? Ciao, Steffen

5 6

Re: [Haskell] GHC binary for Cygwin
by Thomas Hafner 23 Mar '04

23 Mar '04

"Simon Marlow" <simonmar(a)microsoft.com> writes: > We would happily support it, but we don't have the resources. It'll be > supported if someone steps up to take on the responsiblity - the > advantage would be that you would get your name in lights on > > http://www.haskell.org/ghc/contributors.html How about publishing there, that somebody is wanted as a porter/packager for Cygwin? That could be a first, initial step. Regards Thomas

1 0