February 2003 - Glasgow-haskell-users

RE: chains of IORefs
by Simon Marlow 06 Feb '03

06 Feb '03

> using IORefs, one can construct linked lists in Haskell > that resemble one's used in imperative C programming. > > eg, the following toy code creates a chain of 1000 linked records. > > import IOExts > > data Record= RecordNil > | Record String Int Chain > type Chain = IORef Record > > main=makeChain [1..1000] > > makeChain::[Int]->IO Chain > makeChain []=newIORef RecordNil > makeChain (a:as)=makeChain as>>= \chain-> > newIORef (Record "data" a chain) > > such structures will be garbage-collected "automatically", right? Yes. > in general terms, please comment on how well GHC supports code > that uses such structures. It should work fine. > now, to turn makeChain into a "lazy producer" requires adding an IO > to the type of Chain, yielding > > type Chain=IO (IORef Record) > > please comment on how well GHC would tend to support such a type. I'm not sure exactly what you mean by "support" in this context, but I'm not aware of any known bugs that would impact your use of the above type. Cheers, Simon

1 0

chains of IORefs
by Richard Uhtenwoldt 06 Feb '03

06 Feb '03

using IORefs, one can construct linked lists in Haskell that resemble one's used in imperative C programming. eg, the following toy code creates a chain of 1000 linked records. import IOExts data Record= RecordNil | Record String Int Chain type Chain = IORef Record main=makeChain [1..1000] makeChain::[Int]->IO Chain makeChain []=newIORef RecordNil makeChain (a:as)=makeChain as>>= \chain-> newIORef (Record "data" a chain) such structures will be garbage-collected "automatically", right? in general terms, please comment on how well GHC supports code that uses such structures. (I have no reason to suspect it would not be well-supported, but it never hurts to verify assumptions before plunging into coding.) now, to turn makeChain into a "lazy producer" requires adding an IO to the type of Chain, yielding type Chain=IO (IORef Record) please comment on how well GHC would tend to support such a type.

1 0

RE: ghc feature request: core notes
by Simon Peyton-Jones 06 Feb '03

06 Feb '03

I have to say that I'm not very keen. There is an annotation facility in Core, but it's easy for the notes to be discarded. So if they are conveying important info, it might easily get lost... and if not, what's it doing there in the first place. What do you expect to happen to these annotations? So just now I'm a bit sceptical. Core is a data type that I'm trying hard to keep simple. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 03 February 2003 23:24 | To: GHC Users Mailing List | Subject: ghc feature request: core notes | | I'm not sure how "generally useful" this would be, but I would find it | useful to be able to attach notes to core expressions from the Haskell | code. The idea being something along the lines of a code annotation like | a pragma. For instance, in my Haskell program I would have something | like: | | f x y = | case {-# CORE "my first note" #-} g x of | ... | | then, the core would come out with, instead of: | | case g x of ... | | we would have | | case {note "my first note"} g x of ... | | The reason I would find this useful is somewhat obscure, but the basic | idea is that I need to be able to both preprocess code and then change | core based on how it was preprocessed. I'd like to send annotations like | these out of the preprocessor so they can then be picked up later by my | core transformer. | | If this sounds like a good enough idea to go in, but no one has time to | implement it, I could do it myself (probably), but I thought I'd ask the | experts first (or if there's anything like this in there currently)... | | - Hal | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

RE: buffering woes
by Simon Marlow 06 Feb '03

06 Feb '03

> >Hal Daume III <hdaume(a)ISI.EDU> writes: > > > > > > > >>Not for me, GHC 5.04.2 (Solaris). > >> > >>here it goes right the first time, but then i have to type two more > >>letters (in this case 'b\n') to get it to respond to "hello". > >> > >> > > > >Solaris has a slightly bizarre buffering scheme in "raw" terminal > >mode, whereby it buffers 4 characters at a time, instead of passing > >on each character immediately. Try > > > > stty -icanon min 1 > > > >(or something similar) to fix it? > > > > > Someone must have failed setting the tty mode. :-) > The 4 is (if I remember right) the VMIN value which is stored in the > same place as the EOF (^D = 4) character. It has to be set to 0 when > placing the tty in raw mode. Bingo. Now fixed, thanks all. Cheers, Simon

1 0

Your message to Glasgow-haskell-bugs awaits moderator approval
by glasgow-haskell-bugs-admin＠haskell.org 06 Feb '03

06 Feb '03

Your mail to 'Glasgow-haskell-bugs' with the subject Kontakt Lenste yeni yil firsati 1 Kutu Lens 35 Milyon USTELIK ADRESE TESLIM KACIRMAYIN_____6357474__ Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

buffering woes
by Hal Daume III 05 Feb '03

05 Feb '03

I expect the following to work, but it doesn't. Can someone help: 9:53am moussor:JavaInterp/ cat > Test.hs import System.IO main = do hSetBuffering stdout NoBuffering hSetBuffering stdin NoBuffering loop where loop = do putStr "> " s <- getLine putStrLn $ "You said: " ++ s loop 9:54am moussor:JavaInterp/ ghc Test.hs -o test 9:54am moussor:JavaInterp/ ./test > hello foYou said: hello > o^Ctest: interrupted 9:54am moussor:JavaInterp/ ./test > hello foYou said: hello > o You said: foo > You said: > You said: > ^Ctest: interrupted 9:55am moussor:JavaInterp/ basically, i have to type 'fo' before it will give me my first reply. I thought the two calls to hSetBuffering would fix this. -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

4 4

RE: Problem with --split-objs on windoze (when building HOpenGL)
by Simon Peyton-Jones 05 Feb '03

05 Feb '03

Sven, Peter, Did you two sort out what was going on here? We haven't a clue. (If there's some advice to offer to other users, we'll gladly add it to the FAQ.) Simon | -----Original Message----- | From: Peter Smith [mailto:smithp@gil.com.au] | Sent: 25 January 2003 01:26 | To: glasgow-haskell-users(a)haskell.org | Subject: Problem with --split-objs on windoze (when building HOpenGL) | | I'm having some difficulties with the --split-objs parameter when building | HOpenGL on win xp ine with --disable-split-objs. | | Tried uninstalling my 'normal' copy of perl & upgrading GHC to 5.04.2 but | am still getting the same error. | | Couldn't find anything in the archives, so anyone got any ideas?? | | $ make | ------------------------------------------------------------------------ | Recursively making `all' in lib examples ... | PWD = /usr/local/HOpenGL-1.04 | ------------------------------------------------------------------------ | ------------------------------------------------------------------------ | make all - --unix; | in /usr/local/HOpenGL-1.04/lib | ------------------------------------------------------------------------ | rm -f GL_Marshal.o ; if [ ! -d GL_Marshal_split ]; then mkdir | GL_Marshal_split; | else find GL_Marshal_split -name '*.o' -print | xargs -s 8000 rm -f | __rm_food ; | fi ; | "/cygdrive/c/ghc/ghc-5.04.1/bin/ghc" -package lang -package-name HOpenGL | -i../GL | UT -I../GLUT/include -cpp -DCALLCONV=stdcall -split-objs -odir | GL_Marshal_split | -fglasgow-exts "-#include <GL/glut.h>" -O -c GL_Marshal.hs -o GL_Marshal.o | Can't locate utf8.pm in @INC (@INC contains: .) at | c:\ghc\ghc-5.04.1\ghc-split l | ine 50, <TMPI> line 7. | BEGIN failed--compilation aborted, <TMPI> line 7. | make[1]: *** [GL_Marshal.o] Error 1make: *** [all] Error 1 | | | Peter | | At 01:10 PM 24/01/2003 +0100, Sven Panne wrote: | Peter Smith wrote: | > I'm getting the following error when running make all/make install (make | > depend worked fine). | > | > I'm building on windoze xp home, GHC5.04.1, cygwin. Any ideas? [...] | Hmmm, this looks like a GHC/Perl installation problem (GHC uses Perl | e.g. for -split-objs). A few questions: | * Can you compile and link a simple HelloWorld.hs with -O? | * Can you do the same with -O *and* -split-objs? | * Does HOpenGL work when configure is called with --disable-split-objs? | Cheers, | S. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

How do I profile Prelude functions?
by Bayley, Alistair 05 Feb '03

05 Feb '03

I can't find advice in the GHC manual on determining how much time your program spends in Prelude functions. I've discovered that I can alias a Prelude function e.g. > import Data.Set .... > myMkSet = mkSet ... which will give me a cost-centre for mkMySet. Isn't there an easier way to do this? ***************************************************************** The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. *****************************************************************

1 0

RE: Modifying GHC to accept external Styx code
by Simon Peyton-Jones 05 Feb '03

05 Feb '03

Aha! So what you really want is a code generator! I suggest you take a look at C--. www.cminusminus.org (Check out the papers especially.) It's designed for exactly what Stix is designed for, only much, much better. There's a prototype implementation from Fermin Reig, and Norman Ramsey is working hard on another. (I'm ccing him.) Hmm. Maybe someone can write a C-- front end for GHC's code generator! Simon | -----Original Message----- | From: Mark Alexander Wotton [mailto:mwotton@cse.unsw.EDU.AU] | Sent: 03 February 2003 22:19 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users(a)haskell.org | Subject: RE: Modifying GHC to accept external Styx code | | On Mon, 3 Feb 2003, Simon Peyton-Jones wrote: | | > | > | I want to use GHC as a backend for my experimental compiler. | > | I'm trying to modify it to accept styx code from my compiler, and I'm | > | having some trouble working out where I need to make changes. In | > truth, | > | GHC is more haskell code than I've ever seen before in one place, and | > I'm | > | a bit lost: can anyone suggest which modules I should become familiar | > with | > | and which I should leave alone? | > | > You don't say what 'styx code' is. My advice: either translate styx to | > Haskell, or to External Core. (Probably the latter.) GHC can read both | > of these in without modification. | > | > External Core is a typed lambda calculus. | | Yes, I know External Core: I'm using it as my input language. (GHC is my | frontend as well.) The optimisation algorithms I want to implement need | a lower-level language than Core, which is why I want to use Styx, the | native generation intermediate language. Abstract C is also an option, but | if I've got to hack GHC to get either of them going, I'd rather do it for | Styx. | | Mark | | -- | no-one takes up music to play their own instrument | -- Randy Hiatt, Chalkhills list |

2 1

Re: GHC and C++ (was RE: Creating COM objects and passing out pointers to them via a COM interface)
by Sarah Thompson 04 Feb '03

04 Feb '03

I'm replying to two threads at the same time and cross posting my reply, because they are very relevant to each other. I'm sorry if anyone here ends up seeing this more than once as a consequence. [s] ------ > Sarah > > Did you get this problem sorted out? Not directly. I ended up building an 'outer' COM component in C++ that mapped an MSXML-like interface onto a simpler, internal COM component that wraps up the Haskell code. This approach seems to work well - I might have been able to build the necessary wrapper directly in Haskell using HDirect, but I was becoming aware that I was probably starting to take up an unreasonable amount of Sigbjorn's time with increasingly detailed questions and I didn't have time to figure out the necessary intricacies from scratch. HDirect seems very good, but I don't think it's currently in quite as stable a state as the main GHC release. The problems I had in building a version that works with the current GHC are an example of this. I'm not complaining - it worked well in the end, but I do think it might be a 'good thing' to consider rolling HDirect into the main GHC release at some point. The other thing that bit me was exception handling, or rather the default behaviour when an uncaught exception 'falls out' and reaches the top level of the runtime system. Currently, the functionality appears to be to abort the current process. Whilst this is probably desirable for a typical application executable (be that console or GUI based), it is a problem if it happens inside a COM component. My thinking is quite straightforward on this. Preferred behaviour should really be for a call to a COM component to fail returning an error code, rather than abort the calling process. 'Server-style' applications are usually expected to keep running when minor faults occur, rather than terminate. HDirect/GHC's current behaviour makes this difficult to achieve - I managed to successfully catch exceptions, but the price was needing to use some code based on DeepSeq to force deep strict evaluation for all state updates. This (seemingly) was the only way I could stop exceptions from happening in the context of the automatically generated COM wrapper - passing it a fully evaluated data structure was apparently the only solution available. However, this does break the advantages of laziness as applied to the current state of the object - it would be pretty neat, for example, to be able to define a view of a database as the result of an expression involving relational algebra combinators, with the query evaluated one record at a time as the data is pulled back by the client application. The need for DeepSeq forces strict evaluation, so this benefit is lost. This is actually more of an issue than it might immediately seem - many queries don't actually need to retrieve all of a record set before useful things can be done. A particular example is updating a GUI, where a list box reflects the results of a query. Lazy evaluation will allow the screen to start updating more or less immediately even on a query that returns thousands of records - strict evaluation might incur a delay of a few seconds (for a very complex query or a large database) before updates can start happening. In an ideal world, what I'd dearly love to see would be an HDirect option that allows a choice between existing functionality and having calls return a failure code, or better still allowing a user-supplied handler function to determine the correct course of action. So, to sum up my wish list: 1. A facility to replace the default uncaught exception behaviour for COM objects and similar shared library code 2. HDirect rolled into the main GHC tree 3. A facility within HDirect to create COM objects based on existing (Haskell) data structures, returning an interface pointer as a return parameter on a call to an existing COM object. (This was the question Simon asked if I'd had an answer to - I've attached a copy below for reference). Sarah PS: I've not yet looked closely at the .NET integration in GHC yet, but I can imagine myself having a very similar wish list in that case too. -------- Hi again, A slightly harder problem this time. I want to implement something that looks something like the Microsoft XML parser. This is a very COM heavy contraption that provides an interface that looks to client applications like a tree of COM objects that reflects the internal structure of an XML document. The idea is, you start with the document object, make a method call requesting the root node, and have a COM object that wraps that node returned to you. You can then request the children of that node, and their children and siblings, all which involves being passed back interface pointers to COM objects. Effectively, there is one COM object per syntactic item in the XML document. I already have my document object working nicely. This is where the actual database resides. I want to be able to spawn views of this database as COM objects. When I've done this in the past (using ATL mostly, euuuugh), I've used an IDL definition something like HRESULT CreateView([in,string] BSTR query, [out,retval] IDbView **); What's the correct way to implement the necessary Haskell code to create the coclass and return a pointer to it? I fiddled around for ages, but either couldn't get GHC to like the types I was using, or when I finally got it to compile, I found that my test harness was being passed an invalid COM object. This should be simple stuff, so I'm sure someone will have done it! Secondly, it is a nasty, though fairly common trick, if you know your objects are going to be created in the same process space, to allow them some 'behind the scenes' communication. In my case, I'd like to avoid needing to serialise and deserialise the data in a view during creation of these child objects (of which there may be a great many, and which may be created on the fly rather often). Ideally, I'd like to be able to do something like: newView :: String -> State -> IO State newView db (State st) = do db <- readIORef st r <- newIORef db -- Insert some kind of COM magic here return (State r) so the database content gets copied within the Haskell environment (lazily, I'd hope), without needing to be serialised and deserialised. Is this feasible? One (messy) approach might be to create a bunch of extra interfaces on the main database object, then create 'thin wrapper' child objects that simply make calls back into the parent object. I'm not so keen on that for various reasons, however. Sarah

1 0